JP5129917B2

JP5129917B2 - 情報システムのモデルベースのアーキテクチャを設計する自動システムおよび方法

Info

Publication number: JP5129917B2
Application number: JP2002523190A
Authority: JP
Inventors: エルアタ・ナビル・エーアブ
Original assignee: Individual
Current assignee: Individual
Priority date: 2000-08-29
Filing date: 2001-08-29
Publication date: 2013-01-30
Anticipated expiration: 2021-08-29
Also published as: JP2004507838A; CA2419153A1; EP1314106A2; AU2001286907A1; WO2002019148A2; US20020049573A1; WO2002019148A8

Description

【０００１】
【発明の背景】
電子コンピューティングの到来により、金融機関などの企業組織は情報システムを利用して、ビジネスプロセスをサポートするコンピュータ化インフラを提供している。情報システムは、多数の相互接続されたハードウェアおよびソフトウェアコンポーネントを含み、１つまたは複数のビジネスソリューションを実現している。このようなシステムのアーキテクチャは一般に、課せられたビジネス制約下で、変動する作業負荷および優先順位を処理することを要求される。
【０００２】
このような要求および制約を有するシステムアーキテクチャを設計することは、極めて難しいことである。大部分の既存の方法、ツールおよびテクニックは、コンピュータ化ビジネスインフラの静的で部分的な記述に集中している。動的システムの挙動は一般に、情報システムが構築または作動状態になるまで未知であるため、改良の可能性が制限される。アーキテクチャによりサポートされなければならない新しいビジネスアプリケーションが追加されて、システムが進化するにつれ、許容できない、性能上の問題はさらに悪化する可能性がある。
【０００３】
さらに、問題の原因が開発プロセスの初期になされた決定にあるときは、システムアーキテクチャの特定レベルでの再設計が必要である場合に、改良コストが極めて高くなる可能性がある。したがって、許容外のシステムアーキテクチャの設計に起因する多額の投資損失が発生する場合がある。
【０００４】
【発明の概要】
本発明の実施形態によれば、情報システムのモデルベースのアーキテクチャを設計する自動システムおよび方法が提供される。自動システムおよび方法の実施形態は、システム設計者が利用するコンピュータ支援デザインツールで実現できる。このような実施形態は、多数のビジネスプロセスを記述し、各ビジネスプロセスに対するビジネス要求セットを定義するビジネスプロセスデザインを提供する。システムアーキテクチャのマルチレイヤ数学モデルがビジネスプロセスデザインから構築され、このモデルはビジネスレイヤ、アプリケーションレイヤおよびテクノロジーレイヤを有する。初期モデルが構築されると、性能メトリクス（metrics：測定基準）が各レイヤでモデル化される。各ビジネスプロセスに対し、モデル化された性能メトリクスをビジネス要求セットと比較して、１つまたは複数のビジネスプロセスの許容外の性能メトリクスの表示をそれぞれ生成する。許容外の性能メトリクスを有するビジネスプロセスに対しては、システムアーキテクチャの修正が決定され、容認を得るためにシステム設計者に提案される。容認されると、システムアーキテクチャのモデルは、容認された修正形態で修正され、性能メトリクスが各レイヤで更新される。更新された性能メトリクスがビジネス要求を満たせば、その結果得られたシステムアーキテクチャの記述の出力が有効になる。
【０００５】
本発明の前述およびその他の目的、特徴、および利点は、添付図面に示す本発明の好ましい実施形態の以下の詳細な説明で明らかになるであろう。図面では、同一参照符号は異なる図面においても同一部品を指す。図面は必ずしも縮尺通りでなく、本発明の原理を示すことに重点が置かれている。
【０００６】
【好ましい実施形態の詳細な説明】
以下、本発明の好ましい実施形態について記述する。
【０００７】
本発明の実施形態は、システム設計者が情報システムのモデルベースのアーキテクチャを設計するための自動システムおよび方法を提供する。モデルベースのアーキテクチャとは、モジュール式ハードウェアおよびソフトウェアコンポーネントモデルから設計され、性能モデル化により実証されたシステムアーキテクチャである。性能モデル化による実証により、モデルベースのアーキテクチャは、システム設計者の経験だけに基づいて設計されたシステムアーキテクチャより堅牢かつ確実なものとなる。自動システムおよび方法の実施形態は、システム設計者により利用されるコンピュータ支援デザインツールで実現できる。
【０００８】
本発明を概略的に述べると、システム設計者に一連のグラフィカルユーザーインタフェースが提供され、これを介して、ビジネスプロセスデザインからシステムアーキテクチャの初期モデルが構築される。ビジネスプロセスデザインを提供している状態で、自動システムの実施形態は、予めモデル化されたビジネスアプリケーションの選択可能なリストを提供し、そのビジネスアプリケーションはデフォルトのハードウェアおよびソフトウェアコンポーネントモデルのセットに連結されている。初期モデルを構築するには、ビジネスプロセスデザインで定義された対応するビジネスプロセスに対して、利用可能なビジネスアプリケーションを単にマッピングするだけでよい。したがって、システム設計者は、サポートハードウェアおよびソフトウェアコンポーネントを定義することから解放される。初期モデルが構築された後、自動システムの実施形態は性能モデル化、比較およびアーキテクチャ修正ステージのシーケンスを反復し、この反復をモデル化されたメトリクスがビジネスプロセスデザインのビジネス要求を満たすまで続ける。ビジネス要求が満たされると、結果として得られたモデルから、システムアーキテクチャを記述した詳細な仕様書セットが導き出される。
【０００９】
図１は、本発明の１つの実施形態による、モデルベースのアーキテクチャを設計するための自動システムの機能モジュールを示す。自動システムの実施形態は、ビジネスデザインモジュール１０と、アーキテクチャ構築モジュール２０と、性能モデル化モジュール３０と、比較モジュール４０と、修正エンジン５０と、出力モジュール６０とを含む。
【００１０】
ビジネスデザインモジュール１０は、システム設計者がビジネスプロセスデザインを提供できるグラフィカルレイアウトインタフェースを提供する。ビジネスプロセスデザインは、企業組織内のビジネスプロセスと、これらビジネスプロセス間の通信および作業負荷の流れとを識別する。さらに、ビジネスプロセスデザインは、個々のビジネスプロセスに対してビジネス要求セットを定義する。
【００１１】
アーキテクチャ構築モジュール２０はグラフィカルユーザーインタフェースを提供しており、これを介してシステム設計者は、ビジネスデザインモジュール１０におけるビジネスプロセスデザイン入力をサポートするシステムアーキテクチャのマルチレイヤ数学モデルを構築する。モデルのレイヤは、ビジネスレイヤと、アプリケーションレイヤと、テクノロジーレイヤとを含む。ビジネスレイヤは、ビジネスプロセスデザインを含むのに対して、アプリケーションおよびテクノロジーレイヤは、ビジネスプロセスデザインをサポートするソフトウェアおよびハードウェアコンポーネントモデルをそれぞれ含む。マルチレイヤ数学モデルの構造に関する詳細な情報については、１９９８年７月３１日に出願された米国特許出願第０９／１２７，１９１号の、発明の名称「マルチレイヤ数学モデルを用いた情報システムの設計および解析の方法および装置（ＭｅｔｈｏｄａｎｄＡｐｐａｒａｔｕｓｆｏｒＤｅｓｉｇｎｉｎｇａｎｄＡｎａｌｙｚｉｎｇＩｎｆｏｒｍａｔｉｏｎＳｙｓｔｅｍｓＵｓｉｎｇＭｕｌｔｉ−ＬａｙｅｒＭａｔｈｅｍａｔｉｃａｌＭｏｄｅｌｓ）」を参照されたい。前記出願は、その全文を本願明細書の一部をなすものとしてここに引用している。
【００１２】
性能モデル化モジュール３０は、システムアーキテクチャのマルチレイヤ数学モデルの各レイヤで性能メトリクスをモデル化する。ビジネスフローおよび作業負荷の定義などのビジネス要求のいくつかが、性能メトリクスの計算に利用される。
【００１３】
各ビジネスプロセスに対して、比較モジュール４０は、性能モデル化モジュール３０から出力されたモデル化した性能メトリクスを、ビジネスデザインモジュール１０で提供される定義されたビジネス要求セットと比較する。比較モジュール４０は、１つまたは複数のビジネスプロセスが、入力ビジネス要求を満たさない許容外の性能メトリクスを表すかどうかの表示を生成する。
【００１４】
許容外のモデル化したビジネス性能メトリクスが識別されると、ルールベースの修正エンジン５０がシステムアーキテクチャのモデルに対して適切な修正を決定して、許容外のビジネス性能メトリクスを改良し、システム設計者に修正を提案して容認を求める。
【００１５】
容認されると、アーキテクチャ構築モジュール２０は、システム設計者からのそれ以上の支援を受けることなく、提案された修正をシステムアーキテクチャのモデルに自動的に組み込む。修正されたシステムアーキテクチャの性能メトリクスは、性能モデル化モジュール３０により更新され、比較モジュール４０により再度比較される。モデル化されたビジネス性能メトリクスがビジネス要求を満たせば、出力モジュール６０はシステム設計者にシステムアーキテクチャの詳細な記述を提供し、この記述は後続の実行ステージにおいて使用される。ビジネス要求を満たさない場合、自動システムの実施形態は、モジュール５０、２０、３０および４０の修正、モデル化および比較ステージを反復し続ける。このプロセスは、各ビジネスプロセスのモデル化された性能メトリクスがビジネス要求を満たすか、またはサポートハードウェアおよびソフトウェアコンポーネントモデルの性能メトリクスを、ビジネスプロセスデザインを変更することなくさらに改良することができなくなるまで続く。
【００１６】
図２Ａおよび図２Ｂは、図１の実施形態を用いたモデルベースのアーキテクチャを設計するための自動デザインプロセスのフローチャートを示す。
【００１７】
１１０において、ビジネスデザインモジュール１０はグラフィカルレイアウトインタフェースを提供し、図３に示されているように、そのインタフェースを介してシステム設計者がビジネスプロセスおよびプロセス相互作用の流れの記述を提供する。
【００１８】
図３は、１つの実施形態によるビジネスプロセスデザインのグラフィカルレイアウトを示す図である。この例では、ビジネスプロセスデザイン３００は、金融機関内の支払処理のビジネスプロセスおよび相互作用を記述する。システム設計者は、アイコン３１０およびリンク３２０をレイアウトに追加することにより、ビジネスプロセスデザインを作成する。各アイコン３１０はビジネスプロセスを識別し、一方、ビジネスプロセスアイコン３１０間のリンク３２０は処理の流れを表す。１つの実施形態によれば、グラフィカルレイアウトインタフェースは、ユニバーサルマークアップ言語（ＵＭＬ：ＵｎｉｖｅｒｓａｌＭａｒｋｕｐＬａｎｇｕａｇｅ）などのグラフィカルスクリプト言語を用いて実現される。
【００１９】
図２Ａの１２０では、ビジネスデザインモジュール１０はグラフィカルレイアウトインタフェースを提供し、このインタフェースを介して、システム設計者が各ビジネスプロセスに対するビジネス要求を定義する。
【００２０】
１つの実施形態によれば、ビジネス要求とは、ビジネス制約およびビジネスドライバのことをいう。ビジネスドライバとは、一般に、ビジネスプロセスが受け取ると予測される作業負荷を表す。典型的なビジネスドライバは、ビジネスイベントの予測される数および種類とイベントを受け取る速度とを含む。
【００２１】
ビジネス制約とは、一般に、ビジネスニーズにより課せられる時間と量の制約を指す。例えば、ビジネス制約は時間制約と量制約とを含む。典型的な時間制約は、ビジネス応答時間を含むのに対して、典型的な量制約は、例えば一日当たりに処理されるイベントまたは１秒当たりに処理されるイベントを含む。ビジネス制約は、提案されたシステムアーキテクチャが、企業組織のニーズを満たすかどうかを決定する比較基準を提供する。
【００２２】
１３０において、アーキテクチャ構築モジュール２０はグラフィカルユーザーインタフェースを提供し、このインタフェースを介して、システム設計者が各ビジネスプロセスをビジネスアプリケーションにマッピングする。１つの実施形態によれば、システム設計者は、ビジネスプロセスデザイン３００のグラフィカルレイアウトにあるビジネスプロセスアイコン３１０を“ダブルクリック”することにより、アーキテクチャ構築モジュールに対してグラフィカルユーザーインタフェースを立ち上げる。
【００２３】
次に、システム設計者に、予めモデル化されたビジネスアプリケーションのリストが提供される。リストに示された各ビジネスアプリケーションは、サポートハードウェアおよびソフトウェアコンポーネントモデルのデフォルトセットに連結される。初期モデルを構築するには、利用可能なビジネスアプリケーションを、ビジネスプロセスデザインで定義された対応するビジネスプロセスに単にマッピングするだけでよい。したがって、システム設計者は、サポートハードウェアおよびソフトウェアコンポーネントのすべてを定義する作業から解放され、自動デザインプロセスがさらに単純化される。
【００２４】
ビジネスプロセスのすべてをマッピングした後、アーキテクチャ構築モジュール２０は、提案されたシステムアーキテクチャのマルチレイヤ数学モデルを生成する。モデルのレイヤは、ビジネスレイヤ、アプリケーションレイヤおよびテクノロジーレイヤを含む。マルチレイヤ数学モデルの構造に関する詳細な情報については、１９９８年７月３１日に出願された米国特許出願第０９／１２７，１９１号の発明「マルチレイヤ数学モデルを用いた情報システムの設計および分析方法および装置」を参照されたい。前記出願は、その全文を本願明細書の一部をなすものとしてここに引用している。
【００２５】
１４０において、性能モデル化モジュール３０は、アーキテクチャ構築モジュール２０において生成されたマルチレイヤ数学モデルの各レイヤに対する性能メトリクスをモデル化する。このようなメトリクスは、延長、応答時間、処理されるトランザクション量およびトランザクション処理速度を含む。１つの実施形態によれば、１２０において、ビジネスプロセスデザインで定義されたビジネスドライバは、性能メトリクスのモデル化に含まれる。性能メトリクスのマルチレイヤモデル化に関する詳細な情報については、１９９８年７月３１日に出願された米国特許出願第０９／１２７，１９１号の発明「マルチレイヤ数学モデルを用いた情報システムの設計および分析方法および装置」と、２０００年６月２９日に出願された米国特許出願第０９／６０６，８６９号の発明「情報システム構築に対し性能メトリクスを決定するシステムおよび方法（ＳｙｓｔｅｍａｎｄＭｅｔｈｏｄｆｏｒＤｅｔｅｒｍｉｎｉｎｇＰｅｒｆｏｒｍａｎｃｅＭｅｔｒｉｃｓｆｏｒＣｏｎｓｔｒｕｃｔｉｎｇＩｎｆｏｒｍａｔｉｏｎＳｙｓｔｅｍｓ）」と、を参照されたい。前記の両出願は、その全文を本願明細書の一部をなすものとしてここに引用している。次に、モデル化された性能メトリクスは比較モジュール４０に送出される。
【００２６】
１５０において、比較モジュール４０は、ビジネスプロセスのモデル化された性能メトリクスが、ビジネスプロセスデザインで定義されたビジネス要求を満たすかどうかについて、初期決定を行う。１つの実施形態によれば、この比較は、モデル化された性能メトリクスの値と、応答時間のような対応するビジネス制約の値との差でなされる。ファジー論理を使用して、モデル化された性能メトリクスが定義されたビジネス制約を満たすかどうかを確認することもできる。
【００２７】
１６０において、モデル化されたビジネス性能メトリクスが各ビジネスプロセスのビジネス要求を満たせば、提案されたシステムアーキテクチャは、出力モジュール６０に送られ、１７０において、モデルベースのシステムアーキテクチャの仕様書の詳細な記述を出力する。出力モジュール６０は、システムアーキテクチャモデルを、システムアーキテクチャの構築および実施を記述した詳細な“青写真”セットにフォーマット（形式化）する。１つの実施形態によれば、出力フォーマットは、インターネットブラウザで容易に表示可能なユニバーサルマークアップ言語（ＵＭＬ）ドキュメントである。ＵＭＬで作成された表示は、ビジネス、アプリケーションおよびテクノロジーレイヤ内のコンポーネント間を結合するハイパーリンクを含むシステムアーキテクチャを表示できる。
【００２８】
１６０において、ビジネスプロセスの少なくとも１つが、許容外のビジネス性能メトリクスを示す場合、比較モジュール４０は、図２Ｂの１８０において、アプリケーションおよびテクノロジーレイヤ内にある、許容外のビジネス性能メトリクスの原因になる、サポートコンポーネントモデルを識別することを試みる。
【００２９】
図２Ｂの１８０では、比較モジュール４０は、許容外のビジネス性能メトリクスを示す１つまたは複数のビジネスプロセスにリンクした、サポートハードウェアおよびソフトウェアコンポーネントモデルの性能メトリクスを評価する。１つの実施形態によれば、サポートコンポーネントモデルのモデル化された性能メトリクスを、ベンダーが提供するか、またはモデル化されたベンチマークと比較して、このメトリクスの動作が非効率性であるかどうかを決定する。
【００３０】
１９０において、サポートコンポーネントモデルが、許容外のモデル化された性能メトリクスを示さなければ、システム設計者には、２００において、グラフィカルユーザーインタフェースを介して、許容外のビジネス性能メトリクスがビジネスプロセスデザインの欠陥により生じたことが通知される。これらの欠陥は、非効率的なビジネスプロセスの相互作用または非現実的なビジネス要求を含むことがある。プロセスは１１０に戻り、システム設計者にビジネスデザインモジュール１０のグラフィカルレイアウトインタフェースを提供し、それにより設計者はビジネスプロセスデザインを修正する。
【００３１】
１９０において、１つまたは複数のサポートコンポーネントモデルが許容外の性能メトリクスを示した場合、ステップ２１０は、サポートコンポーネントのアイデンティティ（識別情報）および許容外の性能メトリクスをルールベースの修正エンジン５０に送り、システムアーキテクチャの修正を決定して改良を行う。
【００３２】
２１０において、修正エンジン５０は、システムアーキテクチャの修正を決定して、サポートハードウェアおよびソフトウェアコンポーネントの、システムアーキテクチャにおいてモデル化された許容外の性能メトリクスに対処する。１つの実施形態によれば、ルールベースの修正エンジン５０は、データ記憶装置内に組み込まれた論理ツリーを検索する。サポートコンポーネントモデルのアイデンティティおよびそれらの許容外のメトリクスを使用して、業界標準、ベンダーベンチマークまたは前にモデル化された結果に従って、推奨された修正に対して論理ツリーを検索する。例えば、メモリサイズの増大が推奨された修正であれば、推奨されたサイズは、前のモデル化された結果、ベンダー提供のベンチマーク、または業界標準の仕様のいずれかから得られる値である。このような修正は、１つまたは複数のサポートコンポーネントモデルを別のコンポーネントモデルに置き換えることを含んでもよい。
【００３３】
２２０において、検索により、システムアーキテクチャに対する推奨された修正を見出した場合、２３０において、グラフィクルユーザーインタフェースを介してシステム設計者に修正が提案され、容認を求める。
【００３４】
２４０において、システム設計者が提案された修正をすべて拒絶すれば、２１０において、論理ツリーが再度検索され、システムアーキテクチャに対する別の修正を見出す。２２０において、検索により別の推奨される修正を見出すことができなければ、２００において、システム設計者には、グラフィカルユーザーインタフェースを介して、許容外のビジネス性能メトリクスがビジネスプロセスデザインの欠陥により生じたことが通知される。プロセスは１１０に戻り、システム設計者にビジネスデザインモジュール１０のグラフィカルレイアウトインタフェースを提供し、それにより設計者はビジネスプロセスデザインを修正する。
【００３５】
２４０において、設計者が１つまたは複数の提案修正を容認すれば、２５０において、システムアーキテクチャのモデルは、容認された修正でアーキテクチャ構築モジュール２０により自動的に修正される。
【００３６】
システムアーキテクチャモデルを修正後、別のモデル化を実行するために、プロセスは再度１４０に戻って、プロセスを繰り返し、これを各ビジネスプロセスのモデル化された性能メトリクスがビジネス要求を満たすか、または、サポートハードウェアおよびソフトウェアコンポーネントモデルの性能メトリクスを、ビジネスプロセスデザインを変更することなくさらに改良することができなくなるまで繰り返す。
【００３７】
モデル化されたビジネス性能メトリクスがビジネス要求を満たすと、システムアーキテクチャのモデルは、システムアーキテクチャの詳細な記述にフォーマットされ、これを、１７０において、出力モジュール６０から出力する。
【００３８】
図４は、図１〜２Ｂの前述の実施形態による自動デザインプロセスから得られた情報システムのモデルベースのアーキテクチャを示す。モデルベースのアーキテクチャ４００の実施形態は、アプリケーションレイヤ４０５およびテクノロジーレイヤ４５０を含み、アプリケーションレイヤ４０５は、ビジネスアプリケーションレイヤ４１０と、アプリケーションバスレイヤ４２０と、アプリケーションサービスレイヤ４３０と、テクノロジーバスレイヤ４４０からなるサブレイヤに分割される。アプリケーションサブレイヤは、多数の処理原則、制約およびガイドラインを実行して、複雑かつ多次元・多機能の適時な重大なビジネスソルーションをサポートする拡張可能なシステムアーキテクチャを設計する。
【００３９】
１つの実施形態によれば、ソフトウェアコンポーネントモデルは、ビジネスアプリケーションレイヤ４１０またはアプリケーションサービスレイヤ４３０のいずれかに分離される。ビジネスアプリケーションレイヤ４１０およびアプリケーションサービスレイヤ４３０は、フロントエンド・クライアント処理およびバックエンド・サーバ処理をそれぞれ実行するソフトウェアコンポーネントを区別する。フロントエンド・クライアント処理は一般に、実時間および適時の重大な処理を含むのに対して、バックエンド・サーバ処理は一般に、延期可能なバッチ処理を含む。
【００４０】
ビジネスアプリケーションレイヤ４１０は、システム設計者によりビジネスプロセスに最初にマッピングされるか、または、図２Ａおよび図２Ｂに記述されたように、自動デザインプロセス中にそのモデルに置き換えられたビジネスアプリケーションコンポーネントモデルに埋め込まれる。ビジネスアプリケーションレイヤ４１０は、プレゼンテーションレイヤおよび（例えば、グラフィカルユーザーインタフェース）およびビジネス論理レイヤに細分でき、さらにセグメント化できる。
【００４１】
アプリケーションサービスレイヤ４３０は、モジュラサービスエンジン、一般ルーチン、クライアント特定ソフトウェアコンポーネントおよび揮発性ソフトウェアコンポーネントの集合体を含み、この集合体は特定のサービスを１つまたは複数のビジネスアプリケーションに提供する。エンジンは個別の機能を実行する１つまたは複数のプログラムを含む。１つの実施形態によれば、アプリケーションサービスレイヤ４３０のコンポーネントが待ち行列ベースとしてモデル化され、サービス要求の並列処理を可能にして、処理時間を実質的に短縮する。このレイヤでのアーキテクチャデザイン方式は、例えば、分散型、パイプフィルタ方式、バッチシーケンシャルおよび黒板方式であってよい。
【００４２】
システム設計者が最初に、ビジネスプロセスをビジネスアプリケーションにマッピングすると、アプリケーションサービスレイヤ４３０に、選択されたビジネスアプリケーションをサポートするデフォルトアプリケーションサービスが自動的に追加される。デフォルトアプリケーションサービスは、図２Ａおよび図２Ｂに記述されているように、自動デザインプロセス中に置き換えることができる。新しいアプリケーションサービスが要求されると、アプリケーションサービスレイヤ４３０は拡張可能である。
【００４３】
アプリケーションバスレイヤ４２０は、複数の通信サービスを提供することにより、ビジネスアプリケーションレイヤ４１０とアプリケーションサービスレイヤ４３０の分離を容易にする。レイヤ４１０、４３０にあるソフトウェアコンポーネント間でのすべての通信は、アプリケーションバスレイヤ４２０を介して要求する必要がある。モデル化された通信サービスには、コードおよびネットワーク通信プロトコル変換サービス（例えば、Ｊａｖａからコボル、ＴＣＰ／ＩＰからＳＮＡ）、分散サービス（例えば作業負荷を分散して、サーバの過負荷を防ぐ）、イベント、システムおよびトランザクション管理サービス（例えば、各レベルでの複数のサービス要求の順序付けおよび完全性を与える）、セキュリティサービス（例えば認証）、スクリプトフロー、コンフリクト解決、ロック処理、サービス要求のスケジューリングおよびディスパッチング（タスクに対して処理装置上の時間を割り当てること）を含むことができる。このような通信サービスはディレイ（delay）またはロック処理としてモデル化され、それにより情報システムの全体的な性能メトリクスに影響を与える。１つの実施形態によれば、アプリケーションバスレイヤ４２０は、メッセージ伝達およびＴＣＰ／ＩＰネットワーク通信プロトコルなどの通信ミドルウェアをモデル化する。
【００４４】
ソフトウェアコンポーネントをビジネスアプリケーション４１０とアプリケーションサービス４３０レイヤとに分離することにより、ソフトウェアコンポーネントの再利用および分散が行われる。再利用および適正な分散により、メンテナンスおよび開発コストが低減され、製品の配信速度が上がる。さらに、アプリケーションサービスレイヤ４３０内のサービスを混乱させることなく、ビジネスアプリケーションレイヤ４１０内でカスタマイズが可能である。
【００４５】
テクノロジーレイヤ４５０は、ビジネスアプリケーションおよびアプリケーションサービスが展開される物理ハードウェアのハードウェアコンポーネントモデルおよびオペレーティングシステムを提供する。このようなハードウェアの典型的な例には、データ記憶装置、処理ユニットおよびエンジン、ルーター、スイッチ、および他のネットワークデバイスを含む。特定のハードウェアコンポーネントは、自動デザインプロセスの予測モデル化、比較および修正ステージの間に決定される。
【００４６】
テクノロジーバスレイヤ４４０が、テクノロジーレイヤ４５０をアプリケーションレイヤ４１０、４３０から隔離して、テクノロジー特定のアーキテクチャを回避する。１つの実施形態によれば、テクノロジーバスレイヤ４４０は、データアクセスまたはテクノロジーサービスに対して抽象インタフェース（例えば、Ｊａｖａ（商標）仮想機械）をモデル化する。テクノロジーバスレイヤ４４０をモデルに組み込むことにより、その結果得られるシステムアーキテクチャは、ハードウェアコンポーネントの特定のセットに固有のものでなくなる。したがって、テクノロジーバスレイヤ４４０への移植性が最大になることにより、コードを新しいハードウェアプラットフォームに実質的に移植することなく、テクノロジーレイヤ４５０の物理ハードウェアを置き換えることができる。さらに、テクノロジーバスレイヤ４４０は、レベル補償、ネットワークプロトコル変換、暗号化および接続管理サービスを提供する。
【００４７】
当業者には、情報システムのモデルベースのアーキテクチャを設計する自動システムおよび方法に含まれるプロセスが、コンピュータ使用可能媒体を含む製品で具体化できることが認識されるであろう。例えば、このようなコンピュータ使用可能媒体には、ハードドライブデバイス、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、コンピュータディスケットまたは固体メモリコンポーネント（ＲＯＭ、ＲＡＭ）などのような、コンピュータ読取り可能なプログラムコードセグメントが格納された、読取り可能なメモリデバイスを含むことができる。コンピュータ読取り可能な媒体にはまた、例えば、ディジタルまたはアナログデータ信号のようなプログラムコードセグメントを伝送する光学、有線または無線のいずれかのバスまたは通信リンクのような通信または伝送媒体を含むことができる。
【００４８】
本発明を好ましい実施形態により図示し、説明してきたが、当業者には、添付の特許請求の範囲に定義された本発明の範囲から逸脱することなく、形態または細部に各種の変更を加えるのが可能であることは理解されるであろう。
【図面の簡単な説明】
【図１】本発明の１つの実施形態にかかるモデルベースのアーキテクチャを設計する自動システムの機能モジュールを示す。
【図２Ａ】図１の実施形態を用いて、モデルベースのアーキテクチャを設計するための自動デザインプロセスのフローチャートを示す。
【図２Ｂ】図１の実施形態を用いて、モデルベースのアーキテクチャを設計するための自動デザインプロセスのフローチャートを示す。
【図３】 1つ実施形態によるビジネスプロセスデザインのグラフィカルレイアウトを示す図である。
【図４】図１、図２Ａおよび図２Ｂの実施形態にかかる自動デザインプロセスから得られる情報システムのモデルベースのアーキテクチャを示す。

Claims

ビジネスソリューションを実現するシステムアーキテクチャであって、モデルベースのシステムアーキテクチャを生成するようにコンピュータシステムを作動させる方法であって、
複数のビジネスプロセスはアイコンで記述し、それらの相互作用の流れはリンクで記述するグラフィカルレイアウトからなるビジネスプロセスデザインであって、各ビジネスプロセスに対して、ビジネスにおける制約およびビジネスプロセスが受け取ると予測される作業負荷からなる、ビジネス要求セットを定義するビジネスプロセスデザインを入力させるために、システム設計者にグラフィカルレイアウトインタフェースを提供するステップと、
前記ビジネスプロセスデザインに対応するシステムアーキテクチャについてのマルチレイヤモデルを、前記コンピュータシステムに構築させるステップであって、該モデルの層が、前記ビジネスプロセスデザインを含むビジネスレイヤと、前記ビジネスプロセスデザインを支援するソフトウェアコンポーネントを含むアプリケーションレイヤと、前記ビジネスプロセスデザインを支援するハードウェアコンポーネントモデルを含むテクノロジーレイヤとからなり、デフォルトのハードウェアコンポーネントモデルおよびソフトウェアコンポーネントモデルのセットにそれぞれ連結されて予めモデル化されたビジネスアプリケーションの選択可能なリストを、前記システムが提供する、ステップと、
前記コンピュータシステムが、さらに、前記システムアーキテクチャのマルチレイヤモデルの各レイヤについての性能メトリクスの値を計算する、ステップと、
前記計算された性能メトリクスの値を、各ビジネスプロセスの前記ビジネス要求セットにおける対応するビジネス制約の値と比較して、前記性能メトリクスが前記ビジネス制約を満たさない場合はその性能メトリクスを許容外の性能メトリクスと認定し、ビジネスプロセスに対して定義された前記ビジネス要求セットを満たさない１つまたは複数のビジネスプロセスの許容外の性能メトリクスの表示を生成する、ステップと、
前記許容外の性能メトリクスを有する前記１つまたは複数のビジネスプロセスを支援する、前記アプリケーションレイヤおよびテクノロジーレイヤ内のコンポーネントモデルを識別する、ステップと、
前記識別されたコンポーネントモデルについての性能メトリクスを評価した後に、前記システムアーキテクチャに対して修正することを決定する、ステップと、
前記アプリケーションレイヤおよび前記テクノロジーレイヤ内のコンポーネントモデルの許容外の性能メトリクスを許容外ではない性能メトリクスに変更するように、前記コンピュータシステムのデータ記憶装置に含まれるハードウェアコンポーネントモデルおよびソフトウェアコンポーネントモデルの性能メトリクスを修正のために調べる、ステップと、
前記アプリケーションレイヤと前記テクノロジーレイヤ内のコンポーネントモデルのいずれかが許容外の性能メトリクスを持つ場合、グラフィカルユーザインタフェースを介して、許容外の性能メトリクスを持つコンポーネントモデルの変更を提案し、
前記アプリケーションレイヤと前記テクノロジーレイヤ内のコンポーネントモデルのいずれもが許容外の性能メトリクスを持たない場合、前記ビジネスプロセスデザインを修正するように、前記システム設計者に、前記グラフィカルレイアウトインタフェースを提供する、ステップとを備えた方法。
請求項１において、さらに、
前記許容外の性能メトリクスを持つコンポーネントモデルの変更が提案されると、
前記提案された変更で前記システムアーキテクチャのモデルの各レイヤに対して更新された性能メトリクスの値を計算するステップと、
前記更新された性能メトリクスの値を、各ビジネスプロセスに対して定義された前記ビジネス要求セットにおける対応するビジネス制約の値と比較するステップと、
前記更新された性能メトリクスが前記ビジネス要求セットを満たす場合、前記システムアーキテクチャの記述を出力するステップとを備えた方法。
請求項１において、前記１つまたは複数のサポートコンポーネントモデルの許容外の性能メトリクスを変更するための修正が、前記識別された１つまたは複数のコンポーネントモデルを、前記コンピュータシステムの前記データ記憶装置に記憶された別のコンポーネントモデルと置き換えることを含む、方法。
請求項１において、前記システムアーキテクチャのマルチレイヤモデルを構築するステップが、
グラフィカルユーザインタフェースを提供し、このインタフェースを介して、各ビジネスプロセスに前記アプリケーションレイヤ内のアプリケーションコンポーネントモデルを割り当てることを受け付けるステップであって、各アプリケーションコンポーネントモデルが、前記アプリケーションコンポーネントモデルを支援するアプリケーションレイヤおよびテクノロジーレイヤ内の１つまたは複数のコンポーネントモデルにリンクされている、ステップと、
前記割り当てに従って、前記マルチレイヤモデルを生成する、ステップとを備えた方法。
請求項４において、前記アプリケーションレイヤはさらに、テクノロジーバスレイヤを備えており、このテクノロジーバスレイヤは、前記アプリケーションレイヤおよびテクノロジーレイヤにおいてモデル化されたコンポーネント間のデータアクセスまたはテクノロジーサービスに対する仮想インタフェースをモデル化したものである、方法。
請求項４において、前記アプリケーションレイヤはさらに、アプリケーションバスレイヤを備えており、このアプリケーションバスレイヤは、該アプリケーションレイヤ内のアプリケーションコンポーネントモデル間の通信、分散および管理インタフェースをモデル化したものである、方法。
請求項４において、前記アプリケーションレイヤ内のアプリケーションコンポーネントモデルは、ビジネスアプリケーションレイヤおよびアプリケーションエンジンレイヤに細分されており、前記ビジネスアプリケーションレイヤが、実時間または適時の処理を実行するアプリケーションコンポーネントのモデルを備え、前記アプリケーションエンジンレイヤが、延期可能な処理を実行し、かつ該ビジネスアプリケーションレイヤ内の１つまたは複数のアプリケーションコンポーネントに対応するアプリケーションコンポーネントのモデルを備える、方法。
請求項４において、ビジネスプロセスに対応するコンポーネントモデルの組み合わせが変更されて、ビジネスプロセスの許容外の性能メトリクスが、許容外ではない性能メトリクスに変更される、方法。
ビジネスソリューションを実現するシステムアーキテクチャを設計するコンピュータシステムであって、
複数のビジネスプロセスはアイコンで記述し、それらの相互作用の流れはリンクで記述するグラフィカルレイアウトからなるビジネスプロセスデザインであって、各ビジネスプロセスに対して、ビジネスにおける制約およびビジネスプロセスが受け取ると予測される作業負荷からなる、ビジネス要求セットを定義するビジネスプロセスデザインを受け取るグラフィカルレイアウトインタフェースであって、予めモデル化されたビジネスアプリケーションの選択可能なリストを提供する、インタフェースと、
前記ビジネスプロセスデザインに対応するシステムアーキテクチャのマルチレイヤモデルを、当該コンピュータシステムに構築する手段であって、前記マルチレイヤモデルのレイヤが、前記ビジネスプロセスデザインを含むビジネスレイヤと、前記ビジネスプロセスデザインを支援するソフトウェアコンポーネントを含むアプリケーションレイヤと、前記ビジネスプロセスデザインを支援するハードウェアコンポーネントモデルを含むテクノロジーレイヤとを含む、手段と、
前記システムアーキテクチャのマルチレイヤモデルの各レイヤに対して性能メトリクスの値を計算する、手段と、
前記計算された性能メトリクスの値を、各ビジネスプロセスに対するビジネス要求セットにおける対応するビジネス制約の値と比較する手段であって、前記性能メトリクスが前記ビジネス制約を満たさない場合はその性能メトリクスを許容外の性能メトリクスと認定する、手段と、
前記許容外の性能メトリクスを有する前記１つまたは複数のビジネスプロセスを支援する、前記アプリケーションレイヤおよびテクノロジーレイヤ内のコンポーネントモデルを識別する、手段と、
前記識別されたコンポーネントモデルについての性能メトリクスを評価した後に、前記システムアーキテクチャに対して修正することを決定する、手段と、
前記アプリケーションレイヤおよび前記テクノロジーレイヤ内のコンポーネントモデルの許容外の性能メトリクスを許容外ではない性能メトリクスに変更するように、前記コンピュータシステムのデータ記憶装置に含まれるハードウェアコンポーネントモデルおよびソフトウェアコンポーネントモデルの性能メトリクスを修正のために調べる、手段と、
前記アプリケーションレイヤと前記テクノロジーレイヤ内のコンポーネントモデルのいずれかが許容外の性能メトリクスを持つ場合、グラフィカルユーザインタフェースを介して、許容外の性能メトリクスを持つコンポーネントモデルの変更を提案し、または、デフォルトのハードウェアおよびソフトウェアのコンポーネントモデルのセットにそれぞれ連結されている、予めモデル化されたビジネスアプリケーションの選択可能なリストを提供する、出力手段であって、さらに、
前記アプリケーションレイヤと前記テクノロジーレイヤ内のコンポーネントモデルのいずれもが許容外の性能メトリクスを持たない場合、前記ビジネスプロセスデザインが修正されるべきであることを、システム設計者に通知するように、グラフィカルレイアウトインタフェースを提供する、出力手段とを備えた、コンピュータシステム。
請求項９において、
前記性能メトリクスを調べる手段が、さらに、前記提案された変更により、前記システムアーキテクチャのモデルの各レイヤに対して、更新された性能メトリクスの値を計算し、
前記比較手段はさらに、前記更新された性能メトリクスの値を、各ビジネスプロセスのビジネス要求セットにおける対応するビジネス制約の値と比較し、
前記出力手段はさらに、前記更新された性能メトリクスがビジネス要求セットを満たす場合、システムアーキテクチャの記述を出力するシステム。
請求項９において、前記データ記憶装置は、別のコンポーネントモデルを保持し、前記アプリケーションレイヤおよびテクノロジーレイヤの許容外の性能メトリクスを、許容外ではない性能メトリクスに変更することが、該１つまたは複数の対応するコンポーネントモデルを前記別のコンポーネントモデルと置き換えることを含む、システム。
請求項９において、前記構築手段は、各ビジネスプロセスに、前記アプリケーションレイヤ内のアプリケーションコンポーネントモデルを割り当て、各アプリケーションコンポーネントモデルが、該アプリケーションコンポーネントモデルに対応するアプリケーションおよびテクノロジーレイヤ内の１つまたは複数のコンポーネントモデルにリンクされている、システム。
請求項１２において、前記アプリケーションレイヤはさらに、テクノロジーバスレイヤを含み、このテクノロジーバスレイヤは、前記アプリケーションレイヤおよびテクノロジーレイヤにおいてモデル化されたコンポーネント間のデータアクセスまたはテクノロジーサービスに対する仮想インタフェースをモデル化したものである、システム。
請求項１２において、前記アプリケーションレイヤはさらに、アプリケーションバスレイヤを含み、このアプリケーションバスレイヤは、該アプリケーションレイヤ内のアプリケーションコンポーネントモデル間の通信、分散および管理インタフェースをモデル化したものである、システム。
請求項１２において、前記アプリケーションレイヤにあるアプリケーションコンポーネントモデルは、ビジネスアプリケーションレイヤおよびアプリケーションエンジンレイヤに細分され、該ビジネスアプリケーションレイヤが、実時間または適時の処理を実行するアプリケーションコンポーネントのモデルを含み、該アプリケーションエンジンレイヤが、延期可能な処理を実行し、かつビジネスアプリケーションレイヤ内の１つまたは複数のアプリケーションコンポーネントに対応するアプリケーションコンポーネントのモデルを含むシステム。
コンピュータ上で実行されると、請求項１から８のいずれか一項に記載のステップを実現する、モデルベースのシステムアーキテクチャを設計する命令を含むコンピュータ動作命令のセットを備えた、コンピュータプログラム。