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