学校の地デジ化、電子黒板、ＬＡＮ整備は、中止ってこと？

ここのニュース
民主、補正予算を原則全面停止…未執行分
http://headlines.yahoo.co.jp/hl?a=20090903-00000522-yom-pol

ってことは、２１年補正予算の、スクールニューディール
「スクール・ニューディール」構想関係　平成21年度補正予算の概要
http://www.mext.go.jp/a_menu/shisetu/newdeal/seido/1279523.htm
も、全面停止？

ってことは、

学校の地デジ化、電子黒板、コンピュータ・ＬＡＮ整備は、中止？

これの売り込みをやっていた、業界の人は涙目そうだな・・・

非定型業務の画面－データをクラウド、表示ＲＩＡに、しやすい

　昨日の、画面は業務系とマスタ系に別れ、マスタ系は１エンティティ１テーブル２画面が基本なんだけど、このわけ方だと、グラフ表示なども、「業務」になってしまう。
　これは、一般の受注業務などとはちがうので、非定型業務としてわけて、

　非定型業務
　定型業務
　マスタ系

とわけたほうがいいかもしれない。

---

■非定型業務画面の特徴

　これは、定型業務やマスター系とちがって、特徴がある。

・基本的に、検索のみである。
　なにか、データ処理加工を行う場合、それは、定型業務（を不定期にやっている）か、バッチ（データマートを作るため）が多く、基本的には、検索するだけが多い。
　このため、システムが出来てから作ったり、現行のシステムに後付けしたりできる（現行の受注システムに、ＲＦＭ分析を追加するなど）。ただし、業務で集めていない情報を後付けするのはむずかしい。

　このことは、開発が遅れたとき、この非定型部分だけ切り離して、後で提供することが出来るかもしれないということを示唆している。
（定型業務が遅れると、システムが動かない。マスタメンテは、データベースにＳＱＬ等で直接データを入れればすむことも多い）

・部品化できる場合がおおい
　データ自体はちがっても、その表現方法、棒グラフとか、円グラフとかの部分は、共通化できることが多い。この部分は、部品化でき、あとはその部品に渡すデータを切り替えればいいだけのことも多い。

---

■ということは、

　部品をあらかじめ用意し、雛形プログラムを用意すれば、そのフォーマットでよければ、データ部分を切り替えるだけで、各種分析が可能になることも多い。

　Ｅｘｃｅｌなどは、まさにその例なわけ。

　ＲＩＡによって、この部品部分（グラフ化）などを提供すれば、クラウド上にデータを送るようにして、そこから適切なサービスを呼び出しデータを処理加工、ＲＩＡで表示ということで、比較的自由に処理可能になる。

　一方、業務をクラウド化してしまうと、クラウドサービスを提供する側の都合で、業務が影響を受けたり、クラウド＝業務間の回線リスクなどがあるため、リスキーになる（この程度のリスクは、非定型業務の場合、あまり問題にならないことも多い）

　また、データ移行について考えると、非定型は、後付可能なので、現行データを吸い上げて（あるいは加工して）、クラウドにもっていき、それを処理するということがしやすいのに対して、業務をクラウド化しようとすると、現在のＤＢを移行するため、とめるとか、いろいろと問題が出てきそうだ。

UML等各種ダイアグラムのエラーチェック体系化（その２４：ユースケース図 その３）

　シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。
　（前回、２３回だったのに、２２回と書いてしまったので、今回、その２４になります）

　現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、今、クラス図、ＥＲ図、アクティビティ図を入れたと思います。
　今回から、ユースケース図です。

　
なお、ここで書いたとおり、いままでのまとめは、こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm
（更新しました。前回までの分に対応してます）

---

■ユースケース図とは

　ユースケース図は、

【伝わる！モデリング】はじめようUML！
第2回：ユースケース図を学ぼう！
http://www.thinkit.co.jp/article/40/2/

にあるとおりです。

　そこにあるように、ユースケース図は、アクターとユースケースと関連からなっていて、

　　　ユースケースは、なにをするかを記述し、
　　　アクターはそのユースケースをする人等、関連する人やシステムを書きます。
　　　ユースケースとアクターを結ぶのに、関連を使います。

　このほかに、サブジェクトというシステム範囲を示すのを書いたり書かなかったり。
　なお、関連についてですが、次のページの図にあるように、拡張、汎化、包含をあらわすケースがありますので、関連にも、種類があります。

---

■ＲＤＢにいれる

　で、これをＲＤＢにいれるとすると、アクターとユースケースがノード、関連がエッジになります。サブジェクトも入れるとすると、こんなかんじ

アクターテーブル（アクターＩＤ、アクター名）
ユースケース（ユースケースＩＤ、ユースケース名）
サブジェクトテーブル（サブジェクトＩＤ，サブジェクト名）
関連テーブル（元ノードＩＤ、先ノードＩＤ、関連種別）

＊アクターＩＤ，ユースケースＩＤ，サブジェクトＩＤは、値の範囲を決めて、
　重ならないようにする。
＊ノードＩＤ＝（アクターＩＤ｜ユースケースＩＤ｜サブジェクトＩＤ）
＊関連種別＝（一般、拡張、汎化、包含）

　関連種別の一般とは、拡張、汎化、包含でない関連を示し、アクター－ユースケース間あるいは、ユースケース－ユースケース間の場合は、実線、ユースケース－サブジェクト間の場合だったら、上に載っていることを示します。
　（アクター－アクター間は、汎化等になり、直接一般的な線で結ばれることはたぶんない。
　　アクター－サブジェクト間も、アクターは、サブジェクトの中に入れない気が？
　　・・・ユースケースは必ず入れる）

---

■アクティビティ図との関連
　で、そこの説明に、アクティビティ図との関連というか、作り方が載っています。
　それが、ＲＤＢ的に、どう関連するかについては、次回書きたいと思います。