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

松下 誠 † 岡野 浩三 † 楠本 真二 †山下 裕介 ‡ 我妻 智之 ‡‡大阪大学 大学院情報科学研究科〒 560-8531 大阪府豊中市待兼山町 1-3

井上 克郎 †（株）NTT データ〒 104-0033 東京都中央区新川 1-21-2

ソフトウェアを高品質かつ短期間で開発・保守したいという要求が高まる中，Web アプリケーションを効率よく開発するためのフレームワークが登場している．このようなフレームワークを用いた開発では，ソフ
トウェアを新規に開発するときだけでなく，修正や削除などの保守を行う際にもフレームワークの意図する枠組みに従った設計が維持されていることが保証できなければならない．本研究では Struts フレームワー
クを対象とし，個々の成果物の仕様，およびそれら成果物間の依存関係の仕様となるメタモデルを定義することで，一貫性を保った状態でソフトウェア成果物を管理し，追跡可能性を実現する手法を提案する．

Realization of Model Traceability using Metamodel for the Struts
Framework
Naohiro Ohira† Makoto Matsushita† Kozo Okano† Shinji Kusumoto† Katsuro Inoue†
Yusuke Yamashita‡ Tomoyuki Azuma‡†

Graduate School of Information Science andTechnology, Osaka University
1-3 Machikaneyama, Toyonaka, Osaka, 560-8531 Japan‡NTT DATA Corporation
1-21-2 Shinkawa, Chuo-ku, Tokyo, 104-0033 JapanWeb application frameworks have been proposed to develop and maintain high quality software in aneﬀective way. In the case of software artifacts developed under these application frameworks, they are
required to satisfy the speciﬁcations of the framework, not only during the development phase, but also
during the maintenance phase. Therefore, it is important to ensure that the software artifacts are kept
in a consistent manner according to the frameworks. In this paper, focusing on the Struts framework,
we propose a method to realize model traceability and manage software artifacts in a consistent way,by deﬁning metamodels of artifacts and dependency among them.

-1-

1

の一貫性を保証することが課題となる．

まえがき

成果物間の関連を定義する研究としては，独自Web アプリケーションに代表される中小規模のソフトウェアを高品質かつ短期間で効率よく開発・の変換規則を記述してモデル変換を実現する研究保守したいという要求は大きく，Java においては[4] や，UML のサブセットと制約言語 OCL を用い

Struts[2] や JSF[7] といった Web アプリケーショて，互いに変換可能なモデル間の関連を記述する

ンフレームワークが用いられている．アプリケー

研究 [1] などがある．これらはいずれも関連のある

ションフレームワークを用いたソフトウェア開発

モデルの変換に重点を置いているが，本研究ではでは，性質の似たソフトウェアに共通する処理を成果物とその依存関係を MOF で統一的に記述し，フレームワークが行ってくれるため，開発者は個々

トレーサビリティを実現することを目指している．

のソフトウェア毎に異なる部分だけを設計・実装

以降，2 節では Web アプリケーションフレームすればよく，開発効率を高めることができる．

ワーク Struts について説明し，3 節ではメタモデ

フレームワークを用いた開発では，フレームワー

ルを作成する重要性とメタモデリング言語 MOF

クの仕様を満たす実装が要求されるため，その設について説明する．4 節では提案手法に必要な各計も制限される．しかし，明示的な仕様が定めら

種メタモデルを定義し，5 節で MOF メタモデル

れている実装とは異なり，設計成果物に対する仕を用いたトレーサビリティの実現手法を説明する．

様は定められていないことが多い．そのため，開最後に，6 節でまとめと今後の課題を述べる．

発者が作成・修正した設計成果物がフレームワー

2Strutsクの仕様を満たしていることを検証できないといここでは Java を用いた Web アプリケーションフ

う問題が起こっている．また，設計成果物の厳密

レームワーク Struts[2] と，その開発時に作成されな仕様が存在しないため，設計・実装間の変更影響

る画面遷移図，struts-conﬁg.xml について述べる．

を管理できず，一貫性を保証することができない．

2.1

そこで，本研究では Struts フレームワークにおWeb アプリケーションフレームワーク

一般に，Web アプリケーションは，ユーザ画面

ける画面遷移を対象に，メタモデリング言語 MOFのフォーム情報を入力として受け付け，リクエス（Meta Object Facility）[8][9] を用いて，成果物のトに応じた処理を実行し，結果を次の画面として仕様を形式的に定義し，追跡可能性（トレーサビリティ）を実現する手法を提案する．提案手法は，

Web ブラウザ上に出力する．ユーザに表示する画
面はあらかじめ静的に作成されている場合も実行(1) 個々の成果物の仕様であるメタモデルを定義し，各成果物が仕様を満たす状態で作成されて時に動的に作成される場合もあるが，いずれの場
合もその数は開発するアプリケーションの規模にいることを保証する．

比例して多くなる．そのため，Web アプリケーショ(2) 成果物間の依存関係のメタモデルも定義し，ト
レース情報自体も成果物と同様に管理し，成果ンを効率的に開発するためのアプリケーションフ

物の変更影響が及ぶ範囲を特定可能にする．

ションフレームワークは，画面間の遷移を効率的という 2 つの手順によって追跡可能性を実現し，新に管理し，Web アプリケーション全般に共通する

規作成のみならず変更が行われた際にも一貫して処理を受け持つことで，開発者が固有部分の開発

成果物を管理可能にする．提案手法自体は特定ののみに専念できるようにする．

フレームワークや成果物に依存するものではない

2.2

レームワークが用いられている．Web アプリケー

が [3]，本研究では Struts フレームワークにおけStruts 概略

Struts は Java 言語を用いた Web アプリケーショ
ン開発を支援するためのフレームワークであり，ア
クションサーブレットと呼ばれるコアエンジンがる画面遷移の設計・実装を対象にする．Struts はJava の Web アプリケーションフレームワークとして広く利用されている．一方で，Struts を用いた

画面遷移を含むアプリケーションの動作全体を制開発においては，設計成果物である画面遷移図と御する．Struts はアプリケーションの機能を次の実装成果物である設定ファイル struts-conﬁg.xml

ようなコンポーネントに分離させ，それらをアク-2-

conﬁg.xml を適切に設定することで，Web アプリ
1.

  

&

2.

 

   ケーションを開発することができる．



Beans

2.3

Struts を用いた Web アプリケーションでは  
struts-config.xml

struts-conﬁg.xml と呼ばれる設定ファイルが個々のコンポーネントを結合する．これは図 2 で表されるような XML ファイルとして記述され，以下      
 #   $ %   !   "3.

5.

struts-conﬁg.xml と画面遷移図

4.

の設定項目により画面遷移の基本部分を実現する．

• <form-bean>タグ

図 1: Struts における処理の流れ

アプリケーション中で利用されるアクション

ションサーブレットが統合する形で 1 つの Web アフォーム Beans の名前 name と実際のクラス名

プリケーションを構成する．

type を対応付ける．

• ユーザの入出力画面を表示する JSP ファイルやHTML ファイル• ユーザがフォームに入力した情報を格納するク• <action>タグ
リクエストを受けるパス path とそのリクエス
トを処理するアクションクラス type を対応付け

ラス（アクションフォーム Beans）

る．入力フォームのデータが渡される場合，そ• アクションフォーム Beans を参照し，ユーザののデータを格納するアクションフォーム Beans

リクエストに応じた処理を実行するためのアク

名 name とスコープ scope を設定する．また，ションクラスアクションクラスによる処理を介さず画面を遷アクションサーブレットの設定ファイルである

移させるには forward 属性を設定する．

struts-conﬁg.xml は，これらのコンポーネントの• <forward>タグ
アクションクラスが処理後に返すステータス

結合方法を定義している．

Struts を用いた Web アプリケーションの大まかな処理の流れは図 1 のようになる．まず，ユーザかname と遷移先 path を対応付ける．
例えば，図 2 は 3 つの画面（スタート画面

らのリクエストを受け付けると，アクションサー

welcome.jsp，ログイン画面 logon.jsp，認証済

ブレットは，設定ファイル struts-conﬁg.xml を参

み画面 mainMenu.jsp）の存在を仮定し，これらの照し，ユーザの入力情報を格納するクラス（アク画面間の遷移を表現している．<form-bean>はア

ションフォーム Beans）を決定してデータを保存

クションフォーム Beans を 1 つ用意し，1 つ目のする．次に，同様に struts-conﬁg.xml を参照する<action>は，パス/Logon からログイン画面への無条件の遷移を表す．また，2 つ目の<action>は，ことで，アクションサーブレットはリクエストを処理するためのアクションクラスを特定し，これパス/SubmitLogon に対する遷移先がユーザの入を呼び出す．呼び出されたアクションクラスは，ア

力情報とアクションクラスの処理結果に依存してクションフォーム Beans を参照することでユーザ決定され，結果が success ならば認証済み画面へ，の入力情報を取得し，目的の処理を行って，結果

failure ならばログイン画面へ振り分けられることを意味する．なお，どの画面がどのパスへリクをステータスとして返す．最後に，アクションサー
ブレットはアクションクラスから返されるステー

エストを送るかは画面を表す JSP ファイルへ記述

タスをもとに，struts-conﬁg.xml を参照して次のされ，struts-conﬁg.xml 中には記述されない．

遷移先を決定し，ユーザ画面として表示する．

このように，Struts では画面から画面へ直接遷移

つまり，開発者は，表示画面となる JSP ファイ

させるのではなく，一度アクションを処理するノー

ル，ユーザの入力情報を保存するアクションフォー

ドを経由してから次画面への遷移が行われる．そのム Beans，リクエストを処理するアクションクラ

ため，画面遷移を設計する際には最終的に struts-

スといった個々のコンポーネントを作成し，最後

conﬁg.xml として記述されることを意識した設計にアクションサーブレットの動作を決める struts--3-

デルとして表現される．しかし，仕様の中には自<struts-config>...
<form-beans> <!--アクションフォーム Beans の設定--><form-bean name="LogonForm"
type="org.example.LogonForm" /></form-beans>...
<action-mappings> <!--アクションクラスの設定--><action path="/Logon" forward="/logon.jsp" /><action path="/SubmitLogon"
type="org.example.LogonAction"
name="LogonForm"
scope="request" /><forward name="success" path="/mainMenu.jsp"/><forward name="failure" path="/logon.jsp" /></action><action path="/Logoff"
type="org.example.LogoffAction"><forward name="success" path="/welcome.jsp"/></action></action-mappings>...
</struts-config>

然言語で定義されたものや，必要以上に条件の緩いものが存在し，本来意図した内容よりも曖昧なモデルの作成が可能になる．そのため，作成したモデルが，管理したい情報を正しくかつ厳密に表現できていることを保証できないという問題がある．
そこで，モデルによって表現される意味論を形式的に定義し，意味解釈の曖昧さを取り除くためのメタモデルが必要となる．メタモデルは，モデ
ルとして記述すべき，あるいは記述すべきでない
内容を定義し，作成されたモデルが意図した情報を正しく表現していることを保証する．つまり，管理する情報に対する仕様としてメタモデルを定義することで，実際に作成されたモデルの正当性を検証できる．

3.2

図 2: struts-conﬁg.xml の例

作成すべきメタモデル

厳密なメタモデルを定義した上で管理しなければならない対象に，成果物とその依存関係がある．
org.example.LogonForm 

成果物は設計，実装に関わらずソフトウェア開発

  

において最も重要な生産物であり，要求される仕/Logonwelcom.jsp

logon.jspに，フレームワークを用いた開発を行う際には，フLogonForm

success/Logoff/SubmitLogonorg.example.LogoffAction様を満たすことが保証されなければならない．特 
mainMenu.jsp

レームワークの枠組みに従った成果物の作成が必

failure須となる．そのため，個々の成果物の仕様としてメ

success

タモデルを定義し，成果物を管理する必要がある．
org.example.LogonAction

一方，成果物間の依存関係（トレース情報）も厳密な仕様のもとで管理する必要がある．トレー

図 3: 図 2 に対応する画面遷移図

ス情報の仕様とは，互いに依存関係を保持した状が必要となる．例としては，図 3 のような画面遷態で管理しなければならない要素対の定義であり，

移図が考えられる．画面遷移図をどのような仕様

トレース情報はそのような要素対に実際に引かれで作成するかは Struts によって定められているわ

た関連である．つまり，依存関係をもつべき要素

けではないが，Struts を用いたソフトウェア開発

対をメタモデルとして定義することで，実際に存では画面遷移図の設計が struts-conﬁg.xml に強く在すべき依存関係が正しく保持されているかを検影響することに注意しなければならない．

証可能にする．

3.3

メタモデルと MOF

3

MOF と MOF リポジトリ

ここでは，ソフトウェア開発において，成果物

オブジェクト指向設計に基づいて自由にメタモとその依存関係のメタモデルを定義する必要性にデルを定義するための枠組みを提供するために，ついて述べ，本研究で着目したメタモデリング言

MOF（Meta Object Facility）[8][9] と呼ばれるメ
タモデリング言語が OMG（Object Management

語 MOF について紹介する．

3.1

Group）標準として提案されている．MOF は UML（Uniﬁed Modeling Language）[10] のクラス図に似た意味論をもつが，その表記法は定義されていメタモデルの重要性

ソフトウェア開発で扱われる情報は多様で，個々の情報はあらかじめ定められた記述仕様に従うモ

-4-




<<meta-model>><<meta-model>>

A

1

A

B

*

1
0..1

B
C

GenerateC  
OK




<<model>>
A1: A

B1: B

 

OK

<<model>>
A1: A

B1: B

C1: C






NG

A1: A

A



B

          #    !"  $%!" #      !"  



$

     !"  %#            <<model>>
B1: B

B2: B

 

 

MOF



C1: C

C

図 4: MOF リポジトリの生成とモデルの管理ないため UML クラス図を用いて記述されることが多い．UML が同じ性質をもつオブジェクトを

図 5: struts-conﬁg.xml の MOF メタモデル

UML クラスとして抽象化するのに対し，MOF は同じ性質をもつメタオブジェクトを MOF クラス

       として抽象化する．メタオブジェクトとは他のオ               
ブジェクトの性質を規定するためのオブジェクト: Action: FormBean

であり，UML クラスに相当すると考えられる．

++

また，MOF によって記述したメタモデル（以name: = "LogonForm"
type: = "org.example.LogonForm"降，MOF メタモデル）に対して，そのインスタンスであるモデルを蓄積・管理するためのリポジト

+
+
+
+

path: = "/SubmitLogon"
type: = "org.example.LogonAction"
name: = "LogonForm"
scope: = "request": Forward++

リを MOF リポジトリと呼ぶ．与えられた MOF

name: = "success"path: = "mainMenu.jsp": Forward++

name: = "failure"
path: = "logon.jsp"

メタモデルから MOF リポジトリの API を生成する標準規則として MOF to IDL Mapping[8] や

図 6: struts-conﬁg.xml のインスタンス例

MOF to Java Mapping である JMI（Java Meta-

分にのみ着目し，図 2，3 の例をもとにその概略をdata Interface）[6] が提唱されており，その実装として Medini[5] などが存在する．
図 4 で表されるように，ある成果物のメタモデ説明する．なお，実際の struts-conﬁg.xml の仕様

ルを MOF で定義することで，その MOF メタモ

しかし，ここで述べるメタモデル定義は Struts のデルに従ったモデルのみを管理可能なリポジトリ

基本部分をカバーしているため，詳細化を進めるをあらかじめ生成することができる．これにより，際にはそのまま利用可能である．

開発者がメタモデルに従わない誤ったモデルを成

4.1

は本論文で述べるよりも広く，それに伴って各メタモデルの定義もより詳細なものにする必要がある．

果物として作成した場合や，あるいは修正によっ

成果物のメタモデル

成果物のメタモデルとして，struts-conﬁg.xml とてメタモデルを満たせなくなってしまった場合に画面遷移図に対する MOF メタモデルを定義する．

も検出が可能となり，設計ミスを防止できるよう

4.1.1になる．例えば，図 4 中の開発者 C が作成したモ

struts-config.xml のメタモデル

デルは，クラス A1，C1 の間に関連が記述されてstruts-conﬁg.xml は XML ファイルであり，そのいるが，これはメタモデル中でメタクラス A，C

メタデータ構造は DTD （Document Type Deﬁni-間に関連が定義されないという仕様に矛盾する．

tion，文書定義型）を用いて定義されている．しかし，提案手法では全てのメタモデルを MOF で記述

4

Struts に対するメタモデル

し，成果物を MOF リポジトリの上で統一的に管理5 節で述べるトレーサビリティの実現手法に必要な，画面遷移図，struts-conﬁg.xml，およびそのすることを目的としているため，struts-conﬁg.xmlのメタモデルも MOF を用いて定義する．

トレース情報のメタモデルを定義する．ここでは，Struts フレームワークにおける画面遷移の基本部

図 5 は struts-conﬁg.xml のメタモデルのうち，
図 2 で表されるアクションフォーム Beans とアク-5-

ションクラスの記述に対応する部分である．同メ

ValueSpecification(from BasicActivities)

タモデルは XML 文書における要素をメタクラス

1+guard+targetとして，属性をメタクラスの属性として定義し，要+incomming

ActivityNode1(from BasicActivities) +source

素間の親子関係をメタクラス間の集約関係として

ActivityEdge*+outgoing (from BasicActivities)

1

保持する形で定義している．

DisplayNode+

メタモデルのインスタンスとして，図 2 相当部分

impl_file: JspName*

ActionEdge

ForwardEdge

constraints{+source is DisplayNode}{+target is ActionNode}constraints{+source is ActionNode}

ActionNode++

path: String
impl_class: ClassNameを図 6 に示す．この例では，図 2 中の<form-bean>+action
DisplayDefと 2 番目の<action>の記述に関する部分（図 3 の+form-bean
ActionFormBean+++

logon.jsp 画面から mainMenu.jsp 画面への遷移部

name: String
impl_class: ClassName
scope: String分）のみを抜粋している．図 2 と図 6 では表現形
式が異なるが，図 2 は図 6 で表されるモデルのテ

図 7: 画面遷移図の MOF メタモデル

キスト表現に過ぎず，意味として記述しようとし: DisplayNodeている内容は同一である点に注意されたい．

+: ValueSpecification

impl_file: = "logon.jsp"+

body: = "[failure]"   
4.1.2

: ActionFormBean

画面遷移図のメタモデル+++

画面遷移図の MOF メタモデルは UML のアク

name: = "LogonForm"
impl_class: = "org.example.LogonForm"
scope: = "request": ForwardEdge: ActionEdge  



: ActionNode

ティビティ図を拡張して定義する．図 7 上部の 3 つ++のメタクラスは，アクティビティ図のメタモデルの

path: = "/SubmitLogon"
impl_class: = "org.example.LogonAction"

中心部分を定義している．具体的には，状態遷移: ForwardEdge

を記述するために，ノード（ActivityNode）と辺: ValueSpecification+

body: = "[success]"  : DisplayNode（ActivityEdge）を定義し，ノードとノードを辺で+接続することによって遷移関係を表現する．また，遷移条件として，辺には遷移可能性を判定するた

impl_file: = "mainMenu.jsp"

図 8: 画面遷移図のインスタンス例

めのガード条件（ValueSpeciﬁcation）が関連付け

画面を表し，それを実現する JSP ファイルの情報られている．実際のアクティビティのメタモデルを保持する．一方，ActionNode は処理ノードを表

では，さらに意味論を厳密に定義するためにノー

し，このノードへのパスやリクエストを処理する

ドや辺の種類を詳細化したり，イベントのトリガ

アクションクラスの情報を保持する．また，テキを定義したりということが行われているが，ここ

ストボックスやボタンの表示レイアウトなど画面でそれらを全て説明することは不可能であり，本に関する詳細な設計を DisplayDef として遷移モデ

質からも外れるため省略する．

ルから分離させている．
さらに，これらのノードを接続する 2 種類の辺

2 節で述べたように，Struts では画面と画面を直接遷移可能な状態で結合するのではなく，アクションサーブレットを介して入力データはアクショ

ら処理ノード ActionNode へのリクエストを表す

ンフォーム Beans へ，処理はアクションクラスへ

辺 ActionEdge である．リクエストが送られる際振り分けられる．そして，その処理結果を受けてには，画面からユーザの入力情報が渡されうるの次の遷移画面が決定するという構造になっている．

で，辺 ActionEdge と関連させる形で ActionForm-

つまり，Struts に適した画面遷移図とは，画面とBean を定義し，実際にデータを保存するためのクラスに関する情報を保持させる．もう 1 つの辺はを定義する．1 つは，画面ノード DisplayNode か

画面を直接接続するようなモデルではなく，画面

ActionNode からの遷移を表す辺 ForwardEdge である．アクションクラスの処理結果によって遷移先は複数存在しうるので，その場合は遷移条件をから処理ノードへ接続し，処理ノードから次画面へ接続するという，図 3 のようなモデルが良いと考えられる．そこで，提案するメタモデルでは画面

ValueSpeciﬁcation として記述し，複数の ForwardEdge によって遷移先を分岐させる．

と処理ノードをモデル化するために DisplayNodeと ActionNode を定義している．DisplayNode は

メタモデルのインスタンスとして，図 3 に相当-6-Asub : RefElement+

ref: = "ValueSpecification"<<meta-model>>Asub_X_Trace: Trace+<<meta-model>>detail: StringA

ValueSpecification.body → Forward.name

BC+

ref: = "ForwardEdge"++

detail: String

BX_Trace

RefX

RefC

CY_Trace

RefY

XY
struts-config.xml-struts-config.xml

           

X : RefElement

A_X_Trace: Trace

A : RefElement<<meta-model>>

RefB



ref: = "Forward"<<model>><<model>>
B1: B

B_XY_Trace: Trace
B : RefElement+

ref: = "DisplayNode"

X1: X

C1: C





<<model>>C : RefElement+

ref: = "ActionNode"

B1: B

C_Y_Trace: Trace
+

Y1: Y
Y2: Y

C2: C

+ detail: String
DisplayNode.impl_file → Action.forward
DisplayNode.impl_file → Forward.path

Y : RefElement

detail: String
ActionNode.path→ Action.path
ActionNode.impl_class → Action.type

+

C1: C
C2: C

ref: = "Action"<<model>>X1: X 

Y1: Y
Y2: Y





D_YZ_Trace: Trace
D : RefElement+

ref: = "ActionFormBean"+ detail: String
ActionFormBean.name→ FormBean.name
ActionFormBean.name→ Action.name
ActionFormBean.impl_class → FormBean.type
ActionFormBean.scope→ Action.scope

Z : RefElement+

図 11: 成果物の正当性管理

ref: = "FormBean"

ス情報を保持しうるようになっている．
例えば，図 9 の上 2 つの依存関係は，画面

図 9: トレース情報のメタモデル

遷移図メタモデル中の ForwardEdge が，strutsRefElement++source0..*
ref: String +target

Trace
+

conﬁg.xml メタモデル中の Forward に影響を与え+subtrace

detail: String

ることを意味する．そして，この依存関係をより詳0..*細化する形で，ガード条件 ValueSpeciﬁcation がForward に影響を与えることを定義している．な

図 10: トレース情報のメタメタモデル

お，ValueSpeciﬁcation の body 属性が Forward のする部分を図 8 に示す．図中では遷移条件として便宜上 2 つの ValueSpeciﬁcation を定義しているが，ValueSpeciﬁcation は抽象クラスであるため，厳name 属性に影響する，というような属性レベルでの詳細な依存関係は，detail 属性として記述する．

メタモデルに基づくトレーサビリティ
の実現手法

5

密にはそのサブクラスのインスタンスが Forward-

Edge と関連付けられることを断っておく．
また，ここでも図 3 と図 8 で表現形式が異なる

先に定義した 3 つのメタモデルを用いて，Struts

が，struts-conﬁg.xml の場合と同様に図 3 は図 8 でフレームワークにおけるトレーサビリティを実現

表されるモデルの一表現に過ぎない．ただし，直する手法を述べる．提案手法は，各メタモデルに

接図 8 のようなモデルを記述するのは困難である

対する MOF リポジトリをあらかじめ生成し，• 個々の成果物の正当性管理• トレース情報を用いたトレース管理を行うことによってトレーサビリティを実現する．

ため，開発者はモデリングツール上で図 3 のような画面遷移図を描き，その背後で厳密な意味定義
として図 8 が作成されることを想定している．

4.2

また，トレーサビリティの実現により，成果物間トレース情報のメタモデルの一貫性保証が可能となる．

次に，成果物間の依存関係（トレース情報）に対しても MOF メタモデルを定義する．ここでは，

5.1

個々の成果物の正当性管理

集合へ影響を与えるような n 対 n の依存関係を定3 節 で 述 べ た よ う に ，画 面 遷 移 図 と strutsconﬁg.xml に対して定義した MOF メタモデルか義することを目指している．画面遷移図と struts-

らそれぞれ対応する MOF リポジトリを生成可能

conﬁg.xml のトレース情報に対するメタモデルは
図 9 のように定義し，このメタモデルをさらに一である．生成されたリポジトリはそのメタモデル

般化すると図 10 のような構造になっている．なお，者が作成・修正したモデルが仕様を満たさない場

ある依存関係がより詳細ないくつかの依存関係で合には検出が可能となる．つまり，図 11 で表され構成される，というような構造的な関係を定義でるように，開発者が編集するモデルと，そのメタ

きるようにするため，トレース情報は別のトレーモデルとの縦方向の関係を調べることで，成果物一方のモデル要素集合の変更が他方のモデル要素を満たすモデルのみを管理可能であるため，開発-7-

<<meta-model>><<meta-model>>

A

B

RefB
RefC

C

 

RefX

CY_Trace

RefY-struts-config.xml            

C1: C

RefB1

B1X1: BX_Trace

RefX1

C2: C

RefC1

C1Y1: CY_Trace

RefY1

RefC2

C2Y2: CY_Trace

RefY2



まとめ

X

本論文では，Struts フレームワークにおける画Y
struts-config.xml



面遷移図と struts-conﬁg.xml に対して MOF メタ

モデルを定義し，さらにその依存関係もメタモデ<<model>><<model>><<model>>B1: B

6<<meta-model>>BX_Trace

X1: X

Y1: Y

ルのもとで管理することで，トレーサビリティを

Y2: Y

実現する手法を提案した．提案手法は，Struts フ レームワークの全仕様をカバーしているわけではないが，ここで定義した MOF メタモデルは今後

図 12: 成果物間のトレース管理

詳細化を進める上での基礎となる．

がその仕様を満たしていることを検証可能である．

今後は各メタモデルのさらなる詳細化を進め，成これにより，リポジトリに蓄積・管理されている

果物の一貫性を保証しながら開発を行うためのモ

画面遷移図や struts-conﬁg.xml が，フレームワー

デリングツールを実装し，具体的な評価実験と考クの仕様を満たした状態で作成されていることが察を行う予定である．

保証できる．

5.2

参考文献

トレース情報を用いたトレース管理[1] Akehurst, D. H. and Kent, S.: A Relational Approach to Deﬁning Transformations in a Metamodel, UML ’02: Proceedings of the 5th International Conference on The Uniﬁed Modeling Language, London, UK, Springer-Verlag, pp. 243–
258 (2002).

4 節で定義したトレース情報のメタモデルに対して，トレース情報を蓄積・管理する MOF リポ
ジトリを生成可能である．このとき，図 12 で表されるように，画面遷移図と struts-conﬁg.xml，お[2] Apache Struts
apache.org/.

よびそのトレース情報がメタモデルに基づいて正しく蓄積されていると仮定する．すると，画面遷

Project:

http://struts.

[3] 我妻智之，神谷慎吾，大平直宏，松下 誠，楠本真二，井上克郎：メタモデルに基づくトレーサビリティ技術の提案，電子情報通信学会信学技報， Vol. 105,
No. 270, pp. 25–30 (2005).

移図に変更があった場合には，トレース情報を参照することで，struts-conﬁg.xml への影響範囲を特定可能である．つまり，開発者が編集する成果
物のモデルと，そのトレース情報との横方向の関係を調べることで，個々の成果物の変更影響を管理し，トレーサビリティを実現することができる．
なお，トレース情報は，開発者ではなくツール[4] Bondé, L., Boulet, P. and Dekeyser, J.-L.:
Traceability and Interoperability at Diﬀerent
Levels of Abstraction in Model Transformations, Forum on Speciﬁcation and Design Languages(FDL’05), Lausanne, Switzerland (2005).
[5] IKV++ Technologies AG: http://www.ikv.de/.

が自動的に作成・管理することを想定している．実[6] Java Metadata Interface (JMI): http://java.
sun.com/products/jmi/.

際の開発においては，図 12 のように正しくトレー
ス情報が管理されている状況だけでなく，一貫性[7] JavaServer Faces (JSF): http://java.sun.com/
j2ee/javaserverfaces/.

が保証できない状況も考えられる．例えば，設計成果物である画面遷移図のみが作成された場合には，対応する struts-conﬁg.xml が作成されていないた
め，メタモデルを満たす形でトレース情報を作成できない．あるいは，画面遷移図に変更や削除があった場合にも，その影響を受ける struts-conﬁg.xmlに修正が行われていないという状況が考えられる．
しかし，このような場合にもツールはメタモデルに矛盾した状態であることを検出可能であるため，開発者に修正を強要し，一貫性を保つことができる．

-8-c[8] Object Management Group:
Meta Object
Facility (MOF) Speciﬁcation, Version 1.4(2002). http://www.omg.org/cgi-bin/apps/
doc?formal/02-04-03.pdf.
[9] Object Management Group:
Meta Object
Facility (MOF) 2.0 Core Speciﬁcation (2003).
http://www.omg.org/cgi-bin/apps/doc?ptc/
04-10-15.pdf.
[10] Object Management Group:
UML Superstructure Speciﬁcation, Version 2.0 (2005).
http://www.omg.org/cgi-bin/apps/doc?
formal/05-07-04.pdf.