プロジェクトをユニットに分割する際の考慮事項

IBM® Rational® Rhapsody® を使用して、構成項目またはユニット の細分度レベルを制御することができます。

デフォルトでは、作成されるパッケージはすべてユニット (ファイル・システムにおける個別ファイル) です。また、コンポーネントとダイアグラムもユニットです。デフォルトでは、その他の設計要素はすべてユニットではなく、親ユニットのファイル内に保管されます。したがって、モデルはプロジェクト・ファイル (*.rpy)、パッケージ・ファイル (*.sbs)、コンポーネント・ファイル (*.cmp)、およびさまざまなダイアグラム・ファイルで構成されます。

ただし、プロジェクトの編成および要件に応じて、ユニットごとに、またはユニット作成のための新規ポリシーを確立することで、これらのデフォルトをオーバーライドすることができます。例えば、特定のクラスをそれ自体のユニットにすることを選択できます。あるいは、作成されるすべての新規クラスをユニットにするように、製品をセットアップすることができます。

場合によっては (異なる使用法を適用することが多い 2 人のチーム・メンバーによってパッケージが保守されている場合など)、デフォルト設定をオーバーライドし、1 つのクラスまたは複数のクラスを個別ファイルに保管することが賢明であると言えます。チーム・メンバー A が、1 つのクラスのステートチャートに取り込まれたパッケージ内の特定要素の振る舞いを設計している一方で、チーム・メンバー B はそのパッケージのすべてのクラスで使用されるタイプの新規ファミリーを定義します。この場合、ステートチャートを持つクラスを個別ユニットにすることができます。

これはダイアグラムにも当てはまります。Rational Rhapsody では、ダイアグラムがユニットとして保管されます。これにより、ダイアグラムに表示されている実際のモデル要素を変更せずに、ダイアグラムに変更を適用できます。また、ダイアグラムの色、要素のレイアウト、コメントなどのグラフィック特性は、要素を含むユニットの状況 (読み取り専用、または読み取り/書き込み) にかかわらず変更することができます。しかし、多くの場合、ダイアグラムは、そのダイアグラムが属しているパッケージの特定の側面を示す単なる「ビュー」です。この場合、側面の変更 (例えば、関係の多重度の変更やクラスの削除) では、ダイアグラムにおける変更が必要です。その逆の場合も同様です。製品の結合性により、ダイアグラムにおける一部の変更 (例えば、関係の追加や変更) では、設計要素をチェックアウトする必要があります。

デフォルトの設定を逆の設定でオーバーライドし、複雑度を下げることは、ファイル数、および構成管理操作を実行する必要性の点で、場合によっては賢明と言えます。例えば、パッケージ内に 50 個のイベントを定義する必要があるとします。設計を見やすくするために、これらの 50 個のイベントを 3 つのサブパッケージに分割し、わかりやすい名前と適切な説明を付けます。新規ファイルを 3 つ作成せずに、パッケージを作成したい場合があるかもしれません。この場合は、パッケージがユニットとして作成されないように、デフォルトの振る舞いをオーバーライドすることができます。

個別にユニットを定義することに加え、プロパティー を使用してユニット作成のための新規ポリシーを定義することができます。例えば、すべての新規ダイアグラムが個別のユニットにならないようすることができます。また、クラスのデフォルト・ポリシーをオーバーライドして、すべての新規クラスが自動的にユニットとして保管されるようにすることもできます。


フィードバック