(57)【要約】  【課題】  ソフトウェア・ライフサイクルの各段階の作業を対象として、ソフトウェアの品質向上を図り問題解決を行う自立的なシステムおよび方法を実現する。  【解決手段】  ソフトウェア・ライフサイクルの各段階の実行環境１１〜１４と、このソフトウェア・ライフサイクルの段階ごとに適用可能な設計のパターンに関する情報を格納したパターンカタログ２０と、設計目的を含む所定の条件に基づいてパターンカタログ２０から各段階のパターンを検索するパターン組合せ検索エンジン３０と、パターン組合せ検索エンジン３０にて検索されたパターンを適用して実行環境１１〜１４の動作を制御するパターン適用エージェント４０とを備える。設計目的に合致したパターンを自動選択することにより、自立的にソフトウェアの品質向上を図ると共に、問題が発見された場合にパターン組合せ検索エンジン３０の検索結果であるパターンを適用し直すことで自立的に問題解決を行う。  【選択図】  図１
2005173788.tif 000002
【特許請求の範囲】
【請求項１】
モデリング段階、開発段階、テスト段階および運用段階からなるソフトウェア・ライフサイクルの段階ごとに適用可能な設計のパターンに関する情報を格納したパターンカタログと、
前記パターンカタログから前記ソフトウェア・ライフサイクルの各段階のパターンを検索するパターン検索部と、
前記パターン検索部の検索結果であるパターンを前記ソフトウェア・ライフサイクルの各段階に適用し、当該各段階の実行環境における動作を制御するパターン適用部と
を備えることを特徴とするオートノミック・コンピューティングシステム。
【請求項２】
前記パターンカタログは、前記パターンに関する情報として、複数の前記パターンの組合せにおける関連性の高さを示す重み値を格納し、
前記パターン検索部は、前記重み値に基づいて前記パターンの検索を行うことを特徴とする請求項１に記載のオートノミック・コンピューティングシステム。
【請求項３】
前記パターンカタログは、前記ソフトウェア・ライフサイクルの異なる段階で用いられるパターンの組合せに対する重み値を格納したことを特徴とする請求項２に記載のオートノミック・コンピューティングシステム。
【請求項４】
前記パターン適用部は、前記ソフトウェア・ライフサイクルの所定の段階に適用可能な前記パターンに関して、当該所定の段階以降の作業をシミュレーションし、当該シミュレーションの結果に基づいて当該所定の段階に適用するパターンを決定することを特徴とする請求項１に記載のオートノミック・コンピューティングシステム。
【請求項５】
前記パターン適用部は、前記ソフトウェア・ライフサイクルの所定の段階で作業対象のソフトウェアに問題が発見された場合に、当該所定の段階よりも前の段階に戻り、当該前の段階に対して適用されていたパターンとは別のパターンを改めて適用し、当該前の段階以降の実行環境における動作を制御することを特徴とする請求項１に記載のオートノミック・コンピューティングシステム。
【請求項６】
モデリング段階、開発段階、テスト段階および運用段階からなるソフトウェア・ライフサイクルの各段階における作業の実行手段と、
前記ソフトウェア・ライフサイクルの段階ごとに前記実行手段に適用される設計のパターンを決定するパターン決定手段と、
前記パターン決定手段により決定された前記パターンを適用して前記実行手段の動作を制御するパターン適用手段と
を備えることを特徴とするオートノミック・コンピューティングシステム。
【請求項７】
前記パターン決定手段は、前記ソフトウェア・ライフサイクルの所定の段階に適用可能な前記パターンが複数ある場合に、当該各パターンに関して、当該所定の段階以降の作業をシミュレーションし、当該シミュレーションの結果に基づいて当該所定の段階に適用するパターンを決定することを特徴とする請求項６に記載のオートノミック・コンピューティングシステム。
【請求項８】
前記実行手段は、作業対象のソフトウェアに問題が発見された場合に前記パターン決定手段に対して報告を行い、
前記パターン決定手段は、前記実行手段からの報告を受けると、前記ソフトウェア・ライフサイクルにおける前記問題が発見された段階よりも前の段階に戻り、当該前の段階に対して適用されていたパターンとは別のパターンを改めて適用されるパターンに決定することを特徴とする請求項６に記載のオートノミック・コンピューティングシステム。
【請求項９】
前記パターン決定手段は、前記ソフトウェア・ライフサイクルの段階ごとに適用可能な設計のパターンの情報と当該パターンの組合せにおける関連性の高さを示す情報とに基づいて、各段階の作業の実行手段に適用されるパターンを決定することを特徴とする請求項６に記載のオートノミック・コンピューティングシステム。
【請求項１０】
コンピュータを用いてモデリング段階、開発段階、テスト段階および運用段階からなるソフトウェア・ライフサイクルの各段階における実行環境の動作を制御する実行環境制御方法であって、
前記コンピュータが、記憶手段に構築されソフトウェア・ライフサイクルの段階ごとに適用可能な設計のパターンに関する情報を格納したパターンカタログから、前記ソフトウェア・ライフサイクルの各段階に適用されるパターンを検索するステップと、
前記コンピュータが、検索された前記パターンを前記ソフトウェア・ライフサイクルの各段階に適用し、当該各段階の実行環境の動作を制御するステップと
を含むことを特徴とする実行環境制御方法。
【請求項１１】
前記実行環境の動作を制御するステップは、
前記ソフトウェア・ライフサイクルの所定の段階に適用可能な前記パターンに関して、当該所定の段階以降の作業をシミュレーションするステップと、
前記シミュレーションの結果に基づいて前記所定の段階に適用するパターンを決定するステップとを含むことを特徴とする請求項１０に記載の実行環境制御方法。
【請求項１２】
前記実行環境の動作を制御するステップでは、前記ソフトウェア・ライフサイクルの所定の段階で作業対象のソフトウェアに問題が発見された場合に、当該所定の段階よりも前の段階に戻り、当該前の段階に対して適用されていたパターンとは別のパターンを改めて適用し、当該前の段階以降の実行環境における動作を制御することを特徴とする請求項１０に記載の実行環境制御方法。
【請求項１３】
前記パターンを検索するステップでは、前記パターンカタログに格納されている、前記ソフトウェア・ライフサイクルの段階ごとに適用可能な設計のパターンの情報と当該パターンの組合せにおける関連性の高さを示す情報とに基づいて、各段階の作業の実行手段に適用されるパターンを検索することを特徴とする請求項１０に記載の実行環境制御方法。
【請求項１４】
コンピュータを、
モデリング段階、開発段階、テスト段階および運用段階からなるソフトウェア・ライフサイクルの段階ごとに適用可能な設計のパターンに関する情報を格納した記憶手段から、当該ソフトウェア・ライフサイクルの各段階に適用されるパターンを検索するパターン検索手段と、
前記パターン検索手段の検索結果であるパターンを前記ソフトウェア・ライフサイクルの各段階に適用し、当該各段階の実行環境における動作を制御するパターン適用手段として機能させることを特徴とするプログラム。
【請求項１５】
前記記憶手段に、前記パターンに関する情報として、複数の前記パターンの組合せにおける関連性の高さを示す重み値を格納し、
前記パターン検索手段の機能として、前記重み値に基づいて前記パターンを検索する処理を前記コンピュータに実行させることを特徴とする請求項１４に記載のプログラム。
【請求項１６】
前記記憶手段に、前記ソフトウェア・ライフサイクルの異なる段階で用いられるパターンの組合せに対する重み値を格納したことを特徴とする請求項１４に記載のプログラム。
【請求項１７】
前記パターン適用手段の機能として、前記ソフトウェア・ライフサイクルの所定の段階に適用可能な前記パターンに関して、当該所定の段階以降の作業をシミュレーションし、当該シミュレーションの結果に基づいて当該所定の段階に適用するパターンを決定する処理を前記コンピュータに実行させることを特徴とする請求項１４に記載のプログラム。
【請求項１８】
前記パターン適用手段の機能として、前記ソフトウェア・ライフサイクルの所定の段階で作業対象のソフトウェアに問題が発見された場合に、当該所定の段階よりも前の段階に戻り、当該前の段階に対して適用されていたパターンとは別のパターンを改めて適用し、当該前の段階以降の実行環境における動作を制御する処理を前記コンピュータに実行させることを特徴とする請求項１４に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オートノミック・コンピューティングに関し、特にソフトウェアの開発作業に対して適用されるオートノミック・コンピューティングに関する。
【背景技術】
【０００２】
今日、コンピュータが使用される場面は多岐におよび、これに伴ってシステムの複雑さも増大している。そこで、種々の状況にコンピュータ自身が対応し、変化する環境への適応(自己構成)、障害の発見/診断/防止(自己修復)、リソースや負荷の調整(自己最適化)、攻撃の予測/探知/識別/防御(自己防御)といったことを自らの判断で実行する機能を持つオートノミック・コンピューティング（Autonomic Computing）という概念が提案されている（例えば、非特許文献１、２参照）。
【０００３】
現在のオートノミック・コンピューティングは、コンピュータシステムが業務の実行時に自立的に最適な状態で稼働することを目指しており、ソフトウェアの開発作業に対する適用は考えられていない。しかしながら、コンピュータシステムに関して最もワークロードを要するのは、ソフトウェアの開発、保守である。
【０００４】
今日のソフトウェア開発では、様々なスキルレベルの開発者が多数参画して開発が行われる。このため、コードの品質が一定せず、実際の業務実行時やその前のテストの最終段階で、バグがある、パフォーマンスが悪いなどの品質上の問題が顕在化することが多い。このような段階で問題が露見した場合は、モデリング（Modeling）、開発（Development）、テスト（Testing）、運用（Operation）というソフトウェア開発の流れにおける上流に遡って、問題判別やパフォーマンス測定コードの埋め込み、デザインの修正、バグのフィックス、再テストといった作業が行われ、多大なワークロードがかかることになる。
そこで、このソフトウェア開発の各段階（フェーズ）で発生する様々な状況に対して、コンピュータ自身が自立的に対応できると効果的である。
【０００５】
【非特許文献１】「オートノミック・コンピューティング・アーキテクチャーに関するブループリント」、［online］、２００３年４月、日本ＩＢＭ、［平成１５年８月２２日検索］、インターネット＜URL : http://www-6.ibm.com/jp/autonomic/pdf/acwp_j.pdf＞
【非特許文献２】「ＩＢＭの展望」、［online］、日本ＩＢＭ、［平成１５年８月２２日検索］、インターネット＜URL : http://www-6.ibm.com/jp/servers/eserver/ac/view/index.html＞
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上述したように、コンピュータシステムのソフトウェア開発では多大なワークロードを要するため、この段階の作業においてオートノミック・コンピューティングによるコンピュータ自身の自立的な対応ができることが好ましい。しかし、従来のオートノミック・コンピューティングは、コンピュータシステムが業務の実行時における自立的な動作を対象としており、ソフトウェアの開発作業に対しては適用されていない。
【０００７】
従来、ソフトウェア開発時における品質改善や生産性向上のための手段として、上述したソフトウェア開発の各局面で様々なソフトウェアツール（以下、単にツールと記す）を用いた作業が行われている。例えば、モデリングツールを用いてモデリングを行い、開発支援ツールを用いてモデリングの結果からコードを自動生成したり、LoadRunner（米国マーキュリーインタラクティブ社の負荷テストツール）やＪＵｎｉｔ（Ｊａｖａ（米国サン・マイクロシステムズ社の商標）言語用テスティングフレームワーク）などの自動テストツールを用いてテストを実行したり、ＪＴｅｓｔ（米国ParaSoft社のユニットテストツール）を用いてコードの品質検査を行っている。
【０００８】
しかし、これら既存のツールは、それぞれソフトウェア開発における様々な作業を各局面において支援するものであり、開発者が自身の作業の補助として能動的に使用するものである。現状では、ソフトウェア開発の分野において、オートノミック・コンピューティングにより自立的にソフトウェアの品質向上を図ることを実現する有効なメカニズムが存在しない。
【０００９】
ところで、ソフトウェアに関する問題は、通常、ソフトウェア・ライフサイクルの各段階（モデリング、開発、テスト、運用）での作業が関係している。例えば、モデリングが悪いと運用段階でパフォーマンスの問題を引き起こすといった具合である。したがって、問題に対して自立的に対応するには、ソフトウェアのライフサイクル全体にわたって自立的な問題解決を促す仕組みを設けることが有効である。
【００１０】
そこで本発明は、モデリング段階、開発段階、テスト段階および運用段階からなるソフトウェア・ライフサイクルの各段階の作業を対象として、ソフトウェアの品質向上のための自立的なシステムおよび方法を実現することを目的とする。
また本発明は、ソフトウェア・ライフサイクルの全体にわたり、自立的な問題解決を行うシステムおよび方法を実現することを他の目的とする。
【課題を解決するための手段】
【００１１】
上記の目的を達成する本発明は、次のように構成されたオートノミック・コンピューティングシステムとして実現される。すなわち、このシステムは、モデリング段階、開発段階、テスト段階および運用段階からなるソフトウェア・ライフサイクルの各段階における作業を実行する実行環境と、このソフトウェア・ライフサイクルの段階ごとに適用可能な設計のパターンに関する情報を格納したパターンカタログと、所定の条件に基づいてパターンカタログからソフトウェア・ライフサイクルの各段階のパターンを検索するパターン検索部と、パターン検索部の検索結果に基づいて決定されたパターンをソフトウェア・ライフサイクルの各段階に適用し、かかる各段階の実行環境における動作を制御するパターン適用部とを備える。
【００１２】
さらに詳細には、パターンカタログは、パターンに関する情報として、所定のパターンの組合せにおける関連性の高さを示す重み値を格納し、パターン検索部は、この重み値に基づいてパターンの検索を行う。ここで、重み値は、ソフトウェア・ライフサイクルにおける同じ段階に用いられるパターンの組合せのみならず、異なる段階で用いられるパターンの組合せに対しても設定される。
【００１３】
また、より好ましくは、パターン適用部は、ソフトウェア・ライフサイクルの所定の段階に適用可能なパターンに関して、かかる所定の段階以降の作業をシミュレーションし、このシミュレーションの結果に基づいて所定の段階に適用するパターンを決定する。
さらにパターン適用部は、ソフトウェア・ライフサイクルの所定の段階で作業対象のソフトウェアに問題が発見され、その段階の実行環境からの報告を受けた場合に、かかる所定の段階よりも前の段階に戻り、かかる前の段階に対して適用されていたパターンとは別のパターンを改めて適用し、かかる前の段階以降の実行環境における動作を制御する。
【００１４】
上記の目的を達成する他の本発明は、コンピュータを用いてモデリング段階、開発段階、テスト段階および運用段階からなるソフトウェア・ライフサイクルの各段階における実行環境の動作を制御する、つぎのような実行環境制御方法としても実現される。この実行環境制御方法は、所定の記憶手段に構築されソフトウェア・ライフサイクルの段階ごとに適用可能な設計のパターンに関する情報を格納したパターンカタログから、所定の条件に基づいてソフトウェア・ライフサイクルの各段階に適用されるパターンを検索するステップと、検索されたパターンをソフトウェア・ライフサイクルの各段階に適用し、各段階の実行環境の動作を制御するステップとを含むことを特徴とする。
【００１５】
さらに本発明は、コンピュータを制御して上述したオートノミック・コンピューティングシステムとして機能させるプログラム、あるいは上記の実行環境制御方法の各ステップに対応する処理を実行させるプログラムとして実現される。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供することができる。
【発明の効果】
【００１６】
以上のように構成された本発明によれば、あらかじめ用意された設計のパターンに対して所望の設計目的に応じた検索を行い、得られたパターンに基づいてソフトウェア・ライフサイクルにおける各段階の実行環境の動作制御を行うことで、ソフトウェア・ライフサイクルの全体にわたり、ソフトウェアの品質向上を図る自立的なシステムおよび方法を実現することができる。
【００１７】
また本発明によれば、本実施形態のオートノミック・コンピューティングシステムは、ソフトウェア・ライフサイクルの各段階で、適用すべき設計のパターンを選択するために次の段階以降のシミュレーションを行って問題の発生を事前に予測したり、所定の段階で実際に問題が発生した場合に、その前の段階に遡って設計のパターンの適用を変更したりすることにより、自立的な問題解決を行うシステムおよび方法を実現することができる。
【発明を実施するための最良の形態】
【００１８】
以下、添付図面を参照して、本発明を実施するための最良の形態（以下、実施形態）について詳細に説明する。
まず、本発明の概要について説明する。ソフトウェア開発の各工程で品質を向上させる手段として、良い設計をパターン化し、これを選択して適用するという手法が広く用いられている。そこで本発明は、ソフトウェア・ライフサイクルをモデリング段階、開発段階、テスト段階、運用段階の４段階で把握し、その段階ごとに適用し得るパターンを集め、各段階で適切なパターンを選択すると共に、ソフトウェア・ライフサイクル全体を考慮して各段階のパターンの適切な組合せを選択する。そして、ソフトウェア・ライフサイクルの各段階の作業を、選択されたパターンにしたがって自立的に実行する。
【００１９】
ここで、ソフトウェア・ライフサイクルのモデリング段階とは、開発対象のソフトウェアの論理モデルをプログラムモジュールとモジュール間の接続関係を表すネットワーク・データ構造として構築し、コンピュータの記憶装置に格納する作業を行う段階である。
開発段階とは、モデリング段階で作成されたソフトウェアの論理モデルに基づいて、実際にコンピュータの動作を制御して実現するプログラムコードを生成し、コンピュータの記憶装置に格納する作業を行う段階である。
テスト段階とは、開発段階で生成されたプログラムコードを、種々のテスト条件の下でコンピュータにて実行し、バグの検出や処理に要する時間の実測などを行う段階である。
運用段階とは、テストに合格したプログラムコードを、実際に業務を実施するシステムのコンピュータの記憶装置にインストールし、業務を実行する段階である。
【００２０】
図１は、本実施形態によるオートノミック・コンピューティングシステムの全体構成を示す図である。
図１を参照すると、本実施形態のオートノミック・コンピューティングシステムは、ソフトウェア・ライフサイクルの各段階（モデリング、開発、テスト、運用）の作業の実行手段である実行環境（モデリング環境１１、開発環境１２、テスト環境１３、本番環境１４）と、各段階でのパターンを格納したパターンカタログ２０と、パターンカタログ２０に格納されたパターンの選択および組合せを行うパターン組合せ検索エンジン３０と、各実行環境１１〜１４に対してパターンの適用を行うパターン適用エージェント４０とを備える。
これらの各機能は、物理的に単一のコンピュータ装置にて実現しても良いし、複数台のコンピュータ装置にて実現しても良い。例えば、パターンカタログ２０、パターン組合せ検索エンジン３０およびパターン適用エージェント４０と各実行環境１１〜１４とを異なるコンピュータ装置とした構成や、パターンカタログ２０およびパターン組合せ検索エンジン３０とパターン適用エージェント４０および各実行環境１１〜１４を異なるコンピュータ装置とした構成、あるいは本番環境１４のみを異なるコンピュータ装置とした構成をとることができる。
【００２１】
図２は、本実施形態によるオートノミック・コンピューティングシステムを実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図２に示すコンピュータ装置は、演算手段であるＣＰＵ（Central Processing Unit：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２およびＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２およびＡＧＰ（Accelerated Graphics Port）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット１０２に接続された磁気ディスク装置（ＨＤＤ）１０５、ネットワークインターフェイス１０６と、さらにこのＰＣＩバスからブリッジ回路１０７およびＩＳＡ（Industry Standard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピー（登録商標）ディスクドライブ１０８およびキーボード／マウス１０９とを備える。
【００２２】
なお、図２は本実施形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、外部記憶装置として、ＡＴＡ（AT Attachment）やＳＣＳＩ（Small Computer System Interface）などのインターフェイスを介してＣＤ−Ｒ（Compact Disc Recordable）やＤＶＤ−ＲＡＭ（Digital Versatile Disc Random Access Memory）のドライブを設けても良い。
【００２３】
図１に示したオートノミック・コンピューティングシステムの構成のうち、パターンカタログ２０は、例えば図２に示す磁気ディスク装置１０５に格納されて実現され、ソフトウェア・ライフサイクルの各段階における設計のパターンに関する情報を格納したデータベースである。
パターンに関する情報としては、各パターンの名称、目的、内容、適用可能性と共に、各パターン間の関連性を示す重み付けの値（以下、重み値）が登録される。ここで、パターンの目的には、そのパターンが何をするのか、そのパターンの原理と意図は何か、そのパターンが扱える設計課題や問題は何かといった情報が記述される。パターンの内容には、パターンが問題をどのように解くかが記述される。パターンの適用可能性には、そのパターンがどのような状況で適用できるかが記述される。
これらのパターンに関する情報は、それぞれ可変長文字列のテキストにて記録される。
【００２４】
本実施形態で利用されるパターンには、所定の作業において一緒に適用すると有効であるものと、一緒に適用することが望ましくない、もしくは一緒に適用できないものとがある。詳しくは後述するが、例えば、開発段階で用いられるデザインパターンに、StrategyというパターンとTemplate Methodというパターンがあり、Template Methodにより呼び出し形式を決めて、Strategyにより処理内容を決めることができるので、これらを併用すると有効である。また、デザインパターンを用いてオブジェクトを変化させる方法として、Decoratorというパターンを用いてオブジェクトの殻を替えるか、Strategyによりオブジェクトの中身を替えるかのいずれかの手段が適用できるが、この場合、殻と中身を同時に替えても意味がないので、どちらかのパターンが排他的に選択されて用いられる。
【００２５】
そこで、パターンカタログ２０では、パターンの組合せに対して重み付けを行い、所定のパターンを選択した場合に、その重み値に基づいて、一緒に適用すると有効であるパターンや一緒に適用することが望ましくない、もしくは一緒に適用できないパターンを特定できるようにする。本実施形態では、一緒に適用すると有効であるパターンに、その効果の度合に応じて正の重み値を付与する。反対に、一緒に適用することが望ましくない、もしくは一緒に適用できないパターンに、その度合に応じて負の重み値を付与する。例えば、上記デザインパターンの例では、StrategyとTemplate Methodの組合せに対して正の重み値を与え、DecoratorとStrategyの組合せに対して負の重み値を与える。
【００２６】
この重み付けは、ソフトウェア・ライフサイクルの各段階での作業におけるパターン間の関連性に対して行うのみならず、異なる段階で用いられるパターンの間の関連性に対しても行われる。すなわち、モデリングの段階でＡパターンを使用した場合、開発の段階でデザインパターンのＢパターンを用いると効果的である、あるいはＣパターンを用いることはできない、といった関連性が重み値によって表現される。
【００２７】
パターン組合せ検索エンジン３０は、例えば図２に示したコンピュータ装置のプログラム制御されたＣＰＵ１０１にて実現され、パターンカタログ２０に格納されているパターンに関する情報に基づいて、ソフトウェア・ライフサイクルの各段階の作業で適用されるべきパターンを検索する。
具体的には、まず、システムの使用者（ソフトウェア開発者）が、ソフトウェア・ライフサイクルの所望の段階を特定し、設計目標としてパターンの適用目的を入力する。パターン組合せ検索エンジン３０は、この入力を受け付け、パターンカタログ２０に登録されているパターンの情報を参照して、入力された適用目的に合ったパターンを検索する。そして、パターンカタログ２０に登録されているパターンの組合せに対する重み値にしたがって、一緒に用いることが効果的なパターンを検索する。
【００２８】
さらに、パターン組合せ検索エンジン３０は、同様にしてソフトウェア・ライフサイクルの各段階におけるパターンを検索した上で、異なる段階におけるパターンの組合せに対する重み値に基づいて、一緒に用いることが効果的なパターンの組合せを調べ、パターンリストを作成する。パターンリストには、最も有効性が高いと考えられるパターンの組合せ（すなわち、各パターンの組合せにおける重み値の合計が最も大きいもの）をリストアップしても良いし、有効性が高い順に何種類かのパターンの組合せを列挙しても良い。作成されたパターンリストは、例えば図２に示したメインメモリ１０３や磁気ディスク装置１０５等の記憶装置に保存され、後述のパターン適用エージェント４０による制御において用いられる。
【００２９】
パターン適用エージェント４０は、例えば図２に示したコンピュータ装置のプログラム制御されたＣＰＵ１０１にて実現され、パターン組合せ検索エンジン３０によって作成されたパターンリストに基づき、ソフトウェア・ライフサイクルの各段階において、各実行環境１１〜１４における呼び出し可能なツールを呼び出して自動実行させ、動作制御を行う。具体的には、例えば、開発段階においてコードの自動生成ツールを呼び出し、パターンリストに挙げられたデザインパターンに対応するコード生成を行うように、開発環境１２を制御する。また、テスト段階において、ＪＵｎｉｔ等の自動テストツールを呼び出し、パターンリストに挙げられたパターンに対応するテストプログラムを自動実行するように、テスト環境１３を制御する。また、運用段階において、コード配置ツールを呼び出し、アプリケーションサーバ等に対して、パターンリストに挙げられたパターンに対応するアプリケーションコードの配置を行うように、本番環境１４を制御する。
パターンリストにパターンの組合せが複数列挙されている場合は、重み値の合計が最も大きい組合せにしたがって各実行環境１１〜１４を制御しても良いし、パターンリストを出力してシステムの使用者による選択を促し、使用者により選択された組合せにしたがって各実行環境１１〜１４を制御しても良い。すなわちこの場合、パターン適用エージェントは、パターンリストの中からソフトウェア・ライフサイクルの各段階で実際に適用するパターンを決定するパターン決定手段としても機能する。
【００３０】
次に、各段階で適用されるパターンについて説明する。
ソフトウェア・ライフサイクルのモデリング段階で適用できるパターンは、一般に、アーキテクチャー・パターンとして知られている。代表的なパターンとしては、図３に示すように、システムを層に分けて機能を層に配置するパターンであるレイヤー（Layers）、システムの機能を処理を行うフィルタに分割しフィルタをパイプで接続してシステムとするパターンであるパイプ・アンド・フィルタ（Pipes and Filters）、互いに依存性を持たないコンポーネント群がブローカーを介して相互作用するパターンであるブローカー（Broker）、対話型アプリケーションをモデル、ビュー、コントローラ・コンポーネントにより構成するパターンであるモデル・ビュー・コントローラ（Model-View-Controller：ＭＶＣ）、システムの核となる最小限の機能を拡張機能から分離するパターンであるマイクロ・カーネル（Microkernel）等のパターンがある。
パターンカタログ２０には、モデリング段階におけるこれらのパターンに関して、それぞれ情報を格納している。
図４は、上記のブローカーに関するパターンカタログ２０に格納された情報の例を示す図である。図示のように、モデリング段階のパターンであるブローカーに関して、その名称と共に、目的、内容、適用可能性を記述したテキストが記録されている。
【００３１】
開発段階で適用できるパターンは、一般に、デザインパターンとして知られている。代表的なパターンとしては、図５に示すように、互いに関連するクラス群を、その実装クラス群をあきらかにせずに生成するパターンであるAbstract Factory、複合オブジェクトについて同じ作成過程で異なる表現形式のオブジェクトを生成するパターンであるBuilder、オブジェクトを生成するインターフェースだけを規定して実際にどのクラスをインスタンス化するかはサブクラスにまかせるパターンであるFactory Method、あるクラスに対してインスタンスが１つしかないことを保障しグローバルにアクセスするパターンであるSingleton、あるクラスのインターフェースを他のインターフェースに変換するパターンであるAdapter、部分−全体階層を表現するためにオブジェクトを木構造に組み立てるパターンであるComposite、オブジェクトに責任を動的に追加するパターンであるDecorator、要求をオブジェクトとしてカプセル化することにより要求の受け渡しやキューイングを可能にするパターンであるCommand、多数の小さいオブジェクトを効率よくサポートするために共有を利用するパターンであるFlyweight、あるオブジェクトが状態を変えたときに、依存するすべてのオブジェクトに変化を通知するパターンであるObserver、アルゴリズムの集合を定義し各アルゴリズムをカプセル化して交換可能にするパターンであるStrategy、１つのオペレーションにアルゴリズムのスケルトンを定義しておき、その中のいくつかのステップはサブクラスの定義にまかせるパターンであるTemplate Method等のパターンがある。
パターンカタログ２０には、開発段階におけるこれらのパターンに関して、それぞれ情報を格納している。
図６−１、６−２は、上記のAdapterおよびCommandに関するパターンカタログ２０に格納された情報の例を示す図である。図示のように、モデリング段階のパターンであるAdapterおよびCommandに関して、その名称と共に、目的、内容、適用可能性を記述したテキストが記録されている。
【００３２】
テスト段階で適用できるパターンとしては、開発段階におけるデザインパターンのような広く一般に認知されたものはないが、例えばインターネット上のウェブサイト（http://c2.com/cgi-bin/wiki?TestingPatterns）に公開されたテストパターンが存在し、これらを適用することができる。同ウェブサイトに公開されているテストパターンには、図７に示すように、モジュール間の境界条件をテストするパターンであるTestBoundaryConditions、ヌル値をパラメータとして渡して実行するパターンであるTestNull、ランダムな値を与えて実行するパターンであるRandomTesting、テスト対象がさらに呼び出すオブジェクトとして、テスト用として動作が決まっているオブジェクトを与えて実行するパターンであるMockObject等がある。また、システムに負荷をかけて問題が生じないかテストするストレス・テストや、システムを長時間運転して問題が生じないかテストするロングラン・テストといったテスト手法も、テストパターンとして用いることができる。
【００３３】
運用段階で実際にシステムを構築する際に適用できるパターンは、ハードウェアやソフトウェアにおける構成のトポロジーのパターンである。これも、開発段階におけるデザインパターンのような広く一般に認知されたものはないが、例えばインターネット上のウェブサイト（http://www-106.ibm.com/developerworks/patterns/ja_jp/）に公開されたパターンが存在し、これらを適用することができる。同ウェブサイトに公開されているパターンには、図８に示すように、独立したサーバが単一種類のユーザにサービスを提供するパターンであるスタンドアロン単一チャネル・アプリケーション・パターン、従来のシステムと新システムを直接接続して単一種類のユーザにサービスを提供するパターンである直接統合単一チャネル・アプリケーション・パターン、従来のシステムと新システムをルーター・システムを介して接続してユーザにサービスを提供するパターンであるルーター・アプリケーション・パターン、ユーザからの要求を複数のパックエンドに分解して処理させるパターンである分解アプリケーション・パターン、ユーザと対話するエージェントを用意し実際の処理はエージェントが呼び出すパターンであるエージェント・アプリケーション・パターン等がある。
パターンカタログ２０には、運用段階におけるこれらのパターンに関して、それぞれ情報を格納している。
図９は、上記の分解アプリケーション・パターンに関するパターンカタログ２０に格納された情報の例を示す図である。図示のように、モデリング段階のパターンである分解アプリケーション・パターンに関して、その名称と共に、目的、内容、適用可能性を記述したテキストが記録されている。
なお、ソフトウェア・ライフサイクルの各段階に適用されるこれらのパターンは例示に過ぎず、他の既知のパターンや実際のソフトウェア開発によって経験的に得られる種々のパターンをパターンカタログ２０に登録して利用できることは言うまでもない。
【００３４】
次に、パターン間の重み付けについて説明する。
図１０は、開発段階で適用されるデザインパターンの場合を例として、パターンの組合せとその重み値との関係を示す図表である。
図１０に示す例では、重み値は１を常に同時に使用すべき組合せ、０を関連のない組合せ、−１を同時に使ってはいけない組合せとし、２０段階で値を設定してある。
同図において、Abstract FactoryとSingletonとの組合せには、重み値０．５が付与されている。Abstract Factoryに対応する実装のファクトリは、実装に応じて１つあれば十分であり、無駄を避けるためSingletonとしてファクトリを作成することが多い。ただし、この２つは排他的なものではない。そこで、０．５という中間的な値に設定している。
また、Abstract FactoryとFactory Methodとの組合せには、重み値０．８が付与されている。Factory MethodはAbstract Factoryを実現するのに適した方法であり、多くの場合に合わせて使用される。そこで、Abstract FactoryとFactory Methodのいずれかが選択された場合に他方も選択されやすいように、０．８という高めの値に設定している。
また、CompositeとBuilderとの組合せには、重み値０．５が付与されている。Compositeを組み立てるプログラミングが煩雑になることが多いので、組み立てを担当するBuilderを設けておくと便利である。ただし、Builderがなくてもプログラミングは可能であり、排他的なものではないので、０．５という中間的な値に設定している。
また、CompositeとDecoratorとの組合せには、重み値０．３が付与されている。Decoratorは退化したCompositeとみなすことができる。したがって、いずれか一方が適用されれば十分であり、両方を設ける必要はないので、０．３という低めの値が設定されている。
また、DecoratorとStrategyとの組合せには、重み値−０．７が付与されている。これについては既に述べたが、オブジェクトを変化させる方法として、Decoratorにより殻を替えるか、Strategyにより中身を替えるかのいずれかの手段が排他的に適用される。そこで、いずれか一方が選択された場合には他方を選択しないようにするため、負の値が設定される。
また、StrategyとTemplate Methodとの組合せには、重み値０．７が付与されている。Template Methodにより呼び出し形式を決め、Strategyにより処理内容を決めることができ、併用することが効果的である。そこで、いずれかが選択された場合に他方も選択されやすいように、０．７という高めの値に設定している。
【００３５】
図１１は、異なる段階で適用されるパターンの組合せとその重み値との関係を示す図表である。
図１１に示す例でも、図１０と同様に、重み値は１を常に同時に使用すべき組合せ、０を関連のない組合せ、−１を同時に使ってはいけない組合せとし、２０段階で値を設定してある。
同図において、モデリング段階のパターンと開発段階のパターンとの組合せでは、BrokerとAdapterとの組合せに対して、重み値０．８が付与されている。Brokerによってクライアントとさまざまなサーバを接続するような場合に、Adapterによってサーバの呼び出し形式の違いを吸収して接続しやすくすることができる。そこで、モデリング段階でBrokerが選択された場合は、開発段階でAdapterが選択されやすいように、０．８という高めの値を設定している。
また、BrokerとCommandとの組合せには、重み値０．５が付与されている。Brokerが要求を受け渡す場合にCommandパターンを用いて要求の取り扱いを一元化すると実装しやすい。しかしながら、BrokerとAdapterとの組合せほど効果的ではないので、０．５という中間的な値を設定している。
また、ＭＶＣとObserverとの組合せには、重み値０．８が付与されている。ＭＶＣではモデルの変化に伴ってビューが変わる必要があり、これは通常、Observerを用いて実現することができる。したがって、モデリング段階でＭＶＣが選択された場合には、開発段階でObserverが選択されやすいように、０．８という高めの値を設定している。
【００３６】
開発段階のパターンとテスト段階のパターンとの組合せでは、AdapterとMockObjectとの組合せに対して、重み値０．５が付与されている。Adapterのテストには、Adapterの変換元のMockObjectを作って、Adapterの機能をテストする方法が有効である。ただし、テスト段階の実施は、他の段階と異なり、どのような種類のテストを行うべきか、あるいはテストそのものを実行すべきかについて、比較的自由度があり、ソフトウェア開発者の恣意によって定め得る比重が大きいので、重み値は低めに設定される。したがって、AdapterとMockObjectとの組合せは有効であるものの、０．５という中間的な値が設定されている。
また、ObserverとRandomTestingとの組合せには、重み値０．３が付与されている。Observerが正しく機能していることを確認するために、Observerが観測している先のsubjectをランダムに変更して、Observerの動きを確認する方法が有効である。しかしながら上述したように、テスト段階のパターンの選択に関する重み付けなので、重み値は低めに設定されている。
【００３７】
モデリング段階のパターンと運用段階のシステム構築のためのパターンとの組合せでは、ＭＶＣとスタンドアロン・単一チャネルとの組合せに対して、重み値０．３が付与されている。ＭＶＣは単一マシンによるシステムでも使用できるが、クライアントにビューをおき、サーバにモデルとコントローラとをおく形態でも有効である。そこで、ＭＶＣとスタンドアロン・単一チャネルとの組合せが特に有効というわけではないので、０．３という低めの値に設定している。
また、Brokerと分解との組合せには、重み値０．８が付与されている。Broker機能を中間サーバ上におくことで、分解パターンを実現することができる。そこで、モデリング段階でBrokerが選択された場合には、運用段階で分解が選択されやすいように０．８という高い値を設定している。
【００３８】
開発段階のパターンと運用段階のシステム構築のためのパターンとの組み合わせでは、Commandと分解との組合せに対して、重み値０．７が付与されている。処理を分解して複数のサーバに行わせる場合、処理要求をCommandにすると効果的である。そこで、開発段階でCommandが選択された場合には、運用段階で分解が選択されやすいように０．７という高めの値に設定している。
また、Commandとエージェントとの組合せには、重み値０．７が付与されている。エージェントを用いる場合、処理要求をCommandにした上で、エージェントが適切な処理先を見つけてCommandを渡す形態で実現すると効果的である。そこで、開発段階でCommandが選択された場合には、運用段階でエージェントが選択されやすいように０．７という高めの値に設定している。
【００３９】
以上のように、ソフトウェア・ライフサイクルの各段階におけるパターンの組合せに対しても、異なる段階で適用されるパターンの組合せに対しても、一緒に使用することで高い効果を得られる組合せに対しては高い重み値が付与され、それほど効果が得られない組合せに対しては低い重み値が付与される。また、排他的に使用されるべきパターンの組合せに対しては負の重み値が付与されている。これらの重み値の具体的な値は、ソフトウェア開発の経験に基づいて設定され、図１０および図１１に示した値は例示に過ぎない。また、成功したシステムにおいて使用されている各段階のパターンを調べて、一緒に使用されているパターンの組合せを抽出し、その頻度を分析してフィードバックすれば、実システムに即した重み値を設定することが可能となる。
【００４０】
次に、パターン組合せ検索エンジン３０により生成されるパターンリストについて説明する。
上述したように、パターン組合せ検索エンジン３０は、まず、システムの使用者（ソフトウェア開発者）によって入力された設計目標（パターンの適用目的）に合うパターン（１）を検索しパターンリストにリストアップする。次に、パターン（１）と同じソフトウェア・ライフサイクルの段階におけるパターンの中から上述した重み値を参酌して関連生の高い（重み値の大きい）パターン（２）を検索し、パターンリストにリストアップする。ここで、重み値に基づいてパターン（１）に関連するパターン（２）を選ぶ場合、閾値を設けて、検索するパターン（２）の数を制限することができる（例えば、パターン（１）との間の重み値が０．１以上のパターンのみを検索してパターンリストにリストアップする等）。また、単にパターン（１）との間の重み値が大きいものの他、選択されたパターン（２）との間での重み値が大きい他のパターンを選択することもできる。
【００４１】
具体的には、例えば、開発段階のパターンを検索する場合に、パターン（１）としてCompositeが選択され、このCompositeとの間の重み値が高いFlyweightがパターン（２）として検索されたとする。そして、さらにこのFlyweightとStrategyとの間の重み値が高い場合に、StrategyもCompositeに関連するパターン（２）として検索する。ただし、パターン間の関連を無限にたどってしまうことを避けるため、このような場合は、Composite−Flyweight間の重み値とFlyweight−Strategy間の重み値とを乗算し、算出された値が上記の閾値を超えている場合に限り、Strategyをパターン（２）として検索することとする。
【００４２】
また、この重み値に基づいて検索されたパターン（２）をリストアップする際には、かかるパターン（２）に関して、他のソフトウェア・ライフサイクルの段階において入力された適用目的に基づいて検索されたパターン（ｘ）との間の重み値を参酌する。具体的な方法としては、例えば、パターン（２）をパターンリストにリストアップする際に、同一段階のパターン（１）との間の重み値と他の段階のパターン（ｘ）との間の重み値とを加算し、この加算値によってパターンリストにおける当該パターン（２）の評価を行う。これにより、ソフトウェア・ライフサイクルのある段階で同じ重み値の複数のパターン（２）が検索された場合、それらのパターン（２）とソフトウェア・ライフサイクルの他の段階のパターン（ｘ）との間の重み値が異なるならば、パターンリストへのリストアップにおいて、かかる他の段階のパターン（ｘ）との間の重み値の大きいものほど有効性が高いと判断されることとなる。
【００４３】
また、システムの使用者が設計目標としてパターン適用目的を入力する際、その設計目標の重要性を示す重要度の値を設定して一緒に入力することができる。この場合、パターン組合せ検索エンジン３０によって検索された上記のパターン（２）における重み値の加算値に、設定された重要度の値を乗じて評価値とし、パターンリストにおける当該パターン（２）の評価を行う。これにより、システムの使用者が設計目標を設定する際に個々の設計目標をどの程度重視するかを指定することができ、システムの使用者の要求にきめ細かく対応することが可能となる。
【００４４】
図１２は、パターンリストの例を示す図である。
図１２に示すように、本実施形態で用いられるパターンリストには、ソフトウェア・ライフサイクルにおけるモデリング、開発、テスト、運用の各段階に適用されるべきパターンが列挙される。上述したように、パターン適用エージェント４０は、このパターンリストに基づいて、各段階の実行環境１１〜１４に対する動作制御を行う。図１２に示したパターンリストには、各パターンに対して他の段階のパターンとの間の重み値が記述されており、例えば、開発段階におけるAdapterや運用段階における分解といったパターンがモデリング段階におけるBrokerと一緒に用いることで効果が高い（重み値が大きい）ために選択されていることがわかる。同様にして、同一段階の他のパターンとの間の重み値やこれらの重み値の加算値に重要度の値を乗じた評価値によって、リストアップされるパターンを選択できることは上述の通りである。なお、パターンの組合せに対する重み値は、パターン組合せ検索エンジン３０によってパターンリストに登録されるパターンが検索される際に参照されるものであり、必ずしもパターンリストに記述しなくても良い。
【００４５】
次に、上記のように構成されたオートノミック・コンピューティングシステムを用いたソフトウェアの開発に関わる自立的な動作について説明する。
図１３は、本実施形態によるソフトウェア開発の基本的な手順を説明するフローチャートである。
図１３に示すように、まず、オートノミック・コンピューティングシステムの使用者であるソフトウェア開発者が、ソフトウェア・ライフサイクルの各段階における設計目標（パターン適用目的）と重要度の値とを入力する（ステップ１３０１）。例えば、モデリング段階に対して「クライアントとサーバの独立性」という設計目標を表すキーワード（例えば「クライアント」「サーバ」「独立性」）と重要度の値０．５、開発段階に対して「既存のクラスの利用」という設計目標を表すキーワード（例えば「既存」「クラス」「利用」）と重要度の値０．５、運用段階に対して「既存システムの有効利用」という設計目標を表すキーワード（例えば「既存システム」「有効利用」）と重要度の値１．０という具合に設計目標と重要度の値が入力される。
【００４６】
各段階の設計目標が入力されると、オートノミック・コンピューティングシステムのパターン組合せ検索エンジン３０が、パターンカタログ２０から各段階の設計目標に合うパターンを検索する（ステップ１３０２）。ここで、各段階の設計目標として入力されるパターンの適用目的は、図４、６、８に示したように可変長文字列のテキストにて記録されているが、既存のテキスト検索技術を用いて、入力された設計目標のテキストにできるだけ合致する内容の適用目的を、合致の程度の大きい順に検索することができる。この場合、上記のような設計目標を表すいくつかのキーワードを検索キーとして指定し、パターンカタログ２０に格納されている各パターンの適用目的のテキストを検索して一致度の高いものから選択していく。
次に、パターン組合せ検索エンジン３０は、パターンカタログ２０に登録されている同一段階の他のパターンとの間の重み値にしたがって、各段階における関連性の高いパターンを検索する（ステップ１３０３）。そして、検索されたパターンに対して、ステップ１３０２で検索された他の段階のパターンとの間の重み値およびステップ１３０１で入力された設計目標の重要度の値を加味して評価を行い、各パターンをパターンリストにリストアップする（ステップ１３０４）。
ここまでの動作は、いわばソフトウェア開発の前処理であり、作成されたパターンリストにしたがって、ソフトウェア・ライフサイクルの各段階の作業が実施される。
【００４７】
ソフトウェア開発が開始されると、オートノミック・コンピューティングシステムのパターン適用エージェント４０が、まず、パターン組合せ検索エンジン３０によって作成されたパターンリストにリストアップされた適用可能なパターンの中からソフトウェア・ライフサイクルの各段階で実際に適用するパターンを選択する（ステップ１３０５）。具体的には、パターンリストにリストアップされているパターンの組合せのうちで、重み値の合計が最も高い組合せ、すなわち最も有効性の高い組合せを構成するパターンを、適用するパターンとして自動選択することができる。また、パターンリストをソフトウェア開発者に提示し、ソフトウェア開発者によって選択されたパターンを、適用するパターンとして採用しても良い。
次に、パターン適用エージェント４０は、ステップ１３０４で選択されたソフトウェア・ライフサイクルの各段階に適用されるパターンにしたがって、各段階の実行環境１１〜１４の動作を制御し、ソフトウェア開発を実施する（ステップ１３０６）。
【００４８】
また本実施形態では、オートノミック・コンピューティングの実施例として、上記の基本手順に加え、各段階で適用される事前予測動作と、テスト段階や運用段階で適用される自動解決動作とを行う。
事前予測動作とは、ソフトウェア・ライフサイクルの各段階が実施される際に、所定の段階に適用されるパターンまたはその組合せに関して、次の段階以降の作業で事前にシミュレーションが可能なものについて、シミュレーションを実行し、最適なパターンを割り出す動作である。
【００４９】
図１４は、事前予測動作の流れを説明するフローチャートである。この動作は、図１３のステップ１３０５に示した動作のオプションとして導入される。
パターン適用エージェント４０は、ソフトウェア・ライフサイクルの所定の段階に関して、パターンリストにリストアップされている各パターンまたはその組合せにしたがって、その段階および下流の段階の作業をシミュレーションする（ステップ１４０１）。このシミュレーションは、オートノミック・コンピューティングシステムの空いている資源を用いて行う。次に、パターン適用エージェント４０は、シミュレーションの結果に基づいて、各パターンやその組合せごとに、ソフトウェアの機能やパフォーマンスを評価する（ステップ１４０２）。そして、評価結果に基づいて、実際の実行環境１１〜１４において適用されるパターンまたはその組合せを選択する（ステップ１４０３）。
【００５０】
具体例を挙げると、開発段階に対するパターンの検索では、ソフトウェアの論理モデル（モデリング段階に対するパターン）に対して適用可能な複数のデザインパターンがパターンカタログ２０から選択される。そして、どのデザインパターンが適用されるかに応じて、開発されるソフトウェアのプログラム構造が変わり、そのパフォーマンスも変わることが予想される。そこで、選択されたデザインパターンを適用したコードを実際に生成し、生成されたコードに対して機能テストやパフォーマンス・テストを実行して、最適なパターンを予測することが有効である。なお、コードの生成および各種テストは、例えば、パターン適用エージェント４０によって制御される各実行環境１１〜１４のツールを用いて自動的に実施することができる。
【００５１】
また、運用段階に対するパターンの検索では、コードの物理的な配置パターン、すなわちハードウェアやソフトウェアの構成のトポロジーパターンがパターンカタログ２０から選択される。そこで、選択されたパターンに基づいてコード配置された結果に対してパフォーマンス測定を実行し、最適な配置パターンを予測することが有効である。なお、コード配置およびパフォーマンス測定は、例えば、パターン適用エージェント４０によって制御される本番環境１４のツールを用いて自動的に実施することができる。
【００５２】
自動解決動作とは、テスト環境１３または本番環境１４での実施において、開発されたソフトウェアにバグやパフォーマンス上の問題が発見された場合に、必要に応じてソフトウェア・ライフサイクルを上流に遡り、各段階でのパターンの選択をやり直して問題を解決したり、問題解決の手がかりとなるレポートを作成したりする動作である。
図１５は、自動解決動作の流れを説明するフローチャートである。この動作は、図１３のステップ１３０６によるソフトウェア開発の実施において、テスト段階や運用段階で問題が発生した場合に実行される。
ソフトウェア・ライフサイクルの開発段階やテスト段階でパフォーマンス等の問題が発見されると、パターン適用エージェント４０にその報告がなされる（ステップ１５０１）。パターン適用エージェント４０は、問題発生の報告を受けると、問題の発生した段階よりも上流の段階に戻り、問題の発生したパターンとは異なるパターンをパターンリストから選択して（ステップ１５０２）、その段階から改めてソフトウェア開発の実施する（ステップ１５０３）。
【００５３】
図１６は、ソフトウェア・ライフサイクルの全体の流れと本実施形態のオートノミック・コンピューティングによる自動解決動作との関係を説明する図である。
図１６に示すように、テスト段階で適宜ツールを用いて、機能テスト、パフォーマンス・テストが実施され、問題が発見されたならば、問題発見を示す通知がテスト環境１３からパターン適用エージェント４０に送信される。また、運用段階でソフトウェアが実際に使用されて問題が発生した場合や、パフォーマンス測定によって問題が発見された場合には、問題発生を示す通知が本番環境１４からパターン適用エージェント４０に送信される。テスト環境１３や本番環境１４からこのような通知を受信したパターン適用エージェント４０は、記憶装置に保存されているパターンリストを読み出し、改めてこのパターンリストに基づき、問題の発生したパターンとは異なるパターンを選ぶ。そして、問題が発生した段階よりも上流の段階から実行環境１１〜１４の制御を行い、各段階の作業をやり直す。ここで、新たに採用するパターンは、パターンリストに複数のパターンの組合せがリストアップされておりその重み値や評価値が記述されているならば、問題の発生した組合せの次にそれらの値が大きい組合せを選ぶことができる。また、パターンリストの表示用画像データを生成し、図２に示したビデオカード１０４を介してディスプレイ表示に表示することにより、パターンリストをシステムの使用者（ソフトウェア開発者）に提示し、キーボード等の入力手段により使用者が所望の組合せを指定する操作を受け付けて、選択された組合せを採用するようにしても良い。さらに、問題の発生したパターンの組合せをリストアップしないように条件付けを行った上で、パターン組合せ検索エンジン３０によりパターンリストを作成し直すこともできる。
さらに、テスト段階や運用段階ばかりでなく、開発段階において、コードの実装（自動ビルド）や検証（自動バリデーション）の際に問題が発見された場合にも、モデリング段階に遡ってパターンの適用からやり直すことも可能である。
【００５４】
具体例を挙げると、テスト段階や運用段階でパターン適用エージェント４０に問題が報告された場合、上流の開発段階に戻って、問題の原因となったソフトウェアのバグを判別するためのバグ解析用コードを開発対象のソフトウェアに埋め込む。バグ解析用コードの埋め込みは、他のコードと同様に開発環境１２のコードの自動生成ツールを制御して行うことが可能である。この場合、どのような問題を判別するために用いることができるバグ解析用コードを記述した問題判別用のパターンを作成して予めパターンカタログ２０に登録しておき、パターン組合せ検索エンジン３０により問題の現象に合うパターンを選択してパターンリストを作成できるようにする。
テスト段階での問題発生に対してバグ解析用コードが埋め込まれた場合は、このバグ解析用コードが埋め込まれたソフトウェアがテスト段階で改めてテストされると、同様の問題が発生するが、この際にバグ解析用コードの機能により、問題の種類やソフトウェアの原因箇所を記録した解析データが自動作成され、テスト環境１３の記憶装置に蓄積される（あるいは、ネットワークを介してテスト環境１３からパターン適用エージェント４０へ送信されて、図２に示した磁気ディスク装置１０５等の記憶装置に蓄積される）こととなる。
運用段階での問題発生に対してバグ解析用コードが埋め込まれた場合は、このバグ解析用コードが埋め込まれたソフトウェアが運用段階で業務遂行のために実行される。そして、同様の問題が再度発生した場合に、バグ解析用コードの機能により、問題の種類やソフトウェアの原因箇所を記録した解析データが自動作成され、本番環境１４の記憶装置に蓄積される（あるいは、ネットワークを介して本番環境１４からパターン適用エージェント４０へ送信されて、図２に示した磁気ディスク装置１０５等の記憶装置に蓄積される）こととなる。
【００５５】
また、テスト段階や運用段階でパターン適用エージェント４０にパフォーマンス上の問題が報告された場合、上流の開発段階に戻って、パフォーマンス分析の仕組み（測定環境）を開発対象のソフトウェアに組み込む。これは例えば、パフォーマンス測定用のコードを開発対象のソフトウェアに埋め込むことで実現される。パフォーマンス測定用コードの埋め込みは、他のコードと同様に開発環境１２のコードの自動生成ツールを制御して行うことが可能である。この場合、どのようなパフォーマンス分析方法を用いることが適当であるかを記述したパフォーマンス分析用のパターンを作成して予めパターンカタログ２０に登録しておき、パターン組合せ検索エンジン３０によりパターンリストを作成できるようにする。
このパフォーマンス測定用コードが埋め込まれたソフトウェアがテスト段階で改めてパフォーマンス・テストされると、パフォーマンス測定用コードの機能により、このソフトウェアのパフォーマンス分析が実行され、ソフトウェアのどの部分のパフォーマンスが悪いか（多大な実行時間を要しているか、遅延が生じているか等）を分析し、分析結果を記録した分析データが自動作成され、テスト環境１３の記憶装置に蓄積される（あるいは、ネットワークを介してテスト環境１３からパターン適用エージェント４０へ送信されて、図２に示した磁気ディスク装置１０５等の記憶装置に蓄積される）こととなる。
また、問題個所が開発段階におけるパターン選択に関係している場合には、パターンリストにリストアップされている複数のパターンを各々適用してパフォーマンス・テストを実行し、最適なパターンを選択し直して、開発段階以降の作業を実施することもできる。
【００５６】
以上のようにして、本実施形態のオートノミック・コンピューティングシステムは、ソフトウェア・ライフサイクルの各段階に対して自立的に対応しながら各実行環境１１〜１４の動作制御を行ってソフトウェアの開発効率の向上に寄与する。
また、ソフトウェア・ライフサイクルの各段階で、適用すべき設計のパターンを選択するために次の段階以降のシミュレーションを行って問題の発生を事前に予測したり、テスト段階や運用段階で実際に問題が発生した場合に、開発段階やモデリング段階に遡って設計のパターンの適用を変更することにより自立的に対応したりすることができる。
【図面の簡単な説明】
【００５７】
【図１】本実施形態によるオートノミック・コンピューティングシステムの全体構成を示す図である。
【図２】本実施形態によるオートノミック・コンピューティングシステムを実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
【図３】ソフトウェア・ライフサイクルのモデリング段階で適用される設計のパターンの例を示す図である。
【図４】パターンカタログに格納されたブローカーに関する情報の例を示す図である。
【図５】ソフトウェア・ライフサイクルの開発段階で適用される設計のパターンの例を示す図である。
【図６−１】パターンカタログに格納されたAdapterに関する情報の例を示す図である。
【図６−２】パターンカタログに格納されたCommandに関する情報の例を示す図である。
【図７】ソフトウェア・ライフサイクルのテスト段階で適用される設計のパターンの例を示す図である。
【図８】ソフトウェア・ライフサイクルの運用段階で適用される設計のパターンの例を示す図である。
【図９】パターンカタログに格納された分解アプリケーション・パターンに関する情報の例を示す図である。
【図１０】開発段階で適用されるデザインパターンの場合を例として、パターンの組合せとその重み値との関係を示す図表である。
【図１１】異なる段階で適用されるパターンの組合せとその重み値との関係を示す図表である。
【図１２】本実施形態で用いられるパターンリストの例を示す図である。
【図１３】本実施形態によるソフトウェア開発の基本的な手順を説明するフローチャートである。
【図１４】本実施形態による事前予測動作の流れを説明するフローチャートである。
【図１５】本実施形態による自動解決動作の流れを説明するフローチャートである。
【図１６】ソフトウェア・ライフサイクルの全体の流れと本実施形態のオートノミック・コンピューティングによる自動解決動作との関係を説明する図である。
【符号の説明】
【００５８】
１１…モデリング環境、１２…開発環境、１３…テスト環境、１４…本番環境、２０…パターンカタログ、３０…パターン組合せ検索エンジン、４０…パターン適用エージェント、１０１…ＣＰＵ（Central Processing Unit：中央処理装置）、１０３…メインメモリ、１０５…磁気ディスク装置（ＨＤＤ）
【図１】
2005173788.tif 000003
【図２】
2005173788.tif 000004
【図３】
2005173788.tif 000005
【図４】
2005173788.tif 000006
【図５】
2005173788.tif 000007
【図６−１】
2005173788.tif 000008
【図６−２】
2005173788.tif 000009
【図７】
2005173788.tif 000010
【図８】
2005173788.tif 000011
【図９】
2005173788.tif 000012
【図１０】
2005173788.tif 000013
【図１１】
2005173788.tif 000014
【図１２】
2005173788.tif 000015
【図１３】
2005173788.tif 000016
【図１４】
2005173788.tif 000017
【図１５】
2005173788.tif 000018
【図１６】
2005173788.tif 000019