ケータイの遠隔操作＆盗聴、「バグではなくて、仕様です」ってことはないよね？

ここのスラッシュドットニュース
外務省、幹部の執務室への携帯電話持ち込みを禁止
http://slashdot.jp/security/09/08/31/0551255.shtml
によると（以下斜体は上記サイトより引用）

朝日新聞の記事によると、外務省は来月1日から局長・部長級以上の全幹部の執務室への携帯電話持ち込みを禁止するそうだ。携帯電話の持ち主が知らない間に、遠隔操作で端末のマイク機能を使って周囲の会話を盗聴する「ロービングバグ」と呼ばれるケースがあるそうで、秘密保全の観点から禁止対象の拡大に踏み切ったそうだ。


この遠隔操作＆盗聴、「ロービングバグ」ってなってるけど、
本当にバグ？まさか、ケータイの仕様ってことはないよね・・・

つまり、
携帯電話をパソコンで受信するには　２
http://oshiete1.goo.ne.jp/qa3979591.html
とかあるけど、

まさかATコマンドを外部から、ケータイに向かって打つと、処理して実行しちゃうとか、そーいうことはないよね。

　そして、そのATコマンドに、「こちらから、着信音を立てないで、電話をかけたら、相手が取るようにする」と、「こちらから電話を切る」という操作ができるとか・・・ないよね（＾＾；）

　もしあったら、いろんなシステムに応用できて、なんか、ソリューションが増えて、SIerさんは、喜びそうだけど、一歩間違えると、超やばい、盗聴器になりそうな気が・・



　さすがに、そんな機能は入ってないか（＾＾；）

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

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

　現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、今、アクティビティ図のエラーチェックです。

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

---

■前回までの話

　アクティビティ図をＲＤＢに入れるには、

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

＊制御ノード：分岐・マージ、フォーク・ジョイン、開始、アクティビティ終了、フロー終了

という構成でいれて、チェック内容としては、

動作ノード（アクション、アクティビティ）で親子関係を考えたとき、
つまり、ある動作ノードの詳細化のアクティビティ図を記述した場合、

元の動作ノードに接続している、他の動作ノード、オブジェクトノードは、
その詳細化のアクティビティ図の動作ノードのいずれか１つ以上と、
必ず接続しているはずである。

というものでした。

で、さらにこれは、ＤＦＤと同じで・・・・というところで、終わっていたと思います。

---

■オブジェクトノードにも、親子がありえる。

　ＤＦＤのとき同様、オブジェクトノードにも親子関係がありえるので
（詳細化したオブジェクトノードという意味）
もうすこし、拡張して、

元の動作ノードと、他の動作ノード、オブジェクトノードが接続している場合、

その詳細化のアクティビティ図の動作ノードのいずれか１つ以上と、

他の動作ノード、オブジェクトノードそのもの、またはその子孫が

必ず接続しているはずである。


ということになります。

---

■で、オブジェクトノードにも、親子って？

　ここで、オブジェクトノードの親子について考えると、
オブジェクトノードが、ＥＲ図で記述されるようなデータであれば、
ＥＲ図内でも親子（継承関係とか）になっているはずです。

　ということで、ＥＲ図とかとも関係してくるのですが、
　このような、他の図との関係については、別の回（もっとあと）
で話すことになります。

　ただその場合、実は、アクティビティ図よりも、業務流れ図のほうが、他の図や表との流れが明確になり、ＲＤＢの構造的に見ると、業務流れ図のビュー（一部の情報省略）が、アクティビティ図になっています。
　そういう話も、別の回（もっとあと）で話すことになります。

---

■まとめ

ということでまとめると、
●レーンテーブル
　　（レーンＩＤ，ロール（レーン名））
●エッジテーブル
　　（エッジＩＤ，エッジ種別、元ノード等ＩＤ，先ノード等ＩＤ，エッジ説明）
●エッジコネクタテーブル
　　（コネクタＩＤ，番号等）
●動作ノード（アクション）テーブル
　　（動作ノードＩＤ，動作名、所属レーンＩＤ、親動作ノードＩＤ）
●オブジェクトノードテーブル
　　（オブジェクトノードＩＤ、オブジェクト名、親オブジェクトノードＩＤ）
●制御ノードテーブル＊
　　（制御ノードＩＤ，制御ノード種別）
●コメントテーブル
　　（コメントＩＤ，コメント内容）

（赤字が追加項目）

テスト内容は、
元の動作ノードと、他の動作ノード、オブジェクトノードが接続している場合、
その詳細化のアクティビティ図の動作ノードのいずれか１つ以上と、
他の動作ノード、オブジェクトノードそのもの、またはその子孫が
必ず接続しているはずである。

ということになります。

---

短いけど、こんかいはここまで

ホワイトスペースの利用としてのデジタルサイネージや特定ワンセグテレビ

　ホワイトスペースの利用方法として、アメリカでは通信に利用することを考えているらしいが、
　日本においては
　　　その周波数帯は、放送インフラが出来ているわけで、そのインフラをつぶしたり、
　　　放送のニュービジネスの芽をつむことになるし、
　　　通信にとっても、安定した基地局への投資ということを考えた場合、どーなんでしょう？
　っていうことで、よくないっていうことを、前回書いた。

　で、そこで、「放送のニュービジネスの芽」ってなによ？ってことになる。

　今回はそれについて、総務省の考え？と、実際の動きについて。

---

■ホワイトスペースについて

　ネットでこんなの見つけた。総務省の
情報通信審議会　情報通信政策部会
通信・放送の総合的な法体系に関する検討委員会（第12回）

の配布資料、資料６

ホワイトスペースについて
http://www.soumu.go.jp/main_sosiki/joho_tsusin/policyreports/joho_tsusin/houtai/pdf/090130_1_s6.pdf

の２ページ（ＰＤＦのページだと3/12）に

「特定エリア向けワンセグ」

というのがある。総務省では、ホワイトスペースを特定エリア向けワンセグ利用なんかにいいと思っているのかもしれない。
そして、これが、まっとうなホワイトスペースの使い方だと思うし、
そして、その方面のニュービジネスが現在起こっているので、
これを促進するのが、経済的な成長戦略だと思う。

---

■特定エリア向けワンセグさまざま

　いままで、テレビ放送は、広域のものが多かった。数ＫＷ，数十ＫＷつかって、どーん、視聴率がーん
　みたいなかんじ。

　一方、ラジオは１００ＫＷどーんみたいな広域のものももちろんあるけど、
　コミュニティＦＭみたいな、小規模のものもあるし、
　もっともっと、小規模で、一番身近なのだと、通訳の同通レシーバー、あれも無線で飛ばしてる放送？だ。

　テレビでも、広域でなく、特定エリアで行おうっていう考え方が出ている。

　それについては、以前、
　微弱電波のワンセグ放送なんだけど・・・？
　で書いたけど、ケータイのワンセグ放送に向けて、なにか番組を流すっていう話が、すでにある。

　さらに、
消費者の購買意欲を高めるリテール・デジタルサイネージ技術
http://jp.fujitsu.com/about/journal/solutions/retail/chapter05.shtml
で「スポットキャスト（ワンセグ配信）」っていうのが書いてあるけど、

そんなように、今後期待されるデジタルサイネージを、ワンセグ放送として流すという手がある。

こうすると、デジタルサイネージを、地デジ対応テレビで放送できるから、
とくに、大画面テレビなんかが安く売り出されると、特別な投資ではなく、
ワンセグ放送機械と、町で売っている大画面テレビを組み合わせて、
いろんな場所で、デジタルサイネージ（電子看板）ができる（免許が下りれば）。

---

　じゃ、具体的に、どんなふうに、この「特定エリア向けワンセグ」を利用していくのかについては、
長くなったので次回にしておきたいと思う。
　予告編として、こんなことを考えている

　　広域テレビ局　　　　　：現在のテレビ局。現在の免許基準
　　コミュニティワンセグ局：免許必要。特定エリアのワンセグ、デジタルサイネージ放送
　　免許不要ワンセグ局：同通レシーバーのような１建物内程度の放送局

では、次回のこのコーナーで

Strutsの要素技術の基本的構造（その３ 画面遷移図から）

　Strutsの要素技術の基本的構造で、前回、画面定義から、
・Ａｃｔｉｏｎ
・ＡｃｔｉｏｎＦｏｒｍ
・Ｓｔｒｕｔｓ－ｃｏｎｆｉｇ．ｘｍｌ
・ＪＳＰファイル
を起こすやり方について書きました。
　今日は、画面遷移図から、Ｓｔｒｕｔｓ－ｃｏｎｆｉｇ．ｘｍｌとＡｃｔｉｏｎを作る部分を書きたいと思います。
　前回同様、例は、発注者ビューガイドラインから。「画面編」の、Ver1.0(2008年７月）版、第一部－３９ページ（ＰＤＦのページでは56/291）の図を基に考えたいと思います。



著作権表示：CopyrightまるＣ2008 IPA
（まるＣは、著作権のコピーライトのＣです）

---

■画面遷移図からプログラムへ

　画面遷移図の、ある画面に対して、
　　　その画面から、他の画面に行くところが、Struts-config.xmlのforwardにあたります
　　　そして、その画面に遷移させるために、Actionでforwardするように書きます。

---

■ここまでをまとめると、

４つのファイルは、以下のように作れます。

（１）ＡｃｔｉｏｎＦｏｒｍ
　　・画面定義書の「使用する部品」から、フィールド名とsetter,getterを書きます。
　　　最低限なら、これだけで動きます。
　　　ほかに、画面定義書の「使用する部品」，「操作手順」の内容によっては、
　　　初期化resetが必要かもしれません。

（２）ＪＳＰ
　　　レイアウトに沿って、画面を作成し、「使用する部品」に応して、、
　　　　　部品が入出力なら、HTMLタグの該当のもの
　　　　　部品が出力だけなら、セッションに値をいれBeanのWriteで
　　　　　部品がボタンなら、buttonまたはsubmitとして
　　　処理を書き換える。

（３）Ａｃｔｉｏｎ
　　　方針によって、アクションの単位は変わりますが、内容は、どれも、以下のようなことを書く

　　　１．ＡｃｔｉｏｎＦｏｒｍからデータ受け取り
　　　２．request.getSesstioでセッション受け取り（セッションの変数も受け取り）
　　　３．エラーチェック
　　　４．ＤＢアクセス、セッションセットなど主処理
　　　５．クローズなどの後処理
　　　６．forwardして抜ける

　このうち、１は、画面定義書の「使用する部品」のボタンと、フレームワークの方針から、
　どのＡｃｔｉｏｎＦｏｒｍから受け取るかが決まり、
　２は、お決まりのせりふ
　３．は、「使用する部品」の型と入力範囲から、
　　　存在チェックのようなＤＢアクセスが必要なもの以外は決まる。
　　　（ただし、存在チェックなどのチェックも、ここでの対象）
　４．は、「操作手順」を参考に（ここにはかかれていない）
　５．はＯｐｅｎしたものをクローズする
　６．は、上記「■画面遷移図からプログラムへ」で書いたように、画面遷移図で決まる

（４）Ｓｔｒｕｔｓ－ｃｏｎｆｉｇ．ｘｍｌ
　Form-beanとActionを設定すれば、とりあえず動き、
　Form-beanは、ＡｃｔｉｏｎＦｏｒｍをもとに雛形を参考にすればかける
　actionは、Ａｃｔｉｏｎを元に雛形を参考にして、
　　forward部分を（３）Ａｃｔｉｏｎの６から
　　（さらにそれは画面遷移図から）
　　を参考にすればかける。

---

ということで、Actionの３のチェックの一部（存在チェックなど）と４の処理部分以外は、画面定義書から落とせる。

以上、今回はここまで

Ｐ．Ｓ　４の処理部分は、「システム振る舞い編」の業務フローから出てくる。詳しいことは、UML等各種ダイアグラムのエラーチェック体系化のもっと先のほう（業務流れ図）のところで出てくる。

発注者ビューガイドラインに沿って開発すれば、システムは開発できるって、誰か証明した？

　昨日、発注者ビューガイドラインとＳｔｒｕｔｓのプログラムについて書いたので、一言

　業界で、外部仕様について共通化する？ということで、発注者ビューガイドラインというのができた。
　ところが、この発注者ビューガイドライン、はじめは、外部仕様についてまとめていたはずなのに、発注者ビューガイドラインの活用と拡張　～機能要件の合意形成を目指して～において、１６ページで、「(2)要件定義工程における活用」っていう話で、

　　いやいや、要求仕様の機能要件に使えるねということになってきて、

　 じゃあ、あとは、非機能要件をきめれば・・・ということで

　　　非機能要求グレード検討会が非機能要件を標準化？しようとしているが、

　ちょっとまて、これ、もし、

　発注者ビューガイドラインと、要件仕様の機能要件との間に不整合や論理ジャンプ、情報不足があれば、外部設計に落ちないし、
　発注者ビューガイドラインの情報で、プログラムが作れることも保障してないし、
　発注者ビューガイドラインを機能要件に使うなら、それがＲＦＰなどと整合性があるかも確認を取ってるように見えない

　つまり、この

　　ＲＦＰ→発注者ビューガイドライン（機能要件→外部設計）→プログラム作成

　の間に矛盾や致命的な情報不足（による論理ジャンプ）があれば、これを業界標準にしたら、業界全体が混乱しちゃうと思うけど、
　この間に、矛盾がなく、かつ情報が足りていて、次の工程に進められると、だれか、証明したの？？
　しないと、やばくない？？
　機能要件がはっきりしないと、機能要件「でない」ところを定義する非機能要件もはっきりしなくなる。

---

　つまり、これを業界標準とするためには、
　　ＲＦＰ→発注者ビューガイドライン（機能要件→外部設計）→プログラム作成
　間の情報が足りていて、どの情報を元に、下位の作業を実行するかについて、明示しないといけない。

　詳しく言うと、以下の

・求める成果物から、標準的なＲＦＰに落とし込め

・そのＲＦＰの情報を元に、要求仕様が、発注者ビューガイドラインの
　　　システム振る舞い編
　　　データモデル編
　の各図におとしこめ

・その落とし込んだ図から、ＥＡにおける各成果物、
　ないしはIEEE830の要求仕様などに落とし込め

・発注者ビューガイドラインの「システム振る舞い編」、「データモデル編」から、「画面編」の画面定義が作れ、

・「画面定義」などから、プログラムが作れる

一連の流れを示すことになる。

---

　昨日の「Strutsの要素技術の基本的構造（その２　基本的ソースを画面定義書から）」は、上記”「画面定義」などから、プログラムが作れる”の一部を示している。

　そして、それ以前の工程については、
　ＩＴコーディネーター協会が出しているＲＦＰ見本のＤＦＤなどから、発注者ビューガイドラインの「システム振る舞い編」、「データモデル編」の図に落ちるかどうか、さらにそれらの図が、画面定義に落ちるかどうかを、UML等各種ダイアグラムのエラーチェック体系化で、図から変換可能かについてやっているので、

　まあ、このブログで、そのうち検証されることではあるのですけどね・・・

Ｐ．Ｓ　そうすると、なぜ、「振る舞い編」の図がＵＭＬの図ではなく、システム化業務フローなのかわかると思う。

アマゾンも企業内クラウドなのね・・・

ここのニュース
Amazon、企業向けクラウドサービス「Virtual Private Cloud」を発表
http://headlines.yahoo.co.jp/hl?a=20090827-00000026-zdn_ep-sci

　クラウドは、ＧｏｏｇｌｅがＡＰＩを提供するとか、そーいったパブリッククラウドより、企業内クラウド（プライベートクラウド）のほうが、やっぱ、はやりなんでしょうね。

　でも、それって、単なるアウトソーシングなんじゃあ・・・・

　・・・って思っちゃうことは、内緒です（＾＾；）

Strutsの要素技術の基本的構造（その２ 基本的ソースを画面定義書から）

まえに、Strutsの要素技術の基本的構造というのを、その１だけ書いて、以降、何も書かなかったので、これから、続きを書いてみる。

　まず、前に書いた流れだと、はじめ、

○Strutsを基本的に構成するもの
　　　Ａｃｔｉｏｎ
　　　ＡｃｔｉｏｎＦｏｒｍ
　　　Ｓｔｒｕｔｓ－ｃｏｎｆｉｇ．ｘｍｌ
　　　ＪＳＰファイル


　なので、これらのファイルと、画面定義書の関係を示して、設計から、プログラムにどのように落ちてくるかについて、書きたいと思います。
　で、画面定義書は、主に、画面遷移図と、各画面レイアウト説明（っていうのかな？）に分かれると思います。
　今回は特に、「各画面レイアウト説明」のどの部分から、それぞれのソースが出来てくるかについて、書きたいと思います。

　で、画面定義についてなんですが、今回は、発注者ビューガイドラインのVer1.0(2008年７月）版、第一部－７１ページ（ＰＤＦのページ数は８８／２９１）の右の図



著作権表示：CopyrightまるＣ2008 IPA
（まるＣは、著作権のコピーライトのＣです）

をもとに説明します。

---

■各ファイルの概要

まず、各ファイルの概要について書きます。

（１）Ａｃｔｉｏｎクラス
　ここのexecuteに処理内容が書かれる。

（２）ＡｃｔｉｏｎＦｏｒｍ
　画面の内容のＢｅａｎ（フォームＢｅａｎ）
　　・画面項目
　　・項目のＳｅｔｔｅｒ
　　・項目のＧｅｔｔｅｒ
　が基本的に書かれている。
　　・初期化のresetや、
　　・値チェックのvalidate()
　もここにかかれることがある
　（validatorを使う場合、ActionFormでなく、ValidatorFormを使う）

（３）Ｓｔｒｕｔｓ－ｃｏｎｆｉｇ．ｘｍｌ
　以下の内容が書かれる
　・data-sources
　　データベース接続に関して使うこともある

　・form-beans
　　ActionForm等のフォームBeanをかく

　・action-mappings
　　Actionの定義と、forward先について

　・global-exceptions、global-forward
　　全体として、飛ばし先を決めたり、例外・エラー画面を決めたりするとき

　・message-resources
　　メッセージをまとめたメッセージリソースについて

　・plug-in
　　プラグイン(validatorはプラグイン）

　・その他もろもろ
　　controllerにかかれることもある
　
（４）ＪＳＰファイル
　画面を記述する。ここで、strutsタグを使って、ActionFormの入出力項目と結びつけたり
　bean:writeをつかって、beanやセッションの内容を画面に記述する

---

■画面定義書からプログラムへ

　では、上述の画面定義書が、どのようにプログラムに関係していくかという話なのですが・・・

（Ａ）画面定義書の「使用する部品」から、
　　　「ＪＳＰ」、「ＡｃｔｉｏｎＦｏｒｍ」、「Ａｃｔｉｏｎクラス」が決定します。

　使用する部品（項目）の「画面部品の種類」（＝型）が、
　　テキストボックスのような入力するものであれば、該当項目を
　　　　　　ＪＳＰでは、HTMLタグなどを使って、入力項目のタグを作り
　　　　　　ActionFormでは、対応する部品のフィールド、setter,getterをつくります
　　　　なお、「画面部品の種類」と表示範囲から、エラーチェックがかけますが、これは
　　　　　　・ＪＳＰにjavascriptとして書く
　　　　　　・Validatorを使って書く
　　　　　　・validateで書く
　　　　　　・action内に書く
　　　　と、いろいろありますので、てきとーに決めて（決める基準あります）かきます。　　　　　

　　ボタンであれば
　　　　　　Ａｃｔｉｏｎをつくります。
　　　　このとき、１画面にボタンが複数ある場合
　　　　　　１画面１アクションでメソッドがボタンごとに変わる
　　　　　　１画面１アクション１メソッドでメソッド内切り替え
　　　　　　１ボタン（イベント）１アクションでつくる（１画面で複数アクション）
　　　　の３通りの作り方がある。詳しくは何回か先に話す。
　　　　Ａｃｔｉｏｎの内容は、「操作手順」から読み取るしかない？？

　　出力のみの項目であれば
　　　　Strutsタグのbean:writeを使って書きます。
　　　　値はSessionに入れておけば、nameで指定すればかけます。
　　　　bean（フィールド、setter,getterがあるクラス）の場合、それをsessionに入れれば、
　　　　　　name=セッションに入れたbeanのキー名　property=フィールド名

　　表示しない場合
　　　　StrutsのHTMLタグのhiddenでかけます。　　

（Ｂ）画面定義書のレイアウトからＪＳＰが決まります。
　　ですが、たぶん、このレイアウト、ＨＴＭＬで書いているから、その場合、
　　拡張子をＪＳＰにして、その後、上記の
　　　　HTMLタグ
　　　　bean:writeタグ
　　などのstrutsタグをいれます(logicも）

（Ｃ）(A)で決まった、ＡｃｔｉｏｎとActionFormからstruts-config.xmlがかけます
　　　Action=actionタグ（action-mapping内）
　　　ActionForm=form-beanタグ（form-beans内）

---

　次回は、画面遷移図と、action,struts-config.xmlの関係

ホワイトスペースを通信に使うと、放送のニュービジネスとインフラをつぶす

　で、まえに電波オークションはニュービジネスを阻害し、地方格差を広げるということを書いたときに、「ホワイトスペースで、もっと顕著な話があるんだけど」って書いておきながら、それについて書かなかった。

　予備知識は書いたので、じゃあ、今度はこのホワイトスペースの話。

---

■ホワイトスペースとは・・・

・・・空白のこと？？
じゃなくって、ここでいうホワイトスペースは、

・テレビの割り当て周波数帯なんだけど
・テレビが映って無い周波数。

　関東アナログVHFだと、１，３，４，６，８，１０，１２が映っているので、
　あいているチャンネルは
　２，５，７，９，１１になる。このあいてるチャンネルがホワイトスペース。

　実際には、３チャンと４チャンの間はすごく離れてる（だからFMでテレビが聞けるラジカセは、３チャンまでが多い）。そのため、実質交互になっているわけだけど、このように、交互にして、きっちり使わないことにより、混信が避けられる。

　とはいえ、VHFはそうだけど、UHF(Uチャン）は、かなりあいているわけで・・・
　地デジになっても、開いている周波数はたぶん、多いだろう。

　なお、このチャンネルは、地域によって違う。UHF、VHF帯は、あまり遠方へはめったなことでは電波は届かない（スポラディックEs(イースポ）というのがあると、確かに届くことは届くけど、めったに起こらない）。そこで、届かない地域同士では、同じチャンネルで違う局が放送しても、混信が起きない。そこで、地域によって、混信が起きないように、チャンネルを変えて放送しているが、遠方では、同じチャンネルで放送していることもあり得る。

---

■で、このホワイトスペースを・・・

　ホワイトスペースは、混信を避けるためとはいえ、基本的には、ここには、番組が映らない。そこで、この周波数帯を利用しようという考えもあり得るわけだ。

で、その空き周波数についてなのだが・・・

ホワイトスペース：電波の90％以上は空いている
http://blog.goo.ne.jp/ikedanobuo/e/7fea36450315ddd8c2992556b99f1352

に書かれているように、このホワイトスペースをケータイなどの通信に使おうという考えがある。

　たしかに、アメリカでは、通信（WiFiとか)にも、使うことを考えているようだ

　でも、この考え方で、ケータイなどの通信に使ってしまうのは、ニュービジネスをつぶし、せっかくの放送インフラをどぶに捨てる行為だと思う。筋が悪すぎる。

---

■ホワイトスペースを通信に使うと、放送のニュービジネスをつぶす

　話を単純化しよう。
　ホワイトスペース、すべてをケータイに使ったとする。
　その後、新たな放送局をそこに作ろうとしたら、どうなるか？

　ケータイが使っているホワイトスペースを一部削り、その放送局に割り当てることになる。ところが、ケータイをつなぐには、基地局への大きな投資がかかる。その投資をどぶに捨て、そのあとに、放送局を作ってもらうことになる。

　これは無駄だ。それなら、初めからケータイは、ずっと動かないで、安定した周波数帯で、全国一律で、サービスを提供したほうが、投資・研究の安定化につながる。
　電波は周波数によって、入り方などが違い、ベストな基地局の場所（２基地局間の距離）も違ってくる。だから、できるだけ周波数は動かない方がいいだろう。
　LTEも含め、その後も１．５G～２G、２．５Gあたりで安定させるのが無難じゃないかな・・・

　さらに、無駄という話でいうなら、ホワイトスペースは基本的に、テレビを受信するように受信機が出わまっちゃっているという問題がある。ここを通信に使うと、果たしてそれらのテレビに影響が出ないか？って問題がある。

　たしかに、電波の形式が違うし、ケータイは基本的に盗聴できない仕組みなので、通話がばれるということはない。しかし、ケータイを話してテレビを見ているとき、本当に近接している周波数だったら、まったくテレビは影響をうけないのか（＝テレビにホワイトノイズが出ないか）、テレビをスキャンして調べる方式の受信機に、影響が出ないか（まちがって、番組と思って止まっちゃわないか？）などは、やってみないとわからない。

---

■で、地方にとって、メリットがあるのか？

　で、ホワイトスペースが多いのは、たぶん、地方だろう。
　そこで問題なのだが、この案、地方にとってメリットはあるのだろうか？

　ホワイトスペースも多いかもしれないけど、ケータイを使う人も（都会よりは）少なくないか？そーすると、ホワイトスペースを使ってまでやる意義は。。。

　地方から見たら、既存の通信ビジネスではなく、これから起ころうとしている放送ビジネス（デジタルサイネージと放送の融合など。詳しくは次回書くけど）のほうが、お金になる。つまり、ニュービジネスを起こしたほうが、地方にとってはメリットがある。

---

■じゃ、どーするのがいいの？

　ってことで、ホワイトスペースを通信に使うアメリカのような方式では、

　日本のメリットより
　放送ニュービジネスをつぶし、地方は恩恵を受けらないというデメリット
　のほうが、大きく思える。

　もし、ホワイトスペースを利用するなら、
　新しい放送ビジネスに利用すべきである。

　そのビジネスは、もう起きているし、
　総務省も、考えているわけだが、
　それについては、次回、書いてみたいと思う。

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

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

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

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

---

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

　そのため、みんなが受信できる設備を持っていることが必要
　　（送信できるのは、免許を持った一部の人でいい）
　だけど、多少の混信があっても、ご愛嬌
　　（夜のＡＭラジオ放送とか）
　できるだけ、幅広く届いたほうがいい。なので、大出力にしたい
　　（１００Ｋｗとか）。
　バンド幅は、みんなが聞き取れればいいので、狭くすることも可能
　　（ＡＭなら、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マップ・・ま、緯度経度さえわかれば、逆ジオコーディングすれば、住所がわかるからいいけどね）

---

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

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

　この話、つづく

「学校ＩＴ整備構想」で知った。あれ、電子黒板っていうんだ・・・

ここのニュース
＜スクール・ニューディール構想＞政府の学校ＩＴ整備構想　教育現場、戸惑い
http://headlines.yahoo.co.jp/hl?a=20090825-00000007-maiall-bus_all
なんだけど、この前、ここで書いた、

あれもさー、ホワイトボードが実はペンタブレットになっていて、ペンで字を書くと、触れたところが色が変わる、黒板消しの代わりにボタンがあって、そのボタンを押すと、いっぺんに消してくれるとかのほうが便利だよねー。

って、すでにあって、電子黒板っていうんですね（＾＾；）
ここにその写真が。。。

ただ、これだと、人の影が映っちゃうよね。
やっぱ、高校講座なんかがやっている、座ったままで、紙の上に描く、その紙を
Ｗｅｂカメラで撮ったほうがいい気がする。

でも、それより、この電子黒板が、政府の後押しで売れるってことのほうが、話大きいのでしょうね。
一般企業導入にも。。

ただ、プロジェクター方のものはいいけど、
（以下斜体は上記ニュースより引用）


　デジタル放送対応テレビも、自治体の反応はさまざま。文科省が５月に実施した説明会では、５０インチを推奨する同省に「単価が高すぎる」「大きすぎる」と教委関係者から意見が相次いだ。


５０インチは・・・どうなんでしょうね（＾＾；）

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

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

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

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

---

■まずは、アクティビティ図とは？

こんなかんじ
http://www.thinkit.co.jp/images/article/40/1/4013_zoom.gif

　担当者（ロール）ごとに、書くところ（（スイム）レーン）を分けて、そこに、やること（アクティビティって昔言ってた気がするけど、そこには、アクションって書いてあるね）が流れ図みたいに、線を引いて（フロー）書いてある。ただし、流れ図と違って、並行処理がかける（フォーク／ジョインとなっている、「チケットを手配する」と「仮払い金を用意する」）。

　（スイム）レーンがないこともある。
　また、昔と違って今は、

　で、
http://www.atmarkit.co.jp/aig/04biz/activitydiagram.html
に書かれているように（以下斜体は上記サイトより引用）

UML 1.xのアクティビティ図は状態図の特殊形という扱いで、制御フローに焦点を当てた状態遷移の表現だったが、UML 2.0からは状態図から独立し、トークンフローを表すものに位置付けが変わっている。そのため、制御フローに加えてオブジェクトフローも記述できるようになっている。

ということで、オブジェクトノードがある。
あと、たしか、紙が折れているマーク（はじめに紹介した図にある）は、コメントだと思った

---

■アクティビティ図をＲＤＢに入れる

　それには、まずノードとエッジにわけないといけないけど・・・

　もう、分けてくれてますね。２番目に紹介したやつにアクティビティノードとアクティビティエッジと分かれて書いてある。

　で、これで、ノードとエッジ（リレーション、アーク）に分けてしまってもいいんだけど、
　その場合、ちょっと問題があるので、そこについてふれておきます。

---

■ノードとエッジの分け方　問題点１

　まず、アクティビティのコネクタ表現ですが、これはノードっぽい形に書かれています。
　でも、ノードの定義からすると、あいませんよね。意味があるものではない。

　しかし、エッジだとすると、２つのノードを結ばないといけないけど、ここでつなげているのは２つのエッジ・・・

　・・・どうしよう・・・・

　ってことになりますが、ここは、このまえ、拡張したエッジのグループということにします。これなら、２つのノードを結べます。

　で、そーすると、「分岐・マージ」や「フォーク・ジョイン」もノードではなく、エッジのグループでは？という気もします・・・が、まあ、これはこれでいいか（これについては、また別のところで書きます）。

　で、めでたしめでたし・・・

　ではないんだな、これが・・・

---

■ノードとエッジの分け方　問題点２

　上記の例には、レーンがありません。

　レーンはノードで、ロールはその属性っていうことはいい。

　で、レールの上に、アクションが乗っているので、

　レールが親、アクションが子、

　これはいいんだけど、オブジェクトやコメントは？
　２つのレーンに乗ってることもあるけど・・・

　っていうか、コメントとか明らかにわかるように、
　これは、たまたま乗ったと考えるべきで、親子関係にはない
　（だれのコメント、だれのオブジェクトとは、いいにくい）
　なので、今回は、これの親子は考えないことにします。

---

■ノードとエッジの分け方　問題点３

　で、今出てきた、コメントなのですが、これは、１つのものと
結びついている場合もありますが（図の例）

ここ
http://www.ibm.com/developerworks/jp/webservices/library/ws-tip-drawuml/figure1.gif

のように、まったく独立して書かれているものもあります。

そこで、コメントはノードとし、コメントと、ノードなどを結び付けるために、アークを使うということにしたいと思います。

---

■まとめると・・・

テーブルとその項目は、こんなかんじ

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

＊エッジ種別：
　　フロー（アクション・オブジェクト等をつなぐ）
　　コメント接続（コメントをつなぐ。点線）
　　みかけのコメント接続（コメントが何かの上に乗っているとき、下のものとコメント間）

＊制御ノード種別
　　分岐・マージ
　　フォーク・ジョイン
　　開始
　　アクティビティ終了
　　フロー終了

＊エッジの「元ノード等ＩＤ」、「先ノード等ＩＤ」の対象ＩＤ
　　コネクタＩＤ
　　動作ノードＩＤ
　　オブジェクトノードＩＤ
　　制御ノードＩＤ
　　コメントＩＤ
　　（レーンＩＤ　◎）

　これらのＩＤは、重ならないように、種別によってＩＤの範囲が決まっているものとする
（動作ノードＩＤは１０００～４９９９、オブジェクトノードは５０００～７０００など）
　　◎レーンＩＤは、コメントがレーン上にあるときのみ、これを使う。
　　　動作ノードとレーンの親子関係は、所属レーンＩＤで設定する。

---

次回は、この話の続き・・・

　

電波オークションは、地方と都会の格差を広げ、ニュービジネスを阻害しないか？

ここの記事
民主党マニフェストに含まれる電波オークション制度
http://slashdot.jp/article.pl?sid=09/08/20/0019252

もし、電波がオークション制になると、

現在、お金を持っていて、投資回収が見込まれるビジネス、
はっきり言うと携帯電話などにとっては、有利だけど、

海のものとも山のものともわからないニュービジネスにとっては、
オークションで電波を競り落とすだけの資金力は、ないだろうから
（いくら回収できるかどうかわからないものに、お金は出せないだろう）

電波を利用しようとしたニュービジネスは起こりにくくなり（阻害され）、
既存サービスにとっては、若い芽を摘めるから、ちょっと見いいけど、
長期的に見ると、成長できる機会が失われ、損なんじゃないか？

---

それと、もし、これが、テレビ局にも適用されると、
東京のキー局はいいだろうけど、
地方の放送局は、電波を競り落とすだけの資金力がなく、
地方局が減り、田舎ではＮＨＫしかみれなくなるという
地方と都会の格差を広げないか？

---

このような不平等をなくすため、電波法は、第一条で（以下斜体はリンク先より引用）

第一条 　この法律は、電波の公平且つ能率的な利用を確保することによつて、公共の福祉を増進することを目的とする。

といっているわけで・・・

つまり、お金がないから、地方を見捨てるとか、
既存のビジネスだけにしか電波を渡さないとか、
そーいうことはしませんよ、
公共の福祉という観点から、「平等」かつ「能率的」に電波を使いますよ！
といっているわけで、お金の観点から、電波割り当てを決めるのは、
いかがなものなのだろうか・・・

Ｐ．Ｓ　これについては、ホワイトスペースで、もっと顕著な話があるんだけど、
　　　　それはまたこんど。

UML等各種ダイアグラムのエラーチェック体系化（その２０：ＤＦＤ その３）

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

　現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、前回、ＤＦＤのエラーチェックをやりました。
　今回は、そのＤＦＤのエラーチェックの問題点です。

　なお、ここで書いたとおり、いままでのまとめは

こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm
（最新のものになおしました）

---

■前回のＤＦＤエラーチェック方法

前回のＤＦＤエラーチェック方法は、

親と子のＤＦＤがあったとき、
　親プロセスと結びついているデータ吸収・発生、データストアは、
　子プロセス中のどれかのプロセスとも、結びついていないといけない

という性質を利用してチェックしました。

で、今回は、このとき、問題があると書いたことについてです。

---

■同じものは、同じ名前になっているか？

　ここで、問題なのは、

　　すべての部署で、同じ名前＝同じモノか？

　という問題が起こります。
　つまり、ある部署では、まったく名称なのに、同じものをさしていたり、
　逆に、同じ名称なのに、違うものということはないか？

　ということです。

　まず先ほどのチェックをする際には、同じものが、同じＩＤになっていないと、いけません
（そうしないと、ＩＤから、同じものをさしているかどうか判断できない）
　なので、同じものをあつめてくる、つまり名寄せするわけですが、
　この際、同じ名前のものは、同じものと考えます。

　だから、すべての部署で、同じ名前＝同じモノになってくれていないと困ります。

---

■モノにおける親子関係

　しかし、おおまかなＤＦＤと詳細ＤＦＤでは、
　データストアなどの名称が、

　おおまかなもの→詳細なもの

　へ変わっていくのが普通です。
　そうすると、「おおまかなもの」を親、詳細のものを子として、親子関係をもたせるということになります。
　結果として

プロセステーブル：プロセスＩＤ，プロセス名、親プロセスＩＤ
データ発生・吸収テーブル：発生吸収ＩＤ,元名、親発生吸収ＩＤ
データストアテーブル：データストアＩＤ，データストア名、親データストアＩＤ
データフロー：データフローＩＤ、元データＩＤ，先データＩＤ、フロー情報内容

となります。親のＩＤが０のものは、これがトップということです。

そして、検索は、

親と子のＤＦＤがあったとき、
　親プロセスと結びついているデータ吸収・発生、データストア
　　　　自身あるいはその子孫が、
　子プロセス中のどれかのプロセスと、結びついていないといけない

ということになります

---

■ただし・・・

　データ吸収・発生をものすごく大雑把にとってしまい、
　子、孫をどこまでも調べていって、結びつきを確認してしまうと、
　実は違うものをさしていたのに、親が一緒になってしまいＯＫってこともありえます。

　たとえば、親を従業員として取ってしまうと、
　社員用のプロセスをアルバイトと間違えて書いても、どっちも従業員なので、エラーが取れない
といったケースです。

　そこで、
　親プロセスと結びついているデータ吸収・発生、データストア
　　　　自身あるいはその子が、
　子プロセス中のどれかのプロセスと、結びついていないといけない

　のように、プロセスの親子１段階に対してデータのほうも、親子１段階しか対象にしない
といった方法が考えられます。

　なお、このように、ＤＦＤのチェックをするためには、
名寄せや親子関係の作業がいることになりますが、
むしろ、この作業のほうが、間違いを直すには有効かもしれません・・・

---

ＤＦＤは、とりあえずここまで。
次は違う図を扱います。