知財求人 - 知財ポータルサイト「IP Force」
特開2024-126151システム構成導出装置、システム構成導出方法およびプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024126151
(43)【公開日】2024-09-20
(54)【発明の名称】システム構成導出装置、システム構成導出方法およびプログラム
(51)【国際特許分類】
G06F 8/65 20180101AFI20240912BHJP
【ＦＩ】
G06F8/65
【審査請求】未請求
【請求項の数】6
【出願形態】ＯＬ
(21)【出願番号】P 2023034356
(22)【出願日】2023-03-07
(71)【出願人】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100149548
【弁理士】
【氏名又は名称】松沼 泰史
(74)【代理人】
【識別番号】100181135
【弁理士】
【氏名又は名称】橋本 隆史
(72)【発明者】
【氏名】桑原 拓也
【テーマコード（参考）】
5B376
【Ｆターム（参考）】
5B376BC38
5B376CA41
5B376DA11
(57)【要約】
【課題】更改コストがより小さいシステム構成を導出するシステム構成導出装置を提供する。
【解決手段】システム構成導出装置は、移行前システムと移行後システムの具体構成を入力とし、更改コストが少ない移行後システムの候補が有する特徴に対してより高い評価を行う構造フィードバック関数を出力する構造フィードバック算出手段と、機能要件と、移行前システムの構成を表現した具体構成である一次構成とを入力とし、機能要件に関する具体化を繰り返すことによって、機能要件が完全に具体化された構成を探索し、かつ、構造フィードバック算出手段が出力した構造フィードバック関数を利用して、更改コストが少ない具体構成を導出する構成情報具体化手段と、を備える。
【選択図】図１
【解決手段】システム構成導出装置は、移行前システムと移行後システムの具体構成を入力とし、更改コストが少ない移行後システムの候補が有する特徴に対してより高い評価を行う構造フィードバック関数を出力する構造フィードバック算出手段と、機能要件と、移行前システムの構成を表現した具体構成である一次構成とを入力とし、機能要件に関する具体化を繰り返すことによって、機能要件が完全に具体化された構成を探索し、かつ、構造フィードバック算出手段が出力した構造フィードバック関数を利用して、更改コストが少ない具体構成を導出する構成情報具体化手段と、を備える。
【選択図】図１
【特許請求の範囲】
【請求項1】
抽象構成を、システムを構成する部品に相当するノードおよび前記部品間の関係性を示すエッジで構成されるグラフ構造を用いて未確定な部分が含まれている前記システムの構成を表現するものとし、具体化を、前記抽象構成の前記未確定な部分を確定させるような前記グラフ構造の変換とし、具体構成を、前記抽象構成に含まれる前記未確定な部分が全て具体化によって確定したものとする場合に、
移行前の前記システムである移行前システムおよび移行後の前記システムである移行後システムの候補の各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムの候補への更改コストが少ない前記移行後システムの候補が有する前記グラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力する構造フィードバック算出手段と、
前記抽象構成によって表現された前記移行後システムが備えるべき機能要件と、前記移行前システムの構成を表現した前記具体構成である一次構成とを入力とし、前記機能要件に関する前記具体化を繰り返すことによって、前記機能要件が完全に前記具体化された前記具体構成を探索し、前記一次構成と前記探索された前記具体構成とを元に、前記構造フィードバック算出手段が出力した前記構造フィードバック関数を利用して、前記更改コストが最も少ない前記具体構成を導出する構成情報具体化手段と、
を備えるシステム構成導出装置。
移行前の前記システムである移行前システムおよび移行後の前記システムである移行後システムの候補の各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムの候補への更改コストが少ない前記移行後システムの候補が有する前記グラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力する構造フィードバック算出手段と、
前記抽象構成によって表現された前記移行後システムが備えるべき機能要件と、前記移行前システムの構成を表現した前記具体構成である一次構成とを入力とし、前記機能要件に関する前記具体化を繰り返すことによって、前記機能要件が完全に前記具体化された前記具体構成を探索し、前記一次構成と前記探索された前記具体構成とを元に、前記構造フィードバック算出手段が出力した前記構造フィードバック関数を利用して、前記更改コストが最も少ない前記具体構成を導出する構成情報具体化手段と、
を備えるシステム構成導出装置。
【請求項2】
前記移行前システムおよび前記移行後システムの各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムへの更改にかかるコストを算出する更改コスト算出手段、
をさらに備える請求項１に記載のシステム構成導出装置。
をさらに備える請求項１に記載のシステム構成導出装置。
【請求項3】
前記移行前システムおよび前記移行後システムの各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムへの更改手順を算出する更改手順生成手段と
前記更改手順と、前記移行前システムから前記移行後システムへ更改するにあたり更改の対象となる前記ノードを示す更改対象ノードと、を入力とし、前記更改手順を実行するにあたり、前記更改対象ノードを更改する必要がなくなった場合の更改コストの見積り値を算出する単位構造フィードバック算出手段と、
をさらに備える請求項１に記載のシステム構成導出装置。
前記更改手順と、前記移行前システムから前記移行後システムへ更改するにあたり更改の対象となる前記ノードを示す更改対象ノードと、を入力とし、前記更改手順を実行するにあたり、前記更改対象ノードを更改する必要がなくなった場合の更改コストの見積り値を算出する単位構造フィードバック算出手段と、
をさらに備える請求項１に記載のシステム構成導出装置。
【請求項4】
前記構造フィードバック算出手段が出力する前記構造フィードバック関数は、前記抽象構成に含まれる各々の前記ノードが、前記移行前システムの状態と設定上整合する前記ノードに具体化されるときに正のフィードバックを与え、前記移行前システムや前記移行後システムに含まれない前記ノードに具体化されるときには負のフィードバックを与える、
請求項１から請求項３の何れかに記載のシステム構成導出装置。
請求項１から請求項３の何れかに記載のシステム構成導出装置。
【請求項5】
抽象構成を、システムを構成する部品に相当するノードおよび前記部品間の関係性を示すエッジで構成されるグラフ構造を用いて、未確定な部分が含まれている前記システムの構成を表現するものとし、具体化を、前記抽象構成の前記未確定な部分を確定させるような前記グラフ構造の変換とし、具体構成を、前記抽象構成に含まれる前記未確定な部分が全て具体化によって確定したものとする場合に、
移行前の前記システムである移行前システムおよび移行後の前記システムである移行後システムの候補の各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムの候補への更改コストが少ない前記移行後システムの候補が有する前記グラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力し、
前記抽象構成によって表現された前記移行後システムが備えるべき機能要件と、前記移行前システムの構成を表現した前記具体構成である一次構成とを入力とし、前記機能要件に関する前記具体化を繰り返すことによって、前記機能要件が完全に前記具体化された前記具体構成を探索し、前記一次構成と前記探索された前記具体構成とを元に、前記出力された前記構造フィードバック関数を利用して、前記更改コストが最も少ない前記具体構成を導出する、
システム構成導出方法。
移行前の前記システムである移行前システムおよび移行後の前記システムである移行後システムの候補の各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムの候補への更改コストが少ない前記移行後システムの候補が有する前記グラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力し、
前記抽象構成によって表現された前記移行後システムが備えるべき機能要件と、前記移行前システムの構成を表現した前記具体構成である一次構成とを入力とし、前記機能要件に関する前記具体化を繰り返すことによって、前記機能要件が完全に前記具体化された前記具体構成を探索し、前記一次構成と前記探索された前記具体構成とを元に、前記出力された前記構造フィードバック関数を利用して、前記更改コストが最も少ない前記具体構成を導出する、
システム構成導出方法。
【請求項6】
抽象構成を、システムを構成する部品に相当するノードおよび前記部品間の関係性を示すエッジで構成されるグラフ構造を用いて、未確定な部分が含まれている前記システムの構成を表現するものとし、具体化を、前記抽象構成の前記未確定な部分を確定させるような前記グラフ構造の変換とし、具体構成を、前記抽象構成に含まれる前記未確定な部分が全て具体化によって確定したものとする場合に、
コンピュータに、
移行前の前記システムである移行前システムおよび移行後の前記システムである移行後システムの候補の各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムの候補への更改コストが少ない前記移行後システムの候補が有する前記グラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力し、
前記抽象構成によって表現された前記移行後システムが備えるべき機能要件と、前記移行前システムの構成を表現した前記具体構成である一次構成とを入力とし、前記機能要件に関する前記具体化を繰り返すことによって、前記機能要件が完全に前記具体化された前記具体構成を探索し、前記一次構成と前記探索された前記具体構成とを元に、前記出力された前記構造フィードバック関数を利用して、前記更改コストが最も少ない前記具体構成を導出する処理、
を実行させるプログラム。
コンピュータに、
移行前の前記システムである移行前システムおよび移行後の前記システムである移行後システムの候補の各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムの候補への更改コストが少ない前記移行後システムの候補が有する前記グラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力し、
前記抽象構成によって表現された前記移行後システムが備えるべき機能要件と、前記移行前システムの構成を表現した前記具体構成である一次構成とを入力とし、前記機能要件に関する前記具体化を繰り返すことによって、前記機能要件が完全に前記具体化された前記具体構成を探索し、前記一次構成と前記探索された前記具体構成とを元に、前記出力された前記構造フィードバック関数を利用して、前記更改コストが最も少ない前記具体構成を導出する処理、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、更改コスト最適化を目的としたシステム構成導出装置、システム構成導出方法およびプログラムに関する。
【背景技術】
【0002】
サービス運用等の目的でICT（Information and Communication Technology）システムを構築する際には、システム構成の設計作業が必要である。システム構成の設計作業には、所望のシステムに求められる要件（以下、「システム要件」と称する。）を満たすために必要なシステムの構成部品及びその接続関係（以下、これらをまとめて「システム構成」と称する。）を不足なく構築し、更にシステム全体が正常に動作するために必要な設定項目を全て正しく設定しなくてはならない。これは非常に工数のかかる作業となる可能性がある。
【0003】
上記の設計工程、すなわちシステム要件からシステム構成へと具体化していく過程を自動化する技術が自動設計技術である。既存の自動設計技術としては、ICTシステムの特定のドメイン、例えばネットワーク経路や計算リソースの配置等に問題を制限し、その上である種の最適化問題等を解くことで自動設計を行うものが多いものの、汎用的な要件記述に対応するための技術も研究が進んでいる。たとえば、特許文献１には、システムの構成を効率的に導出することができるシステム構成導出装置が開示されている。
【0004】
また、非特許文献１には、グラフ様のフォーマットによる汎用的なシステム構成情報モデルを用いて記述した要件を元に、システム構成を自動で導出する技術についての記載がある。非特許文献１に記載の技術によれば、必要なモデルを用意することで汎用的かつ多面的な要件を入力とした自動設計が可能となる。
【0005】
非特許文献１に記載の汎用的なモデルによって記述可能な要件とは、主に機能や機器などの部品がノード(節点)として表現され、さらにそのノード間の関連性がエッジ (向きづけられた辺)によって表現されたグラフ的表現によって指定されたもの（以下これを「抽象構成」と呼ぶ）である。たとえば、「2台のサーバの間でTCP(Transmission Control Protocol)による通信が可能」という要件は、それぞれのサーバに相当するノードが「TCP通信可能」を表現するエッジによって接続されることによって構成された抽象構成として表現される。非特許文献１に記載の手法は前記の抽象構成に含まれる抽象的な「TCP通信可能」エッジを具体化する方法を自動で導出する仕組みである。
【0006】
非特許文献１に記載の自動設計手法は与えられた要件を一度に具体化するわけではないことには注意が必要である。前記の自動設計手法では、抽象構成を1段階具体的な別の抽象構成に書換えるための規則（以下これを「具体化規則」と呼ぶ）をデータとして持っておき、このデータを、要件を表す抽象構成に順次適用していくことで段階的に具体的な抽象構成に変換していく。
【0007】
具体化規則は抽象構成に含まれる抽象的な要素（以下これを「単位要件」と呼ぶ）を、より具体的な別の構成要素へと変換する（以下ではこのことを、単位要件を「解決する」と言う。）方法について詳述されたデータである。形式的に言えば、具体化規則は抽象構成を変換することで単位要件を解決する方法を定義したものであり、抽象構成と同形式のグラフである2つのデータ (それぞれ「左辺」「右辺」と呼ぶ)から構成される。
【0008】
具体化規則の適用により要件に含まれる全ての単位要件が解決された抽象構成を得ることができれば、この抽象構成は一切抽象的な要素のない、完全に具体化されたシステム構成（以下では単に「具体構成」と呼ぶ）であると考えることができる。
【0009】
以上のようにして、システム要件の段階的な具体化により自動設計が可能になるわけであるが、前述の技術は、要件ベースのICTシステム構築後の運用・保守の一部を自動化する技術に応用することが可能である。
【0010】
以下では、自動設計技術を応用したサービス運用の手順の概要を説明する。
まずユーザ（以下「サービス運営」とする）が、所望のICTシステムに求められるシステム要件（以下「要件I(0)」とする）を構築する。これを元に、システム自動設計技術を使うことで要件を満足するシステム構成（以下「システムS(0)」とする）を生成することができ、サービス運営者は出力された設計を元にシステムを構築し、サービスの提供を開始する。
まずユーザ（以下「サービス運営」とする）が、所望のICTシステムに求められるシステム要件（以下「要件I(0)」とする）を構築する。これを元に、システム自動設計技術を使うことで要件を満足するシステム構成（以下「システムS(0)」とする）を生成することができ、サービス運営者は出力された設計を元にシステムを構築し、サービスの提供を開始する。
【0011】
システムS(0)の運用中に提供中のサービスに対し要件の変更を行う必要が生じた場合、サービス運営者はシステムS(0)を変更するのではなく、必要な要件の変更を要件I(0)に反映させ、新たな要件I(1)を構築し、再度システム自動設計装置に入力しシステムS(1)を得る。これにより、要件の変更に対応した新システムを提供することができるようになる。
【0012】
また、システムS(1)の運用中に何らかの障害が発生した場合も、サービス運営者は発生した障害を復旧するために必要な対応を要件I(1)に反映させ、新たな要件I(2)を構築し、再度システム自動設計装置に入力しシステムS(2)を得る。これにより、自動でシステムに対する障害対応を適用することができるようになる。
【0013】
以降、運用中のシステムに何らかの変更を加えなければならない事情が生じるたびに要件を変更し、これを自動設計装置に入力することでシステム設計に必要な変更を行うことができる。
以上が、自動設計技術を応用したサービス運用の説明である。
以上が、自動設計技術を応用したサービス運用の説明である。
【0014】
上述したようにシステム自動設計装置の応用によってシステムの運用・保守を行うことにより、システム運用者が運用中のシステムではなく、システムの要件を通じてシステムの変更作業を行うことができる。これにより、システム自動運用のもつ「効率的に設計が可能」、「属人性の排除」。「品質の安定化」などの利点をシステム運用フェーズにおいても享受することができる。
【0015】
このように非特許文献１に記載の手法によれば、必要なシステム構成部品のモデルを整備し、これを組合せてシステム要件を抽象構成として指定することで、あらかじめ定義された具体化規則を適用することによって自動設計を行うことができる。よって、適切に定義されたシステム要件があれば、要件を変更したのちに再度設計しなおすプロセスを繰り返すことで、前述したシステムの運用・保守フェーズでの活用も可能である。
【0016】
しかし、各設計プロセスには問題がなくとも、システム運用・保守全体の流れにおいて生じてくる問題が存在する。以下では、ある1ステップの要件変更に着目し、この課題について述べる。着目する変更前のシステム要件を「一次要件」、変更後のシステム要件を「新規要件」と呼び、また一次要件を元に自動設計されたシステム構成を「一次構成」、新規要件を元に自動設計されたシステム構成を「新規構成」と呼ぶ。
【0017】
非特許文献１に記載の技術よれば、上述の自動設計装置は要件を満たす設計のうち、設計プロセスで最初に発見されたシステム構成を出力する。
【0018】
しかしながら、多く複雑な更新手順はその間に予期しないエラーや不具合をもたらす可能性を高め、長大な更新時間はサービス利用者の満足度を下げてしまうため、システムの運用中にシステムを更新する場合、その手順の数および更新にかかる時間（以下ではこれをまとめて「更改コスト」と呼ぶ）はなるべく少なくあるべきとされることが多い。したがって、自動設計技術によるシステム運用・保守を実現するためには、自動設計エンジンが一次構成からの更改コストがなるべく小さい新規構成を出力することが望ましい。
【0019】
しかし、一次構成からの更改の難しさを仕組み上反映することができない一般的なシステム自動設計技術では、より自律運用に好適な新規構成を出力することが難しい。
【0020】
以下では、一次構成から更改コストがなるべく小さい新規構成を出力することを難しくしている主たる要因の一つである、設計途中に更改コストを算出することの難しさについて述べる。
【0021】
まず、前提として時間的コストの大小はグラフ構造的な類似度に依存して決まるものではないことを説明する。そのために、以下に「一次構成により類似している構成のほうが、より類似していない構成より更改コストが少ない」という主張に対する反例を挙げる。
【0022】
図１８は要件４００を具体化することで3通りの具体構成Ｄ４０２,Ｄ４０３,Ｄ４０４が得られる様子と、具体構成Ｄ４０２～Ｄ４０４と一次構成４０１との更改手順を示す説明図である。なお、図１８に示されているシステムの更改手順は以下の事項（１）～（４）が考慮に加えられている。
【0023】
（１）アプリケーション“a1”のメジャーアップデートに伴い、マシンの設定更新および再起動が必要になっている。この際、アプリケーション“a1”,“a2”および“a3”は正規の終了プロセスによって終了させる必要がある。
【0024】
（２）設計に使われるサーバ同士は互いに同一ネットワーク上に存在する前提が置かれているため、アプリケーション“a1”,“a2”および“a3”間の連携は送信先の設定変更を行うだけで正常に動作する。つまり、アプリケーションのデプロイ先が変化したとしてもネットワークの配線を変更する等の作業は追加発生しない。
【0025】
（３）未使用サーバ“m2”および“m3”は一次構成においては電源がOFFの状態である。
【0026】
（４）アップデート期間中、サービスはメンテナンス状態であり通常のサービス提供が行えなくともよい。
【0027】
さて、一次構成４０１にもっとも類似する具体構成は、設定値を除く構成要素が完全に一致しているＤ４０２であると考えられる。一方で、一次構成に比べて必要なサーバ台数が1つ多いＤ４０３はより類似度の低い構成と捉えることができる。
【0028】
しかし、一次構成４０１からＤ４０２への更改のためにはアプリケーション“a1”の更新に伴いマシン“m1”を再起動させる必要があり、この再起動に伴い“a2”および“a3”の停止・再起動が必要になってしまう。逆にＤ４０３は“a1”のためにサーバを新たに立ち上げているためにそのような追加作業を引き起すことはない。結果として、Ｄ４０２への更改手順は（“m2”の起動コストが“m1”に比べて著しく高いなどの事情がない限り）Ｄ４０３への更改手順に比べて大きくなってしまう。
【0029】
以上が、「一次構成により類似している構成のほうが、より類似していない構成より更改コストが少ない」という主張に対する反例の説明である。
【0030】
続いて、設計プロセスの途中段階で更改コストを見積ることの難しさについて説明する。先に述べた通り、汎用的な要件記述に対応可能な自動設計技術では要件を段階的に具体化していくことになるが、先に述べた反例によれば、更改コストの見積り値（あるいは、より更改コストの低いほうへ向かうための評価付けスコア）を設計途中の抽象構成（以下「中間構成」と呼ぶ。）と一次構成との間の類似性を見ることによって算出することはできない。
【0031】
一方で、抽象的な要素を含む中間構成は一次構成と直接比較することができないため、通常の更改手順を計算するのと同様のやり方で更改手順に相当するデータを計算するのは難しい。
【0032】
したがって中間構成から更改コストの見積値を算出するためには、グラフの類似度とは別の、グラフ構造から導出可能な何らかの特徴を元に、当該中間構成から結果として得られる具体構成に対する更改コストを評価する手段が必要である。
【0033】
以下、前述した「グラフの構造的な特徴を元に更改コストを評価する」ことを「構造フィードバック」と呼び、またグラフ構造を入力として構造フィードバックを行い、評価値を返す関数のことを「構造フィードバック関数」と呼ぶ。ただし、構造フィードバック関数が出力するのは必ずしも更改コストの値そのものである必要はなく、構造フィードバック関数の評価値を比較することにより、更改コストがより小さいと見込まれる中間構成を発見することができればよい。
【先行技術文献】
【特許文献】
【0034】
【特許文献1】特許第６９８９０１４号公報
【非特許文献】
【0035】
【非特許文献1】Takayuki Kuroda, Takuya Kuwahara, Takashi Maruyama, Kozo Satoda, Hideyuki Shimonishi, Takao Osaki and Katsushi Matsuda, “Weaver: A Novel Configuration Designer for IT/NW Services in Heterogeneous Environments”, 2019 IEEE Global Communications Conference (GLOBECOM), 2019, pp. 1-6.
【非特許文献2】T. Kuroda and A. Gokhale, ”Model-based IT Change Management for Large System Definitions with State-related Dependencies,” 2014 IEEE 18th International Enterprise Distributed Object Computing Conference, Ulm, 2014, pages 170-179.
【非特許文献3】M. Nakanoya, T. Kuroda and A. Kitano, ”Automated Change Planning for Differential Update IT Systems with State Constraint,” 2016 IEEE 20th International Enterprise Distributed Object Computing Workshop (EDOCW), Vienna, 2016, pages 1-9.
【発明の概要】
【発明が解決しようとする課題】
【0036】
一次構成に対する更改コストがより小さい新規構成を導出する技術が必要である。
【0037】
そこでこの発明は、上述の課題を解決する冗長構成の設計を可能とするシステム自動設計装置、システム自動設計方法、およびプログラムを提供することを目的としている。
【課題を解決するための手段】
【0038】
本発明の一態様によれば、システム構成導出装置は、抽象構成を、システムを構成する部品に相当するノードおよび前記部品間の関係性を示すエッジで構成されるグラフ構造を用いて、未確定な部分が含まれている前記システムの構成を表現するものとし、具体化を、前記抽象構成の前記未確定な部分を確定させるような前記グラフ構造の変換とし、具体構成を、前記抽象構成に含まれる前記未確定な部分が全て具体化によって確定したものとする場合に、移行前の前記システムである移行前システムおよび移行後の前記システムである移行後システムの候補の各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムの候補への更改コストが少ない前記移行後システムの候補が有する前記グラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力する構造フィードバック算出手段と、前記抽象構成によって表現された前記移行後システムが備えるべき機能要件と、前記移行前システムの構成を表現した前記具体構成である一次構成とを入力とし、前記機能要件に関する前記具体化を繰り返すことによって、前記機能要件が完全に前記具体化された前記具体構成を探索し、前記一次構成と前記探索された前記具体構成とを元に、前記構造フィードバック算出手段が出力した前記構造フィードバック関数を利用して、前記更改コストが最も少ない前記具体構成を導出する構成情報具体化手段と、を備える。
【0039】
本発明の一態様によれば、システム構成導出方法は、抽象構成を、システムを構成する部品に相当するノードおよび前記部品間の関係性を示すエッジで構成されるグラフ構造を用いて、未確定な部分が含まれている前記システムの構成を表現するものとし、具体化を、前記抽象構成の前記未確定な部分を確定させるような前記グラフ構造の変換とし、具体構成を、前記抽象構成に含まれる前記未確定な部分が全て具体化によって確定したものとする場合に、移行前の前記システムである移行前システムおよび移行後の前記システムである移行後システムの候補の各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムの候補への更改コストが少ない前記移行後システムの候補が有する前記グラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力し、前記抽象構成によって表現された前記移行後システムが備えるべき機能要件と、前記移行前システムの構成を表現した前記具体構成である一次構成とを入力とし、前記機能要件に関する前記具体化を繰り返すことによって、前記機能要件が完全に前記具体化された前記具体構成を探索し、前記一次構成と前記探索された前記具体構成とを元に、前記出力された前記構造フィードバック関数を利用して、前記更改コストが最も少ない前記具体構成を導出する。
【0040】
本発明の一態様によれば、プログラムは、抽象構成を、システムを構成する部品に相当するノードおよび前記部品間の関係性を示すエッジで構成されるグラフ構造を用いて、未確定な部分が含まれている前記システムの構成を表現するものとし、具体化を、前記抽象構成の前記未確定な部分を確定させるような前記グラフ構造の変換とし、具体構成を、前記抽象構成に含まれる前記未確定な部分が全て具体化によって確定したものとする場合に、コンピュータに、移行前の前記システムである移行前システムおよび移行後の前記システムである移行後システムの候補の各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムの候補への更改コストが少ない前記移行後システムの候補が有する前記グラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力し、前記抽象構成によって表現された前記移行後システムが備えるべき機能要件と、前記移行前システムの構成を表現した前記具体構成である一次構成とを入力とし、前記機能要件に関する前記具体化を繰り返すことによって、前記機能要件が完全に前記具体化された前記具体構成を探索し、前記一次構成と前記探索された前記具体構成とを元に、前記出力された前記構造フィードバック関数を利用して、前記更改コストが最も少ない前記具体構成を導出する処理を実行させる。
【発明の効果】
【0041】
本発明によれば、一次構成に対する更改コストがより小さい新規構成を導出することができる。
【図面の簡単な説明】
【0042】
【図1】本発明の第１の実施形態によるシステム構成導出装置の構成例を示すブロック図である。
【図2】システム構成導出装置の入力の一つとして与えられる抽象構成の例を示した説明図である。
【図3】具体化の例を示す説明図である。
【図4】更改手順の一例を示す説明図である。
【図5】更改手順を表現するタスクモデルの一例を示す説明図である。
【図6】本発明の第１の実施形態によるシステム構成導出装置の構造フィードバック算出部１０２の動作を説明するフローチャート図である。
【図7】本発明の第１の実施形態における構造フィードバック関数の処理内容を説明するフローチャート図である。
【図8A】本発明の第１の実施形態におけるシステム構成導出装置の構成情報具体化部１０１の動作を説明する第１のフローチャート図である。
【図8B】本発明の第１の実施形態におけるシステム構成導出装置の構成情報具体化部１０１の動作を説明する第２のフローチャート図である。
【図9】本発明の第１の実施形態におけるシステム構成導出装置の構成情報具体化部１０１の動作の一例を示す説明図である。
【図10】本発明の第２の実施形態によるシステム構成導出装置の構成例を示すブロック図である。
【図11】本発明によるシステム構成導出装置の第２の実施形態における、構造フィードバック算出部２０２の動作を説明するフローチャート図である。
【図12】本発明によるシステム構成導出装置の第２の実施形態における、単位構造フィードバック算出部２０４の動作を説明するフローチャート図である。
【図13】本発明の一実施形態におけるシステム更新の例を示す説明図である。
【図18】一次構成と類似した構成が必ずしも更改コストを最小にする構成ではないことを説明する説明図である。
【図19】最小構成を有するシステム構成導出装置の構成を示すブロック図である。
【図20】最小構成を有するシステム構成導出装置の動作を示すフローチャート図である。
【発明を実施するための形態】
【0043】
以下、本発明の各実施形態に係るシステム構成導出装置について図面を参照して説明する。以下の説明に用いる図面において本発明に関係ない部分の構成については、記載を省略し、図示しない場合がある。
【0044】
＜第１の実施形態＞
（構成）
図１は、本発明の第１の実施形態によるシステム構成導出装置の構成例を示すブロック図である。
図１に示すように、システム構成導出装置１００は、入力としてシステム要件を表す抽象構成を受け取り、これを段階的に具体化することで具体構成を導出する構成情報具体化部１０１を備える。
（構成）
図１は、本発明の第１の実施形態によるシステム構成導出装置の構成例を示すブロック図である。
図１に示すように、システム構成導出装置１００は、入力としてシステム要件を表す抽象構成を受け取り、これを段階的に具体化することで具体構成を導出する構成情報具体化部１０１を備える。
【0045】
システム構成導出装置１００は、入力として一次構成を表す具体構成と、構成情報具体化部１０１から出力された具体構成とを受け取り、一次構成からの更改コストの大きさを見積る構造フィードバック関数を出力する、構造フィードバック算出部１０２を備える。
【0046】
システム構成導出装置１００は、入力として２つの具体構成（一次構成、新規構成）を受け取り、一次構成から新規構成へと構成を変更する際の更改コストを算出する、更改コスト算出部１０３を備える。
【0047】
以下、本実施形態における抽象構成と、そのデータ構造について説明する。上記の通り、抽象構成とは、構成や設定に関し未確定な部分を含む抽象的なシステム構成を指す。抽象構成は、ICTシステムを所望する主体によって、確定している情報すなわち「システムがどのような要件を満たし、どのような機能を持つべきか」を表す情報のみを書き下すことで、システムの詳細に具体的に言及することなく所望のシステムを規定する役割を担う。
【0048】
抽象構成は、システムの機能や論理的・物理的な構成部品に相当する「ノード」と、２つのノード間に張ることでそれら２つのノード間の関係性を表現する「エッジ」からなるグラフを基本構成とする。前記のエッジは向きを持ち、ノードＡからノードＢに向かうエッジに対し、ノードＡを「接続元」ノードＢを「接続先」と呼ぶ。また、以下ではノード及びエッジに区別なく言及する場合、これらをまとめて「エンティティ（ｅｎｔｉｔｙ）」と呼ぶ。
【0049】
エンティティは、システム全体で一意に当該エンティティを識別するための「識別子」と、当該エンティティに関する各付属情報を表す「設定値」と、当該エンティティがどのような概念に相当するかを表現する「型情報」を持つ。2つの異なる抽象構成におけるエンティティの同一性は識別子によって判別する。つまり型情報が異なっていたとしても、識別子が同じなら「同じエンティティ」として扱う。
【0050】
以下に、エンティティに付随する「型情報」についてより詳しく説明する。
型情報とは、それが付随するエンティティがどのような種類のものであるかを示す役割をもつ。型には「抽象型」と「具体型」の２種類が存在し、抽象型は「Machine」や「HTTP接続可能」など、直感的には現実に存在する具体的な部品や接続関係と対応せず、更なる具体化が求められるような種類のエンティティを示す。一方具体型は「(具体的なマシンの型番)」や「有線LAN接続」など、現実に存在する具体的な部品や接続関係と対応するエンティティを示す。
型情報とは、それが付随するエンティティがどのような種類のものであるかを示す役割をもつ。型には「抽象型」と「具体型」の２種類が存在し、抽象型は「Machine」や「HTTP接続可能」など、直感的には現実に存在する具体的な部品や接続関係と対応せず、更なる具体化が求められるような種類のエンティティを示す。一方具体型は「(具体的なマシンの型番)」や「有線LAN接続」など、現実に存在する具体的な部品や接続関係と対応するエンティティを示す。
【0051】
また、ノード型は「要請部品」を示す情報を持つ。これは複数存在することもあるし、全くないこともある。
【0052】
さらに、エンティティの「設定値」は、当該エンティティの型情報に定義されたプロパティに対する設定値として定義することができる。つまり型情報はプロパティ定義として設定値のキーの一覧情報「p[1], p[2],..., p[n]」を持ち、エンティティの「設定値」は、これらキーの一部あるいは全てに対して値を対応づけた「p[i1]:n1, p[i2]:n2, ...」という関係データとして規定される。
【0053】
以上が、エンティティに付随する「型情報」についての説明である。以下に、ノード型に付随する「要請部品」についてより詳しく説明する。
ノード型に付随する要請部品とは、直感的にはノード型を持つノードに相当する部品の正常な動作のために必要な依存部品を示している。たとえば、アプリケーションを示す「App」型は要請部品として「Machine」を持ち、これはアプリケーションの動作のためにはそれをホストするマシンが必要であることを指す。
ノード型に付随する要請部品とは、直感的にはノード型を持つノードに相当する部品の正常な動作のために必要な依存部品を示している。たとえば、アプリケーションを示す「App」型は要請部品として「Machine」を持ち、これはアプリケーションの動作のためにはそれをホストするマシンが必要であることを指す。
【0054】
要請部品が付随するノード型を持つノードは、単にそのノード自体が要請部品を持つという表現をする。ノードN1が持つ要請部品reqに対し、「WIRE:req」(“req”の部分は要請部品によって変化する)という特別な具体エッジ型を持つエッジをノードN1から別のノードN2に向けて張ることで、要請されている部品を接続することができる。これはN1が要請する部品reqとしてN2を選択したことに相当する。ノードが持つ要請部品は、適切な部品を接続することで要請を満たすことができる。
【0055】
たとえば、先のApp型の例を取れば、App型のノードMyAppから「WIRE:Machine」型のエッジをMachine型のノードMachine1に接続することで、MyAppのホスト先をMachine1に指定することができる。
【0056】
ノードの持つ要請部品には、高々１つのノードしか接続できない。たとえば先の例でMachine1に接続したあとのMyAppに、さらに加えて「WIRE:Machine」型のエッジによって別のMachine 型のエッジMachine2 に接続することはできない。
以上が、ノード型に付随する「要請部品」についての説明である。
以上が、ノード型に付随する「要請部品」についての説明である。
【0057】
図２に抽象構成の例を示す。Node３００、Node３０１、Node３０２に示されるような、ラベルが付されたアイコンはノードを示す。Edge３０３、Edge３０４に示されるような、ラベルが付された矢印はエッジを示している。ノードのラベルは「(識別子):(型の名前)」の形式を取っており、エッジのラベルは型の名前のみである。また、Node３００、Node３０１には要請部品を示す吹き出しが付してある。図面の単純化のため、要請やラベルの情報は適宜省略される。
【0058】
Node３００、Node３０１は共にアプリケーションを表しており、ここでは両方とも未確定な部分を含まない具体的なシステム構成部品に相当するものとする。これらのノードは共に「Machine」要請部品を持っており、Node３００の要請はMachine1が接続されることによって満たされている一方、Node３０１の要請は満たされていない。
【0059】
Node３０２は「何らかのマシン」を示すノードである。すなわちアプリケーションを動作させることができるマシンであることは確定しているが、具体的にどのような製品をここで用いるかまでは確定していない。
【0060】
Edge３０３は、接続元のノードNode３００が接続先のノードNode３０２上にホストされることを示す、具体的な関係性を示すエッジである。このエッジによってNode３０２がNode３００に接続されることにより、Node３００の「Machine」要請は満たされている。
【0061】
Edge３０４は、接続元のノードNode３００が接続先のノードNode３０１に対し何らかの方法でHTTPリクエストを送信できることが保証されていることを示す、(具体的な通信経路が不定という意味で)抽象的な関係性を示すエッジである。
以上が抽象構成の具体的な例の説明である。
以上が抽象構成の具体的な例の説明である。
【0062】
【0063】
適用例７００はノードApp2の「Machine」要請に対し、新しいMachine型ノードMachine2を生成し接続したケースである。
【0064】
適用例７０１はノードApp2の「Machine」要請に対し、既に図２に含まれているMachine 型ノードMachine1を接続したケースである。
【0065】
【0066】
さらに、前記の2つのケースは全く同じ抽象的要素（すなわちノードApp2の「Machine」要請）を解決するものであるが、解決の方法の違いによって結果生じる構成に差分が生じることは注目に値する。すなわち変換元の抽象構成が全く同じであっても、変換方法の違いによって様々な構成へと変換が進み、結果的に様々な具体構成が生じることになる。
以上が、具体化による抽象構成の書換えの説明である。
以上が、具体化による抽象構成の書換えの説明である。
【0067】
次に、本実施形態によって導出される具体構成の正確な定義について説明する。本実施形態における具体構成とは、完全に具体化された抽象構成のことを指す。ここで、抽象構成が「完全に具体化されている」とは、以下の３種類の具体化済条件（具体化済条件１）（具体化済条件２）および（具体化済条件３）を全て満たすことを指す。
【0068】
（具体化済条件１）抽象構成は、抽象型を持つノードを一つも含まない。
【0069】
（具体化済条件２）抽象構成は、抽象型を持つエッジを一つも含まない。
【0070】
（具体化済条件３）抽象構成は、満足されていない要請を一つも含まない。
【0071】
具体化済条件の定義より、単位要件を含まない抽象構成はICTシステムとして曖昧な部分が一切なく、かつ動作に必要な部品（＝各ノードに対する諸要請）が全て揃っている状態を示していると言えるため、具体構成は機能的に完全に動作するシステムに相当することになる。
【0072】
（動作）
システム構成導出装置１００は、要件を表す抽象構成を入力として受け取り、要件を満たす具体構成を出力する。さらに本実施形態のシステム構成導出装置１００は、設計対象のシステムの前段の構成にあたる一次構成を入力として受け取る。
システム構成導出装置１００は、要件を表す抽象構成を入力として受け取り、要件を満たす具体構成を出力する。さらに本実施形態のシステム構成導出装置１００は、設計対象のシステムの前段の構成にあたる一次構成を入力として受け取る。
【0073】
ここで、一次構成は、同時に入力される要件を具体化して生成される具体構成によって置き換えられることを意図するものである。したがって多くの場合で一次構成はその大本となる要件において要件と類似するものが入力されることを想定している。しかしながら、本実施形態を適用するにあたっては前記要件と前記一次構成との間に相関関係が認められなくともよい。
【0074】
以下に、システム構成導出装置１００の各部の処理についての詳細を説明する。
まず、本実施形態の更改コスト算出部１０３の動作について説明する。
更改コスト算出部１０３は、２つの具体構成「一次構成」および「新規構成」を受け取り、一次構成から新規構成に構成を変更するのに必要な更改コストの値を算出する。
まず、本実施形態の更改コスト算出部１０３の動作について説明する。
更改コスト算出部１０３は、２つの具体構成「一次構成」および「新規構成」を受け取り、一次構成から新規構成に構成を変更するのに必要な更改コストの値を算出する。
【0075】
本実施形態においては、更改コスト算出部１０３が更改コストを算出する方法に関して特定の方法に制限しないが、具体的な手法の例をいくつか、以下で説明する。
【0076】
更改コスト算出部１０３が更改コストを算出する具体的な方法の一例として、非特許文献２および非特許文献３に記載のシステム構成自動変更技術を応用する方法が挙げられる。非特許文献２および非特許文献３には、本実施形態におけるグラフ様表現で表されたシステム構成に対して部品間の依存情報等を元に必要な更改タスク（＝最小粒度の更改手順）の一覧（以下「更改手順」と呼ぶ。）を算出する自動更改手順算出手法が掲載されている。たとえば当該自動更改手順算出手法によって算出した更改手順に含まれる更改タスクの数を更改コストと定めることができる。
【0077】
図４は、10個のタスクA, B, ... , Jからなる更改手順である。この場合、上述の算出法による更改コストは10となる。
【0078】
また別の一例は次のような算出法である。事前に定義された各部品のモデルから各々の更改タスクに対する個別の更改コスト（以下これを「単位的更改コスト」と呼ぶ）が分かるならば、前記自動更改手順算出手法によって算出した更改手順に含まれる更改タスクそれぞれの単位的更改コストの和を更改コストと定めることもできる。
【0079】
図４に示した10個のタスクA, B, ... , Jにはそれぞれ単位的更改コストとして整数値 1, 3, 2, 2, 2, 5, 6, 1, 4, 1が定められている。この場合、上述の算出法による更改コストはこれらの和 1 + 3 + 2 + 2 + 2 + 5 + 6 + 1 + 4 +1 = 27となる。
【0080】
さらに別の一例は次のような算出法である。非特許文献２には更改タスクの一覧を、前述した（有効な）実行順に並べた一列の手順としてではなく、各更改タスク間の依存関係によって結んだ有向非循環グラフ（以下これを「タスクモデル」と呼ぶ）として求める手法も掲載されている。互いに依存しない２つのタスク同士は並列に実行することができるので、タスクモデルを最大限並列的に実行した場合にかかる時間は、タスクモデルに含まれる中で最も時間がかかる一連のタスク列（以下「ボトルネック手順」と呼ぶ）の実行時間と同じと考えることができる。そこで、前述した「単位的更改スコアの和」によって求める手法において、和を取る対象を更改手順全体でなくボトルネック手順に限定したものを更改コストと定めることができる。
【0081】
図５は、図４に示した10個のタスクA, B, ... , Jからなるタスクモデルである。ここで、矢印は依存性を表しており、依存先のタスクを完了しなければ依存元のタスクを開始できないことを表している。また、点線で囲まれたタスク列 A, B, C, E, F, G は図５に記載のタスクモデルにおけるボトルネック手順を表している。この場合、上述の算出法による更改コストは前記ボトルネック手順に含まれるタスクの単位的更改スコアの和 1 + 3 + 2 + 2 + 5+ 6 = 19 となる。
【0082】
以上が、本実施形態における更改コスト算出部１０３の動作の具体的な実現方法の一例である。ただし、前述のように本実施形態における更改コスト算出部１０３の動作の具体的な実現方法は上述した3つの例に限定されない。また、非特許文献２および非特許文献３に記載の手法に基づくものである必要もない。
【0083】
次に、本実施形態の構造フィードバック算出部１０２の動作について説明する。
図６は、第１の実施形態の構造フィードバック算出部１０２の動作の全体を示すフローチャート図である。
構造フィードバック算出部１０２は、入力として一次構成D0および新規構成D1を受け取る（ステップＳ８００）。
図６は、第１の実施形態の構造フィードバック算出部１０２の動作の全体を示すフローチャート図である。
構造フィードバック算出部１０２は、入力として一次構成D0および新規構成D1を受け取る（ステップＳ８００）。
【0084】
構造フィードバック算出部１０２は、更新対象ノード（の識別子）の一覧Vuを算出する。ここで(D0からD1への更改に対する)更新対象ノードとは、D1に含まれるノードのうち、D0とD1で状態が異なっており、システムの更改に際して必ずそのノードに関する更改タスクを実行しなくてはならないノードを指す。ここで「ノードの状態が異なる」状況とは、ノードに設定された設定値が異なる、ノードの要請に対し異なるノードが接続されている、ノードそのものが(D0に)存在しないなどの状況を含む（ステップＳ８０１）。
【0085】
ここで、D0からD1への更改手順には、必ずしも「更改対象ノードを更新するタスク」のみが含まれる訳ではないことに注意する。たとえば、D0とD1で設定上の差分は存在せず更新の必要はないノードであっても、関連するシステム部品の変更のために再起動等のタスクが生じるようなものも存在する。この場合当該ノードは更新対象ノードには含まれない。
【0086】
構造フィードバック算出部１０２は、更改コスト算出部１０３にD0とD1を入力してその出力を得ることで、D0からD1への更改コストc[total]を求める（ステップＳ８０２）。
【0087】
構造フィードバック算出部１０２は、全ての更新対象ノードv∈Vuに対し、ステップＳ８０４およびステップＳ８０５を実行する（ステップＳ８０３）。
【0088】
構造フィードバック算出部１０２は、D1におけるノードvの状態をD0における状態に復元した構成を生成し、これをD1[v]とする（ステップＳ８０４）。
【0089】
ここで「ノードvの状態をD0における状態に復元」するとは次のような操作を指す。更新対象ノードvはD0とD1で状態が異なっているが故に更新対象となっている。そこで、vの状態をD0時点のものに合わせることを復元と呼ぶ。すなわち設定値が異なるならばD0時点の設定値に合わせる、要請に対応する部品が異なるならばD0における要請部品に接続しなおす、元々存在しない部品であるならばノード自体を取り除く、等の操作を行うことで、D1のノードvの状態をD0に合わせ、vに関連する更新タスクを行う必要がないよう「（D0の状態に）復元」する。
【0090】
構造フィードバック算出部１０２は、更改コスト算出部１０３にD0とD1[v]を入力してその出力を得ることで、D0からD1[v]への更改コストc[v]を求める（ステップＳ８０５）。
【0091】
構造フィードバック算出部１０２は、全ての更新対象ノードv∈Vuに対するステップＳ８０４およびステップＳ８０５の実行が完了した時点でステップＳ８０７に進む（ステップＳ８０６）。
【0092】
構造フィードバック算出部１０２は、入力である抽象構成D0, D1に加え、前ステップまでで求めた c[total], Vu, c[v]をもとに、構造フィードバック関数Fを構築する（ステップＳ８０７）。構築される構造フィードバック関数の詳細の説明は後述する（図７）。
【0093】
構造フィードバック算出部１０２は、前ステップで求めた構造フィードバック関数Fを出力する（ステップＳ８０８）。
【0094】
【0095】
図７は、ステップＳ８０７で構築される構造フィードバック関数Fが、入力された抽象構成Tを評価して評価値SCOREを出力するまでに実行される、具体的な処理内容を示すフローチャート図である。
【0096】
図７の各ステップの説明においては、入力される抽象構成の他に、上述の図６におけるステップＳ８０７で説明した通り、データとしてD0,D1,c[total],Vu, c[v]を用いることができるという前提を置いている。
【0097】
構造フィードバック関数Fは、入力として抽象構成Dを受け取る（ステップＳ９００）。
【0098】
構造フィードバック関数Fは、評価値SCOREの初期値をc[total]と定める（ステップＳ９０１）。
【0099】
構造フィードバック関数Fは、更新対象ノードVuに含まれる全てのノード(の識別子)vについて、ステップＳ９０３およびステップＳ９０４を実行する（ステップＳ９０２）。
【0100】
構造フィードバック関数Fは、入力された抽象構成Dにおけるノードvが一次構成D0におけるノードvと整合するかどうかを検証し、整合する場合はステップＳ９０４に、整合しない場合はステップＳ９０２に進む（ステップＳ９０３）。
【0101】
ここで「(DにおけるノードvがD0におけるノードvと)整合する」とは、抽象構成Dの具体化を進めることでD0と同じ状態のノードvが含まれる抽象構成に変換することができることを指す。以下に３つの具体例を挙げる。
【0102】
（例１）たとえば、Dにノードvが含まれず、その後の具体化によってDにvが追加されうるならば、整合する。
【0103】
（例２）たとえば、Dにノードvが含まれ、かつあるパラメータにおいてD0における値と異なる値が設定されていたならば、整合しない。これは、具体化によってパラメータに既に設定された設定値を変更することができないためである。
【0104】
（例３）たとえば、Dにノードv が含まれ、かつ全てのパラメータにおいて「(1)D0における値と同じ値が設定されている、または(2)値が設定されていない」が成り立つならば、整合する。このケースでは、Dにおけるvに未設定のパラメータにD0におけるvと同じ設定値を設定するように具体化することで、D0におけるvと全く同じノードに具体化することができるためである。
【0105】
構造フィードバック関数Fは、評価値SCOREからc[total]－c[v]を減算（正のフィードバック）する（ステップＳ９０４）。ステップＳ９０３で整合しない場合は、減算しない為、負のフィードバックとなる。ここで、評価値SCOREは「更改コストの大きさ」を表しているので、低いほうがより良い構成であることを示し、減算が正のフィードバックを意味する。
【0106】
構造フィードバック関数Fは、更新対象ノードVuに含まれる全てのノード(の識別子)vについて、ステップＳ９０３およびステップＳ９０４の実行が完了した時点でステップＳ９０６に進む（ステップＳ９０５）。
【0107】
構造フィードバック関数Fは、抽象構成Dに含まれる全てのノード(の識別子)vについて、ステップＳ９０７およびステップＳ９０８を実行する（ステップＳ９０６）。
【0108】
構造フィードバック関数Fは、ノードvがD0またはD1のどちらかに含まれるかどうかを検証し、どちらかに含まれていればステップＳ９０６に、どちらにも含まれていなければステップＳ９０８に進む。（ステップＳ９０７）
【0109】
構造フィードバック関数Fは、SCOREに「ノードvの追加コスト」を加算する。ここで「ノードvの追加コスト」とは、ノードvに相当する部品をシステム構成に追加するときに発生する更改コストを指す（ステップＳ９０８）。
【0110】
ここで、構造フィードバックが用いる「ノードvの追加コスト」として用いるべき値は、更改コスト算出部１０３で更改コストをどのように算出しているかに依存して決まると考えることができる。たとえば単に更改手順に含まれるタスクの個数として算出している場合、ノードvの追加コストは1とすることが考えられる。一方更改手順に含まれるタスクの単位的更改コストの和として算出している場合、ノードvの追加コストは「“ノードvの追加”を意味する更改タスクの単位的更改コスト」とすることが考えられる。
【0111】
ただし、構造フィードバックが用いる「ノードvの追加コスト」については、本実施形態では、上述したような特定の定義に限定しない。たとえば、追加コストを0として無視してしまうような構成であってもよい。
【0112】
構造フィードバック関数Fは、抽象構成Dに含まれる全てのノード(の識別子)vについて、ステップＳ９０７およびステップＳ９０８の実行が完了した時点でステップＳ９１０に進む（ステップＳ９０９）。
【0113】
構造フィードバック関数Fは、評価値SCOREを出力する（ステップＳ９１０）。
【0114】
以上が、図６におけるステップＳ８０７で構築される構造フィードバック関数Fの具体的な処理内容についての説明である。図６におけるステップＳ８０７では、上述した処理を行う関数を構築し、値として構造フィードバック算出部１０２より出力する。
【0115】
以下では、上述した構造フィードバックFの評価値算出手続きについて、当該手続きによって算出される値が抽象構成に対する「一次構成からの更改コストの見積り」となっていることを説明する。
【0116】
図６におけるステップＳ８０５で算出される「D0からD1[v]への更改コストc[v]」は、直感的には「D0からD1への更改手順に含まれる更改タスクのうち、vの更新に由来するものを除くことができた場合の更改コスト」の値に相当する。
【0117】
すなわち、抽象構成Dが「vの更新を必要としない構成」に具体化できたとしたら、更改コストはc[total]から「c[total]－c[v]」だけ改善されることが期待できる。そこで以下では「c[total]－ c[v]」を「vに関する見込み改善スコア」と呼ぶ。
【0118】
以上の考え方をもとに、次のような見積りが可能である。
（１）まず、SCOREをc[total]の値とする。
（１）まず、SCOREをc[total]の値とする。
【0119】
（２）その後、評価対象の抽象構成に対し、更新対象ノードを更新しないことが可能であるか（つまり、当該更新対象ノードに関してD0と整合するかどうか）をチェックし、可能であるならばそのノードに関しては見込み改善スコアの分だけ更改スコアの改善が見込めるため、SCOREから当該ノードに関する見込み改善スコアの値を減ずる。
【0120】
（３）上述の手続きによって算出されたSCOREは、更新対象ノードによって最終的にもたらされる更改スコアに関する下限の値の見積りとなっている。
【0121】
以上の（１）～（３）を手続きとして表現したものが、図７におけるステップＳ９０５までの処理である。
【0122】
加えて、抽象構成にはD0にもD1にも含まれないノードが存在することがあり、これらは当然更新対象ノードでないため上述の見積りでは考慮されない。また、これら新規に追加されたノードと既存のノードとが（更改手順において）どのように影響し合うかを考慮するのは難しい。
【0123】
したがって構造フィードバック関数Fは、新規ノードについては単にこれらを独立して導入する場合に見込まれる更改コスト（＝追加コスト）を SCOREにそれぞれ加算する。
【0124】
この手続きは図７におけるステップＳ９０６からの処理として表現されている。
【0125】
以上が、構造フィードバックの評価値算出手続きが抽象構成に対する「一次構成からの更改コストの見積り」となっていることに対する説明である。
【0126】
次に、本実施形態の構成情報具体化部１０１が ICTシステムを設計する動作を、図８Ａ～図８Ｂを参照して説明する。図８Ａ、図８Ｂはそれぞれ、本実施形態の構成情報具体化部１０１がシステムの具体構成を導出する手続きを表わす第１、第２のフローチャート図である。
【0127】
構成情報具体化部１０１は、入出力装置から抽象構成の形式で表現された構成要件Dinit および一次構成D0を入力として受け付ける（ステップＳ１０００）。
【0128】
構成情報具体化部１０１は、評価関数ｆを初期化する。ここで評価関数とは、抽象構成を入力として評価値を出力する関数のことを指す（ステップＳ１００１）。
【0129】
本実施形態においては、ステップＳ１００１において評価関数ｆをいかなる関数によって初期化するかについて特定の方法に限定しない。初期化の具体的な方法としては、「定数関数（何を入力されても0などの定数値を返す」、「含まれるエンティティの総数を返す」、「含まれる要請の総数を返す」、「一次構成とのグラフ構造的な類似度（＝値が低いほど類似していることを表す）を返す」などを意味する関数を入力することができる。
【0130】
構成情報具体化部１０１は、探索候補リストTを空のリストで初期化する（ステップＳ１００２）。
【0131】
探索候補リストに加えられるのは、第一要素が抽象構成、第二要素がその評価値であるような２つの要素をもつ組である。
【0132】
構成情報具体化部１０１は、組(Dinit, 0)を探索候補リストTに追加する（ステップＳ１００３）。
【0133】
構成情報具体化部１０１は、後述する探索終了条件を満たさず、探索対象が探索候補リストTに残っており、かつ探索候補リストTに具体構成が含まれていないならばステップＳ１００５に進み、そうでなければ図８ＢのステップＳ１００８に進む（ステップＳ１００４）。
【0134】
構成情報具体化部１０１は探索候補リストTに含まれる組(D,S)のうち、次の３つの条件（１）（２）（３）を全て満たすものを一つ選択する（ステップＳ１００５）。
【0135】
（１）抽象構成Dは完全には具体化されていない。
【0136】
（２）抽象構成Dと同じ第一要素を持つ組が本ステップで以前に選ばれたことがない。
【0137】
（３）評価値Sは探索候補リストTに含まれる組の評価値の中で最も低い。
【0138】
構成情報具体化部１０１は、ステップＳ１００５で選んだ抽象構成Dを具体化してできる抽象構成 D1, D2, ..., DN を生成する（ステップＳ１００６）。
【0139】
ここで、本実施形態の構成情報具体化部１０１が抽象構成を具体化する具体的な方法としては、たとえば非特許文献１に記載の具体化規則による方法を用いることができる。しかし、本実施形態では具体化の具体的な方法について特定の手法に限定はしない。
【0140】
ただし、本実施形態の具体化は以下の3つの性質（１）、（２）、（３）を満たすものとする。（たとえば非特許文献１に記載の手法はこれらを満たす。）（１）一度生成されたノードは具体化によって削除されない。（２）一度生成された具体的なエッジは具体化によって削除されない。（３）一度設定されたエンティティの設定値は変更されず、削除もされない。
【0141】
構成情報具体化部１０１は、前ステップで生成した抽象構成 D1, D2, ..., DNに対し評価関数ｆを適用し、組(D1, ｆ(D1)), (D2, ｆ(D2)), ..., (DN, F(DN))をそれぞれ全て探索候補リストTに加える。その後、ステップＳ１００４に戻る（ステップＳ１００７）。
【0142】
構成情報具体化部１０１は、探索候補リストTに具体構成を含む組が含まれていない場合はステップＳ１０１２に、具体構成を含む組(Dc, Sc)が含まれている場合はステップＳ１００９に進む。（ステップＳ１００８）
【0143】
構成情報具体化部１０１は、Soutが未定義の場合、あるいはSoutとScとを比較して Sout ＞ Scの場合、Dout := Dc, Sout := Sc とそれぞれ更新する（ステップＳ１００９）。
【0144】
構成情報具体化部１０１は、一次構成D0と具体構成Dcとを構造フィードバック算出部１０２に入力(Dcは「新規構成」として入力)し、出力される構造フィードバック関数 F´を取得する（ステップＳ１０１０）。
【0145】
構成情報具体化部１０１は、評価関数ｆを前ステップで得られた構造フィードバック関数F´に置き換え、ステップＳ１００２に戻る（ステップＳ１０１１）。
【0146】
構成情報具体化部１０１は、具体構成Doutを入出力装置にシステム構成導出装置１００の結果として出力する（ステップＳ１０１２）。
以上が構成情報具体化部１０１の動作の説明である。
以上が構成情報具体化部１０１の動作の説明である。
【0147】
ここで、ステップＳ１００４の条件分岐に使われる探索終了条件について説明する。
図８Ａ、図８Ｂは、具体化によって得られた具体構成を元に具体化方法を改善する、フィードバックループの手続きである。したがって、フィードバックループ全体を停止する仕組みを入れない限り基本的には停止しないプロセスとなってしまう。
図８Ａ、図８Ｂは、具体化によって得られた具体構成を元に具体化方法を改善する、フィードバックループの手続きである。したがって、フィードバックループ全体を停止する仕組みを入れない限り基本的には停止しないプロセスとなってしまう。
【0148】
フィードバックループ全体を停止させる役割を担うものが探索終了条件であり、これは例えば「全体で～回以上の具体化が行われた」「処理開始から～時間が経過した」「～回以上のフィードバックが行われた」「最初に得られた構成から～以上のコスト改善が見られた」などの条件式によって定義される。本実施形態では、探索終了条件として上に挙げたものを含めどのような基準を設定することも可とし、その方法については限定しない。
【0149】
次に、本実施形態の構成情報具体化部１０１の実際の動作の全体像を、例を用いて概観する。図９は本実施形態の構成情報具体化部１０１の動作途中の様子の一例を示した説明図である。
【0150】
図９に図示されている、数値が記載されている一重線または二重線の枠を持つ四角形は、探索候補リストTに追加された抽象構成と類似度スコアの組を指している。ここでは抽象構成は省略し、中の数値によって類似度スコアのみが分かるようにしている。本説明において、この組を便宜上「探索状態」と呼ぶことにする。
【0151】
一重線の枠を持つ四角形は、ステップＳ１００５によって選ばれなかった探索状態、二重線の枠を持つ四角形は、ステップＳ１００５によって選ばれた探索状態を表している。また、二重線の枠を持つ四角形の右上にはカッコ“[]”で囲んだ数字が記載されており、これはその状態がステップＳ１００５で何回目に選択された探索状態であるかを示している。
【0152】
最も上段にある探索状態Ｄ１１００は、入力として与えられた構成要件に相当する探索状態であり、ステップＳ１００３において探索候補リストTに加えられたものである。
【0153】
図９に図示されている、四角形から四角形に伸びる矢印は、当該矢印の始点に対応する探索状態がステップＳ１００４にて選ばれたときに、その後のステップＳ１００６にて当該矢印の終点に対応する探索状態が生成されたことを示す。すなわち、各矢印の終点に対応する探索状態は、当該矢印の始点に対応する探索状態の抽象構成を具体化することで得られる。本説明において、この矢印を便宜上「遷移」と呼ぶことにする。
【0154】
図９に示される通り、ステップＳ１００５では実行される段階で存在する探索状態のうち最も評価値の低い探索状態が選ばれている。たとえば、探索状態2が選ばれた直後において、探索候補リストTに加えられている探索状態の評価値は、評価値23を持つ探索状態Ｄ１１０１、評価値25を持つ探索状態Ｄ１１０２、および評価値20を持つ探索状態Ｄ１１０３であるが、状態3として次に選択されたのは最も評価値が低い探索状態Ｄ１１０３である。
【0155】
以上が、本実施形態の構成情報具体化部１０１の挙動に対する例に関する説明である。
【0156】
（効果）
本実施形態のシステム構成導出装置１００の構成情報具体化部１０１は、構成要件と一次構成とを受け取り、構成要件を繰り返し具体化することで、抽象構成を節点とする木（ツリー）上の木探索を行い、最終的に完全に具体化されたICTシステムの構成情報を出力する。
本実施形態のシステム構成導出装置１００の構成情報具体化部１０１は、構成要件と一次構成とを受け取り、構成要件を繰り返し具体化することで、抽象構成を節点とする木（ツリー）上の木探索を行い、最終的に完全に具体化されたICTシステムの構成情報を出力する。
【0157】
また、本実施形態の構成情報具体化部１０１は、具体構成を求めるごとに構造フィードバック算出部１０２に問合せることで構造フィードバック関数を生成し、これを木探索における優先指標として再度具体化を行うことを繰り返す。
【0158】
また本実施形態の構造フィードバック算出部１０２は、一次構成から新規に得られた構成への実際の更改手順を元に、更改コストがより少なくなるようなグラフ構造上の性質を抽出し、抽出した性質を持つ抽象構成により良い評価を与えるような構造フィードバック関数を生成し、出力する。
【0159】
よって、本実施形態のシステム構成導出装置１００は、得られた具体構成を元により更改コストの少ない構成を得るための指標を得て再度具体化を行う、更改コストに関するフィードバックループを繰り返すことで、構成要件を満たす構成であってより一次構成からの更改コストが少ない具体構成を出力することができる。
【0160】
【0161】
図示するように、システム構成導出装置２００は、システム構成導出装置１００の構成情報具体化部１０１の代わりに構成情報具体化部２０１を備える。
【0162】
システム構成導出装置２００は、システム構成導出装置１００の構造フィードバック算出部１０２の代わりに構造フィードバック算出部２０２を備える。
【0163】
システム構成導出装置２００は、入力として２つの具体構成（一次構成、新規構成）を受け取り、一次構成から新規構成へと構成を変更する更改手順を算出する、更改手順生成部２０３を備える。
【0164】
システム構成導出装置２００は、更新手順と更新対象ノードとを入力として、前記更新手順を実行するにあたり、前記ノードに関する更新が不要となったと仮定した場合の更改コストを算出する、単位構造フィードバック算出部２０４を備える。
【0165】
（動作）
本実施形態の構成情報具体化部２０１の動作は、図８Ｂに示した第１の実施形態の構成情報具体化部１０１の動作中のステップＳ１０１０において、構造フィードバック算出部１０２の代わりに構造フィードバック算出部２０２を用いることで構造フィードバックを得るという点以外に差分はない。
本実施形態の構成情報具体化部２０１の動作は、図８Ｂに示した第１の実施形態の構成情報具体化部１０１の動作中のステップＳ１０１０において、構造フィードバック算出部１０２の代わりに構造フィードバック算出部２０２を用いることで構造フィードバックを得るという点以外に差分はない。
【0166】
次に、本実施形態の更改手順生成部２０３の動作について説明する。
更改手順生成部２０３は、２つの具体構成「一次構成」および「新規構成」を受け取り、一次構成から新規構成に構成を変更する更改手順を求める。
更改手順生成部２０３は、２つの具体構成「一次構成」および「新規構成」を受け取り、一次構成から新規構成に構成を変更する更改手順を求める。
【0167】
出力される更改手順は、「一次構成」から「新規構成」へのシステム移行に必要な全ての更改タスク（＝最小粒度の更改手順）を、タスク間の依存関係によって結んだ有向非循環グラフ（以下これを「タスクモデル」と呼ぶ）として表現されているものとする。
【0168】
本実施形態の更改手順生成部２０３が更改手順を算出する具体的な方法について本実施形態では特定の方法に限定しないが、たとえば非特許文献２および非特許文献３に記載の方法を用いることにより、更改手順をタスクモデルの形式で求めることが可能である。
【0169】
本実施形態における各更改タスクには、「どのシステム部品（＝ノード）に対する更新操作であるか」に相当する情報が紐付けられているとする。
【0170】
タスクモデルにはその属性としてその更改コストの情報が含まれるとする。この更改コストとしてどのような値を採用するかについて本発明では特に限定しないが、実施形態１の更改コスト算出部１０３と同様、「更改タスクの数」「各更改タスクの単位的更改コストの総和」などとして定義できるものとする。
【0171】
以上が、本実施形態の更改手順生成部２０３の動作に関する説明である。
【0172】
次に、本実施形態の構造フィードバック算出部２０２の動作について説明する。図１１は、本実施形態の構造フィードバック算出部２０２の動作の全体を示すフローチャート図である。
【0173】
図１１に示す通り、構造フィードバック算出部２０２の動作は、図７に示す構造フィードバック算出部１０２の動作と比較すると、ステップＳ８０４がないことと、２つのステップが変更されている（Ｓ８０２およびＳ８０５が、それぞれＳ１２００およびＳ１２０１に変更）を除いて全く同じである。したがって、ここでは当該２つのステップについてのみ説明を追加する。
【0174】
構造フィードバック算出部２０２は、移行元構成としてD0、移行後構成としてD1を更改手順生成部２０３に入力し、D0からD1への更改手順を表すタスクモデルMを得る。さらに、c[total]をタスクモデルMの更改コストとする（ステップＳ１２００）。
【0175】
構造フィードバック算出部２０２は、タスクモデルMとノードvを単位構造フィードバック算出部２０４に入力し、出力された更改コストをc[v]とする（ステップＳ１２０１）。
【0176】
以上が、本実施形態における構造フィードバック算出部２０２の動作のうち構造フィードバック算出部１０２と異なる２つのステップに関する説明である。
【0177】
次に、本実施形態における単位構造フィードバック算出部２０４の動作について説明する。
【0178】
図１２は、本実施形態における単位構造フィードバック算出部２０４の動作の全体を示すフローチャート図である。
【0179】
単位構造フィードバック算出部２０４は、タスクモデルMとノードvとを入力として受け取る（ステップＳ１３００）。
【0180】
単位構造フィードバック算出部２０４は、タスクモデルMに含まれるvに関連する更改タスクを、他タスクに影響を及ぼさない方法（後述）で削除する（ステップＳ１３０１）。
【0181】
タスクモデルMに含まれるvに関連する更改タスクを、他タスクに影響を及ぼさずに削除する方法について述べる。タスクモデルMに含まれる、v上の更新作業に相当するタスクをt1, t2, ..., tNとする。これらのタスクに対し別のタスクからの依存がなかった場合は、タスクモデル上から単に削除することができる。
【0182】
一方、t1, t2, ..., tNに含まれるタスクtiが別のタスクから依存されている、つまりタスクtiを実行した後でなければ実行できないタスクが存在する場合、「D0におけるノードvの状態から、タスクtiを実行したのち元の状態に戻ってくるようなタスク列」を求め、t1, t2, ..., tNをこれで置き換える。タスクtiに相当するタスクが複数あった場合も同様である。
【0183】
単位構造フィードバック算出部２０４は、タスクモデルM中にあるノードviに関する省略可能タスク列t1, t2, ..., tNが含まれるならば、それを取り除く操作を繰り返す。ここで、ノードviに関する省略可能タスク列t1, t2, ...,tNとは、（１）ノードvi上の更新操作を表すタスクt1, t2, ..., tNがタスクモデル中にこの順で並んでおり、（２）これら全てを実行する前と後とでノードviの状態に変化がなく、かつ（３）t1, t2, ..., tN-1に対し別のノード上の更新操作を表すタスクが依存していないことを指して言う（ステップＳ１３０２）。
【0184】
ここで、ノードviに関する省略可能タスク列t1, t2, ..., tNは、直感的にはノードviに対する正しい更新手順ではあるものの、結局同じ状態に戻ってくるため実行する必要がないものを意味する。したがって基本的にそのようなタスクは省略（＝タスクモデルから排除）していいと考えられるが、これらのタスクに別のノードの更新タスクが依存していた場合には、それらの依存タスクの実行のために残しておく必要がある。
【0185】
単位構造フィードバック算出部２０４は、前ステップまでの操作により更新されたタスクモデルMの更改コストを出力する（ステップＳ１３０３）。
【0186】
以上が、本実施形態の単位構造フィードバック算出部２０４の説明である。
【0187】
以下に、本実施形態の単位構造フィードバック算出部２０４の動作の例を、図面を参照して説明する。図１３はシステム更改の例で、図１４は、図１３に示されている更改を実現する更新手順のタスクモデルの一例である。
【0188】
図１３に示されている一次構成と新規構成は、設定値を除き全く同じエンティティから構成されている。すなわち、アプリケーションa1,a2とそれにそれぞれ接続されたデータベースサーバdb＜１＞,db＜２＞およびこれら全てをホストするマシンであるm＜１＞を含む。
【0189】
このような状況は、最初の自動設計プロセス（つまり、構造フィードバックが与えられていない状況での探索）にて「なるべく一次構成に似たものを求める」のような指針を採用した場合などに起こりうる。
【0190】
設定値の違いにより、a1,db＜１＞およびm＜１＞の更新をする必要がある。ここで、a1およびdb＜１＞は単に設定値を更新するだけで更新可能であるのに対し、m＜１＞の設定変更は変更された設定値を反映するための再起動が必要であるとする。
【0191】
以上のような状況での更改に対し、図１４に示される更新手順が有効である。すなわちa1,db＜１＞,m＜１＞それぞれの設定値の変更ののち、m＜１＞の再起動のために一旦全てのアプリケーションおよびデータベースサーバを停止、m＜１＞の再起動後に全てを立ち上げるという手順である。
【0192】
上述の手順は、図１４に示されているようなタスクからなるＤＡＧ１５００として定義できる。つまり、「m＜１＞を停止する」タスクは「a1を停止する」「db＜１＞を停止する」、「a2を停止する」、「db＜２＞を停止する」タスクに依存しており、「a1を起動する」、「db＜１＞を起動する」、「a2を起動する」、「db＜２＞を起動する」タスクは「m ＜１＞を起動する」タスクに依存している。また、「a1の停止」、「db＜１＞の停止」はそれぞれ「a1の更新」、「db＜１＞の更新」に依存している。これらの依存関係が、図１４における矢印として明示されている。
【0193】
図１２を参照して、単位構造フィードバック算出部２０４に、タスクモデルとしてＤＡＧ１５００を、ノードとしてa1を入力した場合の動作を説明する。まず、Ｓ１３０１では、削除候補タスクとして「a1を更新する」、「a1を停止する」、「a1を起動する」の3つがあるが、「a1を停止する」タスクに対し「m＜１＞を停止する」タスクが依存しているため、当該ステップでは「a1を停止する」タスクを含み、更新前後でa1が起動状態にあるようなタスク列でこれらを置き換える。するとそのようなタスク列は「a1を停止する」、「a1を起動する」なので、結果として図１５に示すタスクモデルに更新される。当該タスクモデルには省略可能なタスク列が含まれないため、出力される更改コストは図１５に示すタスクモデルの更改コストとなる。
【0194】
次に、単位構造フィードバック算出部２０４に、タスクモデルとしてＤＡＧ１５００を、ノードとしてm＜１＞を入力した場合の動作を説明する。まず、Ｓ１３０１では、削除候補タスクとして「m＜１＞を更新する」、「m＜１＞を停止する」、「m＜１＞を起動する」の3つがあり、「m＜１＞を更新する」、「m＜１＞を停止する」タスクに対し依存する（かつm＜１＞に関連しない）タスクは存在しない。よってこれらのタスクは全て削除され、結果として図１６に示すタスクモデルに更新される。ステップＳ１３０２では、当該タスクモデルには省略可能な以下の４つのタスク列が含まれることが検出される。
【0195】
・「a1の停止」と「a1の更新」、・「db＜１＞の停止」と「db＜１＞の更新」、・「a2の停止」、・「db＜２＞の停止」
【0196】
【0197】
以上が、単位構造フィードバック算出部２０４の具体例を用いた説明である。
【0198】
（効果）
第２の実施形態の構造フィードバック算出部２０２は構造フィードバック算出部１０２とは異なり、構造フィードバック関数の構築に用いる「各ノードを更新する必要がなくなった場合の更改コストc[v]」を、更改コスト算出部１０３のように更改手順から求めるのではなくD0からD1への更改手順のデータを改変する形で求める。
第２の実施形態の構造フィードバック算出部２０２は構造フィードバック算出部１０２とは異なり、構造フィードバック関数の構築に用いる「各ノードを更新する必要がなくなった場合の更改コストc[v]」を、更改コスト算出部１０３のように更改手順から求めるのではなくD0からD1への更改手順のデータを改変する形で求める。
【0199】
一般に構成情報の差分からシステム更改の手順を自動で求めるのは比較的計算量が大きいタスクである一方、本実施形態の単位構造フィードバック算出部２０４は既に算出されたタスクモデルを改変するだけの手続きであるため高速に更改コストを求められる。
【0200】
したがって、本実施形態の構成情報具体化部２０１によれば、構造フィードバックを得るステップが構成情報具体化部１０１より高速であり、フィードバックループを高速に回すことができる。
【0201】
（最小構成）
図１９は、最小構成を有するシステム構成導出装置の構成を示すブロック図である。
システム構成導出装置８００は、構造フィードバック算出手段８０１と、構成情報具体化手段８０２と、を備える。抽象構成を、システムを構成する部品に相当するノードおよび前記部品間の関係性を示すエッジで構成されるグラフ構造を用いて、未確定な部分が含まれている前記システムの構成を表現するものとし、具体化を、前記抽象構成の前記未確定な部分を確定させるような前記グラフ構造の変換とし、具体構成を、前記抽象構成に含まれる前記未確定な部分が全て具体化によって確定したものとする場合に、構造フィードバック算出手段８０１は、移行前の前記システムである移行前システムおよび移行後の前記システムである移行後システムの候補の各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムの候補への更改コストが少ない前記移行後システムの候補が有する前記グラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力する。
図１９は、最小構成を有するシステム構成導出装置の構成を示すブロック図である。
システム構成導出装置８００は、構造フィードバック算出手段８０１と、構成情報具体化手段８０２と、を備える。抽象構成を、システムを構成する部品に相当するノードおよび前記部品間の関係性を示すエッジで構成されるグラフ構造を用いて、未確定な部分が含まれている前記システムの構成を表現するものとし、具体化を、前記抽象構成の前記未確定な部分を確定させるような前記グラフ構造の変換とし、具体構成を、前記抽象構成に含まれる前記未確定な部分が全て具体化によって確定したものとする場合に、構造フィードバック算出手段８０１は、移行前の前記システムである移行前システムおよび移行後の前記システムである移行後システムの候補の各々を表現する２つの前記具体構成を入力とし、前記移行前システムから前記移行後システムの候補への更改コストが少ない前記移行後システムの候補が有する前記グラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力する。
【0202】
構成情報具体化手段８０２は、前記抽象構成によって表現された前記移行後システムが備えるべき機能要件と、前記移行前システムの構成を表現した前記具体構成である一次構成とを入力とし、前記機能要件に関する前記具体化を繰り返すことによって、前記機能要件が完全に前記具体化された前記具体構成を探索し、前記一次構成と前記探索された前記具体構成とを元に、前記構造フィードバック算出手段が出力した前記構造フィードバック関数を利用して、前記更改コストが少ない前記具体構成を導出する。
【0203】
図２０は、最小構成を有するシステム構成導出装置の動作を示すフローチャート図である。構成情報具体化手段８０２は、移行後システムが備えるべき機能要件と、移行前システムの構成を表現した具体構成である一次構成とを取得する（ステップＳ１）。次に構成情報具体化手段８０２は、一次構成を元に機能要件に関する具体化を繰り返すことによって、機能要件が完全に具体化された具体構成を探索する（ステップＳ２）。
次に構造フィードバック算出手段８０１は、一次構成（請求項の移行前システムに相当）と探索された具体化構成（請求項の移行後システムに相当）を入力とし、一次構成から探索された具体化構成への更改コストが少ない探索された具体化構成が有するグラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力する（ステップＳ３）。次に構成情報具体化手段８０２は、一次構成と探索された具体構成とを元に、構造フィードバック算出手段が出力した前記構造フィードバック関数を利用して、更改コストが少ない具体構成を導出する（ステップＳ４）。
次に構造フィードバック算出手段８０１は、一次構成（請求項の移行前システムに相当）と探索された具体化構成（請求項の移行後システムに相当）を入力とし、一次構成から探索された具体化構成への更改コストが少ない探索された具体化構成が有するグラフ構造に基づく特徴に対してより高い評価を行う構造フィードバック関数を出力する（ステップＳ３）。次に構成情報具体化手段８０２は、一次構成と探索された具体構成とを元に、構造フィードバック算出手段が出力した前記構造フィードバック関数を利用して、更改コストが少ない具体構成を導出する（ステップＳ４）。
【0204】
なお、上述した実施形態におけるシステム構成導出装置８００、１００、２００の一部をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、システム構成導出装置８００、１００、２００に内蔵されたコンピュータシステムであって、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や周辺機器等のハードウェアを含むものとする。
【0205】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
【0206】
また、上述した実施形態におけるシステム構成導出装置８００、１００、２００の一部、または全部を、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等の集積回路として実現してもよい。システム構成導出装置８００、１００、２００の各機能部は個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。
【0207】
以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。また、本発明の一態様は、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。また、上記各実施形態や変形例に記載された要素であり、同様の効果を奏する要素同士を置換した構成も含まれる。
【符号の説明】
【0208】
１００・・・システム構成導出装置
１０１・・・構成情報具体化部
１０２・・・構造フィードバック算出部
１０３・・・更改コスト算出部
２００・・・システム構成導出装置
２０１・・・構成情報具体化部
２０２・・・構造フィードバック算出部
２０３・・・更改手順生成部
２０４・・・単位構造フィードバック算出部
８００・・・システム構成導出装置
８０１・・・構造フィードバック算出手段
８０２・・・構成情報具体化手段
１０１・・・構成情報具体化部
１０２・・・構造フィードバック算出部
１０３・・・更改コスト算出部
２００・・・システム構成導出装置
２０１・・・構成情報具体化部
２０２・・・構造フィードバック算出部
２０３・・・更改手順生成部
２０４・・・単位構造フィードバック算出部
８００・・・システム構成導出装置
８０１・・・構造フィードバック算出手段
８０２・・・構成情報具体化手段
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8A】
【図8B】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】