MDA
システムの機能や振る舞いを、プラットフォームに依存しないモデルとして整理し、実行環境に応じたモデルや実装へ展開する開発の考え方。OMGが提唱し、環境が変わっても中核の設計を再利用しやすくする。
イマシルちゃんの解説
同じお店の仕組みを、別の建物でも使いたいとするよ。
接客の流れと、建物ごとの電気や水道の配置を分けて考えれば、移転のたびに全部を考え直さずに済むよね。
共通の設計を、新しい場所で使える設計へつなげる。
ただし、どの部分が場所に左右されるかを、先にはっきりさせる必要があるんだ。
より深い解説
実行環境への依存を分ける
MDAはOMGのモデルに基づく開発アプローチである。業務上の規則やシステムの振る舞いと、特定のOS、ミドルウェア、通信基盤などへの依存を分けて整理する。
モデルを詳しく描くことだけが目的ではない。モデル間の対応や変換規則を明確にし、技術の変更に応じて展開できるようにする。
二つのモデルの役割
| モデル | 内容 |
|---|---|
| プラットフォーム独立モデル | 特定の実行基盤から独立して、機能や振る舞いを表す |
| プラットフォーム依存モデル | 採用する実行基盤の制約や実現方法を反映する |
英語名と略称は次のとおりである。
PIM: Platform-Independent Model
PSM: Platform-Specific Modelどこまでをプラットフォームとみなすかは、対象とする抽象度や変換の範囲によって決まる。
モデルを展開する流れ
- 必要な機能・規則を、プラットフォームに依存しない形で定義する。
- 対象の技術基盤を選ぶ。
- その基盤へのマッピングや変換規則を適用する。
- 具体的なモデルと実装を作り、元の要求を満たすか検証する。
ツールによる自動生成を利用できる場合があるが、すべてを人手なしで完全に生成できることが必須条件ではない。変換できる範囲と、手作業で補う部分を管理する。
独自の例
貸出しシステムを作る場合、「同じ資料を同時に二人へ貸さない」という規則は業務側のモデルへ置ける。一方、データベースでどのトランザクションやロックを使うかは、採用基盤を踏まえて具体化する。
| 整理するもの | 主な観点 |
|---|---|
| 業務の規則 | 実行基盤を変えても維持したい内容 |
| データ保存の方法 | 基盤の機能と制約 |
| モデル間の対応 | 元の規則がどこで実現されるかという追跡可能性 |
基盤側へ移すときに業務の規則が抜け落ちないよう、対応付けが必要になる。
UMLとの関係
UMLは、モデルを表現するためのモデリング言語である。MDAは、モデルをどう分け、実装へどう結び付けるかという開発の考え方である。UMLで図を描くだけで、自動的にMDAになるわけではない。
モデルを使い分けることで中核の設計を再利用しやすくなる一方、モデルと実装が食い違うと効果が下がる。変更時にも両者と変換規則の整合性を保つ必要がある。