2024-163490 計算機システム及びＩＴシステムのアーキテクチャ設計の支援方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024163490

(43)【公開日】2024-11-22

(54)【発明の名称】計算機システム及びＩＴシステムのアーキテクチャ設計の支援方法

(51)【国際特許分類】

   G06F 8/20 20180101AFI20241115BHJP

【ＦＩ】

G06F8/20

【審査請求】未請求

【請求項の数】14

【出願形態】ＯＬ

(21)【出願番号】P 2023079130

(22)【出願日】2023-05-12

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＡＷＳ

２．ＭｙＳＱＬ

３．ＰＹＴＨＯＮ

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110001678

【氏名又は名称】藤央弁理士法人

(72)【発明者】

【氏名】松本 渚紗

(72)【発明者】

【氏名】柿田 将幸

(72)【発明者】

【氏名】受田 賢知

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376BC02

5B376DA16

5B376DA20

(57)【要約】

【課題】ＩＴシステムのアーキテクチャ設計を支援する。
【解決手段】計算機システムは、非機能要件を実装するための設計情報である要素を管理する要素データベースと、過去の非機能要件の実装履歴を格納する履歴データベースとを保持する。計算機システムは、ベースとなるアーキテクチャによって実現されるＩＴシステムに実装する非機能要件の情報を取得し、要素データベースを参照して要素の組合せを複数生成し、複数の要素の組合せについて、複数の要素の組合せの推薦順位を表す優先度を付与する。制約条件を満たす要素の組合せが存在しない場合、実装履歴を用いて代替案を生成する。計算機システムは、優先度に基づいてソートされた要素の組合せ及び代替案の少なくともいずれかを出力する。
【選択図】図１

【特許請求の範囲】

【請求項1】

ＩＴシステムのアーキテクチャの設計を支援する計算機システムであって、
非機能要件及び前記非機能要件を実装するための設計情報である要素を対応づけたデータを格納する要素データベースと、過去の前記非機能要件の実装履歴を格納する履歴データベースとを保持し、
ベースとなるアーキテクチャによって実現されるＩＴシステムに実装する前記非機能要件の情報を取得し、
前記要素データベースを参照して、前記非機能要件を実装するための前記要素の組合せを複数生成し、
前記複数の要素の組合せについて、推薦順位を決定するために用いる評価指標を算出し、
前記評価指標に基づいて、前記複数の要素の組合せの推薦順位を表す優先度を付与し、
制約条件を満たす前記要素の組合せが存在するか否かを判定し、
前記制約条件を満たす前記要素の組合せが存在しない場合、前記実装履歴を解析することによって、前記要素の組合せに含まれる少なくとも一つの前記要素の変更方法を特定し、
特定された前記変更方法に基づいて前記要素の組合せを修正することによって代替案を生成し、
前記優先度に基づいてソートされた前記要素の組合せ及び前記代替案の少なくともいずれかを出力することを特徴とする計算機システム。

【請求項2】

請求項１に記載の計算機システムであって、
前記実装履歴を解析することによって、実装の実績が少ない前記要素、又は過去の実装履歴と比較して要素が満たす要件が過剰若しくは不足している前記要素を、変更可能な前記要素として特定し、
前記変更可能な要素の変更方法を特定することを特徴とする計算機システム。

【請求項3】

請求項２に記載の計算機システムであって、
前記実装履歴を解析することによって、前記非機能要件の実装傾向を特定し、
前記非機能要件の実装傾向に基づいて、前記要素の組合せに含まれる前記要素の変更方法を特定することを特徴とする計算機システム。

【請求項4】

請求項２に記載の計算機システムであって、
前記評価指標は、金銭的なコスト、実装に要するコスト、及び運用に要するコストの少なくともいずれかであり、
前記制約条件は、前記金銭的なコスト、前記実装に要するコスト、及び前記運用に要するコストの少なくともいずれかに関する制約条件であることを特徴とする計算機システム。

【請求項5】

請求項２に記載の計算機システムであって、
前記制約条件は、実装に関する制約条件あり、
前記評価指標は、前記制約条件の合致の程度を表す数値であることを特徴とする計算機システム。

【請求項6】

請求項２に記載の計算機システムであって、
前記履歴データベースは、過去の前記非機能要件のユーザによる採用の可否に関する実装判断履歴を格納し、
前記実装判断履歴は、前記要素、前記要素の実装可否、及び前記要素の実装の判断基準となる前記評価指標の種類を含み、
前記計算機システムは、
複数種類の前記評価指標を算出し、
前記実装判断履歴に基づいて、前記非機能要件の実装の判断に用いる前記評価指標の種類を特定し、
特定された種類の前記評価指標に基づいて、前記優先度を付与することを特徴とする計算機システム。

【請求項7】

請求項６に記載の計算機システムであって、
出力した前記要素の組合せ及び前記代替案を利用した実装結果をフィードバックとして取得し、
取得した前記フィードバックを前記実装履歴又は前記実装判断履歴として蓄積することを特徴とする計算機システム。

【請求項8】

計算機システムが実行するＩＴシステムのアーキテクチャ設計の支援方法であって、
前記計算機システムは、非機能要件及び前記非機能要件を実装するための設計情報である要素を対応づけたデータを格納する要素データベースと、過去の前記非機能要件の実装履歴を格納する履歴データベースとを保持し、
前記ＩＴシステムのアーキテクチャ設計の支援方法は、
前記計算機システムが、ベースとなるアーキテクチャによって実現されるＩＴシステムに実装する前記非機能要件の情報を取得する第１のステップと、
前記計算機システムが、前記要素データベースを参照して、前記非機能要件を実装するための前記要素の組合せを複数生成する第２のステップと、
前記計算機システムが、前記複数の要素の組合せについて、推薦順位を決定するために用いる評価指標を算出する第３のステップと、
前記計算機システムが、前記評価指標に基づいて、前記複数の要素の組合せの推薦順位を表す優先度を付与する第４のステップと、
前記計算機システムが、制約条件を満たす前記要素の組合せが存在するか否かを判定する第５のステップと、
前記制約条件を満たす前記要素の組合せが存在しない場合、前記計算機システムが、前記実装履歴を解析することによって、前記要素の組合せに含まれる少なくとも一つの前記要素の変更方法を特定する第６のステップと、
前記計算機システムが、特定された前記変更方法に基づいて前記要素の組合せを修正することによって代替案を生成する第７のステップと、
前記計算機システムが、前記優先度に基づいてソートされた前記要素の組合せ及び前記代替案の少なくともいずれかを出力するする第８のステップと、を含むことを特徴とするＩＴシステムのアーキテクチャ設計の支援方法。

【請求項9】

請求項８に記載のＩＴシステムのアーキテクチャ設計の支援方法であって、
前記第６のステップは、
前記計算機システムが、前記実装履歴を解析することによって、実装の実績が少ない前記要素、又は過去の実装履歴と比較して要素が満たす要件が過剰若しくは不足している前記要素を、変更可能な前記要素として特定するステップと、
前記計算機システムが、前記変更可能な要素の変更方法を特定するステップと、を含むことを特徴とするＩＴシステムのアーキテクチャ設計の支援方法。

【請求項10】

請求項９に記載のＩＴシステムのアーキテクチャ設計の支援方法であって、
前記第６のステップは、
前記計算機システムが、前記実装履歴を解析することによって、前記非機能要件の実装傾向を特定するステップと、
前記計算機システムが、前記非機能要件の実装傾向に基づいて、前記要素の組合せに含まれる前記要素の変更方法を特定するステップと、を含むことを特徴とするＩＴシステムのアーキテクチャ設計の支援方法。

【請求項11】

請求項９に記載のＩＴシステムのアーキテクチャ設計の支援方法であって、
前記評価指標は、金銭的なコスト、実装に要するコスト、及び運用に要するコストの少なくともいずれかであり、
前記制約条件は、前記金銭的なコスト、前記実装に要するコスト、及び前記運用に要するコストの少なくともいずれかに関する制約条件であることを特徴とするＩＴシステムのアーキテクチャ設計の支援方法。

【請求項12】

請求項９に記載のＩＴシステムのアーキテクチャ設計の支援方法であって、
前記制約条件は、実装に関する制約条件あり、
前記評価指標は、前記制約条件の合致の程度を表す数値であることを特徴とするＩＴシステムのアーキテクチャ設計の支援方法。

【請求項13】

請求項９に記載のＩＴシステムのアーキテクチャ設計の支援方法であって、
前記履歴データベースは、過去の前記非機能要件のユーザによる採用の可否に関する実装判断履歴を格納し、
前記実装判断履歴は、前記要素、前記要素の実装可否、及び前記要素の実装の判断基準となる前記評価指標の種類を含み、
前記第３のステップは、
前記計算機システムが、複数種類の前記評価指標を算出するステップを含み、
前記第４のステップは、
前記計算機システムが、前記実装判断履歴に基づいて、前記非機能要件の実装の判断に用いる前記評価指標の種類を特定するステップと、
前記計算機システムが、特定された種類の前記評価指標に基づいて、前記優先度を付与するステップと、を含むことを特徴とするＩＴシステムのアーキテクチャ設計の支援方法。

【請求項14】

請求項１３に記載のＩＴシステムのアーキテクチャ設計の支援方法であって、
前記計算機システムが、出力した前記要素の組合せ及び前記代替案を利用した実装結果をフィードバックとして取得するステップと、
前記計算機システムが、取得した前記フィードバックを前記実装履歴又は前記実装判断履歴として蓄積するステップを、を含むことを特徴とするＩＴシステムのアーキテクチャ設計の支援方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、アーキテクチャの設計を支援するシステムに関する。

【背景技術】

【0002】

ＩＴシステムの開発において、ＩＴシステムのアーキテクチャの設計は、ユーザがＩＴシステムに期待する要求をコンピュータの構造及び形式に変換し、ＩＴシステムの土台を形作るという観点で重要な役割を持つ。本明細書において、ＩＴシステムのアーキテクチャとは、ＩＴシステムの構成要素及び構成要素間の接続関係等を具体的な形式で表現した情報を意味する。

【0003】

ＩＴシステムのアーキテクチャ設計には、ＩＴシステム全般にわたる幅広い知識、アーキテクチャの構成要素の関係性及び実装方法等について深い知識が必要である。そのため、ゼロベースでのＩＴシステムのアーキテクチャの設計は手間及び時間がかかる。これに対し、クラウドベンダ等は、ドメイン及びＩＴシステムの目的に対応したリファレンスアーキテクチャを提供している。

【0004】

リファレンスアーキテクチャは、ドメインで頻出の構成又はアーキテクチャ設計時のベストプラクティスに基づいて作成され、ＩＴシステムの目的を達成するための一般的なサービス及び最低限の機能から構成される。

【0005】

設計者は、類似するドメイン又は目的に対応したリファレンスアーキテクチャを、ＩＴシステムのユーザ要求に応じて修正することで、ＩＴシステムのアーキテクチャの設計を効率的に行うことができる。

【0006】

ユーザ要求は、一般的に、機能要件及び非機能要件に分類される。機能要件は、ＩＴシステムによって提供される機能及び挙動に関する要件であり、非機能要件は、性能、セキュリティ、可用性等のＩＴシステムの品質に関する要件である。非機能要件は、アーキテクチャを構成する要素の組合せによって実現されることが多いため、設計者は、非機能要件間の関連性及び影響を考慮した上でユーザ要求を満たすようにアーキテクチャを設計する必要がある。したがって、リファレンスアーキテクチャを用いたＩＴシステムのアーキテクチャ設計においても幅広い知識及び経験が必要となる。

【0007】

そのため、従来技術では、設計者が十分な開発能力を有さない場合、ユーザ要求を満たすＩＴシステムのアーキテクチャを設計することは難しい。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特開２０１６-１１０３２５号公報

【非特許文献】

【0009】

【非特許文献1】情報処理推進機構、「非機能要求グレード」、［online］、２０１８年４月、［令和４年１２月２７日検索］、インターネット＜ＵＲＬ：https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html＞

【発明の概要】

【発明が解決しようとする課題】

【0010】

前述の課題に対して特許文献１に記載の技術が知られている。特許文献１には、「システム設計支援装置１８０において、新規設計対象のシステムに関する複数の要件それぞれを実現する設計情報を第１のテーブルで特定し、当該特定の結果、いずれかの要件について複数の設計情報を特定した場合、複数の設計情報それぞれと他要件に関して特定された設計情報との組合せ利用の適性順位を第２のテーブルで参照して適性順位がより高い組合せとなる設計情報を特定し、複数の要件それぞれについて特定した設計情報を所定装置に出力する。」ことが記載されている。

【0011】

特許文献１に記載の技術を用いることによって、複数の要件を満たし、かつ、適正順位が高い設計情報を出力できる。しかし、特許文献１では以下のような課題がある。１つの課題は、ＩＴシステムのアーキテクチャを実装する場合のコストを考慮した順位付けがされていないことである。他の課題は、適切な設計情報の組合せがない場合に生成される代替案の変更基準が明らかでないことである。

【0012】

本発明は、以上のような課題に鑑みてなされたものであり、コストを考慮してＩＴシステムのアーキテクチャの順位付けを行い、また、適切なアーキテクチャを生成できない場合にユーザに根拠を提示できる変更基準に基づいて代替案を生成するシステム及び方法を提供することを目的とする。

【課題を解決するための手段】

【0013】

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、ＩＴシステムのアーキテクチャの設計を支援する計算機システムであって、非機能要件及び前記非機能要件を実装するための設計情報である要素を対応づけたデータを格納する要素データベースと、過去の前記非機能要件の実装履歴を格納する履歴データベースとを保持し、ベースとなるアーキテクチャによって実現されるＩＴシステムに実装する前記非機能要件の情報を取得し、前記要素データベースを参照して、前記非機能要件を実装するための前記要素の組合せを複数生成し、前記複数の要素の組合せについて、推薦順位を決定するために用いる評価指標を算出し、前記評価指標に基づいて、前記複数の要素の組合せの推薦順位を表す優先度を付与し、制約条件を満たす前記要素の組合せが存在するか否かを判定し、前記制約条件を満たす前記要素の組合せが存在しない場合、前記実装履歴を解析することによって、前記要素の組合せに含まれる少なくとも一つの前記要素の変更方法を特定し、特定された前記変更方法に基づいて前記要素の組合せを修正することによって代替案を生成し、前記優先度に基づいてソートされた前記要素の組合せ及び前記代替案の少なくともいずれかを出力する。

【発明の効果】

【0014】

本発明の一形態によれば、計算機システムは、適切なＩＴシステムのアーキテクチャの設計を支援できる。上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

【図面の簡単な説明】

【0015】

【図1】実施例１のアーキテクチャ設計支援システムの構成の一例を示す図である。

【図2A】実施例１の要素ＤＢのデータ構造の一例を示す図である。

【図2B】実施例１の要素ＤＢのデータ構造の一例を示す図である。

【図3A】実施例１の履歴ＤＢのデータ構造の一例を示す図である。

【図3B】実施例１の履歴ＤＢのデータ構造の一例を示す図である。

【図4】実施例１のアーキテクチャ設計支援システムが実行する処理の一例を説明するフローチャートである。

【図5】実施例１のアーキテクチャ設計支援システムによる非機能要件の要素の特定方法及び要素の組合せの生成方法の一例を説明する図である。

【図6】実施例１のアーキテクチャ設計支援システムによるコストの算出方法の一例を説明する図である。

【図7】実施例１のアーキテクチャ設計支援システムが実行する優先度の決定処理の一例を説明するフローチャートである。

【図8】実施例１のアーキテクチャ設計支援システムが実行する優先度の決定処理の一例を説明するフローチャートである。

【図9】実施例１のアーキテクチャ設計支援システムが実行する優先度の決定処理の一例を説明するフローチャートである。

【図10】実施例１の優先度の具体的な決定方法を示す図である。

【図11A】実施例１のアーキテクチャ設計支援システムが実行する代替案の生成処理の一例を説明するフローチャートである。

【図11B】実施例１のアーキテクチャ設計支援システムが実行する代替案の生成処理の一例を説明するフローチャートである。

【図12A】実施例１のアーキテクチャ設計支援システムが実行する代替案の生成処理の一例を説明するフローチャートである。

【図12B】実施例１のアーキテクチャ設計支援システムが実行する代替案の生成処理の一例を説明するフローチャートである。

【図13】実施例３のアーキテクチャ設計支援システムが実行する代替案の生成処理の一例を説明するフローチャートである。

【図14】実施例３のアーキテクチャ設計支援システムが実行する処理の一例を説明するフローチャートである。

【図15】実施例４のアーキテクチャ設計支援システムの構成の一例を示す図である。

【発明を実施するための形態】

【0016】

以下、本発明の実施例を添付図面に基づいて説明する。ただし、本発明は以下に示す実施例の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

【0017】

以下に説明する発明の構成において、同一又は類似する構成又は機能には同一の符号を付し、重複する説明は省略する。

【0018】

本明細書等における「第１」、「第２」、「第３」等の表記は、構成要素を識別するために付するものであり、必ずしも、数又は順序を限定するものではない。

【実施例0019】

図１は、実施例１のアーキテクチャ設計支援システム１００の構成の一例を示す図である。

【0020】

実施例１のアーキテクチャ設計支援システム１００は、ＩＴシステムのアーキテクチャの設計を支援する。後述するように、アーキテクチャ設計支援システム１００は、コスト制約を考慮して非機能要件を実現するＩＴシステムのアーキテクチャを生成する。

【0021】

本明細書では、ＩＴシステムのアーキテクチャは、サービスの種類、サービス間の接続、物理的な機器の接続、及びパラメータ等を定義する情報を要素から構成される情報であるものとする。また、本明細書では、ユーザは、クラウドベンダ等によって提供されるＩＴシステムのリファレンスアーキテクチャ（基本構成）に対して非機能要件を追加するユースケースを想定する。

【0022】

アーキテクチャ設計支援システム１００は、組合せ決定部１１１、検証部１１２、代替案生成部１１３を備え、また、要素ＤＢ１１４及び履歴ＤＢ１１５を保持する。アーキテクチャ設計支援システム１００はユーザと直接情報をやりとりしてもよいし、外部システムとの間で情報をやりとりしてもよい。

【0023】

要素ＤＢ１１４は、非機能要件を実装するための設定情報である要素を格納するデータベースである。なお、要素ＤＢ１１４は、アーキテクチャ設計支援システム１００とは異なる外部サーバが保持してもよい。要素ＤＢ１１４の詳細は図２Ａ及び図２Ｂを用いて説明する。

【0024】

履歴ＤＢ１１５は、ＩＴシステムのアーキテクチャの実装の履歴を格納するデータベースである。履歴ＤＢ１１５の詳細は図３Ａ及び図３Ｂを用いて説明する。

【0025】

組合せ決定部１１１は、要素ＤＢ１１４を参照して、指定された非機能要件を実現するための要素を抽出し、要素の組合せを決定する。

【0026】

検証部１１２は、組合せ決定部１１１が決定した要素の組合せについて、開発、実装、及び運用等の観点に基づいた評価指標であるコストを算出し、コストに基づいて要素の組合せの推薦順位（適用順位）を決定するための優先度を決定する。コストは、例えば、ＩＴシステムの導入及び維持に要するコスト、実装に要する工数、ＩＴシステムにおけるサービスの管理レベル等である。

【0027】

代替案生成部１１３は、履歴ＤＢ１１５を参照して、要素の変更方法を特定し、特定された変更方法に基づいて要素の組合せの要素を修正することによって代替案を生成する。ここで、要素の変更とは、要素の変数及びパラメータの修正、及び、要素そのものの変更を含む概念である。

【0028】

なお、アーキテクチャ設計支援システム１００は、プロセッサ、メモリ、及びネットワークインタフェースを有する計算機を用いて実現される。

【0029】

図２Ａ及び図２Ｂは、実施例１の要素ＤＢ１１４のデータ構造の一例を示す図である。

【0030】

要素ＤＢ１１４は、非機能要件を実現するための要素を管理するための情報として、例えば、図２Ａに示すようなテーブル２００を格納する。本実施例では、非機能要件は、非特許文献１の非機能要件グレード表に示される非機能要件の項目、及び対象に基づいて分類される。また、要件レベルは各要素が対応可能な非機能要件の範囲を相対的に示す数値として定義される。テーブル２００は、ＩＤ２０１、項目２０２、対象２０３、要件レベル２０４、及び要素２０５から構成されるエントリを格納する。

【0031】

例えば「データベースを対象にした要件レベル３の耐障害性に関する非機能要件」を実現する要素は「ＲＤＳ ｆｏｒ Ａｕｒｏｒａ」であることを示している。なお、項目、対象、及び要件レベルが同一である非機能要件を実現するための要素は複数存在してもよく、非機能要件の情報に対応する要素が１対１になるようにテーブル２００に新たなフィールドを追加してもよい。

【0032】

要素２０５には、例えば、図２Ｂに示すようなデータ構造のデータ２５０が格納される。データ２５０は、非機能要件を実現するために必要な情報を含む。例えば、データ２５０には、非機能要件を実現するリソースの名称２５１、リソースの構造、パラメータ、及び設定を表すコード２５２、並びに、コストに関する変数２５３等が含まれる。なお、図２Ｂに示すデータ２５０は一例であってこれに限定されない。例えば、リソース間の詳細な構造をメインリソース及びサブリソースとして含んでもよいし、パラメータの重要度及び設定方法を含んでもよい。

【0033】

データ２５０は、例えば、クラウドベンダが提供するＩａＣ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ Ｃｏｄｅ）の形式で記述されてもよく、箇条書きのテキストでもよい。

【0034】

図３Ａ及び図３Ｂは、実施例１の履歴ＤＢ１１５のデータ構造の一例を示す図である。

【0035】

履歴ＤＢ１１５は、非機能要件の実装履歴を格納する。履歴ＤＢ１１５は、例えば、図３Ａに示すような履歴テーブル３００及び図３Ｂに示すような採否結果テーブル３１０を格納する。なお、履歴ＤＢ１１５には、非機能要件の実装状況を管理するテーブル等が含まれてもよい。

【0036】

履歴テーブル３００は、ＩＴシステムに実装された非機能要件を実現するための要素を管理するためのエントリ（実装履歴）を格納する。エントリは、ＩＤ３０１、要素リスト３０２、及び基本構成３０３を含む。要素リスト３０２は、ＩＴシステムに実装された要素のＩＤ（ＩＤ２０１）のリストを格納するフィールドである。基本構成３０３は、ＩＴシステムのリファレンスアーキテクチャを格納するフィールドである。なお、基本構成３０３は、ＩＴシステムの主目的、ドメイン、及び構成図等が格納されてもよい。

【0037】

要素は、要素ＤＢ１１４にて非機能要件と関連付けて管理される。そのため、履歴テーブル３００から、ＩＴシステムにどの非機能要件の要素が実装されているかを把握することができる。また、非機能要件の要素が実装されたＩＴシステムのアーキテクチャの詳細を把握できる。

【0038】

採否結果テーブル３１０は、ユーザによる要素の実装の採否の判断結果を管理するためのエントリ（実装判断履歴）を格納する。エントリは、ＩＤ３１１、履歴ＩＤ３１２、要素ＩＤ３１３、採用種別３１４、コスト情報３１５、及び理由３１６を含む。コスト情報３１５は、実装可否の判断において着目したコストに関する情報を格納するフィールドである。例えば、コストの種別及び判定式等が格納される。理由３１６は、ユーザが要素の実装を採用しなかった理由を格納するフィールドである。理由は、プルダウン形式で選択できるようにしてもよいし、ユーザによる自由記述でもよい。

【0039】

採否結果テーブル３１０から、要素の採否の判断基準を把握することができる。実装履歴と関連付けて実装判断履歴を管理することによって、任意のＩＴシステムにおける非機能要件の実装の優先順位を把握できる。

【0040】

図４は、実施例１のアーキテクチャ設計支援システム１００が実行する処理の一例を説明するフローチャートである。

【0041】

アーキテクチャ設計支援システム１００は、ユーザから非機能要件を含む設計要求を受け付けた場合、以下で説明する処理を開始する。ユーザは、非機能要件を指定する情報とし、項目及び対象を入力すればよい。なお、要件レベルを含めてもよい。要件レベルは数値で指定してもよいし、範囲で指定してもよい。

【0042】

組合せ決定部１１１は、要素ＤＢ１１４を参照して、指定された非機能要件に対応する要素を特定する（ステップＳ１０１）。

【0043】

組合せ決定部１１１は、指定された全ての非機能要件の要素の組合せを生成する（ステップＳ１０２）。

【0044】

組合せ決定部１１１は、要素の組合せ毎に整合性を確認し、実装可能な要素の組合せを特定する（ステップＳ１０３）。

【0045】

例えば、非機能要件αに対応する要素１と要素２、及び非機能要件βに対応する要素３があると仮定する。なお、要素１はサービスＡを、要素２と要素３はサービスＢを対象としている。このとき、非機能要件αとβを同時に満たす組合せとして要素１と要素３の組合せ、及び要素２と要素３の組合せが考えられる。しかし、サービスＡを対象とする要素１とサービスＢを対象とする要素３を組み合わせることはＩＴシステムの実装として適さない。そのため、組合せ決定部１１１は要素１と要素３の組合せを削除する。なお、実装可能な要素の組合せを特定するための情報として、ＩＴシステムの基本構成を用いてもよい。

【0046】

検証部１１２は、各要素の組合せのコストを算出する（ステップＳ１０４）。例えば、以下のようなコストが考えられる。

【0047】

（パターン１）実装に要する金額をコストとして算出する場合、検証部１１２は、クラウドベンダが提示する料金情報に基づいてコストを算出する。また、要素の組合せの実装前後の基本情報の差分に基づいてコストが算出されてもよい。

【0048】

（パターン２）実装に要する工数をコストとして算出する場合、検証部１１２は、要素に含まれるリソースの数、及び定義が必要な変数の数等に基づいてコストを算出する。なお、コストは、要素又は要素の実装履歴に基づいて算出できる。

【0049】

（パターン３）実装したＩＴシステムの運用の手間をコストとして算出する場合、検証部１１２は、要素の管理レベル及びサービスタイプ等に基づいてコストを算出する。なお、コストは、要素又は要素の実装履歴に基づいて算出できる。

【0050】

検証部１１２は、要素の組合せに含まれる各要素のコストの合計値、最大値、最小値、及び平均値を要素の組合せのコストとして算出する。なお、要素の重複する内容を考慮してコストが算出されてもよい。

【0051】

検証部１１２は、コストに基づいて、要素の組合せの優先度を決定する（ステップＳ１０５）。例えば、コストの低い順に優先度を高く設定する方法が考えられる。

【0052】

なお、複数種類のコストが算出されている場合、各種コストの合計値、又は任意のコストに基づいて優先度が決定されてもよい。また、検証部１１２は、履歴ＤＢ１１５に基づいて、着目するコストを特定してもよい。優先度の決定方法の詳細は後述する。

【0053】

アーキテクチャ設計支援システム１００は、優先度に基づいて、要素の組合せをソートし、ユーザに提示する（ステップＳ１０６）。

【0054】

ユーザは、要素の組合せを確認し、コスト制約条件を決定し、アーキテクチャ設計支援システム１００に入力する。コスト制約条件は、コスト又は優先度に関する条件式、及び選択する要素の組合せの数等である。

【0055】

検証部１１２は、ユーザからコスト制約条件を取得した場合、コスト制約条件を満たす要素の組合せが存在するか否かを判定する（ステップＳ１０７）。

【0056】

コスト制約条件を満たす要素の組合せが存在する場合、検証部１１２は、当該要素の組合せを出力し（ステップＳ１０８）、その後、処理を終了する。

【0057】

コスト制約条件を満たす要素の組合せが存在しない場合、代替案生成部１１３は、代替案となる要素の組合せを生成する（ステップＳ１０９）。代替案は、１つでもよいし、複数でもよい。

【0058】

例えば、代替案生成部１１３は、履歴ＤＢ１１５に基づいて、ある要素の組合せにおいて実装頻度が低い要素を特定し、当該要素の要件レベル等を変更することによって代替案を生成する。このとき、代替案生成部１１３は、代替案のコストを算出し、コスト制約条件を満たすか否かを判定する。

【0059】

代替案生成部１１３は、コスト制約条件を満たす代替案を出力し（ステップＳ１１０）、その後、処理を終了する。

【0060】

なお、ステップＳ１０７において、コスト制約条件を満たす要素の組合せと、コスト制約条件を満たさない要素の組合せとが存在する場合、代替案生成部１１３はステップＳ１０９に進んでもよい。

【0061】

以下、図５から図１２を用いて各処理を具体的について説明する。

【0062】

まず、図５を用いて要素の組合せの生成方法について説明する。図５は、実施例１のアーキテクチャ設計支援システム１００による非機能要件の要素の特定方法及び要素の組合せの生成方法の一例を説明する図である。

【0063】

アーキテクチャ設計支援システム１００は以下のような非機能要件を指定する情報を受け付けたものとする（図５（Ａ）参照）。

【0064】

（非機能要件１）項目は耐障害性、対象はデータベース、要件レベルは２以上
（非機能要件２）項目はバックアップ、対象はデータベース、要件レベルは２以上

【0065】

ステップＳ１０１では、図５（Ｂ）に示すように、組合せ決定部１１１は、図２Ａに示すテーブル２００を参照し、非機能要件１を実現するための要素として「ＲＤＳ ｆｏｒ Ａｕｒｏｒａ」及び「ＲＤＳ（Ｍｕｌｔｉ）」を特定し、非機能要件２を実現するための要素として「ＡＷＳ Ｂａｃｋｕｐ」、「Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｒ」、「ＲＤＳ（ｂａｃｋｕｐ）」を特定する。

【0066】

ステップＳ１０２では、図５（Ｃ）に示すように、組合せ決定部１１１は６つの要素の組合せを生成する。

【0067】

「ＲＤＳ ｆｏｒ Ａｕｒｏｒａ」及び「ＲＤＳ（Ｍｕｌｔｉ）」の対象はＲＤＳであるが、「Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｒ」の対象はＥＣ２であり、対象が異なる。そのため、同一のデータベースに適用する要素としては同時に実装できない。したがって、ステップＳ１０３では、図５（Ｄ）に示すように、組合せ決定部１１１は、「ＲＤＳ ｆｏｒ Ａｕｒｏｒａ、Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｒ」及び「ＲＤＳ（Ｍｕｌｔｉ）、Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｒ」を含む要素の組合せを削除し、４つの要素の組合せを出力する。

【0068】

次に、図６を用いてコストの算出方法について説明する。図６は、実施例１のアーキテクチャ設計支援システム１００によるコストの算出方法の一例を説明する図である。

【0069】

ここでは、要素の組合せ「ＲＤＳ（Ｍｕｌｔｉ）、ＲＤＳ（ｂａｃｋｕｐ）」のコストの算出方法を説明する。

【0070】

まず、金銭コストの算出方法について説明する。本実施例では、要素に対して金銭コストの算出方法が事前に設定されているものとする。例えば、要素ＲＤＳ（Ｍｕｌｔｉ）については式（１）に示すような算出方法が設定され、要素ＲＤＳ（ｂａｃｋｕｐ）については式（２）に示すような算出方法が設定される。

【0071】

【数1】

【0072】

【数2】

【0073】

上記のコストの算出式の変数は異なるため、検証部１１２は、式（１）及び式（２）の各々から得られる値の総和を金銭コストとして算出する。

【0074】

次に、実装／運用コストの算出方法について説明する。検証部１１２は、要素ＲＤＳ（Ｍｕｌｔｉ）及び要素ＲＤＳ（ｂａｃｋｕｐ）から図６に示すような情報を得ることができる。検証部１１２は、２つの要素がいずれも同じ特徴をもち、管理レベルがマネージド、サービスタイプが単体、サブリソースが４つであることが分かる。また、要素ＲＤＳ（Ｍｕｌｔｉ）は実装に必要な変数として変数１と変数２を合わせて２つの変数を含み、要素ＲＤＳ（ｂａｃｋｕｐ）は実装に必要な変数として変数１と変数２を合わせて３つの変数を含むことが分かる。

【0075】

検証部１１２は、要素から取得した情報を比較し、同時に実装する場合のコストを算出する。例えば、検証部１１２は、管理レベル、サービスタイプ、構成の数、及び変数の数を実装／運用コストとして算出する。図６に示す例では、サービスタイプは単体となり、変数１の数は３となり、変数２の数は要素間で変数が共通するため１となり、変数３の数は０となる。サブリソースの数は構成間で共通するため４つとなり、これに共通するメインリソースであるＲＤＳを加えた５つが構成数となる。また、検証部１１２は、要素の組合せにおける管理レベルの組合せをコストに変換する。例えば、全ての要素の管理レベルがセルフマネージドの場合コスト小とし、セルフマネージド及びマネージドが混在する場合コスト中とし、全ての要素の管理レベルがマネージドの場合コスト大とする。

【0076】

次に、図７から図１０を用いて、優先度の決定方法について説明する。

【0077】

図７、図８、及び図９は、実施例１のアーキテクチャ設計支援システム１００が実行する優先度の決定処理の一例を説明するフローチャートである。図１０は、実施例１の優先度の具体的な決定方法を示す図である。

【0078】

まず、図７の優先度の決定処理について説明する。検証部１１２は、各要素の組合せについて、金銭コストを、順位を表す数値に変換し、また、実装／運用コストを、順位を表す数値に変換する（ステップＳ２０１）。数値の変換方法は、予め設定されている。例えば、検証部１１２は、コストの小さい順に小さい数値を出力する。

【0079】

例えば、図５で示した各要素の組合せについて、図１０（Ａ）に示すようなコストが算出されている場合、検証部１１２は、図１０（Ｂ）に示すように数値に変換する。

【0080】

検証部１１２は、各要素の組合せについて、各コストから算出された数値に基づいて、総合コストを算出する（ステップＳ２０２）。

【0081】

例えば、検証部１１２は、各コストから算出された数値の合計値を総合コストとして算出する。また、数値の重み付け和から総合コストが算出されてもよい。

【0082】

検証部１１２は、総合コストに基づいて、要素の組合せの優先度を決定する（ステップＳ２０３）。

【0083】

例えば、総合コストが小さい要素の組合せが優先的に表示されるように、優先度が付与される。なお、総合コストが同一の要素の組合せについては同一の優先度が付与されてもよいし、個別のコストの比較結果に基づいて一意な優先度が付与されてもよい。

【0084】

各コストの数値の合計値を総合コストとする場合、図７の決定方法では、図５（Ｄ）のＩＤが３、４の要素の組合せに高い優先度が付与され、図５（Ｄ）のＩＤが１、２の要素の組合せに低い優先度が付与される。高い優先度が付与された要素の組合せが優先的にユーザに提示される。

【0085】

次に、図８の優先度の決定方法について説明する。検証部１１２は、各要素の組合せの基準コストに基づいて、要素の組合せの優先度を決定する（ステップＳ３０１）。なお、基準コストが同一の要素の組合せについては同一の優先度が付与されてもよいし、他のコストの比較結果に基づいて一意な優先度が付与されてもよい。

【0086】

基準コストは、優先度を決定するために使用するコストであり、予め設定されてもよいし、ユーザが選択できるようにしてもよい。なお、基準コストは複数でもよい。

【0087】

構成数が基準コストである場合、図５（Ｄ）のＩＤが４の要素、ＩＤが２の要素、ＩＤが３の要素、ＩＤが１の要素の順に高い優先度が付与される。

【0088】

次に、図９の優先度の決定方法について説明する。検証部１１２は、採否結果テーブル３１０を参照して、基準コストを特定する（ステップＳ４０１）。

【0089】

例えば、検証部１１２は、採否結果テーブル３１０の各エントリのコスト情報３１５に基づいて、各種コストの使用頻度を算出する。検証部１１２は、最も使用頻度が高い種別のコストを基準コストとして特定する。

【0090】

なお、要素又は基本構成が類似するエントリのみを用いて使用頻度が算出されてもよい。また、基準コストは複数でもよい。

【0091】

検証部１１２は、各要素の組合せの基準コストに基づいて、要素の組合せの優先度を決定する（ステップＳ４０２）。なお、基準コストが同一の要素の組合せについては同一の優先度が付与されてもよいし、他のコストの比較結果に基づいて一意な優先度が付与されてもよい。

【0092】

サービスタイプが基準コストとして特定された場合、図５（Ｄ）のＩＤが１、３の要素の組合せには高い優先度が付与され、図５（Ｄ）のＩＤが２、４の要素の組合せには低い優先度が付与される。

【0093】

次に、図１１から図１４を用いて代替案の生成方法について説明する。

【0094】

コスト制約条件を満たす要素の組合せが存在しない場合、組合せ内の一部の要素を変更することで、コスト制約条件を満たす要素の組合せを生成できる。しかし、非機能要件の変更には知識及び経験を要する。実施例１のアーキテクチャ設計支援システム１００は、過去の非機能要件の実装履歴を用いて要素の変更方法を特定し、代替案を生成する。

【0095】

図１１Ａ及び図１１Ｂは、実施例１のアーキテクチャ設計支援システム１００が実行する代替案の生成処理の一例を説明するフローチャートである。

【0096】

図１１Ａ及び図１１Ｂに示す代替案の生成方法では、実装頻度に基づいて要素の変更が行われる。まず、代替案生成部１１３は、検証部１１２が出力した要素の組合せの優先度に基づいて、ベースとなる要素の組合せを選択する。ベースとなる要素の組合せは１つでもよいし、複数でもよい。ここでは、ベースとなる要素の組合せが１つ選択されたものとする。ベースとなる要素の組合せが複数選択された場合、各要素の組合せに対して以下で説明する処理が実行される。

【0097】

代替案生成部１１３は、履歴テーブル３００を参照して、ベースとなる要素の組合せに対応した各非機能要件の実装頻度を算出する（ステップＳ５０１）。ここで、非機能要件の実装頻度は、非機能要件を実現するための要素が実装された回数を表す。

【0098】

具体的には、代替案生成部１１３は、非機能要件を実現するための要素を特定する。代替案生成部１１３は、特定された要素のＩＤを要素リスト３０２に格納するエントリの数を、非機能要件の実装頻度として算出する。

【0099】

なお、基本構成が類似するエントリのみを検索対象としてもよい。また、ユーザが実行頻度を算出する非機能要件を指定してもよい。

【0100】

代替案生成部１１３は、各非機能要件の実装頻度に基づいて、変更可能な非機能要件が存在するか否かを判定する（ステップＳ５０２）。

【0101】

具体的には、代替案生成部１１３は、ベースとなる要素の組合せに対応した非機能要件間の実装頻度差分を算出する。非機能要件間の実装頻度に差分が存在する場合、代替案生成部１１３は、変更可能な非機能要件が存在すると判定する。

【0102】

変更可能な非機能要件が存在しない場合、代替案生成部１１３はステップＳ５１２に進む。

【0103】

変更可能な非機能要件が存在する場合、代替案生成部１１３は、変更対象の非機能要件を選択する（ステップＳ５０３）。ここでは、実装頻度が小さい順に非機能要件が選択されるものとする。すなわち、実装の実績が低い非機能要件が変更対象の非機能要件として選択される。

【0104】

代替案生成部１１３は、選択した非機能要件に対応する要素が変更可能か否かを判定する（ステップＳ５０４）。

【0105】

例えば、要素の変数又はパラメータの修正に伴ってコストが変化しない場合、又は、現在の非機能要件のレベルと同一の他の要素又は当該レベルが異なる他の要素に変更してもコストが変化しない場合、選択した要素は変更可能でないと判定される。これは、要素の変更を行っても、コスト制約条件を満たすことがないためである。

【0106】

選択した非機能要件に対応する要素が変更可能ではない場合、代替案生成部１１３は、非機能要件の実装頻度が所定の閾値より小さいか否かを判定する（ステップＳ５０５）。これは、ＩＴシステムのアーキテクチャに実装される機会が少ない非機能要件であるか否かを判定するものである。

【0107】

非機能要件の実装頻度が所定の閾値以上である場合、代替案生成部１１３はステップＳ５０７に進む。

【0108】

非機能要件の実装頻度が所定の閾値より小さい場合、代替案生成部１１３は、非機能要件に対応する要素を含む操作データにＲｅｍｏｖｅフラグを付与し、代替案候補スタックに追加する（ステップＳ５０６）。その後、代替案生成部１１３はステップＳ５０７に進む。Ｒｅｍｏｖｅフラグは、要素の削除操作を示すフラグである。

【0109】

ステップＳ５０７では、代替案生成部１１３は、選択可能な変更対象の要素が存在する否かを判定する（ステップＳ５０７）。

【0110】

選択可能な変更対象の要素がない場合、代替案生成部１１３はステップＳ５１２に進む。

【0111】

選択可能な変更対象の要素がある場合、代替案生成部１１３は、ステップＳ５０３に戻る。

【0112】

なお、ステップＳ５０５及びステップＳ５０６の処理は実行されなくてもよい。ステップＳ５０４の判定結果がＮＯである場合、代替案生成部１１３は、ステップＳ５０７に進む。

【0113】

ステップＳ５０４において、選択した非機能要件に対応する要素が変更可能である場合、代替案生成部１１３は、当該要素の変更方法を特定する（ステップＳ５０８）。

【0114】

具体的には、代替案生成部１１３はコストが変動する変更方法を抽出する。変更方法としては、要素の変数又はパラメータの修正又は要素の変更である。複数の変更方法が抽出された場合、代替案生成部１１３は、１つ又は任意の数の変更方法を選択してもよい。

【0115】

なお、代替案生成部１１３は、選択した非機能要件の実装履歴を参照し、現在の要素と実装履歴の要素とを比較して、変更方法を特定してもよい。

【0116】

代替案生成部１１３は、特定された変更方法による要素の変更に伴って他の要素へ影響を与えるか否かを判定する（ステップＳ５０９）。

【0117】

要素の変更に伴って、ステップＳ１０３で説明したように、他の要素と共存できなくなる等の影響がある。そのため、影響の有無が確認される。例えば、代替案生成部１１３は、特定された変更方法にしたがって要素の変更を実施し、変更後の要素と他の要素を比較し、他の要素についても変更が必要か否かを判定する。なお、基本構成への影響の有無を考慮してもよい。

【0118】

要素の変更に伴って他の要素へ影響を与えない場合、代替案生成部１１３は、現在の要素及び変更方法を対応づけた操作データにＣｈａｎｇｅフラグを付与し、代替案候補スタックに追加する（ステップＳ５１０）。その後、代替案生成部１１３はステップＳ５１２に進む。Ｃｈａｎｇｅフラグは、変更対象の要素の変更の実施を示すフラグである。

【0119】

要素の変更の実施に伴って他の要素へ影響を与える場合、代替案生成部１１３は、他の要素の変更方法を特定し、現在の要素、他の要素、及び変更方法を対応づけた操作データにＬｉｎｋ－Ｃｈａｎｇｅフラグを付与し、代替案候補スタックに追加する（ステップＳ５１１）。その後、代替案生成部１１３はステップＳ５１２に進む。Ｌｉｎｋ－Ｃｈａｎｇｅフラグは、変更対象の要素及び影響を受ける他の要素の変更の実施を示すフラグである。

【0120】

なお、他の要素の変更方法が存在しない場合、代替案生成部１１３はステップＳ５１２に進む。また、ステップＳ５１１の処理は省略してもよい。ステップＳ５０９がＹＥＳの場合、代替案生成部１１３はステップＳ５１２に進む。

【0121】

ステップＳ５１２では、代替案生成部１１３は、代替案候補スタックが空であるか否かを判定する（ステップＳ５１２）。

【0122】

代替案候補スタックが空ではない場合、代替案生成部１１３は、代替案候補スタックに格納される操作データの優先度を決定する（ステップＳ５１３）。

【0123】

具体的には、コスト制約条件を満たし、かつ、非機能要件が満たされる要素の組合せを実現する操作データに対して高い優先度が付与される。優先度の付与には、変更に伴うコストの差分、要件のレベル、他の要素への影響の程度等が考慮される。なお、優先度を決定するための要因は１つでもよいし、複数でもよい。

【0124】

代替案生成部１１３は、優先度が付与された操作データと、ベースとなる要素の組合せとに基づいて、代替案を生成する（ステップＳ５１４）。その後、代替案生成部１１３は処理を終了する。

【0125】

例えば、代替案生成部１１３は、優先度が最も高い操作データに基づいて、ベースとなる要素の組合せに含まれる要素の変更を実施することによって代替案を生成する。なお、代替案生成部１１３は、優先度に基づいて上位の操作データを複数選択し、選択した複数の操作データを組み合わせて代替案を生成してもよい。

【0126】

代替案候補スタックが空である場合、代替案生成部１１３は、代替案が生成できなかった旨を通知するメッセージを出力する（ステップＳ５１５）。その後、代替案生成部１１３は処理を終了する。

【0127】

なお、代替案生成部１１３は、基本構成に関する情報の追加、又は変更対象の非機能要件の選択条件の変更等によって、代替案を生成できる可能性を示唆するメッセージを出力してもよい。また、代替案生成部１１３は、実装履歴を参照することによって、代替案を生成できる可能性を示唆するメッセージを出力してもよい。

【0128】

ここで、代替案の具体的な生成について説明する。

【0129】

（ケース１）図５（Ｄ）のＩＤが３の要素の組合せがベースであり、ステップＳ５０３において「非機能要件１」が選択され、ステップＳ５０４において要素「ＲＤＳ（Ｍｕｌｔｉ）」については要件レベルを下げることで金銭コストが下がることが分かったものとする。ステップＳ５０８において、代替案生成部１１３は、要素を「ＭｙＳＱＬ－ＭｕｌｔｉＡｚ」に変更する変更方法を特定する。当該変更方法は、ベースとなる要素の組合せの他の要素「ＡＷＳ Ｂａｃｋｕｐ」に影響を与えない。そのため、代替案生成部１１３は、ステップＳ５１０において、要素「ＲＤＳ（Ｍｕｌｔｉ）」及び前述の変更方法とを対応づけた操作データに、Ｃｈａｎｇｅフラグを付与し、代替案候補スタックに追加する。

【0130】

（ケース２）図５（Ｄ）のＩＤが４の要素の組合せがベースであり、ステップＳ５０３において「非機能要件１」が選択され、ステップＳ５０４において要素「ＲＤＳ（Ｍｕｌｔｉ）」については要件レベルを下げることで金銭コストが下がることが分かったものとする。ステップＳ５０８において、代替案生成部１１３は、要素を「ＭｙＳＱＬ－ＭｕｌｔｉＡｚ」に変更する変更方法を特定する。当該変更方法は、ベースとなる要素の組合せの他の要素「ＲＤＳ（ｂａｃｋｕｐ）」に影響を与えるため、要素「ＲＤＳ（ｂａｃｋｕｐ）」について変更が必要となる。ここでは、要素「ＲＤＳ（ｂａｃｋｕｐ）」を「Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｒ」に変更する変更方法が特定されたものとする。この場合、代替案生成部１１３は、ステップＳ５１０において、要素「ＲＤＳ（Ｍｕｌｔｉ）」、要素「ＲＤＳ（ｂａｃｋｕｐ）」、及び前述の変更方法を対応づけた操作データにＬｉｎｋ－Ｃｈａｎｇｅフラグを付与し、代替案候補スタックに追加する。

【0131】

要件レベルに基づいて優先度を付与する場合、ケース１の操作データに高い優先度が付与され、ケース２の操作データに低い優先度が付与される。

【0132】

ここで、実装／運用コストに基づく制約条件を満たさない場合の代替案の生成方法の一例を説明する。図５（Ｄ）のＩＤが１の要素の組合せがベースであり、ステップＳ５０３において「非機能要件１」が選択されたものとする。要素「ＲＤＳ ｆｏｒ Ａｕｒｏｒａ」の運用コストを下げるためには、亜要件レベル又は管理レベルを上げる必要がある。ここで、要素を「Ａｕｒｏｒａ Ｓｅｒｖｅｒｌｅｓｓ」に変更することによって実装／運用コストが下がることが分かったものとする。ステップＳ５０８において、代替案生成部１１３は、要素を「Ａｕｒｏｒａ Ｓｅｒｖｅｒｌｅｓｓ」に変更する変更方法を特定する。当該変更方法は、ベースとなる要素の組合せの他の要素「ＡＷＳ Ｂａｃｋｕｐ」に影響を与えない。そのため、代替案生成部１１３は、ステップＳ５１０において、要素「ＲＤＳ ｆｏｒ Ａｕｒｏｒａ」及び前述の変更方法を対応づけた操作データに、Ｃｈａｎｇｅフラグを付与し、代替案候補スタックに追加する。

【0133】

図１２Ａ及び図１２Ｂは、実施例１のアーキテクチャ設計支援システム１００が実行する代替案の生成処理の一例を説明するフローチャートである。

【0134】

図１２Ａ及び図１２Ｂに示す代替案の生成方法では、非機能要件のレベルに基づいて要素の変更を行う。まず、代替案生成部１１３は、検証部１１２が出力した要素の組合せの優先度に基づいて、ベースとなる要素の組合せを選択する。ベースとなる要素の組合せは１つでもよいし、複数でもよい。ここでは、ベースとなる要素の組合せが１つ選択されたものとする。ベースとなる要素の組合せが選択された場合、各要素の組合せに対して以下で説明する処理が実行される。

【0135】

代替案生成部１１３は、履歴テーブル３００を参照して、ベースとなる要素の組合せに対応した非機能要件が過去に実装された際のレベルを算出する（ステップＳ６０１）。ここで、非機能要件のレベルは、要件レベル又は管理レベルである。

【0136】

具体的には、代替案生成部１１３は、履歴テーブル３００を参照し、各構成要素のレベルを取得する。代替案生成部１１３は、要素ＤＢ１１４を参照し、同一の非機能要件を実現する要素のレベルを用いて、非機能要件のレベルを算出する。非機能要件のレベルは、最も頻出するレベルでもよいし、レベルの範囲でもよい。

【0137】

なお、基本構成が類似するエントリのみを検索対象としてもよい。また、ユーザが実行レベルを算出する非機能要件を指定してもよい。

【0138】

代替案生成部１１３は、各非機能要件のレベルに基づいて、変更可能な非機能要件が存在するか否かを判定する（ステップＳ６０２）。

【0139】

具体的には、代替案生成部１１３は、ユーザが指定した非機能要件のレベルが、算出した非機能要件のレベルと異なるか否かを判定する。２つのレベルが異なる場合、当該非機能要件は変更可能な非機能要件であると判定される。

【0140】

例えば、金銭コストに関するコスト制約条件を満たす代替案を生成する場合、ユーザが指定したレベルが算出したレベルより高い場合、レベルを変更することによって金銭コストが削減される可能性がある。そのため、前述のようなレベルの違いがある非機能要件は変更可能な非機能要件となる。

【0141】

例えば、実装／運用コストに関するコスト制約条件を満たす代替案を生成する場合、ユーザが指定したレベルが算出したレベルより低い場合、レベルを変更することによって実装／運用コストが削減される可能性がある。そのため、前述のようなレベルの違いがある非機能要件は変更可能な非機能要件となる。

【0142】

変更可能な非機能要件が存在しない場合、代替案生成部１１３はステップＳ６１０に進む。

【0143】

変更可能な非機能要件が存在する場合、代替案生成部１１３は、変更対象の非機能要件を選択する（ステップＳ６０３）。ここでは、レベルの差分が大きい順に非機能要件が選択されるものとする。すなわち、ユーザが指定した非機能要件のレベルが過去の実装履歴と比較して過剰又は不足している非機能要件が変更対象の非機能要件として選択される。

【0144】

代替案生成部１１３は、選択した非機能要件に対応する要素が変更可能か否かを判定する（ステップＳ６０４）。

【0145】

例えば、代替案生成部１１３は、要素の変数若しくはパラメータの修正に伴ってコストが変わらない場合、又は、現在の非機能要件のレベルと同一の他の要素若しくは当該レベルと異なる他の要素への変更に伴ってコストが変わらない場合、選択した要素は変更可能でないと判定される。これは、要素の変更を行っても、コスト制約条件を満たすことがないためである。

【0146】

選択した非機能要件に対応する要素が変更可能ではない場合、代替案生成部１１３は、全ての変更対象の要素の判定が完了したか否かを判定する（ステップＳ６０５）。

【0147】

全ての変更対象の要素の判定が完了していない場合、代替案生成部１１３はステップＳ６０３に戻る。

【0148】

全ての変更対象の要素の判定が完了した場合、代替案生成部１１３はステップＳ６１０に進む。

【0149】

ステップＳ６０４において、選択した非機能要件に対応する要素が変更可能である場合、代替案生成部１１３は、当該要素の変更方法を特定する（ステップＳ６０６）。ステップＳ６０６の処理はステップＳ５０８の処理と同一である。

【0150】

代替案生成部１１３は、特定された変更方法による要素の変更に伴って他の要素へ影響を与えるか否かを判定する（ステップＳ６０７）。ステップＳ６０７の処理はステップＳ５０９の処理と同一である。

【0151】

要素の変更に伴って他の要素へ影響を与えない場合、代替案生成部１１３は、現在の要素及び変更方法を対応づけた操作データにＣｈａｎｇｅフラグを付与し、代替案候補スタックに追加する（ステップＳ６０８）。その後、代替案生成部１１３はステップＳ６１０に進む。ステップＳ６０８の処理はステップＳ５１０の処理と同一である。

【0152】

要素の変更に伴って他の要素へ影響を与える場合、代替案生成部１１３は、他の要素の変更方法を特定し、現在の要素、他の要素、及び変更方法を対応づけた操作データにＬｉｎｋ－Ｃｈａｎｇｅフラグを付与し、代替案候補スタックに追加する（ステップＳ６０９）。その後、代替案生成部１１３はステップＳ６１０に進む。ステップＳ６０９の処理はステップＳ５１１の処理と同一である。

【0153】

ステップＳ６１０では、代替案生成部１１３は、代替案候補スタックが空であるか否かを判定する（ステップＳ６１０）。ステップＳ６１０の処理はステップＳ５１２の処理と同一である。

【0154】

代替案候補スタックが空ではない場合、代替案生成部１１３は、代替案候補スタックに格納される操作データの優先度を決定する（ステップＳ６１１）。ステップＳ６１１の処理はステップＳ５１３の処理と同一である。

【0155】

代替案生成部１１３は、優先度が付与された操作データと、ベースとなる要素の組合せとに基づいて、代替案を生成する（ステップＳ６１２）。その後、代替案生成部１１３は処理を終了する。ステップＳ６１２の処理はステップＳ５１４の処理と同一である。

【0156】

ステップＳ６１０において、代替案候補スタックが空である場合、代替案生成部１１３は、代替案が生成できなかった旨を通知するメッセージを出力する（ステップＳ６１３）。その後、代替案生成部１１３は処理を終了する。ステップＳ６１３の処理はステップＳ５１５の処理と同一である。

【0157】

ここで、代替案の具体的な生成について説明する。

【0158】

（ケース１）図５（Ｄ）のＩＤが３の要素の組合せがベースであり、ステップＳ６０３において「非機能要件２」が選択されたものとする。ステップＳ６０４において、要素を「ＡＷＳ Ｂａｃｋｕｐ」に変更した場合、変更後の要素の組合せは、図５（Ｄ）のＩＤが４の要素の組合せと同一となる。そのため、ステップＳ６０４の判定結果はＮＯとなる。

【0159】

（ケース２）図５（Ｄ）のＩＤが４の要素の組合せがベースであり、ステップＳ６０３において「非機能要件２」が選択されたものとする。ステップＳ６０４において、要素「ＲＤＳ（ｂａｃｋｕｐ）」のパラメータを修正することによって、金銭コストが下がることが分かったものとする。ステップＳ６０６では、代替案生成部１１３は、要素「ＲＤＳ（ｂａｃｋｕｐ）」のパラメータを修正する変更方法を特定する。要素「ＲＤＳ（ｂａｃｋｕｐ）」のパラメータの修正は他の要素に影響を与えない。そのため、代替案生成部１１３は、要素「ＲＤＳ（ｂａｃｋｕｐ）」及び前述の変更方法を対応づけた操作データにＣｈａｎｇｅフラグを付与し、代替案候補スタックに追加する。

【0160】

実施例１のアーキテクチャ設計支援システム１００は、コストに基づいて要素の組合せの推薦順位を決定し、ユーザに提示する。これによって、ユーザは優先的に採用すべき要素の組合せを把握できる。また、実施例１のアーキテクチャ設計支援システム１００は、コスト制約条件を満たす要素の組合せが存在しない場合、履歴に基づいて代替案を生成する。これによって、アーキテクチャ設計の変更及び決定を効率的に支援できる。要素の変更は履歴に基づいて特定されるため、履歴を根拠となるデータとして提示できる。

【実施例0161】

実施例２のアーキテクチャ設計支援システム１００の構成は実施例１と同一である。実施例２のアーキテクチャ設計支援システム１００は、非機能要件とともに、コスト制約条件の入力を受け付ける。この場合、アーキテクチャ設計支援システム１００は、ステップＳ１０６の処理が省略される。その他の処理は実施例１と同一である。

【0162】

予めコスト制約条件を受け付けることによって、要素の組合せ及びコスト制約条件の検証を自動的に実行することができる。

【0163】

実施例２のアーキテクチャ設計支援システム１００は、実施例１と同様の効果を得ることができる。さらに、実施例２のアーキテクチャ設計支援システム１００は、コスト制約条件の検証及び代替案の生成を迅速に行うことができる。