オブジェクト指向で、修正による影響をうけにくくする方策で書いてきたことを総合すると、システムを作るには、
・出力したい結果から、（正規化などして）必要なデータを割り出し、
・その必要なデータを生成する業務プロセスを抽出して、
入力したものが業務プロセスにより加工され、目標となる出力ができることを確認しないといけない。
（逆にいえば、これが出来れば、システムは作れる）
この「入力したものが業務プロセスにより加工され、目標となる出力ができる」過程がモデルであり、ここには、
・「入力されるもの」、「出力されるもの」といった情報と
・それを処理する業務プロセス（処理）
が記述されていることになる(情報＋処理＝情報処理）。
この情報部分のモデルがプログラミング上におち（＝テーブル、ファイルなどで表現される）
業務プロセスに対応するプロセス（メソッド、関数）が、すでにあるか、あるいは、既存のものから作れるとき、
モデルはプログラムから自動生成しうる。このモデルから、プログラムへの自動生成がMDAだった。
逆に言うと、情報部分と処理部分が、関連付けてかかれることがなければ、自動生成のしようがないことになる。
一方、UMLは、情報と処理の流れが同時にかかれることはない。
情報と処理の両方が含まれるのは、クラス図である。
で、たしかにクラス図からクラスはつくれるかもしれないが、クラスのメソッドの処理内容はクラス図にはかかれないので、そこまで自動生成できない。
アクティビティ図、ユースケース図には、今度は、情報(データ）をそこまで詳しく書き込まない。
このようなかんじで、UMLには、情報とモデル、完全にかかれることがないので、モデルがプログラムに落としこめるレベルまで、はっきりしない。そのため、これでは、MDAとして、プログラムの自動生成までいくかどうか、疑問である・・・
・・・とか書いたら、UMLやってるひとに、おこられそうだ。。
アクセス
トータル
ランキング
