本製品では、階層リポジトリー として知られるパラダイムがサポートされます。このフィーチャーを使用して、モデルを保存する際に、Rational Rhapsody によって、UML パッケージが有効範囲内の設計要素を含むディレクトリーにマップされます。デフォルトでは、ツールでフラット構造が使用されるため、階層スキームを使用する必要はありません。パッケージのうちの一部、またはすべてを階層構造に移動するよう選択できます。
プロジェクトの再構築は一度に行うことも、あるいは 1 回にいくつかのパッケージをそれ自体のディレクトリーに移動し、モデルの特定領域の複雑さが軽減されるように段階的に行うこともできます。
リポジトリーの構造はプロジェクトの編成に依存しており、他のプロジェクトの決定と同様に、トレードオフに関係します。
モデル全体を単一ファイル内に置いておくと、競合を防ぐことはできますが、実質的には並行開発が行えなくなります。しかし、すべての設計要素とダイアグラムを 1 つのユニットにするのは行き過ぎかもしれません。これらを 1 つのユニットにすると、タスクを完了するためにチェックアウトを行う必要があるファイルが増えることになります。
同様に、Rational Rhapsody プロジェクト・リポジトリーの構造化の場合、ある極端な状態 (単一ディレクトリー内に何百ものファイルが配置されている) から別の極端な状態 (何百ものディレクトリーにそれぞれ単一ファイルが含まれる) に移行することは、階層リポジトリー・フィーチャーの効果的な使用法ではないということを念頭においてください。
例えば、プロジェクト A には 200 個のユニットがあり、そのうちの 120 個がパッケージ (*.sbs)・ファイルで、残りの 80 個が他のタイプのユニット・ファイルだとします。また、プロジェクト B では、200 個のユニットのうち、20 個がパッケージであるとします。
純粋なツリー構造 (すべての UML パッケージがファイル・システム内のディレクトリーにマップされている) に移動させた場合、プロジェクト A 内のそれぞれのディレクトリーに (平均で) 1.66 個のファイルが存在する可能性があります。この場合、多数のディレクトリーに 1 つのファイルが含まれる可能性があり、また 2 つのファイルが存在する可能性もあります。このような構造には利点はほとんどなく、プロジェクト・サイズが増大する可能性があります。
あるいは、プロジェクト B を純粋なツリー構造に移動させた場合、平均的なディレクトリーには相関機能性を持つ 10 個 (妥当な数) のファイルが含まれることになります。このメソッドにより、フラット・リポジトリーで直面する多くの問題が解決されると同時に、新規ディレクトリーにおいては追加するファイルがより少なくなります。
プロジェクトを階層構造に保管するかどうかを決定する際は、これらの要因を考慮してください。プロジェクト全体が同じ構造である必要はありません。いくつかのパッケージは階層で保管し、その他は親フォルダー内でフラット構造のままにしておくことができます。