타스크: 서브시스템 디자인(SOA)
이 타스크에서는 SOA 솔루션의 세부사항이 있는 일반 RUP 서브시스템 디자인을 확장합니다. 특히 서브시스템은 비즈니스 분석 모델에서 식별됩니다. 비즈니스 도메인에서 IT 도메인으로 상태 전이하면 비즈니스 도메인에서 정의된 기능 영역을 식별하여 서브시스템, 즉 IT 상대자에 맵핑할 수 있습니다.
원칙: 분석 및 디자인
확장: 서브시스템 디자인
목적

비즈니스 모델을 IT 상대자에게 링크하려면 다음을 수행합니다.

관계
기본 설명

타스크: 기능 영역 분석 중에 식별된 기능 영역에 해당하는 서브시스템 간 종속성을 결정 및 문서화합니다. 대개 기능 영역은 단일 서브시스템에 해당합니다. 즉, 대부분의 경우는 아니지만 많은 경우에 단순화한 가정이 정확하다는 것입니다. 기능 영역을 여러 서브시스템에 맵핑하도록 결정하는 경우, 이것이 실행 가능하고 유효할 수 있습니다. 하지만 대개 도메인 분해가 충분하지 않고 기능 영역이 세부적이지 않습니다.

단계
서브시스템 원점 문서화

타스크: 기능 영역 분석 중에 컴포넌트 비즈니스 맵에서 수신한 입력에 해당하는 서브시스템의 세트를 식별합니다(개념: 컴포넌트 비즈니스 모델링 참조). 프로세스 문서화 중에 식별된 리프 레벨 활동 노드는(개념: 비즈니스 프로세스 분해) Facade로서 서브시스템에서 제공하는 오퍼레이션 또는 서비스인 서브시스템에 위치합니다. 이 오퍼레이션의 기능성은 서비스 컴포넌트의 기능적 컴포넌트에서 실현됩니다. 또한 이 오퍼레이션을 서브시스템에서 제공하는 인터페이스로 그룹화할 수 있습니다. 오퍼레이션 비기능적 요구사항은 서브시스템에 필요한 기술적 컴포넌트를 찾는 데 사용됩니다.

식별된 서브시스템과 해당 소스 간 관계는 현재 상태를 유지해야 합니다. 비즈니스 레벨과 서비스 모델 중간 산출물 모두 UML에 있는 경우, 종속성 정보는 모델에 쉽게 저장될 수 있습니다. 반면에 이와 같은 정보는 템플리트: 워드의 서비스 모델에 저장되거나 연관된 중간 산출물에 저장되어야 합니다.

ISV 고려사항: 서비스는 기존 서브시스템(예: 사용자 정의 응용프로그램, 소프트웨어 패키지 및/또는 종속적인 소프트웨어 벤더)을 통해 실현 가능합니다. 경우에 따라 다음 섹션에서는 서브시스템 식별이 대개 기능 영역 분석 활동 중에 하향식으로 이루어지지만 새 서브시스템의 식별은 기준(데이터 선호도, 비용, 수행 등)을 기반으로 한 서비스의 실제 그룹화와 연관됨을 설명합니다. 아키텍처 계층에 대한 컴포넌트 할당은 비기능적 요구사항에서 주어진 아키텍처 제한조건을 충족시키기 위해 서비스 실현(realization)에서 설명됩니다.

예제

렌탈 에이전시 예제의 기능 영역 분석 결과는 다음 테이블에 있습니다.

도메인 기능 영역 서브시스템 설명
마케팅 및 고객 관리 고객 서비스 고객 서비스 기능 영역에 필요한 자동 기능 모두를 제공합니다.
제품 승격 관리 승격 관리 기능 영역에 필요한 자동 기능 모두를 제공합니다.
임대 차대 물류 차대 관리 차대 관리 기능 영역에 필요한 자동 기능 모두를 제공합니다.
임대 관리 임대 임대 기능 영역에 필요한 자동 기능 모두를 제공합니다.
임대 관리 예약 예약 기능 영역에 필요한 자동 기능 모두를 제공합니다.
임대 관리 가격 가격 기능 영역에 필요한 자동 기능 모두를 제공합니다.

위에서 식별한 서브시스템의 결과 UML 모델은 다음과 같습니다. 서브시스템 종속성은 이미 아래 표시된 모델에 제공되었습니다.

각 서브시스템의 경우, 다음과 유사한 양식으로 아티팩트: 디자인 서브시스템에서 설명된 세부사항을 문서화하거나 문서 양식 서비스 모델(템플리트: 워드의 서비스 모델)에서 캡처할 수 있습니다.

이름 예약
설명 예약 서브시스템은 자동차 임대 예약을 하고 관리하는 데 사용됩니다.
인터페이스
  • 차량 예약
  • 예약 수정
  • 옵션 정보 가져오기
  • 임대 계약 확인
  • 예약 찾기
  • 예약 취소
기능
  • 차량 예약
  • 예약 수정
  • 옵션 정보 가져오기
  • 임대 계약 확인
  • 예약 찾기
  • 예약 취소
종속성 없음
비기능적 요구사항 없음



서비스 컴포넌트 패턴 식별 및 적용

가이드라인: 서비스 컴포넌트 패턴의 소개에 따르면, 일반적으로 서로 다른 종류의 컴포넌트가 이 타스크 중에 식별된 서브시스템을 구현하는 데 사용될 뿐 아니라 패턴 세트로 이러한 서브시스템을 스케일 가능하고 유연하게 구현할 수 있습니다. 패턴과 추가 패턴이 존재하며(전체 세트가 아님) 프로젝트의 아키텍처 일부로 지정할 수 있습니다.

특정 패턴의 선택사항 또는 사용자 정의는 다음에 따라 다릅니다.

  • 솔루션 및 특정 서브시스템의 기능적, 비기능적 요구사항
  • 컴포넌트를 배치할 미들웨어에서 제공된 서비스의 기능 및 품질
  • 여러 패턴 간 비용/복합성 및 이점 절충
서비스 컴포넌트 식별

서브시스템은 IT 자산이 아니며 IT 하부 구조에 배치할 수 없습니다. 이 서브시스템은 비즈니스와 IT Perspective 간의 다리 역할을 합니다. 각 서브시스템은 서비스 컴포넌트가 엔터프라이즈 규모의 자산(보증된 가용성, 로드 밸런스, 보안, 성능 및 버전화가 있는 관리 소프트웨어 요소)인 경우 하나 이상의 서비스 컴포넌트에서 실현됩니다. 서비스 컴포넌트는 아래 다이어그램에 따라 다중 기능적 컴포넌트와 기술적 컴포넌트에서 번갈아 실현됩니다.

일반적으로 서브시스템에 지정된 각 서비스는 서비스 컴포넌트가 됩니다. 기능적 및 기술적 컴포넌트는 동일한 서브시스템에 있는 서비스 컴포넌트 간에 공유 가능합니다.

기능적 컴포넌트 식별

기능적 컴포넌트에서는 추가 비즈니스 기능을 서비스 컴포넌트에 제공합니다. 많은 점에서 서비스 컴포넌트에서 제공된 기능은 해당 기능적 컴포넌트 및 이 기능에 더해 구현되는 추가 비즈니스 로직에 따라 다릅니다.

기능적 컴포넌트는 종종 유형 관리자 간에서 찾을 수 있습니다. 이 컴포넌트는 특정 도메인 요소를 관리하며, 그 예로 "차량", "고객", "스케줄" 등이 있습니다. 이 도메인 요소는 단순한 구조이기보다는 세분화된 데이터 그래프임을 분명하게 해야 합니다.

예제

렌트카 예제를 고려할 때 예약 서비스 컴포넌트에서는 고객, 고객이 임대할 위치 및 고객이 지정한 클래스에서 사용 가능한 차량에 대한 세부사항을 통합해야 합니다. 또한 고객의 등급을 결정하여 문제가 발생한 경우(예: 사용 불가능한 차량), 적합한 레벨의 서비스를 제공할 수 있습니다. 다음 다이어그램에서는 예약의 컴포넌트 모델을 보여 줍니다.



기술적 컴포넌트 식별

기술적 또는 하부 구조 컴포넌트에서는 동급의 플랫폼 기능을 사용 가능하게 합니다. 이 컴포넌트 제공 기능은 특정 비즈니스 도메인용이 아닌 비즈니스 도메인 전체에 대한 것입니다. 이 기술적 서비스는 운영 체제를 포함한 미들웨어 제품에서 제공되며 이 서비스에 영향을 주는 서비스 컴포넌트 또는 기능적 컴포넌트에서 직접 사용됩니다.

예제

렌트카 컴포넌트 모델을 완성하는 경우(위의 기능적 컴포넌트 단계 참조), 두 개의 기술적 컴포넌트가 모델에 포함되는데, 하나는 예약 요청의 완료를 로그하는 예약용이고 다른 하나는 차량 및 위치 컴포넌트가 비즈니스 데이터를 계속 사용하는 EJB 서비스에 따라 다름을 나타냅니다.

또는 아래의 그림에 표시된 대로, 테이블 형식을 사용해 필수 컴포넌트와 이전에 식별된 서비스와의 관계를 나타낼 수 있습니다.



서브시스템 동작을 서브시스템 요소로 분배
목적 서브시스템의 내부 동작 지정.
서브시스템 동작 요구사항 충족에 필요한 새 디자인 클래스 또는 디자인 서브시스템 식별. 

서브시스템 외부 동작은 실현하는 인터페이스에 의해 주로 정의됩니다. 서브시스템이 인터페이스를 실현하는 경우 인터페이스에서 정의한 각각의 모든 오퍼레이션을 지원하도록 확약합니다. 오퍼레이션은 서브시스템에 포함된 디자인 요소에서 오퍼레이션으로 차례로 실현되고 (예: 디자인 클래스 또는 디자인 서브시스템) 해당 오퍼레이션에는 다른 디자인 요소와의 협업이 요청됩니다.

서브시스템의 모델 요소 협업은 서브시스템 동작이 실현되는 방법을 표시하는 시퀀스 다이어그램을 사용하여 문서화되어야 합니다. 서브시스템에서 실현되는 인터페이스의 각 오퍼레이션에는 문서화된 시퀀스 다이어그램이 포함되어야 합니다. 서브시스템이 해당 다이어그램을 소유하고 서브시스템의 내부 동작 디자인에 사용됩니다.

서브시스템 동작이 상태에 의존하는 정도가 높고 하나 이상의 제어 스레드를 표시하는 경우 상태 머신이 일반적으로 서브시스템 동작 설명에 유용하게 사용됩니다. 이 컨텍스트에서 상태 머신은 일반적으로 시스템(이 경우에는 서브시스템)의 제어 스레드 분리를 나타내는 활성 클래스와 같이 사용되고 상태 차트 다이어그램에 설명됩니다. 상태 차트: 상태 차트 다이어그램를 참조하십시오. 실시간 시스템에서 중간 산출물: 캡슐의 동작도 상태 머신을 사용하여 설명됩니다.서브시스템에서 활성 클래스로 표시되는 실행 독립 스레드가 있을 수 있습니다.

실시간 시스템에서 중간 산출물: 캡슐은 해당 스레드 캡슐화에 사용됩니다.

예제:

시스템의 필수 동작 몇 가지를 수행하기 위한 서브시스템 협업은 시퀀스 다이어그램을 사용하여 표시될 수 있습니다.

함께 표시된 텍스트에서 설명되는 다이어그램

이 다이어그램은 서브시스템 인터페이스가 시나리오 수행에 사용되는 방법을 표시합니다. 특히, 네트워크 처리 서브시스템에 대해 서브시스템이 지원해야 하는 특수한 인터페이스(이 경우 ICoordinator) 및 오퍼레이션을 보게 됩니다. 또한, 네트워크 처리 서브시스템이 IBHandler 및 IAHandler 인터페이스에 종속되는 것도 보게 됩니다.

서브시스템을 자세히 보면 ICoordinator 인터페이스가 실현되는 방법을 알게됩니다.

함께 표시된 텍스트에서 설명되는 다이어그램

Coordinator 클래스는 ICoordinator 인터페이스의 "프록시"로 수행되어 인터페이스 오퍼레이션을 처리하고 인터페이스 동작을 조합합니다.

이 "내부" 시퀀스 다이어그램은 인터페이스를 제공하는 클래스, 서브시스템 기능 제공을 위해 내부에서 발생해야 하는 작업 및 서브시스템에서 메시지를 송신하는 클래스를 정확히 표시합니다. 이 다이어그램은 내부 디자인을 명백하게 설명하며 복잡한 내부 디자인으로 되어있는 서브시스템에는 반드시 필요합니다. 또한 서브시스템 동작을 더 쉽게 이해하도록 도와주며 컨텍스트에서 재사용가능하도록 렌더링하기도 합니다.

이러한 "인터페이스 실현(realization)" 다이어그램 작성은 필요한 동작을 수행하는 새 클래스 및 서브시스템을 작성하는 데 필요합니다. 프로세스는 유스 케이스 분석에 정의된 프로세스와 비슷하지만, 유스 케이스 대신 인터페이스 오퍼레이션에 대해 작업하게 됩니다. 각 인터페이스 오퍼레이션에 대해 오퍼레이션 수행에 필요한 현재 서브시스템의 클래스(또는 필수 동작이 복잡한 경우 포함된 서브시스템)를 식별합니다. 기존 클래스/서브시스템에서 필요한 동작을 제공하지 못하는 경우(그래도 재사용은 시도해야 함) 새 클래스/서브시스템을 작성하십시오.

새 디자인 요소를 작성하면 서브시스템 컨텐츠 및 경계를 다시 고려해야 합니다. 다른 두 서브시스템에서 유효한 동일한 클래스를 만들지 마십시오. 이런 클래스를 만들게 되면 서브시스템 경계를 잘 나타낼 수 없게됩니다. 주기적으로 타스크: 디자인 요소 식별을 다시 검토하여 서브시스템 책임의 밸런스를 재조정하십시오.

서브시스템 클라이언트를 대상으로 하는 스펙과 구현자를 대상으로 하는 실현(realization)과 같이 서브시스템의 독립된 두 개의 내부 모델을 작성하면 유용할 때가 있습니다. 스펙에는 "이상적인" 클래스 및 협업이 포함되어 이상적인 클래스 및 협업의 관점으로 서브시스템 동작을 설명합니다. 반면에 실현은 구현에 더 가깝게 대응되고 결국 구현으로 전개됩니다. 디자인 서브시스템 스펙 및 실현에 대한 자세한 정보는 중간 산출물 가이드라인: 디자인 서브시스템, 서브시스템 스펙 및 실현을 참조하십시오.

서브시스템 요소 문서화
목적 서브시스템 내부 구조 문서화. 

서브시스템의 내부 구조를 문서화하려면 서브시스템에 포함된 요소와 다른 요소와의 연관을 표시하는 하나 이상의 클래스 다이어그램을 작성하십시오. 하나의 클래스 다이어그램으로 충분하지만 복잡도를 줄이고 이해도를 높이기 위해 여러 개를 사용할 수도 있습니다.

예제 클래스 다이어그램이 아래 표시됩니다.

함께 표시된 텍스트에서 설명되는 다이어그램

주문 입력 시스템의 예제 클래스 다이어그램

컴포넌트로 모델링된 서브시스템의 내부 컨텐츠는 컴포넌트 다이어그램의 컴포넌트 직사각형에 대신 표시될 수 있습니다. 이 표시를 이용하면 인터페이스를 통해 수행되는 이 서브시스템의 다른 시스템 파트에 대한 상호작용을 포함할 수 있습니다.

아래 표시된 컴포넌트 다이어그램의 예제에는 주문 서브시스템, 주문 서브시스템의 내부 컨텐츠 및 제공하는 필수 인터페이스도 표시됩니다.

함께 표시된 텍스트에서 설명되는 다이어그램

주문 서브시스템의 예제 컴포넌트 다이어그램

컴포넌트는 구조화된 클래스이기 때문에 선언된 인터페이스에 따라 포트를 통해 전달하도록 외부에서 통신을 강제 실행하면 더 강력하게 캡슐화됩니다. 이에 따라 해당 컴포넌트의 스펙 및 상호 연결의 정밀도가 증가합니다. 이 표시에서 컴포넌트 구현의 특정 역할을 수행하도록 커넥터를 통해 파트 인스턴스를 "연결"할 수 있습니다(추가 정보는 개념: 구조화된 클래스 참조).

인터페이스와 포트를 사용하는 주문 서브시스템의 컴포지트 구조 다이어그램 예제가 아래 표시됩니다.

함께 표시된 텍스트에서 설명되는 다이어그램

주문 서브시스템의 컴포지트 구조 다이어그램 예제



추가로 상태 차트 다이어그램은 서브시스템에서 예상 가능한 상태를 문서화해야 하며, 기법: 상태 차트 다이어그램을 참조하십시오.

서브시스템 자체에 포함된 클래스 설명은 타스크: 클래스 디자인에서 처리됩니다.

서브시스템 종속성 설명
목적 서브시스템이 종속된 인터페이스 문서화. 

서브시스템이 포함한 요소에서 기타 서브시스템이 포함하는 요소 동작을 사용하는 경우 엔클로징 서브시스템 간에 종속성이 작성됩니다. 재사용을 증대하고 유지보수 종속성을 줄이기 위해 서브시스템 자체 또는 서브시스템에 포함된 요소에 대해서가 아닌 서브시스템의 특정 인터페이스 종속성에 대해 표시합니다.

이유는 두 가지가 있습니다.

  • 모델 요소가 동일한 동작을 제공하는 경우 하나의 모델 요소(서브시스템 포함)를 다른 요소로 대체할 수 있습니다. 인터페이스와 연관된 필수 동작을 지정하여 임의의 모델 요소에 있는 동작 요구사항이 인터페이스에 연관되어 표현되어야 합니다.
  • 디자이너가 서브시스템의 내부 동작을 디자인할 때 올바른 외부 동작을 제공하기만 하면 디자이너가 원하는 방식으로 디자인하도록 허용합니다. 임의의 서브시스템 모델 요소가 다른 서브시스템의 모델 요소를 참조하는 경우 디자이너는 해당 모델 요소를 임의로 제거하거나 모델 요소의 동작을 다른 요소로 재분배할 수 없습니다. 결과적으로 시스템이 손상되기 쉬워집니다.

종속성을 작성할 때 서브시스템에 포함된 모델 요소와 기타 서브시스템에 포함된 모델 요소 간에 직접적인 종속성이나 연관이 없도록 하십시오. 서브시스템과 인터페이스에 순환되는 종속성이 없는지도 확인하십시오. 서브시스템이 인터페이스를 실현하지도 못하고 의존할 수도 없는 상태가 되면 안됩니다.

서브시스템 간의 종속성 및 서브시스템과 패키지 간의 종속성은 아래와 같이 직접적으로 그릴 수 있습니다. 이 방식으로 표시되면 종속성은 임의의 서브시스템(예: 송장 관리)이 다른 서브시스템(예: 지불 스케줄 관리)에 직접 의존하게 됩니다.


함께 표시된 텍스트에서 설명되는 다이어그램

직접 종속성을 사용하는 서브시스템 계층화 예제

임의의 서브시스템에서 다른 서브시스템으로 잠재적인 대체가 있는 경우(동일한 인터페이스 포함) 종속성은 서브시스템 자체가 아닌 서브시스템에서 실현되는 인터페이스로 표시됩니다. 이를 통해 사용되는 동일한 인터페이스를 실현하는 다른 모든 모델 요소(서브시스템 또는 클래스)가 허용됩니다. 인터페이스 종속성을 사용하면 교체 가능한 디자인 요소를 사용하여 디자인되는 융통성있는 프레임워크를 사용할 수 있습니다.


함께 표시된 텍스트에서 설명되는 다이어그램

인터페이스 종속성을 사용하는 서브시스템 계층화 예제

 

자세한 정보