(57)【要約】  非機能要件に影響する様々な要因を考慮しつつ、指定された非機能要件を満たすシステム構成の候補を自動的かつ効率的に導出できる設計支援装置が開示される。係る設計支援装置は、非機能要件を受け付ける受付手段と、２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受付手段において受け付けられた前記非機能要件を満たすための前記属性値の制約条件を生成する制約条件生成手段を備える。
2015162889.tif 000002
【特許請求の範囲】
【請求項１】
非機能要件を受け付ける受付手段と、
２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受付手段において受け付けられた前記非機能要件を満たすための前記属性値の制約条件を生成する制約条件生成手段
を備えた設計支援装置。
【請求項２】
前記制約条件生成手段は、前記制約条件に基づいて制約充足問題を定式化する
請求項１に記載の設計支援装置。
【請求項３】
前記制約充足問題を解くことによって、前記非機能要件を満たす前記属性値を導出する制約ソルバーを
更に備えた請求項２に記載の設計支援装置。
【請求項４】
前記システムの設計情報と、当該設計情報に対応する属性情報を保持するモデル格納手段と、
前記制約ソルバーが導出した前記属性値と、前記モデル格納手段が保持する前記属性情報との比較の結果に基づいて、前記受付手段において受け付けられた前記非機能要件を満たす前記属性情報を検索するモデル検索手段と、を更に備えた請求項３に記載の設計支援装置。
【請求項５】
前記モデル検索手段は、
前記属性情報を順位付ける推薦度を算出し、該推薦度に基づいて前記属性情報を提示する
請求項４に記載の設計支援装置。
【請求項６】
前記モデル格納手段は、
前記属性情報が複数対応付けられた前記設計情報を保持する
請求項４または５に記載の設計支援装置。
【請求項７】
前記属性値条件情報は、
前記非機能要件の複数の状態と、当該各非機能要件の状態を満たすために必要な前記属性値の条件とを対応付けた情報を含む、
ことを特徴とする請求項１〜６のいずれか１項に記載の設計支援装置。
【請求項８】
非機能要件を受け付け、
２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受け付けられた前記非機能要件を満たすための前記属性値の制約条件を生成する
設計支援方法。
【請求項９】
コンピュータに、
非機能要件を受け付ける処理と、
２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受け付けられた前記非機能要件を満たすための前記属性値の制約条件を生成する処理と
を、実行させる設計支援プログラムを記録するプログラム記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムの設計を支援する設計支援装置、方法、およびプログラム記録媒体に関する。
【背景技術】
【０００２】
コンピュータシステム（以下、システムと呼ぶ）の開発においては、顧客から指定される各種要件を満たすようにシステムの設計（アーキテクチャ）を決める必要がある。【０００３】
顧客から指定される要件には、システムの品質（QoS：Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）がある。システムの品質を表す指標として、性能や可用性などの非機能に関する要件（非機能要件）がある。【０００４】
非機能要件は、システムの規模や社会的な影響度ごとに、開発対象のシステムが満たすべきサービスレベルの評価項目と水準を数段階のレベルで定義した、「非機能要求グレード表」や、ＩＴＩＬ（Information Technology Infrastructure Library）の内容に基づいて決定されることが多い。【０００５】
しかしながら、システムの品質は、ＨＷ（Hardware）の構成やＭＷ（Middleware）の設定項目等に関する様々な設計パラメータの影響を受けると共に、非機能要件を満たす設計パラメータの組み合わせも多数存在するので、適切に設計するには高度な知識が必要となる。【０００６】
そこで、非機能要件を満たす設計パラメータの組み合わせを、自動的かつ効率的に導出できる設計支援装置が求められている。【０００７】
関連技術として、特許文献１は、Ｗｅｂサービスを連携させて作るＳＯＡ（Service Oriented Architecture）のシステムの設計に関する技術を開示する。特許文献１に記載の技術では、個々のＷｅｂサービスに対して、指定された非機能要件を実現できる処理を、使用するソフトウェア（ミドルウェア）製品への実装可能性と非機能要件の優先度を考慮しながら付与する。これにより、適切なＷｅｂサービスの組み合わせが決定できる。【０００８】
特許文献２は、Ｗｅｂサービスに対して、システム全体の非機能要件に影響する平均処理時間などの値（性能値）を予め登録し、指定した要件に合う、または近いサービスを抽出しながら設計を行う技術を開示する。【０００９】
特許文献３は、重要度の高い要件から順に、満たすべき設定値を利用者から受け付け、好適なシステムコンポーネント（製品）の組み合わせを決定する技術を開示する。特許文献３に記載の技術は、利用者から受け付けた設定値に対応するシステムコンポーネントを順次抽出し、上位要件の設定値に対して抽出された構成と矛盾が生じない組み合わせの候補を求め、利用者に提示する。【００１０】
特許文献４は、ＳＬＯ（Service Level Objective）を満たすために見直さなければならない設定項目を容易に特定できる装置を開示する。この装置は、業務システムの設定項目とＳＬＯの対応関係をもとに、ある設定項目の値を変更した場合に影響を受ける（要件を満たせなくなる）可能性があるＳＬＯを特定し、ＳＬＯを満たすために設定値を見直すべき設定項目を特定する。【００１１】
特許文献５は、最適なシステム構成を決定する対話型の設計支援装置を開示する。この設計支援装置は、システム構成を体系化したモデルや、各モデルで利用可能なネットワーク構成、サーバの処理能力などのシステム構築に必要な情報をノウハウとして蓄積する。そして、この設計支援装置は、プルダウンメニューを介してユーザからそれらの条件の選択を受け付けることで、最適なシステムを決定する。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特許第５０４９９１１号公報
【特許文献２】特許第４９０６４２４号公報
【特許文献３】特許第４９３７１５９号公報
【特許文献４】特許第４８８０３７６号公報
【特許文献５】特開２００２−２２２２２７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
非機能要件は、一般に、システムの社会的影響度などに基づいて、複数の候補の中から満たすべき値や状態が指定されている。しかしながら、特許文献１では、非機能要件の対応情報として、非機能要件を実現できる処理によってその非機能要件が相対的に向上するか否かが定義されており、その非機能要件が具体的にどのような状態になるかは考慮されていない。よって、上記のような、社会的影響度などに基づく満たすべき値や状態を指定することはできない。【００１４】
特許文献２は、登録されたＷｅｂサービスの中から付与された性能値に基づいて、非機能要件として指定された値を検索キーとして、条件に合うサービスを抽出している。これは、キーワードマッチに近い検索であり、個々のＷｅｂサービスの単純な結合によって、一つのＷｅｂサービスを構成することが前提となっている。そのため、様々な種類のコンポーネントを複雑に組み合わせて、要件を満たすようにシステムを構築するような場合には適用できない。【００１５】
特許文献３では、使用可能な製品ごとに、要件の設定値に対応する組み合わせの候補を用意する必要がある。しかしながら、多数の製品について組み合わせの候補を全て列挙することは困難である。また、非機能要件には、製品の組み合わせだけでなく、待機系のスタンバイ構成やデータのバックアップ方法等の、様々な要因が影響するが、特許文献３では考慮されていない。【００１６】
特許文献４、および５は、設計を変更した場合に影響のあるＳＬＯを提示したり、設計の一部分を決定した場合に他の部分が取りうる構成の候補を絞り込んで選択肢を提示したりする等、ユーザによる設計操作を補助する技術である。したがって、ユーザが指定したＳＬＯを満たすシステム構成を自動的に導出できない。【００１７】
本発明は、上記の事情を鑑みてなされたものであり、非機能要件に影響する様々な要因を考慮しつつ、指定された非機能要件を満たすシステム構成の候補を自動的かつ効率的に導出できる設計支援装置、方法、およびプログラムを提供することを主な目的とする。
【課題を解決するための手段】
【００１８】
本発明の第１の設計支援装置は、非機能要件を受け付ける受付手段と、２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受付手段において受け付けられた前記非機能要件を満たすための前記属性値の制約条件を生成する制約条件生成手段を備える。【００１９】
本発明の第１の設計支援方法は、非機能要件を受け付け、２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受け付けられた前記非機能要件を満たすための前記属性値の制約条件を生成する。【００２０】
なお同目的は、上記の各構成を有する設計支援方法を、コンピュータによって実現するコンピュータ・プログラム、およびそのコンピュータ・プログラムが格納されている、コンピュータ読み取り可能な記憶媒体によっても達成される。
【発明の効果】
【００２１】
本発明は、非機能要件に影響する様々な要因を考慮しつつ、指定された非機能要件を満たすシステム構成の候補を自動的かつ効率的に導出できるという効果が得られる。
【図面の簡単な説明】
【００２２】
【図１】本発明の第１実施形態に係る設計支援装置を示すブロック図である。
【図２Ａ】システムモデルを示す概念図である。
【図２Ｂ】図２Ａに示すシステムモデルのアーキテクチャの一例を示す概念図である。
【図３Ａ】図２Ａに示すシステムモデルのアーキテクチャの一例を示す図である。
【図３Ｂ】図２Ａに示すシステムモデルのアーキテクチャの一例を示す図である。
【図４】システムモデルの他の例を示す図である。
【図５Ａ】非機能要件の一例を示す表である。
【図５Ｂ】非機能要件の一例を示す表である。
【図６】非機能要件‐属性値対応情報の一例を示す表である。
【図７】システムモデルの一例を示す図である。
【図８】第１実施形態に係る設計支援装置の処理の流れを示すフローチャートである。
【図９】本発明の第２実施形態に係る設計支援装置を示すブロック図である。
【図１０】システムモデルテンプレートの概念図である。
【図１１Ａ】システムモデルテンプレートに定義される属性情報の一例を示す表である。
【図１１Ｂ】システムモデルテンプレートに定義される属性情報の一例を示す表である。
【図１２】モデル検索部の処理の流れを示すフローチャートである。
【図１３】本発明の第３実施形態に係る設計支援装置を示すブロック図である。
【図１４】本発明の各実施形態に係る設計支援装置を実現するハードウエア構成を例示する図である。
【発明を実施するための形態】
【００２３】
第１実施形態
図１は、本発明の第１実施形態に係る設計支援装置１０の構成を表すブロック図である。以下、本発明に係る設計支援装置１０について説明する。
【００２４】
設計支援装置１０は、受付部１０１と、ＮＦＲ（Ｎｏｎ−Ｆｕｎｃｔｉｏｎａｌ  Ｒｅｑｕｉｒｅｍｅｎｔｓ）−属性値対応情報格納部１０２と、制約条件生成部１０４と、制約ソルバー１０６と、を備える。設計支援装置１０は、システムモデル２００と、非機能要件（ＮＦＲ）３００とを受付部１０１において受け付ける。
【００２５】
システムモデル２００は、設計対象のシステムを模式化したモデルであり、２種類以上のコンポーネントを組み合わせて設計されるシステムに関する各種設計情報を含んでいる。具体的に説明すると、システムモデル２００は、設計情報として、システムを構成する要素、例えばハードウェア、ミドルウェアなどの接続状態と、システムの品質に影響する設計パラメータに関する情報等を含んでいる。また、システムモデル２００は、設計情報として、設計パラメータが取りうる値に関する情報を含んでもよい。設計パラメータに関する情報および設計パラメータが取りうる値に関する情報とは、システムを構成する要素を表すシステムコンポーネント（以降、「コンポーネント」とも称する）の属性値として定義されてもよい。
【００２６】
設計支援装置１０は、例えば、システムモデル２００のコンポーネントの属性値について、非機能要件３００を満たす組み合わせを出力する機能を有していてもよい。なお、本実施形態において属性値とは、非機能要件を満たすために必要な設計情報を意味する。
【００２７】
図２Ａは、本発明に係るシステムモデル２００の一例を示す概念図である。図２Ａに示すシステムモデル２００は、Ｗｅｂ／ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ）サーバ２０１と、ＤＢ（Ｄａｔａｂａｓｅ）サーバ２０３とを組み合わせた接続状態を有する。「Ｗｅｂ／ＡＰサーバ２０１」は、ＷｅｂサーバおよびＡＰサーバのいずれでもよいことを示す。Ｗｅｂ／ＡＰサーバ２０１は、「冗長性」、「スタンバイ構成」という属性を有する。「冗長性」は、属性値として、「非冗長」または「並列冗長」をとる。「スタンバイ構成」は、属性値として、「コールド」、「ウォーム」または「ホット」をとる。システムモデル２００のコンポーネントの属性値を変更することによって、冗長構成の異なる複数のアーキテクチャを表現できる。図２Ｂは、Ｗｅｂ／ＡＰサーバ２０１が「冗長性」の属性値として、「非冗長」をとる場合のシステムモデル２００のアーキテクチャを示す。
【００２８】
図３Ａおよび図３Ｂは、図２Ｂに示すシステムモデル２００から、Ｗｅｂ／ＡＰサーバ２０１の冗長性と、スタンバイ構成の属性値を変更したシステムモデル２００のアーキテクチャの一例を示す図である。図３Ａは、冗長性を「並列冗長」、スタンバイ構成を「コールド」に設定した構成を示している。一方、図３Ｂは、冗長性を「並列冗長」、スタンバイ構成を「ホット」に設定した構成を示している。本実施形態では、非機能要件を満たすアーキテクチャを、後述する制約充足問題を解くことによって求めることについて説明する。
【００２９】
以下、図４を参照して、本実施形態に係るシステムモデル２００、および属性値について説明する。図４に示すように、システムモデル２００は、Ｗｅｂサーバ２０２と、ＡＰサーバ２０４と、ＤＢサーバ２０６とが直列に接続された構成を示す。
【００３０】
また、システムモデル２００には、冗長性、スタンバイ構成、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成、データのバックアップ、および保持データの種類が、属性として定義されている。なお、これらの属性は一例であり、本実施形態を限定するものではない。
【００３１】
Ｗｅｂサーバ２０２、ＡＰサーバ２０４、ＤＢサーバ２０６は、それぞれ、図４に示す属性に関連付けられた、括弧内に記述された値を属性値としてとりうる。すなわち、各サーバは、冗長性の属性値として、「非冗長」、「並列冗長」をとりうる。各サーバは、スタンバイ構成の属性値として、「コールド」、「ウォーム」、「ホット」をとりうる。各サーバは、ＲＡＩＤ構成の属性値として、「ＲＡＩＤ０」、「ＲＡＩＤ５」、「ＲＡＩＤ１」をとりうる。各サーバは、データのバックアップの属性値として、「なし」、「週次」、「日次」、「オンライン」をとりうる。また、Ｗｅｂサーバ２０２、ＡＰサーバ２０４は、保持データの種類の属性値として、「システムデータ」をとりうる。ＤＢサーバ２０６は、保持データの種類の属性値として、「ユーザデータ」をとりうる。システムモデル２００は、上記の属性値を組み合わせることによって、様々なアーキテクチャを構築できる。
【００３２】
次に、非機能要件について説明する。
【００３３】
非機能要件は、設計対象のシステムの品質に関して、顧客から指定される要件に関する情報を含む。具体的に説明すると、非機能要件は、例えば、顧客から指定される、設計対象のシステムの性能や可用性に関する情報を含んでもよい。また非機能要件は、顧客から指定される要件として、複数の候補の中から、満たすべき値や状態等が選択された情報を含んでもよい。以下、非機能要件の具体例について説明する。
【００３４】
図５Ａおよび図５Ｂは、非機能要件の具体例（非機能要件３００、３１０）を示す表である。図５Ａおよび図５Ｂを参照すると、システムの可用性に関する非機能要件として、障害発生時の業務継続性、耐障害性（論理）（復旧すべきデータの範囲）、および復旧時点が指定されている。なお、これらの非機能要件は一例であり、本実施形態を限定するものではない。
【００３５】
図５Ａに示す非機能要件３００は、業務継続性として「単一障害時は処理を継続」すること、耐障害性（論理）として「重要データのみ復旧」すること、復旧時点として「１営業日前まで」復旧することを指定している。また、図５Ｂに示す非機能要件３１０は、業務継続性として「障害時の業務停止を許容」すること、耐障害性（論理）として「全データを復旧」すること、復旧時点として「１営業日前まで」に復旧することを指定している。非機能要件３００と、非機能要件３１０とで、満たすべき状態として異なる状態が指定されている。すなわち、非機能要件および満たすべき状態は、顧客が指定する要件に応じて指定できる。満たすべき状態として、非機能要件の各項目が取りうる複数の状態の中から、最も満たすべき状態が選択されて指定されてもよい。
【００３６】
図１に示したＮＦＲ−属性値対応情報格納部１０２は、非機能要件を満たすために必要な、システムモデルのコンポーネントの属性値の条件を定義した情報、すなわち非機能要件−属性値対応情報（以下、ＮＦＲ‐属性値対応情報）を保持する。以下、ＮＦＲ−属性値対応情報について説明する。
【００３７】
図６は、ＮＦＲ−属性値対応情報４００の一例を示す表である。ＮＦＲ−属性値対応情報４００は、業務継続性と、サービス切替時間と、耐障害性（物理）と、耐障害性（論理）と、復旧時点との、５項目の非機能要件について属性値の条件を定義している。ＮＦＲ−属性値対応情報４００は、各非機能要件がとりうる複数の状態とそれぞれ対応付けて属性値の条件を定義してもよい。条件は、論理式の形式で記述されてもよい。
【００３８】
図１に示した制約条件生成部１０４は、例えば、外部から受付部１０１において受け付けた非機能要件と、ＮＦＲ−属性値対応情報４００とに基づいて、システムモデルの各コンポーネントの属性値に対する制約条件を生成する。さらに制約条件生成部１０４は、生成した制約条件を制約充足問題として定式化する。
【００３９】
制約条件生成部１０４は、例えば、図４に示すシステムモデル２００に対して、図５Ａに示した非機能要件３００を受けた場合、図６に示すＮＦＲ−属性値対応情報４００から、制約条件を抽出する。すなわち、制約条件生成部１０４は、業務継続性の状態が「単一障害時は処理を継続」を満たすために必要な、「冗長性 = (並列冗長 or k/n（k-out-of-n system）冗長) ＡＮＤ スタンバイ構成 = (ホット)」という条件を抽出する。抽出した条件は、各コンポーネント（Ｗｅｂサーバ２０２、ＡＰサーバ２０４、ＤＢサーバ２０６）の属性値の制約条件として、各コンポーネントに付与される。
【００４０】
同様に、制約条件生成部１０４は、耐障害性（論理）の状態が「重要データのみ復旧」を満たすために必要な、「保持データの種類 = (システムデータ) OR データのバックアップ ≠ (なし)」という条件を抽出する。抽出した条件は、各コンポーネント（Ｗｅｂサーバ２０２、ＡＰサーバ２０４、ＤＢサーバ２０６）の属性値の制約条件として、各コンポーネントに付与される。
【００４１】
ここで、図４に示したシステムモデル２００において、Ｗｅｂサーバ２０２、ＡＰサーバ２０４が保持するデータの種類は「システムデータ」であり、ＤＢサーバ２０６が保持するデータの種類は「ユーザデータ」という固定値である。したがって、Ｗｅｂサーバ２０２、ＡＰサーバ２０４については、「保持データの種類 = (システムデータ)」という条件を必ず満たすため、その他の制約条件については考慮する必要はない。
【００４２】
一方、ＤＢサーバ２０６については、上記条件は満たされないので、「データのバックアップ ≠ (なし)」という条件が、属性値の制約条件としてＤＢサーバ２０６に付与される。これは、耐障害性（論理）の満たすべき状態として、ユーザデータという種類のデータについてのみ復旧する必要があるため、ＤＢサーバのデータバックアップ属性に対してのみ、“バックアップ ≠ (なし)”という制約条件が付与されることを表している。
【００４３】
さらに、制約条件生成部１０４は、復旧対象のデータ（ユーザデータ）を持つＤＢサーバ２０６については、復旧時点の状態が「１営業日前まで」を満たすために必要な、「データのバックアップ = {日次 or オンライン}」という条件を抽出し、それを属性値の制約条件としてＤＢサーバ２０６に付与する。
【００４４】
そして制約条件生成部１０４は、各サーバに付与した制約条件を、制約充足問題として定式化する。
【００４５】
制約ソルバー１０６は、制約条件生成部１０４が生成したシステムモデルのコンポーネントの属性値に関する制約充足問題を、例えば、バックトラッキング等の既存の汎用的な手法によって解く機能を有している。なお、これは制約充足問題を解く手法を限定するものではなく、制約ソルバー１０６は他の手法を用いて制約充足問題を解く機能を有していてもよい。以下、システムモデルのコンポーネントの属性値に関する制約充足問題を解く流れについて説明する。
【００４６】
制約ソルバー１０６は、図４に示されるシステムモデル２００のコンポーネントの属性、およびそれらの取りうる値（属性値）から、変数の集合と各変数の領域を定義する。説明を簡略化するため、各属性値の取りうる値を、以下のように、順に０以上の整数値に置き換えて定義する。
【００４７】
・｛非冗長，並列冗長｝＝｛０，１｝
・｛コールド，ウォーム，ホット｝＝｛０，1，２｝
・｛ＲＡＩＤ０，ＲＡＩＤ５，ＲＡＩＤ１｝＝｛０，１，２｝
・｛なし，週次，日次，オンライン｝＝｛０，１，２，３｝
・｛システムデータ｝＝｛０｝、｛ユーザデータ｝＝｛１｝
なお、属性値の定義は上記に限定されるものではなく、上記定義とは異なる定義をしてもよい。
【００４８】
属性値を上記のように定義することによって、変数の集合と各変数の領域は、以下のように表すことができる。
【００４９】
・冗長性：x_web，x_ap，x_db = {０，１}
・スタンバイ構成：y_web，y_ap，y_db = {０，１，２}
・ＲＡＩＤ構成：z_web，z_ap，z_db = {０，１，２}
・データのバックアップ：u_web，u_ap，u_db = {０，１，２，３}
・保持データの種類：w_web，w_ap = {０}、 w_db = {１}
ここで、ｘは冗長性、ｙはスタンバイ構成、ｚはＲＡＩＤ構成、ｕはデータのバックアップ、ｗは保持データの種類を表す変数を示す。また、添え字「web」はＷｅｂサーバ、「ap」はＡＰサーバ、「db」はＤＢサーバの、それぞれ属性に関する変数であることを示している。
【００５０】
図５Ａに示す非機能要件３００と、図６に示すＮＦＲ−属性値対応情報４００とに基づいて、各変数間の制約の集合を、以下のように定義できる。ただし、冗長性がｋ/ｎ冗長の状態を、ｘ＝２と置き換えている。
【００５１】
・((x_web = 1) ∨ (x_web = 2)) ∧ (y_web = 2)
・((x_ap = 1) ∨ (x_ap = 2)) ∧ (y_ap = 2)
・((x_db = 1) ∨ (x_db = 2)) ∧ (y_db = 2)
・(w_web = 0) ∨ (u_web ≠ 0)
・(w_ap = 0) ∨ (u_ap ≠ 0)
・(w_db = 0) ∨ (u_db ≠ 0)
・(w_db = 1) ∨ (w_db = 2)
ここで、「∨」はＯＲ、「∧」はＡＮＤを意味する。
【００５２】
制約ソルバー１０６は、制約充足問題を解くことで変数の値を得ることができる。変数の値は、以下のように求められる。
【００５３】
＜解１＞
・x_web = x_ap = x_db = 1
・y_web = y_ap = y_db = 2
・u_db = 1
＜解２＞
・x_web = x_ap = x_db = 1
・y_web = y_ap = y_db = 2
・u_db = 2
上記以外の変数については、各領域内で任意の値を取ることが可能である。
【００５４】
したがって、図５Ａに示す非機能要件３００を満たす属性値の組み合わせとして、以下のような２通りの解が導出される。
【００５５】
＜解１＞
・Ｗｅｂサーバ：冗長性 = (並列冗長)、スタンバイ構成 = (ホット)
・ＡＰサーバ：冗長性 = (並列冗長)、スタンバイ構成 = (ホット)
・ＤＢサーバ：冗長性 = (並列冗長)、スタンバイ構成 = (ホット)、データのバックアップ = (日次)
＜解２＞
・Ｗｅｂサーバ：冗長性 = (並列冗長)、スタンバイ構成 = (ホット)
・ＡＰサーバ：冗長性 = (並列冗長)、スタンバイ構成 = (ホット)
・ＤＢサーバ：冗長性 = (並列冗長)、スタンバイ構成 = (ホット)、データのバックアップ = (オンライン)
【００５６】
ここで、システムモデルごとに、コンポーネントの属性の取りうる値は異なっていてもよい。例えば、図７に示すシステムモデル７００について説明する。システムモデル７００は、サーバの接続状態はシステムモデル２００と同一であるが、サーバが取りうる属性値はシステムモデル２００と異なっている。具体的に説明すると、システムモデル７００では、ＤＢサーバ７０６はスタンバイ構成としてコールドのみを、Ｗｅｂサーバ７０２はＲＡＩＤ構成としてＲＡＩＤ０、またはＲＡＩＤ５をとる。
【００５７】
制約条件生成部１０４は、システムモデル７００に対して図５Ａに示す非機能要件３００が与えられた場合、図６に示すＮＦＲ−属性値対応情報４００が定義する業務継続性の状態「単一障害時は処理を継続」を満たすための条件を抽出する。すなわち、制約条件生成部１０４は、「冗長性 = (並列冗長 or k/n冗長) ＡＮＤ スタンバイ構成 = (ホット)」という条件を抽出すると共に、抽出した条件を属性値の制約条件として、各コンポーネントに付与する。しかしながら、ＤＢサーバ７０６は、スタンバイ構成として「コールド」のみをとるので、「スタンバイ構成 = (ホット)」という制約条件を満たす解は存在しない。したがって、システムモデル７００では「単一障害時は処理を継続」を実現することができない。
【００５８】
図８は、本実施形態に係る設計支援装置１０の動作の流れを示すフローチャートである。以下、設計支援装置１０の動作の流れについて詳細に説明する。
【００５９】
まず、設計支援装置１０は、図示しないユーザ、または外部装置等から、設計対象となるシステムに関するシステムモデル、および非機能要件の入力を受け付ける（ステップＳ１０１）。
【００６０】
次いで、制約条件生成部１０４は、ＮＦＲ−属性値対応情報を参照し、非機能要件を満たすために必要なシステムモデルのコンポーネントの属性値に対する制約条件を抽出する（ステップＳ１０２）。
【００６１】
次いで、制約条件生成部１０４は、抽出した属性値に対する制約条件に基づいて、属性値に関する制約充足問題を構築（定式化）する（ステップＳ１０３）。
【００６２】
そして、制約ソルバー１０６は、例えば、バックトラッキング等の汎用的な手法を用いて制約充足問題を解くことにより、非機能要件を満たすシステムモデルのコンポーネントの属性値の組み合わせの候補を算出する（ステップＳ１０４）。
【００６３】
以上のように、本実施形態に係る設計支援装置１０は、非機能要件に影響する様々な要因を考慮しつつ、指定された非機能要件を満たすシステム構成（システムアーキテクチャ）の候補を自動的かつ効率的に導出できるという効果が得られる。また、システム構成の候補を自動的かつ効率的に導出できるので、システム設計者の負担を軽減できるという効果が得られる。
【００６４】
また設計支援装置１０は、非機能要件の複数の状態と、属性値の条件とを対応付けたＮＦＲ‐属性値対応情報を定義することによって、設計対象のシステムの社会的影響度などに基づいて複数の候補の中から満たすべき値や状態を非機能要件として指定できるという効果が得られる。
【００６５】
第２実施形態
図９は、本発明の第２実施形態に係る設計支援装置２０の構成を示すブロック図である。以下、設計支援装置２０について説明する。
【００６６】
図９を参照すると、設計支援装置２０は、受付部１０１と、ＮＦＲ−属性値対応情報格納部１０２と、制約条件生成部１０４と、制約ソルバー１０６と、モデル検索部１０８と、モデル格納部１１０と、を備える。設計支援装置２０は、モデル検索部１０８と、モデル格納部１１０と、を備える点で、第１の実施形態における設計支援装置１０と異なっている。また、設計支援装置２０には、システムモデルは入力されずに、非機能要件のみが入力され、受付部１０１において受け取られる。設計支援装置２０は、例えば、非機能要件を満たす属性値の組み合わせと一致する属性情報を持つシステムモデルテンプレート、および対応する属性情報を出力する機能を有している。
【００６７】
モデル格納部１１０は、システムモデルテンプレート１２０、およびシステムモデルテンプレート１２０に対応する属性情報１３０を保持する。モデル格納部１１０は、複数のシステムモデルテンプレート１２０と、それぞれのシステムモデルテンプレート１２０に対応する複数の属性情報１３０とを保持していてもよい。
【００６８】
モデル格納部１１０のシステムモデルテンプレート１２０は、システムの設計情報の雛形に相当する情報を含んでいる。具体的に説明すると、システムモデルテンプレート１２０は、システムを構成する要素（例えばハードウェアやミドルウェアなど）を機能単位で記述したコンポーネント、およびコンポーネントの接続状態に関する情報を含んでいる。またシステムモデルテンプレート１２０は、システムが提供するサービスの種類や機能などに応じた設計情報から共通部分を抽出した情報を含んでいてもよいし、コンポーネントに対して定義されうる属性の種類に関する情報を含んでいてもよい。
【００６９】
モデル格納部１１０の属性情報１３０は、システムモデルテンプレート１２０の各コンポーネントの属性値を表す情報を含んでいる。属性情報１３０は、システムモデルテンプレート１２０に対して複数定義されていてもよい。また属性情報１３０は、システムの設計情報からシステムモデルテンプレート１２０として抽出された共通部分以外の、システムごとに異なる部分を定義した情報を含んでいてもよい。
【００７０】
一般的なＷｅｂ３層システムを表すシステムモデルテンプレート１２０の例を、図１０に示す。図１０を参照すると、システムモデルテンプレート１２０は、Ｗｅｂサーバ１２２と、ＡＰサーバ１２４と、ＤＢサーバ１２６と、を含んでいる。
【００７１】
また、システムモデルテンプレート１２０は、コンポーネントに対して定義される属性の種類を含む。定義される属性は、例えば、冗長性、スタンバイ構成、ＲＡＩＤ構成、データのバックアップ、保持データの種類などである。なお、図１０に示したシステムモデルテンプレート１２０は一例であり、本実施形態を限定するものではない。
【００７２】
図１１Ａおよび図１１Ｂは、図１０に示すシステムモデルテンプレート１２０に対して定義される属性情報１３０の一例を示す。図１１Ａと図１１Ｂとでは、ＤＢサーバの属性「データのバックアップ」の値が異なっている。すなわち、属性「データのバックアップ」に関して、図１１Ａに示す表では、Ｗｅｂサーバは「週次」、ＤＢサーバは「日次」、ＡＰサーバは「週次」または「日次」を、属性情報としてとる。これに対して、図１１Ｂに示す表では、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバのいずれも「週次」を、属性情報としてとる。このように、共通のシステムモデルテンプレートをベースとして異なる属性情報を表すことができる。
【００７３】
第２実施形態による制約条件生成部１０４は、外部から受付部１０１において受け取られた非機能要件３００と、ＮＦＲ−属性値対応情報４００に基づいて、システムモデルテンプレート１２０のコンポーネントに対して定義されうる属性の値に対する制約条件を生成する。そして制約条件生成部１０４は、制約条件に基づいて制約充足問題を定式化する。
【００７４】
第１実施形態と同様に、制約ソルバー１０６は、制約条件生成部１０４が生成したシステムモデルテンプレートの属性値に関する制約充足問題を、例えば、バックトラッキング等の既存の汎用的な手法によって解く。これにより、非機能要件を満たす属性値の組み合わせ（解）が導出される。
【００７５】
モデル検索部１０８は、モデル格納部１１０が保持する各システムモデルテンプレート１２０に対応する属性情報１３０のうち、制約ソルバー１０６が導出した属性値の組み合わせ（解）に含まれる属性情報１３０を検索する。例えば、図５Ａに示す非機能要件が与えられた場合、図１１Ａおよび図１１Ｂに示すシステムモデルテンプレートおよび対応する属性情報について、図１１Ａは制約ソルバー１０６により導出される解に含まれるが、図１１Ｂは含まれない。
【００７６】
またモデル検索部１０８は、属性情報を順位づけるための推薦度を算出し、推薦度に基づいて属性情報を並べ替える機能を有していてもよい。具体的に説明すると、モデル検索部１０８は、例えば、推薦度としてシステムの価格を算出する。この場合、モデル検索部１０８は、価格の安い順に属性情報を並び替えることができる。またモデル検索部１０８は、例えば、推薦度としてシステムの品質を示す評価値を算出する。この場合、モデル検索部１０８は、評価値の高い順に属性情報を並べ替えることができる。
【００７７】
図１２は、モデル検索部１０８の動作の流れを示すフローチャートである。以下、図１２を参照しながら、モデル検索部１０８の動作について説明する。
【００７８】
まず、モデル検索部１０８は、モデル格納部１１０から、システムモデルテンプレート１２０及び対応する属性情報１３０を抽出する（ステップＳ２０１）。
【００７９】
次に、外部から指定された非機能要件を満たす、制約ソルバー１０６により導出された複数の属性値の組み合わせ（解）の中に、ステップＳ２０１で抽出された属性情報と一致する解が含まれるか否かを検索する（ステップＳ２０２）。
【００８０】
モデル格納部１１０に含まれるシステムモデルテンプレート１２０、および対応する属性情報１３０について、ステップＳ２０１、およびステップＳ２０２の操作を繰り返す（ステップＳ２０３）。
【００８１】
また設計支援装置２０は、解の候補と一致すると判定された属性情報１３０を、対応するシステムモデルテンプレート１２０と共に外部に出力する装置を更に備えていてもよい。
【００８２】
以上のように、本実施形態によれば、設計支援装置２０は、システムの設計情報の雛形に相当する情報を含むシステムモデルテンプレートと、そのシステムモデルテンプレートの各コンポーネントの属性値を表す属性情報とを、対応付けてモデル格納部１１０に格納する。モデル検索部１０８は、制約ソルバー１０６により導出された複数の属性値の組み合わせ（解）の中に、モデル格納部１１０に格納される属性情報と一致する組み合わせが含まれるか否かを検索し、検索結果を出力する。この構成により、本実施形態によれば、指定された非機能要件を満たす、異なる複数の設計情報をユーザに提示することができるので、ユーザはそれらを比較しながら、システムを設計することが可能となる。
【００８３】
第３実施形態
図１３は、第３実施形態の設計支援装置３０を示すブロック図である。以下、図１３を参照しながら、第３実施形態の設計支援装置３０について説明する。
【００８４】
図１３を参照すると、設計支援装置３０は、受付部３１と、制約条件生成部３２とを備えている。受付部３１は、非機能要件を受け付ける。制約条件生成部３２は、２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受付手段において受け付けられた非機能要件を満たすための前記属性値の制約条件を生成する。なお、属性値条件情報は、上記第１の実施形態における非機能要件−属性値対応情報に相当する。
【００８５】
上記構成を採用することにより、本第３の実施形態によれば、非機能要件に影響する様々な要因を考慮しつつ、指定された非機能要件を満たすシステム構成の候補を自動的かつ効率的に導出できるという効果が得られる。
【００８６】
なお、図１等に示した設計支援装置の各部は、図１４に例示するハードウエア資源において実現される。すなわち、図１４に示す構成は、プロセッサ４０、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）４１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）４２、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）デバイス４３、ストレージ４４および各構成要素を接続するバス４５を備える。
【００８７】
上述した各実施形態では、図１４に示すプロセッサ４０が実行する一例として、以下の場合について説明した。すなわち、本実施形態は、設計支援装置に対して、上述した機能を実現可能なコンピュータ・プログラムを供給した後、そのコンピュータ・プログラムを、プロセッサ４０がＲＡＭ４１に読み出して実行することによって実現される。しかしながら、図１等に示した各ブロックに示す機能は、一部または全部を、ハードウエアとして実現してもよい。
【００８８】
係る供給されたコンピュータ・プログラムは、読み書き可能なメモリ（一時記憶媒体）またはハードディスク装置等のコンピュータ読み取り可能な記憶デバイスに格納すればよい。そして、このような場合において、本発明は、係るコンピュータ・プログラムを表すコード或いは係るコンピュータ・プログラムを格納した記憶媒体によって構成されると捉えることができる。
【００８９】
以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【００９０】
また上記の実施形態の一部、または全部は、以下のようにも記載されうる。なお、以下の付記は本発明を何等限定するものではない。
【００９１】
［付記１］
非機能要件を受けると共に、前記非機能要件とシステムの設計情報の要素である属性値とを対応付けた非機能要件‐属性値対応情報に基づいて、前記非機能要件を実現するための前記属性値の制約条件を生成する制約条件生成部を備える、
ことを特徴とする設計支援装置。
【００９２】
［付記２］
前記制約条件生成部は、
前記制約条件に基づいて制約充足問題を定式化する、
ことを特徴とする上記付記１に記載の設計支援装置。
【００９３】
［付記３］
前記制約充足問題を解くことによって、前記非機能要件を満たす前記属性値を算出する制約ソルバーを更に備える、
ことを特徴とする上記付記２に記載の設計支援装置。
【００９４】
［付記４］
前記設計情報と前記設計情報に対応する属性情報を保持するモデル格納部と、
前記制約ソルバーが導出した前記属性値と、前記モデル格納部が保持する前記属性情報とを比較するモデル検索部と、
を更に備える、
ことを特徴とする上記付記３に記載の設計支援装置。
【００９５】
［付記５］
前記モデル検索部は、
前記属性情報を順位付けるための推薦度を算出し、該推薦度に基づいて前記属性情報を並び替える、
ことを特徴とする上記付記４に記載の設計支援装置。
【００９６】
［付記６］
前記モデル格納部は、
前記属性情報が複数対応付けられた前記設計情報を保持する、
ことを特徴とする上記付記４または５に記載の設計支援装置。
【００９７】
［付記７］
前記非機能要件‐属性値対応情報は、
複数の異なる状態の前記非機能要件に前記制約条件を対応付けた情報を含む、
ことを特徴とする上記付記１乃至６のいずれか１項に記載の設計支援装置。
【００９８】
［付記８］
非機能要件を受けると共に、前記非機能要件とシステムの設計情報の要素である属性値とを対応付けた非機能要件‐属性値対応情報に基づいて、前記非機能要件を実現するための前記属性値の制約条件を生成する、
ことを特徴とする設計支援方法。
【００９９】
［付記９］
コンピュータを、
非機能要件を受けると共に、前記非機能要件とシステムの設計情報の要素である属性値とを対応付けた非機能要件‐属性値対応情報に基づいて、前記非機能要件を実現するための前記属性値の制約条件を生成する制約条件生成手段として動作させる、
ことを特徴とする設計支援プログラム。
【０１００】
この出願は、２０１４年４月２３日に出願された日本出願特願２０１４−０８９０９８を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【０１０１】
本発明は、例えば、システムアーキテクチャの設計支援装置に適用できる。
【符号の説明】
【０１０２】
１０、２０、３０  設計支援装置
１０２  ＮＦＲ−属性値対応情報格納部
１０４  制約条件生成部
１０６  制約ソルバー
１０８  モデル検索部
１１０  モデル格納部
１２０  システムモデルテンプレート
１２２  Ｗｅｂサーバ
１２４  ＡＰサーバ
１２６  ＤＢサーバ
１３０  属性情報
２００  システムモデル
２０２  Ｗｅｂサーバ
２０４  ＡＰサーバ
２０６  ＤＢサーバ
３００  非機能要件
３１０  非機能要件
４００  ＮＦＲ‐属性値対応情報
７００  システムモデル
７０２  Ｗｅｂサーバ
７０４  ＡＰサーバ
７０６  ＤＢサーバ
【図１】
2015162889.tif 000003
【図２Ａ】
2015162889.tif 000004
【図２Ｂ】
2015162889.tif 000005
【図３Ａ】
2015162889.tif 000006
【図３Ｂ】
2015162889.tif 000007
【図４】
2015162889.tif 000008
【図５Ａ】
2015162889.tif 000009
【図５Ｂ】
2015162889.tif 000010
【図６】
2015162889.tif 000011
【図７】
2015162889.tif 000012
【図８】
2015162889.tif 000013
【図９】
2015162889.tif 000014
【図１０】
2015162889.tif 000015
【図１１Ａ】
2015162889.tif 000016
【図１１Ｂ】
2015162889.tif 000017
【図１２】
2015162889.tif 000018
【図１３】
2015162889.tif 000019
【図１４】
2015162889.tif 000020
【手続補正書】
【提出日】平成28年9月23日(2016.9.23)
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本発明は、コンピュータシステムの設計を支援する設計支援装置、方法、およびプログラムに関する。
【手続補正３】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項９
【補正方法】変更
【補正の内容】
【請求項９】
コンピュータに、
非機能要件を受け付ける処理と、
２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受け付けられた前記非機能要件を満たすための前記属性値の制約条件を生成する処理と
を、実行させるプログラム。
【手続補正４】
【補正対象書類名】図面
【補正対象項目名】図３Ｂ
【補正方法】変更
【補正の内容】
【図３Ｂ】
2015162889.tif 000021
【国際調査報告】
2015162889.tif 000022
2015162889.tif 000023