自己適応システム（Self-adaptive systems）[121, 35, 122]とは，環境の変化を検知すること で状況を判断し，自発的に振舞いを変化させることで，状況変化に対応できるシステムであ り，状況変化への対応，つまり適応のための振舞いや構成変更を実現する意思決定メカニズム が組み込まれているシステムを指す．そのような背景から，本研究でシステム構成要素として
利用したControl loopを自己適応システムの振舞いモデルとして位置づける研究も少なくない [123, 124]．自己構成（Self-configuration），自己修復（Self-healing）などのソフトウェアの自 律化を掲げるオートノミックコンピューティング（Autonomic computing）[36, 125]の研究に おいても，制御ループと同様の概念がMAPE (Monitor, Analyze, Plan, Execute) loopとして用 いられている．
本節では以降，自己適応システムに関する研究動向を，本研究に関連する，要求記述，アー キテクチャ，フレームワーク，検証技術の観点から述べる．
7.4.1 要求記述に関する議論
本研究では，自己適応システムの進化を支援する開発プロセスを実現するために，進化の要 因となる要求の変化が分析・同定可能である要求記述に着目したが，自己適応システムのよう な動的な適応を扱うシステムにおいては，適応のタイミングと適応後の動作を決定するため に，システム自身が要求の達成状況を管理する必要がある．従って，自己適応システムにおい ても，本研究のアプローチ同様に，要求記述はシステムにおいて核となるモデルであると言 え，自己適応システムの研究領域では要求分析に関するものや要求記述を扱った研究が少なく ない．
Fickasら[126]は，環境の変化に対してもシステムを安定稼働させるためには要求の監視が
重要であるとの主張から，システム動作中の要求監視法を提案している．Salifuら[127]は，
環境の変化を検出するために必要なモニタリングに関する要求と，変化に適応して要求を満足 するために必要な振舞い切替（スイッチング）要求に着目し，これらを要求記述上で仕様化す る手段を提案している．この研究では，適応時の振舞いに対する要求の記述に，システム開発 の対象となる領域，システム，システムに対する要求とこれらの間の関連を記述する問題フ
レーム（Problem Frames）[128]を用いている．Chengらは，不確実な状況を記述するために
RELAX言語[129]を提案している．このRELAX言語は，要求記述に用いる自然言語に対し
て，不確かさを記述する固有のオペレータを導入することで時制を緩める（relax）ことを目的 としたものであり，従来の「．．．すべきである（shall）」の記述に，「いずれは（eventually）」，
「なるべく早く（as early as possible）」などを導入することで，適応に関する要求記述を可能に している．
自己適応システムの要求記述モデルとして，本研究で用いたKAOSや，i* [130]などのゴー ルモデルを用いる研究も少なくない．Chengら[131]は，彼女らが提案したRELAX言語を用 いて自己適応システムに対するゴールモデルの構築法を提案している．Lapouchnianら[132]
も自己適応システムに対する要求をゴールモデル上に記述し，各状況においてどの振舞いが可
能であるかの決定と最適な振舞いの選出にこのゴールモデルを利用している．Landtsheerら
[133]は，制御システムを対象としたイベント駆動型の仕様生成手法を提案している．この手
法は，ゴールモデルから表型記述言語に基づいた仕様を生成するものである．Wangら[134]
は，レガシーなソフトウェアシステムに高い可変性（variability）を付与することを目的とし て，ゴールモデルを用いたシステムの監視・再構成手法を提案している．これらのアプローチ はいずれも，ゴールモデルをシステムの振舞い記述や振舞いの決定のために用いたものであ る．Chenら[135]は，Webアプリケーションの生存性（survivability）を保証することを目的 として，ゴールモデルに基づいた自己適応手段を提案している．この手法では，ゴールモデル 上の各ゴールに付与された引機能要求に対するrelative parent valuesと呼ばれる貢献度をもと に，各状況においてどのゴールを優先しすべきかを決定し，コンフィギュレーションを決定す る．この手法でもControl loopの概念を採用しているが，コンフィギュレーションの変更タイ ミングを決定するために利用するという，従来のシステム制御としての利用法であり，本研究 のようなコンフィギュレーション決定のためのものではない．
本論文で導入した開発プロセスはソフトウェアシステムの進化を対象としたものであるが，
ゴールモデルから実装コードへの開発プロセスが，自己適応システムの実現メカニズムに対応 すると考えることもできる．例えば，要求や環境の変化は，ゴールモデルの変更に対応し，変 化がシステム構成の変更，つまりコンフィギュレーションの変更を触発し，実装コンポーネン トを切り替えることにより，環境変化に適応すると考えると，両者のプロセスは類似している．
7.4.2 アーキテクチャに関する議論
次に，自己適応システムのアーキテクチャに関する研究動向について述べる．自己適応シス テムやオートノミックコンピューティング[36, 125, 37]を実現するためのアーキテクチャモデ ルとしては，複数のコンポーネントを接続したモデルが有効であると考えられている．
KramerとMageeは，自身の振舞いを管理可能なシステムが取るべきアーキテクチャとし
て，階層構造からなる3層アーキテクチャモデル[5]を提案している．このアーキテクチャモ デルは，ロボティクスの分野で提唱されたGatの3層モデル[136]を応用したものであり，目 的に応じた行動プランを決定する最上層のゴール管理層（Goal management layer）と，振舞い を実現する最下層のコンポーネント制御層（Component control layer），さらにこれらの2層 の中間に位置し，現在の状況と目的の達成状況からコンポーネントの構成切り替えを決定する 変更管理層（Change management layer）の3層により構成され，各階層がそれぞれの抽象度 に応じた適応を扱うことが特徴である．この3層アーキテクチャモデルは，現在多くの自己適 応システムに関する研究において基本アーキテクチャモデルとして用いられている．Taylorら
（ゴールの変更）意思決定
コンフィギュレーションの変更
新しいアクション群，
コンフィギュレーション 状態の通知
プランの変更要求 新しいプラン群
振舞いの変更
図7.1.3層アーキテクチャモデル[5]
[35, 137]も，動的な振舞いの切り替えを実現するために，前節で述べたコンポーネントの動的
切換えを実現するためのアーキテクチャ[105]を自己適応システムのアーキテクチャモデルに 発展させている．彼らが提案するRASアーキテクチャモデル[137]は，コンポーネントとコ ネクタにより構成され，抽象化に応じた複数の層を持つモデルである．RASアーキテクチャ モデルにおいては，コネクタが層間の通信を実現する要素として用いられている．
これらの研究は，動的な適応を扱うためのアーキテクチャを提案するものであるが，設計・
実装すべきコンポーネントの決定やコンポーネント間の接続関係の決定関して言及したもので はない．従って，開発者はこれらのモデルを採用するとしても，具体的なコンフィギュレー ションや，目的管理とコンフィギュレーションとの対応関係を整合を取りながら検討する必要 がある．特に，複数のゴールやアクションをもつ自己適応システムにおいては，必要なコン ポーネントを抽出・決定し，コンポーネント間で発生し得る競合を考慮しながら，接続関係を 決定することは通常容易ではない．3層アーキテクチャモデルに関しては，実現に向けた関連 研究が文献[138, 139]などいくつか挙げられるものの，各層間での無矛盾性の保証などの研究 課題も多く，3層アーキテクチャを実現するための実装フレームワークは現段階では確立され ていない．
本研究で導入するコンフィギュレーション決定法は，自己適応システムの構築においても，
設計・実装すべきコンポーネントとコンポーネント間の接続関係を決定するために利用するこ とができる．本研究で生成されるコンフィギュレーションは，例えばKramerらの3層アーキ テクチャモデルにおいては，最下層のコンポーネント制御層のコンポーネント間構成として利 用することができる．提案手法が生成するコンフィギュレーションでは，Analyze & Decide
タイプのコンポーネントが上位階層，例えば3層アーキテクチャモデルにおける変更管理層や ゴール管理層との接続の役割を担うことになる．加えて，ゴールモデルの階層構造を利用して コンポーネント間の接続関係を決定するため，生成されるコンフィギュレーションは，目的と の対応関係も考慮したものであることが期待できる．
自己適応システムのアーキテクチャモデルとしては，3層アーキテクチャモデル，RASアー キテクチャモデルの他に，GarlanらのRainbow [140]がある．Rainbowはセンサ・イフェク タにより構成されるSystem-layer，適応を実現するArchitecture-layerと，これらを仲介する Translation infrastructureにより構成されるアーキテクチャモデルを持つ．Rainbowは，アー キテクチャモデルだけでなく実装フレームワークも提供し，またControl loopをモデルとした 実装が可能であるが，1つのControl loopがシステム全体を管理するという集中的な制御機構 を採用しているため，複数の適応を扱う場合にはその記述は急激に複雑化するという特徴が ある．
7.4.3 フレームワークに関する議論
自己適応システムの実装フレームワークとしては，前節で述べたRainbowの他に，StarMX [141]やAdaptive Server Framework (ASF) [142]，JADE [143, 144, 145]*1などが提案されて
いる．StarMXは，Java 言語とポリシー記述言語で動作を記述する実装フレームワークで
ある．StarMXの特徴としては，Java のアプリケーション管理フレームワークである Java
Management Extensions (JMX) [146]を利用して，センサやイフェクタ，アプリケーションを
監視する点にある．しかしながら，StarMXは振舞いの制御を基本的にはポリシー言語で記述 するため，複数の適応を扱う場合にポリシー記述部が急激に複雑化する可能性がある．ASF もJMXを用いてアプリケーションを監視するが，Control loopモデルに従った実装が可能で ある．ただし，Rainbow同様に，1つのControl loopによる集中的な制御機構であるため，複 数の適応を扱う場合は，記述が複雑化する．JADEは，自己修復機能を有するフレームワーク であり，コンポーネントの状態やコンポーネントの異常終了を監視することで，事前に定めら れたポリシーに従って，システムを安定状態に戻すようにコンポーネントの構成を切り替える ことが可能なコンポーネントベースのフレームワークである．JADEはサーバの安定運用を目 的としたフレームワークであり，J2EE上に実装されている．ただし，サーバの安定運用を目 的としていることから，コンポーネントの切り替えは，クラスタ構成されている同一クラスの コンポーネントへの切り替えを想定したものである．
本研究同様に，エージェントプラットフォームを利用した自己適応システム実装フレーム
*1本研究で利用するエージェントプラットフォームのJADEと同名であるが，関連性は無い．