JPWO2016017111A1 - 情報処理システム及びシステム設計方法 - Google Patents

Abstract

本発明は、情報システムの自動構築において、ソフトウェア及びハードウェアの組合せを、より好適に選択する情報処理システムを提供する。その情報処理システムは、機能を示す抽象コンポーネントを含む抽象ワークフローに具体コンポーネントが割り当てられた具体ワークフローの集合から、リソース・性能特性が相対的に優れた最適解集合を導出する手段と、その最適解集合の具体ワークフローのリソース構成情報を生成する手段と、そのリソース構成情報に対する、優先的に使用するリソースの情報を含むシステム構成情報を生成し、出力する手段と、を備える。

Description

本発明は、ソフトウェア及びハードウェアから構成されるシステムを、設計するための技術に関する。

システムを自動設計するための技術は、例えばウェブサービスの合成という分野において注目されており、盛んに研究がなされている。特許文献１、特許文献２及び特許文献３に開示された技術は、機能要求あるいは非機能要求を充足するためのサービスの作成あるいは合成を目的としている。

特許文献１は、サービス作成方法を開示する。第１に、そのサービス作成方法は、自然言語の要求を意味的に解析してウェブサービスの要件を識別する。第２に、そのサービス作成方法は、識別されたそのウェブサービスの要件に基づいてウェブサービスを決定し、順序付けする。第３に、そのサービス作成方法は、順序付けされたウェブサービスを組み立て、ユーザにとって利用可能なものとする。

特許文献２は、ビジネスプロセスについて、事前条件及び事後条件に基づいてコンポーネントを合成することによる自動ワークフロー・システムを開示する。その自動ワークフロー・システムは、宣言型言語を使用してビジネス論理を実行する自動ワークフロー・システムである。そして、その自動ワークフロー・システムは、フロー、規則、及び状態をさらに含むプロセス記述を含む。そのフローは、ビジネス機能間の制御フローを表す。その状態は、ビジネス・エンティティについて法的状態遷移を表す。かつ、規則は、外部形式でビジネス・エンティティへ強制されるビジネス規則及び方針を表す。

上述の構成において、その自動ワークフロー・システムは、機能要件を事前条件及び事後条件として記述することによって、機能要件に基づく自動合成を可能にする。

特許文献３は、Ｗｅｂサービス構築管理方法を開示する。第１に、そのＷｅｂサービス構築管理方法は、非機能要求に基づいてサービス非機能要求情報を作成する。第２に、そのＷｅｂサービス構築管理方法は、その非機能要求に基づいて組合せ可能な実装機能群の情報を保管する。第３に、そのＷｅｂサービス構築管理方法は、その要求を実現するためのサービス論理モデル情報を作成する。第４に、そのＷｅｂサービス構築管理方法は、その論理モデル情報に基づいてその論理モデルを実現する。第５に、そのＷｅｂサービス構築管理方法は、その実装機能群情報に基づいて、その非機能要求と組合せ可能な実装機能群を備えたプログラム群を生成する。第６に、そのＷｅｂサービス構築管理方法は、そのサービス非機能要求情報を保管する。第７に、そのＷｅｂサービス構築管理方法は、そのプログラム群を保管する。第８に、そのＷｅｂサービス構築管理方法は、その非機能要求を解釈する。第９に、そのＷｅｂサービス構築管理方法は、その組合せ可能な実装機能群を選択し、そのプログラム群から実行プログラムを構成する。第１０に、そのＷｅｂサービス構築管理方法は、その実行プログラムを実行する。

上述の構成において、そのＷｅｂサービス構築管理方法は、非機能要件に基づいて、Ｗｅｂサービスの論理モデルの生成を実現する。

また、特許文献４及び特許文献５に開示された技術は、情報システムの構築を支援することを目的とする技術である。

特許文献４は、意味論を用いた情報システムの自動合成方法を開示する。第１に、その自動合成方法は、複数のコンピュータシステム機能ソースをコンピュータシステムにおけるサービスとして意味論的に記述する。第２に、その自動合成方法は、複数のプログラム可能なコンピュータシステム実行段にコンピュータシステムをセグメント化する。第３に、その自動合成方法は、そのコンピュータシステム実行段であるプレゼンテーションレイヤで生成されたタスクインターフェースに従って、そのサービスを有する実行可能なタスクをリアルタイムで動的に構成するステップを有する。

特許文献５は、複数のコンポーネントから構成されるシステムの開発を支援する開発支援装置を開示する。その開発支援装置は、データベース、計算手段、決定手段及び予測手段を含む。

そのデータベースは、既存システムのコンポーネントの種別毎に資源使用量を記憶する。その計算手段は、その開発対象システムの各コンポーネントと同じ種別のコンポーネントについてそのデータベースに記憶されている資源使用量を比較して、開発対象システムの複数のコンポーネントへの資源使用量の配分比を算出する。その決定手段は、その開発対象システムの各コンポーネントに対して、配分比を満足する範囲内である量の資源使用量を配分する。その予測手段は、トランザクションを複数同時に実行した場合のシステム全体の性能を予測する。その決定手段及びその予測手段は、予測結果が性能要求を満たすまで、配分比を満足する範囲内で資源使用量を配分し直し、予測することを繰り返す。

上述の構成において、その開発支援装置は、性能要求を満足するのに必要な各コンポーネントの資源使用量を探索する。換言すると、その開発支援装置は、複数コンポーネントから構成されるシステムについての、リソース配分の決定支援を実現する。

また、特許文献６及び特許文献７に開示された技術は、仮想マシンの配置を支援する目的の技術であり、仮想マシンレベルでの機能要求及び非機能要求を考慮したものである。

特許文献６は、コンピュータ資源を仮想化した仮想マシンを管理する計算機を開示する。その計算機は、複数の物理マシンをその仮想マシンを配備するための物理マシンとして管理する仮想マシン配備決定部を含む。

第１に、その仮想マシン配備決定部は、その仮想マシン上で動作するソフトウェアの種別と、そのソフトウェアの運用方針を含む設定情報とを取得する。第２に、その仮想マシン配備決定部は、その設定情報に基づいて、その仮想マシンの配備先となる物理マシンを、その複数の物理マシンの中から選択して決定する。

上述の構成において、その計算機は、非機能要件を考慮して、仮想マシンを物理マシンに配備する。

特許文献７は、クラウド環境内で資源を配分するシステム及び方法を提供する方法を開示する。第１に、その方法は、仮想ハイパーバイザをアプリケーションプログラミングインタフェースとして生成することによって、クラウド環境と１つ以上のデータセンタとの間に抽象化レイヤを提供する。第２に、その方法は、そのデータセンタによる作業負荷要求に応答し、その作業負荷の非機能要件がその仮想ハイパーバイザを用いるその抽象化レベルにおいて対処されるように、その仮想ハイパーバイザを用いて資源を区画する。更に、その方法は、そのデータセンタ内の仮想マシンをインスタンス化する。

上述の構成において、その方法は、複数のデータセンタ間にまたがる独立したクラウドシステムにおいて、論理的に接続することで単一のクラウドシステムとして取り扱うための抽象化を行い、非機能要件に基づいて仮想マシンの配備を自動的に導出する。しかし、使用することができる非機能要件は仮想マシン単位であるため、原理上、複数の機能が同一仮想マシンに割り当てられた場合には、適切な配備を導出することはできない。

非特許文献１は、大きなデータ量をもつデータベース中から、最適なデータを抽出するための演算として、スカイライン法の原理を提案する。さらに、非特許文献１は、その演算の有効性について、２次元及び多次元データに対してスカイライン法を実行した、評価実験の結果を示す。

特表２００９-５２４１７３号公報 特開２０１１-１２９１５０号公報 国際公開第２０１１／０９６３１４号 特表２００７-５３５７６７号公報 特開２０１０-１２８８３５号公報 国際公開第２０１３／０７２９７８号 特表２０１３−５１８３３０号公報

Ｓｔｅｐｈａｎ Ｂｏｒｚｓｏｎｙｉ、Ｄｏｎａｌｄ Ｋｏｓｓｍａｎｎ、Ｋｏｎｒａｄ Ｓｔｏｃｋｅｒ「Ｔｈｅ Ｓｋｙｌｉｎｅ Ｏｐｅｒａｔｏｒ」、ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ、２００１年、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＴＨＥ １７ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｄａｔａ Ｅｎｇｉｎｅｅｒｉｎｇ、ｐ．ｐ．４２１−４３０

情報システムの自動構築においては、その情報システムとして正しく動作し、機能要求及び非機能要求を満足し、かつコストに対して最適な、ソフトウェア及びハードウェアの組合せを自動的に選択することが求められる。

具体的には、情報システムは、ソフトウェア及びリソースの複雑な組合せにより構築される。また、情報システムの構築においては、顧客要求を満足する必要がある。その顧客要求は、機能要求と非機能要求とに大別される。その機能要求は、構築される情報システムにおける機能を定義するものである。即ち、その機能要求は、どのような入力に対してどのような出力をどのように提示するかを決定するものである。その非機能要求は、その機能を達成すべき程度を定義するものである。例えば、その非機能要求は、想定負荷に対する処理時間や構築コストなど様々な制約として与えられる。

従って、情報システムの自動構築の実現には、以下の３つの技術が必要である。第１の技術は、システムとして正しく動作する、ソフトウェア及びリソースの組合せを得るための技術である。第２の技術は、選択された組合せが機能要求及び非機能要求を満足しているかどうかを判定する技術である。第３の技術は、その組合せをコストに対して最適化する技術である。

ここで、上述したように、情報システムの構成は、ソフトウェア及びリソースの複雑な組合せである。このため、情報システムの自動構築の処理における探索空間は、例えば、Ｗｅｂサービス合成の処理における探索空間と比較して、非常に大きい。

図２４は、情報システムの構築とＷｅｂサービス合成とのそれぞれにおける、探索空間を構成する軸の違いを説明する図である。Ｗｅｂサービス合成は、アプリケーションに相当するＷｅｂサービス（図中のＷｅｂサービス合成のＡｐｐ（Ａｐｐｌｉｃａｔｉｏｎ）１乃至５）の実行順序と組合せを考慮して実行される。一方、情報システムの構築においては、アプリケーションとしてのソフトウェア（図中のＩＴシステム構築のＡｐｐ１乃至５）について、ハードウェアを含むリソースの割り当てを考慮して実行される必要がある。ここで、そのリソースは、図２４に示す、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やＭｅｍ（Ｍｅｍｏｒｙ）、Ｄｉｓｋに加え、これらを束ねた仮想的なＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）などである。この場合、その組合せ方によって、性能や耐故障性など様々な特性が変化する。

即ち、情報システムの構築における探索空間は、Ｗｅｂサービス合成における探索空間と比較し、爆発的に増大している。換言すると、サービス合成の場合には単体で動作する既存のコンポーネントにリソースのパラメータを与える必要がないのに対して、情報システムの設計の場合には、個々コンポーネントに割り当てる様々なリソースを考慮する必要がある。そのため、より多くの組合せが考慮されなければならない。よって、探索空間が乗算的に増大する。このため、Ｗｅｂサービス合成で使用される探索空間の削減技術は、情報システムの構築における探索空間の削減技術としての要求を満たさない。

換言すると、機能要求及び非機能要求から、目的とする複雑なシステム構築において、ソフトウェア選択とリソース選択とを自動で実施することが困難である。その理由は、以下のとおりである。

ソフトウェア性能は、割り当てられるリソースの性能に依存する。従って、一般的に、ソフトウェア選択とリソース選択とは、同時に考慮されるべきである。しかしながら、ソフトウェア選択とリソース選択とを同時に考慮する場合、結果として、探索空間の組合せ爆発が発生し、探索空間が大きくなりすぎる。

また、その探索空間の組合せ爆発の問題を、ソフトウェア選択を実施した後にリソース選択を実施することで解決しようとする場合、ソフトウェア選択が困難になる。

その理由は、ソフトウェア選択は、リソース選択に対する依存関係をもつためである。すなわち、割り当てられるリソースによって性能の優位性が逆転する可能性のあるソフトウェア同士を、それらのソフトウェアに割り当てられるリソースが決定される前に、比較し、選択する必要があるためである。

さらに、上述した先行技術文献に記載された技術においては、以下の問題点がある。

特許文献１のサービス作成方法は、構築される情報システムの最適化に、時間がかかりすぎるという問題点がある。その理由は、特許文献１のサービス作成方法がウェブサービスを対象とした方法であり、情報システムの構築のように、パラメータ数が多く、探索空間を大きい処理に適していないからである。

特許文献２の自動ワークフロー・システムは、性能情報をはじめとする非機能要件が重要となる情報システムを、自動構成することができないという問題点がある。その理由は、その自動ワークフロー・システムが、非機能要件について考慮されていないからである。

特許文献３のＷｅｂサービス構築管理方法は、ハードウェアを機能に対して割り当てることが設計上重要となる情報システムの自動設計には適用することはできないという問題点がある。その理由は、そのＷｅｂサービス構築管理方法が、ハードウェア割り当ては固定である、Ｗｅｂサービスを対象としているからである。

上述のとおり、特許文献１、特許文献２及び特許文献３のような、サービスやビジネスプロセスの合成に関する技術は、ハードウェアの構成及びハードウェアの割り当てを考慮しない。このため、それらの技術は、情報システムとして正しく動作するソフトウェア及びハードウェアの組合せを選択するという課題を解決することができない。

特許文献４の自動合成方法は、性能や可用性といった非機能要件を考慮しない。そのため、自動合成結果について設計者が判断し、候補から選択する必要があるという問題点がある。

特許文献５の開発支援装置は、自動的にアプリケーションを決定する用途に使用することができないという問題点がある。その理由は、その開発支援装置が、使用するアプリケーションのモデルの、入力を必要とするからである。

特許文献６の計算機は、機能要件を基にアプリケーションを決定することができないという問題点がある。その理由は、その計算機が、機能要件やミドルウェア上に載せられるアプリケーションプログラムについて考慮しないからである。

特許文献７の方法は、複数の機能を同一仮想マシンに割り当てた場合に、適切な配備を導出することができないという問題点を有する。その理由は、使用することができる非機能要件が仮想マシン単位であるからである。

上述の特許文献５、特許文献６及び特許文献７は、非機能要件に基づいて物理システムあるいは仮想化されたシステムの構成を導出する技術を開示する。一方で、これらの文献に記載された技術は、機能要求について考慮しない。このため、自動的に機能を充足するアプリケーションを開発者が選定する必要がある。このため、それらの技術は、機能要求及び非機能要求を満足する、ソフトウェア及びハードウェアの組合せを自動的に選択するという課題を解決することができない。

本発明の目的は、情報システムの自動構築において、ソフトウェア及びハードウェアの組合せを、より好適に選択する情報処理システム、システム設計方法及びそのためのプログラムあるいはそのプログラムを記録したコンピュータ読み取り可能な非一時的記録媒体を提供することにある。

本発明の一様態における情報処理システムは、機能を示す抽象コンポーネントを含む抽象ワークフローと、前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、前記具体コンポーネントへのリソース量割り当てに関する設計情報とに基づいて、前記具体コンポーネントを割り当てられた具体ワークフローの集合の内、リソース・性能特性が相対的に優れた前記具体ワークフローの集合である最適解集合を導出する導出手段と、前記最適解集合と、前記設計情報と、リソースの性能に関する情報と、前記具体ワークフローが充足する第１の非機能要件と、に基づいて、前記具体ワークフローに含まれる前記具体コンポーネントに割り当てる前記リソースを示すリソース構成情報を生成する性能サイジング手段と、前記リソース構成情報と、前記具体ワークフローと、前記具体ワークフローが充足する第２の非機能要件と、前記第２の非機能要件に関するリソースの情報とに基づいて、優先的に使用する前記リソースの情報を含むシステム構成情報を生成し、出力するリソース割り当て手段と、を含む。

本発明の一様態におけるシステム設計方法は、機能を示す抽象コンポーネントを含む抽象ワークフローと、前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、前記具体コンポーネントへのリソース量割り当てに関する設計情報とに基づいて、前記具体コンポーネントを割り当てられた具体ワークフローの集合の内、リソース・性能特性が相対的に優れた、具体ワークフローの集合である最適解集合を導出し、前記最適解集合と、前記設計情報と、リソースの性能に関する情報と、前記具体ワークフローが充足する第１の非機能要件とに基づいて、前記具体ワークフローに含まれる前記具体コンポーネントに割り当てる前記リソースを示すリソース構成情報を生成し、前記リソース構成情報と、前記具体ワークフローと、前記具体ワークフローが充足する第２の非機能要件と、前記第２の非機能要件に関するリソースの情報とに基づいて、優先的に使用する前記リソースの情報を含むシステム構成情報を生成し、出力する。

本発明の一様態におけるコンピュータ読み取り可能な非一時的記録媒体は、機能を示す抽象コンポーネントを含む抽象ワークフローと、前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、前記具体コンポーネントへのリソース量割り当てに関する設計情報とに基づいて、前記具体コンポーネントを割り当てられた具体ワークフローの集合の内、リソース・性能特性が相対的に優れた、具体ワークフローの集合である最適解集合を導出する処理と、前記最適解集合と、前記設計情報と、リソースの性能に関する情報と、前記具体ワークフローが充足する第１の非機能要件とに基づいて、前記具体ワークフローに含まれる前記具体コンポーネントに割り当てる前記リソースを示すリソース構成情報を生成する処理と、前記リソース構成情報と、前記具体ワークフローと、前記具体ワークフローが充足する第２の非機能要件と、前記第２の非機能要件に関するリソースの情報とに基づいて、優先的に使用する前記リソースの情報を含むシステム構成情報を生成する処理と、出力する処理をコンピュータに実行させるプログラムを記録する。

本発明は、情報システムの自動構築において、ソフトウェア及びハードウェアの組合せを、より好適に選択することを可能にするという効果がある。

本発明の第１の実施形態に係る情報処理システムの構成を示すブロック図である。 第１の実施形態における抽象ワークフローの一例を示す図である。 第１の実施形態における機能リストの一例を示す図である。 第１の実施形態における性能リストの一例を示す図である。 第１の実施形態における具体ワークフローの一例を示す図である。 第１の実施形態におけるリソースリストの一例を示す図である。 第１の実施形態におけるリソース構成情報の一例を示す図である。 本発明の実施例におけるシステム構成情報の一例を示す図である。 第１の実施形態に係る情報処理システムを実現するコンピュータのハードウェア構成を示すブロック図である。 第１の実施形態における情報処理システムの動作を示すフローチャートである。 第３の実施形態における具体ワークフローが生成される場合の動作を示す図である。 第２の実施形態におけるワークフローに対してリソース・性能特性を計算する上でワークフローを変形させ、分岐を除去する例を示す図である。 第１の実施形態におけるリソース量に対応する所定の重みで性能を重み付けし、リソース・性能特性を比較する例を説明する図である。 第１の実施形態の変形例に係る情報処理システムの構成を示すブロック図である。 本発明の第２の実施形態に係る情報処理システムの構成を示すブロック図である。 第２の実施形態における機能要求の一例を示す図である。 第２の実施形態における接続リストの一例を示す図である。 第２の実施形態における情報処理システムの動作を示すフローチャートである。 第２の実施形態の変形例に係る情報処理システムの構成を示すブロック図である。 図本発明の第３の実施形態に係る情報処理システムの構成を示すブロック図である。 第３の実施形態におけるスカイライン集合について説明する図である。 第３の実施形態におけるスカイライン集合が生成される場合の動作を説明する図である。 本発明の第１の実施例における各具体コンポーネントの値域に関する情報の一例を示す図である。 関連技術における情報システムの構築とＷｅｂサービス合成とのそれぞれにおける、探索空間を構成する軸の違いを説明する図である。

本発明を実施するための形態について図面を参照して詳細に説明する。尚、各図面及び明細書記載の各実施形態において、同様の構成要素には同様の符号を付与し、適宜説明を省略する。また、図面中の矢印の方向は、一例を示すものであり、ブロック間の信号の向きを限定するものではない。

＜＜＜第１の実施形態＞＞＞
図１は、本発明の第１の実施形態に係る情報処理システム１０１の構成を示すブロック図である。

図１に示すように、本実施形態に係る情報処理システム１０１は、導出部１１０と、性能サイジング部１２０と、リソース割当部１３０とを含む。尚、図１に示す各構成要素は、ハードウェア単位の回路でも、コンピュータ装置の機能単位に分割された構成要素でもよい。ここでは、図１に示す構成要素は、コンピュータ装置の機能単位に分割された構成要素とする。

＝＝＝導出部１１０＝＝＝
導出部１１０は、抽象ワークフロー８３０と、機能リスト１４１と、性能リスト１４２とに基づいて、最適解集合８５０を導出する。

抽象ワークフロー８３０は、機能を示す抽象コンポーネントを含む。抽象ワークフロー８３０の詳細は、後述する。

機能リスト１４１は、抽象コンポーネントに対応する具体コンポーネントを示す情報とも呼ばれる。ここで、その具体コンポーネントは、情報システムを構成する、実在するソフトウェアアプリケーション（アプリケーション、コンポーネント、ソフトウェア及びプログラムなどとも呼ばれる）である。機能リスト１４１の詳細は、後述する。

性能リスト１４２は、具体コンポーネントへのリソース量割り当てに関する設計情報とも呼ばれる。ここで、そのリソース量割り当てにおけるリソースは、ハードウェア（ＣＰＵや、メモリ、ディスクなど）である。即ち、リソース量は、ハードウェア及び仮想ハードウェアの数量である。性能リスト１４２の詳細は、後述する。

その最適解集合８５０は、具体コンポーネントを割り当てられた図５に示すような具体ワークフロー８４０の集合の内、リソース・性能特性が相対的に優れた具体ワークフロー８４０の集合である。例えば、最適解集合８５０は、図５に示す具体ワークフロー８４０の集合の内の、１行目の具体ワークフロー８４０を要素とする集合である。

そのリソース・性能特性は、例えば、具体ワークフロー８４０の、割り当てられたリソース量に対する、性能を示す関数である。導出部１１０は、例えば、性能リスト１４２に含まれる、その具体コンポーネントの性能を示す関数（後述）に基づいて、そのリソース・性能特性を生成する。

具体的には、第１に、導出部１１０は、具体ワークフロー８４０のそれぞれに対応するリソース・性能特性を、リソース量に対応する所定の重みで重み付けして比較する。その具体ワークフロー８４０は、抽象ワークフロー８３０に含まれる抽象コンポーネントのいずれかひとつに対応する、複数の具体コンポーネントのそれぞれが、その抽象ワークフロー８３０に割り当てられたものである。

その所定の重みは、そのリソース・性能特性を比較する場合の、リソース量の所定の定義域の範囲を限定する、窓関数であってよい。即ち、その所定の重みは、リソース量の所定の定義域の範囲を「１」とし、ほかの範囲を「０」としてよい。またその所定の重みは、リソース量の所定の定義域の範囲を「０」を超え「１」以下である小数としてもよい。その所定の重みは、経験的にあるいは理論的に得られる、そのリソース量がシステムの設計時において設計値として採用される頻度に対応する。

第２に、導出部１１０は、そのリソース・性能特性を比較した結果に基づいて、その具体コンポーネントを含む具体ワークフロー８４０の集合である、最適解集合８５０を導出する。

＝＝＝抽象ワークフロー８３０＝＝＝
図２は、抽象ワークフロー８３０の一例を示す図である。図２において、ａ、ｂ、ｃ及びｄのそれぞれは、抽象コンポーネントを示す。抽象コンポーネントは、機能カテゴリの区分、即ち機能を示す。本実施形態において、ａは、例えば入力データを保存する機能を示す抽象コンポーネントである。ｂは、例えば入力データの各単語の出現頻度を計算する機能を示す抽象コンポーネントである。ｃは、例えば出現頻度の大きい順に表示する機能を示す抽象コンポーネントである。ｄは、例えば計算結果を保存する機能を示す抽象コンポーネントである。

抽象ワークフロー８３０は、Ｇ_ｘ：＝＜ｆ_０ｘ、Ｆ_ｘ、Ｖ_ｘ＞と表現される場合もある。ここで、ｆ_０ｘ∈Ｆ_ｘは、最初に実行される抽象コンポーネントである。Ｆ_ｘは、ワークフローに含まれる抽象コンポーネントの集合である。Ｖ_ｘは、抽象コンポーネント間の接続を示す、抽象コンポーネント２つ組の情報である。

即ち、図２に示す抽象ワークフロー８３０は、最初に実行される抽象コンポーネントがａであることを示す。そして、抽象ワークフロー８３０は、抽象ワークフロー８３０が抽象コンポーネントａ、ｂ、ｃ及びｄを含むことを示す。さらに、抽象ワークフロー８３０は、抽象コンポーネントａとｂとの間の、抽象コンポーネントｂとｄとの間の、及び抽象コンポーネントｄとｃとの間の、接続を示す。

尚、抽象ワークフロー８３０は、図２に示す例に係わらず、任意の構造であってよい。

＝＝＝機能リスト１４１＝＝＝
図３は、機能リスト１４１の一例を示す図である。図３に示すように、機能リスト１４１は、具体コンポーネントｃ_ｉと、その具体コンポーネントｃ_ｉが属する抽象コンポーネントで示される機能カテゴリ区分ｆ_ｊと、その具体コンポーネントｃ_ｉが充足する制約ａ_ｋとの３つ組を示す、レコードを含む。ここで、その制約は、例えば、信頼性、可用性要求などである。

本実施形態において、Ａは、例えば、１０並列分散ファイルシステムＸへ保存するアプリケーションを示す具体コンポーネントｃ_ｉである。Ｂは、例えば、ジャーナリングファイルシステムYへ保存するアプリケーションを示す具体コンポーネントｃ_ｉである。Ｃは、例えば、ワードカウントアプリケーションを示す具体コンポーネントｃ_ｉである。Ｄは、例えば、Ｗｅｂアプリケーションを示す具体コンポーネントｃ_ｉである。Ｅは、例えば、メモリキャッシュを使用するコンポーネントを示す具体コンポーネントｃ_ｉである。Ｆは、例えば、ネットワークストレージを使用するコンポーネントを示す具体コンポーネントｃ_ｉである。

換言すると、機能リスト１４１の１つのレコード＜ｃ_ｉ、ｆ_ｊ、ａ_ｋ＞は、具体コンポーネントｃ_ｉが、機能カテゴリ区分ｆ_ｊに属し、制約ａ_ｋを充足することを意味する。

尚、機能リスト１４１は、図３に示す例に係わらず、任意の構造であってよい。例えば、機能リスト１４１は、ａ_ｋを含まなくてもよいし、図３に示す情報以外の、任意の情報を含んでもよい。例えば、機能リスト１４１は、複数のリストに分離されてもよいし、その一部あるいは全部を、性能リスト１４２に統合されてもよい。

＝＝＝性能リスト１４２＝＝＝
図４は、性能リスト１４２の一例を示す図である。図４に示すように、性能リスト１４２は、具体コンポーネントｃ_ｉと、その具体コンポーネントｃ_ｉの、性能を示す関数ｖ_ｉ、上述の重みを示す関数ｗ_ｉ及びコスト情報ｐ_ｉとの４つ組を示す、レコードを含む。

ここで、関数ｖ_ｉは、あるリソース量ｒが与えられたときの性能ｖ_ｉ（ｒ）を示す、ベクトルからベクトルへの関数である。リソース量ｒは、例えば、（ＣＰＵ：２０ＧＨｚ（Ｇｉｇａ Ｈｅｒｔｚ）、Ｍｅｍｏｒｙ：５０ＧＢ（Ｇｉｇａ Ｂｙｔｅ）、Ｄｉｓｋ：３ＴＢ（Ｔｅｒａ Ｂｙｔｅ））のような多次元（ベクトル）データである。

また、関数ｗ_ｉは、あるリソース量（ベクトル形式）ｒが与えられたときの重みｗ_ｉ（ｒ）を示す、ベクトルからスカラへの関数である。重みｗ_ｉ（ｒ）は、上述したように、そのリソース量ｒが、システムの設計時において採用される頻度に対応する値である。即ち、関数ｗ_ｉは、あるリソースのリソース量の、設計出現頻度とも言われる。

換言すると、性能リスト１４２のひとつのレコード＜ｃ_ｉ、ｖ_ｉ、ｗ_ｉ、ｐ_ｉ＞は、以下のことを意味する。第１に、具体コンポーネントｃ_ｉが、あるリソース量（ベクトル形式）ｒが与えられたときの性能ｖ_ｉ（ｒ）をもつ。第２に、そのリソース量に対応する重みがｗ_ｉ（ｒ）である。第３に、その具体コンポーネントの価格がｐ_ｉである。

尚、性能リスト１４２は、図４に示す例に係わらず、任意の構造であってよい。例えば、機能リスト１４１は、図４に示す情報以外の、任意の情報を含んでもよい。例えば、性能リスト１４２は、複数のリストに分離されてもよいし、その一部あるいは全部を、機能リスト１４１に統合されてもよい。

＝＝＝具体ワークフロー８４０＝＝＝
図５は、具体ワークフロー８４０の一例を示す図である。図５は、４つの具体ワークフロー８４０の集合を示す。図５において、Ａ、Ｂ、Ｃ、Ｄ、Ｅ及びＦのそれぞれは、図３に示す具体コンポーネントｃ_ｉに対応する。

具体ワークフロー８４０は、ＧＤ_ｘ：＝＜ｃ_０ｘ、ＣＤ_ｘ、ＶＤ_ｘ＞と表現される場合もある。ここで、ｃ_０ｘ∈ＣＤ_ｘは、最初に実行される具体コンポーネントｃ_ｉである。ＣＤ_ｘは、ＧＤ_ｘに含まれるｃ_ｉの集合である。ＶＤ_ｘは、ｃ_ｉ間の接続を示す、ｃ_ｉの２つ組の情報である。

即ち、図５に示す、最上行の具体ワークフロー８４０は、最初に実行される具体コンポーネントｃ_ｉがＡであることを示す。そして、その具体ワークフロー８４０は、具体ワークフロー８４０が具体コンポーネントｃ_ｉのＡ、Ｃ、Ｄ及びＥを含むことを示す。さらに、具体ワークフロー８４０は、具体コンポーネントｃ_ｉのＡとＣとの間の、具体コンポーネントｃ_ｉのＣとＥとの間の、及び具体コンポーネントｃ_ｉのＥとＤとの間の、接続を示す。

＝＝＝性能サイジング部１２０＝＝＝
性能サイジング部１２０は、最適解集合８５０と、リソースリスト１５１と、第１の非機能要件とに基づいて、リソース構成情報８６０を生成する。前述したように、最適解集合８５０は、リソース・性能特性を示す具体ワークフロー８４０を含む。その第１の非機能要件は、具体ワークフロー８４０が充足する非機能要件である。リソース構成情報８６０は、具体ワークフロー８４０に含まれる具体コンポーネントに割り当てるリソースと、性能との対応を示す。リソースリスト１５１は、リソースの性能に関する情報とも呼ばれる。その第１の非機能要件は、例えば、性能である。

性能サイジング部１２０は、例えば、局所探索法、焼きなまし法及び遺伝的アルゴリズムを任意に用いた最適化計算の結果に基づいて、その第１の非機能要件を充足する、そのリソースの候補を選定してよい。

＝＝＝リソースリスト１５１＝＝＝
図６は、リソースリスト１５１の一例を示す図である。リソースリスト１５１は、システムを構成するリソースｈ_ｉと、そのリソースｈ_ｉの、リソース量ｒ_ｉ、価格情報ｐ_ｉ及び入手容易性ｅ_ｉとの４つ組を示す、レコードを含む。

換言すると、リソースリスト１５１の１つのレコード＜ｈ_ｉ、ｒ_ｉ、ｐ_ｉ、ｅ_ｉ＞は、リソースｈ_ｉが、リソース量ｒ_ｉをもち、その価格はｐ_ｉであって、［０、１］の範囲で正規化された入手容易性はｅ_ｉであることを意味する。

尚、リソースリスト１５１は、図６に示す例に係わらず、任意の構造であってよい。例えば、リソースリスト１５１は、ｅ_ｉを含まなくてもよいし、図６に示す情報以外の、任意の情報を含んでもよい。

＝＝＝リソース構成情報８６０＝＝＝
図７は、リソース構成情報８６０の一例を示す図である。図７に示すようにリソース構成情報８６０は、リソース構成と、そのリソース構成に対する性能及びコストを示す。尚、リソース要素の列の数値のそれぞれは、そのリソース要素の台数を示す。

＝＝＝リソース割当部１３０＝＝＝
リソース割当部１３０は、リソース構成情報８６０と、最適解集合８５０に含まれる具体ワークフロー８４０と、その具体ワークフロー８４０が充足する第２の非機能要件と、リソースリスト１５１とに基づいて、図８に示すようなシステム構成情報８９０を生成し、出力する。
その具体ワークフロー８４０は、最適解集合８５０に含まれる具体ワークフロー８４０である。リソースリスト１５１は、第２の非機能要件に関するリソースの情報とも呼ばれる。

＝＝＝システム構成情報８９０＝＝＝
図８は、システム構成情報８９０の一例を示す図である。図８に示すように、システム構成情報８９０は、優先的に使用するリソースの情報を少なくとも含む。

尚、システム構成情報８９０は、図８に示す例に係わらず、任意の構造であってよい。例えば、システム構成情報８９０は、コストや性能の情報を含まなくてもよいし、図８に示す情報以外の、任意の情報を含んでもよい。

以上が、情報処理システム１０１の機能単位の各構成要素についての説明である。

次に、情報処理システム１０１のハードウェア単位の構成要素について説明する。

図９は、本実施形態における情報処理システム１０１を実現するコンピュータ７００のハードウェア構成を示す図である。まず、図９を参照して、情報処理システム１０１を実現するコンピュータ７００の、ハードウェア単位の各構成要素について説明する。

図９に示すように、コンピュータ７００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、プロセッサとも呼ばれる）７０１、記憶部７０２、記憶装置７０３、入力部７０４、出力部７０５及び通信部７０６を含む。さらに、コンピュータ７００は、外部から供給される記録媒体（または記憶媒体）７０７を含む。例えば、記録媒体７０７は、情報を非一時的に記憶する不揮発性記録媒体（非一時的記録媒体）である。また、記録媒体７０７は、情報を信号として保持する、一時的記録媒体であってもよい。

ＣＰＵ７０１は、オペレーティングシステム（不図示）を動作させて、コンピュータ７００の全体の動作を制御する。例えば、ＣＰＵ７０１は、記憶装置７０３に装着された記録媒体７０７から、そのプログラムやデータを読み込み、読み込んだそのプログラムやそのデータを記憶部７０２に書き込む。ここで、そのプログラムは、例えば、後述の図１０に示すフローチャートの動作をコンピュータ７００に実行させるためのプログラムである。

そして、ＣＰＵ７０１は、その読み込んだプログラムに従って、またその読み込んだデータに基づいて、図１に示す導出部１１０、性能サイジング部１２０及びリソース割当部１３０として各種の処理を実行する。

尚、ＣＰＵ７０１は、通信網（不図示）に接続される外部コンピュータ（不図示）から、記憶部７０２にそのプログラムやそのデータをダウンロードしてもよい。

記憶部７０２は、そのプログラムやそのデータを記憶する。記憶部７０２は、例えば、抽象ワークフロー８３０、機能リスト１４１、性能リスト１４２、具体ワークフロー８４０、リソース構成情報８６０及びリソースリスト１５１を記憶してよい。記憶部７０２は、導出部１１０、性能サイジング部１２０及びリソース割当部１３０の一部として含まれてよい。

記憶装置７０３は、例えば、光ディスクや、フレキシブルディスク、磁気光ディスク、外付けハードディスク、半導体メモリなどであって、記録媒体７０７を含む。記憶装置７０３（記録媒体７０７）は、そのプログラムをコンピュータ読み取り可能に記憶する。記憶装置７０３は、例えば、抽象ワークフロー８３０、機能リスト１４１、性能リスト１４２、具体ワークフロー８４０、リソース構成情報８６０及びリソースリスト１５１を記憶してよい。記憶装置７０３は、導出部１１０、性能サイジング部１２０及びリソース割当部１３０の一部として含まれてよい。

入力部７０４は、オペレータによる操作の入力や外部からの情報の入力を受け付ける。入力操作に用いられるデバイスは、例えば、マウスや、キーボード、内蔵のキーボタン及びタッチパネルなどである。入力部７０４は、導出部１１０、性能サイジング部１２０及びリソース割当部１３０の一部として含まれてよい。

出力部７０５は、例えばディスプレイで実現される。出力部７０５は、例えばＧＵＩ（ＧＲＡＰＨＩＣＡＬ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）によるオペレータへの入力要求や、オペレータに対する出力提示などのために用いられる。出力部７０５は、導出部１１０、性能サイジング部１２０及びリソース割当部１３０の一部として含まれてよい。

通信部７０６は、外部システムとのインタフェースを実現する。通信部７０６は、導出部１１０、性能サイジング部１２０及びリソース割当部１３０の一部として含まれてよい。

以上説明したように、図１に示す情報処理システム１０１の機能単位のブロックは、図９に示すハードウェア構成のコンピュータ７００によって実現される。但し、コンピュータ７００が備える各部の実現手段は、上記に限定されない。すなわち、コンピュータ７００は、物理的に結合した１つの装置により実現されてもよいし、物理的に分離した２つ以上の装置を有線または無線で接続し、これら複数の装置により実現されてもよい。

尚、上述のプログラムのコードを記録した記録媒体７０７が、コンピュータ７００に供給される場合、ＣＰＵ７０１は、記録媒体７０７に格納されたそのプログラムのコードを読み出して実行してもよい。あるいは、ＣＰＵ７０１は、記録媒体７０７に格納されたそのプログラムのコードを、記憶部７０２、記憶装置７０３またはその両方に格納してもよい。すなわち、本実施形態は、コンピュータ７００（ＣＰＵ７０１）が実行するそのプログラム（ソフトウェア）を、一時的にまたは非一時的に、記憶する記録媒体７０７の実施形態を含む。尚、情報を非一時的に記憶する記憶媒体は、不揮発性記憶媒体とも呼ばれる。

以上が、本実施形態における情報処理システム１０１を実現するコンピュータ７００の、ハードウェア単位の各構成要素についての説明である。

次に本実施形態の動作について、図面を参照して詳細に説明する。

図１０は、本実施形態の動作を示すフローチャートである。尚、このフローチャートによる処理は、前述したＣＰＵ７０１によるプログラム制御に基づいて、実行されてよい。また、処理のステップ名については、Ｓ６０１のように、記号で記載する。

導出部１１０は、以下のように動作する。

導出部１１０は、抽象ワークフロー８３０を取得したことを契機に、図１０に示す動作を開始する。

導出部１１０は、機能リスト１４１に基づいて、抽象ワークフロー８３０に含まれる抽象コンポーネントｆ_ｉのそれぞれに対応する具体コンポーネントｃ_ｉの集合Ｃ_ｉを取得する（ステップＳ６０１）。例えば、導出部１１０は、抽象ワークフロー８３０の抽象コンポーネントを集合Ｃ_ｉで置き換えた中間ワークフローを生成する。

次に、導出部１１０は、その中間ワークフローに含まれる集合Ｃ_ｉに基づいて、それぞれ１つずつ具体コンポーネントｃ_ｉを選択し、具体ワークフロー８４０を生成する（ステップＳ６０２）。

図１１は、ステップＳ６０１とステップＳ６０２の、具体ワークフロー８４０が生成される動作を説明する図である。導出部１１０は、ステップＳ６０１において、機能リスト１４１と抽象ワークフロー８３０とから中間ワークフローを生成する。導出部１１０は、ステップＳ６０２において、中間ワークフローから具体ワークフロー８４０を生成する。

次に、導出部１１０は、具体ワークフロー８４０から最適解集合８５０を導出する（ステップＳ６０３）。以下に、導出部１１０が、具体ワークフロー８４０から最適解集合８５０を導出する動作の一例を、詳細に説明する。

第１に、導出部１１０は、具体ワークフロー８４０のリソース・性能特性となる関数ｆ_ＧＤｘ（ｒ）を、個々の具体コンポーネントｃ_ｉのリソース・性能特性の関数ｖ_ｉ（ｒ）とワークフローの形状とから合成によって求める。第２に、導出部１１０は、求めた関数ｆ_ＧＤｘ（ｒ）のうち、最適なリソース・性能特性の関数ｆ_ＧＤｘ（ｒ）を得られる具体コンポーネントを選択する。この選択は、ナップザック問題として知られている最適化計算問題に帰着し、その解き方には動的計画法を用いることができる。但し、定数の比較を使用するナップザック問題と異なる点として、関数ｆ_ＧＤｘ（ｒ）の最適化は、リソース・性能特性を示す関数間の、半順序による比較を使用する。そのため、得られる最適解は単一であることが保証されない最適解集合８５０である。

接続関係にある関数どうしの合成は、以下の法則に基づいて実行される。関数の接続関係は、直列接続と、合流によって定義されるため、それぞれの接続関係の法則について説明する。

例えば、コンポーネントａのリソース・性能特性を示す関数ｆ_ａ（ｒ）とコンポーネントｂのリソース・性能特性を示す関数ｆ_ｂ（ｒ）との直列接続ａ→ｂのリソース・性能特性を示す関数は、ｆ_ａ→ｂ（ｒ）：＝ｍｉｎ（ｆ_ａ（ｒ）、ｆ_ｂ（ｒ））である。また、ｆ_ａ（ｒ）とｆ_ｂ（ｒ）とのｆ_ｃ（ｒ）への合流［ａ｜ｂ］→ｃのリソース・性能特性を示す関数は、ｆ_{［ａ｜ｂ］→ｃ}（ｒ）：＝ｍｉｎ（ｍｉｎ（ｆ_ａ（ｒ）、ｆ_ｂ（ｒ））、ｆ_ｃ（ｒ））である。

上述の定義を用いることができるように、分岐のあるワークフローを、分岐のないワークフローに置き換えることができる。図１２は、ワークフローの分岐の解消を説明する図である。図１２に示すように、上側の分岐のあるワークフローは、下側の分岐のないワークフローを形成することができる。従って、上述の直列接続と合流とのそれぞれの、リソース・性能特性を示す関数の合成により、任意のワークフローのリソース・性能特性を示す関数を求めることができる。

また、導出部１１０は、各具体コンポーネントｃ_ｉについて、比較を行うための定義域を、重みを示すｗ_ｉを用いて限定する。

図１３は、リソース量に対応する所定の重みで性能を重み付けし、リソース・性能特性を比較する例を説明する図である。図１３は、２つの具体コンポーネントのそれぞれのリソース・性能特性を示す関数４０１と関数４１１とを比較する場合を示す。関数４０２及び関数４１２のそれぞれは、その２つの具体コンポーネントのそれぞれに対応するｗ_ｉである。関数４０３及び関数４１３のそれぞれは、関数４０１が関数４０２で重み付けされたもの、及び関数４１１が関数４１２で重み付けされたものである。換言すると、関数４０３及び関数４１３のそれぞれは、リソース・性能特性を示す関数４０１及び関数４１１のそれぞれが、窓関数ｗ_ｉと乗算され、範囲を限定されたものである。

導出部１１０は、関数４０３と関数４１３とを、それらの最大値や、最小値、中間値及び積分値などの組合せに基づいて、比較することで、優劣（最適さ）を判定する。

以上が、導出部１１０が、具体ワークフロー８４０から最適解集合８５０を導出する動作の説明である。

尚、導出部１１０は、複数の抽象ワークフロー８３０を取得する場合がある。この場合、導出部１１０は、各抽象ワークフロー８３０に対応する最適解集合８５０を前述のステップＳ６０１乃至ステップＳ６０３によって導出する。次に、導出部１１０は、それらの最適解集合８５０の和集合をとり、その和集合からいずれかの抽象ワークフロー８３０において最適解とならないものを除去すればよい。

図１０に戻って、性能サイジング部１２０は、最適解集合８５０と性能リスト１４２とリソースリスト１５１と非機能要件とに基づいて、リソース構成情報８６０を生成する（ステップＳ６０４）。
その非機能要件は、最適解集合８５０に含まれる具体ワークフロー８４０が充足する第１の非機能要件であり、例えば、性能やコストである。

換言すると、性能サイジング部１２０は、入力された最適解集合８５０に含まれる具体ワークフロー８４０であるＧＤ_ｘについて、そのリソース・性能特性ｆ_ＧＤｘ（ｒ）をリソースｒについて解く。これは、情報処理システム１０１に与えられた入力のうち、リソースｒを変量、コストを制約として性能ｖ_ＧＤｘ（ｒ）を最大化する、一般的な制約付き多変量最適化問題を解くことである。尚、そのリソース・性能特性ｆ_ＧＤｘ（ｒ）は、最適解集合８５０に含まれる具体ワークフロー８４０であるＧＤ_ｘと、性能リスト１４２とに基づいて、導出部１１０によって生成されたものである。その多変量最適化問題の最適解ｒ_ＧＤｘが、具体ワークフロー８４０であるＧＤ_ｘに対する最適な割り当てリソース総量である。

上述したように、そのリソース構成情報８６０は、具体ワークフロー８４０に含まれる具体コンポーネントに割り当てるリソースと性能との対応を示す。即ち、リソース構成情報８６０のリソースの各要素の台数が、最適解ｒ_ＧＤｘであり、リソース構成情報８６０の性能の数値が、性能ｖ_ＧＤｘ（ｒ）である。

次に、リソース割当部１３０は、最適解集合８５０に含まれる具体ワークフロー８４０であるＧＤ_ｘとリソース構成情報８６０と非機能要件とリソースリスト１５１とに基づいて、システム構成情報８９０を生成し、出力する（ステップＳ６０５）。ここで、その非機能要件は、具体ワークフロー８４０が充足する第２の非機能要件であり、例えば、コストや入手容易性である。

換言すると、リソース割当部１３０は、具体ワークフロー８４０であるＧＤ_ｘ及びそのＧＤ_ｘの最適な割り当てリソース総量ｒ_ＧＤｘを入力として、そのＧＤ_ｘに含まれる具体コンポーネントに割り当てる、最適なリソース量を計算する。尚、リソース割当部１３０は、複数の具体コンポーネントについて、割り当てるリソースを集約させて、同一のリソースを割り当ててよい。

さらに換言すると、リソース割当部１３０は、個々の具体コンポーネントに割り当てるリソースの総和について、以下の２点の制約を充足し、リソースのコストを最小化する最適化問題を解く。その総和は、例えば、ＣＰＵ、Ｍｅｍｏｒｙ、Ｄｉｓｋのそれぞれのリソースの種類毎の総和である。その総和は、具体的には、（ＣＰＵ：２０ＧＨｚ、Ｍｅｍｏｒｙ：５０ＧＢ、Ｄｉｓｋ：３ＴＢ）のような多次元（ベクトル）データである。

第１の制約は、リソース割当部１３０がリソースの割り当てを実施した結果、具体ワークフロー８４０の性能が、構築するシステムの性能目標を充足することである。

第２の制約は、リソース割当部１３０がリソースの割り当てを実施した結果、個々の具体コンポーネントに割り当てられたリソースの総和が、割り当てリソース総量ｒ_ＧＤｘに遊びベクトル定数ｒ_ｉを加えた値を超えないことである。即ち、その第２の制約は、具体コンポーネントｉ_０、ｉ_１を集約し、リソースｊ_０、ｊ_１を割り当てることを、ａｓｓｉｇｎ（ｊ_０）＝｛ｉ_０、ｉ_１｝及びａｓｓｉｇｎ（ｊ_１）＝｛ｉ_０、ｉ_１｝で表現したときに、以下の式が充足されることである。Σ_ｊ∈ｎｒ_{ａｓｓｉｇｎ（ｊ）}＜ｒ_ＧＤｘ＋ｒ_ｌ。但し、ｎは割り当てに使用したリソースの集合である。

よって、リソース割当部１３０は、以上の２条件を満足し、Σ_ｊ∈ｎｐ_ｊを最小化するときのリソース割り当てａｓｓｉｇｎを求める。

以上の動作において、例えば、抽象ワークフロー８３０は、図９に示す記憶部７０２あるいは記憶装置７０３に、予め記憶されていてよい。導出部１１０は、図９に示す入力部７０４を介して操作者が入力した、抽象ワークフロー８３０を取得してもよい。導出部１１０は、図９に示す通信部７０６を介して図示しない機器から、抽象ワークフロー８３０を受信してもよい。導出部１１０は、図９に示す記憶装置７０３を介して、記録媒体７０７に記録された抽象ワークフロー８３０を取得してもよい。導出部１１０は、機能リスト１４１や性能リスト１４２を、抽象ワークフロー８３０の場合と同様にして取得してよい。

性能サイジング部１２０は、性能リスト１４２や第１の非機能要件を、導出部１１０が抽象ワークフロー８３０を取得する場合と同様にして、取得してよい。

リソース割当部１３０は、リソースリスト１５１や、第２の非機能要件を、導出部１１０が抽象ワークフロー８３０を取得する場合と同様にして、取得してよい。

また、リソース割当部１３０は、図９に示す出力部７０５を介して、システム構成情報８９０を出力する。リソース割当部１３０は、図９に示す通信部７０６を介して、図示しない機器にシステム構成情報８９０を送信してもよい。リソース割当部１３０は、図９に示す記憶装置７０３を介して、記録媒体７０７にシステム構成情報８９０を記録してもよい。

以上が、本実施形態の動作についての説明である。

以上説明したように、導出部１１０は、具体ワークフロー８４０の割り当てリソース量に対する性能を示す関数（リソース・性能特性とも呼ばれる）を比較することで、最適な具体ワークフロー８４０を導出する。

ここで、具体ワークフロー８４０のそれぞれは、１つの抽象コンポーネント（機能カテゴリの区分とも呼ばれる）に対応する、複数の競合する具体コンポーネントのそれぞれを含む。すなわち、導出部１１０は、同じ機能を実現する複数の具体コンポーネントの内、同程度のリソース量を割り当てた場合の非機能要件（例えば、性能）の達成度がより高い具体コンポーネントを選択する。

但し、リソース・性能特性は関数であるため、その関数の定義域によって性能値の大小関係が異なる。そのため、導出部１１０は、性能リスト１４２に含まれるｗ_ｉ（リソース量割り当てに関する設計情報とも呼ばれる）に基づいて、その関数の定義域を決定する。

また、性能サイジング部１２０は、リソース・性能特性を示す関数に対して、非機能要件を制約あるいは最適化目標のいずれかとする、探索的あるいは解析的な最適化を行う。性能サイジング部１２０は、この最適化を行うことによって、具体ワークフロー８４０を構成する具体コンポーネントに割り当てるリソースの総量（例えば、リソース構成情報８６０に含まれる情報）を得る。

尚、リソース・性能特性を示す関数は、具体ワークフロー８４０を構成する具体コンポーネントのそれぞれのリソース・性能特性を示す関数に基づいて、生成される。
その非機能要件は、導出するワークフローが充足すべき非機能要件である。

ここで、具体ワークフロー８４０は、具体コンポーネントを直列あるいは並列に接続したものである。そして、接続された複数の具体コンポーネントを、１つのコンポーネントと見なすことができる。接続された結果である、その１つのコンポーネントのリソース・性能特性を示す関数は、接続される具体コンポーネントのリソース・性能特性を示す関数を使用して合成され得る。その合成を再帰的に繰り返すことで、具体ワークフロー８４０を、単一コンポーネントと見なすことができ、具体ワークフロー８４０のリソース・性能特性を示す単一の関数を得ることができる。

また、リソース割当部１３０は、リソース構成情報８６０と、リソースリスト１５１とに基づいて、リソース総量を制約とする最適化計算により、所望の情報システムを形成するためのリソース割り当てを得る。即ち、リソース割当部１３０は、リソース割り当てを変量とし、リソース総量を制約とし、具体ワークフロー８４０のリソース・性能特性関数を目的関数とする最適化計算を行う。

ここで、リソース構成情報８６０は、具体ワークフロー８４０を構成する具体コンポーネントに割り当てるリソースの総量を示す情報である。リソースリスト１５１は、リソースの非機能的要件に関する情報である、例えばリソース価格や入手容易性情報などを含む。

その最適化計算において、最適化目的変数は、非機能要件の達成度や構築に使用するリソース及びソフトウェアの価格情報、入手容易性情報などからなる、多次元の変量である。また、最適化の制約は、具体ワークフロー８４０が達成すべき非機能要件を充足することである。従って、リソース割当部１３０は、その最適化計算を、多目的最適化問題として解く。

上述した本実施形態における第１の効果は、情報システムの自動構築において、ソフトウェア及びリソースの組合せを、より好適に選択することを可能にする点である。

その理由は、導出部１１０が抽象ワークフロー８３０に基づいて機能要件を満足する最適解集合８５０を導出し、性能サイジング部１２０及びリソース割当部１３０が非機能要件に基づいてシステム構成情報８９０を生成するからである。

上述した本実施形態における第２の効果は、情報システムの設計において人手が介在した場合の、最適構成の見落としを防止することが可能になる点である。

その理由は、第１の効果の理由と同じである。

上述した本実施形態における第３の効果は、リソースの選択にさきがけて、コンポーネントの選択を実行することが可能になる点である。

その理由は、導出部１１０が、同じ機能をもつ具体コンポーネントのそれぞれに対応する具体ワークフロー８４０のリソース・性能特性を、リソースのリソース量に対応する重みで重み付けし、比較するからである。

上述した本実施形態における第４の効果は、コンポーネントの選択とリソースの選択とを同時に実施することによる探索空間の組合せ爆発を回避することが可能になる点である。

その理由は、上述の第２の効果に示すように、リソースの選択にさきがけて、コンポーネントの選択を実行するからである。

＜＜＜第１の実施形態の変形例＞＞＞
図１４は、第１の実施形態の変形例である情報処理システム１００を示す図である。図１４に示すように、情報処理システム１００は、図１に示す情報処理システム１０１とコンポーネント性能情報リポジトリ１４０とリソースリポジトリ１５０とを含む。情報処理システム１０１と、コンポーネント性能情報リポジトリ１４０及びリソースリポジトリ１５０とは、ネットワーク７０９を介して接続されている。尚、情報処理システム１０１と、コンポーネント性能情報リポジトリ１４０及びリソースリポジトリ１５０とは、１台の図９に示すようなコンピュータ７００であってよいし、ネットワークを介することなく直接接続されてもよい。

＝＝＝コンポーネント性能情報リポジトリ１４０＝＝＝
コンポーネント性能情報リポジトリ１４０は、機能リスト１４１及び性能リスト１４２を記憶する。コンポーネント性能情報リポジトリ１４０は、図９に示す記憶装置７０３に記憶されてよい。また、コンポーネント性能情報リポジトリ１４０は、図９に示す入力部７０４を介して操作者より入力されてもよい。この場合、図９に示す出力部７０５に操作画面が表示されてもよい。

＝＝＝リソースリポジトリ１５０＝＝＝
リソースリポジトリ１５０は、リソースリスト１５１を記憶する。リソースリポジトリ１５０は、図９に示す記憶装置７０３に記憶されてよい。また、リソースリポジトリ１５０は、図９に示す入力部７０４を介して操作者より入力されてもよい。この場合、図９に示す出力部７０５に操作画面が表示されてもよい。

本変形例において、導出部１１０は、コンポーネント性能情報リポジトリ１４０の機能リスト１４１及び性能リスト１４２を参照する。性能サイジング部１２０は、コンポーネント性能情報リポジトリ１４０の性能リスト１４２を参照する。また、リソース割当部１３０は、リソースリポジトリ１５０のリソースリスト１５１を参照する。

上述した本実施形態における変形例の効果は、情報処理システム１００の構築を柔軟に実現することが可能になる点である。

その理由は、情報処理システム１０１と、コンポーネント性能情報リポジトリ１４０及びリソースリポジトリ１５０とを、ネットワーク７０９を介して接続するからである。

＜＜＜第２の実施形態＞＞＞
次に、第２の実施形態について図面を参照して詳細に説明する。以下、本実施形態の説明が不明確にならない範囲で、前述の説明と重複する内容については説明を省略する。

図１５は、本発明の第２の実施形態に係る情報処理システム２０１の構成を示すブロック図である。

図１５に示すように、本実施形態における情報処理システム２０１は、図１に示す第１の実施形態の情報処理システム１０１と比べて、機能コンポーネント割当部２６０をさらに含む点が異なる。

＝＝＝機能コンポーネント割当部２６０＝＝＝
機能コンポーネント割当部２６０は、機能要求８７０と接続リスト２７１とに基づいて、抽象ワークフロー８３０を生成する。

図１６は、機能要求８７０の一例を示す図である。図１６に示すように、機能要求８７０は、３つの機能要件ａ_０、ｂ_０及びｃ_０を含む。本実施形態において、機能要件ａ_０は、例えば入力データを保存する機能であり、機能要件ｂ_０は、例えば入力データの各単語の出現頻度を計算する機能であり、機能要件ｃ_０は、例えば出現頻度の大きい順に表示する機能である。図１６に示す例に係わらず、機能要求８７０が含む機能要件は、任意の数であってよい。

図１７は、接続リスト２７１の一例を示す図である。図１７に示すように、接続リスト２７１は、コンポーネントｆ_ｉの出力をコンポーネントｆ_ｊの入力とすることが可能であることを示す２つ組（ペア）＜ｆ_ｉ、ｆ_ｊ＞を含む。図１７は、抽象コンポーネントのａ及びｂと、ｂ及びｄと、ｄ及びｃとのそれぞれについての接続を示す。

機能コンポーネント割当部２６０は、機能要件ａ_０、ｂ_０及びｃ_０を抽象コンポーネントａ、ｂ及びｃとし、接続リスト２７１に基づいて、図２に示すような抽象ワークフロー８３０を生成する。換言すると、機能コンポーネント割当部２６０は、機能要求を示す機能要件の列＜ｆ_０、ｆ_１、・・・、ｆ_ｎ＞を入力とし、抽象ワークフローＧ_ｘ：＝＜ｆ_０ｘ、Ｆ_ｘ、Ｖ_ｘ＞を要素とする集合を出力する。

尚、情報処理システム２０１は、図１に示す情報処理システム１０１と同様に、図９に示すコンピュータ７００で実現されてよい。この場合、ＣＰＵ７０１は、その読み込んだプログラムに従って、またその読み込んだデータに基づいて、図１５に示す機能コンポーネント割当部２６０としても各種の処理を実行する。

また、記憶部７０２は、機能要求８７０及び接続リスト２７１を記憶してよい。記憶部７０２は、機能コンポーネント割当部２６０の一部としても含まれてよい。

さらに、記憶装置７０３は、機能要求８７０及び接続リスト２７１を記憶してよい。記憶装置７０３は、機能コンポーネント割当部２６０の一部としても含まれてよい。

次に本実施形態の動作について、図面を参照して詳細に説明する。

図１８は、本実施形態の動作を示すフローチャートである。機能コンポーネント割当部２６０は、機能要求８７０を取得したことを契機に、図１８に示す動作を開始する。

機能コンポーネント割当部２６０は、機能要求８７０に含まれる機能要件（ｆ_０乃至ｆ_ｎ）を全て充足する抽象ワークフローＧ_ｘ：＝＜ｆ_０ｘ、Ｆ_ｘ、Ｖ_ｘ＞を生成する（ステップＳ６２１）。

抽象ワークフロー８３０は、以下の条件を満足する、Ｇ_ｘである。第１の条件は、∀ｆ_ｘ∈＜ｆ_０、ｆ_１、・・・、ｆ_ｎ＞、ｆ_ｘ∈Ｆ_ｘ、かつ∀＜ｆ_ｉ、ｆ_ｊ＞∈Ｆ_ｘ、＜ｆ_ｉ、ｆ_ｊ＞∈Ｐであることである。第２の条件は、Ｆ_ｘの各要素は必ずＶ_ｘ中の辺により、相互に接続されていることである。第３の条件は、分断が発生しないグラフであることである。
このＧ_ｘの計算は組合せ最適化問題に帰属し、遺伝的アルゴリズムやタブー探索といったヒューリスティクスアルゴリズムを用いて実現することができる。

ステップＳ６０１からステップＳ６０５の動作は、図１０に示すステップＳ６０１からステップＳ６０５の動作と同じである。

即ち、機能コンポーネント割当部２６０によって生成された抽象ワークフロー８３０について、第１の実施形態で述べたように導出部１１０、性能サイジング部１２０及びリソース割当部１３０を適用することで、所望のシステム構成の情報を得ることができる。

上述した本実施形態における第１の効果は、第１の実施形態の効果に加え、機能要求８７０に基づいて、ソフトウェア及びリソースの組合せがより好適に選択された、情報システムの自動構築を可能にする点である。

その理由は、機能コンポーネント割当部２６０が、機能要求８７０と接続リスト２７１とに基づいて、抽象ワークフロー８３０を生成するからである。

上述した本実施形態における第２の効果は、機能要求８７０が不完全であっても不足する情報を補完して接続可能なワークフローを生成すること、を可能にする点である。

その理由は、機能コンポーネント割当部２６０が、接続リスト２７１に基づいて、抽象ワークフロー８３０を生成するからである。

＜＜＜第２の実施形態の変形例＞＞＞
図１９は、第２の実施形態の変形例である情報処理システム２００を示す図である。図１９に示すように、情報処理システム２００は、図１５に示す情報処理システム２０１とコンポーネント性能情報リポジトリ１４０とリソースリポジトリ１５０とコンポーネント接続情報リポジトリ２７０とを含む。情報処理システム２０１と、コンポーネント性能情報リポジトリ１４０、リソースリポジトリ１５０及びコンポーネント接続情報リポジトリ２７０とは、ネットワーク７０９を介して接続されている。尚、情報処理システム２０１と、コンポーネント性能情報リポジトリ１４０、リソースリポジトリ１５０及びコンポーネント接続情報リポジトリ２７０とは、１台の図９に示すようなコンピュータ７００であってよい。また、情報処理システム２０１と、コンポーネント性能情報リポジトリ１４０、リソースリポジトリ１５０及びコンポーネント接続情報リポジトリ２７０とは、ネットワークを介することなく直接接続されてもよい。

＝＝＝コンポーネント接続情報リポジトリ２７０＝＝＝
コンポーネント接続情報リポジトリ２７０は、接続リスト２７１を記憶する。コンポーネント接続情報リポジトリ２７０は、図９に示す記憶装置７０３に記憶されてよい。また、コンポーネント接続情報リポジトリ２７０は、図９に示す入力部７０４を介して操作者より入力されてもよい。この場合、図９に示す出力部７０５に操作画面が表示されてもよい。

上述した本実施形態における変形例の効果は、情報処理システム２００の構築を柔軟に実現することが可能になる点である。

その理由は、情報処理システム２０１と、コンポーネント性能情報リポジトリ１４０、リソースリポジトリ１５０及びコンポーネント接続情報リポジトリ２７０とを、ネットワーク７０９を介して接続するからである。

＜＜＜第３の実施形態＞＞＞
次に、本発明の第３の実施形態について図面を参照して詳細に説明する。以下、本実施形態の説明が不明確にならない範囲で、前述の説明と重複する内容については説明を省略する。

図２０は、本発明の第３の実施形態に係る情報処理システム３０１の構成を示すブロック図である。

図２０に示すように、本実施形態における情報処理システム３０１は、図１に示す第１の実施形態の情報処理システム１０１と比べて、導出部１１０に替えて導出部３８０を含む点が異なる。

＝＝＝導出部３８０＝＝＝
第１に、導出部３８０は、具体ワークフロー８４０のそれぞれに対応する、リソース量に対応する所定の重みで重み付けした、リソース・性能特性を、スカイライン法を用いて比較する。第２に、導出部３８０は、その比較した結果に基づいて、その具体ワークフロー８４０の集合である、スカイライン集合（最適解集合とも呼ばれる）８８０を導出する。

次に、具体ワークフロー８４０の集合の部分集合である、スカイライン集合８８０を導出する手順について説明する。

図２１は、一般的なスカイライン集合について説明する図である。図２１は、横軸に（ｘ、ｙ）の値（2次元）を、縦軸にｆ（ｘ、ｙ）の値を取る、２次元対１次元の３次元の示す図である。図２１を参照すると、複数の異なるプロット（ｘ_ｉ、ｙ_ｉ）が与えられたとき、ｘ及びｙに対してそれぞれ正の相関をもつ関数ｆ（ｘ、ｙ）を最小化する（ｘ、ｙ）を求めることを想定する。すると、関数を最小化しうる（ｘ、ｙ）はスカイライン（図２１中の点線）上にあることがわかる。このスカイライン上にあるプロットの集合が、スカイライン集合である。

従って、リソース・性能特性のそれぞれをプロットとして、そのスカイライン集合８８０を求めれば、リソース量を最小化する具体ワークフロー８４０は、そのスカイライン集合８８０に含まれるリソース・性能特性に対応する具体ワークフロー８４０である。結果的に、スカイライン集合８８０に含まれない具体ワークフロー８４０、即ちそのスカイライン上に位置しないリソース・性能特性に対応する具体ワークフロー８４０については、リソース・性能特性が適用された値を計算する必要はない。

導出部３８０は、スカイライン集合８８０を、各プロット（リソース・性能特性）について以下の手順を実行し求める。

初期状態において、全てのプロットが未処理のプロット集合に含まれ、スカイライン集合は空集合である。例えば、（未処理プロット集合、スカイライン集合）は、（｛ａ、ｂ、ｃ、ｄ、・・・｝、｛｝）という状態である。まず、未処理プロット集合から最初の任意のプロット(例えば、ａ)が取り出され、スカイライン集合に加えられる。即ち、最初に取り出されたプロットは、必ず最初（初期状態の次）のスカイライン集合に含まれる。例えば、（未処理プロット集合、スカイライン集合）は、（｛ｂ、ｃ、ｄ、・・・｝、｛ａ｝）という状態になる。

続けて、未処理プロット集合から次の任意のプロットが取り出される。そして、その取り出されたプロットが、スカイライン集合のプロットのいずれかを支配する関係にあれば、支配されたプロットがスカイライン集合から除去され、その取り出されたプロットがスカイライン集合に加えられる。

「プロットａがプロットｂを支配する」とは、プロットａの利得の全ての次元について、プロットａがプロットｂより優れているあるいは等しいことに加え、必ず１つ以上の次元においてプロットａがプロットｂより優れていることである。

導出部３８０は、全ての未処理プロット集合のプロットについて、上述の手順を実行し、完了した時点でのスカイライン集合８８０を解として得る。

図２２は、導出部３８０が、あるプロットについて、上述の手順を実行して、スカイライン集合８８０を生成する場合の動作を説明する図である。図２２の上段のグラフに示すように、点線のプロットが投入されたとき、その投入されたプロットは既存のスカイライン上のプロット１つを支配する。このため、導出部３８０は、図２２の下段のグラフに示すように、その支配される既存のプロットをスカイライン集合から除外し、その投入されたプロットをスカイライン集合に加える。このようにして、導出部３８０は、複数のプロットに対してスカイラインを導出するために、プロットを順次評価し、スカイライン集合の要素を入れ替えて、最終的なスカイライン集合８８０を導出する。

尚、スカイライン集合８８０を導出するためには、具体ワークフロー８４０のそれぞれに対応する利得関数が必要である。本実施形態における利得関数は、前述のリソース・性能特性を示す関数である「ｆ_ＧＤｘ（ｒ）」である。それらの関数間の比較、及び具体ワークフロー８４０のリソース・性能特性を計算する方法は、第１の実施形態で説明したとおりである。

上述した本実施形態における第１の効果は、第１の実施形態の効果に加えて、スカイライン法を使用することによる最適解集合を導出するための計算時間を削減することが可能になる点である。

その理由は、導出部３８０が、全要素間の比較が必要な最適化計算に替えて、スカイライン法により最適解集合であるスカイライン集合８８０を導出するからである。

上述した本実施形態における第２の効果は、ストリーム実行が可能になる点である。

その理由は、スカイライン集合８８０を導出するための計算では、スカイライン集合のサイズ（スカイライン集合の要素数）を変更しつつ、スカイライン集合へのプロットの入力に対し、その段階での解（スカイライン集合）を保持することが可能だからである。

＜＜＜第１の実施例＞＞＞
次に、本発明の実施例について図面を参照して詳細に説明する。以下、本実施例の説明が不明確にならない範囲で、前述の説明と重複する内容については説明を省略する。

本実施例は、図１９に示す情報処理システム２００における実施例である。

情報処理システム２００は、図１６に示す機能要求８７０を、与えられたとした。

また、第１の非機能要件は、スループットが毎秒１万件以上の処理の性能要求であり、第２の非機能要件は、５００万円以下のコスト要求であるとした。コンポーネント接続情報リポジトリ２７０は、図１７に示す接続リスト２７１を記憶しているものとした。

上述の前提に対して、機能コンポーネント割当部２６０は、組合せ最適化問題の解として、図２に示すような抽象ワークフロー８３０を生成した。例えば、機能コンポーネント割当部２６０は、その解法の一例として、以下のように部分解を使用して段階的に解いた。

Ｓｔｅｐ１： ＜ａ、ｂ＞、＜ｄ、ｃ＞
Ｓｔｅｐ２： ＜ａ、ｂ＞、＜ｂ、ｄ＞、＜ｄ、ｃ＞
Ｓｔｅｐ１では、機能コンポーネント割当部２６０は、機能要求８７０について、接続リスト２７１に基づいて、前方から＜ａ、ｂ＞を計画し、後方から＜ｄ、ｃ＞を計画した。この時点で機能要求８７０は充足されるが、分断がありワークフローを形成していないため、機能コンポーネント割当部２６０は、処理を継続した。

Ｓｔｅｐ２では、機能コンポーネント割当部２６０は、接続リスト２７１から、＜ｂ、ｄ＞の接続情報を取り出すことができるため、＜ａ、ｂ＞と＜ｄ、ｃ＞とを接続した。

以上により、機能コンポーネント割当部２６０は、図２に示す、Ｇ_ｘ：＝＜Ｆ_０ｘ、Ｆ_ｘ、Ｖ_ｘ＞で表現される抽象ワークフロー８３０を生成した。尚、この抽象ワークフロー８３０には、機能要求８７０には含まれていない「計算結果を保存する」機能が挿入された。これは、第２の実施形態の第２の効果である、「機能要求８７０が不完全であっても不足する情報を補完して接続可能なワークフローを生成すること」に対応する。

次に、導出部１１０は、得られた抽象ワークフロー８３０について、具体ワークフロー８４０を作成した。コンポーネント性能情報リポジトリ１４０は、図３に示す機能リスト１４１を記憶していたとする。

まず、導出部１１０は、抽象ワークフロー８３０に対して、機能リスト１４１の具体コンポーネントｃ_ｉをそれぞれあてはめ、図５に示す具体ワークフロー８４０の集合を作成した。

次に、導出部１１０は、この具体ワークフロー８４０の集合からリソース・性能特性を計算し、最適解集合８５０を導出した。

ここで、コンポーネント性能情報リポジトリ１４０には、図４に示す性能リスト１４２が格納されていた。但し、ｗ_ｉにおけるＣＰＵの性能は、システム上の累算値（コア数と最大周波数とを乗算した値）である。

導出部１１０は、上述の性能リスト１４２より、図２３に示すような、各具体コンポーネントｃ_ｉの値域に関する情報を取得した。

このとき、導出部１１０は、図５に示す具体ワークフロー８４０の１乃至４行目のそれぞれのリソース・性能特性Ｆを、以下の（１）乃至（４）のそれぞれのとおり計算した。

（１）｛＜Ａ、Ｃ＞、＜Ｃ、Ｅ＞、＜Ｅ、Ｄ＞｝
Ｆ＝Ｍｉｎ（ｃｐｕ＋ｍｅｍ／１００、ｃｐｕ＋ｍｅｍ／１００、８、ｃｐｕ＊１００）＝Ｍｉｎ（ｃｐｕ＋ｍｅｍ／１００、８、ｃｐｕ＊１００）
（２）｛＜Ａ、Ｃ＞、＜Ｃ、Ｆ＞、＜Ｆ、Ｄ＞｝
Ｆ＝Ｍｉｎ（ｃｐｕ＋ｍｅｍ／１００、ｃｐｕ＋ｍｅｍ／１００、０．２、ｃｐｕ＊１００）＝Ｍｉｎ（ｃｐｕ＋ｍｅｍ／１００、０．２、ｃｐｕ＊１００）＝０．２
（３）｛＜Ｂ、Ｃ＞、＜Ｃ、Ｅ＞、＜Ｅ、Ｄ＞｝
Ｆ＝Ｍｉｎ（ｃｐｕ＊１０、ｃｐｕ＋ｍｅｍ／１００、８、ｃｐｕ＊１００）＝Ｍｉｎ（ｃｐｕ＊１０、ｃｐｕ＋ｍｅｍ／１００、８）
（４）｛＜Ｂ、Ｃ＞、＜Ｃ、Ｆ＞、＜Ｆ、Ｄ＞｝
Ｆ＝Ｍｉｎ（ｃｐｕ＊１０、ｃｐｕ＋ｍｅｍ／１００、０．２、ｃｐｕ＊１００）＝Ｍｉｎ（ｃｐｕ＊１０、ｃｐｕ＋ｍｅｍ／１００、０．２）＝０．２。

この時の関数を比較すると、（２)及び（４）は、第１の非機能要求（スループットが毎秒１万件以上）を充足できなかった。

また、（１）と（３）は具体コンポーネントＡとＢの比較となり、頻繁に使用される設計パラメータの定義域から、Ａを使用する具体ワークフロー８４０の(１)のみが最適解集合８５０の要素となった。具体的には、導出部１１０は、頻繁に使用される設計パラメータの定義域の最大値及び最小値を、それぞれの（１）及び（３）のリソース・性能特性Ｆを示す関数に代入した。ここで、Ａは２０．８〜４３．２万件／秒に対して、Ｂは１〜３０万件／秒であった。従って、導出部１１０は、最小値・最大値ともに、Ｂを含む（３）よりもＡを含む（１）が優れていると判断した。

次に、リソースリポジトリ１５０は、図６に示すリソースリスト１５１を記憶していた。

さらに、本実施例におけるリソース組合せの最適化のヒューリスティクスとして、必ずＣＰＵ、メモリ、ディスクのそれぞれを少なくとも１つずつ選択する制約があるものとした。

また、性能の最大値は（１）の式を解析的に解くと８であったため、性能の値が８であり、かつコストを最小とする構成は最適解集合８５０の要素であった。この構成に支配されない構成を全て列挙すると下記構成が最適解集合８５０の要素であった。ここで、「性能の値が８であり、かつコストを最小とする構成」に支配されない構成は、「性能の値が８であり、かつコストを最小とする構成」が、以下のいずれの関係も満たさない。その関係は、（性能、コスト）が、（高い、小さい）、（同等、小さい）及び（高い、同等）のいずれかの関係である。

性能サイジング部１２０は、その支配されない構成を、図７に示すリソース構成情報８６０のように列挙した。

最後に、各構成について、リソース割当部１３０が、各具体コンポーネントにリソースの割り当てを実施した。上記構成のうち、構成｛ＣＰＵ３、ＭＥＭ１、ＤＩＳＫ１｝にリソース割当部１３０が、各具体コンポーネントにリソースの割り当てを実施する計算例を示す。

｛ＣＰＵ３、ＭＥＭ１、ＤＩＳＫ１｝の構成においては、複数のマシンに複数の具体コンポーネントを割り当てるということはできない。その結果として、所望のシステムは、単一のシステムとして構成された。

そこで、リソース割当部１３０は、構成｛ＣＰＵ３、ＭＥＭ１、ＤＩＳＫ１｝がもつリソースを分割し、各具体コンポーネントに割り当てを行った。リソース割当部１３０は、分割されたリソース量を示すＣＰＵ_Ａ、ＣＰＵ_Ｃ、ＣＰＵ_Ｅ、ＣＰＵ_Ｄ、ＭＥＭ_Ａ、ＭＥＭ_Ｃ、ＭＥＭ_Ｅ、ＭＥＭ_Ｄ、ＤＩＳＫ_Ａ、ＤＩＳＫ_Ｃ、ＤＩＳＫ_Ｅ、ＤＩＳＫ_Ｄの値を変量とし、具体ワークフロー８４０の性能を目的関数とした。
尚、各リソースの添え字（例えば「_Ａ」）は、そのリソースが対応する具体コンポーネント（例えば、具体コンポーネントＡ）を示す。

この場合、制約式は、例えば以下のとおりであった。ＣＰＵ_Ａ＋ＣＰＵ_Ｃ＋ＣＰＵ_Ｅ＋ＣＰＵ_Ｄ＝６（ＧＨｚ）。ＭＥＭ_Ａ＋ＭＥＭ_Ｃ＋ＭＥＭ_Ｅ＋ＭＥＭ_Ｄ＝２（ＧＢ）。ＤＩＳＫ_Ａ＋ＤＩＳＫ_Ｃ＋ＤＩＳＫ_Ｅ＋ＤＩＳＫ_Ｄ＝２（ＴＢ）。また、目的関数は、Ｍｉｎ（ＣＰＵ_Ａ＋ＭＥＭ_Ａ／１００、ＣＰＵ_Ｃ＋ＭＥＭ_Ｃ／１００、８、ＣＰＵ_Ｄ＊１００）であった。

これらの目的関数の最小値が具体ワークフロー８４０の性能となった。その一方で、ＣＰＵ_Ａ＋ＭＥＭ_Ａ／１００及びＣＰＵ_Ｃ＋ＭＥＭ_Ｃ／１００の両方が同時に８を超えることはできなかったため、これらがボトルネックであることがわかった。また、具体ワークフロー８４０の性能への貢献を考慮すると、ＣＰＵ_Ａ＋ＭＥＭ_Ａ／１００＝ＣＰＵ_Ｃ＋ＭＥＭ_Ｃ／１００が最適なヒューリスティクスとして想定することができた。

また、ＣＰＵ_Ｄ＊１００は、ｗｉの最小値として０．１（ＧＨｚ）としても、８（万件／秒）を超えた。そのため、具体コンポーネントＤに対するＣＰＵの割り当ては、最小の割り当てでよかった。同様に、具体コンポーネントＥに対するＣＰＵの割り当ても、最小値でよかった。一方で、ＤＩＳＫサイズの割り当ては性能に寄与しなかったため、リソース割当部１３０は、ＤＩＳＫを、ｗｉの比率に従い分配した。

その結果、リソース割当部１３０は、最適なリソース割り当てとして、以下の割り当てを算出した。ＣＰＵ_Ａ＝２．９ＧＨｚ、ＣＰＵ_Ｃ＝２．９ＧＨｚ、ＣＰＵ_Ｅ＝０．１ＧＨｚ、ＣＰＵ_Ｄ＝０．１ＧＨｚ。ＭＥＭ_Ａ＝０．４９ＧＢ、ＭＥＭ_Ｃ＝０．４９ＧＢ、ＭＥＭ_Ｅ＝１ＧＢ、ＭＥＭ_Ｄ＝０．０２ＧＢ。ＤＩＳＫ_Ａ＝１．９９７ＴＢ、ＤＩＳＫ_Ｃ＝０．００１ＴＢ、ＤＩＳＫ_Ｅ＝０．００１ＴＢ、ＤＩＳＫ_Ｄ＝０．００１ＴＢ。

リソース割当部１３０は、ほかの構成についても同様の計算を行った。構成｛ＣＰＵ３、ＭＥＭ１、ＤＩＳＫ１｝からは、ＣＰＵをひとつしかもたなかったため、ワークフロー上の全機能が同一マシンに割り当てられることがわかった。その結果、図８のシステム構成が得られた。

上述した本実施例における効果は、第２の実施形態と同様である。

以上の各実施形態で説明した各構成要素は、必ずしも個々に独立した存在である必要はない。例えば、複数個の任意のその構成要素が１個のモジュールとして実現されてよい。また、その構成要素の内の任意のひとつが複数のモジュールで実現されてもよい。また、その構成要素の内の任意のひとつがその構成要素の内の任意の他のひとつであってよい。また、その構成要素の内の任意のひとつの一部と、その構成要素の内の任意の他のひとつの一部とが重複してもよい。

以上説明した各実施形態における各構成要素及び各構成要素を実現するモジュールは、必要に応じ、可能であれば、リソース的に実現されてよい。また、各構成要素及び各構成要素を実現するモジュールは、コンピュータ及びプログラムで実現されてよい。また、各構成要素及び各構成要素を実現するモジュールは、リソース的なモジュールとコンピュータ及びプログラムとの混在により実現されてもよい。

そのプログラムは、例えば、磁気ディスクや半導体メモリなど、コンピュータが読み取り可能な非一時的記録媒体に記録され、コンピュータに提供される。そして、そのプログラムは、コンピュータの立ち上げ時などに、非一時的記録媒体からコンピュータに読み取られる。この読み取られたプログラムは、そのコンピュータの動作を制御することにより、そのコンピュータを前述した各実施形態における構成要素として機能させる。

また、以上説明した各実施形態では、複数の動作をフローチャートの形式で順番に記載してあるが、その記載の順番は複数の動作を実行する順番を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の順番は内容的に支障のない範囲で変更することができる。

さらに、以上説明した各実施形態では、複数の動作は個々に相違するタイミングで実行されることに限定されない。例えば、ある動作の実行中に他の動作が発生してよい。また、ある動作と他の動作との実行タイミングが部分的に乃至全部において重複してもよい。

さらに、以上説明した各実施形態では、ある動作が他の動作の契機になるように記載しているが、その記載はある動作と他の動作との関係を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の関係は内容的に支障のない範囲で変更することができる。また各構成要素の各動作の具体的な記載は、各構成要素の各動作を限定するものではない。このため、各構成要素の具体的な各動作は、各実施形態を実施する上で機能的、性能的、その他の特性に対して支障を来さない範囲内で変更されてよい。

上記の実施形態の一部または全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１） 機能を示す抽象コンポーネントを含む抽象ワークフローと、前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、前記具体コンポーネントへのリソース量割り当てに関する設計情報とに基づいて、前記具体コンポーネントを割り当てられた具体ワークフローの集合の内、リソース・性能特性が相対的に優れた前記具体ワークフローの集合である最適解集合を導出する導出部と、前記最適解集合と、前記設計情報と、リソースの性能に関する情報と、前記具体ワークフローが充足する第１の非機能要件とに基づいて、前記具体ワークフローに含まれる前記具体コンポーネントに割り当てる前記リソースを示すリソース構成情報を生成する性能サイジング部と、前記リソース構成情報と、前記具体ワークフローと、前記具体ワークフローが充足する第２の非機能要件と、前記第２の非機能要件に関するリソースの情報とに基づいて、優先的に使用する前記リソースの情報を含むシステム構成情報を生成し、出力するリソース割り当て部と、を含む情報処理システム。

（付記２）前記導出部は、前記抽象コンポーネントのいずれかひとつに対応する複数の前記具体コンポーネントのそれぞれを前記抽象ワークフローに割り当てた、前記具体ワークフローのそれぞれに対応するリソース・性能特性を、リソース量に対応する所定の重みで重み付けして比較し、前記リソース・性能特性を比較した結果に基づいて、前記最適解集合を導出することを特徴とする付記１記載の情報処理システム。

（付記３）前記導出部は、前記所定の重みで重み付けした前記リソース・性能特性を、スカイライン法を用いて比較し、前記スカイライン法を用いて比較した結果に基づいて、前記最適解集合を導出することを特徴とする付記２記載の情報処理システム。

（付記４）前記性能サイジング部は、前記具体ワークフローが充足する非機能要件を制約及び最適化目標のいずれかひとつとする、探索的な最適化及び解析的な最適化のいずれかひとつを実行することによって、前記具体コンポーネントに割り当てる前記リソースを決定することを特徴とする付記１乃至３のいずれかひとつに記載の情報処理システム。

（付記５）前記性能サイジング部は、局所探索法、焼きなまし法及び遺伝的アルゴリズムを任意に用いた最適化計算の結果に基づいて、前記非機能要件を充足する、前記リソースの候補を選定することを特徴とする付記４記載の情報処理システム。

（付記６）機能要求の正規化されたゴールモデル表現を入力とし、前記抽象コンポーネントの機能カテゴリの区分と、前記区分において充足される機能がオントロジーを使用して正規化された表現と、前記区分間の接続関係とに基づいて、前記抽象ワークフローを生成する、機能コンポーネント割り当て部をさらに含む、ことを特徴とする付記１乃至５のいずれかひとつに記載の情報処理システム。

（付記７）前記抽象コンポーネントの機能カテゴリの区分と、前記区分において充足される機能がオントロジーを使用して正規化された表現と、を含む前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、前記区分間の接続関係を示す情報と、前記設計情報と、を記憶するコンポーネント情報記憶部と、前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、前記区分間の接続関係を示す情報と、前記設計情報と、を入力する部、とをさらに含むことを特徴とする付記６記載の情報処理システム。

（付記８）前記リソースの性能に関する情報を記憶するリソース情報記憶部と、前記リソースの性能に関する情報を入力する部、とをさらに含むことを特徴とする付記１乃至７のいずれかひとつに記載の情報処理システム。

（付記９）前記システム構成情報は、前記具体コンポーネントに前記リソースが割り当てられた前記具体ワークフロー、及び同一の前記リソースに割り当てられた前記具体コンポーネントの情報を任意に含むことを特徴とする付記１乃至８のいずれかひとつに記載の情報処理システム。

（付記１０）機能を示す抽象コンポーネントを含む抽象ワークフローと、前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、前記具体コンポーネントへのリソース量割り当てに関する設計情報とに基づいて、前記具体コンポーネントを割り当てられた具体ワークフローの集合の内、リソース・性能特性が相対的に優れた、具体ワークフローの集合である最適解集合を導出し、前記最適解集合と、前記設計情報と、リソースの性能に関する情報と、前記具体ワークフローが充足する第１の非機能要件とに基づいて、前記具体ワークフローに含まれる前記具体コンポーネントに割り当てる前記リソースを示すリソース構成情報を生成し、前記リソース構成情報と、前記具体ワークフローと、前記具体ワークフローが充足する第２の非機能要件と、前記第２の非機能要件に関するリソースの情報とに基づいて、優先的に使用する前記リソースの情報を含むシステム構成情報を生成し、出力するシステム設計方法。

（付記１１）機能を示す抽象コンポーネントを含む抽象ワークフローと、前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、前記具体コンポーネントへのリソース量割り当てに関する設計情報とに基づいて、前記具体コンポーネントを割り当てられた具体ワークフローの集合の内、リソース・性能特性が相対的に優れた、具体ワークフローの集合である最適解集合を導出し、前記最適解集合と、前記設計情報と、リソースの性能に関する情報と、前記具体ワークフローが充足する第１の非機能要件とに基づいて、前記具体ワークフローに含まれる前記具体コンポーネントに割り当てる前記リソースを示すリソース構成情報を生成し、前記リソース構成情報と、前記具体ワークフローと、前記具体ワークフローが充足する第２の非機能要件と、前記第２の非機能要件に関するリソースの情報とに基づいて、優先的に使用する前記リソースの情報を含むシステム構成情報を生成し、出力する処理をコンピュータに実行させる
プログラム。

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

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

１００ 情報処理システム
１０１ 情報処理システム
１１０ 導出部
１２０ 性能サイジング部
１３０ リソース割当部
１４０ コンポーネント性能情報リポジトリ
１４１ 機能リスト
１４２ 性能リスト
１５０ リソースリポジトリ
１５１ リソースリスト
２００ 情報処理システム
２０１ 情報処理システム
２６０ 機能コンポーネント割当部
２７０ コンポーネント接続情報リポジトリ
２７１ 接続リスト
３０１ 情報処理システム
３８０ 導出部
４０１ 関数
４０２ 関数
４０３ 関数
４１１ 関数
４１２ 関数
４１３ 関数
７００ コンピュータ
７０１ ＣＰＵ
７０２ 記憶部
７０３ 記憶装置
７０４ 入力部
７０５ 出力部
７０６ 通信部
７０７ 記録媒体
７０９ ネットワーク
８３０ 抽象ワークフロー
８４０ 具体ワークフロー
８５０ 最適解集合
８６０ リソース構成情報
８７０ 機能要求
８８０ スカイライン集合
８９０ システム構成情報

Claims (10)

1. 機能を示す抽象コンポーネントを含む抽象ワークフローと、前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、前記具体コンポーネントへのリソース量割り当てに関する設計情報とに基づいて、前記具体コンポーネントを割り当てられた具体ワークフローの集合の内、リソース・性能特性が相対的に優れた前記具体ワークフローの集合である最適解集合を導出する導出手段と、
   前記最適解集合と、前記設計情報と、リソースの性能に関する情報と、前記具体ワークフローが充足する第１の非機能要件とに基づいて、前記具体ワークフローに含まれる前記具体コンポーネントに割り当てる前記リソースを示すリソース構成情報を生成する性能サイジング手段と、
   前記リソース構成情報と、前記具体ワークフローと、前記具体ワークフローが充足する第２の非機能要件と、前記第２の非機能要件に関するリソースの情報とに基づいて、優先的に使用する前記リソースの情報を含むシステム構成情報を生成し、出力するリソース割り当て手段と、を含む
   情報処理システム。
2. 前記導出手段は、前記抽象コンポーネントのいずれかひとつに対応する複数の前記具体コンポーネントのそれぞれを前記抽象ワークフローに割り当てた、前記具体ワークフローのそれぞれに対応するリソース・性能特性を、リソース量に対応する所定の重みで重み付けして比較し、前記リソース・性能特性を比較した結果に基づいて、前記最適解集合を導出する
   ことを特徴とする請求項１記載の情報処理システム。
3. 前記導出手段は、前記所定の重みで重み付けした前記リソース・性能特性を、スカイライン法を用いて比較し、前記スカイライン法を用いて比較した結果に基づいて、前記最適解集合を導出する
   ことを特徴とする請求項２記載の情報処理システム。
4. 前記性能サイジング手段は、前記具体ワークフローが充足する非機能要件を制約及び最適化目標のいずれかひとつとする、探索的な最適化及び解析的な最適化のいずれかひとつを実行することによって、前記具体コンポーネントに割り当てる前記リソースを決定する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 機能要求の正規化されたゴールモデル表現を入力とし、前記抽象コンポーネントの機能カテゴリの区分と、前記区分において充足される機能がオントロジーを使用して正規化された表現と、前記区分間の接続関係とに基づいて、前記抽象ワークフローを生成する、機能コンポーネント割り当て手段をさらに含む、
   ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理システム。
6. 前記抽象コンポーネントの機能カテゴリの区分と、前記区分において充足される機能がオントロジーを使用して正規化された表現と、を含む前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、
   前記区分間の接続関係を示す情報と、
   前記設計情報と、を記憶するコンポーネント情報記憶手段と、
   前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、
   前記区分間の接続関係を示す情報と、
   前記設計情報と、を任意に入力する手段と、をさらに含む
   ことを特徴とする請求項５記載の情報処理システム。
7. 前記リソースの性能に関する情報を記憶するリソース情報記憶手段と、
   前記リソースの性能に関する情報を入力する手段と、をさらに含む
   ことを特徴とする請求項１乃至６のいずれか１項に記載の情報処理システム。
8. 前記システム構成情報は、前記具体コンポーネントに前記リソースが割り当てられた前記具体ワークフロー、及び同一の前記リソースに割り当てられた前記具体コンポーネントの情報を任意に含む
   ことを特徴とする請求項１乃至７のいずれか１項に記載の情報処理システム。
9. 機能を示す抽象コンポーネントを含む抽象ワークフローと、前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、前記具体コンポーネントへのリソース量割り当てに関する設計情報とに基づいて、前記具体コンポーネントを割り当てられた具体ワークフローの集合の内、リソース・性能特性が相対的に優れた、具体ワークフローの集合である最適解集合を導出し、
   前記最適解集合と、前記設計情報と、リソースの性能に関する情報と、前記具体ワークフローが充足する第１の非機能要件とに基づいて、前記具体ワークフローに含まれる前記具体コンポーネントに割り当てる前記リソースを示すリソース構成情報を生成し、
   前記リソース構成情報と、前記具体ワークフローと、前記具体ワークフローが充足する第２の非機能要件と、前記第２の非機能要件に関するリソースの情報とに基づいて、優先的に使用する前記リソースの情報を含むシステム構成情報を生成し、出力する
   システム設計方法。
10. 機能を示す抽象コンポーネントを含む抽象ワークフローと、前記抽象コンポーネントに対応する具体コンポーネントを示す情報と、前記具体コンポーネントへのリソース量割り当てに関する設計情報とに基づいて、前記具体コンポーネントを割り当てられた具体ワークフローの集合の内、リソース・性能特性が相対的に優れた、具体ワークフローの集合である最適解集合を導出する処理と、
    前記最適解集合と、前記設計情報と、リソースの性能に関する情報と、前記具体ワークフローが充足する第１の非機能要件とに基づいて、前記具体ワークフローに含まれる前記具体コンポーネントに割り当てる前記リソースを示すリソース構成情報を生成する処理と、
    前記リソース構成情報と、前記具体ワークフローと、前記具体ワークフローが充足する第２の非機能要件と、前記第２の非機能要件に関するリソースの情報とに基づいて、優先的に使用する前記リソースの情報を含むシステム構成情報を生成する処理と、
    前記システム構成情報を出力する処理と、をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な
    非一時的記録媒体。

Images