JP7428006B2 - システム構成導出装置、方法およびプログラム - Google Patents

Description

本発明は、システム構成導出装置、システム構成導出方法およびシステム構成導出プログラムに関する。

サービス運用等の目的でＩＣＴ（Information and Communication Technology）システム（以下、単にシステムと記す。）を構築する際に必要な作業には、システム構成の設計作業と、配備手順の設計作業とが含まれる。

所望のシステムに求められる要件を、システム要件と称する。また、システムの構成部品およびその接続関係をまとめて、システム構成と称する。

システム構成の設計作業では、システム要件を満たすために必要なシステム構成を不足なく構築し、さらにシステム全体が正常に動作するために必要な設定項目を全て正しく設定しなければならない。これは、場合によっては、非常に工数のかかる作業である。

システム要件からシステム構成へと具体化していく過程を自動化する技術が自動設計技術である。一般的な自動設計技術としては、システムの特定のドメインのみに設計対象を絞り、ある種の最適化問題等を解くことで自動設計を行うものが多い。なお、システムの特定のドメインの例として、例えば、ネットワーク経路や計算リソースの配置等が挙げられる。

また、システム要件の汎用的な記述に対応するための技術の研究も進んでいる。非特許文献１には、汎用的なモデルを用いて記述したシステム要件を元に、システム構成を自動で導出する技術が記載されている。非特許文献１に記載の技術によれば、必要なモデルを用意することで、汎用的かつ多面的なシステム要件を入力とした自動設計が可能となる。

非特許文献１に記載された汎用的なモデルによって記述可能なシステム要件は、主に機能や機器等の部品がノードとして表現され、さらにそのノード間の関連性がエッジ（向き付けられた辺）によって表現されたグラフ表現で指定される。例えば、「２台のサーバの間でＴＣＰ（Transmission Control Protocol ）による通信が可能」というシステム要件は、それぞれのサーバに相当するノードが「ＴＣＰ通信可能」を表現するエッジによって接続されたグラフとなる。非特許文献１に記載の技術は、例えば、このグラフが表現するＴＣＰ通信を具体化する方法を自動で導出する。

非特許文献１に記載された技術は、システムの構成部品のモデルを整備し、整備されたシステムの構成部品のモデルのセットを必要に応じて拡張することができる。非特許文献１に記載された技術は、整備されたシステムの構成部品のモデルのセットから必要なシステムの構成部品を選択し、その構成部品を組み合わせることで得たシステム要件を一般的な属性付きグラフの表現に落とし込む。そして、その属性付きグラフに、予め定義された規則を適用することによって、その属性付きグラフを書き換える。

また、特許文献１には、未確定な部分を含むベースの構成に適用可能な書き換え規則を選択し、選択された規則を適用する試行を繰り返すことによって、全ての未確定な部分が確定された構成を設計結果として出力するシステム構成導出装置が記載されている。また、特許文献１には、システム構成導出装置が、入力された抽象構成を具体的なシステム構成情報に変換する機能を有することも記載されている。

また、特許文献２には、非機能要件に影響する様々な要因を考慮しつつ、指定された非機能要件を満たすシステム構成の候補を自動的かつ効率的に導出できる設計支援装置が記載されている。

国際公開第２０１９／２１６０８２号 国際公開第２０１５／１６２８８９号

黒田貴之、外３名、「ネットワーク運用の自動化に向けた探索型ネットワーク設計導出方式の提案」、信学技報、一般社団法人電子情報通信学会、vol.118, no.118, ICM2018-11, pp.1-6、２０１８年７月

未確定な部分が存在するシステム構成を示す情報を抽象構成と称する。抽象構成の例としては、アプリケーションが示されていても、そのアプリケーションがデプロイされる装置が示されていないシステム構成等が挙げられる。

また、システム要件のうち、数値的な要件を定量的要件と記す。定量的要件の例として、例えば、「要求されるマシンスペック」、「必要なネットワーク帯域幅」、「要求されるメモリリソース量」、「予算の上限額」等が挙げられる。これらは例示であり、定量的要件は、これらの例に限定されない。

前述のように、特許文献１には、入力された抽象構成を具体的なシステム構成情報に変換する機能を有するシステム構成導出装置が記載されている。

しかし、特許文献１には、抽象構成を具体化すると同時に、その具体化した結果が定量的要件も満たすようにする技術については記載されていない。

また、非特許文献１に記載の技術におけるグラフは、事前に定義された型情報によってラベル付けされたグラフに過ぎないため、定量的要件を表現するのには向いていない。コンピュータが整数や小数をビット表現で表現する方法と同様の表現方法をグラフに適用することも不可能ではないが、設定値として数千、数万の数値を表現するケースを考えると現実的ではない。

さらに、定量的要件は、全て確定した状態で与えられるとは限らない。一部の数値が未確定な状態で、定量的要件が与えられる場合もある。例えば、フレームサイズの数値は確定しているが、フレームレートの数値が未確定な状態の定量的要件が与えられる場合もあり得る。このような場合においても、抽象構成を具体化すると同時に、その具体化した結果が定量的要件を満たしていることが望まれる。

そこで、本発明は、抽象構成と、一部の数値が未確定である定量的要件とが与えられた場合に、その定量的要件を含む、所望のシステムの動作に必要な条件等を表した定量的要件を満たし、かつ、その抽象構成を具体化した具体的なシステム構成を出力することができるシステム構成導出装置、システム構成導出方法およびシステム構成導出プログラムを提供することを目的とする。

本発明の実施形態に係るシステム構成導出装置は、未確定な部分が存在するシステム構成を示す情報である抽象構成と、システムに要求される数値的な要件である定量的要件であって、一部の数値が未確定である定量的要件とを入力として取得し、未確定な部分が存在しないシステム構成を示す情報である具体構成であって、定量的要件を満たした具体構成を出力する構成情報具体化手段を含み、構成情報具体化手段が、入力となる抽象構成を、描画されたグラフとして取得するとともに、入力となる定量的要件をテキストデータとして取得し、具体構成をグラフとして出力することを特徴とする。

本発明の実施形態に係るシステム構成導出方法は、未確定な部分が存在するシステム構成を示す情報である抽象構成と、システムに要求される数値的な要件である定量的要件であって、一部の数値が未確定である定量的要件とを入力として取得し、未確定な部分が存在しないシステム構成を示す情報である具体構成であって、定量的要件を満たした具体構成を出力し、入力となる抽象構成を、描画されたグラフとして取得するとともに、入力となる定量的要件をテキストデータとして取得し、具体構成をグラフとして出力する。

本発明の実施形態に係るシステム構成導出プログラムは、コンピュータに、未確定な部分が存在するシステム構成を示す情報である抽象構成と、システムに要求される数値的な要件である定量的要件であって、一部の数値が未確定である定量的要件とを入力として取得し、未確定な部分が存在しないシステム構成を示す情報である具体構成であって、定量的要件を満たした具体構成を出力する構成情報具体化処理を実行させ、構成情報具体化処理で、入力となる抽象構成を、描画されたグラフとして取得させるとともに、入力となる定量的要件をテキストデータとして取得させ、具体構成をグラフとして出力させる。

本発明によれば、抽象構成と、一部の数値が未確定である定量的要件とが与えられた場合に、その定量的要件を含む、所望のシステムの動作に必要な条件等を表した定量的要件を満たし、かつ、その抽象構成を具体化した具体的なシステム構成を出力することができる。

システム要件の例を示す模式図である。 システム要件を満たす具体的なシステム構成の例を示す模式図である。 定量的要件を満たさないシステム構成の例を示す模式図である。 定量的要件を満たさないシステム構成の例を示す模式図である。 本発明の第１の実施形態のシステム構成導出装置の構成例を示すブロック図である。 抽象構成の例を示す模式図である。 定量的要件の例を示す説明図である。 具体化規則の例を示す模式図である。 第１の実施形態における構成情報具体化部の処理経過の例を示すフローチャートである。 構成情報具体化部が生成する探索木の例を示す模式図である。 図１０に示す探索木の生成に用いられた具体化規則を示す模式図である。 図１０に示す探索木の生成に用いられた具体化規則を示す模式図である。 図１０に示す探索木の生成に用いられた具体化規則を示す模式図である。 定量的要件検証部の処理経過の例を示すフローチャートである。 集合型変数の値の変化の具体例を示す模式図である。 本発明の第２の実施形態のシステム構成導出装置の構成例を示すブロック図である。 定量的要件判定部の処理経過の例を示すフローチャートである。 各実施形態における抽象構成および定量的要件の入力画面の例を示す説明図である。 各実施形態のシステム構成導出装置における具体構成の出力画面の例を示す説明図である。 本発明の第３の実施形態のシステム構成導出装置の例を示すブロック図である。 本発明の各実施形態のシステム構成導出装置に係るコンピュータの構成例を示す概略ブロック図である。

本発明の実施形態について説明する前に、まず、抽象構成と、数値が全て確定している定量的要件とが与えられた場合における、具体的なシステム構成の例を述べる。なお、抽象構成と定量的要件とを合わせたものがシステム要件であるということができる。

図１は、システム要件の例を示す模式図である。図１に示すシステム要件は、抽象構成５１と、定量的要件５２とを含んでいる。抽象構成５１では、例えば、映像分析アプリケーション（符号ＶＡで表す。）をデプロイする物理マシンが未確定であり、そのような物理マシンは、抽象構成５１内に示されていない。また、図１では、映像分析アプリケーションＶＡをデプロイする物理マシンの３つの候補（ServerX, ServerY, ServerZ）も図示している。

図１に示すシステム要件を入力する設計者は、店舗内の監視カメラの映像を分析し異常を検出する映像分析アプリケーションＶＡを新規に導入しようとしている。映像分析アプリケーションＶＡには、パラメータとして、「フレームサイズ（ＭＢ）」、「フレームレート（ｆｐｓ）」を設定することができる。フレームサイズの値は１ＭＢとして、フレームレートの値は５ｆｐｓとして、それぞれ、定量的要件５２で定められている。また、映像分析アプリケーションＶＡの動作に必要なメモリの量は、「フレームサイズ×フレームレート×３０００（ＭＢ）」で見積もられ、このことも、定量的要件５２で定められている。また、定量的要件５２では、予算上限額も定められている。本例では、定量的要件５２において、未確定な数値は存在していないものとする。

図２は、映像分析アプリケーションＶＡを物理マシンServerYにデプロイした構成を示す模式図である。図２に示す構成は、図１に示すシステム要件を満たす具体的なシステム構成である。図１に示すように、物理マシンServerYでは、１６ＧＢのメモリを使用可能であり、かつ、費用合計額は１７００００円である。従って、図２に示すシステム構成は、指定された定量的要件５２、および、映像分析アプリケーションＶＡの持つリソースに関する定量的な制約を全て満たしている。

図３および図４は、定量的要件を満たさないシステム構成の例を示す模式図である。図３は、映像分析アプリケーションＶＡを物理マシンServerXにデプロイした構成を示す。物理マシンServerXで使用可能なメモリは８ＧＢしかなく、図３に示す構成では、映像分析アプリケーションＶＡは正常に動作しない。また、図４は、映像分析アプリケーションＶＡを物理マシンServerZにデプロイした構成を示す。物理マシンServerZは、３２ＧＢのメモリを使用できるので、映像分析アプリケーションＶＡは正常に動作する。しかし、費用合計額が２４００００円であり、定量的要件５２で指定された費用上限額“２０００００円”を満たさない。

上記のような定量的要件を、非特許文献１に記載の手法と同様に、規則によるグラフ書き換えで実現しようとする場合、属性に対する条件付けを用いる方法が考えられる。グラフのノードおよびエッジ（なお、ノードおよびエッジをまとめて「エンティティ」と称する。）には数値を属性として付記できる。上記の方法の考え方は、このことを利用して定量的要件を指定し、また、規則がこれを参照することで定量的要件を充足する構成を導出するという考え方である。

例えば、図１に記載のシステム要件では、映像分析アプリケーションＶＡに関して指定された「フレームサイズ １ＭＢ」、「フレームレート ５ｆｐｓ」という要件を元に、必要メモリ量を１（ＭＢ）×５（ｆｐｓ）×３０００＝１５０００（ＭＢ）＝１５（ＧＢ）と見積もることができる。

そして、映像分析アプリケーションＶＡを物理マシンの３つの候補（ServerX, ServerY, ServerZ）にデプロイする規則を以下のように規定しているとする。

ａ）「映像分析アプリケーションＶＡの必要メモリが８ＧＢ以下であり、使用可能な予算が １２００００円以上ならば、映像分析アプリケーションＶＡを物理マシンServerX上にデプロイする。」

ｂ）「映像分析アプリケーションＶＡの必要メモリが１６ＧＢ以下であり、使用可能な予算が １７００００円以上ならば、映像分析アプリケーションＶＡを物理マシンServerY上にデプロイする。」

ｃ）「映像分析アプリケーションＶＡの必要メモリが３２ＧＢ以下であり、使用可能な予算が ２４００００円以上ならば、映像分析アプリケーションＶＡを物理マシンServerZ上にデプロイする。」

上記のように規則を規定しておけば、図１に示すシステム要件を具体化することができる。

しかし、上記のような具体化の方法では、定量的要件において一部の数値が未確定である場合には、具体化が進まないという問題がある。例えば、図１に示す定量的要件５２において、「フレームサイズ １ＭＢ」および「フレームレート ５ｆｐｓ」という数値が指定されていなかった場合には、映像分析アプリケーションＶＡの必要メモリ量を見積ることができない。その結果、映像分析アプリケーションＶＡを物理マシンの３つの候補のうち、どの候補にデプロイすればよいのかを決定できない。このような場合に、未確定の数値に対して適当な数値を設定することによって、具体化を進めることは可能である。しかし、フレームサイズおよびフレームレートの値の組み合わせとして可能な組み合わせは無数に存在するため、その組み合わせ毎に網羅的に具体化を進めることは現実的でない。

このような問題によって、一部の数値が未確定である定量的要件が与えられた場合に、抽象構成を具体化することは、一般的な技術では困難である。

しかし、定量的要件を満たすようにすることは、現実のシステム設計のほとんどの場合に要請される。

本発明の各実施形態のシステム構成導出装置は、抽象構成と、一部の数値が未確定である定量的要件とが与えられた場合に、その定量的要件を含む、所望のシステムの動作に必要な条件等を表した定量的要件を満たし、かつ、その抽象構成を具体化した具体的なシステム構成を出力できるものである。以下、図面を参照して本発明の実施形態を説明する。

実施形態１．
図５は、本発明の第１の実施形態のシステム構成導出装置の構成例を示すブロック図である。第１の実施形態のシステム構成導出装置１００は、構成情報具体化部１０１と、具体化規則記憶部１０２と、定量的要件検証部１０３とを備える。

構成情報具体化部１０１は、入力として抽象構成と、一部の数値が未確定である定量的要件とを受け取り、抽象構成および定量的要件に具体化規則を順次適用することで具体構成を導出し、その具体構成を出力する。具体構成とは、未確定な部分が存在しないシステム構成を示す情報である。また、構成情報具体化部１０１が導出する具体構成は、定量的要件を満たしている。

また、具体化規則とは、抽象構成を具体化するとともに定量的要件を更新する方法が規定された規則である。

具体化規則記憶部１０２は、上記の具体化規則を予め記憶する記憶装置である。

後述するように、定量的要件は変数を用いて表される。定量的要件検証部１０３は、構成情報具体化部１０１から定量的要件を受け取ると、その定量的要件を充足する変数への値の割り当てが存在するか否かを検証し、その検証結果を返す。

構成情報具体化部１０１および定量的要件検証部１０３は、例えば、システム構成導出プログラムに従って動作するコンピュータのＣＰＵ（Central Processing Unit ）によって実現される。例えば、ＣＰＵが、コンピュータのプログラム記憶装置等のプログラム記録媒体からシステム構成導出プログラムを読み込み、そのシステム構成導出プログラムに従って、構成情報具体化部１０１および定量的要件検証部１０３として動作すればよい。具体化規則記憶部１０２は、例えば、コンピュータが備える記憶装置によって実現される。

以下、本実施形態における抽象構成と、そのデータ構造について説明する。抽象構成は、構成や設定に関し未確定な部分が存在するシステム構成を示す情報である。抽象構成は、システムの詳細に具体的に言及することなく、「システムがどのような要件を満たし、どのような機能を持つべきか」を表す情報を規定しているということができる。

抽象構成は、システムの機能や論理的・物理的な構成部品に相当する「ノード」と、２つのノード間に張ることでそれら２つのノード間の関係性を表現する「エッジ」とを備えるグラフを基本構成とする。エッジは向きを持ち、ノードＡからノードＢに向かうエッジに関して、ノードＡを「接続元」と呼び、ノードＢを「接続先」と呼ぶ。また、ノードおよびエッジに区別なく言及する場合、これらをまとめて「エンティティ」と称する。

エンティティは、システム全体で一意に当該エンティティを識別するための「識別子」と、当該エンティティがどのような概念に相当するかを表現する「型情報」を持つ。またこれらに加え、ノードは、「要請する部品」を示す情報を持っていてもよい。ノードは、「要請する部品」を示す情報を複数持っていてもよく、あるいは、全く持っていなくてもよい。

図６は、抽象構成の例を示す模式図である。図６に示す例では、ノード５００，５０１，５０２は、アイコンを含む角丸四角形で表されている。エッジ５０３，５０４は、ノード同士を結ぶ矢印で表されている。各エンティティには、吹き出しが付属している。吹き出しの中に、エンティティの識別子およびエンティティの型情報が記述される。なお、図面を簡単にするために、エンティティの吹き出しの図示を省略する場合がある。

ノード５００は、ネットワークカメラを表し、ノード５０１は、Ｌ２（Layer 2 ）スイッチを表している。このノード５００，５０１は、両方とも、未確定な部分を含まない具体的なシステムの構成部品に相当する。

ノード５０１には、「ＬＡＮ（Local Area Network）」と記述された５角形のラベルが付されている。このラベルは、ノードが要請する部品を示す情報であり、本例では、ノード５０１がＬＡＮを要請していることを表している。具体的には、このラベルは、「 Ｌ２スイッチの機能を用いるには物理ＬＡＮケーブルによって通信先と接続される必要がある」という要請を表現している。エッジ５０４は、この要請に応えるエッジの１つであり、エッジ５０４によって、ノード５０１の「ＬＡＮ」要請は満たされている。

ノード５０２は、映像分析アプリケーションを表している。ノード５０２には、「Machine 」と記述されたラベルが付されている。このラベルは、「映像分析アプリケーションの動作には物理マシンが必要である」という要請を表現している。この要請を満たすには、WIRE:Machine型を持つエッジがノード５０２から、MACHINE 型（または、MACHINE を詳細化した型）を持つノードに張られている必要がある。図６に示す例では、ノード５０２の「Machine 」要請は満たされていない。この点で、未確定な部分が存在している。

エッジ５０３は、接続元のノード５００が接続先のノード５０２に対して、取得した映像データを送信することを意味している。エッジ５０３は、エッジ５０４とは異なり、実現方法が未確定な抽象的エッジである。従って、エッジ５０３も、未確定な部分に該当する。

以上の説明から分かるように、図６に例示する抽象構成は、「ネットワークカメラで撮影した映像を分析するシステム」を、その一部が未確定なまま表現した情報である。

以下、本実施形態における定量的要件について説明する。定量的要件は、抽象構成に紐付けられて、構成情報具体化部１０１に入力される。よって、定量的要件は、常に抽象構成に紐付けられている。

また、定量的要件は、「使用変数リスト」と、「制約式リスト」とを含む。

定量的要件の使用変数リストとは、後述する制約式リストで使用される全ての変数の変数名を列挙したリストである。使用変数リストに含まれる個々の変数名は、文字列である。この変数名となる文字列は、定量的要件に紐付けられている抽象構成に含まれるエンティティの識別子や型情報を含み、エンティティの性能やコストを表すことが多い。

定量的要件の制約式リストとは、数式で表現された変数間制約のリストである。このリストに含まれる各数式で用いられる変数は、使用変数リストに列挙される。制約式リストに含まれるそれぞれの制約は、変数の値によって真偽の値が一意に定まるものでなければならない。

図７は、定量的要件の例を示す説明図である。図７に例示する定量的要件は、図２に示す構成に課される定量的要件である。

図７に示す使用変数リストは、以下の７つの変数を含んでいる。

「System.CAPEX」
「VA.FrameSize」
「VA.FrameRate」
「VA.Memory 」
「ServerY.MemoryLimit」
「ServerY.Memory」
「ServerY.Price」

「System.CAPEX」は、「消費された予算の集合」を意味している。

「VA.FrameSize」は、「映像分析アプリケーションＶＡのフレームサイズの値」を意味している。

「VA.FrameRate」は、「映像分析アプリケーションＶＡのフレームレートの値」を意味している。

「VA.Memory 」は、「映像分析アプリケーションＶＡの消費メモリの値」を意味している。

「ServerY.MemoryLimit」は、「物理マシンServerYのメモリ上限値」を意味している。

「ServerY.Memory」は、「消費されている物理マシンServerYのメモリの集合」を意味している。

「ServerY.Price」は、「物理マシンServerYの価格の値」を意味している。

上記のように、使用変数リストに含まれる変数には、「数値」を意味する変数の他に、「集合」を意味する変数が存在する。すなわち、変数には、「数値を値に持つ数値型変数」および「数値型変数の集合を値として持つ集合型変数」の２種類が存在する。

図７に示す制約式リストは、以下の８個の制約式を含んでいる。

「sum(System.CAPEX) ≦ 200000」
「VA.FrameSize ＝ 1」
「VA.Memory ＝ VA.FrameSize × VA.FrameRate× 3000」
「ServerY.MemoryLimit ＝ 16000」
「ServerY.Price ＝ 170000」
「VA.Memory ∈ ServerY.Memory」
「sum(ServerY.Memory) ≦ ServerY.MemoryLimit」
「ServerY.Price∈ System.CAPEX」

ここで、等号（＝）、不等号（≦）、所属（∈）等は、一般的な意味の２項関係と解釈される。また“sum ”は、集合に属する変数の値の総和を表す。

「sum(System.CAPEX) ≦ 200000」は、「『消費された予算の集合』に属する変数の値の総和は 200000 以下である」ということを表している。

「VA.FrameSize ＝ 1」は、「『映像分析アプリケーションＶＡのフレームサイズの値』は１である」ということを表している。

「VA.Memory ＝ VA.FrameSize × VA.FrameRate× 3000」は、「『映像分析アプリケーションＶＡの消費メモリの値』は、『映像分析アプリケーションＶＡのフレームサイズの値』と『映像分析アプリケーションＶＡのフレームレートの値』との積にさらに 3000を乗じた値である」ということを表している。

「ServerY.MemoryLimit ＝ 16000」は、「『物理マシンServerYのメモリ上限値』は 16000 である」ということを表している。

「ServerY.Price ＝ 170000」は、「『物理マシンServerYの価格の値』は 170000 である」ということを表している。

「VA.Memory ∈ ServerY.Memory」は、「『消費されている物理マシンServerYのメモリの集合』は、変数VA.Memoryを含む」ということを表している。

「sum(ServerY.Memory) ≦ ServerY.MemoryLimit」は、「『消費されている物理マシンServerYのメモリの集合』に属する変数の値の総和は『物理マシンServerYのメモリ上限値』以下である」ということを表している。

「ServerY.Price∈ System.CAPEX」は、「『消費された予算の集合』は、変数ServerY.Priceを含む」ということを表している。

図７に例示する定量的要件では、例えば、変数「VA.FrameRate」の値や、変数「VA.Memory 」の値が未確定となっている。すなわち、図７に例示する定量的要件では、一部の数値が未確定である。

制約式リストには、数値に関する制約式の他に、集合が含む要素に関する制約式も含まれる。集合が含む要素に関する制約式を、集合型制約と称する。また、数値に関する制約式を数値型制約と称する。

集合型制約には、「ｅ∈Ｓ」という形式で記載され、「Ｓは変数ｅを含む」ということを表す制約と、「Ｓ１⊆Ｓ２」という形式で記載され、「Ｓ１に含まれる要素が全てＳ２に含まれる」ということを表す制約とが存在する。前者を「所属制約」と呼び、後者を「包含制約」と呼ぶ。

以上が、具体例を用いた定量的要件についての説明である。

定量的要件に含まれる全ての変数に値を割り当てたとき、制約式リストに含まれる各制約式それぞれの真偽が確定する。定量的要件の使用変数リストに含まれる変数に対する値の割り当て（符号Ｍで表す。）が、定量的要件の制約式リストに含まれる全ての制約式を満たすことを、「値の割り当てＭは定量的要件を充足する」という。定量的要件を充足するような値の割り当てが１つでも存在する場合、定量的要件は「充足可能」であるという。定量的要件を充足するような値の割り当てが１つも存在しない場合、定量的要件は「充足不能」であるという。ただし、集合型制約に関してはその真偽を決定する際に、以下に説明するような注意が必要である。

前述のように、定量的要件で使用される変数には、「数値型変数」と「集合型変数」の２種類が存在する。そして、集合型変数に関しては、所属制約（∈）と包含制約（⊆）の２種類の制約式が存在する。本発明の各実施形態では、集合型制約を、閉世界仮説（Closed World Assumption, ＣＷＡ）に基づいて解釈する。

「制約の閉世界仮説に基づく解釈」について、具体例を用いて説明する。集合型変数に関する制約ＳＣがあるとする。そして、制約ＳＣ＝「x ∈ A, y ∈ B, A ⊆ B」であるとする。この制約ＳＣは、「A は、x を要素として含む。」、「B は、y を要素として含む。」、および、「B は、A の全ての要素を、要素として含む。」という意味である。例えば、「A = {x}, B = {x,y}」という値の割り当ては、制約ＳＣ内の全ての制約式を真とする割り当てである。一般的には、上記の割り当てに限らず、「A = {x,y}, B = {x,y}」のような値の割り当ても、制約ＳＣ内の全ての制約式を真とする。

しかし、割り当て「A = {x,y}, B = {x,y}」は、「A は、y を要素として含む。」という所属関係を含んでいる。そして、この所属関係は、制約ＳＣが示している「A は、x を要素として含む。」、「B は、y を要素として含む。」、および、「B は、A の全ての要素を、要素として含む。」という事実から演繹できない。制約ＳＣを閉世界仮説に基づいて解釈するとは、上記のような、「制約ＳＣから演繹できない所属関係」は存在しないと解釈することを意味する。上記の例では、制約ＳＣは所属関係「y ∈ A」を演繹できないという事実から、明示的に「y ∈ A」の否定を制約ＳＣに加えた制約が、閉世界仮説に基づいて解釈された制約ＳＣとなる。すなわち、制約ＳＣを閉世界仮説に基づいて解釈すれば、制約ＳＣを満たす値の割り当ては、「A = {x}, B = {x,y}」のみとなる。

変数への値の割り当てＭ、および、定量的要件の充足性の具体例を以下に示す。

図７に示す定量的要件に関して、以下に示す値の割り当てＭを定めたとする。

System.CAPEX = { ServerY.Price }
VA.FrameSize = 1
VA.FrameRate = 5
VA.Memory = 15000
ServerY.MemoryLimit = 16000
ServerY.Memory = { VA.Memory }
ServerY.Price = 170000

上記の値の割り当てＭは、図７に示す制約式リストに含まれる全ての制約式を満たす。従って、上記の値の割り当てＭは、図７に示す定量的要件を充足する。従って、図７に示す定量的要件は、充足可能な定量的要件である。

ここで、上記の値の割り当てＭにおいて、変数System.CAPEXの値が、{ 170000 }ではなく、{ ServerY.Price }であることに注意すべきである。すなわち、集合型変数の値は、あくまで、変数の集合であり、割り当てられた変数の値ではない。例えば、数値型変数x,y を含む集合を値として持つ変数S があるとする。このとき、x=10, y=10であったとしても、S の値は{ x,y } であり、S の値が{ 10 }という１つの要素にまとめられることはない。

なお、上記の値の割り当てＭは、図７に示す定量的要件を充足する値の割り当ての１つに過ぎない。例えば、以下に示す値の割り当ても、図７に示す定量的要件を充足する。

System.CAPEX = { ServerY.Price }
VA.FrameSize = 1
VA.FrameRate = 4
VA.Memory = 12000
ServerY.MemoryLimit = 16000
ServerY.Memory = { VA.Memory }
ServerY.Price = 170000

また、以下に示す値の割り当ては、図７に示す定量的要件を充足しない値の割り当ての例である。

System.CAPEX = { ServerY.Price }
VA.FrameSize = 1
VA.FrameRate = 6
VA.Memory = 18000
ServerY.MemoryLimit = 16000
ServerY.Memory = { VA.Memory }
ServerY.Price = 170000

また、図７に示す制約式リストの１番目の制約式「sum(System.CAPEX) ≦ 200000」を、「sum(System.CAPEX) ≦ 100000」に置き換えた定量的要件（αとする。）を考える。この定量的要件αを充足するような値の割り当ては存在しない。従って、定量的要件αは、充足不能な定量的要件である。

以上が、変数への値の割り当てＭ、および、定量的要件の充足性の具体例の説明である。

以下に、各実施形態における具体化規則について説明する。図８は、具体化規則の例を示す模式図である。具体化規則７００は、具体化の対象を示す情報（以下、（具体化規則の）左辺と記す。）と、具体化後の構成を示す情報（以下、（具体化規則の）右辺と記す。）と、具体化によって追加される定量的要件を生成するためのテンプレート（以下、定量的要件テンプレートと記す。）７０１とを含む。

定量的要件テンプレートの形式は、基本的には定量的要件と同様であり、使用変数リストと制約式リストとを含む。ただし、定量的要件テンプレートでは、使用変数リストに列挙される変数名や、制約式リストに含まれる制約式に出現する変数において、左辺または右辺に含まれる識別子を参照する部分が含まれる。左辺または右辺に含まれる識別子（エンティティの識別子）を参照することを、仮変数参照と記す。ただし、左辺または右辺に含まれる識別子を参照しない変数が存在していてもよい。本実施形態では、定量的要件テンプレート内で記述される変数名において、左辺または右辺に含まれる識別子を参照する部分（換言すれば、仮変数参照に該当する部分）を、「{識別子}」という表現で記述するものとする。

例えば、左辺または右辺に、「Node1 」というエンティティの識別子が存在しているとする。変数名がその識別子を参照しているならば、その変数名は、{ Node1 } という表現を含む。例えば、{ Node1 }.MemoryLimit等の変数名が定量的要件テンプレート内で用いられる。

図８に示す例では、左辺や右辺に含まれるエンティティの識別子“app ”や識別子“server”を参照する部分を含む変数名が定量的要件テンプレート内で記述されている。

次に、抽象構成が具体化規則によってどのように具体化されるのかについて説明する。

具体化規則Ｒの左辺に相当する構造が抽象構成Ｄに含まれるとき、具体化規則Ｒは抽象構成Ｄに適用可能であるという。ここで「相当する構造を持つ」とは、一対一で対応するノードが存在し、かつ一対一で対応するエッジが存在することである。ただし、「エッジＥ１がエッジＥ２に対応する」という表現は、単に型情報に関するエッジ単体での対応だけを意味するものではなく、両端のノードがそれぞれ対応するノードであるという意味をも含む。例えば、エッジＥ１がノードＮａからノードＮｂに対して張られるエッジであり、かつ、エッジＥ２がノードＮｃからノードＮｄに対して張られるエッジであるとする。この場合、エッジＥ１とエッジＥ２とが対応していると言えるためには、ノードＮａとノードＮｃとが対応していて、かつ、ノードＮｂとノードＮｄとが対応していなければならない。

「具体化規則Ｒの左辺に相当する、抽象構成Ｄの部分構造」のことを、抽象構成Ｄの具体化規則Ｒによる具体化対象と称する。

抽象構成Ｄに具体化規則Ｒを適用可能であるとき、抽象構成Ｄは、具体化規則Ｒの左辺と一対一に対応する部分構造（すなわち、具体化対象）を持つ。具体化規則Ｒによる抽象構成Ｄの書き換えとは、具体化対象を具体化規則Ｒの右辺で表現される構造に置き換えることである。この時、左辺と右辺で識別子が共通するエンティティは、左辺のエンティティと同じエンティティに置き換えられる。左辺とは共通でないエンティティが右辺にあるならば、そのエンティティに相当するエンティティが新規に作られ、具体化対象に付加される。また、そのエンティティの識別子として、他の識別子と重複しない識別子が付加される。

抽象構成の書き換えの後、定量的要件テンプレートに含まれる全ての仮変数参照を、置き換え後の構成中の対応するエンティティの識別子に置き換える。例えば、具体化規則の左辺の識別子“Node1 ”を有するノードが、置き換え後の構成中の“Server1 ”というノードに対応しているとする。“Server1 ”は、識別子である。この場合、定量的要件テンプレートに記述されている「{Node1}.MemoryLimit 」等の変数名は、「Server1.MemoryLimit 」等に置き換えられる。右辺のみに存在する識別子を参照する仮変数参照に該当する部分は、具体化対象を置き換える際に新たに追加された対応するエンティティの識別子に置き換えられる。

定量的要件テンプレートに含まれる全ての仮変数参照を、置き換え後の構成中の対応するエンティティの識別子に置き換えたものは、定量的要件に追加される新たな定量的要件となる。この新たな定量的要件が追加されることで、定量的要件は更新される。すなわち、「{識別子}」という表現で記述された仮変数参照を識別子に置き換えた後の各変数名が、使用変数リストに追加され、「{識別子}」という表現で記述された仮変数参照を識別子に置き換えた後の各制約式が制約式リストに追加されることで、定量的要件が更新される。なお、仮変数参照を含まない変数名は、そのまま使用変数リストに追加されればよく、仮変数参照を含まない制約式は、そのまま制約式リストに追加されればよい。

図８を例にして、具体化規則について詳細に説明する。図８に示す具体化規則７００の左辺および右辺は、「Machine 」要請が満たされていない「App 」型のノードを含むグラフを、その「App 」型のノードに対して「ServerX 」型のノードを接続することでその要請が満たされるグラフに変換することを表している。

また、定量的要件テンプレート７０１は、ServerX にデプロイするアプリケーションの使用メモリの上限に関する制約と、ServerX を配備するのに必要な予算に関する制約を示している。

ここで、共通の識別子“app ”を持つ左辺のノード７０２および右辺のノード７０３は、共通のノードを表していることに注意すべきである。

具体化規則７００による抽象構成の書き換えは、抽象構成に既に含まれている「App 」型のノードに対し、新規に生成した「ServerX 」型のノードを、「WIRE:Machine」型のエッジで接続するという操作になる。

図８に例示する具体化規則７００に含まれる定量的要件テンプレート内の使用変数リストは、以下の５つの変数を含んでいる。

「{ app }.Memory」
「{ server }.Memory」
「{ server }.MemoryLimit」
「{ server }.Price」
「System.CAPEX」

また、具体化規則７００に含まれる定量的要件テンプレート内の制約式リストは、以下の５つの制約式を含んでいる。

「{ app }.Memory ∈ { server }.Memory」
「sum({ server }.Memory) ≦ { server }.MemoryLimit」
「{ server }.Price ∈ System.CAPEX」
「{ server }.MemoryLimit ＝ 8」
「{ server }.Price ＝ 120000」

変数「{ app }.Memory」は、数値型変数であり、この例では、識別子app に対応するアプリケーションを表すノードの使用メモリ量を値とする。

変数「{ server }.Memory」は集合型変数であり、この例では、識別子serverに対応する物理マシンを表すノードのメモリを消費する全てのアプリケーションの「使用メモリ量」の変数の集合を値とする。

変数「{ server }.MemoryLimit」は、数値型変数であり、この例では、識別子serverに対応する物理マシンを表すノードの使用可能メモリ量の上限を値とする。

変数「{ server }.Price」は、数値型変数であり、この例では、識別子serverに対応する物理マシンを表すノードの配備に必要な設置費用を値とする。

変数「System.CAPEX」は、集合型変数であり、この例では、システムの構成にあたり新規に配備が必要な設備の「設置費用」に対応する変数の集合を値とする。

従って、「{ app }.Memory ∈ { server }.Memory」は、「識別子app に対応するアプリケーションが識別子serverに対応する物理マシンのメモリを消費する」ということを表している。

「sum({ server }.Memory) ≦ { server }.MemoryLimit」は、「識別子serverに対応する物理マシンのメモリ消費量の総和は、その物理マシンの使用可能メモリ量の上限以下である」ということを表している。

「{ server }.Price ∈ System.CAPEX」は、「識別子serverに対応する物理マシンを新規に配備する必要があり、設置費用を必要とする」ということを表している。

「{ server }.MemoryLimit ＝ 8」は、「識別子serverに対応する物理マシンの使用可能なメモリの上限は８（ＧＢ）である」ということを表している。

「{ server }.Price ＝ 120000」は、「識別子serverに対応する物理マシンの配備に必要な設置費用は１２００００（円）である」ということを表している。

定量的要件テンプレート７０１を具体化する（すなわち、抽象構成から置き換えられた構成中の識別子で仮変数参照を置き換える）ことで、追加すべき定量的要件が得られる。この定量的要件は、識別子serverに対応する物理マシンを新たに配備し、その物理マシンに、識別子app に対応するアプリケーションをデプロイする場合に、現在、具体化している抽象構成において、「使用メモリ」、「予算上限」の観点で問題が起きないようにするための要件である。

定量的要件テンプレート７０１は、左辺から右辺へのグラフ構造の変換を抽象構成に施したときに、追加で必要となる定量的要件を導出するために用いられる。

次に、各実施形態で導出される具体構成について説明する。

具体構成とは、未確定な部分が存在しないシステム構成を示す情報である。具体構成は、完全に具体化された抽象構成であるということもできる。ここで、「完全に具体化されている」とは、以下の（１），（２），（３）の３つの条件をすべて満たしていることを指す。

（１）抽象構成に含まれる全てのノードの型が「具体的な」型であること。

なお、ノードの型が具体的であるか否かは、型の種類に応じて、事前に定義されているものとする。

（２）抽象構成に含まれる全てのエッジの型が「具体的な」型であること。

なお、エッジの型が具体的であるか否かは、型の種類に応じて、事前に定義されているものとする。

（３）抽象構成に含まれている全てのノードに関して、ノードが要請する部品が適切なエッジで接続されていること。

以上の３つの条件を全て満たした抽象構成は、属性値以外に未確定な要素を含まない。従って、具体構成は、その具体構成に付与された属性値制約に従って適当な設定値を付与することによって、実際にＩＣＴシステムとして動作する構成を表現している。

次に、第１の実施形態における処理経過について説明する。図９は、第１の実施形態における構成情報具体化部１０１の処理経過の例を示すフローチャートである。

最初に、構成情報具体化部１０１は、抽象構成および定量的要件の入力を受け付ける（ステップＳ８００）。入力される抽象構成および定量的要件は、紐付けられている。

以下、抽象構成を符号Ｄで表し、定量的要件を符号ＱＣで表す。特に、最初に入力される抽象構成を符号Ｄ０で表し、最初に入力される定量的要件を符号ＱＣ０で表す。

ステップＳ８００の次に、構成情報具体化部１０１は、入力された抽象構成Ｄ０と入力された定量的要件ＱＣ０との組を探索木のルートとして定める（ステップＳ８０１）。

この探索木は、抽象構成と定量的要件との組をノードとする。また、抽象構成と定量的要件との組を、組（Ｄ，ＱＣ）等のように記す場合がある。

ステップＳ８０１の次に、構成情報具体化部１０１は、「具体化可能な組（Ｄ，ＱＣ）が残っていて、かつ、十分な数の具体構成が得られていない」という条件が満たされているか否かを判定する（ステップＳ８０２）。ここで、具体化可能な組（Ｄ，ＱＣ）とは、具体化可能な抽象構成Ｄと、その抽象構成Ｄに紐づけられる定量的要件ＱＣとの組である。また、上記の「十分な数」は、予め定められている。

上記の条件が満たされている場合（ステップＳ８０２のＹｅｓ）、構成情報具体化部１０１は、具体化可能な組（Ｄ，ＱＣ）を１つ選んで、具体化規則を用いて、その組（Ｄ，ＱＣ）を具体化し、組（Ｄ’，ＱＣ’）を得る（ステップＳ８０３）。ステップＳ８０３では、構成情報具体化部１０１は、具体化規則に基づいて、抽象構成Ｄを具体化することによって、抽象構成Ｄ’を生成する。そして、構成情報具体化部１０１は、その具体化規則に含まれる定量化要件テンプレートを具体化することによって、新たに追加すべき定量化要件を生成し、その定量化要件を定量的要件ＱＣに追加することによって、定量的要件ＱＣを更新する。この更新後（換言すれば、追加後）の定量的要件が、定量的要件ＱＣ’である。

ステップＳ８０３において具体化可能な組（Ｄ，ＱＣ）を１つ選ぶときに、構成情報具体化部１０１は、探索木に含まれている組（Ｄ，ＱＣ）のうち、「抽象構成Ｄが完全には具体化されていない」、かつ、「抽象構成Ｄ内の具体化対象に対して適用可能かつ未だ適用されたことのない具体化規則Ｒが存在する」という条件を満たす組（Ｄ，ＱＣ）を選ぶ。このとき、例えば、抽象構成Ｄ内に具体化規則Ｒが適用され得る具体化対象が２つ存在し、一方の具体化対象のみに具体化規則Ｒが適用されている場合には、その具体化規則Ｒを、抽象構成Ｄ内の具体化対象に未だ適用されたことのない具体化規則として扱う。

ステップＳ８０３の次に、構成情報具体化部１０１は、定量的要件ＱＣ’を定量的要件検証部１０３に入力し、定量的要件検証部１０３に対して、定量的要件ＱＣ’を満たす変数の値の割り当てが存在するか否かの検証を求める。定量的要件検証部１０３は、構成情報具体化部１０１からの要求に応じて、定量的要件ＱＣ’を満たす変数の値の割り当てが存在するか否かを検証し、その検証結果を、構成情報具体化部１０１に返す。構成情報具体化部１０１は、その検証結果によって、定量的要件ＱＣ’が充足可能であるか否かを判定する（ステップＳ８０４）。換言すれば、構成情報具体化部１０１は、その検証結果によって、定量的要件ＱＣ’を満たす変数の値の割り当てが存在するか否かを判断する。

定量的要件ＱＣ’が充足可能である場合（ステップＳ８０４のＹｅｓ）、構成情報具体化部１０１は、ステップＳ８０３で選択した組（Ｄ，ＱＣ）の子ノードとして、組（Ｄ’，ＱＣ’）を探索木に追加する（ステップＳ８０５）。

ステップＳ８０５の後、構成情報具体化部１０１は、ステップＳ８０２に移行し、ステップＳ８０２以降の処理を繰り返す。

また、定量的要件ＱＣ’が充足不能である場合（ステップＳ８０４のＮｏ）、構成情報具体化部１０１は、ステップＳ８０５を行うことなくステップＳ８０２に移行し、ステップＳ８０２以降の処理を繰り返す。

また、ステップＳ８０２で、「具体化可能な組（Ｄ，ＱＣ）が残っていて、かつ、十分な数の具体構成が得られていない」という条件が満たされていないと判断した場合（ステップＳ８０２のＮｏ）、構成情報具体化部１０１は、得られている具体構成を出力し（ステップＳ８０６）、処理を終了する。ステップＳ８０６では、得られている具体構成を全て出力してもよく、あるいは、得られている具体構成のうちのいくつか（例えば、１つ）を出力してもよい。

次に、構成情報具体化部１０１が生成する探索木の例について説明する。図１０は、構成情報具体化部１０１が生成する探索木の例を示す模式図である。組Ｎ９０１は、探索木のルートである。また、組Ｎ９０１は、抽象構成Ｎ９０１－Ｔと、定量的要件Ｎ９０１－ＱＣとの組である。図１０では見やすさのため、組Ｎ９０１に限らず、定量的要件を制約式リストのみによって示している。また、抽象構成の各ノードにおいて、要請する部品を示すラベルの図示を省略している。実際には、App 型のノードには、「Machine 」を要請するラベルが付帯している。

抽象構成Ｎ９０１－Ｔは、「Machine 」要請が満たされていないApp 型のノード「App-1 」、「App-2 」のみが存在する抽象構成である。

また、定量的要件Ｎ９０１－ＱＣの使用変数リストには、変数「App-1.Memory」、「App-2.Memory」および「System.CAPEX」が含まれる。定量的要件Ｎ９０１－ＱＣの制約式リストには、３つの制約式「App-1.Memory=7」、「App-2.Memory=10 」および「sum(System.CAPEX) ≦ 300000」のみが含まれる。

組Ｎ９０１の入力者は、アプリケーション「App-1 」、「App-2 」をデプロイしたいということを表す抽象構成Ｎ９０１－Ｔをシステム構成導出装置に入力したことになる。また、その入力者は、「App-1 には７ＧＢのメモリが必要である。」、「App-2 には１０ＧＢのメモリが必要である。」、および、「システム構築に新規に必要になる費用の上限は３０００００円以内である。」という内容の定量的要件Ｎ９０１－ＱＣをシステム構成導出装置に入力したことになる。

図１１、図１２および図１３は、図１０に示す探索木の生成に用いられた具体化規則を示す模式図である。

図１１に示す具体化規則９００Ａは、図８に示す具体化規則７００と同一である。

図１２に示す具体化規則９００Ｂは、具体化規則７００（図８参照）における型「ServerX 」を型「ServerY 」に置き換えた規則である。この置き換えに伴い、具体化規則７００における「{ server }.MemoryLimit ＝ 8」が、「{ server }.MemoryLimit ＝ 16」に置き換えられ、具体化規則７００における「{ server }.Price ＝ 120000」が、「{ server }.Price ＝ 170000」に置き換えられている。具体化規則９００Ｂのその他の点は、具体化規則７００（図８参照）と同一である。

図１３に示す具体化規則９００Ｃは、具体化規則７００（図８参照）における型「ServerX 」を型「ServerZ 」に置き換えた規則である。この置き換えに伴い、具体化規則７００における「{ server }.MemoryLimit ＝ 8」が、「{ server }.MemoryLimit ＝ 32」に置き換えられ、具体化規則７００における「{ server }.Price ＝ 120000」が、「{ server }.Price ＝ 240000」に置き換えられている。具体化規則９００Ｃのその他の点は、具体化規則７００（図８参照）と同一である。

３つの具体化規則９００Ａ，９００Ｂ，９００Ｃによって、組Ｎ９０１（図１０参照）からは、５パターンの具体化が考えられる。すなわち、具体化対象を「App-1 」とした場合の具体化規則９００Ａ，９００Ｂ，９００Ｃによる具体化と、具体化対象を「App-2 」とした場合の具体化規則９００Ｂ，９００Ｃによる具体化である。この５パターンの具体化によって、抽象構成と定量的要件との組として、５つの組Ｎ９０２，Ｎ９０３，Ｎ９０４，Ｎ９０５，Ｎ９０６が得られる。

ここで、組Ｎ９０１の抽象構成Ｎ９０１－Ｔの「App-2 」を具体化対象とした場合に、具体化規則９００Ａで具体化した場合の組は、探索木に追加されない。その理由は、その具体化の際に得られる更新後の定量的要件を満たすような変数への値の割り当てが存在しないからである。具体的には、新規に生成された型「ServerX 」のノードの識別子が「ServerX-1 」であるとすると、更新後の制約式リストには、以下に示す制約式が含まれる。

「App-1.Memory=7」
「App-2.Memory=10」
「sum(System.CAPEX) ≦300000」
「App-2.Memory ∈ ServerX-1.Memory」
「sum(ServerX-1.Memory) ≦ ServerX-1.MemoryLimit」
「ServerX-1.Price ∈ System.CAPEX」
「ServerX-1.MemoryLimit = 8」
「ServerX-1.Price = 120000」

これらの制約式を全て満たすような変数への値の割り当ては存在しない。すなわち、更新後の定量的要件は、充足不能である。よって、抽象構成Ｎ９０１－Ｔの「App-2 」を具体化対象とした場合に、具体化規則９００Ａで具体化した場合の組は、探索木に追加されない。

組Ｎ９０１を具体化して得られた５つの組のうち、更に具体化できる組は、組Ｎ９０２および組Ｎ９０５のみである。組Ｎ９０２に関しては、具体化対象を「App-2 」として、具体化規則９００Ｂを用いた具体化が可能である。組Ｎ９０５に関しては、具体化対象を「App-1 」として、具体化規則９００Ａを用いた具体化が可能である。いずれの場合も、具体化の結果は、組Ｎ９０７（図１０参照）となる。組Ｎ９０７に含まれる構成Ｎ９０７－Ｔは、完全に具体化されている具体構成である。従って、具体構成Ｎ９０７－Ｔが、入力された組Ｎ９０１を満たす唯一のシステム構成である。

なお、組Ｎ９０２および組Ｎ９０５に対して上記以外の具体化規則を適用して得られた組や、組Ｎ９０３，Ｎ９０４，Ｎ９０６に対して具体化規則を適用して得られた組は、探索木に追加されない。前述の場合と同様に、具体化の際に得られる更新後の定量的要件を満たすような変数への値の割り当てが存在しないからである。すなわち、更新後の定量的要件が充足不能であるからである。

以上が、探索木の具体例の説明である。

次に、定量的要件検証部１０３の動作について説明する。定量的要件検証部１０３は、構成情報具体化部１０１から定量的要件を受け取ると、その定量的要件を充足する変数への値の割り当てが存在するか否かを検証し、検証結果（すなわち、定量的要件を充足する変数への値の割り当てが存在するか否か）を、構成情報具体化部１０１に返す。

定量的要件を充足する変数への値の割り当てが存在するならば、その定量的要件は充足可能であり、そのような変数への値の割り当てが存在しなければ、その定量的要件は充足不能である。

数値型変数の値は集合型変数の値に影響しない。そのため、定量的要件検証部１０３は、集合型変数の値となる要素を決定し、集合型変数を含む制約式を、数値型変数のみを含む制約式に変形する。そして、定量的要件検証部１０３は、数値型変数のみを含む制約式による制約を満たす変数への値の割り当てが存在するか否かを検証することによって、定量的要件の充足性を検証する。

図１４は、定量的要件検証部１０３の処理経過の例を示すフローチャートである。

定量的要件検証部１０３は、構成情報具体化部１０１から与えられた定量的要件で定められている制約を、集合型制約（以下、符号ＳＣで表す。）と、それ以外の数値型制約（以下、符号ＮＣで表す。）とに分ける（ステップＳ９９９）。集合型制約ＳＣは、「ｘ∈Ａ」という形式で記載される所属制約と、「Ａ∈Ｂ」という形式で記載される包含制約とに分類できる。

次に、定量的要件検証部１０３は、集合型制約ＳＣに含まれる所属制約に基づいて、各集合型変数の初期値を定める（ステップＳ１０００）。１つ以上の数値型変数がそれぞれ、共通の集合型変数の値となる集合に属している場合、定量的要件検証部１０３は、その数値型変数の集合をその集合型変数の初期値として定める。例えば、集合型変数Ａに関する全ての所属制約が、「ｘ（１）∈Ａ」、「ｘ（２）∈Ａ」、・・・、「ｘ（ｎ）∈Ａ」であるとする。ｘ（１），ｘ（２），・・・，ｘ（ｎ）は、数値型変数である。この場合、定量的要件検証部１０３は、集合型変数Ａの初期値を、「Ａ＝｛ｘ（１），ｘ（２），・・・，ｘ（ｎ）｝」と定める。定量的要件検証部１０３は、他の集合型変数に関してもそれぞれ同様に初期値を定める。

ステップＳ１０００の次に、定量的要件検証部１０３は、集合型制約ＳＣに含まれている包含制約に基づいて、集合型変数の値を更新する（ステップＳ１００１）。ステップＳ１００１において、定量的要件検証部１０３は、包含制約「Ｓ（１）⊆Ｓ（２）」に関して、集合型変数Ｓ（１）の値となる集合に含まれる全ての数値型変数を、集合型変数Ｓ（２）の値となる集合に追加する。ただし、既に集合型変数Ｓ（２）の値となる集合に含まれている数値型変数については、重複して追加されない。定量的要件検証部１０３は、この動作を包含制約毎に行う。

次に、定量的要件検証部１０３は、ステップＳ１００１における更新前の集合型変数の値と、更新後の集合型変数の値との間に差分があるか否かを判定する（ステップＳ１００２）。

差分がある場合（ステップＳ１００２のＹｅｓ）、定量的要件検証部１０３は、ステップＳ１００１以降の動作を繰り返す。

差分がない場合（ステップＳ１００２のＮｏ）、その時点での集合型変数の値が、閉世界仮説の下での、集合型制約ＳＣの唯一のモデルとなる。差分がない場合には（ステップＳ１００２のＮｏ）、定量的要件検証部１０３は、集合型変数を含む制約式を、数値型変数のみを含む制約式に変形する（ステップＳ１００３）。すなわち、定量的要件検証部１０３は、制約式から集合型変数を除去する。例えば、「ｓｕｍ（Ｓ）」が集合型変数Ｓの値となる集合に含まれる数値型変数の和を意味しているものとする。そして、集合型変数Ｓの値となる集合が｛ａ，ｂ，ｃ，ｄ｝であるとする。この場合、定量的要件検証部１０３は、集合型変数Ｓを含む制約式「ｓｕｍ（Ｓ）≦ｕｂ」を、数値型変数のみを含む制約式「ａ＋ｂ＋ｃ＋ｄ≦ｕｂ」に変形する。

ステップＳ１００３の次に、定量的要件検証部１０３は、数値型制約の充足性を検証し、数値型制約を満たす変数への値の割り当てが存在するか否かを、検証結果として、構成情報具体化部１０１に返す（ステップＳ１００４）。ここで、数値型制約を満たす変数への値の割り当てが存在するということは、定量的要件を充足する変数への値の割り当てが存在することを意味する。数値型制約を満たす変数への値の割り当てが存在しないということは、定量的要件を充足する変数への値の割り当てが存在しないことを意味する。

ステップＳ１００４で数値型制約を満たす変数への値の割り当てが存在するか否かを判定する方法は、特に限定されず、公知の方法でよい。数値型制約を満たす変数への値の割り当てが存在するか否かを判定する方法の例として、例えば、Fourier-Motzkin の消去法や、Cylindrical Algebraic Decomposition (CAD) を利用した量化子消去アルゴリズム等が挙げられる。

次に、更新前後の集合型変数の値の差分が無くなるまで、ステップＳ１００１，Ｓ１００２が繰り返されるときの、集合型変数の値の変化の具体例を示す。図１５は、集合型変数の値の変化の具体例を示す模式図である。

図１５に示す集合型制約ＳＣが得られているとする。この集合型制約ＳＣは、所属制約である「ｘ∈Ａ」、「ｙ∈Ｂ」および「ｚ∈Ｃ」、並びに、包含制約「Ａ⊆Ｃ」、「Ｂ⊆Ｄ」および「Ｃ⊆Ｄ」を含んでいる。ここで、ｘ，ｙ，ｚは、数値型変数である。Ａ，Ｂ，Ｃ，Ｄは、集合型変数である。

図１５に示すＰ１１０１は、各集合型変数Ａ，Ｂ，Ｃ，Ｄの初期値である。所属制約は、「ｘ∈Ａ」、「ｙ∈Ｂ」および「ｚ∈Ｃ」のみである。従って、Ａの初期値は｛ｘ｝となり、Ｂの初期値は｛ｙ｝となり、Ｃの初期値｛ｚ｝となる。また、Ｄの初期値は、｛｝（すなわち、空集合）となる。

図１５に示すＰ１１０２は、Ｐ１１０１の状態から、ステップＳ１００１（図１４参照）が１回実行された結果を表している。包含制約「Ａ⊆Ｃ」により、Ａの初期値に含まれる数値型変数が、Ｃの値となる集合に追加される。この結果、Ｃの値は｛ｘ，ｚ｝となる。また、包含制約「Ｂ⊆Ｄ」および「Ｃ⊆Ｄ」により、Ｂの初期値に含まれる数値型変数およびＣの初期値に含まれる数値型変数が、Ｄの値となる集合に追加される。この結果、Ｄの値は｛ｙ，ｚ｝となる。

図１５に示すＰ１１０３は、Ｐ１１０２の状態から、ステップＳ１００１がさらに１回実行された結果を表している。包含制約「Ａ⊆Ｃ」により、Ａの値に含まれる数値型変数が、Ｃの値となる集合に追加される。ただし、既にＣの値となる集合に含まれている数値型変数は重複して追加されないので、Ｃの値は｛ｘ，ｚ｝のままである。また、包含制約「Ｂ⊆Ｄ」および「Ｃ⊆Ｄ」により、Ｂの値に含まれる数値型変数およびＣの値に含まれる数値型変数が、Ｄの値となる集合に追加される。この結果、Ｄの値は｛ｘ，ｙ，ｚ｝となる。

図１５に示すＰ１１０４は、Ｐ１１０３の状態から、ステップＳ１００１がさらに１回実行された結果を表している。包含制約「Ａ⊆Ｃ」により、Ａの値に含まれる数値型変数が、Ｃの値となる集合に追加される。ただし、既にＣの値となる集合に含まれている数値型変数は重複して追加されないので、Ｃの値は｛ｘ，ｚ｝のままである。また、包含制約「Ｂ⊆Ｄ」および「Ｃ⊆Ｄ」により、Ｂの値に含まれる数値型変数およびＣの値に含まれる数値型変数が、Ｄの値となる集合に追加される。ただし、既にＤの値となる集合に含まれている数値型変数は重複して追加されないので、Ｄの値は｛ｘ，ｙ，ｚ｝のままである。すなわち、更新前のＰ１１０３と、更新後のＰ１１０４との間に差分はなく、Ｐ１１０４の状態で、ステップＳ１００３（図１４）に移行することになる。

本実施形態において、構成情報具体化部１０１は、抽象構成および定量的要件の入力を受け付ける。そして、構成情報具体化部１０１は、抽象構成に対して具体化規則を適用して、抽象構成の具体化および定量的要件の更新を繰り返す。そして、最終的に、完全に具体化されたＩＣＴシステムの構成を示す具体構成が得られたならば、構成情報具体化部１０１は、その具体構成を出力する。

また、本実施形態の構成情報具体化部１０１は、抽象構成の具体化の度に、更新された定量的要件の充足可能性を定量的要件検証部１０３に問い合わせる。その結果、更新された定量的要件が充足可能である場合にのみ、構成情報具体化部１０１は、抽象構成の具体化を許容する。

従って、最終的に得られた具体構成に紐づけられている定量的要件も充足可能である。よって、抽象構成と、一部の数値が未確定である定量的要件とが与えられた場合に、その定量的要件を含む、所望のシステムの動作に必要な条件等を表した定量的要件を満たし、かつ、その抽象構成を具体化した具体的なシステム構成を出力することができる。例えば、機能要件（与えられた抽象構成）だけでなく、数値的な要件（例えば、性能、リソース制限、ネットワーク帯域、予算等の数値的な要件）も満たすＩＣＴシステムの具体構成を出力することができる。

実施形態２．
図１６は、本発明の第２の実施形態のシステム構成導出装置の構成例を示すブロック図である。第２の実施形態のシステム構成導出装置２００は、構成情報具体化部１０１と、具体化規則記憶部１０２と、定量的要件検証部１０３と、定量的要件判定部２０１と、充足性情報記憶部２０２とを備える。

まず、本実施形態において、構成情報具体化部１０１への入力となる定量的要件、および、具体化規則に含まれる定量的要件テンプレートが満たすべき条件について説明する。この条件を、以下、規約Ｗと称する。

規約Ｗは、「充足可能な定量的要件ＱＣにおいて、定量的要件ＱＣの制約式リストからいくつかの制約式リストを取り除いてできる定量的要件ＷＱＣは必ず充足可能でなければならない。」という条件である。

本実施形態では、規約Ｗを満たさない定量的要件が入力されたり、規約Ｗを満たさない定量的要件テンプレートを含む具体化規則を用いたりする場合においても、システム構成導出装置２００は動作できる。しかし、その場合には、導出された具体構成が定量的要件を満たしていなかったり、入力された抽象構成に基づいていてかつ定量的要件を満たす具体構成が存在するにも関わらず具体構成が導出されなかったりする場合があるという問題が生じる。

システム構成導出装置２００に入力される定量的要件や、各具体化規則に含まれる定量的要件テンプレートが規約Ｗを満たす場合には、上記の問題は起こらず、定量的要件を満たす適切な具体構成が得られる。

具体化規則記憶部１０２は、第１の実施形態における具体化規則記憶部１０２と同様である。ただし、第２の実施形態の具体化規則記憶部１０２に記憶されている具体化規則内の定量的要件テンプレートは、規約Ｗを満たしている。

構成情報具体化部１０１の動作は、第１の実施形態の構成情報具体化部１０１の動作と同様に、図９に示すフローチャートで表される。ただし、第２の実施形態では、構成情報具体化部１０１は、ステップＳ８０４（図９参照）において、定量的要件判定部２０１に定量的要件ＱＣ’を入力し、定量的要件判定部２０１に対して、定量的要件ＱＣ’の充足性に関する判定結果を求める。そして、構成情報具体化部１０１は、定量的要件判定部２０１から判定結果を返され、その判定結果に基づいて、定量的要件ＱＣ’を満たす変数の値の割り当てが存在するか否かを判断する。すなわち、第２の実施形態では、構成情報具体化部１０１は、定量的要件ＱＣ’の充足性に関する問い合わせを、定量的要件検証部１０３ではなく、定量的要件判定部２０１に対して行う。この点と、規約Ｗを満たす定量的要件が入力されなければならないという点以外に関しては、構成情報具体化部１０１は、第１の実施形態における構成情報具体化部１０１と同様である。

定量的要件検証部１０３の動作は、第１の実施形態の定量的要件検証部１０３の動作と同様である。ただし、第２の実施形態では、定量的要件検証部１０３は、定量的要件判定部２０１から定量的要件を受け取り、その定量的要件を充足する変数への値の割り当てが存在するか否かの検証結果を、定量的要件判定部２０１に返す。すなわち、第２の実施形態では、定量的要件検証部１０３は、定量的要件の充足性に関する問い合わせを、定量的要件判定部２０１から受け、検証結果を定量的要件判定部２０１に返す。

充足性情報記憶部２０２は、定量的要件検証部１０３に与えられた定量的要件と、定量的要件検証部１０３が導出したその定量的要件の充足性に関する検証結果との組を記憶する。そして、充足性情報記憶部２０２は、定量的要件ＱＣ’を満たす変数への値の割り当てが存在するか否かに関する問い合わせを定量的要件判定部２０１から受けると、記憶している組（定量的要件と検証結果との組）に基づいて、その問合せへの応答を返す。

定量的要件判定部２０１は、構成情報具体化部１０１から定量的要件ＱＣ’が与えられ、定量的要件ＱＣ’の充足性に関する判定結果を求められる。すると、定量的要件判定部２０１は、その定量的要件ＱＣ’に含まれる制約式リストを含むクエリを充足性情報記憶部２０２に与え、定量的要件ＱＣ’の充足性に関する問い合わせを充足性情報記憶部２０２に対して行う。充足性情報記憶部２０２からの応答によって、定量的要件ＱＣ’を満たす変数への値の割り当てが存在するか否かが明らかになった場合には、その結果を、構成情報具体化部１０１に返す。しかし、充足性情報記憶部２０２からの応答で、定量的要件ＱＣ’を満たす変数への値の割り当てが存在するか否かが明らかにならない場合もあり得る。そのような場合には、定量的要件判定部２０１は、定量的要件ＱＣ’を定量的要件検証部１０３に与え、定量的要件検証部１０３から検証結果を受け取り、その検証結果を構成情報具体化部１０１に返す。

すなわち、定量的要件判定部２０１は、構成情報具体化部１０１から定量的要件ＱＣ’の充足性に関する判定結果を求めると、定量的要件ＱＣ’の充足性を充足性情報記憶部２０２に問い合わせる。充足性情報記憶部２０２からの応答で定量的要件ＱＣ’の充足性が明らかになった場合には、その結果を、構成情報具体化部１０１に返す。充足性情報記憶部２０２からの応答で定量的要件ＱＣ’の充足性が明らかにならなかった場合には、定量的要件判定部２０１は、定量的要件ＱＣ’の充足性に関する検証を定量的要件検証部１０３に要求し、その検証結果を構成情報具体化部１０１に返す。

充足性情報記憶部２０２は、定量的要件ＱＣ’内の制約式リスト（ＣＬと記す。）を含むクエリを定量的要件判定部２０１から受け取る。このクエリは２種類あり、一方をＱｓ（ＣＬ）と記し、もう一方をＱｆ（ＣＬ）と記す。

充足性情報記憶部２０２は、クエリＱｓ（ＣＬ）を与えられると、制約式リストＣＬに含まれる全ての制約式を含む制約式リスト（すなわち、制約式リストＣＬを包含する制約式リスト）と、充足可能という検証結果との組を記憶しているか否かを判定する。充足性情報記憶部２０２は、そのような組を記憶しているならば、Ｙｅｓを定量的要件判定部２０１に返す。充足性情報記憶部２０２は、そのような組を記憶していないならば、Ｎｏを定量的要件判定部２０１に返す。充足性情報記憶部２０２は、クエリＱｓ（ＣＬ）に対する応答としてＹｅｓが返された場合、定量的要件ＱＣ’は充足可能であると判定する。

充足性情報記憶部２０２は、クエリＱｆ（ＣＬ）を与えられると、制約式リストＣＬのサブセットとなる制約式リストと、充足不能という検証結果との組を記憶しているか否かを判定する。充足性情報記憶部２０２は、そのような組を記憶しているならば、Ｙｅｓを定量的要件判定部２０１に返す。充足性情報記憶部２０２は、そのような組を記憶していないならば、Ｎｏを定量的要件判定部２０１に返す。充足性情報記憶部２０２は、Ｑｆ（ＣＬ）に対する応答としてＹｅｓが返された場合、定量的要件ＱＣ’は充足不能であると判定する。

定量的要件判定部２０１が、充足性情報記憶部２０２から受け取る応答の例を示す。例えば、充足性情報記憶部２０２が、制約式リスト「Ｃ１，Ｃ２，Ｃ３，Ｃ４」を含む定量的要件と、「充足可能」という検証結果との組を記憶し、また、制約式リスト「Ｃ３，Ｃ５」を含む定量的要件と、「充足不能」という検証結果との組を記憶しているとする。

そして、制約式リストＣＬが「Ｃ１，Ｃ２，Ｃ３」であるとする。この場合、定量的要件判定部２０１は、クエリＱｓ（ＣＬ）を充足性情報記憶部２０２に与えた場合には、“Ｙｅｓ”という応答を受け取り、クエリＱｆ（ＣＬ）を充足性情報記憶部２０２に与えた場合には、“Ｎｏ”という応答を受け取る。

また、制約式リストＣＬが「Ｃ３，Ｃ４，Ｃ５」であるとする。この場合、定量的要件判定部２０１は、クエリＱｓ（ＣＬ）を充足性情報記憶部２０２に与えた場合には、“Ｎｏ”という応答を受け取り、クエリＱｆ（ＣＬ）を充足性情報記憶部２０２に与えた場合には、“Ｙｅｓ”という応答を受け取る。

また、制約式リストＣＬが「Ｃ５」であるとする。この場合、定量的要件判定部２０１は、クエリＱｓ（ＣＬ）を充足性情報記憶部２０２に与えた場合であっても、クエリＱｆ（ＣＬ）を充足性情報記憶部２０２に与えた場合であっても、“Ｎｏ”という応答を受け取る。

次に、ステップＳ８０４（図９参照）で定量的要件判定部２０１が構成情報具体化部１０１から定量的要件ＱＣ’を与えられたときの処理経過について説明する。図１７は、このときの定量的要件判定部２０１の処理経過の例を示すフローチャートである。構成情報具体化部１０１から与えられた定量的要件ＱＣ’に含まれる制約式リストをＣＬとする。

定量的要件判定部２０１は、まず、クエリＱｓ（ＣＬ）を充足性情報記憶部２０２に与え、そのクエリＱｓ（ＣＬ）に対する充足性情報記憶部２０２からの応答がＹｅｓであるかＮｏであるかを判定する（ステップＳ１２００）。

クエリＱｓ（ＣＬ）に対する応答が“Ｙｅｓ”であるならば、定量的要件判定部２０１は、「定量的要件ＱＣ’は充足可能である」という判定結果を構成情報具体化部１０１に返し（ステップＳ１２０５）、処理を終了する。

クエリＱｓ（ＣＬ）に対する応答が“Ｎｏ”であるならば、ステップＳ１２０１に移行する。ステップＳ１２０１において、定量的要件判定部２０１は、クエリＱｆ（ＣＬ）を充足性情報記憶部２０２に与え、そのクエリＱｆ（ＣＬ）に対する充足性情報記憶部２０２からの応答がＹｅｓであるかＮｏであるかを判定する。

クエリＱｆ（ＣＬ）に対する応答が“Ｙｅｓ”であるならば、定量的要件判定部２０１は、「定量的要件ＱＣ’は充足不能である」という判定結果を構成情報具体化部１０１に返し（ステップＳ１２０６）、処理を終了する。

クエリＱｆ（ＣＬ）に対する応答が“Ｎｏ”であるならば、ステップＳ１２０２に移行する。

クエリＱｓ（ＣＬ）に対する応答、および、クエリＱｆ（ＣＬ）に対する応答がいずれも“Ｎｏ”である場合というのは、充足性情報記憶部２０２からの応答で定量的要件ＱＣ’の充足性が明らかにならなかった場合である。すなわち、充足性情報記憶部２０２からの応答では、定量的要件ＱＣ’の充足性が不明である場合である。

この場合、ステップＳ１２０２において、定量的要件判定部２０１は、定量的要件ＱＣ’を定量的要件検証部１０３に入力し、定量的要件検証部１０３に対して、定量的要件ＱＣ’を満たす変数の値の割り当てが存在するか否かの検証を求める。そして、定量的要件検証部１０３は、定量的要件判定部２０１からの要求に応じて、定量的要件ＱＣ’を満たす変数の値の割り当てが存在するか否かを検証し、定量的要件判定部２０１は、その検証結果を定量的要件検証部１０３から取得する。

次に、定量的要件判定部２０１は、定量的要件ＱＣ’と、ステップＳ１２０２で取得した検証結果との組を充足性情報記憶部２０２に記憶させる（ステップＳ１２０３）。

次に、定量的要件判定部２０１は、ステップＳ１２０２で取得した検証結果を構成情報具体化部１０１に返し（ステップＳ１２０４）、処理を終了する。

第２の実施形態において、構成情報具体化部１０１、定量的要件判定部２０１、充足性情報記憶部２０２および定量的要件検証部１０３は、例えば、システム構成導出プログラムに従って動作するコンピュータのＣＰＵによって実現される。例えば、ＣＰＵが、コンピュータのプログラム記憶装置等のプログラム記録媒体からシステム構成導出プログラムを読み込み、そのシステム構成導出プログラムに従って、構成情報具体化部１０１、定量的要件判定部２０１、充足性情報記憶部２０２および定量的要件検証部１０３として動作すればよい。

第２の実施形態においても、第１の実施形態と同様の効果が得られる。さらに、第２の実施形態では、充足性情報記憶部２０２が、定量的要件検証部１０３による定量的要件の検証結果を再利用して、クエリに対する応答を定量的要件判定部２０１に返している。そして、定量的要件判定部２０１からの応答で、定量的要件の充足性が明らかにならなかった場合に、定量的要件判定部２０１は、その定量的要件の充足性の検証を定量的要件検証部１０３に行わせる。

ここで、充足性情報記憶部２０２がクエリに対する応答を導出する処理は、与えられたクエリに含まれている制約式リストと、充足性情報記憶部２０２が記憶している情報との照合によって行うことができる。従って、この処理は、定量的要件検証部１０３による検証処理（図１４参照）よりも高速に実現できる。従って、第２の実施形態によれば、より高速に、定量的要件を満たす具体構成を導出することができる。

次に、本発明の各実施形態における抽象構成および定量的要件の入力態様と、具体構成の出力態様の例について説明する。

図１８は、各実施形態における抽象構成および定量的要件の入力画面の例を示す説明図である。構成情報具体化部１０１は、ディスプレイ装置（図５、図１６において図示略）に、入力画面７０を表示させる。入力画面７０は、第１の入力領域７１と、第２の入力領域と、ボタン７５とを含む。

第１の入力領域７１は、抽象構成を入力するための領域である。第１の入力領域７１では、マウスやキーボード等の入力デバイス（図５、図１６において図示略）およびＧＵＩ（Graphical User Interface）によって、アイコンを含むノード、ノード間を結ぶエッジ、およびエンティティの吹き出しを描画可能である。また、キーボードやマウス等の入力デバイスを用いることで、吹き出し内に、エンティティの識別子および型情報を記述することも可能である。オペレータが、ノード、エッジ、吹き出し等を描画することによって、抽象構成を表すグラフが第１の入力領域７１内に描画される。

構成情報具体化部１０１は、入力となる抽象構成を、第１の入力領域７１に描画されたグラフとして取得する。

第２の入力領域７２は、定量的要件を入力するための領域である。第２の入力領域７２は、使用変数リストを入力するための第１のテキストボックス７３と、制約式リストを入力するための第２のテキストボックス７４とを含む。

第１のテキストボックス７３には、マウスやキーボード等の入力デバイスによって使用変数リストがテキストデータとして入力される。また、第２のテキストボックス７４には、マウスやキーボード等の入力デバイスによって制約式リストがテキストデータとして入力される。

第１のテキストボックス７３に使用変数リストに該当するテキストデータが入力され、第２のテキストボックス７４に制約式リストに該当するテキストデータとして入力されることによって、構成情報具体化部１０１は、入力となる定量的要件（一部の数値が未確定である定量的要件）を、テキストデータとして取得する。

構成情報具体化部１０１は、ボタン７５がマウスクリックされた時点で、第１の入力領域７１にグラフとして入力された抽象構成と、第２の入力領域７２にテキストデータとして入力された定量的要件とを取得し、各実施形態のシステム構成導出装置は、各実施形態の動作を開始すればよい。

また、上記の例では、構成情報具体化部１０１が、第１の入力領域７１にグラフとして入力された抽象構成と、第２の入力領域７２にテキストデータとして入力された定量的要件とを取得する場合を説明した。抽象構成および定量的要件の入力態様は、上記の例に限定されない。例えば、抽象構成および定量的要件がファイルに記述され、そのファイルが光学ディスク等のデータ記録媒体に記録されていてもよい。そして、各実施形態において、システム構成導出装置が、データ記録媒体に記録されたデータを読み込むデータ読み込み装置（図示略）を備え、データ読み込み装置がデータ記録媒体から、抽象構成および定量的要件が記述されたファイルを読み込み、構成情報具体化部１０１がそのファイルを取得してもよい。

図１９は、各実施形態のシステム構成導出装置における具体構成の出力画面の例を示す説明図である。構成情報具体化部１０１は、具体構成を導出した後に、図１９に例示するような、具体構成をグラフとして表す出力画面８０を、ディスプレイ装置に表示させてもよい。

実施形態３．
図２０は、本発明の第３の実施形態のシステム構成導出装置の例を示すブロック図である。第３の実施形態のシステム構成導出装置３００は、構成情報具体化手段３０１を備える。

構成情報具体化手段３０１（例えば、構成情報具体化部１０１に対応する。）は、未確定な部分が存在するシステム構成を示す情報である抽象構成と、システムに要求される数値的な要件である定量的要件であって、一部の数値が未確定である定量的要件とを入力として取得し、未確定な部分が存在しないシステム構成を示す情報である具体構成であって、定量的要件を満たした具体構成を出力する。

そのような構成により、抽象構成と、一部の数値が未確定である定量的要件とが与えられた場合に、その定量的要件を含む、所望のシステムの動作に必要な条件等を表した定量的要件を満たし、かつ、その抽象構成を具体化した具体的なシステム構成を出力することができる。

また、抽象構成を具体化するとともに定量的要件を更新するための規則である具体化規則を記憶する具体化規則記憶手段（例えば、具体化規則記憶部１０２に対応する。）を備え、構成情報具体化手段３０１が、具体化規則に基づいて、定量的要件を段階的に更新しつつ、定量的要件を満たすように、抽象構成を段階的に具体化する構成であってもよい。

また、構成情報具体化手段３０１が、入力となる抽象構成と入力となる定量的要件との組を探索木のルートとし、具体化規則に基づいて得られる新たな抽象構成および新たな定量的要件の組における新たな定量的要件を満たす値が存在する場合に、当該組を探索木の子ノードとして探索木に追加することを繰り返すことによって、具体構成を導出する構成であってもよい。

また、定量的要件が与えられたときに、定量的要件を満たす値の割り当てが存在するか否かを検証する定量的要件検証手段（例えば、定量的要件検証部１０３に対応する。）を備え、構成情報具体化手段３０１が、新たな定量的要件を定量的要件検証手段に与えることによって、新たな定量的要件を満たす値の割り当てが存在するか否かを定量的要件検証手段に問い合わせる構成であってもよい。

また、定量的要件が与えられたときに、定量的要件を満たす値の割り当てが存在するか否かを検証する定量的要件検証手段（例えば、定量的要件検証部１０３に対応する。）と、定量的要件検証手段に与えられた定量的要件と、検証結果との組を記憶し、記憶した組に基づいて、新たな定量的要件を満たす値の割り当てが存在するか否かに関する問い合わせに応答する充足性情報記憶手段（例えば、充足性情報記憶部２０２に対応する。）と、構成情報具体化手段３０１から新たな定量的要件を与えられた場合に、充足性情報記憶手段に対して、新たな定量的要件を満たす値の割り当てが存在するか否かに関する問い合わせを行い、充足性情報記憶手段から、新たな定量的要件を満たす値の割り当てが存在するか否かが不明であるという応答を得た場合に、新たな定量的要件を定量的要件検証手段に与えることによって、新たな定量的要件を満たす値の割り当てが存在するか否かを定量的要件検証手段に問い合わせる定量的要件判定手段（例えば、定量的要件判定部２０１に対応する。）とを備える構成であってもよい。

また、構成情報具体化手段３０１が、入力となる抽象構成を、描画されたグラフとして取得するとともに、入力となる定量的要件をテキストデータとして取得し、具体構成をグラフとして出力する構成であってもよい。

図２１は、本発明の各実施形態のシステム構成導出装置に係るコンピュータの構成例を示す概略ブロック図である。コンピュータ１０００は、ＣＰＵ１００１と、主記憶装置１００２と、補助記憶装置１００３と、インタフェース１００４と、キーボード１００５と、マウス１００６と、ディスプレイ装置１００７とを備える。

本発明の各実施形態のシステム構成導出装置は、コンピュータ１０００によって実現される。システム構成導出装置の動作は、プログラム（システム構成導出プログラム）の形式で補助記憶装置１００３に記憶されている。ＣＰＵ１００１は、そのプログラムを補助記憶装置１００３から読み出して主記憶装置１００２に展開し、そのプログラムに従って、上記の各実施形態で説明した処理を実行する。

補助記憶装置１００３は、一時的でない有形の媒体の例である。一時的でない有形の媒体の他の例として、インタフェース１００４を介して接続される磁気ディスク、光磁気ディスク、ＣＤ－ＲＯＭ（Compact Disk Read Only Memory ）、ＤＶＤ－ＲＯＭ（Digital Versatile Disk Read Only Memory ）、半導体メモリ等が挙げられる。また、プログラムが通信回線によってコンピュータ１０００に配信される場合、配信を受けたコンピュータ１０００がそのプログラムを主記憶装置１００２に展開し、そのプログラムに従って上記の各実施形態で説明した処理を実行してもよい。

また、各構成要素の一部または全部は、汎用または専用の回路（circuitry ）、プロセッサ等やこれらの組み合わせによって実現されてもよい。これらは、単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。各構成要素の一部または全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。

各構成要素の一部または全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。

本発明は、抽象構成に基づいて具体構成を導出するシステム構成導出装置に好適に適用可能である。

１００，２００ システム構成導出装置
１０１ 構成情報具体化部
１０２ 具体化規則記憶部
１０３ 定量的要件検証部
２０１ 定量的要件判定部
２０２ 充足性情報記憶部

Claims (9)

1. 未確定な部分が存在するシステム構成を示す情報である抽象構成と、システムに要求される数値的な要件である定量的要件であって、一部の数値が未確定である定量的要件とを入力として取得し、未確定な部分が存在しないシステム構成を示す情報である具体構成であって、前記定量的要件を満たした具体構成を出力する構成情報具体化手段を含み、
   前記構成情報具体化手段は、
   入力となる前記抽象構成を、描画されたグラフとして取得するとともに、入力となる前記定量的要件をテキストデータとして取得し、
   前記具体構成をグラフとして出力する
   ことを特徴とするシステム構成導出装置。
2. 前記抽象構成を具体化するとともに前記定量的要件を更新するための規則である具体化規則を記憶する具体化規則記憶手段を備え、
   前記構成情報具体化手段は、
   前記具体化規則に基づいて、前記定量的要件を段階的に更新しつつ、前記定量的要件を満たすように、前記抽象構成を段階的に具体化する
   請求項１に記載のシステム構成導出装置。
3. 前記構成情報具体化手段は、
   入力となる前記抽象構成と入力となる前記定量的要件との組を探索木のルートとし、
   前記具体化規則に基づいて得られる新たな抽象構成および新たな定量的要件の組における前記新たな定量的要件を満たす値が存在する場合に、当該組を前記探索木の子ノードとして探索木に追加することを繰り返すことによって、前記具体構成を導出する
   請求項２に記載のシステム構成導出装置。
4. 定量的要件が与えられたときに、前記定量的要件を満たす値の割り当てが存在するか否かを検証する定量的要件検証手段を備え、
   前記構成情報具体化手段は、
   前記新たな定量的要件を前記定量的要件検証手段に与えることによって、前記新たな定量的要件を満たす値の割り当てが存在するか否かを前記定量的要件検証手段に問い合わせる
   請求項３に記載のシステム構成導出装置。
5. 定量的要件が与えられたときに、前記定量的要件を満たす値の割り当てが存在するか否かを検証する定量的要件検証手段と、
   前記定量的要件検証手段に与えられた前記定量的要件と、検証結果との組を記憶し、記憶した組に基づいて、前記新たな定量的要件を満たす値の割り当てが存在するか否かに関する問い合わせに応答する充足性情報記憶手段と、
   前記構成情報具体化手段から前記新たな定量的要件を与えられた場合に、前記充足性情報記憶手段に対して、前記新たな定量的要件を満たす値の割り当てが存在するか否かに関する問い合わせを行い、前記充足性情報記憶手段から、前記新たな定量的要件を満たす値の割り当てが存在するか否かが不明であるという応答を得た場合に、前記新たな定量的要件を前記定量的要件検証手段に与えることによって、前記新たな定量的要件を満たす値の割り当てが存在するか否かを前記定量的要件検証手段に問い合わせる定量的要件判定手段とを備える
   請求項３に記載のシステム構成導出装置。
6. 未確定な部分が存在するシステム構成を示す情報である抽象構成と、システムに要求される数値的な要件である定量的要件であって、一部の数値が未確定である定量的要件とを入力として取得し、未確定な部分が存在しないシステム構成を示す情報である具体構成であって、前記定量的要件を満たした具体構成を出力し、
   入力となる前記抽象構成を、描画されたグラフとして取得するとともに、入力となる前記定量的要件をテキストデータとして取得し、
   前記具体構成をグラフとして出力する
   ことを特徴とするシステム構成導出方法。
7. 前記抽象構成を具体化するとともに前記定量的要件を更新するための規則である具体化規則に基づいて、前記定量的要件を段階的に更新しつつ、前記定量的要件を満たすように、前記抽象構成を段階的に具体化する
   請求項６に記載のシステム構成導出方法。
8. コンピュータに、
   未確定な部分が存在するシステム構成を示す情報である抽象構成と、システムに要求される数値的な要件である定量的要件であって、一部の数値が未確定である定量的要件とを入力として取得し、未確定な部分が存在しないシステム構成を示す情報である具体構成であって、前記定量的要件を満たした具体構成を出力する構成情報具体化処理を実行させ、
   前記構成情報具体化処理で、
   入力となる前記抽象構成を、描画されたグラフとして取得させるとともに、入力となる前記定量的要件をテキストデータとして取得させ、
   前記具体構成をグラフとして出力させる
   ためのシステム構成導出プログラム。
9. 前記コンピュータに、
   前記構成情報具体化処理で、
   前記抽象構成を具体化するとともに前記定量的要件を更新するための規則である具体化規則に基づいて、前記定量的要件を段階的に更新しつつ、前記定量的要件を満たすように、前記抽象構成を段階的に具体化させる
   請求項８に記載のシステム構成導出プログラム。

Images