８／３０(土）に開催されたモデル駆動開発勉強会のprudenceの熊田訓さんの発表のまとめです。
熊田さんは、MDAの考え方をベースとした実践的なモデル駆動開発をAndroMDAをメインツールとして推進されており、いくつもの開発プロジェクトを成功させております。本日は、その経験をお話いただきました。お忙しいところありがとうございました！
発表資料はこちら
MDA開発の実際
〜AndroMDAによるモデル駆動チーム開発の現場で起きたこと
■AndroMDAの紹介
・オープンソースのMDSD/MDAフレームワーク
・カートリッジにより機能を実現
・様々なスタンダードオープンソース製品を利用
・AndroMDAを用いた開発は、Web,DBをドメインとターゲットとした開発
すべてをモデルで記述しない
■MDSD/MDA採用によるメリット
・生きたドキュメント
ドキュメントと実装につながりがある
・定型コード/設定ファイルの自動生成
・デバッグ工数の大幅削減
■AndroMDA採用によるメリット
・様々なベストプラクティスの踏襲→構成が決まっている
・XML Hellからの開放
・３〜４人でのスムーズな分散開発の実現。チーム開発も成功
・運用しながらの各種変更にも柔軟に対応
MDAでは変換定義が必要 → ボーランドのツールでは、変換定義(OCL,QVT)が必要
AndroMDAでは、既に変換定義が容易されている(Ready-to-go)
■AndroMDAによる開発のデメリット
モデル記述、方法が複雑なところがある
Rails系フレームワークと比べると
・コンパイルが遅い
しかし、チーム開発、商用開発（設計主導）には強い
■Enterprise系のMDAってどうなのか
Rational ツール(Together)は定義が難しかった
変換定義の開発は、よほどの大手ではないとメリットが出ないのでは
AndroMDAでの開発は、Spring, Strutsにさわらなかった！
・JSP書いて、struts-configをいじってなどをやらなくていい
・作法をおぼえれば後はサクサク
・ダイナミックな型づけ言語だと、実行時エラー
・プロジェクト管理
・モデルの変換
・Agileだと開発規模がスケールしない
・大きなプロジェクトでAgileを採用すると、リーダーの実力が出やすくなり、リスクが高い
■まとめ
AndroMDAの開発で、Agile Allianceの考え方に近づくことができた
個人と相互作用を、プロセスやツールより重視する
動作するソフトウェアを、包括的なドキュメントより重視する
顧客との協調を、契約上の交渉よりも重視する
計画に従うことよりも変化に対応することを重視する
今年の目標：１００エントリーまであと３６。
