JP2011222020A - ソフトウェアシステムの自律管理提供方法、これを実行するプログラムを記録した記録媒体及びソフトウェアの自律管理機能を備えたシステム - Google Patents

Abstract

【課題】ユーザの介入なしにリアルタイムに変化する環境に対応して最適化されたサービスを提供する。
【解決手段】リアルタイムに変化する環境に対応して最適化されたシステムを提供することができるソフトウェアシステムの自律管理提供方法、これを実行するプログラムを記録した記録媒体及びソフトウェアの自律管理機能を備えたシステムが開示される。ユーザからサービスを要請されれば、動的フィーチャーモデルから要請されたサービスを提供することができるシステムのすべての構成を獲得し、あらかじめ設定された方針に基づいて獲得したシステムのすべての構成のうち要請されたサービスに相当する構成を獲得してシステムの資源を再構成し、再構成された資源に基づいて要請されたサービスを提供する。したがって、ユーザの介入なしにリアルタイムに変化する環境に対応して最適化されたサービスを提供することができる。
【選択図】図１

Description

本発明は、ソフトウェア開発方法に関し、さらに詳細には、実行時に動的に変化する情報に基づいてシステムのための最適化された構成を提供することができるソフトウェアシステムの自律管理提供方法、これを実行するプログラムを記録した記録媒体及びソフトウェアの自律管理機能を備えたシステムに関する。

製品系列工学（ＰＬＥ：Product Line Engineering）は、ソフトウェアを開発するとき、体系的な再使用技法を適用することによって、同一領域で多様に特化したソフトウェアを迅速に開発することができる効果的な方法を提供する接近方法であって、領域（Domain）を分析し、１つの領域に属する多様なアプリケーションの共通点と差異点を抽出し、これに基づいて再使用が可能な製品系列資産（product line asset）を定義し、早い時間内に同じ製品系列のソフトウェアを開発する方法である。

製品系列工学のための方法のうち、１９９０年にＣＭＵ ＳＥＩで提案したフィーチャー基盤ソフトウェア開発（Feature-Oriented Software Development）方法が最も広く活用されている。フィーチャー基盤ソフトウェア開発方法は、製品の共通点と差異点を領域専門家（domain expert）がフィーチャー（feature）単位で分析し、フィーチャーモデルを定義し、応用プログラム開発者が、定義されたフィーチャーモデルを基盤として新しい製品を早い時間内に開発することができるようにする方法である。

具体的に、従来のフィーチャー基盤ソフトウェア開発方法においては、領域専門家が製品の系列を分析した後、分析した製品系列を基盤として製品系列再使用ライブラリ（Product Line Reuse Library）を作成し、これをフィーチャーモデル（feature model）を利用して関係を定義する。そして、アプリケーション専門家（application engineer）がフィーチャーモデルを基盤として当該ソフトウェアシステムの要求事項に合うように新しいソフトウェアを容易に開発した。

しかしながら、前述したような従来のフィーチャー基盤ソフトウェア開発方法は、ソフトウェア開発時間及び経済的費用を効果的に使用することができる長所があるが、ソフトウェア開発者が与えられた環境を考慮して手動にフィーチャーを選択し、静的にソフトウェアシステムを構成するので、ソフトウェアシステムの実行時にリアルタイムに変化する環境に動的に対応して最適化されたシステムを提供することができず、そのため、ユーザの介入が必要であるという短所がある。

本発明の目的は、リアルタイムに変化する環境に対応して最適化されたシステムを提供することができるソフトウェアシステムの自律管理提供方法を提供することにある。
また、本発明の他の目的は、前記ソフトウェアシステムの自律管理提供方法を実行するプログラムを記録した記録媒体を提供することにある。

また、本発明のさらに他の目的は、リアルタイムに変化する環境に対応して最適化されたシステムを提供することができるソフトウェアの自律管理機能を備えたシステムを提供することにある。

本発明の目的は、前述した目的に限定されず、言及していない他の目的は、下記の記載から当業者に明確に理解されることができる。

上記目的を達成するために、本発明の一態様によるソフトウェアシステムの自律管理提供方法は、ユーザからサービスを要請されるステップと、動的フィーチャーモデル（dynamic feature model）から前記要請されたサービスを提供することができるシステムのすべての構成（configuration）を獲得するステップと、あらかじめ設定された方針に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を獲得するステップと、前記獲得した構成に基づいてシステムの資源を再構成するステップと、前記再構成された資源に基づいて前記要請されたサービスを提供するステップとを含む。前記動的フィーチャーモデルは、ソフトウェアシステムの実行時に動作することができる客体の構成（configuration）を示すことができる。前記動的フィーチャーモデルは、ソフトウェアシステムが設置されたシステムの実行時に変化する値を定義する実行中フィーチャー（runtime feature）を含むことができる。前記獲得したシステムのすべての構成のうちあらかじめ設定された方針に基づいて要請されたサービスに相当する構成を獲得するステップは、前記システムの前記実行中フィーチャー（runtime feature）に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに最も適した構成を獲得することができる。前記ソフトウェアシステムの自律管理提供方法は、前記あらかじめ設定された方針に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を獲得するステップの前に、前記システムまたは周囲の物理的な環境から状況（context）情報を獲得するステップをさらに含むことができる。前記あらかじめ設定された方針に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を獲得するステップは、前記あらかじめ設定された方針及び前記獲得した状況情報に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を獲得することができる。

また、本発明の他の態様によるソフトウェアシステムの自律管理提供方法を実行するプログラムを記録した記録媒体は、要請されたサービスを提供することができるシステムのすべての構成（configuration）を動的フィーチャーモデル（dynamic feature model）から獲得するステップと、あらかじめ設定された方針に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を獲得するステップと、前記獲得した構成に基づいてシステムの資源を再構成するステップと、前記再構成された資源に基づいて前記要請されたサービスを提供するステップとを実行するプログラムが記録される。

また、本発明のさらに他の態様によるソフトウェア自律管理機能を備えたシステムは、要請されたサービスを提供することができるシステムのすべての構成（configuration）を提供する動的フィーチャーモデルと、あらかじめ設定された方針情報に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を提供する自律管理者と、前記自律管理者から要請されたサービスのための構成を提供され、前記提供された構成に基づいてシステムの資源を再構成した後、再構成された資源に基づいてユーザにサービスを提供するコアシステムとを含む。前記ソフトウェア自律管理機能を備えたシステムは、ユーザが設定した方針を提供され、前記提供された方針または前記提供された方針に相当する目標を前記自律管理者に提供する方針管理者と、前記システムまたは周囲の物理的な環境から状況情報を収集し、収集した状況情報を前記自律管理者に提供する状況管理者とをさらに含むことができる。前記自律管理者は、前記あらかじめ設定された方針情報及び前記状況情報に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を提供することができる。前記動的フィーチャーモデルは、前記システムの実行時に変化する値を定義する実行中フィーチャー（runtime feature）を含むことができる。前記自律管理者は、前記システムの前記実行中フィーチャーに基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を提供することができる。

以上説明したように、本発明によるソフトウェアシステムの自律管理提供方法及びソフトウェアの自律管理機能を備えたシステムによれば、ソフトウェアシステムが静的に構成されるだけでなく、システムの実行中にリアルタイムに変化する環境を示す実行中フィーチャー（runtime feature）を含む動的フィーチャーモデルを利用して要請されたサービスに最適化された構成を抽出し、抽出された構成を利用してシステムの資源を再構成した後、サービスを提供する。

したがって、ユーザの介入なしにリアルタイムに変化する環境に対応して最適化されたサービスを提供することができ、このような特徴に起因して、要求される目的によって動的に再構成が可能なソフトウェアシステムが必要な埋め込みシステム、ロケット、軍用ソフトウェアシステムなどに活用されることができる。

本発明の一実施例によるソフトウェアの自律管理を実行するシステムの構成を示すブロック図である。 本発明の一実施例によるソフトウェアシステムの自律管理方法を示すフローチャートである。 本発明の一実施例によるソフトウェアシステムの自律管理方法に適用される静的フィーチャーモデルと動的フィーチャーモデルの関係を説明するための概念図である。 本発明の一実施例によるソフトウェアシステムの自律管理方法に適用される静的フィーチャーモデルと動的フィーチャーモデルを比較したものを示す。 本発明の一実施例によるソフトウェアシステムの自律管理方法が適用される例を説明するための移動通信端末機の静的フィーチャーモデルの構成を示す概念図である。 本発明の一実施例によるソフトウェアシステムの自律管理方法が適用される例を説明するための移動通信端末機の動的フィーチャーモデルの構成を示す概念図である。 図６に示す移動通信端末機の動的フィーチャーモデルを基盤として自律管理される移動通信端末機の状態図を示す。

本発明は、多様な変更を加えることができ、様々な実施例を有することができるところ、特定の実施例を図面に例示し、詳細な説明に詳細に説明する。しかし、これは、本発明を特定の実施形態に限定しようとするものではなく、本発明の思想及び技術範囲に含まれるすべての変更、均等物及び代替物を含むものと理解すべきである。なお、各図面を説明するに際して、類似の参照符号を類似の構成要素に対して使用した。

第１、第２などの用語は、多様な構成要素を説明するのに使用されることができるが、前記構成要素は、前記用語に限定されるわけではない。前記用語は、１つの構成要素を他の構成要素から区別する目的だけで使用される。例えば、本発明の権利範囲を脱することなく、第１構成要素は、第２構成要素として命名されることができ、同様に、第２構成要素も第１構成要素として命名されることができる。及び／またはという用語は、複数の関連された記載項目の組み合わせまたは複数の関連された記載項目のうちいずれかの項目を含む。

任意の構成要素が他の構成要素に「連結されて」いるか、「接続されて」いると記述されたときには、他の構成要素に直接的に連結されているか、または接続されていることもできるが、中間に他の構成要素が存在することもできると理解すべきである。一方、任意の構成要素が他の構成要素に「直接連結されて」いるか、「直接接続されて」いると記述されたときには、中間に他の構成要素が存在しないものと理解すべきである。

本出願において使用した用語は、ただ特定の実施例を説明するために使用されたものであって、本発明を限定しようとする意図ではない。単数の表現は、文脈上、明白に異なって意味しない限り、複数の表現を含む。本出願において、「含む」または「有する」などの用語は、記述された特徴、数字、ステップ、動作、構成要素、部分品またはこれらを組み合わせたものが存在することを指定しようとするものであって、１つまたはそれ以上の他の特徴、数字、ステップ、動作、構成要素、部分品またはこれらを組み合わせたものなどの存在または付加可能性をあらかじめ排除しないものと理解すべきである。

以下、添付の図面を参照して、本発明の好ましい実施例をさらに詳細に説明する。以下、図面において、同一の構成要素については、同一の参照符号を使用し、同一の構成要素について重複説明は省略する。

図１は、本発明の一実施例によるソフトウェアの自律管理を実行するシステムの構成を示すブロック図である。
図１を参照すれば、領域専門家（Domain engineer）は、製品系列（Product line）を分析し、これを基盤として製品系列再使用ライブラリ（Product Line Reuse Library）１１０を生成し、これを静的フィーチャーモデル（Static Feature Model）１２０を利用して関係を示す。

アプリケーション専門家（Application engineer）は、前記静的フィーチャーモデル１２０に基づいて開発しようとする当該ソフトウェアシステムの要求事項に対応してソフトウェアを開発する。

また、領域専門家は、コアシステム１４０の実行時の製品再構成のための意思決定のための動的フィーチャーモデル（Dynamic Feature Model）１３０を生成する。ここで、前記静的フィーチャーモデル１２０及び動的フィーチャーモデル１３０は、ソフトウェアシステムの開発時に生成されることができる。

本発明の一実施例によるソフトウェアシステムの自律管理提供方法においては、従来のフィーチャー基盤ソフトウェア開発方法を拡張し、従来のフィーチャーモデルを静的フィーチャーモデル１２０として命名し、前記静的フィーチャーモデルを基盤としてソフトウェアシステムの実行時に変化可能なフィーチャーモデルを分析し、分析したフィーチャーモデルを基盤として動的フィーチャーモデル１３０を新しく定義する。

前記動的フィーチャーモデル１３０は、コアシステム１４０の実行時にどんな構成で動作するかをすべて定義することができるモデルであって、静的フィーチャーモデル１２０で選択された機能に基づいて前記選択された機能の実行時にどのように活性化されるかを定義したものである。

コアシステム（Core system）１４０は、所定領域のハードウェア及びハードウェアに設置され、ハードウェアの動作を制御するソフトウェアシステムをすべて含み、ユーザから新しいサービス要請を提供され、提供されたサービス要請情報を自律管理者１５０に提供する。その後、コアシステム１４０は、自律管理者１５０から要請されたサービスのための構成情報を提供され、提供された構成情報に基づいてシステムの資源を再構成（reconfiguration）した後、再構成されたシステム資源に基づいてユーザにサービスを提供する。

自律管理者（autonomic manager）１５０は、方針管理者１６０から提供された方針情報と、状況管理者１７０から提供された状況情報に基づいて、動的フィーチャーモデル１３０から提供されたコアシステム１４０のすべての可能な構成情報のうちユーザから要請されたサービスに最も適した構成を抽出した後、コアシステム１４０に提供する。

方針管理者（Policy manager）１６０は、ユーザから上位レベルの方針（policy）を提供され、提供された方針または前記上位レベルの方針に相当する具体的な目標を自律管理者１５０に提供する。

状況管理者（Context manager）１７０は、コアシステム及び／または周囲の物理的な環境から提供されることができる状況（context）情報を収集し、収集した状況情報を自律管理者１５０に提供する。

図２は、本発明の一実施例によるソフトウェアシステムの自律管理方法を示すフローチャートである。
図１及び図２を参照して本発明の一実施例によるソフトウェアシステムの自律管理方法を説明すれば、まず、コアシステム１４０は、ユーザからサービス要請を提供され（ステップ２１０）、提供されたサービス要請情報を自律管理者１５０に提供する。

自律管理者１５０は、方針管理者１６０からユーザが設定した方針情報を獲得し（ステップ２２０）、状況管理者１７０からコアシステム及び／または周囲の物理的な環境から状況情報を獲得する（ステップ２３０）。

また、自律管理者１５０は、動的フィーチャーモデルからシステムのすべての可能な構成情報を獲得し（ステップ２４０）、獲得した前記方針情報及び状況情報に基づいて前記システムのすべての可能な構成情報のうちユーザが要請したサービスに最も適した構成を抽出した後（ステップ２５０）、抽出した構成情報をコアシステム１４０に提供する。

コアシステム１４０は、自律管理者１５０から提供された構成情報に基づいてシステムの資源を再構成し（ステップ２６０）、再構成された資源を利用してユーザが要請したサービスを提供する（ステップ２７０）。

図２では、サービス要請が受け付けられた後（ステップ２１０）、ユーザが設定した方針情報を獲得し（ステップ２２０）、状況情報を獲得（ステップ２３０）するものと例示して説明したが、これは、説明の便宜のためのものに過ぎず、実質的には、ステップ２１０〜ステップ２３０は、順序が互いに変わって実行されてもよい。また、ステップ２２０及び／またはステップ２３０は、ステップ２４０と実行順序が変わってもよい。

図３は、本発明の一実施例によるソフトウェアシステムの自律管理方法に適用される静的フィーチャーモデルと動的フィーチャーモデルの関係を説明するための概念図である。
図３を参照すれば、図３において、上部の円錐（cone）領域は、ソフトウェアシステムの開発のための静的フィーチャーモデルを示し、下部の円錐領域は、１つの製品が実行中に再構成されることができる動的フィーチャーモデルを示す。

図３において、Ｐ₁、Ｐ₂、Ｐ₃及びＰ₄は、プログラム（program）を意味し、ｆ₁、ｆ₂、ｆ₃及びｆ₄は、静的フィーチャー（static features）を意味する。また、Ｃ₁、Ｃ₂、Ｃ₃及びＣ₄は、構成（configuration）を意味し、ｆ₁'及びｆ₂'は、動的フィーチャー（dynamic feature）を意味する。

静的フィーチャーモデルは、フィーチャーを利用して基本的なソフトウェアプログラムであるＰ₁からＰ₂、Ｐ₃及びＰ₄を漸進的に開発することができる。例えば、加算機能のみを有する電卓プログラムがＰ₁であり、ｆ₁は、減算機能、ｆ₂は、除算機能として仮定すれば、Ｐ₄は、加算、減算及び除算機能を有する電卓プログラムが作成される。

動的フィーチャーモデルは、前述したように生成されたソフトウェアシステムが実行される途中にどんな構成で動作するかを示す。すなわち、静的フィーチャーモデルにおいてフィーチャーがプログラムコードなら、動的フィーチャーモデルにおいては、これに対する客体となる。例えば、ソフトウェアシステムが実行される途中に、プログラムＰ₄は、方針及び状況情報に基づいて加算だけで構成されたＣ₁になることもでき、減算及び／または除算機能が付加され、Ｃ₂、Ｃ₃及びＣ₄のうちいずれか１つで再構成されることもできる。また、前述したＣ₁、Ｃ₂、Ｃ₃及びＣ₄の構成は、方針及び状況情報によって動的フィーチャーが追加されるか、除外され、構成が変更されることもできる。

図４は、本発明の一実施例によるソフトウェアシステムの自律管理方法に適用される静的フィーチャーモデルと動的フィーチャーモデルを比較したものを示す。
図４を参照すれば、静的フィーチャーモデルは、ソフトウェアプログラムの合成のためのものであり、動的フィーチャーモデルは、システムが実行される途中に再構成のための意思決定モデルである。

また、静的フィーチャーモデル及び動的フィーチャーモデルは、領域工学者（または領域専門家）がソフトウェア開発時点に生成し、静的フィーチャーモデルは、ソフトウェアシステムの開発時点にソフトウェア開発者が意思決定をし、動的フィーチャーモデルは、システムの実行時に自律管理者またはユーザによって決定される。

静的フィーチャーモデルにおけるフィーチャーの組み合わせがソフトウェアシステムなら、動的フィーチャーモデルにおいてフィーチャーの組み合わせは、システムの実行中の状態（または構成）となる。システムが動作されるうちのソフトウェアシステムを有限仮想機械（ＦＳＭ：Finite State Machine）で示す場合、状態は、独立的な状態なので、これと同じであると言える。

図５は、本発明の一実施例によるソフトウェアシステムの自律管理方法が適用される例を説明するための移動通信端末機の静的フィーチャーモデルの構成を示す概念図である。
移動通信端末機に設置されるソフトウェアは、移動通信端末機に具備される多様なハードウェアに対応して多様な機能が提供されなければならないので、製品系列工学を適用するのに非常に適した事例である。

フィーチャーモデルは、領域内の専門家と一般ユーザまたは開発者間の意思疎通手段で領域内の様々なシステムの共通点と差異点をＡＮＤ／ＯＲグラフで図式化した領域分析モデルである。フィーチャーモデルは、領域内の共通的なフィーチャーは、必須（Mandatory）フィーチャーで表現され、システム間の区別される差異点は、選択的（Optional）フィーチャー、二者択一（Alternative）フィーチャー、そして１つ以上の選択を行うことができるＯＲフィーチャーで表現される。

図５を参照して移動通信端末機の静的フィーチャーモデルを説明すれば、移動通信端末機においてアプリケーション（application）は、必須フィーチャーであり、アプリケーションにおいて画像通話（Video Call）は、選択的フィーチャーに該当する。移動通信端末機は、アプリケーションを含むこともでき、ネットワークインターフェース（network interface）をも有することができ、方針（policy）をも有することができる。このような場合、アプリケーション（application）、ネットワークインターフェース（network interface）及び方針（policy）を基本（Base）移動通信端末機に与えられたフィーチャーモデルの関係に基づいて追加し、新しい移動通信端末機システムを製作することができる。

図５に示された移動通信端末機の静的フィーチャーモデルにおいては、アプリケーション（application）は、音声通話（Voice call）を必ず含まれなければならないし、ＣＤＭＡ、ＷＬＡＮ、ＷｉＢｒｏ、ブルートゥース（Bluetooth）のうち少なくとも１つのネットワークインターフェース（network interface）と方針（policy）を含むことを示す。

図６は、本発明の一実施例によるソフトウェアシステムの自律管理方法が適用される例を説明するための移動通信端末機の動的フィーチャーモデルの構成を示す概念図である。
図６を参照すれば、静的フィーチャーモデルが製品の機能的な特性を分析して生成されることに対し、動的フィーチャーモデルは、実行中のシステムの特性を分析して生成される。例えば、図５に示す移動通信端末機の静的フィーチャーモデルにおいてソフトウェア開発者がアプリケーション（application）として音声通話（voice call）及びウェブブラウザー（web browser）を選択し、ネットワークインターフェース（network interface）としてＣＤＭＡ、ＷＬＡＮ、ＷｉＢｒｏを選択し、ネットワークインターフェース（network interface）を選択する方法として、ＲＳＳ（Received Signal Strength）、Ｃｏｓｔ、Ｐｏｗｅｒ、Ｑｕａｌｉｔｙ、Ｍａｎｕａｌを選択したと仮定すれば、移動通信端末機は、前述した機能をすべて含んで製造される。

動的フィーチャーモデルは、システムの実行中にどのように変化可能であるかを示す。例えば、図６に示す移動通信端末機の動的フィーチャーモデルを見れば、現在移動通信端末機は、実行中に、アプリケーション（application）は実行されないか、または音声通話（voice call）及びウェブブラウザー（web browser）のうちただ１つだけ実行可能であり、ネットワークインターフェース（network interface）も活性化されないか、またはＣＤＭＡ、ＷＬＡＮ及びＷｉＢｒｏのうちただ１つだけ活性化が可能であり、方針（policy）もＲＳＳ、Ｃｏｓｔ、Ｐｏｗｅｒ、Ｑｕａｌｉｔｙ及びＭａｎｕａｌのうちいずれか１つだけ選択可能であることが分かる。

図６に示されたような動的フィーチャーモデルを有する移動通信端末機において自律管理者は、動的フィーチャーモデルを基盤として設定された当該方針（policy）に対応してシステムを管理するようになる。例えば、自律管理者は、アプリケーション（application）ごとに設定された方針（policy）に基づいて最適のネットワークインターフェース（network interface）を選択することができる。

前記動的フィーチャーモデルには、静的フィーチャーモデルにない新しいフィーチャーで実行中に変化することができる値を実行中フィーチャー（runtime feature）として定義した。図６においては、ネットワークインターフェース（network interface)の場合に、使用可能性（Availability）、信号強度（Signal strength)、コストモデル（Cost Model）、電力消耗率（power consumption rate）、品質（quality）などがシステムの実行中に動的に変化可能なフィーチャーを示し、自律管理者は、移動通信端末機の実行中に前述した実行中フィーチャーを利用して最適のネットワークインターフェースを選択する。例えば、ＣＤＭＡを使用することができない場所では、ＣＤＭＡの使用可能性（Availability）がＦ（False）となり、このような実行中フィーチャー（runtime feature）の値を利用して自律管理者は、最も適切なネットワークインターフェース（network interface）を選択するようになる。

図７は、図６に示す移動通信端末機の動的フィーチャーモデルを基盤として自律管理される移動通信端末機の状態図を示す。
図７を参照すれば、移動通信端末機は、パワーがオンとされれば（turn on）、パワーオフＰＯＷＥＲ＿ＯＦＦ状態からパワーオンＰＯＷＥＲ＿ＯＮ状態に状態が遷移され、パワーオン状態から待機状態Ｓ１（IDLE）に動作を開始する。

その後、移動通信端末機は、ユーザの操作に対応して音声通話Ｓ２（Voice call）状態またはウェブブラウザーＳ３（Web browser）状態に転移される。
前述したように、状態が転移され、音声通話またはウェブブラウザーが使用される場合、ネットワークインターフェースが活性化される。ここで、ネットワークインターフェースが使用される初期には、ユーザがＣＤＭＡ、ＷＬＡＮ及びＷｉＢｒｏのうちいずれか１つのネットワークインターフェースを直接選択し、その後、移動通信端末機は、動的フィーチャーモデルを基盤とした実行中フィーチャー（runtime feature）とあらかじめ設定された方針（policy）及び／または収集された状況（context）情報に基づいて最適のネットワークインターフェースを自律的に選択するようになる。

例えば、移動通信端末機の待機状態Ｓ１でユーザが音声通話Ｓ２を選択し、最初にネットワークインターフェースとしてＷｉＢｒｏ Ｓ６を選択したと仮定すれば、移動通信端末機の自律管理者は、移動通信端末機が実行される途中に変化する実行中フィーチャー（runtime feature）とユーザがあらかじめ設定した方針（policy）に基づいて自律的に所定の時点にネットワークインターフェースとしてＷＬＡＮ Ｓ５を選択することができる。

以上、本発明を好ましい実施例により詳細に説明したが、本発明は、前記実施例に限定されず、本発明の技術的思想及び範囲内で当該分野における通常の知識を有する者によって様々な変形及び変更が可能である。

１１０ 製品系列再使用ライブラリ
１２０ 静的フィーチャーモデル
１３０ 動的フィーチャーモデル
１４０ コアシステム
１５０ 自律管理者
１６０ 方針管理者
１７０ 状況管理者

Claims (12)

1. ユーザからサービスを要請されるステップと、
   動的フィーチャーモデル（dynamic feature model）から前記要請されたサービスを提供することができるシステムのすべての構成（configuration）を獲得するステップと、
   あらかじめ設定された方針に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を獲得するステップと、
   前記獲得した構成に基づいてシステムの資源を再構成するステップと、
   前記再構成された資源に基づいて前記要請されたサービスを提供するステップと、を含むソフトウェアシステムの自律管理提供方法。
2. 前記動的フィーチャーモデルは、
   ソフトウェアシステムの実行時に動作することができる客体の構成（configuration）を示すことを特徴とする請求項１に記載のソフトウェアシステムの自律管理提供方法。
3. 前記動的フィーチャーモデルは、
   ソフトウェアシステムが設置されたシステムの実行時に変化する値を定義する実行中フィーチャー（runtime feature）を含むことを特徴とする請求項１に記載のソフトウェアシステムの自律管理提供方法。
4. 前記獲得したシステムのすべての構成のうちあらかじめ設定された方針に基づいて要請されたサービスに相当する構成を獲得するステップは、
   前記システムの前記実行中フィーチャー（runtime feature）に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに最も適した構成を獲得することを特徴とする請求項３に記載のソフトウェアシステムの自律管理提供方法。
5. 前記ソフトウェアシステムの自律管理提供方法は、
   前記あらかじめ設定された方針に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を獲得するステップの前に、前記システムまたは周囲の物理的な環境から状況（context）情報を獲得するステップをさらに含むことを特徴とする請求項１に記載のソフトウェアシステムの自律管理提供方法。
6. 前記あらかじめ設定された方針に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を獲得するステップは、
   前記あらかじめ設定された方針及び前記獲得した状況情報に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を獲得することを特徴とする請求項５に記載のソフトウェアシステムの自律管理方法。
7. ソフトウェアの自律管理を実行するデジタル処理装置によって実行されることができる命令語のプログラムが類型的に具現されていて、前記デジタル処理装置によって読み取り可能なプログラムを記録した記録媒体において、
   要請されたサービスを提供することができるシステムのすべての構成（configuration）を動的フィーチャーモデル（dynamic feature model）から獲得するステップと、
   あらかじめ設定された方針に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を獲得するステップと、
   前記獲得した構成に基づいてシステムの資源を再構成するステップと、
   前記再構成された資源に基づいて前記要請されたサービスを提供するステップとを実行するプログラムを記録した記録媒体。
8. 要請されたサービスを提供することができるシステムのすべての構成（configuration）を提供する動的フィーチャーモデルと、
   あらかじめ設定された方針情報に基づいて獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を提供する自律管理者と、
   前記自律管理者から要請されたサービスのための構成を提供され、前記提供された構成に基づいてシステムの資源を再構成した後、再構成された資源に基づいてユーザにサービスを提供するコアシステムと、を含むソフトウェア自律管理機能を備えたシステム。
9. 前記ソフトウェア自律管理機能を備えたシステムは、
   ユーザが設定した方針を提供され、前記提供された方針または前記提供された方針に相当する目標を前記自律管理者に提供する方針管理者と、
   前記システムまたは周囲の物理的な環境から状況情報を収集し、収集した状況情報を前記自律管理者に提供する状況管理者と、をさらに含むことを特徴とする請求項８に記載のソフトウェア自律管理機能を備えたシステム。
10. 前記自律管理者は、前記あらかじめ設定された方針情報及び前記状況情報に基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を提供することを特徴とする請求項９に記載のソフトウェア自律管理機能を備えたシステム。
11. 前記動的フィーチャーモデルは、前記システムの実行時に変化する値を定義する実行中フィーチャー（runtime feature）を含むことを特徴とする請求項８に記載のソフトウェア自律管理機能を備えたシステム。
12. 前記自律管理者は、前記システムの前記実行中フィーチャーに基づいて前記獲得したシステムのすべての構成のうち前記要請されたサービスに相当する構成を提供することを特徴とする請求項１１に記載のソフトウェア自律管理機能を備えたシステム。

Images