シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
前回は、ドキュメントの記述する基準として、
・後工程の入力になるために、前工程としては、どこまで記述しないといけないか？
を基準に考えると書きましたが、じつは、そーやって考えると、UMLの図は、
みごとに行き詰まります。
たしかに、アクティビティ図とユースケース図の間には、関連があります。
しかし、これらにおいては、プロセス記述が中心で、データが記述されません。
データが記述されるのは、クラス図なのですが、このクラスが出てくる根拠が、前工程であるアクティビティ図、ユースケース図から、かならずしも、導き出せないのです。これは、矛盾チェックとして、ユースケースは、どこかのクラスに存在するはずであるという（成果物からの）チェックはできるのですが、前工程とはつながっていないため、ここに悪く言えば恣意性、よく言えば技術者の経験的勘が入ってくることになります。
クラス図まで持っていけば、Javaなどのクラスに落とし込めることはたしかです。
ただ、プログラムのほうには持って行けるのですが、データベースのテーブル作成根拠がないのです。ふつうはこの根拠はER図の導出方法（つまり正規化）になりますが、そもそもUMLにER図はないので、（＝エンティティはオブジェクトではない）クラス図で代用することになりますが、そうなると、そのクラスは、永続性をもたせるべきなのかどうか？ということが、これまた、悪く言えば恣意性、よく言えば技術者の経験的勘になってしまうのです。
つまりですね、UMLの図はぶつ切りで、これを結び付けようとすると、えいや！っていうところが出てきてしまい、関連性もなにも、なくなってきてしまうのです（＞＿＜！）
ところが、ところがですね、ここで、すごいことが起こるのです！！！
・後工程の入力になるために、前工程としては、どこまで記述しないといけないか？
を基準に考えた場合、ある図とある図を組み合わせると・・・・
・・・あーれー不思議なことに、ぜーんぶつながって、さらにUMLの多くの図、DFDなどが、自動的に導き出せるのです。
そして、その図は、UMLや、DFDではないんだけど、よーくみんなかく図なのです。
この、全部をつなげることができ、多くの図が導出できるという、
史上最強ダイアグラムについては、またこんど。。
アクセス
トータル
ランキング
