拡張可能なアスペクト指向モデリングにおける織り合わせの検証 九州工業大学大学院　情報工学研究科 前野 雄作，鵜林 尚靖 それでは、スキーマ言語に基づいたモデル変換の検証と題しまして鵜林研究室の前野が発表させていただきます。

発表内容 研究の背景と目的 検証のメカニズム 考察 まとめ 第155回ソフトウェア工学研究会 2007/3/22 発表内容は以下のようになっています。 まず最初に研究の背景としてアスペクト指向プログラミングについて述べ、本研究室で提案しているアスペクト指向モデリングを説明します。 次に、本研究の問題意識を挙げ、研究の目的を述べます。 次に、本研究で提案する検証手法について述べ、考察、まとめの順で説明させていただきます。 第155回ソフトウェア工学研究会 2007/3/22

研究の背景と目的

アスペクト指向プログラミング(AOP) システム本来の関心事と横断的関心事を分離して実装するためのメカニズム 横断的関心事をアスペクトと呼ばれる単位でモジュール化 織り込み(weave)によりアスペクトをシステム本来の関心事と結合 AOPのメカニズムはジョインポイントモデル（JPM）によって実現される アスペクト指向プログラミングはシステム本来の関心事とログ処理、永続化処理などの横断的関心事を分離して実装するためのメカニズム です。 この横断的関心事はアスペクトと呼ばれる単位でモジュール化され、織り込みによりシステム本来の関心事と結合されます。 このメカニズムはジョインポイントモデルによって実現されます。 第155回ソフトウェア工学研究会 2007/3/22

ジョインポイントモデルの構成 ジョインポイント ポイントカット アドバイス アスペクト ソースコード ジョインポイント ポイントカット メソッド呼び出しなどのプログラム実行フロー中のポイント ポイントカット 全てのジョインポイントの中からある特定の条件を満たすポイントを選び出す機能 アドバイス ポイントカットによって抜き出したジョインポイントでのプログラム実行を変更する機能 アスペクト ソースコード ジョインポイント ジョインポイントの絞込み ポイントカット ・・・・・・ ・・・・・・ フィールドアクセス コンストラクタ メソッド呼び出し ジョインポイントモデルはジョインポイント、ポイントカット、アドバイスと呼ばれる３つの機能から構成されます。 ジョインポイントはメソッド呼び出しなどのプログラム実行中のポイントを指し、 ポイントカットによって、ある特定の条件を満たすジョインポイントが絞り込まれます。 最後に、アドバイスによって絞り込まれたジョインポイントにコードの追加や置換が行われます。 ・・・・・・ 関連付け ・・・・・・ ・・・・・・ アドバイス ・・・ ・・・・・・ コードの追加・置換 第155回ソフトウェア工学研究会 2007/3/22

アスペクト指向モデリング言語 AspectM アスペクト指向の概念はプログラミング段階だけでなく開発上流工程のモデリング段階でも有効 モデルレベルでのアスペクト指向をサポートする言語AspectMを提案している UMLのクラス図を拡張 クラス名 ・・・・・・ ポイントカット アドバイス 関連付け アスペクトモデル UMLモデル 属性 操作 ジョインポイント モデルレベルでのアスペクト指向 静的なモデル要素 クラス パッケージ ジョインポイントの 絞込み 本研究室ではアスペクト指向の概念はプログラミング段階だけではなく、開発上流工程のモデリングでも有効だと考え、UMLのクラス図を拡張したアスペクト指向モデリング言語AspectMを提案しています。 AspectMでのジョインポイントはクラスなどのモデル要素を対象としており、ポイントカットは特定の属性を持つクラスなどを指定できます。 アドバイスはポイントカットで絞り込まれたモデル要素に対し、モデル要素の追加・削除などを行います。 newOperation ダイアグラムの編集 第155回ソフトウェア工学研究会 2007/3/22

アスペクト指向モデリング言語 AspectM モデルレベルでの織り込みを行うために、７種類のジョインポイントモデルを定義している ユーザはJPMを用いて様々なアスペクトを定義することにより、多様な織り込みが可能 ジョインポイントモデル 説明 pointcut & advice メソッドの追加・置き換え composition クラス同士のマージ new element クラスの追加・削除 open class 属性・操作の追加・削除 rename クラス・属性・操作の名前の変更 relation クラス間の関連・集約・合成関係の追加・削除 inheritance クラス間の継承関係の追加・削除 また、このモデルレベルでの織り込みを行うためにAspectMでは７種類のジョインポイントモデルを定義しています。 たとえば・・・。 ユーザは・・・。 第155回ソフトウェア工学研究会 2007/3/22

AspectMサポートツールの構成 モデルエディタ weaving モデルコンパイラ アスペクトの織り込まれたモデル クラスダイアグラム アスペクトダイアグラム また、本研究室ではAspectMをサポートするツールの開発も行っています。 AspectMサポートツールはモデルエディタと、モデルコンパイラから構成されています。 モデルエディタ上でクラスとアスペクトの定義を行い、モデルコンパイラによってアスペクトの織り込みを行います。 weaving モデルコンパイラ 第155回ソフトウェア工学研究会 2007/3/22

アスペクト指向モデリング言語 AspectM AspectMで扱うモデルはXML形式で保存される クラスダイアグラム <ownedElement xsi:type="asm:Class" name="Message"> <feature xsi:type="asm:Attribute" name="name" visibility="private" type=“String"/> <feature xsi:type="asm:Attribute" name="message" visibility="private" type=“String"/> <feature xsi:type="asm:Attribute" name="subject" visibility="private" type=“String"/> <feature xsi:type="asm:Operation" name="getMessage"> <parameter name="message" kind="return"/> </feature> </ownedElement> アスペクトダイアグラム <ownedElement xsi:type="asm:Aspect“ joinPointModelType="cm"> <aspectFeature xsi:type="asm:Pointcut" joinPointType="class" advice=“advice” body="Message||MessageProfile"/> <aspectFeature xsi:type="asm:Composition" name="" adviceType="mergeByName“ pointcut=“pointcut" mergedClassName="PostMessageForm"/> </ownedElement> 第155回ソフトウェア工学研究会 2007/3/22

AspectMの特徴 ユーザはAspectMのメタモデルを拡張することにより、モデルの表現能力を拡張可能 ユーザのドメインに特化したモデリングが可能 メタモデルとは？ モデルの文法をUMLによって記述したもの モデルの記述要素（モデル要素）の意味と構文を 記述したモデル UMLクラス図の拡張ポイント アスペクト図の拡張ポイント Operationの拡張 拡張後の記述例 このモデリング言語の特徴として、制限はありますが表現能力を拡張することが出来ます。 それはAspectMのメタモデルを拡張する形で行われます。 メタモデルとはモデルを定義するためのモデルであり、AspectMのメタモデルはこのようになっています。 例として操作を拡張した場合は、このように、ステレオタイプの付いた特別な操作を記述することが出来ます。 例えばトランザクショナルな操作を明記するために 第155回ソフトウェア工学研究会 2007/3/22

AspectMの適用例～MDAへの適用～ MDA（Model Driven Architecture）とは？ UMLモデルを中心としたシステム開発手法 プラットフォームに依存しないモデル（PIM）から、プラットフォームに特化したモデル（PSM）を自動生成 PIM : Platform Independent Model PSM : Platform Specific Model PIM 各プラットフォームごとのマッピングルール model compiler CORBA PSM Java PSM .NET PSM XML PSM 第155回ソフトウェア工学研究会 2007/3/22

AspectMの適用例～MDAへの適用～ 各プラットフォームへのマッピングルールをアスペクトとして記述 各プラットフォームに特化した記述をアスペクトルを用いてモジュール化し、織り込みを行うことでPSMを生成 マッピングルール アスペクトモデル アスペクトモデル PIM アスペクトモデル アスペクトモデル 織り込み model compiler CORBA PSM Java PSM .NET PSM XML PSM 第155回ソフトウェア工学研究会 2007/3/22

本研究の問題意識 その１ アスペクト織り込み後のモデルの構造 本研究の問題意識　その１ アスペクト織り込み後のモデルの構造 アスペクト織り込み後のモデルが、メタモデルの拡張の有無に関わらず、メタモデルの定義と異なるモデル構造であってはならない 織り込み後のモデル構造をチェックするメカニズムが必要 つまり・・・ 次に本研究のモチベーションについて述べます。 まず最初にモデルの表現能力の拡大に伴う問題があります。 第155回ソフトウェア工学研究会 2007/3/22

本研究の問題意識 その２ アスペクトの適用順序や、アスペクト同士の干渉により、正しい変換が行われない場合がある モデルエディタ 本研究の問題意識　その２ アスペクトの適用順序や、アスペクト同士の干渉により、正しい変換が行われない場合がある モデルエディタ クラス図 アスペクト図 …… アスペクト同士の干渉 によりモデルに誤りが 含まれる モデル変換 適用順序により 結果が異なる 第155回ソフトウェア工学研究会 2007/3/22

研究の目的 適用後のモデルがメタモデルの定義に従っているかを検証 アスペクト織り込みの正しさを検証 モデルコンパイラによって正しい織り込み処理が行われていることを保証する それにより・・・ 第155回ソフトウェア工学研究会 2007/3/22

検証の概要 モデル構造の検証 モデル変換の妥当性検証 検証のメカニズム 検証の概要 モデル構造の検証 モデル変換の妥当性検証

検証の概要 検証は大きく分けて以下の２つのステップで行う モデル構造の検証 モデル変換の妥当性検証 アスペクト適用後のモデルの構造がメタモデルの定義に従っているかを検証 モデル変換の妥当性検証 ユーザが指定するポイントカットに、対応するアドバイスが全て適用されているかを検証 アスペクトの干渉によりモデル中に誤りが含まれていないかを検証 検証は大きくわけて二つのステップで行います。 最初のモデル構造の検証では、モデルの構造がメタモデルの定義に従っているかの検証を行います。 次に、モデル変換の妥当性検証ではアスペクトが正しく適用されているかの検証を行います。 1. モデル構造の検証 2. モデル変換の妥当性検証 第155回ソフトウェア工学研究会 2007/3/22

１．モデル構造の検証

１．モデル構造の検証 モデルの構造はメタモデルが定義している モデルはXML文章として保存されている つまり・・・ そこで・・・ 第155回ソフトウェア工学研究会 2007/3/22

スキーマ言語とは？ XML文章の構造を定義するためのメタ言語 スキーマとはXML文章がvalidかどうかチェック(validation)するための制約 代表的なスキーマ言語にXML Schemaがある 第155回ソフトウェア工学研究会 2007/3/22

１．モデル構造の検証 検証に先立ち拡張前のメタモデルから、デフォルトのスキーマを定義 モデル構造の検証は以下のステップで行う Step1. メタモデルの拡張をチェック Step2. メタモデルが拡張されていれば、デフォルトのスキーマを拡張情報を用いて再定義 そのXML Schemaを用いて拡張前のメタモデルから、デフォルトのスキーマをあらかじめ定義しておきます。 そのスキーマを用いて、実際の検証は３つのステップから行われます。 Step１ Step3. 対象となるモデルの構造がスキーマの定義する構造に従っているかをチェック 第155回ソフトウェア工学研究会 2007/3/22

Step0. デフォルトのスキーマの定義 AspectMメタモデル中のUMLクラス図に関する部分の構造を定義 例）“Class”に関する構造の定義の一部 1 : <xsd:complexType name="ClassType"> 2 : <xsd:choice maxOccurs="unbounded" minOccurs="0"> 3 : <xsd:element name="Attribute" type="AttributeType"/> 4 : <xsd:element name="Operation" type="OperationType"/> 5 : </xsd:choice> 6 : <xsd:attribute name="name" type="Name" use=“required"/> 7 : <xsd:attribute name="isAbstract" type="Boolean" use="optional"/> 8 : … 9 : </xsd:complexType>　 Classの制約 デフォルトのスキーマはAspectMメタモデル中のUMLクラス図に関する部分の構造を定義しています。 アスペクト適用後のモデルはアスペクトを含んでいてはならないため、クラス図に含まれるモデル要素に制限しています。 スキーマの例としてクラスに関する制約を上げます このスキーマでは、クラスを表すXMLタグの子要素に属性と操作が０個以上存在する可能性があることと、クラスを表すXMLタグの属性としてクラス名を表すnameと、抽象クラスかどうかを表すisAbstractを持っていることを表しています 1: <Class name=“ClassName” isAbstract=“false” …> 2: <Attribute …/> 3: 　　 … 4: <Operation …/> 5: 　　 … 6: </Class> スキーマに従った Classの表記 第155回ソフトウェア工学研究会 2007/3/22

Step1. メタモデルの拡張をチェック メタモデルの拡張は拡張ポイントにサブクラスを定義する形で行われる メタモデルを解析し、拡張ポイントを継承するクラスの有無を調べる 従って・・・ メタモデルの拡張 拡張ポイント メタモデルの拡張は左下の図のように拡張可能なポイントにサブクラスを定義する形で行われるため、メタモデルを解析し、拡張ポイントを継承するクラスの有無を調べることにより、メタモデルの拡張を調べることが出来ます。 例えば操作を拡張するトランザクションオペレーション 新たに追加する モデル要素 第155回ソフトウェア工学研究会 2007/3/22

Step2. メタモデルが拡張されていれば、デフォルトのスキーマを拡張情報を用いて再定義 例）操作の拡張に伴うスキーマの再定義 1 :<xsd:complexType name="ClassType"> 2 : <xsd:choice maxOccurs="unbounded" minOccurs="0"> 3 : <xsd:element name="Attribute" type="AttributeType"/> 4 : <xsd:element name="Operation" type="OperationType"/> 5 : <xsd:element name=“TransactionOperation" type=" TransactionOperationType"/> 6 : </xsd:choice> 7 : <xsd:attribute name="name" type="Name" use="required"/> 8 : <xsd:attribute name="isAbstract" type="Boolean" use="optional"/> 9 : </xsd:complexType> 10 : 11 : <xsd:complexType name=" TransactionOperationType "> 12 : <xsd:complexContent> 13 : <xsd:extension base=“OperationType“/> 14 : </xsd:complexContent> 15 : </xsd:complexType> 第155回ソフトウェア工学研究会 2007/3/22

Step3. 対象となるモデルの構造がスキーマの定義する構造に従っているかをチェック Javaのjavax.xml.validationパッケージの提供するValidatorクラスを利用 スキーマと照合して XML文章の構造をチェック 検証対象となるモデルの読み込み スキーマの読み込み モデルの妥当性検証 第155回ソフトウェア工学研究会 2007/3/22

2.1 アスペクト適用順序のチェック 2.2 アスペクト同士の干渉のチェック ２．モデル変換の妥当性検証 2.1 アスペクト適用順序のチェック 2.2 アスペクト同士の干渉のチェック

２．モデル変換の妥当性検証 2.1 アスペクトの適用順序のチェック 2.2 アスペクト同士の干渉のチェック 2.1　アスペクトの適用順序のチェック ユーザが指定するポイントカットに、対応するアドバイスが全て適用されているかを検証 2.2　アスペクト同士の干渉のチェック 誤ったアスペクトの組み合わせによる、名前の衝突・多重継承・循環継承のチェック 第155回ソフトウェア工学研究会 2007/3/22

2.1 アスペクト適用順序のチェック 検証には一階述語論理に基づいたプログラミング言語であるprologを利用 検証は以下のステップで行う 処理系にはSWI-Prologを使用 JPLを利用しJavaを用いて実装 検証は以下のステップで行う 2.1 アスペクト適用順序のチェック Step1. 変換後のモデルから事実を生成 Step2. アスペクトから質問を生成 Step3. 質問の問い合わせ 第155回ソフトウェア工学研究会 2007/3/22

<ownedElement name=“Hello” xsi:type=“asm:Class”/> Step1.　変換後のモデルから事実を生成 XML文章からprologの事実を生成するジェネレータを実装 生成の概要 <ownedElement name=“Hello” xsi:type=“asm:Class”/> property(‘tagName’,’ownedElement’) モデル情報の保存 property(‘name’,’Hello’) property(‘xsi:type’,’asm:Class’) property(‘id’,’一意なID’) 階層構造の保存 property(‘parentID’,’親ノードのID’) modelElement( [述語propertyのリスト] ). 第155回ソフトウェア工学研究会 2007/3/22

Step2. アスペクトから質問を生成 質問はアスペクト適用後のモデルの制約 質問はJPMごとに、プリミティブな述語の組み合わせで定義される 説明 super_class_of(P,C) PはCのスーパークラスである attribute_of(A,C) 属性AはクラスCに属する操作である operation_of(O,C) 操作OはクラスCに属する操作である class_exist(C) クラスCが存在する related_to(C1,C2) クラスC1とクラスC2間に関連がある aggregated_to(C1,C2) クラスC1とクラスC2間に集約関係がある composited_to(C1,C2) クラスC1とクラスC2間に合成関係がある 第155回ソフトウェア工学研究会 2007/3/22

Step2. アスペクトから質問を生成 例）JPM：Compositionを用いたクラスのマージ アスペクト適用後のモデルの制約 マージを行うアスペクト クラスMessageは存在しない not(class_exist(‘Message’)). 生成 クラスMessageProfileは存在しない not(class_exist(‘MessageProfile’)). クラスPostMessageFormが存在する class_exist(‘PostMessageForm’). 第155回ソフトウェア工学研究会 2007/3/22

Step3. 質問の問い合わせ 変換後のモデル クラスPostMessageFormが存在する クラスPostMessageFormはActionFormクラスを継承している 生成 事実 SWI-Prolog処理系 Java JPL 生成 質問 結果：true 結果：false 問い合わせ not(class_exist(‘Message’)). not(class_exist(‘MessageProfile’)). アスペクト class_exist(‘PostMessageForm’). super_class_of(‘ActionForm’,’PostMessageForm’). 第155回ソフトウェア工学研究会 2007/3/22

2.2 アスペクト同士の干渉のチェック 以下の項目をチェックする 名前の衝突のチェック 多重継承のチェック 循環継承のチェック 第155回ソフトウェア工学研究会 2007/3/22

考察とまとめ

考察 現在、出力後のモデルが満たすべき制約はアスペクトやメタモデルから生成 ユーザが出力後のモデルへの制約を加えることも有効 ユーザの本当に意図したモデルが生成されているかを検証することが可能 それに加えて・・・ それが出来れば・・・ 第155回ソフトウェア工学研究会 2007/3/22

まとめ モデル変換の正しさを検証するために、2つの観点から検証を行った 本研究により、ユーザにモデル変換時の誤りを通知することが可能になった モデルの構造における問題点の検証 アスペクトの織り込みに伴う問題点の検証 本研究により、ユーザにモデル変換時の誤りを通知することが可能になった 第155回ソフトウェア工学研究会 2007/3/22

終わり ご清聴ありがとうございました

付録

AOPを用いたログ処理の例 通常のログ出力 アスペクトによるログ処理の織り込み モジュールAに適用されるログ出力アスペクト log() log() 全てのオブジェクト 初期化直前にlog() 全てのメソッド実行 直前にlog() log() log() モジュールA モジュールB モジュールA モジュールB モジュールAに適用されるログ出力アスペクト ポイントカット：全てのオブジェクト初期化 アドバイス：直前にlog() モジュールBに適用されるログ出力アスペクト ポイントカット：全てのメソッド実行 第155回ソフトウェア工学研究会 2007/3/22

２．問題意識 具体例 組込みシステムにおける外部環境分析 システムと外部環境の関係を表現するためにクラス図を利用 ＵＭＬのクラス図を使って表現 観測を妨害する光 外部環境 LightSensor 光センサー SensorDriver ドライバ 　ObservedLight 観測光 環境光 EnvironmentLight システム 光センサー 光センサーを制御 光センサーが観測する光 第155回ソフトウェア工学研究会 2007/3/22

２．問題意識 具体例 問題提起 ＵＭＬでは・・・ ステレオタイプを用いて 視覚的に区別を行う ソフトウェア ハードウェア 外部環境 個々のモデル要素の役割を視覚的に区別できない 第155回ソフトウェア工学研究会 2007/3/22

２．問題意識 問題提起 しかし・・・ステレオタイプは単なるラベルであり、アノテーションにすぎない 「ソフトウェア」と「外部環境」 →ハードウェアを仲介する 「ハードウェア」 →制御するソフトウェアが必要 しかし・・・ステレオタイプは単なるラベルであり、アノテーションにすぎない モデルがドメイン特有の制約事項を満たしていることまでは保証できない ドメインに特化した表現上の区別や制約を、厳密にモデリングできる機構が必要 第155回ソフトウェア工学研究会 2007/3/22

2.2 アスペクト同士の干渉のチェック 検証項目 名前の衝突の検出 多重継承の検出 循環継承の検出 2.2　アスペクト同士の干渉のチェック 検証項目 名前の衝突の検出 既にモデル中に存在する名前を持つモデル要素の追加 →同スコープ内での名前の衝突を検出 多重継承の検出 同じクラスへの複数の継承関係の追加 既にスーパークラスを持つクラスへの継承関係の追加 →複数のスーパークラスを持つクラスを検出 循環継承の検出 継承関係がループになるような継承関係の追加 →全クラスの継承関係を辿ることで検出 第155回ソフトウェア工学研究会 2007/3/22

１．モデル構造の検証 検証に先立ち拡張前のメタモデルから、デフォルトのスキーマを定義 モデル構造の検証は以下のステップで行う Step1. メタモデルの拡張をチェック Step2. メタモデルが拡張されていれば、デフォルトのスキーマを拡張情報を用いて再定義 そのXML Schemaを用いて拡張前のメタモデルから、デフォルトのスキーマをあらかじめ定義しておきます。 そのスキーマを用いて、実際の検証は３つのステップから行われます。 Step１ Step3. 対象となるモデルの構造がスキーマの定義する構造に従っているかをチェック 第155回ソフトウェア工学研究会 2007/3/22

２．モデル変換の妥当性検証 2.1 アスペクトの適用順序のチェック 2.2 アスペクト同士の干渉のチェック 2.1　アスペクトの適用順序のチェック ユーザが指定するポイントカットに、対応するアドバイスが全て適用されているかを検証 2.2　アスペクト同士の干渉のチェック 誤ったアスペクトの組み合わせによる、名前の衝突・多重継承・循環継承のチェック 第155回ソフトウェア工学研究会 2007/3/22

問題意識 その２ アスペクトの適用順序や、アスペクト同士の干渉により、正しい変換が行われない場合がある モデルエディタ アスペクト同士の干渉 問題意識　その２ アスペクトの適用順序や、アスペクト同士の干渉により、正しい変換が行われない場合がある モデルエディタ クラス図 アスペクト図 …… アスペクト同士の干渉 によりモデルに誤りが 含まれる モデル変換 適用順序により 結果が異なる 第155回ソフトウェア工学研究会 2007/3/22

問題意識 その２ アスペクトの適用順序により、正しい変換が行われない場合がある モデルエディタ 適用順序により 結果が異なる クラス図 問題意識　その２ アスペクトの適用順序により、正しい変換が行われない場合がある モデルエディタ クラス図 アスペクト図 モデル変換 適用順序により 結果が異なる 第155回ソフトウェア工学研究会 2007/3/22

３．モデリング言語の拡張 モデル要素をメタレベルで区別することが有効 メタモデル クラス 属性 操作 ＵＭＬの定義をＵＭＬ自身で記述 第155回ソフトウェア工学研究会 2007/3/22

Document Object Model (DOM) XML文章で保存されているモデルをDOMを用いて操作 XML文章を汎用的に操作するためのインターフェース XMLを構成する最小単位であるノードの追加・削除・変更が可能 DOMツリー 第155回ソフトウェア工学研究会 2007/3/22