UMLメタモデルの変更に対応した ダイアグラム間整合性検証環境の 自動生成手法 井上研究室 博士前期課程2年 浜口 優 タイトルは「UMLメタモデルの変更に対応した ダイアグラム間整合性検証環境の自動生成手法」 で井上研の浜口が発表させて頂きます．

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

研究背景 モデル駆動型開発（Model-Driven Development, MDD） UMLダイアグラム間の整合性を保つことが必要 対象に関する知識を「モデル」に変換して行うソフトウェア開発手法 UML（Unified Modeling Language） オブジェクト指向システム開発における表記法 複数の視点から複数の図を記述 不整合が発生する（例．名前要素の不一致 etc…） 工程3 工程2 不整合が発生 修正・ 詳細化 修正・ 詳細化 工程1 モデル駆動型開発MDDは対象に関する知識を「モデル」に変換して 行うソフトウェア開発手法です．近年，オブジェクト指向システム 開発における表記法であるUMLの普及に伴い，注目を集めています． MDDで一般的に用いられるUMLダイアグラムは工程を進める毎に 修正・詳細化されていきます．例えば，開発の初期段階では クラス図のみを作成し，開発に進行に伴ってシーケンス図など 様々な種類のUMLダイアグラムが追加されていきます． しかし，複数の視点から複数のUMLダイアグラムを記述するため， これら複数種類のUMLダイアグラムは相互に依存しています． 従って，UMLダイアグラム間で名前要素の不一致などの不整合 を起こす可能性があります． UMLダイアグラム間の整合性を保つことが必要になります． UMLダイアグラム間の整合性を保つことが必要 修士論文発表会 2008/2/15

既存研究 各々のUMLモデルに対して依存関係を解析して検証 UMLモデルの仕様に対して整合性ルールを付加して検証 UMLメタモデル あらかじめ用意された整合性ルールしか検証できない UMLモデルの仕様に対して整合性ルールを付加して検証 整合性ルールをOCL制約式などを用いて表現する 同じ仕様に基づく任意のUMLモデルに対して整合性検証が可能 UMLモデルの仕様 UMLメタモデル 整合性ルール インスタンス化 インスタンス化 既存研究では，各々のUMLモデルに対して依存関係を解析して検証 を行っている研究があります．しかしこの手法ではあらかじめツールに 組み込まれた整合性ルールしか検証できません．追加する場合は プログラムの修正が必要になります． 一方，UMLモデルの仕様に対して整合性ルールを付加して検証を 行っている研究があります． UMLモデルの仕様に基づいてUMLモデル を書いた，つまりインスタンス化したUMLモデルに対して整合性検証 を行っています． 整合性ルールには述語論理であるOCL制約式などを用いています． この制約式を追加・編集することで自由に整合性ルール を追加・編集できます．また，同じ仕様であれば，任意のUMLモデルに 対して整合性検証が可能です． そして，このUMLモデルの仕様のことをUMLメタモデルと言います． 次にUMLメタモデルについて紹介します． 検証処理系 検証ツール UMLモデルA UMLモデルB 修士論文発表会 2008/2/15

簡略化したUML メタモデル（クラス図に関係する部分） MOF インスタンス化 モデル要素 名前 M2 UMLメタモデル インスタンス化 * 特徴 分類子 M1 UMLモデル インスタンス化 UMLメタモデルとはUMLモデルの仕様で，UMLで記述されます． 左の図が簡略化したUMLメタモデルの一部で，クラス図 のクラスについて定義しています．この図からクラスは 分類子を継承し，名前，属性，操作を持つことが分かります． 右の図はUMLのメタモデル4層です．UMLは４つの階層のモデル によって定義されます．最上位のMOFモデルがUMLメタモデル を定義し，UMLメタモデルがUMLモデルを定義し，UMLモデル がユーザオブジェクトを定義しています． 属性 操作 インターフェイス クラス M0 ユーザオブジェクト 簡略化したUML メタモデル（クラス図に関係する部分） UMLのメタモデル4層 修士論文発表会 2008/2/15

既存研究の問題点 UMLメタモデルは変更される可能性がある 開発チームが使用しているUMLメタモデルが変更される UMLメタモデルV1に 対応した既存の検証ツール UMLメタモデルV2用に 作り直した検証ツール UMLメタモデルV1 UMLメタモデルV2 変更 ツールを 作り直して 検証 インスタンス化 インスタンス化 インスタンス化 インスタンス化 既存研究の問題点について述べます． UMLメタモデルは変更される可能性があります． 開発チームが使用しているUMLメタモデルが変更されたり， ドメインに特化したUMLメタモデルに拡張されることが あります． しかし，既存研究の手法では，変更されたUMLメタモデルに 従って，別途検証ツールを作り直して検証する必要があります． UMLメタモデルはバージョンチェンジや， 組込みシステム向けなどへの拡張が頻繁に行われます． 検証ツールを作り直す作業は負担が大きいです． 検証 UML モデルA 検証処理系 UML モデルB UML モデルC 検証処理系 UML モデルD 修士論文発表会 2008/2/15

本研究の目的 UMLメタモデルの変更に柔軟に対応できる UMLダイアグラム間整合性検証環境の生成手法の実現 自動生成 システム UMLメタモデルV1に 対応した既存の検証ツール UMLメタモデルV2に 基づいて生成した検証ツール 自動生成 システム UMLメタモデルV1 UMLメタモデルV2 生成 生成 インスタンス化 インスタンス化 インスタンス化 インスタンス化 これまでの内容を踏まえて，本研究の目的は UMLメタモデルの変更に柔軟に対応できる UMLダイアグラム間整合性検証環境の生成手法の実現です． なんらかの自動生成システムを用意し， 任意のUMLメタモデルに対応した検証ツールを生成することで 検証ツールを作り直す手間を省きます． 検証 検証 UML モデルA 検証処理系 UML モデルB UML モデルC 検証処理系 UML モデルD 修士論文発表会 2008/2/15

方針 自動生成システムに必要な機能 生成される検証ツールに必要な機能 既存のモデリングフレームワークを応用 UMLメタモデルの入力機能 検証処理系 既存のモデリングフレームワークを応用 EMF（Eclipse Modeling Framework）を応用 UMLメタモデル階層とEMFモデル階層の対応付け ここで研究目的を達成するために必要な機能について 整理します． 自動生成システムに必要な機能はUMLメタモデルの 入力機能と，そのUMLメタモデルに基づいて検証ツール を生成する機能です． 生成される検証ツールに必要な機能はUMLモデルの入力機能 とそのUMLモデルに対する検証処理系です． そこで本研究では、既存のモデリングフレームワークを 応用できないかと考えました．そして，モデリングフレームワーク の１つであるEMFを応用し，UMLメタモデル階層とEMFモデル階層の 対応付けを行うことを考案しました．詳細は後程述べます． 修士論文発表会 2008/2/15

EMF（Eclipse Modeling Framework） モデル記述とコード生成のためのフレームワーク モデルを入力することでモデルのインスタンス編集環境をコード生成 EMF Meta Level モデル M1 EMFモデル 入力 コード生成 記述 EMF（Eclipse Modeling Framework）はモデル記述とコード 生成のためのフレームワークです．ユーザがモデルを 入力することで，EMF内で独自の仕様であるEMFモデルに 変換され，それを基にモデルのインスタンス編集環境を 自動でコード生成してくれます． EMFもUMLと同様に右のようにメタモデル階層が存在します． 要するに入力したモデルをメタモデルとしたモデルエディタを 作成することができるということです． モデルの インスタンス編集環境 M0 ⇒入力したモデルをメタモデルとしたモデルエディタを生成可能 修士論文発表会 2008/2/15

提案手法 UMLメタモデル階層とEMFモデル階層の対応付け M3 M2 M1 M0 Essential MOF M3 MOF インスタンス化 インスタンス化 M2 UMLメタモデル 入力可能 EMFモデル インスタンス化 インスタンス化 コード生成 よってこれらから，提案手法ではUMLメタモデル階層とEMFモデル階層 の対応付けを行うことにしました．EMFモデルとUMLメタモデルの 階層を対応させることで，UMLメタモデルをEMFに入力することができ， UMLモデルのインスタンス編集環境，つまりUMLモデルエディタを 自動でコード生成することができます． モデルの インスタンス編集環境 M1 UMLモデル インスタンス化 M0 ユーザオブジェクト 修士論文発表会 2008/2/15

提案する検証システムの概要 UMLメタモデルと整合性ルールをEMFに入力し，UMLモデル検証環境を自動生成する M2 M1 EMF （OCL式） EMF UMLメタモデル Meta Level M2 EMFモデル 入力 コード生成 記述 そして提案する検証システムの概要は以下の通りになります． EMFにUMLメタモデルと整合性ルールを記述したOCL式を入力として与えます． そしてEMFモデルが生成され，EMFモデルからUMLモデル検証環境が 自動生成されます．自動生成されたUMLモデル検証環境において 各UMLモデルを記述し，整合性ルールを検証することが可能になります． M1 整合性検証 UMLモデル検証環境 検証結果出力 修士論文発表会 2008/2/15

実験概要 目的 異なるバージョンのUMLメタモデルであっても同様に整合性検証が可能かを評価 実験対象1 実験対象2 UML2.0メタモデル に基づくクラス図とシーケンス図間の整合性検証 UML2.1.1メタモデル に基づくクラス図とシーケンス図間の整合性検証 提案手法を評価するために実験を行いました． 実験の目的は異なるバージョンのUMLメタモデルであっても 同様に整合性検証が可能かどうかの評価です． 行った実験は2段階に分かれていて， 実験対象1の次に実験対象2を行いました． 実験対象1ではUML2.0メタモデルに基づいたクラス図と シーケンス図間の整合性検証を行います． 実験対象2ではUML2.1.1メタモデルに基づいたクラス図と 詳細は次に述べます． 修士論文発表会 2008/2/15

UMLダイアグラム間整合性検証が可能かどうか？ 実験対象1：バージョン2.0の整合性検証 入力 UML2.0メタモデル 文献のクラス図とシーケンス図間に関する整合性ルール（10個）[2] 記述するUMLダイアグラム クラス図とシーケンス図 整合性ルール （OCL式） UML2.0 メタモデル EMF EMFモデル M2 入力 UMLダイアグラム間整合性検証が可能かどうか？ コード生成 記述 実験対象1で与える入力は，UML2.0メタモデルと下記の文献の クラス図とシーケンス図間に関する整合性ルールの制約式です． 記述するUMLダイアグラムはクラス図とシーケンス図です． 実験対象1では，既存研究と同様にUMLダイアグラム間整合性検証 が可能かどうかを評価します． M1 整合性検証 検証結果出力 UMLモデル検証環境 [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 修士論文発表会 2008/2/15

整合性ルールの制約式はどのくらい実験対象1から再利用できるのか？ 実験対象2：バージョン2.1.1の整合性検証 入力 UML2.1.1メタモデル 実験対象1と同じ整合性ルール（10個）[2] 記述するUMLダイアグラム 実験対象1と同じ 整合性ルール （OCL式） UML2.1.1 メタモデル EMF EMFモデル M2 入力 実験対象1と同様に整合性検証が 可能かどうか？ 整合性ルールの制約式はどのくらい実験対象1から再利用できるのか？ コード生成 記述 実験対象2で与える入力は，UML2.1.1メタモデルと実験対象1と同じ 整合性ルールの制約式です．記述するUMLダイアグラムも 実験対象1と同じものです。 実験対象2では実験対象1と同様に整合性検証が可能かどうかと， 整合性ルールの制約式はどのくらい実験対象1から再利用できるのかを 評価します． M1 整合性検証 検証結果出力 UMLモデル検証環境 [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 修士論文発表会 2008/2/15

整合性検証例 違反検出 違反が出力されなくなった １．関連のないクラスのオブジェクト間で メッセージのやりとりをしてはいけない cd DMaker DrinkMixer - chosenDrink: int + setChosenDrink(Drink) : void prepareDrink() : void Coffee {leaf} Cocoa Drink addWater(Water) : void addPowder(IngredientPortion) : void Tea cｄ 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 Tea {leaf} {leaf} ２．メッセージが未定義ではいけない 修士論文発表会 2008/2/15

実験対象1，実験対象2，共に全ての整合性ルールに対して検証成功 実験結果 実験対象1 （UML2.0メタモデル） 実験対象2 （UML2.1.1メタモデル） 整合性 ルール OCL 制約式 実験結果 ルールa 制約式a 検証成功 ルールb 制約式b ルールc 制約式c_d_e ルールd ルールe ルールf 制約式f ルールg 制約式g ルールh 制約式h_i_j ルールi ルールj 整合性 ルール OCL 制約式 実験結果 ルールa 制約式a 検証成功 ルールb 制約式b ルールc 制約式c_d_e ルールd ルールe ルールf 制約式f ルールg 制約式g ルールh 制約式h_i_j ルールi ルールj 再利用可能 実験全体の結果について述べます．左の表は実験対象1の実験結果 です．左から適用した整合性ルール，それに対応するOCL制約式， その検証結果になります．整合性ルールの中にはまとめて OCL制約式で記述できるものもありました．表から実験対象1では 全ての整合性ルールに対して正しく検証できたことが分かります． 右の図は実験対象2の実験結果です．実験対象2も同様に全ての 整合性ルールに対して正しく検証することができました． また，この実験では実験対象1で記述したOCL制約式を実験対象2でも そのまま再利用することができました． 実験対象1，実験対象2，共に全ての整合性ルールに対して検証成功 修士論文発表会 2008/2/15

考察と評価 提案手法により異なるバージョンのUMLメタモデルであっても同様にUMLダイアグラム間整合性検証を行うことができた UML2.0，UML2.1.1共に，OCL制約式を用いてUMLダイアグラム間整合性検証が可能であったことを確認 UML2.0用に記述したOCL制約式をUML2.1.1に再利用できた 別の種類のUMLダイアグラム間に対しても整合性検証が可能だと考えられる クラス図とシーケンス図間の制約と同様にOCL式を記述可能 クラス図とステートマシン図　etc… しかし、OCL式で記述できない整合性ルールも存在した 事前事後条件は不変表明を妨げない　etc… 考察と評価です． UML2.0，UML2.1.1共に，OCL制約式を用いてUMLダイアグラム間 整合性検証が可能であったことを確認し，提案手法により異なる バージョンのUMLメタモデルであっても同様にUMLダイアグラム間 整合性検証を行うことができました． また，UML2.0用に記述したOCL制約式をUML2.1.1に再利用できました． そして，別の種類のUMLダイアグラム間に対しても提案手法により 検証可能だと考えます．クラス図とシーケンス図間の制約と同様にOCL式を 記述可能であれば，クラス図とステートマシン図などの整合性ルールも 検証可能だと考えます．しかし，クラス図とシーケンス図間に関する 制約以外の制約の中にはOCL式で記述できない整合性ルールも存在しました． 修士論文発表会 2008/2/15

まとめと今後の課題 UMLメタモデルの変更に対応可能なUMLモデル検証環境を自動生成する手法を提案 今後の課題 EMFを利用して検証環境のソースコードを自動生成 ツールを作成し，作業を効率化 クラス図とシーケンス図間に関する例題を，異なるUMLメタモデルの下で適用 今後の課題 より多くのUMLメタモデルのバージョンを用いた評価実験 他の例題への適用 検出した不整合の修正支援機能追加 修士論文発表会 2008/2/15

ありがとうございました これで発表を終わります．ありがとうございました． 修士論文発表会 2008/2/15