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

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

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

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

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

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

---

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

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

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

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

　入出力に関して、

　　　　InputMedia
　　　　OutputMedia

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

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

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

---

■業務流れ図について

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

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

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

---

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

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