JP5083408B2 - 構成管理装置、構成管理プログラム、構成管理方法 - Google Patents

Description

本発明は、リソースに関する情報を管理する構成管理装置、構成管理プログラム、構成管理方法に関する。

大量のデータを格納する異種システム間でデータ共有を可能にする構成管理システム（以下、ＦＣＭＤＢシステム（ＦＣＭＤＢ：Federated Configuration Management Databese)が知られている。

ＦＣＭＤＢシステムは、例えば複数のコンピュータによって構成された業務処理システムや、解析システム等の各種システムを構成するリソースに関する情報を登録、更新、検索、削除することでリソースの構成を管理する。ＦＣＭＤＢシステムの概要図を図１３に示す。ＦＣＭＤＢシステムは、例えば、構成情報、インシデント情報、トラブル情報、リリース情報、変更情報、アプリ情報の各情報をそれぞれ管理している異種システムから、ＦＣＭＤＢシステムを構成する個々のアイテムである構成アイテム（以下、ＣＩと記す）、およびＣＩを定義する属性情報（以下プロパティと記す）を取得する。さらにＦＣＭＤＢシステムは、これらＣＩの関連性（Ｒｅｌａｔｉｏｎｓｈｉｐ）を保持することで、異業種システムに保持されている情報を関連付け、異種システム間の情報を管理する。

よって、ＦＣＭＤＢシステムでは、通常のＤＢ（Ｄａｔａｂａｓｅ）の機能に加えて、異種システム間に保持されている情報を整合、調整するために、Ｅｎｔｉｔｙ（ＣＩ、プロパティおよびＲｅｌａｔｉｏｎｓｈｉｐの総称）間の対応付け、および対応するＥｎｔｉｔｙのプロパティの操作を実行する処理であるリコンシエーションが行われる。

なお、関連ある従来技術として、読み出し要求が発生してからデータが出力されるまでに要求される許容遅延時間を満たしつつ、効率よくアクセスするディスク制御装置が開示されている。
特開平８−５５０５５号公報

ＦＣＭＤＢシステムの処理は、上述のようにリコンシエーションが行われるため、通常のＤＢの処理時間よりも更に時間を要する。一方、ユーザからの処理依頼は、早急に処理完了する必要があるもの、またそれなりに時間がかかっても問題の無いものがある。

また、ＦＣＭＤＢシステムに対し、検索依頼を行った場合、当然ＦＣＭＤＢシステムからの検索結果は不整合な情報や古い情報であってはならず正確なものである必要がある。

本発明は上述した問題点を解決するためになされたものであり、登録、削除、更新処理にいかほどの時間をかけてもいいかを外部から制御可能にし、さらに、登録、削除、更新処理において、ＣＩに対するプロパティの反映操作は処理依頼のあったタイミングとは別のタイミングで実施することで、見かけ上の処理時間を短縮することができる構成管理装置、構成管理プログラム、構成管理方法を提供することを目的とする。

構成管理装置は、システムを構成するリソースを示す情報である構成アイテムと、前記構成アイテムを定義する属性情報とを有するデータに基づき、前記リソースに関する情報を管理する構成管理装置であって、属性情報と、該属性情報の登録、更新、および削除のうちいずれの処理を行うかの処理情報とを少なくとも含んだ処理依頼を取得する処理依頼取得部と、前記処理依頼取得部によって処理依頼が取得された場合、該処理依頼がいずれの構成アイテムに対する処理依頼かを判定し、構成アイテムと処理依頼とを対応付ける対応付け部と、前記処理依頼取得部によって処理依頼が取得されたタイミングとは別のタイミングで、対応付け部による対応付けに基づき、前記構成アイテムに対し前記処理依頼内の処理情報の処理をすることで、前記処理依頼内の属性情報を前記構成アイテムに反映する属性情報反映部と、を備えることを特徴とする。

また、構成管理プログラムは、システムを構成するリソースを示す情報である構成アイテムと、前記構成アイテムを定義する属性情報とを有するデータに基づき、前記リソースに関する情報の登録、更新、削除、検索をコンピュータに実行させる構成管理プログラムであって、属性情報と、該属性情報の登録、更新、および削除のうちいずれの処理を行うかの処理情報とを少なくとも含んだ処理依頼を取得する処理依頼取得ステップと、前記処理依頼取得ステップによって処理依頼が取得された場合、該処理依頼がいずれの構成アイテムに対する処理依頼かを判定し、構成アイテムと処理依頼とを対応付ける対応付けステップと、前記処理依頼取得ステップによって処理依頼が取得されたタイミングとは別のタイミングで、対応付けステップによる対応付けに基づき、前記構成アイテムに対し前記処理依頼内の処理情報の処理をすることで、前記処理依頼内の属性情報を前記構成アイテムに反映する属性情報反映ステップと、をコンピュータに実行させることを特徴とする。

さらに、構成管理方法は、システムを構成するリソースを示す情報である構成アイテムと、前記構成アイテムを定義する属性情報とを有するデータに基づき、前記リソースに関する情報の登録、更新、削除、検索を実行する構成管理方法であって、属性情報と、該属性情報の登録、更新、および削除のうちいずれの処理を行うかの処理情報とを少なくとも含んだ処理依頼を取得する処理依頼取得ステップと、前記処理依頼取得ステップによって処理依頼が取得された場合、該処理依頼がいずれの構成アイテムに対する処理依頼かを判定し、構成アイテムと処理依頼とを対応付ける対応付けステップと、前記処理依頼取得ステップによって処理依頼が取得されたタイミングとは別のタイミングで、対応付けステップによる対応付けに基づき、前記構成アイテムに対し前記処理依頼内の処理情報の処理をすることで、前記処理依頼内の属性情報を前記構成アイテムに反映する属性情報反映ステップと、を実行することを特徴とする。

本実施の形態に係るＦＣＭＤＢシステムの構成の一例を示す図である。 本実施の形態に係る、遅延処理の概要の一例を説明する図である。 ＦＣＭＤＢシステムがクライアント端末からの処理依頼を取得する処理の一例を示すフローチャートである。 処理実行部の処理の一例について示すフローチャートである。 優先度決定情報テーブルの一例および処理実行部の処理概要の一例を示す図である。 計算実行部の処理の一例について示すフローチャートである。 計算実行部の処理概要の一例を示す図（全体概要）である。 計算実行部の処理概要の一例を示す図（計算実行前）である。 計算実行部の処理概要の一例を示す図（計算実行後）である。 遅延計算判断部の処理の一例について示すフローチャートである。 遅延計算計画部の処理の一例について示すフローチャートである。 遅延計算判断部、遅延計算計画部による遅延処理の一例について示す図である。 ＦＣＭＤＢシステムの概要を示す図である。

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

図１に、本実施の形態におけるＦＣＭＤＢシステムを示す。ＦＣＭＤＢシステム１００は、操作実行部１、データ管理部２、処理実行部３、遅延計算判断部４、計算実行部５、遅延計算計画部６を備える。また、ＦＣＭＤＢシステム１００は、計算済情報ＤＢ１１、履歴情報テーブル１２、優先度決定情報テーブル１３、未計算情報ＤＢ１４、Ｅｎｔｉｔｙ管理情報テーブル１５を備える。

操作実行部１およびデータ管理部２によって、従来のＦＣＭＤＢシステムが実現される。操作実行部１は、ユーザが使用する端末であるクライアント端末２００からの登録、削除、更新、検索の処理依頼を取得し、データ管理部２に対しＦＣＭＤＢ情報のアクセス指示を行う。データ管理部２は、計算済情報ＤＢ１１（ＦＣＭＤＢ情報）に対する読み書きを行う。

本実施の形態の操作実行部１は、更に、クライアント端末２００から検索、登録、削除、更新のいずれの処理を実行するかを示す処理種別、および処理の具体的内容（検索する際の条件式や実データ等）を示す情報で構成された処理依頼以外に、当該処理依頼がいつまでに完了していればよいかの終了希望時間を取得し、処理実行部３へ取得した処理種別、情報、終了希望時間を処理依頼として送信する。尚、早急に計算する必要がある処理依頼の場合は終了希望時間に０が指定される。

処理実行部３は、操作実行部１からの処理依頼を取得する。処理実行部３は、処理依頼が検索、登録、削除、更新のいずれの処理種別であるかに基づき、遅延計算判断部４、計算実行部５へ処理実行を依頼する。また、処理実行部３は、遅延計算判断部４、計算実行部５の実行結果を取得する。さらに、処理実行部３は、処理依頼が遅延可能なものである場合に優先度決定情報テーブル１３に対し依頼に関する内容を登録する。

遅延計算判断部４は、処理依頼が登録、削除、更新である場合において、早急に該当するＣＩに対するプロパティの反映操作（以下、該当するＣＩに対するプロパティの反映操作を「計算」と称す）をする必要があるか否かをデータの更新頻度、ユーザからの終了希望時間等に基づき判断する。

計算実行部５は、処理実行部３が取得した処理依頼の処理種別に応じて、計算を行う。

遅延計算計画部６は、優先度決定情報テーブル１３に保持された依頼内容を取得し、遅延計算判断部４に遅延判断を依頼する。また、遅延計算計画部６は、遅延計算判断部４による遅延判断結果が遅延可能でないものである場合、計算実行部５に計算依頼をする。

従来からの構成管理用のＤＢである計算済情報ＤＢ１１は、プロパティまで計算済みであるＥｎｔｉｔｙ（以下、計算済情報）を保持する。履歴情報テーブル１２は、Ｅｎｔｉｔｙの履歴に関する情報が保持されている。履歴情報テーブル１２には、ＣＩやＲｅｌａｔｉｏｎｓｈｉｐを示すＥｎｔｉｔｙ種別と、Ｅｎｔｉｔｙに対する更新頻度の指標である平均更新頻度（例えば日単位、週単位で何回更新されたかを示す数値）と、Ｅｎｔｉｔｙとしてデータが保持されている期間の指標である平均存在時間等とが対応付けられている。

優先度決定情報テーブル１３は、処理依頼に関する内容として、処理依頼ごとに割り振られる識別子（ｉｄ）と、処理依頼の処理種別と、終了希望時間とが対応付けられたテーブルである。尚、優先度決定情報テーブル１３に保持されたデータは、処理実行部３によって書き込まれ、遅延計算計画部６によって使用される。

未計算情報ＤＢ１４は、ＣＩの対応付けまでは完了しているがプロパティの計算がなされていない情報（以下、未計算情報）が保持されている。Ｅｎｔｉｔｙ管理情報テーブル１５は、Ｅｎｔｉｔｙが計算済か未計算かを管理するためのテーブルである。

尚、上述の各テーブルおよびＤＢは、以降の説明で必要に応じさらに詳説する。

また、上述の各ユニットは、ＦＣＭＤＢシステム内に備えられたＣＰＵ３００（ＣＰＵ：Central Processing Unit）、記憶装置であるメモリ３０１等のハードウェア資源と、メモリ３０１に予め記憶されているプログラムとが協働することで実現される。また、上述の各テーブルおよび各ＤＢは、メモリ３０１の処理領域に保持されているものとする。

次に、計算済情報ＤＢ１１に保持されている計算済情報、および未計算情報ＤＢ１４に保持されている未計算情報の一例を図２の概念図に示し、ＦＣＭＤＢシステム１００の計算済情報、未計算情報を用いた処理の概要を説明する。

図２において、ＣＩとして「計算機−Ａ」、「ＨＤＤ−Ａ」、「ＨＤＤ−Ｂ」、「アプリ−Ａ」、「データ−Ａ」が計算済情報ＤＢ１１に保持されている。また、これらＣＩとＣＩの関連性（図２においてはＲｅｌＸ（Ｘは項目番号）として表示）が計算済情報として計算済情報ＤＢ１１に保持されている。また、計算済情報ＤＢ１１は、ＣＩの計算済みのプロパティも保持している。尚、図２において、例えば計算機−ＡのＣＩに関する計算済みプロパティは「ＯＳ：ＯＳ−Ｂ」、「ＨＤＤ：５００ＧＢ」であり、ＨＤＤ−ＡのＣＩに関する計算済みプロパティは「容量：５００ＧＢ」となる。

一方、未計算情報ＤＢ１４には、計算済情報ＤＢ１１に保持されているＣＩとの対応付けのみ成され、当該ＣＩに対する計算が成されていないプロパティ、および処理種別が保持されている。図２においては、例えば、ＣＩに関しては計算済情報ＤＢ１１に保持されている「計算機−Ａ」との対応付けがなされているが、「計算機−Ａ」に対する計算がなされていないプロパティとして「メモリ：２ＧＢ」、および処理種別として登録（追加）が未計算情報ＤＢ１４に保持されている。別の例として、「計算機−Ａ」のＣＩに対し、処理種別が削除、プロパティが「ＣＰＵ：ＣＰＵ−Ａ」の情報が未計算情報ＤＢ１４に保持されている。

本実施の形態のＦＣＭＤＢシステム１００は、ＣＩの対応付けをクライアント端末２００からの処理依頼が発生したときに行い、そのＣＩに関するプロパティは処理依頼が発生したときとは別のタイミング（たとえばユーザから指定された終了希望時間までに終了することができる時間）で計算を行うことで、計算処理を遅延させる。このように、ＦＣＭＤＢシステム１００は、従来のＦＣＭＤＢシステムのように処理依頼が発生したときにＣＩの対応付けおよびプロパティの計算処理を行う場合に比べ、見かけ上の処理時間を短縮する。

また、ＦＣＭＤＢシステム１００は、検索依頼がクライアント端末２００からあった場合、未計算のプロパティがあることによって生ずる不正確な検索結果をクライアント端末２００へ通知しないようにする必要がある。よって、ＦＣＭＤＢシステム１００は、処理依頼が検索である場合、検索処理の対象であるＣＩに係る未計算のプロパティを、検索処理依頼を取得したタイミングで反映する。

次に、ＦＣＭＤＢシステム１００の処理について説明する。

まず、図３に、ＦＣＭＤＢシステム１００がクライアント端末２００からの処理依頼を取得する処理を示す。操作実行部１は、処理依頼をクライアント端末２００から取得する（ステップＳ１）。尚、クライアント端末２００から取得する処理依頼は、検索、更新、登録、削除のいずれの処理を行うかを示す処理種別、検索する際の条件式や登録、更新、削除処理を行う際の実データ等の情報、およびいつまでに当該依頼処理が完了していればよいかを示す終了希望時間を有する。以降、必要に応じ処理種別を「処理種別ｏ」または単に「ｏ」と表記し、検索する際の条件式や登録、更新、削除処理を行う際の実データ等の情報を必要に応じ「情報ｄ」または単に「ｄ」と表記する。また終了希望時間を必要に応じ「終了希望時間ｔ」または単に「ｔ」と表記する。

その後、ＦＣＭＤＢシステム１００は上述の各ユニットを使用することで遅延計算処理を行う（ステップＳ２）。

次に、ステップＳ２における遅延計算処理の詳細について、各ユニットごとの処理に基づきさらに説明する。まず、処理実行部３の処理について図４のフローチャートを参照しつつ説明する。

処理実行部３は、操作実行部１からの依頼である処理依頼を取得し、処理種別ｏが検索であるか否かを判定する（ステップＳ１１）。処理種別ｏが検索である場合（ステップＳ１１、Ｙｅｓ）、計算実行部５に情報ｄでの検索を依頼し（ステップＳ１２）、処理実行部３の処理は終了する。

一方、処理種別が検索でなく、更新、登録、削除の処理である場合（ステップＳ１１、Ｎｏ）、処理実行部３は計算遅延判断部４に情報ｄ、終了希望時間ｔに基づく遅延判断を依頼する（ステップＳ１３）。計算遅延判断部４の判断結果が遅延可能である場合（ステップＳ１４、Ｙｅｓ）、処理実行部３は当該処理依頼の情報ｄに対する識別子（以下、識別子ｉｄ）を決定し（ステップＳ１６）、優先度決定情報テーブル１３に処理種別ｏ、識別子ｉｄ、終了希望時間ｔを登録する（ステップＳ１７）。また、処理実行部３は、未登録情報ＤＢ１４の所定領域に識別子ｉｄ、情報ｄを登録する（ステップＳ１８）。

その後、処理実行部３は、Ｅｎｔｉｔｙ管理情報テーブル１５（詳細は後述）を識別子ｉｄ、情報ｄで更新し（ステップＳ１９）、処理は終了する。

尚、計算遅延判断部４の判断結果が遅延可能でない場合（ステップＳ１４、Ｎｏ）、処理実行部３は、計算実行部５に処理種別ｏ、情報ｄを送信することで計算依頼をする（ステップＳ１５）。

尚、処理実行部３は、図４に示したフローチャートを実行する前（すなわち、ステップＳ１１の前）に、処理種別ｏ、情報ｄがいずれのＣＩに対するものかを判定し（判定処理は従来のＦＣＭＥＢシステムに含まれている機能（例えば操作実行部１の機能）を使用する）、ＣＩと処理依頼とを対応付けてもよい。

図５に、優先度決定情報テーブル１３の一例および処理実行部３の処理概要を示す。図４に示した処理実行部３の処理によって、ＦＣＭＤＢシステム１００は、処理依頼が更新、登録、削除である場合、早急に計算が必要な処理依頼に対しては即時プロパティに対し計算を行い、計算済情報ＤＢ１１に保持させる。一方、早急に計算をする必要がなく遅延させることが可能な処理依頼に対しては、ＦＣＭＤＢシステム１００は識別子ｉｄが付与された状態で未計算情報ＤＢ１４に保持させるとともに優先度決定情報テーブル１３に当該処理依頼の内容（処理種別ｏ、識別子ｉｄ、終了希望時間ｔ）を登録する。

次に、計算実行部５の処理について図６のフローチャートを参照しつつ説明する。尚、図６において、二重線で示した処理ステップはＥｎｔｉｔｙ間（ＣＩ間）の対応付け処理を示した処理ステップであり、破線にて示した処理ステップはプロパティの計算を行うことを示した処理ステップである。また、二点長鎖線にて示した処理ステップは、Ｅｎｔｉｔｙ間の対応付けおよび対応するプロパティの計算を行うことを示した処理ステップである。

計算実行部５は、まず、処理種別ｏ、情報ｄに基づき履歴情報テーブル１２に保持されている情報を更新する（ステップＳ２１）。例えば処理種別ｏが検索である場合、情報ｄに係るＥｎｔｉｔｙ種別の平均更新頻度が更新され、処理種別ｏが更新、登録、削除である場合、情報ｄに係るＥｎｔｉｔｙ種別の平均存在時間が更新される（尚、履歴情報テーブル１２の一例は図１２参照）。

次に、計算実行部５は、処理種別ｏに対する判定を行う。ここで、処理種別ｏが検索である場合（ステップＳ２２、Ｙｅｓ）、計算実行部５は、Ｅｎｔｉｔｙとのマッチングを行い、情報ｄ（この場合は条件式）にマッチするＥｎｔｉｔｙ集合を求める（ステップＳ２３）。

その後、計算実行部５は、ステップＳ２３の処理において、未計算情報として保持されているプロパティを計算したか否かの判定を行う（ステップＳ２４）。ここで、未計算情報として保持されているプロパティを計算した場合（ステップＳ２４、Ｙｅｓ）、計算実行部５は、計算したプロパティに関する情報を未計算情報ＤＢ１４から削除するとともに（ステップＳ２５）、計算したプロパティを計算済情報ＤＢ１１に追加する（ステップＳ２６）。計算実行部５は、これら削除処理（ステップＳ２５）、および追加処理（ステップＳ２６）によってなされた処理に基づきＥｎｔｉｔｙ管理情報を更新し（ステップＳ３３）、処理は終了する。

一方、未計算情報として保持されているプロパティに対する計算をしたか否かの判定において、計算しなかった場合（ステップＳ２４、Ｎｏ）、処理は終了する。

ステップＳ２２の判定処理に説明を戻す。処理種別ｏが検索でない場合（ステップＳ２２、Ｎｏ）、計算実行部５は、処理種別ｏが登録または更新であるか否かを判定する（ステップＳ２７）。ここで、処理種別ｏが登録または更新である場合（ステップＳ２７、Ｙｅｓ）、計算実行部５は、Ｅｎｔｉｔｙ間の対応付けを行い、情報ｄに対応するＥｎｔｉｔｙ集合Ｅを求める（ステップＳ２８）。

計算実行部５は、Ｅｎｔｉｔｙ集合Ｅに含まれているＥｎｔｉｔｙについて、情報ｄで登録または更新する（ステップＳ２９）。

その後、計算実行部５は、ステップＳ２９の処理において、未計算情報として保持されているプロパティを計算したか否かの判定を行う（ステップＳ３０）。ここで、未計算情報として保持されているプロパティを計算した場合（ステップＳ３０、Ｙｅｓ）、計算実行部５は、計算したプロパティに関する情報を未計算情報ＤＢ１４から削除するとともに（ステップＳ３１）、計算したプロパティを計算済情報ＤＢ１１に追加する（ステップＳ３２）。計算実行部５は、これら削除処理（ステップＳ３１）、および追加処理（ステップＳ３２）によってなされた処理に基づきＥｎｔｉｔｙ管理情報を更新し（ステップＳ３３）、処理は終了する。

一方、未計算情報として保持されているプロパティに対する計算をしたか否かの判定において、計算しなかった場合（ステップＳ３０、Ｎｏ）、処理は終了する。

ステップＳ２７の判定処理に説明を戻す。処理種別ｏが登録または更新でない場合（ステップＳ２７、Ｎｏ）、計算実行部５は、処理種別ｏは削除処理であるとみなす。計算実行部５は、Ｅｎｔｉｔｙ間の対応付けを行い、情報ｄに対応するＥｎｔｉｔｙ集合Ｅを求める（ステップＳ３４）。計算実行部５は、Ｅｎｔｉｔｙ集合Ｅに含まれるＥｎｔｉｔｙを削除する（ステップＳ３５）。

その後、計算実行部５は、ステップＳ３５の処理において未計算情報を計算したかの判定を行う（ステップＳ３６）。ここで、未計算情報を計算した場合（ステップＳ３６、Ｙｅｓ）、計算実行部５は、計算した情報を未計算情報ＤＢ１４から削除する（ステップＳ３７）。計算実行部５は、削除処理（ステップＳ３７）によってなされた処理に基づきＥｎｔｉｔｙ管理情報を更新し（ステップＳ３３）、処理は終了する。

一方、未計算情報を計算をしたか否かの判定において、計算しなかった場合（ステップＳ３６、Ｎｏ）、処理は終了する。

上述の計算実行部５の処理概要を図７から図９に示す。

図７に全体概要を示す。ＦＣＭＤＢシステム１００は、Ｅｎｔｉｔｙ管理情報テーブル１５を保持している。Ｅｎｔｉｔｙ管理情報テーブル１５は、Ｅｎｔｉｔｙ管理情報としてＥｎｔｉｔｙ（Ｅｎｔｉｔｙを識別するための属性名と属性値）ごとに、計算済みのＥｎｔｉｔｙに対応した識別情報であるグループＩＤ（ＧＩＤ）（図９では「計算済ＥｎｔｉｔｙのＧＩＤ」と表記）、識別子ｉｄ（図９では「未計算ＥｎｔｉｔｙのＩＤ」と表記）を保持している。例えば図７において、Ｅｎｔｉｔｙの属性名として「計算機−Ａ」のＥｎｔｉｔｙに対し、ＧＩＤとしてＧＩＤ１が割り与えられており、さらに、計算機−ＡのＥｎｔｉｔｙに対応付けられた未計算情報として、ＩＤ１（処理種別ｏが登録、情報ｄが「メモリ：２ＧＢ」）、ＩＤ３（処理種別ｏが削除、情報ｄが「ＯＳ：ＯＳ−Ｂ」）が対応付けられている。

同様に、ＨＤＤ−ＡのＥｎｔｉｔｙに対してはＧＩＤ２が割り与えられているが、ＨＤＤ−ＡのＥｎｔｉｔｙに対する未計算情報は無いため識別子ｉｄは対応付けられていない。また、Ｒｅｌ５のＥｎｔｉｔｙに対しては、未だ登録されておらず、計算済情報でないためＧＩＤは割り与えられていない。またＲｅｌ５のＥｎｔｉｔｙは、未計算情報としての識別子ｉｄ（ＩＤ５）が対応付けられている。

図８に計算実行部５の計算処理前の状態の一例を示す。図８に示すように、例えばクライアント端末２００からの処理依頼の結果、ＧＩＤ１（すなわち、計算機−Ａ）に関する情報を計算する必要がある場合、計算実行部５は、Ｅｎｔｉｔｙ管理情報テーブル１５を参照することで、ＧＩＤ１に係る未計算情報としてＩＤ１、ＩＤ３を計算する必要があると判断する。

計算実行部５は、これらＩＤ１、ＩＤ３を計算済情報にマージ（計算）することで、計算済情報であるＧＩＤ１の「計算機−Ａ」が更新される。例えば、図８の「計算機−Ａ」のプロパティが「ＯＳ：ＯＳ−Ｂ」、「ＨＤＤ：５００ＧＢ」であったのに対し、計算処理後の図９では、「計算機−Ａ」のプロパティはＩＤ１の計算およびＩＤ３の計算が成されることで、「ＨＤＤ：５００ＧＢ」、「メモリ：２ＧＢ」に更新される。また、計算されたＩＤ１、ＩＤ３は未計算情報から削除される。その後、計算実行部５は、Ｅｎｔｉｔｙ管理情報テーブル１５内の識別子ｉｄ（未計算ＥｎｔｉｔｙのＩＤ）の値を削除する。

次に、遅延計算判断部４の処理について、図１０のフローチャートを参照しつつ説明する。

遅延計算判断部４は、処理実行部３、または遅延計算計画部６からの判断依頼を取得した場合、情報ｄに係るＥｎｔｉｔｙ種別を特定し、履歴情報テーブル１２に保持されているＥｎｔｉｔｙ種別の履歴情報を調べる（ステップＳ４１）。

次に、遅延計算判断部４は、終了希望時間ｔが０であるかの判断（ステップＳ４２）、現在時間と計算処理するために必要な時間とを共に加算した時間が終了希望時間ｔ以上であるかの判断（ステップＳ４３）を行う。また、遅延計算判断部４は、当該Ｅｎｔｉｔｙ種別の平均更新頻度が所定基準を上回っているかを判断することで、当該Ｅｎｔｉｔｙ種別が頻繁に更新されているかを判断する（ステップＳ４４）。また遅延計算判断部４は、当該Ｅｎｔｉｔｙ種別の平均存在時間が所定基準を上回っているかを判断することで、長時間存在しているか否かの判断を行う（ステップＳ４５）。

さらに、遅延計算判断部４は、記憶領域の容量不足を未然に防止するための処理として、未計算情報が保持されているメモリ領域の中で、情報ｄに含まれるプロパティのデータサイズが占める領域が大きいかの判断を行う（ステップＳ４６）。例えば、遅延計算判断部４は、情報ｄに含まれるプロパティのデータサイズと未計算情報ＤＢ１２が保持可能な記憶容量との割合が、所定値よりも大きいか否かを判定する。

これらステップＳ４２からステップＳ４６までの判断のいずれかに合致する場合、遅延計算判断部４は、当該計算依頼は早急に計算処理すべきもの（遅延不可）と判断する。（ステップＳ４７）、一方、ステップＳ４２からステップＳ４６までの判断に合致しない場合、遅延計算判断部４は計算しない（遅延可能）と判断する（ステップＳ４８）。

次に、遅延計算計画部６の処理について、図１１のフローチャートを参照しつつ説明する。

遅延計算計画部６は、優先度決定情報テーブル１３から全ての情報（情報Ｔとする）を取得する（ステップＳ５１）。ここで、情報Ｔが空である場合（ステップＳ５２、Ｙｅｓ）、処理は「計画依頼ＳＴＡＲＴ」に戻り、ステップ５１の処理が再度繰り返し行われる（ステップＳ５８）。

情報Ｔが空でない場合（ステップＳ５２、Ｎｏ）、遅延計算計画部６は、情報Ｔから処理種別ｏ、識別子ｉｄ、終了希望時間ｔを取り出し（ステップＳ５３）、未計算情報ＤＢ１４から識別子ｉｄに対応する情報ｄを取り出す（ステップＳ５４）。

次に、遅延計算計画部６は、遅延計算判断部４に処理種別ｏ、情報ｄ、終了希望時間ｔによる遅延判断を依頼する（ステップＳ５５）。ここで、遅延計算判断部４から遅延可能との判断結果を取得した場合（ステップＳ５６、Ｙｅｓ）、何もせず処理は「計画依頼ＳＴＡＲＴ」に戻り（ステップＳ５８）、再度ステップＳ５１の処理が繰り返しなされる。一方、遅延計算判断部４から遅延不可との判断結果を取得した場合（ステップＳ５６、Ｎｏ）、遅延計算計画部６は計算実行部５に計算を依頼し（ステップＳ５７）、処理は「計画依頼ＳＴＡＲＴ」に戻る（ステップＳ５８）。

図１２に、優先度決定情報テーブル１３、履歴情報テーブル１２に保持されている情報の一例を示しつつ、遅延計算判断部４、遅延計算計画部６による遅延処理について説明する。

優先度決定情報テーブル１３は、処理種別ｏ、識別子ｉｄ、終了希望時間ｔの各値を保持したテーブルであり、履歴情報テーブル１２はＥｎｔｉｔｙ種別、平均更新頻度、平均存在時間の各値を保持したテーブルである。遅延計算判断部４は、履歴情報テーブル１２に保持された値を参照し、また優先度決定情報テーブル１３に保持されている終了希望時間を遅延計算計画部６を介して間接的に参照することで、図１０に示したフローチャートの処理を行う。また遅延計算計画部６は、優先度決定情報テーブル１３に保持されている情報および遅延計算判断部４による判断結果に基づき、計算実行部５に計算依頼をするか否かを判断する。

図１２の例では、遅延計算計画部６は優先度決定情報テーブル１３に保持されている終了希望時間によりＩＤ３の処理が最も早く、優先的に実施されるものであると判断する。よって遅延計算計画部６は、ＩＤ３の処理をＩＤ１、ＩＤ２の処理よりも優先的に実施し、プロパティ「ＯＳ：ＯＳ−Ｂ」の削除を行う。

また、構成管理装置を構成するコンピュータにおいて上述した各ステップを実行させるプログラムを、構成管理プログラムとして提供することができる。上述したプログラムは、コンピュータにより読取り可能な記録媒体に記憶させることによって、構成管理装置を構成するコンピュータに実行させることが可能となる。ここで、上記コンピュータにより読取り可能な記録媒体としては、ＲＯＭやＲＡＭ等のコンピュータに内部実装される内部記憶装置、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。

なお、処理依頼取得部は、本実施の形態における操作実行部１に対応し、対応付け部は、本実施の形態における処理実行部３に対応する。また、属性情報反映部は、本実施の形態における遅延計算判断部４、計算実行部５、遅延計算計画部６に対応する。

構成アイテムに対する属性情報の反映を、処理依頼を取得したタイミングとは別のタイミングですることで、ユーザに対する見かけ上の処理時間を短縮することができる。

Claims (7)

1. システムを構成するリソースを示す情報である構成アイテムと、前記構成アイテムを定義する属性情報とを有するデータに基づき、前記リソースに関する情報を管理する構成管理装置であって、
   属性情報と、該属性情報の登録、更新、および削除のうちいずれの処理を行うかの処理情報とを少なくとも含んだ処理依頼と、前記処理情報として前記リソースに関する情報の検索処理依頼とを取得する処理依頼取得部と、
   前記処理依頼取得部によって処理依頼が取得された場合、該処理依頼がいずれの構成アイテムに対する処理依頼かを判定し、構成アイテムと処理依頼とを対応付ける対応付け部と、
   前記処理依頼取得部によって処理依頼が取得されたタイミングとは別のタイミングで、対応付け部による対応付けに基づき、前記構成アイテムに対し前記処理依頼内の処理情報の処理をすることで、前記処理依頼内の属性情報を前記構成アイテムに反映する属性情報反映部とを備え、
   前記属性情報反映部は、前記処理依頼取得部が検索処理依頼を取得したときに、前記検索処理依頼の対象である構成アイテムに係る属性情報のうち、未反映の属性情報がある場合、対応付け部による対応付けに基づき該未反映の属性情報を反映し、反映した前記構成アイテムに対して前記検索処理を実行することを特徴とする構成管理装置。
2. 請求項１に記載の構成管理装置において、
   前記処理依頼取得部は、更に、取得した処理依頼がいつまでに完了すればよいかの終了希望時間を取得し、
   前記属性情報反映部は、前記終了希望時間までに前記処理依頼内の属性情報を前記構成アイテムに反映することを特徴とする構成管理装置。
3. 請求項１に記載の構成管理装置において、
   前記属性情報反映部は、更に、前記処理依頼内の属性情報に係る構成アイテムの更新頻度に基づき、前記処理依頼内の属性情報を前記構成アイテムに反映するか否かを判断することを特徴とする構成管理装置。
4. 請求項１に記載の構成管理装置において、
   更に、少なくとも前記構成アイテムおよび前記属性情報を保持する保持部を備え、
   前記属性情報反映部は、更に、前記処理依頼内の属性情報に係る構成アイテムが前記保持部に保持されている期間に基づき、前記処理依頼内の属性情報を前記構成アイテムに反映するか否かを判断することを特徴とする構成管理装置。
5. 請求項１に記載の構成管理装置において、
   更に、少なくとも前記構成アイテムおよび前記属性情報を保持する保持部を備え、
   前記属性情報反映部は、更に、前記処理依頼内の属性情報のデータサイズに基づき、前記処理依頼内の属性情報を前記構成アイテムに反映するか否かを判断することを特徴とする構成管理装置。
6. システムを構成するリソースを示す情報である構成アイテムと、前記構成アイテムを定義する属性情報とを有するデータに基づき、前記リソースに関する情報の登録、更新、削除、検索をコンピュータに実行させる構成管理プログラムであって、
   属性情報と、該属性情報の登録、更新、および削除のうちいずれの処理を行うかの処理情報とを少なくとも含んだ処理依頼と、前記処理情報として前記リソースに関する情報の検索処理依頼とを取得する処理依頼取得ステップと、
   前記処理依頼取得ステップによって処理依頼が取得された場合、該処理依頼がいずれの構成アイテムに対する処理依頼かを判定し、構成アイテムと処理依頼とを対応付ける対応付けステップと、
   前記処理依頼取得ステップによって処理依頼が取得されたタイミングとは別のタイミングで、対応付けステップによる対応付けに基づき、前記構成アイテムに対し前記処理依頼内の処理情報の処理をすることで、前記処理依頼内の属性情報を前記構成アイテムに反映する属性情報反映ステップとをコンピュータに実行させ、
   前記属性情報反映ステップは、前記処理依頼取得ステップが検索処理依頼を取得したときに、前記検索処理依頼の対象である構成アイテムに係る属性情報のうち、未反映の属性情報がある場合、対応付けステップによる対応付けに基づき該未反映の属性情報を反映し、反映した前記構成アイテムに対して前記検索処理をコンピュータに実行させることを特徴とする構成管理プログラム。
7. システムを構成するリソースを示す情報である構成アイテムと、前記構成アイテムを定義する属性情報とを有するデータに基づき、前記リソースに関する情報の登録、更新、削除、検索を実行する構成管理方法であって、
   属性情報と、該属性情報の登録、更新、および削除のうちいずれの処理を行うかの処理情報とを少なくとも含んだ処理依頼と、前記処理情報として前記リソースに関する情報の検索処理依頼とを取得する処理依頼取得ステップと、
   前記処理依頼取得ステップによって処理依頼が取得された場合、該処理依頼がいずれの構成アイテムに対する処理依頼かを判定し、構成アイテムと処理依頼とを対応付ける対応付けステップと、
   前記処理依頼取得ステップによって処理依頼が取得されたタイミングとは別のタイミングで、対応付けステップによる対応付けに基づき、前記構成アイテムに対し前記処理依頼内の処理情報の処理をすることで、前記処理依頼内の属性情報を前記構成アイテムに反映する属性情報反映ステップとを実行し、
   前記属性情報反映ステップは、前記処理依頼取得ステップが検索処理依頼を取得したときに、前記検索処理依頼の対象である構成アイテムに係る属性情報のうち、未反映の属性情報がある場合、対応付けステップによる対応付けに基づき該未反映の属性情報を反映し、反映した前記構成アイテムに対して前記検索処理を実行することを特徴とする構成管理方法。

Images