UMLメタモデルの変更に対応した ダイアグラム間整合性検証環境の 自動生成手法

Slides:



Advertisements
Similar presentations
関心事指向アーキテクチャモデリング環 境 Concern-oriented Architecture Modeling Environment 九州工業大学大学院情報工学府 情報科学専攻 鵜林研究室 M1 佐藤 友紀 1.
Advertisements

OWL-Sを用いたWebアプリケーションの検査と生成
メタモデル記述を用いた成果物間の依存関係追跡手法
シーケンス図の生成のための実行履歴圧縮手法
国内線で新千歳空港を利用している航空会社はどこですか?
オブジェクト指向プログラミング(4) 静的分析(2)
Myoungkyu Song and Eli Tilevich 発表者: 石尾 隆(大阪大学)
情報伝播によるオブジェクト指向プログラム理解支援の提案
3-5 クラス図の関係その3 福本研究室 神田 祐輔.
変数のスコープの設計判断能力 を育成するプログラミング教育
ユースケース図2-4~ FM11012 中島拓也.
リファクタリングのための 変更波及解析を利用した テスト支援ツールの提案
UML入門 UML PRESS vol.1 より 時松誠治 2003年5月19日.
UMLとは           032234 田邊祐司.
プログラム実行履歴を用いたトランザクションファンクション抽出手法
チーム FSEL 立命館大学情報理工学部 ソフトウェア基礎技術研究室
UMLメタモデル仕様とOCL制約に基づくUMLモデル検証環境の生成
識別子の命名支援を目的とした動詞-目的語関係の辞書構築
その他の図 Chapter 7.
組込みシステムの外部環境分析のためのUMLプロファイル
暗黙的に型付けされる構造体の Java言語への導入
オブジェクト指向プログラムにおける エイリアス解析手法の提案と実現
インラインスクリプトに対するデータフロー 解析を用いた XHTML 文書の構文検証
シーケンス図を用いて実行履歴を可視化するデバッグ環境の試作
利用関係に基づく類似度を用いたJavaコンポーネント分類ツールの作成
只見町 インターネット・エコミュージアムの「キーワード」検索の改善
Javaプログラムの変更を支援する 影響波及解析システム
アスペクト指向に基づく 拡張可能な MDAモデルコンパイラ
社会シミュレーションのための モデル作成環境
コードクローン検出ツールを用いた ソースコード分析システムの試作と プログラミング演習への適用
プログラム動作理解支援を目的とした オブジェクトの振舞いの同値分割手法
ソフトウェア設計検証 研究室の紹介 知能情報学部 准教授 新田直也.
コードクローンに対する一貫性のない変更に起因する欠陥の検出
言語XBRLで記述された 財務諸表の分析支援ツールの試作
UMLモデルを対象とした リファクタリング候補検出の試み
コードクローン検出に基づくデザイン パターン適用支援手法の提案と実現
第1章 実世界のモデル化と形式化 3.地物インスタンスの表現
Webコミュニティ概念を用いた Webマイニングについての研究 A study on Web Mining Based on Web Communities 清水 洋志.
バイトコードを単位とするJavaスライスシステムの試作
背景 課題 目的 手法 作業 期待 成果 有限体積法による汎用CFDにおける 流体構造連成解析ソルバーの計算効率の検証
シナリオを用いたレビュー手法PBRの追証実験 - UMLで記述された設計仕様書を対象として -
1-3 UMLの図(ダイアグラム) コンポーネント図 システムの物理的な構成を表現 ソフトウェアコンポーネントの依存性を表現
コードクローンの理解支援を目的としたコードクローン周辺コードの解析
コードクローン分類の詳細化に基づく 集約パターンの提案と評価
UMLの概要とオブジェクト指向の基本概念
既存ソフトウェア中の 頻出コード片を用いた コード補完手法の提案
項目間の対応関係を用いた XBRL財務報告書自動変換ツールの試作
プログラムの織り込み関係を可視化するアウトラインビューの提案と実装
コーディングパターンの あいまい検索の提案と実装
拡張可能なアスペクト指向モデリングにおける織り合わせの検証
JavaScriptを含んだHTML文書に対する データフロー解析を用いた構文検証手法の提案
オブジェクトの協調動作を用いた オブジェクト指向プログラム実行履歴分割手法
オブジェクト指向言語論 第十二回 知能情報学部 新田直也.
設計情報の再利用を目的とした UML図の自動推薦ツール
「マイグレーションを支援する分散集合オブジェクト」
プログラムの差分記述を 容易に行うための レイヤー機構付きIDEの提案
メソッドの同時更新履歴を用いたクラスの機能別分類法
ソフトウェア工学 理工学部 情報システム工学科 新田直也.
プログラム分散化のための アスペクト指向言語
UMLモデルを対象とした リファクタリング候補検出手法の提案と実現
開発者との対話を活かした 横断的構造の表現
ソフトウェア工学 知能情報学部 新田直也.
エイリアス関係を考慮した Javaプログラム用静的スライシングツール
ソフトウェア工学 知能情報学部 新田直也.
コードクローン解析に基づく デザインパターン適用候補の検出手法
木構造の比較に基づく メソッド呼び出し履歴の変化の可視化手法
オブジェクト指向言語における セキュリティ解析アルゴリズムの提案と実現
オブジェクト指向メトリクスを用いた 開発支援に関する研究 --- VC++とMFCを用いた開発を対象として ---
プログラム理解のための 付加注釈 DocumentTag の提案
Presentation transcript:

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は4つの階層のモデル によって定義されます.最上位の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モデルに対する検証処理系です. そこで本研究では、既存のモデリングフレームワークを 応用できないかと考えました.そして,モデリングフレームワーク の1つである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

整合性検証例 違反検出 違反が出力されなくなった 1.関連のないクラスのオブジェクト間で メッセージのやりとりをしてはいけない 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 1.関連のないクラスのオブジェクト間で   メッセージのやりとりをしてはいけない Coin CoinValue + value: CoinValue Cocoa Coffee Tea {leaf} {leaf} 2.メッセージが未定義ではいけない 修士論文発表会 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