「MDA モデル駆動アーキテクチャ(ISBN:4434038133)」
第8章「異なる抽象度におけるモデリング」を読んで
どうやら本章が本書でもっともコアな部分のようです．ちょっと長い．．．
本章における「異なる抽象度」におけるモデリングというのは，いわゆるドメインモデルや要求モデル，そしてMDAで扱うPIMやPSM，それに実行モデル(実行モジュールや環境)のことを指しており，冒頭で軽く要求モデルからPIMへの洗練(変換のこと，人手でやります)について，そしてPIMからPSMへの洗練(ジェネレート)については例を交えて説明されています．
それにしてもPIM，やはりこれは「実装」モデルなのですね．多少抽象度が高くても，間違いなく実装だと思います．たとえば例として出てくるPIMのあるクラスでは，<<focus>>というステレオタイプが付けられており*1，それによってJ2EEなPSMへマップするジェネレータはValue Object(Data Transfer Object)を適用します．つまり，J2EEパターン(PofEAAでも)などのベストプラクティスを適用するには，それなりのステレオタイプやタグ付き値を厳密に詳細に付与しておかなくてはならないわけです．もっとも，現在ゴリゴリとコーディングでやっていることに比べれば，十分にスマートなやり方だと言えるのかもしれません．後から「なんだよー，○○パターン使ってないのかよー」なぁんてことになった場合でも，マウスをチョイチョイっと操作するだけであっという間に「ベストプラクティス」準拠にできたりなんかするのかもしれません．あ，ちょっと素敵な感じが漂ってきました．(^^;
PIMで記述された関連をJavaによるPSMにマップする際の例として，関連の実装をListやMapなどの候補からどのように選ぶか，という点についての記述もあるのですが，その選択肢として
常に同じ 常に
Listとして生成する．中略
エンジニアによる上書き 2つのコレクションインタフェースのうち，どちらかをデフォルトで，それをエンジニアがグローバルまたは個別に上書きすることができる．
抽象化 2つのコレクション型の間の選択が，PIMで表現する意味のある，プラットフォーム独立コンセプトの下で行うことができるかどうかを決定する．
となっています．2番目の場合にはJavaマッピング固有のステレオタイプやタグ付き値を使って指定することになるそうです．しかし，そうなるとプラットフォーム独立モデルではなくて，プラットフォーム(で)共有(する)モデルになってしまい，なんだかなーって思います*2．ここでの例はインタフェースの選択ですが，その後ArrayListかLinkedListか，という話も出てきます．3番目で言われているように，うまくプラットフォーム独立なパラメータとして指定できれば，むしろ抽象的というか論理的な側面で特性を指定できるのはいいことだと思います．
こういうテーマって，表現力を保ったままいかに自由度を下げるかと言うことにも関連すると思うのですが，そこで思ったのが，構造化プログラミングのすごさ．かつてのラベルとブランチ(ジャンプ)による自由自在なコントロールフローを，選択と繰り返しに絞っちゃった((returnやbreakなどの脱出系もありますけどね．))わけですが，不自由さを感じるわけではありません．よくぞ整理したものだなぁって感心します．MDAが成功するには，相当に広い範囲でこういう整理整頓が必要になるのでしょうね．
本題に戻ると，本章の後半ではモデル(PIM)と生成されたコードの同期が取り上げられています．
ここでの大きなテーマは，PIMからコードへのフォワードエンジニアリングオンリーなのか，それともコードからのリバースエンジニアリングを含む完全なラウンドトリップエンジニアリングなのか，その中間か，ということです．近頃のUMLをサポートしたツールは大抵ラウンドトリップができる2Wayツールらしいですが，それらの場合は同じ抽象度のモデルについて，コードとUMLの両方で表示しているというだけであり，PIMと生成されたコードのように抽象度が異なる場合には，リバースエンジニアリングによるモデルとコードの同期はとても難しくなるそうです．それはそうですよね．想像したくないくらい複雑なにおいがプンプンします．なんでも，組み込みなどの世界では，フォワードエンジニアリングオンリーでも十分に使いやすいことが証明されているのだそうです．もうそういう実績があるんですねぇ．
さらに，3層あるいは4層アーキテクチャが絡んでくると，モデルとコード間の同期に加えて層間の同期を扱えることが求められ，その複雑化に対処するにはフォワードエンジニアリングオンリーに向かうだろうと述べられています．そうなんだぁ，って感じなのですが，それよりも3(4)層アーキテクチャはプラットフォームではないのですね．名前のどこからもプラットフォームとは読み取れませんし当然なのでしょうけれど，一瞬あれ？と思いました．さらには，クライアントがWEBブラウザ(HTTP+HTMLってことでしょう)であるとか，もしかしたらFlashだったりとかっていうことも，プラットフォームではない，みたいです．かな？ もっとも，プラットフォームというのは相対的なものだということなので，いずれクライアントの種類もPIMでは気にしなくてすむようになっていくのかもしれません(なっていかないかもしれません)．
本章では，MDAの具体的な例*3が示され，少なくとも本書執筆時点では未解決の課題(難題)が述べられています．ここだけ読んだ限りでは，実際の開発現場にMDAを導入できるのは相当先になってしまうのではないかと思いました．
ということは，OCLなどの宣言的・仕様記述的なスキルを学習する時間も十分にあるということかな？ 集合，論理，証明．．． どうにかしなくちゃ．
