타스크: 변형 지향 분석 수행
이 타스크는 많은 분석과 디자인 요소에 적용 가능합니다. 이와 같은 요소에서 변동을 분리하여 공통성에 포함시키면 좀 더 견고하면서도 유연한 결과가 발생합니다.
목적

제공된 모델 요소를 분석하고 이 요소 중 여러 응용프로그램에 공통된 요소를 식별하여 여러 다른 요소에서 분리합니다. 응용프로그램에 따라 다른 요소를 식별하여 변동을 명시적으로 모델링하고 모델 요소의 클라이언트를 위해 이 변동을 문서화할 수 있습니다.

관계
역할기본: 추가: 지원:
입력필수:
  • 없음
선택사항: 외부:
  • 없음
출력
기본 설명

이 타스크는 분석 또는 디자인 모델에 적용 가능하며 모델의 요소는 여기에 설명된 기법의 혜택을 받을 수 있습니다. 이 기법은 제품 라인 엔지니어링의 경험과(여기서 공통 요소는 제품 라인의 제품을 통합하는 것, 변동은 제품 각각을 구별하는 것임) 패턴 개발(여기서 공통 요소는 패턴의 구조이며, 변동은 매개변수를 패턴으로 정의하는 데 사용)의 경험에서 생겨난 것입니다.

접근 방식은 첫 번째로 모든 응용프로그램에 공통된 디자인 요소를 식별하는 것, 다음은 각 응용프로그램에서 다양한 요소를 식별하는 것, 그리고 마지막으로 변동(차이)을 문서화하는 것입니다. (여기에서 서로 다른 접근 방식은 서로 다른 도메인에서 사용됩니다.)

예제

다음 클래스 다이어그램에서는 법적 계약의 요소를 볼 수 있으며 둘 이상의 관계자 간 계약을 식별합니다. 공통 요소 식별의 경우, 코어 요소는 계약 자체의 구조이며 관계자 간의 여러 관계입니다.

하지만 법적 계약은 서로 다른 사람, 조직 또는 정부 기관 간에 이루어지므로 관계자는 유형별 변수 요소입니다. 이것을 문서화하는 경우 관계자의 유형 계층 구조를 정의하고 관계자를 추상 클래스로 표시하여 구체적 유형을 실제 디자인에 사용해야 합니다.

단계
공통 및 변수 요소 식별

서로 다른 상황에서 사용 시 변경되지 않는 디자인 요소는 반복으로 가장 잘 식별됩니다. 시나리오 세트를 사용하여 인스턴스 다이어그램을 작성하고 요소가 모든 경우에 공통인 서로 다른 시나리오의 인스턴스 다이어그램을 비교할 시기를 확인하십시오. 사용 가능한 시나리오가 많을수록 사용 가능한 데이터 지점이 늘어나므로 결과 및 합계를 유효성 검증할 수 있습니다.

모델의 공통 요소를 설명하는 경우, 특정 양식의 캡슐화 요소를 제공하여 나머지 디자인에서 이 요소들을 분리하는 것이 좋습니다. 캡슐화 기법의 선택사항은 컨텍스트에 따라 다르지만 다음과 같을 수도 있습니다.

  • 요소가 있는 패키지 소개 - 요소 또는 패키지 밖의 요소 간 관계가 아닌 요소의 소유권만을 변경합니다. 이것은 일반적으로 분석 모델에 적용됩니다.
  • 요소가 있는 컴포넌트 소개 - 소유권을 변경하고 공식적인 캡슐화를 소개하여 외부로 관련 요소를 공개하는 인터페이스를 정의할 수 있습니다.
  • UML 2.0 협업 소개 - 이로 인해 공통 요소는 협업의 컴포지트 구조의 일부로, 변수 요소는 역할로 정의될 수 있습니다. 나중에 바인딩은 변수 요소 역할에서 작성되어 요소를 구체화할 수 있습니다. 이는 UML의 디자인 패턴을 정의하는 공통된 접근 방식입니다. 협업에는 요소는 없고, 요소에 해당하는 역할만 있습니다.
  • 템플리트화된 클래스 소개 - 여기에서는 템플리트가 변수 요소의 유형에 해당합니다. 이 소개는 Ada, C++, Eiffel 및 지금 일반 프로그래밍을 지원하는 Java와 같은 언어에 공통되는 접근 방식입니다.
  • 간단하게 비주얼 큐 사용을 선택할 수도 있습니다. 예를 들어, 일반적으로 단일 다이어그램을 사용하고(기본 설명에 표시된 대로) 공통과 변수 요소를 서로 다른 색으로 표시합니다.

예제

법적 계약의 경우, 아래 그림에 표시된 대로 요소가 포함될 컴포넌트 소개를 선택합니다.

변동 양식 문서화

변동에는 많은 양식이(해당 가능한 양식 모두) 있으며 어떤 경우에는 하나 이상의 양식이 제공된 상황에 있습니다. 공통된 변동 유형은 다음과 같습니다.

  • 유형별 변동 - 예를 들어, 법적 계약의 경우, 변동은 "관계자" 개념을 나타내는 데 사용하는 유형 계층 구조를 기반으로 합니다. 이는 매우 일반적인 양식이며 클래스 다이어그램으로서의 UML을 사용하여 쉽게 설명됩니다(기본 설명의 표시대로).
  • 역할별 변동 - 이 경우 요소의 유형은 일반적으로 중요하지 않거나 이차적인 문제입니다. 중요한 것은 역할입니다. 이러한 변동의 유형은 종종 패턴 개발에서 찾을 수 있습니다. 여기서 패턴은 넓은 가능성의 세트에 적용 가능하므로 패턴에 대한 매개변수가 제공된 요소에서만 수행하는 역할이라는 점에서 정의됩니다.
  • 구현 변동 - 이 경우 제공된 요소가 특정 동작을 수행하는 데 필요하므로 적용 가능한 제공된 인터페이스(또는 공식적으로 프로토콜)를 구현하는 데 필요합니다. 이와 같은 경우 공통 요소의 컨테이너에서는 대개 인터페이스를 설명하고 인터페이스 유형의 템플리트 매개변수를 포함하거나 인터페이스를 요청해야 합니다.

예제

다음 다이어그램에서는 역할별 변동 개념을 보여줍니다. 여기에는 새 협업 "판매"가 있는데 계약에 있는 파키로서 판매자와 구매자 간 관계를 표시합니다. UML에서 "구매자"와 "판매자"의 역할을 실제 모델 요소에 바인드하는 협업 발생을 작성할 수 있습니다.

또는 에스크로 서비스를 사용하는 판매 프로세스를 찾아보십시오. 인터페이스로서 모든 에스크로 서비스에 필요한 기능을 캡처합니다. 이 기능에는 에스크로 서비스에서 수행할 책임에 해당하는 오퍼레이션 세트가 있습니다. 이렇게 하여 템플리트화된 협업을 작성하는데, 여기에서 템플리트 매개변수의 유형으로서 에스크로 인터페이스를 사용합니다. 템플리트를 인스턴스화하여 IEscrowService 인터페이스를 실현하는 모든 클래스 또는 컴포넌트를 제공할 수 있습니다.

마지막으로, 좀 더 간단하게 컴포넌트(또는 클래스)를 사용하여 공통 요소를 포함하고 아래 다이어그램의 표시된 대로 UML 2.0 <<use>> 관계를 사용하여 IEscrowService 인터페이스를 사용하도록 합니다. 이 접근 방식은 특히 디자인 레벨에서 유용한데, 이는 이 접근 방식이 또한 컴포넌트 기반 개발의 공통 프로그래밍 접근 방식 또는 Java와 같은 언어의 접근 방식이기 때문입니다.

기법의 선택사항은 대개 다음과 같은 고려사항을 포함하는 상황에 따라 다릅니다.

  • 위와 같이 표시되는 변동 유형
  • 요소가 분석, 디자인 또는 모델 구현의 일부인지의 여부
  • 모델의 이해 당사자의 스킬 및 기대

특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보
가이드라인