가이드라인:
|
|
자세히 |
---|---|
선택사항 찾기 | 특정 협력(또는 서브협업)이 선택사항 작동이면 이를 서브시스템 내에 포함시키십시오. 제거, 갱신 또는 대안으로 바꿀 수 있는 기능은 독립적 기능으로 간주합니다. |
시스템의 사용자 인터페이스 찾기 | 사용자 인터페이스가 시스템 내의 엔티티 클래스와 비교적 독립적인 경우(두 개를 독립적으로 변경할 수 있으므로 독립적으로 변경할 경우) 수평적으로 통합되는 서브시스템을 작성하십시오. 관련된 사용자 인터페이스 경계 클래스를 함께 서브시스템으로 그룹화하고 관련 엔티티 클래스를 다른 서브시스템으로 그룹화하십시오. |
표시되는 사용자 인터페이스 및 엔티티 클래스가 긴밀하게 결합되어 있으면(한 트리거를 변경하면 다른 트리거도 변경해야 함) 수직적으로 통합되는 서브시스템을 작성하십시오. 관련된 경계 및 엔티티 클래스를 공통 서브시스템에 포함시키십시오. | |
액터 찾기 | 각 액터는 독립적으로 시스템에 대한 요구사항을 변경시키므로 두 액터가 사용하는 기능을 별도로 분리하십시오. |
외부 시스템 또는 장치에 대한 액세스를 캡슐화하는 서브시스템 작성 | |
설계 요소 간의 결합 또는 응집력 찾기 | 결합 또는 응집력이 높은 클래스/서브시스템은 협력하여 서비스 세트를 제공합니다. 결합도가 높은 요소를 서브시스템으로 구성하고 결합도가 낮은 요소별로 분리하십시오. 어떤 경우에는 응집력이 높은 책임을 가진 더 작은 클래스로 클래스를 분할하거나 서브시스템을 적절히 재파티션하여 결합력이 낮은 요소를 완전히 제거할 수도 있습니다. |
대체 찾기 | 특정 기능에 대해 여러 레벨의 서비스가 지정되어 있으면 (예: 고, 중 및 저 사용 가능성) 각 서비스 레벨을 각각 동일한 인터페이스 세트를 구현하는 별도의 서브시스템으로 나타내십시오. 이를 수행하여 서브시스템을 다른 서브시스템으로 대체할 수 있습니다. |
분배 관찰 | 특정 시스템에 대해 각각 다른 노드에서 실행되는 복수의 인스턴스가 있다 해도 많은 구조에서 노드에 걸쳐 컴포넌트의 단일 인스턴스를 분할하는 것은 불가능합니다. 노드에 걸쳐 서브시스템 작동을 분할해야 하는 경우, 서브시스템을 좀더 제약이 많은 더 작은 서브시스템(각각 단일 컴포넌트를 나타냄)으로 분해하는 것이 좋습니다. 각 노드에 있어야 하는 노드를 결정한 후, 원래 서브시스템의 책임 및 관련 요소를 적절히 분배하여 해당 기능을 '소유'할 새 서브시스템을 작성하십시오. 새 서브시스템은 원래 서브시스템에 대해 내부적입니다. |
설계를 서브시스템으로 조직했으면 유스 케이스 구현을 알맞게 갱신하십시오.
설계 서브시스템은 UML 컴포넌트를 사용하여 모델화됩니다. 이 구성은 다음과 같은 모델링 기능을 제공합니다.
다른 고려사항은 다음과 같습니다.
참고: UML 2.0은 <<서브시스템>>이라는 컴포넌트의 스테레오타입도 정의하여 서브시스템이 사용될 수 있음을 나타냅니다(예: 대규모 구조를 표현할 경우에). RUP 설계 서브시스템은 대형 구조일 수도 있고 소형 구조일 수도 있습니다. 둘 다 RUP Perspective에서 보면 설계 서브시스템입니다. 이는 소프트웨어 아키텍트가 결정해야 할 문제입니다(예: 컴포넌트로 합성된 컴포넌트를 <<서브시스템>>이라고 할지 여부).
기존의 제품이 인터페이스를 내보내는 제품(예: 조작 또는 영수증일 수도 있음)이지만 숨겨진 구현을 상세히 보존할 경우, 논리 보기에 서브시스템으로 모델화할 수 있습니다. 서브시스템으로 표현할 수 있는, 시스템이 사용하는 제품의 예에는 다음이 포함됩니다.
유형 콜렉션 및 데이터 구조와 같은 기존의 일부 제품(예: 스택, 목록, 큐)은 더 많은 작동을 표시하기 때문에 패키지라고 표현하는 것이 더 낫습니다. 이들은 중요하고 유용한 패키지의 특정 내용으로서, 패키지가 아닌 단지 컨테이너입니다.
필요에 의해서든 아니면 모델화된 작동의 본질에 대한 설계자의 판단에 따라서든 단순히 인터페이스를 내보낼 경우, math 라이브러리와 같은 공통 유틸리티는 서브시스템으로 표현될수 있습니다. 서브시스템은 객체 지향 구조입니다(모델화된 컴포넌트이기 때문에). 서브시스템은 인스턴스를 가질 수 있습니다(설계자가 그렇게 지정한 경우). UML은 스테레오타입이 클래스인 유틸리티 (유틸리티는 인스턴스가 없음) 내의 글로벌 변수 및 프로시저 그룹을 모델화하는 다른 방법을 제공합니다.
제품을 표시할 서브시스템을 정의할 때 제품 인터페이스를 표현할 하나 이상의 인터페이스도 정의하십시오.
설계 서브시스템(UML 구성요소로 모델화됨)은 의미론적인 면에서 다릅니다. 서브시스템은 이를 구현하는 하나 이상의 인터페이스를 통해 작동을 제공합니다. 패키지는 작동을 제공하지 않습니다. 패키지는 단지 작동을 제공하는 것들의 컨테이너입니다.
패키지가 아닌 서브시스템을 사용하는 이유는 서브시스템은 컨텐츠를 캡슐화하여 인터페이스를 통해서만 작동을 제공하기 때문입니다. 서브시스템을 사용하면, 패키지와는 달리 서브시스템의 인터페이스가 변경되지 않은 한 시스템의 컨텐츠 및 내부 작동을 자유롭게 변경할 수 있습니다. 서브시스템은 '대체 가능한 설계' 요소도 제공합니다. 동일한 인터페이스(또는 <<스펙>> 구성요소)를 구현하는 임의의 두 <<구현화>> 컴포넌트는 상호 변경가능합니다.
모델에서 서브시스템을 대체할 수 있으려면 몇 가지 규칙을 지켜야 합니다.
서브시스템 및 패키지 종속성 예제가 다음에 나와 있습니다.
설계 모델의 서브시스템 및 패키지 종속성
UML([UML04])은 다음에 대해 기술합니다.
컴포넌트(예: 별개의 스펙과 구현 정의를 가진 컴포넌트를 모델화하기 위한 <<스펙>> 및 <<구현>>(하나의 스펙이 여러 구현을 가질 수 있음))에 적용되는 여러 개의 UML 표준 스테레오타입이 존재합니다.
<<스펙>> 스테레오타입을 가진 구성요소는 이러한 객체의 실제 구현을 정의하지 않고 객체 도메인을 지정합니다. 이 구성요소는 제공된 필수 인터페이스만 가지며 정의의 일부로 구현 클래스 및 서브구성요소를 갖도록 되어 있지는 않습니다.
<<구현>> 스테레오타입을 가진 컴포넌트는 객체 도메인을 지정하며 이러한 객체의 실제 구현을 정의합니다. 예를 들어, <<구현>> 스테레오타입을 가진 컴포넌트는 별도의 <<스펙>> 컴포넌트에 지정된 작동을 구현하는 구현 클래스 및 서브 컴포넌트만을 갖습니다.
스펙 및 구현을 본질적으로 분리하면 서브시스템에 대한 두 개의 다른 설명이 있을 수 있습니다. 스펙은 클라이언트가 서브시스템을 사용하기 위해 알아야 하는 모든 것을 정의하는 계약입니다. 구현은 구현자를 안내하도록 만들어진 상세한 내부 설계입니다. 복수의 구현을 지원하려면, 별도의 "구현" 서브시스템을 작성하고 각 구현 서브시스템에서 스펙 서브시스템으로의 구현을 작성하십시오.
서브시스템의 내부 상태 및 작동이 비교적 간단하면 표시된 인터페이스, 작동을 설명하는 상태 다이어그램 및 설명 텍스트만으로도 충분히 서브시스템을 지정할 수 있습니다.
보다 복잡한 내부 상태 및 작동의 경우, 분석 클래스를 사용하여 높은 추상 레벨로 서브시스템을 지정할 수 있습니다. 대형 시스템의 경우, 서브시스템 스펙은 유스 케이스도 포함할 수 있습니다. Rational Unified Process를 사용하여 대형 시스템 개발을 참조하십시오.
다음과 같은 경우에는 구현과 별도로 상세한 스펙을 제공하는 것이 가장 중요합니다.
누군가가 서브시스템의 구현이 스펙과 호환되는지 확인해야 하기 때문에
별도의 스펙을 유지보수하는 데 노력이 필요합니다.
별도의 스펙, 구현 클래스 및 협력을 작성해야 하는지와 작성 시기에 대한 기준은
결과물: 프로젝트 특정 가이드라인에 설명되어 있습니다.
스펙은 해당 종속성을 정의해야 합니다. 종속성은 인터페이스 및 다른 서브시스템에 있는 인터페이스 및 가시적인 요소이며 서브시스템의 모든 호환 가능한 구현에서 사용 가능해야 하는 패키지입니다.
구현은 추가 종속성을 갖고 있으며 구현자 또는 설계자가 도입합니다. 예를 들어, 구현을 단순화하기 위해 유틸리티 컴포넌트를 사용할 기회가 있을 수 있습니다. 그러나 이 유틸리티 컴포넌트를 사용하면 세부사항을 클라이언트에게 표시할 필요가 없습니다. 이 추가 종속성은 별도의 다이어그램에서 구현의 일부로 캡처되어야 합니다.
아주 자세한 스펙은 클라이언트가 서브시스템을 사용하는 데 필요한 모든 것을 정의합니다. 이는 코드와 일 대 일로 대응하도록 표시된 인터페이스와 모든 가시적인 공용 요소를 정제함을 의미합니다. 서브시스템의 작동을 지정하기 위해 도입된 분석 클래스는 모든 서브시스템 구현과 독립적이기 때문에 상위 레벨의 추상으로 유지됩니다.
서브시스템의 구현 요소는 코드와 근접해져야 합니다.
이 주제에 대한 자세한 토론 내용은 개념: 설계에서 코드로 맵핑을 참조하십시오.
설계 서브시스템은 UML 2.0 컴포넌트 또는 UML 1.5 서브시스템으로 모델화될 수 있습니다. 이러한 구성은 모듈 방식, 캡슐화 및 런타임시 실행할 수 있는 인스턴스와 같이 거의 동등한 모델링 기능을 제공합니다.
이 모델링 선택사항에 대한 일부 추가 고려사항은 다음과 같습니다.
그러나 전반적으로 이 표기법은 상호 교환적으로 사용될 수 있습니다.
설계 서브시스템을 UML 1.5 서브시스템으로 표시할지 또는 UML 2.0 컴포넌트로 표시할지를
결정하는 것은 해당 프로세스/프로젝트에 맞게 조정된
프로젝트 특정 가이드라인에 문서화되어 있습니다.
비주얼 모델링 툴이 UML 1.5 패키지는 지원하나 UML 1.5 서브시스템은 지원하지 않을 경우, 스테레오타입이 <<서브시스템>>인 패키지를 사용하여 서브시스템을 표기할 수 있습니다.
동일한 종속성 제한사항 및 서브시스템 종속성 제한사항 섹션에 언급된 토론 내용도 UML 1.5 서브시스템으로 모델화되고 있는 설계 서브시스템에 적용됩니다.
UML 1.5에서의 서브시스템 및 패키지 종속성 예제가 아래에 표시되어 있습니다.
설계 모델에서의 서브시스템 및 패키지 종속성
서브시스템의 컨텐츠는 두 개의 서브세트, 1) 스펙
요소 및 2) 구현 요소로 나뉘어져 있습니다. 시스템 조작 및 수령과 함께 스펙 요소는
구현 요소가 제공하는 작동의 추상
스펙을 제공하는 데 사용됩니다. 구현 요소의 콜렉션은
실제 시스템의 작동 단위의 내부를 설계합니다.
스펙 및 구현을 본질적으로 분리하면 서브시스템에 대한 두 개의 다른 설명이 있을 수 있습니다. 스펙은 클라이언트가 서브시스템을 사용하기 위해 알아야 하는 모든 것을 정의하는 계약 역할을 합니다. 구현은 구현자를 안내하기 만들어진 상세한 내부 설계입니다.
모델링 환경에 의해 직접 지원되지 않을 경우, 스펙 및 구현 모델링에 대한 한 가지 선택사항은 각 서브시스템의 내부에 두 개의 패키지(스펙 및 구현)를 배치하는 것입니다.
스펙에 대한 한 가지 모티베이션은 복수의 구현을 지원하는 것입니다. 이는 UML 1.x에서는 직접 지원되지 않았습니다. UML 1.5 서브시스템을 사용하여 복수의 구현을 지원하려면 별도의"구현" 서브시스템을 작성한 후 각 구현 서브시스템에서 스펙 서브시스템으로의 구현을 작성하십시오.
기본적으로 UML 2.0에 적용되는 스펙 및 구현에 적용된 것과 동일한 고려사항이 여기에도 적용됩니다(자세한 설명은 사용 시기 및 방법, 종속성 및 구현 관계 참조).
자세한 정보는 UML
1.x과 UML 2.0 간의 차이를 참조하십시오.
Rational Unified Process
|