UMLメタモデル仕様とOCL制約に基づくUMLモデル検証環境の生成 大阪大学 浜口 優，長井 栄吾，松下 誠，岡野 浩三， 楠本 真二，井上 克郎 NTTデータ 我妻 智之，梅村 晃広 2007/10/20 ESS2007

概要 仕様の変更に柔軟に対応可能なUMLモデル検証環境を自動生成する手法を提案 クラス図とシーケンス図間の整合性検証に適用して実験的に評価 支援ツールを作成 生成するUMLモデルと制約を管理 クラス図とシーケンス図間の整合性検証に適用して実験的に評価 概要を述べます。 仕様の変更に柔軟に対応可能なUMLモデル検証環境を自動生成する 手法を提案しました。モデル駆動型開発を支援するフレームワーク を用いてUMLモデル検証環境のソースコードを自動生成しました。 また、生成するUMLモデルと制約を管理するために支援ツール を作成しました。 予備実験としてクラス図とシーケンス図間の整合性検証に適用して 実験的に評価しました。 ESS2007 2007/10/20

⇒ UMLダイヤグラム間の整合性を保つことが必要 研究背景 モデル駆動開発（Model-Driven Development, MDD） 対象に関する知識を「モデル」に変換して行うソフトウェア開発手法 UML（Unified Modeling Language） オブジェクト指向システム開発における表記法 工程３ 工程２ 修正・ 詳細化 修正・ 詳細化 工程１ モデル駆動開発MDDは対象に関する知識を「モデル」に変換して 行うソフトウェア開発手法です。近年、オブジェクト指向システム 開発における表記法であるUMLの普及に伴い、注目を集めています。 MDDで一般的に用いられるUMLダイアグラムは工程を進める毎に 修正・詳細化されていきます。クラス図のみであったUMLモデルに シーケンス図など様々な種類のUMLダイアグラムが追加されて いきます。しかし、この各工程間で不整合が発生することがあります。 また複数の視点から複数のダイアグラムを記述するので各ダイアグラム は完全に独立していません。工程内でも不整合は発生することがあります。 従ってUMLダイアグラム間の整合性を保つことが必要です。 今回私はb.の工程内における不整合に着目しています。 b．　複数の視点から複数の図を記述 　　　（完全に独立していない） 　　⇒　工程内で不整合が発生 a．　各工程において、修正・詳細化 ⇒　工程間で不整合が発生 ⇒　UMLダイヤグラム間の整合性を保つことが必要 ESS2007 2007/10/20

不整合の例 クラス図とシーケンス図間の不整合例 ビデオオンデマンド（VOD）システム[1] 不整合１： 不整合２： 呼び出し先メソッドが存在しない 不整合２： メッセージの方向と関連が不一致 不整合の例について紹介します。図はビデオオンデマンドシステムの クラス図とシーケンス図です。クラス図で記述している各クラスが どのようなやり取りをするのかを記述しているのが下のシーケンス図 になります。したがってクラス図とシーケンス図には密接な関係 があります。 しかしこのダイアグラムは２つの不整合を含んでいます。 １つめは呼び出し先メソッドが存在しない不整合です。 DisplayクラスのオブジェクトdispはStreamerクラスのオブジェクトstに Connect()メソッドを呼び出していますが、Streamerクラスに Connect()メソッドは存在しません。 ２つめはメッセージの方向と関連の不一致です。Streamerクラスから Displayクラスに対して関連が引かれているのに、シーケンス図では dispからstの各メソッドを呼び出しています。これは関連の方向を 逆にしなければなりません。 [1] A. Egyed, Fixing Inconsistencies in UML Design Models, In Proc. of ICSE2007 ESS2007 2007/10/20

既存研究 UMLモデルの仕様に対して整合性ルールを付加して検証 UMLメタモデル 利点 整合性ルールにOCL制約式を利用 USE，OCLE　etc.. 整合性ルールに独自の制約式を利用 UML/Analyzer　etc.. 仕様 整合性ルール UMLメタモデル インスタンス化 インスタンス化 既存研究ではいくつかのツールがUMLモデルの仕様、 つまりUMLメタモデルに対して整合性ルールを付加 することで検証を行っています。UMLメタモデルに 対して整合性ルールを付加することでインスタンス化された UMLモデルに対して整合性検証が可能になります。 整合性ルールにはOCL制約式や独自の制約式を利用しています。 利点は同一仕様に基づく任意のUMLモデルに対して整合性検証 が可能な点です。 次にUMLメタモデルとOCLについて紹介します。 検証処理系 UMLモデルA UMLモデルB 利点 同一仕様に基づく任意のUMLモデルに対して整合性検証が可能 ESS2007 2007/10/20

簡略化したUML メタモデル（クラス図に関係する部分） UMLについてのUMLモデル M3 MOF インスタンス化 モデル要素 名前 M2 UMLメタモデル インスタンス化 * 特徴 分類子 M1 UMLモデル インスタンス化 UMLメタモデルとはUMLについてのUMLモデルです。 左の図が簡略化したUMLメタモデルの一部で、クラス図 のクラスについて定義しています。この図からクラスは 分類子を継承し、名前、属性、操作を持つことが分かります。 右の図はUMLのメタモデル4層です。UMLは４つの階層のモデル によって定義されます。最上位のMOFモデルがUMLメタモデル を定義し、UMLメタモデルがUMLモデルを定義し、UMLモデル がユーザオブジェクトを定義しています。 属性 操作 インターフェイス クラス M0 ユーザオブジェクト 簡略化したUML メタモデル（クラス図に関係する部分） UMLのメタモデル4層 ESS2007 2007/10/20

OCL（Object Constraint Language） UMLモデル内のモデル要素に対して制約を与えるために導入された制約記述言語 クラスの詳細仕様を決定 第一階述語論理に基づく 論理式　(真ならば制約を満たす) context ClassA inv: self.name = ‘client’ OCL式記述例 OCL式 インスタンス化 インスタンス クラス OCL（Object Constraint Language）はUMLモデル内のモデル要素 に対して制約を与えるために導入された制約記述言語です。 クラスの詳細仕様を決定します。第一階述語論理に基づき 論理式で表され、真ならば制約を満たすことになります。 下の図のようにクラスにOCL式を付加し、クラスのインスタンスに 対してOCL式の記述通りの動作でなくてはならないことを保証します。 右の図はOCL式の表記例です。クラスAのname属性はclientで なくてはならないという不変式になっています。 不変表明 事前事後条件 派生属性値の設定 etc…. OCL式の記述通りの動作 ESS2007 2007/10/20

既存研究の問題点 既存研究ではUMLメタモデルの変更に対応できない 頻繁なバージョンチェンジを行うUMLメタモデルに逐一対応する必要あり UMLメタモデルB 変更不可 UMLメタモデルA 整合性ルール 整合性 ルール 変更不可 UMLメタモデルC インスタンス化 インスタンス化 既存研究を調べた結果、UMLメタモデルの変更に対応できないという 問題点があることが分かりました。UMLメタモデルには複数のバージョンが 存在し、バージョンチェンジも頻繁に行われます。したがって既存研究 ではツール内で逐一対応する必要があります。また、以前のバージョン のUMLメタモデルからインスタンス化されたUMLダイアグラムのような 過去の設計資産の再利用も困難になります。また、同様にドメインに 特化したUMLメタモデルにも対応することができません。 整合性 ルール 検証処理系 UMLモデルA UMLモデルB ESS2007 2007/10/20

研究内容 本研究の目的 UMLメタモデルの変更に柔軟に対応した UMLダイアグラム間整合性検証環境の生成 変更可 変更可 UMLモデルA ルール 整合性ルール UML メタモデルB 変更可 インスタンス化 インスタンス化 これまでの内容を踏まえて、本研究の目的は UMLメタモデルの変更に柔軟に対応した UMLダイアグラム間整合性検証環境の生成です。 任意のUMLメタモデルを用いて検証を行うことが できる検証システムを考案します。 整合性 ルール UML メタモデルC 検証処理系 UMLモデルA UMLモデルB ESS2007 2007/10/20

方針 研究目的を達成するために必要な機能 既存のモデリングフレームワークを応用 UMLメタモデルの編集機能 UMLモデルの編集機能 検証処理系 既存のモデリングフレームワークを応用 EMF（Eclipse Modeling Framework）を応用 UMLモデル階層とEMFモデル階層の対応付け …EMF …EMFT_OCL ここで研究目的を達成するために必要な機能について 整理します。大きく分けてUMLメタモデルの編集機能と 対応したUMLモデルの編集機能とそのUMLモデルに対する 検証処理系が必要になります。 そこで本研究では、既存のモデリングフレームワークを 応用できないかと考えました。で、モデリングフレームワーク の１つであるEMFを応用し、UMLモデル階層とEMFモデル階層の 対応付けを行うことを考案しました。上記２つに関してはEMFが 編集機能を提供し、検証処理系に関してはEMFに付属する EMFT_OCLプラグインにより提供されることになります。 詳細は後程述べます。 ESS2007 2007/10/20

EMF（Eclipse Modeling Framework） モデル記述とコード生成のためのフレームワーク モデル駆動型アーキテクチャ（MDA）をサポート M2 Essential MOF MDAに基づいて、Ecoreモデルからモデルのインスタンス編集環境をコード生成 インスタンス化 Ecoreモデル（PIM） M1 自動変換 XMI形式に基づく木構造で管理 インスタンス インスタンス間の関連 木構造に基づくユーザインターフェース EMFモデル（PSM） インスタンス化 コード生成 EMF（Eclipse Modeling Framework）はモデル記述とコード 生成のためのフレームワークです。モデル駆動型アーキテクチャ （MDA）をサポートしています。 このMDAに基づいて、Ecoreモデルからモデルのインスタンス 編集環境を自動でコード生成します。生成されたインスタンス 編集環境ではインスタンスやインスタンス間の関連をXMI形式に 基づく木構造で管理し、そのユーザインターフェイスを提供 しています。EMFもUMLと同様に右の図のようにメタモデル階層 が存在します。EMOFモデルがEcoreモデルを定義し、Ecoreモデル からEMFモデルへの自動変換を行った後、EMFモデルからモデル のインスタンス編集環境のソースコードを自動生成することができます。 要するにEcoreモデルをメタモデルとしたXMI形式に基づく木構造の モデルエディタを作成することができるということです。 モデルの インスタンス編集環境 M0 EMFのメタモデル3層 ⇒　Ecoreモデルをメタモデルとした木構造のモデルエディタを生成可能 ESS2007 2007/10/20

EMFT-OCL EMFT-OCL (EMF Technology-OCL) OCL 制約の検証 インスタンスは OCL 制約 また、EMFにはEMFT-OCLプラグインがあり、OCL制約の検証を サポートしています。EMFモデルにOCL式を追加することで、 先程のモデルのインスタンス編集環境においてインスタンスがOCL制約 を満たしているのかどうかを検証することができます。 インスタンスは OCL 制約 を満たしているのか？ EMFモデル ESS2007 2007/10/20

提案手法 UMLモデル階層とEMFモデル階層の対応付け M3 M2 M1 M0 Ecore、EMFモデルとUMLメタモデルを対応させれば検証可能 Essential MOF M3 MOF インスタンス化 インスタンス化 M2 Ecoreモデル（PIM） UMLメタモデル 自動変換 EMFモデル（PSM） インスタンス化 OCL式 インスタンス化 コード生成 よってこれらから、提案手法ではUMLモデル階層とEMFモデル階層 の対応付けを行うことにしました。Ecore、EMFモデルとUMLメタモデルを 対応させることで、EMF上でUMLモデルエディタがコード生成されます。 また、UMLメタモデルと対応するEcore、EMFモデル に対してOCL制約式を付加することで、UMLモデルエディタ においてEMFT_OCLプラグインによるOCL式を用いた 検証が可能になります。 モデルの インスタンス編集環境 M1 UMLモデル インスタンス化 EMFT_OCL によりOCL式を用いた検証が可能 M0 ユーザオブジェクト ESS2007 2007/10/20

提案する検証システムの概要 M2 M1 検証結果出力 EMF EMFT_OCL UMLメタモデル 入力 入力 整合性ルール (OCL式) UMLメタモデルと整合性ルールをEMFの入力として与え、UMLモデル検証環境を自動生成する EMF EMFT_OCL Ecoreモデルエディタ UMLメタモデル 入力 入力 整合性ルール (OCL式) Ecoreモデル M2 自動変換 EMFモデル コード生成 記述 そして提案する検証システムの概要は以下の通りになります。 EMFにUMLメタモデルと整合性ルールを記述したOCL式を入力として与えます。 そしてEcoreモデルが生成され、EcoreモデルはEMFモデルに自動変換され、 EMFモデルからインスタンス化されたUMLモデル検証環境が自動生成されます。 自動生成されたUMLモデル検証環境において各UMLモデルを記述し、 整合性ルールを検証することが可能になります。 この四角で囲まれた部分が検証システム提供者の仕事で、それ以外 が検証者の仕事になります。 記述 M1 整合性検証 記述 検証結果出力 UMLモデル検証環境 ESS2007 2007/10/20

⇒ 必要な全クラスと関連を持つクラスをEcoreモデルに追加する 検証システム実現の問題点 インスタンス編集環境はパッケージ毎に生成 クラスのインスタンスをルートとして木構造で管理 ルートと関連を持たないクラスはインスタンス化できない Ecoreモデル Root B A M2 V T U Ｓ r1:Root s1:S XMI形式 UMLモデル検証環境構築には複数パッケージ内のクラスが必要 互いに関連を持たないクラスどうしも存在 u1:U <s1> <u1>…</u1> <t1>…</t1> <tn>…</tn> </s1> <r1> <s1>…</s1> <u1>…</u1> <t1>…</t1> <tn>…</tn> <v1>…</v1> </r1> M1 t1:T v1:V しかし、この検証システムを実装するにあたり、EMFの仕様が 原因で発生する問題点がありました。 EMFの仕様では、右の図のようにインスタンス編集環境がEcoreモデル内 のパッケージ毎に生成されます。そして、そのパッケージ内の１クラス のインスタンスをルートとして木構造で管理することになります。 また、ルートと関連を持たないクラスはインスタンス化することが できません。（例紹介） しかし、UMLモデル検証環境構築には複数パッケージ内のクラスが 必要になります。当然それらには互いに関連を持たないクラスどうしも 存在します。したがって今のままでは適切にUMLモデル検証環境を 構築することができません。 そこで、構築に必要な全クラスと関連を持つクラスをEcoreモデルに 追加することにしました。必要な全クラスと関連を持つRootクラス を追加し、Rootクラスのインスタンスをルートとすることで、全ての クラスインスタンスを生成することが可能になります。 Aモデル インスタンス編集環境 tn:T 構築できない ⇒　必要な全クラスと関連を持つクラスをEcoreモデルに追加する ESS2007 2007/10/20

検証システム実現のためのプラグイン Ecoreモデルエディタの拡張 プラグインによる自動化 プラグイン 導入 Ecoreモデル Root mainパッケージ作成 各UMLダイアグラムに必要なUMLメタモデル要素を包含 プラグイン 導入 Ecoreモデル Root main A B インスタンス化 インスタンス化 インスタンス化 EMFモデル 一連の作業を支援するためにEcoreモデルエディタを拡張しました。 プラグインによってRootクラスを含むmainパッケージがEcoreモデルに 作成され、Rootクラスは各UMLダイアグラムに必要なUMLメタモデル要素 を包含します。mainパッケージから生成されるmainモデル検証環境では 適切に各UMLダイアグラムを編集することが可能になります。 また、各UMLダイアグラムに必要なUMLメタモデル要素は UMLの仕様書から特定しました。 Aモデル 検証環境 Bモデル 検証環境 Mainモデル 検証環境 UMLモデル検証環境 ESS2007 2007/10/20

プラグインのUI インスタンス化するUMLダイアグラムの選択 UMLメタモデルに付加するOCL式の編集 OCL式リスト UMLダイアグラム 選択部分 OCL式 編集部分 図：プラグインのUI ESS2007 2007/10/20

プラグインの出力結果 Mainパッケージ作成 Rootクラス作成 選択したUMLダイアグラムに必要なUMLメタモデルを包含 編集したOCL式を付加 main パッケージ Rootクラス OCL式に対応した関数 図はプラグインの出力が反映されたEcoreモデルです。 mainパッケージが作成され、Rootクラスが作成されます。 Rootクラスは選択したUMLダイアグラムの構築に必要な UMLメタモデルを包含します。構築に必要なUMLメタモデル内の モデル要素はUMLの仕様書から特定しました。 そして編集したOCL式もRootクラスに付加します。 UMLダイアグラムを構築するUMLメタモデルの包含関係 図：Ecoreモデル ESS2007 2007/10/20

Mainモデル検証環境 Rootクラスを起点としてツリー構造のエディタで編集 図：検証結果例 図：Mainモデル検証環境 ESS2007 2007/10/20

実験 目的 入力 UMLモデル検証環境で記述するUMLダイアグラム 実験環境 提案手法がUMLダイアグラム間整合性検証に可能かどうか評価 文献のクラス図とシーケンス図間に関する整合性ルール（10個）[2] UMLモデル検証環境で記述するUMLダイアグラム クラス図とシーケンス図 実験環境 OS ：　Windows Vista Business CPU ： Intel（R） Core（TM） 2 CPU 1.87GHz Memory : 2.0GB RAM Eclipse ver : 3.2.0 EMF ver : 2.2.0 uml::interactions::basicinteractions::Lifeline.allInstances()->forAll(l | uml::classes::kernel::Class.allInstances() ->select(oclIsTypeOf(uml::classes::kernel::Class))->collect(Name) ->includesAll(l->collect(Name)) ) おこなった実験について述べます。目的は提案手法がUMLダイアグラム間 整合性検証が可能かどうかの評価です。 入力はUMLバージョン2.0のメタモデルと、カールトン大学で提案されている クラス図とシーケンス図間に関する10個のルールです。 UMLモデル検証環境で記述するUMLダイアグラムはクラス図とシーケンス図です。 図は整合性ルールのOCL式表記例です。意味はシーケンス図内の各オブジェクト は必ずクラス図で定義されていなければならないという制約です。このような OCL式が10個存在します。実験環境は以下のようになります。 図：整合性ルールのOCL式表記例 [2] L. C. Briand, Y. Labiche and L. O'Sullivan, Impact Analysis and Change Management of UML Models, Technical Report SCE-03-01, Carleton University, 2003 ESS2007 2007/10/20

実験設定 M2 M1 検証結果出力 EMF EMFT_OCL UML2.0メタモデル 入力 入力 整合性ルール (OCL式) Ecoreモデルエディタ UML2.0メタモデル 入力 入力 整合性ルール (OCL式) Ecoreモデル M2 自動変換 EMFモデル コード生成 記述 検証システムと対応させると以下のようになります。 M1 クラス図 検証結果出力 整合性検証 記述 UMLモデル検証環境 シーケンス図 ESS2007 2007/10/20

調査した産業用UMLモデル2つにおいて、引くべき関連のうち約70％が忘れられていた[4] 適用例題　概要 DrinkMakerに関するクラス図、シーケンス図 これらのダイアグラム中に、UMLダイアグラムで最もよく起こるとされる不整合である「関連の引き忘れ」がある[3] 調査した産業用UMLモデル2つにおいて、引くべき関連のうち約70％が忘れられていた[4] １．関連のないクラスのオブジェクト間で 　　メッセージのやりとりをしている ２．メッセージが未定義 適用した例題はDrinkMakerに関するクラス図とシーケンス図です。 DrinkMakerはコーヒーや紅茶などの飲料を作るシステムです。 これらのダイアグラム中にはUMLダイアグラムで最もよく起こる とされる不整合である関連の引き忘れをあります。 具体的には、関連のないクラスのオブジェクト間でメッセージの やりとりをしているというものとメッセージが未定義であると いうものです。 [3] K. Ludwik and S. Miroslaw, Inconsistencies in Student Designs, In Proc. of Workshop on Consistency Problems in UML-based Software Development, 2003 [4] C. Lange, M. R. V. Chaudron, J. Muskens , L. J. Somers and H. M. Dortmans, An Empirical Investigation in Quantifying Inconsistency and Incompleteness of UML Designs, In Proc. of Workshop on Consistency Problems in UML-based Software Development, 2003 ESS2007 2007/10/20

不整合の検出 違反検出 違反が出力されなくなった １．関連のないクラスのオブジェクト間で メッセージのやりとりをしてはいけない cd DMaker DrinkMixer - chosenDrink: int + setChosenDrink(Drink) : void prepareDrink() : void Coffee {leaf} Cocoa Drink addWater(Water) : void addPowder(IngredientPortion) : void Tea cd DMaker 違反が出力されなくなった DrinkMaker Container IngredientPortion + chooseDrink(int) : void + insertCoin(CoinValue) : void + getIngredient() : IngredientPortion + prepareDrink() : void + returnCoin(CoinValue) : void TeaPowder CoffeePowder CoinSlot DrinkRecipe Watertank DrinkMixer - toPay: int - chosenDrink: int + price: int + getWater() : Water + validate(CoinValue) : void + setPrice(int) : void + setChosenDrink(Drink) : void + prepareDrink() : void CoinContainer Water - totalAmount: int Drink これがドリンクメーカーのクラス図とシーケンス図です。 この赤く囲まれた部分を利用します。このクラス図は 赤い部分にあるはずの関連と継承がありません。また シーケンス図の方には関連がないはずのオブジェクト間 でメッセージを送っています。ここで検証を行った結果、 関連のないクラスのオブジェクト間のメッセージ のやりとりをしてはいけないという整合性ルールと メッセージが未定義ではいけないという 整合性ルールに違反していることを検出できました。 これらを修正し、再度検証を行ったところ違反が 出力されなくなり、適用例題での検証は成功する ことができました。 + addWater(Water) : void + addPowder(IngredientPortion) : void １．関連のないクラスのオブジェクト間で 　　メッセージのやりとりをしてはいけない Coin CoinValue + value: CoinValue Cocoa Coffee {leaf} {leaf} Tea ２．メッセージが未定義ではいけない ESS2007 2007/10/20

考察と評価 提案手法によりUMLダイアグラム間整合性検証は可能 別の種類のUMLダイアグラム間に対しても検証可能だと考えられる DrinkMaker例題に対する10個の整合性ルールの検証に成功 OCL式で整合性ルールを記述することが可能 別の種類のUMLダイアグラム間に対しても検証可能だと考えられる クラス図とシーケンス図間の制約と同様にOCL式を記述可能 クラス図とステートマシン図　etc… しかし、OCL式で記述できない整合性ルールも存在した 事前事後条件は不変表明を妨げない 集約リンクの有向パス中にサイクルはない etc… 考察と評価です。提案手法によりUMLダイアグラム間整合性検証は可能 だと考えます。適用例題で述べた整合性ルール以外に対しても評価実験を 行い、10個の整合性ルールをOCL式で記述し、検証することに成功しました。 別の種類のUMLダイアグラム間に対しても検証可能だと考えます。 クラス図とシーケンス図間の制約と同様にOCL式を記述可能であれば、 クラス図とステートマシン図などの整合性ルールも検証可能だと考えます。 しかし、クラス図とシーケンス図間に関する制約以外の制約の中には OCL式で記述できない整合性ルールも存在しました。 ESS2007 2007/10/20

まとめと今後の課題 UMLメタモデルとOCL制約を用いてUMLモデル検証環境を構築する手法を提案 今後の課題 EMFを利用して検証環境のソースコードを自動生成する ツールを作成し、作業の効率化を図る クラス図とシーケンス図間に関する例題に適用 今後の課題 UML2.0以外のバージョンを用いた場合の評価実験 他の例題への適用 別の種類のUMLダイアグラム間整合性検証 ESS2007 2007/10/20