論理編成
論理モデル編成では、次の目標を達成する必要があります。
物理編成
物理モデル編成には、次の 2 つのアプローチがあります。
物理的に分割する戦略の計画には利点があるものの、 もっと自発的なアプローチも有効で、計画した方法で見落とされていた問題や予測されなかった問題に対処できることもあります。 例えば、新しい要件や予想外に複雑な設計のために、パッケージ構造のモデル全体のサイズまたは深さが管理できなくなったときに、物理分割の実行を決定することができます。
モデルのマージ
モデルのマージは、モデルの論理編成および物理編成を計画する際の重要な考慮事項です。
構成管理ポリシーの中には、 複数のチーム・メンバーが 1 つのモデルについて同時に作業を行う並行開発を使用可能にしているものもあります。 並行開発の際に、整合性のない変更が行われると、モデルに影響が及ぶ可能性があります。 モデル・ファイルを構成管理システムに保存するときには、事前に変更をマージしておく 必要があります。 変更が競合しない場合は、発生するマージは簡単なので、ツールにより変更は自動的にマージされます。 変更が競合する場合は、発生するマージは複雑なので、受け入れる変更内容を判別する必要が あります。
有効なモデル・アーキテクチャーを構築するには、分解が重要な鍵となります。 分解は、システムを複数のパーツに分割する機能です。 以下の分解の原則は、オブジェクト指向の開発、 コンポーネント・ベースの設計、 およびサービス指向のアーキテクチャーを駆動するものと同じです。
分解後のモデルにも引き続き多くの依存関係が含まれている場合は、次の 2 つのオプションがあります。
有効なアーキテクチャーを確立したあとで、 アーキテクチャー・コンポーネントの所有権を、 個人または小規模のチームに割り当てることができます。 1 人、または近い場所にいる小規模のチームで、論理パッケージまたはモデル内のブランチについての作業をしている場合は、 モデルの保管先が単一のモデル・ファイルか、複数のモデル・ファイルかに関係なく、 そのモデルの複雑なマージを最小限に抑えることができます。
論理モデルの分割化では、別モデルの作成とフラグメント化という 2 つのメカニズムを使用することができます。
別個のモデルを作成するときは、通常、共通の論理モデル・ルート、 つまりルート・パッケージ下に編成されている多くの論理モデル・パッケージを開始点とします。 これらの論理パッケージは、同じ物理モデル・ファイルに含まれます。 ルート下の 1 つのパッケージを選択して、そのパッケージから物理モデルを作成します。 このパッケージが、「プロジェクト・エクスプローラー」ビューの新しい最上位の論理モデルになります。 新しいモデルの所有者は、論理的には、分割元のモデルではなくなります。 また、新しいモデルに含まれる要素と、モデルの以前の親である論理モデルにまだ含まれている要素との関係は、 ファイル間関係になります。 以前の関係は、モデルの比較およびマージのシナリオに影響するファイル内関係でした。
対照的に、モデルのフラグメント化では、モデルの分類子型要素を選択し、それをフラグメントとして管理します。 フラグメントは、別個の物理的な Eclipse リソース・ファイルですが、その内容の所有者は親の論理モデルになります。
モデルの分割化は非常事態の場合のみ行うようにしてください。 モデルの分割化が適切に行われないと、チームのコラボレーションや開発に支障が出る可能性があります。
モデルの比較およびマージのアクティビティーの数や規模を抑えようとして、 物理分割を行うことが多いですが、アーキテクチャーの相互依存関係は論理的なものであり、物理的なものではないため、 モデルを複数のモデル・ファイルに分割すると、複雑なマージを回避できなくなります。 モデルを複数のモデル・ファイルに分割した場合、 要素の相互依存関係の表記は、ファイル内参照ではなく、ファイル間参照になります。 ファイル間参照を伴うマージの競合は、他のモデル・ファイル内のモデルの論理的な内容が分からないため、 解決が難しくなります。 マージを実行する必要がある場合に物理分割を行うと、マージ・セッションはさらに難しくなります。
次に、物理モデル分割が適しているシナリオを示します。
モデルを物理分割しない場合は、論理編成、 強力な論理パッケージ所有権、および物理的に大きいモデル・ファイルに重点を置いてください。 Rational ClearCase を使用する場合は、 private の静的ビューまたは動的ビューと、UCM のリベースとデリバーを使用して、 統合が完全に完了するまで、モデルの整合性を確保してください。
また、モデルの分割は、論理的なコンテンツが安定し始めてから実行してください。 分割化の決定を変更する必要が少なくなります。 例えば、モデルの前のバージョンが最上位のサブシステムを表していることがよくあります。 今後の反復に残る可能性がある最上位のサブシステムを定義するまで、モデルを分割しないでください。 最上位のサブシステムが成熟し、安定したときに、 物理的な分離によって、並行開発ワークフローや、モデルのオープンや公開などの作業のパフォーマンスが改善される場合には、 それらのサブシステムを物理的に分離することができます。 また、最初に、共有性の高い共通のコンポーネントを論理的に安定化することにも重点を置いてください。これらのコンポーネントを変更すると、他のすべてのパーティションに影響する競合を招くことがあります。
モデルの分割を行う場合は、データ破壊を回避するため、 同じ改訂レベルにあるすべてのパーティションを含む同期化ワークスペースで必ず作業してください。
サンプル
次の例で、 非同期化ワークスペースでモデルの分割を行った場合に発生する可能性がある事象を紹介します。
構成管理システム内に、 モデル X とモデル Y という 2 つのパーティションを持つモデルがあります。 両方とも、バージョンは 20 です。 モデル X は、P1 という名前のパッケージを 1 つ持っています。 モデル Y は空です。
2 人のユーザーが、以下のワークフローに関与しています。
ユーザー B が、 ワークスペース内の既存のバージョン (モデル X、バージョン 20) を選択した場合、 チェックアウトについてのプロンプトが出された操作を、 繰り返すことになるかもしれません。
しかし、ユーザー B が、 自分の変更を新規のモデル・バージョン (モデル X、バージョン 21) で保存すると、 ユーザー A が行った変更は上書きされてしまうことになります。