もしかするとここ30年ぐらい基本的な部分はあまり進化してないんじゃねーか？
https://twitter.com/ibucho/status/332482504680419328
確かにそうかも・・・
８０年代から起こった構造化手法の設計方法は、ＥＡにおいて、一旦完成すると見て良いと思う。
ＥＡの開発手法は
EAポータル
http://warp.ndl.go.jp/info:ndljp/pid/286890/www.meti.go.jp/policy/it_policy/ea/
に出ている通り、
機能構成図（DMM)
（http://warp.ndl.go.jp/info:ndljp/pid/286890/www.meti.go.jp/policy/it_policy/ea/gainen/product/dmm/1.htmlより引用）
で全社から、各機能に分解し、それを
ＤＦＤに展開
（https://warp.ndl.go.jp/info:ndljp/pid/286890/www.meti.go.jp/policy/it_policy/ea/gainen/product/dfd/images/2-22f.gifより引用）
ＤＦＤを詳細化していき、そのプロセスの手順を
業務流れ図
（https://warp.ndl.go.jp/info:ndljp/pid/286890/www.meti.go.jp/policy/it_policy/ea/gainen/product/wfa/images/2-34f.gifより引用）
で示す
ここで示された業務流れ図のファイル(データ）を正規化し、
テーブルを作成。その内容をＥＲ図で記述する。
そして、業務流れ図の
画面に対し、画面定義書（＝画面レイアウト＋画面遷移図）
帳票に対し、帳票定義（＝帳票レイアウト）
を作成する。
この
画面定義、
帳票定義、
業務流れ図、
ＤＦＤから最終的に作られるミニスペック（自体はＤＦＤではないけど）
出プログラムは作れる（ここから、流れ図などに落としてもいいけど、落とさなくても、フレームワークが決まると作れる）
これと、「ほぼ」等価なものが、マインドマップ＋ＵＭＬで作れる。
●ＤＭＭ→マインドマップ
マインドマップで、全社から分解していく。最終的に、ユースケース図のユースケースまで落とす
●ＤＦＤ→ユースケース
マインドマップからユースケース図に落としたところが、
構造化手法の世界で言う、コンテキストダイアグラム（レベル０のＤＦＤ）となる。
ここから詳細化していく。
この詳細化は、ユースケースの詳細化となる。
ただし、ここでＤＦＤは、データフローダイアグラムの略称なので、データがはいってくるが
ユースケース図は、データが抜ける。これを、補完するのが、次の工程
●業務流れ図→アクティビティ図
ユースケース図の各ユースケースに対応するアクティビティ図を書き、これをユースケース記述の
基本処理系、例外処理系にしていく。
このとき、アクティビティ図は、業務流れ図に相当する。
ただし、業務流れ図に出てくる画面、帳票などは、すべてアクティビティ図のオブジェクトノード
になってしまうので、色を変えるなどの工夫がいる。
ＤＦＤのデータは、業務流れ図のファイルにマッピングされるはずである。
そして、業務流れ図のファイルは、アクティビティ図のオブジェクトノードとなる
ということは、ユースケースでデータが抜けても、アクティビティ図のオブジェクトノードで補完できる
●ＥＲ図→クラス図
ファイル、テーブルの内容はクラス図でも表現できる
ということは、ＥＲ図は、クラス図に相当することになるが、
ＥＲ図は、主キーなどのキー情報が書ける点っで、クラス図と異なる。これを何らかの形で補う必要がある。
●画面定義、帳票定義、ミニスペックに対応するものはない。
ソースコード＆コメントで直接書くことになる
→これが「みずほ証券」の裁判で問題になっている、ドキュメントは必要か？の本質と思う。
今の開発方法論では、この部分の情報がない。
ということで、３０年前のレガシーな設計書の情報は、ほぼ、
マインドマップ＋ＵＭＬで置き換えられる。
でも、最後の部分、「ソースコード＆コメントで直接書く」ということは、ＵＭＬと実装との対応が付くということになるが、それについては・・・
・・・それについては・・・
・・・それについては・・・
・・あ、（＠＿＠！）、書きかけだった。
こんど、つづきやる。
アクセス
トータル
ランキング
