実験結果

本実験においては，まず，図5.2のゴールモデルに対して，本研究で導入する整形プロセス を適用した．整形プロセスを適用後のゴールモデルを図5.7に示す．

整形プロセス適用後のゴールモデルにおいては，メインエディタなどの各ビューを構成する Control loopや，それらが共通で利用するControl loopなど，合計10個のControl loopが同 定された．整形前後のゴールモデルの構成要素の比較を表5.3に示す．表5.3からは，まず，

図5.7.k-toolに対する整形後のゴールモデル

表5.3.整形前後におけるゴールモデルの構成変化

整形前 整形後 ゴール数（# Goals） 120 168 エンティティ数（# Entities） 15 28

Concerns関係数（# Concerns） 39 40

# Concerns / # Entities 2.6 1.43

Control loop数（# Control loops） – 10

整形後にゴール数とエンティティ数が増加していることが分かるが，これは，ゴールに関して は，共通ゴール記述の追加やCollectタイプゴールの追加によるものであり，エンティティに 関しては，プロセス変数の新たな追加によるものである．その一方で，表5.3からはエンティ ティあたりのConcerns関係数(#Concerns/ #Entities)は減少していることも確認できる．これ

は，Control loop単位でプロセス変数，つまりエンティティへのアクセスを限定することによ

り，各Control loopにおけるエンティティに対する責務が明確化されたことを示しているとい

える．実際に，整形前のゴールモデル上でConcerns関連が多く定義されていたエンティティ である「ダイアグラム」（5本）や「要素」（7本）については，整形後は，主要ゴール「KAOS モデルが管理されている」内のサブゴールからの1本のConcerns関連に集約されていること を確認することができた．

続いて，図5.7の整形後ゴールモデルをgocc_{へ入力として与えた．}gocc_{から得られた情} 報として，Control loopの階層構造情報と階層構造を可視化したものを図5.8に示す．図5.8 に表示されているコンポーネントは各Control loopを表現しており，合計10個のControl loop と，Control loop間の階層構造を確認することができた．各Control loopの責務は表5.4に示 すとおりである．

goccが出力した競合リストにおいては，同一のControl loop利用に関する競合の可能性も 出力されたが，エンティティに関する競合は検出されないことを確認することができた．同一 のControl loop利用に関する競合についても，k-tool（ここではc-tool）はユーザからの入力に よるツールであり，出力された可能性のある状況に対しても，複数のControl loopが同時に同

一Control loopを利用するものはないと判断したため，本実験においては，競合に対応するた

めの設計は施さないこととした．

続いて，goccから得られた情報をもとにc-toolを実装した．本実験においては，以下の実 装方針により，本研究で提案するプログラミングフレームワーク上にControl loopにより構成

されるc-toolを実装した．まず，各Control loopにおいては，コンフィギュレーション上では

ManageMainEditor Uses ManageKAOSModel ManageMainEditor Uses ManageDiagramActions ManageMainEditor Uses ManageEditActions ManageMainEditor Uses ManagePrintAction ManageTreeView Uses ManageKAOSModel ManageTreeView Uses ManageProjectActions ManageTreeView Uses ManageDiagramActions ManageTreeView Uses ManageEditActions ManageTreeView Uses ManagePrintAction ManageMenuBar Uses ManageProjectActions ManageMenuBar Uses ManageDiagramActions ManageMenuBar Uses ManageEditActions ManageMenuBar Uses ManagePrintAction ManageToolBar Uses ManageProjectActions ManageToolBar Uses ManageDiagramActions ManageToolBar Uses ManageEditActions ManageToolBar Uses ManagePrintAction ManageMainWindow Uses ManageMainEditor ManageMainWindow Uses ManageTreeView ManageMainWindow Uses ManageMenuBar ManageMainWindow Uses ManageToolBar

ManageProjectActions Uses ManageKAOSModel ManageDiagramActions Uses ManageKAOSModel ManageEditActions Uses ManageKAOSModel ManagePrintAction Uses ManageKAOSModel

図5.8.c-toolのControl loop間階層構造（上段：goccにより生成される階層構造情報，下段：

コンポーネント図による可視化表記）

表5.4.同定された各Control loopの責務．Control loop名にはAnalyze & Decideタイプのゴー ルに割り当てられたオペレーション名を用いている．

Control loop名 責務

ManageMainWindow メインウィンドウを管理する．分割ペインに対する入力に基づいて，

各部品のサイズを変更したり，非表示にする．ステータスバーの表示 についても責務を持つ．

ManageMainEditor メインエディタ部を管理する責務を持つ．

ManageTreeView ツリービュー部を管理する責務を持つ．

ManageMenuBar メニューバー部を管理する責務を持つ．

ManageToolBar ツールバー部を管理する責務を持つ．

ManageProjectActions ファイルへの保存など，プロジェクトに関連する操作を

提供する責務を持つ．

ManageDiagramActions ダイアグラム（図）に関連する操作を提供する責務を持つ．

ManageEditActions コピー，ペーストなど，編集に関連する操作を提供する責務を持つ．

ManagePrintAction 印刷操作を提供する責務を持つ．

ManageKAOSModel KAOSモデルデータを管理する責務を持つ．

Collect，Analyze & Decide，Actタイプの3種類のコンポーネントが同定されるが，本実験の ようなGUIアプリケーションの場合は，マウスからの入力と処理結果の表示が同一のGUI部 品である場合が多いことと，同様の理由から，情報収集部であるCollectタイプと，出力処理 部であるActタイプの進化のタイミングが異なる可能性が少ないことから，本実験において

は，Control loopの構築にあたっては，3つのタイプのコンポーネントを明示的に分離して構築

するのではなく，Analyze & Decideタイプのコンポーネントを必須のコンポーネントとして，

特に必要な場合を除いて，Collect，Actタイプの責務も同コンポーネント上に実装することと した．また，情報収集の手段としては，マウスイベントの他に，モデル要素の状態を観察する ためにデザインパターンの一つであるObserverパターン[50]を実装し，各Analyze & Decide タイプのコンポーネントは情報収集対象のObserverインタフェースを実装することで，対象 の変化が観測できるように実装した．また，他Control loopの利用に関しては，利用Control loopのAnalyze & Decideタイプのコンポーネント上にサービス提供用のpublicメソッドを用 意し，同メソッドを呼び出すスタイルで実装した．これは，今回実験対象としたk-toolのよう な，ユーザからの入力に応じて動作するGUIアプリケーションにおいては，Control loop間で の競合が発生することは少なく，従って，Control loopの優先順位を制御する機会が少ないと 判断したことによるものである．

このような実装方針に基づいて，c-tool を実装した．具体的には，図 5.8 に示される各

Control loop内に，同名のクラスをControl loopを制御するクラスとしてそれぞれ実装し，こ れらのクラスが必要に応じてk-toolの構成部品クラスを呼び出すことで，各Control loopを構 築した．

各Control loopを実装後，それらを4章で導入したプログラミングフレームワーク上で動作

させることにより，Control loopにより構成されるc-toolが問題なく動作し，要求された機能 を提供していることが確認できた．