シリーズUML等各種ダイアグラムのエラーチェック体系化です。
今まで「いろんなダイアグラムをＲＤＢにいれよう！」化計画をやって
・クラス図
・ＥＲ図
・アクティビティ図
・ユースケース図
・ＤＦＤ
・機能構成図（ＤＭＭ）
・業務流れ図
までをRDBに入れる方法について示しました。
その結果、ここで話を展開したように、
オブジェクト指向の場合は、DIっぽくおこなうには、入出力メディアを決めないほうがよい。
それには、アクティビティ図、ユースケース図が向いている。
そうでない場合は、メディアをはっきりさせたほうがよい。なぜなら、メディアから来る制約により、実現できない要望を受け入れるリスクを避けられるから。
そう考えると、入出力メディアをはっきりさせる、業務流れ図のほうが向いている。
この場合、あとは
・画面定義(レイアウト、遷移、項目）
・帳票定義(レイアウト、項目）
・DB・ファイル定義（項目など）
・入力項目と出力項目間の関係（そのための処理）
を用意すると、大体自動的に、プログラムに落とせるということになることを書きました。
（これ以上詳しい今までのまとめについては、
ここ http://www.geocities.jp/xmldtp/index_system.htm
を参照してください。さっき、新しいものに更新しました）
今回は、そのオブジェクト指向の場合に利用するダイアグラム（これをUML系の図とよびます）と、オブジェクト指向を利用しない場合の図（これをEA系の図と呼びます）について、どのような流れになるかを考えていきます。
■EA系の図
まず、機能構成図（ＤＭＭ）でシステム化の大雑把な分類を行い、
この機能に対して、業務流れ図を書いていく。
業務流れ図では、入出力メディア（帳票、メールなど）が明確になっているので、
各入出力メディアに対する方式が決定でき、
方式が決定すれば、あとはぞれぞれのデータ項目である
・画面定義(レイアウト、遷移、項目）
・帳票定義(レイアウト、項目）
・DB・ファイル定義（項目など）
が決まると、その部分のプログラムは出来る
(例：画面名、レイアウト、遷移、項目が決まってStrutsとなれば、
レイアウト＋項目からJSP
遷移＋画面名からstruts-config.xml
項目＋画面名からActionForm
画面名からActionの外側（中身ナシ）
のプログラムは作成できる）
それら入出力関係は、業務流れ図に書いてあるので、あと
・入力項目と出力項目間の関係（そのための処理）
を決定して、記述すると（これが上記の例だとActionの中身）、プログラムは作成できる。
■UML系の図
全体からの部分わけは、はっきりしないが、DMMを使っても問題ない。
ユースケース図でも出来ないことはない。
ま、とにかく、部分に分けて、機能が適当に分けられたら
この機能に対して、アクティビティ図を書いていく。
このアクティビティ図から、システム化するアクティビティを抜き出し
ユースケース図とし、そのユースケース図を眺め、抽象化したほうがいい場合、
継承関係をいれていく。
これでできたユースケースと、アクティビティ図におけるオブジェクトノードが
クラスとなるので、クラス図へ
オブジェクトノードのメソッドは、入出力機能（CRUD)ということになる。
このクラス内部の処理に関しては、クラスがどのようなメッセージを発するか
ということになるので、シーケンス図で表現できる「かもしれない」。
（シーケンス図には、メディアがかかれないが、上記のように、今、メディアは関係なく、
クラスで表現されているので、入出力＝オブジェクトへメッセージを飛ばすということで
表現できる）
そしてそのあとで、オブジェクトをどのメディアに入れるかについては
DBに入れるなどという場合は、O/Rマッピング
帳票の場合はデータをXML書き出しでCocoon（FOP)に
など考えられる。
ただし、画面に関しては、Web系の場合、ある程度の制約（ハリウッドの法則で、自分から呼び出せない）があるので、それをあらかじめ考慮しておかないと、破綻してしまう。
ってかなんじになるんでしょうかねえ・・・
アクセス
トータル
ランキング
