(57)【特許請求の範囲】
【請求項１】
機能モジュールＩＤと前記機能モジュールが属するグループのＩＤ（識別子）を示す関連情報とを関連付けた機能情報と、第１のシステムと当該第１のシステムを構成する複数の第２のシステムと当該第２のシステムの各々が依存する前記機能モジュールＩＤとを関連付けた構成情報と、を記憶する記憶手段を参照して、特定の機能モジュールＩＤを基に、前記特定の機能モジュールＩＤと関連付けられた前記関連情報を出力する機能管理手段と、
前記構成情報に含まれる前記第１のシステムを構成する複数の第２のシステムの各々が依存する前記機能モジュールＩＤの各々を前記機能管理手段に入力し、前記機能管理手段から、当該各々の機能モジュールＩＤに関連する前記関連情報を各々取得し、異なる前記機能モジュールＩＤに同一の前記関連情報が関連付けられているか否かを判定して、当該判定結果を出力する検証手段と、
を備える検証装置。
【請求項２】
前記記憶手段は、前記関連情報と他の関連情報とをさらに関連付けた前記機能情報を記憶し、
前記機能管理手段は、前記特定の機能モジュールＩＤと関連付けされた前記関連情報が前記他の関連情報と関連付けされている場合には、当該他の関連情報をさらに取得する請求項１に記載の検証装置。
【請求項３】
前記記憶手段は、複数の重要度のいずれかが付加された複数の前記関連情報を記憶し、
前記機能管理手段は、前記複数の重要度のいずれかが付加された前記機能モジュールＩＤを取得して、当該重要度と同一の重要度が付加された前記関連情報を前記記憶手段から抽出して出力する請求項１乃至２のいずれかに記載の検証装置。
【請求項４】
前記記憶手段を自装置に備える請求項１乃至３のいずれかに記載の検証装置。
【請求項５】
前記関連情報と、代替機能モジュールＩＤとをさらに関連付けて記憶する前記記憶手段と、
外部から前記関連情報を含む代替機能モジュール要求情報を取得し、取得した当該関連情報に関連する前記代替機能モジュールＩＤを前記記憶手段から取得する代替機能性提案手段と、
当該代替機能モジュールＩＤを出力する前記検証手段と、
を備える請求項１乃至４のいずれかに記載の検証装置。
【請求項６】
機能モジュールＩＤと前記機能モジュールが属するグループのＩＤを示す関連情報とを関連付けた機能情報と、第１のシステムと当該第１のシステムを構成する複数の第２のシステムと当該第２のシステムの各々が依存する前記機能モジュールＩＤとを関連付けた構成情報と、を記憶する記憶手段を参照可能なコンピュータに、
特定の機能モジュールＩＤを基に、前記記憶手段を参照して、前記特定の機能モジュールＩＤの各々と関連付けられた前記関連情報を各々出力する機能管理処理と、
異なる前記機能モジュールＩＤに同一の前記関連情報が関連付けられているか否かを判定して、当該判定結果を出力する検証処理と、
を実行させる検証プログラム。
【請求項７】
前記記憶手段は、前記関連情報と他の関連情報とをさらに関連付けた前記機能情報を記憶し、
前記特定の機能モジュールＩＤと関連付けされた前記関連情報が前記他の関連情報と関連付けされている場合には、当該他の関連情報をさらに取得する前記機能管理処理を、前記コンピュータに実行させる請求項６に記載の検証プログラム。
【請求項８】
前記記憶手段は、複数の重要度のいずれかが付加された複数の前記関連情報を記憶し、
前記複数の重要度のいずれかが付加された前記機能モジュールＩＤを取得して、当該重要度と同一の重要度が付加された前記関連情報を前記記憶手段から抽出して出力する前記機能管理処理を、前記コンピュータに実行させる請求項６乃至７のいずれかに記載の検証プログラム。
【請求項９】
機能モジュールＩＤと前記機能モジュールが属するグループのＩＤを示す関連情報とを関連付けた機能情報と、第１のシステムと当該第１のシステムを構成する複数の第２のシステムと当該第２のシステムの各々が依存する前記機能モジュールＩＤとを関連付けた構成情報と、を記憶する記憶手段を参照して、特定の機能モジュールＩＤを基に、前記特定の機能モジュールＩＤの各々と関連付けられた前記関連情報を各々出力し、
異なる前記機能モジュールＩＤに同一の前記関連情報が関連付けられているか否かを判定して、当該判定結果を出力する検証方法。
【請求項１０】
前記記憶手段は、前記関連情報と他の関連情報とをさらに関連付けた前記機能情報を記憶し、
前記特定の機能モジュールＩＤと関連付けされた前記関連情報が前記他の関連情報と関連付けされている場合には、当該他の関連情報をさらに取得する請求項９に記載の検証方法。
【請求項１１】
前記記憶手段は、複数の重要度のいずれかが付加された複数の前記関連情報を記憶し、
前記複数の重要度のいずれかが付加された前記機能モジュールＩＤを取得して、当該重要度と同一の重要度が付加された前記関連情報を前記記憶手段から抽出して出力する請求項９乃至１０のいずれかに記載の検証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は検証装置、検証方法、及び、コンピュータプログラムに関する。
【背景技術】
【０００２】
複数のコンポーネントから構成される大規模なシステムを効率的に開発するには、各コンポーネントが要求する他の機能モジュールに対する依存性の適切な管理が重要である。【０００３】
例えば、複数のコンポーネントのそれぞれが同一の機能モジュールの異なるバージョンに依存したまま開発が進められたとする。この場合、ある段階において当該コンポーネント同士が連携する部分が開発され始めた場合、当該連携部分に同一モジュールの異なるバージョンが混在するために名前空間が衝突するなどの不具合が発生するおそれがある。【０００４】
或いは、各コンポーネントについて、異なるリレーショナル・データベースの存在を前提としたデータベース接続モジュールが用いられて開発が進められた場合、システム全体としては複数のデータベースに依存することとなってしまうおそれがある。【０００５】
データの連携性やリソースの利用効率の観点から、データベースは集約する方が有利である。そのため、前述のようなケースは、いずれかのコンポーネントが修正を求められる可能性が高い。【０００６】
とりわけ各コンポーネントの開発者が異なる場合には、コミュニケーション不足からこうした機能モジュールの重複が発生し易い。【０００７】
また、修正はいずれか一方のコンポーネントのみに行われることとなるため、不公平感が大きく、問題が深刻化する場合もある。【０００８】
この様に、同一システム内に異なるデータベース管理製品が存在するというコンポーネント間において発生する依存性の競合は、可能な限り早期に解消し、集約すべきである。しかし、異なる複数のチームが開発する多数のコンポーネントについて、コンポーネント相互の依存性の変化を監視することにより競合を解消する作業を、開発中に継続的に実施することは困難である。そこで、こうした一連の作業の自動化が必要となる。【０００９】
特許文献１と特許文献２には、システムとそのコンポーネントのそれぞれが持つ要件間の整合性を自動的に検証する装置の一例が記載されている。【００１０】
これらの特許文献に記載された装置は、検証する要件および検証に必要なデータをシステムや各コンポーネントに予め設定しておく。そして、上述の装置は、コンポーネントをシステムに組み込む際に前記データに基づく要件の検証を実施する。上述の装置は、前記データに基づく要件がシステム側の要件に合致しないコンポーネントであると判断した場合、組み込みを避けることによりシステムの適切な動作を維持することを目的としている。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００４−３２６３６６号公報
【特許文献２】特開２００８−１７１３１８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかしながら、これらの特許文献において紹介されている要件の検証に必要なデータは、対象システムやそのコンポーネントの詳細なモデル記述であり、その準備にかかる作業工数は少なくない。例えば、多数存在する機能モジュールのそれぞれについて、コンポーネントが要求すべきでない依存性を設定するなどの作業は困難であり、各コンポーネント間の依存性の整合を容易に検証できないという課題があった。【００１３】
本発明は、上記課題を鑑み、各コンポーネント間の依存性の競合の有無を容易に検証可能とする検証装置などを提供することを１つの目的とする。
【課題を解決するための手段】
【００１４】
かかる目的を達成するため、本発明の一形態は、検証装置であって、機能モジュールＩＤと前記機能モジュールが属するグループのＩＤ（識別子）を示す関連情報とを関連付けた機能情報と、第１のシステムと当該第１のシステムを構成する複数の第２のシステムと当該第２のシステムの各々が依存する前記機能モジュールＩＤとを関連付けた構成情報と、を記憶する記憶手段を参照して、特定の機能モジュールＩＤを基に、前記特定の機能モジュールＩＤと関連付けられた前記関連情報を出力する機能管理手段と、前記構成情報に含まれる前記第１のシステムを構成する複数の第２のシステムの各々が依存する前記機能モジュールＩＤの各々を前記機能管理手段に入力し、前記機能管理手段から、当該各々の機能モジュールＩＤに関連する前記関連情報を各々取得し、異なる前記機能モジュールＩＤに同一の前記関連情報が関連付けられているか否かを判定して、当該判定結果を出力する検証手段と、を備える。【００１５】
また、本発明の他の形態は、機能モジュールＩＤと前記機能モジュールが属するグループのＩＤを示す関連情報とを関連付けた機能情報と、第１のシステムと当該第１のシステムを構成する複数の第２のシステムと当該第２のシステムの各々が依存する前記機能モジュールＩＤとを関連付けた構成情報と、を記憶する記憶手段を参照可能なコンピュータに、特定の機能モジュールＩＤを基に、前記記憶手段を参照して、前記特定の機能モジュールＩＤの各々と関連付けられた前記関連情報を各々出力する機能管理処理と、異なる前記機能モジュールＩＤに同一の前記関連情報が関連付けられているか否かを判定して、当該判定結果を出力する検証処理と、を実行させる検証プログラムを提供する。【００１６】
また、本発明の他の形態は、機能モジュールＩＤと前記機能モジュールが属するグループのＩＤを示す関連情報とを関連付けた機能情報と、第１のシステムと当該第１のシステムを構成する複数の第２のシステムと当該第２のシステムの各々が依存する前記機能モジュールＩＤとを関連付けた構成情報と、を記憶する記憶手段を参照して、特定の機能モジュールＩＤを基に、前記特定の機能モジュールＩＤの各々と関連付けられた前記関連情報を各々出力し、異なる前記機能モジュールＩＤに同一の前記関連情報が関連付けられているか否かを判定して、当該判定結果を出力する検証方法を提供する。
【発明の効果】
【００１７】
本発明は、各コンポーネント間の依存性の競合の有無を容易に検証可能とする。
【図面の簡単な説明】
【００１８】
【図１】本発明を実施する第１の実施の形態に係る検証装置１００の構成の一例である。
【図２】第１の実施の形態に係る構成管理部１０３が管理する構成情報の一例である。
【図３】第１の実施の形態に係る構成情報変更要求の一例である。
【図４】第１の実施形態に係る構成情報取得要求の一例である。
【図５】第１の実施の形態に係る機能管理部１０４が管理する機能情報の一例である。
【図６】第１の実施形態に係る機能情報取得要求の一例である。
【図７】第１の実施形態に係る検証要求の一例である。
【図８】第１の実施の形態に係る構成管理部１０３への要件定義処理の動作の一例である。
【図９】第１の実施の形態に係る検証部１０１の検証処理の動作の一例である。
【図１０】第１の実施の形態に係る依存性記憶部１０２が記録する情報の一例である。
【図１１】第２の実施の形態に係る機能管理部１０４が管理する機能情報の一例である。
【図１２】第２の実施の形態に係る検証要求の一例である。
【図１３】第２の実施の形態に係る依存性記憶部１０２が記録する情報の一例である。
【図１４】第３の実施の形態に係る検証装置３００の構成の一例である。
【図１５】第３の実施の形態に係る依存性提案要求の一例である。
【図１６】第３の実施の形態に係る代替機能性提案部３０１が管理する推奨依存性情報の一例である。
【図１７】第３の実施の形態に係る検証部１０１の検証処理の動作の一例である。
【図１８】第４の実施の形態に係る検証装置４００の構成の一例である。
【図１９】第１の実施の形態に係る検証装置１００を実現可能な情報処理装置（コンピュータ）のハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態について、図面を用いて説明する。すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。
【００２０】
なお、各実施形態に係る装置等を構成する各部は、論理回路等のハードウェアによって構成される。図１９は、後述する本発明の第１の実施の形態に係る検証装置１００を実現可能な情報処理装置（コンピュータ）のハードウェア構成例を示す図である。図１９に示すように、検証装置１００は、ＣＰＵ（Central Processing Unit）１０、メモリ１２、ＨＤＤ（ハードディスクドライブ）１４、図示しないネットワークを介して通信を行う通信ＩＦ（インタフェース）１６、及びＣＤ等の記憶媒体２０に記憶された情報を読み取り可能なリーダーライター１８を有する。これらの構成要素は、バス２２を通して互いに接続されており、互いにデータの入出力を行う。各部は、ハードウェアとソフトウェアの任意の組合せによって実現されてもよい。そして特に断りのない限り、その実現方法、装置は限定されない。
【００２１】
また、制御部は、ＣＰＵ１０などからなり、ＯＳ（Operating system）を動作させて装置等の全体を制御する。ＣＰＵ１０は、例えばメモリ１２またはＨＤＤ１４に記憶されているコンピュータプログラム（以下、「プログラム」と称する）やデータを読み出し、読み出したデータを基にプログラムを実行することにより、各種の処理を実現する。または、検証装置１００は、ＣＰＵ１０が記憶媒体２４に記憶されているプログラムを実行することにより実現されてもよい。記録媒体２４は、例えば光ディスク、フレキシブルディスク、磁気光ディスク、外付けハードディスク、半導体メモリ等であって、プログラムをコンピュータが読み取り可能に記録する。また、コンピュータプログラムは、通信ＩＦ１６或いはリーダーライター１８を介して、図示しない外部コンピュータからダウンロードされても良い。図１９に示す検証装置１００のハードウェア構成例は、後述する各実施形態にも適用可能である。尚、検証装置１００は、専用の装置であってもよい。
【００２２】
＝＝実施形態１＝＝
次に、本発明の第１の実施形態について図面を用いて説明する。
【００２３】
[構成の説明]
図１は、本発明を実施する第１の実施の形態に係る検証装置１００の構成例を示すブロック図である。図１は、図１９において例示したハードウェアを用いて実現される検証装置１００の機能（処理）単位に表現したブロック図である。但し、図１に示したブロック分けは、説明の便宜上から表された構成であり、本願の各実施形態を例に説明する本発明は、実装に際して係る構成には限定されない。
【００２４】
図１に示されるように、本発明を実施する第１の実施の形態に係る検証装置１００は、フロントエンド１０６、検証部１０１、依存性記憶部１０２、構成管理部１０３、機能管理部１０４、記憶装置１０５を備える。フロントエンド１０６は、利用者が情報の入出力に用いる外部の入出力装置１１０と、ネットワーク等により通信可能に接続される。本実施の形態において、記憶装置１０５は、一例として検証装置１００が備える構成として記載しているが、外部装置が備える構成でもよい。
【００２５】
構成管理部１０３は、システムやそのコンポーネントの構成情報を管理する。構成情報は、記憶装置１０５に格納されている。
【００２６】
図２は、本発明を実施する第１の実施の形態に係る構成管理部１０３が管理する構成情報の一例である。図２に示す例において、構成情報は、ＸＭＬ（Extensible Markup Language）形式により記述されている。システムの構成情報は、タグ"system"により記述される。そして、そのタグ"system"の"id"属性により当該システムのＩＤ（Identification）が定義される。
【００２７】
図２に示す例において、構成情報は、システムＡとシステムＢとシステムＣとの３つのシステムが定義されている。また、システムのコンポーネントは、当該システムを定義するタグ"system"の子要素にあたるタグ"component"により記述される。そして、そのタグ"component"の"name"属性により当該コンポーネントの実体に相当するシステムが定義される。
【００２８】
図２に示す例において、システムＡのコンポーネントは、システムＢおよびシステムＣであると定義されている。また、システムの依存性は、当該システムを定義するタグ"system"の子要素にあたるタグ"dependency"により記述される。そして、そのタグ"dependency"の"name"属性により当該依存性によって要求される機能モジュール或いは機能モジュールの属するグループ（後述の依存性グループ）のＩＤが定義される。
【００２９】
構成管理部１０３は、フロントエンド１０６を介して利用者から構成情報の変更要求を受付ける。そして、構成管理部１０３は、当該要求の内容に応じて構成情報を変更する。ここで構成情報の変更とはＦ、例えば特定のシステムについての追加、更新、削除等の操作である。図３は、第１の実施の形態に係る構成情報変更要求の一例である。変更要求には、図３に示すように、操作の種類と当該操作の対象に関する情報が含まれる。図３の例においては、構成変更要求の１行目に操作の種類が示され、２行目以降に１行目に示された操作の対象が示されている。
【００３０】
例えば、"create"は、システムの追加の操作を示す。そして、上記"create"に続く記述は、追加するシステムの構成情報を示している。"update"は、システムの更新の操作を示す。そして、上記"update"に続く記述は、更新対象のシステムと更新対象のシステムの構成情報を示している。"delete"は、システムの削除の操作を示す。そして、上記"delete"に続く記述は、削除対象のシステムのＩＤを示している。
【００３１】
また構成管理部１０３は、検証部１０１からの構成情報取得要求を受付け、当該要求において指定されたシステムと指定されたシステムのコンポーネントとに関する構成情報を返答する。
【００３２】
図４は、第１の実施形態に係る構成情報取得要求の一例である。ここで、構成情報取得要求は、例えば図４に示すように、構成情報取得要求であることを示す情報と、構成情報を取得したい対象のシステムを示す情報とを含む。
【００３３】
例えば、図４の１行目の"getcomp"は、当該要求が構成情報取得要求であることを示す。図４の２行目は、情報取得対象のシステムのＩＤを示している。
【００３４】
機能管理部１０４は、機能モジュールや機能モジュールの属するグループに関する情報である機能情報を管理する。機能情報は、記憶装置１０５に格納されている。
【００３５】
図５は、本実施の形態に係る機能管理部１０４が管理する機能情報の一例である。この例において、機能モジュールや機能モジュールの属するグループは、文字列のＩＤにより表現され、特定の機能モジュール群を丸括弧によって括り、丸括弧の左に当該機能モジュールが属するグループ（依存性グループ）を示すＩＤを記載している。
【００３６】
例えば、図５の１行目には機能モジュールＩＤとして"mysql_3.0"、"mysql_4.0"、"mysql_5.0"が示されており、その依存性グループＩＤとして"mysql"が示されている。同様に、図５の２行目には機能モジュールＩＤとして"oracle_10g"、"oracle_11g"が示されており、その依存性グループＩＤとして"oracle"が示されている。さらに３行目には機能モジュールＩＤとして"mysql"、"oracle"が示されており、その依存性グループＩＤとして"rdb"が示されている。この様に、機能情報において階層的にグループが構成されてもよい。
【００３７】
なお、依存性グループＩＤは、機能モジュールＩＤに関連付けられている関連情報ともいう。すなわち、図５の例において、"mysql"は、"mysql_3.0"、"mysql_4.0"、"mysql_5.0"に関連付けられた関連情報である。また、"oracle"は、"oracle_10g"、"oracle_11g"に関連付けられた関連情報である。さらに、"rdb"は、"mysql"、"oracle"に関連付けられた関連情報である。そして、上述のような階層的な依存性グループＩＤが存在することは、機能モジュールＩＤに関連付けられた第１の関連情報にさらに他の第２の関連情報が関連付けられていることと同じである。
【００３８】
異なる機能モジュールＩＤが同一の依存性グループＩＤに属する（或いは同一の関連情報に関連付けられている）ということは、それらの機能モジュールＩＤが当該依存性グループＩＤ（或いは関連情報）のレベルにおいて競合していることを意味する。例えば、"mysql_3.0"と"mysql_4.0"とは、同じ依存性グループＩＤ"mysql"に属する（同じ関連情報"mysql"が関連付けされている）。すなわち、このことは、"mysql_3.0"に依存するコンポーネントと"mysql_4.0"に依存するコンポーネントとが"mysql"というレベルにおいて競合することを意味する。
【００３９】
同様に、例えば、"mysql_3.0"と"oracle_11g"とは、それぞれ"mysql"と"oracle"に属する。そして、"mysql"と"oracle"とは、さらに"rdb"に属する（すなわち、"mysql_3.0"と"oracle_11g"とが、"mysql"と"oracle"とに関連付けられ、さらに、"mysql"と"oracle"とが、"rdb"に関連付けられている）。上記の関連関係は、"mysql_3.0"に依存するコンポーネントと"oracle_11g"に依存するコンポーネントとが、"rdb"というレベルにおいて競合することを示している。このように、依存性グループＩＤ（或いは関連情報）は、システムを構成する各々のコンポーネントが互いにどのレベルにおいて競合しているかを示す情報である。
【００４０】
機能管理部１０４は、検証部１０１からの機能情報取得要求を受付け、当該要求において指定された機能モジュールＩＤ(又は機能モジュールＩＤが属する依存性グループＩＤ)が属する依存性グループＩＤに関する情報を返答する。すなわち、機能管理部１０４は、機能モジュールＩＤが入力されると、当該機能モジュールＩＤに関連付けられた関連情報、あるいは、さらにその関連情報に関連付けられた関連情報を返答する。
【００４１】
図６は、第１の実施形態に係る機能情報取得要求の一例である。ここで機能情報取得要求は、例えば図６に示すように、当該要求が機能情報取得要求であることを示す情報と、機能情報を取得したい対象の機能モジュールＩＤ(又は機能モジュールＩＤの依存性グループＩＤ)とを示す情報が含まれる。図６の１行目の"getfuncgroup"は、要求が機能情報取得要求であることを示している。図６の２行目には、情報取得対象の機能モジュールＩＤを示している。
【００４２】
機能管理部１０４が返答する情報は、例えば、当該要求において指定された機能モジュールＩＤが所属する依存性グループのＩＤである。図５と図６とに示す機能情報と機能情報取得要求とを例にすれば、要求された機能モジュールＩＤは、"mysql_5.0"であり、返答する情報は、"mysql_5.0"が直接所属する依存性グループＩＤである"mysql"である。また、機能管理部１０４は、要求された機能モジュールＩＤが所属する依存性グループＩＤが存在しない場合には、存在しないことを示す空文字などの情報を返答しても良い。
【００４３】
また、機能管理部１０４は、機能情報取得要求において指定された機能モジュールＩＤが直接所属する依存性グループＩＤの他、当該依存性グループＩＤを含む依存性グループＩＤを検証部１０１に返答しても良い。すなわち、機能管理部１０４は、機能モジュールの関連情報と、当該関連情報にさらに関連付けされた関連情報とを再帰的に記憶装置１０５から取得して、検証部１０１に返答しても良い。
【００４４】
検証部１０１は、フロントエンド１０６を介して利用者から検証要求を受付け、構成管理部１０３から得られる構成情報と機能管理部１０４から得られる機能情報とを基に、システムを構成するコンポーネントが持つ機能モジュールに関する依存性の競合を検出する。
【００４５】
図７は、第１の実施形態に係る検証要求の一例である。ここで、検証要求は、例えば図７に示すように、当該要求が検証要求であることを示す情報と、検証対象のシステムを示すＩＤとが含まれている。例えば、図７の１行目のvalidateは、要求が検証要求であることを示している。図７の２行目には、検証対象のシステムのＩＤを示している。
【００４６】
依存性記憶部１０２は、検証部１０１によって検証されたコンポーネントの依存性要件を記憶する。図１０は、依存性記憶部１０２が記録する情報の一例である。この例において、コンポーネントＢは、依存する機能モジュールＩＤである"mysql_5.0"を介して、"mysql"と"rdb"との２つの依存性グループＩＤに属することが示されている。また、コンポーネントＣは、依存する機能モジュールＩＤである"oracle_11g"を介して、"oracle"と"rdb"との２つの依存性グループに属することが示されている。
【００４７】
[動作の説明]
次に、第１の実施の形態に係る検証装置１００の動作について説明する。
【００４８】
図８は、本実施の形態に係る構成管理部１０３への要件定義処理の動作例を示すフローチャートである。
【００４９】
フロントエンド１０６は、入出力装置１１０から要求の入力を受けると、当該要求の種類を示す１行目の内容を確認し、確認した要求の種類が構成情報の変更要求であることを示す"create"、"update"、"delete"のいずれかであれば、当該要求を構成管理部１０３へ送信する（ステップＳ１０１）。
【００５０】
構成管理部１０３は、構成情報の変更要求を受け取ると、当該要求の種類に応じて構成情報の変更を実施する（ステップＳ１０２）。具体的には、構成管理部１０３は、要求の種類が"create"すなわち追加であれば、当該要求の２行目以降に記載されたシステムの構成情報を追加する。また、構成管理部１０３は、要求の種類が"update"すなわち更新であれば、当該要求の２行目以降に記載されたシステムの構成情報とシステムのＩＤに従い、当該ＩＤと同一のＩＤを持つシステムの構成情報を更新する。また、構成管理部１０３は、要求の種類が"delete"すなわち削除であれば、当該要求の２行目に記載されたシステムのＩＤに従い、当該ＩＤと同一のＩＤを持つシステムの構成情報を削除する。
【００５１】
最後に構成管理部１０３は、フロントエンド１０６を介して、入出力装置１１０へ構成情報の変更結果を出力する（ステップＳ１０３）。構成情報の変更結果とは、例えば変更処理が完了したことを示す記号や変更内容等の情報である。
【００５２】
図９は、第１の実施の形態に係る検証部１０１の検証処理の動作例を示すフローチャートである。
【００５３】
フロントエンド１０６は、入出力装置１１０から要求の入力を受けると、当該要求の種類を示す１行目の内容を確認する。フロントエンド１０６は、確認した要求の内容が検証要求であることを示す"validate"であれば、当該要求を検証部１０１へ送信する（ステップＳ１０４）。
【００５４】
検証部１０１は、検証要求を受け取ると、当該要求の２行目に記載されたＩＤを持つシステムを検証対象のシステムとして検証を開始する。
【００５５】
検証部１０１は、まず当該システムのＩＤを含む構成情報取得要求を構成管理部１０３に送信する。次に、検証部１０１は、当該システムを構成する全てのコンポーネントの構成情報を構成管理部１０３から取得して、取得した当該コンポーネントの依存性要件を依存性記憶部１０２に記録する（ステップＳ１０５）。
【００５６】
このとき、構成管理部１０３は、構成情報取得要求に含まれるＩＤを持つシステムの構成情報を記憶装置１０５から取得する。次に、構成管理部１０３は、そのシステムを構成する全てのコンポーネントの構成情報を記憶装置１０５から取得して、取得した全てのコンポーネントの構成情報を検証部１０１へ送信する。
【００５７】
なお、構成管理部１０３は、あるシステムのコンポーネントの構成情報を、当該システムにおける全てのタグ"component"の"name"属性に記載されたＩＤを持つシステムの構成情報に基づいて取得することができる。例えば、図２に示される構成情報が構成管理部１０３内に存在するとき、ＩＤがＡのシステムに対する構成情報取得要求を構成管理部１０３が受け取った場合であれば、構成管理部１０３は、ＡのコンポーネントであるＢとＣとの２つの構成情報を検証部１０１へ送信する。
【００５８】
ここで、構成管理部１０３は、取得したコンポーネントがさらに他のコンポーネントによって構成される場合（当該他のコンポーネントを、元のコンポーネントの子コンポーネントともいう。）には、当該子コンポーネントの情報も再帰的に取得して検証部１０１へ送信してもよい。この場合、検証部１０１は、子コンポーネントが持つ依存性要件も併せて前記コンポーネントの依存性要件として依存性記憶部１０２に記録してもよい。
【００５９】
次に検証部１０１は、取得した構成情報から各コンポーネントの構成情報内のタグ"dependency"の"name"属性に記述された機能情報のＩＤを取得する。検証部１０１は、取得した当該ＩＤを含む機能情報取得要求を機能管理部１０４に送信する。次に、検証部１０１は、機能管理部１０４から検証対象システムのコンポーネントの依存性を示す機能モジュールＩＤの依存性グループＩＤに関する情報を取得し、取得した情報を依存性記憶部１０２に記録する（ステップＳ１０６）。
【００６０】
検証部１０１は、例えば図２に示される構成情報が得られた場合、コンポーネントＢの依存性を示す機能モジュールＩＤの依存性グループＩＤに関する情報として、"mysql_5.0"を要素として持つ依存性グループＩＤである"mysql"を取得する。また、検証部１０１は、コンポーネントＣの依存性を示す機能モジュールＩＤの依存性グループＩＤに関する情報として"oracle_11g"を要素として持つ依存性グループＩＤである"oracle"を取得する。
【００６１】
さらに検証部１０１は、得られた依存性グループＩＤの属する依存性グループＩＤを再帰的に機能管理部１０４から取得する。すなわち、検証部１０１は、各コンポーネントごとに、各コンポーネントが依存する機能モジュールＩＤに関連付けされた関連情報を再帰的に機能管理部１０４から取得する。
【００６２】
本例においては、"mysql"と"oracle"はいずれも"rdb"に属するため、結果としてコンポーネントＢは"mysql"と"rdb"との２つの依存性グループＩＤに依存し、コンポーネントＣは"oracle"と"rdb"との２つの依存性グループＩＤに依存する。
【００６３】
図１０は、本実施の形態に係る依存性記憶部１０２が記録する情報の一例である。この例において、コンポーネントＢは、依存する機能モジュールＩＤである"mysql_5.0"を介して"mysql"と"rdb"との２つの依存性グループＩＤの依存性を持つことが示されている。また、コンポーネントＣは、依存する機能モジュールＩＤである"oracle_11g"を介して"oracle"と"rdb"との２つの依存性グループＩＤの依存性を持つことが示されている。
【００６４】
続いて検証部１０１は、取得した依存性グループＩＤの情報を基にシステムのコンポーネント間の依存性要件の競合を検出する（ステップＳ１０７）。具体的には、検証部１０１は、依存性記憶部１０２内の情報を基に、同一の依存性グループＩＤに属する異なる機能モジュールＩＤが存在する場合、競合と判断する。
【００６５】
図１０の例に挙げた表においては、依存性グループＩＤの列の情報の中に重複する項目として２つの"rdb"がある。この場合は、それぞれに関連する機能モジュールＩＤは、異なる("mysql_5.0"と"oracle_11g")ので、これらの機能モジュールＩＤ"mysql_5.0"と"oracle_11g"が競合として検出される。
【００６６】
最後に、検証部１０１は、フロントエンド１０６を介して入出力装置１１０に検証結果を送信する（ステップＳ１０８）。検証結果には、例えば、競合が存在するか否かを示す情報が含まれる。さらに、検証結果には、競合が存在する場合、検証結果の詳細情報として競合の原因となった依存性グループＩＤ、機能モジュールＩＤおよび当該機能モジュールＩＤに依存するコンポーネントなどの情報が含まれる。
【００６７】
本実施の形態によれば、システムを構成するコンポーネント間の依存性の競合を容易に検出可能となる。その理由は、機能モジュールの属するグループを比較することによって機能モジュール間の依存性が容易に検証可能となるからである。これにより依存性の競合が統合時に初めて発見された場合、大幅な修正が強いられるような事態を防ぐことができる。さらに、効率的な開発環境を実現できる。
【００６８】
＝＝実施形態２＝＝
[構成の説明]
次に第２の実施の形態について説明する。
【００６９】
第１の実施の形態と同様の要素については図１と同様の記号を付して詳細な説明を省略する。
【００７０】
図１１は、第２の実施の形態に係る機能管理部１０４が管理する機能情報の一例である。この例において、機能情報には、第１の実施の形態と同様に機能モジュールＩＤと、競合として検出したい依存性グループＩＤに関する情報とが示されている。
【００７１】
本実施の形態においては、各依存性グループが、当該グループ内の機能モジュールが複数存在することがもたらす競合の重要度を表す情報（重要度）を持つ点が第１の実施の形態と異なる。
【００７２】
図１１の例においては、"mysql"、"oracle"、"rdb"の３つのグループが示されている。図１１に示すグループの情報の右側には角括弧が記述され、丸括弧の中に重要度が示されている。この例においては、"mysql"と"oracle"には"fatal"が付与され、"rdb"には"warn"が付与されている。
【００７３】
ここで、"fatal"は、当該グループ内の機能モジュールＩＤによる競合が致命的であることを示す。また、"warn"は、できれば避けるべきであると警告する程度の競合であることを示している。
【００７４】
すなわち、この例は、同一システム内にバージョンのみが異なる同一のデータベース管理システムが存在することは、絶対に避けるべき致命的な競合であることを示している。さらに、この例は、同一システム内に異なるデータベース管理製品が存在することは、できれば避けるべき競合であることを示している。
【００７５】
ここで、第２の実施の形態に係る検証要求は、要求が検証要求であることを示す情報と、検証対象のシステムを示すＩＤと、競合の重要度と、を含む。
【００７６】
図１２は、第２の実施の形態に係る検証要求の一例である。図１２の１行目のvalidateは、これが検証要求であることを示している。図１２の２行目は、検証対象のシステムのIDを示している。図１２の３行目は、検出したい競合の重要度が"fatal"なものであることを示している。
【００７７】
[動作の説明]
次に、第２の実施の形態に係る検証部１０１の動作について説明する。
【００７８】
第２の実施の形態に係る検証部１０１の動作は、図９に示したステップＳ１０４、Ｓ１０５、Ｓ１０７、Ｓ１０８については第１の実施の形態と同様である。一方、ステップＳ１０６の動作において、検証部１０１が機能管理部１０４から受け取った機能モジュールＩＤの依存性グループＩＤに関する情報のうち、検証要求に含まれる検出したい競合の重要度が一致する情報だけを依存性記憶部１０２に記録する点が第１の実施の形態と異なる。
【００７９】
例えば、機能管理部１０４に図１１において示される機能情報が存在するとし、検証部１０１が図１２において示される検証要求を受け付けた場合の動作例を説明する。
【００８０】
まず検証部１０１は、第１の実施の形態と同様に、構成管理部１０３からシステムＡを構成するコンポーネント群の依存性要件を取得し（ステップＳ１０５と同様）、"mysql_5.0"と"oracle_11g"を得る。続いて検証部１０１は、取得した各コンポーネントの依存する機能モジュールＩＤを機能管理部１０４から取得する。本例においては、検証部１０１は、"mysql_5.0"が属する依存性グループＩＤとして"mysql[fatal]"と"rdb[warn]"を取得し、"oracle_11g"が属する依存性グループＩＤとして"oracle[fatal]"と"rdb[warn]"をそれぞれ取得する。
【００８１】
検証部１０１は、依存性グループＩＤのうち、検証要求に記載された"fatal"が付加された依存性グループＩＤのみを依存性記録部１０２に記録する。その結果、検証部１０１は、図１３の例に挙げた依存性情報を得る。図１３は、第２の実施の形態に係る依存性記憶部１０２が記録する情報の一例である。
【００８２】
競合の重要度に予め順位付けがなされておくことによって、検証部１０１は、指定された順位以下のものを全て抽出するといった制御をしてもよい。例えば、管理者等が前述の重要度を"fatal"、"warn"の順序により予め順位付けしておいた場合、検証要求に"fatal"が指定された場合には、検証部１０１は、"fatal"が付与されたものだけ抽出するといった制御をしてもよい。検証要求に"warn"が指定された場合には、検証部１０１は、"fatal"と"warn"のいずれかが付与されたものを抽出するといった制御をしてもよい。
【００８３】
本実施の形態によれば、依存性グループごとに競合のレベルを付与しているため、検出したい競合の種類や重要度を容易に限定することができ、検証作業を効率化できる。さらに、本実施の形態によれば、開発者への警告を適切な競合に限定した効率的な開発支援が実現できる。
【００８４】
＝＝実施形態３＝＝
[構成の説明]
図１４は、第３の実施の形態に係る検証装置１００の構成例を示すブロック図である。
【００８５】
図１４に示されるように、第３の実施の形態に係る検証装置１００は、代替機能性提案部３０１を備える点が第１の実施の形態と異なる。第１の実施の形態と同様の要素については、図１と同様の記号を付して詳細な説明を省略する。
【００８６】
特定の依存性グループＩＤと当該グループＩＤにおける推奨機能モジュールＩＤに関する推奨依存性情報は、記憶装置１０５に記録されており、代替機能性提案部３０１によって管理される。
【００８７】
図１６は、第３の実施の形態に係る代替機能性提案部３０１が管理する推奨依存性情報の一例である。図１６に例示する表には、各行に依存性グループＩＤと機能モジュールＩＤの組が記録されている。図１６に例示する表は、依存性グループＩＤと当該依存性グループＩＤにおける推奨機能モジュールＩＤを表している。
【００８８】
代替機能性提案部３０１は、検証部１０１から依存性提案要求を受付け、当該要求の内容に応じた機能モジュールＩＤを返答する。図１５は、第３の実施の形態に係る依存性提案要求の一例である。ここで依存性提案要求は、図１５に示すように、当該要求が依存性提案要求であることを示す情報と、依存性グループを示すＩＤが含まれる。図１５の１行目の"proposal"は、これが依存性提案要求であることを示している。図１５の２行目は、機能モジュールを提案して欲しい依存性のグループのＩＤを示している。
【００８９】
[動作の説明]
次に、第３の実施の形態に係る検証部１０１の動作について説明する。
【００９０】
図１７は、第３の実施の形態に係る検証部１０１の検証処理の動作を示すフローチャートである。
【００９１】
第３の実施の形態に係る検証部１０１の動作は、図９に示したステップＳ１０４、Ｓ１０５、Ｓ１０６、Ｓ１０７、Ｓ１０８については第１の実施の形態と同様である。一方、ステップＳ１０７の動作において検証部１０１が競合を検出した場合、ステップＳ３０１の動作において、競合する機能モジュールＩＤが含まれる依存性グループＩＤを含む依存性提案要求を、検証部１０１が代替機能性提案部３０１に送信することにより当該グループにおける推奨機能モジュールＩＤを取得する点が第１の実施の形態と異なる。記憶装置１０５は、図１６に示すような、機能モジュールＩＤと依存性グループＩＤとを関連付けた推奨依存性情報を格納している。
【００９２】
例えば、記憶装置１０５には、図２において示される構成情報、図５において示される機能情報、図１６において示される推奨依存性情報が存在するとし、検証部１０１が図７において示される検証要求を受け付けた場合の動作例を説明する。
【００９３】
この例の場合、第１の実施の形態に係る動作の説明の際に説明したように、ステップＳ１０７において、依存性グループＩＤ"rdb"における競合が検出される。
【００９４】
続いて、検証部１０１は、図１５に示される"rdb"を含んだ依存性提案要求を代替機能性提案部３０１に送信することによって、提案を要求する（ステップＳ３０１）。そして、検証部１０１は、当該依存性グループＩＤにおける推奨機能モジュールＩＤを取得する。具体的には、代替機能性提案部３０１は、検証部１０１から受け付けた依存性提案要求内の依存性グループＩＤに関連する機能モジュールＩＤが、記憶装置１０５に存在する場合には当該機能モジュールＩＤを返答する。
【００９５】
例えば、図１６に示す依存性提案情報が記憶装置１０５に存在する場合、代替機能性提案部３０１は、"rdb"の依存性グループＩＤに関連する機能モジュールＩＤである"mysql_5.0"を推奨機能モジュールＩＤとして検証部１０１に返答する。
【００９６】
最後に、検証部１０１が、フロントエンド１０６を介して入出力装置１１０に検証結果を送信する。検証結果には、競合が存在するか否かを示す情報、競合の原因となった依存性グループＩＤ、機能モジュールＩＤおよび当該機能モジュールＩＤに依存するコンポーネントなどの情報に加えて、競合の原因となった依存性グループＩＤにおける推奨機能モジュールＩＤがさらに含まれてもよい。
【００９７】
また、検証部１０１による競合検出の結果として得られた、競合でない機能モジュールＩＤと依存性グループＩＤとの組に関する情報を、検証部１０１等が代替機能性提案部３０１に送信することによって、代替機能性提案部３０１が管理する推奨依存性情報を更新するステップがさらに追加されてもよい。
【００９８】
例えば、検証部１０１による競合検出処理において、図１０に示される情報が依存性記憶部１０２に記録された場合、"mysql"と"mysql_5.0"および"oracle"と"oracle_11g"の各組については、競合としては検出されない。そのため、検証部１０１がこれらを代替機能性提案部３０１に送信することによって、"mysql"の依存性グループＩＤにおける推奨機能モジュールＩＤを"mysql_5.0"とし、"oracle"の依存性グループＩＤにおける推奨機能モジュールＩＤを"oracle_11g"として記憶装置１０５等が記録しても良い。
【００９９】
本実施の形態によれば、機能モジュールの競合が発生した場合、代替機能性提案部３０１が推奨機能モジュールを返答するため、機能モジュールの競合が発生した場合に変更すべき機能モジュールを開発者が即時に取得できるようになる。そのため、効率的な開発支援が実現できる。
【０１００】
＝＝実施形態４＝＝
次に、本発明の第４の実施の形態について説明する。
【０１０１】
図１８は、本発明を実施する第４の実施の形態に係る検証装置４００の構成例を示すブロック図である。図１８に示すように、本実施の形態に係る検証装置４００は、記憶装置１０５と、機能管理部１０４と、検証部１０１とからなる。
【０１０２】
記憶装置１０５は、機能モジュールＩＤと、依存性グループＩＤ（関連情報）とを関連付けて記憶する。本実施形態において、記憶装置１０５は、一例として外部装置が備える構成として記載しているが、検証装置４００が備える構成としてもよい。
【０１０３】
機能管理部１０４は、外部から入力された機能モジュールＩＤを取得し、記憶装置１０５を参照して、取得した機能モジュールＩＤと関連付けられた依存性グループＩＤ（関連情報）を出力する。
【０１０４】
検証部１０１は、システムを構成する複数のコンポーネントの各々が依存する機能モジュールＩＤを機能管理部１０４に入力し、機能管理部１０４から、各々の機能モジュールＩＤに関連する前記関連情報を各々取得し、機能モジュールＩＤに、同一の関連情報が関連付けられている場合に競合と判定して判定結果を出力する。
【０１０５】
例えば、図２の機能情報を例にすれば、あるコンポーネントが機能モジュール"mysql_3.0"に依存し、他のコンポーネントが機能モジュール"mysql_4.0"に依存する場合、"mysql_3.0"、"mysql_4.0"は、共に同一の関連情報である依存性グループＩＤ"mysql"に関連付けられているから、検証部１０１は、これらのコンポーネント同士を競合と判断する。
【０１０６】
また、検証部１０１は、機能モジュールＩＤと関連付けされた関連情報が、さらに他の関連情報と関連付けされている場合には、当該他の関連情報をさらに取得することにより、競合を判定する。
【０１０７】
例えば、あるコンポーネントが機能モジュール"mysql_3.0"に依存し、他のコンポーネントが機能モジュール"oracle_11g"に依存する場合、"mysql_3.0"は、"mysql"と関連付けられる。さらに、"mysql"は、"rdb"と関連付けられている。また、"oracle_11g"は、"oracle"と関連付けられる。さらに、"oracle"は、"rdb"と関連付けられている。そのため、結果として、これらのコンポーネントは、同一の関連情報"rdb"と関連付けられている。よって、検証部１０１は、これらのコンポーネント同士を競合と判断する。
【０１０８】
本実施の形態によれば、システムを構成するコンポーネント間の依存性の競合を容易に検出可能となる。その理由は、機能モジュールの属するグループ（関連付けられた関連情報）を比較することによって機能モジュール間の依存性が容易に検証可能となるからである。これにより依存性の競合が統合時に初めて発見されて大幅な修正が強いられるような事態を防ぎ、効率的な開発環境を実現できる。
【０１０９】
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内によって当業者が理解しうる様々な変更をすることができる。
【０１１０】
この出願は、２０１２年１月２３日に出願された日本出願特願２０１２−０１１０７５を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【０１１１】
１０          ＣＰＵ
１２          メモリ
１４          ＨＤＤ
１６          通信ＩＦ
１８          リーダーライター
２０          記憶媒体
２２          バス
１００、３００、４００          検証装置
１０１          検証部
１０２          依存性記憶部
１０３          構成管理部
１０４          機能管理部
１０５          記憶装置
１０６          フロントエンド
１１０          入出力装置
３０１          代替機能性提案部
【図１】
0006007920.tif 000002
【図２】
0006007920.tif 000003
【図３】
0006007920.tif 000004
【図４】
0006007920.tif 000005
【図５】
0006007920.tif 000006
【図６】
0006007920.tif 000007
【図７】
0006007920.tif 000008
【図８】
0006007920.tif 000009
【図９】
0006007920.tif 000010
【図１０】
0006007920.tif 000011
【図１１】
0006007920.tif 000012
【図１２】
0006007920.tif 000013
【図１３】
0006007920.tif 000014
【図１４】
0006007920.tif 000015
【図１５】
0006007920.tif 000016
【図１６】
0006007920.tif 000017
【図１７】
0006007920.tif 000018
【図１８】
0006007920.tif 000019
【図１９】
0006007920.tif 000020