JP7023807B2 - 管理システム、情報処理装置、設定管理方法、およびプログラム - Google Patents

Description

本発明の実施形態は、システム設定を管理する管理システム、情報処理装置、設定管理方法、およびプログラムに関する。

構成定義に基づいてコンピュータ内のシステムを自動的にセットアップするための種々の構成管理ツールが利用されている。構成定義は、コンピュータのシステム設定の値とその設定方法とでそれぞれ規定される複数のタスクを記述する。構成管理ツールは、このような構成定義に基づいてそれら複数のタスクを順に処理させることにより、コンピュータをセットアップする。

社会インフラや放送局のような企業で利用されるオンラインシステム（例えば、ウェブシステム、クラウドシステム、等）には、多数のコンピュータ（例えば、サーバ）が設けられることが多い。このような多数のコンピュータに対して、管理者が一台ずつセットアップ作業を行うことは、非常に煩雑である。

管理者は、構成管理ツールを用いることにより、構成定義を作成するだけで、例えば、遠隔から各コンピュータのセットアップを自動的に行うことができる。したがって、セットアップ作業の負担を軽減することができる。

特開平６－２５０８８５号公報

複数のタスクが記述される構成定義は、管理者による理解や編集が容易になるようにリファクタリングされることがある。リファクタリングでは、例えば、関連性が高いものをまとめるようにタスクの順序が変更される。リファクタリングは、タスクの順序が変更される前の構成定義を用いた場合と、タスクの順序が変更された後の構成定義を用いた場合とで、コンピュータのセットアップ結果（すなわち、コンピュータのシステム構築結果）に違いがないように行われることが要求される。

しかし、構成定義が、多数のタスクが記述されたファイル（例えば、１０００行以上の記述を含むファイル）であるような場合、あるタスクの順序の変更がセットアップ結果に影響を与えるものであるかどうかを、管理者が判断することは容易ではない。そのため、セットアップ結果に影響を与えることなく構成定義をリファクタリングできる新たな機能の実現が必要とされる。

本発明が解決しようとする課題は、セットアップ結果に影響を与えることなく構成定義をリファクタリングできる管理システム、情報処理装置、設定管理方法、およびプログラムを提供することである。

実施形態によれば、管理システムは、ネットワークまたはケーブルを介して相互に接続される第１情報処理装置と第２情報処理装置とによって構成される。前記第１情報処理装置は、前記第２情報処理装置による要求に応じて、複数のタスクを第１の順序で処理するように構成される。前記第２情報処理装置は、前記第１情報処理装置に前記複数のタスクを前記第１の順序で処理させる間に、前記複数のタスクの各々の処理に応じて読み出されたデータと書き込まれたデータとを示す情報を取得し、前記情報を用いて、前記複数のタスクの内の第１タスクの処理に応じて書き込まれ、且つ前記第１タスクの処理よりも後の第２タスクの処理に応じて読み出された第１データを検出するように構成される。

第１実施形態に係る管理システムの構成を説明するための図。 第１実施形態の管理システムと管理対象のサーバを含むシステムとの構成の一例を示すブロック図。 第１実施形態の管理システムで用いられる構成定義のためのタスクのフォーマットの例を示す図。 図３のフォーマットに基づくコマンドおよびパラメータの例を示す図。 第１実施形態の管理システムにおいて構成定義がリファクタリングされる例を示す図。 第１実施形態の管理システムによって、リファクタリング前の構成定義が解析され、リファクタリング後の構成定義が検査される例を説明するための図。 第１実施形態の管理システムに設けられる設定用端末とサーバとの機能構成の例を示すブロック図。 第１実施形態の管理システムによって用いられるアクセスデータ表の例を示す図。 第１実施形態の管理システムによって用いられる依存関係表の例を示す図。 第１実施形態の管理システムによって表示される検査結果の例を示す図。 図７の設定用端末によって実行される解析処理の手順の例を示すフローチャート。 図７の設定用端末によって実行されるセットアップ制御処理の手順の例を示すフローチャート。 図７の設定用端末によって実行される検査処理の手順の例を示すフローチャート。 図７の設定用端末によって入力コマンドと検査結果とが表示される画面の例を示す図。 図７の設定用端末において、構成定義エディタを用いた構成定義の編集中に検査結果が表示される画面の例を示す図。 第２実施形態の管理システムに設けられる設定用端末とサーバとの機能構成の例を示すブロック図。 第２実施形態の管理システムで用いられる構成定義の例を示す図。 第２実施形態の管理システムで用いられるタスクの処理履歴の例を示す図。 図１８のタスクの処理履歴を記録するために用いられる、タスクの処理過程の出力の例を示す図。 第２実施形態の管理システムで用いられるアクセスファイル表の例を示す図。 第２実施形態の管理システムで用いられる依存関係表の例を示す図。 第２実施形態の管理システムで用いられるリファクタリング後の構成定義の例を示す図。 第２実施形態の管理システムによって表示される検査結果の例を示す図。 第３実施形態の管理システムに設けられる設定用端末とサーバとの機能構成の例を示すブロック図。 第４実施形態の管理システムに設けられる設定用端末とサーバとの機能構成の例を示すブロック図。 設定用端末のシステム構成例を示すブロック図。 サーバのシステム構成例を示すブロック図。

以下、実施の形態について図面を参照して説明する。

（第１実施形態）
まず、図１を参照して、第１実施形態に係る管理システムの構成を説明する。この管理システム１は、セットアップ対象の第１情報処理装置と、第１情報処理装置のセットアップを管理する第２情報処理装置とで構成される。

第１情報処理装置は、例えば、サーバコンピュータ２０（以下、サーバとも称する）として実現され得る。第２情報処理装置は、例えば、パーソナルコンピュータである設定用端末１０として実現され得る。設定用端末１０とサーバ２０とはネットワーク３０を介して相互に接続されている。なお、設定用端末１０とサーバ２０とはケーブルを介して接続されていてもよい。

サーバ２０は、設定用端末１０で作成または編集される構成定義１０１を用いてセットアップされる。構成定義１０１には、システム設定のために、サーバ２０で処理されるべき複数のタスクＴ１，Ｔ２が記述される。各タスクＴ１，Ｔ２は、例えば、コマンドとそのパラメータとで規定される。

設定用端末１０は構成管理ツールを備える。構成管理ツールは、構成定義１０１に記述されたタスクＴ１，Ｔ２を先頭から順に、別の情報処理装置（ここでは、サーバ２０）に処理させる機能を有するプログラムである。構成管理ツールとしては、様々なプログラムが提供されており、例えば、Ａｎｓｉｂｌｅ（登録商標）、Ｓａｌｔ、Ｐｕｐｐｅｔ（登録商標）、Ｃｈｅｆ等が利用され得る。

設定用端末１０が、構成定義１０１を用いて構成管理ツールを実行することにより、サーバ２０は、構成定義１０１に記述されたタスクＴ１，Ｔ２を先頭から順に処理（適用）する。これにより、サーバ２０のシステム設定を自動的にセットアップすることができる。

図１に示すように、サーバ２０のセットアップは、コマンド入力３０１のような手作業で行われることがある。コマンド入力３０１では、管理者が、セットアップのためのコマンドとそのパラメータとを、キーボード等を用いて順に入力する必要がある。

図２に示すように、セットアップ対象のサーバ２０は、多数のクライアント４０と多数のサーバ２０とから構成されるシステム２内に設けられ得る。このようなシステム２を管理する管理者が多数のサーバ２０をセットアップする場合、管理者による作業は非常に煩雑になり、長い時間を要することになる。

そのため、上述したように、設定用端末１０による構成管理ツールと構成定義とを用いたセットアップが利用されている。管理者は、サーバ２０内のハードウェア、オペレーティングシステム（ＯＳ）、ミドルウェア、およびアプリケーションの各レイヤを管理し得る。本実施形態の管理システム１による構成管理の対象は、サーバ２０内のＯＳ、ミドルウェア、およびアプリケーションのレイヤに属するソフトウェアである。なお、セットアップは、管理者に限らず、システム２を開発する開発者によって行われてもよい。

上述したように、構成定義には、システム設定のためにサーバ２０で処理されるべき複数のタスクが記述される。構成定義は、複数のタスクとその処理順序とを示す。各タスクは、構成定義において、例えば、コマンドと、コマンドを適用する対象のオブジェクトと、当該オブジェクトが設定されるべき状態とを定義するための要素である。

コマンドは、サーバ２０によって実行可能なコマンドである。例えば、コマンドは、サーバ２０によって実行されるＯＳ、ミドルウェア、またはアプリケーションプログラムに設けられるコマンドである。

オブジェクトは、サーバ２０によって用いられるデータであり、例えば、ファイル、メモリまたはデータベース内のレコード、各種のパラメータ等である。パラメータは、例えば、サーバ２０を使用するユーザに関するパラメータや、サーバ２０で使用されるソフトウェアやハードウェア（デバイス）に関するパラメータ、サーバ２０が接続されるネットワークに関するパラメータ、等を含む。

図３に示すように、構成定義において、各タスクは、例えば、ＩＤ、コマンド、および１つ以上のパラメータを用いて定義（記述）される。あるタスクにおいて、「ＩＤ」は、そのタスクを識別するための情報（名称）を示す。「コマンド」は、対応するタスクが処理されるときに、構成管理ツールを用いてサーバ２０で実行されるべきコマンドを示す。「パラメータ」は、コマンドの実行のために指定される値であり、例えば、コマンドを適用する対象のオブジェクト、当該オブジェクトが設定されるべき状態等を示す。

「コマンド」および「パラメータ」に設定される値は、構成管理ツールの仕様に基づくものであり、使用される構成管理ツールに応じて変わり得る。

図４を参照して、タスクを定義するコマンドおよびパラメータの例を説明する。ここでは、構成管理ツールとしてＡｎｓｉｂｌｅが用いられることを想定する。

パラメータ“ｓｔａｔｅ： ａｂｓｅｎｔ， ｐａｔｈ： “／ａ””を指定するコマンド“ｆｉｌｅ”は、“ｐａｔｈ”で指定されるファイル“ａ”を、“ｓｔａｔｅ”で指定される“ａｂｓｅｎｔ”の状態にすること、すなわち、ファイル“ａ”が存在すれば削除することを示す。

パラメータ“ｓｔａｔｅ： ｓｙｍｌｉｎｋ， ｐａｔｈ： “／ｌｉｎｋｂ”， ｓｒｃ： “／ｂ””を指定するコマンド“ｆｉｌｅ”は、“ｐａｔｈ”で指定される“／ｌｉｎｋｂ”を、“ｓｒｃ”で指定される“／ｂ”と、“ｓｔａｔｅ”で指定される“ｓｙｍｌｉｎｋ”の状態にすること、すなわち、“／ｌｉｎｋｂ”を“／ｂ”のシンボリックリンクに設定することを示す。

パラメータ“ｓｔａｔｅ： ｐｒｅｓｅｎｔ， ｎａｍｅ： “ｕｓｅｒｃ””を指定するコマンド“ｕｓｅｒ”は、“ｎａｍｅ”で指定されるユーザ名“ｕｓｅｒｃ”を、“ｓｔａｔｅ”で指定される“ｐｒｅｓｅｎｔ”の状態にすること、すなわち、ユーザ“ｕｓｅｒｃ”がなければ作成することを示す。

また、パラメータ“ｓｔａｔｅ： ｐｒｅｓｅｎｔ， ｎａｍｅ： “ｐａｃｋ＿ｄ－１．０．０””を指定するコマンド“ｙｕｍ”は、“ｎａｍｅ”で指定されるソフトウェア“ｐａｃｋ＿ｄ－１．０．０”を、“ｓｔａｔｅ”で指定される“ｐｒｅｓｅｎｔ”の状態にすること、すなわち、ソフトウェア“ｐａｃｋ＿ｄ－１．０．０”がインストールされていなければインストールすることを示す。

このようなコマンドおよびパラメータの記述を用いることにより、構成定義において種々のタスクを定義することができる。

ところで、構成定義は、管理者による理解や編集が容易になるようにリファクタリングされることがある。リファクタリングでは、例えば、関連性が高いものをまとめるようにタスクの順序が変更される。以下では、構成定義のリファクタリングが、構成定義内のタスクの順序を変更することを表すものとする。

図５は、構成定義がリファクタリングされる例を示す。リファクタリング前の構成定義１０１には、先頭から順に、ユーザの作成・設定のためのタスクＴ１とソフトウェアＳａｍｂａのインストールのためのタスクＴ２とが記述されている。

管理者が、例えば、これらタスクＴ１，Ｔ２の順序を変更する操作を行うことにより、リファクタリング後の構成定義１０４が作成される。

このようなリファクタリングは、リファクタリング前の構成定義１０１を用いた場合と、リファクタリング後の構成定義１０４を用いた場合とで、サーバ２０のセットアップ結果に違いがないように行われることが要求される。しかし、構成定義１０１，１０４が、多数のタスクが記述されたファイル（例えば、１０００行以上の記述を含むファイル）であるような場合、あるタスクの順序の変更がサーバ２０のセットアップ結果に影響を与えるものであるかどうかを、管理者が判断することは困難である。

構成管理ツールの一つであるＡｎｓｉｂｌｅでは、ある構成定義を用いてセットアップが実行されたと仮定した場合に、セットアップ対象のコンピュータ（例えば、サーバ２０）内のファイル等に変更が加えられるかどうかを事前に調べる機能がある。この機能を用いることにより、リファクタリング前の構成定義１０１を用いてセットアップしたコンピュータに対して、リファクタリング後の構成定義１０４を用いたセットアップをさらに行うと仮定した場合に、ファイル等に何らかの変更が加えられるかどうかに基づき、リファクタリング前後の構成定義１０１，１０４が等価であるかどうかを判断できることがある。つまり、リファクタリング後の構成定義１０４を用いたセットアップをさらに行うと仮定した場合に、ファイル等に変更が加えられないならばリファクタリング前後の構成定義１０１，１０４が等価であり、一方、ファイル等に変更が加えられるならばリファクタリング前後の構成定義１０１，１０４が等価でないと判断できることがある。

より具体的には、まず、Ａｎｓｉｂｌｅは、リファクタリング前の構成定義１０１を用いてコンピュータをセットアップする。Ａｎｓｉｂｌｅは、管理者による編集作業等により、この構成定義に変更を加えた（例えば、タスクの順序を入れ替えた）リファクタリング後の構成定義１０４を、事前チェックモードで実行する。そして、Ａｎｓｉｂｌｅは、リファクタリング前の構成定義１０１を用いてセットアップしたコンピュータに対して、事前チェックモードで実行されたリファクタリング後の構成定義１０４によってファイル等の変更が加えられるかどうかを通知する。この事前チェックモードでの実行では、コンピュータに対する実際の変更は行われない。

変更が加えられると通知された場合、この通知がコンピュータのセットアップ結果が変わることを意味し、リファクタリング前後の構成定義１０１，１０４が等価でないと解釈され得る。一方、変更が加えられないと通知された場合、この通知はコンピュータのセットアップ結果が変わらないことを意味し、リファクタリング前後の構成定義１０１，１０４が等価であると解釈され得る。

しかし、この方法によるリファクタリング前後の構成定義１０１，１０４が等価であるか否かの判定は、以下のように、妥当でない場合がある。

例えば、リファクタリング前の構成定義１０１を用いてセットアップされたコンピュータに対して、リファクタリング後の構成定義１０４を事前チェックモードで実行した場合に、実際には変更の影響により必要なファイルが作成されていないにも関わらず、リファクタリング前の構成定義１０１を用いたセットアップ時やそれ以前にそのファイルが既に作成されていたならば、リファクタリング前後の構成定義１０１，１０４を用いたセットアップ結果に違いがなく、等価であると判断される。

さらに、Ａｎｓｉｂｌｅのような一般的な構成管理ツールでは、特定の種類のコマンドが用いられるタスクが処理される場合に、そのタスクの処理に応じてコンピュータに変更が加えられたかどうかを検出することができない。この特定の種類のコマンドは、例えば、その実行により、ＯＳに組み込まれたプログラムモジュールが動作するコマンドである。つまり、一般的な構成管理ツールでは、直接的に監視できる第１のプログラムモジュールの動作によって、コンピュータに変更が加えられたかどうかを検出することはできる。しかしながら、例えば、その第１のプログラムモジュール内でＯＳのコマンドがさらに呼び出される場合に、このコマンドに関連付けられた第２のプログラムモジュールの動作によって、コンピュータに変更が加えられたかどうかを検出することはできない。

本実施形態では、リファクタリング前の構成定義１０１を用いてタスクの処理順序の制約を決定し、リファクタリング後の構成定義１０４がこの制約に違反していないかどうかを検査する。

より具体的には、図６に示すように、サーバ２０に、リファクタリング前の構成定義１０１に記述された複数のタスクを第１の順序で処理させる間に、各タスクの処理に応じて読み出されたデータと書き込まれたデータとを示す情報を含むアクセスデータ表１０２が取得される。取得されたアクセスデータ表１０２を用いて、例えば、複数のタスクの内の第１タスクの処理に応じて書き込まれ、且つ第１タスクの処理よりも後の第２タスクの処理に応じて読み出された第１データが検出される。この第１データが検出されたことに基づき、第１タスクの後に第２タスクが処理されなければならないことを示す制約が決定される。アクセスデータ表１０２を用いて、このような依存関係（制約）を有する全てのデータが検出されることにより、依存関係表１０３が生成される。

そして、リファクタリング後の構成定義１０４に記述された、第２の順序で処理される複数のタスクが、依存関係表１０３に示される制約（依存関係）を満たしているか否かが判定される。制約に違反している場合、この制約に違反していることを示す検査結果１０５が管理者に通知される。

この通知に従って、管理者は、リファクタリング後の構成定義１０４をさらに変更できるので、サーバ２０のセットアップ結果に影響を与えないように構成定義１０１をリファクタリングすることができる。したがって、管理者が構成定義１０１をリファクタリングしたことによって、誤ってセットアップ結果を変えてしまうこと、あるいはセットアップ時にエラーが発生することを未然に防ぐことができる。

図７を参照して、本実施形態の管理システム１に設けられる設定用端末１０とサーバ２０の機能構成について説明する。
設定用端末１０は、構成定義エディタ１１１、構成管理ツール１１２、アクセス記録生成部１１３、依存関係解析部１１４、および違反検査部１１５を備える。また、サーバ２０は、データ格納部２０１、タスク実行部２１１、およびデータアクセス監視部２１２を備える。

設定用端末１０の構成定義エディタ１１１は、構成定義を作成および編集するためのテキストエディタである。構成定義エディタ１１１は、例えば、ある構成定義の内容を画面に表示する。そして、構成定義エディタ１１１は、キーボードやポインティングデバイスを用いた管理者による操作に応じて、表示されている構成定義に対して、タスクの追加、タスクの内容（例えば、コマンド、パラメータ、等）の変更、タスクの順序の変更、等を反映し、変更された構成定義を生成する。

以下では、管理者が、構成定義エディタ１１１を用いて、サーバ２０をセットアップするための構成定義１０１を作成することを想定する。

構成管理ツール１１２は、作成された構成定義１０１を用いて、サーバ２０にタスクを処理させる。構成管理ツール１１２は、構成定義１０１に記述された複数のタスクの内の１つのタスクを、先頭から順に選択し、選択されたタスクの処理をサーバ２０に要求する。

サーバ２０のタスク実行部２１１は、この要求に応じてタスクを処理する。すなわち、タスク実行部２１１は、そのタスクを処理するためのプロセスを実行する。このタスク実行部２１１は、ＯＳ、ミドルウェア、およびアプリケーションプログラムの少なくともいずれかに組み込まれたものであってもよい。また、タスク実行部２１１は、構成管理ツール１１２と連携した処理を行うための機能を有していてもよい。

タスク実行部２１１は、タスクの処理（すなわち、タスクを処理するためのプロセスの実行）に応じて、データ格納部２０１に格納されたいずれかのデータＤ１，Ｄ２，……，Ｄｎを読み出し、またデータ格納部２０１にデータを書き込むことができる。なお、データ格納部２０１にデータを書き込むことは、データ格納部２０１内のデータＤ１，Ｄ２，……，Ｄｎを書き換えることを含む。

データ格納部２０１は、サーバ２０によってアクセス可能なデータを格納する記憶媒体である。データ格納部２０１は、例えば、サーバ２０内に設けられるか、あるいはネットワーク３０やケーブルを介して接続される、ストレージ（例えば、ＨＤＤ、ＳＳＤ等）やメモリ（例えば、ＤＲＡＭ、ＳＲＡＭ等）である。

データアクセス監視部２１２は、タスクの処理に応じたデータ格納部２０１へのアクセスを監視し、タスクの処理に応じてデータ格納部２０１から読み出されたデータと、タスクの処理に応じてデータ格納部２０１に書き込まれたデータとを検出する。データアクセス監視部２１２は、例えば、タスク毎に、読み出されたデータと書き込まれたデータとを示す情報（例えば、ファイル名）を設定用端末１０に送信する。

設定用端末１０のアクセス記録生成部１１３は、サーバ２０のデータアクセス監視部２１２によって送信された、タスク毎の読み出されたデータと書き込まれたデータとを示す情報を用いて、アクセスデータ表１０２を生成する。アクセス記録生成部１１３は、構成管理ツール１１２から、サーバ２０によって処理されるタスクの識別情報や処理順序をさらに取得して、アクセスデータ表１０２を生成してもよい。

図８は、アクセスデータ表１０２の例を示す。アクセスデータ表１０２は、サーバ２０によって処理された構成定義１０１に記述された複数のタスクに対応する複数のエントリを含む。各エントリは、例えば、順序、タスク、読み出されたデータ、および書き込まれたデータを含む。

あるタスクに対応するエントリにおいて、「順序」は、そのタスクが処理された順序を示す。「順序」に示される値は、例えば、構成定義１０１においてそのタスクが記述された順序に対応する。

「タスク」は、対応するタスクを識別するための情報を示す。「タスク」は、例えば、構成定義１０１において記述されたそのタスクのＩＤ（あるいは名称）を示す。

「読み出されたデータ」は、対応するタスクが処理されたことに応じて読み出されたデータを特定可能な情報を示す。読み出されたデータは、例えば、ファイル、ＸＭＬのような構造化されたファイルの少なくとも一部、メモリまたはデータベース内のレコードやその一部、等である。そのため、読み出されたデータを特定可能な情報には、例えば、ファイル名（ファイルパス）、構造化されたファイル内の読み出された要素を特定する情報、メモリまたはデータベース内のレコードを特定する情報、等が含まれ得る。

なお、タスクの処理に応じて読み出されたデータがなければ、「読み出されたデータ」には値が設定されない。また、タスクの処理に応じて複数のデータが読み出されたならば、「読み出されたデータ」には、それら複数のデータをそれぞれ特定可能な複数の情報が設定される。

「書き込まれたデータ」は、対応するタスクが処理されたことに応じて書き込まれたデータを特定可能な情報を示す。書き込まれたデータは、例えば、ファイル、ＸＭＬのような構造化されたファイルの少なくとも一部、メモリまたはデータベース内のレコード、等である。そのため、書き込まれたデータを特定可能な情報には、例えば、ファイル名（ファイルパス）、構造化されたファイル内の書き込まれた（あるいは、書き換えられた）要素を特定する情報、メモリまたはデータベース内のレコードを特定する情報、等が含まれ得る。

なお、タスクの処理に応じて書き込まれたデータがなければ、「書き込まれたデータ」には値が設定されない。また、タスクの処理に応じて複数のデータが書き込まれたならば、「書き込まれたデータ」には、それら複数のデータをそれぞれ特定可能な複数の情報が設定される。

図８に示す例では、アクセスデータ表１０２に４つのエントリが含まれ、以下の内容を示している。
（１）１番目のタスクＴ１の処理に応じて、データＤ１およびデータＤ２が読み出され、データＤ３およびデータＤ４が書き込まれた。
（２）２番目のタスクＴ２の処理に応じて、データＤ３が読み出され、データＤ３が書き込まれた。
（３）３番目のタスクＴ３の処理に応じて、データＤ５が書き込まれた。
（４）４番目のタスクＴ４の処理に応じて、データＤ３、データＤ４、およびデータＤ５が読み出され、データＤ６、データＤ７、およびデータＤ８が書き込まれた。

依存関係解析部１１４は、アクセスデータ表１０２を用いてタスク間の依存関係を検出する。依存関係解析部１１４は、アクセスデータ表１０２を用いて、第１タスクの処理に応じて書き込まれ、且つ第１タスクの処理よりも後の第２タスクの処理に応じて読み出されたデータを検出する。このようなデータが検出された場合、第２タスクは、第１タスクによって書き込まれたデータを読み出しているので、第２タスクは第１タスクに依存していると云える。

図８に示したアクセスデータ表１０２が用いられる場合、依存関係解析部１１４は以下の検出結果（１）－（５）を取得する。
検出結果（１） タスクＴ１によって書き込まれた後に、タスクＴ２によって読み出されたデータＤ３
検出結果（２） タスクＴ１によって書き込まれた後に、タスクＴ４によって読み出されたデータＤ３
検出結果（３） タスクＴ１によって書き込まれた後に、タスクＴ４によって読み出されたデータＤ４
検出結果（４） タスクＴ２によって書き込まれた後に、タスクＴ４によって読み出されたデータＤ３
検出結果（５） タスクＴ３によって書き込まれた後に、タスクＴ４によって読み出されたデータＤ５

依存関係解析部１１４は、決定された検出結果（１）－（５）に基づいて依存関係表１０３を作成する。

図９は、依存関係表１０３の例を示す。サーバ２０によって処理された構成定義１０１に記述された複数のタスクに対応する複数のエントリを含む。各エントリは、例えば、タスクと依存するタスクリストとを含む。あるタスクに対応するエントリにおいて、「タスク」は、そのタスクを識別するための情報を示す。

また、「依存するタスクリスト」は、そのタスクが依存するタスク、すなわち、そのタスクよりも前に処理されなければならないタスクのリストを示す。あるタスクが別のタスクに依存している場合、そのタスクよりも前に、依存する別のタスクが処理されなければならない。したがって、あるタスクよりも前に、対応する「依存するタスクリスト」に示される全てのタスクが処理されなければならない。つまり、「依存するタスクリスト」は、タスクの処理順序に関する制約を示していると云える。

図９に示すように、上述した検出結果（１）－（５）に基づいて作成された依存関係表１０３では、タスクＴ１，Ｔ３には依存するタスクがなく、タスクＴ２がタスクＴ１に依存し、タスクＴ４がタスクＴ１，Ｔ２，Ｔ３に依存することが示されている。

なお、データアクセス監視部２１２、アクセス記録生成部１１３、および依存関係解析部１１４は、依存関係分析モジュール１Ａを構成する。この依存関係分析モジュール１Ａでは、サーバ２０と設定用端末１０とが連携して、構成定義１０１に基づくタスクの依存関係を解析する。

違反検査部１１５は、違反検出部１１５Ａと違反通知部１１５Ｂとを備える。違反検出部１１５Ａは、依存関係表１０３を用いて、以下の制約（１）－（４）を決定することができる。
制約（１） タスクＴ２がタスクＴ１に依存するので、タスクＴ１の後にタスクＴ２が処理されなければならない。
制約（２） タスクＴ４がタスクＴ１に依存するので、タスクＴ１の後にタスクＴ４が処理されなければならない。
制約（３） タスクＴ４がタスクＴ２に依存するので、タスクＴ２の後にタスクＴ４が処理されなければならない。
制約（４） タスクＴ４がタスクＴ３に依存するので、タスクＴ３の後にタスクＴ４が処理されなければならない。

違反検出部１１５Ａは、決定された制約に基づき、リファクタリング後の構成定義１０４を検査する。リファクタリング後の構成定義１０４は、例えば、管理者が構成定義エディタ１１１を用いて、リファクタリング前の構成定義１０１に記述されたタスクの順序を変更したものである。違反検出部１１５Ａは、リファクタリング後の構成定義１０４におけるタスクの処理順序を検出する。そして、違反検出部１１５Ａは、検出されたタスクの処理順序が、制約に示されるタスクの処理順序を満たしているか、それとも制約に示されるタスクの処理順序に違反しているかを決定する。

違反通知部１１５Ｂは、リファクタリング後の構成定義１０４に記述されたタスクが、いずれの制約にも違反していない場合、制約に違反していないことを示す検査結果１０５を通知する。また、違反通知部１１５Ｂは、リファクタリング後の構成定義１０４に記述されたタスクが、ある制約に違反している場合、当該制約に違反していること示す検査結果１０５を通知する。この通知において、違反通知部１１５Ｂは、例えば、どのタスク間で、どのデータに関して、違反が発生しているかを示す情報を、画面等に出力する。

図１０は、違反通知部１１５Ｂによって通知される検査結果１０５の例を示す。違反通知部１１５Ｂは、検査結果１０５を、例えば、設定用端末１０の画面に表示する。

図１０（Ａ）は、制約に違反するタスクがなかった場合に通知される検査結果１０５－１を示す。この検査結果１０５－１では、例えば、「タスクの順序に問題は見つかりませんでした」というメッセージが画面に表示される。管理者は、この検査結果１０５－１により、リファクタリング後の構成定義１０４（すなわち、タスクの順序が変更された構成定義）が、サーバ２０のセットアップ結果に影響を与えないことを認識できる。

これに対して、図１０（Ｂ）は、制約に違反するタスクがあった場合に通知される検査結果１０５－２を示す。この検査結果１０５－２では、例えば、「タスクの順序に問題が見つかりました」というメッセージが画面に表示され、さらに、いずれのタスク間の順序に問題があったかを説明するメッセージが表示される。例えば、「タスクＴ２はタスクＴ１にデータＤ３について依存しますが、Ｔ１はＴ２よりも前に処理されません」といったメッセージのように、制約に違反した順序関係を有する二つのタスクと、その違反によりセットアップ結果に影響を与えるデータとが特定可能な情報が示される。

これにより、管理者は、順序関係に問題のある二つのタスクを認識できると共に、いずれのデータについてその問題が発生しているのかを認識することができる。したがって、管理者は、リファクタリング後の構成定義１０４を、タスクの順序関係に問題が発生しないように（すなわち、制約に違反しないように）適切に変更することができる。

以上の構成により、サーバ２０のセットアップ結果に影響を与えることなく構成定義をリファクタリングすることができる。リファクタリング前の構成定義１０１を用いたセットアップにおいて、各タスクの処理に応じて読み出されたデータと書き込まれたデータとを示す情報が取得され、この情報に基づいてタスク間の処理順序の制約が決定される。

本実施形態では、リファクタリング前の構成定義１０１を用いたセットアップ結果とリファクタリング後の構成定義１０４を用いたセットアップ結果とを比較するのではなく、タスク間の処理順序の制約を用いて、リファクタリング後の構成定義１０４に、処理順序の制約に違反しているタスクがあるかどうかが判定される。これにより、リファクタリング後の構成定義１０４を用いたセットアップが実行される前のサーバ２０の状態（例えば、ファイルの有無）に関わらず、セットアップ結果に影響を与える違反を見つけることができる。また、各タスクの処理に応じて読み出されたデータと書き込まれたデータとを示す情報を利用するので、タスク内で用いられるコマンドの種類に依らず、例えば、ＯＳに組み込まれたプログラムモジュールを動作させるコマンドが用いられる場合にも、セットアップ結果に影響を与える違反を漏れなく見つけることができる。

したがって、管理者が構成定義をリファクタリングしたことによって、誤ってセットアップ結果を変えてしまうこと、あるいはセットアップ時にエラーが発生することを未然に防ぐことができる。

次いで、図１１から図１３を参照して、リファクタリングされた構成定義を用いてサーバ２０をセットアップするための処理の手順について説明する。

まず、図１１のフローチャートは、設定用端末１０によって実行される解析処理の手順の例を示す。ここでは、この解析処理において、構成定義１０１を用いたサーバ２０のセットアップが解析される場合について例示する。

まず、設定用端末１０は、第１の順序に従って、構成定義１０１に記述された複数のタスクの内の１つのタスクをサーバ２０に処理させる（ステップＳ１１）。第１の順序は、例えば、構成定義１０１において複数のタスクが記述された順序に対応する。設定用端末１０は、例えば、構成管理ツール１１２を用いて、そのタスクを処理することをサーバ２０に要求する。サーバ２０は、設定用端末１０による要求に応じてタスクを処理する。

設定用端末１０は、タスクの処理に応じてアクセスされたデータを記録する（ステップＳ１２）。サーバ２０では、タスクの処理中に、そのタスクの処理に応じて読み出されたデータと書き込まれたデータとが検出される。設定用端末１０は、検出された、読み出されたデータと書き込まれたデータとを示す情報がタスク毎に記録されたアクセスデータ表１０２を生成する。

そして、設定用端末１０は、構成定義１０１に記述されたすべてのタスクが処理されたか否かを判定する（ステップＳ１３）。すべてのタスクが処理されていない場合（ステップＳ１３のＮＯ）、ステップＳ１１に戻り、第１の順序に従って、後続するタスクが処理される。

すべてのタスクが処理された場合（ステップＳ１３のＹＥＳ）、設定用端末１０は、それらタスクから、処理された順序（すなわち、第１の順序）に従って、１つのタスクＴを選択する（ステップＳ１４）。なお、処理された順序が１番目であるタスクが他のタスクに依存していないことは自明であるため、１番目のタスクはスキップして、２番目のタスクから選択されるようにしてもよい。そして、設定用端末１０は、タスクＴよりも前に処理された１つのタスクＳを選択する（ステップＳ１５）。

設定用端末１０は、アクセスデータ表１０２を用いて、選択されたタスクＴを処理するためのプロセスが、このタスクＴのプロセスよりも前に実行された、タスクＳを処理するためのプロセスが書き込んだデータを読み出したか否かを判定する（ステップＳ１６）。つまり、設定用端末１０は、タスクＳの処理に応じて書き込まれ、且つタスクＳよりも後のタスクＴの処理に応じて読み出されたデータがあるか否かを判定する。

選択されたタスクＴを処理するためのプロセスが、このタスクＴのプロセスよりも前に実行された、タスクＳを処理するためのプロセスが書き込んだデータを読み出していた場合（ステップＳ１６のＹＥＳ）、設定用端末１０は、依存関係表１０３において、タスクＴが依存するタスクリストにタスクＳを追加する（ステップＳ１７）。タスクＴが依存するタスクリストには、複数のタスクが追加されてもよい。

一方、選択されたタスクＴを処理するためのプロセスが、このタスクＴのプロセスよりも前に実行された、タスクＳを処理するためのプロセスが書き込んだデータを読み出していない場合には（ステップＳ１６のＮＯ）、ステップＳ１７がスキップされる。

次いで、設定用端末１０は、タスクＴよりも前に処理された別のタスクＳがあるか否かを判定する（ステップＳ１８）。別のタスクＳがある場合（ステップＳ１８のＹＥＳ）、ステップＳ１５に戻り、別のタスクＳとタスクＴとの依存関係を解析するための処理が実行される。

別のタスクＳがない場合（ステップＳ１８のＮＯ）、すなわち、タスクＴよりも前に処理されたすべてのタスクＳについて、タスクＴとの依存関係が解析済みである場合、設定用端末１０は、構成定義１０１に基づいて処理された複数のタスクに、依存関係を解析すべき別のタスクＴがあるか否かを判定する（ステップＳ１９）。別のタスクＴがある場合（ステップＳ１９のＹＥＳ）、ステップＳ１４に戻り、別のタスクＴの依存関係を解析するための処理が実行される。

別のタスクＴがない場合（ステップＳ１９のＮＯ）、処理を終了する。

以上により、構成定義１０１に基づくタスクの処理に応じて読み出されたデータと書き込まれたデータとが検出され、タスクの依存関係が解析されることにより、依存関係表１０３を取得することができる。

図１２のフローチャートは、設定用端末１０によって実行されるセットアップ制御処理の手順の例を示す。ここでは、設定用端末１０が、構成定義１０１をリファクタリングした構成定義１０４を用いて、サーバ２０をセットアップしようとする場合について例示する。なお、このセットアップ制御処理が開始される前に、構成定義１０１を用いた、上述した解析処理が実行済みであるものとする。

まず、設定用端末１０は、構成定義エディタ１１１を用いて、構成定義１０１が変更されたか否かを判定する（ステップＳ２１）。構成定義１０１が変更されていない場合（ステップＳ２１のＮＯ）、ステップＳ２１に戻り、構成定義１０１が変更されたか否かが再度判定される。

構成定義１０１が変更された場合（ステップＳ２１のＹＥＳ）、設定用端末１０は、リファクタリング後の構成定義１０４が、リファクタリング前の構成定義１０１に基づく制約に違反していないかどうかを検査するための検査処理を実行する（ステップＳ２２）。検査処理では、構成定義１０４が制約に違反しているかどうかを示す通知が出力（例えば、画面に表示）される。検査処理については、図１３のフローチャートを参照して後述する。

設定用端末１０は、検査処理の結果に基づいて、リファクタリング後の構成定義１０４が制約に違反しているか否かを判定する（ステップＳ２３）。リファクタリング後の構成定義１０４が制約に違反していない場合（ステップＳ２３のＮＯ）、設定用端末１０は、リファクタリング後の構成定義１０４をサーバ２０に適用するか否かを判定する（ステップＳ２４）。設定用端末１０は、例えば、管理者による入力（操作）に応じて、リファクタリング後の構成定義１０４をサーバ２０に適用するか否かを判定する。管理者は、例えば、リファクタリング後の構成定義１０４の編集を終了して、サーバ２０に適用する場合に、適用を指示するための操作を行ってもよい。また、管理者は、例えば、リファクタリング後の構成定義１０４の編集を続行する場合に、リファクタリング後の構成定義１０４をサーバ２０に適用せず、構成定義エディタ１１１を用いた編集作業の再開を指示するための操作を行ってもよい。

リファクタリング後の構成定義１０４をサーバ２０に適用する場合（ステップＳ２４のＹＥＳ）、設定用端末１０は、リファクタリング後の構成定義１０４に記述された複数のタスクを第２の順序でサーバ２０に処理させる（ステップＳ２５）。第２の順序は、例えば、リファクタリング後の構成定義１０４において複数のタスクが記述された順序に対応する。設定用端末１０は、例えば、構成管理ツール１１２を用いて、タスクの処理をサーバ２０に要求する。サーバ２０は、設定用端末１０による要求に応じてタスクを処理する。これにより、サーバ２０がセットアップされる。

一方、リファクタリング後の構成定義１０４をサーバ２０に適用しない場合（ステップＳ２４のＮＯ）、ステップＳ２１に戻り、サーバ２０のセットアップ結果に影響を与えることなく構成定義をリファクタリングするための処理が続行される。

また、リファクタリング後の構成定義１０４が制約に違反している場合（ステップＳ２３のＹＥＳ）、設定用端末１０は、違反している構成定義を修正するか否かを判定する（ステップＳ２６）。設定用端末１０は、例えば、管理者による入力に応じて、違反している構成定義を修正するか否かを判定する。管理者は、例えば、検査処理によって検出された違反が、サーバ２０のセットアップ結果に影響を与えるものであると認識した場合に、違反したタスクの記述を修正することを示す操作を行ってもよい。また、管理者は、例えば、検査処理によって検出された違反が誤りであると認識した場合に、違反したタスクの記述を修正しないことを示す操作を行ってもよい。

違反している構成定義を修正する場合（ステップＳ２６のＹＥＳ）、ステップＳ２１に戻り、構成定義エディタ１１１を用いた編集作業が再開される。

一方、違反している構成定義を修正しない場合（ステップＳ２６のＮＯ）、設定用端末１０は、リファクタリング後の構成定義１０４について解析処理を実行し（ステップＳ２７）、ステップＳ２１に戻る。解析処理については、図１１のフローチャートを参照して上述した通りである。この解析処理により、リファクタリング後の構成定義１０４に記述された複数のタスクがサーバ２０によって処理され、アクセスデータ表１０２と依存関係表１０３とが更新される。そして、更新された依存関係表１０３を用いた検査処理が実行されることになる。なお、ステップＳ２７の解析処理が実行された後、構成定義１０４の編集を続行するためのステップＳ２１ではなく、検査処理を実行するためのステップＳ２２に進んでもよい。

図１３のフローチャートを参照して、設定用端末１０によって実行される検査処理の手順の例を説明する。検査処理では、リファクタリング後の構成定義１０４が、リファクタリング前の構成定義１０１に基づくタスクの依存関係の制約に違反するものでないかが検査される。

まず、設定用端末１０は、違反フラグを初期化（クリア）する（ステップＳ３０１）。違反フラグは、リファクタリング後の構成定義１０４がタスクの依存関係の制約に違反しているか否かを示す。違反フラグがクリアされた状態は、違反が見つかっていないことを表す。一方、違反フラグが立っている状態は、違反が見つかったことを表す。

次に、設定用端末１０は、リファクタリング後の構成定義１０４に記述された複数のタスクの処理順序を検出する（ステップＳ３０２）。検出されるタスクの処理順序は、例えば、構成定義１０４において、複数のタスクが記述された順序に対応する。

設定用端末１０は、リファクタリング後の構成定義１０４に含まれる複数のタスクから、１つのタスクＴを選択する（ステップＳ３０３）。設定用端末１０は、リファクタリング前の構成定義１０１についての解析処理で得られた依存関係表１０３を用いて、タスクＴが依存するタスクリストから１つのタスクＳを選択する（ステップＳ３０４）。そして、設定用端末１０は、ステップＳ３０２で検出されたタスクの処理順序において、タスクＳがタスクＴよりも前に存在するか否かを判定する（ステップＳ３０５）。

タスクＳがタスクＴよりも前に存在しない場合（ステップＳ３０５のＮＯ）、すなわち、タスクＳがタスクＴよりも後に存在する場合、設定用端末１０は、違反フラグを立て（ステップＳ３０６）、タスクＳとタスクＴとの依存関係の制約に対する違反があることを出力する（ステップＳ３０７）。設定用端末１０は、例えば、タスクＳとタスクＴとの依存関係の制約に対する違反があることを示す通知を画面に表示する。

一方、タスクＳがタスクＴよりも前に存在する場合（ステップＳ３０５のＹＥＳ）、ステップＳ３０６およびステップＳ３０７がスキップされる。

次いで、タスクＴが依存するタスクリストに別のタスクＳがあるか否かを判定する（ステップＳ３０８）。別のタスクＳがある場合（ステップＳ３０８のＹＥＳ）、ステップＳ３０４に戻り、タスクＴと別のタスクＳとの依存関係が検査される。つまり、ステップＳ３０４からステップＳ３０８の手順では、タスクＴが依存する全てのタスクＳについて、各タスクＳがタスクＴよりも前に処理されるかどうかが検査される。

別のタスクＳがない場合（ステップＳ３０８のＮＯ）、すなわち、タスクＴと、タスクＴが依存するタスクリストに含まれるすべてのタスクＳとの間の依存関係が検査された場合、設定用端末１０は、リファクタリング後の構成定義１０４に別のタスクＴがあるか否かを判定する（ステップＳ３０９）。別のタスクＴがある場合（ステップＳ３０９のＹＥＳ）、ステップＳ３０３に戻り、別のタスクＴに関する依存関係が検査される。

別のタスクＴがない場合（ステップＳ３０９のＮＯ）、すなわち、リファクタリング後の構成定義１０４に含まれるすべてのタスクＴに関する依存関係が検査された場合、設定用端末１０は、違反フラグが立っているか否かを判定する（ステップＳ３１０）。違反フラグが立っている場合（ステップＳ３１０のＹＥＳ）、処理を終了する。

一方、違反フラグがクリアされた状態である場合（ステップＳ３１０のＮＯ）、設定用端末１０は、リファクタリング後の構成定義１０４に含まれるタスクの処理順序に問題がなかったことを出力し（ステップＳ３１１）、処理を終了する。設定用端末１０は、例えば、タスクの処理順序に問題がなかったことを示す通知を画面に表示する。

以上により、リファクタリング後の構成定義１０４が、リファクタリング前の構成定義１０１と等価であるかどうかが検証され、これら構成定義１０１，１０４が等価である場合に、リファクタリング後の構成定義１０４を用いてサーバ２０をセットアップすることができる。

図１４は、設定用端末１０によって表示されるコマンド入力画面５１の例を示す。コマンド入力画面５１では、設定用端末１０に実行させる任意のコマンドを、キーボード等を用いて入力することができる。

図１４に示す例では、管理者は、リファクタリング後の構成定義１０４のファイル“ｘｘｘ．ｙｍｌ”が、タスクの依存関係に関する制約に違反していないかどうかを検査するためのコマンド“ｃｈｅｃｋ ｘｘｘ．ｙｍｌ”５１１を入力している。

入力されたコマンド５１１に応じて、構成定義１０４のファイル“ｘｘｘ．ｙｍｌ”が検査された結果、タスクＴ２とタスクＴ１とが制約に違反していることを示す通知５１２が画面５１に表示される。さらに、この違反を解消するために推奨される変更を示す通知５１３も画面５１に表示されている。管理者は、このような通知５１２，５１３に基づき、構成定義１０４のファイル“ｘｘｘ．ｙｍｌ”を適切に修正することができる。

なお、コマンド入力画面ではなく、構成定義を編集するための構成定義エディタ１１１の画面上で、構成定義の検査結果が出力されるようにしてもよい。

図１５は、設定用端末１０において、構成定義エディタ１１１を用いた構成定義の編集中に検査結果が表示されるエディタ画面５５の例を示す。

図１５（Ａ）に示すように、エディタ画面５５は、編集領域５５１と通知領域５５２とを含む。編集領域５５１には、編集中の構成定義の内容が表示される。管理者は、キーボードやポインティングデバイス等を用いた操作により、タスクの追加やタスクの順序の変更等を行い、表示されている構成定義の内容を変更することができる。

通知領域５５２には、編集中の構成定義の検査結果が表示される。図１５（Ａ）に示す例では、タスクＴ１とタスクＴ２とが依存関係の制約に違反していることが通知されている。例えば、タスクＴ１，Ｔ２が処理される順序を変更することを示す、管理者による操作（入力）を受け付けたとき、変更された順序で処理されるタスクＴ１，Ｔ２が、ある依存関係の制約に違反しているならば、当該制約に違反していることが通知領域５５２に表示される。

通知領域５５２には、例えば、編集領域５５１に表示されている構成定義の内容を変更する操作を受け付けたとき、その変更された内容に対する検査結果が表示される。また、管理者によって検査結果を要求する操作が行われたことに応じて、あるいは一定時間毎に、編集領域５５１に表示されている構成定義の内容に対する検査結果が、通知領域５５２に表示されるようにしてもよい。

また、編集領域５５１では、検査結果に応じて、違反に該当するタスクが他のタスクとは識別できるように表示されてもよい。例えば、タスクＴ１とタスクＴ２とが依存関係の制約に違反している場合、それらタスクＴ１，Ｔ２の記載箇所５５３，５５４に対して、線を引く、色を変更する、太字にする等のような、識別可能な装飾が施される。

さらに、制約に違反しているタスクＴ１の記載箇所５５３に関連付けて、例えば、タスクＴ１の記載箇所５５３の近傍に、ボタン５５５が表示されてもよい。

図１５（Ｂ）に示すように、このボタン５５５を押し下げる操作が行われたことに応じて、違反を解消するために推奨される構成定義の変更を示す通知５５６が表示される。この通知５５６には、例えば、タスクＴ２をタスクＴ１の後に移動することを示す項目５５７と、解析処理を再実行することを示す項目５５８とが含まれている。

これら項目５５７，５５８のいずれかを選択する操作に応じて、選択された項目に対応する処理が実行されてもよい。例えば、項目５５７が選択された場合、編集領域５５１において、タスクＴ２に対応する記述がタスクＴ１に対応する記述の後に移動される。また、項目５５８が選択された場合、例えば、編集領域５５１に表示されている構成定義についての解析処理が実行される。この項目５５８は、例えば、管理者が、制約に違反しているという通知が適切でないと判断した場合に選択される。

このようなグラフィカルユーザインタフェースが用いられることにより、構成定義をリファクタリングするための管理者による作業をより効率化することができる。

（第２実施形態）
第２実施形態では、第１実施形態の構成のより具体的な実装例を示す。第２実施形態に係る管理システム１の構成は第１実施形態の管理システム１と同様であり、第２実施形態と第１実施形態とでは、構成管理ツール１１２、アクセス記録生成部１１３、および依存関係解析部１１４によって実行される処理の手順のみが異なる。以下、第１実施形態と異なる点を主に説明する。

また、ここでは、構成管理ツール１１２としてＡｎｓｉｂｌｅが用いられ、データアクセス監視部２１２を実装するためにｆａｎｏｔｉｆｙ ＡＰＩが用いられ、またタスクの処理中に監視されるデータがファイルであることを想定する。ｆａｎｏｔｉｆｙは、Ｌｉｎｕｘ（登録商標）のカーネルに設けられているファイルシステムの状態変化を通知する機構である。

図１６は、管理システム１に設けられる設定用端末１０とサーバ２０との機能構成を示す。構成定義エディタ１１１は、管理者による操作に応じて構成定義１０１（リファクタリング前の構成定義）を生成する。

図１７は構成定義１０１の例を示す。この構成定義１０１には、４つのタスクＴ１，Ｔ２，Ｔ３，Ｔ４が記述されている。図３を参照して上述したように、記述された各タスクには、ＩＤ、コマンド、およびパラメータが含まれている。

Ａｎｓｉｂｌｅである構成管理ツール１１２は、構成定義１０１に記述されたタスクを、先頭から順にサーバ２０に処理させると共に、タスクの処理履歴１０２Ｂを生成する。

図１８は、構成管理ツール１１２によって生成されるタスクの処理履歴１０２Ｂを示す。タスクの処理履歴１０２Ｂは、構成管理ツール１１２を用いてサーバ２０に処理させたタスクＴ１～Ｔ４と、これらタスクＴ１～Ｔ４を処理するためにサーバ２０上で実行されたプロセスＰ１～Ｐ４との対応を示す複数のエントリを含む。これらエントリは、タスクＴ１～Ｔ４の処理順に並べられている。

図１９に示すように、構成管理ツール１１２は、あるタスクを処理するためのプロセスの実行過程１０６Ａにおいて、サーバ２０に投入されたコマンド１０６Ｂを取得し、このコマンド１０６Ｂに関連付けられたプロセスを記録する機能を有している。この機能を用いることにより、タスクの処理履歴１０２Ｂを作成することができる。なお、タスクの処理履歴１０２Ｂには、取得されたコマンド１０６Ｂがさらに記録されていてもよい。

このタスクの処理履歴１０２Ｂにより、タスクＴ１，Ｔ２，Ｔ３，Ｔ４がプロセスＰ１，Ｐ２，Ｐ３，Ｐ４とそれぞれ対応し、タスクＴ１，Ｔ２，Ｔ３，Ｔ４の順に処理されたこと（すなわち、プロセスＰ１，Ｐ２，Ｐ３，Ｐ４の順に実行されたこと）が分かる。

サーバ２０のタスク実行部２１１は、構成管理ツール１１２による要求に応じて、タスクを処理するためのプロセスを実行する。タスク実行部２１１は、タスクに対応するプロセスの実行に応じて、データ格納部２０１に格納されたいずれかのファイルＦ１，Ｆ２，……，Ｆｎを読み出し、またデータ格納部２０１にファイルを書き込むことができる。なお、データ格納部２０１にファイルを書き込むことは、データ格納部２０１内のファイルＦ１，Ｆ２，……，Ｆｎを書き換えることを含む。

データアクセス監視部２１２は、プロセスの実行に応じたデータ格納部２０１へのアクセスを監視し、プロセスの実行に応じてデータ格納部２０１から読み出されたファイルと、プロセスの実行に応じてデータ格納部２０１に書き込まれたファイルとを検出する。このような検出は、Ｌｉｎｕｘカーネルによって提供されるｆａｎｏｔｉｆｙ機能を用いて実現できる。データアクセス監視部２１２は、ｆａｎｏｔｉｆｙ機能を用いることにより、ファイルアクセス時に任意のフック処理を追加することができ、例えば、あるプロセスがあるファイルに対する読み出しや書き込みを行ったといったイベントの発生を検出することができる。データアクセス監視部２１２は、検出されたイベントに基づき、例えば、プロセス毎に、プロセスを識別するための情報と、読み出されたファイルおよび書き込まれたファイルを示す情報（例えば、ファイル名）とを設定用端末１０に送信する。

なお、プロセスを識別するための情報には、ファイルに実際にアクセスしたプロセスだけでなく、そのプロセスを呼び出した親のプロセスの情報も含まれ得る。あるいは、プロセスを識別するための情報に、ファイルに実際にアクセスしたプロセスではなく、そのプロセスを呼び出した親のプロセスの情報が含まれてもよい。また、プロセスを識別するための情報には、このプロセスを発生させるトリガとなったコマンドを示す情報が含まれていてもよい。

設定用端末１０のアクセス記録生成部１１３は、サーバ２０のデータアクセス監視部２１２によって送信された、プロセス毎の読み出されたファイルと書き込まれたファイルとを示す情報を用いて、アクセスファイル表１０２Ａを生成する。

図２０は、構成定義１０１に記述されたタスクＴ１～Ｔ４がそれぞれ、プロセスＰ１～Ｐ４のいずれかとして実行される場合に、各プロセスの実行に応じて読み出されたファイルと書き込まれたファイルとを示すアクセスファイル表１０２Ａを示す。

図８を参照して上述したアクセスデータ表１０２では、タスク毎に、そのタスクが処理されたことに応じて読み出されたデータと書き込まれたファイルとが示されている。これに対して、このアクセスファイル表１０２Ａでは、プロセス毎に、そのプロセスが実行されたことに応じて読み出されたファイルと書き込まれたファイルとが示されている。このアクセスファイル表１０２Ａのみでは、プロセスＰ１～Ｐ４のそれぞれが、タスクＴ１～Ｔ４のいずれに対応するのかは不明である。

依存関係解析部１１４は、アクセスファイル表１０２Ａとタスクの処理履歴１０２Ｂとを用いて、タスク間の依存関係を検出する。依存関係解析部１１４は、タスクの処理履歴１０２Ｂにより、処理順に並べられたタスクＴ１～Ｔ４それぞれとプロセスＰ１～Ｐ４それぞれとの対応が示されるので、プロセスＰ１～Ｐ４の実行順を取得できる。依存関係解析部１１４は、このプロセスＰ１～Ｐ４の実行順に基づき、アクセスファイル表１０２Ａを用いて、タスクＴ１～Ｔ４にそれぞれ対応するプロセスＰ１～Ｐ４間の依存関係を検出する。したがって、アクセスファイル表１０２Ａとタスクの処理履歴１０２Ｂとを用いることにより、図８を参照して上述したアクセスデータ表１０２と同等の情報が得られる。

図２０に示す例では、プロセスＰ１の実行（すなわち、タスクＴ１の処理）に応じて書き込まれたファイル“ｓｍｂ．ｃｏｎｆ”は、プロセスＰ１の実行よりも後のプロセスＰ２の実行（すなわち、タスクＴ２の処理）に応じて読み出されている。したがって、プロセスＰ２に対応するタスクＴ２は、プロセスＰ１に対応するタスクＴ１に依存する。

プロセスＰ１の実行（すなわち、タスクＴ１の処理）に応じて書き込まれたファイル“ｓｍｂ．ｃｏｎｆ”は、プロセスＰ１の実行よりも後のプロセスＰ４の実行（すなわち、タスクＴ４の処理）に応じて読み出されている。したがって、プロセスＰ４に対応するタスクＴ４は、プロセスＰ１に対応するタスクＴ１に依存する。

プロセスＰ２の実行（すなわち、タスクＴ２の処理）に応じて書き込まれたファイル“ｓｍｂ．ｃｏｎｆ”は、プロセスＰ２の実行よりも後のプロセスＰ４の実行（すなわち、タスクＴ４の処理）に応じて読み出されている。したがって、プロセスＰ４に対応するタスクＴ４は、プロセスＰ２に対応するタスクＴ２に依存する。

プロセスＰ１の実行（すなわち、タスクＴ１の処理）に応じて書き込まれたファイル“ｓｍｂｄ”は、プロセスＰ１の実行よりも後のプロセスＰ４の実行（すなわち、タスクＴ４の処理）に応じて読み出されている。したがって、プロセスＰ４に対応するタスクＴ４は、プロセスＰ１に対応するタスクＴ１に依存する。

また、プロセスＰ３の実行（すなわち、タスクＴ３の処理）に応じて書き込まれたファイル“／ｓｒｖ／ｄａｔａ／”は、プロセスＰ３の実行よりも後のプロセスＰ４の実行（すなわち、タスクＴ４の処理）に応じて読み出されている。したがって、プロセスＰ４に対応するタスクＴ４は、プロセスＰ３に対応するタスクＴ３に依存する。

依存関係解析部１１４は、検出されたタスク間の依存関係に基づき、図２１に示す依存関係表１０３を作成する。この依存関係表１０３では、タスクＴ１，Ｔ３には依存するタスクがなく、タスクＴ２がタスクＴ１に依存し、タスクＴ４がタスクＴ１，Ｔ２，Ｔ３に依存することが示されている。

第１実施形態と同様に、データアクセス監視部２１２、アクセス記録生成部１１３、および依存関係解析部１１４は、依存関係分析モジュール１Ａを構成する。この依存関係分析モジュール１Ａでは、サーバ２０と設定用端末１０とが連携して、構成定義１０１に基づくタスクの依存関係を解析する。

次いで、図２２は、リファクタリング前の構成定義１０１に対して、タスクＴ３とタスクＴ４の順序が入れ替えられた、リファクタリング後の構成定義１０４を示す。このリファクタリング後の構成定義１０４に基づくタスクの処理順序は、タスクＴ１、タスクＴ２、タスクＴ４、タスクＴ３の順である。

違反検査部１１５は、違反検出部１１５Ａと違反通知部１１５Ｂとを備える。違反検出部１１５Ａは、依存関係表１０３を用いて、タスク間の依存関係に基づく制約を決定する。違反検出部１１５Ａは、例えば、タスクＴ１の後にタスクＴ２が処理されなければならないことを示す制約と、タスクＴ１，Ｔ２，Ｔ３の後にタスクＴ４が処理されなければならないことを示す制約とを決定する。そして、違反検出部１１５Ａは、決定された制約に基づき、リファクタリング後の構成定義１０４を検査する。

図２１に示す依存関係表１０３を用いて、図２２に示すリファクタリング後の構成定義１０４が検査される場合、違反検出部１１５Ａは、リファクタリング後の構成定義１０４において、タスクＴ３に依存するタスクＴ４がタスクＴ３よりも前に処理されるので、制約に違反していることを検出する。

違反通知部１１５Ｂは、制約に違反していることを示す検査結果１０５を通知する。違反通知部１１５Ｂは、アクセスファイル表１０２Ａおよびタスクの処理履歴１０２Ｂを用いて、どのファイルについて、制約に違反しているかを取得してもよい。例えば、図１８のアクセスファイル表１０２Ａおよび図２０のタスクの処理履歴１０２Ｂが用いられる場合、タスクＴ４はタスクＴ３にファイル“／ｓｒｖ／ｄａｔａ／”について依存していることが分かる。

この場合、違反通知部１１５Ｂは、図２３に示すように、タスクＴ４がタスクＴ３にファイル“／ｓｒｖ／ｄａｔａ／”について依存するにも関わらず、タスクＴ３がタスクＴ４よりも前に実行されないことを示す検査結果１０５－３を通知することができる。

以上の構成により、リファクタリング後の構成定義１０４がセットアップ結果に影響を与えるか否かが管理者に通知されるので、リファクタリングによって、誤ってセットアップ結果を変えてしまうこと、あるいはセットアップ時にエラーが発生することを未然に防ぐことができる。したがって、サーバ２０のセットアップ結果に影響を与えることなく構成定義をリファクタリングすることができる。

（第３実施形態）
第１実施形態では、サーバ２０内のデータアクセス監視部２１２と、設定用端末１０内のアクセス記録生成部１１３および依存関係解析部１１４とが連携して依存関係分析モジュール１Ａを構成している。これに対して、第３実施形態では、図２４に示すように、データアクセス監視部２１２が設定用端末１０に設けられ、設定用端末１０が依存関係分析モジュール１Ａを備えている。

第３実施形態に係る管理システム１の構成は第１実施形態の管理システム１と同様であり、第３実施形態と第１実施形態とでは、データアクセス監視部２１２が設定用端末１０内に設けられることのみが異なる。以下、第１実施形態と異なる点のみを説明する。

図２４に示すように、データアクセス監視部２１２は、ネットワーク３０またはケーブルを介して、タスクの処理に応じたデータ格納部２０１へのアクセスを監視し、タスクの処理に応じてデータ格納部２０１から読み出されたデータと、タスクの処理に応じてデータ格納部２０１に書き込まれたデータとを検出する。データアクセス監視部２１２は、例えば、タスク毎に、読み出されたデータと書き込まれたデータとを示す情報（例えば、ファイル名）をアクセス記録生成部１１３に送出する。

他の構成については第１実施形態と同様であり、データアクセス監視部２１２が設定用端末１０に設けられる場合にも、第１実施形態と同様の効果を得ることができる。

（第４実施形態）
第１実施形態では、サーバ２０内のデータアクセス監視部２１２と、設定用端末１０内のアクセス記録生成部１１３および依存関係解析部１１４とが連携して依存関係分析モジュール１Ａを構成している。また、第３実施形態では、データアクセス監視部２１２が設定用端末１０に設けられ、設定用端末１０が依存関係分析モジュール１Ａを備えている。

これらに対して、第４実施形態では、図２５に示すように、データアクセス監視部２１２およびアクセス記録生成部１１３がサーバ２０に設けられ、依存関係解析部１１４が設定用端末１０に設けられる。

第４実施形態に係る管理システム１の構成は第１実施形態の管理システム１と同様であり、第４実施形態と第１実施形態とでは、アクセス記録生成部１１３がサーバ２０内に設けられることのみが異なる。以下、第１実施形態と異なる点のみを説明する。

図２５に示すように、データアクセス監視部２１２は、タスクの処理に応じたデータ格納部２０１へのアクセスを監視し、タスクの処理に応じてデータ格納部２０１から読み出されたデータと、タスクの処理に応じてデータ格納部２０１に書き込まれたデータとを検出する。データアクセス監視部２１２は、例えば、タスク毎に、読み出されたデータと書き込まれたデータとを示す情報（例えば、ファイル名）をアクセス記録生成部１１３に送出する。

アクセス記録生成部１１３は、データアクセス監視部２１２によって送出された、タスク毎の読み出されたデータと書き込まれたデータとを示す情報を用いて、アクセスデータ表１０２を生成し、設定用端末１０（依存関係解析部１１４）に送信する。

他の構成については第１実施形態と同様であり、アクセス記録生成部１１３がサーバ２０に設けられる場合にも、第１実施形態と同様の効果を得ることができる。

また、図２６は、設定用端末１０のシステム構成の例を示す。
設定用端末１０は、ＣＰＵ８０１、システムコントローラ８０２、主メモリ８０３、グラフィクスコントローラ８０４、ＢＩＯＳ－ＲＯＭ８０５、不揮発性メモリ８０６、通信デバイス８０７、エンベデッドコントローラ／キーボードコントローラ（ＥＣ／ＫＢＣ）８０８、ＬＣＤ８０９、キーボード８１０、ポインティングデバイス８１１等を備える。

ＣＰＵ８０１は、設定用端末１０内の様々なコンポーネントの動作を制御するプロセッサである。ＣＰＵ８０１は、ストレージデバイスである不揮発性メモリ８０６から主メモリ８０３にロードされる様々なプログラムを実行する。これらプログラムには、ＯＳ８０３Ａ、および様々なアプリケーションプログラムが含まれている。アプリケーションプログラムには、構成管理プログラム８０３Ｂが含まれている。この構成管理プログラム８０３Ｂは、上述した構成定義エディタ１１１、構成管理ツール１１２、アクセス記録生成部１１３、依存関係解析部１１４、違反検査部１１５等の各機能を実現するための命令群を含む。

また、ＣＰＵ８０１は、ＢＩＯＳ－ＲＯＭ８０５に格納された基本入出力システム（ＢＩＯＳ）も実行する。ＢＩＯＳは、ハードウェア制御のためのプログラムである。

システムコントローラ８０２は、ＣＰＵ８０１のローカルバスと各種コンポーネントとの間を接続するデバイスである。システムコントローラ８０２には、主メモリ８０３をアクセス制御するメモリコントローラも内蔵されている。また、システムコントローラ８０２は、ＰＣＩ ＥＸＰＲＥＳＳ規格のシリアルバスなどを介してグラフィクスコントローラ８０４との通信を実行する機能も有している。

グラフィクスコントローラ８０４は、設定用端末１０のディスプレイモニタとして使用されるＬＣＤ８０９を制御する表示プロセッサである。このグラフィクスコントローラ８０４によって生成される表示信号はＬＣＤ８０９に送られる。ＬＣＤ８０９は、表示信号に基づいて画面イメージを表示する。なお、ＬＣＤ８０９は、設定用端末１０の外部に設けられ、ケーブル等を介して設定用端末１０に接続されてもよい。

通信デバイス８０７は、有線通信または無線通信を実行するように構成されたデバイスである。通信デバイス８０７は、信号を送信する送信部と、信号を受信する受信部とを含む。

ＥＣ／ＫＢＣ８０８は、電力管理のためのエンベデッドコントローラと、キーボード８１０およびポインティングデバイス８１１を制御するキーボードコントローラとを内蔵したワンチップマイクロコンピュータである。ＥＣ／ＫＢＣ８０８は、ユーザによる電源スイッチの操作に応じて設定用端末１０を電源オンまたは電源オフする機能を有している。ポインティングデバイス８１１は、例えば、タッチパッドである。なお、ポインティングデバイス８１１は、ＵＳＢコネクタ（図示せず）を介して接続されるマウスや、ＬＣＤ８０９の上面に配置されるタッチパネルであってもよい。

また、図２７は、サーバ２０のシステム構成の例を示す。
サーバ２０は、ＣＰＵ９１、システムコントローラ９２、主メモリ９３、ＢＩＯＳ－ＲＯＭ９４、不揮発性メモリ９５、通信デバイス９６、エンベデッドコントローラ（ＥＣ）９７等を備える。

ＣＰＵ９１は、サーバ２０内の様々なコンポーネントの動作を制御するプロセッサである。ＣＰＵ９１は、ストレージデバイスである不揮発性メモリ９５から主メモリ９３にロードされる様々なプログラムを実行する。これらプログラムには、ＯＳ９３Ａ、ミドルウェア９３Ｂ、および様々なアプリケーションプログラム９３Ｃが含まれている。ＯＳ９３Ａ、ミドルウェア９３Ｂ、およびアプリケーションプログラム９３Ｃは、上述したタスク実行部２１１、データアクセス監視部２１２等の各機能を実現するための命令群を含む。

また、ＣＰＵ９１は、ＢＩＯＳ－ＲＯＭ９４に格納された基本入出力システム（ＢＩＯＳ）も実行する。ＢＩＯＳは、ハードウェア制御のためのプログラムである。

システムコントローラ９２は、ＣＰＵ９１のローカルバスと各種コンポーネントとの間を接続するデバイスである。システムコントローラ９２には、主メモリ９３をアクセス制御するメモリコントローラも内蔵されている。

通信デバイス９６は、有線通信または無線通信を実行するように構成されたデバイスである。通信デバイス９６は、信号を送信する送信部と、信号を受信する受信部とを含む。

ＥＣ９７は、電力管理のためのエンベデッドコントローラを内蔵したワンチップマイクロコンピュータである。ＥＣ９７は、ユーザによる電源スイッチの操作に応じてサーバ２０を電源オンまたは電源オフする機能を有している。

以上説明したように、第１乃至第４実施形態によれば、セットアップ結果に影響を与えることなく構成定義をリファクタリングできる。サーバ２０は、設定用端末１０による要求に応じて、複数のタスクを第１の順序で処理する。設定用端末１０は、サーバ２０に複数のタスクを第１の順序で処理させる間に、複数のタスクの各々の処理に応じて読み出されたデータと書き込まれたデータとを示す情報を取得する。そして、設定用端末１０は、この情報を用いて、複数のタスクの内の第１タスクの処理に応じて書き込まれ、且つ第１タスクの処理よりも後の第２タスクの処理に応じて読み出された第１データを検出する。

したがって、この第１データの検出に基づいて、例えば、第１タスクに依存する第２タスクがあって、これらの順序を誤って入れ替えた場合に、第２タスクが処理されるときに、第１タスクの処理により提供（生成）される第１データが存在しないことでセットアップに問題が生じることを、管理者に通知することができる。

また、第１乃至第４実施形態に記載された様々な機能の各々は、回路（処理回路）によって実現されてもよい。処理回路の例には、中央処理装置（ＣＰＵ）のような、プログラムされたプロセッサが含まれる。このプロセッサは、メモリに格納されたコンピュータプログラム（命令群）を実行することによって、記載された機能それぞれを実行する。このプロセッサは、電気回路を含むマイクロプロセッサであってもよい。処理回路の例には、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、マイクロコントローラ、コントローラ、他の電気回路部品も含まれる。これら実施形態に記載されたＣＰＵ以外の他のコンポーネントの各々もまた処理回路によって実現されてもよい。

また、第１乃至第４実施形態の各種処理はコンピュータプログラムによって実現することができるので、このコンピュータプログラムを格納したコンピュータ読み取り可能な記憶媒体を通じてこのコンピュータプログラムをコンピュータにインストールして実行するだけで、これら実施形態と同様の効果を容易に実現することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…管理システム、１０…設定用端末、２０…サーバ、３０…ネットワーク、１０１…リファクタリング前の構成定義、１０２…アクセスデータ表、１０３…依存関係表、１０４…リファクタリング後の構成定義、１０５…検査結果、１１１…構成定義エディタ、１１２…構成管理ツール、１１３…アクセス記録生成部、１１４…依存関係解析部、１１５…違反検査部、１１５Ａ…違反検出部、１１５Ｂ…違反通知部、２０１…データ格納部、２１１…タスク実行部、２１２…データアクセス監視部。

Claims (20)

1. ネットワークまたはケーブルを介して相互に接続される第１情報処理装置と第２情報処理装置とによって構成される管理システムであって、
   前記第１情報処理装置は、前記第２情報処理装置による要求に応じて、複数のタスクを第１の順序で処理するように構成され、
   前記第２情報処理装置は、
   前記第１情報処理装置に前記複数のタスクを前記第１の順序で処理させる間に、前記複数のタスクの各々の処理に応じて読み出されたデータと書き込まれたデータとを示す情報を取得し、
   前記情報を用いて、前記複数のタスクの内の第１タスクの処理に応じて書き込まれ、且つ前記第１タスクの処理よりも後の第２タスクの処理に応じて読み出された第１データを検出するように構成される、管理システム。
2. 前記第２情報処理装置は、さらに、
   前記第１データが検出されたことに基づき、前記第１タスクの後に前記第２タスクが処理されなければならないことを示す第１制約を決定し、
   第２の順序で処理される前記複数のタスクが、前記第１制約に違反している場合、前記第１制約に違反していることを通知するように構成される、請求項１記載の管理システム。
3. 前記第２情報処理装置は、さらに、前記複数のタスクを前記第２の順序で処理することを示す操作を受け付けたとき、前記第２の順序で処理される前記複数のタスクが、前記第１制約に違反しているならば、前記第１制約に違反していることを画面に表示するように構成される、請求項２記載の管理システム。
4. 前記第１データは、前記第１情報処理装置によってアクセス可能なファイルの少なくとも一部である請求項１記載の管理システム。
5. 前記第１データは、前記第１情報処理装置によってアクセス可能なメモリまたはデータベース内のレコードの少なくとも一部である請求項１記載の管理システム。
6. 前記複数のタスクは、前記第１情報処理装置によって実行されるべき複数のコマンドを用いてそれぞれ規定され、
   前記複数のコマンドは、前記第１情報処理装置によって実行されるオペレーティングシステム、ミドルウェア、またはアプリケーションプログラムに設けられるコマンドを含む請求項１記載の管理システム。
7. ネットワークまたはケーブルを介して接続された外部情報処理装置に複数のタスクを第１の順序で処理させる間に、前記複数のタスクの各々の処理に応じて読み出されたデータと書き込まれたデータとを示す情報を取得する取得手段と、
   前記情報を用いて、前記複数のタスクの内の第１タスクの処理に応じて書き込まれ、且つ前記第１タスクの処理よりも後の第２タスクの処理に応じて読み出された第１データを検出する検出手段とを具備する情報処理装置。
8. 前記第１データが検出されたことに基づき、前記第１タスクの後に前記第２タスクが処理されなければならないことを示す第１制約を決定する決定手段と、
   第２の順序で処理される前記複数のタスクが、前記第１制約に違反している場合、前記第１制約に違反していることを通知する通知手段とをさらに具備する請求項７記載の情報処理装置。
9. 前記通知手段は、前記複数のタスクを前記第２の順序で処理することを示す操作を受け付けたとき、前記第２の順序で処理される前記複数のタスクが、前記第１制約に違反しているならば、前記第１制約に違反していることを画面に表示する請求項８記載の情報処理装置。
10. 前記第１データは、前記外部情報処理装置によってアクセス可能なファイルの少なくとも一部である請求項７記載の情報処理装置。
11. 前記第１データは、前記外部情報処理装置によってアクセス可能なメモリまたはデータベース内のレコードの少なくとも一部である請求項７記載の情報処理装置。
12. 前記複数のタスクは、前記外部情報処理装置によって実行されるべき複数のコマンドによってそれぞれ規定され、
    前記複数のコマンドは、前記外部情報処理装置によって実行されるオペレーティングシステム、ミドルウェア、またはアプリケーションプログラムに設けられるコマンドを含む請求項７記載の情報処理装置。
13. 外部情報処理装置による要求に応じて、複数のタスクを第１の順序で処理する制御手段と、
    前記複数のタスクを前記第１の順序で処理する間に、前記複数のタスクの各々の処理に応じて読み出されたデータと書き込まれたデータとを示す情報を前記外部情報処理装置に送信する送信手段とを具備し、
    前記情報は、前記複数のタスクの内の第１タスクの処理に応じて書き込まれ、且つ前記第１タスクの処理よりも後の第２タスクの処理に応じて読み出された第１データを検出するために用いられる情報処理装置。
14. 前記読み出されたデータおよび前記書き込まれたデータは、前記情報処理装置によってアクセス可能なファイルの少なくとも一部である請求項１３記載の情報処理装置。
15. 前記読み出されたデータおよび前記書き込まれたデータは、前記情報処理装置によってアクセス可能なメモリまたはデータベース内のレコードの少なくとも一部である請求項１３記載の情報処理装置。
16. 前記複数のタスクは、前記情報処理装置によって実行されるべき複数のコマンドによってそれぞれ規定され、
    前記複数のコマンドは、前記情報処理装置によって実行されるオペレーティングシステム、ミドルウェア、またはアプリケーションプログラムに設けられるコマンドを含む請求項１３記載の情報処理装置。
17. ネットワークまたはケーブルを介して相互に接続される第１情報処理装置と第２情報処理装置とによって構成されるシステムの設定管理方法であって、
    第２情報処理装置による要求に応じて、前記第１情報処理装置によって複数のタスクを第１の順序で処理し、
    前記第１情報処理装置に前記複数のタスクを前記第１の順序で処理させる間に、前記複数のタスクの各々の処理に応じて読み出されたデータと書き込まれたデータとを示す情報を取得し、
    前記情報を用いて、前記複数のタスクの内の第１タスクの処理に応じて書き込まれ、且つ前記第１タスクの処理よりも後の第２タスクの処理に応じて読み出された第１データを検出する設定管理方法。
18. ネットワークまたはケーブルを介して接続された外部情報処理装置に複数のタスクを第１の順序で処理させる間に、前記複数のタスクの各々の処理に応じて読み出されたデータと書き込まれたデータとを示す情報を取得し、
    前記情報を用いて、前記複数のタスクの内の第１タスクの処理に応じて書き込まれ、且つ前記第１タスクの処理よりも後の第２タスクの処理に応じて読み出された第１データを検出する設定管理方法。
19. 外部情報処理装置による要求に応じて、複数のタスクを第１の順序で処理し、
    前記複数のタスクを前記第１の順序で処理する間に、前記複数のタスクの各々の処理に応じて読み出されたデータと書き込まれたデータとを示す情報を前記外部情報処理装置に送信する設定管理方法であって、
    前記情報は、前記複数のタスクの内の第１タスクの処理に応じて書き込まれ、且つ前記第１タスクの処理よりも後の第２タスクの処理に応じて読み出された第１データを検出するために用いられる設定管理方法。
20. コンピュータにより実行されるプログラムであって、前記プログラムは、
    ネットワークまたはケーブルを介して接続された外部コンピュータに複数のタスクを第１の順序で処理させる間に、前記複数のタスクの各々の処理に応じて読み出されたデータと書き込まれたデータとを示す情報を取得する手順と、
    前記情報を用いて、前記複数のタスクの内の第１タスクの処理に応じて書き込まれ、且つ前記第１タスクの処理よりも後の第２タスクの処理に応じて読み出された第１データを検出する手順とを前記コンピュータに実行させるプログラム。

Images