シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
前回はダイアグラムを、
・後工程の入力になるために、前工程としては、どこまで記述しないといけないか？
という基準で見た場合、UMLだと、データの部分で、この条件をみたしていないため、クラス図に行くところなどで、
悪く言えば恣意性、よく言えば技術者の経験的勘がはいってしまうということを書きました。
そして、こうならないための、史上最強ダイアグラムが存在すると・・・
さらに、そのダイアグラムから、UMLの各ダイアグラム等は変形できると描きました。
で、そのお話です。
■史上最強ダイアグラム＝業務流れ図
そのダイアグラムは、業務流れ図になります。
業務流れ図の正確な書き方というのは、はっきりしない（基準がない）のですが、
EAにおける、
業務流れ図（WFA）
http://www.meti.go.jp/policy/it_policy/ea/gainen/product/wfa/index.html
や、
財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の設定について（意見書）」
http://www.fsa.go.jp/singi/singi_kigyou/tosin/20070215.pdf（PDF)のPDFのページで100/129ページ
（下の真ん中ページ５９、下右端ページ９２）
などが、例としてあげられる。アクティビティ図にデータ部分、つまり
入力画面＋出力帳票・画面＋入出力ファイル・DB
がかかれている。（なので、アクティビティ図に不足していた、データ部分が補強される）
さらに、EAの場合、手作業部分も明示されているので、ユースケース図にも展開できる（手作業でないところ）
■ダイアグラムと開発の流れ
では、業務流れ図を中心とした開発の流れを書いてみよう。これが、前段階→後段階のようにつながればOK！
まず、業務流れ図には、担当者（アクティビティ図でいうスイムレーン、役割というべき？）に分けて書く。
この担当者は、その前の入力・・・というと組織図になってしまうが、組織にいない人（顧客）なども出てくるので、
まあ、用語定義というのを考え、
●用語定義に出てくる人が、担当者としよう。
●業務範囲を明確にするため、機能構成図（DMM)を書いているのであれば、業務流れ図の範囲は
DMMとなってくる。
●で、業務流れ図に記載される業務に対して、画面入力、帳票出力するものが入出力となり、
ここででてくる、画面、帳票に対して、画面定義書、帳票定義書ができないといけない。
●この画面定義書、帳票定義書の項目から、どの項目が保存する必要があるかを選び出し、
それを正規化することにより、テーブル構造が出てくる＝ER図が描ける
●このテーブル、ファイルと業務流れ図のテーブル出力などを矛盾がないか確認するわけだが、
それは、「後工程の入力になるために、前工程としては、どこまで記述しないといけないか？」
ではなく、矛盾チェックのほうになる。
●画面、帳票が出来たことにより、画面出力フレームワーク、帳票出力フレームワークによって
クラスが決定する。
画面出力をStrutsで行う場合、
画面分、ActionFormができ、そのフィールドとメソッドは画面項目と、そのsetter,getter,resetとなる
業務流れ図の各業務において、どこかの画面のボタンをクリック等して、イベントを発生させ、処理を
開始する。この場合、Actionごとにクラスが発生する
モデル部分は、この業務ごとにクラスにしてもいいし、テーブルごとにクラスをもち、そこに
業務（メソッド）をはめ込むというというのでもいい。
→これを、フレームワーク段階できめる。
ということは、これらフレームワークの方針が決まると、クラスが決定するので、クラス図がかける。
●クラス図、テーブル、画面、帳票の定義が出来ると、javaのプログラムに落とせる。
と、こんな流れになる。
■ダイアグラムの関係
では、この業務流れ図から、ダイアグラムがどう抽出できるか。
●アクティビティ図
データ部分を書かないと、アクティビティ図になる。
●ユースケース図
アクティビティ図を基に作れる
●ER図
上記で作っている
●クラス図
上記で作っている
●DFD
業務をプロセス、DB,ファイルをデータストア、
画面入出力、帳票出力を外部として書き換える。
（条件などは無視：条件のような順番をDFDでは記述しない）
なんてかんじで、抽出できてくる。
今日はここまで。
アクセス
トータル
ランキング
