JPWO2017033441A1 - システム構築支援システム、方法および記憶媒体 - Google Patents

Abstract

システム構築支援システムは、構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも１つ以上有するコンポネントを定義づける情報であるコンポネント定義であって、該フィールドの情報と、該フィールドに対応づけられる構成要素に対する設定に関する設定定義とを含みうるコンポネント定義を用いたコンポネントの指定と、フィールドに対する構成要素の割当定義とを少なくとも含むシステム定義を入力するシステム定義入力手段５０１と、システム定義およびコンポネント定義に基づいて、指定されたコンポネントのフィールドに構成要素を対応づけるとともに、フィールドに対する設定内容を、対応づけられた構成要素に反映する設定の付与処理を行う設定付与手段５０２とを備える。

Description

本発明は、システムの構築を支援するシステム構築支援システム、システム構築支援方法およびシステム構築支援プログラムが記録された記憶媒体等に関する。

システムのコンポネント化とは、システムをより粗い抽象的な構成要素の集合として効率的に定義可能とする技術である。一般に、システムを構成するには細かい具体的な構成要素を多数記述する必要がある。しかしながら巨大なシステムや複数のシステムを俯瞰すると、同様の構成要素やその集まりが複数現れることがある。こうした構成要素群を、抽象的なパターンとして定義しこれを再利用可能とすることにより、構成要素の集まりを簡潔に記述できるようになる。このように再利用可能に抽象化された１つ以上の構成要素からなる構成要素群のパターンは、一般にコンポネントと呼ばれる。

このようなコンポネントの組み合わせによってシステムを定義する仕組みを有していれば、コンポネントの組み合わせを変更するだけで、似て非なる多様なシステムを素早く確実に定義することができるようになる。例えば仮想マシン（以下ＶＭと略記）、ミドルウェア（以下ＭＷと略記）、アプリケーション（以下ＡＰＰと略記）からなるシステムを定義したい場合を考える。このようなとき、ＶＭの定義に必要な要素をＶＭコンポネント、ＭＷの定義に必要な要素をＭＷコンポネント、ＡＰＰの定義に必要な要素をＡＰＰコンポネントとしてそれぞれ定義しておき、これら予め定義された要素群のコンポネントを必要に応じて組み合わせてシステム全体を定義する。ここで、例えばＭＷの部分だけ異なる種類のコンポネントに挿げ替えることにより、ＭＷだけが異なるシステムの全体をわずかな変更により再定義できる。

このようなシステムのコンポネント化を実現するためのコンポネントの記述に関する標準仕様として、非特許文献１がある。

一般に、可能なコンポネントの組み合わせには限りがあり、正しい組み合わせが指定されなければ意味のあるシステム定義は完成しない。例えば上記のＡＰＰがＭＷ上でのみ動作可能である場合には、ＶＭとＡＰＰを直接組み合わせても意味のあるシステム定義は完成しない。非特許文献１に記載の仕様に沿ってコンポネントを定義することにより、可能なコンポネントの組み合わせを適切かつ統一的に記述できる。また、当該仕様に準拠したツールによってその組み合わせを管理したり適切さを検証したりすることができる。

また、コンポネントの組み合わせを利用してシステムの配備に必要な情報を定義するための標準仕様として、非特許文献２がある。この仕様によれば、特定のコンポネントの組み合わせに対して、当該組み合わされたコンポネントを実体化して配備するための処理内容が合わせて定義され、定義された処理を呼び出すことで当該コンポネントの実体を配備することができる。当該コンポネントの組み合わせを、さらに別のコンポネントと組み合わせることも可能である。その際には、新たな組み合わせに対して、配備のための処理内容を定義するために、既に組み合わされているコンポネントに定義された処理を再利用することもできる。

M.Edwards, "Service Coponent Architecture(SCA)", [online], 2007, [２０１５年８月３日検索], インターネット<URL:http://www.oasis-opensca.org/sca> T.Binz, G.Breiter, F.Leyman, and T.Spatzier, "Portable cloud services using tosca", Internet Computing, IEEE, vol.16, no.3, 2012, p.80-85.

しかしながら非特許文献２に記載の方法では、コンポネントの組み合わせを規定する度に、組み合わせにより定まるコンポネント間の関連性に基づく処理内容を定義する必要がある点が問題となる。例えば、上記のＡＰＰとＭＷとＶＭからなるシステムの配備に必要な処理内容において、ＭＷだけ異なる種類のコンポネントに挿げ替えた場合には、実施すべき処理内容を変更しなければならない場合がある。

より簡素な例を図７４に示す。図７４は、コンポネントの組み合わせにより規定されるシステム定義の一例を示す説明図である。図中の３つの角丸の長方形はコンポネントを示している。本例のシステムは、あるＡＰＰに対応したＡＰＰ１コンポネントと、あるＭＷに対応したＭＷ１コンポネントと、あるＶＭに対応したＶＭ１コンポネントの３つのコンポネントを有している。また、二重線はコンポネント間の連結を示している。各コンポネント内の長方形は、当該コンポネントが対応する構成要素としての配備処理を示している。例えば、図中のＡＰＰ１コンポネントには、対応するアプリケーションの配備処理に相当する構成要素“app”が定義されている。また、例えば、図中のＭＷ１コンポネントには、ミドルウェアパッケージの配備処理（例えば、コンフィグレーションマネージメントシステムが提供する当該ミドルウェアのパッケージリソースのインストール処理等）に相当する構成要素“package”が定義されている。また、例えば、図中のＶＭ１コンポネントには、ＶＭの配備処理（例えば、起動処理等）に相当する構成要素“vm”が定義されている。

ここで、図中の各構成要素の間にある点線の矢印は、当該構成要素間の依存性を示している。ここで依存性とは、あることをするためには別のあることをする必要がある、という二者間の関連性のうち事前の必要性を示す概念である。図の例では、“app”構成要素が“package”構成要素と“vm”構成要素に依存するため、“app”構成要素を配備（実行）する前に“package”構成要素と“vm”構成要素とが配備されなければならない。また、“package”構成要素が“vm”構成要素に依存するため、“package”構成要素を配備する前に“vm”構成要素が配備されなければならない。これらの依存性により、ＶＭの起動、ＭＶのインストール、ＡＰＰの起動という正しい処理順序が導出される。このようなコンポネントを跨る依存性は、相手先のコンポーネントが決定して初めて指定が可能となる要素、すなわち特定のコンポネントの組み合わせに対して初めて指定が必要となる要素であり、コンポネントの組み合わせ定義に付加する形で定義されてきた。そのため、異なるコンポネントの組み合わせ定義においては、異なる依存性の指定が必要となる。

図７５は、コンポネントの組み合わせにより規定されるシステム定義の他の例を示す説明図である。図７５には、図７４においてＭＷ１コンポネントが対応しているＭＷとは異なるＭＷを利用する場合に、当該ＭＷに対応したＭＷ２コンポネントを用いてシステム定義がされた例が示されている。ＭＷ１コンポネントからＭＷ２コンポネントへの変更に伴い、ＡＰＰ１コンポネントの“app”構成要素の依存先が、ＭＷ１コンポネントの“package”構成要素から、ＭＷ２コンポネントが有する構成要素であり、当該ＭＷの配備処理（例えば、サービス処理の起動等）に相当する“service”構成要素に変更されている。また、ＶＭ１コンポネントの“vm”構成要素に対して依存関係を有する構成要素が、ＭＷ１コンポネントの“package”構成要素であったものが、ＭＷ２コンポネントのpackage”構成要素に変更されている。

このように、コンポネントの内部に踏み込んで依存関係が結ばれる仕様の場合、システム定義において一部のコンポネントを別のコンポネントに変更すると、差し替えられたコンポネントと依存関係を有していた他のコンポネントに対して同じような依存関係を示す設定を再度行わなければならず、再利用性が低いという問題があった。

そこで、本発明は、コンポネントの組み合わせごとにその組み合わせに応じた設定を追加しなくてもよいなど、システム定義の容易性を向上させることが目的である。

本発明によるシステム構築支援システムは、構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも１つ以上有するコンポネントを定義づける情報であるコンポネント定義であって、定義対象とされるコンポネントが有するフィールドの情報であるフィールド定義と、フィールドに対応づけられる構成要素に対する設定に関する情報である設定定義とを含むことができるコンポネント定義を用いたコンポネントの指定と、コンポネントが有するフィールドに対する構成要素の割り当てに関する割当定義とを少なくとも含むシステム定義を入力するシステム定義入力手段と、システム定義およびコンポネント定義に基づいて、指定されたコンポネントのフィールドに具体的な構成要素を対応づけるとともに、フィールドに対して定義された設定内容を、フィールドに対応づけられた構成要素に反映することにより、対象システムを構成する構成要素に対する設定の付与を行う設定付与手段とを備えたことを特徴とする。

本発明によるシステム構築支援方法は、情報処理装置が、構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも１つ以上有するコンポネントを定義づける情報であるコンポネント定義であって、定義対象とされるコンポネントが有するフィールドの情報であるフィールド定義と、フィールドに対応づけられる構成要素に対する設定に関する情報である設定定義とを含むことができるコンポネント定義を用いたコンポネントの指定と、コンポネントが有するフィールドに対する構成要素の割り当てに関する割当定義とを少なくとも含むシステム定義を受け付けると、システム定義およびコンポネント定義に基づいて、指定されたコンポネントのフィールドに具体的な構成要素を対応づけるとともに、フィールドに対して定義された設定内容を、フィールドに対応づけられた構成要素に反映することにより、対象システムを構成する構成要素に対する設定の付与を行うことを特徴とする。

本発明によるシステム構築支援プログラムが記録された記憶媒体には、コンピュータに、構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも１つ以上有するコンポネントを定義づける情報であるコンポネント定義であって、定義対象とされるコンポネントが有するフィールドの情報であるフィールド定義と、フィールドに対応づけられる構成要素に対する設定に関する情報である設定定義とを含むことができるコンポネント定義を用いたコンポネントの指定と、コンポネントが有するフィールドに対する構成要素の割り当てに関する割当定義とを少なくとも含むシステム定義を受け付けると、システム定義およびコンポネント定義に基づいて、指定されたコンポネントのフィールドに具体的な構成要素を対応づけるとともに、フィールドに対して定義された設定内容を、フィールドに対応づけられた構成要素に反映することにより、対象システムを構成する構成要素に対する設定の付与を行う処理を実行させるコンピュータ・プログラムが記録される。

本発明によれば、システム定義の容易性を向上させることができる。

第１の実施形態のシステム構築支援システムの構成例を示すブロック図。 ＧＵＩによるＵｂｕｎｔｕコンポネントの定義例を示す説明図。 ＪＳＯＮによるＵｂｕｎｔｕコンポネントの定義例を示す説明図。 システム定義入力部００１に入力されるシステム定義の例を示す説明図。 ＪＳＯＮによるシステム定義の例を示す説明図。 システム構成出力部００２が出力するシステム構成情報の例を示す説明図。 ＪＳＯＮによるシステム構成情報の例を示す説明図。 システム定義の他の例を示す説明図。 システム構成情報の他の例を示す説明図。 第１の実施形態の動作の一例を示すフローチャート。 第１の実施形態のシステム定義展開部のシステム定義展開プロセスを示すフローチャート。 第１の実施形態におけるシステム定義展開後の出力情報の例を示す説明図。 第１の実施形態の構成要素設定部の構成要素設定プロセスを示すフローチャート。 システム定義の他の例を示す説明図。 システム構成情報の他の例を示す説明図。 ＧＵＩによるＯＳポートの定義例を示す説明図。 ＪＳＯＮによるＯＳポートの定義例を示す説明図。 第２の実施形態における対象システムのＧＵＩによる定義例を示す説明図。 ＪＳＯＮによるシステム定義の例を示す説明図。 第２の実施形態のＵｂｕｎｔｕコンポネントのＧＵＩによる定義例を示す説明図。 第２の実施形態のＵｂｕｎｔｕコンポネントのＪＳＯＮによる定義例を示す説明図。 第２の実施形態のＴｏｍｃａｔコンポネントのＧＵＩによる定義例を示す説明図。 第２の実施形態のＴｏｍｃａｔコンポネントのＪＳＯＮによる定義例を示す説明図。 第２の実施形態のＴｏｍｃａｔコンポネントのＧＵＩによる他の定義例を示す説明図。 第２の実施形態のＴｏｍｃａｔコンポネントのＪＳＯＮによる他の定義例を示す説明図。 第２の実施形態の動作の一例を示すフローチャート。 第２の実施形態のシステム定義展開部のシステム定義展開プロセスを示すフローチャート。 第２の実施形態のシステム定義展開部のコンポネント読み込みプロセスを示すフローチャート。 第２の実施形態におけるコンポネント読み込み後のデータ例を示す説明図。 第２の実施形態におけるシステム定義展開後のデータ例を示す説明図。 第２の実施形態の構成要素設定部の構成要素設定プロセスを示すフローチャート。 第２の実施形態における参照解決後のフィールド間の関係性を示す説明図。 第２の実施形態における参照解決後のある構成要素のデータ例を示す説明図。 第２の実施形態における設定付与後の構成要素間の関係性を示す説明図。 第２の実施形態における設定付与後のある構成要素のデータ例を示す説明図。 第２の実施形態のＧＵＩによるシステム構成情報の例を示す説明図。 第２の実施形態のＪＳＯＮによるシステム構成情報の例を示す説明図。 第３の実施形態のＯＳポートのＧＵＩによる定義例を示す説明図。 第３の実施形態のＯＳポートのＪＳＯＮによる定義例を示す説明図。 第３の実施形態のシステム定義の例を示す説明図。 第３の実施形態のＧＵＩによるＵｂｕｎｔｕコンポネントの定義例を示す説明図。 第３の実施形態のＧＵＩによるＴｏｍｃａｔコンポネントの定義例を示す説明図。 第３の実施形態におけるシステム定義展開後のデータ例を示す説明図。 第４の実施形態のフィールドおよび構成要素のＧＵＩによる表現例を示す説明図。 第４の実施形態のＧＵＩによるシステム定義の例を示す説明図。 第４の実施形態のＧＵＩによるＯＳポートの定義例を示す説明図。 第４の実施形態のＪＳＯＮによるＯＳポートの定義例を示す説明図。 第４の実施形態のＧＵＩによるＷＡＳポートの定義例を示す説明図。 第４の実施形態のＪＳＯＮによるＷＡＳポートの定義例を示す説明図。 第４の実施形態のＵｂｕｎｔｕコンポネントのＧＵＩによる定義例を示す説明図。 第４の実施形態のＵｂｕｎｔｕコンポネントのＪＳＯＮによる定義例を示す説明図。 第４の実施形態のＴｏｍｃａｔコンポネントのＧＵＩによる定義例を示す説明図。 第４の実施形態のＴｏｍｃａｔコンポネントのＪＳＯＮによる定義例を示す説明図。 第４の実施形態のＷｅｂＡｐｐコンポネントのＧＵＩによる定義例を示す説明図。 第４の実施形態のＷｅｂＡｐｐコンポネントのＪＳＯＮによる定義例を示す図。 第４の実施形態における参照解決後のフィールド間の関係性を示す説明図。 第４の実施形態における参照解決後の構成要素間の関係性を示す説明図。 第４の実施形態における参照解決後のある構成要素のデータ例を示す説明図。 第４の実施形態における設定付与後の構成要素間の関係性を示す説明図。 第４の実施形態のＧＵＩによるシステム構成情報の例を示す説明図。 第４の実施形態の構成要素生成結果のＪＳＯＮによる記載例を示す説明図。 第４の実施形態におけるシステム定義の他の例を示す説明図。 第４の実施形態におけるシステム定義の他の例を示す説明図。 第４の実施形態のＧＵＩによるＣｅｎｔＯＳコンポネントの定義例を示す説明図。 第４の実施形態のＪＳＯＮによるＣｅｎｔＯＳコンポネントの定義例を示す説明図。 第４の実施形態のＧＵＩによるＪｅｔｔｙコンポネントの定義例を示す説明図。 第４の実施形態のＪＳＯＮによるＪｅｔｔｙコンポネントの定義例を示す説明図。 第５の実施形態のＧＵＩによる構成要素のおよび構成要素間の関連性の表現例を示す説明図。 第５の実施形態の構成要素の型定義のＪＳＯＮによる表現例を示す説明図。 第５の実施形態の構成要素のＪＳＯＮによる表現例を示す説明図。 第５の実施形態のWASポートのＪＳＯＮによる定義例を示す説明図。 本発明の概要を示すブロック図。 本発明によるシステム構築支援システムの他の構成例を示すブロック図。 コンポネントの組み合わせにより規定されるシステム定義の一例を示す説明図。 コンポネントの組み合わせにより規定されるシステム定義の他の例を示す説明図。

実施形態１．
以下、本発明の実施形態を図面を参照して説明する。図１は、第１の実施形態のシステム構築支援システムの構成例を示すブロック図である。第１の実施形態のシステム構築支援システム１００は、コンポネントを用いて示されるシステムの構成を、具体的な構成要素による構成に変換して出力する構成定義機能を提供するシステムであって、図１に示されるように、システム定義展開部１０１と、構成要素設定部１０２とを備える。

システム定義展開部１０１は、ネットワークなどを介して間接的にまたは直接、システム定義入力部００１および部品定義記憶部００３と接続されている。また、構成要素設定部１０２は、ネットワークなどを介して間接的にまたは直接、システム構成出力部００２と接続されている。システム定義展開部１０１および構成要素設定部１０２は、例えば、プログラムに従って動作するＣＰＵ等によって実現される。

システム定義入力部００１は、後述するコンポネント定義によって定義づけられるコンポネントを用いて構築対象のシステムの構成が表現されたシステム定義を入力する。システム定義入力部００１は、例えば、マウスやキーボードなどの各種入力装置や、ネットワークを介して情報を入力する任意のサーバ装置等であってもよい。

システム構成出力部００２は、システム定義入力部００１が入力したシステム定義によって示されるシステムの構成を具体化して出力する。システム構成出力部００２は、例えば、ディスプレイ装置などの各種出力装置や、ネットワークを介して情報を出力する任意のサーバ装置等であってもよい。

また、本発明において、コンポネントは、構成要素に関する情報を格納するフィールドを少なくとも有する。ここでフィールドとは、構成要素の情報が代入されるための枠を表す概念である。本発明において、フィールドに構成要素に関する情報を格納することにより、該フィールドに対して、最終的に具体的な一の構成要素を対応づける。なお、個々のフィールドは、複数種類の構成要素に対応可能なことが好ましい。ここで、１つのフィールドが複数種類の構成要素に対応可能であるとは、これら構成要素の共通する要件が抽出されるなど、構成要素の抽象化がなされていることを意味している。なお、コンポネントがどのようなフィールドを有するかは、当該コンポネントを定義づけるコンポネント定義によって定まる。コンポネント定義は、定義対象とされたコンポネントが有するフィールドに関する情報であるフィールド定義を含む。さらに、コンポネント定義は、必要に応じて、フィールドに格納される構成要素に対する設定に関する情報である設定定義を含んでいてもよい。

本実施形態において、システム定義入力部００１が入力するシステム定義は、より具体的には、コンポネント定義を用いたコンポネントの指定と、該コンポネントが有するフィールドに対する構成要素の割り当てに関する割当定義とを少なくとも含む情報とする。一方、システム構成出力部００２が出力する情報は、システムの構成を、具体的な構成要素によって表現した情報である。このように、本実施形態のシステム構築支援システム１００は、抽象化された構成要素群のパターンであるコンポネントを用いて対象システムの構成が示されたシステム定義を受け付けて、具体的な構成要素によって表現した情報に変換して出力する機能を有する。以下、システム構成出力部００２が出力する情報を、システム構成情報という場合がある。

部品定義記憶部００３は、システムを構成する構成要素を抽象化して再利用可能な部品として定義づけた情報である部品定義を記憶する。ここで、部品は、上述したコンポネントを含む概念である。なお、本発明でも、抽象化された構成要素群（上述した例でいう配備処理など）のパターンをコンポネントという。本発明では、具体的な構成要素に対応しない、例えばコンポネント同士を接続するための端子機能を抽象化した概念であるポート等を含む概念として、「部品」という表現を用いている。部品定義記憶部００３は、例えば、記憶装置によって実現される。

システム定義展開部１０１は、システム定義入力部００１を介して利用者からシステム定義を受領し、これを具体的なシステム定義に変換する。ここで、具体的なシステム定義は、入力されたシステム定義に対して、対象システムを構成するコンポネントが有するフィールドに対応づけられる構成要素が解決されている（具体的に指定されている）とともに、コンポーネント間の関係性が解決されている（対象システムを構成するコンポネントが有するフィールドと関連のあるフィールドが特定されている）情報をいう。

構成要素設定部１０２は、システム定義展開部１０１から具体的なシステム定義を受領し、対象システムを構成する構成要素に対して、属性値や、他の構成要素との関連性などの設定を付与する。

以下では、システムの構成として、対象システムの構築処理を定義する場合を例に用いて説明する。本実施形態では、対象システムはＩＴシステムであることを想定している。
また、以下では、ＩＴシステムの構築処理に含まれる任意のプログラム単位を構成要素とし、それらの組み合わせによって構成されるシステムの構築を支援する例を示すが、構成要素は、構築処理に限られず、あらゆるシステムを構成する任意の単位であればよい。

本実施形態において、コンポネント定義は、当該コンポネント定義の識別子（以下、ｉｄという）と、当該コンポネント定義が定義対象とするコンポネントが有する１または複数のフィールドに関する情報であるフィールド定義とを含む。

また、フィールド定義は、当該フィールド定義の名前と、当該フィールドの初期値（当該フィールドに格納される構成要素のインスタンスの定義）と、設定定義とを有していてもよい。ここで、設定定義は、当該フィールドに格納される構成要素に対する各種設定に関する情報（設定内容や設定方法等）である。設定定義としては、例えば、該構成要素に設定される属性値や、該構成要素と他の構成要素等との間の関連性などを指定できる。例えば、関連性として、特に、他の構成要素に対する依存性を指定できる。また、属性値としては、属性を識別する識別子と該属性に対する値とを指定できる。

図２は、ＧＵＩ（Graphical user interface）によるＵｂｕｎｔｕコンポネントの定義例を示す説明図である。ここで、Ｕｂｕｎｔｕコンポネントは、オペレーティングシステム（ＯＳ）の一種である“Ubuntu”に対応したコンポネントを想定している。図２には、“Ubuntu_1”という識別子が付されたコンポネント定義の一例が示されている。図２に示すコンポネント定義“Ubuntu_1”には、“file”フィールドと“boot”フィールドという２つのフィールドが定義されている。ここで“file”や“boot”は、定義対象とされたコンポネントにおけるフィールドのｉｄとしての名前を表している。本例において、“file”フィールドは、あるファイルの作成処理といった、“Ubuntu”上におけるファイル構築に関する構成要素に対応したフィールドを想定している。また、“boot”フィールドは、ＯＳの起動処理といった、“Ubuntu”の起動に関する構成要素に対応したフィールドを想定している。また、“file”フィールドには、設定定義として、当該フィールドに格納される構成要素の“mode”という属性の値を“644”とする旨や、当該フィールドに格納される構成要素が、“boot”フィールドに格納される構成要素に対して関連性を有する旨が指定されている。また、“boot”フィールドには、当該フィールドの初期値として、構成要素“boot1”が指定されている。

以下では、コンポネント定義のＧＵＩによる表現例として、コンポネントを角丸長方形で示す。また、フィールドを点線の長方形で示す。また、構成要素を実線の長方形で示す。また、属性値をフィールド付きの吹き出しで示す。また、関連性をフィールドから他のフィールドへの点線の矢印で示す。また、コンポネントを角丸長方形の内側右上に付された文字列は、当該コンポネント定義のｉｄを示している。また、フィールドを表す点線の長方形の枠外に付された文字列は、該フィールドに付されたｉｄ（名前）を示している。
このような、コンポネントやフィールドや構成要素や属性値や関連性の指定に対応する各々のＧＵＩ部品を用意して、任意のコンポネント定義をユーザが入力できるようにしてもよい。

ここで、図２において、“Ubuntu_1”コンポネント定義に、“file”フィールドから“boot”フィールドへの関連性が指定されていることの意味を補足する。ファイルの作成処理は当然ながらそれが実行されるＯＳが起動していなければ実行できないため、処理の実行順序としては、ＯＳの起動処理の後にファイルの作成処理が実行されなければならない。“file”フィールドから“boot”フィールドの関連性とは、このような処理の実行に関する順序関係の制約を、”file”フィールドの”boot”フィールドへの依存性として定義している。

ところで、コンポネント定義は、ＧＵＩによる表記以外にも、ＪＳＯＮ（Java Script（登録商標）Object Notation）といった言語を利用するなどして、テキスト形式による記述も可能である。

図３は、ＪＳＯＮによるＵｂｕｎｔｕコンポネントの定義例を示す説明図である。図３に示す例は、図２に示したコンポネント定義をＪＳＯＮによって定義した例である。図３には、ＪＳＯＮによるシステム定義が、“種別”要素と、“id”要素と、“フィールド”要素という３つの要素を含む例が示されている。ここで、“種別”要素は、当該一連の情報が何に関する情報であるかを定義するものであり、本例では、コンポネント定義である旨を示す“コンポネント定義”が指定されている。また、“id”要素は、当該コンポネント定義のｉｄを定義するものであり、本例では、“Ubuntu_1”が定義されている。また、“フィールド”要素は、当該コンポネント定義が定義するコンポネントが有するフィールドを定義するものであり、本例では、“file”フィールドと、“boot”フィールドの２つのフィールドが定義されている。

また、フィールド定義において、さらに“初期値”と“設定”という２つの要素が定義されている。なお、“file”フィールドの初期値は空であり、“boot”フィールドの“初期値”には構成要素“boot1”が定義されている。より具体的には、“boot”フィールドの初期値定義における“種別”要素に基づき、当該フィールドに代入される“値”として、ｉｄを“boot1”とする構成要素が定義されている。ここで、フィールドの“初期値”定義における“値”要素は、初期値定義における“種別“要素および当該種別の内容に応じて定義される。ここでは“種別”要素が“新規定義”であるため、“値”要素が合わせて定義される。“値”要素の内容としては、構成要素が定義される。構成要素の定義方法としては、図３に示すように構成要素のｉｄを指定してもよい。ここでは、そのようなｉｄとして“boot1”が定義されている。

また、図３には、フィールド定義の“設定”要素として、“属性”要素と“依存性”要素を含む例が示されている。例えば、図３に示した例では、“file”フィールドの“設定”要素に、“属性”要素と“依存性”要素が含まれている。一方、“boot”フィールドの“設定”要素には、何も定義されていない。本例の”属性”要素は、当該フィールドに格納される構成要素の属性値を定義づけるものであり、その定義方法としては、例えば、属性の識別子と、属性値のペアを指定してもよい。また、”依存性”要素は、当該フィールドに格納される構成要素が有する、他の構成要素への依存性を定義づけるものであり、その定義方法としては、依存先とされる構成要素を、当該構成要素が格納される他のフィールドの参照を表す形式で指定してもよい。なお本例では、ドルマーク“＄”を付加したフィールド名によって、そのフィールドの参照を表現している。

上記のようなコンポネント定義は予め、外部の部品定義記憶部００３などに読み出し可能に記録されていてもよい。例えば、共通モデルを開発する開発者などが予め複数の案件に横断的に共通的に利用されるモデルを、構成要素群のパターンとして定義し、そのような定義を示す情報をコンポネント定義として部品定義記憶部００３に記憶しておいてもよい。

また、図４は、システム定義入力部００１に入力されるシステム定義の例を示す説明図である。なお、図４は、システム定義をＧＵＩによって表現した例である。システム定義は、例えば、当該システム定義が示すシステムの識別子（名前）と、該システムを構成する１つ以上のコンポネントを指定する情報と、該コンポネントに対する各種設定に関する情報とを有していてもよい。図４に示す例では、“system1”システムの構成として、当該“system1”が、コンポネント定義“Ubuntu_1”によって定義づけられるコンポネントのインスタンスの１つである“ubuntu1”コンポネントを有すること、および該“ubuntu1”コンポネントが有する“file”フィールドに対する構成要素の代入に関する情報が指定されている。ここでは“ubuntu1“コンポネントの“file”フィールドに対して、 “file1”構成要素が代入される旨が指定されており、かつ該“file1“構成要素は、“name”属性の値として“"file1.txt”を有する旨が指定されている。

なお、システム定義についても、コンポネント定義と同様に、ＪＳＯＮによる定義が可能である。

図５は、ＪＳＯＮによるシステム定義の例を示す説明図である。図５に示す例は、図４に示したシステム定義をＪＳＯＮによって定義した例である。図５に示すシステム定義は、“種別”要素と、“id”要素と、“コンポネント”要素という３つの要素を含んでいる。システム定義の場合、“種別”要素には、例えば、当該一連の情報がシステム定義である旨を示す“システム定義”が指定される。また、“id”要素には、当該システム定義が定義するシステムのｉｄが指定される。また、“コンポネント”要素には、当該システム定義が定義するシステムが有するコンポネントが指定される。本例では、“ubuntu1”コンポネントが１つだけ指定されている。なお、２以上のコンポネントを定義する場合には、“コンポネント”要素内に、コンポネントの名前と対応づけて当該コンポネントの情報を列挙すればよい。

本例では、コンポネントの情報として、“型名”と“代入”という２つの要素が定義されている。“型名”要素には、コンポネントの有り様を規定するコンポネント定義の識別子としてのｉｄが指定される。ここでは“Ubuntu_1”が指定されている。また“代入”要素には、コンポネント定義によって示される当該コンポネントが有するフィールドに対する、構成要素の代入が定義される。

また、図６は、システム構成出力部００２が出力するシステム構成情報の一例を示す説明図である。図６には、ＧＵＩによるシステム構成情報の表示例が示されている。なお、図６は、図５に示したシステム定義に基づく構成要素の生成結果の例でもある。図６に示すように、システム構成情報は、対象システムを構成する１または複数の構成要素について、これらの構成要素を特定する情報とともに、属性値や他の構成要素との関連性の情報が付与されたものであってもよい。図６に示す例によれば、対象システム“system1”は、“file1”と“boot1”という２つの構成要素を含み、“file1”構成要素は、“name”属性の値が“file1.txt”であって、“mode”属性の値が“644”であり、かつ“boot1”情報要素に対して依存性を有する旨が示されている。

また、図７は、システム構成出力部００２が出力するシステム構成情報の他の例を示す説明図である。図７には、ＪＳＯＮによるシステム構成情報の例が示されている。なお、図７も、図５に示したシステム定義に基づく構成要素の生成結果の例である。

なお、本明細書に基づく手法によれば、システム定義が当該システムの構築方法以外のシステム構成を定義してもよく、またコンポネント定義が関連性の定義として依存性以外の関連性を定義してもよい。

図８は、システム定義の他の例を示す説明図である。また、図９は、図８に示すシステム定義に基づくシステム構成情報の例を示す説明図である。なお、図８および図９のいずれもＧＵＩによる表示例である。

図８に示すシステム定義は、対象システムが、コンポネント定義“DBApplication”によって定義づけられるコンポネントのインスタンスの１つである“dBApplication”コンポネントを有し、かつその“logic”フィールドに構成要素“logic1”が代入されることを定義している。なお、図中のコンポネント定義“DBApplication”によれば、当該コンポネント定義によって定義づけられる“dBApplication”コンポネントが、“logic”フィールドと、“dBConnection”フィールドという２つのフィールドを有し、“dBConnection”フィールドは“dBConnection1”で初期化され、かつ“dBConnection”フィールドに格納される構成要素が“logic”フィールドに格納される構成要素に対して関連性を有することがわかる。ここで、“dBConnection”フィールドに格納される構成要素と“logic”フィールドに格納される構成要素との関連性は、“logic”フィールドとして表現された特定の処理機能が“dBConnection”フィールドとして表現されたデータベースコネクションを利用することを示している。その結果、図９に示すように、単に機能やオブジェクト間の利用関係が導出される。このように、構成要素間の関連性は、利用関係を示すものであってもよい。

ただし、以降、本明細書では特に断らない限り、システム定義が対象システムの構築処理を定義する場合を例に用いて説明する。

［動作の説明］
次に、本実施形態の動作を説明する。図１０は、本実施形態のシステム構築支援システム１００の動作の一例を示すフローチャートである。図１０に示す例では、まず、システム定義展開部１０１が、システム定義入力部００１からシステム定義を受け取ると（ステップＳ１１）、これを読み込む。そして、システム定義展開部１０１は、システム定義が参照するコンポネント定義があれば、これを部品定義記憶部００３から取得して、システム定義を展開して各フィールドに格納される構成要素を解決して、具体的なシステム定義を生成する（ステップＳ１２）。なお、ステップＳ１２で生成された具体的なシステム定義は、構成要素設定部１０２へ送信される。

続いて、構成要素設定部１０２は、システム定義展開部１０１から受け取った具体的なシステム定義に含まれるフィールドに対応づけられた構成要素の各々に対し、これを格納するフィールドに定義された設定を具体化しつつ付与する（ステップＳ１３）。ここで、設定の具体化とは、例えば、フィールドに対して指定されていた依存性や初期値の値を、当該他のフィールドに格納される構成要素の情報に基づいて、具体的な構成要素に落としこんで設定する処理をいう。

最後に、構成要素設定部１０２は、設定が付与された構成要素からなるシステムの構成を示すシステム構成情報を、システム構成出力部００２に出力する（ステップＳ１４）。

以下、ステップＳ１２とステップＳ１３の動作についてさらに詳細に説明する。

図１１は、本実施形態のシステム定義展開部１０１によるシステム定義展開プロセス（図１０のステップＳ１２）のより詳細な動作例を示すフローチャートである。システム定義展開部１０１は、システム定義入力部００１から受け取ったシステム定義を読み込み（ステップＳ１２１）、システム定義内にコンポネントを指定する箇所が見つかった場合（ステップＳ１２２のＹｅｓ）には、その定義を部品定義記憶部００３等から取得する（ステップＳ１２３）。そして、得られたコンポネント定義に基づいて、当該コンポネントに対して値（構成要素）の代入を行い具体化する（ステップＳ１２４）。

例えば図５に例示した“system1”のシステム定義を読み込む場合であれば、“ubuntu1”コンポネントの定義として“Ubuntu_1”が指定されているため、これを部品定義記憶部００３から取得する。部品定義記憶部００３は、例えば、コンポネント定義のｉｄを受付けて該当するコンポネント定義を返信する機能を備えていればよく、一例として、ｈｔｔｐサーバやファイルサーバやＤＢサーバにより実現されていてもよい。この例では、システム定義展開部１０１は、部品定義記憶部００３にｉｄ＝“Ubuntu_1”を指定したコンポネント定義要求を送信し、図３に示すコンポネント定義を取得する。そして、システム定義展開部１０１は、システム定義や取得したコンポネント定義に当該コンポネントが有するフィールドに対する値（構成要素）の代入が定義されていれば、その値を代入する。例えば、図５に例示した“system1”定義の場合、コンポネント定義の参照元であるシステム定義で定義された“file”フィールドへの“file1”構成要素の代入と、コンポネント定義で定義された“boot”フィールドへの“boot1”構成要素の代入とを実施し、その結果得られたコンポネントを“ubuntu1”コンポネントとする。

全てのコンポネント定義の参照が解決された場合（ステップＳ１２２のＮｏ）には、システム定義展開部１０１は、具体化したシステム定義を出力して（ステップＳ１２５）、システム定義展開プロセスを終了する。

以上の結果、例えば、図１２に示すような具体的なシステム定義が生成される。図１２はＪＳＯＮによる、システム定義展開後の出力情報としての具体的なシステム定義の例を示す説明図である。本例では、具体的なシステム定義であることを示すものとして、”種別”要素に、“システム定義２”が設定されている。なお、この時点では、属性値や依存性の設定はまだコンポネントのフィールドに対して設定されている。

また、図１３は、本実施形態の構成要素設定部１０２による構成要素設定プロセス（図１０のステップＳ１３）のより詳細な動作例を示すフローチャートである。構成要素設定部１０２は、システム定義展開部１０１が生成した具体的なシステム定義に含まれる全てのフィールドを対象に、以下の３つのステップを実行する。すなわち、まず、対象としたフィールドに格納された構成要素を取得し（ステップＳ１３１）、当該構成要素に対して当該フィールドに設定された設定を付与する（ステップＳ１３２）。ステップＳ１３２では、例えば、構成要素に対して属性値などが設定される。ここで、構成要素の取得および構成要素に対する設定の付与は、具体的には、対象システムにおける当該構成要素の定義情報を生成または取得し、その定義情報に、フィールドに設定された設定内容を反映（値の代入等）することであってもよい。このとき、構成要素設定部１０２は、フィールドの設定定義内に他のフィールドの参照がある場合には、参照先の指定を参照先のフィールドに格納された構成要素のｉｄに変換した上で、設定内容を反映する（ステップＳ１３３）。

例えば図１２に例示した具体的なシステム定義が入力された場合、当該システム定義から“ubuntu1”コンポネントの“file”フィールドと“boot”フィールドとが抽出される。そして、それらフィールドから“file1”構成要素と“boot1”構成要素が取得される。
そして、“file1”構成要素に対して、“file”フィールドに設定された設定内容が付与される。ここでは、“file1”構成要素に対して、“mode”属性の値として“644”が追加されるとともに、“file1”構成要素に対して、“boot”フィールドに対応する具体的な構成要素である“boot1”に対する依存性が付与される。結果として、図６や図７に示すようなシステム構成情報が生成される。

［効果の説明］
本実施形態によれば、コンポネントという抽象化された構成要素群のパターンを利用するとともに、そのようなコンポネントの定義情報として、当該コンポネントが対応している構成要素に関する情報として、当該構成要素が共通に有する設定（属性値や他の構成要素との間の依存関係）を持たせることによって、個々の構成要素に対する設定のうちの再利用性がある設定をコンポネントの情報として閉じ込めることができる。また、本実施形態によれば、抽象化された構成要素の情報を格納するフィールドという枠に対して、その中身の構成要素に対する設定を定義しておき、構成要素の組み合わせが確定した後で、中身の構成要素に対して、枠に設定された設定を反映する仕組みを有しているので、組み合わせが変更される度に同様の設定を設定しなおすといった手間を省略できる。このように、既に定義されたコンポネントの設定を利用することで、構成要素の組み合わせを変更しても、関係する構成要素に対する設定の追加が不要となりシステム定義が容易化される。

例えば、図５に示すシステム定義によって示される“system1”とは異なる構成のシステムを、“system2”として定義しなおす場合を考える。このとき、例えば、図１４に示すようなシステム定義が入力されたとする。図１４は、システム定義の他の例を示す説明図である。図１４に示す例では、“system1”と同様、コンポネント定義“Ubuntu_1”によって定義づけられる“ubuntu1”コンポネントを有している。しかし、“ubuntu1”コンポネントの“file”フィールドへ代入する構成要素が異なっている。具体的には、“file2”というｉｄを有する構成要素を代入する旨、およびその構成要素は“name”属性に“file2.py”という値と、“mode”属性に“755”という値をもっていることが定義されている。

このようなシステム定義が入力された場合、例えば、図１５に示すようなシステム構成情報が出力される。図１５に示すシステム構成情報によれば、システム“system2”は、“boot1”構成要素と、“file2”構成要素とを備え、“file2”構成要素が、“name”属性として“file2.py”と“mode”属性として“755”とを有するとともに“boot1”構成要素に対して依存性を有することがわかる。

“Ubuntu_1”というコンポネント定義を予め定義しておくことで、システム“system1”のシステム構成情報に、“boot1”構成要素の存在と、“file1”構成要素の存在と、“file1”構成要素に対して“mode”属性値として値“664”と、“boot1”に対する依存性の情報が自動で付加される。このように、システム定義として、コンポネント定義の指定と当該システムにおける固有の指定といったわずかな記載をするだけで、より多くの情報を盛り込むことが可能となり、出力量に対する必要な記述量が削減されることがわかる。
また、“Ubuntu”上で使用するファイルの種別を変更するなどシステム構成の一部を変更する場合であっても、“Ubuntu_1”というコンポネント定義が既に定義済みであれば、“file”フィールドに対する値の代入を設定するだけで、“Ubuntu”上において“file2”ファイルの構築処理が有するブート処理への依存性を設定しなおす必要なしに、システム構成を変更できる。このように、本実施形態によれば、構成要素間の依存性に対しても再利用性を持たせることができる。

実施形態２．
次に、本発明の第２の実施形態について説明する。第２の実施形態におけるシステム構築支援システム１００の構成は、システム定義展開部１０１と構成要素設定部１０２の動作が異なる点を除いて第１の実施形態の構成と同様である。以下、第１の実施形態と同様の部位には同一の記号を付し、説明を省略する。

本実施形態では、部品定義に、コンポネント定義の他、ポートを定義づける情報であるポート定義が含まれる点、コンポネント定義がポートの指定を含みうる点、システム定義がワイヤの指定を含みうる点が異なる。ここで、ポートとは、コンポネント間の接続関係を規定するための端子を表す概念であり、ワイヤとはポート間の接続を表す概念である。
本実施形態のシステム定義展開部１０１および構成要素設定部１０２は、これらポートおよびワイヤの情報を扱う点が第１の実施形態と異なる。

本発明において、ポートは、コンポネントと同様に、１つまたは複数のフィールドを有する。ポートが有するフィールドは、当該ポートを含むコンポネントが他のコンポネントを接続する際に必要となる構成要素の情報を格納するためのものである。

ポート定義は、当該ポート定義のｉｄと、当該ポート定義が定義づけるポートが有する１つまたは複数のフィールドを規定するフィールド定義とを含む。

図１６は、本実施形態におけるＧＵＩによるＯＳポートの定義例を示す説明図である。
ここで、ＯＳポートは、Ｕｂｕｎｔｕコンポネントなど一般にＯＳに対応するコンポネントが他のコンポネントと接続するための接続処理を抽象化したものを想定している。図１６には、“OS_2”というｉｄが付されたポート定義の一例が示されている。図１６に示すポート定義“OS_2”は、“file”フィールドと“package”フィールドという２つのフィールドを有する。ここで、“file”フィールドは、一般的なＯＳ上において他のコンポネントとの接続に必要なファイルの作成処理といったファイル構築に関する構成要素に対応したフィールドを想定している。また、“package”フィールドは、ＯＳの下で動作するミドルウェアのコンフィグレーションマネージメントシステムが提供するパッケージ化されたリソース等に対応したフィールドを想定している。なお、当該ポート定義においてこれら２つのフィールドには、設定定義および初期値は特に指定されていない。

以下では、ＧＵＩによる表現例として、ポート定義におけるポートをベース形で表現するものとする。

また、図１７は、本実施形態におけるＪＳＯＮによるＯＳポートの定義例を示す説明図である。図１７に示す例は、図１６に示したポート定義をＪＳＯＮによって定義した例である。図１７に示すように、ＪＳＯＮによるＯＳポートのポート定義は、“種別”要素にポート定義である旨を示す“ポート定義”が指定されている点を除き、図３に示すコンポネント定義と基本的に同様である。すなわち、“種別”要素と、“id”要素と、“フィールド”要素とを有し、“id”要素には当該ポート定義の識別子を指定し、“フィールド”要素には、当該ポート定義によって定義されるポートが有するフィールドの情報が列挙される構成であってもよい。

また、本実施形態において、コンポネント定義は、当該コンポネント定義のｉｄと、当該コンポネント定義によって定義されるコンポネントが有するフィールドの定義と、当該コンポネント定義によって定義されるコンポネントが有するポートの指定とを含んでいてもよい。ここで、ワイヤは常に同じポート定義によって定義づけられるポートの組を接続するものとしてもよい。

また、ポートは、サービスポートとリファレンスポートという２種類のポートに分けられていてもよい。サービスポートは、接続を受け入れる側の端子を示す概念であり、一方のリファレンスポートとは接続を要求する側の端子を示す概念である。そのような場合において、ワイヤは、同じポート定義によって定義づけられるポートであって、かつサービスポートとリファレンスポートの組を接続し、サービスポート同士やリファレンスポート同士は接続しないようにしてもよい。

また、本実施形態では、フィールドの初期値定義に、種別として、新規定義の他に、他のフィールドの参照を指定できるものとする。これは、コンポネント同士を接続する過程で、異なるコンポネントのフィールド間を、構成要素を伝搬させることにより、必要な設定を網羅させるためである。

図１８は、本実施形態におけるシステム定義の例を示す説明図である。図１８には、ＧＵＩによるシステム定義の例が示されている。図１８に示すシステム定義によれば、対象システム“system2”が、コンポネント定義“Tomcat_2”によって定義づけられるコンポネントのインスタンスである“tomcat2”コンポネントと、コンポネント定義“Ubuntu_2”によって定義づけられるコンポネントのインスタンスである“ubuntu2”コンポネントとを有していることがわかる。また、“tomcat2”コンポネントが有する“os”リファレンスポートと、“ubuntu2”コンポネントが有する“os”サービスポートとがワイヤによって接続されていることがわかる。ここで、Ｔｏｍｃａｔコンポネントの一例である“tomcat2”は、Ｗｅｂアプリケーションの一種である“Tomcat”に対応したコンポネントを想定している。本例のコンポネント定義“Tomcat_2”および“Ubuntu_2”については後述する。

以下では、ＧＵＩによる表現例として、サービスポートを、対向する辺のうちの一方が山形、他方が谷型の形状（以下、矢羽型という）で表現し、リファレンスポートをホームベース型で表現し、ワイヤを２重線で表現するものとする。

また、図１９は、本実施形態におけるＪＳＯＮによるシステム定義の例を示す説明図である。図１９に示す例は、図１８に示したシステム定義をＪＳＯＮによって定義した例である。図１９に示すシステム定義には、“種別”要素、“id”要素、“コンポネント”要素に加えて、“ワイヤ”要素が含まれている。ここで、“ワイヤ”要素には、接続元のポートを指定する“接続元”要素と、接続先のポートを指定する“接続先”要素が含まれる。本例では、“接続元”要素には、“$ubuntu2.os”が指定されており、“接続先”要素には、“$tomcat2.os”が指定されている。

利用者は、このように既に定義されたコンポネント定義を利用してコンポネントを指定した上で、当該コンポネントが有するポート同士をワイヤを用いて接続する旨を指定することにより、複数のコンポネントが協働するようなシステムであっても簡易に定義することができる。

図２０は、本実施形態におけるＵｂｕｎｔｕコンポネントのＧＵＩによる定義例を示す説明図である。図２０には、“Ubuntu_2”というｉｄが付されたコンポネント定義の一例が示されている。図２０に示すコンポネント定義“Ubuntu_2”によれば、当該コンポネント定義によって定義づけられるコンポネントは、“file”フィールドと“package”フィールドと、“boot”フィールドという３つのフィールドを有し、かつポート定義“OS_2”によって定義づけられる “os”ポートをサービスポートとして有することが定義されている。また、“file”フィールドと“package”フィールドの初期値定義として、“os”ポートの“file”フィールドと“package”フィールドの参照がそれぞれ定義されている。一方、“boot”フィールドの初期値定義として、“boot2”構成要素が新規に作成される旨が定義されている。また、“file”フィールドと“package”フィールドには、それぞれ“boot”フィールドに対する依存性が定義されている。

以下、ＧＵＩによる表現例として、フィールドの参照による値の定義を、参照する側のフィールドに付した黒丸から参照先のフィールドへの実線の矢印で表現するものとする。

また、図２１は、本実施形態におけるＵｂｕｎｔｕコンポネントのＪＳＯＮによる定義例である。図２１に示す例は、図２０に示したコンポネント定義をＪＳＯＮによって定義した例である。図２１に示すコンポネント定義には、“種別”要素、“id”要素、“フィールド”要素に加えて、サービスポートを指定するための“サービスポート”要素が含まれている。本例では、“サービスポート”要素において、ポート定義“OS_2”によって定義づけられるポートである１つの“os”ポートが指定されている。また、本例では、“Ubuntu_2”が定義するコンポネントが有する“file”フィールドと“package”フィールドの初期値設定において、“種別”が“参照”となっているとともに、“参照先”として“$os.file”と“$os.package”がそれぞれ指定されている。ここでは、これらの指定は“os”サービスポート内の“file”フィールドと“package”フィールドをそれぞれ示している。このように、ある要素が内包する要素を表現する方法として、これらの要素名をドット“.”で連結する表現方法を採用することができる。なお、上位のコンポネント要素が内包する要素を示す場合、例えば、ポート内のフィールドが本体のコンポネントのフィールドを示す場合、上位の要素を指す表現として２個のドット“..”で表現する方法を採用することができる。

また、図２２は、本実施形態におけるＴｏｍｃａｔコンポネントのＧＵＩによる定義例である。図２２には、“Tomcat_2”というｉｄが付されたコンポネント定義の一例が示されている。図２２に示すコンポネント定義によれば、当該コンポネント定義によって定義づけられるコンポネントは、“configFile”フィールドと“package”フィールドという２つのフィールドを有することがわかる。また、リファレンスポートとして、ポート定義“OS_2”によって定義づけられる“os”ポートを有することがわかる。また、本例では、“Tomcat_2”が定義するコンポネントが有する“configFile”フィールドと“package”フィールドの初期値設定において、“tomcatConfig2”構成要素と”tomcatPackage2”構成要素がそれぞれ新規定義されている。さらに、“configFile”フィールドに対して、“package”フィールドに対する依存性が定義されている。また、“os”ポート内の“file”フィールドと“package”フィールドに対して、当該ポートを有するコンポネントの“configFile”フィールドと“package”フィールドからの参照による値の代入が定義されている。

図２３は、本実施形態におけるＴｏｍｃａｔコンポネントのＪＳＯＮによる定義例を示す説明図である。図２３に示す例は、図２２に示したコンポネント定義をＪＳＯＮによって定義した例である。図２３に示すコンポネント定義には、“種別”要素、“id”要素、“フィールド”要素に加えて、リファレンスポートを指定するための“リファレンスポート”要素が含まれている。本例では、“リファレンスポート”要素において、ポート定義“OS_2”によって定義づけられる “os”ポートが定義されている。また、本例では、“Tomcat_2”が定義するコンポネントが有する“configFile”フィールドと“package”フィールドの初期値設定において、“tomcatConfig2”構成要素と”tomcatPackage2”構成要素がそれぞれ新規定義されている。さらに、“configFile”フィールドには、“package”フィールドに対する依存性が定義されている。また、“os”ポート内の“file”フィールドと“package”フィールドに対して、当該フィールドの値の代入に関する設定として、当該ポートを有する本体のコンポネントが有する“configFile”フィールドと“package”フィールドの内容が参照される旨が定義されている。

ところで、図２４は、本実施形態におけるＴｏｍｃａｔコンポネントの他の定義例を示す説明図である。図２４には、ＧＵＩによるコンポネント定義の例が示されている。図２４に示すコンポネント定義“Tomcat_2x”では、本体のコンポネントには直接フィールドを持たせず、本体のコンポネントが有するリファレンスポートが持つフィールドに直接値を代入している。なお、この場合も、コンポネントは、自身が有するポートを介して間接的にフィールドを有していると解釈できる。なお、本例では、リファレンスポート内のフィールドへの値の代入は、他のフィールドの参照によるものではなく、構成要素の新規定義によって指定されている。また、依存性に関して、“os”ポート内の“file”フィールドに格納されている“tomcatConfig2”構成要素に対して、同じポート内の“package”フィールドへの依存性が指定されている。このように、依存性はフィールド内の構成要素を直接指定して設定することも可能であるが、このような依存性の場合、当該コンポネントを再利用する際に他の構成要素が代入されて元々の構成要素が上書きされた場合などには消失することとなる。なお、上書きされた構成要素においても同様の依存性を保持させたい場合には、“os”ポート内の“file”フィールドに対して、同じポート内の“package”フィールドの参照を用いて当該フィールドに格納される構成要素への依存性を指定すればよい。

また、図２５は、本実施形態におけるＪＳＯＮによるＴｏｍｃａｔコンポネントの他の定義例を示す説明図である。図２５に示す例は、図２４に示したコンポネント定義をＪＳＯＮによって定義した例である。なお、図２５には、“os”ポート内の“file”フィールドに対して、同じポート内の“package”フィールドの参照を用いて当該フィールドに格納される構成要素への依存性を指定する例が示されているが、直接“tomcatpackage2”構成要素を指定することも可能である。この場合、例えば、「“依存性”：［“tomcatpackage2”］のように指定してもよいし、直接構成要素を指定することを表す記号として、“#”などを導入し、“#tomcatpackage2”のように指定してもよい。

［動作の説明］
次に、本実施形態の動作を説明する。図２６は、本実施形態のシステム構築支援システム１００の動作の一例を示すフローチャートである。以下では、第１の実施形態と同様の動作については同一の記号を付し、説明を省略する。

本実施形態の動作は、システム定義展開部１０１による具体的なシステム定義を生成するシステム定義展開プロセス（ステップＳ２２）と、構成要素設定部１０２による構成要素設定プロセス（ステップＳ２３）とが第１の実施形態の動作と異なる。

図２７は、本実施形態のシステム定義展開部１０１によるシステム定義展開プロセスのより詳細な動作例を示すフローチャートである。本実施形態のシステム定義展開プロセスにおいては、システム定義展開部１０１は、コンポネント定義の読み込みプロセス（ステップＳ２２１）の内容と、全てのコンポネントを読み込んだ後にワイヤ定義に従ってポートを連結する動作（ステップＳ２２２）が加わっている点が、第１の実施形態と異なる。
ここで、ポートを連結するとは、連結対象とされたポート間に接続関係があることを構成情報として保持することに加えて、連結対象とされたポート間においてフィールドの値を移譲可能にすること、より具体的には、システム定義、コンポネント定義およびポート定義に従って構成要素の情報を相手先ポートに伝搬させる（移し替える）処理を行うことをいう。

また、図２８は、本実施形態のシステム定義展開部１０１によるコンポネント定義読み込みプロセス（図２７のステップＳ２２１）のより詳細な動作例を示すフローチャートである。図２８に示す例では、システム定義展開部１０１は、システム定義が参照するコンポネント定義があれば、これを部品定義記憶部００３等から読み込む（ステップＳ２２１１）。そして、当該コンポネント定義が参照するポート定義があれば（ステップＳ２２１２のＹｅｓ）、これを部品定義記憶部００３等から読み込む（ステップＳ２２１３）。そして、システム定義が示すコンポネントが有するフィールドの各々に、コンポネント定義およびポート定義に従って値（情報要素）の代入を行ってコンポネントが有する情報要素を具体化することにより、具体的なシステム定義を生成する（ステップＳ２２１４）。

例えば、上述したポート定義“OS_2”と、コンポネント定義“Ubuntu_2”と、コンポネント定義“Tomcat_2”とが部品定義記憶部００３に保持されている状態で、図１８に例示したシステム定義が入力された場合を考える。本例では、システム定義展開部１０１は、当該システム定義で示される“system2”システムが内包するコンポネントの定義である“Ubuntu_2”や“Tomcat_2”を取得する。また、システム定義展開部１０１は、これらのコンポネント定義中に“os”ポートのポート定義として“OS_2”ポート定義が参照されていることを受けて、当該ポート定義を取得する。システム定義展開部１０１は、さらに取得したポート定義に基づいて、コンポネントおよびポートが有するフィールドに対して値（構成要素）の代入を実施する。このとき、代入定義として“参照”が設定されていた場合、参照先で定義された値を代入する。この例では、“system2”の“tomcat2”コンポネントの“os”リファレンスポートにおいて、本体のコンポネントの“configFile”フィールドと“package”フィールドへの参照による値（構成要素）の代入が定義されている。
その結果、ポート定義“OS_2”によって定義づけされる”os”ポートは、“file”フィールドに本体コンポネントの“tomcat2.configFile”フィールドへの参照が代入され、かつ“package”フィールドに“tomcat2.package”フィールドへの参照が代入された上で、“tomcat2”コンポネントの“os”リファレンスポートとして設定される。

また、この例では、“system2”の“ubuntu2”コンポネントの“file”フィールドに対して、“os”サービスポートの“file”フィールドからの参照による初期値の設定が定義されているとともに、“ubuntu2”コンポネントの“package”フィールドに対して、“os”サービスポートの“package”フィールドからの参照による初期値の設定が定義されている。その結果、本体である“ubuntu2”コンポネントの“file”フィールドには、当該コンポネントが有する“os”サービスポートの“file”フィールドへの参照が設定される。また、同様に、“ubuntu2”コンポネントの“package”フィールドには、当該コンポネントが有する“os”サービスポートの“package”フィールドへの参照が設定される。

システム定義展開部１０１は、全てのポート定義の参照が解決された場合には（ステップＳ２２１２のＮｏ）、コンポネント定義の読み込みプロセスを終了する。

さらに、システム定義展開部１０１は、全てのコンポネント定義の参照が解決された場合には（図２７のステップＳ１２２のＮｏ）、システム定義に含まれるワイヤ定義に従ってポートを連結する（ステップＳ２２２）。ポートの連結処理として、本実施形態では、リファレンスポート内の各フィールドに格納された値を対応するサービスポート内のフィールドに伝搬させる（移し替える）。これによりワイヤで接続された２つのポートを１つにまとめる。

例えば、コンポネント定義およびポート定義の読み込みの結果、図２９に示すような、サービスポートのフィールドを除き、すべてのフィールドが解決された具体的なシステム定義が生成されたとする。本実施形態では、システム定義展開部１０１が、ポートの連結処理において、システム定義に含まれるワイヤの設定に基づいて、接続元である“os”リファレンスポートのフィールドの値を、接続先である“os”サービスポートの対応するフィールドの値に移す処理を行う。これにより、接続要求元である“tomcat2”コンポネントの“os”リファレンスポートの“file”フィールドおよび“package”フィールドに格納される値が、接続要求先である“ubuntu2”コンポネントの“os”サービスポートの“file”フィールドおよび“package”フィールドに移される。本例では、例えば“tomcat2.os.file”フィールドに設定された値として“tomcat2.configFile”フィールドへの参照が、“ubuntu2.os.file”フィールドに移される。なお、“package”フィールドについても同様である。

次に、システム定義展開部１０１は、全てのワイヤに対してポートの連結処理を完了すると、具体化したシステム定義を出力して（ステップＳ１２５）、システム定義展開プロセスを終了する。

図３０は、ポート連結後のフィールド間の関係を示す説明図である。図３０では、上述したシステム定義に基づいて、ポート連結後の具体的なシステム定義におけるフィールドのみを抽出して、それらの関係を示している。なお、図３０に示す例では、“tomcat2”コンポネントの“os”リファレンスポートのフィールドの値は、接続先の“ubuntu2”コンポネントの“os”サービスポートの対応するフィールドにそのまま反映されているとして図示省略しているが、“tomcat2”コンポーネントの“os”リファレンスポートを残しておいてもよい。その場合、例えば、“tomcat2.configFile”フィールドと“ubuntu2.os.file”フィールドとの間に“tomcat2.os.file”フィールドを設け、“ubuntu2.os.file”フィールドの参照先を、“tomcat2.os.file”フィールドとすればよい。なお、“package”フィールドについても同様である。いずれの記述であっても、次の構成要素設定プロセスで多段の参照設定が解決されることにより、当該参照関係にある一連のフィールドに対応する構成要素としては、最終的な参照先とされるフィールドに格納される値に具体化される。

また、図３１は、本実施形態の構成要素設定部１０２による構成要素設定プロセス（図２６のステップＳ２３）のより詳細な動作例を示すフローチャートである。構成要素設定部１０２は、システム定義展開部１０１が生成した具体的なシステム定義内の全てのフィールドについて第１の実施形態と同様の処理を実行する。ただし、本実施形態は、各フィールドに対応づけられる構成要素が、参照による複製である場合がある点が異なる。この点に関して、本実施形態の構成要素設定部１０２は、まず各フィールドに格納された値を確認し、値が構成要素を直に指定するものであれば単にそれを取得する。一方、値が他のフィールドへの参照を指定するものであれば、参照先のフィールドに格納された構成要素の情報を複製して、参照元のフィールドに格納した上で、最終的に対象フィールドに格納された情報を取得する（ステップＳ２３１）。このとき、参照先のフィールドに格納されている値がさらに他のフィールドへの参照を指定するものである場合には、さらに該参照先である他のフィールドに格納された構成要素の情報を複製して参照元のフィールドに格納する処理を再帰的に実施し、最終的な参照先とされるフィールドに格納された構成要素の情報を、各参照元のフィールドに構成要素を格納する。例えば２段の参照が設定されていた場合、大元の構成要素の複製の複製が作成されることになる。ここで構成要素の複製は、例えば、構成要素の情報として、適宜重複しないように生成された識別子と、複製元の構成要素の識別子の要素を持たせてもよい。

図３２は、図３０に示した具体的なシステム定義から参照による構成要素を解決した後のフィールド間の関係性を示す説明図である。図３２において、内部にｉｄを持たない構成要素（図中の実線の長方形のうち網掛けがされているもの）は、矢印が示す構成要素の複製であることを示しており、構成要素の複製から構成要素、あるいは複製から複製に引かれた実線の矢印は複製元の構成要素を示している。

また、図３３は、参照解決後のある構成要素のデータ例を示す説明図である。図３３には、図３２における“ubuntu2”コンポネントの“os”サービスポートの“file”フィールド（すなわち“ubuntu2.os.file”フィールド）内に格納される、構成要素の情報の例が示されている。ワイヤに基づくポートの連結処理と、参照の解決処理とを経た結果、図３３に示すように、当該“file”フィールドは、構成要素の情報として、複製元の構成要素の識別子（本例では、“tomcatConfig2”）と、当該フィールドに格納される複製された構成要素の仮の識別子（本例では、“tomcatConfig2_1”）とを含む情報を保持していてもよい。なお、本例では、複製された構成要素の仮の識別子として、大元の構成要素の名前＋“_”（アンダーバー）＋数字を付すことにより、当該構成要素が複製であることを表現している。

続いて、構成要素設定部１０２は、各フィールドが保持する構成要素に対する設定に関する情報（設定定義）に基づき、当該フィールドに格納された構成要素または複製された構成要素に対して設定を付与する（ステップＳ２３２）。

図３４は、図３２に示したフィールド間の関係性を基に、設定の付与を実施した後の構成要素間の関係性を示す説明図である。図３４に示すように、フィールドに設定されていた内容がそのまま、当該フィールドが格納する構成要素に対して付与されている。なお、図３４において、構成要素の複製を表す網掛け長方形の上部に付した名前は当該複製のｉｄを示している。また、図３５は、本実施形態における設定付与後のある構成要素のデータ例を示す説明図である。図３５に示す例は、図３４における“ubuntu2”コンポネントの“file”フィールド（すなわち“ubuntu2.file”フィールド)に格納される、構成要素の複製の情報の例である。

ここで、フィールド内の構成要素に対する設定内の参照定義は、当該フィールドを定義しているコンポネント定義内において指定されているため、当該参照が定義されたコンポネントをスコープとして参照先を探索すればよい。例えば、“system2”において、“ubuntu2”コンポネントの“file”フィールドに対して定義された依存性の参照先の定義が“$boot”であったとする。この場合、“ubuntu2“コンポネント内で“boot”フィールドを探索すればよい。その結果、ここでは“ubuntu2.boot”フィールドが発見される。

各フィールド内の構成要素に対する設定の付与が完了すると、構成要素設定部１０２は、フィールド内の構成要素に対する設定内の参照を解決するとともに、複製に付与された設定を全て複製元となる構成要素に集約する（ステップＳ２３３）。

本実施形態の構成要素設定部１０２は、構成要素の複製に対して行われた設定を複製元に集約する集約処理を行う。例えば、図３２に示した情報を基に、設定を付与した結果、図３４に示すような構成要素間の関連性が構築されたとする。この場合、“ubuntu2.file”フィールドに格納されている複製“tomcatConfig2_2”が持つ、“ubuntu2.boot”フィールドに格納されている構成要素“boot2”への依存性は、大元の複製元である“tomcatConfig2”構成要素に集約される。同様に、“ubuntu2.package”フィールドに格納されている複製“tomcatPackage2_2”が持つ、“ubuntu2.boot”フィールドに格納されている構成要素“boot2”への依存性は、大元の複製元である“tomcatPackage2”構成要素に集約される。

結果として、図３６や図３７に示すようなシステム構成情報が生成される。なお、図３６は、ＧＵＩによるシステム構成情報の例を示す説明図であり、図３７は、ＪＳＯＮによるシステム構成情報の例を示す説明図である。図３６および図３７はいずれも同じ構成を示している。図３６および図３７によれば、“system2”が、“tomcatConfig2”と“tomcatPackage2”と“boot2”という３つの構成要素を備えており、“tomcatConfig2”構成要素は、“tomcatPackage2”構成要素と“boot2”構成要素にそれぞれ依存性を有しており、tomcatPackage2”構成要素は“boot2”構成要素に依存性を有していることがわかる。

［効果の説明］
本実施形態によれば、複数のコンポネントで定義された設定の全てを構成要素に集約的に付与可能となり、またフィールドへの構成要素の代入に関する定義までが再利用可能に抽象化されることで、ユーザはワイヤを定義するだけでより効率的にシステムの構成を定義できる。より具体的には、本実施形態では、フィールドへの構成要素の代入に関する設定定義に、他のフィールドの参照である旨を指定できるようにした（代入の抽象化要素を追加した）ことで、フィールドに対して設定されている属性値や依存性といった設定内容を、参照関係に基づいて伝搬させていくことができる。また、このような参照関係は、コンポーネントの組み合わせが決定して初めて確定されるものであるが、本実施形態では参照関係の設定をフィールドを用いて行い、かつポートとワイヤという抽象化された部品を使って伝搬可能に結びつける仕組みとなっている。このように代入の抽象化と設定対象の抽象化とを組み合わせることで、再利用性を犠牲にせずに、設定の伝搬が可能になっている。このような構成を備えているので、本実施形態によれば、より効率的にシステム構成を定義できる。

なお、本実施形態では、システムが“Ubuntu”を用いる場合を例に説明したが、“Ubuntu”に代えて”CentOS”を用いることも可能である。その場合、“Ubuntu2”とほぼ同様の定義を“CentOS_2”として作成し、当該コンポネント定義“CentOS_2”によって定義づけられるコンポーネントのインスタンスをシステム定義で指定すればよい。なお、“boot”構成要素にＯＳを区別する情報が含まれている必要がある場合には、“Ubuntu2”コンポネント定義や、“CentOS_2”コンポネント定義において、“boot”フィールドの設定定義にname属性に対する設定を設けて、“ubuntu”や“centOS”などの値を指定されることなどが挙げられる。

ＯＳコンポネントが変更となった場合でも、“os”ポートなどの共通のポート定義を利用してポートを定義しておけば、ワイヤの定義を変更するだけで変更後のコンポネント間の接続に必要な設定を、各フィールドに格納される構成要素またはその複製に伝搬させることができるので、より効率的にシステム構成を定義できる。

実施形態３．
次に、本発明の第３の実施形態について説明する。第３の実施形態におけるシステム構築支援システム１００の構成は、システム定義展開部１０１と構成要素設定部１０２の動作が異なる点を除いて第２の実施形態の構成と同様である。以下、第１〜２の実施形態と同様の部位には同一の記号を付し、説明を省略する。

本実施形態では、ポートが有するフィールドに対して、アクセプトフィールドとプロバイドフィールドという種別を設ける点が第２の実施形態と異なる。ここで、アクセプトフィールドは、リファレンスポートからサービスポートへの構成要素の伝搬を扱うフィールドである。このため、アクセプトフィールドに対しては、ポート間の接続による伝搬を除き、当該ポートをリファレンスポートとして持つコンポネントからのみ値の代入を受け付ける。一方、プロバイドフィールドは、サービスポートからリファレンスポートへの構成要素の伝搬を扱うフィールドである。このため、プロバイドフィールドに対しては、ポート間の接続による伝搬を除き、当該ポートをサービスポートとして持つコンポネントからのみ値の代入を受け付ける。第３の実施形態のシステム定義展開部１０１や構成要素設定部１０２は、これら種別に対応した定義情報を扱う点が第２の実施形態と異なる。

図３８は、本実施形態におけるＧＵＩによるＯＳポートの定義例を示す説明図である。
図３８には、“OS_3”という識別子が付されたポート定義の一例が示されている。図３８に示すポート定義“OS_3”では、当該ポート定義によって定義づけられるポートが有するフィールドとして、“file”フィールドと“package”フィールドという２つのアクセプトフィールドと、“boot”フィールドという１つのプロバイドフィールドとが定義されている。また、本例では、“file”フィールドと“package”フィールドのそれぞれに対して、“boot”フィールドへの依存性が定義されている。

図３８に示すように、本明細書では、ＧＵＩによるフィールドの表現例として、アクセプトフィールドを右側を凸にした矢羽型で表し、プロバイドフィールドを左側を凸にした矢羽型で表すものとする。

また、図３９は、本実施形態におけるＪＳＯＮによるＯＳポートの定義例を示す説明図である。図３９に示す例は、図３８に示したポート定義をＪＳＯＮによって定義した例である。図３９に示すように、ＪＳＯＮによるＯＳポートのポート定義は、“種別”要素が”ポート定義”となっている点と、“フィールド要素”が、“アクセプトフィールド”要素と、“プロバイドフィールド”要素とに分かれている点を除き、コンポネント定義と基本的に同様でよい。本例のポート定義における内容は、図３８と同様である。すなわち、図３９に示すポート定義には、“種別”要素としてポート定義である旨が定義され、“id”要素として“OS_3”が定義され、“アクセプトフィールド”要素として“file”フィールドおよび“package”フィールドを備える旨、“プロバイドフィールド”として“boot”フィールドを備える旨が定義されている。

ここで、アクセプトフィールドである“file”フィールドおよび“package”フィールドには、当該ポートをリファレンスポートとして有するコンポネントの対応するフィールドから値が代入されることを想定している。一方、プロバイドフィールドである“boot”フィールドには、当該ポートをサービスポートとして有するコンポネントの対応するフィールドから値が供給されることを想定している。これは、当該ポート定義によって定義されるポートをサービスポートとして持つコンポネントは、当該ポート定義によって定義されるポートをリファレンスポートとして持つコンポネントに対してホストの関係にあることを想定していることを表している。ポートが有するフィールドに、アクセプトフィールドとプロバイドフィールドという区別を設けることにより、第２の実施形態においてコンポネント内で定義していたポートにおけるフィールド間の関係性を、当該ポート内で定義することができるので、当該ポートとともに依存性に関する定義も再利用に供することができる。

以下、本実施形態におけるＯＳポートの使用例について説明する。図４０は、本実施形態におけるＧＵＩによるシステム定義の例を示す説明図である。図４０に示すシステム定義によれば、対象システム“system3”が、コンポネント定義“Tomcat_3”によって定義づけられるコンポネントのインスタンスである“tomcat3”コンポネントと、コンポネント定義“Ubuntu_3”によって定義づけられるコンポネントのインスタンスである“ubuntu3”コンポネントとを有し、かつ“tomcat3”コンポネントが有する“os”リファレンスポートと“ubuntu3”コンポネントが有する“os”サービスポートとがワイヤによって接続されていることがわかる。なお、コンポネント定義“Tomcat_3”および“Ubuntu_3”については後述する。

図４１は、本実施形態におけるＧＵＩによるＵｂｕｎｔｕコンポネントの定義例を示す説明図である。図４１には、“Ubuntu_3”という識別子が付されたコンポネント定義の例が示されている。図４１に示すコンポネント定義によれば、当該コンポネント定義によって定義づけられるコンポネントは、“file”フィールドと“package”フィールドと“boot”フィールドという３つのフィールドをもち、さらに、サービスポートとして、ポート定義“OS_3”によって定義づけられる１つのポートが“os”ポートをもつことがわかる。
また、“file”フィールドと“package”フィールドの初期値定義として、“os”ポートの“file”フィールドと“package”フィールドへの参照がそれぞれ定義されている。一方、“boot”フィールドの初期値定義として、“boot3”構成要素が新規に作成される旨が定義されているとともに、“os”ポートの“boot”フィールドに対して本体のコンポネントである当該コンポネントの“boot”フィールドの参照が定義されている。

また、図４２は、本実施形態におけるＧＵＩによるＴｏｍｃａｔコンポネントの定義例である。図４２には、“Tomcat_3”という識別子が付されたコンポネント定義の例が示されている。図４２に示すコンポネント定義によれば、当該コンポネント定義によって定義づけられるコンポネントは、“configFile”フィールドと“package”フィールドをもち、さらに、レファレンスポートとして、ポート定義“OS_3”によって定義づけられる１つの“os”ポートを有していることがわかる。また、本例では、“configFile”フィールドと“package”フィールドの初期値設定において、“tomcatConfig3”構成要素と”tomcatPackage3”構成要素がそれぞれ新規定義されている。さらに、“configFile”フィールドには、“package”フィールドに対する依存性が定義されている。ここで、本例の“os”ポートにおけるプロバイドフィールドである“boot”フィールドについては、当該ポートがリファレンスポートとしてコンポネント定義“Tomcat_3”によって定義づけられるコンポネントに内包されることから本体コンポネントから値の代入を受け付けないことと、ワイヤによるポートの連結処理によっても値が代入されない（当該ポートはリファレンスポートであって他のサービスポートへ移譲する側の立場である）ことから、使用されないフィールドであるとして記載を省略している。

なお、図４０〜図４２に示す例は、第２の実施形態で示した定義と、ｉｄを除き、展開後には同じ構成となる定義の例である。ただし、図４１に示すコンポネント定義“Ubuntu_3”は、ＯＳポート内の“boot”フィールドに対して、当該フィールドの値の代入に関する設定として、本体コンポネントの“boot”フィールドへの参照を定義している点と、当該コンポネントのフィールド間での依存性が省略されている点とが、第２の実施形態におけるコンポネント定義“Ubuntu_2”と異なる。

また、図４３は、ポート連結後のフィールド間の関係を示す説明図である。図４３では、図４０に示したシステム定義に基づいて、ポート連結後の具体化されたシステム定義におけるフィールドを抽出して、それらの関係を示している。なお、第２の実施形態の例では、“ubuntu2.file”フィールドと“ubuntu2.package”フィールドとからそれぞれ“ubuntu2.boot”フィールドへの依存性が設定されていたが（図３０参照）、本例では、“os.file”フィールドと“os.package”フィールドとからそれぞれ“os.boot”フィールドへの依存性が設定されている点が大きく異なっている。なお、第３の実施形態における最終的なシステム構成情報は、図３６に示す第２の実施形態のシステム構成情報と同様である。

［動作の説明］
次に、本実施形態の動作を説明する。本実施形態の動作は、システム定義展開部１０１と構成要素設定部１０２が、ポートのアクセプトフィールドとプロバイドフィールドとを扱う点を除いて第２の実施形態と同様である。

すなわち、システム定義が参照するコンポネント定義およびポート定義に基づき、システム定義が示すコンポネントが有するフィールドの各々に値の代入を行って具体化されたシステム定義を生成する際に、対象ポートがリファレンスポートかサービスポートかに応じて、当該ポートが有するフィールドへの値の代入に制限をかける。例えば、“system3”の“tomcat3”コンポネントの“os”リファレンスポートの“file”フィールドおよび“package”フィールドにおいて、それぞれ本体コンポネントの“configFile”フィールドおよび“package”フィールドへの参照が定義されている。本例のシステム定義展開部１０１は、当該“os”ポートの“file”フィールドおよび“package”フィールドがアクセプトフィールドであるため、当該“os”ポートをリファレンスポートとして有する本体コンポネントからの値の代入を許可する。その結果、“file”フィールドに本体のコンポネントの“tomcat3.configFile”フィールドへの参照である旨が代入され、“package”フィールドに“tomcat3.package”フィールドへの参照である旨が代入された、ポート定義“OS_3”によるポートのインスタンス“os”ポートが、“tomcat3”コンポネントの“os”リファレンスポートとして設定される。

また、この例では、“system3”の“ubuntu3.file”フィールドに対して、“ubuntu3.os.file”フィールドからの参照による初期値の設定が定義されているとともに、“ubuntu3.package”フィールドに対して、“ubuntu3.os.package”フィールドからの参照による初期値の設定が定義されている。その結果、本体のコンポネントである“ubuntu3”コンポネントの“file”フィールドには、当該本体コンポネントが有する“os”サービスポートの“file”フィールドに格納される値が代入される。また、同様に、“ubuntu2”コンポネントの“package”フィールドには、当該本体コンポネントが有する“os”サービスポートの“package”フィールドに格納される値が代入される。ただし、この時点では、参照先である“os”サービスポートの“file”フィールドおよび“package”フィールドに値が代入されていないため、該フィールドへの参照である旨が代入される。また、本例では、“ubuntu3.os.boot”フィールドに対して、“ubuntu3.file”フィールドからの参照による代入の設定が定義されている。システム定義展開部１０１は、当該“os”ポートの“boot”フィールドがプロバイドフィールドであるため、当該“os”ポートをサービスポートとして有する本体コンポネントからの値の代入を許可する。その結果、ポート定義“OS_3”によるポートのインスタンス“os”ポートであって、“boot”フィールドへの依存性を有する“file”フィールドおよび“package”フィールドと、“ubuntu3.boot”フィールドへの参照である旨が代入された“boot”フィールドとを有する“os”ポートが、“ubuntu3”コンポネントの“os”サービスポートとして設定される。その後のポート連結処理は第２の実施形態と同様である。

［効果の説明］
本実施形態によれば、あるポートをリファレンスポートとして持つコンポネントが持つ構成要素と、サービスポートとして持つコンポネントが持つ構成要素との間の関連性に関する設定（例えば、“os”ポートの“file”フィールドと“package”フィールドに対する“boot”フィールドへの依存性の設定等）をポート内で定義でき、これを当該ポートと共に再利用できることにより、より効率的にシステム定義を記述できる。すなわち、抽象化された依存性という設定をポート内で完結させることでより再利用性を高めることができる。

実施形態４．
次に、本発明の第４の実施形態について説明する。第４の実施形態におけるシステム構築支援システム１００の構成は、システム定義展開部１０１と、構成要素設定部１０２の動作が異なる点を除いて第３の実施形態の構成と同様である。以下、第１〜３の実施形態と同様の部位には同一の記号を付し、説明を省略する。

本実施形態では、構成要素の型を扱う点が第１〜第３の実施形態と異なる。以下では、構成要素の型の種類として、当該構成要素の目的に必要な全ての情報要素を持つ具体的な構成要素である具体構成要素と、その一部の情報要素のみを持つ抽象的な構成である抽象構成要素の２種類を扱う。これらの構成要素の型を扱うために、本実施形態のフィールドや構成要素は、“型名”の情報をもつ。そして、システム定義展開部１０１や構成要素設定部１０２は、これらの“型名”に応じた処理を行う。

図４４は、本実施形態におけるＧＵＩによるフィールドおよび構成要素の表現例を示す説明図である。図４４には、“file”フィールドに、“OSFile”型と“FileUbuntu”型という２種類の型が設定された例が示されている。このうち“OSFile”型の“file”フィールドは、様々な種類のＯＳ向けの“file”構成要素となることを意図した抽象構成要素型の例であり、“FileUbuntu”型の“file”フィールドは“Ubuntu”という特定のＯＳ向けの“file”構成要素を扱うことを意図した具体構成要素型の例である。また、“file1”構成要素は、抽象構成要素を表し、“file2”構成要素は具体構成要素を表している。

以下では、ＧＵＩによる表現例として、フィールドの型名を、当該フィールド名とコロン“：”で区切って併記するものとする。なお、構成要素の型名については当該構成要素を格納するフィールドの型と同じ場合には特に記載しないものとする。また、抽象構成要素型のフィールドを背景が白の点線の長方形で示す。また、具体構成要素型のフィールドを背景が斜線パターンの点線の長方形で示す。また、抽象構成要素型の構成要素を背景が白の実線の長方形で示す。また、具体構成要素型の構成要素を背景が黒の長方形で示す。

以下、具体的な例を用いて構成要素の型の使用方法について説明する。図４５は、本実施形態におけるＧＵＩによるシステム定義の例を示す説明図である。図４５に示すシステム定義は、対象システム“system4”が、コンポネント定義“WebApp_4”によって定義づけられるコンポネントのインスタンスである“webApp4”コンポネントと、コンポネント定義“Tomcat_4”によって定義づけられるコンポネントのインスタンスである“tomcat4”コンポネントと、コンポネント定義“Ubuntu_4”によって定義づけられるコンポネントのインスタンスである“ubuntu4”コンポネントを有することを定義している。また、“webApp4”コンポネントの“was”ポートと“tomcat4”コンポネントの“was”ポートが接続されるとともに、“tomcat4”コンポネントの“os”ポートと“ubuntu4”コンポネントの“os”ポートが接続されることを定義している。ここで、ＷｅｂＡｐｐコンポネントの一例である“webApp4”は、Ｗｅｂ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ（以下、ＷｅｂＡｐｐという）の機能に対応したコンポネントを想定している。また、ＷＡＳポートの一例である“was”ポートは、ＷｅｂＡｐｐの機能に関するポートであることを想定している。

また、図４６は、本実施形態におけるＧＵＩによるＯＳポートの定義例を示す説明図である。また、図４７は、図４６に示すポート定義のＪＳＯＮによる定義例を示す説明図である。なお、図４６および図４７に示すポート定義はいずれも同じ構成を示している。また、図４６および図４７に示すポート定義が定義づけるポートの構成は、各フィールドが型名の情報をもつ点を除いて、図３８および図３９に示すポート定義“OS_3”が定義づけるポートの構成と同様である。図４６および図４７に示すポート定義“OS_4”によれば、当該ポート定義によって定義づけられるポートは、“OSFile”という型名の抽象構成要素型の“file”フィールドをアクセプトフィールドとして有している。また、同ポートは、“OSPackage”という型名の抽象構成要素型の“file”フィールドをアクセプトフィールドとして有している。また、同ポートは、“OSBoot”という型名の抽象構成要素型の“boot”フィールドをプロバイドフィールドとして有している。そして、“file”フィールドと“package”フィールドに対して“boot”フィールドへの依存性が定義されている。なお、ＪＳＯＮによる例では、型名が抽象構成要素型か具体構成要素型かまでは示されていないが、各フィールドの型名に対応づけて、当該型が抽象構成要素型か具体構成要素型かの情報が別途保持されているものとする。

また、図４８は、本実施形態におけるＧＵＩによるＷＡＳポートの定義例を示す説明図である。また、図４９は、図４８に示すポート定義のＪＳＯＮによる定義例を示す説明図である。図４８および図４９に示すポート定義“WAS_4”によれば、当該ポート定義によって定義づけられるポートは、“War”という型名の抽象構成要素型の“war”フィールドをアクセプトフィールドとして有し、“OSPacage”という型名の抽象構成要素型の“package”フィールドをプロバイドフィールドとして有している。また、“war”フィールドに対して“package”フォールドへの依存性が定義されている。ここで、“War”型の“war”アクセプトフィールドは、ＷｅｂＡｐｐのプログラム等をアーカイブしたＷＡＲファイルの構成要素を格納することを想定している。また、“OSPackage”型の“package”プロバイドフィールドは、当該“war”フィールドに格納される構成要素をホストとするＷｅｂＡｐｐのインストール処理を構成要素として格納することを想定している。

また、図５０は、本実施形態におけるＧＵＩによるＵｂｕｎｔｕコンポネントの定義例を示す説明図である。図５０には、“Ubuntu_4”というｉｄが付されたコンポネント定義の例が示されている。図５０に示すコンポネント定義は、ｉｄと、各フィールドが型の情報を持つ点と、本体のコンポネントがＯＳポートから値を参照する際に変換処理が定義されている点とが図４１に示す第３の実施形態のＵｂｕｎｔｕコンポネントの定義と異なっている。本例のコンポネント定義では、当該コンポネントが備える“OS_4”型の“os”サービスポートの“file”フィールドおよび“package”フィールドの値を参照して、本体コンポネントの“file”フィールドおよび“package”フィールドに値（構成要素）を複製するに当たり、単に構成要素を複製するのではなく、当該構成要素を適切な具体構成要素型の構成要素に変換して格納するための指定が追加されている。なお、“ubuntu4.os.boot”フィールドに対する“ubuntu4.boot”フィールドへの参照設定に関して、参照先である“ubuntu4.boot”フィールドの“BootUbuntu”型は、代入先である“ubuntu4.os.boot”フィールドの“OSBoot”型の派生型であるため、通常の参照設定により伝搬されるものとしている。

以下、このような具体構成要素への変換を伴う参照を変換呼出しという。また、以下では、変換呼出しを、図５０に示すような、黒丸から参照先（変換元）のフィールドへと接続される２重線の矢印で表現するものとする。なお、図５０には、変換方法の指定方法までは例示されていないが、ＧＵＩによって変換呼出しが指定された場合に、当該変換呼出しの詳細を定義する別画面等が表示されるなどして、ユーザにより変換呼び出しの詳細情報が入力できるものとする。

また、図５１は、本実施形態におけるＪＳＯＮによるＵｂｕｎｔｕコンポネントの定義例を示す説明図である。図５１に示す例は、図５０に示したコンポネント定義とほぼ同様の内容をＪＳＯＮによって定義した例である。図５１に示すコンポネント定義“Ubuntu_4”は、第３の実施形態のコンポネント定義“Ubuntu_3”と比較して、“フィールド”要素に、格納可能な構成要素の型名の定義が追加されているとともに、“初期値”設定の種別に“変換呼出し”が追加されている。さらに、コンポネント定義“Ubuntu_4”は、初期化設定の種別が“変換呼出し”である場合に、“初期値”設定に“変換方法”要素と“引数”要素とを含んでいる。また、当該コンポネント定義は、“id”要素、“ポート”要素（“サービスポート”要素または“リファレンスポート”要素）と、“フィールド”要素に加えて、“変換”の要素を有する。また、“変換”要素における各々の要素である変換定義は、変換要素名に対応づけて、“戻り値型名”、“引数”、“属性割当て”の３つの要素を含む。ここで、“戻り値型名”には、当該変換の結果として受け取る構成要素の型名を指定する。“引数”には、変換対象となる構成要素を格納するフィールドの名前に対応づけて、当該構成要素の型名を指定する。“属性割当て”には、変換後の構成要素に新規に割り当てる属性値があれば、その定義方法を指定する。“属性割当て”の指定方法の一例として、上記の“引数”で指定した変換元の構成要素を参照し、その属性値を用いることができる。例えば、“変換”要素に含まれる変換定義“convertFile”は、“file”フィールドに格納される“OSFile”型の“file”構成要素を、“FileUbuntu”型の構成要素に変換する定義である。その際の“属性割当て”として、“file”フィールドに格納される変換後の構成要素の“name”属性値として、変換前の“OSFile”型の“file”構成要素の“name”属性の値がそのまま割り当てられる旨が定義されている。また、変換呼出しが設定されている“file”フィールドの“初期値”設定には、“変換呼出し”である旨とともに、“変換方法”設定として“変換”要素のうちのいずれかの変換方法定義が指定されている。また、“引数”設定として、“os”ポートの“file”フィールドが指定されている。これは、変換方法である“convertFile”に渡される引数すなわち変換元の構成要素として、“os.file”フィールドに格納される“file”構成要素を用いることを意味している。

このように、構成要素の値が“変換呼出し”である場合、“種別”には変換呼出しである旨が指定され、“変換方法”には、同定義内の変換定義の名前が指定され、“引数”には変換対象となる構成要素が指定されてもよい。

なお、図５１に示すように、変換呼出しにおける変換方法の指定には、例えば先頭にアンドマーク“＆”を付加した変換名によって表現することができる。

また、図５２は、本実施形態におけるＧＵＩによるＴｏｍｃａｔコンポネントの定義例を示す説明図である。図５２には、“Tomcat_4”というｉｄが付されたコンポネント定義の例が示されている。図５２に示すコンポネント定義によれば、当該コンポネント定義によって定義づけられるコンポネントが、“OSPackage”型の“package”フィールドと、ポート定義“OS_4”によって定義づけられる“os”リファレンスポートと、ポート定義“WAS_4”によって定義づけられる“was”サービスポートを有することが定義されている。また、該コンポネントにおいて、“os”リファレンスポートの“package”フィールドと“was”サービスポートの“package”フィールドはともに、本体のコンポネントの“package”フィールドを参照する設定となっている。また、該コンポネントにおいて、“os”リファレンスポートのfileフィールドは、“was”サービスポートの“war”フィールドに対して変換呼出しによる代入が設定されている。また、“package”フィールドの初期値として定義される構成要素“tomcatPackage4”の“name”属性の値には“tomcat”が設定されている。これは、当該構成要素が、tomcatのインストール処理等を含む構成要素であることを示している。

また、図５３は、本実施形態におけるＪＳＯＮによるＴｏｍｃａｔコンポネントの定義例を示す説明図である。なお、図５３に示す例は、図５２に示したコンポネント定義をＪＳＯＮによって定義した例である。本例では、“os”リファレンスポートの“file”フィールドから“was”サービスポートの“war”フィールドに対する変換呼出しの変換方法として、“&convertWar”が設定されている。そして、同コンポネント定義の“変換”要素において、“convertWar”が定義されている。この“convertWar”では、“War”型の構成要素を“war”フィールドから受け取り、“OSFile”型の構成要素に変換して返す。その際、属性割当てとして、変換後の“OSFile”型の構成要素の“name”属性値に、“Tomcat”独自のファイルパスの例として示した“/usr/local/tomcat”と変換対象の“War”型の構成要素の“name”属性値の値を連結した文字列を設定することが指定されている。

また、図５４および図５５は、本実施形態におけるＷｅｂＡｐｐコンポネントの定義例を示す説明図である。なお、図５４はＧＵＩによる定義例を示し、図５５はＪＳＯＮによる定義例を示している。なお、いずれも“WebApp_4”という識別子が付されたコンポネント定義の例を示している。図５４および図５５に示すコンポネント定義によれば、当該コンポネント定義によって定義づけられるコンポネントが、“War”型の“war”フィールドであって初期値として“war4”構成要素が格納される“war”フィールドと、ポート定義“WAS_4”によって定義づけられる“was”リファレンスポートを有することが定義されている。また、該コンポネントにおいて、“war”リファレンスポートの“war”フィールドが、本体のコンポネントの“war”フィールドを参照する設定となっている。また、“war”フィールドの値である“war4”構成要素の“name”属性値には、当該“war”ファイルのファイル名である“app.war”が指定されている。

また、図５６は、ポート連結後のフィールド間の関係を示す説明図である。図５６では、図４５に示すシステム定義に基づいて展開された、ポート連結後の具体的なシステム定義におけるフィールド間の関係を示している。図５６に示すように、参照だけでなく変換呼出しによっても、構成要素が伝搬されることがわかる。例えば、“webApp4.war”フィールドに格納された“war”型の抽象構成要素である“war4”構成要素は、“tomcat4.was.war”フィールドを介して、“ubuntu4.os.file”フィールドに伝搬される。その際、“war”型から抽象構成要素型の“OSFile”型に変換される。さらに、この“OSFile型に変換後の“war4”構成要素は、“ubuntu4.file”フィールドに伝搬される。その際、“OSFile”型から具体構成要素型の“fileubuntu”型に変換される。

［動作の説明］
本実施形態の動作は、システム定義展開部１０１と構成要素設定部１０２が、フィールドや構成要素に定義された構成要素の型を扱う点と、フィールドの値として“変換呼出し”を扱う点を除いて第３の実施形態の動作と同様である。

すなわち、フィールドに格納された構成要素を取得するプロセス（図３１のＳ２３１）において、構成要素設定部１０２は、まず対象フィールドに格納された値を確認し、値が変換呼出しであれば、変換元に指定された構成要素を取得した上で変換方法に指定された変換方法定義を基にこれを変換し、その結果として得られた構成要素を複製して、変換呼出し元のフィールドである対象フィールドに格納した上で取得する。

また、図５７は、図５６に示したフィールド間の関係性から変換呼出しを含む参照等による構成要素を解決した後の構成要素間の関係性を示す説明図である。本例では、変換呼出しによる構成要素の伝搬があるため、構成要素の完全な複製ではなく、伝搬元と伝搬先とで構成要素の型や属性値が異なる場合がある。

また、図５８は、本実施形態における、フィールドの値への参照設定を解決後の構成要素のデータ例である。図５８には、“ubuntu4”コンポネントの“file”フィールド（すなわち“ubuntu4.file”フィールド）内に格納される、構成要素の情報の例が示されている。ワイヤに基づくポートの連結処理と、参照の解決処理とを経た結果、図５８に示すように、当該“file”フィールドに格納される構成要素の情報として、複製元の構成要素の識別子（本例では、“war4_2”）と、当該フィールドに格納される構成要素の識別子（本例では、“war4_3”）と、変換後の型名と、変換後に付される属性値の情報とが保持されてもよい。なお、この構成要素の大元の構成要素は、“webApp4”コンポネントの“war”フィールドに格納された“War”型の“war4”構成要素である。当該構成要素は、“tomcat4”コンポネント内で“OSFile”型に変換される他、“name”属性値の値が変更される。
さらに“ubuntu4“コンポネント内で“FileUbuntu”型に変換される。その結果、“型名“には“FileUbuntu”型が指定されており、“属性値“としてはname属性値に“/usr/local/tomcat/app.war”が指定される。

なお、本実施形態における構成要素設定部１０２による構成要素の集約処理は、厳密には上記の各実施形態の集約処理と異なる。本実施形態における構成要素の集約処理、すなわち新規定義された構成要素と、変換されたものを含む複製の構成要素からなる一連の構成要素群を出力情報である単一の構成要素にまとめる処理では、次のように処理する。すなわち、出力情報である単一の構成要素に、一連の構成要素群の新規定義された構成要素の識別子を持たせ、複製による伝搬の末端に位置する具体構成要素の型および属性値を型および属性値として持たせ、全ての複製に付与された関連性の集合を、当該構成要素の関連性の情報として持たせる。

そのために、構成要素設定部１０２は、例えば、各フィールドに格納された構成要素のコピー元構成要素の“id”をトレースして、各構成要素群を構成する構成要素の集合と、コピー元の末端である新規定義された構成要素と、具体構成要素型の構成要素とを特定する。そして、新規定義された構成要素から”id”と、具体構成要素型の構成要素から型および属性値と、全ての構成要素から依存性とを集めることにより、出力の構成要素の情報を合成する。このとき、構成要素設定部１０２は、参照関係にあるフィールド全体において、具体的な構成要素が指定される箇所が１箇所であることを検証する機能を有していてもよい。例えば、構成要素設定部１０２は、参照関係にある一連のフィールドに格納される構成要素群に複数の具体構成要素型が含まれる場合に、エラーを検出してもよい。

このように、参照関係にあるフィールド全体において、具体的な構成要素が指定される箇所が１箇所に限定されることで、当該構成要素の正しい配備処理が実現される。単一の構成要素が複数個所で実現される状況は、本例のような対象システムの構築処理を定義する用途では意図しない状況といえる。したがって、そのような場合には、単一の構成要素が複数個所で実現されるような状況を検出し、警告することが好ましい。

図５９は、設定の付与を実施した後の構成要素間の関係性を示す説明図である。なお、図５９において、構成要素の複製を表す網掛け長方形の上部に付した名前は当該複製の型名およびｉｄを示している。

また、図６０と図６１は、本実施形態におけるシステム構成情報の例を示す説明図である。なお、図６０は、上述した定義を基に構成要素を生成した結果、生成されるシステム構成情報のＧＵＩによる表示例を示す説明図である。また、図６１は、該システム構成情報のＪＳＯＮによる出力例を示す説明図である。なお、図６０および図６１はいずれも同じ構成を示している。

［効果の説明］
本実施形態によれば、コンポネントの組み合わせに応じて構成要素の属性値や型といった情報が適切に調整されることで、さらに効率的にシステム定義を定義できる。例えば、本実施形態によれば、構成要素の型をホストに応じて適切に変換することができ、最終的に生成される構成要素をそのホストに応じた具体的なものにできる。また、そのための設定を接続先のホスト側に閉じ込めておけるので、ユーザはホスト先を柔軟に決定することができる。

以下、上述したシステム定義を変更して、コンポネントの再利用性について具体例を用いて説明する。図６２は、ＧＵＩによるシステム定義の他の例を示す説明図である。なお、図６２（ａ）には、Ｕｂｕｎｔｕに代えてＣｅｎｔＯＳを用いるシステムの例として“system4_2”が示されており、図６２（ｂ）には、Ｔｏｍｃａｔに代えてＪｅｔｔｙを用いるシステムの例として“system4-3”が示されており、図６２（ｃ）には、Ｕｂｕｎｔｕに代えてＣｅｎｔＯＳを用い、かつＴｏｍｃａｔに代えてＪｅｔｔｙを用いるシステムの例として“system4-4”が示されている。また、図６３は、図６２（ａ）に示したシステム定義のＪＳＯＮによる定義例を示す説明図である。ここで、図６２（ｂ）および図６２（ｃ）においてＪｅｔｔｙコンポネントの一例として示した“mw”コンポネントは、Ｗｅｂアプリケーションの一種であるｊｅｔｔｙに対応したコンポネントを想定している。

また、図６４および図６５は、本実施形態におけるＣｅｎｔＯＳコンポネントの定義例を示す説明図である。図６４および図６５に示すコンポネント定義“CentOS_4”によれば、当該コンポネント定義によって定義づけられるコンポネントは、上記のコンポネント定義“Ubuntu_4”の場合と同様に、“OS_4”によって定義される“os”サービスポートを有する。一方で、“file”フィールド、“package”フィールド、“boot”フィールドの型はそれぞれ“FileCentOS”型、“PackageCentOS”型、“BootCentOS”型のように、“CentOS”に特化した型となっている。また、“os.file”フィールドと、“os.package”フィールドから本体のコンポネント内の対応する各フィールドへの構成要素を再割り当てするための変換呼出しにおいて、それぞれの返り値に“FileCentOS”型と“PackageCentOS”型を持つ。ただし、本体のコンポネント内の“boot”フィールドから“os.boot”フィールドへの値の再割り当てについては、“Ubuntu_4”と同様、通常の参照設定となっている。これは、“BootCentOS”型が“OSboot”型の派生型であるためである。

また、図６６および図６７は、本実施形態におけるＪｅｔｔｙコンポネントの定義例を示す説明図である。図６６および図６７に示すコンポネント定義“Jetty_4”によれば、当該コンポネント定義によって定義づけられるコンポネントは、上記のコンポネント定義“Tomcat_4”の場合と同様に、“WAS_4”によって定義づけられる“was”リファレンスポートを有するとともに、“OSPackage”型の“package”フィールドを有する。ただし、“package”フィールドの初期値として定義される構成要素“jettyPackage4”の“name”属性は“jetty”となっている。これは、当該構成要素がＪｅｔｔｙのインストール処理等を含む構成要素であることを示している。また、変換方法“convertWar”における属性割当てが、Ｊｅｔｔｙにおけるディレクトリ構造を踏まえたルールとなっている。

このように、コンポネント定義“CentOS_4”は、コンポネント定義“Ubuntu_4”と同様のポート構成をもつコンポネントを定義し、またコンポネント定義“Jetty_4”はコンポネント定義“Tomcat_4”と同様のポート構成をもつコンポネントを定義している。これは、交換可能性を有していることを意味している。例えば、図６２（ａ）〜（ｃ）に示す例では、“WebApp_4”によって定義されるコンポネント“app”を配備する一方で、“mw”コンポネントと“vm”コンポネントの型の組み合わせが異なるシステムが定義されている。さらにコンポネントの定義を増やすことで、選択可能なパターン数は指数関数的に増加することとなる。このように、コンポネントの再利用性により少ない定義から多様なシステムが効率的に記述可能となる。

実施形態５．
次に、本発明の第５の実施形態について説明する。第５の実施形態におけるシステム構築支援システム１００の構成は、システム定義展開部１０１と構成要素設定部１０２の動作が異なる点を除いて、第４の実施形態の構成と同様である。以下、第１〜４の実施形態と同様の部位には同一の記号を付し、説明を省略する。

本実施形態の主な特徴は、各フィールドが構成要素の情報として、構築処理等の構成要素の内容だけでなく、構成要素が取り得る状態や可能な状態遷移の情報をもつ点、および、フィールド間の関連性を示す情報が、当該フィールドに格納される構成要素のある状態から他の構成要素のある状態に対して指定される点である。このような関連性は、前者の構成要素が当該状態遷移を実行するには後者の構成要素が当該状態になければならないという制約条件を意味する。

図６８は、本実施形態におけるＧＵＩによる構成要素および構成要素間の関連性の表現例を示す説明図である。図６８には、“War”型の“war”構成要素と、“OSPackage”型の“package”構成要素という２つの構成要素の例が示されている。“war”構成要素は、“f”と、“t”という２つの状態と、当該状態間を相互に結ぶ状態遷移を持つ。同様に、“package”構成要素も“f”と“t”という２つの状態と当該状態間を相互に結ぶ状態遷移を持つ。また、“war”構成要素は、“f”状態から“t”状態へと至る状態遷移、および“t”状態から“f”状態へと至る状態遷移において、“package”構成要素の“t”状態に対する依存性を有している。また、“package”構成要素は、“t”状態から“f”状態へと至る状態遷移において、“war”構成要素の“f”状態に対する依存性を有している。
これは、“war”構成要素が“f”状態から“t”状態に遷移するもしくは“t”状態から“f”状態に遷移する場合に、“package”構成要素の状態が“t”状態にいなければならないことを表している。また、“package”構成要素が“t”状態から“f”状態に遷移する場合に、“war”構成要素の状態が“f”状態にいなければならないことを表している。

また、図６９は、ＪＳＯＮによる構成要素の型の定義例を示す説明図である。また、図７０は、ＪＳＯＮによる構成要素の定義例を示す説明図である。なお、図７０における各構成要素は、型名として指定する構成要素型が保持する状態や状態遷移を持つと解釈できる。また、図７０において、“f->t”といった記載は、“f”状態から“t”状態への状態遷移を示しており、“package(t)”といった記載は、“package”構成要素の“t”状態を示している。なお、図７０では、構成要素の定義として、当該構成要素がもつ他の構成要素に対する依存性を設定する例を示したが、同様の定義をフィールドに対して設定することも可能である。その場合、設定されたフィールドに格納される構成要素が、型名として指定する構成要素型が保持する状態や状態遷移を持ったり、設定されたフィールドに格納される構成要素が状態遷移等する場合に、指定した他のフィールドに格納される構成要素の状態等に対して依存性をもつと解釈できる。また、上記例では構成要素やフィールドが型情報を持つ場合を例にして説明しているが、本実施形態において構成要素やフィールドの型情報は必須ではない。

上述したような情報を用いると、さらに状況に応じて各構成要素に現在状態と要求状態を指定することにより、各構成要素を指定した現在状態から要求状態へ変更するための手順を状態遷移の羅列として導出することができる。

例えば、“war”構成要素と“package”構成要素の現在状態をともに“f”状態とし、“war”構成要素と“package”構成要素の要求状態をともに“t”状態に指定した場合であれば、“war”構成要素を“f”状態から“t”状態へ遷移させるには、“package”構成要素が“t”状態でなければならないことから、まず“package”構成要素を“f”状態から“t”状態へ遷移させ、その後“war”構成要素を“f”状態から“t”状態へ遷移させるという手順が導出できる。

なお、そのような手順は、一般に「Ａｕｔｏｍａｔｅｄ Ｐｌａｎｎｉｎｇ（自動計画）」と呼ばれる手法により導出できる。当該手法は、初期状態、要求状態、状態変換方法、状態変換の制約条件の各情報により、制約条件を満たしつつ初期状態を要求状態へ至らしめる状態変換の順序を求める手法である。

本発明のシステム構築支援システム１００は、このような状態遷移を有する構成要素においても利用できる。

また、図７１は、本実施形態におけるＪＳＯＮによるＷＡＳポートの定義例を示す説明図である。このように、本実施形態では、依存性の定義の仕方が上記の各実施形態と異なる。すなわち、“依存元遷移”として、ある構成要素またはフィールドに格納される構成要素が持つ状態遷移が指定され、“依存先状態”として、他の構成要素またはフィールドに格納される構成要素が持つ状態が指定されてもよい。

［動作の説明］
本実施形態の動作は、システム定義展開部１０１と構成要素設定部１０２が、状態と状態遷移およびある構成要素の状態遷移から他の構成要素の状態への依存性を持つような構成要素またはそのような構成要素を格納するフィールドを扱う点を除いて、第４の実施形態と同様である。

［効果の説明］
本実施形態によれば、状態と状態遷移およびある構成要素の状態遷移から他の構成要素の状態への依存性を持つような構成要素を有するシステムであっても、そのような構成要素またはそのような構成要素を格納するフィールドを有するコンポネントを用いることで、容易に定義できる。

なお、本実施形態に限らず、上述した第１〜第４の実施形態においても、システムの構築手順を生成することが可能である。例えば、図６や図７に示した情報によれば、構築処理を保持する各構成要素が依存性で連結されている旨が示されている。依存性に循環がない限りにおいて、このような情報を基に依存性を満たしつつ全ての構築処理を実施するための順序を決定することができる。

例えば、依存性に循環がなければ、他の構成要素への依存性を一切持たない構成要素が必ず１つ以上存在する。まず、このような構成要素の構築処理を実行するようにすればよい。その結果、保持する全ての依存性が解決される構成要素が出てくるので、そのような構成要素の構築処理を、上記の構築処理の後に実行するようにすればよい。移行、先行する構築処理の実行により依存性が解決される構成要素を順次実行するようにすることにより、必ず全ての構築要素の構築処理が実行される。このような順序の決定アルゴリズムは、一般に「トポロジカルソート」として知られている。

次に、本発明の概要について説明する。図７２は、本発明の概要を示すブロック図である。図７２に示すシステム構築支援システムは、システム定義入力手段５０１と、設定付与手段５０２とを備えている。

システム定義入力手段５０１（例えば、システム定義入力部００１）は、構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも１つ以上有するコンポネントを定義づける情報であるコンポネント定義であって、定義対象とされるコンポネントが有するフィールドの情報であるフィールド定義と、フィールドに対応づけられる構成要素に対する設定に関する情報である設定定義（例えば、“代入”定義等）とを含むことができるコンポネント定義を用いたコンポネントの指定と、コンポネントが有するフィールドに対する構成要素の割り当てに関する割当定義とを少なくとも含むシステム定義を入力する。

設定付与手段５０２（例えば、システム定義展開部１０１および構成要素設定部１０２）は、システム定義およびコンポネント定義に基づいて、指定されたコンポネントのフィールドに構成要素を対応づけるとともに、フィールドに対して定義された設定内容を、フィールドに対応づけられた構成要素に反映することにより、対象システムを構成する構成要素に対する設定の付与を行う。

このような構成を備えることにより、構成要素に対する設定に関する情報を、抽象化したコンポネントの情報として閉じ込めることができ、そのような設定に関する情報に対しても再利用性を持たせることができる。したがって、システム定義の容易性を向上させることができる。

また、図７３は、本発明のシステム構築支援システムの他の構成例を示すブロック図である。図７３に示すように、システム構築支援システムは、少なくとも２以上のコンポネント定義を格納する部品定義記憶手段５０３（例えば、部品定義記憶部００３）や、対象システムを構成する具体的な構成要素の情報であって、構成要素に付与された設定の内容を含む情報であるシステム構成情報を出力するシステム構成出力手段５０４（例えば、システム構成出力部００２）を備えていてもよい。

なお、コンポネント定義に含まれる設定定義は、対象とされたフィールドに対応づけられる構成要素の属性値または構成要素が有する他の構成要素との間の関連性を示す情報を少なくとも含んでいてもよい。

また、関連性を示す情報における他の構成要素の指定が、他の構成要素が対応づけられるいずれかのフィールドの指定により行われてもよい。

また、コンポネント定義は、対象とされたフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義（例えば、“初期値”定義等）を含むことができ、設定付与手段は、システム定義により指定されたコンポネントのコンポネント定義に割当定義が含まれている場合に、割当定義に基づいて、割当定義が指定するフィールドに構成要素を対応づけてもよい。

また、割当定義は、割り当て対象の構成要素が、新規定義であるか、他のフィールドからの参照であるかを指定する情報を含み、設定付与手段は、システム定義により指定されたコンポネントのコンポネント定義に含まれる割当定義が新規定義を指定している場合に、指定された構成要素を生成した上で割当定義が指定するフィールドに対応づけ、割当定義が他のフィールドからの参照を指定している場合に、割当定義が指定されたフィールドに対して他のフィールドに対応づけられている構成要素を対応づけてもよい。

コンポネント定義は、定義対象とされるコンポネントが他のコンポネントと接続するための端子機能を抽象化した概念であるポートであって、ポート定義により定義づけられ、接続処理に必要な構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも１つ以上有するポートの指定を含み、ポート定義は、定義対象とされるポートが有するフィールドの情報であるフィールド定義を含み、システム定義は、ポート間の接続を指定する情報を含み、設定付与手段は、接続関係にあるポートの対応するフィールド間で、対応づけられる構成要素の情報および構成要素に対して付与された設定を伝搬させてもよい。

また、ポート定義は、定義対象とされるポートが有するフィールドに対応づけられる構成要素に対する設定に関する情報である設定定義（例えば、“設定”定義）を含むことができ、設定付与手段は、ポート定義に設定定義が含まれている場合は、フィールドに対して定義された設定内容を、フィールドに対応づけられた構成要素に反映した上で、接続関係にあるポートの対応するフィールド間で設定を伝搬させてもよい。

コンポネント定義は、定義対象とされるコンポネントがポートを有している場合に、ポートが有するフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義を含むことができ、割当定義は、割り当て対象の構成要素が、コンポネントが有するフィールドからの参照である旨の指定を含んでいてもよい。

また、コンポネント定義は、定義対象とされるコンポネントがポートを有している場合に、コンポネントが有するフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義を含むことができ、割当定義は、割り当て対象の構成要素が、ポートが有するフィールドからの参照である旨の指定を含んでいてもよい。

また、ポート定義は、定義対象とされるポートが有するフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義（例えば、“初期値”定義）を含むことができ、割当定義は、割り当て対象の構成要素が、ポートに対応づけられる任意のコンポネントが有するフィールドからの参照である旨の指定を含んでいてもよい。

また、コンポネント定義またはシステム定義は、コンポネントが有するポートが、他のポートが提供する接続機能の利用を示すリファレンスポートであるか、他のポートへの接続機能の提供を示すサービスポートであるかを指定することができ、ポート定義は、定義対象とされるポートが有するフィールドが、リファレンスポートからサービスポートへの構成要素の伝搬を扱うアクセプトフィールドであるか、サービスポートからリファレンスポートへの構成要素の伝搬を扱うプロバイドフィールドであるかを指定することができ、設定付与手段は、コンポネント定義またはシステム定義およびポート定義に基づいて、サービスポートのアクセプトフィールドに対して当該サービスポートを有するコンポネントのフィールドからの参照による構成要素の割り当てを制限し、リファレンスポートのプロバイドフィールドに対して当該リファレンスポートを有するコンポネントのフィールドからの参照による構成要素の割り当てを制限してもよい。

また、割当定義は、構成要素の変換方法に関する情報である変換定義を含むことができ、設定付与手段は、フィールドへ構成要素を対応づける際に、変換定義に基づいて、指定された構成要素を変換した上で対応づけてもよい。

また、コンポネント定義は、フィールドが格納可能な構成要素の種類に関する情報である型に関する情報を含み、割当定義は、割り当て対象とされる構成要素の型に関する情報を含み、型は、他の型を包含することができ、設定付与手段は、フィールドへの構成要素の対応づけを、当該フィールドに対して設定されている型が、割り当て対象の構成要素の型と一致もしくは包含関係にある場合に限定してもよい。

また、システム構築支援システムは、構成要素の型の種類として、必須の情報を全て備えた具体構成要素と、必須の情報の一部のみを備えた抽象構成要素とを有し、割当定義は、構成要素の変換方法に関する情報である変換定義を含むことができ、変換定義は、変換元と変換先の構成要素の型を指定する情報を含み、変換定義における型の指定は、変換元が抽象構成要素型であって変換先が抽象構成要素型であるか、変換元が抽象構成要素型であって変換先が具体構成要素型であるかのいずれかであってもよい。

また、設定付与手段は、システム定義により指定されたコンポネントが有するフィールドに対する割当定義に、割り当て対象の構成要素の指定に他のフィールドからの参照が含まれる場合に、参照関係にあるフィールド全体において、具体的な構成要素が指定される箇所が１箇所であることを検証してもよい。

また、構成要素は、状態と状態遷移の情報を含んでいてもよく、その場合、構成要素間の関連性を示す情報は、ある一方の構成要素内の状態遷移から他の構成要素内の状態への依存性を示す情報であってもよい。

以上、本発明を、上述した模範的な実施形態に適用した例として説明した。しかしながら、本発明の技術的範囲は、上述した各実施形態に記載した範囲には限定されない。当業者には、係る実施形態に対して多様な変更又は改良を加えることが可能であることは明らかである。そのような場合、係る変更又は改良を加えた新たな実施形態も、本発明の技術的範囲に含まれ得る。更に、上述した各実施形態、あるいは、係る変更又は改良を加えた新たな実施形態を組み合わせた実施形態も、本発明の技術的範囲に含まれ得る。そしてこのことは、請求の範囲に記載した事項から明らかである。

この出願は、２０１５年８月２７日に出願された日本出願特願２０１５−１６７７９７を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明は、ＩＴシステムに限らず、複数の部品からなるシステムを構築する際の設計支援に好適に適用可能である。

１００ システム構築支援システム
００１ システム定義入力部
００２ システム構成出力部
００３ 部品定義記憶部
１０１ システム定義展開部
１０２ 構成要素設定部
５０１ システム定義入力手段
５０２ 設定付与手段
５０３ 部品定義記憶手段
５０４ システム構成出力手段

Claims (20)

1. 構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも１つ以上有するコンポネントを定義づける情報であるコンポネント定義であって、前記フィールドの情報であるフィールド定義と、前記フィールドに対応づけられる構成要素に対する設定に関する情報である設定定義とを含むことができるコンポネント定義を用いたコンポネントの指定と、前記コンポネントが有するフィールドに対する構成要素の割り当てに関する割当定義とを少なくとも含むシステム定義を入力するシステム定義入力手段と、
   前記システム定義および前記コンポネント定義に基づいて、指定されたコンポネントのフィールドに構成要素を対応づけるとともに、前記フィールドに対して定義された設定内容を、前記フィールドに対応づけられた構成要素に反映することにより、対象システムを構成する構成要素に対する設定の付与を行う設定付与手段とを備えた
   ことを特徴とするシステム構築支援システム。
2. コンポネント定義に含まれる設定定義は、対象とされたフィールドに対応づけられる構成要素の属性値または前記構成要素が有する他の構成要素との間の関連性を示す情報を少なくとも含む
   請求項１に記載のシステム構築支援システム。
3. 関連性を示す情報における他の構成要素の指定が、前記他の構成要素が対応づけられるいずれかのフィールドの指定により行われる
   請求項２に記載のシステム構築支援システム。
4. コンポネント定義は、対象とされたフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義を含むことができ、
   設定付与手段は、システム定義により指定されたコンポネントのコンポネント定義に前記割当定義が含まれている場合に、前記割当定義に基づいて、前記割当定義が指定するフィールドに構成要素を対応づける
   請求項１から請求項３のうちのいずれか１項に記載のシステム構築支援システム。
5. 割当定義は、割り当て対象の構成要素が、新規定義であるか、他のフィールドからの参照であるかを指定する情報を含み、
   設定付与手段は、システム定義により指定されたコンポネントのコンポネント定義に含まれる前記割当定義が新規定義を指定している場合に、指定された構成要素を生成した上で前記割当定義が指定するフィールドに対応づけ、前記割当定義が他のフィールドからの参照を指定している場合に、前記割当定義が指定されたフィールドに対して前記他のフィールドに対応づけられている構成要素を対応づける
   請求項４に記載のシステム構築支援システム。
6. コンポネント定義は、定義対象とされるコンポネントが他のコンポネントと接続するための端子機能を抽象化した概念であるポートであって、ポート定義により定義づけられ、接続処理に必要な構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも１つ以上有するポートの指定を含み、
   前記ポート定義は、定義対象とされるポートが有するフィールドの情報であるフィールド定義を含み、
   前記システム定義は、ポート間の接続を指定する情報を含み、
   設定付与手段は、接続関係にあるポートの対応するフィールド間で、対応づけられる構成要素の情報および前記構成要素に対して付与された設定を伝搬させる
   請求項１から請求項５のうちのいずれか１項に記載のシステム構築支援システム。
7. ポート定義は、定義対象とされるポートが有するフィールドに対応づけられる構成要素に対する設定に関する情報である設定定義を含むことができ、
   設定付与手段は、ポート定義に前記設定定義が含まれている場合に、前記フィールドに対して定義された設定内容を、前記フィールドに対応づけられた構成要素に反映した上で、接続関係にあるポートの対応するフィールド間で前記設定を伝搬させる
   請求項６に記載のシステム構築支援システム。
8. コンポネント定義は、定義対象とされるコンポネントがポートを有している場合に、前記ポートが有するフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義を含むことができ、
   前記割当定義は、割り当て対象の構成要素が、前記コンポネントが有するフィールドからの参照である旨の指定を含むことができる
   請求項６または請求項７に記載のシステム構築支援システム。
9. コンポネント定義は、定義対象とされるコンポネントがポートを有している場合に、前記コンポネントが有するフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義を含むことができ、
   前記割当定義は、割り当て対象の構成要素が、前記ポートが有するフィールドからの参照である旨の指定を含むことができる
   請求項６から請求項８のうちのいずれか１項に記載のシステム構築支援システム。
10. ポート定義は、定義対象とされるポートが有するフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義を含むことができ、
    前記割当定義は、割り当て対象の構成要素が、前記ポートに対応づけられる任意のコンポネントが有するフィールドからの参照である旨の指定を含むことができる
    請求項６から請求項９のうちのいずれか１項に記載のシステム構築支援システム。
11. コンポネント定義またはシステム定義は、コンポネントが有するポートが、他のポートが提供する接続機能の利用を示すリファレンスポートであるか、他のポートへの接続機能の提供を示すサービスポートであるかを指定することができ、
    ポート定義は、定義対象とされるポートが有するフィールドが、リファレンスポートからサービスポートへの構成要素の伝搬を扱うアクセプトフィールドであるか、サービスポートからリファレンスポートへの構成要素の伝搬を扱うプロバイドフィールドであるかを指定することができ、
    設定付与手段は、前記コンポネント定義または前記システム定義および前記ポート定義に基づいて、サービスポートのアクセプトフィールドに対して当該サービスポートを有するコンポネントのフィールドからの参照による構成要素の割り当てを制限し、リファレンスポートのプロバイドフィールドに対して当該リファレンスポートを有するコンポネントのフィールドからの参照による構成要素の割り当てを制限する
    請求項６から請求項１０のうちのいずれか１項に記載のシステム構築支援システム。
12. 割当定義は、構成要素の変換方法に関する情報である変換定義を含むことができ、
    設定付与手段は、フィールドへ構成要素を対応づける際に、前記変換定義に基づいて、指定された構成要素を変換した上で対応づける
    請求項１から請求項１１のうちのいずれか１項に記載のシステム構築支援システム。
13. コンポネント定義は、フィールドが格納可能な構成要素の種類に関する情報である型に関する情報を含み、
    割当定義は、割り当て対象とされる構成要素の型に関する情報を含み、
    前記型は、他の型を包含することができ、
    設定付与手段は、フィールドへの構成要素の対応づけを、当該フィールドに対して設定されている型が、割り当て対象の構成要素の型と一致もしくは包含関係にある場合に限定する
    請求項１から請求項１２のうちのいずれか１項に記載のシステム構築支援システム。
14. 構成要素の型の種類として、必須の情報を全て備えた具体構成要素と、必須の情報の一部のみを備えた抽象構成要素とを有し、
    割当定義は、構成要素の変換方法に関する情報である変換定義を含むことができ、
    前記変換定義は、変換元と変換先の構成要素の型を指定する情報を含み、
    前記変換定義における型の指定は、変換元が抽象構成要素型であって変換先が抽象構成要素型であるか、変換元が抽象構成要素型であって変換先が具体構成要素型であるかのいずれかである
    請求項１３に記載のシステム構築支援システム。
15. 設定付与手段は、システム定義により指定されたコンポネントが有するフィールドに対する割当定義に、割り当て対象の構成要素の指定に他のフィールドからの参照が含まれる場合に、参照関係にあるフィールド全体において、具体的な構成要素が指定される箇所が１箇所であることを検証する
    請求項１から請求項１４のいずれか１項に記載のシステム構築支援システム。
16. 構成要素は、状態と状態遷移の情報を含み、
    構成要素間の関連性を示す情報は、ある一方の構成要素内の状態遷移から他の構成要素内の状態への依存性を示す情報である
    請求項１から請求項１５のいずれか１項に記載のシステム構築支援システム。
17. 少なくとも２以上のコンポネント定義を格納する部品定義記憶手段を備えた
    請求項１から請求項１６のうちのいずれか１項に記載のシステム構築支援システム。
18. 対象システムを構成する具体的な構成要素の情報であって、前記構成要素に付与された設定の内容を含む情報であるシステム構成情報を出力するシステム構成出力手段を備えた 請求項１から請求項１７のうちのいずれか１項に記載のシステム構築支援システム。
19. 情報処理装置が、構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも１つ以上有するコンポネントを定義づける情報であるコンポネント定義であって、前記フィールドの情報であるフィールド定義と、前記フィールドに対応づけられる構成要素に対する設定に関する情報である設定定義とを含むことができるコンポネント定義を用いたコンポネントの指定と、前記コンポネントが有するフィールドに対する構成要素の割り当てに関する割当定義とを少なくとも含むシステム定義を受け付けると、前記システム定義および前記コンポネント定義に基づいて、指定されたコンポネントのフィールドに構成要素を対応づけるとともに、前記フィールドに対して定義された設定内容を、前記フィールドに対応づけられた構成要素に反映することにより、対象システムを構成する構成要素に対する設定の付与を行う
    ことを特徴とするシステム構築支援方法。
20. コンピュータに、
    構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも１つ以上有するコンポネントを定義づける情報であるコンポネント定義であって、前記フィールドの情報であるフィールド定義と、前記フィールドに対応づけられる構成要素に対する設定に関する情報である設定定義とを含むことができるコンポネント定義を用いたコンポネントの指定と、前記コンポネントが有するフィールドに対する構成要素の割り当てに関する割当定義とを少なくとも含むシステム定義を受け付けると、前記システム定義および前記コンポネント定義に基づいて、指定されたコンポネントのフィールドに構成要素を対応づけるとともに、前記フィールドに対して定義された設定内容を、前記フィールドに対応づけられた構成要素に反映することにより、対象システムを構成する構成要素に対する設定の付与を行う処理
    を実行させるためのシステム構築支援プログラムが記録された記憶媒体。

Images