Struts フレームワークにおけるメタモデルを用いた追跡可能性実現手法の提案

1. Strutsフレームワークにおけるメタモデルを用いた追跡可能性実現手法の提案Strutsフレームワークにおけるメタモデルを用いた追跡可能性実現手法の提案 大平直宏†，松下誠†，岡野浩三†，楠本真二†，井上克郎†，山下裕介‡，我妻智之‡ † 大阪大学大学院情報科学研究科 ‡ （株）NTTデータ 第150回ソフトウェア工学研究会（SIGSE-150-5）

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

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

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

5. 第150回ソフトウェア工学研究会（SIGSE-150-5）

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

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

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

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

10. 第150回ソフトウェア工学研究会（SIGSE-150-5）

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

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

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

14. 第150回ソフトウェア工学研究会（SIGSE-150-5）

15. struts-config.xmlのMOFメタモデル • XML文書のメタモデル • 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> …

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

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

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

19. トレース情報のMOFメタモデル（1/2） • 成果物間の依存関係（トレース情報）のメタモデル • 依存関係を保持した状態で管理しなければならない要素対を定義 • 依存元の要素と依存先の要素のn対nの関係 • あるトレース情報はより詳細な別のトレース情報と関連をもつ • インスタンスであるトレース情報はツールが自動生成することを想定

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

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

22. <<model>> <<meta-model>> A B C B1: B B1: B C1: C C1: C C2: C C2: C <<model>> X1: X Y1: Y Y2: Y 開発者 開発者 正当性管理 正当性管理 <<model>> <<model>> X1: X Y1: Y Y2: Y 個々の成果物の正当性管理 <<meta-model>> <<meta-model>> BX_Trace RefB RefX X CY_Trace RefC RefY Y 画面遷移図-struts-config.xml間の依存関係のメタモデル（トレースメタモデル） struts-config.xmlの メタモデル 画面遷移図のメタモデル モデリングインターフェース

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

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

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

26. 第150回ソフトウェア工学研究会（SIGSE-150-5）

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

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