UMLとDIとオブジェクト指向

　前に書いた、


　アクティビティ図やユースケース図は、なんか別の視点から出来ている図なのではないか？
　ということを予感させることを書き始めてしまったわけですが、このことに関しては、このシリーズではなく、別枠で書くつもりです。


の別枠の話。

　アクティビティ図やユースケース図等、UMLの図は、あくまでも、オブジェクト指向分析における図であって、それ以外の開発の場合では、ベストな図とは言いがたい場合があります。

　たとえば、前に見たアクティビティ図。
　これは、オブジェクト指向では開発しない、たとえばCでの開発の場合、最適とはいえない。

　入力メディアが違ってしまえば、プログラミングは変わってくるわけで、そうなると、かなり早い段階で、入出力メディア（画面かファイルか）がわかっていないといけない。
　この場合においては、入出力のメディアがはっきりしない（オブジェクトノードとして一括して表してしまう）アクティビティ図より、データベース、画面、帳票をはっきり書く、業務流れ図のほうが、好ましい。

---

　しかし、オブジェクト指向で開発するという場合、多態性を利用して、はじめのうちは、メディアをはっきりさせず、入力、出力を共通的なインターフェースを使って設計しておき、最終段階で実際の入出力メディアを決めるという開発方法もありえます。

　つまり、DI（依存性の注入）であります。

　こうやってシステムを作ると、仮に考えると（仮に考えるだけで、この方法で作れることは保障していない）入出力メディアを決めないで、システムを設計、開発していき、最終段階で、確定させるということができないといけません。

　この場合においては、入出力のメディアをデータベース、画面、帳票をはっきり書く、業務流れ図ではまずいわけで、はっきりとはかかず、オブジェクトノードとして、項目だけ挙げるアクティビティ図のほうが望ましいということになります。

---

　ユースケース図においても、オブジェクト指向でなければ、継承などは関係ないから、コンピューターが行うプロセス部分をユースケースとして出しているだけで、あまり意味ある図ではありません。

　しかし、オブジェクト指向で考えた場合、継承関係があるわけで、その継承を表現するには、ユースケース図の意義があるわけです（ER図でも継承は表せます。しかし、ER図では永続的なモノや出来事を表現するので、一時的な処理（帳票出力）の継承関係（と受注表出力、納品書出力）までが表現されることは保障されていません。そこでこれらの継承を表せる図が必要になってくるわけです－そもそもER図はオブジェクト指向の図ではないですが）。

　で、ここで要求分析で継承関係が表せるため、さらに下の工程で作成されるクラス図での継承関係の正当性が担保できるということになってきます。

---

　ということで、UMLの図は、オブジェクト指向的には意味があるけど、そうじゃなければ、意味がなかったり逆効果だったりすることがあります。

　で、次なる話題。

　さっき、さらっと流したけど、

はじめのうちは、メディアをはっきりさせず、入力、出力を共通的なインターフェースを使って設計しておき、最終段階で実際の入出力メディアを決めるという開発方法もありえます。



もっと言っちゃうと、要求仕様をはっきり決めず、どんどん開発していくということも、オブジェクト指向、とくにDIを使った場合可能なのか？

という問題があります。これについては長くなるので、別の機会に。。。

StrutsでHashMapの中身を全部出す

　recという名前でハッシュマップがセッションに入っていたとしたら、

　JSPでは、strutsタグのlogic:iterateを使って

	＜logic:iterate id="map" name="rec"＞
		＜bean:write name="map" property="key" /＞
		＜bean:write name="map" property="value" /＞
	＜/logic:iterate＞

（＜　＞　は本当は半角）
とすると、keyにハッシュマップのキー、valueに値の形で書き出せる。

なので、

　dataという名前で、ハッシュマップの配列がセッションに入っていたとしたら、

　JSPでは、strutsタグのlogic:iterateを使って

＜logic:iterate id="rec" name="data"＞
	＜logic:iterate id="map" name="rec"＞
		＜bean:write name="map" property="key" /＞
		＜bean:write name="map" property="value" /＞
	＜/logic:iterate＞
＜/logic:iterate＞

（＜　＞　は本当は半角）
とすると、keyにハッシュマップのキー、valueに値の形で書き出せる。

UML等各種ダイアグラムのエラーチェック体系化（その３４：業務流れ図→プログラム その３）

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

　前回、業務流れ図＋アクティビティ図をあわせたものから、プログラムがどこまで作れるかについて検討した結果、

　以下の汎用プログラム
　　・データベースアクセス（１テーブル用、検索SQL用）
　　・帳票出力（XML＋レイアウト→PDF)
　　・画面自動生成
　　・バッチプログラム外枠作成
があり、

業務流れ図があれば、あとは
　　・画面定義(レイアウト、遷移、項目）
　　・帳票定義(レイアウト、項目）
　　・DB・ファイル定義（項目など）
　　・入力項目と出力項目間の関係（そのための処理）
を用意すると、大体自動的に、プログラムに落とせるということになることまでを書きました。

　今回は、では、これらがそろったとして、業務流れ図やアクティビティ図で、作れないところはどこなのか？ということについて、考えてみたいと思います。

---

■アクティビティ図について

　アクティビティ図があっても、データ入出力が、帳票に出すのか、画面に出すのかは明記されていません。
　なので、ここから、プログラムを作るのは無理・・・

　・・・というと思ったでしょ・・・

　・・・違うんですねーこれが。

　入出力に関して、

　　　　InputMedia
　　　　OutputMedia

　というクラスないしはインターフェースを作ります。
　このインターフェースは、Read,Writeの基本的なメソッドを持っていて、
　業務プログラムは、そのメソッドを利用して入出力します。

　こうして、最後の段階で、実際に、どれを帳票にして、どれを画面にして、どれをDBにして・・・
　（依存性を注入すると・・）
　プログラムは出来ることになります。

　つまり、オブジェクト指向を使えば、ある程度作れることになります・・・
　これについては、また、別の機会に詳しく書きます。

---

■業務流れ図について

　この場合、プロセス間での同時処理などがあった場合、こまるのでした。

　ただ、実際には、同時処理のところはバッチプログラムでまとまっていたり、画面を利用している処理が並行処理できる場合は、画面を利用するために起動するのは、人間（ユーザーが、起動画面から）なので、そこらへんは人間がやるので、問題はないってことはあります。

　なので、業務流れ図がある場合、（オブジェクト指向ではなくても）
　　・画面定義(レイアウト、遷移、項目）
　　・帳票定義(レイアウト、項目）
　　・DB・ファイル定義（項目など）
　　・入力項目と出力項目間の関係（そのための処理）
　がそろえば、プログラムは作れそうということになります。

---

　そんなことより、「アクティビティ図」の流れですよね。
　アクティビティ図やユースケース図は、なんか別の視点から出来ている図なのではないか？
　ということを予感させることを書き始めてしまったわけですが、このことに関しては、このシリーズではなく、別枠で書くつもりです。

　で、その後の話として、今までの図
　　・ＥＲ図
　　・アクティビティ図
　　・ユースケース図
　　・ＤＦＤ
　　・機能構成図（ＤＭＭ）
　　・業務流れ図
　の関係について書きます。