「MDA導入ガイド」1-3章

日記のための読書シリーズ第2弾です.
第1弾で読んだ「MDA モデル駆動アーキテクチャ(ISBN:4434038133)」に比べると初心者にも優しいようで,一気に3章まで読めました.
1. MDA開発プロセス
まずは従来の開発プロセスの問題点があげられています.主な問題点としては,分析や設計の成果物であるモデルが「単なる紙」にすぎず,それらはコーディングが始まると(コードとモデルが乖離して)価値がなくなってしまうことだとしています.そのため,XPなどのようにコードを中心とする開発プロセスに注目が集まっているものの,大規模なシステムを開発チームが解散した後も保守することなどを考えると,「目印」としてのモデルが必要である,ということです.
しかしながら,モデル(ドキュメント)を正しく維持するのは困難です.この理由について著者は,次のように書いています.

1.1.4 保守と文書化の問題
文書を作成することで開発者の主なタスクがサポートされるわけではありません.文書を利用することでサポートされるのは,後で発生するタスクです.従って,文書の作成は全体の繁栄のために行っているようなもので,自分自身のために行っているのではありません.

確かに.ここで「人のために」だからこそ頑張れる人ばかりならいいのですが,不幸にして私は自分が楽しいことしかしたくないタイプ... 心より恥じる.
そこで,コードではなくモデルにより開発プロセスを駆動する,MDAが役に立つというわけです.
「1.2.1 MDA開発のライフサイクル」では,開発プロセスの各工程ごとの成果物が説明されています.それによると,「分析」の成果物がPIMということになっています.そして「設計」の成果物がPSM,「コーディング」の成果物がコード.どうなんでしょうか? ちょっと納得しがたい定義です.PIMは確かにプラットフォームから独立しているという点で抽象度が高いとは思いますが,とても分析の成果物とは考えられません.「MDA モデル駆動アーキテクチャ(ISBN:4434038133)」の印象では,コーディングでなくても間違いなく実装だと思わざるを得ない雰囲気だったのですが.
MDAによって得られるメリットとして,お約束の生産性が上げられています.理由の一つはプラットフォームの詳細を扱わなくていいこと,もう一つの理由は開発者が焦点をコードからモデルに移せることだとしています.最初の理由はまだ分かるとして,2番目の理由はどうなんでしょう? なぜモデルに焦点を移すと生産性が向上するのか,その理由は説明されていません.最新のモデリングツールは,優れたエディタやIDEでのコーディングを凌駕する生産性を実現できるのでしょうか? 少し疑問を感じました.
2. MDAフレームワーク
ここでは,「モデル」とはどういうものかという定義やその種類,異なるモデル(PIMとPSM)間の変換について解説されています.
3. 今日のMDA
MDAの現状を解説しています.
それによると,アクション・セマンティクスは抽象度が低くPIMの記述には向いておらず,OMG(UML)の標準でもないとのことです.そうだったんだ... また,「Executable UML(ISBN:479810602X)」で紹介されているステートマシンを使用した振る舞いモデリングは,組み込み系では有用でも,業務系では面倒すぎるとしています.やばい,次に読む本なんだから,ほめてほしいんだけどなぁ.


という感じで,いかにも導入部です.PIMが分析の成果物というあたりが納得できませんが,読み進んでいくと「なるほどぉ」ってことになるのでしょうか? 今後に期待します.