特許 5988173 アプリケーションアーキテクチャ設計方法、アプリケーションアーキテクチャ設計システム、およびプログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】5988173

(24)【登録日】2016年8月19日

(45)【発行日】2016年9月7日

(54)【発明の名称】アプリケーションアーキテクチャ設計方法、アプリケーションアーキテクチャ設計システム、およびプログラム

(51)【国際特許分類】

   G06F 9/44 20060101AFI20160825BHJP

【ＦＩ】

   G06F9/06 620A

【請求項の数】21

【全頁数】23

(21)【出願番号】特願2013-512419(P2013-512419)

(86)(22)【出願日】2012年4月19日

(86)【国際出願番号】JP2012061154

(87)【国際公開番号】WO2012147825

(87)【国際公開日】20121101

【審査請求日】2015年3月4日

(31)【優先権主張番号】特願2011-101106(P2011-101106)

(32)【優先日】2011年4月28日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(73)【特許権者】

【識別番号】305027401

【氏名又は名称】公立大学法人首都大学東京

(73)【特許権者】

【識別番号】504137912

【氏名又は名称】国立大学法人 東京大学

(74)【代理人】

【識別番号】100077838

【弁理士】

【氏名又は名称】池田 憲保

(74)【代理人】

【識別番号】100129023

【弁理士】

【氏名又は名称】佐々木 敬

(72)【発明者】

【氏名】細野 繁

(72)【発明者】

【氏名】木見田 康治

(72)【発明者】

【氏名】赤坂 文弥

(72)【発明者】

【氏名】原 辰徳

(72)【発明者】

【氏名】下村 芳樹

(72)【発明者】

【氏名】新井 民夫

【審査官】 石川 亮

(56)【参考文献】

【文献】 国際公開第２００５／０２９３８２（ＷＯ，Ａ２）

【文献】 特開２００８−１４０２４０（ＪＰ，Ａ）

【文献】 Shigeru Hosono, He Huang, Tatsunori Hara, Yoshiki Shimomura, Tamio Arai，A Lifetime Supporting Framework for Cloud Applications，Proceedings of 2010 IEEE 3rd International Conference on Cloud Computing，IEEE，２０１０年 ７月 ５日，pp.362-369

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４４

Ｇ０６Ｆ ９／４６

Ｇ０６Ｆ ９／５０

Ｇ０６Ｑ ５０／００

(57)【特許請求の範囲】

【請求項1】

アプリケーションプログラムを形成する機能を動作させるモジュール群、前記モジュール群を動作させる仮想マシン群、前記仮想マシン群を動作させる物理マシン群に関しての設計事項となる依存関係および設計アスペクトに関する情報を入力する段階と、
前記入力された依存関係および設計アスペクトに関する情報についてＤＳＭ形式の設計マトリクスの入れ替えを行なうことによって、ＤＳＭ形式上で前記モジュール群、仮想マシン群、及び物理マシン群に対するそれぞれの割当を段階的に再配置処理してアーキテクチャの適正化処理を図る段階と
を含み、
アーキテクチャの設計解を出力する
ことを特徴とする情報処理装置によるアプリケーションアーキテクチャ設計方法。

【請求項2】

複数の仮想マシン上で分散して動作するアプリケーションプログラムを構成する機能群と前記機能群の各機能間の依存関係を示す情報を入力する依存関係入力段階と、
アプリケーションの提供にかかる各設計要件とその内容を示す情報を入力する設計アスペクト入力段階と、
入力された依存関係と設計アスペクトの情報を受けて保管すると共に、各再配置を終えて生成された設計マトリクス情報を記憶する設計情報保管段階と、
前記依存関係と設計アスペクトの情報を入力項目である設計マトリクス情報として、各モジュールに割当てる機能と割当てられるモジュールの対応関係が反映された機能−モジュールを示す設計マトリクスをＤＳＭ形式に表示すると共に、当該設計マトリクスの再配置の入力を受けつけて設計マトリクス情報に反映処理させて出力する機能モジュール設計マトリクス表示段階と、
前記設計マトリクス情報を入力として、モジュールが個々に動作する仮想マシンに対する各モジュールのモジュール配置を示す設計マトリクスをＤＳＭ形式に表示すると共に、当該設計マトリクスの再配置の入力を受けつけて設計マトリクス情報に反映処理させて出力するモジュール配置設計マトリクス表示段階と、
前記設計マトリクス情報を入力として、仮想マシンが個々に動作する物理マシンに対する各仮想マシンの割振りとなるリソース割当を示す設計マトリクスをＤＳＭ形式に表示すると共に、当該設計マトリクスの再配置の入力を受けつけて設計マトリクス情報に反映処理させて出力するリソース割当設計マトリクス表示段階と、
を有する
ことを特徴とする情報処理装置によるアプリケーションアーキテクチャ設計方法。

【請求項3】

前記設計情報保管段階は、
前記機能モジュール設計マトリクス表示段階を終えて生成された機能モジュール設計マトリクス情報が、モジュール配置設計マトリクスを表示する入力情報となり、
前記モジュール配置設計マトリクス表示段階を終えて生成されたモジュール配置設計マトリクス情報が、リソース割当設計マトリクスを表示する入力情報となり、
前記３つの設計マトリクスを、順次段階的に連携させる
ことを特徴とする請求項２記載のアプリケーションアーキテクチャ設計方法。

【請求項4】

更に、ＤＳＭ形式で表示された各設計マトリクスの行／列の再配置に基づき設計開発の適正解を自動的に算定する設計マトリクス配置計算段階を有することを特徴とする請求項２または３に記載のアプリケーションアーキテクチャ設計方法。

【請求項5】

前記設計アスペクトに対して個々の項目ごとに重要度を示す情報を与え、前記ＤＳＭ形式のマトリクス上で他の項目との比較を示すように重要度に基づく適正化を可視化することを特徴とする請求項１ないし４の何れか一項に記載のアプリケーションアーキテクチャ設計方法。

【請求項6】

各段階で行われるＤＳＭ形式の設計マトリクスの表示について、再配置前と再配置後の設計マトリクスについて、対比可能にインタフェース画面を出力することを特徴とする請求項１ないし５の何れか一項に記載のアプリケーションアーキテクチャ設計方法。

【請求項7】

各段階で行われたＤＳＭ形式の設計マトリクスでの再配置を受けて、再配置後の設計マトリクスに基づいたモデル図を示したインタフェース画面を出力することを特徴とする請求項１ないし６の何れか一項に記載のアプリケーションアーキテクチャ設計方法。

【請求項8】

アプリケーションプログラムを形成する機能を動作させるモジュール群、前記モジュール群を動作させる仮想マシン群、前記仮想マシン群を動作させる物理マシン群に関しての設計事項となる依存関係および設計アスペクトに関する情報を入力する入力部と、
前記入力された依存関係および設計アスペクトに関する情報についてＤＳＭ形式のマトリクスの入れ替えを可能とすることによって、ＤＳＭ形式上で前記モジュール群、仮想マシン群、及び物理マシン群に対するそれぞれの割当を段階的に再配置してアーキテクチャの適正化処理を図ると共に結果を出力する設計マトリクス最適化部と
を含むことを特徴とするアプリケーションアーキテクチャ設計システム。

【請求項9】

複数の仮想マシン上で分散して動作するアプリケーションプログラムを構成する機能群と前記機能群の各機能間の依存関係を示す情報を入力する依存関係入力部と、
アプリケーションの提供にかかる各設計要件とその内容を示す情報を入力する設計アスペクト入力部と、
入力された依存関係と設計アスペクトの情報を受けて保管すると共に、各再配置を終えて生成された設計マトリクス情報を記憶する設計情報保管部と、
前記依存関係と設計アスペクトの情報を入力項目である設計マトリクス情報として、各モジュールに割当てる機能と割当てられるモジュールの対応関係が反映された機能−モジュールを示す設計マトリクスをＤＳＭ形式に表示すると共に、当該設計マトリクスの再配置の入力を受けつけて設計マトリクス情報に反映処理させて出力する機能モジュール設計マトリクス表示部と、
前記設計マトリクス情報を入力として、モジュールが個々に動作する仮想マシンに対する各モジュールのモジュール配置を示す設計マトリクスをＤＳＭ形式に表示すると共に、当該設計マトリクスの再配置の入力を受けつけて設計マトリクス情報に反映処理させて出力するモジュール配置設計マトリクス表示部と、
前記設計マトリクス情報を入力として、仮想マシンが個々に動作する物理マシンに対する各仮想マシンの割振りとなるリソース割当を示す設計マトリクスをＤＳＭ形式に表示すると共に、当該設計マトリクスの再配置の入力を受けつけて設計マトリクス情報に反映処理させて出力するリソース割当設計マトリクス表示部と、
を有することを特徴とするアプリケーションアーキテクチャ設計システム。

【請求項10】

前記設計情報保管部に保管される情報は、
前記機能モジュール設計マトリクス表示部による機能モジュール設計マトリクス表示段階を終えて生成された機能モジュール設計マトリクス情報を、モジュール配置設計マトリクスを表示する入力情報として、
前記モジュール配置設計マトリクス表示部によるモジュール配置設計マトリクス表示段階を終えて生成されたモジュール配置設計マトリクス情報を、リソース割当設計マトリクスを表示する入力情報として、
前記３つの設計マトリクスを、順次段階的に連携させるように使用される
ことを特徴とする請求項９記載のアプリケーションアーキテクチャ設計システム。

【請求項11】

ＤＳＭ形式で表示された各設計マトリクスの行／列の再配置を行い設計開発の適正解を自動的に算定する設計マトリクス配置計算部を有することを特徴とする請求項９または１０に記載のアプリケーションアーキテクチャ設計システム。

【請求項12】

前記設計アスペクトに対して個々の項目ごとの重要度を示す情報を受けて、前記ＤＳＭ形式のマトリクス上で他の項目との比較を示すように重要度に基づく適正化を可視化することを特徴とする請求項８ないし１１の何れか一項に記載のアプリケーションアーキテクチャ設計システム。

【請求項13】

各段階で行われるＤＳＭ形式の設計マトリクスの表示について、再配置前と再配置後の設計マトリクスを、対比可能にインタフェース画面を出力することを特徴とする請求項８ないし１２の何れか一項に記載のアプリケーションアーキテクチャ設計システム。

【請求項14】

各段階で行われたＤＳＭ形式の設計マトリクスでの再配置を受けて、再配置後の設計マトリクスに基づいたモデル図を示したインタフェース画面を出力することを特徴とする請求項８ないし１３の何れか一項に記載のアプリケーションアーキテクチャ設計システム。

【請求項15】

情報処理装置の制御部を、
アプリケーションプログラムを形成する機能を動作させるモジュール群、前記モジュール群を動作させる仮想マシン群、前記仮想マシン群を動作させる物理マシン群に関しての設計事項となる依存関係および設計アスペクトに関する情報を入力する入力手段と、
前記入力された依存関係および設計アスペクトに関する情報についてＤＳＭ形式のマトリクスの入れ替えを可能とすることによって、ＤＳＭ形式上で前記モジュール群、仮想マシン群、及び物理マシン群に対するそれぞれの割当を段階的に再配置してアーキテクチャの適正化処理を図ると共に結果を出力する設計マトリクス最適化手段
として動作させることを特徴とするプログラム。

【請求項16】

情報処理装置の制御部を、
複数の仮想マシン上で分散して動作するアプリケーションプログラムを構成する機能群と前記機能群の各機能間の依存関係を示す情報を入力する依存関係入力部と、
アプリケーションの提供にかかる各設計要件とその内容を示す情報を入力する設計アスペクト入力部と、
入力された依存関係と設計アスペクトの情報を受けて保管すると共に、各再配置を終えて生成された設計マトリクス情報を記憶する設計情報保管部と、
前記依存関係と設計アスペクトの情報を入力項目である設計マトリクス情報として、各モジュールに割当てる機能と割当てられるモジュールの対応関係が反映された機能−モジュールを示す設計マトリクスをＤＳＭ形式に表示すると共に、当該設計マトリクスの再配置の入力を受けつけて設計マトリクス情報に反映処理させて出力する機能モジュール設計マトリクス表示部と、
前記設計マトリクス情報を入力として、モジュールが個々に動作する仮想マシンに対する各モジュールのモジュール配置を示す設計マトリクスをＤＳＭ形式に表示すると共に、当該設計マトリクスの再配置の入力を受けつけて設計マトリクス情報に反映処理させて出力するモジュール配置設計マトリクス表示部と、
前記設計マトリクス情報を入力として、仮想マシンが個々に動作する物理マシンに対する各仮想マシンの割振りとなるリソース割当を示す設計マトリクスをＤＳＭ形式に表示すると共に、当該設計マトリクスの再配置の入力を受けつけて設計マトリクス情報に反映処理させて出力するリソース割当設計マトリクス表示部と、
して動作させることを特徴とするプログラム。

【請求項17】

前記設計情報保管部に保管される情報を、
前記機能モジュール設計マトリクス表示部による機能モジュール設計マトリクス表示段階を終えて生成された機能モジュール設計マトリクス情報を、モジュール配置設計マトリクスを表示する入力情報として、
前記モジュール配置設計マトリクス表示部によるモジュール配置設計マトリクス表示段階を終えて生成されたモジュール配置設計マトリクス情報を、リソース割当設計マトリクスを表示する入力情報として、
前記３つの設計マトリクスを、順次段階的に連携させるように前記制御部を動作させる
ことを特徴とする請求項１６記載のプログラム。

【請求項18】

前記制御部を、ＤＳＭ形式で表示された各設計マトリクスの行／列の再配置を行い設計開発の適正解を自動的に算定する設計マトリクス配置計算部として動作させることを特徴とする請求項１６または１７に記載のプログラム。

【請求項19】

前記設計アスペクトに対して個々の項目ごとの重要度を示す情報を受けて、前記ＤＳＭ形式のマトリクス上で他の項目との比較を示すように重要度に基づく適正化を可視化させることを特徴とする請求項１５ないし１８の何れか一項に記載のプログラム。

【請求項20】

各段階で行われるＤＳＭ形式の設計マトリクスの表示について、再配置前と再配置後の設計マトリクスを、対比可能にインタフェース画面を出力させることを特徴とする請求項１５ないし１９の何れか一項に記載のプログラム。

【請求項21】

各段階で行われたＤＳＭ形式の設計マトリクスでの再配置を受けて、再配置後の設計マトリクスに基づいたモデル図を示したインタフェース画面を出力させることを特徴とする請求項１５ないし２０の何れか一項に記載のプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、アプリケーションアーキテクチャの設計方法、設計装置、および記録媒体に関し、特に仮想化環境やクラウド環境に適したアプリケーションアーキテクチャの設計方法、設計装置、およびプログラムに関する。

【背景技術】

【0002】

Ｗｅｂアプリケーションの設計・開発では、Ｗｅｂ三層モデルといった確立された標準的なアーキテクチャが用いられている。Ｗｅｂ三層モデルは、アプリケーションのリクエストを受けるＷｅｂ画面（インタフェース）、アプリケーションのリクエストを処理するモジュール、処理した結果などを読み書きするデータベースに分けられる。この分け方を用いた設計方法が一般的なＷｅｂアプリケーションの設計・開発に用いられている。
また仮想化環境やクラウド環境などで不特定のマシン上で分散して動作するアプリケーションプログラムの利用が進みつつある。このような環境下で使用されることに特化したアプリケーションプログラムも設計開発が行なわれている。
クラウドコンピューティングは、アプリケーションソフトウェアの機能や、アプリケーションを実行するミドルウェアの機能、オペレーティングシステムやネットワーク、ストレージなどのインフラストラクチャの機能を利用して、ユーザに所定の機能を提供するアプリケーションを構築する。
クラウドコンピューティングを実現する主要な要素技術は、サーバやストレージなどの仮想化技術である。この仮想化技術では、ＣＰＵやハードディスクなどの物理的なハードウェア資源（物理マシン）の区分と、仮想的に割り当てられるＣＰＵコア数やストレージ量などの論理的なハードウェア機能（仮想マシン）の区分とが分離される。
昨今のＷｅｂアプリケーション設計・開発では、上述のハードウェアの物理的・論理的な区別を一体として扱ってきた。一方、クラウド環境などで使用されるアプリケーション開発では、分離された各部分がアプリケーション構成を作るための設計インタフェースとして切り出される。このため、仮想化技術を考慮したアプリケーション開発は、ハードウェアに区別を設けることなく設計されているＷｅｂアプリケーションに比べて設計インタフェースの数が大きく増える傾向にある。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特許第４１０４６２２号

【特許文献2】特許第４３１９００７号

【非特許文献】

【0004】

【非特許文献1】Ａｌｂｅｒｔ Ａｌｂｅｒｓ，Ｋｏｒｋｉａｔ Ｓｅｄｃｈａｉｃｈａｒｎ，Ｃｈｒｉｓｔｉａｎ Ｓａｕｔｅｒ，Ｗｏｌｆｇａｎｇ Ｂｕｒｇｅｒ 著「Ａ Ｍｅｔｈｏｄ ｔｏ Ｄｅｆｉｎｅ Ａ Ｐｒｏｄｕｃｔ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅａｒｌｙ Ｉｎ Ｐｒｏｄｕｃｔ Ｄｅｖｅｌｏｐｍｅｎｔ Ｕｓｉｎｇ Ａ Ｃｏｎｔａｃｔ ａｎｄ Ｃｈａｎｎｅｌ Ｍｏｄｅｌ」 ＩＣＥＤ’０９ ２４−２７ＡＵＧＵＳＴ ２００９，ＳＴＡＮＦＯＲＤ ＵＮＩＶＥＲＳＩＴＹ，Ｐ２４１−Ｐ２５２

【発明の概要】

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

【0005】

浸透しつつあるクラウドコンピューティング環境などにおいては、既存の確立された標準的なアーキテクチャを採用したアプリケーション構成の決定方法では、性能や保守などの考慮が不十分となりやすく、最適なアプリケーション設計が困難となっている。
既存のアプリケーション設計では、性能や保守性を高めるために、基本的な設計指針として、複数の設計インタフェースのモジュール化を行っている。
一方、仮想化・クラウド環境下では、ハードウェアとソフトウェアが分離独立されて運用されるため、両者を同時に考慮したアプリケーションアーキテクチャの設計が望まれる。
しかし、従前の設計方法では、設計インタフェースを含めて、アプリケーションを適切にモジュール化することが困難である課題がある。
なお、本明細書で記載するアプリケーションアーキテクチャとは、データの追加・更新などの処理の効率性や安全性などを考慮したソフトウェアおよびハードウェア構成である。また、アーキテクチャ設計とは、その構成を定義し、アプリケーションを構成するデータの格納場所、データを処理するモジュールの構成やその実行場所などを設計することである。
クラウド環境で動作しているアプリケーションプログラム（クラウドアプリケーションプログラム）は、クラウド環境を提供するデータセンタ内に配備されたサーバ群やストレージ群の中から、仮想化された機能を必要に応じて呼び出して用いている。クラウドアプリケーション（サービス）は、多くの場合、アプリケーションを構成するモジュール群が複数の仮想マシンに分散配置されることやリモートのデータストアを利用することなどから、分散システムとなる。このため、クラウドアプリケーションプログラムは、分散システムに順応する必要がある。
しかし、このようなアプリケーションアーキテクチュアの設計方法では、仮想化された機能を適宜呼び出す際に、その機能を構築するモジュールがどの物理的なハードウェア資源上で動作しているかなどを、設計・開発時に十分に考慮できない。設計上の困難性を作り出す原因の一つを例示する。クラウドサービスでは、複数の機能間、或いは複数のアプリケーション間で同一の物理的なハードウェア資源を共有する。このことがサービスを提供のために期待される機能の性能設計を困難にしている。
そこで、発明者は、独自の考えに従い、公理的設計（Ａｘｉｏｍａｔｉｃ Ｄｅｓｉｇｎ）およびＤｆＸ（Ｄｅｇｉｇｎ ｆｏｒ Ｘ）の設計学の考え方で、このようなアプリケーションのアーキテクチャ設計方法の単純化を行なう。
公理的設計では、顧客要求、機能要求、設計パラメータ、プロセス変数の４つのドメインを定義する。そして、設計プロセスは、顧客要求：ＣＡ（Ｃｕｓｔｏｍｅｒ Ａｔｔｒｉｂｕｔｅ）→機能要求：ＦＲ（Ｆｕｎｃｔｉｏｎａｌ Ｒｅｑｕｉｒｅｍｅｎｔ）→設計パラメータ：ＤＰ（Ｄｅｓｉｇｎ Ｐａｒａｍｅｔｅｒ）→プロセス変数：ＰＶ（Ｐｒｏｃｅｓｓ Ｖａｒｉａｂｌｅ）という順に進める。また、ＤｆＸは、性能や安全性など複数の設計観点を同時に扱う設計方法である。
図１６は、これらの考え方を１つに統合したモデルである。このモデルをクラウド環境で動作させるアプリケーションの設計方法に導入する。すなわち、クラウド環境で動作させるアプリケーションの設計プロセスをＦＲ→ＤＰ１、ＤＰ１→ＤＰ２、ＤＰ２→ＰＶの３つの段階に単純化する。
前記の公理的設計では図１６のように二次元のマトリクスを用い、ＣＡの各要素とＦＲの各要素、ＦＲの各要素とＤＰの各要素、ＤＰの各要素とＰＶの各要素の関係を表記し、設計プロセスを形式的に表現することができる。
ところで、マトリクスを用いて複雑化なシステム内の構成要素間の関係を単純化して可視化を行ない適切な設計の意思決定を支援する一手法として、複雑化するシステム構築を容易にするＤＳＭ（Ｄｅｐｅｎｄｅｎｃｙ（Ｄｅｓｉｇｎ）Ｓｔｒｕｃｔｕｒｅ Ｍａｔｒｉｘ）がある。
ＤＳＭでは、製品を対象としたコンポーネントの機能分割や、人間系の組織を対象にしたチームの分割、情報の流れからアクティビティ分割、設計値のパラメータ関係からモジュールを分割することができる。ＤＳＭを用いる手法に関連する文献を例示すれば以下の文献が挙げられる。
非特許文献１には、製品を対象としたコンポーネントの機能分割が示されている。本方法は、ＤＳＭを用いて製品を構成する機能間の依存関係を表現し、ＤＳＭの各セル値の入れ替えによって、最適な機能群の分割方法を導出している。しかしながら、当該文献に記載された方法は、製品機能に限定している。そのため、この方法を設計プロセスを通じたアーキテクチャの設計評価に用いることは困難である。
また、特許文献１には、ＤＳＭを利用して製品開発プロセスにおける無駄をなくす方法が示されている。一般に製品設計において、機能要求から機能設計を行い、更に各機能のパラメータを設計するように、段階的に製品開発は進行する。本方法では、製品開発プロセスを課題設定しているものの、前述した製品開発プロセスのある時点において扱われる設計情報は対象としておらず、特定の時点における設計の最適化が困難である。また、本方式で示されているＱＦＤ（Ｑｕａｌｉｔｙ Ｆｕｎｃｔｉｏｎ Ｄｅｓｉｇｎ）とＤＳＭマトリクスは、行・列項目間の重み付けをつけている点に特長がある。しかし、機能従属の関係以外の観点で二項間の関係を評価することが困難であった。
また、特許文献２には、ＤＳＭを利用して、開発工期を短縮するために開発上のアクティビティを最適化する方法が示されている。本方法は、特許文献１と同様に、開発プロセスを課題設定している。しかし、ある時点において扱われる設計情報を対象としたものではないので、特定の時点におけるアーキテクチャ設計の最適化に用いることは困難であった。
仮想化・クラウド環境を対象としたアプリケーションの設計開発では、その論理的構成と物理的構成とを段階的に構築していくことが必要となる。しかし、上記文献に記載された技術を当てはめても仮想化を伴うアプリケーションアーキテクチャの設計を最適化することはできない。また、仮想化技術を使用するアーキテクチャ構造の設計にＤＳＭを利用すること、またその利用の仕方について、何れの文献にも記載されていない。
本発明は、前記の３段階に単純化した設計プロセスに沿って、仮想化環境やクラウド環境におけるアプリケーション設計において、アプリケーションアーキテクチャの良好な設計解を導出する方法を提供する。
また、本発明では、性能、保守性、安全性、可用性、移行性などの多種の設計観点を考慮した上でアプリケーションプログラムを構成するモジュール群を導出する方法を提供する。
また、本発明では、これらのモジュール群を実行環境へ良好に配備する構成（アーキテクチャ）を導出する方法を提供する。
また、本発明は、仮想化環境やクラウド環境におけるアプリケーション設計において、アプリケーションアーキテクチャの設計解を導出する装置およびプログラムを提供する。

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

【0006】

本発明に係るアプリケーションアーキテクチャ設計システムは、アプリケーションプログラムを形成する機能を動作させるモジュール群、前記モジュール群を動作させる仮想マシン群、前記仮想マシン群を動作させる物理マシン群に関しての設計事項となる依存関係および設計アスペクトに関する情報を入力する入力部と、前記入力された依存関係および設計アスペクトに関する情報についてＤＳＭ形式の設計マトリクスの入れ替えを可能とすることによって、ＤＳＭ形式上で前記モジュール群、仮想マシン群、及び物理マシン群に対するそれぞれの割当を段階的に再配置してアーキテクチャの適正化処理を図ると共に結果を出力する設計マトリクス最適化部とを含むことを特徴とする。
また、本発明に係る情報処理装置によるアプリケーションアーキテクチャ設計方法は、アプリケーションプログラムを形成する機能を動作させるモジュール群、前記モジュール群を動作させる仮想マシン群、前記仮想マシン群を動作させる物理マシン群に関しての設計事項となる依存関係および設計アスペクトに関する情報を入力する段階と、前記入力された依存関係および設計アスペクトに関する情報についてＤＳＭ形式の設計マトリクスの入れ替えを行なうことによって、ＤＳＭ形式上で前記モジュール群、仮想マシン群、及び物理マシン群に対するそれぞれの割当を段階的に再配置処理してアーキテクチャの適正化処理を図る段階とを含み、アーキテクチャの設計解を出力することを特徴とする。
また、本発明に係るプログラムは、情報処理装置の制御部を、アプリケーションプログラムを形成する機能を動作させるモジュール群、前記モジュール群を動作させる仮想マシン群、前記仮想マシン群を動作させる物理マシン群に関しての設計事項となる依存関係および設計アスペクトに関する情報を入力する入力手段と、前記入力された依存関係および設計アスペクトに関する情報についてＤＳＭ形式のマトリクスの入れ替えを可能とすることによって、ＤＳＭ形式上で前記モジュール群、仮想マシン群、及び物理マシン群に対するそれぞれの割当を段階的に再配置してアーキテクチャの適正化処理を図ると共に結果を出力する設計マトリクス最適化手段として動作させることを特徴とする。

【発明の効果】

【0007】

本発明によれば、仮想化環境やクラウド環境におけるアプリケーションアーキテクチャ設計において、良好なアプリケーションアーキテクチャの設計解を導出する方法を提供できる。
また、本発明によれば、性能、保守性、安全性、可用性、移行性などの多種の設計観点を考慮した上でアプリケーションプログラムを構成するモジュールを導出する方法を提供できる。すなわち、プログラム設計開発時に決定するソフトウェア機能のモジュール化が判断しやすくなる。
また、本発明によれば、これらのモジュール群を実行環境へ良好に配備できる構成（アーキテクチャ）を導出する方法を提供できる。すなわち、設計開発時に決定するアプリケーションの論理的・物理的配置場所が判断しやすくなる。
また、本発明によれば、仮想化環境やクラウド環境におけるアプリケーション設計において、アプリケーションアーキテクチャの設計解を導出する装置を提供できる。

【図面の簡単な説明】

【0008】

図１は、実施の一形態のアプリケーションアーキテクチャ設計装置の構成を示すブロック図である。
図２は、実施形態で用いる設計アスペクト情報の構成を例示する説明図である。
図３は、設計マトリクスの構成を例示する説明図である。
図４は、機能設計フェーズの処理を示すフローチャートである。
図５は、モジュール配置設計フェーズの処理を示すフローチャートである。
図６は、リソース配分設計フェーズの処理を示すフローチャートである。
図７は、例としてクラウドコンピューティング環境上で使用するために構築を行なうアプリケーションプログラムの構成を示すブロック図である。
図８は、設計アスペクト情報の一覧を例示する説明図である。
図９は、マトリクスの再配置処理の一例を示す説明図である。
図１０は、設計マトリクスを用いた仮想マシンへのリソース配置に基づくアーキテクチャのモデル図である。
図１１は、設計マトリクスを用いた物理マシンへのリソース配置に基づくアーキテクチャのモデル図である。
図１２は、モデル図を表示する実装インタフェース例を示す説明図である。
図１３は、ＤＳＭマトリクスを表示する実装インタフェース例を示す説明図である。
図１４は、本発明の具現化の一例を示す構成図である。
図１５は、本発明の別の具現化の一例を示す構成図である。
図１６は、発明者による公理的設計及びＤｆＸの考え方を用いてアプリケーションの設計を１つのモデルに統合して示したモデル図である。

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

【0009】

本発明の実施の一形態を図面に基づいて説明する。
本実施の一形態では、クラウドアプリケーションのアーキテクチャ設計プロセスを３つのフェーズに分割して各フェーズにおける設計対象（モジュールの粒度や、割当、配分、配置など）を明確化する。分割する３つのフェーズは、機能モジュール設計フェーズ、モジュール配置設計フェーズ、リソース割当設計フェーズである。
第１のフェーズである機能モジュール設計フェーズは、アプリケーションを構成する機能群とアプリケーションプログラムを構成するモジュール群との対応と、個々のモジュールの粒度とを決定する。
第２のフェーズであるモジュール配置設計フェーズは、上記モジュール群と、各モジュールを配置する仮想マシン群（ネットワークリソース：論理リソース）との対応を決定する。
第３のフェーズであるリソース配分設計フェーズは、上記仮想マシン群と、各仮想マシンを配置する物理マシン（物理リソース）との対応を決定する。
本発明のアプリケーションアーキテクチャの設計方法は、この３フェーズに沿って、アプリケーションアーキテクチャの設計を実行する。また、このフェーズに沿って動作するように、設計装置およびプログラムを構成する。
以下、アプリケーションアーキテクチャ設計方法を実行するアプリケーションアーキテクチャ設計装置１００を示して、本発明を説明する。
図１は、アプリケーションアーキテクチャ設計装置１００の構成を示すブロック図である。
図１に示すアプリケーションアーキテクチャ設計装置１００は、依存関係入力部１１０と、設計アスペクト情報入力部１２０と、設計情報保管部１３０と、設計マトリクス配置計算部１４０と、機能モジュール設計マトリクス表示部１５０と、モジュール配置設計マトリクス表示部１６０と、リソース割当設計マトリクス表示部１７０とを含み構成されている。なお、本構成以外にも入力部などの一般的な構成を有する。
依存関係入力部１１０と設計アスペクト情報入力部１２０は、設計事項入力部として動作する。設計事項入力部では、アプリケーションプログラムを形成するモジュール群、仮想マシン群、物理マシン群に関しての設計事項となる依存関係および設計アスペクトに関する情報の入力に使用する。
機能モジュール設計マトリクス表示部１５０、モジュール配置設計マトリクス表示部１６０、およびリソース割当設計マトリクス表示部１７０は、設計マトリクス最適化部として動作する。設計マトリクス最適化部では、依存関係および設計アスペクトをそれぞれのレイヤーレベルでＤＳＭ形式のマトリクスとして表示すると共に、表示したマトリクスの行・列の入れ替えを可能とする。この入れ替えを行なうことによって、マトリクスの操作に対応するようにアーキテクチャ設計を設計マトリクス最適化部が変更処理する。
すなわち、設計マトリクス最適化部を用いて、それぞれ適したマトリクス形状のパターン（モジュール化度合いなど）を選択することで、モジュール群、仮想マシン群および物理マシン群に対するそれぞれ上位レイヤのパーツが適切に割当てられたように配分・配置される。この配分・配置を繰り返すことにより、総じてアーキテクチャの最適化が図られる。
また、上記３フェーズ（機能モジュール設計フェーズ、モジュール配置設計フェーズ、リソース割当設計フェーズ）を順に設計マトリクス最適化部で変更処理（最適化処理）の実行を行いう。この際、各フェーズの出力結果は、次フェーズへの入力情報とする。このことで、アーキテクチャ構造全体について、一体的且つ効率的にアーキテクチャ設計が行える。
依存関係入力部１１０に入力される情報としては、考慮する２者間の関係を示す情報を含ませる。例えば、メソッドの呼出し元と呼出し先の関係のように直接的に機能呼出しの関係がある２者間の関係を示す情報や、複数の機能から構成するモジュールとその配置先のように直接的に物理的な関係がある２者間の関係を示す情報などである。
また、設計アスペクト情報入力部１２０に入力される情報としては、以下のような情報を含ませる。
−性能（データトランザクションの関連性，ファイル書き込みの共有，．．．）
−保守性（更新時の同時停止の要否，オーナーの違いの有無，．．．）
−安全性（データの隔離の要否，ＶＭ間の隔離の要否，．．．）
−可用性（停止範囲の関連性，フォールトトレラントの必要，．．．）
−移行性（ミドルウェア更新時の影響の関連，モジュールホットアップデートの要否，．．．）
設計情報保管部１３０は、入力とする依存関係と設計アスペクトの情報を受けて記憶保管し、また、各再配置（最適化）を終えて生成された設計マトリクス情報を記憶保管する。
設計マトリクス配置計算部１４０は、各種アルゴリズムを用いて、受け付けた各設計マトリクスの行／列の配置を、所定のパターンに近づけるように自動変更処理（再配置）させて、その結果を返す。
次に、アプリケーションアーキテクチャ設計装置１００の動作について、図２、図３、図４、図５、図６を用いて説明する。
［第１のフェーズ］
まず、第１のフェーズとして、アプリケーションの提供に用いるアプリケーションプログラムのモジュール構成を決定するための機能モジュール設計フェーズを実行する。
まずアプリケーションを構成する機能群と、機能間の呼び出し関係とを依存関係として依存関係入力部１１０に入力する（図４のＳ１１１）。
次に、データトランザクションに関する性能要件などアプリケーションのロジックとして特定の機能間に関連がある場合には、それらの情報を設計アスペクト情報２００として設計アスペクト情報入力部１２０に入力する（Ｓ１１２、図２参照）。なお、入力される設計アスペクト情報には、図２に例示するように、”機能依存関係”、”性能”、”セキュリティ”、”保守性”、”保全性”、”拡張性”、”可用性”、”移行性”などの多種の設計観点と共に、個々の観点に重要度を割当てることができる。
図２に示す本例では、モジュール１に割当てる機能のうち、”性能”について機能Ａ、機能Ｂ、機能Ｈが関連し、”セキュリティ”について機能Ａ、機能Ｂ、機能Ｃが関連することを示している。また、”保守性”や”拡張性”についても同様である。これら設計観点は、設計アスペクト情報の入力者（アーキテクト）の知見に基づいて入力される。
また、それぞれの性能観点について、入力者が適に重要度を与える。図２の“性能”についての設計観点を用いて説明すれば、機能Ａと機能Ｂ、機能Ｂと機能Ｈ、機能Ａと機能Ｈの関係について、“機能依存関係”の重要度が加味される。この機能間の依存関係に与える重要度は、例えば、機能間の直接的な呼び出し関係などを加味して与える値である。
図２の例では、それぞれの設計観点の重要度について、”機能依存関係”には０．１、”性能”には０．３、”セキュリティ”には０．２、”保守性”には０．３、”拡張性”には０．１を与えている。
また、アーキテクトは、このとき要件毎に与えた重要度の全体が１．０になるよう重要度の値を入力することが望ましい。
なお、図示したように全体に与える値（例えば機能依存関係：０．１）とは別に、特定の機能間に与える値を加えることとしてもよい。アプリケーションアーキテクチャ設計装置は、与えられた各値を、図３に示すように設計マトリクスのセルに設定する。
設計情報保管部１３０は、Ｓ１１１、Ｓ１１２で入力された情報を受け付けて設計マトリクス情報として保管する（Ｓ１１３）。
機能モジュール設計マトリクス表示部１５０は、設計情報保管部１３０に保管された設計マトリクス情報を用いてＤＳＭ方式のマトリクス（機能モジュール設計マトリクス）を表示する（Ｓ１１４、図３参照）。この処理が行われることで、図３に示すように、機能モジュール設計マトリクスには、それぞれのセルに重要度の値が割当てられて、機能とモジュールの対応が表示される。ここでの重要度とは、設計アスペクト情報として割当てられた図２に記載された重要度に基づき、それぞれのモジュール間の依存度を加味しつつ算出される。
このＤＳＭ方式に基づくマトリクスの可視化により、Ｓ１１１、Ｓ１１２で入力した情報の十分性を確認し、見直しが必要な場合にはＳ１１１に戻る。見直しが不要で、機能分割が適正になされている場合には、その内容を設計マトリクス情報として設計情報保管部１３０に出力した後、表示を終了する。また、可視化したマトリクスに基づき再配置を行う場合には、Ｓ１２１に進む（Ｓ１１５）。なお、十分性の判断では、ＤＳＭマトリクスを参照して、配列の対角ラインを基準としたモジュールの配置位置や、各モジュールに含まれる値の合計値などを参照すればよい。この十分性の確認によって、例えばモジュール相互の統合や、モジュールの重要性、モジュールの粒度などが判断できる。
機能モジュール設計マトリクスの再配置計算を行う場合、機能モジュール設計マトリクス表示部１５０は、再配置の指示入力を受けつけて表示した各情報の相互関係を維持しつつマトリクスの行および列の置換処理（再配置）を行った設計マトリクス情報を計算して再配置が反映された状態に変更して設計情報保管部１３０に登録処理する（Ｓ１２１）。
ここで、行・列の配置変換による機能とモジュールとの対応付けの適正化（個々のモジュールの粒度決定などの決定）は、マトリクスを利用者自身が手動で操作してもよい。このとき、設計マトリクスをモジュール化（ブロック化）を進めることによってアーキテクチャの適正化が図れる。ＤＳＭの最適なモジュール分割は、配列の斜めラインに寄せて配置されかつ各モジュールに含まれる値の合計値が最大に近づけるような、戦略をとるとよい。
他方、行・列の数が多い場合には、各設計マトリクスの行／列の再配置に基づき設計開発の適正解を自動的に算定する設計マトリクス配置計算部１４０を用いることで、より有効に適正解を導出できる。適正解の自動算定は、遺伝的アルゴリズムを利用できる。また、他のアルゴリズムを使用することも可能である。当該自動化によって、入力された設計マトリクス情報に好適なアーキテクチャのモデル図（設計図）が得られる。適正解の自動算定でも、手動で適正解を求める際と同様に、使用する適正化アルゴリズムを実行するプログラムによって、配列の斜めに配置されかつ各モジュールに含まれる値の合計値が最大になるようなパターン（マトリクスの形状と密度）を導出するなどとすればよい。なお、導出するパターンは、１種類に限らずとも複数種類のパターンを導出させてもよい。
機能モジュール設計マトリクス表示部１５０は、再配置計算された設計マトリクス情報を用いて再配置計算後の機能モジュール設計マトリクスを表示する（Ｓ１２２）。なお、機能モジュール設計マトリクス表示部１５０は、再配置計算後のマトリクス表示の際に、再配置前後の機能モジュール設計マトリクスを対比できるように表示するように構成してもよい。
以上の第１のフェーズにより、アプリケーションプログラムのモジュール構成（担当機能や粒度など）が定まる。すなわち、機能モジュール設計マトリクスを参照することで、性能、保守性、安全性、可用性、移行性、機能間の依存関係などの設計観点を識別でき、再配置によってこれら設計観点を考慮した良好なモジュール構成を導出できる。
この結果、設計開発時に決定するソフトウェア機能のモジュール化が判断しやすくなる。なお、個々のモジュール開発は、下記のフェーズによって全体の適正化が行われた後に行なわれることとなる。
［第２のフェーズ］
次に、第２のフェーズとして、上述したように決定したアプリケーションのモジュール構成に対して、そのモジュール群の論理的配置を決定するためのモジュール配置設計フェーズを実行する。
まずアプリケーションを構成するモジュール群と、モジュール間の呼び出し関係とを依存関係として依存関係入力部１１０に入力する（図５のＳ２１１）。
次に、可用性・保守性・移行性・安全性などの要件（設計観点）で特定のモジュール間に関連がある場合には、これらを設計アスペクト情報２００として設計アスペクト情報入力部１２０に入力する（Ｓ２１２、図２参照）。
設計情報保管部１３０は、Ｓ２１１、Ｓ２１２で入力された情報を受け付けて設計マトリクス情報として保管する（Ｓ２１３）。
モジュール配置設計マトリクス表示部１６０は、設計情報保管部１３０に保管された、設計マトリクス情報を用いてＤＳＭ方式のマトリクス（モジュール配置設計マトリクス）を表示する（Ｓ２１４）。
このＤＳＭ方式に基づくマトリクスの可視化により、Ｓ２１１、Ｓ２１２で入力した情報の十分性を確認し、見直しが必要な場合には、Ｓ２１１に戻る。見直しが不要で、モジュール配置が適正になされている場合には、その内容を設計マトリクス情報として設計情報保管部１３０に出力した後、表示を終了する。また、可視化したマトリクスに基づき再配置を行う場合には、Ｓ２２１に進む（Ｓ２１５）。なお、本フェーズでの十分性の判断でも、先のフェーズ（機能モジュール設計フェーズ）での判断と同様の基準（配置や合計値など）を用いておこなうこととすればよい。
モジュール配置設計マトリクスの再配置計算を行う場合、モジュール配置設計マトリクス表示部１６０は、再配置の指示入力を受けつけて表示した各情報の相互関係を維持しつつマトリクスの行および列の置換処理（再配置）を行った設計マトリクス情報を計算して再配置が反映された状態に変更して設計情報保管部１３０に登録処理する（Ｓ２２１）。
ここで、行・列の配置変換によるモジュールと論理リソースとの対応付けの適正化（論理リソースへのモジュール配置とその密度の決定など）は、設計マトリクスを利用者自身が手動で操作して、モジュール配置（ブロック化）を進めることとしてもよい。このとき、設計マトリクスをモジュール化（ブロック化）を進めることによってアーキテクチャの適正化が図れる。ＤＳＭの最適なモジュール配置は、配列ラインの斜めに配置されかつ各モジュールに含まれる値の合計値が最大になるような戦略をとるとよい。
また、設計マトリクス配置計算部１４０を用いて適正解を導出してもよい。適正解の自動算定は、上記機能モジュール設計フェーズと同様に行える。当該自動化によって、入力された設計マトリクス情報に好適なアーキテクチャのモデル図（設計図）が得られる。なお、マトリクスのパターンは、複数種類のパターンを導出することとしてもよい。また、マトリクスのパターンは、先のフェーズで導出した個々のモジュールのマトリクス上での合計値の重心が均一化されるように導出するようにてもよい。このようにモジュールの重心を均一化することで、設計アスペクト情報として入力した重要度に基づく個々のモジュールの仮想化マシンへの分布の平均化が図れる。この平均化によって、クラウド環境での各処理の平坦化が期待できる。
モジュール配置設計マトリクス表示部１６０は、再配置計算された設計マトリクス情報を用いて再配置計算後のモジュール配置設計マトリクスを表示する（Ｓ２２２）。なお、モジュール配置設計マトリクス表示部１６０は、再配置計算後のマトリクス表示の際に、再配置前後のモジュール配置設計マトリクスを対比できるように表示するように構成してもよい。また、モジュール配置設計マトリクス表示部１６０は、モジュール配置設計マトリクスと共に機能モジュール設計マトリクスを表示するようにしてもよい。
以上の第２のフェーズにより、先のフェーズで導出した個々のモジュールの実行環境とする論理装置への配置が定まる。すなわち、機能モジュール設計マトリクスを参照することで、設計開発時に決定するアプリケーションモジュールの論理的配置場所が判断しやすくなる。
［第３のフェーズ］
次に、第３のフェーズとして、上述したように決定したモジュールの論理装置に対して、モジュールが配置された論理リソース群の物理的配置を決定するためのリソース割当設計フェーズを実行する。
まずアプリケーション間の呼び出し関係を依存関係として依存関係入力部１１０に入力する（図６のＳ３１１）。
次に、性能の要件などに基づき、特定のモジュール間（モジュールを搭載する論理リソース間）に関連を持たせる場合には、これらを設計アスペクト情報２００として設計アスペクト情報入力部１２０に入力する（Ｓ３１２）。
設計情報保管部１３０は、Ｓ３１１、Ｓ３１２で入力された情報を受け付けて設計マトリクス情報として保管する（Ｓ３１３）。
リソース割当設計マトリクス表示部１７０は、設計情報保管部１３０に保管された設計マトリクス情報を用いてＤＳＭ方式のマトリクス（リソース割当設計マトリクス）を表示する（Ｓ３１４）。
このＤＳＭ方式に基づくマトリクスの可視化により、Ｓ３１１、Ｓ３１２で入力した情報の十分性を確認し、見直しが必要な場合にはＳ３１１に戻る。見直しが不要で、モジュール配置が適正になされている場合には、その内容を設計マトリクス情報として設計情報保管部１３０に出力した後、表示を終了する。また、可視化したマトリクスに基づき再配置を行う場合には、Ｓ３２１に進む（Ｓ３１５）。なお、十分性の判断は、先のフェーズと同様に行えばよい。
リソース割当設計マトリクスの再配置計算を行う場合、リソース割当設計マトリクス表示部１７０は、再配置の指示入力を受けつけて表示した各情報の相互関係を維持しつつマトリクスの行および列の置換処理（再配置）を行った設計マトリクス情報を計算して再配置が反映された状態に変更して設計情報保管部１３０に登録処理する（Ｓ３２１）。
ここで、行・列の配置変換による論理リソースと物理リソースとの対応付けの適正化（物理リソースへの仮想マシンの配置とその密度の決定など）は、先のフェーズと同様に、設計マトリクスを利用者自身が手動で操作して、モジュール化を進めることとしてもよいし、設計マトリクス配置計算部１４０を用いて適正解を導出してもよい。このように、設計マトリクスをモジュール化（ブロック化）を進めることによってアーキテクチャの適正化が図れる。
適正解の自動算定は、上記両設計フェーズと同様に行える。当該自動化によって、入力された設計マトリクス情報に好適なアーキテクチャのモデル図（設計図）が得られる。なお、マトリクスのパターンは、複数種類のパターンを導出することとしてもよい。また、マトリクスのパターンは、先のモジュール配置フェーズで導出した個々の論理リソースのマトリクス上での合計値の重心が均一化されるように導出するようにしてもよい。このように論理リソースの重心を均一化することで、論理リソースを介しても設計アスペクト情報として入力した重要度に基づく個々のモジュールに起因する物理マシンへの分布の平均化や処理の平坦化が期待できる。
リソース割当設計マトリクス表示部１７０は、再配置計算された設計マトリクス情報を用いて再配置計算後のリソース割当設計マトリクスを表示する（Ｓ３２２）。なお、リソース割当設計マトリクス表示部１７０は、再配置計算後のマトリクス表示の際に、再配置前後のリソース割当設計マトリクスを対比できるように表示するように構成してもよい。また、リソース割当設計マトリクス表示部１７０は、リソース割当設計マトリクスと共に先の両フェーズでのマトリクスを表示するようにしてもよい。
以上の第３のフェーズにより、先のフェーズで導出した個々の論理リソースを実行環境とする物理装置（物理リソース）に対する割当位置を好適に定められる。
以上のように、アプリケーションアーキテクチャ設計装置１００において、仮想化環境やクラウド環境におけるアプリケーションアーキテクチャの良好な設計解を導出できる。
以下に、具体的な事例を用いて上記実施の一形態について、図７、図８、図９、図１０、図１１、図１２、図１３を用いて説明する。
図７に例とするクラウドコンピューティング環境上に構築を予定するアプリケーションプログラムの構成を示す。このクラウドアプリケーションプログラムは、ネットワーク上に配置されたサーバ機器のログ情報を一定期間ごとに収集して、データベースに保管する。
また、このクラウドアプリケーションプログラムは、ユーザとのインタフェースとして、Ｗｅｂ画面（インタフェース）を構築する。ネットワークを介してユーザからキーワード検索のリクエストを受け付けると、このクラウドアプリケーションプログラムは、保管されたデータベースからデータを読み出してキーワードを含むログを抽出し、その件数をカウントしてＷｅｂ画面として提示する。
このようなアプリケーションが有する機能としては、まず、ログ収集機能、スケジュール機能、ログ書き込み機能、データ保管機能、次に、リクエスト入力機能、リクエスト分析機能、データキャッシュ機能、データ検索機能、検索結果カウント機能、カウント結果出力機能が挙げられる。
先ず、アーキテクトは、アプリケーションアーキテクチャ設計装置１００に、前述の機能間の呼び出し関係を依存関係入力部１１０から入力する。
ここでは、設計アスペクト情報入力部１２０では、図８に示すような設計観点を示すリストから、パフォーマンス（性能）とセキュリティ（安全性）に関するアスペクトを選択して、設計アスペクト情報を入力する。
次に、アーキテクトは、パフォーマンス観点の要件として、ログ収集機能とログ書き込み機能は連続して実行することが望ましいことと、ログ書き込み機能とデータ保管機能は一体となって連続実行されることを、設計アスペクト情報入力部１２０に設計アスペクト情報の一項目として入力する。同様に、アーキテクトは、パフォーマンス観点の他の要件や、他の観点の各項目を入力する。なお、当該入力情報は、アーキテクトの手入力に限定されるわけではなく、データベースとして過去に蓄積済みの設計アスペクト情報などから引用することとしてもよい。
また、アーキテクトは、この設定を行なう際に、要件毎に入力する重要度の値を、総和が１．０になるよう重要度を入力することが望ましい。重要度の設定例は、図２に示している。図２の設定例では、機能依存関係を０．１、パフォーマンスを０．３、セキュリティを０．２、保守性を０．３、拡張性を０．１に調整して、総和を１．０にしている。
入力された依存関係と設計アスペクトの情報を受けて設計情報保管部１３０では、設計マトリクス情報として保管される。また、設計情報保管部１３０によって、設計アスペクト情報で指定された機能間には、その設計アスペクトの重要度の値を加える。
各情報の入力を受けて、アプリケーションアーキテクチャ設計装置１００は、自動的又はアーキテクトの指示に基づき、機能モジュール設計マトリクス表示部１５０を動作させて、設計情報保管部１３０に登録されている設計マトリクス情報を読み出して、ＤＳＭ形式に各モジュールに割当てる機能と割当てられるモジュールの対応関係が反映された機能−モジュールを示す設計マトリクスを表示して、アーキテクトに提示する。
ここで、機能モジュール設計マトリクスの適正化を行い、性能を考慮した機能分割を反映したモジュールを算定する。
人為的に行なう場合は、アーキテクトによる設計マトリクスの操作を受け付け、設計マトリクス（設計マトリクス情報）を再計算（再構築処理）し、その結果の機能モジュール設計マトリクスを適宜表示する。
また、自動化して行なう場合は、設計マトリクス配置計算部１４０からの再配置の入力を受けつけて自動的に設計マトリクス（設計マトリクス情報）を再計算（再構築処理）し、その結果の１ないし複数の機能モジュール設計マトリクスを表示する。
アーキテクトは、機能モジュール設計マトリクス表示部１５０に適時出力された設計マトリクスを視認することで、見直しの有無やその設計の適否を視認する。また、再配置前後の設計マトリクスを対比可能なように表示するようにしてもよい。また他のマトリクスと対応付けや、各モジュールの密度や重心を視覚効果として表示してもよい。
図９には、マトリクスの再配置の一例を示す。アーキテクト又は設計マトリクス配置計算部１４０は、行および列をそれぞれ移動して、対角線（黒塗りのセル）および左下方向に値を持つセルが多く並び大きなモジュール（セルの集合：ブロック）を形成するように再配置する。このＤＳＭ表記上のモジュールの大きさが、プログラムのモジュールの粒度の単位と成る。なお、図９では各セルを０，１の二値で記載している。他方、図３に示す様に各セルが０，１の二値ではなく０から１の間の重みを付けている場合には、上記したように、ブロック中の合計値が大きくなる組合せを適切なものとすればよい。
第一のフェーズでの再配置後のモジュール構成として、例えば次のような分割結果が得られたとする。
（１）ログ収集機能、ログ書き込み機能
（２）スケジュール機能
（３）データ保管機能、データ検索機能
（４）リクエスト入力機能、カウント結果出力機能
（５）リクエスト分析機能、データキャッシュ機能
※（１）〜（５）は、個々のモジュールを指す
次に、第二のフェーズとして上記の各モジュールを仮想マシンに配置する。
ここでは、設計アスペクト情報入力部１２０には、保守性・安全性・可用性・移行性などに関するアスペクトを次のように入力する。
保守性の観点から、（１）ログ収集機能、ログ書き込み機能と（２）スケジュール機能とは同じ仮想マシン上で管理するのが望ましい。同様に、保守性の観点から、（３）データ保管機能、データ検索機能と（４）リクエスト入力機能、カウント結果出力機能とは同じ仮想マシン上で管理するのが望ましい。これらの情報を保守性の要件として入力するとともに、他の要件（拡張性や保守性など）も入力する。なお、当該アスペクトの入力は、フェーズ開始時や先のフェーズ時に行なってもよいし、追加的に行なってもよく、適宜行えばよい。
各情報の入力を受けて、アプリケーションアーキテクチャ設計装置１００は、モジュール配置設計マトリクス表示部１６０を動作させて、設計情報保管部１３０に登録されている設計マトリクス情報を読み出して、ＤＳＭ形式にモジュールが個々に動作する仮想マシンに対する各モジュールのモジュール配置を示す設計マトリクスを表示して、アーキテクトに提示する。
ここで、モジュール配置設計マトリクスの適正化を行い、各要件を反映したモジュールの仮想マシンへの配置を算定する。
人為的に行なう場合は、アーキテクトによる設計マトリクスの操作を受け付け、設計マトリクスを再計算し、その結果のモジュール配置設計マトリクスを適宜表示する。
また、自動化して行なう場合は、設計マトリクス配置計算部１４０からの再配置の入力を受けつけて自動的に設計マトリクスを再計算し、その結果の１ないし複数のモジュール配置設計マトリクスを表示する。
アーキテクトは、モジュール配置設計マトリクス表示部１６０に適時出力された再配置前後の設計マトリクスを視認することで、見直しの有無やその設計の適否を視認する。
これにより、再配置後のモジュール構成として、例えば、次のようなリソース配置結果が得られ、図１０で示すような設計のモデル図を出力することができる。得られたモデル図は、適時又はアーキテクトの指示のもと、インタフェース上に提示すればよく、また、他の情報と連係させることが望ましい。
仮想マシン１：（１）ログ収集機能、ログ書き込み機能、（２）スケジュール機能
仮想マシン２：（３）データ保管機能、データ検索機能、（４）リクエスト入力機能、カウント結果出力機能
仮想マシン３：（５）リクエスト分析機能、データキャッシュ機能
※（１）〜（５）は、個々のモジュールを指す
次に、第三のフェーズとして上記の仮想マシンを物理マシン上に配置する。
ここでは、設計アスペクト情報入力部１２０には、性能などに関するアスペクトを次のように入力する。
上記仮想マシン１から３は、他のサービスで用いられる仮想マシンとの干渉を考慮し、実際に仮想マシンを動かす物理マシンの決定を容易にする。
上記仮想マシン１から３は、ディスクＩＯが多い他のアプリケーションとは分離させる。
これらの情報を性能の要件として入力するとともに、他の要件（拡張性や保守性など）も入力する。なお、当該アスペクトの入力は、フェーズ開始時や先のフェーズ時、再配置後に追加的に適宜行えばよい。
各情報の入力を受けて、アプリケーションアーキテクチャ設計装置１００は、リソース割当設計マトリクス表示部１７０を動作させて、設計情報保管部１３０に登録されている設計マトリクス情報を読み出して、ＤＳＭ形式に個々の仮想マシンが動作する物理マシンに対する各仮想マシンの割振りとなるリソース割当を示す設計マトリクスを表示して、アーキテクトに提示する。
ここで、リソース割当設計マトリクスの適正化を行い、各要件を反映した仮想マシン１〜３の物理マシンへの配置を算定する。
人為的に行なう場合は、アーキテクトによる設計マトリクスの操作を受け付け、設計マトリクスを再計算し、その結果のリソース割当設計マトリクスを適宜表示する。
また、自動化して行なう場合は、設計マトリクス配置計算部１４０からの再配置の入力を受けつけて自動的に設計マトリクスを再計算し、その結果の１ないし複数のリソース割当設計マトリクスを表示する。
アーキテクトは、リソース割当設計マトリクス表示部１７０に適時出力された再配置前後の設計マトリクスを視認することで、見直しの有無やその設計の適否を視認する。
これにより、再配置後の仮想マシンの配置構成として、例えば、次のような配置計画が得られ、図１１で示すような設計のモデル図を出力することができる。得られたモデル図は、適時又はアーキテクトの指示のもと、インタフェース上に提示すればよく、また、他の情報と連係させることが望ましい。
物理マシン１：仮想マシン１、仮想マシン２
物理マシン２：仮想マシン３
ここまでの各フェーズを行なうことで、図１１に示すように、個々の物理マシンに導入すべき仮想マシンおよびモジュール群が好適なアーキテクチャで導出できる。
次に、アーキテクトに対して提示するインタフェース（画面）を例示する。
図１２は、設計後のアーキテクチャを確認するインタフェース例である。この例では、設計マトリクスを用いて行った３つのフェーズによって得られた２つのモデル図を上ウインドに、選択された部分の適正化後の設計マトリクスを下ウインドに表示される画面構成を採用している。なお、本発明は、このインタフェースに限定されるものではなく、アーキテクトの操作性や利便性を考慮して適宜同時表示する情報を選択すればよい。
図１３は、アプリケーションアーキテクチャ設計装置１００での設計マトリクスの自動的最適化を行なう時に用いるインタフェース例である。この例では、上ウインドに適正化前、下ウインドに適正化後が表示される構成であり、操作者からアナライズボタンへの入力を受けて、設計マトリクス計算部１４０で設計マトリクスの適正化が行われて、その結果が下ウインドに表示されている。図中からわかるように、再配置前に多数のモジュールを、再配置によってモジュールを統合できる良好な設計解を導出している。この導出した設計解に基づいて設計を再考することで、より良い仮想化環境やクラウド環境におけるアプリケーション設計が行える。また、その際に、図中の密度表示（下ウインド参照）で表しているように、設計アスペクトとして入力した性能や保守性、安全性・・・などの多種の設計観点を可視的に一体的に確認できる。このことにより、効率的に良好な設計解を導き出せる。
以上説明したように、本発明を適用したアプリケーションアーキテクチャ設計装置によれば、仮想化環境やクラウド環境におけるアプリケーション設計時に、アプリケーションアーキテクチャのより良い設計解を容易且つ均一的に導出できる。また、各設計マトリクスを用いることで、アーキテクチャの客観的な評価にも役立てることできる。
具体的に例示すれば、ソフトウェア機能の性能観点などによるモジュールの規模の策定、割当機能の決定が判断しやすくなる。これは、機能モジュール設計マトリクスの適正化を用いることにより、性能を考慮した機能分割が容易と成るからである。
同様に、モジュール配置設計マトリクスにより、拡張性や保守性の要件を充たしたモジュールの配置方法が容易となる。
また、アプリケーション配置場所（どの地域やどのデータセンタを用いるなど）が判断しやすくなる。これは、リソース割当設計マトリクスにより、仮想マシン間の依存関係が分かり、運用管理者によるクラウドサービスで用いる仮想マシンをどの物理マシン上で動かすことが適しているのかが分かり、計画を立て易くなるためである。
また、アプリケーションアーキテクチャ設計装置によれば、ＤＳＭ形式で表示された各設計マトリクスの行／列の再配置に基づく設計開発の適正解を自動化して利用者に提供できる。当該自動化によれば、入力した設計アスペクト情報と依存関係とに基づき、性能、保守性、安全性、可用性、移行性などの設計観点を所望のように考慮した、アプリケーションのモジュール構成、仮想マシンへのモジュール配置、および物理マシンへの仮想マシン配置を示してくれる。また、各観点に対する重要度を反映させた各フェーズ毎の複数のモデル図を容易に取得することが可能となる。
尚、アプリケーションアーキテクチャ設計装置の各部は、ハードウェアとソフトウェアの組み合わせを用いて実現すればよい。ハードウェアとソフトウェアとを組み合わせた形態では、ＲＡＭにアプリケーションアーキテクチャ設計プログラムが展開され、当該プログラムに基づいて制御部（ＣＰＵ）等のハードウェアを動作させることによって、各部を各種手段として機能させる。また、このプログラムは、固定的に記録媒体に記録されて頒布されても良い。当該記録媒体に記録されたプログラムは、有線、無線、又は記録媒体そのものを介して、メモリに読込まれ、制御部等を動作させる。尚、記録媒体を例示すれば、オプティカルディスクや磁気ディスク、半導体メモリ装置、ハードディスクなどが挙げられる。
また、アプリケーションアーキテクチャ設計装置は、図１４や図１５に例示すように、コンピュータ単体として構築してもよいし、サーバ−クライアントシステムとして構築してもよい。
上記実施の形態を別の表現で説明すれば、アプリケーションアーキテクチャ設計装置として動作させる情報処理装置を、ＲＡＭに展開されたアプリケーションアーキテクチャ設計プログラムに基づき、依存関係入力部、設計アスペクト情報入力部、設計情報保管部、設計マトリクス配置計算部、機能モジュール設計マトリクス表示部、モジュール配置設計マトリクス表示部、リソース割当設計マトリクス表示部として制御部を動作させることで実現することが可能である。当該情報処理装置は、設計情報保管部に蓄積された各時点の設計マトリクス情報を各種設定要件などとともに出力部（プリンタなど）から出力する。また、情報処理装置の画面には、機能モジュール設計フェーズ、モジュール配置設計フェーズ、リソース割当設計フェーズの３時点の設計マトリクス情報を関連付けて反映させた３ＤＳＭマトリクスを表示できるようにしてもよい。また、各ＤＳＭマトリクスと関連付けて、入力された依存関係や設計アスペクトをモデル化したアーキテクチャのモデル図を表示するようにしてもよい。また、表示したモデル図を操作することによって、依存関係や設計アスペクトについて修正できるようにしてもよい。これらのモデル図は、各段階で行われるＤＳＭ形式の設計マトリクスと連係させ、また、再配置前と再配置後の設計マトリクスについて、適宜表示できるようにインタフェース画面を作ることが望ましい。これらのことを行なうことで、設計アスペクトとして入力される項目ごとの重要度がアーキテクチャ設計の適正化により有効に寄与することとなる。
また、本発明の具体的な構成は前述の実施の形態に限られるものではなく、この発明の要旨を逸脱しない範囲の変更があってもこの発明に含まれる。
本発明によれば、仮想化をも考慮したアプリケーションの設計が可能になることで、システム開発者が、サーバやストレージが仮想化されている環境に適したアプリケーションのモジュール構成や、仮想的配置、物理的配置を良好に設計することが可能となる。
また、クラウドサービスなどの提供事業者は、アプリケーションの特性に合わせて、仮想マシンの割り当て方を最適化することが可能となる。
また、クラウドサービスなどの提供事業者は、他のサービスで用いられる仮想マシンとの干渉を考慮して、実際に仮想マシンを動かす物理マシンの決定を容易に行なうことが可能となる。
この出願は、２０１１年４月２８日に出願された日本出願特願２０１１−１０１１０６号を基礎とする優先権を主張し、その開示の全てをここに取り込む。

【符号の説明】

【0010】

１００ アプリケーションアーキテクチャ設計装置（システム）
１１０ 依存関係入力部（依存関係入力手段）
１２０ 設計アスペクト情報入力部（設計アスペクト情報入力手段）
１３０ 設計情報保管部（設計情報保管手段）
１４０ 設計マトリクス配置計算部（設計マトリクス配置計算手段）
１５０ 機能モジュール設計マトリクス表示部（機能モジュール設計マトリクス表示手段）
１６０ モジュール配置設計マトリクス表示部（モジュール配置設計マトリクス表示手段）
１７０ リソース割当設計マトリクス表示部（リソース割当設計マトリクス表示手段）

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】