ＭＤＡ（Model Driven Architecture、モデル駆動型アーキテクチャ）
ＭＤＡとは、ビジネス要件やソフトウエアの機能と構造などを分かりやすい図を使ったモデルで表現してシステム開発を進め、最終的にそれらのモデルからプログラムを自動生成する技術です。
オブジェクト指向の標準化団体であるアメリカのＯＭＧが提唱するシステムの構築方法で、いくつもの標準技術を体系化したものです。
ＭＤＡのモデル体系
- ＣＩＭ（Computation Independent Model、情報処理独立モデル）
- 実装技術から独立する形でビジネスプロセスを分析し、ビジネスルールと各種制約の下で実現すべきビジネス要件をモデル化します。すなわち、whatだけを定義したものです。
- ＰＩＭ（Platform Independent Modelプラットフォーム独立モデル）
- ＣＩＭに業務ロジックを付加したモデルですが、ここでは、ＯＳや言語などのプラットフォーム技術に依存せずに作成します。ＵＭＬ（Unified Modeling Language）での記述になります。
- ＰＳＭ（Platform Specific Model プラットフォーム特化モデル）
- ＰＩＭで作成した多くのＵＭＬ図を、特定のＯＳ、Ｊ２ＥＥ, Webサービス, ＣＯＲＢＡ等のモデル設計プラットフォーム依存した（how を記述した）モデルを生成します。
ＰＩＭからＰＳＭへのマッピングルールは定義されており、ＭＤＡツールによりＰＩＮからＰＳＭへのソの生成を自動、半自動で行うことができます。
- ソースコード
- ＰＳＭが最終的なソースコードになっていることもありますが、メタ言語段階の場合もあります。それをツールを使って実際のソースコードに変換します。
ＭＤＡの利点
- 開発者の分担
ビジネス要件、ＰＩＭでの論理設計、ＰＳＭでの実装のモデル化を分けることは、ウォータフォール型の開発と同様に、異なる開発者に分担でき、しかも整合性を保つことができます。
- 自動生成による生産性向上
- 標準化・部品化
ツールを用いた自動生成により、標準化された記述方法になり、一定の品質確保、トレーサビリティの向上、部品の再利用性が高まります。
ＭＤＡ関連技術
- ＵＭＬ（Unified Modeling Language）
- ＵＭＬは、オブジェクト指向分析／設計における標準的モデリング言語です。アプリケーション開発者はＵＭＬの各種図法を利用して、システム設計/開発を行ないます。
- ＭＯＦ（Meta Object Facility）
- ＭＤＡは、抽象モデル→具体モデルの変換体系でもあります。その抽象モデルをメタモデルといいます。ＭＯＦは、メタモデルを記述するための構成要素を定義し、メタモデルを管理するための技術仕様です。
抽象モデル→具体モデルでは、抽象モデル（メタモデル）にオプションを書き加え、そのオプションを解釈して具体モデルに変換します。ＭＯＦとは、その「書き加え」る方法の標準でもあります。
- ＸＭＩ（XML Metadata Interchange）
- ＭＤＡでは、ＵＲＬ図（例えばクラス図）をＸＭＬ文書に変換して保存・共有することが多くありますが変換の際のスキーマ（ＸＭＬ Schema）の適用の標準化が必要です。ＸＭＩは、ＭＯＦを基盤としたモデル情報をＸＭＬ形式に変換し、ツール間でモデルを交換可能にするための技術仕様です。
- ＣＷＭ（Common Warehose MetaModel）
- ＵＭＬは、データのモデリングやデータ処理には不向きな図法です。ＣＷＭは、ＯＬＡＰ、データウェアハウス、データマイニングなどの用途に向けたメタモデルを定義した技術仕様です。
ＦＤＤ（Feature Driven Development：ユーザー機能駆動開発）
ＦＤＤもＭＤＡと同様に「モデル駆動型」のシステム開発方法論ですが、ＭＤＡは、どちらかといえばウォータフォール型の方法論です。それに対してＦＤＤはアジャイル開発を意図した方法論です。
ＦＤＤは、ＭＤＡの概念を多くとりこんでいますが、アジャイルでの「小さな機能の集合」であるフィーチャーいう単位に基づいて、要求仕様間の依存度を可能な限り小さくなるように表現すれば、仕様追加・変更や設計変更に対応できるようにしたものです。
フィーチャーは、設計とプログラム開発を ２週間以内での開発が可能な単位であり、独立性が高いので複数人で並行開発、かつ、反復（イテレーション）開発ができます。
フィーチャーの概念
フィーチャーは「価値のある小さな機能のかたまり」（ユーザから見た最小機能）としてのサービスです。例えば、
・販売員の成果を査定する。
・スケジュールされた自動車整備を実施する。
・カード所有者のクレジットカード取引を認証する。
・銀行予期人の残高を取得する。
というような単位です。
概念形式的には、フィーチャーは、
[目的語（オブジェクト）］[結果］動詞[（アクション）］
の形式で表現されます（［結果］は省略可能）。
ＦＤＤの流れ
基本的にはＭＤＡのＣＩＭ→ＰＩＭ→ＰＳＭと同じ流れになります。
フィーチャーは、ＣＩＭの一つになります。
- 要件分析段階：ＵＳＤＭ
- 「派生開発の変更を含む要求仕様の表現方法」です。特に要求漏れを防止するのに有効です。また、要求仕様が変更になるときの対応が柔軟になります。
- フィーチャーの形式でいえば、「要求」はフィーチャー、「仕様」は目的語、動詞になります。
要求は上位要求、下位要求の階層になり、最下位要求がフィーチャーにななる。
- 要求仕様書と機能仕様書の使い分け
要求仕様書 機能仕様書（等）
目的 作るためのもの 機能を説明するもの
関係者 計画書で特定されている 特定されていない
表現 関係者がSpecifyできる状態 一般的な記述
納期やコスト 背後に背負っている 意識されない
バージョン管理 今回だけの文書 ソースコードと対でバージョンアップする
- 基盤方式設計と機能方式設計
- 基盤方式設計は、主として非機能要件を実現する具体的な仕組みを表現するソフトウェア構造（タスク構造、ファイルの分割構造、重要な処理手順）を設計するものです。
機能方式設計は、入力から出力への変換において、機能要求を満足する概念的な（論理的な）構造や振る舞いを明確にする作業です。
ひとまとまりの情報をできるだけ同じコンポーネントにまとめるのですが、ここで重要なのは、コンポーネントが環境の変化に影響を受けることが少ないようにまとめることです。環境変化など外乱の影響による変化を阻止する内的な仕組み、または性質のことを ロバストネスといい、ロバストネスが大きい（影響が少ない）範囲（機能）をまとめることをロバストネス分析といいます。
基盤方式設計と機能方式設計は相互に関係するので並行に進めます。
- 詳細設計
- 詳細設計では、主に下記の成果物を作成します。
① クラス図：プログラムとして実現するためのクラス
② シーケンス図：プログラムとして実現するためのオブジェクトの振る舞い
③ 状態遷移図：プログラムとして実現する上で重要な状態遷移
④ アルゴリズム設計書：②のシーケンス図では表現できない処理手順