表5.12.清掃ロボットに対するインクリメンタルな進化の計測結果．#Classes欄括弧内の“M:”
および“A:”ラベルは，それぞれ修正クラス数，追加クラス数を表わす．
■ベースライン手法
Ver 追加機能 #CLs #Classes ∆Ve CMC LOC
01 初期開発 1 6 – – – 562
02 バッテリー管理機能 1 9 (M:2, A:3) 5 638 711 03 新たな清掃手段(Pick up) 1 10 (M:2, A:1) 1 135 818 04 積載量管理機能 1 14 (M:4, A:4) 6 942 1,106 05 新たな清掃手段(Wipe) 1 15 (M:1, A:1) 1 277 1,150 06 障害物回避機能 1 15 (M:3) 5 1,447 1,383 07 失敗時の清掃手段切り替え 1 15 (M:4) 4 458 1,450
■提案手法
Ver 追加機能 #CLs #Classes ∆Ve CMC LOC
01 初期開発 2 7 – – – 537
02 バッテリー管理機能 3 10 (M:3, A:3) 5 308 733 03 新たな清掃手段(Pick up) 3 12 (M:1, A:2) 1 80 836 04 積載量管理機能 5 19 (M:3, A:7) 2 96 1,256 05 新たな清掃手段(Wipe) 5 20 (M:1, A:1) 1 89 1,300 06 障害物回避機能 5 20 (M:2) 5 698 1,503 07 失敗時の清掃手段切り替え 5 20 (M:4) 4 205 1,557
ここで，Ve は，進化eにおいて既存クラス上に新たに定義された変数および，進化eにおい て取り得る値が追加された変数の集合であり，Meは，進化eの直前に既存クラス内に定義さ れていたメソッドの集合である．また，cij は次のような二値関数である．
cij =
{ 1 ifviはメソッドmj 内に出現する 0 ifviはメソッドmj 内に出現しない
5.9.2 実験結果
実験結果を表5.12と図5.13に示す．表5.12からは，提案手法においてはControl loopが 増えるタイミングで追加するクラス数とコード行数（LOC）が増加する傾向にあるが，一方の ベースライン手法においては，修正コスト（CMC）が提案手法よりも多く要することが確認さ れた．例えば，ver02，ver06，ver07の構築時には，ベースライン手法は提案手法の約2倍の修 正コストを要していた．これは，ベースライン手法で用いる集中型制御方式においては，現在
0 10 20 30 40 50 60 70 80
ver01 ver02 ver03 ver04 ver05 ver06 ver07 Baseline
Proposed method
0 1 2 3 4 5 6
ver01 ver02 ver03 ver04 ver05 ver06 ver07 Baseline
Proposed method
図5.13.Cyclomatic値: (左)最大値，(右)平均値
の状況を判断するための条件分岐が１つのメソッドに集中化する傾向があり，進化，つまり要 求の変化時に，同メソッドが変更される可能性が高いことによるものである．一方で，提案手 法のような開発スタイルでは，同様の条件分岐は，扱う機能や対象により，該当するControl loopに分散化されることとなる．
図5.13の実験結果も同様の特徴を示している．Cyclomatic数はソフトウェアモジュールの 複雑さを表現したものであり，コード内の分岐数の増加に伴い値は大きくなる．図5.13から は，ベースライン手法において各進化のたびにCyclomatic数が増加していることが分かる．
これは集中化された制御部において各進化の都度，機能追加に伴い新たに定義される状態を扱 うための条件分岐が追加されたことによるものである．一方，同図からは，提案手法における
Cyclomatic数が抑制されていることが分かる．これは各進化におけるコード上の変更が集中
化されず，Control loop単位で局所化しており，Cyclomatic数が最大となるメソッドが進化後 も常に同一というわけではないことによるものである．
図5.13の右側のグラフはCyclomatic数の平均値を計測した結果を示したものである．この グラフからも，提案手法においてはCyclomatic 数が抑制されていることが分かる．これは，
ベースライン手法では現在の状態を把握するために複雑な分岐が必要となることと，提案手法
ではControl loopごとに関心事に基づいた状態把握がなされるため，条件分岐が複数のメソッ
ドに分散化されていることによるものである．
5.10 まとめ
本章では，提案する開発プロセスの有効性を評価するためにGUIベースのモデリングツー ルと制御システムを対象ソフトウェアとした5種類の進化実験と，その結果について述べた．
まず，実験1〜実験4として，GUIベースのモデリングツールとして，KAOSモデリング
ツールk-toolを対象としたソフトウェアの進化を扱った．実験1からは，提案する開発プロセ スを適用することで，システムに対する要求が記述されているゴールモデルを，Control loop を包含するゴールモデルに整形することが可能であり，整形後のゴールモデルから得られた 設計支援情報をもとに，実用化されているシステムをControl loopにより構成されるシステ ム構成により実装できることが確認できた．実用化されているシステムにおいては，多くの Control loopが構成要素として同定されるが，goccにより生成されるControl loop間の階層 構造情報は，システムにおけるControl loop間の関係を把握するのに有効であった．
実験2では，実験1により実装されたソフトウェアシステムが提案手法により効果的に進 化ができることを確認した．本実験では，従来のk-toolのシステム構成に対しても同様の進 化実験を実施したが，従来のMVCモデルに従ったGUIシステムにおいては，Model，View，
Controlに変更が及ぶような進化に対しては，進化の影響が広く及んでしまうのに対して，提案
手法で用いるControl loopモデリングでは，変更箇所をゴールモデル上で同定されるControl loop内に限定することができることが確認できた．
実験3では，複数の被験者が整形したゴールモデルから，ほぼ同様のControl loopとControl loopの階層構造が得られることが確認され，整形プロセスの妥当性を確認することができた．
ただし，一部の被験者において，肥大化する可能性のあるControl loop を構築したことは，
Control loopの進化に適した粒度に関する議論が必要であることを示しているといえよう．
実験4では，提案する開発プロセスがソフトウェア進化時の影響分析に対して有効である ことが確認できた．これは，ゴールモデル上での変更箇所から，修正の可能性のあるControl loopを検出することが可能であるという特徴によるところであると考えられる．この特徴は，
特にシステムが大規模になり，Control loopの数が増加した場合に，影響範囲を限定するとい う意味で有効であると考えられる．ただし，実験結果からも示されたように，各Control loop 内での影響の同定は，依然設計者のスキルに依存する部分が残る．従って，設計者がControl loop内での進化の影響を同定するための，更なる支援情報の提供が必要と考えられる．
最後に，実験5として，制御システムでの提案手法適用を想定した清掃ロボットシミュレー タ上での進化実験結果も示した．実験5からは，提案手法に従って抽出したControl loop単位 でシステムを構築した場合，従来の集中型のControl loopの場合よりも，実装コードの変更箇 所と進化によって増加するコードの複雑さを軽減できることが確認できた．
以上の実験結果から，更なる改善の余地はあるものの，提案する開発プロセスが，GUIベー スのアプリケーションや制御システムなどの複数ドメインのシステム進化に対して有効である ことが確認できた．
第 6 章
考察
本章では，ソフトウェア進化の支援を目的として本研究で提案した開発プロセスに対して，
実験結果をもとに有効性と適用範囲を考察する．まず，1章で定義した各要件に対して提案手 法を評価し，続いて本開発プロセスの適用範囲について論じる．その後，提案する開発プロセ スの自動化の可能性について議論する．