JP5775255B2 - 統合設計アプリケーション - Google Patents

Description

本発明は、複合アプリケーションシステムを設計するためのプロセスおよびシステムに関する。

デジタル通信サービス（例えば、ウェブサービス）を提供するビジネスの人気の高まりによって、トランザクションの種々のホストの機能性を提供することができる堅牢で洗練されたシステムが開発されてきた。これらのシステムは、典型的には、論理層、ハードウェア層、およびプロセス層のいくつかの組み合わせを含む、１つまたは複数の層にまたがって想到される場合が多い。さらに、これらのシステムは、すべてが連携して作動する、遠距離（論理的にも物理的にも）にわたって分布させたコンピュータ化ハードウェア装置の複合物としてしばしば実装される。したがって、ビジネス目的を正確にかつ一貫して達成するようにこれらの多層分配システムを設計する困難性は、拡大する要件を満たすと同時に進歩したシステムコンポーネントに起因するコストを管理する複雑さを反映するようになっている。

この要件に対処することに応答して、技術アーキテクチャの分野が開発されてきた。アーキテクチャのこの特定分野における主な課題は、目的の所与の組を１つまたは複数の適切なビジネスプロセスで正確に獲得すること、また、プロセスを成功裡にかつ効率的に実行するのに必要な基礎的な物理的インフラストラクチャを用いてそれらプロセスを実現することである。大型で複雑なシステムでは、単一のシステム設計が、システムの各層のビュー、例えば、システムコンポーネントの配置、システムがその実行時に行うプロセス、および使用される実際のシステムコンポーネントを含むことがある。これらのシステムは「複合アプリケーションシステム」とも称される。

上述したように、複合アプリケーションシステムは、１つもしくは複数の用途および／または目的向けに設計されてもよい。これらの用途（および／または目的）としては、一般に、例えば、１つまたは複数の動作を行うこと、１つまたは複数のシステム目標を達成すること、特定の仕様を守ること、特定のアプリケーション要件を満たすこと、あるいはそれらの何らかの組み合わせが挙げられる。設計プロセスは、典型的には、１つまたは複数の設計用途を行うためのソリューションを観念化することを含む。観念化したソリューションとは、複合アプリケーションシステムを対象とした１つまたは複数の用途（および／もしくは目的）を潜在的に達成する（または最も合理的に近付ける）方策および／または設計方法論を表す。

当然ながら、設計プロセスは、専門分野をそれぞれが持つ複数の共同制作者の労力を伴うことがある。残念なことに、利害の相反、予算の問題、あるいは単に連絡不良によって、共同制作者同士のずれが生じることがある。設計におけるビジネスモデルとその基礎的インフラストラクチャとの間の不整合は、システムの非能率、次善のまたはそれに満たない性能、ビジネス目標を達成するには絶望的な失敗に結び付く場合がある。デバッグ、他の共同制作者との連絡、および不整合を補正するためのシステムの再設計に、貴重な時間が費やされることがある。これにより、結果として、設計されたシステムのコストと性能の両方が予測可能性を欠くことがある。それに加えて、システムの寿命を通じて悪化する非能率による、またはシステムコンポーネントを再構築し再供給することによる経済的損失が、莫大なものとなる可能性がある。

ビジネスシステム設計における不整合は、資源の供給不良（過剰供給または不足供給のいずれか）をもたらすことがある。過剰供給は、アプリケーション要件を達成するのに実際に必要とされるよりも多くの資源を有するコンポーネントでシステムが設計されているときに生じ、多くの場合、他の適切なコンポーネントまたは組み合わせよりも高いコストがかかり、財源の無駄につながる。予算が厳しいかまたは限られている設計プロジェクトの場合、１つのコンポーネントの過剰供給が予算上の制約に結び付き、それによってシステムの他の領域における供給がより安価なものに制限され、コンポーネントの能率が低下し、結果として、設計によって求められるレベルで動作することができなくなる（不足供給）。また、過剰供給ならびに不足供給は両方とも、ビジネス目的の連絡不良またはシステムコンポーネントの誤解によって起こることがある。

技術アーキテクチャの現行の実践において存在する困難をさらに増幅するのは、直接のツール支援と設計の統一規格とが両方とも不足していることである。直接のツールと統一規格の組の不足は、共同作業の不整合につながることがあり、それが次に、設計品質の一貫性のなさ、設計フォーマットの互換性のなさ、および地域間、企業間、個人間、さらには設計プロジェクト同士での表現の矛盾をもたらすことがある。典型的な設計プロセス内では、設計への貢献者は、既存のアプリケーション、および／または様々な既存のツールセットからのアプリケーションのホストを利用してもよい。例としては、文書処理、コンピュータ支援の作図、電子メール、スプレッドシート、ソフトウェア構造管理、およびファイル転送プロトコル向けに特別に製作されたアプリケーションが挙げられる。

共同作業の不整合の一例としては、一人の共同制作者によって文書内のテキストとして表現されるシステム設計の一コンポーネントの表現を挙げることができるが、別の共同制作者は、別のコンポーネントを図表として表すことを選んでもよい場合がある。すべての設計プロジェクトに対する標準の枠組みを確立すること、および／または一致しない表現を併合し合致させることに、貴重な時間と協調のための労力とが費やされることがある。さらに、現在、コンポーネントおよび設計ビューにまたがる関係の明示的な視覚化を支援する、周知のまたは普及しているアプリケーションは存在しない。

さらに、設計のコピーが共同制作者間で分配される、共同制作者が多数いるシステムでは、システム設計の最新バージョンを特定するのが困難なことがある。共同制作者の一人または複数は、ローカルに格納されたコピーに変更を実装することがあり、それによって結果的に、修正の併合が困難で時間のかかるものになることがあり、分配されローカルに格納されたコピーの自動併合により、修正の一部またはすべてを失うリスクを冒すことがある。

最後に、統一規格がないことによって、各システムがアドホックな非標準の設計によって想到されることにつながる場合が多いため、標準化されたツール支援がないことで、以前の作業成果物を効率的に再使用するのも困難になっている。熟練したシステム設計者は、設計者がテンプレートとして使用してもよい、格納された作業のバックログを有することがあるが、統一規格またはツールがないことで、設計者個人の作業に対する参照が制限されることがある。慣れておらず経験の少ない設計者はそのような資源へのアクセスを持たないことがある。

この概要は、以下の「発明を実施するための形態」にて詳述する概念の選択を単純化した形態で紹介するためのものである。この概要は、請求する主題の主要な特徴または必須の特徴を特定するものではなく、また、請求する主題の範囲を制限するために使用するものでもない。

実施形態は統合設計アプリケーションを対象とする。特に、複合アプリケーションシステムを設計するためのシステムである。実施形態は、組み合わされると情報技術アーキテクチャを形成するハードウェアツおよびソフトウェアツールを、選択し構成するための視覚的ツールを扱う。様々な実施形態によって提供される機能性としては、次のものが挙げられる（ただし、それらに限定されない）。設計に含まれるプロセスの複数のビューをユーザに提供すること、これらのビュー同士の関係をユーザが明示的に作成し表示させることができるようにすること、開始日および終了日を含めて計画された容量負荷をユーザが指定できるようにすること、それらの負荷の時間スケール（毎日、一時間ごと、毎週など）をユーザが指定できるようにすること、対応する目標基準値を技術的または論理的プロセスに割り当てられるようにすること、ならびに、その推定性能が目標基準値に対応するインフラストラクチャ内での関係を特定できるようにすること。

一実施形態では、１つまたは複数のアプリケーション要件を満たすように複合アプリケーションシステムを設計するプロセスが提供される。そのプロセスにしたがって、複合アプリケーションシステムは単一のソフトウェアアプリケーション内で設計される。複合アプリケーションシステムは、１つまたは複数のアプリケーション要件を満たすように観念化された複合アプリケーションシステムによって行われる、１つまたは複数のユースケースシナリオを定義することによって設計される。アプリケーション要件は、所要出力が目標基準値として指定される容量情報として指定されたシステム負荷の関数として獲得される。１つまたは複数のユースケースシナリオが定義されると、次に、１つまたは複数のユースケースシナリオが１つまたは複数の実行ツールと統合される。１つまたは複数の実行ツールを具体化する基礎的インフラストラクチャは、システム要件を達成するように特定され選択される。

本明細書に組み込まれ、その一部を成す添付図面は、本発明の実施形態を例示し、本書と併せて本発明の原理を説明する役割を果たす。

一実施形態による、複合アプリケーションシステムを設計するための統合設計アプリケーションのコンポーネント図である。 一実施形態による、複合アプリケーションシステムを設計するプロセスを示すフローチャートである。 一実施形態による、システム設計用の基礎的インフラストラクチャを指定するプロセスを示すフローチャートである。 一実施形態による、本発明の実施形態が実装されてもよい代表的なコンピュータシステムを示すブロック図である。 一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、ユースケースシナリオを定義する代表的なユーザインターフェースを示す図である。 一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、ユースケースを実行ツールと統合する代表的なユーザインターフェースを示す図である。 一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャを指定する代表的なユーザインターフェースを示す図である。 一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、ユースケースシナリオ内の技術プロセスと実行ツールとの関係をマッピングするユーザインターフェースを示す図である。 一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、ユースケースシナリオのコンポーネントと基礎的インフラストラクチャのコンポーネントとの関係をマッピングするユーザインターフェースを示す図である。 図１０Ａは、一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャの容量データを定義するユーザインターフェースを示す図、図１０Ｂは、一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャの目標基準値データを定義するユーザインターフェースを示す図である。 一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャの容量データおよび目標基準値データを適用するユーザインターフェースを示す図である。 一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャの容量データおよび目標基準値データを適用する代替のユーザインターフェースを示す図である。 一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャ中の選択されたオブジェクトに対応する代表的な性能ファイルを示す図である。 一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャ中の選択されたオブジェクトの容量負荷データおよび性能基準値データに対応する代表的な比較インターフェースを示す図である。 一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャのレイアウト内の選択されたオブジェクトに対応する代表的な容量および基準値表示を示す図である。

以下、いくつかの実施形態について詳細に言及していく。代替実施形態と併せて主題について記載していくが、請求する主題をこれらの実施形態に限定するものではないことが理解されるであろう。反対に、請求する主題は、添付の特許請求の範囲によって規定されるような請求する主題の趣旨および範囲に含むことができる代替例、修正例、および均等物を包含するものである。

さらに、以下の詳細な説明では、請求する主題の完全な理解を提供するため、多数の特定の詳細について説明している。しかしながら、当業者であれば、これらの特定の詳細なしに、またはその均等物を用いて実施形態が実施されてもよいことを認識するであろう。他の例では、主題の態様および特徴が不必要に曖昧にならないように、周知の方法、手順、コンポーネント、および回路は詳細に記載していない。

以下の詳細な説明部分は、方法の観点において提示し検討する。ステップおよびそれらの順序付けは、この方法の動作を説明する本明細書の図面（例えば、図２および３）に開示しているが、そのようなステップおよび順序付けは例示である。実施形態は、他の様々なステップ、または本明細書の図面のフローチャートに列挙したステップの変型例を、本明細書にて描写し記載する以外の順序で行うのに十分に適している。

詳細な説明の一部は、コンピュータメモリ上で行うことができる手順、ステップ、論理ブロック、処理、および、データビットに対する演算の他の記号表現の観点から提示される。これらの記載および表現は、データ処理分野の当業者が、自身の作業の実質を他の当業者に最も効率的に伝達するために使用する手段である。手順、コンピュータ実行ステップ、論理ブロック、プロセスなどは、本明細書では、また一般的に、所望の結果につながるステップまたは命令の筋が通ったシーケンスであるものと解釈される。ステップは、物理量の物理的な操作を必要とするものである。必須ではないが、通常、これらの量は、コンピュータシステム内で、格納、転送、結合、比較、または別の形で操作することができる、電気信号または磁気信号の形態をとる。場合によっては、主に共通の用法上の理由から、これらの信号を、ビット、値、エレメント、符号、文字、用語、数値などと称することが便利であることが分かっている。

しかしながら、これらおよび類似の用語は、適切な物理量と関連付けられるものであり、これらの量に付けられる便利なラベルに過ぎないことを念頭に置いておくべきである。特段の規定がない限り、以下の考察から明白なように、考察全体を通して、「アクセスする」、「書き込む」、「含む」、「格納する」、「送信する」、「横断する」、「関連付ける」、「特定する」などの用語の利用は、コンピュータシステムのレジスタおよびメモリ内で物理（電子）量として表されるデータを操作し、コンピュータシステムのメモリもしくはレジスタ、またはそのような他の情報記憶、伝送、もしくは表示装置内で、物理量として同様に表される他のデータへと変形する、コンピュータシステムまたは類似の電子計算装置の動作およびプロセスを指すことが理解される。

以下の実施形態では、複合アプリケーションを設計するための統合設計アプリケーションを提供する方策について記載する。実施形態は、設計に含まれるプロセスの複数のビューをユーザに提供し、これらのビュー同士の関係をユーザが明示的に作成し表示させることができるようにし、容量負荷情報および目標基準値を技術的プロセスに割り当て、指定した負荷の目標基準値にその性能が一致または近似するインフラストラクチャのコンポーネントを選ぶことができるようにする、複合アプリケーションを設計するための方法およびシステムを提案する。

統合設計アプリケーション
次に、図１を参照すると、一実施形態による、複合アプリケーションシステムを設計するための統合設計アプリケーション１００のコンポーネント図が示される。典型的な構成では、統合設計アプリケーション１００は、クライアントアプリケーション１０１、ビジネスロジックコンポーネント１０３、およびバックエンド記憶コンポーネント１０５を含む。

一実施形態によれば、統合設計アプリケーション１００のユーザ１１１は、クライアント装置１１３を通して統合設計アプリケーション１００の機能性にアクセスする。クライアント装置１１３は、統合設計アプリケーション１００のインターフェース１１５がユーザ１１１によって実装されアクセスされる環境であってもよい。いくつかの実施形態では、複数の分散したユーザは、インターフェース１１５の複数のローカルにインストールされたコピーを介して統合設計アプリケーション１００の機能性にアクセスするため、複数のクライアント装置を利用してもよい。

一実施形態では、統合設計アプリケーション１００のインターフェース１１５により、複合アプリケーションシステム設計をユーザ１１１が操作する（例えば、作成する、獲得する、提供する、説明するなど）ことができるようになる。インターフェース１１５により、例えば、ユーザ１１１が、１つまたは複数のケースシナリオを行う様々な属性を有する複数のコンポーネントを提供することによって複合アプリケーションシステムを設計し、コンポーネント間の関係を表し、様々な基準値にしたがって、設計したシステムおよび特定のコンポーネントの性能をシミュレートすることができるようになる。インターフェース１１５はまた、システムの要件または目的とより正確に協調するように、ユーザ１１１が設計を表示させかつ修正を行う（すなわち、１つもしくは複数の代わりのコンポーネントを提供することによる）ことができるように実装されてもよい。

インターフェース１１５はまた、複数の設計「層」にわたって複合アプリケーションシステム設計を獲得（すなわち、包括的に表す）してもよい。例えば、設計または設計の一部は、プロセス層（例えば、システムによって行われる機能）、論理層（例えば、機能を行うのに必要な情報および／もしくは技術ツール）、および物理層（例えば、機能を行うツールとして使用するのに選択された、実際の具体的に特定された装置）にわたって表されてもよい。代替実施形態では、複合アプリケーションシステム設計を含む層の数は、上記に具体的に列挙した３つの層に限定されない（例えば、他の層としては、仮想化したインフラストラクチャを示す仮想化層、および関与するソフトウェアアプリケーションの相互作用を示すアプリケーション層を挙げることができる）。そのような実施形態によれば、ユーザ１１１は、設計を表すのに任意の数の層を割り付け、指定してもよい。

複合アプリケーションシステムを設計するための従来の技術は、各層を別々に表す１つまたは複数の独立した別個のプラットフォームおよび設計アプリケーションを使用することによって、複数の設計層にわたってシステムを設計することを含むことがあるが、統合設計アプリケーション１００によって、設計内の各層を独立に、かつ単一のアプリケーションおよびインターフェース１１５内の複数の層の組み合わせとして、ユーザ１１１が表示させることができるようになる。さらに、統合設計アプリケーション１００における複合アプリケーションシステム設計を含む複数の層はそれぞれ、ユーザ定義の相関を行うことができるので、統合設計アプリケーション１００全体にわたってコンポーネント（例えば、ツール、関係、およびケースシナリオ）の相互参照が可能である。したがって、各コンポーネントに関してシステムに対する総合的な影響が、統合設計アプリケーション１００のインターフェース１１５を介してユーザ１１１に対して視覚的に表されてもよい。

インターフェース１１５はまた、異種の貢献者からの素材をプロジェクトに相関させる、過去の作業をテンプレートとして活用する、基準値データを割り当てて表示する、または設計（もしくは設計の特定部分を含むファイル）をパッケージ化して受信者に転送する機能性を含んでもよい。異種の貢献者からの素材をプロジェクトに相関させることは、例えば、１つまたは複数の同じファイルの合致しないバージョン同士の機能性を併合させることを含んでもよい。併合プロセス中に発見された矛盾する項目は、インターフェース１１５を通して、併合しているユーザに対して表示されてもよい。これらの実施形態内では、ユーザは、同じ項目の２つの矛盾するバージョンを併合する結果を指示することができてもよい。

インターフェース１１５はまた、メッセージ通信などの通信機能性を提供することによって、異種の貢献者からの素材をプロジェクトに相関させてもよい。例えば、ユーザ１１１は、１つもしくは複数の注記（または他の文字／図形による表示）をファイルに、またはファイル内の特定オブジェクトに付けることができてもよい。追加の相関機能性としては、共同制作ユーザに対してドキュメンテーション機構を許可することが挙げられる。いくつかの実施形態では、ユーザはまた、ワードプロセッサ内の設計ドキュメンテーション、および他のテキストを包含するファイルタイプ（例えば、文書として）、スプレッドシート、またはグラフィック作図アプリケーションをエクスポートする（すなわち、複製し出力する）ことができてもよい。インターフェース１１５は、例えば、ローカルな記憶装置、またはバックエンド記憶装置コンポーネント１０５に格納された、格納された既存のアーキテクチャ（例えば、設計、または設計の一部）にアクセスし、それを表示することによって、過去の作業をテンプレートとして活用してもよい。

典型的には、設計は、総称的にプロジェクトと呼ばれ、かつ／またはプロジェクトとして区別される、１つもしくは複数のファイルとして、クライアントアプリケーションにローカルに格納される。分散した共同制作者からの寄与を含むプロジェクトの場合、ユーザ１１１は、設計（または設計の一部）のローカルに格納されたバージョンを他のユーザに転送することができる。いくつかの実施形態では、ユーザは、他の共同制作者にアクセス可能な中央のリポジトリに設計を転送することができる。他の実施形態では、共同制作ユーザのクライアント装置はまた、ピアツーピアネットワーク内のノードとして動作する。そのような実施形態では、ファイルの転送は、中央のリポジトリに転送する代わりにクライアント装置間で直接行われてもよい。インターフェース１１５は、他の共同制作者との接続をユーザ１１１が開始することができるようにしてもよく、また、ファイルのソースおよび宛先のユーザ選択を許可してもよい。設計の転送は、全体的に（典型的には、プロジェクトを含むファイルをパッケージ化することによって）、または部分的に（１つもしくは複数の特定ファイルを転送する）行われてもよい。

いくつかの実施形態では、インターフェース１１５は、ユーザ１１１にアクセス可能な基礎的な機能性を提供する内蔵アプリケーションを含むように実装される。内蔵アプリケーションとしては、例えば、作図アプリケーションインターフェース、文書処理アプリケーション、スプレッドシートアプリケーション、ローカルな作業記憶機構用のローカルデータベース、およびシステム内のコンポーネント間の関係を図式的に表す１つまたは複数のビューイングアプリケーションを挙げることができる。代替実施形態では、作図アプリケーションインターフェース自体が、文書処理アプリケーションに類似した機能性を含んでもよく、かつ／または、システム内のコンポーネント間の関係を図式的に表す機構を含んでもよい。

いくつかの実施形態によれば、複合アプリケーションシステムの設計は、システムに関係する指定の入力負荷および出力基準値に従った特定のパラメータを含んでもよい。典型的な負荷情報は容量データによって特徴付けられる。この容量データとしては、例えば、ユーザセッションの数／サイズ、メッセージの数／サイズ、アクセスの頻度および時間単位での持続時間（例えば、時間、日、年など）を挙げることができる。典型的な出力基準値は、システム性能および／またはコストに関係がある。典型的には、負荷基準値は、出力基準値との直接的および／または間接的な相関を有する。負荷および基準値は、様々な実施形態に従ってあらかじめ定義されてもよいし、またはユーザによってカスタマイズ可能であってもよい。インターフェース１１５は、ユーザ指定のデータに従って基準値を入力するのに利用されてもよい。いくつかの実施形態では、ユースケースもしくはアプリケーションコンポーネントと関連付けられた負荷データ、および／または個別の特定された物理的コンポーネントに対応する基準値データは、外部供給源（例えば、バックエンド記憶コンポーネント１０５）から供給されてもよい。代替実施形態では、負荷および基準値データは、例えば、内蔵スプレッドシートアプリケーションでプログラムすることによって、ローカルにカスタマイズされ格納されてもよい。

ビジネスロジックコンポーネント１０３は、統合設計アプリケーション１００の１つまたは複数の分散したユーザ間での共同作業を容易にする。共同作業の容易化としては、例えば、中央の（「マスター」）バージョンを用いて、複数の分散したユーザのクライアント装置にローカルに格納された複合システム設計のバージョンを合理化することを挙げることができる。ビジネスロジックコンポーネント１０３は、中でも、高度の設計シミュレーションを提供する、外部データソースへのアクセスを許可する、容量負荷データを獲得するなど、追加の共同作業中心のサービスを提供してもよい。ビジネスロジックコンポーネント１０３としては、一実施形態では、互いに通信可能に結合された１つもしくは複数の計算装置（例えば、サーバ１２１）、１つもしくは複数のクライアント装置、または１つもしくは複数のクライアント装置によってアクセス可能なネットワークを挙げることができる。

一実施形態では、統合設計アプリケーション１００における設計プロジェクトの分散したユーザ間でのファイルの転送は、ビジネスロジックコンポーネント１０３によって行われる。プロジェクトまたはファイルの部分集合を別の共同制作者に転送（または、中央のバージョンを更新）しようとするユーザは、そのプロジェクト（またはファイルの部分集合）をビジネスロジックコンポーネント１０３に送信する。それに続いて、ビジネスロジックコンポーネント１０３は、これらのプロジェクトをアーカイブに保管またはバージョン管理してもよい。それに続き、権限を有するユーザには、プロジェクト（またはファイルの部分集合）の１つまたは複数のバージョンへのアクセスが許可されてもよい。

さらなる実施形態では、ビジネスロジックコンポーネント１０３は高度なバージョン管理機構を含む。例えば、ビジネスロジックコンポーネント１０３は、自動ドキュメンテーション、排他的チェックアウト、バージョン併合、バージョンのスナップショット、およびバージョンのロールバックなどの機構を実行してもよい。自動ドキュメンテーションは、ファイルの使用に対応するメタデータ（例えば、作成の日時、最後の修正など）を更新し、そのコンテンツを自動更新することを含む。排他的チェックアウトは、アクセスを設計プロジェクトの１つまたは複数のバージョンに制限する。例えば、チェックアウトが１人の共同制作者に制限される場合、ビジネスロジックコンポーネント１０３に格納された設計プロジェクトの１つまたは複数のバージョンがユーザ１１１によってアクセスされれば、設計プロジェクトの１つまたは複数のバージョンへのアクセスが終わる（すなわち、再提出される）まで、他のユーザは誰も設計プロジェクトの１つまたは複数のバージョンにアクセスすることができない。

いくつかの実施形態では、排他的チェックアウトは、そのバージョンに制限されてもよい（すなわち、他のユーザは、現在アクセスされていないバージョンにアクセスしてもよい）。代替実施形態では、チェックアウトが排他性を維持する時間の長さは持続期間に制限される。前記期間が終了すると、チェックアウト中のファイルへのアクセス制限が取り除かれる。

バージョン併合は、同じファイルの異なるコピーに対してなされた複数の変更を調停する。これらの変更が併合されて、変更の両方の組を含む単一の新しいファイルが得られる。いくつかの実施形態では、権限を有するユーザは、インターフェース１１５を利用して、同じ項目またはファイルの２つの矛盾するバージョンを併合する結果を指示することができる。併合は、１つまたは複数のユーザのインターフェース１１５に送信する前に、ビジネスロジックコンポーネント１０３内に実行されてもよい。併合するユーザはまた、中央のリポジトリに格納されたファイルのバージョンを、ビジネスロジックコンポーネント１０３内の併合されたバージョンを用いて更新してもよい。

バージョンのスナップショットは、更新または併合されているファイルのバージョンを保存する。一実施形態によれば、更新されている中央のリポジトリ内のファイルは、リネームされ、格納され、共同制作ユーザにアクセス可能なままであってもよい旧バージョンを有してもよい。同様に、バージョンのロールバックにより、プロジェクトへのアクセスを有する権限を有するユーザが、ファイルの現在のバージョンを旧バージョンに戻すことが可能になる。例えば、ファイルの現在の（すなわち、最も最近に更新された）マスターバージョンが旧バージョンに再変換されて、それがマスターバージョンになってもよい。

上述の特徴（すなわち、自動システムドキュメンテーション、排他的チェックアウト、バージョン併合、バージョンのスナップショット、およびバージョンのロールバック）それぞれについて、権限を有するユーザは、例えば、プロジェクトのすべての共同制作者を含んでもよく、またはプロジェクト内の特定のユーザに制限されてもよい。他の実施形態では、権限はプロジェクトのコンテンツに付与されてもよい。別の実施形態では、権限は１つまたは複数のファイルに具体的に制限されてもよい。排他的チェックアウト、バージョン併合、バージョンのスナップショット、およびバージョンのロールバックはすべて、様々な既知の実装を伴う当該技術分野において周知の特徴である。したがって、実装の詳細な説明は本明細書では省略するものとする。

バージョン管理データも、ビジネスロジックコンポーネント１０３によって明示的に獲得されてもよい。バージョン管理データとしては、例えば、プロジェクトに対する共同制作者の数、プロジェクト設計の持続時間中に発生するトランザクション（すなわち、ファイル送信）の数、通信（例えば、メッセージ）のサイズ、プロジェクトの期間中に行われる取引および／または通信の時系列的詳細（時刻、時期など）を挙げることができる。一部のバージョン管理データは、例えば、ファイルの中央バージョンにアクセスする身元（例えば、ＩＰアドレス、またはネットワーク内のユーザアカウント）の数をモニタすることによって得られてもよい。あるいは、一部の容量データも、ファイルの中央バージョンに対する修正（例えば、更新）の数をモニタすることによって得られてもよい。

さらなる別の実施形態では、ビジネスロジックコンポーネント１０３は、予測動作のモデリング、ランタイムの最適化、および実時間自動供給などの特徴に拡張してもよい。

バックエンド記憶コンポーネント１０５は追加の記憶機能性を提供する。バックエンド記憶コンポーネント１０５は、統合設計アプリケーション１００のユーザのためのバージョン管理を格納するリポジトリとして実装されてもよい。いくつかの実施形態では、バックエンド記憶コンポーネント１０５は、コンポーネントの属性のデータベース１３１を含む。例えば、データベース１３１は、コストおよび性能などの既知の属性を用いて、ベンダーおよび各ベンダーに対応する製品の知識ベースを格納してもよい。属性はベンダーが提供する情報を含んでもよい。さらなる実施形態では、バックエンド記憶コンポーネント１０５は、将来のシステムの性能を予測する際の活用のために、構成されたシステムの性能基準値を収集する。バックエンド記憶コンポーネント１０５はまた、テンプレートとして使用するためにユーザによって参照されてもよい既存のアーキテクチャを格納してもよい。

複数の（遠隔）貢献者からの素材を関連させる能力を提供することによって、統合設計アプリケーション１００は、複数のユーザ１１１が同じプロジェクトを共同制作する能力を提供する。さらに、共同制作は、貢献者内で直接、かつ設計の同じ段階または局面中に行うことができる。共同制作を組み込んだ従来の技術は、同時かつ並列での変更を除外し、かつ／または、異種の貢献者間の手動での変換を必要とすることがあるが、上述の特徴は、シームレスな共同制作および後に続くコンテンツの変換を容易にする追加の機能性を提供する。

複合アプリケーションシステム設計
図２は、一実施形態による、統合設計アプリケーションにおける複合アプリケーションシステムを設計するプロセスのフローチャート２００を示す。ステップ２０１〜２０５は、本明細書に記載する様々な実施形態によるプロセス２００を含む代表的なステップについて記述している。

ステップ２０１で、アプリケーションシステム設計のための観念化したソリューションの、１つまたは複数のユースケースシナリオを定義する。ユースケースは、システム内の挙動のシーケンスについて記述している。各ユースケースは、特定の目標を達成するためにアクター（すなわち、システムに刺激を供給する人またはオブジェクト）がどのようにシステムと対話するかについて記述している。１つまたは複数のシナリオが各ユースケースから生成されてもよく、これらのシナリオは目標を達成する利用可能な方法に対応する。

ユースケースシナリオは、多くの場合、ビジネスユースケースまたはシステムユースケースのどちらかとして特徴付けられる。ビジネスユースケースは、一般に、ビジネスアクターに値を提供するビジネスプロセスについて記述しており、典型的には、高次の技術専門用語を用いずに記述され、プロセスが何を行うかを記述している。システムユースケースは、通常、システム機能性レベルで記述され、システムがユーザに提供する機能またはサービスを指定する。システムユースケースは、アクターがシステムとの相互作用によって何を達成するかについて記述する。

観念化したソリューションについてのユースケースシナリオの定義は、機能を実行するためにシステムが到達するまたは行う段階、プログラム、動作、プロセス、および相互作用に関して、システムの機能性を描写するシナリオを定義することを含んでもよい。ユースケースは、例えば、特定の動作を実行するため、または意図される結果を達成するためにシステムが行う「ステップ」を含んでもよい。それに加えて、容量負荷および結果の目標基準値がユースケースと関連付けられてもよい。

ステップ２０３で、ステップ２０１にて定義された１つまたは複数のユースケースシナリオを、ステップ２０１にて定義されたユースケースシナリオを実行するための適切な情報技術ツールに統合する。これらの情報技術ツールは、ユースケースシナリオを行うのに必要な技術（例えば、コンポーネント、装置）およびアプリケーション（ソフトウェア）から成る。例えば、単純なウェブベースのビジネスは、１つまたは複数の通信技術コンポーネント（例えば、ルーター）に結合された１つまたは複数の記憶／処理コンポーネント（例えばサーバ）上で実行する、１つまたは複数のソフトウェアプラットフォームを介してサービスを提供することを含んでもよい。

ステップ２０５で、複合アプリケーションシステムを含む基礎的インフラストラクチャを指定する。複合アプリケーションシステムを含む基礎的インフラストラクチャの指定は、１つまたは複数の実行ツールを具体化する特定のハードウェアおよびソフトウェアウエアコンポーネントを特定することを含んでもよい。基礎的インフラストラクチャの指定はまた、典型的には、システム目標を最適に達成する（すなわち、最大の効率および／または効力で）ハードウェアおよびソフトウェアウエアコンポーネントの組み合わせを指定することを含む。基礎的インフラストラクチャの指定はまた、実際に達成することが現実的でないシステム目的の達成に最良に近似する、ハードウェアおよびソフトウェアウエアコンポーネントの組み合わせを特定することを含んでもよい。

図２によるシステムは、３つのモデル層に従って設計されているが、システム設計はこれら３つの代表的なモデル層に制限されないことを理解されたい。より正確に言えば、モデル層の数は使用法および実施形態の両方によって変更してもよい。

基礎的インフラストラクチャの指定
図３は、一実施形態による、ステップ２０５で検討したような複合アプリケーションシステム設計の基礎的インフラストラクチャを指定する方法のフローチャート３００を示す。

ステップ３０１で、設計された複合アプリケーションシステムの基礎的インフラストラクチャの性能を推定する。一実施形態によれば、システム設計の性能の推定は、コンポーネントアプリケーションシステム設計のコンポーネントそれぞれのユーザ入力による推定性能を集約することによって行われてもよい。いくつかの実施形態では、コンポーネントアプリケーションシステム設計を含むコンポーネントの性能データは、統合設計アプリケーション内に予め格納され、その中でアクセス可能である。

ステップ３０３で、プロジェクトの目的および／または目標による設計の実行可能性を評価する。設計の実行可能性の評価は、ステップ３０１で得られた複合アプリケーションシステム設計の推定性能を評価することを含む。評価は、設計による複合アプリケーションシステムの推定性能をシステム性能要件と比較することを含んでもよい。一実施形態では、ユーザは、関連するプログラム可能なプラットフォーム（例えば、スプレッドシート）によって、複合アプリケーションの実行可能性を推定するのに使用される、閾値および計算を指定してもよい。成功した比較（すなわち、設計による複合アプリケーションシステムの推定性能が、システム性能要件を満たすか、または上回る）は、さらに、複合アプリケーションシステム設計の推定コストをシステム予算要件と比較するために評価してもよい。

システム予算および性能要件の両方を満たすシステム設計は、実行可能であると見なされる。あるいは、性能評価またはコスト評価のどちらかが比較的わずかな程度だけ不足している複合アプリケーションシステム設計も、実行可能であると見なされてもよい。性能およびコスト両方の評価が不足している、または性能もしくはコストどちらかの評価が比例的に大きな程度だけ不足している複合アプリケーションシステム設計は、実行不能であると評価されてもよい。

ステップ３０５で、（ステップ３０３で行った評価による）実行可能な設計の潜在的な欠陥を特定する。潜在的な欠陥は、システム設計がシステム要件を満たすことができない原因である特定の１つまたは複数のコンポーネントを含むことがある。潜在的な欠陥はまた、次善の出力が得られるコンポーネントの特定の組み合わせまたは配置を含むことがある。システム設計の失敗の原因である特定のコンポーネントの検出は、複合アプリケーションシステム設計内の各コンポーネントの推定性能および推定コストを、システム要件を満たすコンポーネントの期待性能および期待コストと比較することによってなされてもよい。

基本計算装置
次に、図４を参照すると、代表的なコンピュータシステム４１２のブロック図が示される。本明細書に記載するコンピュータシステム４１２は、実施形態が実装されて利点を得てもよい、動作プラットフォームの代表的な構造を説明していることが理解される。しかしながら、異なる構造を備えた他のコンピュータシステムも、本発明の範囲内でコンピュータシステム４１２の代わりに使用することができる。すなわち、コンピュータシステム４１２は、図４と併せて記載されるもの以外の要素を含むことができる。さらに、実施形態は、コンピュータシステム４１２のようなコンピュータシステムだけではなく、それを可能にするように構成することができるあらゆるシステム上で実行されてもよい。実施形態は、様々なタイプのコンピュータシステム４１２上で実行することができることが理解される。例としては、それらに制限されないが、デスクトップコンピュータ、ワークステーション、サーバー、メディアサーバー、ラップトップ、ゲームコンソール、デジタルテレビ、ＰＶＲ、および携帯情報端末（ＰＤＡ）、ならびに、無線電話、メディアセンターコンピュータ、デジタルビデオレコーダー、デジタルカメラ、およびデジタルオーディオ再生記録装置などの計算およびデータ記憶能力を備えた他の電子装置が挙げられる。

図４を参照すると、実施形態を実施するための代表的なシステムは、計算システム４１２などの汎用計算システム環境を含む。そのほとんどの基本構成では、計算システム４１２は、典型的には、少なくとも１つの処理ユニット４０１およびメモリと、情報を通信するためのアドレス／データバス４００（または他のインターフェース）を含む。計算システム環境の正確な構成およびタイプによって、メモリは、揮発性（ＲＡＭ４０２など）、不揮発性（ＲＯＭ４０３、フラッシュメモリなど）、またはその２つの何らかの組み合わせであってもよい。コンピュータシステム４１２はまた、例えば、ビデオケーブル４１１によって接続された付属の表示装置４１０に情報を表示することによって、情報をコンピュータユーザに提示するための、任意のグラフィックサブシステム４０５を含んでもよい。

さらに、計算システム４１２はまた、追加の特徴／機能性を有してもよい。例えば、計算システム４１２はまた、磁気もしくは光学のディスクまたはテープを含むがそれらに制限されない、追加の記憶装置（リムーバブルおよび／または固定式）を含んでもよい。そのような追加の記憶装置は、データ記憶装置４０４によって図４に示されている。コンピュータ記憶媒体としては、コンピュータ可読の命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するためのあらゆる方法または技術によって実装される、揮発性および不揮発性、リムーバブルおよび固定式の媒体が挙げられる。ＲＡＭ４０２、ＲＯＭ４０３、およびデータ記憶装置４０４はすべてコンピュータ記憶媒体の例である。

コンピュータシステム４１２はまた、任意の英数字入力装置４０６、任意のカーソル制御または指示装置４０７、および１つまたは複数の信号通信インターフェース（入出力装置、例えば、ネットワークインターフェースカード）４０８を含む。任意の英数字入力装置４０６は、情報およびコマンド選択を中央処理装置４０４に通信することができる。任意のカーソル制御または指示装置４０７は、ユーザ入力情報およびコマンド選択を中央処理装置４０４に通信するためのバス４００に結合される。やはりバス４００に結合される信号通信インターフェース（入出力装置）４０８は、シリアルポートであることができる。通信インターフェース４０８はまた、無線通信機構を含んでもよい。通信インターフェース４０８を使用して、コンピュータシステム４１２は、インターネットまたはイントラネット（例えば、ローカルエリアネットワーク）などの通信ネットワークを介して他のコンピュータシステムに通信可能に結合することができ、あるいはデータ（例えば、デジタルテレビ信号）を受信することができる。

ユースケースシナリオの定義
図５は、一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス（ステップ２０１、図２）中に、ユースケースシナリオを定義するための代表的なユーザインターフェース５００のグラフィック表示を示す。

図示される実施形態では、ユーザインターフェース５００は、統合設計アプリケーション１００内のユーザインターフェースの代表的なグラフィック表示である。代表的なユーザインターフェース５００は、ツールバー５０１、パネル５０３、ビューイングウィンドウ５０５、代表的な設計レイアウト（例えば、レイアウトウィンドウ５０７）、ファイルブラウザ５１１、ファイル情報表示５１３、オブジェクト情報表示５１５、オブジェクト目標ウィンドウ５０９、ならびに基準値および容量表示５１７を含む。

ツールバー５０１は、統合設計アプリケーションのユーザ１１１に対して利用可能な機能へのアクセスを提供する。ツールバー５０１は、典型的には、基礎的機能の一般的な特性記述に近似するキーワードを表示するように実装される。多くの場合、キーワードをクリックする（例えば、入力装置によって選択する）ことによって、ドロップダウンバーまたはメニューを介して１つまたは複数の機能がユーザに対してさらに明らかにされる。図示されるように、ツールバー５０１は、ファイルの操作（「Ｆｉｌｅ」）、作図ツール（「Ｖｉｓｉｏ Ｔｏｏｌｓ」）、計算（例えば、「Ｃｏｍｐｕｔｅ」）、関係マッピング（「Ｒｅｌａｔｉｏｎｓｈｉｐｓ」）、目標出力基準値および負荷容量データ（「Ｐｅｒｆｏｒｍａｎｃｅ」）、ならびに通信（「Ｍｅｓｓａｇｉｎｇ」）に関する機能を含む。したがって、他の実施形態は、異なる機能、列挙した機能の異なる配置を含んでもよく、または１つもしくは複数の機能の部分集合を含んでもよい。

提示したように、パネル５０３は、動作特異的な機能のパネルを表示する。例えば、図５のこの図では、ユーザインターフェース５００は代表的な設計のプロセス層を表示している。そのため、パネル５０３は、現在の動作（この場合では、ユースケースシナリオを定義する）に特異的な機能を含んでいる。図示されるように、パネル５０３は、ユースケースシナリオを定義するのに使用されてもよいコンポーネントを代表する形作られたオブジェクトを含む「Ｓｈａｐｅｓ」を含んでいる。

図示されるように、ビューイングウィンドウ５０５は、ユーザが表示させている、および／または操作している現在のファイルまたはコンテンツを表示する。図５に示されるように、ビューイングウィンドウ５０５は、代表的なプロジェクトを含む１つまたは複数のユースケースを表示するレイアウトウィンドウ５０７の表示を含む。さらなる実施形態では、ビューイングウィンドウは、表示されたコンテンツのサポートを含んでもよい。例えば、設計または表示動作中に、視点を変更する機構（例えば、「Ｐａｎ＆Ｚｏｏｍ」）または測定を支援する単純なツールが提供されてもよい。

図示されるように、レイアウトウィンドウ５０７は、代表的な設計に含まれる技術的プロセスを描写する典型的なユースケースシナリオを示す。レイアウトウィンドウ５０７を含むオブジェクトは代表的なものであり、単に表示目的のものである。

ファイルブラウザ５１１（「Ｐｒｏｊｅｃｔ Ｆｉｌｅ Ｂｒｏｗｓｅｒ」）は、プロジェクトに現在収集されているファイルを表示する。図示されるように、ファイルブラウザ５１１はさらに、層に従ってプロジェクトに含まれるファイルを区別する。他の実施形態では、ファイルブラウザ５１１は、他の配置に従ってファイルブラウザ５１１に含まれるファイルを自動的に整理してもよい。さらなる実施形態では、ファイルブラウザ５１１は、共同制作ユーザによって指定された順でファイルを表示してもよい。あるいは、表示されるファイルの順序は、ユーザ特異的であってもよく、かつ／または設計の各バージョンに対して調整可能であってもよい。

一実施形態では、ファイル情報表示５１３は、現在表示させている１つまたは複数のファイルに対応する情報を表示してもよい。例えば、ファイル情報表示５１３は、現在表示させている１つまたは複数のファイル内のオブジェクトの関係の存在有無を示してもよい。他の実施形態では、ファイル情報表示５１３はまた、ファイル内の１つまたは複数のオブジェクトがシステム目的と矛盾するという警告および／または通知を提供してもよい。さらなる実施形態では、ファイル情報表示５１３は、共同制作者の注記（例えば、他の共同制作者へのメッセージ）を表示してもよい。

提示したように、オブジェクト情報表示５１５は、選択されたオブジェクトまたはプロセスに対応する情報を表示する。オブジェクト情報表示５１５に表示された情報は、例えば、選択されたオブジェクトの計算特性、および／または推定性能統計に対応するメタデータを含んでもよい。計算特性は、選択されたオブジェクトまたはプロセスに対応するオブジェクト情報ウィンドウ５０９に入力されたデータの計算を含んでもよい。推定性能統計に対応するメタデータは、例えば、評価を含む、報告するデータソースの数を含んでもよい。いくつかの実施形態によれば、オブジェクトまたはプロセスが現在選択されていないとき、オブジェクト情報表示５１５は、最後に選択されたオブジェクトまたはプロセスの情報を表示してもよい。さらなる実施形態では、オブジェクトまたはプロセスが選択されていないとき、オブジェクト情報表示５１５は空であってもよい。代替実施形態では、オブジェクトまたはプロセスが選択されていないとき、オブジェクト情報表示５１５は、オブジェクトまたはプロセスが選択されていないという指示を表示してもよい。

図示されるように、オブジェクト目標ウィンドウ５０９は、オブジェクト情報表示５１５によって参照されるような、ユースケース内の選択されたオブジェクトまたはプロセスに対応する情報を表示する。ユースケース内の選択されたオブジェクトまたはプロセスに対応する情報は、そのオブジェクトまたはプロセスの目標基準値（すなわち、システム目的を達成するのに十分な条件）を含んでもよい。いくつかの実施形態では、オブジェクト目標ウィンドウ５０９により、それを表示させている、権限を有するユーザが、選択されたオブジェクトまたはプロセスの目標データを入力できるようになる。代表的な目的のため、提示したように、オブジェクト目標ウィンドウ５０９により、ユーザが、選択されたオブジェクトの目標コスト、利用可能性、および遅延を表示させ、および／または設定することができるようになる。

基準値および容量表示５１７は、選択されたオブジェクトまたはプロセスに対して確立された基準値に対応する情報を表示する。基準値および容量表示５１７に含まれる情報は、例えば、システム目的および／または目標基準値（例えば、コスト、性能など）に相対的なシステム設計の性能を表示させるのに使用されてもよい。したがって、ユーザは、システム設計の基準値が目的または目標基準値と一致するかを検表示させることができる。したがって、一致しないシステム設計は、より正確にシステムと連携するように修正されてもよい（例えば、基礎的インフラストラクチャのコンポーネントを再提供する）。選択されたオブジェクトまたはプロセスに対して確立された基準値に対応する情報は、指定の基準値目標、現在の設計の推定性能、現在の設計を含むコンポーネントによる絶対性能限界などのデータフィールドを含んでもよい。選択されたオブジェクトまたはプロセスに対して確立された基準値に対応する情報は、予め確立されたデータの記憶から得られてもよく、かつ／またはオブジェクト情報ウィンドウ５０９を通してユーザが入力してもよい。

さらなる実施形態では、基準値および容量表示５１７は、現在のシステム設計による基準値データの計算された推定値を提供してもよい。基準値データとしては、例えば、コスト、カーボン、性能、および利用可能性の基準値を挙げることができる。基準値データは、現在のシステム設計を含むコンポーネントに対応する基準値データのデポジトリを参照することによって得られてもよい。したがって、現在のシステム設計に対する修正によって、システム設計の基準値データに対する実行時再計算および修正済みの推定値が得られてもよい。したがって、基準値データ推定値は設計プロセス中に利用可能であってもよく、完成したシステム設計は、この実施形態に従って推定基準値データを導き出すのに必須ではない。さらなる別の実施形態では、基準値および容量表示５１７は、要求に応じて、すべてのアプリケーション層にわたって現在のシステム設計の複合基準値を再計算する。

基準値データの計算された推定値を表示する能力を提供することによって、ユーザは、複合システム設計に対する、付加された追加のコンポーネントまたは関係それぞれの影響を直ちにモニタすることができる。その結果、システム目標を追跡することがより簡単になってもよく、従来技術によるよりも、設計プロセス中にシステムの実行可能性を判断することがより容易になってもよい。例えば、特定のコンポーネントの組み合わせが、アプリケーションまたはプロジェクトの要件によるよりも高い推定コストを有する場合、過剰供給が直ちに検出されてもよい。

いくつかの実施形態によれば、オブジェクトまたはプロセスが現在選択されていないとき、基準値および容量表示５１７は、最後に選択されたオブジェクトまたはプロセスの情報を表示してもよい。さらなる実施形態では、オブジェクトまたはプロセスが選択されていないとき、オブジェクト情報表示５１５は空であってもよい。代替実施形態では、オブジェクトまたはプロセスが選択されていないとき、オブジェクト情報表示５１５は、オブジェクトまたはプロセスが選択されていないという指示を表示してもよい。さらなる別の実施形態では、基準値および容量表示５１７は、オブジェクトまたはプロセスについて、特定のデータフィールドを計算するのに十分な容量の負荷データおよび／または実行基準値データが不足しているとき、データが不十分であることを明示的に示してもよい。

ユースケースおよび実行ツールの統合
図６は、一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス（ステップ２０３、図２）中に、ユースケースを実行ツールと統合する代表的なユーザインターフェース６００のグラフィック表示を示す。

図示される実施形態では、代表的なユーザインターフェース６００は、統合設計アプリケーション１００内のユーザインターフェースの代表的なグラフィック表示である。代表的なユーザインターフェース６００は、ツールバー５０１、パネル５０３、ビューイングウィンドウ５０５、代表的な設計レイアウト（例えば、レイアウトウィンドウ６０７）、ファイルブラウザ５１１、ファイル情報表示５１３、オブジェクト情報表示５１５、オブジェクト情報ウィンドウ５０９、基準値および容量表示５１７、ならびに関連する技術プロセス表示６１９を含む。

ツールバー５０１、パネル５０３、ビューイングウィンドウ５０５、ファイルブラウザ５１１、ファイル情報表示５１３、オブジェクト情報表示５１５、オブジェクト情報ウィンドウ５０９、ならびに基準値および容量表示５１７の詳細な記載は、上述の実施形態にて提供されている。したがって、ここでは繰返しを省略するものとする。

図示されるように、レイアウトウィンドウ６０７は、代表的な複合アプリケーション設計内の実行ツールに統合されるコンポーネントを有する代表的なユースケースシナリオを示す。レイアウトウィンドウ６０７を含むオブジェクトは代表的なものであり、単に表示目的のものである。図示されるように、レイアウトウィンドウ６０７は、代表的なユースケースシナリオ内の特定の技術プロセスと対にされている実行ツールを含む。例えば、ユースケースシナリオ内の１つの技術プロセスは、「Ｐａｔｒｏｌ Ｍｏｎｉｔｏｒｉｎｇ Ｉｄｅｎｔｉｆｉｅｓ ａｎ Ａｐｐ Ｓｅｒｖｅｒ ｗｈｉｃｈ ｈａｓ ｆａｉｌｅｄ（パトロールモニタリングが、故障しているＡｐｐサーバを特定しました）」として表示される。レイアウトウィンドウ６０７は、技術プロセスによって特定された動作を行う実行ツール（例えば、「Ｍａｒｉｍｂａ Ａｇｅｎｔ」）を表示する。

提示したように、関連する技術プロセス表示６１９は、レイアウトウィンドウ６０７内の選択されたオブジェクト（例えば、実行ツール、インフラストラクチャ装置）についての、関連する技術プロセスを表示する。関連する技術プロセスとしては、オブジェクトにマッピングされた技術プロセスを挙げることができる。技術プロセスは、ユースケースにおいて定義された特定の使用の達成を可能にするため、オブジェクトによって行われた動作を含んでもよい。関連する技術プロセスを有さないオブジェクトは、空の関連する技術プロセス表示６１９を有してもよい。代替実施形態では、関連する技術プロセスを有さないオブジェクトは、関連する技術プロセスがないことを明示的に示す、関連する技術プロセス表示６１９を有してもよい。

基礎的インフラストラクチャの指定
図７は、一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス（ステップ２０５、図２中）に、基礎的インフラストラクチャを指定する代表的なユーザインターフェース７００のグラフィック表示を示す。

図示される実施形態では、代表的なユーザインターフェース７００は、統合設計アプリケーション１００内のユーザインターフェースの代表的なグラフィック表示である。代表的なユーザインターフェース７００は、ツールバー５０１、パネル５０３、ビューイングウィンドウ５０５、代表的な設計レイアウト（例えば、レイアウトウィンドウ７０７）、ファイルブラウザ５１１、ファイル情報表示５１３、オブジェクト情報表示５１５、オブジェクト情報ウィンドウ５０９、基準値および容量表示５１７、ならびに関連する技術プロセス表示６１９を含む。

ツールバー５０１、パネル５０３、ビューイングウィンドウ５０５、ファイルブラウザ５１１、ファイル情報表示５１３、オブジェクト情報表示５１５、オブジェクト情報ウィンドウ５０９、基準値および容量表示５１７、ならびに関連する技術プロセス表示６１９の詳細な記載は、上述の実施形態にて提供されている。

図示されるように、レイアウトウィンドウ７０７は、代表的な複合アプリケーション設計内の基礎的インフラストラクチャを含むコンポーネントを示す。レイアウトウィンドウ７０７を含むオブジェクトは代表的なものであり、単に表示目的のものである。図示されるように、レイアウトウィンドウ７０７は、ユースケースシナリオのユースケースを実行するツールとして選択されている、具体的に特定されたハードウェア装置およびソフトウェアプラットフォームを含む。例えば、「仮想化層−Ｖｍｗａｒｅ ＥＳＸ」として指定されたオブジェクトはそれぞれ、商用ベンダーであるＶＭｗａｒｅ，Ｉｎｃ．によって提供される企業レベルの仮想化製品であるＶＭｗａｒｅ ＥＳＸサーバを参照する。

ユースケースコンポーネントと実行ツールとの間の関係マッピング
図８は、一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、ユースケースシナリオ内の技術プロセスと実行ツールとの関係をマッピングするユーザインターフェース８００のグラフィック表示を示す。

図示される実施形態では、ユーザインターフェース８００は、統合設計アプリケーション１００内のユーザインターフェースの代表的なグラフィック表示である。代表的なユーザインターフェース８００は、１つまたは複数のビューイング面（例えば、ビューイングウィンドウ８０１、８０５）および代表的な設計レイアウト（例えば、レイアウトウィンドウ８０３、８０７）を含む。代表的なユーザインターフェース８００はまた、関連エレメント表示８０９、および順序付き関係表示８１１を含む。

ビューイングウィンドウ８０１および８０５は、レイアウトウィンドウ（例えば、レイアウトウィンドウ８０３および８０７）を表示し、また、ユーザが、レイアウトウィンドウを含むコンポーネント（例えば、技術プロセスおよび実行ツール）間の関係を表示させ、および／またはマッピングできるようにする。例えば、レイアウトウィンドウ８０３は、代表的な複合アプリケーション設計のユースケースシナリオを含む１つまたは複数の技術プロセスを表示する。レイアウトウィンドウ８０７は、実行ツールとともにユースケースシナリオを表示する。したがって、ユーザインターフェース８００により、ユーザが、技術プロセスとそれに対応する実行ツールとの間の関係をマッピングすることによって、レイアウトウィンドウ８０３に表示されるユースケースシナリオの技術プロセスを、レイアウトウィンドウ８０７内の実行ツールと統合できるようになる。したがって、マッピングされると、その関係はユーザインターフェース８００を介して明示的に観察できる。

順序付き関係表示８１１は、マッピングされているユーザインターフェース８００のレイアウトウィンドウ８０３および８０７内のオブジェクト間の関係のリストを表示する。また、順序付き関係表示８１１により、ユーザが、レイアウトウィンドウ内のオブジェクト間の関係を作成（すなわち、「マッピング」）し削除（すなわち、「アンマッピング」）できるようになってもよい。いくつかの実施形態では、また、順序付き関係表示８１１により、ユーザが、既存のマッピングされた関係に対する修正を保存できるようになってもよい。いくつかの実施形態では、また、順序付き関係表示８１１により、ユーザが、順序付き関係表示８１１におけるマッピングされた関係のリストの提示を変更できるようになる。

さらなる実施形態によれば、関係がマッピングされていないとき、順序付き関係表示８１１は空であってもよい。代替実施形態では、関係がマッピングされていないとき、順序付き関係表示８１１は、関係がマッピングされているという指示を表示してもよい。

ユースケースコンポーネントと基礎的インフラストラクチャとの間の関係マッピング
図９は、一実施形態による、統合設計アプリケーションシステムにける複合アプリケーションを設計するプロセス中に、ユースケースシナリオのコンポーネントと基礎的インフラストラクチャのコンポーネントとの関係をマッピングするユーザインターフェース９００のグラフィック表示を示す。

図示される実施形態では、ユーザインターフェース９００は、統合設計アプリケーション１００内のユーザインターフェースの代表的なグラフィック表示である。代表的なユーザインターフェース９００は、１つまたは複数のビューイング面（例えば、ビューイングウィンドウ８０１、９０５）および代表的な設計レイアウト（例えば、レイアウトウィンドウ８０３、９０７）を含む。代表的なユーザインターフェース９００はまた、関連エレメント表示８０９および順序付き関係表示８１１を含む。

ビューイングウィンドウ８０１および９０５は、レイアウトウィンドウ（例えば、レイアウトウィンドウ８０３および９０７）を表示し、ユーザが、レイアウトウィンドウを含むコンポーネント（例えば、技術プロセスおよび基礎的インフラストラクチャ装置）間の関係を表示させ、および／またはマッピングすることを可能にする。例えば、レイアウトウィンドウ８０３は、代表的な複合アプリケーション設計のユースケースシナリオを含む１つまたは複数の技術プロセスを表示する。レイアウトウィンドウ９０７は、同じ代表的な複合アプリケーション設計の基礎的インフラストラクチャを表示する。したがって、ユーザインターフェース９００により、ユーザが、レイアウトウィンドウ８０３に表示された技術プロセスと、レイアウトウィンドウ９０７に表示されたユースケースシナリオのインフラストラクチャを含む特定の装置との間の関係をマッピングできるようになる。したがって、マッピングされると、関係はユーザインターフェース８００を介して明示的に観察できる。

関連エレメント表示８０９および順序付き関係表示８１１の詳細な記載は、上述の実施形態にて提供されている。

容量および目標基準値データの定義
図１０Ａおよび図１０Ｂはそれぞれ、一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャの容量データおよび目標基準値データを定義するユーザインターフェース１０００および１１００のグラフィック表示を示す。

図示される実施形態では、ユーザインターフェース１０００は、統合設計アプリケーション１００内のユーザインターフェースの代表的なグラフィック表示である。代表的なユーザインターフェース１０００は、１つまたは複数のデータフィールド（例えば、タイトルフィールド１００１および単位略記フィールド１００３）、ならびに動作ボタン（例えば、キャンセルボタン１００５および終了ボタン１００７）を含む。

ユーザインターフェース１０００は、例えば、ツールバー５０１によるナビゲーションを用いて、ユーザインターフェース５００によってインスタンスを生成させてもよい。ユーザインターフェース１０００により、ユーザ入力による容量データの定義が可能になる。図１０Ａに示されるように、ユーザは、名称（タイトルフィールド１００１による）および容量に対応する単位の略記（単位略記フィールド１００３による）を指定することによって、容量を定義することができる。容量の定義は、使用法および実施形態に従って代替および／または追加のフィールドを含んでもよい。

容量を定義するデータを入力した後、ユーザは、終了ボタン１００７によって入力を提出することができる。提出後、容量は、統合設計アプリケーションシステムの対応する記憶コンポーネントに追加され、容量は格納され、現在のプロジェクトの間（例えば、本発明の複合アプリケーションの設計中）持続する（例えば、繰返し使用されてもよい）。他の実施形態では、ユーザは、容量が以降の複合アプリケーション設計において使用されてもよいように、容量を統合設計アプリケーションシステムの記憶コンポーネントに恒久的に（手動で削除されるまで）格納することを選んでもよい。キャンセルボタン１００５により、ユーザが、データフィールドに入力されたデータを提出せずにインターフェース１０００を終了することができるようになる。

図示される実施形態では、ユーザインターフェース１１００は、統合設計アプリケーション１００内のユーザインターフェースの代表的なグラフィック表示である。代表的なユーザインターフェース１１００は、１つまたは複数のデータフィールド（例えば、タイトルフィールド１１０１および単位略記フィールド１１０３）、ならびに動作ボタン（例えば、キャンセルボタン１１０５および終了ボタン１１０７）を含む。

ユーザインターフェース１１００は、例えば、ツールバー５０１によるナビゲーションを用いて、ユーザインターフェース５００によってインスタンスを生成させてもよい。ユーザインターフェース１１００により、ユーザ入力による性能基準値データの定義が可能になる。図１０Ｂに示されるように、ユーザは、名称（タイトルフィールド１１０１による）および性能基準値に対応する単位の略記（単位略記フィールド１１０３による）を指定することによって、性能基準値を定義することができる。性能基準値の定義は、使用法および実施形態に従って代替および／または追加のフィールドを含んでもよい。

性能基準値を定義するデータを入力した後、ユーザは、終了ボタン１１０７によって入力を提出することができる。提出後、性能基準値は、統合設計アプリケーションシステムの対応する記憶コンポーネントに追加され、性能基準値は格納され、現在のプロジェクトの間（例えば、本発明の複合アプリケーションの設計中）持続する（例えば、繰返し使用されてもよい）。他の実施形態では、ユーザは、性能基準値が以降の複合アプリケーション設計において使用されてもよいように、性能基準値を統合設計アプリケーションシステムの記憶コンポーネントに恒久的に（手動で削除されるまで）格納することを選んでもよい。キャンセルボタン１１０５により、ユーザが、データフィールドに入力されたデータを提出せずにインターフェース１１００を終了することができるようになる。

容量および目標基準値データのオブジェクトへの適用
図１１は、一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャの容量および目標基準値データを適用するユーザインターフェース１２００のグラフィック表示を示す。

図示される実施形態では、ユーザインターフェース１２００は、統合設計アプリケーション１００内のユーザインターフェースの代表的なグラフィック表示である。代表的なユーザインターフェース１２００は、基準値選択フィールド１２０１、基準値定義フィールド１２０３、および動作ボタン（例えば、終了ボタン１２０７）を含む。

ユーザインターフェース１２００は、例えば、ツールバー５０１によるナビゲーションを用いて、ユーザインターフェース５００によってインスタンスを生成させてもよい。ユーザインターフェース１２００により、複合アプリケーション設計内の選択されたオブジェクトへの容量および性能データの適用が可能になる。図１１に示されるように、ユーザは、基準値選択フィールド１２０１内の予め定義された容量または性能基準値の名称を選択することによって、容量または性能基準値を適用することができる。一実施形態では、基準値選択フィールド１２０１は、複合アプリケーション設計内の選択されたオブジェクトに対して定義されたすべての容量および性能基準値を表示する。他の実施形態では、基準値選択フィールド１２０１はまた、すべての関連するオブジェクト（例えば、選択されたオブジェクトの下位グループ、上位グループ、もしくは従属グループとして特定されたオブジェクト）、および／または選択されたオブジェクトが属するオブジェクト群全体に対する容量および性能基準値を表示してもよい。

選択されたオブジェクトの容量または性能基準値を選択した後、選択された容量を含むデータ（例えば、境界）が、基準値定義フィールド１２０３を用いてユーザによって入力されてもよい。図１１に示されるように、基準値選択フィールド１２０１において選択された容量（例えば、「Ｐｅａｋ ｕｓｅｒ Ｔｒａｎｓａｃｔｉｏｎ（ピークユーザトランザクション）」）は、時間スケール（計算または測定に使用される時間スケール、例えば、「Ｈｏｕｒｌｙ（１時間ごと）」、「Ｄａｉｌｙ（毎日）」、「Ｗｅｅｋｌｙ（毎週）」など）、ならびに境界（測定または計算を行う時間および日の持続時間または範囲）を含むサブフィールドを含んでもよい。

基準値定義フィールド１２０３を用いて選択された容量を含むデータを入力した後、ユーザは、終了ボタン１２０７を選択することによって、容量または性能基準値を選択されたオブジェクトへと適用してもよい。一実施形態では、容量または性能基準値がオブジェクトに適用された後、選択されたオブジェクトに対応する性能ファイルが、新しく適用された容量または性能基準値を含むように編集される。性能ファイルは、例えは、オブジェクトに対して入力された性能データを、オブジェクトに対して入力された容量負荷データと比較するスプレッドシートとして実現されてもよい。

他の実施形態では、容量または性能基準値が選択されたオブジェクトに適用された後、容量または性能基準値データは、複合アプリケーション設計内のオブジェクトのすべてのインスタンスに追加される。さらなる実施形態では、ユーザは、選択されたオブジェクトの以降のインスタンスがすべて容量又は性能データを含むように、統合設計アプリケーションシステムの記憶コンポーネントにおいて恒久的に（手動で削除されるまで）、選択されたオブジェクトと同じタイプのすべてのオブジェクトに容量または性能データを適用することを選んでもよい。

代替実施形態では、ユーザは、プロジェクトタイプに対応するデータリポジトリから、ベースラインの（例えば、デフォルトの）容量および基準値定義および量を使用することを選択してもよい。例えば、ユーザは、メニューから選択し、そこから予め定義された項目を選んで、中央のリポジトリに格納されそこから利用可能な既存のデータセットに基づいて、プロジェクトの定義をモデル化することができてもよい。次に、アプリケーションによって、それらの典型的な容量タイプ、および各容量タイプに対応する関連基準値が利用可能になり、標準的な値の組を用いてスプレッドシートインターフェースに自動的にそれらが予め書き入れられてもよい。さらなる別の実施形態では、ユーザは、プロジェクトタイプの以降の選択に更新された値が自動的に予め書き入れられるように、標準的な値の組を編集することができる。

図１２は、一実施形態による、統合設計アプリケーションシステム内の複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャの容量データおよび目標基準値データを適用するユーザインターフェース１３００の代替のグラフィック表示を示す。

図示される実施形態では、ユーザインターフェース１３００は、統合設計アプリケーション１００内のユーザインターフェースの代表的なグラフィック表示である。代表的なユーザインターフェース１３００は、上述したように、ツールバー５０１、パネル５０３、ビューイングウィンドウ５０５、代表的な設計レイアウト（例えば、レイアウトウィンドウ５０７）、ファイルブラウザ５１１、ファイル情報を含んでもよい。ユーザインターフェース１３００はまた、基準値適用ウィンドウ１３０１を含んでいる。

ユーザインターフェース１３００は、容量および性能基準値をレイアウトウィンドウ５０７内で選択されたオブジェクトに適用できるようにする、基準値適用ウィンドウ１３０１を含む。基準値適用ウィンドウ１３０１は、容量選択フィールド１３０３、性能基準値フィールド１３０５、関連基準値表示１３０７、基準値定義フィールド１３０９、および動作ボタン（例えば、追加ボタン１３１１、削除ボタン１３１３、および終了ボタン１３１５）を含む。

容量選択フィールド１３０３により、レイアウトウィンドウ５０７内の選択されたオブジェクトに容量データを適用できるようになる。ユーザは、容量選択フィールド１３０１内の予め定義された容量の名称を選択することによって、容量または性能基準値を適用することができる。一実施形態では、容量選択フィールド１３０３は、複合アプリケーション設計内の選択されたオブジェクトに対して定義されたすべての容量を表示する。他の実施形態では、容量選択フィールド１３０３はまた、すべての関連するオブジェクト（例えば、選択されたオブジェクトの下位グループ、上位グループ、もしくは従属グループとして特定されたオブジェクト）、および／または選択されたオブジェクトが属するオブジェクト群全体に対する容量および性能基準値を表示してもよい。

性能基準値選択フィールド１３０５により、性能基準値データをレイアウトウィンドウ５０７の選択されたオブジェクトに適用できるようになる。ユーザは、性能基準値選択フィールド１３０５内の予め定義された性能基準値の名称を選択することによって、性能基準値を適用することができる。一実施形態では、性能基準値選択フィールド１３０５は、複合アプリケーション設計内の選択されたオブジェクトに対して定義されたすべての性能基準値を表示する。他の実施形態では、性能基準値選択フィールド１３０５はまた、すべての関連するオブジェクト（例えば、選択されたオブジェクトの下位グループ、上位グループ、もしくは従属グループとして特定されたオブジェクト）、および／または選択されたオブジェクトが属するオブジェクト群全体に対する性能基準値を表示してもよい。

関連基準値表示１３０７は、レイアウトウィンドウ５０７内で選択されたオブジェクトと現在関連付けられているすべての基準値のリストを表示する。一実施形態では、容量がユーザインターフェース１３０１内でユーザによって現在選択されている場合、レイアウトウィンドウ５０７内で選択されたオブジェクトと関連付けられた容量のみが、関連基準値表示１３０７に表示される。同様に、性能基準値がユーザインターフェース１３０１内でユーザによって現在選択されている場合、レイアウトウィンドウ５０７内で選択されたオブジェクトと関連付けられた性能基準値のみが、関連基準値表示１３０７に表示される。

基準値定義フィールド１３０９により、ユーザが、容量選択フィールド１３０３および性能基準値選択フィールド１３０５内で選択された容量または性能基準値に対応するデータを追加または編集できるようになる。一実施形態では、１つの容量または性能基準値のみが、容量選択フィールド１３０３および性能基準値選択フィールド１３０５のどちらかにおいて選択されてもよい。

動作ボタン（例えば、追加ボタン１３１１、削除ボタン１３１３、および終了ボタン１３１５）により、ユーザが、入力されたデータを用いて動作を行うことができるようになる。追加ボタン１３１１によって、ユーザが、選択された容量または性能基準値を選択されたオブジェクトに追加（適用）できるようになる。削除ボタン１３１３により、ユーザが、選択された容量または性能基準値を選択されたオブジェクトから削除（分離）できるようになる。終了ボタン１３１５は、ユーザインターフェース１３０１において行われたデータおよび動作を提出し、ユーザインターフェース１３０１を終了する。

図１３は、一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャ中の選択されたオブジェクトに対応する代表的な性能ファイル１４００のグラフィック表示を示す。

図１３に示されるように、性能ファイルは、オブジェクトに対して入力された性能データを、オブジェクトに対して入力された容量負荷データと比較するスプレッドシートとして実現される。オブジェクトに対して入力された性能データは、例えば、ユーザインターフェース１２００によって入力されてもよい。

図１４は、一実施形態による、統合設計アプリケーションシステム内の複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャ中の選択されたオブジェクトの容量負荷データおよび性能基準値データに対応する代表的な比較インターフェース１５００のグラフィック表示を示す。

図１４に示されるように、選択されたオブジェクトの性能ファイルを含むデータは、選択されたオブジェクトの容量負荷データを、選択されたオブジェクトの対応する性能基準値データと比較するように解析され分析される。一実施形態では、比較は、図式的に表示される（例えば、図１４の線グラフ）。代替実施形態では、他の視覚化が利用可能であってもよい。

図１５は、一実施形態による、統合設計アプリケーションシステムにおける複合アプリケーションを設計するプロセス中に、基礎的インフラストラクチャのレイアウトの選択されたオブジェクトに対応する代表的なオブジェクト情報ウィンドウ１６００のグラフィック表示を示す。

図１５に示されるように、オブジェクト情報ウィンドウ１６００の典型的な構成は、オブジェクト情報表示５１５ならびに基準値および容量表示５１７を含む。オブジェクト情報表示５１５ならびに基準値および容量表示５１７は両方とも、本明細書にて記載してきた。一実施形態では、基準値および容量表示５１７は、選択されたオブジェクトの容量負荷データと選択されたオブジェクトの対応する性能基準値データとの比較を表示する。図１５に示されるデータは、例えば、図１３による選択されたオブジェクトの性能ファイルから、および／または図１１および図１２によるユーザからの（または記憶装置から得られた）容量および基準値データから解析されてもよい。

上述の詳細な記載は、例えば、共同設計アプリケーション、複合アプリケーション、システム目的、素材の相関、異種の貢献者、および情報技術オブジェクトなど、様々な専門用語に対する参照を含んでいる。明瞭にするため、以下のものは単に例として提供する。共同設計アプリケーションは、様々な実施形態において、例えば、コンパイラ、ソースコードジェネレータ、１つまたは複数のグラフィカルユーザインターフェース、およびソフトウェアアプリケーションリポジトリを含み、かつ／またはそれらとして実装されてもよい。複合アプリケーションは、様々な実施形態において、複数の実行可能ファイル、ソフトウェアプログラム、ソフトウェアパッケージ、データ構造、ファイルシステム、およびコンフィギュレーションデータの１つまたは複数を含み、かつ／またはそれらとして実装されてもよい。システム目的は、性能、効率、スループット、帯域幅、および記憶の要件から成る群からの１つまたは複数を含んでもよい。素材の相関は、プログラムの機能性の併合、データの共用、および／またはソフトウェアもしくはデータの矛盾の解決を含んでもよい。異種の貢献者は、別個の（すなわち、地理的に遠隔の）ソフトウェア開発者もしくは設計者、またはコンピュータが実行可能な命令を生成する別個のコンピュータシステムであってもよい。情報技術ツールは、コンピュータソフトウェアプログラム、パッケージ、データ構造、ファイルシステム、バイナリ、ライブラリ、およびコンフィギュレーションデータ、ならびに計算ハードウェアコンポーネント、分散形計算システムのアーキテクチャを含む装置などのいずれかを含んでもよい。

構造的特徴および／または方法論的動作に特異的な用語を用いて主題について記載してきたが、添付の特許請求の範囲において定義される主題は、必ずしも上述の特定の特徴または動作に制限されないことを理解されたい。より正確に言えば、上述の特定の特徴および動作は、特許請求の範囲を実現する例示的形態として開示されている。

Claims (9)

1. 統合ソフトウェアアプリケーション内で複数のアプリケーション要件を満たす複合アプリケーションシステムを設計するプロセスをコンピュータシステムに行わせる方法であって、該プロセスが、
   複合アプリケーションシステム設計内の複合アプリケーションシステムによって行われる複数のケースシナリオを定義するステップと、
   前記複数のケースシナリオを、ソフトウェアアプリケーションおよびハードウェアコンポーネントの集合体を含む複数の情報技術ツールと統合するステップと、
   前記複数の情報技術ツールを具体化するため、前記複合アプリケーションシステム設計の基礎的インフラストラクチャを指定し、該基礎的インフラストラクチャの指定が、前記情報技術ツールの集合体に対応する、前記複数のアプリケーション要件を満たす複数のソフトウェアアプリケーションおよびハードウェアコンポーネントを選択するステップとを含み、
   前記複合アプリケーションシステム設計の基礎的インフラストラクチャを指定するステップが、
   前記複合アプリケーションシステム設計による前記基礎的インフラストラクチャの性能および費用を推定するステップと、
   前記複合アプリケーションシステム設計の推定性能および推定費用をユーザ指定の閾値および計算と比較することによって、前記複合アプリケーションシステム設計の実行可能性を評価するステップであって、前記ユーザ指定の閾値および計算がシステム性能要件およびシステム予算要件を含む、評価するステップと、
   前記評価により、実現可能な複合アプリケーションシステム設計の潜在的な欠陥を特定するステップとを含む、方法。
2. 前記プロセスが、前記複合アプリケーションシステム設計の修正に対応するように更新される基準値データの実行時推定値を提供するステップをさらに含む、請求項１に記載の方法。
3. 基準値データの実行時推定値を提供するステップが、複数の設計層からの前記複合アプリケーションシステム設計の基準値データを組み合わせることを含む、請求項２に記載の方法。
4. 前記複合アプリケーションシステム設計のケースシナリオを定義するステップが、前記ケースシナリオの目標性能を前記ケースシナリオの推定性能と比較することを含む、請求項１に記載の方法。
5. 前記複数のケースシナリオを複数の情報技術ツールと統合するステップが、
   ケースシナリオを実行するための情報技術ツールを定義するステップと、
   前記ケースシナリオを、前記ケースシナリオを実行する前記情報技術ツールにマッピングするステップとを含む、請求項１に記載の方法。
   
6. 前記複合アプリケーションシステム設計の基礎的インフラストラクチャを指定するステップが、
   前記複数のコンポーネント間の複数の関係を特定するステップと、
   前記複数の関係をそれぞれ視覚化するステップと、
   前記複数の関係それぞれを、前記複合アプリケーションシステム設計内の前記複数のコンポーネントの対応するコンポーネントに対してマッピングするステップとをさらに含む、請求項１に記載の方法。
7. 前記複合アプリケーションシステム設計内の前記複数のコンポーネントの関係をマッピングするプロセスが、
   第１のコンポーネントに対応する基準値データ推定値を第２のコンポーネントに伝えるステップと、
   前記第１のコンポーネントに対応する基準値データ推定値を第３のコンポーネントに伝えるステップとを含み、
   前記第２のコンポーネントが前記第１のコンポーネントの特定された下位グループを含み、
   前記第３のコンポーネントが前記第１のコンポーネントの特定された上位グループを含む、請求項６に記載の方法。
8. 前記アプリケーション要件に一致させるため、一致しない複合アプリケーションシステム設計を補正するステップをさらに含み、前記一致しない複合アプリケーションシステム設計を補正するステップが、
   前記複数のアプリケーション要件と前記基礎的インフラストラクチャの性能との関係を視覚化するステップと、
   視覚化した関係に基づいて、前記複数のアプリケーション要件と一致するように前記複合アプリケーションシステム設計を調節するステップとを含む、請求項１に記載の方法。
9. 前記統合ソフトウェアアプリケーションが、前記統合ソフトウェアアプリケーションの分散したユーザ間での共同制作を提供するべく構成されるように動作可能であり、前記統合ソフトウェアアプリケーションの分散したユーザ間での共同制作を提供するステップが、直接的な同時の共同作業を前記統合ソフトウェアアプリケーションで行うことができるようにすることを含む、請求項１に記載の方法。
   

Images