Strutsフレームワークにおけるメタモデルを用いた追跡可能性実現手法の提案 大平直宏†，松下誠†，岡野浩三†，楠本真二†， 井上克郎†，山下裕介‡，我妻智之‡ † 大阪大学大学院情報科学研究科 ‡ （株）NTTデータ 発表25分，質疑10分 ソフトウェアを高品質かつ短期間で開発・保守したいという要求が高まる中，Web アプリケーションを効率よく開発するためのフレームワークが登場している． このようなフレームワークを用いた開発では，ソフトウェアを新規に開発するときだけでなく，修正や削除などの保守を行う際にもフレームワークの意図する枠組みに従った設計が維持されていることが保証できなければならない． 本研究ではStruts フレームワークを対象とし，個々の成果物の仕様，およびそれら成果物間の依存関係の仕様となるメタモデルを定義することで，一貫性を保った状態でソフトウェア成果物を管理し，追跡可能性を実現する手法を提案する． 2005/11/29 第150回ソフトウェア工学研究会（SIGSE-150-5）

研究の背景 Webアプリケーションフレームワーク 問題点 ex.）Struts，JSF 画面遷移の管理といった典型的な処理をフレームワークが実装 ソフトウェアの品質向上，開発・保守効率の向上 問題点 フレームワークの意図する仕様に従った成果物の作成が必要 修正や削除が加わった場合にも 明示的な仕様が定められていない成果物の存在 実装成果物にはフレームワークの仕様があるが，設計成果物にはない 成果物間の依存関係（トレース情報）を保存・管理する枠組みが存在しない 　設計・実装成果物間の一貫性が保たれない 2005/11/29 第150回ソフトウェア工学研究会（SIGSE-150-5）

研究の目的 Strutsフレームワークにおける画面遷移の設計～実装を対象 追跡可能性を実現する 一貫性管理を実現する 設計・実装間で，互いに関連のある要素の依存関係を追跡可能 （変更影響を追跡可能である） 一貫性管理を実現する 設計・実装間で，お互いが表現する内容に矛盾がない （設計情報が正しく実装に伝わっている）

提案手法の概要 成果物とその依存関係（トレース情報）をMOFメタモデルのもとで統一的に管理 個々の成果物に対してMOFメタモデルを定義 成果物単体の正しさを保証 成果物間のトレース情報に対してMOFメタモデルを定義 成果物間のトレース情報を自動蓄積

2005/11/29 第150回ソフトウェア工学研究会（SIGSE-150-5）

Struts JavaのWebアプリケーションフレームワーク Webアプリケーションの機能を個々のコンポーネントへ分割 処理 各コンポーネントを制御するアクションサーブレット ユーザの入出力画面を表示するJSP/HTMLファイル 入力データを保存するアクションフォームBeans リクエスト処理するアクションクラス アクションサーブレット フレームワークのコアエンジン 各コンポーネントを設定ファイルに基づいて結合 struts-config.xml 2. 入力データの保存 アクションフォームBeans struts-config.xml データ の参照 処理 3. 対応するアクションの実行 4. ステータスの返却 アクションサーブレット アクションクラス 1. リクエスト & 入力データ 5. 次画面の出力

struts-config.xmlの例 <action-mappings> ユーザのリクエストを処理するアクションクラスと画面の遷移に関する設定 <form-beans> ユーザの入力情報を保存するアクションフォームBeansに関する設定

struts-config.xmlの例 <action> リクエスト処理に関する設定 <forward> LogonForm = org.example.LogonForm org.example.LogonAction success failure /SubmitLogon <action> リクエスト処理に関する設定 <forward> アクションクラスの終了ステータスと次画面のマッピング mainMenu.jsp logon.jsp

Strutsにおける成果物 実装：設定ファイルstruts-config.xml 設計：画面遷移図 フレームワークによる明示的な仕様は定められていない struts-config.xmlとして実装できる設計にする必要性 設計もフレームワークによって暗黙的な仕様で制限されている

2005/11/29 第150回ソフトウェア工学研究会（SIGSE-150-5）

メタモデルの重要性 ソフトウェア開発で扱う情報 情報を定められた仕様に従ってモデルとして表現 仕様を形式的に定義（メタモデル）できる必要 要求，設計，実装，依存関係，進捗，etc 情報を定められた仕様に従ってモデルとして表現 仕様が曖昧な場合や明示されない場合が存在 　　仕様を形式的に定義（メタモデル）できる必要 記述仕様 A B C <<model>> 開発者 対象の情報 モデル化

MOF（Meta Object Facility） オブジェクト指向に基づいてメタモデルを定義するためのOMG標準言語 UMLのクラス図に似た意味論をもつが，表記法はない UMLクラス図を用いて記述されることが多い MOFは同じ性質のメタオブジェクトをMOFクラスとして抽象化 UMLは同じ性質のオブジェクトをUMLクラスとして抽象化 メタオブジェクトは他のオブジェクトの性質を規定するオブジェクト（≒UMLクラス） MOFリポジトリを生成可能 <<meta-model>> X MOF クラス メタモデル設計者 1 0..1 Y モデル化 定義 A:Y B:X C:Y <<model>> 開発者 MOF オブジェクト モデル化 定義 対象の情報

MOFリポジトリ MOFで記述したメタモデルに対して，そのスキーマに従うインスタンスを管理できるリポジトリを生成可能 MOFリポジトリ A B C <<meta-model>> MOFリポジトリ <<meta-model>> A B C 1 * 1 0..1 Generate メタモデル設計者 格納NG 格納OK モデル （インスタンス） 格納OK A1: A B1: B C1: C <<model>> 開発者A <<model>> A1: A B1: B B2: B 開発者B <<model>> A1: A B1: B C1: C 開発者C メタモデル 違反

2005/11/29 第150回ソフトウェア工学研究会（SIGSE-150-5）

struts-config.xmlのMOFメタモデル DTD（Document Type Definition，文書定義型）で定義されている MOFによるXML文書のメタモデル 要素の親子関係をMOFクラスの集約関係として定義 　※ MOFで再定義するのは，全ての成果物をMOFリポジトリの上で統一的に扱うため <!– struts-config.xmlのDTDの一部 --> <!ELEMENT struts-config (…, form-beans?, …, action-mappings?)> … <!ELEMENT form-beans (form-bean*)> <!ELEMENT form-bean (…)> <!ATTLIST form-bean name %BeanName; #REQUIRED> <!ATTLIST form-bean type %ClassName; #IMPLIED>

struts-config.xmlのモデル例 <<meta-model>> <<instance of>> <<model>>

画面遷移図のMOFメタモデル UMLアクティビティのメタモデルをベースに定義 ノード ActivityNode 辺 ActivityEdge 画面DisplayNode アクションActionNode 辺 ActivityEdge リクエストActionEdge 次画面遷移ForwardEdge ガード条件 ValueSpecification TODO:アクティビティ図の詳細メタモデル？

画面遷移図のモデル例 <<meta-model>> <<instance of>>

トレース情報のMOFメタモデル（1/2） 成果物間の依存関係（トレース情報）のメタモデル 依存関係を保持した状態で管理しなければならない要素対を定義 依存元の要素と依存先の要素のn対nの関係 あるトレース情報はより詳細な別のトレース情報と関連をもつ インスタンスであるトレース情報はツールが自動生成することを想定 MOFクラス単位でTraceを張る より詳細な関係はdetail属性を使えるようにしているが，その解釈はツールに依存

トレース情報のMOFメタモデル（2/2） struts-config.xmlの メタモデル要素への参照 画面遷移図の メタモデル要素 への参照

メタモデルに基づく追跡可能性の実現手法 MOFリポジトリの操作による追跡可能性の実現 個々の成果物をMOFリポジトリで管理 画面遷移図のメタモデル struts-config.xmlの メタモデル トレース情報のメタモデル トレース管理 正当性管理 正当性管理 モデリングインターフェース 開発者 開発者

個々の成果物の正当性管理 モデリングインターフェース A B C BX_Trace X CY_Trace Y <<meta-model>> A B C <<meta-model>> <<meta-model>> RefB BX_Trace RefX X RefC CY_Trace RefY Y 画面遷移図-struts-config.xml間の 依存関係のメタモデル（トレースメタモデル） 画面遷移図のメタモデル struts-config.xmlの メタモデル <<model>> B1: B C1: C C2: C 正当性管理 <<model>> X1: X Y1: Y Y2: Y 正当性管理 struts-config.xmlのモデルは必ずしも開発者が作るとは限らない（i.e. 自動生成） →ただ，本研究はその前段階として，成果物間の関係を保存することを目的としている <<model>> B1: B C1: C C2: C <<model>> X1: X Y1: Y Y2: Y モデリングインターフェース 開発者 開発者

トレース情報の蓄積 モデリングインターフェース A B C BX_Trace X CY_Trace Y <<meta-model>> A B C <<meta-model>> <<meta-model>> RefB BX_Trace RefX X RefC CY_Trace RefY Y 画面遷移図-struts-config.xml間の 依存関係のメタモデル（トレースメタモデル） 画面遷移図のメタモデル struts-config.xmlの メタモデル <<model>> B1X1: BX_Trace <<model>> RefB1 RefX1 <<model>> 作成されることが要求 されるが，まだ作られて いない状態 B1: B C1: C X1: X Y1: Y Y2: Y C2: C C1Y1: CY_Trace RefC1 RefY1 C2Y2: CY_Trace RefC2 RefY2 トレース管理 モデリングインターフェース 開発者 開発者

追跡可能性の実現と一貫性の管理（1/2） モデリングインターフェース A B C BX_Trace X CY_Trace Y <<meta-model>> A B C <<meta-model>> <<meta-model>> RefB BX_Trace RefX X RefC CY_Trace RefY Y 画面遷移図-struts-config.xml間の 依存関係のメタモデル（トレースメタモデル） 画面遷移図のメタモデル struts-config.xmlの メタモデル <<model>> B1: B C1: C C2: C <<model>> <<model>> X1: X Y1: Y Y2: Y RefB1 B1X1: BX_Trace RefX1 正当性管理 変更 RefC1 C1Y1: CY_Trace RefY1 正当性管理 要修正 RefC2 C2Y2: CY_Trace RefY2 トレース管理 モデリングインターフェース 開発者 開発者

追跡可能性の実現と一貫性の管理（2/2） モデリングインターフェース A B C BX_Trace X CY_Trace Y <<meta-model>> メタモデル違反 A B C <<meta-model>> <<meta-model>> RefB BX_Trace RefX X 1 0..1 RefC CY_Trace RefY Y 画面遷移図-struts-config.xml間の 依存関係のメタモデル（トレースメタモデル） 画面遷移図のメタモデル struts-config.xmlの メタモデル 削除 <<model>> <<model>> B1X1: BX_Trace C1Y1: CY_Trace RefB1 RefC1 RefX1 RefY1 C2Y2: CY_Trace RefC2 RefY2 <<model>> X1: X Y1: Y Y2: Y B1: B C1: C C2: C 正当性管理 削除 要修正 正当性管理 影響 削除 トレース情報の 削除 トレース管理 モデリングインターフェース 開発者 開発者

2005/11/29 第150回ソフトウェア工学研究会（SIGSE-150-5）

まとめと今後の課題 まとめ 今後の課題 画面遷移図とstruts-config.xml，及びそのトレース情報に対してMOFメタモデルを定義 メタモデルから生成したMOFリポジトリを操作することで，Strutsにおける追跡可能性，一貫性管理を実現する手法を提案 今後の課題 メタモデルの詳細化 プロトタイプツールの実装による評価実験 画面遷移部分だけ 今後詳細化を進める上でのベースとなる 2005/11/29 第150回ソフトウェア工学研究会（SIGSE-150-5）

SIGSE質問，コメント トレーサビリティを確保するということだけなら，わざわざこんなことしなくても自動的に生成してしまったら？ QVTを使わなかった（使えなかった）のは？（沢田先生@京大） インスタンス決めうちであるような依存関係は？（沢田先生@京大） 単純なn対nではなくてもう少し何か．すごい数になるよね（沢田先生@京大） 汎用的な手法のようだけど，なぜstrutsを？ なぜ設計と実装の間のインスタンスに対して，適切なトレースが作れるの？（岸先生@JAIST） 簡単に言うけど…もうちょっと詳しく（落水先生@JAIST） 次々に入り組んだトレースを保存していって，いざ修正が入った場合に，その影響が及ぶ部分をどうピンポイントに取り出すのか．（落水先生@JAIST）