連載第13－２回
UMLの基礎と応用

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

■2U
　2Uでは小さな良く定義された実行可能かつ変換可能なUMLカーネルを定義しておき、モデルの意味を明確化し、一連のMDAツール群によりモデル作成を効率化する。2Uのモデル変換方式を図２に示す。まず、ソフトウェア構造に関する記述を含まない抽象的なソリューションだけをPIM （Platform Independent Model）で記述する。次いで機構上の判断を決定し、選択したプラットフォームに対応するMDAモデルコンパイラを用いてPSM（Platform Specific Model）に変換する。ここで機構の例としては、RPC（Remote Procedure Call）、関数呼出、インライン展開などがある。どの機構を用いるかはソフトウェア構造に依存した判断であるので抽象的なソリューションでは記述しない。


図2　2Uのモデル変換

　2UのMDAツール体系を表5に示す。ここで重要なことは、モデルの意味を統一することで、ツール間で意味情報を相互交換できることだ。現在でも、類似する個別のUMLツールがあるが、形式的な変換しかできないことや、個別のアダプタが必要となるなどの問題がある。意味を統一する例として実行（Execution）のサブタイプとして、メソッド呼出し（Method Invocation）と状態遷移（Transition）を定義できることを示す。


表5　2UのMDAツール体系

　Executionにはトリガー、入力データ、制御入力があり、次のいずれかのときにExecutionが実行される。すなわち、トリガーが発生したとき、すべての入力データと制御入力が揃ったとき、条件変数の集合に対して指定された条件が成立したときである。メソッド呼出しは、トリガーを通常のコール（Call）とし、入力データをコール引数、制御入力や条件変数がないようなExecutionである。同様にして、状態遷移は、トリガーを状態遷移機械のイベント（event）とし、入力データをイベントに付随するデータ、条件変数が状態遷移機械の状態から与えられ、制御入力がないようなExecutionである。

　このようにして異なる図式で出現する記述に対して統一的な意味を定義することができるのである。

■3C
　3Cでは、幾何学や物理学などの科学的な方法を応用することにより、まず基本的なモデリング概念の集合を確立して、そこからUML全体を再構築することを提案している。UML1では144 もの異なる概念要素があるのに対して、3Cコアには以下に示す15の基本概念しかない。

・Individual-Objects,Actions,Associations
・Abstraction-Combination,View
・Type
・Specification
・Role
・Template
・Time
・Place
・Possibility
・Change

　これらの基本概念から、属性、振舞い、クラス、ユースケース、インタフェース、コラボレーション、プロセス、アクティビティ、データフローなどの概念を定義する。

　たとえば個人（Individual）は、青写真の扉が建物の扉を示しているのと同じように、システムの中で観察される具体的な現象を示すモデリング概念である。個人はオブジェクト、アクション、アソシエーションに分類される。オブジェクトはシステム現象であってモデル作成者がある時間の中で安定しているとみなすものである場所を占めるものだ。たとえば、人、会社、自動化システム、プログラム、ソフトウェアオブジェクト、データベーステーブルなどがオブジェクトの例だ。アクションはあるシステムの中で観察される現象である。たとえば、ハードウェアノードにアプリケーションをインストールすることはアクションの例である。アクションはイベント自体を表していてイベントの記録はアクションではなく、オブジェクトになる。

　3Cでは仕様とモデル要素を区別することが重要だと指摘する。たとえば、青写真では「扉が樫である」というのは仕様であって、青写真の扉自身が樫であるのではない。ところがUMLでは、たとえば、「このユースケースは仕様である」という表現に見られるように、モデル要素が仕様であるというように規定されているという問題がある。

　このように3Cでは15個の基本概念から厳密にUML2を再定義している。

　また3Cではプログラムの詳細を表現するのではなく、上位言語を提供しておき、プログラミングに関する詳細を追加して、幾つかの変換を施すことによりソースコードを生成する。したがってUML が提供するソースコードを抽象化した上位概念により、ソースコードの詳細を隠蔽できる。

■OPM
　Dori氏はUMLの問題点として次の３点を挙げている。まず、複数の図式を用いているので、本来統合されていなくてはならない構造と振舞いとが分散して記述されてしまう。次に振舞いモデルが複数あるため混乱しやすい。さらに、図式の中でプログラミング言語の影響範囲が明確になっておらず不明瞭である。UMLはこれまでのオブジェクト指向手法を組み合わせたために構成概念が大きく複雑化していると指摘している。たとえばUMLには互いに重複する図式が9個もあり、語彙は150程度ある。この問題を解決するために、直交する概念から理論的に構築したオブジェクトプロセス方法論OPMを提案している。

　OPMの基本的な考え方は次のようになる。システムをオブジェクトの集合から構成し、オブジェクトはプロセスによって変換されると考える。プロセスはオブジェクトの状態を遷移させることにより、オブジェクトを生成、消費、出力する。このようにOPMは単一モデル原理に基づく非常に単純なモデルである。またOPMではプログラミング言語に依存した構文を排除して図式と１対１ に対応する自然言語によるオブジェクトプロセス言語OPL（Object Process Language）を生成する点にも特徴がある。たとえば、図３に示すWebサービスのライフサイクルを定義したOPM図を例にしてOPLとの関係を説明しよう。OPM図では矩形でオブジェクトを表す。オブジェクトの状態を矩形内の角が丸い矩形で表す。プロセスを楕円で表す。状態を起点とし終点がプロセスとなる白抜き矢印により、プロセスの実行の前提となる状態を表す。逆に、プロセスを起点とし終点が状態となる白抜き矢印により、プロセスの実行後の状態を表す。この図ではWebサービスとレジストリがオブジェクトである。Webサービスオブジェクトの状態は生成済、登録済、発見済であることから、図３の文１が導出できる。オブジェクト間の関係には「登録される」というラベルが付いていることから図３の文２が導出できる。図３の文３文４文５はプロセスの事前状態と事後状態の関係から導出される。このようにOPM図はプログラミング言語レベルの構文ではなく単純な図式と自然言語による説明ができる。


図3　トップレベルのオブジェクトプロセス図

　しかし、OPMはこれまでのUMLとはあまりにも異なるので、UML1からの移行性を考えるとUML2として適しているかどうかは疑問だとする声もあるだろう。

■まとめ
　本稿ではUML2への提案について紹介した。以上述べたことから、UML2の各提案を比較すると表６のようになるだろう。MDAを明確に意識したU2P、2U、3Cの間では共同検討が始まっているようである^[１]。


表6　UML2提案の比較

　UML2の提案を見てみると、現在のUML1にどのような問題があるのかが良くわかると同時に、UML1がソフトウェア開発分野で広く普及してきており、UML2への期待が高いこともわかる。ブルックスが人月の神話^[９]で指摘した「セカンドシステム症候群」にUML2が陥らないことを期待しよう。

　さて皆さんはどのUML2提案が採用されることになると想像されるだろうか？

参考文献
[１] Miller,J.,What UML should be,CACM.,Vol.45,No.11,pp.67-69,2002
[２] Selic,B.,Ramackers,G.and Kobryn C.,Evolution,not revolution,CACM.,Vol.45,No.11,pp.70-72 ,2002
[３] Duddy,K,UML 2 must enable a family of language,CACM.,Vol.45,No.11,pp.73-75,2002
[４] Mellor,S.,Make models be assets,CACM.,Vol.45 ,No.11,pp.76-78,2002
[５] Frank,W. and Tyson,K.,Be clear,clean,concise,CACM.,Vol.45 ,No.11 ,pp.79-81,2002
[６] Dori,D.,Why significant UML change is unlikely,CACM.,Vol.45,No.11,pp.82-85,2002
[７] Catalog of OMG Modeling and Metadata,http://www.omg.org/technology/documents/modeling_spec_catalog.htm
[８] UML関連仕様サイト,http://neptune.irit.fr/Biblio/uml_2 _0 .shtml
[９] ブルックス,人月の神話,ピアソンエデュケーション,1996
[10] 山田正樹,開発者からみたUML2.0の可能性,Specificationshttp://www.metabolics.co.jp/O
OTechnology/UMLForum 2002-UML2.pdf