モデル駆動型開発(MDD)とアプローチについて探る

この記事では、モデル駆動型開発(MDD: model-driven development)について、業界における関連動向と比較しながら学びます。具体的には、ソフトウェア・ファクトリーやドメイン固有言語、そしてMDDの手法を比較します。また、開発成果物をモデルとして可視化する方法や、実行可能なUML(Unified Modeling Language)といった手法を使いモデルを直接実行する方法について学びましょう。

Tracy Gardner (tgardner@uk.ibm.com), ), Solution Architect, IBM

Author1 photoTracy Gardner博士は、イギリスにあるIBM Software Group ServicesのSolution Architectであり、モデル駆動型開発に関して5年以上の業界経験があります。彼女はモデル駆動型開発に関して精力的に執筆や後援を行ってきました。University of Bathにてソフトウェア・エンジニアリングの博士を取得しています。連絡先はttgardner@uk.ibm.comです。



Larry Yusuf (yusuf@uk.ibm.com), Solution Architect, IBM

Author2 photoLarry Yusufは、イギリスのHursley LabsにあるSoftware Group Strategy and TechnologyのSolution Designerです。ビジネス統合とモデリングに関して4年間の経験があり、主にビジネス・プロセス管理や、イベントやソリューションの管理、統合パターンなどに取り組んできました。また、こうした話題に関して積極的に記事を執筆し、講演を行ってきました。連絡先はyusuf@uk.ibm.comです。



2006年 3月 14日

はじめに

これまで2本の関連記事の中で、MDD手法によってビジネス価値を高めることができること、またソフトウェア・ソリューションのアーキテクチャーの整合性を改善できることを学びました。

この記事では、業界で起きつつある関連した他の動きと比較しながらMDDを解説します。また、業界の標準化団体であるOMG(Object Management Group)がMDDに関して果たす役割について学び、ソフトウェア・ファクトリーによる手法とMDDとを比較します。さらに、開発成果物をモデルとして可視化するための方法や、実行可能なUMLの手法を使ってモデルを直接実行する方法を検証します。

モデル駆動型開発を要約する

MDDでは、モデルは単なるスケッチや設計図ではなく、変換を適用することによって効率的な実装を生成する元となる主要な成果物として使われます。またMDDで新しいソフトウェア・コンポーネントを開発する際には、主にアプリケーション・ドメイン指向モデルに注目します。コードやその他のターゲット・ドメイン成果物は、モデリングのエキスパートとターゲット・ドメインのエキスパートの両方から入力を得て設計される変換を使って生成されます。


OMGとモデル駆動アーキテクチャー

OMGはオープンな協議会として、エンタープライズ・アプリケーション領域でのインターオペラビリティーのための標準を作成しています。OMGは、MDDの中心であるUML(Unified Modeling Language)に責任を持ち、またMDA(model-driven architecture)も推進しています。MDAは、MDDの手法(例えばRationalソフトウェアが長年推進してきた手法など)を正式なものにしたものです。OMGが定義している通り、MDAはエンタープライズ・アーキテクチャーを整理し、管理するための方法であり、自動化されたツールやサービスでは、モデルを定義するために、そして様々なタイプのモデル間での変換を行うために、MDAをサポートしています。

多くの場合、MDAとMDDという言葉は置き換え可能なものとして使われます。この記事では、MDDはソフトウェア開発者が行うアクティビティーを指します。MDAはOMGによる正式な定義のままとし、MDDを行うための正式なフレームワークの構築に焦点を絞っています。OMGのMDAガイドによると、MDAの主な目的は下記の3つです。

  • 移植性
  • インターオペラビリティー
  • 再利用性

MDAのゴールは、こうした目的を、システムのオペレーション仕様と特定プラットフォームでのシステム実現方法の詳細とを分離することによって実現することです。下記のような課題にMDAを活用することにより、こうした目的をツールによって満足することができます。

  • プラットフォームと独立にシステムを規定する
  • プラットフォームを規定する
  • システム用のプラットフォームを選択する
  • システム仕様を、ある特定のプラットフォーム用の仕様に変換する

『プラットフォーム』という概念は、OMGのMDAの中心です。プラットフォームは、(その実装方法の詳細は無視して)アプリケーションに使用可能な一連のサブシステムや技術によって、インターフェースと使用パターンを実現したものです。

MDAモデル

MDAでは下記の3種類のモデルを定義しています。

CIM(Computation-independent model: コンピュータに依存しないモデル)
CIMは、システムと、システムが使用されるビジネス・コンテキストに対する要求を記述します。このモデルは通常、システムを何に使うかを記述しますが、どのように実装するかは記述しません。CIMは多くの場合、ビジネス固有、あるいはドメイン固有の言語によって記述され、またITシステムが、ビジネス・コンテキストの一部である場合には、ITシステムの使い方に関して、ごく僅かしか触れません。
PIM(Platform-independent model: プラットフォームに依存しないモデル)
PIMは、システムの構築方法を記述しますが、モデルの実装に使われる技術には触れません。このモデルは、特定のプラットフォームに対するソリューションを構築するための機構は記述しません。PIMは、特定のプラットフォームによって実装する場合、あるいは多くのプラットフォームでの実装にも適切かも知れません。
PSM(Platform-specific model: プラットフォームに依存したモデル)
PSMは、ある特定のプラットフォームで見た場合のソリューションを記述します。このモデルには、CIMの実装方法の詳細や、その実装を特定のプラットフォームで実現するための方法の詳細が含まれます。

PIMからPSMへの変換はMDAの心臓部分です。同じシステムの中で行われる、1つのモデルから別のモデルへの変換プロセスは『モデル変換(model transformation)』と言われます。図1は、(場合によっては追加情報を加えた)PIMからPSMへの変換を示しています。

図1. PIMからPSMへの変換
Transformation of a PIM to a PSM

MDAでは、こうしたモデルを固定した階層としては扱いませんが、PIMとPSMが階層化できること、またそれぞれのモデルが、より抽象的なモデルではPIMであり、より具象的なモデルではPSMであることを説明します。例えば、上位レベルの設計モデルを使うこともできれば、詳細な設計モデルを使うこともでき、MDAパターンが2つ登場する実装モデルを使うこともできます。それぞれのレベルにおいて、実装プラットフォームに関する想定を、さらに進めることができます。上位レベルの設計モデルという意味では、詳細な設計モデルはPIMであり、実装モデルという意味ではPSMです。

MDAコミュニティーでは、PIMを最初に非コードのPSMに変換してからコードに変換すべきか、あるいは直接PIMからコードを生成する(つまりPSMがコードである)ことが許されるかに関して、大きな議論があります。J2EE(Java™ 2 Platform, Enterprise Edition)やJavaプラットフォームで作業する場合、RSA(Rational Software Architect)はコード成果物をUMLダイヤグラムとして可視化します。この機能によって、余分なレベルの変換を避けつつ、プラットフォーム成果物を可視化することができます。この記事では、アプリケーションをPIMとしてモデル化した後、こうしたモデルをPSMに変換します。そうすると、これらは実装成果物として直接キャプチャーされます。

ここで説明しているものの大部分は、他のモデリング階層間での遷移に関しても有効です。例えばRUP(Rational Unified Process)に従う場合、最初に分析モデルで始め、それを設計モデルのアウトラインに変換することができます。また、WebSphere Business Modelerモデルを、ソフトウェア開発用の仕様として動作するPIMに変換することもできます。Rational Software Architectはそうした変換を持っており、WebSphere Business Modelerモデルをインポートすることができます。

IBMとMDA

ホワイトペーパー「An MDA Manifesto」では、MDAに対するIBMのビジョンが述べられています。このホワイトペーパーでは、MDAの基本的な考え方として、3つを挙げています。これを図2図3に示します。

図2. MDAの基本的な3つの考え方
Three basic tenets of MDA

直接表現(direct representation)、自動化(automation)、そしてオープン・スタンダードは、モデル駆動手法の中核をなすものです。

図3. MDA manifestoに述べられた基本的な考え方(IBMによる)
Basic tenets of the MDA manifesto (IBM)

ソフトウェア・ファクトリーとドメイン固有言語

DSL(domain-specific language)は、特定な問題領域用に開発されたソフトウェア開発言語です。DSLの例としては、表計算マクロやデータベース・クエリー言語などがあります。DSLはソフトウェア業界で長い歴史を持つものですが、Microsoft®によるソフトウェア・ファクトリーの動きの一部として、最近注目を集めています。

ソフトウェア・ファクトリーは、次のように定義することができます。

Visual Studio Team Systemのような拡張可能な開発ツールを、特定の種類のアプリケーションを開発するための処方に基づいて、DSLやパターン、フレームワーク、ガイダンスなど、パッケージ化されたコンテンツとコンフィギュレーションするための一連のソフトウェア製品。例えばソフトウェア・ファクトリーを、.NET® frameworkやC#、the Microsoft Business Framework、Microsoft SQL ServerそしてMicrosoft Host Integration Serverなどを使ったシン・クライアントCRM(customer relationship management)アプリケーションに対して設定することができます。このファクトリーを装備することによって、それぞれ特定な顧客のユニークな要求に基づくユニークな特徴を持つCRMアプリケーションを、限りなく多種類、迅速に作り出すことができます。もっと良いことに、このファクトリーを使えば1つのエコシステムを作ることができ、それをサードパーティーが利用できるようにすれば、彼らはそれを拡張して自分たちの価値を付加した拡張を組み込み、迅速にCRMアプリケーションを構築することができます。

MDDの手法とソフトウェア・ファクトリーの手法は驚くほど似ています。どちらの手法もアプリケーション・ドメインの概念を対象にしており、ソフトウェア・ライフサイクルに自動化を導入しています。どちらの手法も、視覚的なモデリングと、パターンによって専門性をとらえることの重要性を強調しています。両者の主な違いは、オープン・スタンダード、特にUMLをいかに重視するかにあります。

ソフトウェア・ファクトリーについて学ぶために、参考文献を見てください。

MDDの手法でDSLを作成する場合には、特定な使い方に対してUMLを拡張、あるいは制限するために、UMLプロファイルを導入しています。例えば、ソフトウェア・サービス(SOA)や、テスティング、モデリングなどに対するUMLプロファイルがあります。

UMLとDSL

多くの場合、UMLの役割は、あまりにも単純な言い方で表現されているようです。つまり、MDDはドメイン固有のモデリングには必ずUMLを使うのだと主張し、一方ソフトウェア・ファクトリーではUMLは決して使うべきではないと主張している、というような言い方です。どちらの手法に対しても、そうした言い方は正しくありません。

MDDの手法では、大部分のアプリケーション・モデリングにおいて選択すべきモデリング言語として、(場合によってはカスタム化した)UMLを扱いますが、同時に、ある特別な状況ではカスタム言語の価値も認めています。OMGのMOF(Meta-Object Facility)標準が目的としているのは、正にこれです。この標準は、MDDで重要な役割を果たします。UMLそのものはMOFを使って定義されており、また他の様々な言語に対するMOF定義もあります。MDDでは非UMLのDSLの価値も認めており、単に注意して適用すべきだ、と言っているだけなのです。

一方ソフトウェア・ファクトリーも、完全にUMLを拒否しているわけではありません。スケッチやドキュメンテーションの開発にはUMLを使うようにと示唆する一方、コード生成の元となるモデルの開発には非UMLのDSLを使うべきだと言っているのです。

表1を見ると分かるように、DSLの基礎としてUMLを使うことに対しては、有利な点と不利な点があるのです。

表1. DSLとしてUMLを使うことに対する有利な点と不利な点
有利な点不利な点
UMLはオープン・スタンダードのモデリング言語であり、様々な本やトレーニング・コースがあります。UMLは、ソフトウェア開発者が業界で提示できるスキルとして認められています。UMLプロファイルで許されるカスタム化の量は限られています。既存のUML要素を拡張することで表現できるもの以外は、新たなモデリング概念を導入することはできません。例えばUMLは、電気の回路図を設計するためのDSLの基礎としては適切ではありません。
UMLプロファイルは、既存のUMLツールを使って容易に実装可能な、軽量の手法です。将来はDSL用のツールを生成することもできるかも知れませんが、その場合でも、恐らく幾らかのカスタム化が必要でしょう。UMLを使用するためには、モデリングの概念に慣れていることが必要です。ドメインの専門家がコード生成のための知識を持っている場合もあるかも知れませんが、その人たちも、そうした概念を、UMLを使って表現する力は持っていないかも知れません。
UMLプロファイルを適用したモデルは、どんなUMLツールでも(たとえツールがプロファイルの知識を持っていなくても)読むことができます。ただし、プロファイルによって導入された拡張は無視される場合があります。 
すべてのDSLの基礎をUMLにすることによって、概念を共有する一連の関連した言語を作ることができます。こうすることによって、新しいプロファイルでも理解しやすくなり、異なるDSLを使って表現されたモデルであっても容易に統合することができます。一連のモデルが、異なるDSLを使って表現されていると、ミドルウェア統合の問題がモデリング・レベルで再現することになります。これは当然ながら望ましくありません。 
UMLは上位レベルのアーキテクチャー・モデルにも使用でき、コード生成の元となり得る詳細なモデルにも使用できます。UMLによって、ソフトウェア・ライフサイクル全体が一貫性を持つため、ユーザーは大まかなレベルでのモデリングから細かなレベルでのモデリングへと、継ぎ目なく移動することができます。スケッチやドキュメンテーションのみにUMLを使ってしまうと、この、一貫性の利点が失われることになります。 

UMLは多くのDSLの基礎として適切ですが、場合によってはMDDプロセスの一部に対して別の方法が必要です。UMLの代わりに、あるいはUMLに加えて、次のような手法も使うことができます。

MOFベース言語
カスタム言語が適切な場合には、MOFを使って新しい言語を定義します。Rational Software Architectに含まれているオープンソースのコンポーネント、Eclipse Modeling Frameworkは、MOFで定義された言語を扱うためのJava実装を生成し、またその言語でのモデルのインスタンスを作成するための、基本的なEclipseツールを生成します。

恐らく将来は、完全にグラフィカルなエディターの生成が可能になるでしょう。この手法は、Rational Software Architectがサポートする多くの言語(UMLやXSDなど)を実装するために使用される手法です。この手法を使う場合には、その言語が、同じソリューション・コンテキストに使用されているUMLやUMLではない他のDSLと統合されていることを確認してください。

カスタム・ユーザー・インターフェース

一部ユーザーの専門性を生かすためには、視覚的なモデリング手法は適当ではないかも知れません。そうした場合には、手順を追ったガイドを備え、カスタムのグラフィック要素を持ったカスタム・ツールの方が、モデルの構築には適切かも知れません。当然ながらコストが高くなりますが、適切に使えば有効な手法です。

既存フォーマットからの変換

MDDツールの連携を駆動するために必要な情報は、既存ツールの中に既に入っているかも知れません。そうしたツールとしては、別のソフトウェア・モデリング・ツールの場合もあり、ビジネス・モデリング・ツールの場合もあり、あるいはMicrosoft Excelのようなデスクトップ・ツールであるかも知れません。アクセス可能な情報であれば、どんな情報でもUMLモデルに変換することができます。特に既存の資産に対しては、同じ情報を手動でモデリングするよりも、既存のツールを使って生成すべきです。


可視化

『可視化(visualization)』は、実装成果物をUMLモデルとして見るための手法です。こうしたモデルはプラットフォーム専用ですが、アプリケーション全体のアーキテクチャーを見えにくくしがちな実装の詳細の一部を隠すことができます。

Rational Software Architectでは、JavaやJ2EEの成果物を可視化することができます。この作業モードは、コード中心の手法を使いつつモデリングの利点を生かすための方法の1つです。可視化を使用する場合には、コードが主要成果物であり、モデルはコードから生成されます。モデルは永続的ではなく(ただしモデルのレイアウト情報は永続的です)、単にコードを可視化したものにすぎません。図4は、単純なJ2EEプロジェクトと、それに対応するUMLを可視化したものを示しています

図4. エンティティーbeanの可視化
Visualization of an Entity Bean

モデルはコードから生成されますが、モデルからコードを生成することはできません。可視化された成果物のモデル(モデルは多くの場合、メモリー中にあります)が利用でき、従って成果物のテキスト表現を構文解析する必要がない場合には、可視化は容易です。その一例は、MDDツールの連携の中に非UMLのモデルを使う場合です。

可視化によって、モデル駆動手法の利点を生かすことができます。

  • 実装の詳細の一部を隠すことができ、システムを設計レベルで見ることができます。
  • UMLモデルとコードの同期を保つことができ、ドキュメンテーションと実装との間のミスマッチを避けることができます。

可視化は貴重なものですが、非常に限定された方法で抽象化レベルを上げるにすぎません。可視化を使用する場合には、そのプラットフォームがサポートしている概念詳細を隠すことしかできません。モデル駆動型開発に可視化を使うための方法として、主に次の2つがあります。

  • 可視化によって、MDDに一歩近づくことができます。可視化そのものによる直接的な利点の他に、可視化によって開発者がUMLモデリングに慣れることができます。それによってMDDへの移行が容易になります。
  • 可視化は、プラットフォーム専用のUMLモデルで作業する場合に有効です。つまり可視化によって、アプリケーション・モデルと実装成果物との間に中間的な実装モデルを持たずにコードを直接生成できる一方、実装モデルの可視化という利点は相変わらず生かすことができます。

実行可能なUML

実行可能なUMLと言っても、実行セマンティクスを持つUMLを意味するわけではありません。(確かにUMLには実行セマンティクスがありますが、一部の領域では強化、正式化が必要であり、UML 2.0ではこうしたセマンティクスが大幅に改善されています。)通常、実行可能なUMLは、UMLを完全なプログラミング言語として、つまり単に上位レベルのセマンティクスを表現するだけではなく、完全な実行可能モデルを表現するものとして扱う場合に登場します。そうしたモデルは、UML仮想マシン上で実行されるか、あるいは下位レベルのプログラミング言語へとコンパイルすることによって実行されます。

実行可能なUMLに代わるもの、そして現在MDDで一般的に行われているのは、下位レベルのプログラミング言語に切り換えて詳細を埋める方法です。実行可能なUMLには、開発者が複数の言語(UMLと、ターゲット言語(複数の場合もあります)の両方)を学ばないで済むという利点があります。開発やデバッグはすべて、モデリング・レベルで行われます。

UMLでは、詳細なセマンティクスを、アクションやアクティビティーによって表現することができます。しかし、こうした構成体のために用意されているのは視覚的な表記のみです。一般的には、詳細なセマンティクス(数学的なアルゴリズムやテキスト処理など)をとらえるにはテキスト言語の方が効率的である、と言われています。

実行可能なUMLに関して詳しくは、参考文献を見てください。

アクション用のテキスト表記を含めて、幾つかの実行可能なUML言語が定義されています。またOMGでは現在、実行可能なUMLに関する標準が開発されつつあります。

この手法をさらに変形させたものとして、下位レベルのプログラミング言語の断片をUMLモデルに埋め込む方法があります。Rational Technical Developerツール(これまでのRational Rose Real-Time)では、この手法をとっており、実行可能なUMLモデルにJavaあるいはC++断片を埋め込んでいます。


まとめ

この記事では、OMGでのMDAに関する動きについて、MDDの考え方を正式なものとするために、そしてこの手法をサポートする標準の実現に向けて、何が行われているかを学びました。また、『MDD』という用語についても検証しました。MDDは広い意味で、OMGで開発中の正式なMDAと一致する開発手法です。

またMDDは、Microsoftのソフトウェア・ファクトリーや、ドメイン固有言語など、他の動きとも多くの面で共通しています。こうした手法の間には重要な違い(例えば標準がMDDに対して持つ重要性など)がありますが、類似面もまた多いのです。

既存の成果物をUMLとして可視化することは、UMLの手法を採用する上での一歩です。可視化によってモデル駆動型開発の利点は一部実現できますが、実現できるものはごく限定的です。

実行可能なUMLの手法は、開発を完全にモデリング・レベルにまで高めます。この手法は一部領域において成功していますが、幅広く採用されるまでには至っていません。

参考文献

学ぶために

  • ITシステムのビジネス価値を向上させるためのモデル駆動型開発の実装(developerWorks, 2006年1月)は関連の記事として、現在のIT開発に影響を与えているビジネス上の動機を説明し、またMDDを紹介しています。
  • Rational Unified Processの詳細について学んでください。
  • Applications with Patterns, Models, Frameworks, and Tools』(GreenfieldとShort、Cook、Kent、Crupiの共著、2004年8月、John Wiley & Sons刊、ISBN 0-471-20284-3)を読んでください。
  • 『Model-Driven Architecture with Executable UML』(RaistrickとFrancis、Wright、Carter、Wilkieの共著、2004年3月、Cambridge University Press刊、ISBN 0-521-53771-1)を読んでください。
  • 実行可能なUMLに関して、Stephen MellorとMarc Balcer共著による『A Foundation for Model-Driven Architecture』(2002年5月、Addison Wesley刊、ISBN 0-201-74804-5)を読んでください。
  • MDA Journalの記事、An MDA Manifestoは、継続して行われている議論の一部であり、IBMのMDAビジョンを反映しています。
  • IBM Redbook、「Patterns: Model-Driven Development Using IBM Rational Software Architect」を読んでください。
  • 無料のdeveloperWorks technical events and Webcastsを利用して最新技術を学び、皆さんのスキルと知識の向上に役立ててください。

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Sample IT projects, Rational
ArticleID=250178
ArticleTitle=モデル駆動型開発(MDD)とアプローチについて探る
publish-date=03142006