JP5741717B2 - 情報処理方法、装置及びプログラム - Google Patents

Description

本技術は、コンピュータシステムの管理技術に関する。

ＩＣＴ（Information and Communication Technology）システムの構成情報を、当該ＩＣＴシステムのクライアントに提供するために、図１に示すように、ＦＣＭＤＢ（Federated CMDB(Configuration Management Database)）を用いる場合がある。ＦＣＭＤＢは、複数のＭＤＲ（Management Data Repository）を仮想的に統合して、統一的なビューをクライアントに提供するためのものである。ＭＤＲは、ＩＣＴシステムの運用管理データを保持するものであり、運用管理ミドルウェアのＤＢに相当する。ＭＤＲ毎に保持するデータの種別や量が異なっており、図１の例では、ＭＤＲ１は、設計情報を保持しており、ＭＤＲ２は製品情報を保持しており、ＭＤＲ３は性能情報を保持しており、ＭＤＲ４は構成情報を保持している。

ＦＣＭＤＢは、構成部品（Configuration Item:ＣＩ。構成アイテムとも呼ぶ）及び当該構成部品間の関係（Relationship）のデータを格納している。ＣＩは、ＩＣＴシステムに含まれるサーバ、ストレージ、ソフトウエアなどの部品である。

例えば、図１において、ＦＣＭＤＢ上の構成部品Ｃのデータは、ＭＤＲ４における構成情報Ｃｄと、ＭＤＲ３における性能情報Ｃｃと、ＭＤＲ１における設計情報Ｃａとを統合したデータを含む。

なお、ＭＤＲについては、管理者などが人手でデータ入力を行うことで更新したり、ＩＣＴシステムから自動的にデータを取得して更新する場合もある。その後、ＭＤＲの更新を、ＦＣＭＤＢに反映させる。

このようなＭＤＲの更新をＦＣＭＤＢへ反映させる処理は、ＭＤＲにおいて１つのＣＩのデータが更新される毎に行われるわけではなく、何らかの方法により決められた更新間隔で、その更新間隔において更新されたＣＩのデータが複数の更新要求としてまとめてＦＣＭＤＢに送る形態が考えられる。その場合、例えば複数のＭＤＲで更新間隔が異なっていると、ほぼ同じタイミングで更新されたＣＩについてのデータであっても、ＦＣＭＤＢにその更新要求が送られるタイミングがずれる場合がある。図２に示すように、ＭＤＲ１よりもＭＤＲ２の方が更新間隔が短い場合、ＭＤＲ１では、Ｓｗｉｔｃｈ１更新、Ｓｅｒｖｅｒ１更新及びＳｅｒｖｉｃｅ１更新のための更新要求がＦＣＭＤＢへ送信されるが、同じような更新が行われるＭＤＲ２では、Ｓｗｉｔｃｈ１更新及びＳｅｒｖｅｒ１更新のための更新要求のみがＦＣＭＤＢへ送られる。すなわち、ＭＤＲ２におけるＳｅｒｖｉｃｅ１更新のための更新要求は、少々遅れてＦＣＭＤＢに送られることになる。

また、ＭＤＲへの更新を人手で行う場合には、管理者が同時に行われるべき、ＣＩのデータの更新を失念する場合もある。

ＦＣＭＤＢにおけるＣＩの状態とＣＩの実際の状態とに齟齬があると、ＦＣＭＤＢを参照して構成変更を指示したり、サービス配備を指示したり、パッチ適用を行ったりすると、不具合が発生する。例えば、ネットワーク切断エラーが発生したので、関連するＣＩであるＳｅｒｖｉｃｅ１は利用できない状態であるにも拘わらず、ＦＣＭＤＢへの反映が何らかの理由で同時に行われていない場合が発生する。このような場合、Ｓｅｒｖｉｃｅ１の属性Ｓｔａｔｕｓの属性値がｎｏｒｍａｌのままであることを確認して、Ｓｅｒｖｉｃｅ１を顧客に提供するような構成変更を行ってしまう可能性がある。当然顧客はＳｅｒｖｉｃｅ１を利用しようとするとエラーが発生して使用できない。

このような問題を解決するための手法としては、ＣＩが同時に更新された回数、更新時に同時に更新された割合を利用し、ＣＩ更新時に他の更新すべきＣＩをチェックするという方法がある。しかしながら、この手法によれば、膨大な数のＣＩが存在する場合には計算量が非常に多くなるという問題がある。

Nadi, S., Holt, R.; Mankovskii, S., "Does the Past Say It All? Using History to Predict Change Sets in a CMDB," CSMR2010, pp.97-106, Mar. 2010

特開昭６２−２１４４３８号公報 特開２００６−１６４１３６号公報 特開２００７−８０１７１号公報 特公平３−３２５９号公報

従って、本技術の目的は、一側面では、構成情報の更新漏れ等の問題を低負荷で検出するための技術を提供することである。

本技術に係るパターン適用方法は、（Ａ）システムに含まれる特定の構成部品についての特定の属性の属性値を変更する要求を受信した場合、システムに含まれる第１の構成部品についての属性の属性値の変更に係る第１の条件と、当該第１の構成部品と構成上所定の関係を有する第２の構成部品について第１の構成部品についての属性値の変更と同時期に変更されるべき属性の属性値に係る第２の条件とを含むパターンを複数格納している第１データ格納部において、上記要求に係る変更が第１の条件を満たすパターンが存在するか判断する処理と、（Ｂ）上記要求に係る変更が第１の条件を満たすパターンが存在する場合には、システムに含まれる構成部品の情報を格納し且つ上記要求により構成部品の情報が更新される第２データ格納部と、上記要求と共に処理すべき他の要求とのうち少なくともいずれかに基づき、当該パターンの第２の条件が満たされるか判断する処理と、（Ｃ）第１の条件と第２の条件とが満たされるパターンが存在する場合には、所定の処理を実施する処理とを含む。

本技術に係るパターン生成方法は、（Ａ）同時期とみなされる所定の時期に受信され且つシステムに含まれる特定の構成部品についての特定の属性の属性値を変更する複数の要求の各々について、システムに含まれる構成部品のデータと構成部品間の関係を表すデータとを格納する第１データ格納部において、当該要求に係る特定の構成部品から、構成部品間の関係を所定の範囲辿ることで、複数の要求のうち他の要求に係る特定の構成部品に到達するか判断する処理と、（Ｂ）特定の要求に係る特定の構成部品から複数の要求のうち他の要求に係る特定の構成部品に到達する場合には、特定の要求に係る特定の構成部品についての特定の属性の属性値の変更に係る第１の条件と、他の要求に係る特定の構成部品についての特定の属性の属性値の変更に係る第２の条件とを含むパターンを生成し、第２データ格納部に格納する処理とを含む。

図１は、ＦＣＭＤＢについて説明するための図である。 図２は、ＦＣＭＤＢの更新を説明するための図である。 図３は、本実施の形態に係るシステム構成例を示す図である。 図４は、ＦＣＭＤＢに格納されているＣＩ群の一例を示す図である。 図５は、同時とみなされる時期に受信された更新要求の一例を示す図である。 図６は、生成される更新パターンの一例を示す図である。 図７は、ＦＣＭＤＢに格納されるデータの一例を示す図である。 図８は、ＣＩの関係の一例を示す図である。 図９は、ＣＩのデータ例を示す図である。 図１０は、ＣＩのデータ例を示す図である。 図１１は、関係のデータ例を示す図である。 図１２は、本実施の形態のメインの処理フローを示す図である。 図１３は、関係更新処理の処理フローを示す図である。 図１４Ａは、ＣＩ間の関係の一例を示す図である。 図１４Ｂは、関係の変更の一例を示す図である。 図１４Ｃは、関係の削除の一例を示す図である。 図１４Ｄは、ＣＩの削除の一例を示す図である。 図１５は、更新パターン生成処理の処理フローを示す図である。 図１６Ａは、構成部品Ｓｗｉｔｃｈ１の変更前データの一例を示す図である。 図１６Ｂは、構成部品Ｓｗｉｔｃｈ１の変更後データの一例を示す図である。 図１７Ａは、Ｓｅｒｖｉｃｅ１の変更前データの一例を示す図である。 図１７Ｂは、Ｓｅｒｖｉｃｅ１の変更後データの一例を示す図である。 図１８は、更新パターン生成処理の処理フローを示す図である。 図１９は、ホップ数について説明するための図である。 図２０は、更新パターン格納部に格納されるデータの一例を示す図である。 図２１は、パターン適用処理の処理フローを示す図である。 図２２は、パターン適用処理の処理フローを示す図である。 図２３は、信頼度更新処理の処理フローを示す図である。 図２４は、コンピュータの機能ブロック図である。

本技術の実施の形態に係るシステムの概要を図３に示す。本実施の形態に係る主要な情報処理装置であるＦＣＭＤＢシステム１００は、複数のＭＤＲ（図３ではＭＤＲ１及び２）と、１又は複数のユーザ端末２００と、コンピュータネットワークで接続されている。本実施の形態では、各ＭＤＲから、自身において更新されたＣＩのデータをＦＣＭＤＢに対して反映させるための更新要求が、ＦＣＭＤＢシステム１００に送信されるものとする。ユーザ端末２００は、例えば管理者が操作するパーソナルコンピュータなどの端末装置である。ユーザ端末２００は、管理者の指示に従ってＭＤＲに対する更新を行う場合もある。

そして、ＦＣＭＤＢシステム１００は、更新要求処理部１０１と、第１データ格納部１０２と、ＦＣＭＤＢ１０３と、リレーション更新処理部１０４と、更新パターン生成部１０５と、更新パターン格納部１０６と、パターンマッチング部１０７と、第２データ格納部１０８と、指示処理部１０９とを有する。

更新要求処理部１０１は、各ＭＤＲから更新要求を受信すると、第１データ格納部１０２に格納する。以下、同時に更新されたとみなされるＣＩについての更新要求をまとめて処理することになる。同時に更新されたとみなされるＣＩについての更新要求は、例えば、ある更新要求と当該ある更新要求を受信してから一定時間内に受信した他の更新要求とを含む場合もある。また、更新要求処理部１０１においてタイムスロットを定義して、同一タイムスロットにおいて受信した更新要求を、同時に更新されたとみなされるＣＩについての更新要求として取り扱う場合もある。さらに、場合によっては１度にまとめて送られてきた複数の更新要求を、同時に更新されたＣＩについての更新要求として取り扱う場合もある。

更新要求処理部１０１は、本実施の形態では、更新要求に従ってＦＣＭＤＢ１０３の更新を行うと共に、更新前のデータを、以下の処理のために第１データ格納部１０２に格納する。

リレーション更新処理部１０４は、第１データ格納部１０２に格納されており且つ構成部品間の関係についての更新要求を処理し、更新パターン格納部１０６に格納されている更新パターンを更新する。更新パターン生成部１０５は、第１データ格納部１０２に格納されており且つ同時に更新されたとみなされるＣＩについての更新要求を用いて更新パターンを生成する処理を実施し、生成した更新パターンを更新パターン格納部１０６に格納する。なお、更新パターン生成部１０５は、信頼度算出部１０５１を含む。

パターンマッチング部１０７は、第１データ格納部１０２に格納されており且つ同時に更新されたとみなされるＣＩについての更新要求に対して、更新パターン格納部１０６に格納されている更新パターンを適用して、同時に更新すべきにも拘わらず未更新となっている、他のＣＩの属性を抽出する処理を実施し、処理結果を第２データ格納部１０８に格納すると共に、所定の処理を実施した上でユーザ宛に通知を行う。

指示処理部１０９は、ユーザ端末２００から、更新すべきＣＩの属性についての更新指示を受信して、更新パターン格納部１０６における更新パターンの信頼度を更新したり、ＦＣＭＤＢ１０３の更新を行ったりする。

本実施の形態では、同時に更新されたとみなされるＣＩについての複数の更新要求から更新パターンを生成する。例えば、図４に示すようなＣＩ群がＦＣＭＤＢ１０３に格納されているものとする。すなわち、ＣＩは、Ｓｗｉｔｃｈ１、Ｓｅｒｖｅｒ１及びＳｅｒｖｅｒ２、並びにＳｅｒｖｉｃｅ１を含む。そして、Ｓｗｉｔｃｈ１からＳｅｒｖｅｒ２へ関係（Relationship）が設けられており、Ｓｗｉｔｃｈ１からＳｅｒｖｅｒ１へ関係が設けられており、Ｓｅｒｖｅｒ１からＳｅｒｖｉｃｅ１へ関係が設けられている。また、Ｓｗｉｔｃｈ１の属性Ｐｏｒｔ０には属性値ＯＫが設定されており、Ｓｅｒｖｉｃｅ１の属性Ｓｔａｔｕｓには属性値ｎｏｒｍａｌが設定されている。

このような状態において、図５に示すような更新要求が同時とみなされる時期に受信されたものとする。すなわち、Ｓｗｉｔｃｈ１の属性Ｐｏｒｔ０を属性値ＮＧに変更する要求と、Ｓｅｒｖｉｃｅ１の属性Ｓｔａｔｕｓを属性値ｅｒｒｏｒに変更する要求とを受信したものとする。そうすると、図６に示すような更新パターンが生成される。すなわち、図４に示したように、関係で繋がれた範囲の限度において例えば３ホップ以内（すなわち、距離に相当する中間構成部品の数が３以内）であるという条件の下、一方の更新要求による変更についての条件（例えば特定のＣＩの特定の属性について変更前属性値及び変更後属性値を含む）と、他方の更新要求による変更についての警告条件（例えば特定のＣＩの特定の属性の変更前属性値を含む）とを含む。例えば、第１の更新パターンとしては、Ｓｗｉｔｃｈ１の属性Ｐｏｒｔ０の属性値がＯＫからＮＧへ変更された場合、Ｓｅｒｖｉｃｅ１の属性Ｓｔａｔｕｓの属性値がｎｏｒｍａｌのままであれば、警告などを実施するという更新パターンである。また、第２の更新パターンとしては、Ｓｅｒｖｉｃｅ１の属性Ｓｔａｔｕｓの属性値がｎｏｒｍａｌからｅｒｒｏｒに変更された場合、Ｓｗｉｔｃｈ１の属性Ｐｏｒｔ０の属性値がＯＫのままであれば、警告などを実施するという更新パターンである。

その後、あるタイミングで、Ｓｗｉｔｃｈ１の属性Ｐｏｒｔ０の属性値をＮＧに変更する更新要求のみを受信すると、図７に示すようなデータがＦＣＭＤＢ１０３に格納されるようになる。すなわち、Ｓｗｉｔｃｈ１の属性Ｐｏｒｔ０の属性値としてＮＧが格納されているが、Ｓｅｒｖｉｃｅ１の属性Ｓｔａｔｕｓの属性値はｎｏｒｍａｌのままである。このように、受信された更新要求は、図６に示した更新パターンのうち第１行目の更新パターンの条件を満たすと共に、ＦＣＭＤＢ１０３の状態は警告条件を満たすことになる。このように条件及び警告条件を満たす場合には、管理者に対する警告などの所定の処理を実施する。

なお、ＦＣＭＤＢ１０３には、例えば以下に述べるようなデータが格納される。例えば、図８に示すように、Ｓｅｒｖｅｒ００１というＣＩとＰｅｒｓｏｎ００５というＣＩとが存在しており、Ｓｅｒｖｅｒ００１からＰｅｒｓｏｎ００５へＭａｎａｇｅｄＢｙという関係が設定されているものとする。そうすると、ＣＩであるＳｅｒｖｅｒ００１については、図９に示すようなデータが格納される。すなわち、構成部品ＩＤがＳｅｒｖｅｒ００１となっており、ＴｙｐｅがＳｅｒｖｅｒであり、この構成部品の各属性の属性値が含まれる。さらに、ＣＩであるＰｅｒｓｏｎ００５については、図１０に示すようなデータが格納される。すなわち、構成部品ＩＤがＰｅｒｓｏｎ００５となっており、ＴｙｐｅがＳｅｒｖｅｒであり、この構成部品の各属性の属性値が含まれる。さらに、これらのＣＩ間の関係（Relationship）については、図１１に示すようなデータが格納される。すなわち、関係ＩＤがＲｅｌ１となっており、ＴｙｐｅがＭａｎａｇｅｄＢｙであり、ソース（Ｓｏｕｒｃｅ）のＣＩ及びターゲット（Ｔａｒｇｅｔ）のＣＩと、この関係について他の属性の属性値が含まれる。

上で簡単に述べた更新パターン生成及び更新パターン適用を行うための具体的な処理内容について、図１２乃至図２３を用いて説明する。

まず、ＦＣＭＤＢシステム１００の更新要求処理部１０１は、各ＭＤＲから更新要求を受信し、当該更新要求のデータを第１データ格納部１０２に格納する（図１２：ステップＳ１）。上でも述べたように、予め定められたルールに則って、同時期とみなされる所定の時期に受信した更新要求についてはまとめて処理を行う。

そして、更新要求処理部１０１は、更新要求に従ってＦＣＭＤＢ１０３の更新を行う（ステップＳ３）。但し、更新前に、更新要求に係るＣＩ又は関係の属性について変更前の属性値を取得して、第１データ格納部１０２に格納する。

そして、リレーション更新処理部１０４は、第１データ格納部１０２に格納されている更新要求に、関係の更新（追加、変更又は削除。ここではＣＩの削除も含む。）が含まれているか判断する（ステップＳ５）。第１データ格納部１０２に格納されている更新要求に、関係の更新が含まれていなければ、リレーション更新処理部１０４は処理を行わずに、処理はステップＳ１３に移行する。一方、更新要求に関係の更新が含まれている場合には、リレーション更新処理部１０４は、関係更新に係る未処理の更新要求を特定する（ステップＳ７）。そして、リレーション更新処理部１０４は、特定された更新要求について関係更新処理を実施する（ステップＳ９）。関係更新処理については、図１３乃至図１４Ｄを用いて説明する。

リレーション更新処理部１０４は、特定された更新要求が関係Ｒの追加であるか判断する（図１３：ステップＳ２１）。特定された更新要求が関係Ｒの追加である場合には、ステップＳ３で更新要求を実施しているので、ここでは処理は行わず、呼出元の処理に戻る。一方、特定された更新要求が関係Ｒの追加でない場合には、リレーション更新処理部１０４は、関係Ｒの変更であるか判断する（ステップＳ２３）。関係Ｒの変更には、当該関係Ｒのターゲット又はソースを変更の場合と、当該関係Ｒのターゲット及びソースの両方を変更する場合がある。

関係Ｒの変更である場合には、リレーション更新処理部１０４は、更新パターン格納部１０６に格納されている各更新パターンについて、変更前の関係を利用した更新パターンであるか否かを判断し、変更前の関係を利用した更新パターンであれば当該更新パターンを削除する（ステップＳ２５）。そして処理は呼出元の処理に戻る。

上でも簡単に説明したが、更新パターンでは、予め定められたｎホップ以内で関係に沿って辿ることができる２つのＣＩについて条件及び警告条件が設定されている。従って、変更前の関係が削除されることによって、ソースとターゲットのＣＩがｎホップ以内で関係に沿って辿ることができなくなる場合がある。図１４Ａに示すように、Ａ乃至ＣのＣＩが存在しており、Ｃについての条件とＡについての警告条件とを含む更新パターンが生成されている場合を考える。ここで、図１４Ｂに示すように、関係の更新要求によって、ＣからＢへの関係についてターゲットがＤに変更され、ＣからＤへ関係が新たに設定され、ＢからＡへの関係が維持されたものとする。そうすると、Ｃについての条件とＡについての警告条件とを含む更新パターンについては、ＣからＡへ関係に沿って辿ることができなくなるので、削除される。関係のソースが変更されたり、ソースとターゲットとが両方ともが変更された場合も同様に判断する。なお、関係Ｒが変更されても別経路で辿ることができれば、削除しなくても良い。

なお、関係更新処理においては生成されないが、図１４Ｂにおいて新たにＣからＤへ関係が設定されるため、例えば、Ｃの属性の属性値を変更する更新要求とＤの属性の属性値を変更する更新要求とが受信されていると、これらの更新要求を用いた新たな更新パターンが生成されるようになる。

また、特定された更新要求が関係Ｒの変更ではない場合、リレーション更新処理部１０４は、関係Ｒの削除であるか判断する（ステップＳ２７）。関係Ｒの削除である場合には、リレーション更新処理部１０４は、削除された関係を利用した更新パターンを削除する（ステップＳ２９）。そして呼出元の処理に戻る。図１４Ｃに示したように、ＣからＢへの関係が削除されると、ＣからＡへ関係に沿って辿ることができなくなるので、Ｃについての条件及びＡについての警告条件を含む更新パターンについては削除する。

本実施の形態では、ＣＩの削除を要求する更新要求についても関係の更新として取り扱われるので、特定された更新要求が関係Ｒの削除ではない場合には、リレーション更新処理部１０４は、削除されたＣＩに係る関係を利用した更新パターンを削除する（ステップＳ３１）。そして処理は呼出元の処理に戻る。図１４Ｄに示したように、Ｂが削除されると、当該Ｂに係る関係（ＣからＢへの関係及びＢからＡへの関係）は同時に削除されるので、ＣからＡへ関係に沿って辿ることができなくなる。従って、Ｃについての条件及びＡについての警告条件を含む更新パターンについては削除する。

以上のような処理を実施することで、関係の更新によって影響を受ける更新パターンについて手当てすることができるようになる。

図１２の処理の説明に戻って、リレーション更新処理部１０４は、関係更新に係る未処理の更新要求が存在しているか判断する（ステップＳ１１）。関係更新に係る未処理の更新要求が存在している場合にはステップＳ７に戻る。一方、関係更新に係る未処理の更新が存在していない場合には、更新パターン生成部１０５は、第１データ格納部１０２における更新要求において構成部品ＣＩの更新が含まれているか判断する（ステップＳ１３）。更新要求において構成部品ＣＩの更新が含まれていない場合には、処理を終了する。

一方、更新要求において構成部品ＣＩの更新が含まれている場合には、更新パターン生成部１０５は、更新パターン生成処理を実施する（ステップＳ１５）。この更新パターン生成処理については、図１５乃至図２０を用いて説明する。なお、更新パターン生成処理では、２以上の更新要求が第１データ格納部１０２に格納されていないと更新パターンが生成されないので、最初に同時とみなされるタイミングで２以上の更新要求があるかどうかを確認してから処理を開始するようにしても良い。

更新パターン生成部１０５は、第１データ格納部１０２に格納されている更新要求から、更新される未処理の構成部品Ｃを１つ特定する（図１５：ステップＳ４１）。例えば、図５の例において第１行目の更新要求を処理する場合には、Ｓｗｉｔｃｈ１が構成部品Ｃとして特定される。そして、更新パターン生成部１０５は、第１データ格納部１０２に格納されている変更前データと構成部品Ｃについての更新要求とから更新差分データを抽出する（ステップＳ４３）。

例えば、図１６Ａに示すようなデータが、Ｓｗｉｔｃｈ１についての更新要求をＦＣＭＤＢ１０３に適用する前のデータであるとする。そうすると、図１６Ｂに示すようなデータが、ＦＣＭＤＢ１０３に格納されているものとする。すなわち、属性名ｐｏｒｔ０の属性値「ＯＫ」が「ＮＧ」に変更される。従って、Ｓｗｉｔｃｈ１／Ｐｏｒｔ０＝ＯＫというデータが変更前データとして第１データ格納部１０２に格納されている。従って、この例では、更新差分データは、Ｓｗｉｔｃｈ１／Ｐｏｒｔ０＝ＯＫ−＞ＮＧとして特定される。

そして、更新パターン生成部１０５は、ホップ数のカウンタｉを１に初期化する（ステップＳ４５）。その後、更新パターン生成部１０５は、構成部品Ｃからｉホップ先の構成部品Ｄを特定する（ステップＳ４７）。例えば、ｉ＝１であれば、図７において、Ｓｗｉｔｃｈ１から１ホップ辿ると、Ｓｅｒｖｅｒ１及びＳｅｒｖｅｒ２が構成部品Ｄとして特定される。

その後、更新パターン生成部１０５は、構成部品Ｄが特定されたか判断する（ステップＳ４９）。上でも述べたように、探索は、構成部品間の関係が規定されている間のみ行うので、図７のＳｅｒｖｉｃｅ１やＳｅｒｖｅｒ２のように末端の構成部品で、関係が規定されていなければ、次のホップにおける構成部品が特定できなくなる。ここで、構成部品Ｄが１つも特定できない場合には端子Ｂを介して図１８のステップＳ６９に移行する。

一方、構成部品Ｄが特定できると、更新パターン生成部１０５は、未処理の構成部品Ｄを１つ特定する（ステップＳ５１）。そして、更新パターン生成部１０５は、第１データ格納部１０２において、この構成部品Ｄに対して更新要求が格納されているかを確認することで、同時に更新が発生したか判断する（ステップＳ５３）。第１データ格納部１０２においてこの構成部品Ｄに対して更新要求が格納されていない場合には、同時に更新が発生していないとして、処理は端子Ｃを介して図１８のステップＳ６３に移行する。

図７の例では、Ｓｗｉｔｃｈ１から１ホップ先の構成部品ＤであるＳｅｒｖｅｒ１及びＳｅｒｖｅｒ２については更新要求を受信していないので、端子Ｃを介して図１８のステップＳ６３に移行する。これに対して、ｉ＝２の場合には、構成部品ＤとしてＳｅｒｖｉｃｅ１が特定され、これについては図５の第２行目に更新要求が含まれているので、同時に更新が発生していると判断される。

一方、第１データ格納部１０２にこの構成部品Ｄに対して更新要求が格納されており、同時に更新が発生している場合、更新パターン生成部１０５は、第１データ格納部１０２から、構成部品Ｄについての変更前データを抽出する（ステップＳ５５）。そして処理は端子Ａを介して図１８の処理に移行する。

構成部品Ｓｅｒｖｉｃｅ１の場合、図５の第２行目の更新要求をＦＣＭＤＢ１０３に対して適用していない場合には、図１７Ａに示すようなデータがＦＣＭＤＢ１０３に格納されている。特に属性名Ｓｔａｔｕｓの属性値は「ｎｏｒｍａｌ」となっている。これに対して、図５の第２行目の更新要求をＦＣＭＤＢ１０３に対して適用すると、図１７Ｂに示すようなデータがＦＣＭＤＢ１０３に格納されることになる。属性名Ｓｔａｔｕｓの属性値は「ｅｒｒｏｒ」に変更されている。従って、第１データ格納部１０２には、変更前データとしてはＳｅｒｖｉｃｅ１／Ｓｔａｔｕｓ＝ｎｏｒｍａｌが格納されており、このデータを抽出する。

図１８の処理の説明に移行して、更新パターン生成部１０５は、ステップＳ４３で抽出された更新差分データを条件として含み且つステップＳ５５で抽出された変更前データを警告条件として含む更新パターンが更新パターン格納部１０６に既に格納されているか判断する（ステップＳ５７）。既に同一の更新パターンが格納されていれば重ねて生成することはないので、処理はステップＳ６３に移行する。

一方、同一の更新パターンがまだ登録されていない場合には、更新パターン生成部１０５の信頼度算出部１０５１は、ホップ数ｉを基に信頼度を算出する（ステップＳ５９）。本実施の形態では、構成部品Ｃと構成部品Ｄとが近いほど信頼度が高いものとする。従って、ホップ数ｉが小さな値ほど信頼度を高くする。そのため、例えば１／ホップ数を信頼度として算出する。図１９に示すように、構成部品ＣであるＳｗｉｔｃｈ１を基準にすると、構成部品ＤがＳｅｒｖｅｒ１及びＳｅｒｖｅｒ２であれば、１ホップ先の構成部品であるから信頼度は１（＝１／１）となる。一方、構成部品ＤがＳｅｒｖｉｃｅ１であれば、２ホップ先の構成部品であるから信頼度は０．５（＝１／２）となる。

そして、更新パターン生成部１０５は、ステップＳ４３で抽出された更新差分データとステップＳ５５で抽出された変更前データとから、ステップＳ４３で抽出された更新差分データを条件として含み且つステップＳ５５で抽出された変更前データを警告条件として含む更新パターンを生成し、ステップＳ５９で算出した信頼度と共に、更新パターン格納部１０６に格納する（ステップＳ６１）。すなわち、本実施の形態では、図２０のようなデータが格納される。図２０の例では、条件と警告条件と信頼度とが格納される。図５の第１行目の更新要求を処理すれば、図２０の第１行目の更新パターンが生成され、図５の第２行目の更新要求を処理すれば、図２０の第２行目の更新パターンが生成される。

更新パターン生成部１０５は、ステップＳ４７で特定された構成部品Ｄのうち未処理の構成部品Ｄが存在するか判断する（ステップＳ６３）。未処理の構成部品Ｄが存在する場合には、処理は端子Ｄを介して図１５のステップＳ５１に戻る。一方、未処理の構成部品Ｄが存在しない場合には、更新パターン生成部１０５は、カウンタｉを１インクリメントし（ステップＳ６５）、ｉが、予め設定されているホップ数上限値を超えたか判断する（ステップＳ６７）。ｉがホップ数上限値以下であれば、処理は端子Ｅを介して図１５のステップＳ４７に戻る。一方、ｉがホップ数上限値を超えた場合には、更新パターン生成部１０５は、未処理の構成部品Ｃが存在しているか判断する（ステップＳ６９）。未処理の構成部品Ｃが存在している場合には、処理は端子Ｆを介して図１５のステップＳ４１に戻る。一方、未処理の構成部品Ｃが存在していない場合には、処理は呼出元の処理に戻る。

このように２つの更新要求について、それらの構成部品が関係で繋がれており且つホップ数上限値以内であれば、２つの更新パターンが生成される。３つの更新要求について、それらの構成部品が関係で繋がれており且つホップ数上限値以内であれば、６つ（＝３×２）の更新パターンが生成されることになる。

図１２の処理に戻って、パターンマッチング部１０７は、パターン適用処理を実施する（ステップＳ１７）。パターン適用処理については、図２１乃至図２２を用いてもよい。

パターンマッチング部１０７は、第１データ格納部１０２に格納されている更新要求に係る未処理の構成部品を１つ特定する（ステップＳ７１）。そして、パターンマッチング部１０７は、更新パターン格納部１０６において、特定された構成部品についての更新パターンを探索する（ステップＳ７３）。

パターンマッチング部１０７は、検出された更新パターンに含まれる条件が満たされているかを判断する（ステップＳ７５）。本実施の形態では、構成部品の特定の属性について変更前の属性値と変更後の属性値とが条件に含まれているので、第１データ格納部１０２に格納されている変更前データとＦＣＭＤＢ１０３に格納されている変更後データとから、条件が満たされているかを判断する。

検出された更新パターンに含まれている条件が満たされていない場合又は更新パターンが検出されなかった場合、処理は端子Ｇを介して図２２の処理に移行する。

一方、検出された更新パターンに含まれる条件が満たされている場合には、パターンマッチング部１０７は、ＦＣＭＤＢ１０３において、検出された更新パターンの警告条件に係る構成部品を探索して（ステップＳ７７）、当該構成部品について警告条件で規定されている属性の属性値を読み出し、当該属性値が、警告条件で規定されている属性値と一致するか判断する（ステップＳ７９）。変更前の属性値が警告条件に含まれるので、この変更前の属性値が、ＦＣＭＤＢ１０３にまだ登録されている場合には、警告条件が満たされたものと判断できる。

ＦＣＭＤＢ１０３における属性値が、警告条件に含まれる属性値と一致しない場合には、端子Ｇを介して図２２の処理に移行する。

一方、ＦＣＭＤＢ１０３における属性値が、警告条件に含まれる属性値と一致する場合には、パターンマッチング部１０７は、検出された更新パターンを第２データ格納部１０８に格納する（ステップＳ８１）。そして、端子Ｇを介して図２２の処理に移行する。

図２２の処理の説明に移行して、パターンマッチング部１０７は、第１データ格納部１０２において、更新要求に係る未処理の構成部品が存在しているか判断する（ステップＳ８３）。更新要求に係る未処理の構成部品が存在している場合には、端子Ｈを介して図２１のステップＳ７１に戻る。

一方、更新要求に係る未処理の構成部品が存在しない場合には、パターンマッチング部１０７は、上で述べた処理で抽出された更新パターンを、それらの信頼度を基に降順でソートする（ステップＳ８５）。

そして、パターンマッチング部１０７は、信頼度が閾値以上の更新パターンについては、警告条件に係る構成部品の属性の属性値を、該当するＭＤＲから取得して、ＦＣＭＤＢ１０３に対して更新を実施する（ステップＳ８７）。信頼度が閾値以上の更新パターンについては、更新要求の到着が遅れているようであればＭＤＲからこの時点で変更後データを取得してＦＣＭＤＢ１０３の更新を強制的に行うものである。もし、ＭＤＲから取得した変更後データが、ＦＣＭＤＢ１０３の現在の値と異なる場合には、ＦＣＭＤＢ１０３に対して更新を行う。一方、ＭＤＲから取得した変更後データが、ＦＣＭＤＢ１０３の現在の値と同じである場合には、更新漏れの可能性がある。

また、パターンマッチング部１０７は、第２データ格納部１０８に格納されている更新パターンから、管理者宛の通知データを生成する（ステップＳ８９）。単に、更新パターンの条件及び警告条件を含むような通知データを生成しても良いし、更新パターンの警告条件から未更新となっている構成部品の属性を特定して、当該構成部品の属性について更新を促すようなデータを生成しても良い。なお、信頼度が第２の閾値以上の更新パターンについてのみ通知データを生成するようにしても良い。さらに、信頼度の順で上位ｎ個（ｎは２以上の整数）に更新パターンを絞り込む場合もある。

例えば、ＦＣＭＤＢ１０３においてＳｅｒｖｉｃｅ１の属性Ｓｔａｔｕｓがｎｏｒｍａｌのままである場合には、Ｓｅｒｖｉｃｅ１の属性がｎｏｒｍａｌのままになっているということを表す通知データを生成する。なお、この場合には、ステップＳ７５では、図２０の第２行目の更新パターンの条件が満たされないことになるので、第２データ格納部１０８にはこの更新パターンは登録されない。

そして、パターンマッチング部１０７は、生成された通知データを、予め登録されている管理者宛に送信する（ステップＳ９１）。通知データについては、メールなどで管理者宛に送信しても良いし、ユーザ端末２００からのアクセスに応じて通知データを送信するようにしても良い。さらに、ユーザ端末２００で監視プログラムが起動されている場合には、リアルタイムで通知データを送信して、ユーザ端末２００の表示装置にリアルタイムで通知データを表示するようにしても良い。

このような処理を実施すれば、同時とみなされるタイミングで受信した更新要求について適切に更新パターンを登録することができ、さらに以後はこの更新パターンに従った更新要求を同時とみなされるタイミングで受信していない場合には、遵守されなかった更新パターンについて抽出できるようになる。なお、このようなマッチング処理自体の処理量は多くはなく、低負荷で更新漏れなどを特定できる。

抽出された更新パターンについては、上で述べたように、管理者に通知したり、信頼度に応じてＭＤＲに応じた更新を自動的にＦＣＭＤＢ１０３に対して適用する場合もある。さらに、更新要求の送信タイミングのずれが問題となっているのであれば、ＭＤＲ側の送信タイミングを調整するように要求を行ったり、管理者側に更新要求の送信タイミングを調整するように警告するようにしても良い。

なお、図２１のステップＳ７３で複数の更新パターンが検出された場合には、各更新パターンについてステップＳ７５乃至Ｓ８１を繰り返す。

次に、ユーザ端末２００で管理者が通知データを確認した後の処理について、図２３を用いて説明する。

ここでは、管理者が、ユーザ端末２００の表示装置に表示されている通知データに含まれる更新パターン（又はその警告条件に含まれる構成部品の属性）のうち、更新すべき更新パターンの構成部品を選択し、その属性及び変更後の属性値の入力を行うものとする。そうすると、ユーザ端末２００は、ＦＣＭＤＢシステム１００へ、構成部品、属性及び変更後の属性値を含む構成部品更新指示を送信する。更新パターンの識別子が含まれる場合もある。

指示処理部１０９は、ユーザ端末２００から、管理者からの構成部品更新指示を受信する（図２３：ステップＳ１０１）。ここで、指示処理部１０９は、ＦＣＭＤＢ１０３において、構成部品更新指示に含まれる構成部品の属性について、変更後の属性値が登録されていない場合には、変更後の属性値で更新する。

また、指示処理部１０９は、第２データ格納部１０８に格納されている更新パターンのうち、構成部品更新指示に対応する更新パターンを特定する（ステップＳ１０３）。警告条件に含まれる構成部品及び属性が構成部品更新指示に含まれる構成部品及び属性と一致する更新パターンを特定する。ユーザ端末２００から、Ｓｅｒｖｉｃｅ１の属性Ｓｔａｔｕｓを属性値ｅｒｒｏｒにする構成部品更新指示を受信した場合、図２０の第２行目の更新パターンが特定される。

そして、指示処理部１０９は、特定された更新パターンの信頼度を、予め定められたルールに従って増加させる（ステップＳ１０５）。例えば、予め定められた値だけ足したり１より大きな値を掛けたりする。

また、指示処理部１０９は、第２データ格納部１０８に格納されている更新パターンのうち、ステップＳ１０３で特定された更新パターン以外の更新パターン（残余の更新パターン）についての信頼度を、予め定められたルールに従って減少させる（ステップＳ１０７）。例えば、予め定められた値だけ減じたり、０より大きく１より小さな値を掛けたりする。

そして、この段階において、指示処理部１０９は、信頼度が閾値未満（例えば０未満）の更新パターンが、更新パターン格納部１０６に格納されているか判断する（ステップＳ１０９）。信頼度が閾値未満の更新パターンが存在する場合には、指示処理部１０９は、信頼度が閾値未満の更新パターンを削除する（ステップＳ１１１）。そして処理を終了する。一方、信頼度が閾値未満の更新パターンが存在しない場合には、処理を終了する。

なお、ここまで実施すると、指示処理部１０９は、第２データ格納部１０８に格納されているデータのうち、同時に更新されたとみなされる構成部品についての更新要求の一群に関連する更新パターンについてのデータを破棄する。

以上のような処理を実施することで、管理者に通知しても、管理者から更新が指示されない構成部品についての更新パターンについては信頼度を下げ、管理者から更新が指示される構成部品についての更新パターンについては信頼度を上げることができる。これによって、管理者による確認を経て更新される構成部品についての更新パターンは、信頼できる更新パターンとして、更新パターン格納部１０６で管理されるようになる。

以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。

例えば、更新パターンの形式は上で述べた例は一例であって、必ずしも上で述べた形にしなければならない訳ではない。具体的には、条件には変更前の属性値が含まれているが、変更後の属性値へ変化したことが重要であれば、変更前の属性値を登録しない場合もある。同様に、警告条件には変更前の属性値を登録しているが、変更後の属性値への変更が行われていないことを重要視すれば、変更前の属性値の代わりに変更後の属性値を警告条件に含めておき、「変更後の属性値に一致しない」場合に警告条件を満たすと判断しても良い。さらに、警告条件については、変更前の属性値に加えて変更後の属性値をも含めておくようにしても良い。このようにして、「警告条件に規定されている属性値の変更が正しく行われていない」場合に警告条件を満たすと判断しても良い。

上で述べた例では、最初に更新要求をＦＣＭＤＢ１０３に適用する例を説明したが、後から適用するような場合もある。この場合、関係の更新が行われていない状態で関係更新処理を実施することになるので、更新要求に係る関係の更新を考慮に入れて関係を辿る処理を行う。また、条件及び警告条件を満たしているか否かは、適用していない更新要求及びＦＣＭＤＢ１０３の内容を確認して判断することになる。

さらに、処理結果が変わらない限り、処理ステップの順番を入れ替えたり、処理ステップを並列に実行するようにしても良い。

また、図３の機能ブロック図は一例であって、必ずしも実際のプログラムモジュール構成及びデータ保持態様と一致しない場合もある。

さらに、ＦＣＭＤＢシステム１００は、一又は複数のコンピュータで実施される場合もある。

なお、上で述べたＦＣＭＤＢシステム１００は、コンピュータ装置であって、図２４に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本実施の形態をまとめると、以下のようになる。

本実施の形態の第１の態様に係るパターン適用方法は、（Ａ）システムに含まれる特定の構成部品についての特定の属性の属性値を変更する要求を受信した場合、システムに含まれる第１の構成部品についての属性の属性値の変更に係る第１の条件と、当該第１の構成部品と構成上所定の関係を有する第２の構成部品について第１の構成部品についての属性値の変更と同時期に変更されるべき属性の属性値に係る第２の条件とを含むパターンを複数格納している第１データ格納部において、上記要求に係る変更が第１の条件を満たすパターンが存在するか判断するステップと、（Ｂ）上記要求に係る変更が第１の条件を満たすパターンが存在する場合には、システムに含まれる構成部品の情報を格納し且つ上記要求により構成部品の情報が更新される第２データ格納部と、上記要求と共に処理すべき他の要求とのうち少なくともいずれかに基づき、当該パターンの第２の条件が満たされるか判断するステップと、（Ｃ）第１の条件と第２の条件とが満たされるパターンが存在する場合には、所定の処理を実施するステップとを含む。

このように、同時更新を表すパターンに沿った、複数の構成部品についての更新が同時期に行われたかを確認でき、行われていない場合には、更新漏れが生じていることとなる。従って、管理者などのユーザに通知したり、自動更新を行ったりすることができるようになる。なお、このようなマッチングの処理の処理負荷は高くはなく、低負荷で問題を抽出できるようになる。

また、上で述べたパターンが、当該パターンの信頼度を含む場合もある。この場合、上で述べた所定の処理が、第１の条件と第２の条件とが満たされるパターンが複数存在する場合には、信頼度に従って第１の条件と第２の条件とが満たされるパターンについて管理者に通知すべきデータを生成する処理を含むようにしても良い。このようにすれば、管理者は、更新漏れを確認の上、各種処置を行うことができるようになる。なお、信頼度の高い順に管理者に提示すれば、より確実な更新漏れから対処できるようになる。

さらに、上で述べたパターンが、当該パターンの信頼度を含む場合もある。この場合、上で述べた所定の処理が、第１の条件と第２の条件とが満たされるパターンの信頼度が閾値以上であれば、第２データ格納部に格納されている構成部品の情報の基となる情報を格納する第３データ格納部から第２の条件に規定されている属性のデータを取得する処理を含むようにしても良い。このようにすれば、更新遅れなどが発生している場合に対処できるようになる。なお、信頼度が高い場合には、自動的に第２データ格納部の更新を行ってしまっても良い場合もある。

さらに、本パターン適用方法は、第１の条件と第２の条件とが満たされ且つ管理者に通知されたパターンのうち、第２の条件に係る属性の変更を管理者により指示されたパターンについては、当該パターンの信頼度を上げ、第２の条件に係る属性の変更を管理者により指示されなかったパターンについては、当該パターンの信頼度を下げるステップをさらに含むようにしても良い。このようにして信頼度を更新することで、より確からしいパターンを抽出できるようにする。

また、本実施の形態に係るパターン生成方法は、（Ａ）同時期とみなされる所定の時期に受信され且つシステムに含まれる特定の構成部品についての特定の属性の属性値を変更する複数の要求の各々について、システムに含まれる構成部品のデータと構成部品間の関係を表すデータとを格納する第１データ格納部において、当該要求に係る特定の構成部品から、構成部品間の関係を所定の範囲辿ることで、複数の要求のうち他の要求に係る特定の構成部品に到達するか判断するステップと、（Ｂ）特定の要求に係る特定の構成部品から複数の要求のうち他の要求に係る特定の構成部品に到達する場合には、特定の要求に係る特定の構成部品についての特定の属性の属性値の変更に係る第１の条件と、他の要求に係る特定の構成部品についての特定の属性の属性値の変更に係る第２の条件とを含むパターンを生成し、第２データ格納部に格納するステップとを含む。

このようにすれば、関連性がある程度担保される構成部品について、同時更新を表すパターンが生成されるようになる。

また、上で述べた第１の条件が、変更前の属性値及び変更後の属性値、又は変更後の属性値を含むようにしても良い。また、上で述べた第２の条件が、変更前の属性値、変更後の属性値、又は変更前の属性値及び変更後の属性値を含むようにしても良い。第１及び第２の条件については、様々な規定の仕方が可能である。

さらに、本パターン生成方法は、システムに含まれる構成部品間の関係を変更又は削除する要求又は構成部品を削除する要求を受信した場合、第２データ格納部において、変更前の関係又は削除された関係若しくは削除された構成部品についての規定された関係を辿ることで生成されたパターンを削除するステップをさらに含むようにしても良い。関係が変更又は削除されると、構成部品間を関係で辿ることができなくなる場合が生ずる。これに対処するためである。

さらに、本パターン生成方法は、特定の要求に係る特定の構成部品から他の要求に係る特定の構成部品に到達するまでに経由する構成部品の数に応じた信頼度を算出して、上記パターンに対応付けて第２データ格納部に格納するステップをさらに含むようにしてもよい。例えば経由する構成部品の数の逆数を信頼度として算出してもよい。すなわち、より近い構成部品についてのパターンについては、より高い信頼度を設定するものである。これによって、マッチング処理を行う際により信頼できるパターンを抽出することもできるようになる。

なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭなどの光ディスク、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ（Random Access Memory）等の記憶装置に一時保管される。

Claims (12)

1. システムに含まれる特定の構成部品についての特定の属性の属性値を変更する要求を受信した場合、前記システムに含まれる第１の構成部品についての属性の属性値の変更に係る第１の条件と、当該第１の構成部品と構成上所定の関係を有する第２の構成部品について前記第１の構成部品についての前記属性値の変更と同時期に変更されるべき属性の属性値に係る第２の条件とを含むパターンを複数格納している第１データ格納部において、前記要求に係る変更が第１の条件を満たすパターンが存在するか判断する処理と、
   前記要求に係る変更が第１の条件を満たすパターンが存在する場合には、前記システムに含まれる構成部品の情報を格納し且つ前記要求により前記構成部品の情報が更新される第２データ格納部と、前記要求と共に処理すべき他の要求とのうち少なくともいずれかに基づき、当該パターンの第２の条件が満たされるか判断する処理と、
   前記第１の条件と前記第２の条件とが満たされるパターンが存在する場合には、所定の処理を実施する処理と、
   を、コンピュータに実行させるためのプログラム。
2. 前記パターンが、当該パターンの信頼度を含み、
   前記所定の処理が、
   前記第１の条件と前記第２の条件とが満たされるパターンが複数存在する場合には、前記信頼度に従って前記第１の条件と前記第２の条件とが満たされるパターンについて管理者に通知すべきデータを生成する処理
   を含む請求項１記載のプログラム。
3. 前記パターンが、当該パターンの信頼度を含み、
   前記所定の処理が、
   前記第１の条件と前記第２の条件とが満たされるパターンの信頼度が閾値以上であれば、前記第２データ格納部に格納されている構成部品の情報の基となる情報を格納する第３データ格納部から前記第２の条件に規定されている属性のデータを取得する処理
   を含む請求項１記載のプログラム。
4. 前記第１の条件と前記第２の条件とが満たされ且つ前記管理者に通知されたパターンのうち、第２の条件に係る属性の変更を前記管理者により指示されたパターンについては、当該パターンの信頼度を上げ、第２の条件に係る属性の変更を前記管理者により指示されなかったパターンについては、当該パターンの信頼度を下げる処理
   をさらに前記コンピュータに実行させる請求項２記載のプログラム。
5. 同時期とみなされる所定の時期に受信され且つシステムに含まれる特定の構成部品についての特定の属性の属性値を変更する複数の要求の各々について、前記システムに含まれる構成部品のデータと構成部品間の関係を表すデータとを格納する第１データ格納部において、当該要求に係る特定の構成部品から、前記構成部品間の関係を所定の範囲辿ることで、前記複数の要求のうち他の要求に係る特定の構成部品に到達するか判断する処理と、
   特定の要求に係る特定の構成部品から前記複数の要求のうち他の要求に係る特定の構成部品に到達する場合には、前記特定の要求に係る特定の構成部品についての特定の属性の属性値の変更に係る第１の条件と、前記他の要求に係る特定の構成部品についての特定の属性の属性値の変更に係る第２の条件とを含むパターンを生成し、第２データ格納部に格納する処理と、
   を、コンピュータに実行させるためのプログラム。
6. 前記第１の条件が、変更前の属性値及び変更後の属性値、又は変更後の属性値を含み、
   前記第２の条件が、変更前の属性値、変更後の属性値、又は変更前の属性値及び変更後の属性値を含む
   請求項５記載のプログラム。
7. 前記システムに含まれる構成部品間の関係を変更又は削除する要求又は構成部品を削除する要求を受信した場合、前記第２データ格納部において、変更前の関係又は削除された関係若しくは削除された構成部品についての規定された関係を辿ることで生成されたパターンを削除する処理
   をさらに前記コンピュータに実行させるための請求項５又は６記載のプログラム。
8. 前記特定の要求に係る特定の構成部品から前記他の要求に係る特定の構成部品に到達するまでに経由する構成部品の数に応じた信頼度を算出して、前記パターンに対応付けて前記第２データ格納部に格納する処理
   をさらに前記コンピュータに実行させるための請求項５乃至７のいずれか１つ記載のプログラム。
9. システムに含まれる特定の構成部品についての特定の属性の属性値を変更する要求を受信した場合、前記システムに含まれる第１の構成部品についての属性の属性値の変更に係る第１の条件と、当該第１の構成部品と構成上所定の関係を有する第２の構成部品について前記第１の構成部品についての前記属性値の変更と同時期に変更されるべき属性の属性値に係る第２の条件とを含むパターンを複数格納している第１データ格納部において、前記要求に係る変更が第１の条件を満たすパターンが存在するか判断する処理と、
   前記要求に係る変更が第１の条件を満たすパターンが存在する場合には、前記システムに含まれる構成部品の情報を格納し且つ前記要求により前記構成部品の情報が更新される第２データ格納部と、前記要求と共に処理すべき他の要求とのうち少なくともいずれかに基づき、当該パターンの第２の条件が満たされるか判断する処理と、
   前記第１の条件と前記第２の条件とが満たされるパターンが存在する場合には、所定の処理を実施する処理と、
   を含み、コンピュータにより実行されるパターン適用方法。
10. 同時期とみなされる所定の時期に受信され且つシステムに含まれる特定の構成部品についての特定の属性の属性値を変更する複数の要求の各々について、前記システムに含まれる構成部品のデータと構成部品間の関係を表すデータとを格納する第１データ格納部において、当該要求に係る特定の構成部品から、前記構成部品間の関係を所定の範囲辿ることで、前記複数の要求のうち他の要求に係る特定の構成部品に到達するか判断する処理と、
    特定の要求に係る特定の構成部品から前記複数の要求のうち他の要求に係る特定の構成部品に到達する場合には、前記特定の要求に係る特定の構成部品についての特定の属性の属性値の変更に係る第１の条件と、前記他の要求に係る特定の構成部品についての特定の属性の属性値の変更に係る第２の条件とを含むパターンを生成し、第２データ格納部に格納する処理と、
    を含み、コンピュータにより実行されるパターン生成方法。
11. システムに含まれる第１の構成部品についての属性の属性値の変更に係る第１の条件と、当該第１の構成部品と構成上所定の関係を有する第２の構成部品について前記第１の構成部品についての前記属性値の変更と同時期に変更されるべき属性の属性値に係る第２の条件とを含むパターンを複数格納している第１データ格納部と、
    前記システムに含まれる特定の構成部品についての特定の属性の属性値を変更する要求を受信した場合、前記第１データ格納部において、前記要求に係る変更が第１の条件を満たすパターンが存在するか判断し、前記要求に係る変更が第１の条件を満たすパターンが存在する場合には、前記システムに含まれる構成部品の情報を格納し且つ前記要求により前記構成部品の情報が更新される第２データ格納部と、前記要求と共に処理すべき他の要求とのうち少なくともいずれかに基づき、当該パターンの第２の条件が満たされるか判断し、前記第１の条件と前記第２の条件とが満たされるパターンが存在する場合には、所定の処理を実施する処理部と、
    を有する情報処理装置。
12. システムに含まれる構成部品のデータと構成部品間の関係を表すデータとを格納する第１データ格納部と、
    同時期とみなされる所定の時期に受信され且つ前記システムに含まれる特定の構成部品についての特定の属性の属性値を変更する複数の要求の各々について、前記第１データ格納部において、当該要求に係る特定の構成部品から、前記構成部品間の関係を所定の範囲辿ることで、前記複数の要求のうち他の要求に係る特定の構成部品に到達するか判断し、特定の要求に係る特定の構成部品から前記複数の要求のうち他の要求に係る特定の構成部品に到達する場合には、前記特定の要求に係る特定の構成部品についての特定の属性の属性値の変更に係る第１の条件と、前記他の要求に係る特定の構成部品についての特定の属性の属性値の変更に係る第２の条件とを含むパターンを生成し、第２データ格納部に格納するパターン生成部と、
    を有する情報処理装置。

Images