最近のMDAツールを見ると、分析段階と設計段階ないしは設計段階と実装段階
のそれぞれの間に存在する情報量のギャップを「パターン指定」という形で
埋めようとする試みが良く見られます。
例えば
業務分析で得た結果から設計に移る際に「ここはCompositeパターンで行こう」
と指定すると、それに応じたクラス図を生成してくれる(設計パターンの指定)
といったものや
設計はMVCモデルを採用することにして、実装技術としてstrutsを選ぶと
必要なアクションクラスのスケルトンを生成してくる(実装パターンの指定)
といった感じです。
もちろん、こうしたパターンを各上流のダイアグラムに盛り込むことも不可能
ではないですが、上記のような仕組みがあれば本来のビジネス要件を記述する
ことに集中できるというメリットもあるのではないかと思います。
MDAは抽象的なモデルから具体的な実装への一気通貫の流れを実現させ、モデル
から実装へのトレーサビリティを確保することを目的として進歩してきましたが
今後重要になってくるのは「システム更新の過程でモデルに対する実装側のズレ
を如何に抑えるか？」という点ではないかと考えています。
システム更新に際してもきちんとモデル側の修正から入るのが本筋ですが、実際
の現場では(特に不具合修正であったり、レスポンス低下といった非機能要件に
関連する修正の場合には)ソースコード側から手を入れざるを得ない場面も多々
あるのではないかと思います。
そうした時にモデルとソースコードの自動同期によってモデル側に反映される
のは良いとしても、それがモデルの観点から見て好ましい修正方法であるのか
どうかを可能な限り早い段階でチェックすることが重要になってきます。
例えば、
Abstruct Factoryパターンを使ったり、もっと今風ではDIを使って
疎結合になるようにしたのに、急ぎの修正があって思わず実装クラス
を直接生成してしまう
とか、
コーディング担当者が何人か代わるうちに、本来はTemplate Methodパターン
を意図してprotected指定されていたメソッドの使い方を誤って、サブクラス
内で直接コールしてしまう
とかいったようなミスは単にモデルとソースコードを同期させただけでは
見つけにくい問題であるような気がします。要はモデルのレベルよりも
ソースコードのレベルの方が情報量がより仔細になるので、ソースコード
からモデルへと逆方向への変更の流れが生じた場合に、チェックが難しく
なるのではないかということです。
そこでテストツールに目を転じると、最近のテストツールではバグチェックの
機能の一環としてコーディング規約やコーディングパターンに従っているかを
ソースコードを走査することでチェックできるものがあります。
こうしたテストツールとMDAツールがうまく連携すれば、上記のようなソース
コード変更時のズレを軽減させることができるのではないかと考えています。
あるいは生成させるソースコードにアノテーションなどを使ったメタ情報を
埋め込んでおき、そこに設計上の遵守事項を記載しておくという方法も考え
られます。その場合にはプリコンパイラのようなものでパターンを遵守した
コーディングになっているかをチェックするような流れになるかと思います。
MDA本来のあるべき姿からすると好ましいことではないのですが、下流から
上流へと変更の流れが逆流してしまった場合においても(逆方向の)トレーサ
ビリティが維持され、モデルとしての整合性が崩れないようにする仕組みを
備えているかどうか？という「逆流時の対処」がMDAツールを選択する上で
ポイントの一つになりそうな気がします。
