分割するとき、機能で分割するか、インターフェースを決めるかの問題

　さっき書いた電子政府の話、ちょっとよむと、ＤＭＭとＤＦＤの技術的問題のように読めてしまうので、一応補足＆次の話の橋渡し。

　一番大切なことは、システムを分割するとき、機能で分割してきめるか、入出力を規定して（関数ならインターフェース）決めるか？の違い。

　ＤＭＭは機能に着目してシステム分割していく。
　この場合、その機能の入出力を決めないで分割するので、入出力インターフェースがあわない危険がある。

　一方最近のシステム、たとえば、オブジェクト指向では、メッセージを規定する。なかのメソッドはブラックボックスだ（カプセル化されている）。メッセージとはここで言う入出力にあたる。
　ただ、関数プログラミングのような、受け取った引数と、返り値以外、一切ほかに影響を値得ないということは実際の業務プログラムではあり得ない。現実的には、ファイルやＤＢへの入出力を行う。なので、そのファイルやＤＢの入出力も必要となる。

　そして、このような、入出力を規定する場合、入出力の表現方法を標準化すれば、あとは、具体的になにをどのタイミングで渡すかだけを規定すればいい。この標準化として、ＨＴＴＰ形式で引数で渡したり、ＸＭＬ－ＲＰＣやＳＯＡＰが考えられるわけ。。
　一方、ＤＢとしては、ＲＤＢで受け渡すようにすれば、テーブル構造をきめるだけだし（操作言語ＳＱＬは標準化されている）ファイルに関してもＸＭＬ，プロパティファイル、ＣＳＶなど標準化がある。
（これらは、データの表現方法を標準化しているだけであり、どの項目を書くかというのは、自由だ）

　ＤＦＤは、この入出力を規定するほうに近い。

　で、ここまでのことをつかって、以前述べた話を書きなおすと、分割する場合は、機能を規定する方法と、入出力を規定する方法がある。

　ＤＭＭというのは、機能を規定して分割するほうであり、ＤＦＤでは機能も意識するが、入出力を規定するほうに近い。初めから入出力を意識して分割していけば矛盾はないが、はじめ、機能だけで分割してしまう（これがＤＭＭでの分割）と、機能範囲もはっきりしないし入出力もはっきりしないので、途中から入出力でやっても、うまくつながらないってこと。

　そして、標準化とか、オープンというのも、入出力できめるからできるのであって、機能で分割した場合、標準的な機能を決めることは難しい。というか、そもそも、機能は、範囲すら決めることが難しい。

　っていうことでした。

　じゃ、また、この関連の話をするときまで（＾＾）／

「プライバシー侵害等に関わる発信者情報開示ガイドライン」、総務省のページに出てますね！

スラッシュドットの以下の記事、
プライバシー侵害等に関わる発信者情報開示ガイドライン策定へ
http://slashdot.jp/article.pl?sid=06/12/27/0558215

およびInternetWatchの以下の記事
プライバシー侵害の書き込み、ISPが発信者情報を開示する基準を明確化
http://internet.watch.impress.co.jp/cda/news/2006/12/26/14371.html

にでてくる「プライバシー侵害等に関わる発信者情報開示ガイドライン」、
総務省の以下のサイトにでていますね。

プロバイダ責任制限法第４条に基づく発信者情報開示制度の
円滑かつ適切な運用を支援する取組
http://www.soumu.go.jp/s-news/2007/070110_1.html

「プロバイダ責任制限法　発信者情報開示関係ガイドライン」という名前のようです。

なお、意見が言いたい人や、実際の内容については、ここ
「プロバイダ責任制限法　発信者情報開示関係ガイドライン（案）」に係る意見募集について
http://www.telesa.or.jp/consortium/provider/2007/20070110.htm
そこで、ガイドラインの案が、ダウンロードできます。
（ごめん、ウィリアムのいたずらもまだ見ていない）

「電子政府は構造偽装。姉歯マンションより危ない」って、東洋経済に書いてあるけど（＞＿＜）

　東洋経済の電子政府についてさっきのブログに書いたあとの部分、すなわち、

週刊東洋経済　２００７年１月１３日号
「大丈夫か！？電子政府　１．３兆円予算をめぐるITゼネコンの攻防」
という記事の中、　６４ページに、

「電子政府は構造偽装。姉歯マンションより危ない」

っていう見出しがあって、３段目に（以下斜体は上記東洋経済の記事から引用）、


あるコンサルティング会社の役員が揶揄する。
「総務省行政管理局は姉歯建築士を笑えない。電子政府は構造計算を偽装したマンションより危ないものが建つだろう」


ってかいてある（＾＾；）

ただねー、これ、しょうがない部分があると思うよお（＞＿＜！）

っていうまえに、なぜ、姉歯建築士を笑えないから説明したほうがいいよね。。

---

■DFDはデータ処理構造を規定し、妥当性が確認できる

　問題は、その前のブログで書いたとおり、

会計検査院はこのほかにも、８７システムの最適化計画にDFDの不整合が８３１件もあると報告している。


で、DFDは、データと、そこにおけるプロセスの処理の関係をしめす。
　これだけだったら、構造とはいえないんだけど、DFDは、トップのコンテキストダイアグラム
（これから作ろうとしているシステム全体を１つのシステムとみて、そこに対する外部からの入出力を記述する）から、ミニスペック（もはやDFDで書く必要がなく、紙１枚でまとまるまで、仕様をおとした、言葉で書いた仕様書）まで、ずっと、階層的に落としていく。

　たとえば、一番上（コンテキストダイアグラム）が受注システムだったとすると、

　　　　まず、受注システムで１枚紙を書き、

　受注には、受注受付、受注票作成とかあるから、ってなると、

　　　受注受付と受注票作成で１枚紙を書き

　受注受付が、受注受付画面表示、入力、確認、と３つに分かれるとすると

　　　受注受付画面表示、入力、確認で１枚紙を書き。。

　っていう感じになる。つまり、階層関係ができる。これが、システム構造ともいえると思う。

　で、この構造、データについて着目すると、下の階層で入出力になっているものは、かならず、上の階層でも入出力になってないと変。っていうように、確かめられる。上記の場合だったら、入力で、商品マスタを参照していたら、上位の受注受付でも、商品マスタを参照しているはずってことになる。

　さらにDFDは、他プロセスとの関係も確認できる。たとえば、受注票作成で、受注テーブルを参照していたとすると、受注テーブルをだれかが書き出してないとおかしい。この場合は、受注受付画面で書き出してるはずだけど、もし、受注受付画面で書き出してないで、いきなり、受注テーブルを受注表作成で読んでいたら、うん？？これって？？？っていうことになる。

　で、こういうのを確認した結果、

会計検査院はこのほかにも、８７システムの最適化計画にDFDの不整合が８３１件もあると報告している。


っていう話だと思う。

---

■姉歯氏の偽装は、構造に手を入れた

　姉歯氏の場合、設計書を改ざんして、つじつまを合わせなくさせたということだと思う。
　で、そういう意味で言えば、DFDの入出力の不整合はつじつまが合わないって言うことだから、まったく同じ理屈で。。。

　総務省行政管理局は姉歯建築士を笑えない。

っていえちゃうんだけど。。問題は、もっと奥深いところになると思うよ・・・

---

■問題はシステム分割の管理とEA体系にあると思う。

　問題は２点。
・システム分割の方法が機能ベースで行われたりしてしまうと、システムのインターフェースを管理する人が居ない限り、このようなことはおきてしまう。しかし、現在の電子政府の組織構造では、インターフェース管理を誰がやるのか、不明確。

・EA自体の体系が、構造を壊しやすい体系になってしまっている。

　前者については、かなり長い話になるので、別の機会に説明するとして、今回は、「EA自体の体系が、構造を壊しやすい体系になってしまっている」について説明したいと思います。

---

■EAにおけるDFDを作る手順

　一般にDFDを作る手順は、上記に書いたようにコンテキストダイアグラムからDFDを階層的に落としてゆき、ミニスペックをつくるという構造になる。
　で、この階層は、たとえば、部・課・係・担当者でもいいし、システムのレベルでもいいし、ある程度、実態に合ってつくれる。

　ところが、EAにおいて、DFDを作る手順は、EAポータルによると、以下
機能情報関連図（DFD）
http://www.meti.go.jp/policy/it_policy/ea/gainen/product/dfd/index.html
のようになる（以下斜体は上記サイトより引用）。


機能構成図（DMM）で抽出された業務機能に対して、情報の発生源と到達点、処理、保管、それらの間を流れる情報を、統一記述規則に基づいて表現し、機能間の主要データと情報の流れを図式化する。


（中略）


1つの機能構成図（DMM）には最大8個の機能しか示されないが、これを逆手にとり、機能構成図（DMM）の機能整理に即して徐々に上位から下位の階層へと機能情報関連図（DFD）を作成すると、業務機能をトップの視点から分解したような形で、全ての業務機能を機能情報関連図（DFD）上に示すことができる。


　つまり、DMMで分けられた機能をもとに、そっから書いていけ！という指示なんだけど、

DMMは、
機能構成図（DMM）
http://www.meti.go.jp/policy/it_policy/ea/gainen/product/dmm/index.html
によると（以下斜体は上記サイトより引用）。


機能構成図（DMM）を作成するためには、以下のポイントを共通のルールとして、組織、制度、担当業務ではなく、機能（“はたらき“の集合）を中心に作成する。業務を記述するための必要に応じて、複数階層の機能構成図（DMM）を作成することが多い。

・ 中央に分析の対象とする機能名を書く。
・ レベル0（最上位階層）では、必ず8個をうめる、下位レベルは、最低3個をうめる。
・ 機能の分析なので、機能名は動詞（～をする）、あるいはそれに準ずるものであること。


つまり、機能中心にわけでしまう。

そこで、これを、言われたとおりに作業したとすると、
・DMMを書きます

・DMMに対応するようにDFDを書きます。
　→外部からの入出力はDMMではわかりません（機能しか書いてませんので）
　　なんで、えいや！と発生させます。

・で、ここで問題です。
　ある人はえいや！入力発生！とつくり出したデータ、これ、誰かが発生させてる
　はずなんですけど、その発生元はDMMでは、分からないんです。

・もし、つくり出したデータを作成している人が他の部署、他のプロジェクト
　の人だったら、DMMを見ているだけでは、誰が担当か分かりません
　（DMMに機能とデータの関係はない）。
　DFDにはありますが、DFDを作成しているとき、他プロジェクトのDFDができているか
　どうかは、わからない。出来上がってなきゃ見れないです。

・じゃあ、発生元（書き出した人）がわかんないなら。。（＞＿＜！）
　しょうがないよね、エイやと書いちゃえ、入力だーい！。。

・でも、発生もとの人は、自分は使わないので、書かないかもしれません
　→書き忘れているかもしれません。

たぶん、こういう感じで不整合ができているんだと思います。
いわゆるインターフェースミス。

これは、DMMをつくってDFDを作るって言う手順だと、どうしてもおきます。

---

■EAでない場合、これを防ぐ手段は存在する。

　EAでない場合は、これを防げます。

　まず、DMMをつくるのでなく、

　DFDでやる場合、コンテキストダイアグラムを作ります。
　なので、それ以降のDFDで、データは、検証ができます。
　（もし、矛盾があれば、上記にかいたように、矛盾点がわかります）

　さっきの、「入力だーい！」っていうことはできません。
　上位のDFDは、かならず先にできていて、そのDFD上で入力になっていなければ
　書けません。

　もし、書き間違いがあれば（中間データでなければ）、最終的には、最上位まで
反映されます。
　しかし、最上位まで来た場合、外部インターフェースとなっているはずですが、
この外部が誰かは、コンテキストダイアグラムに書かれています。
　なので、担当者が分からないということはありません。

　EAの場合は、ER図を「データ・情報体系策定」ということで、あとから作成
されるのですが、DFDの場合、要求定義で、同時、むしろ先にできることもあるので、
そのエンティティを利用して、特に、データベースレベルでデータ受け渡しを行う場合
（受注データを受注テーブルにかき、後の工程はその受注テーブルの内容を読む）

　矛盾があればわかるし（テーブルにないデータを読み書きする矛盾が起こるから）、そもそも、矛盾がでにくいです（上から下まで連続しているので）

（あ、そうだ。EAの場合、この手順だと、ERのエンティティの独立性を利用して
インターフェースを構築するって言うのもできないね）

---

■もし、EAで、これをやろうとすると。。。

　ちなみにEAの場合でも、DFDを上から順に書いていき、DFDだけで確認すれば、この問題は防げそうに見えます。

　でも、そーすると、DMMを作る意味はないです。
　DFDだけ作ればOKです。

　だけど、コレは無理です。
　なぜなら、EAにおけるDFDのコンテキストダイアグラムは、全省庁、全プロジェクトをあわせたような、ダイアグラムになっちゃいます。（そうしないと、プロジェクト間の矛盾が指摘できない）

　それは、政府に全省庁、全プロジェクトをあわせたような、”データ入出力レベルでの”グランドデザインがあり、それを管理調整している人がいるということです。
　でも、そんなの、聞いたことないです（＞＿＜！）
（何をやらなきゃいけないという、機能レベルでのデザインは、あるかも。。。あるかなあ　＾＾；）

---

　ってことで、たしかに、危ないんだけど、それは、EAの手順に従った場合、分割箇所でどうしても危なくなるような問題をはらんでいると思う。ドキュメントの作り方からいって。。

　では、分割をどうしたらいいのか？っていう話なんだけど、
　それについては、また別の機会にしますね。

Webページを保存させない（ダイアログが出る）方法とか。。

　もちろん、Javaのプログラムを書いて、データを読み込み、保存されてしまえば、保存できちゃうんだけど、そこまでいかなくても、ブラウザから、

　ファイル→名前を付けて保存
　
をしたとき、ダイアログがでて、保存できないようにしたい。。
って言う場合がありますよね。。

そのテクニックを書いてあるところがあったので、
メモメモ。。。

Web ページを保存させない
http://www.netmania.jp/technique/hp/error.php

ヘッダーにインポート先がないCSSファイルを入れるというテクニック
（上記サイトに、実際のコードが書いてありました！５行いれるだけ）

ウィリアムのいたずらが試したところ、
http://127.0.0.1/a.htm
とかいうかたち、つまり、

・サーバーを経由して、ブラウザから開き、
・保存しようとしたら、

「選択した場所にWebページを保存できませんでした。」エラーが出た。

おお、ばっちし
（c:￥￥test￥a.htmのように、ローカルのファイルとして参照した場合には、
　保存できてしまう。あくまでも、HTTPのサーバー経由でアクセスした場合
　エラーになるみたい）

ちなみに、キャッシュさせないのは、CGIの場合、ヘッダに、HTMLファイルの場合Metaタグにno-cacheを入れればいいみたいです。

メモでした（＾＾）ｖ

会計検査院、電子政府の最適化計画８７システムに不整合８３１件もあると報告

　会計検査院、いい仕事してますねえ。。（＾＾；）

　週刊東洋経済　２００７年１月１３日号
「大丈夫か！？電子政府　１．３兆円予算をめぐるITゼネコンの攻防」
という記事の中、　６４ページの２段目に、以下のような記述が。。
（以下斜体は上記記事より引用）


会計検査院はこのほかにも、８７システムの最適化計画にDFDの不整合が８３１件もあると報告している。


（なお、”このほか”というのは、その前に記述されている、財務省ADAMSと予算執行等管理システムとの接続がないことをさしています）

　おおお、８３１件あるのも問題だけど、それを指摘した会計検査院は、GoodJobですな（＾＾）

　たしかに、DFDは矛盾を指摘しやすいドキュメント。そこで、ここに目をつけ、チェックをかけたっていうところはさすが。
　さらに、そのドキュメントを丹念に見て８３１箇所の間違いを指摘したって言うのはすごい。

　会計検査院、最近なんかかわって、ソフトのチェックに力いれてるみたいだけど、意外とその指摘力は侮れないかもしれません。すごいかも。。。

　って、たまたま、担当者がIBMかなんかにいたひとで、
　DFDが得意だったからかもしんないけど（＾＾；）

（とはいえ、その場合でもこれからはDFDはチェックされるってことだから、侮れないんだけどね！）

　

米アップル、ｉＰｏｄ機能搭載携帯電話「ｉＰｈｏｎｅ」発表

ここのニュース
米アップル、ｉＰｏｄ機能搭載携帯電話「ｉＰｈｏｎｅ」発表
http://today.reuters.co.jp/news/articlenews.aspx?type=marketsNews&storyid=2007-01-09T222358Z_01_TK3040436_RTRIDST_0_JAAESJEA302.XML&src=rss&rpc=112
によると、米アップルコンピューターは（以下斜体は上記ニュースより引用）


携帯音楽プレーヤー「ｉＰｏｄ」の機能を搭載した携帯電話「ｉＰｈｏｎｅ」を発表した。タッチスクリーン機能が搭載されていることも特徴。８ギガバイトモデルの価格は５９９ドル、４ギガバイトモデルは４９９ドルとなる。


だそうな。。。

とーとー出してきましたね！

このニュースには書いてないのですが、
オープニングベルでその様子がでてました。
タッチパネル操作でボタンがないみたいです！すごいです！！