활동:
|
목적
|
|
역할: 설계자 | |
빈도: 설계 서브시스템당 한 번. | |
단계 | |
입력물: | 결과물: |
툴 강좌: | |
자세한 정보: | |
워크플로우 세부사항: |
목적 | 서브시스템의 내부 작동을 지정하기 위함입니다. 서브시스템 작동 요구사항을 만족시키는데 필요한 새 설계 클래스 또는 설계 서브시스템을 식별하기 위함입니다. |
서브시스템 내 모델 요소의 공동 작업은 서브시스템 작동이 구현되는 방법을 표시하는 순서 다이어그램을 사용하여 문서화되어야 합니다. 서브시스템이 구현한 인터페이스의 각 조작은 하나 이상의 문서화된 순서 다이어그램이 있어야 합니다. 이 다이어그램은 서브시스템이 소유하며 서브시스템의 내부 작동이 설계하는데 사용합니다.
서브시스템의 작동이 매우 상태 의존적이며 하나 이상의 제어 스레드를 표시하는 경우, 상태 시스템은 일반적으로 서브시스템 작동을 설명하는데 보다 유용합니다. 이런 상황에서 상태 시스템은 일반적으로 활성 클래스와 함께 사용되어 시스템(또는, 이 경우 서브시스템)의 제어 스레드 분리를 표시하며 상태 차트 다이어그램에 설명되어 있습니다. 가이드라인: 상태 차트 다이어그램을 참조하십시오.
서브시스템 내에 활성 클래스로 표시되는 독립적 실행 스레드가 있을 수도 있습니다.
예:
시스템의 일부 필수 작동을 수행하기 위한 서브시스템의 공동 작업은 순서 다이어그램을 통해 다음과 같이 표현될 수 있습니다.
이 다이어그램은 서브시스템의 인터페이스가 시나리오를 수행하는데 사용되는 방법을 표시합니다. 특히, 네트워크 처리 서브시스템의 경우, 서브시스템이 지원해야 하는 조작 및 특정 인터페이스(이 경우, ICoordinator)가 표시됩니다. 또한 NetworkHandling 서브시스템이 IBHandler 및 IAHandler 인터페이스에 종속적임이 표시됩니다.
서브시스템의 내부를 살펴보면 다음과 같이 ICoordinator 인터페이스가 구현되는 방법을 알 수 있습니다.
Coordinator 클래스가 ICoordinator 인터페이스의 "프록시" 역할을 하며 인터페이스 조작을 처리하고 인터페이스 작동을 조정합니다.
이 "내부" 순서 다이어그램이 인터페이스를 제공하는 클래스, 서브시스템 기능을 제공하기 위해 내부적으로 발생해야 하는 사항, 서브시스템에서 메시지를 전송하는 클래스를 정확히 표시합니다. 다이어그램이 내부 설계를 명확히 하며 복잡한 내부 설계의 서브시스템에 매우 중요합니다. 또한 서브시스템 작동이 쉽게 이해되도록 하며 컨텍스트 전반에 걸쳐 재사용 가능하도록 렌더링할 수도 있습니다.
이러한 "인터페이스 구현" 다이어그램을 작성함으로써 필수 작동을 수행할 새 클래스 및 서브시스템을 작성해야 할 수도 있습니다. 프로세스는 유스 케이스 분석에서 정의한 프로세스와 유사하지만 유스 케이스 대신 인터페이스 조작을 사용하여 작업합니다. 각 인터페이스 조작에 대해 조작을 수행하는데 필요한 현재 서브시스템의 클래스(또는 필수 작동이 복잡한 일부 경우, 포함된 서브시스템)를 식별하십시오. 기존 클래스/서브시스템이 필수 작동을 제공할 수 없는 경우 새 클래스/서브시스템을 작성하십시오. (하지만 우선 재사용을 시도하십시오.)
새 설계 요소의 작성은 서브시스템 컨텐츠와 경계를 다시 고려하도록 해야 합니다. 두 별개의 서브시스템에 사실상 동일한 클래스가 없도록 주의하십시오. 이러한 클래스의 존재는 서브시스템 경계가 제대로 지정되지 않았을 수도 있다는 것을 의미합니다. 정기적으로 활동: 설계 요소 식별을 다시 방문하여 서브시스템 책임의 균형을 다시 맞추십시오.
때때로 서브시스템의 두 별개 내부 모델(서브시스템 클라이언트 대상 스펙 및 구현자 대상 구현)을 작성하는 것이 유용합니다. 스펙에는 "이상적" 클래스와 공동 작업이 포함되어 이상적 클래스와 공동 작업 관점에서 서브시스템의 작동을 설명할 수도 있습니다. 한편, 실현화는 구현에 보다 밀접하게 대응하며 구현이 되도록 전개될 수 있습니다. 설계 서브시스템 스펙 및 구현에 대한 자세한 정보는 가이드라인: 설계 서브시스템, 서브시스템 스펙 및 구현을 참조하십시오.
목적 | 서브시스템의 내부 구조를 문서화하기 위함입니다. |
서브시스템의 내부 구조를 문서화하려면 서브시스템이 포함하는 요소와 상호 연관을 표시하는 하나 이상의 클래스 다이어그램을 작성하십시오. 한 클래스 다이어그램으로 충분하지만 더 많은 다이어그램을 사용하여 복잡도를 줄이고 판독성을 향상시킬 수 있습니다.
클래스 다이어그램 예제는 아래에 표시됩니다.
주문 입력 시스템의 클래스 다이어그램 예제.
컴포넌트로 모델화되어 서브시스템의 내부 컨텐츠는 컴포넌트 다이어그램의 컴포넌트 사각형 안에 대신 표시될 수 있습니다. 이 표시를 사용하여 이 서브시스템의 상호작용 위치를 시스템의 기타 파트에 포함시킬 수도 있으며 이는 해당 인터페이스를 통해 완료됩니다.
컴포넌트 다이어그램의 예가 아래에 표시되어 제공된 필수 인터페이스뿐 아니라 내부 컨텐츠와 주문 서브시스템을 묘사합니다.
주문 서브시스템의 컴포넌트 다이어그램 예제
컴포넌트가 구조화된 클래스이므로 선언된 인터페이스를 준수하는 포트를 통해 전달되도록 외부로부터 의사소통을 시행하여 단단히 캡슐화될 수 있습니다이 표시를 사용하여 커넥터를 통해 파트의 인스턴스를 "전송"하여 컴포넌트 구현에서 특정 역할을 수행하도록 합니다(자세한 정보는 개념: 구조화된 클래스 참조).
인터페이스와 포트를 사용한 주문 서브시스템의 합성 구조 다이어그램 예가 아래 표시됩니다.
주문 서브시스템의 합성 구조 다이어그램 예제
또한 서브시스템이 가정할 수 있는 가능한 상태를 문서화하도록 상태 차트 다이어그램이 필요할 수도 있습니다. 가이드라인: 상태 차트 다이어그램을 참조하십시오.서브시스템 자체에 포함된 클래스의 설명은 활동: 클래스 설계에서 처리합니다.
목적 | 서브시스템이 의존하는 인터페이스를 문서화하기 위함입니다. |
서브시스템에 포함된 요소가 기타 서브시스템에 포함된 요소의 일부 작동을 사용하는 경우, 포함된 서브시스템 간의 종속성이 작성됩니다. 재사용을 향상시키고 유지보수 종속성을 줄이도록 이를 서브시스템 자체나 서브시스템에 포함된 요소가 아닌 특정 시스템의 인터페이스에 대한 종속성 관점에서 표현하고자 합니다.
그 이유에는 두 요소가 있습니다.
종속성 작성시, 서브시스템에 포함된 모델 요소와 기타 서브시스템에 포함된 모델 요소 간의 직접적인 종속성 또는 연관이 없음을 확인하십시오. 또한 서브시스템과 인터페이스 간의 순환 종속성이 없음을 확인하십시오. 서브시스템이 인터페이스를 구현하고 동시에 인터페이스에 종속적일 수 없습니다.
서브시스템 간, 서브시스템과 패키지 간의 종속성은 아래에 표시된 대로 직접 묘사될 수 있습니다. 이런 식으로 표시하는 경우, 한 시스템(예: 송장 관리)을 설명하는 종속성이 기타 서브시스템(지불 스케줄링 관리)에 직접 종속적입니다.
직접 종속성을 사용한 서브시스템 계층화의 예제
한 시스템을 다른 시스템으로 대체할 잠재성이 있는 경우(동일한 인터페이스가 있는 경우), 종속성은 서브시스템 자체가 아니라 서브시스템이 구현한 인터페이스로 묘사될 수 있습니다. 이로써, 동일한 인터페이스가 사용되도록 구현하는 임의의 기타 모델 요소(서브시스템 또는 클래스)가 허용됩니다. 인터페이스 종속성을 사용하여 교체 가능 설계 요소로 유연한 프레임워크를 설계할 수 있습니다.
인터페이스 종속성을 사용한 서브시스템 계층화 예제
직접 종속성을 사용한 서브시스템 계층화의 예
인터페이스 종속성을 사용한 서브시스템 계층화 예제
자세한 정보는 UML 1.x와 UML 2.0의 차이점을 참조하십시오.
Rational Unified Process
|