放送と通信の「違い」を考える

　ホワイトスペースの話をするのに必要な、放送と通信の「違い」を考える。

　放送と通信に関しては、「融合」とかいう感じで、ごっちゃにしようという方向性が見られるが、

　電波の使い方で見ると、ちょっと違いがある。

---

＜＜放送は、みんなに受信してもらってなんぼの性格を持っている＞＞

　そのため、みんなが受信できる設備を持っていることが必要
　　（送信できるのは、免許を持った一部の人でいい）
　だけど、多少の混信があっても、ご愛嬌
　　（夜のＡＭラジオ放送とか）
　できるだけ、幅広く届いたほうがいい。なので、大出力にしたい
　　（１００Ｋｗとか）。
　バンド幅は、みんなが聞き取れればいいので、狭くすることも可能
　　（ＡＭなら、6Khzとか、まあ、中波帯はたしか9Khzだっけ？）


＜＜通信は、相手に確実に届くことを目的とする＞＞

　通信は双方向なので、受信機と送信機をもっていないといけない。
　混信すると、通信が成立しなかったり、混線で傍受される危険があるので、
　混信は避けたい。

　大出力にすると、混信する可能性が高くなるので、
　小出力にして、中継局（基地局）をつくって、基地局まで行くようにしたい。
　バンド幅は、いっぺんに送るには（時分割にするけど、それでも）ある程度の幅をもって、
　どっかーんと送りたい。

＜＜どっちにしても・・・＞＞

　一度決めた周波数帯を大幅に変更するのには、無駄が大きく、たいへん
　→地デジへの変更を見ればわかる。今までのアナログテレビは、ごみになる。
　逆に、今使っている周波数帯はインフラが出来ているので、
　そこに、同じようなビジネスを乗せるのは、簡単！！

---

■電波的に考えると・・・

●低い周波数帯は、遠くまで飛ぶので放送に使われる。

　中波＝ＡＭ：普通のラジオ
　短波＝ＳＷ：ラジオ（ラジオNikkei、Radio Japan、しおかぜ（拉致被害者の）等）
　超短波、極超短波＝ＦＭやテレビ：いろんなＦＭ局、いろんなテレビ局

　占有周波数帯幅が大きいもの(FM,テレビ）は、高い周波数帯にもっていっている。
　でないと、局数を多くできないから。

　ラジオおよびテレビの受信帯に関しては、受信インフラが整っている。
　なお、短波は、中距離の伝送には向いていないため、国際放送向けのため、中波帯ほど、受信インフラは整っていない。

●一方、高い周波数は、遠くには飛ばない（近距離なので）けど、
　広い占有周波数にしても、まあ、大丈夫なので、
　通信に利用されている

　　ケータイ
　　衛星通信
　　中継局間の通信

　ただし、高い周波数では、技術的な開発がいる。音声に直すためには、発振回路、検波回路、その他もろもろが低い周波数のものとは違うが、それらハード的なものも含めて、すべて開発しないといけない。
　そういう意味で、ケータイは、莫大な費用をかけて、インフラ整備がされているといえる。

---

と、ここまでの話をまとめて、やっとホワイトスペースの話にいけるが、今、時間がないので、ここでおしまい。
こんど、本題のホワイトスペースについて書く

UML等各種ダイアグラムのエラーチェック体系化（その２２：アクティビティ図 その２）

シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。

　現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、クラス図、ＥＲ図、ＤＦＤときて、
　前回、アクティビティ図を入れました。

　今回は、このアクティビティ図のエラーチェックです。

なお、ここで書いたとおり、いままでのまとめは、こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm

---

■前回のまとめ

　アクティビティ図は、こんなかんじで、ここにどんなもので書くかが記載されている。

　そして、ＲＤＢに入れる場合のテーブル名と項目はこんな感じ

●レーンテーブル
　　（レーンＩＤ，ロール（レーン名））
●エッジテーブル
　　（エッジＩＤ，エッジ種別、元ノード等ＩＤ，先ノード等ＩＤ，エッジ説明）
●エッジコネクタテーブル
　　（コネクタＩＤ，番号等）
●動作ノードテーブル
　　（動作ノードＩＤ，動作名、所属レーンＩＤ）
●オブジェクトノードテーブル
　　（オブジェクトノードＩＤ、オブジェクト名）
●制御ノードテーブル
　　（制御ノードＩＤ，制御ノード種別）
●コメントテーブル
　　（コメントＩＤ，コメント内容）

---

■エラーチェック内容

　アクティビティ図も、ＤＦＤ同様、あるアクティビティ関して、より詳細なアクティビティというのを記述できます。
　サブアクティビティと呼ばれるようです。
　で、この場合、ＤＦＤにおけるプロセスの詳細化での親子関係のチェック同様、

　　親アクティビティに接続している他アクティビティ、オブジェクトは、
　　その子のアクティビティのどれかと、接続していないといけない

というチェックが出来ます。

　これは、「動作ノードテーブル」に、「親動作ノードＩＤ」を追加すれば、ＤＦＤ同様でよさそうです。

　ただ、ここで、ＤＦＤのとき発生した、接続している相手も親子があって・・・・
　という話題がありますが、それについては、ＤＦＤのときも、分けて話していたので、
　今回もわけて話したいと思います。

---

ってことで、きょうはここまで

社内デジタル・サイネージ

　デジタルサイネージ（電子看板）ネタでこんなの

年齢・性別に応じて変化する電子看板
http://slashdot.jp/articles/09/08/21/0430255.shtml

をみたので、ちょっとデジタルサイネージについて書いてみる。

　メディアには、それぞれ、向き不向きの特徴があって、
　電子とはいえ、看板である以上、看板の特徴にそった使い方をするのが、効果的だと思う。
　そこで、看板の特徴だが、

「その場所にいる人に、同時に瞬時に同じ情報を提供する」

　たとえば、「ラーメン　らいらい軒」（てきとーに書きました、実在するかどうか分かりませんが、実在しても、以下の話とは関係ありません）という看板が見えたら、

　「あ、あのお店は、ラーメン屋さんで、名前はらいらい軒だ」

　と、その看板が見えた人は、瞬時にわかる。ふつう、「ラーメン　らいらい軒」と書いてあって、高級ブティックと思う人は少ない（いないかな）。各自に違う情報を提供したい場合には、看板以外のメディアを使う（ケータイとか）。

　なぜか？

　看板は、移動しながら（＝歩きながらなど）見るので、瞬時に、情報を読み取れるように提供しないといけない。そして、放送同様、だれでも見れるので、特定の人向けの情報を提供して、ほかの人が見て誤解するようでは困る。
　誰が見ても、同じ情報を、瞬時に提供する。それが看板の特徴である。

　そう考えると、人の顔を判断＝人によって情報を変えるっていうのは、筋が良くないかも・・？？

---

　で、そうすると、利用者属性で絞り込むより、場所で絞り込んだほうが筋がいいと思う。



　クラウドが、パブリッククラウドから、社内クラウドに話題が移っていったように、

　デジタルサイネージも
　　パブリックデジタルサイネージといえるトレインチャンネルから
　　社内向けのデジタルサイネージに移っていくんじゃないかと思う。



　そして、社内向けデジタルサイネージっていうと、結局、社内向け掲示板、黒板のデジタル化っていうことになるだろう。

---

　たとえば、社員の外出先。ホワイトボードに書いてあると思うけど、あれが、デジタルサイネージ化されて、パソコンやケータイのインターネット、メール等で記入・更新できると。（ま、そのデジタルサイネージが出ているところで修正できてもいいけど・・・）

　そして、その外出先は、デジタルサイネージで、会社の見える所にも掲示されているけど、パソコンやケータイからでも、その内容を、アクセス可能、つまりケータイからでも社内のネットにアクセスできれば、掲示内容が見れると・・・（社内情報をネットから見えちゃうのはまずいけど、社内のどこかにメールを送り、秘密の文章を書くと、掲示内容がメールされるならOKかも）


　さらにさらに、伝言板に居場所を書き忘れた不届き者がいても、デジタルサイネージを表示・入力するソフトから、「居場所追跡」ボタンをクリックすると、あらかじめ登録してあるケータイへ、（auのサービスだと）GPSマップを使って居場所を追跡して、記入すると・・・（あれ、GPSの緯度経度だけなのかな？地名まで教えてくれるのかな？GPSマップ・・ま、緯度経度さえわかれば、逆ジオコーディングすれば、住所がわかるからいいけどね）

---

　もちろん、掲示板だけじゃなく、会議室予約とかも、会議室にデジタルサイネージを置くことで、できる（この場合、電子ペーパーでデジタルサイネージをしたほうが、いいのかな？）

　さらに、自治体、学校レベルで面白そうな話があるんだけど、それには、ホワイトスペースの話を先したほうがいい気がするので、

　この話、つづく