連載第13-1回
UMLの基礎と応用

(株)NTTデータ 技術開発本部 副本部長
山本修一郎

 UML1がOMGによって1997年に標準化されてから5年が経ち、今年UML2が標準化される予定だったが来年に持ち越されるようだ。表1にUMLのこれまでの標準化の経緯を示した。CACMの11月号ではUMLが進退を決断すべき十字路に直面しているということでUML2の提案者らによる紙上討論の形で、各提案の特徴が紹介されている[1][2][3][4][5][6]

表1 UML2の年表
表1 UML2の年表


 今回は代表的な5つのUML2提案の概要について述べ、それらを比較してみよう。

UML2

 OMGは2000年に52件のUML2に対する要件を提出した。この要件の中にはUML1からの移行する上での影響を最小化すること、オブジェクトとコネクタをモデル化すること複数の言語に対応すること、コード自動生成を可能にする実行可能モデル、言語仕様の厳密性と明解性などが含まれる。

 UML2には2001年に次の5件が提案されている(表2)。

表2 UML2提案
表2 UML2提案

(1)U2P UML2.0 Partners
 Selic, Ramackers, Kobtynが提案者。UML2はUML1を発展させるべきで革命的な変更はすべきではないと主張している。ラショナル社のセリク氏はリアルタイムオブジェクト指向方法論ROOM(Real-time Object Oriented Methodology)の提案者である。

(2)DSTC
 DSTC(Distributed Systems Technology Center)社のDuddyが提案。UML1のプロファイルを用いた拡張機構の代わりに新しくファーストクラスMOF(Meta Object Facility)の拡張機構を導入することにより、現状では互換性のないCWM、EAI、EDOCなどの言語を統一的に記述する。MOFは図1に示すようにUMLのメタデータを記述するための言語である。MOFはM3層に属する。UMLの各図式を定めるためのモデルはM2層に属する。M2層で規定された各図式モデルはM1層に属する。

(3)2U(Unambiguous UML)
 Mellorらが提案しているが、ブレーンにはpreciseUMLの理論家グループ(www.puml.org)がついている。実行可能で変換可能な小規模なUMLカーネルとパターン合成方式の一つであるモデルマージ機構によりUMLを階層的に定義する。モデルマージ機構は、パラメータを持つパッケージ・テンプレートと、名前ベースで再帰的なユニフィケーションができるパッケージ・ジェネラライゼーション機構からなる。

 もしモデルが実行可能でコードに変換できるとしたら実現できるはずのモデルシミュレータやトランスレータなどからなるMDAツールを持つ。MDAツール間で統一的な意味を与えることを主張している。

 ここでMDAについて少し説明しておこう。OMGはMDA(Model Driven Architecture)を2001年に採用した。MDAはOMGのオブジェクト管理アーキテクチャーOMA(Object Management Architecture)やオープン分散処理参照モデル(RM-ODP,Reference Model of Open Distributed Processing)などと同じ開発標準のフレームワークである。

 MDAでは、プラットフォームに依存しないモデルPIM(Platform Independent Model)と、プラットフォームに依存するPSM(Platform Specific Model)がある。PSMでは自動的にコードを生成できるように詳細な情報を記述する。まずプラットフォーム独立なUMLモデルPIMを作成しておき、MDAコンパイラを用いてPIMからPSMに変換する。UML2ではこのようなMDAの考え方にも沿った形で仕様を策定する必要がある。

(4)3C(Clear,Clean,Concise)UML
 FrankとTysonが提案。まず公理的方法により小規模な概念を明確に定義し、次いで厳密な定義と不変式を用いてUMLを規定する。

(5)OPM(Object Process Methodology)
 Doriが提案。必要なモデリング概念を1つの図式で統一している。以下ではこれらのUML2 提案の特徴について説明する。

U2P

 U2Pでは抽象的なコア概念を組み合わせることでUML1と異なる言語にするのではなく、UML1を発展的に拡張しMDAを実現する。表3に示すように次のような特徴がある。

表3 U2Pの概要
表3 U2Pの概要

(1)正確な定義
 MDAを実現するために各UML概念の意味を正確に再定義する。

(2)意味基盤の統合
 意味基盤自体の正確性。基本的なUML抽象としてのクラス、関連、インスタンス抽象コア概念を組み合わせて複合的な概念要素を作成する。

(3)分野向き標準言語
 問題分野向きモデリング言語をMOFで定義するためにUMLを再構成する。

(4)言語拡張方式
 プロファイルにより分野ごとにUML を拡張するだけでなく、全体から必要な部分だけを利用できるような拡張された言語を分割する機能を提供する。

(5)スケーラビリティ
 複雑なシステムに適用するため、再帰的なコンポーネント記述や階層的な振舞いの記述を導入する。

(6)形式的図式構文
 形式的な図式構文を用いてUMLの各図式を生成する。

(7)移行支援
UML1からの移行支援系を定義する。

DSTC

 DuddyはUMLのプロファイルによる言語拡張機構をメタモデルを用いたUMLの拡張には次のような問題があると指摘している。

 たとえばCWM(Common Warehouse Metamodel)ではUMLで定義されたクラスのモデルに相当するモデルを平行して作成している。EAI(Enterprise Application Integration)用のUMLプロファイルはメッセージベースのアプリケーション統合をモデル化する言語だが、UMLのメタモデルを再利用せずに独自のメタモデルを作成してしまっている。これに対してEDOC(Enterprise Distributed Object Computing)のUMLプロファイルではコンポーネント指向のイベントおよびプロセス駆動のアプリケーションを設計するためのメタモデル概念を作成している。またCORBAインタフェース定義言語を定義するUMLプロファイルの定義も洗練されていないし特殊なツールがないと使えない。

 このため次のような共通概念をデータ型、パターン、コンポーネントライブラリとともに再利用する必要があるとしている。

ネーミング:命名された要素と名前空間
構造:コンテナ、ポート、コネクタ、関係
再利用:継承、リネーミング、オーバライディング、合成
洗練:変換のための関係、具象化、ライフサイクル

 また、UML2でより良い結果を出すための唯一の方法は既存のメタモデルであるCWM、EAI 、EDOCをUML2のメタモデルのテストケースとして用いることである。

 図1に示したように、UMLの特徴の一つは高階概念モデリング言語であることだ。メタ言語としてUMLカーネルは目的指向のモデリング言語で明瞭に概念を表現できる必要がある。またMOFは拡張可能なフレームワークであり、プラットフォームに依存することなく定義や操作だけでなくメタデータもデータと統合できる。これによりMOFによりツールやアプリケーション、データを統合できる。これらを理由としてDSTCではUMLカーネルの表現力はMOFと同等であり、UMLカーネルとMOFコアを統一することを提案している。

図1 MOFメタデータアーキテクチャー
図1 MOFメタデータアーキテクチャー

 具体的には以下の7項目についてUML1のメタモデルを改善している(表4)。

表4 DSTCの概要
表4 DSTCの概要

(1)Whole-part関係
 アグリゲーションとコンポジション関係の代わりにWhole-part関係のメタタイプを定義している。

(2)責務(Responsibility)
 ステレオタイプのコメントで定義する代わりにメタクラスで定義している。

(3)依存関係
 関係に関するメタモデルを全体的に見直し階層的に整理している。

(4)型、クラス、インタフェース
 型、クラス、インタフェースに関するメタモデルの誤りをサブタイプの概念に沿うように修正している。

(5)一般化
 一般化とインプリメンテーション継承を継承のサブタイプとなるようにメタモデルを修正している。

(6)ステレオタイプ
 ステレオタイプをモデルレベルで記述するのではなく、メタモデルのサブタイプとして定義している。

(7)空間的な包含関係
 パッケージの中のパッケージを表す包含関係を便宜的な表記方法としてではなく、明確な関係として定義している。

NEXT >> 

・連載第1回

・連載第2回

・連載第3回

・連載第4回

・連載第5回

・連載第6回

・連載第7回

・連載第8回

・連載第9回

・連載第10回

・連載第11回

・連載第12回

・連載第13回

・連載第14回

・連載第15回

・連載第16回

・連載第17回