JPWO2015162889A1 - 設計支援装置、方法、およびプログラム - Google Patents

Abstract

非機能要件に影響する様々な要因を考慮しつつ、指定された非機能要件を満たすシステム構成の候補を自動的かつ効率的に導出できる設計支援装置が開示される。係る設計支援装置は、非機能要件を受け付ける受付手段と、２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受付手段において受け付けられた前記非機能要件を満たすための前記属性値の制約条件を生成する制約条件生成手段を備える。

Description

本発明は、コンピュータシステムの設計を支援する設計支援装置、方法、およびプログラム記録媒体に関する。

コンピュータシステム（以下、システムと呼ぶ）の開発においては、顧客から指定される各種要件を満たすようにシステムの設計（アーキテクチャ）を決める必要がある。

顧客から指定される要件には、システムの品質（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冗長) ＡＮＤ スタンバイ構成 = (ホット)」という条件を抽出すると共に、抽出した条件を属性値の制約条件として、各コンポーネントに付与する。しかしながら、ＤＢサーバ７０６は、スタンバイ構成として「コールド」のみをとるので、「スタンバイ構成 = (ホット)」という制約条件を満たす解は存在しない。したがって、システムモデル７００では「単一障害時は処理を継続」を実現することができない。

図８は、本実施形態に係る設計支援装置１０の動作の流れを示すフローチャートである。以下、設計支援装置１０の動作の流れについて詳細に説明する。

まず、設計支援装置１０は、図示しないユーザ、または外部装置等から、設計対象となるシステムに関するシステムモデル、および非機能要件の入力を受け付ける（ステップＳ１０１）。

次いで、制約条件生成部１０４は、ＮＦＲ−属性値対応情報を参照し、非機能要件を満たすために必要なシステムモデルのコンポーネントの属性値に対する制約条件を抽出する（ステップＳ１０２）。

次いで、制約条件生成部１０４は、抽出した属性値に対する制約条件に基づいて、属性値に関する制約充足問題を構築（定式化）する（ステップＳ１０３）。

そして、制約ソルバー１０６は、例えば、バックトラッキング等の汎用的な手法を用いて制約充足問題を解くことにより、非機能要件を満たすシステムモデルのコンポーネントの属性値の組み合わせの候補を算出する（ステップＳ１０４）。

以上のように、本実施形態に係る設計支援装置１０は、非機能要件に影響する様々な要因を考慮しつつ、指定された非機能要件を満たすシステム構成（システムアーキテクチャ）の候補を自動的かつ効率的に導出できるという効果が得られる。また、システム構成の候補を自動的かつ効率的に導出できるので、システム設計者の負担を軽減できるという効果が得られる。

また設計支援装置１０は、非機能要件の複数の状態と、属性値の条件とを対応付けたＮＦＲ‐属性値対応情報を定義することによって、設計対象のシステムの社会的影響度などに基づいて複数の候補の中から満たすべき値や状態を非機能要件として指定できるという効果が得られる。

第２実施形態
図９は、本発明の第２実施形態に係る設計支援装置２０の構成を示すブロック図である。以下、設計支援装置２０について説明する。

図９を参照すると、設計支援装置２０は、受付部１０１と、ＮＦＲ−属性値対応情報格納部１０２と、制約条件生成部１０４と、制約ソルバー１０６と、モデル検索部１０８と、モデル格納部１１０と、を備える。設計支援装置２０は、モデル検索部１０８と、モデル格納部１１０と、を備える点で、第１の実施形態における設計支援装置１０と異なっている。また、設計支援装置２０には、システムモデルは入力されずに、非機能要件のみが入力され、受付部１０１において受け取られる。設計支援装置２０は、例えば、非機能要件を満たす属性値の組み合わせと一致する属性情報を持つシステムモデルテンプレート、および対応する属性情報を出力する機能を有している。

モデル格納部１１０は、システムモデルテンプレート１２０、およびシステムモデルテンプレート１２０に対応する属性情報１３０を保持する。モデル格納部１１０は、複数のシステムモデルテンプレート１２０と、それぞれのシステムモデルテンプレート１２０に対応する複数の属性情報１３０とを保持していてもよい。

モデル格納部１１０のシステムモデルテンプレート１２０は、システムの設計情報の雛形に相当する情報を含んでいる。具体的に説明すると、システムモデルテンプレート１２０は、システムを構成する要素（例えばハードウェアやミドルウェアなど）を機能単位で記述したコンポーネント、およびコンポーネントの接続状態に関する情報を含んでいる。またシステムモデルテンプレート１２０は、システムが提供するサービスの種類や機能などに応じた設計情報から共通部分を抽出した情報を含んでいてもよいし、コンポーネントに対して定義されうる属性の種類に関する情報を含んでいてもよい。

モデル格納部１１０の属性情報１３０は、システムモデルテンプレート１２０の各コンポーネントの属性値を表す情報を含んでいる。属性情報１３０は、システムモデルテンプレート１２０に対して複数定義されていてもよい。また属性情報１３０は、システムの設計情報からシステムモデルテンプレート１２０として抽出された共通部分以外の、システムごとに異なる部分を定義した情報を含んでいてもよい。

一般的なＷｅｂ３層システムを表すシステムモデルテンプレート１２０の例を、図１０に示す。図１０を参照すると、システムモデルテンプレート１２０は、Ｗｅｂサーバ１２２と、ＡＰサーバ１２４と、ＤＢサーバ１２６と、を含んでいる。

また、システムモデルテンプレート１２０は、コンポーネントに対して定義される属性の種類を含む。定義される属性は、例えば、冗長性、スタンバイ構成、ＲＡＩＤ構成、データのバックアップ、保持データの種類などである。なお、図１０に示したシステムモデルテンプレート１２０は一例であり、本実施形態を限定するものではない。

図１１Ａおよび図１１Ｂは、図１０に示すシステムモデルテンプレート１２０に対して定義される属性情報１３０の一例を示す。図１１Ａと図１１Ｂとでは、ＤＢサーバの属性「データのバックアップ」の値が異なっている。すなわち、属性「データのバックアップ」に関して、図１１Ａに示す表では、Ｗｅｂサーバは「週次」、ＤＢサーバは「日次」、ＡＰサーバは「週次」または「日次」を、属性情報としてとる。これに対して、図１１Ｂに示す表では、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバのいずれも「週次」を、属性情報としてとる。このように、共通のシステムモデルテンプレートをベースとして異なる属性情報を表すことができる。

第２実施形態による制約条件生成部１０４は、外部から受付部１０１において受け取られた非機能要件３００と、ＮＦＲ−属性値対応情報４００に基づいて、システムモデルテンプレート１２０のコンポーネントに対して定義されうる属性の値に対する制約条件を生成する。そして制約条件生成部１０４は、制約条件に基づいて制約充足問題を定式化する。

第１実施形態と同様に、制約ソルバー１０６は、制約条件生成部１０４が生成したシステムモデルテンプレートの属性値に関する制約充足問題を、例えば、バックトラッキング等の既存の汎用的な手法によって解く。これにより、非機能要件を満たす属性値の組み合わせ（解）が導出される。

モデル検索部１０８は、モデル格納部１１０が保持する各システムモデルテンプレート１２０に対応する属性情報１３０のうち、制約ソルバー１０６が導出した属性値の組み合わせ（解）に含まれる属性情報１３０を検索する。例えば、図５Ａに示す非機能要件が与えられた場合、図１１Ａおよび図１１Ｂに示すシステムモデルテンプレートおよび対応する属性情報について、図１１Ａは制約ソルバー１０６により導出される解に含まれるが、図１１Ｂは含まれない。

またモデル検索部１０８は、属性情報を順位づけるための推薦度を算出し、推薦度に基づいて属性情報を並べ替える機能を有していてもよい。具体的に説明すると、モデル検索部１０８は、例えば、推薦度としてシステムの価格を算出する。この場合、モデル検索部１０８は、価格の安い順に属性情報を並び替えることができる。またモデル検索部１０８は、例えば、推薦度としてシステムの品質を示す評価値を算出する。この場合、モデル検索部１０８は、評価値の高い順に属性情報を並べ替えることができる。

図１２は、モデル検索部１０８の動作の流れを示すフローチャートである。以下、図１２を参照しながら、モデル検索部１０８の動作について説明する。

まず、モデル検索部１０８は、モデル格納部１１０から、システムモデルテンプレート１２０及び対応する属性情報１３０を抽出する（ステップＳ２０１）。

次に、外部から指定された非機能要件を満たす、制約ソルバー１０６により導出された複数の属性値の組み合わせ（解）の中に、ステップＳ２０１で抽出された属性情報と一致する解が含まれるか否かを検索する（ステップＳ２０２）。

モデル格納部１１０に含まれるシステムモデルテンプレート１２０、および対応する属性情報１３０について、ステップＳ２０１、およびステップＳ２０２の操作を繰り返す（ステップＳ２０３）。

また設計支援装置２０は、解の候補と一致すると判定された属性情報１３０を、対応するシステムモデルテンプレート１２０と共に外部に出力する装置を更に備えていてもよい。

以上のように、本実施形態によれば、設計支援装置２０は、システムの設計情報の雛形に相当する情報を含むシステムモデルテンプレートと、そのシステムモデルテンプレートの各コンポーネントの属性値を表す属性情報とを、対応付けてモデル格納部１１０に格納する。モデル検索部１０８は、制約ソルバー１０６により導出された複数の属性値の組み合わせ（解）の中に、モデル格納部１１０に格納される属性情報と一致する組み合わせが含まれるか否かを検索し、検索結果を出力する。この構成により、本実施形態によれば、指定された非機能要件を満たす、異なる複数の設計情報をユーザに提示することができるので、ユーザはそれらを比較しながら、システムを設計することが可能となる。

第３実施形態
図１３は、第３実施形態の設計支援装置３０を示すブロック図である。以下、図１３を参照しながら、第３実施形態の設計支援装置３０について説明する。

図１３を参照すると、設計支援装置３０は、受付部３１と、制約条件生成部３２とを備えている。受付部３１は、非機能要件を受け付ける。制約条件生成部３２は、２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受付手段において受け付けられた非機能要件を満たすための前記属性値の制約条件を生成する。なお、属性値条件情報は、上記第１の実施形態における非機能要件−属性値対応情報に相当する。

上記構成を採用することにより、本第３の実施形態によれば、非機能要件に影響する様々な要因を考慮しつつ、指定された非機能要件を満たすシステム構成の候補を自動的かつ効率的に導出できるという効果が得られる。

なお、図１等に示した設計支援装置の各部は、図１４に例示するハードウエア資源において実現される。すなわち、図１４に示す構成は、プロセッサ４０、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）４１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）４２、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）デバイス４３、ストレージ４４および各構成要素を接続するバス４５を備える。

上述した各実施形態では、図１４に示すプロセッサ４０が実行する一例として、以下の場合について説明した。すなわち、本実施形態は、設計支援装置に対して、上述した機能を実現可能なコンピュータ・プログラムを供給した後、そのコンピュータ・プログラムを、プロセッサ４０がＲＡＭ４１に読み出して実行することによって実現される。しかしながら、図１等に示した各ブロックに示す機能は、一部または全部を、ハードウエアとして実現してもよい。

係る供給されたコンピュータ・プログラムは、読み書き可能なメモリ（一時記憶媒体）またはハードディスク装置等のコンピュータ読み取り可能な記憶デバイスに格納すればよい。そして、このような場合において、本発明は、係るコンピュータ・プログラムを表すコード或いは係るコンピュータ・プログラムを格納した記憶媒体によって構成されると捉えることができる。

以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

また上記の実施形態の一部、または全部は、以下のようにも記載されうる。なお、以下の付記は本発明を何等限定するものではない。

［付記１］
非機能要件を受けると共に、前記非機能要件とシステムの設計情報の要素である属性値とを対応付けた非機能要件‐属性値対応情報に基づいて、前記非機能要件を実現するための前記属性値の制約条件を生成する制約条件生成部を備える、
ことを特徴とする設計支援装置。

［付記２］
前記制約条件生成部は、
前記制約条件に基づいて制約充足問題を定式化する、
ことを特徴とする上記付記１に記載の設計支援装置。

［付記３］
前記制約充足問題を解くことによって、前記非機能要件を満たす前記属性値を算出する制約ソルバーを更に備える、
ことを特徴とする上記付記２に記載の設計支援装置。

［付記４］
前記設計情報と前記設計情報に対応する属性情報を保持するモデル格納部と、
前記制約ソルバーが導出した前記属性値と、前記モデル格納部が保持する前記属性情報とを比較するモデル検索部と、
を更に備える、
ことを特徴とする上記付記３に記載の設計支援装置。

［付記５］
前記モデル検索部は、
前記属性情報を順位付けるための推薦度を算出し、該推薦度に基づいて前記属性情報を並び替える、
ことを特徴とする上記付記４に記載の設計支援装置。

［付記６］
前記モデル格納部は、
前記属性情報が複数対応付けられた前記設計情報を保持する、
ことを特徴とする上記付記４または５に記載の設計支援装置。

［付記７］
前記非機能要件‐属性値対応情報は、
複数の異なる状態の前記非機能要件に前記制約条件を対応付けた情報を含む、
ことを特徴とする上記付記１乃至６のいずれか１項に記載の設計支援装置。

［付記８］
非機能要件を受けると共に、前記非機能要件とシステムの設計情報の要素である属性値とを対応付けた非機能要件‐属性値対応情報に基づいて、前記非機能要件を実現するための前記属性値の制約条件を生成する、
ことを特徴とする設計支援方法。

［付記９］
コンピュータを、
非機能要件を受けると共に、前記非機能要件とシステムの設計情報の要素である属性値とを対応付けた非機能要件‐属性値対応情報に基づいて、前記非機能要件を実現するための前記属性値の制約条件を生成する制約条件生成手段として動作させる、
ことを特徴とする設計支援プログラム。

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

本発明は、例えば、システムアーキテクチャの設計支援装置に適用できる。

１０、２０、３０ 設計支援装置
１０２ ＮＦＲ−属性値対応情報格納部
１０４ 制約条件生成部
１０６ 制約ソルバー
１０８ モデル検索部
１１０ モデル格納部
１２０ システムモデルテンプレート
１２２ Ｗｅｂサーバ
１２４ ＡＰサーバ
１２６ ＤＢサーバ
１３０ 属性情報
２００ システムモデル
２０２ Ｗｅｂサーバ
２０４ ＡＰサーバ
２０６ ＤＢサーバ
３００ 非機能要件
３１０ 非機能要件
４００ ＮＦＲ‐属性値対応情報
７００ システムモデル
７０２ Ｗｅｂサーバ
７０４ ＡＰサーバ
７０６ ＤＢサーバ

本発明は、コンピュータシステムの設計を支援する設計支援装置、方法、およびプログラムに関する。

Claims (9)

1. 非機能要件を受け付ける受付手段と、
   ２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受付手段において受け付けられた前記非機能要件を満たすための前記属性値の制約条件を生成する制約条件生成手段
   を備えた設計支援装置。
2. 前記制約条件生成手段は、前記制約条件に基づいて制約充足問題を定式化する
   請求項１に記載の設計支援装置。
3. 前記制約充足問題を解くことによって、前記非機能要件を満たす前記属性値を導出する制約ソルバーを
   更に備えた請求項２に記載の設計支援装置。
4. 前記システムの設計情報と、当該設計情報に対応する属性情報を保持するモデル格納手段と、
   前記制約ソルバーが導出した前記属性値と、前記モデル格納手段が保持する前記属性情報との比較の結果に基づいて、前記受付手段において受け付けられた前記非機能要件を満たす前記属性情報を検索するモデル検索手段と、を更に備えた請求項３に記載の設計支援装置。
5. 前記モデル検索手段は、
   前記属性情報を順位付ける推薦度を算出し、該推薦度に基づいて前記属性情報を提示する
   請求項４に記載の設計支援装置。
6. 前記モデル格納手段は、
   前記属性情報が複数対応付けられた前記設計情報を保持する
   請求項４または５に記載の設計支援装置。
7. 前記属性値条件情報は、
   前記非機能要件の複数の状態と、当該各非機能要件の状態を満たすために必要な前記属性値の条件とを対応付けた情報を含む、
   ことを特徴とする請求項１〜６のいずれか１項に記載の設計支援装置。
8. 非機能要件を受け付け、
   ２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受け付けられた前記非機能要件を満たすための前記属性値の制約条件を生成する
   設計支援方法。
9. コンピュータに、
   非機能要件を受け付ける処理と、
   ２種類以上のコンポーネントを組み合わせて設計されるシステムの前記コンポーネントの属性値について、非機能要件を満たすために必要な条件を定義した属性値条件情報に基づいて、前記受け付けられた前記非機能要件を満たすための前記属性値の制約条件を生成する処理と
   を、実行させる設計支援プログラムを記録するプログラム記録媒体。

Images