チーム・コラボレーションのためのモデルの編成メソッド

プロジェクトのタイプに基づいて、複数の編成メソッドのうちの 1 つを使用してモデルを編成することができます。

ユースケースによる

ユースケースは、要件収集を行う上で中心となるものであり、要件および分析モデル編成における明らかな焦点となります。例えば、関連する要件およびユースケースで作業する場合、通常は 1 つ以上のユースケースおよびアクターへのアクセスが必要となります。ユースケースを詳述する場合、単一のユースケースと複数の詳細ビュー (一連のシナリオ)、および、多くの場合はアクティビティー図またはステートチャート (または、他のいくつかの公式仕様言語) のいずれかで作業します。コラボレーションを詳述する場合は、単一のユースケースに関連する一連のクラスを作成する必要があるだけでなく、そのユースケースにバインドされたシナリオを詳細化する必要があります。パッケージでは、ユースケースを一貫性のあるセット (汎化、«includes» 関係または «Extends» 関係、あるいはアクターの共通セットとの関連付けにより関連付けられたセット) に分割することができます。この場合、パッケージにはユースケースとそのアクター、アクティビティー図、ステートチャート、およびシーケンス図が含まれます。

フレームワークによる

フレームワーク・ベースのモデル編成は、ユースケース・ベースの方法の一部の制限に対応します。引き続き小規模システムがターゲットとなりますが、共有および共通要素のフレームワーク・パッケージが追加されます。フレームワーク・パッケージには、使用点 (ターゲットのアプリケーション環境にサービスを提供するために使用されるクラス)、および拡張点 (ユースケース・パッケージ内のクラスによりサブクラスに分類されたクラス) のサブパッケージがあります。フレームワーク・エリアの編成には、十分に機能する方法が他にもあることに注意してください。例えば、フレームワークは一貫したパターンのセットで構成される場合が多く、フレームワークのサブパッケージはこれらのパターンを中心に編成することができます。これは小規模アプリケーションを共通のフレームワーク内で構築する場合には適していますが、このスキームでは、ユースケース・ベースの方法と同じいくつかの点で再利用が阻止されます。

論理および物理アーキテクチャーによる

別の方法として、アーキテクチャーを論理的側面 (タイプ、クラス、および他の設計時間モデル要素の編成) と物理的側面 (インスタンス、オブジェクト、サブシステム、および他の実行時間要素の編成) に分ける方法があります。論理アーキテクチャーは多くの場合、ドメイン によって編成されるのに対して、物理アーキテクチャーはコンポーネントまたはサブシステムを中心に展開されます。モデルをこの方法でモデルを構築する場合は、ドメイン、サブシステム、またはコンポーネントが、一人の担当者または 1 つのチームに割り当てられる CI となります。要素があまりに大きい場合は、ドメイン、サブコンポーネント、またはチーム編成などの別の基準のサブトピックに基づいて、サブパッケージにさらに分割することができます。

ドメインによる

クラスに基づいて、モデルを分割することもできます。ROPES プロセスで定義されているように、ドメインは、デバイス I/O、ユーザー・インターフェース、またはアラーム管理などの共通のボキャブラリーを使用するサブジェクト・エリアです。各ドメインには多くのクラスが含まれており、システム・レベルでのユースケースのコラボレーションには複数の異なるドメインのクラスが含まれます。多くのドメインには、詳細なデバイス・ドライバー、航空ナビゲーションおよびガイダンス、または通信プロトコルといった、かなり特殊な専門知識が必要となります。一人の担当者または 1 つのチームが開発して操作するため、ワークフローおよび論理の観点から、このような要素を分類することが合理的であると言えます。ドメインによるクラスの分類、およびドメインを CI とすることは、多くのプロジェクトにとって賢明かもしれません。

コンポーネントによる

モデルはコンポーネントによって直感的に編成されることもあります。IBM® Rational® Rhapsody® の UML コンポーネントは、実行可能ファイル、ライブラリー、およびその他の物理的なバイナリー成果物を定義するために使用される基本的なビルディング・ブロックです。これらの各コンポーネントはモデル要素から生成されたコードからコンパイルされます。コンポーネントを構成するモデル要素は、コンポーネント有効範囲 と呼ばれます。特定のコンポーネントにマップされたすべてのモデル要素が組み込まれたトップレベル・パッケージを使用することで、シンプルで使いやすい構造を作成できます。この方法は、複数のコンポーネントでの同じ設計要素の再利用の妨げになります。しかし、コンポーネント・レベルの再利用 (つまり、再利用される設計レベル要素をライブラリーに割り当て、このライブラリーを複数のコンポーネントで使用すること) によって効率性は得られます。

チーム・メンバーまたはグループによる

シンプルなソリューションとして、チーム・メンバーごとに 1 つのパッケージを割り当てる方法があります。サムが取り組むすべてが SamPackage 内にあり、ジュリーが取り組むすべてが JuliePackage 内にあります。非常に小さなプロジェクト・チームの場合、このソリューションは実行可能なモデルです。しかし一方で、サムとジュリーそれぞれの処理対象は何かという問題が発生します。スーザンが、サムのいくつかのクラスに更新を行う必要があり、サムが SamPackage 内のその他のクラスで作業中である場合も、同様に問題が発生します。さらに、このスキームでは、プロジェクト・チーム編成の依存関係がモデル構造に追加され、(チーム・メンバーを他のタスクに割り当てるなどの) プロジェクト・チームの変更をより難しくし、再利用性も制限されます。


フィードバック