トピック

概要ページのトップ

RUP は、その成果物の多くをモデル として 記述します (モデルは特定の観点からシステムを抽象化または記述したものとして定義されます)。 また、モデル (特にビジュアル・モデル) の構築は、RUP の最善の実践原則として説明 されています (『最善の実践原則: ビジュアルなモデリング (UML) (Best Practice: Model Visually (UML))』を参照)。 しかし、RUP は多数のモデルを識別し、それらのモデルをアクティビティー間で入出力として 伝達する方法を記述しますが、モデルの形式は厳密に規定しておらず (表記法は除く)、 あるモデルを別のモデルに変換する方法も特に必要としていません。 したがって、ソフトウェア開発で RUP をインスタンス化および導入するには、 モデルを生成している間、そのモデルを検出、文書化、通信の機構としてのみ機能させ、 人間の開発者の仲介以外では、開発コードに影響が及ばないようにする方法が必要となります。

モデル駆動型開発 (MDD) では抽象化のレベルが向上しますが、モデル記述とビュー・モデルに対して厳密性が 要求されます。つまり、単なる中間的な開発成果物ではなく、運用システムを生成できる厳密な記述が求められるのです。 MDD では、開発を成功させるために、より高度なツールを明確に利用しています。 これにより、テンプレート作成からコード生成の完了まで、さまざまな機能が提供されます。

モデル駆動型アーキテクチャー® (MDA®) は、オブジェクト管理グループ (OMG) のイニシアチブ の一つであり、MDD を規定する完全なフレームワークを記述します。 MDA では、独自の用語と概念が取り入れられていますが、統一モデリング言語やメタオブジェクト・ファシリティーなどの 以前の標準化作業に基づいて、ソフトウェア開発に対する厳格な変換アプローチと、ツールによる自動化の基礎を 定義しています。

モデル駆動型開発 (MDD) ページの先頭へ

モデルおよびモデリングページの先頭へ

モデルは、Rational Unified Process の重要なタイプの成果物です。 (RUP では) 通常、統一モデリング言語 (UML) を使用して、ツールと環境に依存しない方法でモデルを表現します。 したがって RUP は、さまざまな環境の各種ツール・セットを使用して、導入および制定することが可能です。 RUP の『最善の実践原則: ビジュアルなモデリング (Best Practice: Model Visually (UML))』では、モデリングを行う理由をいくつか説明しています。

  • 複雑なシステムを理解する助けにする
  • 設計の代替案を低コストで調査および比較する
  • 実装の基礎にする
  • 要件を正確に把握する
  • 決定内容を明確に伝達する

モデルは、システムの振る舞い (希望の振る舞いと実現される振る舞いの両方) と構造を検討し、 その検討結果を関心のある利害関係者に伝える手段とみなされます。 MDD では、実装の基本要素としてのモデルの役割を重視し続けています。これは、モデルが コード開発者に依存する単なる青写真ではなく、サポートされるツール・セットの機能に応じて、 ある程度、制定または実行可能であることを期待しているからです。 これは、開発者が作業する際の抽象化レベルを高めるという動向に沿うもので、かなり前から始まっています。 これにより、我々が知っているコードから、より高度で (場合によっては) グラフィカルな言語で 表現されるモデルへと、注目が移っています。

RUP はこの可能性を暗黙的にサポートするために、特定の成果物を、 モデルの画像 を含む (例えば、要件と設計を取得している) 文書としてではなく、 モデルとして識別します。

視点およびビューページの先頭へ

視点は、その名前が示すように概念的な位置のことです。システム (または、システムを表す一連のモデル) に関する 特定の側面や関係は、視点から見ることができます。 視点は、概念的フィルターを形成する一連の概念と規則からなるアプリケーションを意味します。 「観点」という用語も同様に使用されます。この用語は、さまざまな利害関係者の 多様な判断や関心を提供するのに最適なモデルを、見たり理解したりする方法を説明するのに使用されます。

ビューはモデルの射影であり、関連するエンティティーを特定の視点または観点から示します。

MDD では、視点とビューを使用して問題点を分離します。これは、例えば、物理構造やプロセス構造とは無関係に 論理構造を扱うためです。 問題ドメインにモデルが接近するほど、視点または観点は、利害関係者のビジネスの問題により強力にマップされます。 モデルの開発が進み、実行可能な形式に近づいてくると、より多くのコンピューティングの問題が立ちはだかります。 いずれの場合も目標は、単に受動的な図を作成することではなく、これらの別々の問題を解決する実装を 生成できるようなモデルを作成することです。

推敲および翻訳 (変換) ページの先頭へ

通常、これらの用語は、手動によるモデル変更 (推敲) とツールによるモデル変更 (翻訳) とを区別するために、 非公式に使用されます。 RUP では、「推敲」の正式な意味は、まったく別なものになっています。「推敲」はライフ・サイクル・フェーズの名前です。 ただし、このセクションでは、モデル発展へのさまざまなアプローチを明確に示すために、 この用語を非公式に使用します。

翻訳と推敲には、ステップのサイズが異なるという意味もあります。つまり、詳細 (言語、インフラストラクチャー、 またはオペレーティング・システムの詳細など) が十分になるまで、モデルをいくつかの小さなステップで繰り返し推敲し、 その後、ツールまたは手動によって、その詳細からコードを生成するという意味です。 手動の場合は、人間がモデルを参照し、Java、C++ などの言語を記述して、可能な場合はプロセス内でさらに推敲を行います。 これに対して、翻訳の場合は、言語、インフラストラクチャー、またはオペレーティング・システムの問題で まだ汚れていない抽象化のレベルのモデルが、実行後に希望の結果を生成するものに変換されます。 推敲の必要はほとんどありません。 希望する結果には、パフォーマンスとその他の機能外特性が含まれることに注意してください。 したがって、このアプローチでは、モデルを作成する方法、およびリソース要件を記述する方法で、 こうした分野横断的なアーキテクチャー問題が暗黙的に解決されます。

別の用語として変換 も使用されていますが、 これは、一連の規則のもとで一連のパラメーターに従って作業することにより、ソース・モデルからターゲット・モデルを 生成するプロセスを説明するものです。ここで、「モデル」という用語は RUP と同じように使用されることに注意してください。 したがって、ターゲット・モデルは、実装要素 (コードやテキストなど) にすることが可能です。 もちろん、変換は手動で行うことができます。この場合、連続する変換 (詳細の追加) は推敲と同じことになり、 規則が非常に複雑になります。規則は、提供されているテクノロジーとドメインの深い経験に根ざすものになります。 しかし、デフォルトの意味は、変換は自動的に実行されるということであり、 これについては、次のセクションの『モデル駆動型アーキテクチャー®』で再検討します。

変換の概念には、ソース・モデルとターゲット・モデルが含まれるにすぎません。 通常の場合、ターゲット・モデルはソース・モデルよりも抽象度が低くなっています。つまり、 ターゲットはソースよりもいくらか特定的であるということですが、これは、変換の概念において暗黙的なことではありません。 また、変換では、詳細をモデルに追加し、より洗練されたターゲット・モデルを作成することもできます。 その一方で変換は、別のドメインに関連する情報が導入されないという点で、 ほぼ同じ抽象化レベルにとどまります。 UML モデルからコードを生成する変換とこの変換とを対比してください。 必要な振る舞いと機能外特性を保持する場合、UML モデルでは、ビジネス利害関係者に関係のない多くのものが、 このターゲット・モデルに導入されます。

変換における理想を実現できるかどうかは、ツールの機能、および経験者が使用する知識を分類、収集、再利用する 能力にかかっています。 収集および分類する必要のある知識の量は、変換ステップを実行する抽象化レベルによって異なります。 一般的には、レベルが高いほど、知識の量とドメイン依存度が増します。

MDD において、我々は、運用システムを自動的に生成できる抽象化レベルを向上させようとしています。 モデルは、何かを生成できる時点になるまで推敲されます。 そこで、出力をさらに推敲しなくても実行を可能にすることが高い優先事項になります。 さらに、我々の野心は、連続する自動変換を通じて、可能な限り先行的な推敲を行うことです。 したがって、2 つのアプローチを融合することになります。つまり、連続する変換ステップによって翻訳を行うとともに、 できる限り翻訳を自動化するのです。 実行するシステムに対して最後の変換を行う際は、依然として抽象化レベルの高いモデル記述を使用します。 また、テクノロジー、インフラストラクチャー、およびターゲット言語の選択を変換エンジンでエンコードし、 規則とデータをそれに対して提供します。

MDD の別の利点は、変換を再利用できる望みがあるということです。その際は、対応するドメイン内の専門家による作成を通じて、 プラットフォームとドメインの知識、および最善の実践原則を分類することになります。 この方法により、スキルが十分でない開発者でも再利用を容易に行うことができ、 それぞれの新しいアプリケーションを使用してゼロから再作成する必要がなくなります。

高レベルの抽象化とは?ページの先頭へ

これを考える方法は、いくつかあります。 1 つの方法は、言語の範囲に沿って考えることで、例えば、実行可能な UML 形式が登場しています。 もう 1 つの方法は、ドメイン・エンジニアリングの観点から考えることです。ドメイン・エンジニアリングでは、 言語とモデリングの概念をそのドメインに特化できます。 例えば、UML は汎用言語なので、 UML の使用法を特定する UML プロファイル の 使用法は、この次元に沿って理解されます。 さらに別の方法は、ベンダーとインフラストラクチャーに固有のモデルを避け、新しいテクノロジーを常に 受け入れることができるようにしておくことです。

動的作用の詳細に関しては、 UML アクション・セマンティクスに 関する作業により、実行可能形式の UML が実現されました。しかし、具体的な構文と表記は標準化されていないので、 アクション・セマンティクスは、その他の OO 言語と同様になります。 したがって、UML とアクション・セマンティクスは、おそらく最終的な答えではなく、 進捗状況を示すものになるでしょう。

結論として、UML 形式または UML プロファイルを使用して表現する、ベンダー依存要素を含まないモデルは、 J2EE や Microsoft® .NET などの特定のインフラストラクチャー・プラットフォームに依存することはなく、 構造内で意味的に完結します。 また、この定義では、特定の手続き型言語 (Java、C#、...) に依存しない振る舞いの抽象化レベルは高くなります。 ただし、アクション・セマンティクスのレベルの問題は残ります。

問題ドメインの観点 (ユーザーまたはビジネス顧客の視点) から言えば、 魅力的で可能な解決策は、ドメイン固有のモデリング言語を公式化することです。 これらの言語は、特定のドメイン内の作業者になじみのある用語と概念で表現されるという意味で抽象的でありますが、 依然として UML ベースであり、モデルの動的作用を表現することが可能な点で完全です。

RUP との関係ページの先頭へ

RUP 分析、設計、および実装モデルの関係により、次の概念が説明されます。 分析モデルは、ユース・ケースで表現される振る舞いの実現方法に対する 初期のビューを表します。これは、解決対象の問題ドメインの方に記述的に傾いているのが自然です。 また、それに含まれる分析クラスは、必要な責務と振る舞いの概念的な グループとみなされます。 通常、モデルを読み取り、ギャップを埋める人間による思考実験の場合は除いて、 分析モデルは、実行するのに十分な完成度ではありません。 なぜなら、決定せずに残されるものが多すぎるからです。 その代わり、分析モデルでは、洗練プロセスを実行し、詳細と精度を追加して、 設計モデルを生成する必要があります。

RUP を使用すると、プロジェクトは、個別の分析モデルを保守することもできますし、 分析モデルを設計モデルに発展するものとみなすこともできます。 洗練プロセスは RUP 作業で特定の長さで記述されますが、そのとき使用されるデフォルト解釈は、 「この発展はソフトウェア・アーキテクトおよび設計者の役割を果たす人間が達成する」というものです。 また、プロセス記述の際は、かなりのツール支援が使用されるでしょう。 この洗練は、一連のモデル変換とみなすことができる点に注意してください。これらのいくつかは、例えば、 RUP 作業のアーキテクチャー分析設計メカニズムの識別で、 分析 およ び設計 パターンのアプリケーション内で 自動化できる場合があるでしょう。

設計モデルはいつ完成するのか? ページの先頭へ

設計モデルは、プロジェクトの存続期間中、いくつかの反復を通じて発展します。 それでは、設計モデル (またはその一部) をコードに変換できるのはいつなのでしょうか? つまり、 実装要素を作成し、それをシステム内の関係のある ビルドに組み込むことができるのは いつなのでしょうか? RUP では、『設計のコードへのマッピング』に関する ガイダンスをいくつか提供していますが、堅実ですぐにわかるような回答は基本的にありません。 実装に移行するのは、レビューが完了した時点、例えば、実装が可能であることを判断した時点ですが、 これは、組織とプロジェクトとの間でかなり異なります。 RUP では、設計からコードに移行する方法を数多く提供していますが、ここでは、そのうちの 2 つを説明し、 設計の完了を判断する方法を示します。

1. スケッチとコード
RUP の記述:「1 つの一般的な設計方法は、設計をかなり抽象的なレベルで略述してから、 直接コードに移行するというものです。その設計モデルの保守は手動です。

このアプローチで成功するには、設計レベルと実装レベル間の抽象化のギャップを開発者が埋めることができなければなりません。 多くの場合、設計モデルの保守は 2 番目の問題であり、コードが中心になります。

2. 単一の発展する設計モデルを使用したラウンド・トリップ・エンジニアリング (RTE)
RUP の記述:「このアプローチには、単一の設計モデルがあります。 設計要素の初期のスケッチは、コードと同期することができるところまで発展します。

ここで開発者は、一連のモデリング・ステップを使用して、抽象化のギャップを埋めます。 このアプローチと「スケッチとコード」の違いは、中間ステップが明白であり、 最終的には、抽象化バージョンの設計モデルが消えていることです。

両方の場合において、抽象化設計モデルの潜在的価値は失われます。 「スケッチとコード」の場合は、抽象化設計モデルは通常は保守されず、 やがてコードとの接点が失われることがその理由です。「単一の発展する設計モデル」の場合は、 抽象化バージョンが消えることがその理由です。 初期のバージョンを保持したとしても、通常それは「スケッチとコード」設計モデルと同じ運命をたどることになります。 RTE による設計モデルの終了点は、実際にはコードの図式化です。同様の図式化は、 適切なツールを使用して「スケッチとコード」で作成したコードから、リバース・エンジニアリングが可能であることに注意してください。 RUP では、抽象化設計モデルの損失をある程度軽減するために、ソフトウェア・アーキテクチャー説明書内の 重要な時点において、重要なアーキテクチャー・ビューと設計根拠を把握します。

MDD では、抽象化設計モデルがコード生成の基盤になり、長く使えるようになるという望みがあります。 このモデルは保守のための重要な基盤になりますが、実際は、保守のための唯一の基盤になります。 また、このモデルでは、設計の終了点が明確に定義されます。つまり、変換エンジンに関して言えば、 モデルが一貫性をもって明確に完成し、実行可能システムに変換できる時点が明確に定義されます。 モデルをどれだけ抽象化できるのかは、使用可能なテクノロジーとツール・ セットによって異なりますが (例については、 『ツアー: Rational Software アーキテクトの概要 (Tour: Rational Software Architect Overview)』を参照)、 ドメインによっても異なる場合があります。 MDD に関して言えば、これは単なる別の変換 (設計からコードへの) ですが、各抽象化レベル間をジャンプする重要な変換です。

次のセクションでは、MDD の新しいフレームワーク標準である、モデル駆動型アーキテクチャ ® (MDA®) と 呼ばれるオブジェクト管理グループ (OMG) のイニシアチブについて説明します。

モデル駆動型アーキテクチャー (MDA) ページの先頭へ

動機ページの先頭へ

MDA は、800 ものメンバーからなる業界コンソーシアム OMG のイニシアチブです。 OMG は、標準のガイドラインと仕様を策定して、ベンダーに依存しない共通のアプリケーション開発フレームワークを提供し、 主要なハードウェア/ソフトウェア・インフラストラクチャー・プラットフォーム間での相互運用性を促進しています。 統一モデリング言語は、OMG が作成したものです。 現在 OMG は、MDA を最も重要な仕様として策定を進めています。 OMG のスタンスは、実用的な標準を普及する団体というものであり、業界 IC、実践原則、およびツールでサポート されています。また、OMG は UML の成功を示しているので、MDA は研究の価値があります。 MDA に関する情報は多数あります。最新の MDA Guide [OMG03] は、 OMG の Web サイトにあります。 また、いくつかの書籍 ([FRA03] や [KLE03]、 [MEL04] など) や、 多数の記事 (The MDA Journal 2004 年 5 月号「MDA マニフェスト (An MDA Manifesto)」。Grady Booch、Alan Brown、Sridhar Iyengar、 James Rumbaugh、Bran Selic 共著など) も発表されています。

MDA の中心概念 ページの先頭へ

MDA には、いくつかの特有の概念と用語が取り入れられています。 これにより、MDD に対するより一般的なアプローチと MDA とが区別されます。

既存の標準に基づく作成ページの先頭へ

MDA は、以下に示す既存の OMG 標準が基礎になっています。

  • メタオブジェクト・ファシリティー (MOF) - MOF は、メタモデル作成用の 言語 (UML や CWM など) を定義するほかに、モデルおよびメタモデルの リポジトリーを実装するフレームワークを定義します。これにより、MDA を使用する際に、 一貫した方法でこれらのモデルを操作できます。 したがって、MOF は MDA に欠かせないテクノロジーとなっています。
  • 統一モデリング言語 (UML) - UML には、PIMPM、および PSM が定義されています。 UML は、MDA の基本的な表記法です。
  • XML Metadata Interchange (XMI) - XMI は、XML に基づいて UML モデル交換形式を定義します。
  • Common Warehouse Metamodel (CWM) - UML はアプリケーション・モデリングに対するものですが、 CWM はデータ・モデリングに対するものです。

プラットフォーム非依存性ページの先頭へ

プラットフォーム の直感的な概念は、 サービスの規定を通じてより高いアーキテクチャー層をサポートし、 実装の詳細を隠す明確に定義された一連のインターフェースを提供するというものです。 OMG のプラットフォームに対する定義 (MDA Guide による) は、以下のとおりです。

「インターフェースを通じて一貫した機能セットを提供する一連のサブシステム/テクノロジー、 およびプラットフォーム提供機能の実装方法の詳細を気にせずにプラットフォーム依存のサブシステムで 使用できる指定された使用パターン。」

これは、RUP で使用されている の概念と似ています。

プラットフォーム非依存性 の概念は、やや曖昧としています。 これは、モデルの特質または特性であって、例えば、モデルが特定のプラットフォームから独立していると言えるのは、 そのプラットフォームが提供するサービスや機能への参照がモデルに一切含まれないときであるということにもなるでしょう。 しかし、プラットフォーム非依存性の絶対的な形式を予想することは難しいので、この説明は相対的なものになります。 MDA Guide はこれを承認するとともに、特定のプラットフォーム (例えば、特定プラットフォームの一般的な機能が モデルによって使用されているようなプラットフォーム) に関しては、 プラットフォーム非依存性の段階の可能性を認めています 。

プラットフォーム非依存性の達成は、J2EE、.NET、および WebSphere などのプラットフォームの発展に支えられており、 アプリケーションに提供されるものの点で抽象化のレベルが増しています。 これにより、プラットフォームに依存しない構造の識別が一層に容易になり、 それらを変換するプラットフォーム固有の変換機構は、作成が非常に単純で簡単になります。

プラットフォーム非依存性モデル (PIM) ページの先頭へ

特定のプラットフォームに関してモデルが PIM であると言えるのは、モデルがそのプラットフォームの使用に縛られず、 また、モデルがそのタイプのどのプラットフォームとも一緒に使用できる場合です。 前のセクションでは、高レベルの抽象化の概念について説明し、次のような結論に至りました。それは、 ベンダー依存要素を含まない UML (または UML プロファイルを使用して) で表現されるモデルは、 特定のインフラストラクチャー・プラットフォームに依存せず、構造内で意味的に完結するということ、また、 特定の手続き型言語に依存しない振る舞いは、少なくとも概念的には実行可能であり、高レベルの抽象化であるということです。 こうしたモデル・プラットフォームは独立しているのでしょうか? そうであるとも、そうでないとも言えます。 おそらく架空の UML 仮想マシンに関してはそうでないと言えますし、そのような仮想マシンが依存する プラットフォームの全クラスに関してはそうであると言えます。

プラットフォーム・モデルページの先頭へ

プラットフォーム・モデルは、特定のプラットフォームを使用する際にアプリケーションで必要となる 概念 (パーツとサービスを表現する)、仕様、インターフェース定義、制約定義、およびその他の要件の集合です。 MDA では、プラットフォーム・モデルは UML で詳述化および形式化され、例えば、MOF 準拠のリポジトリー内で 使用可能になります。 例えば、プラットフォーム・モデルは、J2EE や .NET に対して構築することが可能です。

プラットフォーム固有モデル (PSM)ページの先頭へ

PIM は、情報を追加することにより 1 つ以上の PSM に変換されます (この情報は、 PIM を特定のプラットフォームに固有のものにする情報です)。 PIM と PSM は、依然として同じシステムを規定しますが、PSM は特定のテクノロジーに拘束され、 プラットフォーム固有の要素を含む場合があります。 変換ステップ (PIM から PSM、または関連するプラットフォームへの) が大きいか小さいかという意味は存在しないことに 注意してください。 小さなパターン・セットのアプリケーションを含む変換は、モデルを洗練し、ある意味でモデルをより特定的にします。 これにより、用語 PIM と PSM の相対性が強調されます。

視点およびビューページの先頭へ

これらの用語は、MDD の場合と同じように MDA で使用されます。

  • 視点は、その名前が示すように概念的な位置のことです。システムに関する 特定の側面や関係は、視点から見ることができます。 視点は、概念的フィルターを形成する一連の概念と規則からなるアプリケーションを意味します。 システムに関する一部の情報が隠されると、視点は抽象化の形式になります。 観点 という用語が同様に使用されます。
  • 視点からビュー を見ることができます。ビューはモデルの射影であり、 関連するエンティティーをその視点から示します。

MDA は、計算非依存の視点、プラットフォーム非依存の視点、およびプラットフォーム固有の視点という 3 つの視点を システム上で規定します。

計算非依存の視点ページの先頭へ

計算非依存の視点からは、システムのコンテキスト、システムが動作する要件と制約、 およびシステムが対話する必要のある環境内の要素を確認できます。 システムの構造や振る舞いの詳細は、この視点からは見えません。

計算非依存モデル (CIM) は、計算非依存の視点からのシステムまたは将来のシステムのビューです。 概念上、CIM は、RUP のドメイン・モデルとユース・ケース・モデルの組み合わせに似ています。 RUP のドメイン・モデルは、ビジネス用語集およびビジネス分析モデルを含む一連の成果物であり、 『ワークフローの詳細: ドメイン・モデルの作成 (ビジネス・モデリングにおける)』からの出力です。 ユース・ケース・モデルは、システムの振る舞いに関する計算非依存の記述です。 CIM は、将来のシステムの主要な抽象化に関する分析と設計の最中、主題またはドメインの専門家の言語で表現され、 識別内の重要なリンクになります。

プラットフォーム非依存の視点ページの先頭へ

プラットフォーム非依存の視点は、特定のプラットフォームに対して相対的なものです。 この視点からは、そのプラットフォームの詳細を除く、システムの構造と振る舞いを見ることができます。 PIM は、プラットフォーム非依存の視点からのシステムのビューとなります。

プラットフォーム固有の視点ページの先頭へ

プラットフォーム固有の視点 (特定のプラットフォームに対して相対的でもある) からは、 プラットフォーム非依存の視点から見えたものを見ることができますが、現在は、 プラットフォーム使用の詳細が見えるようになっています。 PSM は、プラットフォーム固有の視点からのシステムのビューとなります。

変換の自動化ページの先頭へ

変換の概念は MDA の基本であり、モデル変換は単に 「同じシステム上で、あるモデルを別のモデルに変換するプロセス」 と定義されています。 また MDA は、変換を視覚化し、これまで取り上げた用語の一部の使用を示す小さなパターンを定義します。

MDA パターン。PIM とその他の情報を変換への入力として、PSM と変換のレコードを出力として示しています。

MDA パターン

図の目的は、変換が最重要項目であることを示すことです。 変換では、PIM とその他の情報が取得され、それらを結合して PSM が生成されます。

モデル変換は、もちろん手動で行うこともできます。 これは、ソフトウェア設計を進行する方法とほとんど変わりません。 ここでも、MDA は、変換の概念、プロセス、および使用する追加情報を記述および形式化するのに役立ちます。 また MDA では、変換のレコードを作成することを勧めています。このレコードには PIM 要素から PSM 要素へのマップが 含まれるので、PIM から PSM への強力な追跡可能性が得られるようになります。 たとえ、高水準言語によるアセンブラー・プログラミングを置き換えることで同じ利点が部分的にでも得られるとしても、 最大の利点は、変換を自動化できるということから得られます。

変換の実行方法 ページの先頭へ

MDA は、変換の実行方法を 1 つだけ規定しているのではありません。 プラットフォームでの PIM から PSM への変換方法の指定を得るために、 プラットフォームの選択に基づくマッピングが用意されています。このマッピングにより、 変換定義 (一連の変換規則で表現される場合もある) が作成され、 場合によっては、変換定義言語で作成された変換パラメーターが提供されます。 OMG は、RFP (MOF 2.0 クエリー/ビュー/変換 RFP) を発行しました。これは、 言語を標準化し (MOF において)、モデル・ビューの作成、モデルのクエリー、および変換定義の作成を行うことを期待してのことです。 MDA Guide には、変換アプローチがいくつか記述されています。

  • メタモデル変換 - このアプローチは、PIM を作成する言語内に PIM レベルの MOF メタモデルがあることを想定しています。 同様に、選択したプラットフォームにおいて、PSM を作成する可能性のある言語内に PSM レベルのメタモデル があることも想定しています。 この 2 つのメタモデル間のマッピングを使用すると、変換定義を作成でき、 これを使用して PIM が PSM に変換されます。
  • マーキング - 選択したプラットフォームに対するマッピングが用意されています。 このマッピングを使用すると、PIM 要素のマークに使用する一連のマークを含む変換定義が作成されます。 また、このマッピングによって、「マーク付けされた PIM」、およびこのようにマーク付けされた要素の処理内容の定義 が生成されます。 次に、マーク付けされた PIM はさらに変換され、PSM が生成されます。 通常、マーク付けは手動のプロセスですが、後続の変換は自動化できます。
  • モデル変換 - PIM は、プラットフォーム非依存性タイプを使用して作成されます。 また、PIM 内の要素がプラットフォーム非依存性タイプのサブタイプであるようなモデル内で指定されます。 一連のプラットフォーム固有タイプに関連付けられた特定のプラットフォームが選択されます。 マッピングは、2 つのタイプ・セット間で作成されます。 これにより、PIM に適用される変換定義が生成され、 プラットフォーム固有タイプのサブタイプで表現される PSM が作成されます。 このアプローチは、メタモデル変換とある程度似ています。異なる点は、 変換が、MOF メタモデルからの概念ではなく、モデル内のタイプに制限されることです。
  • パターン・アプリケーション - PIM は、プラットフォーム非依存の一連のタイプと抽象化パターンを使用して作成されます。 選択されたプラットフォームには、一連のプラットフォーム固有のタイプとパターンが存在します。 マッピングは 2 つのタイプおよびパターン・セット間で行われ、これにより、PIM に適用する変換定義が得られます。 これによって、抽象化パターンがプラットフォーム固有である PSM が作成されます。

詳細については、MDA Guide [OMG03] を参照してください。

変換の適用方法ページの先頭へ

MDA のアプリケーションの最も単純なシナリオを以下に示します。

  1. PIM を作成します。
  2. プラットフォームを選択します。
  3. まだ存在しない場合は、マッピングを作成します。
  4. 変換を適用し、PSM を作成します。
  5. PSM をコードに変換します。PSM をこれ以上洗練する必要がなく、直接実装できる場合は、 次のセクションで説明するように、これが実装になります。

別のプラットフォームの PSM も同様の方法で生成できます。

MDA パターンの繰り返しアプリケーション

MDA パターンは繰り返しアプリケーションに適していますが、生成されるあるレベルの PSM は、 次のより専門化されたプラットフォーム選択における PIM になります。 RUP で記述し、IBM Rational ツール・セットでサポートする MDD では、洗練ステップの回数を最小化することが優先されます。 つまり、顧客の問題の説明に近い表現から、できるだけ直接、実行可能な形式に進むことが望まれます。

MDA パターンの 3 つのアプリケーションを示しています。最初の PIM は、プラットフォーム 1 に依存する PSM になります。次にこの PIM は、再変換されてプラットフォーム 2 にも依存するようになります。さらにこの PIM は変換されて、プラットフォーム 1、2、3 に依存するようになります。

MDA パターンの繰り返しアプリケーション

一般的なモデル間変換

同じ概念を、一般的な変換、つまり、任意のモデルから任意のモデルへの変換に適用できます。 例えば、モデルを表現するために使用する言語を持つメタモデルが 2 つ存在する場合は、 原則として、マッピングを作成することができ、変換定義が生成されます。 これは、PIM から PSM への変換ですでに説明した方法で適用されます。

実装ページの先頭へ

MDA Guide では、RUP の実装モデルと同じような方法で「実装」を使用しています。 これは、システムを作成、導入、インストール、および運用するのに必要な すべての実装要素の仕様です。

PSM は、それ自体が実装になる場合もあれば、コードに変換する前にさらに洗練が必要になる場合もあります。 実装 PSM の作成では、PSM の表現ステップを省略し、直接コードに進むことができます。 この場合、より抽象的な PIM は、変換エンジンによって直接コードに変換できます。 理解の助けにするために、コードの視覚化は依然として開発者に提供することができますが、 これはコードからリバース・エンジニアリングすることが可能です。

考えられる利点ページの先頭へ

移植性および相互運用性ページの先頭へ

MDA では、比較的安定した一連の PIM を、必要なすべての新テクノロジーに再提供できるようにしているので、 テクノロジーの変動に対する費用と混乱を抑制できる望みがあります。 MDA の採用が増えれば、変換を迅速に実行できるように、新しいテクノロジーの開発者がマッピングを提供する ことも期待されます。

MDA で提案していることは、2 つのプラットフォームに対する PIM-PSM マッピングを拡張し、 2 つの PSM 間、最終的には 2 つの実装間に「ブリッジ」を作成して、PIM をプラットフォーム全体に 配布できるようにすることです。 新旧のテクノロジーが混在する異機種環境で、開発の現実に直面している企業は非常に多いので、 相互運用性を実現するこの機能により、非常に大きな利点が得られる可能性があります。

ライフサイクル・コストの削減ページの先頭へ

生産性ページの先頭へ

MDA を使用した開発の中心は、より抽象的な PIM になっています。 PSM (またはコード) を生成する強力なツール・セットを使用すると、 高水準言語で作業の生産性が向上するのと同じような方法で、そのような環境の生産性が向上するはずです。 アセンブラーでの作業 (特に PIM などの場合) は、 どうにか開発されることが多くなります (例えば、RUP の設計モデルとして機能)。 変換プロセスで手動介入の必要性をどれだけ減らせるかということが、生産性向上の重要な鍵となります。

品質ページの先頭へ

MDA では、保守の対象を PIM にするのが理想的です。 したがって、PIM の設計が適切であるという条件があれば、人間が介入する機会がほとんどないので、 製品の存続期間における問題点は少なくなります。また、自動変換の利点により、 発見された問題の修正コストも低減されます。 また、PIM への専念は、ドメインの問題と緊密な関わりがあるので、 ユーザーのニーズを満たす可能性がより高くなるはずです。

Rational Unified Process   2003.06.15