모델 조직

UML 모델을 팀 멤버와 공유하는 경우 모델 조직 및 파티션 전략을 개발해야 합니다. 모델 조직에는 두 가지 측면 즉, 논리와 물리가 있습니다.

논리 조직

논리 모델 조직은 다음 목표를 달성해야 합니다.

물리 조직

물리 모델 조직에는 두 가지 접근법이 있습니다.

물리적 파티션 전략을 계획하면 장점은 있지만, 보다 자발적인 접근법이 유효하며 때로 계획된 접근법에서 예상하지 않았거나 간과한 점을 다룰 수도 있습니다. 예를 들어, 새 요구사항이나 예기치 않은 디자인 복잡도로 인해 전체 모델 크기나 패키지 구조의 깊이가 관리 불가능하게 된 경우 물리 파티션을 수행하도록 결정할 수 있습니다.

모델 병합

모델 병합은 모델의 논리 및 물리 조직을 계획할 때 중요한 고려사항입니다.

일부 구성 관리 정책은 여러 팀 멤버가 동시에 동일한 모델에 대해 작업하는 병행 개발을 가능하게 합니다. 병행 개발 중 조정되지 않은 변경사항은 모델에 영향을 줄 수 있습니다. 구성 관리 시스템에 모델 파일을 저장하기 전에 변경사항을 병합해야 합니다. 단순 병합은 변경사항이 충돌하지 않을 때 발생하며 도구가 변경사항을 자동으로 병합합니다. 비단순 병합은 변경사항이 충돌할 때 발생하며 어느 변경사항을 허용할지 판별해야 합니다.

유효 모델 아키텍처 및 소유권

유효 모델 아키텍처는 시스템을 파트로 분할하는 기능인 분해에 상당히 의존합니다. 다음 분해 원리는 객체 지향 개발, 컴포넌트 기반 디자인 및 서비스 지향 아키텍처를 추구하는 원리와 동일합니다.

분해 후에도 모델에 여전히 많은 수의 종속이 있는 경우 다음 두 가지 옵션이 있습니다.

유효 아키텍처를 확립하고 나면 아키텍처 컴포넌트의 소유권을 개인이나 작은 팀에 지정할 수 있습니다. 밀접한 작은 팀이나 한 개인이 모델의 분기 또는 논리 패키지에서 작업할 때, 단일 모델링 파일 또는 여러 모델링 파일에 모델을 저장할지 여부와 무관하게 이 모델과의 비단순 병합을 최소화합니다.

물리 파티션 유형

논리 모델을 파티션하는 두 가지 메커니즘 즉, 개별 모델 작성 및 단편화를 사용할 수 있습니다.

개별 모델을 작성할 때에는 일반적으로 공통 논리 모델 루트나 루트 패키지 아래에 구성되는 많은 논리 모델 패키지로 시작합니다. 논리 패키지는 동일한 물리 모델링 파일을 점유합니다. 루트 아래의 한 패키지를 선택하고 이 패키지에서 물리 모델을 작성합니다. 그러면 패키지는 프로젝트 탐색기 보기에서 새 최상위 레벨 논리 모델이 됩니다. 새 모델은 더 이상 파티션된 모델에 논리적으로 소유되지 않습니다. 또한 새 모델이 포함하는 요소와 모델의 이전 상위 논리 모델에 여전히 포함된 요소 간의 관계는 상호 파일 관계가 됩니다. 이전에는 관계가 파일 내였으며 이는 모델 비교와 병합 시나리오에 영향을 줍니다.

이와 반대로, 모델을 단편화하는 경우에는 모델의 분류자 유형 요소를 선택해서 이를 단편으로 관리합니다. 단편은 별도의 물리적 Eclipse 자원 파일이지만 상위 논리 모델이 컨텐츠를 소유합니다.

모델을 물리적으로 파티션할 때

모델 파티션은 적절하게 수행하지 않는 경우 팀 협업 및 개발을 저해할 수 있으므로 극단적인 상황에서만 모델을 파티션해야 합니다.

종종 모델을 물리적으로 파티션해서 모델 비교 및 병합 활동의 수와 크기를 줄이려 시도합니다. 그러나 아키텍처 상호 의존은 물리적이 아닌 논리적이기 때문에 모델을 여러 모델링 파일로 파티션해서 비단순 병합을 피할 수는 없습니다. 한 모델을 여러 모델링 파일로 파티션하는 경우 요소 상호 의존의 표시는 파일 내 참조 대신 상호 파일 참조가 됩니다. 다른 모델 파일에 있는 모델의 논리 컨텐츠를 알지 못하기 때문에 상호 파일 참조와 관련된 병합 충돌은 해결하기 곤란합니다. 병합을 수행해야 하는 경우에는 물리 파티션이 병합 세션을 보다 어렵게 합니다.

물리 모델 파티션은 다음 시나리오에 적합합니다.

모델을 물리적으로 파티션하지 않는 경우 논리 조직, 강한 논리 패키지 소유권 및 물리적으로 큰 모델 파일에 초점을 맞추십시오. Rational ClearCase를 사용하면, 개인용 정적 또는 동적 보기와 UCM 리베이스 및 전달을 사용하여 전체 통합을 완료할 때까지 모델 무결성을 유지하십시오.

또한 파티션 결정을 변경하지 않아도 되도록 논리 컨텐츠가 안정화되기 시작한 후에만 모델을 파티션하십시오. 예를 들어, 이전 버전의 모델은 종종 최상위 레벨 서브시스템을 묘사합니다. 이후 반복에 남을 가능성이 있는 최상위 레벨 서브시스템을 정의할 때까지 파티션하면 안됩니다. 최상위 레벨 서브시스템이 성장하여 안정화되면 분리가 모델 열기나 공개와 같은 타스크 성능이나 병행 개발 워크플로우를 개선하는 경우 물리적으로 서브시스템을 분리시킬 수 있습니다. 또한 공통으로 많이 공유하는 컴포넌트의 논리적 안정화에 먼저 초점을 맞추십시오. 이러한 컴포넌트를 변경하면 다른 모든 파티션에 영향을 주는 충돌이 야기될 수 있기 때문입니다.

동기화된 작업공간

모델 파티션에 대해 작업할 때 데이터 손상을 피하려면 항상 동일한 개정 레벨의 모든 파티션을 포함하는 동기화된 작업공간에서 작업해야 합니다.

예제

다음 예제는 동기화되지 않은 작업공간에서 모델의 파티션에 대해 작업하는 경우 발생할 수 있는 사항을 보여줍니다.

구성 관리 시스템에서 모델에 두 개의 파티션인 모델 X 및 모델 Y가 있습니다. 두 모델은 모두 버전 20입니다. 모델 X에는 P1이라는 하나의 패키지가 있습니다. 모델 Y는 비어 있습니다.

두 명의 사용자가 다음 워크플로우에 관여합니다.

  1. 사용자 A는 둘 모두 버전 20인 두 개의 모델을 체크아웃합니다.
  2. 사용자 A는 P1을 변경하고 P1을 모델 X에서 모델 Y로 이동시킵니다.
  3. 사용자 A는 모델 X 및 모델 Y를 체크인합니다. 현재 두 파일은 모두 버전 21입니다.
  4. 사용자 B는 작업공간에 버전 20의 모델 X를 가지고 있으며 P1을 변경합니다.
  5. 사용자 B가 변경사항을 저장하려 시도할 때 구성 관리 시스템은 사용자 B에게 작업 공간의 기존 버전(모델 X, 버전 20) 또는 보다 새 버전(모델 X, 버전 21)을 체크아웃하도록 프롬프트합니다.

사용자 B는 작업공간의 기존 버전(모델 X, 버전 20)을 선택하면 체크아웃을 프롬프트한 조작을 반복해야 합니다.

그러나 사용자 B가 보다 새 모델 버전(모델 X, 버전 21)으로 변경사항을 저장하는 경우에는 사용자 A가 수행한 변경사항을 겹쳐씁니다.


피드백