(57)【特許請求の範囲】
【請求項１】
機能モジュールＩＤと、その機能モジュールＩＤと他の機能モジュールＩＤとの関連付け情報と、を記憶する記憶手段と、
検証対象である特定の機能モジュールＩＤに関して前記記憶手段を参照して、該特定の機能モジュールＩＤが前記他の機能モジュールＩＤと関連付けられている場合には、前記他の機能モジュールＩＤを出力する一方で、関連付けされていない場合には、該特定の機能モジュールＩＤまたは関連付けがないことを表す情報を出力する機能管理手段と、
第１のシステムが依存する機能モジュールＩＤを、前記特定の機能モジュールＩＤとして前記機能管理手段に入力した際に、前記機能管理手段から少なくとも何れかの機能モジュールＩＤを取得した場合には、取得した機能モジュールＩＤを、第１の機能モジュールＩＤ集合とする一方で、前記機能管理手段から前記関連付けがないことを表す情報を取得した場合には、前記特定の機能モジュールＩＤとして前記機能管理手段に入力した機能モジュールＩＤを、該第１の機能モジュールＩＤ集合とし、
前記第１のシステムを構成する第２のシステムが依存する機能モジュールＩＤを、前記特定の機能モジュールＩＤとして前記機能管理手段に入力した際に、前記機能管理手段から少なくとも何れかの機能モジュールＩＤを取得した場合には、取得した機能モジュールＩＤを、第２の機能モジュールＩＤ集合とする一方で、前記機能管理手段から前記関連付けがないことを表す情報を取得した場合には、前記特定の機能モジュールＩＤとして前記機能管理手段に入力した機能モジュールＩＤを、該第２の機能モジュールＩＤ集合とし、
前記第２の機能モジュールＩＤ集合が、前記第１の機能モジュールＩＤ集合を包含している場合に、整合であることを表す情報を出力する検証手段と、
を備える検証装置。
【請求項２】
前記機能管理手段は、
外部から取得した機能モジュールＩＤと関連付けされた前記機能モジュールＩＤが、さらに前記他の機能ジュールＩＤと関連付けされている場合には、当該他の機能モジュールＩＤを抽出する請求項１に記載の検証装置。
【請求項３】
前記記憶手段は、属性条件が付加された前記機能モジュールＩＤを記憶し、
前記機能管理手段は、前記属性条件が付加された前記機能モジュールＩＤを取得して、その属性条件と同一の属性条件が付加された前記機能モジュールＩＤを前記記憶手段から抽出して出力する請求項１または請求項２に記載の検証装置。
【請求項４】
前記記憶手段は、外部ファイルの形式名と、その外部ファイルの内容から前記機能モジュールＩＤを抽出可能なモジュール名称と、を関連付けて記憶し、
入力された外部ファイル名とその外部ファイルの形式名とを取得し、前記取得した外部ファイル名を基に、前記外部ファイルの内容を外部から取得し、
前記記憶手段を参照することにより、前記取得した形式名に関連付けされている前記モジュール名称によって特定されるモジュールに、前記取得した外部ファイルから前記機能モジュールＩＤを抽出させ、その機能モジュールＩＤを前記機能管理手段に出力する機能解決手段をさらに備える請求項１乃至３のいずれかに記載の検証装置。
【請求項５】
機能モジュールＩＤと、その機能モジュールＩＤと他の機能モジュールＩＤとの関連付け情報と、を記憶する記憶手段を備えるコンピュータに、
検証対象である特定の機能モジュールＩＤに関して前記記憶手段を参照して、該特定の機能モジュールＩＤが前記他の機能モジュールＩＤと関連付けられている場合には、前記他の機能モジュールＩＤを出力する一方で、関連付けされていない場合には、該特定の機能モジュールＩＤまたは関連付けがないことを表す情報を出力する機能管理処理と、
第１のシステムが依存する機能モジュールＩＤを、前記特定の機能モジュールＩＤとして前記機能管理処理に入力した際に、前記機能管理処理によって少なくとも何れかの機能モジュールＩＤが取得された場合には、取得した機能モジュールＩＤを、第１の機能モジュールＩＤ集合とする一方で、前記機能管理処理によって前記関連付けがないことを表す情報が取得された場合には、前記特定の機能モジュールＩＤとして前記機能管理処理に入力した機能モジュールＩＤを、該第１の機能モジュールＩＤ集合とし、
前記第１のシステムを構成する第２のシステムが依存する機能モジュールＩＤを、前記特定の機能モジュールＩＤとして前記機能管理処理に入力し、前記機能管理処理によって前記機能モジュールＩＤを取得した場合には、取得した機能モジュールＩＤを、第２の機能モジュールＩＤ集合とする一方で、前記機能管理処理によって前記関連付けがないことを表す情報を取得した場合には、前記特定の機能モジュールＩＤとして前記機能管理処理に入力した機能モジュールＩＤを、該第２の機能モジュールＩＤ集合とし、
前記第２の機能モジュールＩＤ集合が、前記第１の機能モジュールＩＤ集合を包含している場合に、整合であることを表す情報を出力する検証処理と、
を実行させる検証プログラム。
【請求項６】
前記機能管理処理は、
外部から取得した機能モジュールＩＤと関連付けされた前記機能モジュールＩＤが、さらに前記他の機能ジュールＩＤと関連付けされている場合には、当該他の機能モジュールＩＤを抽出する請求項５に記載の検証プログラム。
【請求項７】
前記記憶手段は、属性条件が付加された前記機能モジュールＩＤを記憶し、
前記機能管理処理は、前記属性条件が付加された前記機能モジュールＩＤを取得して、その属性条件と同一の属性条件が付加された前記機能モジュールＩＤを前記記憶手段から抽出して出力する請求項５または請求項６に記載の検証プログラム。
【請求項８】
前記記憶手段は、外部ファイルの形式名と、その外部ファイルの内容から前記機能モジュールＩＤを抽出可能なモジュールの名称と、を関連付けて記憶し、
入力された外部ファイル名とその外部ファイルの形式名とを取得し、前記取得した外部ファイル名を基に、前記外部ファイルの内容を外部から取得し、
前記記憶手段を参照することにより、前記取得した形式名に関連付けされている前記モジュール名称によって特定されるモジュールに、前記取得した外部ファイルから前記機能モジュールＩＤを抽出させ、その機能モジュールＩＤを前記機能管理処理に出力する機能解決処理を、前記コンピュータに実行させる請求項５乃至７のいずれかに記載の検証プログラム。
【請求項９】
コンピュータによって、機能モジュールＩＤと、その機能モジュールＩＤと他の機能モジュールＩＤとの関連付け情報と、を記憶する記憶手段に記憶し、
前記コンピュータによって、検証対象である特定の機能モジュールＩＤに関して前記記憶手段を参照して、該特定の機能モジュールＩＤが前記他の機能モジュールＩＤと関連付けられている場合には、前記他の機能モジュールＩＤを出力する一方で、関連付けされていない場合には、該特定の機能モジュールＩＤまたは関連付けがないことを表す情報を出力し、
前記コンピュータによって、第１のシステムが依存する前記機能モジュールＩＤを、前記特定の機能モジュールＩＤとして入力した際に、少なくとも何れかの機能モジュールＩＤを取得した場合には、取得した機能モジュールＩＤを、第１の機能モジュールＩＤ集合とする一方で、前記関連付けがないことを表す情報を取得した場合には、前記特定の機能モジュールとして入力した機能モジュールＩＤを第１の機能モジュールＩＤ集合とし、
前記コンピュータによって、前記第１のシステムを構成する第２のシステムが依存する機能モジュールＩＤを入力した際に、少なくとも何れかの機能モジュールＩＤを取得した場合には、取得した機能モジュールＩＤを、第２の機能モジュールＩＤ集合とする一方で、前記関連付けがないことを表す情報を取得した場合には、前記特定の機能モジュールＩＤとして入力した機能モジュールＩＤを、該第２の機能モジュールＩＤ集合とし、
前記コンピュータによって、前記第２の機能モジュールＩＤ集合が、前記第１の機能モジュールＩＤ集合を包含している場合に、整合であることを表す情報を出力する検証方法。
【請求項１０】
外部から取得した機能モジュールＩＤと関連付けされた前記機能モジュールＩＤが、さらに前記他の機能ジュールＩＤと関連付けされている場合には、当該他の機能モジュールＩＤを抽出する請求項９に記載の検証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータを利用した各種システムの検証技術に関する。
【背景技術】
【０００２】
コンピュータを利用した各種システムの再利用性を高めるためには、当該システムの稼動に必須となる特定の環境やミドルウェアや機能モジュールなどに対する当該システムの依存性を極力排除し、これにより当該システムの独立性を高めることが有効である。
例えば、あるシステムＳＡが特定のデータベース製品ＤＡに依存している場合、他のシステムＳＢがシステムＳＡを再利用するためには、データベース製品ＤＡも併せて導入する必要がある。この場合、データベース製品ＤＡが高額な商用製品であったり、多くのメモリリソースを必要とする場合、システムＳＢがシステムＳＡを利用することは困難となる。
あるいは、システムＳＢが別のデータベース製品ＤＢを利用しており、構造上データベース製品ＤＡとデータベース製品ＤＢを共存させられないなどの事情が存在する場合には、システムＳＢがシステムＳＡを利用することは困難となる。
ここで、システムＳＡの依存性をデータベース製品ＤＡに限定せず、データベース製品ＤＡまたはデータベース製品ＤＢのいずれかが存在すればよい、というようにその制約条件を緩和した場合を考える。この場合、システムＳＢが自システムの要件に沿ったデータベース製品ＤＢを導入すれば、システムＳＢはシステムＳＡを利用することができる。すなわち、システムＳＡの再利用性が向上する。
この様に、システムの依存性が多くの選択肢を含む（緩い制約条件である）ほど、当該システムの独立性は向上するので、当該システムの再利用性は向上する。
ところで、システムがいくつかのコンポーネントから構成される場合、そのシステムの依存性は、当該システムが含むコンポーネントのうち、その依存性の制約条件が最も厳しいコンポーネントの依存性によって決定される。
例えば、利用者等が、あるシステムＳＣが任意のデータベース製品によって動作可能となることを期待していたとしても、システムＳＣに含まれるコンポーネントＣＣが特定のデータベース製品ＤＣに依存していた場合、結果的にシステムＳＣはデータベース製品ＤＣに依存することとなる。
そのため、利用者等が、このようなシステムの独立性と再利用性とを高めるためにその依存性の制約条件を緩い状態に維持しようとする場合、当該システムの依存性と、当該システムに含まれる各コンポーネントの依存性との整合性を確認する作業、すなわち整合性の検証が必要となる。
とりわけ多くのコンポーネントから構成されるシステムの開発においては、この検証作業は困難となるため、これを容易化する仕組みの提供が望まれる。
特許文献１及び特許文献２には、システムとそのコンポーネントのそれぞれが持つ要件間の整合性を自動的に検証する仕組みの一例が記載されている。特許文献１及び特許文献２に記載の検証装置は、検証する要件および検証に必要なデータをシステムや各コンポーネントに予め設定しておく。そして、検証装置は、コンポーネントをシステムに組み込む際に当該データに基づく要件の検証を実施し、システム側の要件に合致しないコンポーネントであると判断された場合、当該検証装置は、組み込みを避けることで、システムの適切な動作を維持する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−３２６３６６号公報
【特許文献２】特開２００８−１７１３１８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、前述の特許文献で提案されている要件の検証に必要なデータは、対象システムやコンポーネントの詳細なモデル記述である。このため、係る特許文献に提案されている技術において、係る必要なデータの準備に要する作業工数は大きい。そのため、システムの依存性とコンポーネントの依存性との間の整合性を容易に検証できないという問題がある。
そこで、本発明は、上述の課題を解決すべくなされた。本発明は、システムの依存性と、そのシステムを構成するコンポーネントの依存性との間の整合性を容易に検証可能な検証装置及びその制御方法、並びにコンピュータ・プログラムを提供することを主たる目的とする。
【課題を解決するための手段】
【０００５】
かかる目的を達成するため、本発明の一形態は、検証装置であって、
機能モジュールＩＤと、その機能モジュールＩＤと他の機能モジュールＩＤとの関連付け情報と、を記憶する記憶手段と、
検証対象である特定の機能モジュールＩＤに関して前記記憶手段を参照して、該特定の機能モジュールＩＤが前記他の機能モジュールＩＤと関連付けられている場合には、前記他の機能モジュールＩＤを出力する一方で、関連付けされていない場合には、該特定の機能モジュールＩＤまたは関連付けがないことを表す情報を出力する機能管理手段と、
第１のシステムが依存する機能モジュールＩＤを、前記特定の機能モジュールＩＤとして前記機能管理手段に入力した際に、前記機能管理手段から少なくとも何れかの機能モジュールＩＤを取得した場合には、取得した機能モジュールＩＤを、第１の機能モジュールＩＤ集合とする一方で、前記機能管理手段から前記関連付けがないことを表す情報を取得した場合には、前記特定の機能モジュールＩＤとして前記機能管理手段に入力した機能モジュールＩＤを、該第１の機能モジュールＩＤ集合とし、
前記第１のシステムを構成する第２のシステムが依存する機能モジュールＩＤを、前記特定の機能モジュールＩＤとして前記機能管理手段に入力した際に、前記機能管理手段から少なくとも何れかの機能モジュールＩＤを取得した場合には、取得した機能モジュールＩＤを、第２の機能モジュールＩＤ集合とする一方で、前記機能管理手段から前記関連付けがないことを表す情報を取得した場合には、前記特定の機能モジュールＩＤとして前記機能管理手段に入力した機能モジュールＩＤを、該第２の機能モジュールＩＤ集合とし、
前記第２の機能モジュールＩＤ集合が、前記第１の機能モジュールＩＤ集合を包含している場合に、整合であることを表す情報を出力する検証手段と、
を備える。
また、本発明の他の形態は、検証方法であって、
コンピュータによって、機能モジュールＩＤと、その機能モジュールＩＤと他の機能モジュールＩＤとの関連付け情報と、を記憶する記憶手段に記憶し、
前記コンピュータによって、検証対象である特定の機能モジュールＩＤに関して前記記憶手段を参照して、該特定の機能モジュールＩＤが前記他の機能モジュールＩＤと関連付けられている場合には、前記他の機能モジュールＩＤを出力する一方で、関連付けされていない場合には、該特定の機能モジュールＩＤまたは関連付けがないことを表す情報を出力し、
前記コンピュータによって、第１のシステムが依存する前記機能モジュールＩＤを、前記特定の機能モジュールＩＤとして入力した際に、少なくとも何れかの機能モジュールＩＤを取得した場合には、取得した機能モジュールＩＤを、第１の機能モジュールＩＤ集合とする一方で、前記関連付けがないことを表す情報を取得した場合には、前記特定の機能モジュールとして入力した機能モジュールＩＤを第１の機能モジュールＩＤ集合とし、
前記コンピュータによって、前記第１のシステムを構成する第２のシステムが依存する機能モジュールＩＤを入力した際に、少なくとも何れかの機能モジュールＩＤを取得した場合には、取得した機能モジュールＩＤを、第２の機能モジュールＩＤ集合とする一方で、前記関連付けがないことを表す情報を取得した場合には、前記特定の機能モジュールＩＤとして入力した機能モジュールＩＤを、該第２の機能モジュールＩＤ集合とし、
前記コンピュータによって、前記第２の機能モジュールＩＤ集合が、前記第１の機能モジュールＩＤ集合を包含している場合に、整合であることを表す情報を出力する。
尚、同目的は、上記構成を有する検証装置または検証方法を、コンピュータによって実現するコンピュータ・プログラム、及びそのコンピュータ・プログラムが格納されている、コンピュータ読み取り可能な記憶媒体によっても達成される。
【発明の効果】
【０００６】
本発明によれば、システムの依存性と、そのシステムを構成するコンポーネントの依存性との間の整合性を容易に検証可能な検証装置等の提供が実現する。
【図面の簡単な説明】
【０００７】
【図１】図１は、本発明を実施する第１の実施の形態の検証装置１００の構成例を示すブロック図である。
【図２】図２は、本発明を実施する第１の実施の形態の構成管理部１０２が管理する構成情報の一例である。
【図３】図３は、本発明を実施する第１の実施の形態の構成情報変更要求の一例である。
【図４】図４は、本発明を実施する第１の実施の形態の構成情報取得要求の一例である。
【図５】図５は、本発明を実施する第１の実施の形態の機能管理部１０３が管理する機能情報の一例である。
【図６】図６は、本発明を実施する第１の実施の形態の機能情報取得要求の一例である。
【図７】図７は、本発明を実施する第１の実施の形態の検証要求の一例である。
【図８】図は、本発明を実施する第１の実施の形態における構成管理部１０２への要件定義処理の動作を示すフローチャートである。
【図９】図９は、本発明を実施する第１の実施の形態における検証部１０１の検証処理の動作例を示すフローチャートである。
【図１０】図１０は、本発明を実施する第２の実施の形態の機能管理部１０３が管理する機能情報の一例である。
【図１１】図１１は、本発明を実施する第３の実施の形態の構成管理部１０２が管理する構成情報の一例である。
【図１２】図１２は、本発明を実施する第３の実施の形態の機能管理部１０３が管理する機能情報の一例である。
【図１３】図１３は、本発明を実施する第３の実施の形態の機能情報取得要求の一例である。
【図１４】図１４は、本発明を実施する第４の実施の形態の検証装置１００の構成例を示すブロック図である。
【図１５】図１５は、本発明を実施する第４の実施の形態の機能解決部４０１が管理する機能解決情報の一例である。
【図１６】図１６は、本発明を実施する第４の実施の形態の構成管理部１０２が管理する構成情報の一例である。
【図１７】図１７は、本発明を実施する第４の実施の形態の構成管理部１０２が参照する外部の構成情報の一例である。
【図１８】図１８は、本発明を実施する第４の実施の形態の機能解決部４０１が管理する解決可能形式情報の一例である。
【図１９】図１９は、本発明を実施する第４の実施の形態の機能情報取得要求の一例である。
【図２０】図２０は、本発明を実施する第４の実施の形態における機能管理部１０３の機能情報取得処理の動作例を示すフローチャートである。
【図２１】図２１は、本発明の第５の実施の形態の検証装置１００の構成例を示すブロック図である。
【図２２】図２２は、本発明の各実施形態を適用可能な情報処理装置の構成を例示するブロック図である。
【発明を実施するための形態】
【０００８】
以下、本発明の実施の形態について、図面を用いて詳細に説明する。すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。
はじめに、以下に説明する各実施形態に係る装置等を構成する各部は、論理回路等のハードウェアで構成される。
或いは、当該各部は、図２２に例示するような一般的な構成を有する情報処理装置（コンピュータ）１０によっても実現可能である。即ち、当該各実施形態を例に説明する本発明は、係るコンピュータを構成する制御部、メモリ１２、コンピュータ・プログラム（以下、単に「プログラム」と略称する）１５を格納するハードディスク等の記憶装置１４、ネットワーク２０と通信可能に接続する通信インタフェース（Ｉ／Ｆ）１３などのハードウェア資源と、そのハードウェア資源と協働するソフトウェア（プログラム）との任意の組合せによって実現されてもよい。そして特に断りのない限り、その実現方法、装置は限定されない。
そして、係る制御部は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１などを有しており、そのＣＰＵにおいて動作するＯＳ（Ｏｐｅｒａｔｉｎｇ  ｓｙｓｔｅｍ）の管理下においてプログラム１５を実行することにより、当該各実施形態に係る装置等を実現すると共に、係る装置等の全体を制御する。或いは、係る制御部は、例えばドライブ装置１６などに装着された記録媒体１７からメモリ１２にプログラムやデータを読み出し、これに従って各種の処理を実行してもよい。係る記録媒体１７は、例えば、光ディスク、フレキシブルディスク、磁気光ディスク、外付けハードディスク、半導体メモリ等であって、係るプログラムを、コンピュータが読み取り可能に記録する。また、プログラムは、通信ネットワーク２０に通信可能に接続される外部コンピュータ（不図示）等から入手してもよい。
＜第１の実施形態＞
次に、本発明の第１の実施形態について図面を用いて説明する。
［構成の説明］
図１は、本発明を実施する第１の実施の形態の検証装置１００の構成例を示すブロック図である。
図１に示されるように、本発明の第１の実施の形態における検証装置１００は、フロントエンド１０５、検証部１０１、構成管理部１０２、機能管理部１０３、記憶装置１０４を備える。
フロントエンド１０５は、通信ネットワーク（２０）等の有線または無線の通信回線を介して、入出力装置１１０と通信可能に接続されている。入出力装置１１０は、利用者が情報の入出力に用いる、検証装置１００の外部にある装置である。なお、入出力装置１１０は、検証装置１００内部に設けられてもよい。
検証部１０１は、フロントエンド１０５を介して、利用者が入出力装置１１０から入力した検証要求を受け付ける。検証部１０１は、係る検証要求に従い、後述する構成管理部１０２から得られる構成情報と、後述する機能管理部１０３から得られる機能情報とに基づいて、システムの機能モジュールに対する依存性と、当該システムを構成するコンポーネントの機能モジュールに対する依存性との整合性を検証する。検証部１０１の動作については後述する。
記憶装置１０４は、システムや当該システムを構成するコンポーネントの構成要素を表す情報（構成情報、図２参照）、及び、後述する機能情報（図５参照）を格納している。
構成管理部１０２は、記憶装置１０４に格納された構成情報を管理する。図２は、本発明を実施する第１の実施の形態の構成管理部１０２が管理する構成情報の一例である。図２に示す例では、構成情報はＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式で記述されているが、本実施形態を例に説明する本発明において係る構成情報の形式は特に限定されない。
システムの構成情報はｓｙｓｔｅｍタグで記述される。当該システムのＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）は、そのタグ“ｓｙｓｔｅｍ”の属性“ｉｄ”によって定義される。図２に示す例では、システムＡとシステムＢという２つのシステムが定義されている。
また、システムを構成するコンポーネントは、当該システムを定義するタグ“ｓｙｓｔｅｍ”の子要素にあたるタグ“ｃｏｍｐｏｎｅｎｔ”で記述される。当該コンポーネントのＩＤは、そのタグ“ｃｏｍｐｏｎｅｎｔ”の属性“ｎａｍｅ”によって定義される。図２に示す例では、システムＡのコンポーネントがシステムＢであると定義されている。
また、システムやそのコンポーネントの依存する機能モジュールは、当該システムやコンポーネントを定義するタグ“ｓｙｓｔｅｍ”の子要素にあたるタグ“ｄｅｐｅｎｄｅｎｃｙ”によって記述される。当該システムやコンポーネントが依存する１以上の機能モジュールの各々を識別するＩＤ（機能モジュールＩＤ）は、そのタグ“ｄｅｐｅｎｄｅｎｃｙ”の属性“ｎａｍｅ”によって定義される。
例えば、図２に示すシステムＢの依存する機能モジュールＩＤは″ｍｙｓｑｌ″である。また、システムＡの依存する機能モジュールＩＤは″ｒｄｂ″である。図２のシステムＡのタグ“ｄｅｐｅｎｄｅｎｃｙ”の属性“ｎａｍｅ”で定義される″ｒｄｂ″は、図５で示されるように、″ｍｙｓｑｌ″、″ｐｏｓｔｒｅｓｑｌ″、″ｏｒａｃｌｅ″なる３つの機能モジュールＩＤと関連付けられている（この関連付けについては後述する）。
構成管理部１０２は、フロントエンド１０５を介して、利用者が入出力装置１１０によって入力した構成情報の変更要求を受け付け、当該要求の内容に応じて構成情報を更新する。
ここで構成情報の変更要求とは、例えば、特定のシステムの追加要求、更新要求、削除要求等である。要求内容には、例えば、図３に示すように、システムに関する要求の種別と当該要求の対象に関する内容が含まれる。図３に示す例では、構成変更要求の１行目に要求の種別を示し、２行目以降にその要求の対象が示されている。
例えば、図３の一番上に示されたシステムの追加要求において、“ｃｒｅａｔｅ”は、当該要求が、システムの追加の要求であることを示し、続く記述は、追加するシステムの構成情報を示している。
また、図３の中央に示されたシステムの更新要求において、“ｕｐｄａｔｅ”は、当該要求がシステムの更新の要求であることを示し、続く記述は、更新対象のシステムとその構成情報を示している。
また、図３の一番下に示されたシステムの削除要求において、“ｄｅｌｅｔｅ”は、当該要求がシステムの削除の要求であることを示し、続く記述は、削除対象のシステムのＩＤを示している。
また構成管理部１０２は、検証部１０１からの構成情報取得要求を受付け、当該要求において指定されたシステムと、そのシステムを構成するコンポーネントに関する構成情報を返答する。
ここで構成情報取得要求は、例えば図４に示すように、構成情報取得要求であることを表す情報と、利用者が構成情報を取得したい対象のシステムを表す情報とが含まれる。例えば、図４の１行目の“ｇｅｔｃｏｍｐ”は、当該要求が構成情報取得要求であることを示しており、続く２行目は、情報取得対象のシステムのＩＤ（この例ではＡ）を示している。
記憶装置１０４は、機能モジュールＩＤと、機能モジュールＩＤと、他の機能モジュールＩＤとの関連付け情報とによって構成される機能情報（図５参照）を格納している。
機能管理部１０３は、機能情報を管理する。図５は、機能管理部１０３が管理する機能情報の一例である。
図５の例では、機能モジュールＩＤが示されており、機能モジュールに他の機能モジュールが関連付けられている場合に、係る関連付けされた他の機能モジュールは、当該機能モジュールの右に、丸括弧で括って記載される。図５に示す例では、機能モジュールＩＤとして″ｍｙｓｑｌ″、″ｐｏｓｔｇｒｅｓｑｌ″、″ｏｒａｃｌｅ″、″ｔｏｍｃａｔ″、″ｊｅｔｔｙ″、″ｇｌａｓｓｆｉｓｈ″、″ｒｄｂ″、″ａｐＣｏｎｔａｉｎｅｒ″が示されている。また″ｒｄｂ″は、他の機能モジュールＩＤである″ｍｙｓｑｌ″、″ｐｏｓｔｇｒｅｓｑｌ″、″ｏｒａｃｌｅ″と関連付けられている。また、″ａｐＣｏｎｔａｉｎｅｒ″は、″ｔｏｃａｔ″、″ｊｅｔｔｙ″、″ｇｌａｓｓｆｉｓｈ″と関連付けられている。以下の説明では、関連付けられた機能モジュールＩＤを、「被関連付け機能モジュールＩＤ」とも称することとする。
ここで、システムの構成情報内のタグ“ｄｅｐｅｎｄｅｎｃｙ”に機能モジュールＩＤが記述されている場合を考える。この場合において、その機能モジュールＩＤが他の機能モジュールＩＤと関連付けされていない場合には、当該システムは、その機能モジュールＩＤによって示される機能モジュールに依存性を持つ、と表現することとする。反対に、当該機能モジュールＩＤが他の機能モジュールＩＤと関連付けられている場合には、当該システムは、当該他の機能モジュールＩＤによって示される機能モジュールのいずれかに依存性を持つ、と表現することとする。例えば、システムの構成情報内のタグ“ｄｅｐｅｎｄｅｎｃｙ”が＜ｄｅｐｅｎｄｅｎｃｙ  ｎａｍｅ＝Ｘ＞であるとし、機能モジュールＩＤであるＸは、３つの機能モジュールα、β、及び、γのＩＤと関連付けられている場合、当該システムは、機能モジュールα、β、又は、γに依存性を持つ、と表現することとする（当該システムの依存性要件がα、β、γであるともいう）。
ここで、依存性について説明する。システムが機能モジュールα、β、γに依存性を持つ場合（すなわちシステムの依存性要件がα、β、γである場合）とは、機能モジュールα、β、γの少なくともいずれかの機能モジュールが存在すれば、そのシステムが利用可能であることを意味する。すなわち、依存性を持つ機能モジュールの数が増えるほどシステムの制約条件は緩和される。例えば、システムＳＡの依存性がデータベース製品ＤＡだけであるよりも、データベース製品ＤＡまたはデータベース製品ＤＢのいずれかが存在すれば利用可能である、というように制約条件が緩和される。そのため、依存性要件が多くの選択肢を含む緩い制約であるほど、システムの独立性は向上するので、当該システムの再利用性が高まる。
機能管理部１０３は、検証部１０１からの機能情報取得要求を受付け、当該要求において指定された機能モジュールＩＤが他の機能モジュールＩＤと関連付けされていない場合には当該機能モジュールＩＤそのものを返答する。一方、機能モジュールＩＤに他の機能モジュールが関連付けられている場合に、機能管理部１０３は、当該他の機能モジュールＩＤ（被関連付け機能モジュールＩＤ）を返答する。ここで、機能管理部１０３は、機能モジュールＩＤが他の機能モジュールＩＤと関連付けされていない場合には、関連付けがないことを表す情報を返答してもよい。
ここで機能情報取得要求には、例えば図６に示すように、機能情報取得要求であることを表す情報と、機能モジュールＩＤとが含まれる。例えば、図６の１行目の“ｇｅｔｆｕｎｃ”は、当該要求が、機能情報取得要求であることを示しており、続く２行目の記述は情報取得対象の機能モジュールＩＤを示している。
機能管理部１０３が返答する機能情報は、当該要求において指定された機能モジュールＩＤ、あるいは、被関連付け機能モジュールＩＤである。すなわち、機能情報取得要求において指定された機能モジュールＩＤが、記憶装置１０４内で関連付けが定義されていない機能モジュールＩＤである場合には、機能管理部１０３は、当該機能モジュールＩＤそのものを返答する。なお、機能管理部１０３は、関連付けがされていない旨の情報を返答してもよい。また、当該要求において指定された機能モジュールＩＤが記憶装置１０４内で他の機能モジュールＩＤと関連付けが定義された機能モジュールＩＤである場合には、機能管理部１０３は、関連付けされた全ての機能モジュールＩＤ（被関連付け機能モジュールＩＤ）を返答する。
検証部１０１は、上述のように、フロントエンド１０５を介して、利用者から検証要求を受付け、構成管理部１０２から得られる構成情報と機能管理部１０３から得られる機能モジュールＩＤとに基づいて、システムおよびそのコンポーネントの機能モジュールに対する依存性の整合性（整合状態）を検証する。係る検証を行うための検証処理については後述する。
ここで検証要求には、当該要求が検証要求であることを表す情報と、検証対象のシステムを表すＩＤとが含まれている。例えば図７には、検証要求の一例が示されている。図７の１行目の“ｖａｌｉｄａｔｅ”は、当該要求が検証要求であることを示しており、続く２行目の記述は検証対象のシステムのＩＤを示している。
［動作の説明］
次に、本発明の第１の実施の形態における検証装置１００の動作について説明する。
図８は、本発明の第１の実施の形態における構成管理部１０２への要件定義処理の動作例を示すフローチャートである。
まず、フロントエンド１０５は、入出力装置１１０から要求が入力されると、当該要求の種類を示す１行目の内容を確認し、この内容が、構成情報の変更要求（図３参照）であることを示す″ｃｒｅａｔｅ″、″ｕｐｄａｔｅ″、″ｄｅｌｅｔｅ″のいずれかであれば、当該要求を構成管理部１０２へ送信する（ステップＳ１０１）。
構成管理部１０２は、構成情報の変更要求を受け取ると、当該要求の種類に応じて構成情報の変更を実施する（ステップＳ１０２）。具体的には、要求の種類が″ｃｒｅａｔｅ″すなわち追加であれば、構成管理部１０２は、当該要求の２行目以降に記述されたシステムの構成情報を追加する。
また、要求の種類が″ｕｐｄａｔｅ″すなわち更新であれば、当該要求の２行目以降に記述されたシステムの構成情報とそのＩＤに従い、構成管理部１０２は、当該ＩＤと同一のＩＤを持つシステムの構成情報を更新する。
また、要求の種類が″ｄｅｌｅｔｅ″すなわち削除であれば、当該要求の２行目に記述されたシステムのＩＤに従い、構成管理部１０２は、当該ＩＤと同一のＩＤを持つシステムの構成情報を削除する。
最後に構成管理部１０２は、フロントエンド１０５を介して、入出力装置１１０へ構成情報の変更結果を出力する（ステップＳ１０３）。構成情報の変更結果とは、例えば変更処理が完了したことを表す記号や変更内容等の情報である。
図９は、本発明の第１の実施の形態における検証部１０１の検証処理の動作例を示すフローチャートである。
フロントエンド１０５は、入出力装置１１０から要求の入力を受けると、当該要求の種類を示す１行目の内容を確認し、この内容が検証要求であることを示す″ｖａｌｉｄａｔｅ″であれば、当該要求を検証部１０１へ送信する（ステップＳ１０４）。
検証部１０１は、検証要求（図７参照）を受け取ると、当該要求の２行目に記載されたＩＤを持つシステムを検証対象のシステムとして検証を開始する。
検証部１０１は、まず当該システムのＩＤを含む構成情報取得要求（図４参照）を構成管理部１０２に送信し、構成管理部１０２から、当該システムとその全てのコンポーネントの構成情報を取得する（ステップＳ１０５）。
この際、構成管理部１０２は、まず構成情報取得要求に記述されたＩＤを持つシステムの構成情報を取得する。続いて、構成管理部１０２は、そのシステムを構成するコンポーネントの構成情報を再帰的に取得して、取得した全ての構成情報を検証部１０１へ送信する。ここで再帰的とは、コンポーネントがさらに別のコンポーネントを包含する場合には、その包含されるコンポーネントの構成情報も取得することを意味する。なお、構成管理部１０２は、あるシステムを構成するコンポーネントの構成情報を、当該システム内の全てのタグ“ｃｏｍｐｏｎｅｎｔ”の属性“ｎａｍｅ”に記載されたＩＤを基に取得できる。
例えば、構成管理部１０２が、図４に示すような、ＩＤがＡのシステムに対する構成情報取得要求を検証部１０１から取得したとする。この場合、例えば図２に示される構成情報が記憶装置１０４内に存在すれば、構成管理部１０２は、システムＡおよびそのコンポーネントＢの２つの構成情報を検証部１０１へ送信する。
次に検証部１０１は、取得した前記構成情報からシステムの構成情報内のタグ“ｄｅｐｅｎｄｅｎｃｙ”の属性“ｎａｍｅ”に記述された機能モジュールＩＤを取得し、当該ＩＤを含む機能情報取得要求（図６上側参照）を機能管理部１０３に送信する。また、検証部１０１は、システムのコンポーネントの構成情報内のタグ“ｄｅｐｅｎｄｅｎｃｙ”の属性“ｎａｍｅ”に記述された機能モジュールＩＤを取得し、当該ＩＤを含む機能情報取得要求（図６下側参照）を機能管理部１０３に送信する。そして、検証部１０１は、検証対象システムが依存する機能モジュールＩＤ（第１の機能モジュールＩＤ集合）と、そのコンポーネントが依存する機能モジュールのＩＤ（第２の機能モジュールＩＤ集合）とを、機能管理部１０３から取得する（ステップＳ１０６）。
例えば、検証部１０１が、構成管理部１０２から、図２に示される構成情報を得たとする。この場合、検証部１０１は、システムＡの依存する機能モジュールＩＤ（第１の機能モジュールＩＤ集合）を取得するために、″ｒｄｂ″を含む機能情報取得要求を機能管理部１０３に送信する（図６上側参照）。また、検証部１０１は、システムＡのコンポーネントであるシステムＢの依存する機能モジュールＩＤ（第２の機能モジュールＩＤ集合）を取得するために、″ｍｙｓｑｌ″を含む機能情報取得要求（図６下側参照）を機能管理部１０３に送信する。
そして、検証部１０１からこれらの機能情報取得要求を取得した機能管理部１０３は、記憶装置１０４を参照し、第１の機能モジュールＩＤ集合として、″ｒｄｂ″の機能モジュールＩＤと関連付けられた″ｍｙｓｑｌ″、″ｐｏｓｔｇｒｅｓｑｌ″、″ｏｒａｃｌｅ″という３つの機能モジュールＩＤを検証部１０１に送信し、併せて、第２の機能モジュールＩＤ集合である″ｍｙｓｑｌ″機能モジュールのＩＤを検証部１０１に送信する（図５参照）。なお、機能管理部１０３は、″ｍｙｓｑｌ″機能モジュールのＩＤの代わりに、関連付けがないことを表す情報を検証部１０１に送信してもよい。
続いて検証部１０１は、取得した機能モジュールＩＤを基に、システムとそのコンポーネントの整合性を確認する（ステップＳ１０７）。
ここで、検証部１０１は、第２の機能モジュールＩＤ集合が、第１の機能モジュールＩＤ集合を包含する場合に、整合であることを表す情報を入出力装置１１０へ出力する。それ以外の場合に、検証部１０１は、不整合であることを表す情報を入出力装置１０１に出力してもよい。また、第２の機能モジュールＩＤ集合が、第１の機能モジュールＩＤ集合の、空集合以外の真部分集合である場合に、不整合であると判断し、不整合であることを表す情報を入出力装置１１０へ出力してもよい。
なお、検証部１０１は、システムの依存する機能モジュールＩＤを含む機能情報取得要求を機能管理部１０３に送信した結果、当該機能モジュールＩＤには関連付けがないことを表す情報を機能管理部１０３から取得した場合には、当該機能モジュールＩＤそのものを前記第１の機能モジュールＩＤ集合に含める。また、検証部１０１は、システムを構成するコンポーネントの依存する機能モジュールＩＤを含む機能情報取得要求を機能管理部１０３に送信した結果、当該機能モジュールＩＤには関連付けがないことを表す情報を機能管理部１０３から取得した場合には、当該機能モジュールＩＤそのものを前記第２の機能モジュールＩＤ集合に含める。
検証部１０１の検証処理について具体例を用いて説明する。例えば、あるシステムが＜″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″＞に依存し（すなわち、第１の機能モジュールＩＤ集合が″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″である場合）、そのコンポーネントが＜″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″，″ｏｒａｃｌｅ″＞に依存する場合（すなわち、第２の機能モジュールＩＤ集合が″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″，″ｏｒａｃｌｅ″である場合）、検証部１０１は整合であることを表す情報を入出力装置１０１に出力する。
また、あるシステムが、＜″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″，″ｏｒａｃｌｅ″＞に依存する場合であって、コンポーネントが＜″ｍｙｓｑｌ″＞、＜″ｐｏｓｔｇｒｅｓ″＞、＜″ｏｒａｃｌｅ″＞、＜″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″＞、＜″ｐｏｓｔｇｒｅｓｑｌ″，″ｏｒａｃｌｅ″＞、＜″ｍｙｓｑｌ″，″ｏｒａｃｌｅ″＞のいずれかの機能モジュールＩＤによって示される機能モジュールに依存する場合には、検証部１０１によって不整合であると判断される。その理由を、具体例を用いて説明する。
例えば、あるシステムが＜″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″，″ｏｒａｃｌｅ″＞に依存し、そのシステムを構成するコンポーネントが＜″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″＞に依存する場合を例に説明する。
あるシステムが＜″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″，″ｏｒａｃｌｅ″＞に依存する場合、当該システムは、″ｍｙｓｑｌ″、″ｐｏｓｔｇｒｅｓｑｌ″、″ｏｒａｃｌｅ″のいずれかの機能モジュールがあれば利用可能である。
また、コンポーネントが＜″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″＞に依存する場合、コンポーネントは、″ｍｙｓｑｌ″、″ｐｏｓｔｇｒｅｓｑｌ″のいずれかの機能モジュールがあれば利用可能である。したがって、それ以外の機能モジュールである″ｏｒａｃｌｅ″が存在したとしても、該コンポーネントは利用可能ではない。
その結果、″ｏｒａｃｌｅ″の機能モジュールが存在したとしても、該コンポーネントが利用可能ではないので、該コンポーネントを備えるシステムも利用不可能であることになる。
しかし、このことは、当該システムが″ｍｙｓｑｌ″、″ｐｏｓｔｇｒｅｓｑｌ″、″ｏｒａｃｌｅ″のいずれかの機能モジュールがあれば（すなわち、″ｏｒａｃｌｅ″の機能モジュールがあれば）利用可能であることと整合がとれていない。したがって、この場合には、検証部１０１によって、システムの依存性要件とそのコンポーネントの依存性要件とが不整合であると判断される。
なお、システムやコンポーネントの依存性要件が空集合であれば、依存性要件が無いということであるから、システムやコンポーネントはどのような機能モジュールにも依存していないことになり、不整合となることはない。よって、システムの依存性要件が空集合である場合には、検証部１０１によって整合であると判断される。例えば、あるシステムやコンポーネントの構成情報内のタグ“ｄｅｐｅｎｄｅｎｃｙ”に関する情報が存在しない場合には、当該システムやコンポーネントには依存性がないため、依存性要件は空集合となる。
また、あるシステムが＜″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″＞に依存し、そのシステムを構成するコンポーネントが＜″ｍｙｓｑｌ″，″ｐｏｓｔｇｒｅｓｑｌ″，″ｏｒａｃｌｅ″＞に依存する場合には、システムが″ｍｙｓｑｌ″と″ｐｏｓｔｇｒｅｓｑｌ″とのいずれを利用する場合にも、コンポーネントは利用可能であるから整合がとれていることになる。
最後に、検証部１０１は、フロントエンド１０５を介して、利用者端末１１０に検証結果を送信する（ステップＳ１０８）。
検証結果には、整合か不整合かを示す記号などの情報が含まれればよい。検証部１０１は、不整合の原因となったシステムの依存する機能モジュールを示すＩＤや、それらの機能モジュールに依存するコンポーネントのＩＤなどの詳細情報を検証結果に付加してもよい。
本実施の形態によれば、システムの依存性とそのコンポーネントの依存性との間の整合性を容易に検証可能である。
＜第２の実施形態＞
［構成の説明］
次に、本発明の第２の実施の形態について説明する。第１の実施の形態と同様の要素については図１と同様の記号を付し、詳細な説明を省略する。
図１０は、本発明の第２の実施の形態の機能管理部１０３が管理する機能情報の一例である。この例では、機能情報には、第１の実施の形態と同様に、機能モジュールＩＤと、機能モジュールを他の機能モジュールと関連付ける情報が示されているが、関連付けされた機能モジュールＩＤがさらに他の機能モジュールＩＤと関連付けされているという構成が第１の実施の形態とは異なる。
この例では、″ｄｂ″が″ｒｄｂ″、″ｋｖｓ″と関連付けられており、さらに″ｒｄｂ″は″ｍｙｓｑｌ″、″ｐｏｓｔｇｒｅｓｑｌ″、″ｏｒａｃｌｅ″と関連付けられ、″ｋｖｓ″は″ｓｉｍｐｌｅｄｂ″、″ｃｏｕｃｈｄｂ″と関連付けられている。すなわち、″ｄｂ″は、″ｒｄｂ″と″ｋｖｓ″とを包含し、さらに″ｒｄｂ″は″ｍｙｓｑｌ″、″ｐｏｓｔｇｒｅｓｑｌ″、″ｏｒａｃｌｅ″を包含し、″ｋｖｓ″は″ｓｉｍｐｌｅｄｂ″、″ｃｏｕｃｈｄｂ″を包含している集合関係（あるいはツリー構造）と捉えることもできる。
［動作の説明］
次に、本発明の第２の実施の形態における検証装置１００の動作について説明する。
第２の実施の形態における検証装置１００の動作は、図９に示したステップＳ１０４、Ｓ１０５、Ｓ１０７、Ｓ１０８については第１の実施の形態と同様である。一方、ステップＳ１０６の動作において、機能管理部１０３が、機能モジュールＩＤの関連付け情報を再帰的に検索して関連付けされた機能モジュールＩＤを収集するという構成が第１の実施の形態と異なる。ここで、“再帰的に検索して関連付けされた機能モジュールＩＤを収集する”、とは、ある機能モジュールＩＤに他の機能モジュールＩＤが関連付けされている場合に、当該他の機能モジュールＩＤがさらに他の機能モジュールＩＤと関連付けされている場合には、それらの関連付けされた機能モジュールを順次検索して、ある機能モジュールＩＤに関連付けされている全ての機能モジュールＩＤを取得する、ということである。
すなわち、機能管理部１０３は、検証部１０１からの機能情報取得要求を受付けると、当該要求において指定された機能モジュールＩＤに関連付けされた他の機能モジュールＩＤを検索する。
機能管理部１０３は、検索により取得した機能モジュールＩＤがさらに他の機能モジュールＩＤと関連づけられている場合には、さらに関連付けされているそれらの機能モジュールＩＤを検索し、それ以上関連付けされた機能モジュールＩＤが見つからない場合には、当該機能モジュールＩＤ（終点機能モジュールＩＤ）を取得する。
機能管理部１０３は、全ての終点機能モジュールＩＤを取得したら、それらの機能モジュールＩＤを検証部１０１に返答し、検証部１０１がこれらの情報を取得する。
例として記憶装置１０４に、図１０で示される機能情報が存在するとし、機能管理部１０３が″ｄｂ″に関する機能情報取得要求を受け付けた場合の動作を説明する。
機能管理部１０３は、まず″ｄｂ″を検索することにより、記憶装置１０４に″ｄｂ（ｒｄｂ，ｋｖｓ）″の定義を発見し、″ｄｂ″の右側に丸括弧で括られ、″ｄｂ″に関連付けされた機能モジュールＩＤの集合が存在することから、それらの機能モジュールＩＤについて再帰的に検索を実施する。
″ｄｂ″の要素である″ｒｄｂ″と″ｋｖｓ″とは、いずれも他に関連付けられた機能モジュールＩＤをもつため、機能管理部１０３は、それぞれ″ｍｙｓｑｌ″、″ｐｏｓｔｇｒｅｓｑｌ″、″ｏｒａｃｌｅ″と″ｓｉｍｐｌｅｄｂ″、″ｃｏｕｃｈｄｂ″とを記憶装置１０４から得る。機能管理部１０３は、これらの機能モジュールＩＤについてさらに再帰的に検索を実施すると、これ以上関連付けされたＩＤは発見されないことを認識する。そのため、機能管理部１０３は、″ｍｙｓｑｌ″、″ｐｏｓｔｇｒｅｓｑｌ″、″ｏｒａｃｌｅ″と″ｓｉｍｐｌｅｄｂ″、″ｃｏｕｃｈｄｂ″とを検証部１０１に返答する。
本実施の形態によれば、多くの機能モジュールに関連する依存性要件をより判り易く効率的に表現できるので、当該依存性要件に関するシステムと、そのシステムを構成するコンポーネントとの間の整合性の検証作業を効率化できる。
＜第３の実施形態＞
［構成の説明］
本発明の第３の実施の形態では、構成情報の依存性を指定する部分と、機能情報とのそれぞれに対してユーザ等が属性を付加できる構成、並びに、機能管理部１０３が受け付ける機能情報取得要求にユーザ等が属性の情報を付加できる構成が第１の実施の形態と異なる。それ以外の構成は、第１の実施の形態と同様である。第１の実施の形態と同様の要素については、図１と同様の記号を付し、本実施形態における詳細な説明は省略する。
図１１は、本発明を実施する第３の実施の形態の構成管理部１０２が管理する構成情報の一例である。
図１１の例に示すように、本実施の形態における構成情報は、依存性を指定する部分に属性を付加できる点が第１の実施の形態における構成情報と異なる。図１１に示す例では、システムＡの依存する機能モジュールＩＤとして″ｒｄｂ″が指定されており、その属性“ａｔｔｒｉｂｕｔｅ”として″ｏｓｓ″が付加されている。
図１２は、第３の実施の形態に係る機能管理部１０３が管理する機能情報の一例である。
図１２の例に示すように、本実施の形態における機能情報は、各機能モジュールＩＤに対してユーザ等が属性を付加できるという構成が、第１の実施の形態における機能情報と異なる。
この例では、付加された属性は、各要素の右側に配置した角括弧内に属性名と値の組として記述され、属性名と値とは、記号″＝″によって区切る形式で表されている。
すなわちこの例では、″ｍｙｓｑｌ″と″ｐｏｓｔｇｒｅｓｑｌ″とのａｔｔｒｉｂｕｔｅ属性として″ｏｓｓ″が付加され、″ｏｒａｃｌｅ″の属性“ａｔｔｒｉｂｕｔｅ”として″ｃｏｍｍｅｒｃｉａｌ″が付加されている。
図１３は、第３の実施の形態における機能情報取得要求の一例である。
図１３に示すように、本実施の形態において機能管理部１０３が受け付ける機能情報取得要求は、取得対象を示す機能モジュールＩＤに対して属性を追加できるという構成が、第１の実施の形態における機能情報取得要求と異なる。図１３に例示するように、付加された属性は、取得対象の機能モジュールＩＤの右側に配置した角括弧内に属性名と値との組として記述され、属性名と値とは″＝″によって区切る形式で表されている。すなわちこの例では、取得対象の機能モジュールＩＤが″ｒｄｂ″であり、その属性“ａｔｔｒｉｂｕｔｅ”として″ｏｓｓ″が付加されている。
［動作の説明］
次に、本発明の第３の実施の形態における検証装置１００の動作例について説明する。
本実施の形態における検証装置１００の動作は、図９に示したステップＳ１０４、Ｓ１０５、Ｓ１０７、Ｓ１０８については第１の実施の形態と同様である。これに対して、本実施形態では、ステップＳ１０６において、機能管理部１０３が、機能情報取得要求に含まれる取得対象の機能モジュールＩＤだけでなく、属性までが一致する機能モジュールＩＤのみを検証部１０１に返答するという構成が第１の実施の形態と異なる。
すなわち、本実施形態において、機能管理部１０３は、検証部１０１からの機能情報取得要求を受付けると、当該要求において指定された機能モジュールＩＤを基に、当該ＩＤと関連付けられた全ての機能モジュールＩＤを検索する。
続いて、機能管理部１０３は、前記要求において属性が指定されている場合には、前記検索により発見された機能モジュールＩＤのうち、当該属性と同一の属性が付加された機能モジュールＩＤのみを抽出し、これを最終的に返答する機能モジュールＩＤとする。
例として機能管理部１０３に図１２で示される機能情報が存在するとし、機能管理部１０３が図１３で示される機能情報取得要求を受け付けた場合の動作例を説明する。
まず機能管理部１０３は、″ｒｄｂ″に関連付けられた機能モジュールＩＤを検索することにより、″ｍｙｓｑｌ［ａｔｔｒｉｂｕｔｅ＝ｏｓｓ］″、″ｐｏｓｔｇｒｅｓｑｌ［ａｔｔｒｉｂｕｔｅ＝ｏｓｓ］″、″ｏｒａｃｌｅ［ａｔｔｒｉｂｕｔｅ＝ｃｏｍｍｅｒｃｉａｌ］″という３つの機能モジュールＩＤを発見する。
続いて、機能管理部１０３は、機能情報取得要求で示された取得対象である″ｒｄｂ″には属性″ａｔｔｒｉｂｕｔｅ＝ｏｓｓ″が付加されているため、前記検索された機能モジュールＩＤのうちａｔｔｒｉｂｕｔｅ属性の値が″ｏｓｓ″であるもののみを抽出し、検証部１０１に返答する機能モジュールＩＤを″ｍｙｓｑｌ″、″ｐｏｓｔｇｒｅｓｑｌ″と設定する。
機能管理部１０３は、検索の際には機能情報取得要求で付加された属性名と値の組を持つ要素のみを抽出していたが、該当する属性を持たない要素を抽出したり、該当する属性名と値の組を持つ要素以外を抽出したりしてもよい。機能管理部１０３は、さらにメタ属性の追加により、上述のような属性による機能モジュールＩＤの抽出方法を既存の方法により制御してもよい。
本実施の形態によれば、機能モジュールの分類が複雑化した場合でも依存性要件を効率的に表現でき、当該依存性要件に関するシステムとそのコンポーネントとの間の整合性の検証作業を効率化できる。
＜第４の実施形態＞
［構成の説明］
図１４は、本発明を実施する第４の実施の形態の検証装置１００の構成例を示すブロック図である。
図１４に示されるように、本発明の第４の実施の形態における検証装置１００は、特定のＩＤ体系におけるＩＤ（外部体系ＩＤ）と、機能情報内における機能モジュールＩＤとを関連付ける機能解決部４０１を備えるという構成が第１の実施の形態と異なる。また、特定形式のファイルから、当該ファイルに含まれる外部体系ＩＤを抽出するファイル処理モジュール群４０２を備えるという構成が第１の実施の形態と異なる。
第１の実施の形態と同様の要素については図１と同様の記号を付して詳細な説明を省略する。
記憶装置１０４は、機能解決情報を記録する。機能解決情報とは、係る特定のＩＤ体系におけるＩＤ（外部体系ＩＤ）と、機能管理部１０３が管理する機能モジュールＩＤとを関連付ける情報である。機能解決情報は、機能解決部４０１によって管理される。機能解決部４０１は、機能管理部１０３および記憶装置１０４と通信可能に接続される。
図１５は、機能解決部４０１が管理する機能解決情報の一例である。図１５に示す例では、あるＩＤ体系における外部体系ＩＤはタグ“ａｌｉａｓｅｓ”内に記述され、当該タグの属性“ｔｙｐｅ”によって当該ＩＤ体系を表す情報が記述される。タグ“ａｌｉａｓｅｓ”内には、複数のタグ“ａｌｉａｓ”が列記され、各タグ“ａｌｉａｓ”には、前記ＩＤ体系における外部体系ＩＤと機能モジュールＩＤとを関連付ける情報が記述される。例えば、タグ“ａｌｉａｓ”では、属性“ｎａｍｅ”に前記ＩＤ体系における外部体系ＩＤが記述され、前記タグ内の属性“ｖａｌｕｅ”によって前記外部体系ＩＤと対応付けられる機能モジュールＩＤが記述される。
図１５に示す例では、まずタグ“ａｌｉａｓｅｓ”の属性“ｔｙｐｅ”により″ｍａｖｅｎ″のＩＤ体系における外部体系ＩＤと機能モジュールＩＤとを対応付ける情報を記述することが宣言されている。また、図１５に示す例では、係るタグ“ａｌｉａｓｅｓ”内のタグ“ａｌｉａｓ”により“ｍａｖｅｎ”のＩＤ体系における“ｍｙｓｑｌ：ｍｙｓｑｌ−ｃｏｎｎｅｃｔｏｒ−ｊａｖａ：５．１．１７″と、機能モジュールＩＤ″ｍｙｓｑｌ″とが記号″＝″によって対応付けられている。
図１６は、第４の実施の形態の構成管理部１０２が管理する構成情報の一例であり、図１７は、第４の実施の形態の構成管理部１０２が参照する外部の記憶装置等に格納された外部ファイルの一例である。
本実施の形態では、システムやそのコンポーネントの依存性要件に関する情報を外部ファイルの参照によって定義することができる。例えば、図１６に示す構成情報は、システムＢの依存性が外部ファイルの参照によって定義される場合に、タグ“ｄｅｐｅｎｄｅｎｃｙ”内において前記外部ファイルの位置情報をｒｅｆ属性で指定し、当該ファイルの形式を属性“ｔｙｐｅ”によって指定している。すなわち、図１６に示す構成情報では、システムＢの依存性が″／ｘｘｘ／ｘｘｘ／ｐｏｍ．ｘｍｌ″で指定される外部ファイルによって定義され、そのファイル形式（外部ファイルの形式名）は形式“ｍａｖｅｎ”であることが示されている。ここでは、ＩＤ体系を示す名称と外部ファイルの形式名とが関連付けられており同一の名称となっているが、これらは同一でなくても構わない。
図１７は、前記外部ファイルの内容を例示している。“ｍａｖｅｎ”のファイル“ｐｏｍ．ｘｍｌ”では、タグ“ｄｅｐｅｎｄｅｎｃｉｅｓ”によってモジュールへの依存性が記述され、個々の依存性の情報はタグ“ｄｅｐｅｎｄｅｎｃｙ”によって記述される。
タグ“ｄｅｐｅｎｄｅｎｃｙ”はタグ“ｇｒｏｕｐＩｄ”、タグ“ａｒｔｉｆａｃｔＩｄ”、タグ“ｖｅｒｓｉｏｎ”などから構成される。“ｍａｖｅｎ”では、最低限これら３つの情報（タグ“ｇｒｏｕｐＩｄ”、タグ“ａｒｔｉｆａｃｔＩｄ”、タグ“ｖｅｒｓｉｏｎ”）によって依存性が定義される。この例では“ｇｒｏｕｐＩｄ”が″ｍｙｓｑｌ″、“ａｒｔｉｆａｃｔＩｄ”が″ｍｙｓｑｌ−ｃｏｎｎｅｃｔｏｒ−ｊａｖａ″、“ｖｅｒｓｉｏｎ”が″５．１．１７″によって依存性が定義されている。
機能解決部４０１が解決可能な外部ファイルの形式は、解決可能形式情報として機能解決部４０１によって管理され、記憶装置１０４に記録される。図１８は、第４の実施の形態における機能解決部４０１が管理する解決可能形式情報の一例である。
図１８に例示する解決可能形式情報では、外部ファイルの形式名と、当該外部ファイルの形式名が示す形式のファイルから外部体系ＩＤを抽出する処理モジュールの名前（モジュール名）と、の２つの項目からなる表形式の情報が記録される。例えば、モジュール１は、形式“ｍａｖｅｎ”の外部ファイルから外部体系ＩＤを抽出することができる（形式“ｍａｖｅｎ”は、モジュール１によって解決可能である）。
また、処理モジュールは、形式ごとのプラグインとして機能解決部４０１から呼び出し可能な状態でユーザ等が組み込んでおいてもよい。
図１９は、本発明を実施する第４の実施の形態の機能情報取得要求の一例である。
本実施の形態における機能情報取得要求は、例えば、情報取得対象の機能モジュールＩＤの代わりに参照する外部ファイルの位置情報と、その外部ファイルの形式名と、を含んでいる。
図１９に示す例では、外部ファイルの形式名とファイルの位置とが、″：″によって区切られて記述されている。具体的には、図１９では、外部ファイルの形式名として″ｍａｖｅｎ″、ファイルの位置として″／ｘｘｘ／ｘｘｘ／ｐｏｍ．ｘｍｌ″が指定されている。
本実施の形態における機能管理部１０３は、上述の外部ファイルの形式名とファイルの位置情報を基に機能解決部４０１を用いて機能情報を取得する。
［動作の説明］
次に、本発明を実施する第４の実施の形態における検証装置１００の動作例について図２０を用いて説明する。第１の実施の形態と同様の動作については図９と同様の記号を付し、詳細な説明を省略する。ステップＳ１０６以外は図９で示す第１の実施の形態の動作と同様であるから、該ステップについて説明する。
図２０は、第４の実施の形態における機能管理部１０３の機能情報取得処理の動作例を示すフローチャートである。本実施の形態における検証部１０１は、検証処理の中で、構成管理部１０２から取得した構成情報内のタグ“ｄｅｐｅｎｄｅｎｃｙ”に記載された情報について、図２０に示す機能モジュールＩＤの取得処理を実施する。
まず検証部１０１は、タグ“ｄｅｐｅｎｄｅｎｃｙ”の内容を確認し、当該タグ“ｄｅｐｅｎｄｅｎｃｙ”内で外部ファイルを参照しているかを判断する（ステップＳ４０１）。
係る外部ファイルを参照している場合（ステップＳ４０１で「ＹＥＳ」の場合）に、検証部１０１は、タグ“ｄｅｐｅｎｄｅｎｃｙ”の属性“ｔｙｐｅ”に指定された外部ファイルの形式名および属性“ｒｅｆ”に記述された外部ファイルの位置を取得し、これらの情報を含む機能情報取得要求（図１９参照）を機能管理部１０３に送信する（ステップＳ４０４）。例えば、図１６では、タグ“ｄｅｐｅｎｄｅｎｃｙ”の属性“ｔｙｐｅ”に指定された外部ファイルの形式名は“ｍａｖｅｎ”であり、属性“ｒｅｆ”に記述された外部ファイルの位置は、“／ｘｘｘ／ｘｘｘ／ｐｏｍ．ｘｍｌ”である。また、これらの情報を含む機能情報取得要求は、図１９に示すように、１行目の“ｇｅｔｆｕｎｃ”により当該要求が機能情報取得要求であることを示し、続く２行目の記号″：″の前が外部ファイルの形式名、記号″：″の後が外部ファイルの位置情報を示している。
機能管理部１０３は、受け付けた機能情報取得要求に″：″が含まれるかを判断し、含まれる場合には当該機能情報取得要求を機能解決部４０１に転送する（ステップＳ４０５）。
機能解決部４０１は、機能情報取得要求を受け付けると、記号″：″の前の部分を外部ファイルの形式名として切り出し、記号″：″の後の部分を外部ファイルの位置情報として切り出す。そして、機能解決部４０１は、前記外部ファイルの位置情報に基づいて外部ファイル（図１７参照）を取得する。また、機能解決部４０１は、解決可能形式情報（図１８参照）を参照することにより、前記外部ファイルの形式名に対応するファイル処理モジュール群４０２内の処理モジュールを特定する。そして、機能解決部４０１は、前記取得した外部ファイルを、特定した処理モジュールにおいて処理することで、当該形式の体系に基づく外部体系ＩＤを取得する（ステップＳ４０６）。
例えば検証部１０１から機能管理部１０３に対して図１９に示す機能情報取得要求が送信され、図１７に示す外部ファイルと図１８に示す解決可能形式情報が存在する場合を考える。この場合、機能管理部１０３は、まず″ｍａｖｅｎ″を外部ファイルの形式名、″／ｘｘｘ／ｘｘｘ／ｐｏｍ．ｘｍｌ″を外部ファイルの位置情報として取得する。そして機能管理部１０３は、図１７に示す外部ファイルを取得する。さらに、機能管理部１０３は、図１８に示す解決可能形式情報を参照することにより、″ｍａｖｅｎ″に対応する処理モジュールが″モジュール１″であることを特定し、前記取得した外部ファイルをモジュール１に送信する。
モジュール１には、形式が“ｍａｖｅｎ”であるファイルから、“ｍａｖｅｎ”における外部体系ＩＤを抽出する処理が実装されている。モジュール１は、図１７に示すファイルから、″ｇｒｏｕｐＩｄ″、″ａｒｔｉｆａｃｔＩｄ″、″ｖｅｒｓｉｏｎ″なる各タグによって記述された情報を取得し、取得したこれらの情報を″：″によって連結し、″ｍｙｓｑｌ：ｍｙｓｑｌ−ｃｏｎｎｅｃｔｏｒ−ｊａｖａ：５．１．１７″の外部体系ＩＤを取得する。
次に、機能解決部４０１は、機能解決情報（図１５参照）を参照し、ファイル処理モジュール群４０２内のモジュールが取得した外部体系ＩＤを、機能管理部１０３が管理する機能情報に対応した機能モジュールＩＤへ変換し、変換によって得られた機能モジュールＩＤを機能管理部１０３に送信する（ステップＳ４０７）。機能管理部１０３は、第１の実施の形態と同様に、取得した機能モジュールＩＤ、あるいは、当該機能モジュールＩＤに関連付けられた機能モジュールＩＤを取得する。機能管理部１０３は、これらの機能モジュールＩＤを検証部１０１に送信する。そして、検証部１０１は、機能管理部１０３から検証対象システムおよびそのコンポーネントの依存する機能モジュールＩＤを取得する（ステップＳ４０３）。
タグ“ｄｅｐｅｎｄｅｎｃｙ”内で外部ファイルを参照していない場合（ステップＳ４０１で「ＮＯ」の場合）には、その後の動作は第１の実施の形態における機能情報の取得処理（ステップＳ１０６）と同様である。すなわち、検証部１０１は、タグ“ｄｅｐｅｎｄｅｎｃｙ”の属性“ｎａｍｅ”に記述された機能モジュールＩＤを取得し、当該機能モジュールＩＤを含む機能情報取得要求を機能管理部１０３に送信（ステップＳ４０２）する。検証部１０１は、機能管理部１０３から検証対象システムおよびそのコンポーネントの依存する機能モジュールＩＤを取得する（ステップＳ４０３）。
なお、上述した説明では、ファイル処理モジュール群４０２内のモジュールが外部ファイルから外部体系ＩＤを抽出した後、機能解決部４０１が外部体系ＩＤを機能モジュールＩＤに変換する例を説明した。しかしながら、本発明はこの例には限定されず、例えば、ファイル処理モジュール群４０２内のモジュールが機能解決情報を参照して外部体系ＩＤを機能モジュールＩＤに直接変換してもよい。また、機能解決情報は記憶部１０４ではなく図示しない外部の記憶部に格納されてもよい。
本実施の形態によれば、システムやコンポーネントの構成情報内に記述された依存性を定義するＩＤの体系と、機能情報内における機能モジュールＩＤの体系とが異なっていても、システムとコンポーネントとの間の依存性要件の整合性の検証を実施できる。また、本実施の形態によれば、ＩＤの記述の柔軟性を図ることができる。これにより、利用者は、他のシステム開発支援機能の利用のために記述した依存性を定義する情報を用いることで、それ以外に情報を追加することなくシステムと、そのコンポーネントとの間の依存要件の整合性に関する検証を実施できる。
＜第５の実施形態＞
次に、本発明の第５の実施の形態について説明する。
本実施の形態に係る検証装置１００は、記憶装置１０４と、機能管理部１０３と、検証部１０１とを有する。
記憶装置１０４は、機能モジュールＩＤと、機能モジュールＩＤと他の機能モジュールＩＤとの関連付け情報とを記憶している。
機能管理部１０３は、外部から入力された機能モジュールＩＤ（検証対象の特定の機能モジュールＩＤ）を取得する。該ＩＤあるいは該ＩＤを包含する情報は、例えば検証部１０１から入力される。
機能管理部１０３は、記憶装置１０４を参照して、当該機能モジュールＩＤに他の機能モジュールが関連付けられている場合には、当該他の機能モジュールＩＤを抽出して検証部１０１に出力する。また、機能管理部１０３は、入力された機能モジュールＩＤが他の機能モジュールＩＤと関連付けされていない場合には、当該入力された機能モジュールＩＤそのもの、あるいは、関連付けがないことを表す情報を検証部１０１に出力する。
検証部１０１は、システムが依存する１以上の機能モジュールの各々と対応する機能モジュールＩＤを機能管理部１０３に入力する。その結果、検証部１０１は、機能管理部１０３から、機能モジュールＩＤあるいは関連付けがないことを表す情報を取得する。
検証部１０１が、機能モジュールＩＤを取得した場合には、これを第１の機能モジュール集合とする。
検証部１０１が、関連付けがないことを表す情報を取得した場合には、機能管理部１０３に入力した機能モジュールＩＤを第１の機能モジュール集合とする。
すなわち、検証部１０１は、システムが依存する機能モジュールＩＤの集合を第１の機能モジュール集合とする。
検証部１０１は、システムを構成するコンポーネントが依存する１以上の機能モジュールの各々と対応する機能モジュールＩＤを機能管理部１０３に入力する。その結果、検証部１０１は、機能管理部１０３から、機能モジュールＩＤあるいは関連付けがないことを表す情報を取得する。
検証部１０１が、機能モジュールＩＤを取得した場合には、これを第２の機能モジュール集合とする。
検証部１０１が、関連付けがないことを表す情報を取得した場合には、機能管理部１０３に入力した機能モジュールＩＤを第２の機能モジュール集合とする。
すなわち、検証部１０１は、コンポーネントが依存する機能モジュールＩＤの集合を第２の機能モジュール集合とする。
検証部１０１は、第２の機能モジュールＩＤ集合が、第１の機能モジュールＩＤ集合を包含している場合に、整合であることを表す情報を入出力装置１０１等に出力する。また、検証部１０１は、それ以外の場合に、不整合であることを表す情報を入出力装置１０１に出力してもよい。また、検証部１０１は、機能管理部１０３から取得した第２の機能モジュールＩＤ集合が、第１の機能モジュールＩＤ集合の空集合でない真部分集合である場合に不整合であることを表す情報を入出力装置１０１等に出力してもよい。
本実施形態によれば、機能モジュールへの依存性に関し、システムの依存性とコンポーネントの依存性との間の整合性を検証可能である。それゆえ、再利用性の高いシステムの開発が促進される。また、本実施の形態によれば、制約条件までを含む依存性要件の設定が容易になるので、作業工数が削減できる他、設定漏れなどのミスを防止できる。
以上、上述した各実施形態を模範的な例として本発明を説明した。しかしながら、本発明は、上述した各実施形態には限定されない。即ち、本発明は、本発明のスコープ内において、当業者が理解し得る様々な態様を適用することができる。
この出願は、２０１１年１０月１８日に出願された日本出願特願２０１１−２２９０４３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【０００９】
１０        情報処理装置（コンピュータ）
１１        ＣＰＵ
１２        メモリ
１３        通信インタフェース（Ｉ／Ｆ）
１４        記憶装置
１５        コンピュータ・プログラム
１６        ドライブ装置
１７        記憶媒体
２０        通信ネットワーク
１００      検証装置
１０１      検証部
１０２      構成管理部
１０３      機能管理部
１０４      記憶装置
１０５      フロントエンド
１１０      利用者端末
４０１      機能解決部
４０２      ファイル処理モジュール群
【図１】
0006007916.tif 000002
【図２】
0006007916.tif 000003
【図３】
0006007916.tif 000004
【図４】
0006007916.tif 000005
【図５】
0006007916.tif 000006
【図６】
0006007916.tif 000007
【図７】
0006007916.tif 000008
【図８】
0006007916.tif 000009
【図９】
0006007916.tif 000010
【図１０】
0006007916.tif 000011
【図１１】
0006007916.tif 000012
【図１２】
0006007916.tif 000013
【図１３】
0006007916.tif 000014
【図１４】
0006007916.tif 000015
【図１５】
0006007916.tif 000016
【図１６】
0006007916.tif 000017
【図１７】
0006007916.tif 000018
【図１８】
0006007916.tif 000019
【図１９】
0006007916.tif 000020
【図２０】
0006007916.tif 000021
【図２１】
0006007916.tif 000022
【図２２】
0006007916.tif 000023