第 6 章
考察
本章では，ソフトウェア進化の支援を目的として本研究で提案した開発プロセスに対して，
実験結果をもとに有効性と適用範囲を考察する．まず，1章で定義した各要件に対して提案手 法を評価し，続いて本開発プロセスの適用範囲について論じる．その後，提案する開発プロセ スの自動化の可能性について議論する．
このような特性を利用することで，4章の清掃ロボットに対する実験結果や，5章の実験4 の影響範囲分析実験の結果が示すように，提案する開発プロセスでは，進化時に要求の変化に よってシステム上に生じる影響の範囲をゴールモデル上で分析，限定化することが可能であっ た．例えば，5章のk-tool構築実験では，従来のMVCモデルに従った場合には，進化2や進 化3のようなModelの変更を伴うような進化に対して，変更影響がModel，View，Controlの すべての要素に及んだ一方で，提案手法では変更箇所がゴールモデル上で同定されるControl loop内に限定されることが確認された．また，4章の清掃ロボットに対する実験からは，gocc のコンフィギュレーションの生成機能と差分検出機能を用いることで，変化が与える影響を効 果的に明確化できることも確認できた．
Control loopによるモデリングを用いた場合，変数に対する責務も同定することができる．
Control loopは，入力変数，操作変数などのプロセス変数を持つモデルであることから，Control
loopをモデリングの単位とすることで，各Control loopが参照，操作する変数の範囲，つまり 変数に対する責務を同定することが可能となる．例えば，Collectタイプのゴールに関与する エンティティに対しては情報収集，つまりread権限のアクセスに相当し，Actタイプのゴール が関与するエンティティに対しては，操作変数であれば処理，つまりwrite権限に相当するア クセスが発生することとなる．変数に対する責務が同定できることは，変数に対して発生する 影響範囲，つまり競合の可能性を検出できることを意味している．本研究では，この競合の発 生に対しては，2つのConflictパターンを導入し，その検出を自動化する機能をgoccに付与 している．このような競合をゴールモデル上で検出し，必要に応じて対処しておくことは，進 化時における他構成要素に対する変更の影響を防ぐという意味で有益であると考えられる．
影響分析精度の向上に対する提案手法の限界としては，次の2つが考えられる．1つは，本 開発プロセスにおいては上述の通り，主要ゴール自体の追加・削除は，Control loopの追加・
削除に該当し，主要ゴール内の変更については，Control loopの振る舞いの変更に該当するが，
Uses関係における被利用側のControl loopの変更については，利用側のControl loopにおい て変更が必要かどうかを確認する必要がある．これは変更影響がControl loopの外部に及ん でいることを意味している．ただし，このような変更についても，提案手法のようなControl loop同定・構築法に基づいている場合，被利用側Control loopの出力となる提供サービスに変 化があるかどうかを検査することで，変更の影響が利用側に及ぶかどうかを判断することがで きる．また，提案手法のようにUses関係を明確に定義しておくことにより，ゴールモデル上
でControl loop間の影響範囲を特定することもできる．
もう１つは，5章の実験4の影響範囲分析実験でも示されたように，Control loop内での影 響範囲分析に関しては，ゴール記述の差分情報から設計者が判断する必要がある点である．こ の点においては，各Control loopが過度に大きくならないように主要ゴールを同定する工夫が
必要と考えられる．この点については，Control loopの粒度を決定するようなドメイン固有の 知識に基づいたガイドラインの提供が有効であると考えられる．
6.1.2 コード複雑化の抑制
5章で示した清掃ロボットの進化実験（実験5）からは，提案するゴールモデル整形に基づ
いた複数Control loopの設計・実装により，従来の集中型の制御方式と比較して，既存コード
の修正コストとCyclomatic数により計測されたコードの複雑さが軽減されていることが確認 できた．また，5章のk-tool進化実験においても，提案手法においては，機能を横断するよう な共通クラスがなく，Control loop内での限定されたコードの修正となるため，進化を繰り返 すことによるコード複雑化の抑制がなされていることが確認できた．Bhattacharya [54]らは，
ソフトウェア進化のための指標となるメトリクスの提案とともに，「高い集積性を持つソフト ウェアモジュールは修正コストが低い」という仮説を立て，その仮説が有効であることを実 証している．本提案手法では，複数のControl loopを抽出することで，各Control loop内に Collect，Analyze，Decide，Actという情報収集から処理の実行までの一連の振る舞いを凝縮 し，構成要素間の依存関係の最小限化を図ることでシステム構成要素のモジュール性を高めて いるが，これにより既存コードの修正頻度が縮小されることは，Bhattacharyaらの立証した仮 説を裏付けていると言える．また，5章の2種類のソフトウェアの進化実験で示されたよう に，提案手法を用いた場合，機能追加を既存Control loopの修正ではなく，新規Control loop の追加により実現できる場合がある．このような既存コードの修正を避ける機能追加も，修正 コストを軽減していると言えよう．
4章で導入したControl loopの実装法では，進化の種類による変更の影響を限定化できると いう効果がある．本研究では，Control loopのアクティビティから，Control loopを構成する コンポーネントを，Collectタイプ，Analyze & Decideタイプ，Actタイプの3種類に分類し たが，Collectタイプ，Actタイプは環境に関与，作用するコンポーネントであり，Analyze &
DecideタイプはControl loopの状態遷移を管理し，適切な制御を決定するコンポーネントに
該当する．従って，例えば，プラットフォームやセンサ，アクチュエータなどの環境変更を扱 う進化であれば，外部とのインタフェースとなるCollectタイプ，Actタイプの必要箇所を変 更すればよく，要求の変化に対しては，主にAnalyze & Decideタイプが変更対象となり，必 要に応じて，Collectタイプ，Actタイプのコンポーネントを変更することになる．従って，本 研究で導入するControl loopモデルは，進化の要因の観点からも変更の影響を限定化し，これ によりコードの複雑さを抑制していると考えることができる．
提案手法の限界としては，複雑さを十分に抑制するために，Control loopの粒度に関して注
意を払う必要がある点が挙げられる．もし，複数の機能要求を同一のControl loop内に包含さ せた場合，例え影響範囲がControl loop内に閉じていたとしても，他方の機能要求の実装部分 に影響が及ぶ可能性があるからである．この点については，前節の影響分析精度の向上に関す る議論でも取り上げたように，Control loopの粒度を決定するようなドメイン固有の知識に基 づいたガイドラインの提供が有効であると考えられる．