知財求人 - 知財ポータルサイト「IP Force」
特開2024-131058冗長構成の設計を可能とするシステム自動設計装置、システム自動設計方法、およびプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024131058
(43)【公開日】2024-09-30
(54)【発明の名称】冗長構成の設計を可能とするシステム自動設計装置、システム自動設計方法、およびプログラム
(51)【国際特許分類】
G06F 8/30 20180101AFI20240920BHJP
【ＦＩ】
G06F8/30
【審査請求】未請求
【請求項の数】11
【出願形態】ＯＬ
(21)【出願番号】P 2023041085
(22)【出願日】2023-03-15
【国等の委託研究の成果に係る記載事項】（出願人による申告）令和４年度、国立研究開発法人情報通信研究機構「Ｂｅｙｏｎｄ ５Ｇ超高速・大容量ネットワークの自律性・超低消費電力を実現するネットワークサービス基盤技術の研究開発／ネットワークサービス基盤技術／超高速・大容量ネットワークの一元的な制御や電源最適化を実現するネットワークサービス基盤技術の研究開発」産業技術力強化法第１７条の適用を受ける特許出願
(71)【出願人】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100149548
【弁理士】
【氏名又は名称】松沼 泰史
(74)【代理人】
【識別番号】100181135
【弁理士】
【氏名又は名称】橋本 隆史
(72)【発明者】
【氏名】渡辺 俊貴
(72)【発明者】
【氏名】黒田 貴之
【テーマコード（参考）】
5B376
【Ｆターム（参考）】
5B376BC14
5B376BC24
5B376BC32
5B376BC80
(57)【要約】
【課題】冗長化されたシステム構成を自動設計することができるシステム自動設計装置を提供する。
【解決手段】システム自動設計装置は、冗長化の要求を含むシステムの要件を受け付ける入力手段と、前記システムの構成要素を冗長化しながら具体化するパタ－ンを定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成する構成生成手段と、を備える。
【選択図】図１
【解決手段】システム自動設計装置は、冗長化の要求を含むシステムの要件を受け付ける入力手段と、前記システムの構成要素を冗長化しながら具体化するパタ－ンを定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成する構成生成手段と、を備える。
【選択図】図１
【特許請求の範囲】
【請求項1】
冗長化の要求を含むシステムの要件を受け付ける入力手段と、
前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成する構成生成手段と、
を備えるシステム自動設計装置。
前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成する構成生成手段と、
を備えるシステム自動設計装置。
【請求項2】
前記システムの要件は、前記構成要素の冗長度合いを示すパラメータを含み、
構成生成手段は、前記パラメータの値に応じて具体化パターンを選択することで、冗長度の異なる複数の前記システム構成案を生成する、
請求項１に記載のシステム自動設計装置。
構成生成手段は、前記パラメータの値に応じて具体化パターンを選択することで、冗長度の異なる複数の前記システム構成案を生成する、
請求項１に記載のシステム自動設計装置。
【請求項3】
構成生成手段は、前記冗長度合いを示すパラメータが２以上の構成部品を、
前記冗長度合いを示すパラメータの数だけ、自身と同じ型の構成部品を複数生成することで具体化する、
請求項２に記載のシステム自動設計装置。
前記冗長度合いを示すパラメータの数だけ、自身と同じ型の構成部品を複数生成することで具体化する、
請求項２に記載のシステム自動設計装置。
【請求項4】
前記構成生成手段は、前記冗長度合いを示すパラメータが２以上の関係性に対して、
前記関係性を具体化する際に両端の構成部品を仲介する構成部品が存在しない場合は、前記両端の構成部品間を互いに各n本の関係性で接続する構成に具体化し、
前記関係性を具体化する際に両端の構成部品を仲介する構成部品が存在する場合は、片側の構成部品と仲介するn個の構成部品が互いに各1本の関係性で接続され、かつもう一方の構成部品と仲介する前記n個の構成部品が互いに各１本の関係性で接続された構成に具体化する、
請求項２又は請求項３に記載のシステム自動設計装置。
前記関係性を具体化する際に両端の構成部品を仲介する構成部品が存在しない場合は、前記両端の構成部品間を互いに各n本の関係性で接続する構成に具体化し、
前記関係性を具体化する際に両端の構成部品を仲介する構成部品が存在する場合は、片側の構成部品と仲介するn個の構成部品が互いに各1本の関係性で接続され、かつもう一方の構成部品と仲介する前記n個の構成部品が互いに各１本の関係性で接続された構成に具体化する、
請求項２又は請求項３に記載のシステム自動設計装置。
【請求項5】
前記構成生成手段は、前記構成要素の前記具体化パターンとして、前記構成要素自身を、可用性をもつ構成要素に具体化することで耐障害性を向上させる具体化パターンと、前記構成要素を複数用意して冗長化させることで耐障害性を向上させる具体化パターンと、を生成し、生成した前記具体化パターンから選択して前記システム構成案を生成する、
請求項１又は請求項２に記載のシステム自動設計装置。
請求項１又は請求項２に記載のシステム自動設計装置。
【請求項6】
耐障害性要件が設定された前記構成要素を含む、具体化途中もしくは具体化が完了したシステム構成に対して、前記耐障害性要件が設定された前記構成要素が、前記耐障害性要件を満たしうるか否かを検証する耐障害性検証手段、をさらに備え、
前記構成生成手段は、前記耐障害性要件を満たす前記システム構成案を選択する、
請求項１又は請求項２に記載のシステム自動設計装置。
前記構成生成手段は、前記耐障害性要件を満たす前記システム構成案を選択する、
請求項１又は請求項２に記載のシステム自動設計装置。
【請求項7】
前記耐障害性検証手段は、前記構成要素が前記耐障害性要件を満たしうるか否かを検証する際に、当該構成要素が、自身と異なる１種類より多くの前記構成要素の集合で構成される構成要素である複合属性を有するか、１種類のみの前記構成要素である原始属性を有するか、および、その構成要素が１個のみ存在する前記構成要素である単数属性を有するか、２個以上存在する可能性がある前記構成要素である複数属性を有するか、に基づいて判定する、
請求項６に記載のシステム自動設計装置。
請求項６に記載のシステム自動設計装置。
【請求項8】
前記構成要素が前記耐障害性要件を満たしうるか否かを前記構成要素の属性に応じて判定する基準として、前記構成要素が前記複数属性をもつ構成要素であれば、前記構成要素の数が前記耐障害性要件の数以上であり、かつ、前記構成要素が直接および間接的に依存する前記構成要素の集合が互いに疎であること、前記構成要素が前記複合属性かつ前記単数属性をもつ構成要素であれば、前記構成要素が直接的に依存するすべての前記構成要素が前記耐障害性要件を満たしていること、前記構成要素が前記原始属性かつ前記単数属性を持つ構成要素であれば、指定された前記耐障害性要件が０であること、を判定基準とする、
請求項７に記載のシステム自動設計装置。
請求項７に記載のシステム自動設計装置。
【請求項9】
前記構成要素が耐障害性要件を満たしうるか否かの検証を、具体化途中のシステム構成も対象に含め、任意のタイミングで実行すること、を特徴とする、
請求項１又は請求項２に記載のシステム自動設計装置。
請求項１又は請求項２に記載のシステム自動設計装置。
【請求項10】
冗長化の要求を含むシステムの要件を受け付けるステップと、
前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成するステップと、
を有するシステム自動設計方法。
前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成するステップと、
を有するシステム自動設計方法。
【請求項11】
コンピュータに、
冗長化の要求を含むシステムの要件を受け付けるステップと、
前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成するステップと、
を実行させるプログラム。
冗長化の要求を含むシステムの要件を受け付けるステップと、
前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成するステップと、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、冗長構成の設計を可能とするシステム自動設計装置、システム自動設計方法、およびプログラムに関する。
【背景技術】
【0002】
ＩＴ（Information Technology）機器やＩＴサービス、ネットワークの多様化に伴い、それらを組み合わせて構築されるシステムも多様化・大規模化しており、システムに対する要件（システム要件）を満たすシステム構成を設計する自動設計技術の重要性が高まっている。システム要件の中でも重要な要件の一つに可用性要件が存在する。可用性要件とは、システムを構成するある機能に、外部要因による障害等が発生してもシステムを停止せずに稼働し続けられる性質に関する要件である。たとえば、ある“機能Ａ”が依存する構成要素のうちの幾つかが停止しても、その機能Ａが停止せずに稼働し続ける場合に、機能Ａを停止させることなく停止可能な構成要素の数が可用性要件の指標として用いられることがある。
【0003】
システムを構成する構成要素、およびそれらの接続関係の種類は多種多様であり、それらを組み合わせて構築されるシステムの構成の種類は膨大なものとなるため、人手でそれらのシステムを設計することには限界がある。特許文献1および非特許文献１で示されるシステム構成の自動設計技術では、ユーザが要求する機能要件と非機能要件から、それらを満たす具体的なシステム構成を自動で設計する。これらの文献に開示された技術では、システムの構成要素ごとに、その構成要素の具体化の方法を表現した情報（以降、具体化パターンと称する）を事前に定義し、その具体化パターンの任意の組み合わせにより様々なシステム構成の案を生成すると共に、生成した構成案の中から適切なものを探索することによりシステムを自動的に設計可能としている。また、具体化パターンに加えて、システムの各構成要素自身もしくはその周辺の構成要素が満たすべき条件を定義することにより、条件に合わない構成案を直ちに棄却して探索範囲を制限することで、設計を効率化している。しかし、上記の文献には、冗長化されたシステム構成を設計するために作成すべき具体化モデルの詳細な説明や、設計されたシステムの冗長性を判断する基準などは述べられておらず、あくまで様々なシステム要件を満たすシステム構成を自動設計するためのフレームワークに関する説明にとどまっている。また、特許文献２には、ネットワークの冗長構成を設計する技術が開示されている。しかし、特許文献２の技術は、ネットワークの冗長化に限定したものある。したがって、特許文献１、２および非特許文献１の技術により冗長化されたシステム構成を自動設計することは難しい。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】国際公開第２０１９／２１６０８２号
【特許文献2】特開２０１９－１６１２７９号公報
【非特許文献】
【0005】
【非特許文献1】Takuya KUWAHARA, Takayuki KURODA, Takao OSAKI, Kozo SATOD, “An Intent-Based System Configuration Design for IT/NW Services with Functional and Quantitative Constraints”, IEICE Transactions on Communications Vol.E104-B, No.7, pp.791-804, 2021
【発明の概要】
【発明が解決しようとする課題】
【0006】
冗長化されたシステム構成を自動設計する技術が必要である。
【0007】
そこでこの発明は、上述の課題を解決する冗長構成の設計を可能とするシステム自動設計装置、システム自動設計方法、およびプログラムを提供することを目的としている。
【課題を解決するための手段】
【0008】
本発明の一態様によれば、システム自動設計装置は、冗長化の要求を含むシステムの要件を受け付ける入力手段と、前記システムの構成要素を冗長化しながら具体化するパタ－ンを定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成する構成生成手段と、を備える。
【0009】
本発明の一態様によれば、システム自動設計方法は、冗長化の要求を含むシステムの要件を受け付けるステップと、前記システムの構成要素を冗長化しながら具体化するパタ－ンを定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成するステップと、を有する。
【0010】
本発明の一態様によれば、プログラムは、コンピュータに、冗長化の要求を含むシステムの要件を受け付けるステップと、前記システムの構成要素を冗長化しながら具体化するパタ－ンを定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成するステップと、を実行させる。
【発明の効果】
【0011】
本発明によれば、冗長化されたシステムの構成を自動設計することができる。
【図面の簡単な説明】
【0012】
【図1】第１の実施形態に係るシステム自動設計装置の構成を示すブロック図である。
【図2】第１の実施形態に係る構成情報の図による表現の一例を示す図である。
【図3】第１の実施形態に係る構成情報のテキストによる表現の一例を示す図である。
【図4】第１の実施形態に係る構成要素の定義フォーマットの一例を示す図である。
【図5A】第１の実施形態に係る構成部品の定義の一例を示す第１の図である。
【図5B】第１の実施形態に係る構成部品の定義の一例を示す第２の図である。
【図5C】第１の実施形態に係る構成部品の定義の一例を示す第３の図である。
【図6A】第１の実施形態に係る構成部品間の関係性の定義の一例を示す第１の図である。
【図6B】第１の実施形態に係る構成部品間の関係性の定義の一例を示す第２の図である。
【図6C】第１の実施形態に係る構成部品間の関係性の定義の一例を示す第３の図である。
【図7A】第１の実施形態に係るシステム構成の具体化の一例を示す第１の図である。
【図7B】第１の実施形態に係るシステム構成の具体化の一例を示す第２の図である。
【図7C】第１の実施形態に係るシステム構成の具体化の一例を示す第３の図である。
【図8A】第１の実施形態に係る構成要素自身の可用性をもつ構成要素への具体化の一例を示す第１の図である。
【図8B】第１の実施形態に係る構成要素自身の可用性をもつ構成要素への具体化の一例を示す第２の図である。
【図9】第１の実施形態に係る構成部品を冗長化して具体化する一例を示す図である。
【図10A】第１の実施形態に係る構成部品間の関係性を冗長化して具体化する一例を示す第１の図である。
【図10B】第１の実施形態に係る構成部品間の関係性を冗長化して具体化する一例を示す第２の図である。
【図10C】第１の実施形態に係る構成部品間の関係性を冗長化して具体化する一例を示す第３の図である。
【図10D】第１の実施形態に係る構成部品間の関係性を冗長化して具体化する一例を示す第４の図である。
【図10E】第１の実施形態に係る構成部品間の関係性を冗長化して具体化する一例を示す第５の図である。
【図11A】第１の実施形態に係る冗長構成を設計するための構成部品の一定義例を示す第１の図である。
【図11B】第１の実施形態に係る冗長構成を設計するための構成部品の一定義例を示す第２の図である。
【図11C】第１の実施形態に係る冗長構成を設計するための構成部品の一定義例を示す第３の図である。
【図11D】第１の実施形態に係る冗長構成を設計するための構成部品の一定義例を示す第４の図である。
【図12A】第１の実施形態に係る冗長構成を設計するための構成部品間の関係性の一定義例を示す第１の図である。
【図12B】第１の実施形態に係る冗長構成を設計するための構成部品間の関係性の一定義例を示す第２の図である。
【図12C】第１の実施形態に係る冗長構成を設計するための構成部品間の関係性の一定義例を示す第３の図である。
【図12D】第１の実施形態に係る冗長構成を設計するための構成部品間の関係性の一定義例を示す第４の図である。
【図12E】第１の実施形態に係る冗長構成を設計するための構成部品間の関係性の一定義例を示す第５の図である。
【図12F】第１の実施形態に係る冗長構成を設計するための構成部品間の関係性の一定義例を示す第６の図である。
【図12G】第１の実施形態に係る冗長構成を設計するための構成部品間の関係性の一定義例を示す第７の図である。
【図13A】第１の実施形態に係るquantityの値に基づくシステム構成の具体化の一例を示す第１の図である。
【図13B】第１の実施形態に係るquantityの値に基づくシステム構成の具体化の一例を示す第２の図である。
【図13C】第１の実施形態に係るquantityの値に基づくシステム構成の具体化の一例を示す第３の図である。
【図13D】第１の実施形態に係るquantityの値に基づくシステム構成の具体化の一例を示す第４の図である。
【図13E】第１の実施形態に係るquantityの値に基づくシステム構成の具体化の一例を示す第５の図である。
【図14】第１の実施形態に係るシステム自動設計の動作を示すフローチャートである。
【図15A】第１の実施形態に係るquantityの値に基づく構成要素の具体化処理の動作を示す第１のフローチャートである。
【図15B】第１の実施形態に係るquantityの値に基づく構成要素の具体化処理の動作を示す第２のフローチャートである。
【図16】第２の実施形態に係るシステム自動設計装置の構成を示すブロック図である。
【図17】第２の実施形態に係る構成要素の属性に応じた耐障害性制約条件を示す図である。
【図18A】第２の実施形態に係る複合属性かつ単数属性をもつ構成要素の耐障害性制約条件の一例を示す第１の図である。
【図18B】第２の実施形態に係る複合属性かつ単数属性をもつ構成要素の耐障害性制約条件の一例を示す第２の図である。
【図19A】第２の実施形態に係る複数属性をもつ構成要素の耐障害性制約条件の一例を示す第１の図である。
【図19B】第２の実施形態に係る複数属性をもつ構成要素の耐障害性制約条件の一例を示す第２の図である。
【図20】第２の実施形態に係る定式化した耐障害性制約条件を示す図である。
【図21A】第２の実施形態に係る耐障害性制約条件を生成するために追加する構成要素の定義例を示す第１の図である。
【図21B】第２の実施形態に係る耐障害性制約条件を生成するために追加する構成要素の定義例を示す第２の図である。
【図21C】第２の実施形態に係る耐障害性制約条件を生成するために追加する構成要素の定義例を示す第３の図である。
【図22A】第２の実施形態に係る多様な冗長構成のシステムの一設計例を示す第１の図である。
【図22B】第２の実施形態に係る多様な冗長構成のシステムの一設計例を示す第２の図である。
【図22C】第２の実施形態に係る多様な冗長構成のシステムの一設計例を示す第３の図である。
【図22D】第２の実施形態に係る多様な冗長構成のシステムの一設計例を示す第４の図である。
【図23】第２の実施形態に係るシステム自動設計の動作を示すフローチャートである。
【図24】第３の実施形態に係るシステム自動設計装置の構成を示すブロック図である。
【図25】第３の実施形態に係るシステム自動設計の動作を示すフローチャートである。
【図26】最小構成を有するシステム自動設計の構成を示すブロック図である。
【図27】最小構成を有するシステム自動設計の動作を示すフローチャートである。
【発明を実施するための形態】
【0013】
以下、本発明の各実施形態に係るシステム自動設計装置について図面を参照して説明する。以下の説明に用いる図面において本発明に関係ない部分の構成については、記載を省略し、図示しない場合がある。
【0014】
＜第１の実施形態＞
（構成）
図１は、第１の実施形態に係るシステム自動設計装置の構成を示すブロック図である。
図１に示すように、システム自動設計装置９００は、入出力部１００と、構成具体化部２００と、具体化構成案生成部３００と設計情報記録部４００と、制約検証部５００と、を有する。
入出力部１００は、システムに期待する構成や機能、性能などのシステム要件を入力として受け付け、構成具体化部２００へ出力する。入出力部１００は、構成具体化部２００から、受け付けたシステム要件を満たすシステム構成情報を受け取り、表示装置や電子ファイルなどに出力する。ここで、構成具体化部２００から、システム要件を満たすシステム構成情報を受け取れなかった場合は、入出力部１００は、システム要件を満たすシステム構成の設計ができなかった旨を出力する。
（構成）
図１は、第１の実施形態に係るシステム自動設計装置の構成を示すブロック図である。
図１に示すように、システム自動設計装置９００は、入出力部１００と、構成具体化部２００と、具体化構成案生成部３００と設計情報記録部４００と、制約検証部５００と、を有する。
入出力部１００は、システムに期待する構成や機能、性能などのシステム要件を入力として受け付け、構成具体化部２００へ出力する。入出力部１００は、構成具体化部２００から、受け付けたシステム要件を満たすシステム構成情報を受け取り、表示装置や電子ファイルなどに出力する。ここで、構成具体化部２００から、システム要件を満たすシステム構成情報を受け取れなかった場合は、入出力部１００は、システム要件を満たすシステム構成の設計ができなかった旨を出力する。
【0015】
構成具体化部２００は、入出力部１００からシステム要件を受け付け、設計情報記録部４００からシステムの構成要素と具体化の方法に関する情報を取得し、システム要件を満たすシステム構成を導出する。構成具体化部２００は、あるシステム要件もしくはシステム構成に対して具体化モデルを適用することで段階的にシステム構成を具体化する。また、構成具体化部２００は、設計中のシステム構成に含まれる制約条件を制約検証部５００に出力するとともに、設計中のシステム構成が制約条件を満たすか否かの検証結果を制約検証部５００から取得する。構成具体化部２００は、制約条件を満たすシステム構成に限定してシステム構成の具体化を進める。さらに、構成具体化部２００は、作成したシステムの構成情報もしくはシステムの設計に失敗した旨の情報を入出力部１００に出力する。
【0016】
具体化構成案生成部３００は、各構成要素を具体化する構成案を生成し、設計情報記録部４００へ出力する。具体化構成案生成部３００は、冗長構成案生成部３１０と、非冗長構成案生成部３２０を有する。冗長構成案生成部３１０は、構成要素を冗長化しながら具体化する構成案を生成する。非冗長構成案生成部３２０は、構成要素の冗長化は考慮せずに具体化する構成案を生成する。具体化構成案生成部３００は、各構成要素を具体化する構成案の情報を、設計情報記録部４００を介さずに直接、構成具体化部２００へ提供してもよい。すなわち、構成具体化部２００は、具体化構成案生成部３００から、構成要素の具体化に関する情報を取得して、システム構成の具体化を実行してもよい。
【0017】
設計情報記録部４００は、システムの構成情報として構成要素と具体化の方法に関する情報を具体化構成案生成部３００から受信して記憶し、構成具体化部２００からの要求に応じて、前記構成要素と前記具体化の方法に関する情報を構成具体化部２００へ出力する。設計情報記録部４００は、例えば、ＨＨＤやメモリなどの記録媒体で構成される。
【0018】
制約検証部５００は、構成具体化部２００からシステム構成が満たすべき制約条件を取得し、それらの制約条件が矛盾するか否かを検証する。制約検証部５００は、検証結果を構成具体化部２００に出力する。ここで、制約検証部５００は、具体化が完了したシステム構成に対してだけでなく、設計中のシステム構成に対して検証を行うことができる。たとえば、構成具体化部２００は、設計途中のシステム構成に対して具体化モデルを一つ適用するごとに、制約検証部５００にて制約条件の検証を行ってもよい。
【0019】
（構成情報について）
続いて、システム自動設計装置９００で扱うデータについて説明する。システム自動設計装置９００が扱うデータは、主に“システム要件”と“システム構成”である。“システム要件”は、システム設計を行う利用者がシステムに期待する要件として入力する情報であり、システムの構成や満たすべき機能要件および非機能要件を表す情報を含む。“システム構成”は、構成具体化部２００で設計中のシステムの構成情報又はシステム自動設計装置９００で最終的に出力される具体化されたシステムの構成情報である。
続いて、システム自動設計装置９００で扱うデータについて説明する。システム自動設計装置９００が扱うデータは、主に“システム要件”と“システム構成”である。“システム要件”は、システム設計を行う利用者がシステムに期待する要件として入力する情報であり、システムの構成や満たすべき機能要件および非機能要件を表す情報を含む。“システム構成”は、構成具体化部２００で設計中のシステムの構成情報又はシステム自動設計装置９００で最終的に出力される具体化されたシステムの構成情報である。
【0020】
システム要件およびシステム構成は、ノードとエッジで表現される。ノードはシステムを構成する構成部品、エッジは構成部品間の関係性を表し、構成部品とその関係性を総称して構成要素と呼ぶ。以降、単に”関係性”と表記した場合は構成部品間の関係性を表す。構成要素には、その構成要素の特徴を表す任意の情報を設定することができる。ノードおよびエッジには、さらに、自身もしくは周辺の構成要素が満たすべき条件を制約条件として設定できる。図２に、システム構成をノードとエッジで表現した図の一例を示す。
【0021】
図２は、第１の実施形態に係る構成情報の図による表現の一例を示す図である。
図２の丸はノードを示しており、丸をつなぐ矢印はエッジを示している。ノードおよびエッジに添えられた名前はそれぞれ構成部品および関係性の型名を示す。点線は、抽象的な構成要素、実線は具体的な構成要素を示している。たとえば、図２は、具体的なアプリケーションYとなんらかのアプリケーションが通信できることを示す構成情報であり、ノードとエッジを用いて「AppとApp_YがConn_toの関係性で接続されている」ことを表現している。Appは何らかのアプリケーションを表す抽象的なノードであるため、この時点では点線で表示されており、システム構成の具体化過程において、具体的なアプリケーションに具体化されていく。
図２の丸はノードを示しており、丸をつなぐ矢印はエッジを示している。ノードおよびエッジに添えられた名前はそれぞれ構成部品および関係性の型名を示す。点線は、抽象的な構成要素、実線は具体的な構成要素を示している。たとえば、図２は、具体的なアプリケーションYとなんらかのアプリケーションが通信できることを示す構成情報であり、ノードとエッジを用いて「AppとApp_YがConn_toの関係性で接続されている」ことを表現している。Appは何らかのアプリケーションを表す抽象的なノードであるため、この時点では点線で表示されており、システム構成の具体化過程において、具体的なアプリケーションに具体化されていく。
【0022】
図２に示す構成情報は、図による表現だけでなく、テキストで表現されていてもよい。テキストでの表現方法は、一意に相当する図に変換できるのであれば特に限定しないが、その一例を図３に示す。テキスト形式での構成情報は、構成部品と構成部品間の関係性のリストからなり、各構成部品にはその構成部品を識別する識別子とその構成部品の型が定義される。各関係性には、その関係性を識別する識別子とその関係性の型、および、関係性の接続元と接続先の構成部品の識別子が定義される。図３における”＄”はその変数名の識別子を参照することを示す。構成要素の他の定義部分で参照されることがないなどの理由により、ある構成要素の識別子の定義が不要の場合は、識別子の定義を省略してもよい。
【0023】
（構成要素の定義）
続いて、構成要素の定義方法について説明する。構成要素を定義するためのフォーマットを図４に示す。構成要素には、その構成要素の型名、継承元、具体性、プロパティという、その構成要素の特徴を表す情報と、その構成要素がシステム構成内に存在するために、自身の周辺に期待する構成情報を指定できる。以降、ある構成要素が成り立つために、自身の周辺に期待する構成情報を”期待周辺構成”と記載する。
継承元は、その構成要素が継承する他の構成要素の型を表し、指定がない場合は何も継承していないことを表す。構成部品は他の構成部品の型を、関係性は他の関係性の型を継承することで、継承元の型のプロパティや期待周辺構成の情報を継承できる。
具体性は、その構成要素自身が、さらに具体化されうる抽象的な構成要素であるか、それ以上具体化されない具体的な構成要素であるかを表すフラグであり、trueの場合は具体的な構成要素であることを表す。
プロパティはその構成要素の特性を表す属性情報であり、構成要素の種類に応じて任意の属性情報を指定できる。
続いて、構成要素の定義方法について説明する。構成要素を定義するためのフォーマットを図４に示す。構成要素には、その構成要素の型名、継承元、具体性、プロパティという、その構成要素の特徴を表す情報と、その構成要素がシステム構成内に存在するために、自身の周辺に期待する構成情報を指定できる。以降、ある構成要素が成り立つために、自身の周辺に期待する構成情報を”期待周辺構成”と記載する。
継承元は、その構成要素が継承する他の構成要素の型を表し、指定がない場合は何も継承していないことを表す。構成部品は他の構成部品の型を、関係性は他の関係性の型を継承することで、継承元の型のプロパティや期待周辺構成の情報を継承できる。
具体性は、その構成要素自身が、さらに具体化されうる抽象的な構成要素であるか、それ以上具体化されない具体的な構成要素であるかを表すフラグであり、trueの場合は具体的な構成要素であることを表す。
プロパティはその構成要素の特性を表す属性情報であり、構成要素の種類に応じて任意の属性情報を指定できる。
【0024】
期待周辺構成は、その構成要素が成り立つために、自身の周辺で満たされるべき構成情報を表し、ここに記載された構成が存在することで、この構成要素が成り立つことを表す。たとえば、何らかのアプリケーションが存在するためには、それをホストするOSが必須であると考えられるため、App型の構成部品の期待周辺構成に、App自身が何らかのOS型の構成部品にホストされるという構成情報を記載する。一つの構成要素に対して期待周辺構成は複数定義可能である。
【0025】
個々の期待周辺構成には、その期待周辺構成の名前と、前提構成情報、必須構成情報および制約条件を記述できる。前提構成情報とは、後述する必須構成情報を満たすように具体化する前提となる構成情報であり、設計途中のシステム構成が、前提構成情報に記載された構成情報を満たしている場合に、後述する必須構成情報を適用してシステム構成を具体化することを表す。必須構成情報は、その構成要素をどのような構成に具体化するかを意味する具体化パターンを表す情報であり、ここに記載された構成情報をシステム構成に追加することで、システム構成を一段階具体化することを表す。制約条件は、前記必須構成情報に記載された構成情報でシステム構成を具体化する際に、各構成要素が満たすべき制約条件を記述する。
【0026】
入力されたシステム要件に基づいてシステム構成を具体化していく処理とは具体的には、各構成要素自身を具体的な構成要素に具体化していく処理と、各構成要素に定義された期待周辺構成を満たすようにシステム構成を具体化していく二つの処理から成り立っており、システム構成内のすべての構成要素に対して前記二つの処理が完了した時点でシステム設計が完了したとする。すなわち、システム構成内のすべての構成要素の具体性がtrueかつ、すべての構成要素の期待周辺構成が満たされている場合に、システム構成の設計が完了したと判断する。一つの構成要素に複数の期待周辺構成が定義されている場合は、それらのうちいずれか一つの期待周辺構成が満たされていればよいものとする。
【0027】
また、ある構成要素の期待周辺構成をみたすようにシステムの具体化を行う際、必須構成情報に記載された構成要素の全部もしくは一部がすでにシステム構成内に存在している場合、既存の構成要素を利用するような構成に具体化してもよいし、新たに構成要素を作成する構成に具体化してもよい。たとえば、App型の構成部品の期待周辺構成に、App自身が何らかのOS型の構成部品にホストされるという構成情報が記載されていた場合、このAppの期待周辺構成を満たすためにシステム構成に新たなOSを追加してもよいし、もしすでに他のAppがホストされているOSがシステム構成内に存在する場合などは、新たなOSは追加せずに既存のOSにホストされる構成に具体化してもよい。このように、期待周辺構成を満たすように具体化する際に、ある構成要素を使い回す構成に具体化するか、新たに追加する構成に具体化するかは任意に選択できる。
【0028】
以降では、構成部品と構成部品間の関係性の定義例を示す。はじめに、図５Ａ～図５Ｃに、アプリケーション、OS、マシン、およびネットワーク機器に関連する構成部品の定義例を示す。図５ＡのAppはアプリケーションを表す構成部品であり、自身はさらに具体的な何らかのアプリケーションに具体化されうる（この例では、App_XもしくはApp_Yに具体化されうる）抽象的なアプリケーションであるため具体性をfalseに設定している。さらに、”アプリケーションが成立するためにはOS上にそのアプリケーションがホストされている必要がある”ことを表すために、”App_is_hosted_on_Windows_OS”と”App_is_hosted_on_Ubuntu_OS”の2種類の期待周辺構成を定義している。この2種類の期待周辺構成の違いは、ホスト元のOSの種類として、Windows（登録商標） OS上にホストされる構成（App_is_hosted_on_Windows_OS）か、Ubuntu（登録商標） OS上にホストされる構成(App_is_hosted_on_Ubuntu_OS)か、である。App_is_hosted_on_Windows_OS構成では、Appが成り立つためには、Windows（登録商標）型の構成部品が必要であり、App自身とWindows（登録商標）間にHosted_onの関係性が成り立っている必要があることを定義している。App_is_hosted_on_Ubuntu_OS構成もほぼ同様であるが、Appがホストされる構成部品の型がWindows（登録商標）ではなくUbuntu（登録商標）である部分のみ異なる。このAppを継承する形で、具体的なアプリケーションを表すApp_XとApp_Yの構成部品を定義している。Appを継承することで、Appで定義されたプロパティや期待周辺構成を継承している。
【0029】
図５ＢのOSはオペレーティングシステムを表す抽象的な構成部品であり、プロパティとしてOSが使用するメモリ量を指定するrequired_memoryを保持する。ただし、OS型の構成部品は抽象的なOSであるため、具体的な値は設定されていない。OSは、自身が成り立つためには何らかのMachine上にホストされている必要があるため、OS自身とMachine間にHosted_onの関係性が成り立っている必要があることを期待周辺構成として定義している。さらに、期待周辺構成が適用される際の制約条件として、ホスト元のMachineが搭載するメモリ量が、OS自身が必要とするメモリ使用量以上であることを定義している。また、Appと同様に、OSを継承する形で具体的なOSであるWindows（登録商標）とUbuntu（登録商標）型の構成部品を定義し、具体的なメモリ使用量の値を設定している。
【0030】
図５ＣのMachineはなんらかのマシンを表す抽象的な構成部品であり、プロパティとしてMachineが搭載するメモリ量を指定するmemoryを保持する。さらに、Machineを継承する形で一般的な物理サーバを表すPhysical_Server型の構成部品を定義し、具体的な搭載メモリ量を指定している。Switchはネットワーク機器のスイッチを表す具体的な構成部品を表す。
【0031】
続いて図６Ａ～図６Ｃに、図５Ａ～図５Ｃで定義した構成部品間の関係性の定義例を示す。図６ＡのHosted_onはある構成部品が別の構成部品にホストされていることを表す関係性であり、AppがOS上にホストされることを表すHosted_on(App, OS)と、OSがMachine上にホストされることを表すHosted_on(OS, Machine)の２つを定義している。Hosted_onの関係性は具体的な関係性であり、プロパティや期待周辺構成は存在しないものとして定義している。
【0032】
図６Ｂ、図６ＣのConn_toは2つの構成部品間が論理的もしくは物理的に接続関係にあることを表す関係性であり、App間の接続関係Conn_to(App, App)とMachine間の接続関係Conn_to(Machine, Machine)と、MachineとSwitch間の接続関係Conn_to(Machine, Switch)およびConn_to(Switch, Machine)の４つを定義している。図６ＣのConn_to(App, App)では、期待周辺構成として、両端のAppを間接的にホストするMachine間がConn_toで接続される構成を定義している。これは、アプリケーション同士が通信するためには、それをホストするマシン同士が通信できる必要があることを表しており、具体的な定義方法は、期待周辺構成が適用される前提となる前提構成情報として、Conn_to(App, App)の接続元および接続先両方のApp型の構成部品がそれぞれOS型の構成部品にホストされており、かつ、そのOS型の構成部品がそれぞれMachine型の構成部品にホストされている構成を定義している。そのうえで、前提構成情報で定義された構成を満たす場合に、前記Machine間をConn_to型の関係性で接続することを必須構成情報として定義している。図６ＢのConn_to(Machine, Machine)では、期待周辺構成として、Switch型の構成部品を経由して互いに接続される構成を定義している。具体的には、Conn_to(Machine, Machine)の両端のMachine型の構成部品がSwitch型の構成部品とConn_toで接続される構成を定義している。図６ＢのConn_to(Machine, Switch)とConn_to(Switch, Machine)は周辺に期待する構成をもたないため、期待周辺構成は存在せず何も定義していない。
【0033】
図７Ａ～図７Ｃに、図５Ａ～図５Ｃおよび図６Ａ～図６Ｃで定義した構成部品および構成部品間の関係性用いたシステム構成の具体化の例を示す。図７Ａ～図７Ｃのエッジ名については、その両端のノードの型名は省略している。App_XとApp_Yが通信できる(Conn_toで接続)ことを表すシステム構成がシステム要件として与えられたものとして自動設計を開始し（図７ＡのS1）、App_Xの定義に基づき、App_Xの期待周辺構成を満たすようにWindows（登録商標）を作成することでシステム構成を一段階具体化する（図７ＡのS2）。同様に、App_Yの定義に基づき、App_YをホストするUbuntu（登録商標）を作成することでシステム構成が具体化される（図７ＡのS3）。その後、Windows（登録商標）とUbuntu（登録商標）それぞれの期待周辺構成として抽象的なMachineが具体化され（図７ＢのS4）、それぞれの抽象的なMachineが具体的なPhysical_Serverに具体化される（図７ＢのS5）。この時点で、App_XとApp_Y間のConn_toの期待周辺構成として定義された前提構成情報を満たす構成になったため、App_XとApp_Yそれぞれを間接的にホストするPhysical_Server間にConn_toを作成することでシステム構成を具体化する（図７ＣのS6）。最後に、Physical_Server間のConn_toの期待周辺構成として、新たにSwitchを作成し、各Physical_ServerとSwitchをConn_toで接続する（図７ＣのS7）。この時点で、システム構成内のすべての構成部品の具体性がtrue、かつ、すべての構成要素が期待周辺構成を満たす構成となったため、ここでシステム構成の具体化を完了する。
【0034】
ここで、システム構成の具体化は、必ずしも図７Ａ～図７Ｃに示す順番で具体化が実行される必要はなく、ある構成要素に対して適用できる具体化パターンが複数存在する場合は、そのどれを適用しても問題ない。例えば、図７ＡのS1の構成からS2の構成に具体化されるパターンだけでなく、S1の構成から先にApp_YをホストするUbuntu（登録商標）が作成されることでシステム構成が具体化されても構わない。また、適用できる具体化パターンが複数ある場合にどの具体化パターンを適用するかは、ランダムに一つを選択してもよいし、機械学習等の他の技術によって決定してもよい。例えば、具体化構成案生成部３００は、構成部品を具体化する方法を定めた具体化パターンを冗長化無しの場合と冗長化有りの場合のそれぞれについて、複数有していて、図５Ａ～図５Ｃ、図６Ａ～図６Ｃ等に例示した定義情報に基づいて、システム要求に応じた具体化パターンを選択して組み合わせることにより、システム構成案を生成する。冗長化有りの場合の具体化パターンについては以下に説明する。
【0035】
（冗長構成を設計するためのモデル）
続いて、冗長化されたシステム構成を自動設計するための具体化モデルについて説明する。これまでに説明した構成要素の定義だけでは、基本的なシステム構成は設計可能だが、本発明の目的である冗長化されたシステム構成を設計するには不十分である。そのため、自動設計においてある構成要素を冗長化しながら具体化する機能が必要である。冗長化されたシステム構成を自動設計するために、各構成要素に新たに、数と可用性の有無に関する属性情報を取り入れる。具体的には、“quantity”と“available”の二つのプロパティを追加する。quantityはその構成要素の数を表す属性情報である。quantityの値が1の構成要素は、その構成要素が１個のみ存在することを表し、本発明ではそのような構成要素を、「単数属性をもつ」と表現する。一方quantityの値が２以上の場合、その型の構成要素が２個以上存在することを概念的に１つの構成要素で表現しており、本発明ではそのような構成要素を、「複数属性をもつ」と表現する。ただし、システム構成の具体化の過程において数が未定の構成要素は、それ以降の具体化の過程で２個以上に具体化される可能性があることから複数属性をもつ構成要素と考える。このquantityの値に応じて構成要素を冗長化しながら具体化することで、冗長構成を設計する。availableはその構成要素自身の可用性を表すプロパティである。availableの値がfalseの場合は、その構成要素単体では可用性を備えない、すなわち、何らかの原因でその構成要素が機能しなくなる可能性があることを表す。一方、availableの値がtrueの場合は、その構成要素自身に可用性が備わっており、何らかの原因でその構成要素が機能しなくなる可能性を考慮する必要がないことを表す。例えば、一般的なアプリケーションやサーバであれば、プログラムに含まれるバグや部品の故障等で機能が停止することが考えられるため、availableの値はfalseと設定する。一方、耐障害性を備えたFT(Fault Tolerant)サーバや、AWS（Amazon Web Services）上のフルマネージドサービスなど、基本的に機能が停止することがない、もしくは設計者の観点で停止することを考慮する必要がないと考えられる構成要素には、availableの値をtrueと設定することが考えられる。このavailableの値に応じて、その構成要素が冗長化されている必要があるか否かを判定する。
続いて、冗長化されたシステム構成を自動設計するための具体化モデルについて説明する。これまでに説明した構成要素の定義だけでは、基本的なシステム構成は設計可能だが、本発明の目的である冗長化されたシステム構成を設計するには不十分である。そのため、自動設計においてある構成要素を冗長化しながら具体化する機能が必要である。冗長化されたシステム構成を自動設計するために、各構成要素に新たに、数と可用性の有無に関する属性情報を取り入れる。具体的には、“quantity”と“available”の二つのプロパティを追加する。quantityはその構成要素の数を表す属性情報である。quantityの値が1の構成要素は、その構成要素が１個のみ存在することを表し、本発明ではそのような構成要素を、「単数属性をもつ」と表現する。一方quantityの値が２以上の場合、その型の構成要素が２個以上存在することを概念的に１つの構成要素で表現しており、本発明ではそのような構成要素を、「複数属性をもつ」と表現する。ただし、システム構成の具体化の過程において数が未定の構成要素は、それ以降の具体化の過程で２個以上に具体化される可能性があることから複数属性をもつ構成要素と考える。このquantityの値に応じて構成要素を冗長化しながら具体化することで、冗長構成を設計する。availableはその構成要素自身の可用性を表すプロパティである。availableの値がfalseの場合は、その構成要素単体では可用性を備えない、すなわち、何らかの原因でその構成要素が機能しなくなる可能性があることを表す。一方、availableの値がtrueの場合は、その構成要素自身に可用性が備わっており、何らかの原因でその構成要素が機能しなくなる可能性を考慮する必要がないことを表す。例えば、一般的なアプリケーションやサーバであれば、プログラムに含まれるバグや部品の故障等で機能が停止することが考えられるため、availableの値はfalseと設定する。一方、耐障害性を備えたFT(Fault Tolerant)サーバや、AWS（Amazon Web Services）上のフルマネージドサービスなど、基本的に機能が停止することがない、もしくは設計者の観点で停止することを考慮する必要がないと考えられる構成要素には、availableの値をtrueと設定することが考えられる。このavailableの値に応じて、その構成要素が冗長化されている必要があるか否かを判定する。
【0036】
続いて、冗長構成を設計するための、各構成要素を冗長化しながら具体化する具体化パターンを定義する。本発明において、構成要素を冗長化しながら具体化する方法（具体化パターン）には、大きく分けて２種類存在する。
【0037】
一つ目は、その構成要素自身を、可用性を有する構成要素に具体化するパターンである。この具体化パターンの例を図８Ａに示す。図８Ａにおいて、図中の吹き出しはその構成要素に設定されたプロパティとその値を表す。図８Ａは、Machineが、可用性を有するFT_Serverに具体化されるパターンを示す。FT_ServerとはFault Tolerant Serverのことであり、サーバ内部が冗長化されており、それ自身が１つでも可用性を有する端末である。ここで、Machineは抽象的な構成部品であり、どのように具体化されるかが決まっていない状態のため、availableの値は設定されていないが、FT_Serverに具体化された時点で、availableの値がtrueに設定される。このパターンの具体化を実現するための具体化モデルの定義は、Machine型の構成部品を継承した具体的な構成部品としてavailableの値がtrueに設定されたFT_Server型の構成部品を定義することで実現する。図８Ｂに示すのは、Machine間のConn_toが、可用性を有するRedundant_conn_toに具体化されるパターンである。Redundant_conn_toはそれ自身が冗長化された可用性を持つ関係性であり、構成部品と同様に、Conn_to型の関係性を継承する形でRedundant_conn_to型の関係性を定義することで実現できる。
【0038】
二つ目は、構成要素を複数作成することで冗長化しながら具体化するパターンである。このパターンの具体化方法は、構成部品と構成部品間の関係性で異なる部分があるため、以降でそれぞれについて説明する。
【0039】
（構成部品を複数作成して具体化することで冗長化するパターン）
構成部品を複数作成することで冗長化しながら具体化するパターンとは具体的には、quantityの値に応じて自身と同じ型の構成部品を複数作成する具体化パターンである。Machine型の構成部品をこのパターンで具体化する例を図９に示す。図９において、quantityに３が設定されているMachineは、３個のMachineを一つにまとめた概念的なMachineを表す構成部品であるため、quantityの値が１であるMachineを３個作成する構成に具体化する。このパターンの具体化を実現するためのモデル定義は、quantityが２以上のMachine型の構成部品の期待周辺構成に、quantityが１のMachine型の構成部品が、そのquantityの値に応じた数だけ存在する構成を定義することで実現する。
構成部品を複数作成することで冗長化しながら具体化するパターンとは具体的には、quantityの値に応じて自身と同じ型の構成部品を複数作成する具体化パターンである。Machine型の構成部品をこのパターンで具体化する例を図９に示す。図９において、quantityに３が設定されているMachineは、３個のMachineを一つにまとめた概念的なMachineを表す構成部品であるため、quantityの値が１であるMachineを３個作成する構成に具体化する。このパターンの具体化を実現するためのモデル定義は、quantityが２以上のMachine型の構成部品の期待周辺構成に、quantityが１のMachine型の構成部品が、そのquantityの値に応じた数だけ存在する構成を定義することで実現する。
【0040】
（構成部品間の関係性を複数作成して具体化することで冗長化するパターン）
続いて、構成部品間の関係性を複数作成することで冗長化しながら具体化するパターンについて説明する。まず初めに、quantityの値がnである関係性とは、その関係性がn重化されている、すなわち、両端の構成部品間にn本の独立した接続関係が存在することを表す。言い換えると、任意のn-1個の接続関係がなくなっても、両端の構成部品間の関係性が維持されることを表している。ただし、quantityの値がnの関係性が具体的にはどのような構成を意味するか、すなわち、最終的にどのような構成に具体化されるべきかは、関係性自身のquantityの値だけではなく、両端の構成部品のquantityの値、および、関係性の具体化の際に両端の構成部品間を仲介する新たな構成部品が存在するか否かによって異なる。仲介する構成部品が存在する場合とは、例えば、Machine間の接続を表す関係性を、その間にSwitchを経由して接続する構成に具体化する場合などが相当する。関係性とその両端の構成部品のquantityの値、および仲介する構成要素の有無に応じて、最終的にどのような構成に具体化されるべきかについて、本発明における定義を図１０Ａ～図１０Ｅに示す。図１０Ａ～図１０Ｅにおいて、ノード名およびエッジ名の横の括弧で囲まれた値はそのノードもしくはエッジのquantityの値を表し、括弧で囲まれた数字の表記がない場合はquantityが1であることを表す。
続いて、構成部品間の関係性を複数作成することで冗長化しながら具体化するパターンについて説明する。まず初めに、quantityの値がnである関係性とは、その関係性がn重化されている、すなわち、両端の構成部品間にn本の独立した接続関係が存在することを表す。言い換えると、任意のn-1個の接続関係がなくなっても、両端の構成部品間の関係性が維持されることを表している。ただし、quantityの値がnの関係性が具体的にはどのような構成を意味するか、すなわち、最終的にどのような構成に具体化されるべきかは、関係性自身のquantityの値だけではなく、両端の構成部品のquantityの値、および、関係性の具体化の際に両端の構成部品間を仲介する新たな構成部品が存在するか否かによって異なる。仲介する構成部品が存在する場合とは、例えば、Machine間の接続を表す関係性を、その間にSwitchを経由して接続する構成に具体化する場合などが相当する。関係性とその両端の構成部品のquantityの値、および仲介する構成要素の有無に応じて、最終的にどのような構成に具体化されるべきかについて、本発明における定義を図１０Ａ～図１０Ｅに示す。図１０Ａ～図１０Ｅにおいて、ノード名およびエッジ名の横の括弧で囲まれた値はそのノードもしくはエッジのquantityの値を表し、括弧で囲まれた数字の表記がない場合はquantityが1であることを表す。
【0041】
はじめに、関係性および両端の構成部品のquantityがすべて１の場合は、関係性を冗長化しながら具体化するパターンが存在しないため説明は省略する。関係性のquantityが１、両端の構成部品のquantityがそれぞれs、t(≧２)の場合、この関係性が意味すると本発明で定義した構成とは、関係性を具体化する際に両端の構成部品を仲介する構成部品が存在しない場合は、両端の構成部品が図９に示す具体化パターンで具体化された結果作成されたs個とt個の構成部品同士が互いに各１本の関係性で接続された構成である。一方、仲介する構成部品が存在する場合に関係性が意味すると定義した構成は、s個とt個の構成部品と、仲介する１個の構成部品が互いに各１本の関係性で接続された構成である。具体例を図１０Ａの(a-1)から(a-3)に示す。(a-1)の構成のようにNodeA(s)とNodeB(t)間のEdgeが意味すると本発明において定義した構成とは、NodeA(s)とNodeB(t)を具体化して作成されたs個のNodeAとt個のNodeB同士が互いに直接各１本のEdgeで接続される構成(a-2)、もしくは、s個のNodeAと１個のNodeCが各1本のEdge1で接続され、かつ、t個のNodeBと1個のNodeCが各１本のEdge2で接続される構成(a-3)である。ここで、NodeCおよびEdge1とEdge2は、Edgeを具体化した結果として新たに作成される構成部品と関係性であり、その具体的な型はEdgeの種類によって決定される。
【0042】
関係性のquantityがn(≧2)、両端の構成要素のquantityがともに１の場合、この関係性が意味すると定義した構成とは、関係性を具体化する際に両端の構成部品間を仲介する構成部品が存在しない場合は、両端の構成部品間が互いにn本の関係性で接続された構成である。一方、仲介する構成部品が存在する場合に関係性が意味すると定義した構成は、両端の構成部品と、n個の仲介する構成部品が互いに各１本の関係性で接続された構成である。具体例を図１０Ｂの(b-1)から(b-3)に示す。図１０Ｂにおいて、“Edge×n”とは、両端の構成部品間にEdge型のエッジがn本存在することを表す。図１０Ｂの(b-1)の構成のようにNodeAとNodeB間のEdge(n)が意味すると定義した構成とは、NodeAとNodeB間がn本のEdgeで接続される構成(b-2)、もしくは、NodeAとn個のNodeCがそれぞれ1本のEdge1で接続され、かつ、NodeBとn個のNodeCがそれぞれ1本のEdge2で接続される構成(b-3)である。
【0043】
関係性のquantityがn(≧2)、両端の構成部品のquantityがそれぞれs、t(≧2)の場合、この関係性が意味すると定義した構成とは、関係性を具体化する際に両端の構成部品を仲介する構成部品が存在しない場合は、両端の構成部品がそれぞれ具体化されて作成されたs個とt個の構成部品同士が各n本の関係性で直接接続された構成である。一方、仲介する構成部品が存在する場合に関係性が意味すると定義した構成は、s個の構成部品と仲介するn個の構成部品が互いに各1本の関係性で接続され、かつ仲介するn個の構成部品とt個の構成部品が互いに各1本の関係性で接続された構成である。具体例を図１０Ｃの(c-1)から(c-3)に示す。(c-1)の構成のようにNodeA(s)とNodeB(t)間のEdge(n)が意味すると定義した構成とは、NodeA(s)とNodeB(t)を具体化して作成されたs個のNodeAとt個のNodeBがそれぞれ直接n本のEdgeで接続される構成(c-2)、もしくは、s個のNodeAとn個のNodeCが互いに各1本のEdge1で接続され、かつ、t個のNodeBとn個のNodeCが互いに各1本のEdge2で接続される構成である(c-3)。
【0044】
最後に、両端の構成部品のうち片方のquantityのみが1の場合の、その構成部品間の関係性が意味すると定義した構成は、両端のquantityが2以上の場合の構成と、両端のquantityが1の場合の構成を組み合わせた構成となる。具体的には、図１０Ｄの(d-1)に示すように関係性のquantityが1、両端の構成部品の片方の構成部品のquantityが1で、もう一方の構成部品のquantityがs(≧2)場合、この関係性が意味すると定義した構成は、両端の構成部品を仲介する構成部品の存在の有無に応じて(d-2)もしくは(d-3)に示す構成となる。また、図１０Ｅの(e-1)に示すように、関係性のquantityがn(≧2)、両端の構成部品の片方の構成部品のquantityが1で、もう一方の構成部品のquantityがs(≧2)場合、その関係性が意味すると定義した構成は、両端の構成部品を仲介する構成部品の存在の有無に応じて(e-2)もしくは(e-3)に示す構成となる。
【0045】
ここで、quantityがn(≧2)の関係性は、その関係性が意味すると本発明で定義した構成に一度に具体化されるのではなく、その関係性をquantityが1のn本の関係性に展開する形で具体化し、新たに作成されたquantityが1のn本の関係性がそれぞれ独自に具体化を行うことで、段階的に具体化されていってもよい。例えば、(b-1)の状態から一度の具体化処理で(b-3)の構成に具体化されるのではなく、(b-2)の構成への具体化を経由して(b-3)の構成に具体化されてもよい。同様に、(c-1)の構成から一度の具体化処理で(c-2)や(c-3)に示す構成に具体化されるのではなく、(c-1)の構成から、NodeA(s)とNodeB(t)間にEdgeがn本張られる構成に一段階具体化されたうえで、個々のEdgeがそれぞれ具体化されることで(c-2)や(c-3)の構成に具体化されてもよい。
【0046】
（冗長化されたシステム構成を設計するための構成要素の定義）
上記で説明したように、quantityの値に応じて具体化することで冗長構成を設計するための、構成部品と構成部品間の関係性の定義例をそれぞれ図１１Ａ～図１１Ｄと図１２Ａ～図１２Ｇに示す。
図１１Ａ～図１１Ｄは構成部品の定義例であり、図５Ａ～図５Ｃの定義をベースにしている。すなわち、太字の部分が冗長構成を設計するために新たに追加された定義箇所であり、図１１Ａ～図１１Ｄに記載のないApp_X, App_Y, Windows（登録商標）, Ubuntu（登録商標）は図５Ａ等から変更はない。最初に、quantityやavailableプロパティはすべての構成部品がもつプロパティのため、すべての構成部品の型の定義内でそれぞれquantityとavailableプロパティを定義してもよいが、図１１Ａ～図１１Ｄでは、全構成部品に共通するプロパティをComponent型の構成部品にまとめて定義し、すべての構成部品が直接もしくは間接的にComponentを継承する方法で記述している。さらに、Countable_Component型として、可算の構成部品すべてが備える期待周辺構成を定義している。具体的には、”For_Multiplexed_Node”という名の期待周辺構成として、図９に示すように、構成部品のquantityが２以上の場合は、quantityの値の数だけ自身と同じ型、かつquantityが１の構成部品を生成し、そのそれぞれとOne_ofの関係性をもつ構成を定義している。One_ofは、quantityが１の構成部品はquantityが２以上の同型の構成部品の１つであるという接続関係を表す関係性であり、そのquantityの値は１であることを制約条件として定義している。図１１Ｂの定義において、foreach(i, $self.quantity)は、自身のquantityの値の数だけ以降の処理を繰り返すことを表し、<i>にはその時のiの値、すなわち、その時の繰り返しの試行回数が挿入される。また、[$self.__type__]とは、Countable_Componentを宣言した構成要素自身の型を表すものとする。各構成要素は、型の定義の際に型名に続いて<Countable_Component>を記載することで自身が可算Componentであることを宣言し、Countable_Componentの期待周辺構成を継承するものとする。
上記で説明したように、quantityの値に応じて具体化することで冗長構成を設計するための、構成部品と構成部品間の関係性の定義例をそれぞれ図１１Ａ～図１１Ｄと図１２Ａ～図１２Ｇに示す。
図１１Ａ～図１１Ｄは構成部品の定義例であり、図５Ａ～図５Ｃの定義をベースにしている。すなわち、太字の部分が冗長構成を設計するために新たに追加された定義箇所であり、図１１Ａ～図１１Ｄに記載のないApp_X, App_Y, Windows（登録商標）, Ubuntu（登録商標）は図５Ａ等から変更はない。最初に、quantityやavailableプロパティはすべての構成部品がもつプロパティのため、すべての構成部品の型の定義内でそれぞれquantityとavailableプロパティを定義してもよいが、図１１Ａ～図１１Ｄでは、全構成部品に共通するプロパティをComponent型の構成部品にまとめて定義し、すべての構成部品が直接もしくは間接的にComponentを継承する方法で記述している。さらに、Countable_Component型として、可算の構成部品すべてが備える期待周辺構成を定義している。具体的には、”For_Multiplexed_Node”という名の期待周辺構成として、図９に示すように、構成部品のquantityが２以上の場合は、quantityの値の数だけ自身と同じ型、かつquantityが１の構成部品を生成し、そのそれぞれとOne_ofの関係性をもつ構成を定義している。One_ofは、quantityが１の構成部品はquantityが２以上の同型の構成部品の１つであるという接続関係を表す関係性であり、そのquantityの値は１であることを制約条件として定義している。図１１Ｂの定義において、foreach(i, $self.quantity)は、自身のquantityの値の数だけ以降の処理を繰り返すことを表し、<i>にはその時のiの値、すなわち、その時の繰り返しの試行回数が挿入される。また、[$self.__type__]とは、Countable_Componentを宣言した構成要素自身の型を表すものとする。各構成要素は、型の定義の際に型名に続いて<Countable_Component>を記載することで自身が可算Componentであることを宣言し、Countable_Componentの期待周辺構成を継承するものとする。
【0047】
図１１ＣのAppは、Countable_Componentであることを宣言し、Component型を継承するとともに、availableにfalseを設定している。これは、アプリケーションにはバグなどが含まれる可能性があるため、アプリケーション自身が単体で可用性を備えないことを意味している。また、Appの期待周辺構成には明記されていないが、<Countable_Component>を宣言しているため、Countable_Componentで定義された期待周辺構成を継承している。また、quantityで表現される構成要素の数という概念を追加したことにより、図５Ａ等で定義していた“App_is_hosted_on_Windows_OS”と“App_is_hosted_on_Ubuntu_OS”の期待周辺構成についても数の概念を明確に定義している。具体的には、Appが多重化されていない（すなわちquantityの値が1の）場合に適用される期待周辺構成になるため、それぞれの期待周辺構成の制約条件として、quantity==1を追加している。さらに、１個のアプリケーションが複数のOS上にホストされることは物理的にありえず、そのアプリケーションをホストするOSは一個であると限定できるため、制約条件として、OSの数が1個であることを意味するos1.quantity==1およびos2.quantity==1を追加している。さらに、quantityが１のAppが、quantityが１であるOS上にホストされる接続関係を表す関係性が複数であることも考えられないため、Hosted_onのquantityの値が１であることも同様に制約条件として定義している。
【0048】
図１１ＤのOSもApp同様、Countable_Componentである旨を宣言し、Component型を継承するとともに、availableにfalseを設定している。また、制約条件として、自身のquantityが１であること、自身をホストするMachineのquantityが1であること、およびその間のHosted_onのquantityも１であることを制約条件として定義している。MachineはCountable_Componentである旨を宣言し、Componentも継承しているが、availableに明確な値は設定していない。理由は、Machine自身が何に具体化されるかによってavailableの値が変わるためであり、Machineを継承したPhysical_Serverは可用性を備えない構成部品としてavailableをfalseに設定している。一方、Machine自身を、可用性を備えた構成部品に具体化するために、新たにFT_Server型の構成部品を定義し、そのavailableの値をtrueに設定している。最後に、SwitchはAppやOS同様、Countable_Componentである旨を宣言し、Component型を継承するとともに、availableにfalseを設定している。
【0049】
図１２Ａ～図１２Ｇに示す情報は、構成部品間の関係性の定義例であり、図６Ａ～図６Ｃの定義例をベースにしている。すなわち、太字の部分が冗長構成を設計するために新たに追加された定義箇所である。構成部品の定義と同様に、すべての関係性に共通するプロパティであるquantityとavailableをRelationship型の関係性にまとめて定義し、すべての関係性が直接もしくは間接的にRelationshipを継承する方法で記述している。さらに、Countable_Relationship型として、可算の関係性すべてが備える期待周辺構成を８つ定義している（図１２Ｄ～図１２Ｇ）。
図１２Ｄの1つ目の“Edges_between_Single_Node”は、図１０Ｂ(b-2)のように、両端の構成部品のquantityがともに1、自身のquantityが2以上であり、具体化の際に仲介ノードが存在しない関係性を具体化するための期待周辺構成である。具体的には、両端の構成部品間に、quantityの値の本数だけ自身と同じ型、かつquantityが1の関係性を作成する構成を定義している。一方、図１２Ｄの2つ目の“Edges_between_Single_Node_with_broker”は、図１０Ｂ(b-3)のように、両端の構成部品のquantityがともに1、自身のquantityが2以上であり、具体化の際に仲介ノードが存在する関係性を具体化するための期待周辺構成である。具体的には、quantityの値の数だけ仲介ノードを作成し、両端の構成部品と各仲介ノードが互いに、quantityが1の関係性で接続される構成を定義している。この際、仲介ノードの型および両端の構成部品と仲介ノード間の関係性の型は、具体化対象の関係性の型に定義された期待周辺構成に基づいて決定される。すなわち、図１２Ｄの“Edges_between_Single_Node_with_broker”内に定義された<BROKER_TYPE>、<EDGE1_TYPE>、<EDGE2_TYPE>の箇所はそれぞれ、Countable_Relationshipであることを宣言している関係性の型定義における、<Countable_Relationship(X, Y, Z)>という形式で定義されたX, Y, Zの型にそれぞれ置き換えられて具体化される。
図１２Ｄの3つ目の“Edges_between_Multi_Nodes”は、図１０Ａ(a-2)および図１０Ｃ(c-2)のように、両端の構成部品のquantityが2以上であり、具体化の際に仲介ノードが存在しない関係性を具体化するための期待周辺構成である。この期待周辺構成を適用する前提となる前提構成情報として、両端の構成部品がそのquantityの値に応じて具体化されている、すなわち、図１１Ｂで定義したCountable_Componentの“For_Multiplexed_Node”の期待周辺構成が適用されている構成を定義している。この前提構成情報が満たされている場合に、両端の構成部品が具体化されて作成されたquantityが１の同型の構成部品間が互いに、具体化対象の関係性と同じ型かつ同じquantityの値の関係性で接続される構成を定義している。一方、図１２Ｅの4つ目の“Edges_between_Multi_Nodes_with_broker”は、図１０Ａ(a-3)および図１０Ｃ(c-3)のように、両端の構成部品のquantityが2以上であり、具体化の際に仲介ノードが存在する関係性を具体化するための期待周辺構成である。具体的には、quantityの値の数だけ仲介ノードを作成し、図１１Ｂで定義したCountable_Componentの“For_Multiplexed_Node”の期待周辺構成が適用されて生成された各構成部品間と前記各仲介ノードが互いに、quantityが1の関係性で接続される構成を定義している。この際の仲介ノードの型および両端の構成部品と仲介ノード間の関係性の型は、“Edges_between_Single_Node_with_broker”と同様に、Countable_Relationshipであることを宣言した具体的な関係性の定義に基づいて決定される。
図１２Ｄの1つ目の“Edges_between_Single_Node”は、図１０Ｂ(b-2)のように、両端の構成部品のquantityがともに1、自身のquantityが2以上であり、具体化の際に仲介ノードが存在しない関係性を具体化するための期待周辺構成である。具体的には、両端の構成部品間に、quantityの値の本数だけ自身と同じ型、かつquantityが1の関係性を作成する構成を定義している。一方、図１２Ｄの2つ目の“Edges_between_Single_Node_with_broker”は、図１０Ｂ(b-3)のように、両端の構成部品のquantityがともに1、自身のquantityが2以上であり、具体化の際に仲介ノードが存在する関係性を具体化するための期待周辺構成である。具体的には、quantityの値の数だけ仲介ノードを作成し、両端の構成部品と各仲介ノードが互いに、quantityが1の関係性で接続される構成を定義している。この際、仲介ノードの型および両端の構成部品と仲介ノード間の関係性の型は、具体化対象の関係性の型に定義された期待周辺構成に基づいて決定される。すなわち、図１２Ｄの“Edges_between_Single_Node_with_broker”内に定義された<BROKER_TYPE>、<EDGE1_TYPE>、<EDGE2_TYPE>の箇所はそれぞれ、Countable_Relationshipであることを宣言している関係性の型定義における、<Countable_Relationship(X, Y, Z)>という形式で定義されたX, Y, Zの型にそれぞれ置き換えられて具体化される。
図１２Ｄの3つ目の“Edges_between_Multi_Nodes”は、図１０Ａ(a-2)および図１０Ｃ(c-2)のように、両端の構成部品のquantityが2以上であり、具体化の際に仲介ノードが存在しない関係性を具体化するための期待周辺構成である。この期待周辺構成を適用する前提となる前提構成情報として、両端の構成部品がそのquantityの値に応じて具体化されている、すなわち、図１１Ｂで定義したCountable_Componentの“For_Multiplexed_Node”の期待周辺構成が適用されている構成を定義している。この前提構成情報が満たされている場合に、両端の構成部品が具体化されて作成されたquantityが１の同型の構成部品間が互いに、具体化対象の関係性と同じ型かつ同じquantityの値の関係性で接続される構成を定義している。一方、図１２Ｅの4つ目の“Edges_between_Multi_Nodes_with_broker”は、図１０Ａ(a-3)および図１０Ｃ(c-3)のように、両端の構成部品のquantityが2以上であり、具体化の際に仲介ノードが存在する関係性を具体化するための期待周辺構成である。具体的には、quantityの値の数だけ仲介ノードを作成し、図１１Ｂで定義したCountable_Componentの“For_Multiplexed_Node”の期待周辺構成が適用されて生成された各構成部品間と前記各仲介ノードが互いに、quantityが1の関係性で接続される構成を定義している。この際の仲介ノードの型および両端の構成部品と仲介ノード間の関係性の型は、“Edges_between_Single_Node_with_broker”と同様に、Countable_Relationshipであることを宣言した具体的な関係性の定義に基づいて決定される。
【0050】
図１２Ｆの1つ目の“Edges_between_Multi_and_Single_Nodes”は、図１０Ｄ(d-2)および図１０Ｅ(e-2)のように、接続元の構成部品のquantityが２以上、接続先の構成部品のquantityが１であり、具体化の際に仲介ノードが存在しない関係性を具体化するための期待周辺構成である。quantityが2以上である片方の構成部品のみが、“Edges_between_Multi_Nodes”で説明した期待周辺構成を適用する内容であり、詳しい説明は省略する。一方、図１２Ｆの2つ目の“Edges_between_Multi_and_Single_Nodes_with_broker”は、図１０Ｄ(d-3)および図１０Ｅ(e-3)のように、接続元の構成部品のquantityが２以上、接続先の構成部品のquantityが１であり、具体化の際に仲介ノードが存在する関係性を具体化するための期待周辺構成である。quantityが2以上である片方の構成部品のみが、“Edges_between_Multi_Nodes_with_broker”で説明した期待周辺構成を適用する内容であり、詳しい説明は省略する。
【0051】
図１２Ｇの1つ目の“Edges_between_Single_and_Multi_Nodes”は、接続元の構成部品のquantityが1で、接続先の構成部品のquantityが2以上であり、具体化の際に仲介ノードが存在しない関係性を具体化するための期待周辺構成であり、図１０Ｄ(d-2)および図１０Ｅ(e-2)と比べて、接続元と接続先の構成部品の具体化パターンが逆の期待周辺構成を定義している。図１２Ｇの2つ目の“Edges_between_Single_and_Multi_Nodes_with_broker”は、接続元の構成部品のquantityが1で、接続先の構成部品のquantityが2以上であり、具体化の際に仲介ノードが存在する関係性を具体化するための期待周辺構成であり、図１０Ｄ(d-3)および図１０Ｅ(e-3)と比べて、接続元と接続先の構成部品の具体化パターンが逆の期待周辺構成を定義している。これらの期待周辺構成の内容はそれぞれ“Edges_between_Multi_and_Single_Nodes”と“Edges_between_Multi_and_Single_Nodes_with_broker”と類似しているため、詳しい説明は省略する。
図１２Ａ～図１２Ｇの定義における、Countable_Relationshipであることの宣言方法、およびforeach()や<i>、[$self.__type__]の意味は図１１Ａ～図１１Ｄを用いて説明した内容と同様である。ただし、具体化の際に仲介ノードを必要とする関係性がCountable_Relationshipであることを宣言する際に、仲介ノードの型、および両端の構成部品と仲介ノード間の関係性の型を含めて宣言する部分のみ、Countable_Componentの宣言方法と異なる。たとえば図１２ＣのConn_to(Machine, Machine)型の定義では、この型がCountable_Relationshipであることを宣言する際に、この関係性を具体化する際に生成される仲介ノードの型、および両端の構成部品と仲介ノード間の関係性の型としてそれぞれ、Switch、Conn_to(Machine, Swith)、Conn_to(Switch, Machine)を定義している。
図１２Ａ～図１２Ｇの定義における、Countable_Relationshipであることの宣言方法、およびforeach()や<i>、[$self.__type__]の意味は図１１Ａ～図１１Ｄを用いて説明した内容と同様である。ただし、具体化の際に仲介ノードを必要とする関係性がCountable_Relationshipであることを宣言する際に、仲介ノードの型、および両端の構成部品と仲介ノード間の関係性の型を含めて宣言する部分のみ、Countable_Componentの宣言方法と異なる。たとえば図１２ＣのConn_to(Machine, Machine)型の定義では、この型がCountable_Relationshipであることを宣言する際に、この関係性を具体化する際に生成される仲介ノードの型、および両端の構成部品と仲介ノード間の関係性の型としてそれぞれ、Switch、Conn_to(Machine, Swith)、Conn_to(Switch, Machine)を定義している。
【0052】
新たに追加定義したOne_of(App, App)は、quantityが2以上のAppと、そのAppを冗長化しながら具体化することで生成されたquantityが１のApp間の接続関係を表現する関係性であり、生成されたAppは具体化元のAppの一部であることを表現する関係性である。One_of(App, App)はCountable_Relationshipであることを宣言し、Relationship型を継承するとともに、availableにfalseを設定している。また、一つのAppが具体化元のAppの一部であることを表すこの関係性が複数であることは考えられないため、quantityの値を1に限定している。Conn_to(App, App)も同様に、Countable_Relationshipであることを宣言し、Relationship型を継承するとともに、availableにfalseを設定している。また、図６Ｃで定義した”Connection_between_Machines”の期待周辺構成は、Conn_to(App, App)が多重化されていない場合に適用される期待周辺構成であるため、この期待周辺構成の制約条件として、自身のquantityが１であることを追加している。Conn_to(Machine, Machine)もConn_to(App, App)と同様に、Countable_Relationshipの宣言、Relationship型の継承、availableの設定および制約条件を追加している。Conn_to(Machine, Switch)は期待周辺構成を持たないため、Countable_Relationshipの宣言、Relationship型の継承、およびavailableの設定のみを追加している。
図６Ａ～図６Ｃで定義した関係性のうち、図１２Ａ～図１２Ｇに記載のない、Include(System, App)、Hosted_on(App, OS)、Hosted_on(OS, Machine)、Conn_to(Machine, Switch), Conn_to(Switch, Machine)に関しては、期待周辺構成をもたないため、Countable_Relationshipの宣言、Relationship型の継承、availableの設定のみを追加するものとする。
図６Ａ～図６Ｃで定義した関係性のうち、図１２Ａ～図１２Ｇに記載のない、Include(System, App)、Hosted_on(App, OS)、Hosted_on(OS, Machine)、Conn_to(Machine, Switch), Conn_to(Switch, Machine)に関しては、期待周辺構成をもたないため、Countable_Relationshipの宣言、Relationship型の継承、availableの設定のみを追加するものとする。
【0053】
（冗長化されたシステム構成の具体化の例）
図１３Ａ～図１３Ｅに、図５Ａ～図５Ｃと図６Ａ～図６Ｃに加え、図１１Ａ～図１１Ｄおよび図１２Ａ～図１２Ｇで追加した構成部品および構成部品間の関係性を用いた、構成要素のquantityの値に基づくシステ構成の設計例を示す。
図１３ＡのS1は入力として与えられるシステム要件を示す構成情報であり、アプリケーションXとアプリケーションYが存在し、互いに通信できるシステムを設計することを意味している。また、App_XとApp_Y、およびその間の関係性であるConn_toには、それぞれquantityに２が設定されており、それぞれが二重化されていることを要件として与えている。構成要素名に続く括弧で囲まれた数字は、その構成要素のquantityの値を表す。図７Ａ～図７Ｃの説明の際も言及した通り、S1の構成に含まれる構成要素のうちどの構成要素から具体化を行うかの選択方法は特に限定していないため、図１３Ａではまず、App_X(2)から具体化処理が実行されたものとして説明する。
図１３Ａ～図１３Ｅに、図５Ａ～図５Ｃと図６Ａ～図６Ｃに加え、図１１Ａ～図１１Ｄおよび図１２Ａ～図１２Ｇで追加した構成部品および構成部品間の関係性を用いた、構成要素のquantityの値に基づくシステ構成の設計例を示す。
図１３ＡのS1は入力として与えられるシステム要件を示す構成情報であり、アプリケーションXとアプリケーションYが存在し、互いに通信できるシステムを設計することを意味している。また、App_XとApp_Y、およびその間の関係性であるConn_toには、それぞれquantityに２が設定されており、それぞれが二重化されていることを要件として与えている。構成要素名に続く括弧で囲まれた数字は、その構成要素のquantityの値を表す。図７Ａ～図７Ｃの説明の際も言及した通り、S1の構成に含まれる構成要素のうちどの構成要素から具体化を行うかの選択方法は特に限定していないため、図１３Ａではまず、App_X(2)から具体化処理が実行されたものとして説明する。
【0054】
App_X(2)はquantityが2であるため、図１１Ｂ等においてCountable_Componentであることを宣言することで継承した、“For_Multiplexed_Node”の期待周辺構成を満たすように具体化され、quantityが１のApp_Xが２個とそれぞれOne_ofの関係性で接続される構成に具体化される(図１３ＡのS2)。App_Y(2)も同様の手順でquantityが１のApp_Yが２個とそれぞれOne_ofの関係性で接続される構成に具体化される(図１３ＢのS3)。その後、各App_Xと各App_Yはすべてquantityが1であるため、それぞれ“App_is_hosted_on_Windows_OS”と“App_is_hosted_on_Ubuntu_OS”の期待周辺構成を満たすように具体化することで、quantityが１であるWindows（登録商標）とUbuntu（登録商標）が生成され、生成された各OSノードの”OS_is_hosted_on_Machine”の期待周辺構成を満たすように具体化することで、quantityが1のMachineが生成される。その後、具体性がfalseのMachineが、具体性がtrueのPhysical_Serverに具体化される(図１３ＢのS4)。
【0055】
その後、App_X(2)とApp_Y(2)間のConn_to(2)を対象に具体化を実行する。Conn_to(2)はquantityが２であるため、図１２Ｂ等においてCountable_Relationshipであることを宣言することで継承した、”For_Multiplexed_Edge”の期待周辺構成を満たすように具体化され、App_X(2)とApp_Y(2)間にquantityが１のConn_toが２本作成される構成に具体化される(図１３ＣのS5)。App_X(2)とApp_Y(2)間のConn_toは、Conn_to自身のquantityが1であり、その両端のApp_X(2)とApp_Y(2)のquantityがともに２（すなわち２以上）であるため、“For_Single_Edge_between_Multiplexed_Nodes”の期待周辺構成を満たすように具体化され、２個のApp_Xと２個のApp_Yが互いに各１本のConn_toで接続された構成に具体化される。図１３ＣのS6は、App_X(2)とApp_Y(2)間の２本のConn_toのうち、1本のみが具体化された状態を示す。App_XとApp_Yの間の４本のConn_toはすべてquantityが１であるため、それぞれ”Connection_Between_Machines”の期待周辺構成を満たすように具体化され、各AppをホストするPhysical_Server間の、quantityが１のConn_toに具体化される(図１３ＤのS7)。Physical_Server間のConn_toは、“Connection_between_Machine_and_Switch”の期待周辺構成を満たすように具体化され、Switchを経由する構成に具体化される(図１３ＤのS8および図１３ＥのS9)。最後に、App_X(2)とApp_Y(2)の間の残りのConn_toに対しても、S5～S9と同様の流れで具体化が実行される(図１３ＥのS10)。図１３ＥのS9とS10の構成において、省略されているPhysical_ServerとSwitch間の関係性はすべてConn_toであるとする。この時点で、システム構成内のすべての構成要素の具体性がtrue、かつ、すべての構成要素が期待周辺構成を満たす状態となり、システム構成の設計を完了する。
【0056】
（動作）
続いて、第１の実施形態におけるシステム自動設計の処理の流れについて説明する。図１４は、第１の実施形態に係るシステム自動設計装置９００の動作全体を示すフローチャートである。
利用者はシステム要件を入力する（F1)。システム自動設計装置９００は、システム要件を段階的に具体化し（F2～F9）、完全に具体化されたシステム構成もしくは設計失敗の旨を出力する（F10、F11）。システム構成の段階的な具体化として、構成具体化部２００は、まず１段階の具体化（F2～F7）を実施し、得られた複数の設計途中のシステム構成の中に具体的なシステム構成が含まれているかを確認する（F8）。具体的なシステム構成とは、システム構成内に抽象的な構成要素がなくなり、かつ、すべての構成要素の期待周辺構成が満たされている状態のシステム構成である。具体的なシステム構成が含まれていれば（F8のYes）、入出力部１００は、その具体的なシステム構成を出力して（F10）処理を終了する。具体的なシステム構成が含まれていなければ（F8のNo）、構成具体化部２００は、他にまだ抽象的な設計途中のシステム構成が残っているかを確認する（F9）。抽象的な設計途中のシステム構成が残っていれば（F9のYes）、次に具体化する設計途中のシステム構成を選択する処理（F2）に戻り、１段階の具体化を再度実行する。抽象的な設計途中のシステム構成が残っていなければ（F9のNo）、それ以上の具体化を実行できないとして、入出力部１００は、設計に失敗した旨を出力して（F11）処理を終了する。
続いて、第１の実施形態におけるシステム自動設計の処理の流れについて説明する。図１４は、第１の実施形態に係るシステム自動設計装置９００の動作全体を示すフローチャートである。
利用者はシステム要件を入力する（F1)。システム自動設計装置９００は、システム要件を段階的に具体化し（F2～F9）、完全に具体化されたシステム構成もしくは設計失敗の旨を出力する（F10、F11）。システム構成の段階的な具体化として、構成具体化部２００は、まず１段階の具体化（F2～F7）を実施し、得られた複数の設計途中のシステム構成の中に具体的なシステム構成が含まれているかを確認する（F8）。具体的なシステム構成とは、システム構成内に抽象的な構成要素がなくなり、かつ、すべての構成要素の期待周辺構成が満たされている状態のシステム構成である。具体的なシステム構成が含まれていれば（F8のYes）、入出力部１００は、その具体的なシステム構成を出力して（F10）処理を終了する。具体的なシステム構成が含まれていなければ（F8のNo）、構成具体化部２００は、他にまだ抽象的な設計途中のシステム構成が残っているかを確認する（F9）。抽象的な設計途中のシステム構成が残っていれば（F9のYes）、次に具体化する設計途中のシステム構成を選択する処理（F2）に戻り、１段階の具体化を再度実行する。抽象的な設計途中のシステム構成が残っていなければ（F9のNo）、それ以上の具体化を実行できないとして、入出力部１００は、設計に失敗した旨を出力して（F11）処理を終了する。
【0057】
１段階の具体化においては、構成具体化部２００は、入出力部１００が取得したシステム要件、もしくは設計途中のシステム構成を一つ選択し（F2）、選択したシステム構成内に含まれる具体化可能な構成要素をすべて抽出する（F3）。具体化構成案生成部３００は、F3で抽出した各構成要素に対し、適用可能な具体化パターンを適用したシステム構成を生成する。ここで、一つの構成要素に適用可能な具体化パターンが複数存在する場合は、それぞれの具体化パターンを適用した構成をすべて生成する（F4）。冗長構成案生成部３１０は、図８Ａ～図１３Ｅを用いて説明したように、構成部品を冗長化して具体化したり、構成部品間の関係性を冗長化したりしてシステム構成を具体化する。非冗長構成案生成部３２０は、図６Ａ～図７Ｃを用いて説明したように冗長化の必要が無い構成部品の具体化を行う。その後、構成具体化部２００は、具体化構成案生成部３００によって、実際に１つ以上のシステム構成が生成されたかを確認する（F5）。設計途中のシステム構成が生成されなかった場合には（F5のNo）、１段階の具体化は失敗であるため、構成具体化部２００は、他の設計途中のシステム構成が残っているかの確認を行う（F9）。１つ以上のシステム構成が生成された場合（F5のYes）、構成具体化部２００は、制約検証部５００を用いて、システム構成に含まれる制約条件を判定し、制約条件を満たしえないシステム構成を棄却する（F6）。その後、構成具体化部２００は、棄却されていない設計途中のシステム構成が１つ以上残っているかを確認する（F7）。システム構成が残っている場合は（F7のYes）、1段階の具体化は成功であるため、設計途中のシステム構成が具体的か否かの確認（F8）に進む。システム構成が残っていない場合（F7のNo）、１段階の具体化は失敗であるため、他の設計途中のシステム構成が残っているかの確認へ進む(F9）。
【0058】
図１５Ａ、図１５Ｂに、図１４のF4で実行される処理をさらに詳細に示す。図１５Ａ、図１５Ｂは、ある構成要素に具体化パターンを適用する際に、quantityの値に基づいて具体化パターンを決定する処理の流れを示すフローチャートである。ある構成要素を具体化する場合、具体化構成案生成部３００は、その構成要素が構成部品の場合(G1のYes)、まずはその構成部品のquantityの値を確認する(G2)。quantityが2以上の場合(G2のYes)、具体化構成案生成部３００（冗長構成案生成部３１０）は、その構成部品を複数作成する冗長構成への具体化パターンを適用するとともに、具体化構成案生成部３００（非冗長構成案生成部３２０）は、それ以外の冗長化を含まない適用可能なすべての具体化パターンをそれぞれ適用した複数の構成案を生成して(G3)、その構成部品の具体化処理を完了する。quantityの値が１の場合(G2のNo)、非冗長構成案生成部３２０は、適用可能な期待周辺構成があるかを確認し(G4)、適用可能な期待周辺構成がある場合は(G4のYes)、冗長化を含まない適用可能なすべての具体化パターンをそれぞれ適用した複数の構成案を生成して(G5)、その構成部品の具体化処理を完了する。適用可能な期待周辺構成がない場合は(G4のNo)、その構成要素に適用できる具体化パターンはないものとして、その構成部品の具体化処理を完了する。
【0059】
構成要素が関係性の場合(G1のNo)、具体化構成案生成部３００は、その関係性の両端の構成部品のquantityの値を確認する(G6)。両端の構成部品のquantityの値がともに２以上の場合(G6のYes)、冗長構成案生成部３１０は、”Edges_between_Multi_Nodes”と”Edges_between_Multi_Nodes_with_broker”の2つの冗長構成への具体化パターンの中で適用可能なものをそれぞれ適用した構成案を生成するとともに、非冗長構成案生成部３２０は、冗長構成を含まないそれ以外の適用可能なすべての具体化パターンをそれぞれ適用した複数の構成案を生成して(G7)、その関係性の具体化処理を完了する。すなわち、その関係性に、仲介するノードが存在する期待周辺構成と存在しない期待周辺構成の両方が定義されている場合は、その両方の期待周辺構成を適用した構成案を生成するなど、その関係性に適用可能な具体化パターンをすべて適用する。ここで、図１５ＢのG7において、”Edges_between_Multi_Nodes(_with_broker)”は、”Edges_between_Multi_Nodes”と”Edges_between_Multi_Nodes_with_broker”の2つを1つにまとめて表現した記述である。
両端の構成部品のquantityがともに２以上という条件を満たさない場合(G6のNo)、接続元の構成部品のquantityの値が２以上であるかを確認する(G8)。接続元の構成部品のquantityが２以上の場合(G8のYes)、”Edges_between_Multi_and_Single_Nodes”と”Edges_between_Multi_and_Single_Nodes_with_broker”の2つの冗長構成への具体化パターンの中で適用可能なものをそれぞれ適用した構成案を生成するとともに、冗長構成を含まないそれ以外の適用可能なすべての具体化パターンをそれぞれ適用した複数の構成案を生成して(G9)、その関係性の具体化処理を完了する。
接続元の構成部品のquantityが２以上でない場合(G8のNo)、接続先の構成部品のquantityの値が２以上であるかを確認する(G10)。接続先の構成部品のquantityが２以上の場合(G10のYes)、”Edges_between_Single_and_Multi_Nodes”および”Edges_between_Single_and_Multi_Nodes_with_broker”の2つの冗長構成への具体化パターンの中で適用可能なものをそれぞれ適用した構成案を生成するとともに、冗長構成を含まないそれ以外の適用可能なすべての具体化パターンをそれぞれ適用した複数の構成案を生成して(G11)、その関係性の具体化処理を完了する。
両端の構成部品のquantityがともに１の場合(G10のNo)、その関係性自身のquantityの値を確認する(G12)。自身のquantityの値が２以上の場合(G12のYes)、”Edges_between_Single_Nodes”および”Edges_between_Single_Nodes_with_broker”2つの冗長構成への具体化パターンの中で適用可能なものをそれぞれ適用した構成案を生成するとともに、冗長構成を含まないそれ以外の適用可能なすべての具体化パターンをそれぞれ適用した複数の構成案を生成して(G13)、その関係性の具体化処理を完了する。
自身のquantityの値が１の場合(G12のNo)、その関係性に適用可能な期待周辺構成が存在するかを確認し(G14)、存在する場合は(G14のYes)、冗長化を含まない適用可能ななすべての具体化パターンをそれぞれ適用した複数の構成案を生成して(G15)、その関係性の具体化処理を完了する。適用可能な期待周辺構成が存在しない場合は(G14のNo)、その関係性に適用できる期待周辺構成はないものとして、その関係性の具体化処理を完了する。
両端の構成部品のquantityがともに２以上という条件を満たさない場合(G6のNo)、接続元の構成部品のquantityの値が２以上であるかを確認する(G8)。接続元の構成部品のquantityが２以上の場合(G8のYes)、”Edges_between_Multi_and_Single_Nodes”と”Edges_between_Multi_and_Single_Nodes_with_broker”の2つの冗長構成への具体化パターンの中で適用可能なものをそれぞれ適用した構成案を生成するとともに、冗長構成を含まないそれ以外の適用可能なすべての具体化パターンをそれぞれ適用した複数の構成案を生成して(G9)、その関係性の具体化処理を完了する。
接続元の構成部品のquantityが２以上でない場合(G8のNo)、接続先の構成部品のquantityの値が２以上であるかを確認する(G10)。接続先の構成部品のquantityが２以上の場合(G10のYes)、”Edges_between_Single_and_Multi_Nodes”および”Edges_between_Single_and_Multi_Nodes_with_broker”の2つの冗長構成への具体化パターンの中で適用可能なものをそれぞれ適用した構成案を生成するとともに、冗長構成を含まないそれ以外の適用可能なすべての具体化パターンをそれぞれ適用した複数の構成案を生成して(G11)、その関係性の具体化処理を完了する。
両端の構成部品のquantityがともに１の場合(G10のNo)、その関係性自身のquantityの値を確認する(G12)。自身のquantityの値が２以上の場合(G12のYes)、”Edges_between_Single_Nodes”および”Edges_between_Single_Nodes_with_broker”2つの冗長構成への具体化パターンの中で適用可能なものをそれぞれ適用した構成案を生成するとともに、冗長構成を含まないそれ以外の適用可能なすべての具体化パターンをそれぞれ適用した複数の構成案を生成して(G13)、その関係性の具体化処理を完了する。
自身のquantityの値が１の場合(G12のNo)、その関係性に適用可能な期待周辺構成が存在するかを確認し(G14)、存在する場合は(G14のYes)、冗長化を含まない適用可能ななすべての具体化パターンをそれぞれ適用した複数の構成案を生成して(G15)、その関係性の具体化処理を完了する。適用可能な期待周辺構成が存在しない場合は(G14のNo)、その関係性に適用できる期待周辺構成はないものとして、その関係性の具体化処理を完了する。
【0060】
（効果）
以上説明したように、第１の実施形態によれば、quantityを指定するだけで、具体的な冗長構成のありようを指定することなく、quantityの値に応じて冗長化されたシステム構成を自動設計できる。
以上説明したように、第１の実施形態によれば、quantityを指定するだけで、具体的な冗長構成のありようを指定することなく、quantityの値に応じて冗長化されたシステム構成を自動設計できる。
【0061】
＜第２の実施形態＞
次に本発明の第２の実施形態について、図１６～図２３を用いて説明する。第１の実施形態では、各構成要素に冗長度合いを表す数(quantity)の概念を取り入れ、quantityに応じて構成要素を具体化することで、冗長化されたシステム構成を設計する。一方、システムに対する可用性要件としては、システムの各構成要素の数を要件として直接指定するのではなく、システム全体に耐障害性要件という形で指定することがある。耐障害性要件とは、ある機能が依存する構成要素の内、何か所が機能停止に陥ってもその機能が停止せずに稼働し続けられるかを示す数に関する要件である。たとえば耐障害性要件に１が設定されたシステムの場合は、１か所の機能が停止してもシステムが停止せずに稼働し続けられる、すなわち単一障害点がないシステム構成を要求していることを表す。ある構成要素に耐障害性要件が指定されている場合、その構成要素自身およびその構成要素が直接的もしくは間接的に依存する構成要素の数を適切に選択しながら具体化を行うことで、耐障害性要件を満たすシステム構成を設計する必要がある。
次に本発明の第２の実施形態について、図１６～図２３を用いて説明する。第１の実施形態では、各構成要素に冗長度合いを表す数(quantity)の概念を取り入れ、quantityに応じて構成要素を具体化することで、冗長化されたシステム構成を設計する。一方、システムに対する可用性要件としては、システムの各構成要素の数を要件として直接指定するのではなく、システム全体に耐障害性要件という形で指定することがある。耐障害性要件とは、ある機能が依存する構成要素の内、何か所が機能停止に陥ってもその機能が停止せずに稼働し続けられるかを示す数に関する要件である。たとえば耐障害性要件に１が設定されたシステムの場合は、１か所の機能が停止してもシステムが停止せずに稼働し続けられる、すなわち単一障害点がないシステム構成を要求していることを表す。ある構成要素に耐障害性要件が指定されている場合、その構成要素自身およびその構成要素が直接的もしくは間接的に依存する構成要素の数を適切に選択しながら具体化を行うことで、耐障害性要件を満たすシステム構成を設計する必要がある。
【0062】
第２の実施形態では、システムの具体化の過程において、具体化対象の構成要素に明確なquantityの値が設定されていない場合、任意のquantityの値を設定し、そのquantityの値に応じた具体化を行うことで、その構成要素を任意の数に冗長化して具体化する。システム構成内の各構成要素を任意の数で冗長化して具体化することで、多種多様な冗長構成を設計することができる。さらに、構成要素が耐障害性要件を満たす条件を定義し、耐障害性要件が指定された構成要素がその条件を満たすか否かを検証することで、設計されうる多種多様な冗長構成の中から、耐障害性要件を満たす構成のみを選別する。
【0063】
（構成）
第２の実施形態に係るシステム自動設計装置９１０構成を図１６に示す。第２の実施形態にかかるシステム自動設計装置９１０では、第１の実施形態のシステム自動設計装置９００の構成に加えさらに、耐障害性検証部６００を有する。耐障害性検証部６００は、システム構成内に存在する耐障害性要件が指定された構成要素がその耐障害性要件を満たす構成に具体化されているかを検証する。耐障害性検証部６００は、耐障害性制約条件生成部６１０と耐障害性制約条件判定部６２０を有する。耐障害性制約条件生成部６１０は、耐障害性要件が指定された構成要素がその耐障害性要件を満たすために満たすべき制約条件を生成する機能をもつ。耐障害性制約条件判定部６２０は、耐障害性制約条件生成部６１０で生成された制約条件を満たすか否かを判定する機能をもつ。
第２の実施形態に係るシステム自動設計装置９１０構成を図１６に示す。第２の実施形態にかかるシステム自動設計装置９１０では、第１の実施形態のシステム自動設計装置９００の構成に加えさらに、耐障害性検証部６００を有する。耐障害性検証部６００は、システム構成内に存在する耐障害性要件が指定された構成要素がその耐障害性要件を満たす構成に具体化されているかを検証する。耐障害性検証部６００は、耐障害性制約条件生成部６１０と耐障害性制約条件判定部６２０を有する。耐障害性制約条件生成部６１０は、耐障害性要件が指定された構成要素がその耐障害性要件を満たすために満たすべき制約条件を生成する機能をもつ。耐障害性制約条件判定部６２０は、耐障害性制約条件生成部６１０で生成された制約条件を満たすか否かを判定する機能をもつ。
【0064】
以降では、耐障害性要件が指定された構成要素が、その耐障害性要件を満たすための制約条件について説明する。耐障害性要件を満たすための制約条件（以降、耐障害性制約条件と記載）は、その構成要素の属性に応じて決定される。具体的には、composition属性とquantity属性の値に応じて決定される。
【0065】
composition属性とは、その構成要素がどのような構成要素で構成されているかを表す属性であり、具体的な値として“複合属性”と“原始属性”の二種類存在する。複合属性とは、自身と異なる１種類以上の構成要素の集合で構成される構成要素を表す。一方、原始属性とは、自身と異なる種類の構成要素の集合では構成されていない構成要素を表す。例えば、Webシステムは、Webアプリケーションやデータベースなどの自身とは異なる複数の構成要素を含んで構成されていると考えられるため、複合属性をもつと考えられる。一方、アプリケーションやOSなどは、何らかの異なる構成要素の集合体ではないため、原始属性をもつと考えられる。
【0066】
quantity属性とは、その構成要素自身の数を表す属性であり、“単数属性”と“複数属性”の二種類存在する。この属性値は、第１の実施形態で説明したquantityプロパティの値で決定され、quantityの値が１の構成要素は単数属性をもち、quantityの値が２以上、もしくは未定の（具体的な値は設定されていないが2以上になる可能性がある）構成要素は複数属性をもつと定義する。構成要素がもつ属性値に応じた耐障害性制約条件の一覧を図１７に示す。図１７に記載した耐障害性制約条件の詳細についてそれぞれ説明する。
【0067】
（１）複合属性かつ単数属性をもつ構成要素の耐障害性制約条件
構成要素が複合属性かつ単数属性をもつ場合、その構成要素の期待周辺構成に含まれる各構成要素も同様に耐障害性要件を満たしていればよい。このパターンの耐障害性制約条件の例を図１８Ａ～図１８Ｂに示す。図１８Ａは、耐障害性要件１が指定された構成部品の例として、Websystemの耐障害性制約条件を示す図である。耐障害性要件１が指定されたとは、耐障害性要件に１が設定されたことを示し、上述したように、１か所の機能が停止してもシステムが停止せずに稼働し続けられることが要求されているということである。WebsystemはWebAppとDBServerを含んで構成される複合属性の構成要素であると考えられ、さらにWebAppとDBServer間は通信できると考えられる。したがって、Websystemの期待周辺構成としては、Websystem自身とWebAppおよびDBServerの間にIncludeという関係性が存在し、かつ、WebAppとDBServer間がConn_toの関係性をもつ構成を定義できる。したがって、Websystemに耐障害性要件１が指定されている場合、期待周辺構成に含まれるWebApp、DBServerの２つの構成部品、およびそれらの間のConn_toの関係性がすべて耐障害性要件１を満たしていることが耐障害性制約条件である。ここで、Includeという関係性は、複合属性の構成要素とセットで定義される構成要素であり、複合属性の構成要素と、その構成要素によって展開された構成要素との関係性を表現する特別な関係性である。複合属性の構成要素の冗長性は、具体化によって展開された構成要素の冗長度に依存するため、Include自身の数(quantity)は複合属性の冗長度には影響を与えない。
構成要素が複合属性かつ単数属性をもつ場合、その構成要素の期待周辺構成に含まれる各構成要素も同様に耐障害性要件を満たしていればよい。このパターンの耐障害性制約条件の例を図１８Ａ～図１８Ｂに示す。図１８Ａは、耐障害性要件１が指定された構成部品の例として、Websystemの耐障害性制約条件を示す図である。耐障害性要件１が指定されたとは、耐障害性要件に１が設定されたことを示し、上述したように、１か所の機能が停止してもシステムが停止せずに稼働し続けられることが要求されているということである。WebsystemはWebAppとDBServerを含んで構成される複合属性の構成要素であると考えられ、さらにWebAppとDBServer間は通信できると考えられる。したがって、Websystemの期待周辺構成としては、Websystem自身とWebAppおよびDBServerの間にIncludeという関係性が存在し、かつ、WebAppとDBServer間がConn_toの関係性をもつ構成を定義できる。したがって、Websystemに耐障害性要件１が指定されている場合、期待周辺構成に含まれるWebApp、DBServerの２つの構成部品、およびそれらの間のConn_toの関係性がすべて耐障害性要件１を満たしていることが耐障害性制約条件である。ここで、Includeという関係性は、複合属性の構成要素とセットで定義される構成要素であり、複合属性の構成要素と、その構成要素によって展開された構成要素との関係性を表現する特別な関係性である。複合属性の構成要素の冗長性は、具体化によって展開された構成要素の冗長度に依存するため、Include自身の数(quantity)は複合属性の冗長度には影響を与えない。
【0068】
図１８Ｂは、耐障害性要件１が指定された構成部品間の関係性の例として、Hybrid_Accessの耐障害性制約条件を示す図である。あるMachine間の通信が、有線通信と無線通信を含んで構成される複合的な通信手段(Hybrid_Access)である場合、図１８Ｂの通り、Hybrid_Accessの期待周辺構成は、Wired_AccessとWireless_Accessからなる構成であると定義できる。したがって、Hybrid_Accessに耐障害性要件1が指定されている場合、Wired_AccessとWireless_Accessの両方の関係性がともに耐障害性要件1を満たしていることが耐障害性制約条件である。図１８Ａ、図１８Ｂにおいて、期待周辺構成に含まれる構成要素が耐障害性要件を満たしうるかの判定を再帰的に繰り返し、すべての構成要素の耐障害性要件が満たされている場合に、再帰元の構成要素の耐障害性要件が満たされると判定する。
【0069】
（２）原始属性かつ単数属性をもつ構成要素の耐障害性制約条件
構成要素が原始属性かつ単数属性をもつ場合、その構成要素は自身を構成する構成要素に分割することができず、かつ、quantityが1と確定しているため、２重以上に冗長化することはできない。したがって、１か所も機能が停止していないこと、すなわち、自身に設定された耐障害性要件が０であることが耐障害性制約条件となる。
構成要素が原始属性かつ単数属性をもつ場合、その構成要素は自身を構成する構成要素に分割することができず、かつ、quantityが1と確定しているため、２重以上に冗長化することはできない。したがって、１か所も機能が停止していないこと、すなわち、自身に設定された耐障害性要件が０であることが耐障害性制約条件となる。
【0070】
（３）複数属性をもつ構成要素の耐障害性制約条件
構成要素が複数属性をもつ場合、その構成要素自身が耐障害性要件より大きい値の数で冗長化され、かつ、冗長化されて作成された各構成要素が直接的もしくは間接的に依存する構成要素の集合（以降、依存構成要素集合と表記）が互いに非共有であればよいと定義する。ある構成要素が直接的に依存する構成要素とは、その構成要素が存在するために必要な構成要素のことであり、期待周辺構成の必須構成情報に含まれる構成要素が該当する。直接的に依存する構成要素がさらに依存する構成要素といった、依存関係の連鎖に含まれる構成要素の集合が依存構成要素集合である。依存構成要素集合が互いに非共有とは、それぞれの集合に含まれる構成要素は一つの依存構成要素集合のみに属し、複数の依存構成要素集合に属する構成要素がないことを意味する。ただし、可用性を有する(available=1)構成要素は、依存構成要素集合間で共有されていてもよい。複数属性をもつ構成要素の耐障害性制約条件の例を図１９Ａ、図１９Ｂに示す。図１９Ａはアプリケーションを表すAppに耐障害性要件１が指定されている場合の例であり、App自身が２重以上に冗長化、すなわち、Appのquantityの値が２以上であり、かつ、Appを冗長化して具体化されたApp（冗長化元のAppとOne_ofの関係性で接続された各App）、および、各Appが依存するOSとその間のHosted_on、およびOSが依存するMachineとその間のHosted_onからなる2つの依存構成要素集合が非共有、すなわち、図１９Ａにおける破線で囲まれた構成要素群が互いに疎であればよい。ただし、Machineが、FT_Server(available=1)である場合など、可用性をもつ構成要素であれば構成要素群の間で共有されていてもよい。すなわち、図１９Ａにおける２つのOSがともに同じFT_ServerにHosted_onエッジを張っている構成でもよい。
構成要素が複数属性をもつ場合、その構成要素自身が耐障害性要件より大きい値の数で冗長化され、かつ、冗長化されて作成された各構成要素が直接的もしくは間接的に依存する構成要素の集合（以降、依存構成要素集合と表記）が互いに非共有であればよいと定義する。ある構成要素が直接的に依存する構成要素とは、その構成要素が存在するために必要な構成要素のことであり、期待周辺構成の必須構成情報に含まれる構成要素が該当する。直接的に依存する構成要素がさらに依存する構成要素といった、依存関係の連鎖に含まれる構成要素の集合が依存構成要素集合である。依存構成要素集合が互いに非共有とは、それぞれの集合に含まれる構成要素は一つの依存構成要素集合のみに属し、複数の依存構成要素集合に属する構成要素がないことを意味する。ただし、可用性を有する(available=1)構成要素は、依存構成要素集合間で共有されていてもよい。複数属性をもつ構成要素の耐障害性制約条件の例を図１９Ａ、図１９Ｂに示す。図１９Ａはアプリケーションを表すAppに耐障害性要件１が指定されている場合の例であり、App自身が２重以上に冗長化、すなわち、Appのquantityの値が２以上であり、かつ、Appを冗長化して具体化されたApp（冗長化元のAppとOne_ofの関係性で接続された各App）、および、各Appが依存するOSとその間のHosted_on、およびOSが依存するMachineとその間のHosted_onからなる2つの依存構成要素集合が非共有、すなわち、図１９Ａにおける破線で囲まれた構成要素群が互いに疎であればよい。ただし、Machineが、FT_Server(available=1)である場合など、可用性をもつ構成要素であれば構成要素群の間で共有されていてもよい。すなわち、図１９Ａにおける２つのOSがともに同じFT_ServerにHosted_onエッジを張っている構成でもよい。
【0071】
図１９ＢはApp間のConn_to（二重線で示されたエッジ）に耐障害性要件１が指定されている場合の例であり、Conn_to自身が２重に冗長化、すなわち、Conn_toのquantityの値が２以上であり、かつ、このConn_toが冗長化して具体化されたApp間の２本のquantity=1のConn_to（１本の実線で示されたエッジ）、および２本のConn_toそれぞれから具体化された、Switchと、MachineとSwitch間のConn_toからなる依存構成要素集合が非共有、すなわち、図１９Ｂにおける型名の頭に[A]と記載された構成要素の集合と[B]と記載された構成要素の集合に含まれる構成要素同士が互いに疎であればよい。
【0072】
上記で説明した、構成要素がもつ属性値に応じた耐障害性制約条件を定式化した説明を図２０に示す。図２０の［定義］が各パラメータや記号の意味を示し、「定義」に示す関数Multi(c, n)で生成する耐障害性制約条件の式を［Multi(c, n)で生成する耐障害性制約条件］に示す。耐障害性制約条件生成部６１０は、システム構成に含まれる耐障害性要件が指定された構成要素に対して図２０に示す関数Multi(c, n)を適用し、その構成要素が耐障害性要件を満たすための耐障害性制約条件を生成する。
【0073】
なお、詳細な説明は省略するが、耐障害性検証部６００は、図２１Ａ～図２１Ｃに例示するシステム要求から以下の手順で、各処理を行い、耐障害性の検証を行う。
（手順１）耐障害性要件が指定された構成要素を抽出し、属性を確認する。
（手順２）確認した属性に応じて検証処理を分岐する。
(手順２－１)手順２の確認結果が複合属性（composition属性がcomposite）の場合
・期待周辺構成を参照して依存構成要素を抽出する。
・抽出した各要素に対して(手順１)を適用する。
(手順２－２)手順２の確認結果が複数属性（quantity属性が１より大きい）の場合
・(手順２－２－１)：自身のquantityの値を確認する。
・(手順２－２－２)：冗長化して作成した構成要素を異なる依存構成要素集合に割り当てる。
・(手順２－２－３)：新たに依存構成要素集合に割り当てられた構成要素は、自身が依存する構成要素を抽出して、自身と同じ依存構成要素集合に割り当てる。
※耐障害性要件が指定された構成要素が直接もしくは間接的に依存する構成要素がすべていずれかの依存構成要素集合に含まれるまで(手順２－２－３)の処理を繰り返す。
・(手順２－２－４)：それぞれの依存構成要素が独立か否かを判定する。
(手順２－３)手順２の確認結果が単数属性かつ原始属性の場合
・耐障害性要件の値を確認する。
（手順１）耐障害性要件が指定された構成要素を抽出し、属性を確認する。
（手順２）確認した属性に応じて検証処理を分岐する。
(手順２－１)手順２の確認結果が複合属性（composition属性がcomposite）の場合
・期待周辺構成を参照して依存構成要素を抽出する。
・抽出した各要素に対して(手順１)を適用する。
(手順２－２)手順２の確認結果が複数属性（quantity属性が１より大きい）の場合
・(手順２－２－１)：自身のquantityの値を確認する。
・(手順２－２－２)：冗長化して作成した構成要素を異なる依存構成要素集合に割り当てる。
・(手順２－２－３)：新たに依存構成要素集合に割り当てられた構成要素は、自身が依存する構成要素を抽出して、自身と同じ依存構成要素集合に割り当てる。
※耐障害性要件が指定された構成要素が直接もしくは間接的に依存する構成要素がすべていずれかの依存構成要素集合に含まれるまで(手順２－２－３)の処理を繰り返す。
・(手順２－２－４)：それぞれの依存構成要素が独立か否かを判定する。
(手順２－３)手順２の確認結果が単数属性かつ原始属性の場合
・耐障害性要件の値を確認する。
【0074】
続いて、ある構成要素に耐障害性要件が指定されている場合に、具体化の過程において構成要素の数(quantity)として任意の値を選択しながら具体化することで、具体化構成案生成部３００が冗長構成を含む多様なシステム構成を設計する例を、図２２Ａ～図２２Ｄを用いて説明する。その後、耐障害性検証部６００が、耐障害性制約条件に基づき、設計したシステム構成が耐障害性要件を満たすか否か判定する例を説明する。
【0075】
はじめに、耐障害性制約条件を生成するために、図５Ａ～図５Ｃ、図６Ａ～図６Ｃ、図１１Ａ～図１１Ｄ、図１２Ａ～図１２Ｇで定義した各構成要素に対して追加で定義する項目と、説明のために新たに追加する構成要素の定義を図２１Ａ～図２１Ｃに示す。新たに追加定義した構成要素は、システム全体を表すSystemという構成部品と、ある構成要素が別の構成要素で構成されることを表すIncludeという関係性である。図２１Ｃで定義したSystemは、２種類のアプリケーションXとアプリケーションYを含んで構成され、両アプリケーション間は通信できるシステムを意味するものとして、期待周辺構成”System_includes_two_Applications”にて、SystemはApp_XとApp_Yとの間にIncludeの関係性をもち、かつ、App_XとApp_YはConn_toの関係性をもつという構成情報を定義している。Systemは自身と異なる１種類以上の構成要素の集合で構成される構成要素であるため、その旨を表すためにcompositionプロパティとしてcompositeを設定している。Includeはある構成部品が別の構成部品を含むことを表す関係性であり、SystemがAppを含むことを表すInclude(System, App)を定義している。Includeはある構成要素が別の構成要素を含むことを表すこの関係性であり、その性質上、複数であることは考えられないため、quantityの値を1に限定している。図５Ａ～図５Ｃ、図６Ａ～図６Ｃ、図１１Ａ～図１１Ｄ、図１２Ａ～図１２Ｇですでに定義済みの構成要素には１種以上の異なる構成要素から成り立つ構成要素ではないため原始属性を意味するprimitiveを追加で定義している。図２１Ｂにおいて、関係性の型名に続く”(*,*)”は、その関係性の両端の構成要素は任意であることを表しており、その型名の関係性すべてが対象であることを表す。
【0076】
図２２Ａ～図２２Ｄは、単一障害点のないシステムを1つ設計することを意図して、quantityの値が1のSystemに耐障害性要件１が設定された構成情報を入力とした場合の設計例である。図２２Ａ～図２２Ｄにおいて、エッジ名を省略している部分は、System_とApp_XもしくはApp_Y間はInclude、それ以外は図１３Ａ～図１３Ｅにおける同構成要素間のエッジ名と同じである。また、P._ServerはPhysical_Serverの略称である。
【0077】
まずSystemは、自身の期待周辺構成”System_includes_two_Applications”を満たすように具体化され、App_X(-)およびApp_Y(-)とIncludeで接続され、App_X(-)とApp_Y(-)間がConn_to(-)で接続される構成に具体化される(図２２ＡのS2)。ここで、構成要素の型名に続く”(-)”は、その時点でその構成要素のquantityの値が決まっていないことを表す。Systemの期待周辺構成である”System_includes_two_Applications”では、App_XやApp_Y、その間のConn_toの構成要素を作成することは定義しているが、それらの構成要素の数をどのように設定するかは指定していないため、S2の状態では数が未定となっている。続いてApp_X(-)を具体化する処理を実行する。App_X型の構成部品の期待周辺構成はquantityの値により異なるが、この時点でApp_X(-)のquantityの値が未定であるため、この時点ではいずれの期待周辺構成も適用できる可能性がある。そのため、quantityに任意の値を設定するとともに、その値に応じて具体化を実行する。quantityの値は何らかの選択方針に基づいて決定されるものとする。quantityの選択方針とはたとえば、ランダムに選択する方針や、quantityの値を小さい値から順に大きい値を選択する方針、さらには、耐障害性要件の値+1の値から順に大きくする方針などが考えられ、その場合はquantityの値の選択と耐障害性制約条件の検証を繰り返しながら設計を進める。さらに、quantityの選択方針として、想定されうるquantityの値の候補を一度にすべて生成する方針も考えられる。この場合は、生成されたすべてのquantityの値の候補に基づいて複数の構成を生成し、それらの構成の制約条件の検証を一度に行う。このような選択方針は自動設計の実行前に利用者が決めておく。本稿では、逐次的な処理は行わず、後者の想定されうるquantityの候補を一度に生成する方針を採用して説明する。たとえばquantityの値として1と2が候補として定義されている場合、その両方の候補に基づいて具体化を進める。図２２Ａはその中でquantityの値が1の場合の具体化の流れを示しており、App_X(-)のquantityの値が1の場合、“App_is_hosted_on_Windows_OS”の期待周辺構成を満たすように具体化される(図２２ＡのS3の左半分)。App_Y(-)も同様に、quantityの値として１と2を選択した構成を設計する。図２２では紙面の都合上、quantityの値として1を選択した場合のみを記述しており、“App_is_hosted_on_Ubuntu_OS”の期待周辺構成を満たすように具体化される(図２２ＡのS3の右半分)。その後、Windows（登録商標）とUbuntu（登録商標）がそれぞれ“OS_is_hosted_on_Machine”の期待周辺構成を満たすように具体化され、その具体化によって作成されたMachine自身がPhysical_Serverに具体化される(図２２ＢのS4)。
【0078】
次に、App_XとApp_Y間のConn_to(-)を具体化する処理を実行する。Conn_to(-)もこの時点ではquantityの値が未定であるため、quantityの値として1と2を選択した構成を設計する。App_Y(-)と同様、図２２では紙面の都合上、quantityの値として1を選択した場合のみを記述している。この場合、Conn_to(App, App)の“Connection_between_Machines”を満たすように、両端のApp_XとApp_YをホストするPhysical_Server間のConn_toに具体化する(図２２ＢのS5)。最後に、Physical_Server間のConn_toが“Connection_between_Machine_and_Switch” の期待周辺構成を満たすように、Switchを経由して接続される構成に具体化されて、具体化処理を完了する(図２２ＣのS6)。
【0079】
一方、図２２Ａ～図２２ＣのS7～S10に示す構成は、quantityの値として2を選択した場合の設計例であり、図２２ＡのS7は、S2の構成において、App_X(-)およびApp_Y(-)のquantityとして１ではなく２を選択した場合の構成である。quantityの値として２を選択した場合、“For_Multiplexed_Node”の期待周辺構成を満たすように具体化され、それぞれ２個のApp_XとApp_Yが生成される構成に具体化される。その後、Conn_to(-)のquantityに対しては1を選択したとする。その場合、Conn_to(-)は“For_Single_Edge_between_Multiplexed_Nodes”の期待周辺構成を満たすように２個のApp_Xと２個のApp_Yが互いに各１本のConn_toで接続される構成に具体化される(図２２ＢのS8)。その後、App_XとApp_Y間の4本のConn_toそれぞれが“Connection_between_Machines”の期待周辺構成を満たすように具体化され(図２２ＢのS9)、Physical_Server間の4本のConn_toそれぞれが“Connection_between_Machine_and_Switch”の期待周辺構成を満たすように具体化されて具体化処理が完了する(図２２ＣのS10)。
【0080】
図２２Ｂ～図２２ＣのS11～S13に示す構成は、S7の状態からさらに、Conn_to(-)のquantityの値として２を選択した場合の設計例であり、Conn_to(-)は”For_Multiplexed_Edge”の期待周辺構成を満たすように両端の構成部品間に2本のConn_toが張られた構成に具体化される(図２２ＢのS11)。その後は、図13のS5～S10と同様の具体化処理が実行され、App_X(2)とApp_Y(2)との間の1本のConn_toがPhysical_Server間をSwitch経由で接続する構成に具体化される(図２２ＢのS12)。最後に、App_X(2)とApp_Y(2)との間の残りの1本のConn_toも具体化されることで具体化処理が完了する(図２２ＣのS13)。
【0081】
最後に、図２２ＤのS14に示す構成は、図２２Ｂ～図２２ＣのS12～S13に示す構成と同様に、App_X(-)とApp_Y(-)、Conn_to(-)のquantityの値として２を選択した場合の設計例であるが、Windows（登録商標）とUbuntu（登録商標）をホストするPhysical_Serverを４つ作成するのではなく、各種OSが１つずつ１台のPhysical_Server上にホストされた構成が選択された場合の構成例である。これは、第１の実施形態でも説明したように、ある構成要素の期待周辺構成を満たすように具体化を行う際、必ずしも新たな構成要素を作成するのではなく、既存の構成要素がすでに存在していればその構成要素を利用した構成も選択できるという機能に基づいて設計された構成である。
図２２Ａ～図２２Ｄでは、quantityの値として1もしくは2が選択された構成の設計を中心に例示したが、quantityの値の候補として３以上の値を選択する方針を事前に定義しておくことで、3重以上に冗長化された構成も設計可能である。
図２２Ａ～図２２Ｄでは、quantityの値として1もしくは2が選択された構成の設計を中心に例示したが、quantityの値の候補として３以上の値を選択する方針を事前に定義しておくことで、3重以上に冗長化された構成も設計可能である。
【0082】
このように、quantityの値が未定の構成要素に対しては任意のquantityの値を選択して具体化することで、図２２Ｃ～図２２ＤのS6やS10、S13、S14をはじめとする、冗長構成を含む多様なシステム構成を設計できる。最後に、設計されたシステム構成が耐障害性要件を満たすか否かを検証する。
【0083】
まず、図２２ＣのS6の構成の耐障害性要件の検証方法を説明する。図２１Ｃで定義した通りSystemはcomposite属性（複合属性）のため、Systemが耐障害性要件１を満たす条件は、Systemが依存するApp_X(-)、App_Y(-)、Conn_to(-)がそれぞれ耐障害性要件１を満たすことである。続いてApp_X(-)が耐障害性要件１を満たすか否かの検証を行う。S6の構成では、App_X(-)は自身のquantityの値として１を選択し、Windows（登録商標）にホストされる構成に具体化されている。図２１Ａで定義したように、App_Xは原子属性（composition: primitive）であり、かつquantityが１の単数属性をもつ構成要素であるため、App_Xの耐障害性制約条件は、App_Xに設定された耐障害性要件が０であることである。耐障害性検証部６００の耐障害性制約条件生成部６１０は、図２０の式に基づいて、App_Xが満たすべき耐障害性要件の制約条件（「耐障害性要件が０であること」）を生成する。App_Xについて生成された制約条件（「耐障害性要件が０であること」）は耐障害性制約条件１（「耐障害性要件が１であること」）を満たさないため、耐障害性検証部６００の耐障害性制約条件判定部６２０は、S6のシステム構成は耐障害性要件１を満たさないと判定する。
【0084】
図２２ＣのS10の構成では、App_X(-)は自身のquantityの値として２を選択しており、自身のquantityの値は耐障害性要件１よりも大きい。また、図１９Ａの構成と同様に、App_X(2)を冗長化して具体化された各App_Xと、そのApp_Xが依存するWindows（登録商標）とその間のHosted_on、およびWindows（登録商標）が依存するPhysical_Serverとその間のHosted_onからなる2つの依存構成要素集合が非共有である。したがって、App_X(2)は耐障害性要件１を満たすと判定する。同様の理由で、App_Y(2)も耐障害性要件1を満たすと判定する。一方、Conn_to(-)は自身のquantityの値として１を選択しており、そのConn_toが最終的にPhysical_Server間をSwitch経由で接続する構成に具体化されている。すなわち、Conn_to(-)は原始属性かつ単数属性の構成要素であり、このConn_to(-)の耐障害性制約条件は、Conn_to(-)に設定された耐障害性要件が０であることである（耐障害性制約条件生成部６１０が図２０の式に基づいてこの制約条件を生成する。以下同様である。）。したがって、Conn_toは耐障害性要件１を満たさないため、耐障害性制約条件判定部６２０は、S10のシステム構成は耐障害性要件１を満たさないと判定する。
【0085】
図２２ＣのS13の構成は、S10の構成と同じ理由でApp_X(-)とApp_Y(-)は耐障害性制約条件を満たした構成に具体化されている。Conn_to(-)のquantityの値としては2が選択され、Conn_to(2)が2重に冗長化して具体化された各Conn_toと、そのConn_toから具体化された、Switchと、MachineとSwitch間のConn_toからなる2つの依存構成要素集合が非共有である。したがって、Conn_to(2)も耐障害性要件1を満たすと判定する。耐障害性要件1が指定されたSystemが依存するApp_X(-)、App_Y(-)、Conn_to(-)がすべて耐障害性要件1を満たすと判定されるため、耐障害性制約条件判定部６２０は、S13のシステム構成は耐障害性要件１を満たすと判定する。
【0086】
最後に、図２２ＤのS14の構成は、App_X(-)とApp_Y(-)はともにquantity2が選択されており、App_X(2)の2つの依存構成要素集合は非共有であり、かつApp_Y(2)の2つの依存構成要素集合も非共有である。さらに、Conn_to(-)もquantity2が選択されており、Conn_to(2)の2つの依存構成要素集合は互いに非共有である。したがって、耐障害性制約条件判定部６２０は、S14のシステム構成は耐障害性要件１を満たすと判定する。
【0087】
（動作）
続いて、第２の実施形態におけるシステム自動設計の処理を図２３に示す。図２３のフローチャートは、図１４に示す第１の実施形態におけるシステム自動設計の動作に対して、quantityの値の候補の抽出(F12、F13)、および耐障害性制約条件の生成処理(F14)が追加されている。具体的には、入出力部１００がシステム要件を受け付けて、システム設計を開始後(F1)、構成具体化部２００がシステム要件もしくは設計中のシステム構成の選択(F2)と、そのシステム構成内で具体化が可能な構成要素の抽出を行った後(F3)、選択した構成要素のquantityの値が確定しているか否かを確認する(F12)。quantityの値が確定していない場合(F12のNo)、事前に設計者が決めておいたquantityの選択方針に基づいてquantityの値のすべての候補を決定する(F13)。quantityの値が確定している場合(F12のYes)、もしくは、F13においてquantityの値のすべての候補が決定された場合、F4の処理(すなわち図１５Ａ、図１５Ｂに示すG1～G13の処理)に基づいてquantityの値に応じた具体化が実行される。その後、実際に１つ以上のシステム構成が生成されたかを確認し（F5）、１つ以上のシステム構成が生成された場合（F5のYes）、耐障害性制約条件生成部６１０が、生成されたシステム構成内で耐障害性要件が設定された構成要素に対する耐障害性制約条件を生成する(F14)。次に制約検証部５００と耐障害性制約条件判定部６２０が、耐障害性制約条件を含む、システム構成に含まれるすべての制約条件を判定する(F6)。以降の処理は、第１の実施形態と同様である。
続いて、第２の実施形態におけるシステム自動設計の処理を図２３に示す。図２３のフローチャートは、図１４に示す第１の実施形態におけるシステム自動設計の動作に対して、quantityの値の候補の抽出(F12、F13)、および耐障害性制約条件の生成処理(F14)が追加されている。具体的には、入出力部１００がシステム要件を受け付けて、システム設計を開始後(F1)、構成具体化部２００がシステム要件もしくは設計中のシステム構成の選択(F2)と、そのシステム構成内で具体化が可能な構成要素の抽出を行った後(F3)、選択した構成要素のquantityの値が確定しているか否かを確認する(F12)。quantityの値が確定していない場合(F12のNo)、事前に設計者が決めておいたquantityの選択方針に基づいてquantityの値のすべての候補を決定する(F13)。quantityの値が確定している場合(F12のYes)、もしくは、F13においてquantityの値のすべての候補が決定された場合、F4の処理(すなわち図１５Ａ、図１５Ｂに示すG1～G13の処理)に基づいてquantityの値に応じた具体化が実行される。その後、実際に１つ以上のシステム構成が生成されたかを確認し（F5）、１つ以上のシステム構成が生成された場合（F5のYes）、耐障害性制約条件生成部６１０が、生成されたシステム構成内で耐障害性要件が設定された構成要素に対する耐障害性制約条件を生成する(F14)。次に制約検証部５００と耐障害性制約条件判定部６２０が、耐障害性制約条件を含む、システム構成に含まれるすべての制約条件を判定する(F6)。以降の処理は、第１の実施形態と同様である。
【0088】
（効果）
以上説明したように、第２の実施形態によれば、耐障害性要件を指定することにより、構成要素の属性（composition属性とquantity属性の値）に応じて、異なる多重度の冗長構成を含む多様なシステム構成を自動設計することができる。さらに、耐障害性要件を指定するだけで、設計されうる多様なシステム構成の中から、耐障害性要件を満たすシステム構成のみを選別して設計結果として出力することができる。
以上説明したように、第２の実施形態によれば、耐障害性要件を指定することにより、構成要素の属性（composition属性とquantity属性の値）に応じて、異なる多重度の冗長構成を含む多様なシステム構成を自動設計することができる。さらに、耐障害性要件を指定するだけで、設計されうる多様なシステム構成の中から、耐障害性要件を満たすシステム構成のみを選別して設計結果として出力することができる。
【0089】
＜第３の実施形態＞
次に本発明の第３の実施形態について、図２４～図２５を用いて説明する。第２の実施形態にかかるシステム自動設計装置９１０では、様々な冗長構成を含むシステム構成を設計することができる。さらに、各構成要素が耐障害性要件を満たすための制約条件を構成要素の属性に基づいて作成することで、耐障害性要件を満たすシステム構成を自動設計できる。第２の実施形態では、各構成要素を任意の数で冗長化して具体化することでシステム構成を具体化し、具体化が完了したシステム構成に対して耐障害性要件が満たされているかを検証する。その後、耐障害性要件を満たしていないと判定した場合は、各構成要素の数を変更してシステム設計をやり直す。このように、耐障害性要件を満たすシステム構成が設計されるまで、システム構成の具体化と耐障害性要件の検証を繰り返す必要があるため、システム設計に多大な時間がかかる。これに対し、第３の実施形態に係るシステム自動設計装置９２０では、システム設計の途中の任意のタイミングで、設計途中のシステム構成が耐障害性要件を満たしうるか否かを判定し、その時点で耐障害性要件を満たしえないと判定した構成案を棄却することで、耐障害性要件を満たしうる構成に絞って設計を進める。これにより、耐障害性要件を満たしえない無駄な構成の設計を早い段階で棄却できるため、耐障害性要件を満たすシステム構成を短時間で設計できる。
次に本発明の第３の実施形態について、図２４～図２５を用いて説明する。第２の実施形態にかかるシステム自動設計装置９１０では、様々な冗長構成を含むシステム構成を設計することができる。さらに、各構成要素が耐障害性要件を満たすための制約条件を構成要素の属性に基づいて作成することで、耐障害性要件を満たすシステム構成を自動設計できる。第２の実施形態では、各構成要素を任意の数で冗長化して具体化することでシステム構成を具体化し、具体化が完了したシステム構成に対して耐障害性要件が満たされているかを検証する。その後、耐障害性要件を満たしていないと判定した場合は、各構成要素の数を変更してシステム設計をやり直す。このように、耐障害性要件を満たすシステム構成が設計されるまで、システム構成の具体化と耐障害性要件の検証を繰り返す必要があるため、システム設計に多大な時間がかかる。これに対し、第３の実施形態に係るシステム自動設計装置９２０では、システム設計の途中の任意のタイミングで、設計途中のシステム構成が耐障害性要件を満たしうるか否かを判定し、その時点で耐障害性要件を満たしえないと判定した構成案を棄却することで、耐障害性要件を満たしうる構成に絞って設計を進める。これにより、耐障害性要件を満たしえない無駄な構成の設計を早い段階で棄却できるため、耐障害性要件を満たすシステム構成を短時間で設計できる。
【0090】
（構成）
図２４は、第３の実施形態に係るシステム自動設計装置の構成の一例を示す図である。図２４に示すように、システム自動設計装置９２０は、第２の実施形態に係るシステム自動設計装置９１０の構成に加え、設計状態判定部７００を有している。
設計状態判定部７００には、耐障害性制約条件を生成する条件、すなわち、設計中のシステム構成がどのような条件を満たしている場合に、設計中のシステム構成（に含まれる耐障害性要件が設定された構成要素）が耐障害性要件を満たしうるかを検証するか、に関する情報が定義される。耐障害性制約条件を生成する条件としては例えば、設計中のシステム構成が一段階具体化された時点や、特定の構成要素の具体化が完了した時点など、設計者が自由に設定できる。設計状態判定部７００は、構成具体化部２００から設計中のシステムの構成情報を受け取ると、前記システムの構成情報が、自身に定義された耐障害性制約条件を生成する条件を満たすか否かを判定し、その結果を構成具体化部２００に返す。構成具体化部２００は、設計途中のシステム構成を一段階具体化するごとに、設計中のシステム構成の情報を設計状態判定部７００に渡し、設計状態判定部７００からの判定結果を受け取る。条件を満たす旨の判定結果を受け取った場合、耐障害性検証部６００にシステムの構成情報を渡す。一方、条件を満たさない旨の判定結果を受け取った場合、システム構成の具体化処理を継続する。
図２４は、第３の実施形態に係るシステム自動設計装置の構成の一例を示す図である。図２４に示すように、システム自動設計装置９２０は、第２の実施形態に係るシステム自動設計装置９１０の構成に加え、設計状態判定部７００を有している。
設計状態判定部７００には、耐障害性制約条件を生成する条件、すなわち、設計中のシステム構成がどのような条件を満たしている場合に、設計中のシステム構成（に含まれる耐障害性要件が設定された構成要素）が耐障害性要件を満たしうるかを検証するか、に関する情報が定義される。耐障害性制約条件を生成する条件としては例えば、設計中のシステム構成が一段階具体化された時点や、特定の構成要素の具体化が完了した時点など、設計者が自由に設定できる。設計状態判定部７００は、構成具体化部２００から設計中のシステムの構成情報を受け取ると、前記システムの構成情報が、自身に定義された耐障害性制約条件を生成する条件を満たすか否かを判定し、その結果を構成具体化部２００に返す。構成具体化部２００は、設計途中のシステム構成を一段階具体化するごとに、設計中のシステム構成の情報を設計状態判定部７００に渡し、設計状態判定部７００からの判定結果を受け取る。条件を満たす旨の判定結果を受け取った場合、耐障害性検証部６００にシステムの構成情報を渡す。一方、条件を満たさない旨の判定結果を受け取った場合、システム構成の具体化処理を継続する。
【0091】
続いて、第３の実施形態におけるシステム自動設計装置が、システムの設計途中で耐障害性要件を満たしえない構成を棄却する例を、図２２Ａ～図２２Ｄを用いて説明する。設計状態判定部７００に設定された耐障害性制約条件を生成する条件は、システム構成が１段階具体化されること、とする。最初に、図２２Ａにおけるシステム要件(S1)から図２２ＣのS6の構成が設計される具体化の流れを対象に説明する。まず、S1からS2の構成に具体化された時点で、耐障害性制約条件が生成され、Systemが耐障害性要件１を満たしうるかを判定する処理が実行される。Systemは複合属性の構成要素であり、App_X(-)とApp_Y(-)とその間のConn_to(-)がすべて耐障害性要件１を満たしていれば、Systemは耐障害性要件１を満たしていると判定できる。S2の構成の時点では、App_X(-)、App_Y(-)、Conn_to(-)はquantityの値が未定である。したがって、耐障害性要件を満たしうる可能性があるため、この時点では、設計状態判定部７００はSystemが耐障害性要件１を満たしうると判定して、構成具体化部２００は設計を継続する。その後、S3の構成に具体化された時点で再度耐障害性要件の検証を行う。この時点で、App_Xのquantityの値として１が選択されており、耐障害性要件が0でなければならないという耐障害性制約条件を満たしていないため、App_Xは耐障害性要件1を満たさないと判定する。したがって、この時点でSystemは障害性要件１を満たしえないと判定できるので、S3以降のシステム構成を棄却し、他の構成案の設計を進める。これにより、耐障害性を満たしえない構成の具体化処理(S4～S6）は実行されず、システムの設計時間が短縮される。
【0092】
S10のシステム構成が設計される具体化の流れにおいては、S7の構成の時点では、App_X(2)とApp_Y(2)のquantityの値はともに２であり、耐障害性要件の1よりも大きいという耐障害性制約条件を満たしている。また、Conn_to(-)はこの時点ではquantityの値が未定であり、耐障害性要件を満たす可能性があるため、この時点では耐障害性要件１を満たしうると判定して具体化処理を継続する。その後、S8の構成に具体化された時点で、Conn_to(-)のquantityの値として１が選択された具体化されるため、この時点でConn_to(-)は耐障害性要件1を満たさないと判定される。したがって、Systemは耐障害性要件1を満たしえないと判定し、構成具体化部２００は以降の具体化処理(S9、S10)は実行しない。一方、図22を用いたシステムの設計例の説明で述べた通り、S13およびS14のシステム構成は耐障害性要件１を満たす構成であり、具体化の過程で設計途中のシステム構成が棄却されることはない。
【0093】
（動作）
続いて、第３の実施形態におけるシステム自動設計の動作を図２５に示す。図２５のフローチャートでは、第２の実施形態におけるステム自動設計のフローチャートに対して、耐障害性制約条件を生成する条件を検証する処理(F15)が新たに追加されている。具体的には、構成要素に具体化パターンを適用することで１つ以上のシステム構成が生成された場合に(F5のYes)、設計状態判定部７００が、自身に設定された、耐障害性制約条件を生成する条件を満たすか否かを判定（F15）し、条件を満たす場合には(F15のYes)、耐障害性制約条件生成部６１０が、設計中のシステム構成内に含まれる耐障害性要件が指定された構成要素の耐障害性制約条件を生成し(F14)、制約検証部５００と耐障害性制約条件判定部６２０が、耐障害性制約条件を含む、システム構成に含まれるすべての制約条件を判定する(F6)。一方、耐障害性制約条件を生成するための条件を満たさない場合(F15のNo)、耐障害性制約条件を生成せずに、制約検証部５００が、システム構成に含まれる制約条件を判定する(F6)。以降の処理は、第１の実施形態と同様である。
続いて、第３の実施形態におけるシステム自動設計の動作を図２５に示す。図２５のフローチャートでは、第２の実施形態におけるステム自動設計のフローチャートに対して、耐障害性制約条件を生成する条件を検証する処理(F15)が新たに追加されている。具体的には、構成要素に具体化パターンを適用することで１つ以上のシステム構成が生成された場合に(F5のYes)、設計状態判定部７００が、自身に設定された、耐障害性制約条件を生成する条件を満たすか否かを判定（F15）し、条件を満たす場合には(F15のYes)、耐障害性制約条件生成部６１０が、設計中のシステム構成内に含まれる耐障害性要件が指定された構成要素の耐障害性制約条件を生成し(F14)、制約検証部５００と耐障害性制約条件判定部６２０が、耐障害性制約条件を含む、システム構成に含まれるすべての制約条件を判定する(F6)。一方、耐障害性制約条件を生成するための条件を満たさない場合(F15のNo)、耐障害性制約条件を生成せずに、制約検証部５００が、システム構成に含まれる制約条件を判定する(F6)。以降の処理は、第１の実施形態と同様である。
【0094】
（効果）
以上説明したように、第３の実施形態によれば、第２の実施形態の効果に加え、システム設計の途中の段階で耐障害性要件を満たしえない構成を棄却することができ、耐障害性要件を満たすシステム構成を短時間で設計できる。
以上説明したように、第３の実施形態によれば、第２の実施形態の効果に加え、システム設計の途中の段階で耐障害性要件を満たしえない構成を棄却することができ、耐障害性要件を満たすシステム構成を短時間で設計できる。
【0095】
（最小構成）
図２６は、最小構成を有するシステム自動設計の構成を示すブロック図である。
システム自動設計装置８００は、入力手段８１０と、構成生成手段８２０とを備える。入力手段８１０は、冗長化の要求を含むシステムの要件を受け付ける。構成生成手段８２０は、前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成する。入力手段８１０は、実施形態の入出力部１００に対応し、構成生成手段８２０は、実施形態の構成具体化部２００と具体化構成案生成部３００に対応する。
図２６は、最小構成を有するシステム自動設計の構成を示すブロック図である。
システム自動設計装置８００は、入力手段８１０と、構成生成手段８２０とを備える。入力手段８１０は、冗長化の要求を含むシステムの要件を受け付ける。構成生成手段８２０は、前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成する。入力手段８１０は、実施形態の入出力部１００に対応し、構成生成手段８２０は、実施形態の構成具体化部２００と具体化構成案生成部３００に対応する。
【0096】
図２７は最小構成を有するシステム自動設計の動作を示すフローチャートである。
入力手段８１０は、冗長化の要求を含むシステムの要件を受け付ける（８０１）。次に構成生成手段８２０が、前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成する（８０２）。
入力手段８１０は、冗長化の要求を含むシステムの要件を受け付ける（８０１）。次に構成生成手段８２０が、前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成する（８０２）。
【0097】
なお、上述した実施形態におけるシステム自動設計装置８００、９００、９１０、９２０の一部をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、システム自動設計装置８００、９００、９１０、９２０に内蔵されたコンピュータシステムであって、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や周辺機器等のハードウェアを含むものとする。
【0098】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
【0099】
また、上述した実施形態におけるシステム自動設計装置８００、９００、９１０、９２０の一部、または全部を、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等の集積回路として実現してもよい。システム自動設計装置９００、９１０、９２０の各機能部は個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。
【0100】
以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。また、本発明の一態様は、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。また、上記各実施形態や変形例に記載された要素であり、同様の効果を奏する要素同士を置換した構成も含まれる。
【0101】
（付記１）
冗長化の要求を含むシステムの要件を受け付ける入力手段と、前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成する構成生成手段と、を備えるシステム自動設計装置である。
冗長化の要求を含むシステムの要件を受け付ける入力手段と、前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成する構成生成手段と、を備えるシステム自動設計装置である。
【0102】
（付記２）
前記システムの要件は、前記構成要素の冗長度合いを示すパラメータを含み、前記構成生成手段は、前記パラメータの値に応じて具体化パターンを選択することで、冗長度の異なる複数の前記システム構成案を生成する、付記１に記載のシステム自動設計装置である。
前記システムの要件は、前記構成要素の冗長度合いを示すパラメータを含み、前記構成生成手段は、前記パラメータの値に応じて具体化パターンを選択することで、冗長度の異なる複数の前記システム構成案を生成する、付記１に記載のシステム自動設計装置である。
【0103】
（付記３）
前記構成生成手段は、前記冗長度合いを示すパラメータが２以上の構成部品を、前記冗長度合いを示すパラメータの数だけ、自身と同じ型の構成部品を複数生成することで具体化する、付記１又は付記２に記載のシステム自動設計装置である。
前記構成生成手段は、前記冗長度合いを示すパラメータが２以上の構成部品を、前記冗長度合いを示すパラメータの数だけ、自身と同じ型の構成部品を複数生成することで具体化する、付記１又は付記２に記載のシステム自動設計装置である。
【0104】
（付記４）
前記構成生成手段は、前記冗長度合いを示すパラメータが２以上の関係性に対して、前記関係性を具体化する際に両端の構成部品を仲介する構成部品が存在しない場合は、前記両端の構成部品間を互いに各n本の関係性で接続する構成に具体化し、前記関係性を具体化する際に両端の構成部品を仲介する構成部品が存在する場合は、片側の構成部品と仲介するn個の構成部品が互いに各1本の関係性で接続され、かつもう一方の構成部品と仲介するn個の構成部品が互いに各１本の関係性で接続された構成に具体化する、付記１から付記３の何れか１つに記載のシステム自動設計装置である。
前記構成生成手段は、前記冗長度合いを示すパラメータが２以上の関係性に対して、前記関係性を具体化する際に両端の構成部品を仲介する構成部品が存在しない場合は、前記両端の構成部品間を互いに各n本の関係性で接続する構成に具体化し、前記関係性を具体化する際に両端の構成部品を仲介する構成部品が存在する場合は、片側の構成部品と仲介するn個の構成部品が互いに各1本の関係性で接続され、かつもう一方の構成部品と仲介するn個の構成部品が互いに各１本の関係性で接続された構成に具体化する、付記１から付記３の何れか１つに記載のシステム自動設計装置である。
【0105】
（付記５）
前記構成生成手段は、前記構成要素の前記具体化パターンとして、前記構成要素自身を、可用性をもつ構成要素に具体化することで耐障害性を向上させる具体化パターンと、前記構成要素を複数用意して冗長化させることで耐障害性を向上させる具体化パターンと、を生成し、生成した前記具体化パターンから選択して前記システム構成案を生成する、付記１から付記４の何れか１つに記載のシステム自動設計装置である。
前記構成生成手段は、前記構成要素の前記具体化パターンとして、前記構成要素自身を、可用性をもつ構成要素に具体化することで耐障害性を向上させる具体化パターンと、前記構成要素を複数用意して冗長化させることで耐障害性を向上させる具体化パターンと、を生成し、生成した前記具体化パターンから選択して前記システム構成案を生成する、付記１から付記４の何れか１つに記載のシステム自動設計装置である。
【0106】
（付記６）
耐障害性要件が設定された前記構成要素を含む、具体化途中もしくは具体化が完了したシステム構成に対して、耐障害性要件が設定された構成要素が耐障害性要件を満たしうるか否かを検証する耐障害性検証手段、をさらに備え、前記構成生成手段は、前記耐障害性要件を満たす前記システム構成案を選択する、付記１から付記５の何れか１つに記載のシステム自動設計装置である。
耐障害性要件が設定された前記構成要素を含む、具体化途中もしくは具体化が完了したシステム構成に対して、耐障害性要件が設定された構成要素が耐障害性要件を満たしうるか否かを検証する耐障害性検証手段、をさらに備え、前記構成生成手段は、前記耐障害性要件を満たす前記システム構成案を選択する、付記１から付記５の何れか１つに記載のシステム自動設計装置である。
【0107】
（付記７）
前記耐障害性検証手段は、前記構成要素が前記耐障害性要件を満たしうるか否かを検証する際に、当該構成要素が、自身と異なる１種類より多くの構成要素の集合で構成される構成要素である複合属性を有するか、１種類のみの構成要素である原始属性を有するか、および、その構成要素が１個のみ存在する構成要素である単数属性を有するか、２個以上存在する可能性がある構成要素である複数属性を有するか、に基づいて判定する、付記６に記載のシステム自動設計装置である。
前記耐障害性検証手段は、前記構成要素が前記耐障害性要件を満たしうるか否かを検証する際に、当該構成要素が、自身と異なる１種類より多くの構成要素の集合で構成される構成要素である複合属性を有するか、１種類のみの構成要素である原始属性を有するか、および、その構成要素が１個のみ存在する構成要素である単数属性を有するか、２個以上存在する可能性がある構成要素である複数属性を有するか、に基づいて判定する、付記６に記載のシステム自動設計装置である。
【0108】
（付記８）
前記構成要素が前記耐障害性要件を満たしうるか否かを構成要素の属性に応じて判定する具体的な方法として、前記構成要素が複数属性をもつ構成要素であれば、前記構成要素の数が前記耐障害性要件以上であり、かつ、前記構成要素が直接および間接的に依存する前記構成要素の集合が互いに疎であること、前記構成要素が複合属性かつ単数属性をもつ構成要素であれば、前記構成要素が直接的に依存するすべての構成要素が耐障害性要件を満たしていること、前記構成要素が原始属性かつ単体属性を持つ構成要素であれば、指定された耐障害性要件が０であること、を判定基準とする、付記６又は付記７に記載のシステム自動設計装置である。
前記構成要素が前記耐障害性要件を満たしうるか否かを構成要素の属性に応じて判定する具体的な方法として、前記構成要素が複数属性をもつ構成要素であれば、前記構成要素の数が前記耐障害性要件以上であり、かつ、前記構成要素が直接および間接的に依存する前記構成要素の集合が互いに疎であること、前記構成要素が複合属性かつ単数属性をもつ構成要素であれば、前記構成要素が直接的に依存するすべての構成要素が耐障害性要件を満たしていること、前記構成要素が原始属性かつ単体属性を持つ構成要素であれば、指定された耐障害性要件が０であること、を判定基準とする、付記６又は付記７に記載のシステム自動設計装置である。
【0109】
（付記９）
前記構成要素が耐障害性要件を満たしうるか否かの検証を、具体化途中のシステム構成も対象に含め、任意のタイミングで実行する、付記６から付記８の何れかに記載のシステム自動設計装置である。
前記構成要素が耐障害性要件を満たしうるか否かの検証を、具体化途中のシステム構成も対象に含め、任意のタイミングで実行する、付記６から付記８の何れかに記載のシステム自動設計装置である。
【0110】
（付記１０）
冗長化の要求を含むシステムの要件を受け付けるステップと、前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成するステップと、を有するシステム自動設計方法である。
冗長化の要求を含むシステムの要件を受け付けるステップと、前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成するステップと、を有するシステム自動設計方法である。
【0111】
（付記１１）
コンピュータに、冗長化の要求を含むシステムの要件を受け付けるステップと、前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成するステップと、を実行させるプログラムである。
コンピュータに、冗長化の要求を含むシステムの要件を受け付けるステップと、前記システムの構成要素を冗長化しながら具体化する方法を定めた所定の具体化パターンの中から、前記システムの要求に応じた前記具体化パターンを選択して、前記システムのシステム構成案を生成するステップと、を実行させるプログラムである。
【符号の説明】
【0112】
１００・・・入出力部
２００・・・構成具体化部
３００・・・具体化構成案生成部
３１０・・・冗長構成案生成部
３２０・・・非冗長構成案生成部
４００・・・設計情報記録部
５００・・・制約検証部
６００・・・耐障害性検証部
６１０・・・耐障害性制約条件生成部
６２０・・・耐障害性制約条件判定部
７００・・・設計状態判定部
８００・・・システム自動設計装置
８１０・・・入力手段
８２０・・・構成生成手段
９００、９１０、９２０・・・システム自動設計装置
２００・・・構成具体化部
３００・・・具体化構成案生成部
３１０・・・冗長構成案生成部
３２０・・・非冗長構成案生成部
４００・・・設計情報記録部
５００・・・制約検証部
６００・・・耐障害性検証部
６１０・・・耐障害性制約条件生成部
６２０・・・耐障害性制約条件判定部
７００・・・設計状態判定部
８００・・・システム自動設計装置
８１０・・・入力手段
８２０・・・構成生成手段
９００、９１０、９２０・・・システム自動設計装置
【図1】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図5C】
【図6A】
【図6B】
【図6C】
【図7A】
【図7B】
【図7C】
【図8A】
【図8B】
【図9】
【図10A】
【図10B】
【図10C】
【図10D】
【図10E】
【図11A】
【図11B】
【図11C】
【図11D】
【図12A】
【図12B】
【図12C】
【図12D】
【図12E】
【図12F】
【図12G】
【図13A】
【図13B】
【図13C】
【図13D】
【図13E】
【図14】
【図15A】
【図15B】
【図16】
【図17】
【図18A】
【図18B】
【図19A】
【図19B】
【図20】
【図21A】
【図21B】
【図21C】
【図22A】
【図22B】
【図22C】
【図22D】
【図23】
【図24】
【図25】
【図26】
【図27】