서브시스템을 여러 보충 방법으로 사용하여 다음과 같은
단위로 시스템을 파티션할 수 있습니다.
-
독립적으로 주문, 구성 또는 전달될 수 있는 단위
-
인터페이스가 변경되지 않는 한 독립적으로 개발될 수 있는 단위
-
분산된 계산 가능한 노드 세트에서 독립적으로 배치될 수 있는 단위
-
시스템의 다른 파트를 중단하지 않고 독립적으로 변경될 수 있는 단위
따라서 서브시스템은 단일 디자인 클래스보다 더 큰 컴포넌트(컴포넌트 기반 개발 시 바뀔 수 있는 어셈블리 단위)를 모델링하는 데 적합합니다.
또한 서브시스템을 사용하여 다음을 수행할 수 있습니다.
-
시스템을 주요 자원에 제한된 보안을 제공할 수 있는 여러 단위로 파티션할 수 있습니다.
-
디자인 시 외부 시스템 또는 기존의 제품을 표시할 수 있습니다.
복잡한 분석 클래스가 단독으로 활동하는 단일 디자인 클래스의 책임일 수 없는 동작을 포함하는 경우 디자인 서브시스템에 맵핑됩니다. 협업 클래스의 세트로 구현할 수 있는 경우 복잡한 디자인 클래스도 서브시스템이 될
수 있습니다.
서브시스템은 별도의 팀에서 독립적으로 개발할 시스템의 파트를 식별하는 좋은 수단이기도 합니다. 협업 디자인 요소가 해당 협업과 함께 패키지에 완전히 포함될 수 있으면 서브시스템은 단순 패키지보다 더 강력한 양식의
캡슐화를 제공할 수 있습니다. 서브시스템의 컨텐츠 및 협업은 하나 이상의 인터페이스 이면에서 완전히 분리되므로 서브시스템의 클라이언트는 인터페이스에만 종속됩니다. 그러면 서브시스템의 디자이너가 외부 종속성에서
완전히 분리됩니다. 디자이너(또는 디자인 팀)는 인터페이스를 실현하는 방법을 지정해야 합니다. 하지만 외부 종속성에 영향을 주지 않고 내부 서브시스템 디자인을 자유롭게 변경할 수 있습니다. 거의 독립적인 팀으로
구성되는 대규모 시스템에서는, 정규 인터페이스가 제공하는 아키텍처 실행과 함께 이 분리 정도가 단순한 패키지 대신 서브시스템을 선택하는 데 매우 중요한 인수가 됩니다.
서브시스템에서 제공하는 서비스를 사용하는 경우에도, 서브시스템의 클라이언트가 서브시스템의 내부 디자인을 전혀 몰라도 되는 방식으로 이 협업을 캡슐화하는 데 디자인 서브시스템이 사용됩니다. 협업의 참여
클래스/서브시스템이 잘 정의된 결과 세트를 생성하기 위해 둘만 상호작용하는 경우 협업 및 해당 협업 디자인 요소는 서브시스템에서 캡슐화되어야 합니다.
이 규칙은 협업의 서브세트에도 적용 가능합니다. 모든 협업 또는 협업의 파트는 캡슐화 및 단순화될 수 있습니다. 그러면 디자인을 쉽게 이해할 수 있습니다.
힌트
힌트
|
세부사항
|
선택 가능성 검토
|
특정 협업(또는 하위 협업)이 선택적 동작을 표시하는 경우 서브시스템에 해당 협업을 포함하십시오. 제거하거나 업그레이드하거나 대체로 바꿀 수 있는 기능은 독립적인 항목으로 간주되어야
합니다.
|
시스템의 사용자 인터페이스 검토
|
사용자 인터페이스가 시스템의 엔티티 클래스와 독립된 경우(즉, 두 항목이 독립적으로 변경 가능함) 수평적으로 통합된 서브시스템을 작성하십시오. 한 서브시스템에 관련 사용자 인터페이스
경계 클래스를 함께 그룹화하고 다른 서브시스템에 관련 엔티티 클래스를 함께 그룹화하십시오.
|
여기서 표시되는 사용자 인터페이스 및 엔티티 클래스가 강하게 결합된 경우(즉, 하나에서 변경이 발생하면 다른 항목의 변경이 트리거됨) 수직적으로 통합된 서브시스템을 작성하십시오. 공통
서브시스템에 관련 경계 및 엔티티 클래스를 포함하십시오.
|
액터 검토
|
각 액터가 시스템에서 해당 요구사항을 독립적으로 변경할 수 있으므로 다른 두 액터에서 사용하는 기능성을 분리하십시오.
|
외부 시스템 또는 장치에 대한 액세스를 캡슐화하도록 서브시스템을 작성하십시오.
|
디자인 요소 사이에서 결합 및 응집 검토
|
강하게 결합되었거나 응집된 클래스/서브시스템은 협업하여 일부 서비스 세트를 제공합니다. 강하게 결합된 요소는 서브시스템으로 구성하고 약한 결합 라인에 따라 요소를 분리하십시오. 일부
경우 클래스를 책임의 응집력이 강한 더 작은 클래스로 분할하거나 서브시스템을 적절히 다시 파티션하여 약한 결합을 완전히 제거할 수 있습니다.
|
대체 검토
|
특정 기능(예: 높음, 중간 및 낮음 가용성)에 지정된 서비스의 레벨이 여러 개인 경우 별도의 서브시스템으로 각 서비스 레벨을 표시하십시오. 각 서브시스템은 동일한 인터페이스 세트를
실현합니다. 이 작업을 수행하면 해당 서브시스템은 서로 대체 가능합니다.
|
분배 검토
|
각각
다른 노드에서 실행하는 특정 서브시스템의 인스턴스가 여러 개일 수 있지만, 많은 아키텍처에서 컴포넌트의 단일 인스턴스는 노드 간에 분할될 수 없습니다. 서브시스템 동작을 노드 간에
분할해야 경우 서브시스템을 기능성이 더 많이 제한되는 더 작은 서브시스템(각각 단일 컴포넌트를 표시함)으로 분리하는 것이 좋습니다. 각 노드에 상주해야 하는 기능성을 판별하고 원래
서브시스템의 관련 요소 및 책임을 올바르게 분배하여 해당 기능성을 '소유'하도록 새 서브시스템을 작성하십시오. 새 서브시스템은 원래 서브시스템의 내부에 있습니다.
|
디자인을 서브시스템으로 조직한 다음 이에 따라 유스 케이스 실현을 갱신하십시오.
디자인 서브시스템은 UML 컴포넌트를 사용하여 모델링됩니다. 이 구조는 다음 모델링 기능을 제공합니다.
-
클래스를 그룹화하여 시스템의 더 세분화된 파트를 정의할 수 있습니다.
-
내부 구현에서 가시적 인터페이스를 분리할 수 있습니다.
-
런타임 시 실행될 수 있습니다.
다음은 일부 기타 고려사항입니다.
-
각 디자인 서브시스템에 이름 및 짧은 설명을 지정해야 합니다.
-
책임을 문서화하도록 서브시스템 설명을 사용하여 원래 분석 클래스의 책임을 새로 작성한 서브시스템로 이전해야 합니다.
참고: UML 2.0에서는 이름이 <<subsystem>>인 컴포넌트의 스테레오타입도 정의합니다. 이는 예를 들어 대규모 구조를 표시하는 데 사용할 수 있음을 의미합니다. RUP 디자인
서브시스템은 대규모 구조일 수도 있고, 아닐 수도 있습니다. RUP 관점에서는 둘 다 디자인 서브시스템입니다. 이는 소프트웨어 설계자가 결정할 문제입니다(예: 컴포넌트로 구성된 컴포넌트의 레이블을
<<subsystem>>으로 선택할 지 여부).
기존 제품이 인터페이스, 즉, 오퍼레이션(수신일 수
있음)을 내보내는 제품이지만 그렇지 않으면 구현의 모든 세부사항을 숨겨두는 경우 이를 논리 보기에서 서브시스템으로 모델링할 수 있습니다. 다음은 시스템에서 사용하는 제품 중 서브시스템으로 표시할 수 있는
예제입니다.
-
통신 소프트웨어(미들웨어)
-
데이터베이스 액세스 지원(RDBMS 맵핑 지원)
-
응용프로그램 특정 제품
데이터 구조 및 유형의 콜렉션(예: 스택, 목록, 대기열)과 같은 일부 기존 제품은 패키지로 더 잘 표시될 수 있습니다. 왜냐하면 동작보다 더 많이 드러나며, 중요하고 유용한 내용은 패키지의 특정 컨텐츠이지 단순히
컨테이너인 패키지 자체가 아니기 때문입니다.
공통 유틸리티(예: 수학 라이브러리)에서 단순히 인터페이스를 내보내는 경우 서브시스템으로 표시할 수 있습니다. 하지만 이렇게 해야 할 필요가 있는지 또는 합리적인지 여부는 모델링하는 항목의 특성에 대한 디자이너의
판단에 따라 다릅니다. 서브시스템은 객체 지향 구조입니다(모델링된 컴포넌트이므로). 서브시스템은 인스턴스를 포함할 수 있습니다(디자이너가 이와 같이 표시하는 경우). UML에서는 유틸리티에서 글로벌 변수 및 프로시저의 그룹을 모델링하는 다른 방법을 제공합니다. 이때 유틸리티는 클래스의 스테레오타입으로, 인스턴스를 포함하지
않습니다.
제품을 표시하도록 서브시스템을 정의하는 경우 제품 인터페이스를 표시하도록 하나 이상의 인터페이스도 정의하십시오.
디자인 서브시스템(UML 컴포넌트로 모델링됨)은 시맨틱 측면에서 패키지와는 다릅니다. 즉, 서브시스템은 서브시스템이 실현하는 하나 이상의 인터페이스를 통해 동작을 제공합니다. 반면 패키지는 동작을 제공하지
않습니다. 단순히 동작을 제공하는 항목의 컨테이너입니다.
패키지 대신 서브시스템을 사용하는 이유는 서브시스템이 해당 인터페이스를 통해서만 동작을 제공하면서 컨텐츠를 캡슐화하기 때문입니다. 이 경우 패키지와 달리, 서브시스템의 인터페이스가 일정하게 남아 있는 한,
서브시스템의 컨텐츠 및 내부 동작을 완전히 자유롭게 변경할 수 있다는 이점이 있습니다. 또한 서브시스템에서는 '바꿀 수 있는 디자인' 요소를 제공합니다. 동일한 인터페이스 또는 <<스펙>>
컴포넌트를 실현하는 두 개의 <<실현(realization)>> 컴포넌트는 서로 교환 가능합니다.
모델에서 서브시스템이 바꿀 수 있는 요소가 되려면 약간의 규칙을 적용해야 합니다.
-
서브시스템에서 컨텐츠의 노출을 최소화해야 합니다. 이상적으로 서브시스템에 포함된 요소는 'public' 가시성이 아니어야 합니다. 즉, 서브시스템 외부의 모든 요소가 서브시스템 내부의 특정 요소의 존재
여부에 종속되지 않아야 합니다. 다음은 몇 가지 예외입니다.
-
일부 기술의 경우 서브시스템의 외부를 UML 인터페이스로 모델링할 수 없습니다. 예를 들어 Java 인터페이스는 스테레오타입화된 클래스로 모델링됩니다.
-
서브시스템 디자인에서 UML 인터페이스가 아닌 클래스를 노출시켜야 합니다. 예를 들어 "위임" 또는 "액세스" 클래스를 사용하여 다른 클래스의 복잡한 협업을 숨길 수 있어야 합니다. 일반
패키지를 대신 사용할 수도 있지만, 동작을 캡슐화하고 내부 세부사항을 숨기려는 의도를 강조하기 위해 서브시스템을 사용할 수 있습니다.
-
서브시스템의 외부가 UML 인터페이스가 아닌 경우 서브시스템의 가시적 요소를 표시하는 다이어그램(예: 이름이 "외부 보기"임)이 있으면 종종 도움이 됩니다.
-
서브시스템은 서브시스템 인터페이스 및 위에서 설명한 예외의 경우인 서브시스템의 요소(public 가시성)에 대해 해당 종속성을 정의해야 합니다. 또한 여러 서브시스템에서 공통적으로 인터페이스 또는 클래스
정의 세트를 공유할 수 있습니다. 이 경우 해당 서브시스템은 공통 요소를 포함하는 패키지의 컨텐츠를 '가져옵니다.' 서브시스템 사이에서 전달해야 하는 클래스의 공통 정의가 일관되게 정의되도록 하려면 패키지는
아키텍처의 하위 계층에 있는 것이 보다 일반적입니다.
다음은 서브시스템 및 패키지 종속성에 대한 예제입니다.
디자인 모델의 서브시스템 및 패키지 종속성
다음은 UML([UML04])의 내용입니다.
컴포넌트에 적용하는 UML 표준 스테레오타입이 많이 있습니다. 예를 들어 <<specification>> 및 <<realization>>은 별개의 스펙 및 실현
정의를 포함하는 컴포넌트를 모델링하는 경우 사용합니다. 여기서 하나의 스펙에 여러 실현이 포함될 수 있습니다.
<<specification>>으로 스테레오타입화된 컴포넌트는 오브젝트의 실제 구현을 정의하지 않고 해당 오브젝트의 도메인을 지정합니다. 이 컴포넌트에는 제공 및 필수 인터페이스만
있습니다. 해당 정의의 파트로 실현 클래스 및 하위 컴포넌트를 가지려고 하지 않습니다.
<<realization>>으로 스테레오타입화된 컴포넌트는 오브젝트의 도메인을 지정하고 해당 오브젝트의 실제 구현도 정의합니다. 예를 들어
<<realization>>으로 스테레오타입화된 컴포넌트는 별도의 <<스펙>> 컴포넌트로 지정된 동작을 구현하는 실현 클래스 및 하위 컴포넌트만 가집니다.
스펙 및 실현의 분리를 통해 서브시스템에 대한 별도의 설명 두 가지를 얻을 수 있습니다. 스펙은 클라이언트가 서브시스템을 사용할 때 알아야 하는 내용을 정의하는 계약 역할을 합니다. 실현은 구현자를 안내하도록
고안된 자세한 내부 디자인입니다. 다중 실현을 지원하려면 별도의 "실현" 서브시스템을 작성하고 각 실현 서브시스템에서 스펙 서브시스템으로 실현을 가져오십시오.
서브시스템의 내부 상태 및 동작이 비교적 단순한 경우 노출된 인터페이스, 동작을 설명하는 상태 다이어그램 및 설명 텍스트로도 충분히 서브시스템을 지정할 수 있습니다.
내부 상태 및 동작이 더 복잡한 경우 분석 클래스를 사용하여 상위 레벨의 추상으로 서브시스템을 지정할 수 있습니다. 대규모 복합 시스템인 경우 서브시스템의 스펙이 유스 케이스를 포함할 수도 있습니다. Rational Unified Process를 사용하여 대규모 시스템 개발을 참조하십시오.
다음 상황에서는 실현과는 별도로 자세한 스펙을 제공하는 것이 가장 유용합니다.
-
서브시스템 실현의 내부 상태 또는 동작이 복잡하고 클라이언트에서 효과적으로 사용하기 위해 스펙을 가능한 단순하게 표현해야 하는 경우.
-
서브시스템이 여러 시스템으로 어셈블리하기 위해 고안된 재사용가능한 "어셈블리 컴포넌트"인 경우(개념: 컴포넌트 참조).
-
별도의 조직에서 서브시스템의 내부를 개발하는 상황이 예상되는 경우.
-
서브시스템의 다중 구현을 작성해야 하는 경우,
-
외부적으로 가시적인 동작을 변경하지 않고 중요한 내부 변경사항을 포함하는 다른 버전으로 서브시스템을 바꾸는 상황이 예상되는 경우.
별도의 스펙을 유지보수하려면 노력이 필요합니다. 서브시스템의 실현이 스펙을 준수하는지 확인해야 하기 때문입니다. 별도의 스펙 및 실현 클래스를 작성하는 시기 및 작성 여부에 대한 기준은 중간 산출물: 프로젝트 가이드라인에 정의되어 있습니다.
스펙은 해당 종속성을 정의해야 합니다. 다른 서브시스템 및 패키지에는 스펙을 준수하는 서브시스템의 모든 실현에서 사용 가능해야 하는 가시적 요소 및 인터페이스가 있습니다.
실현은 디자이너 또는 구현자가 도입한 추가 종속성을 포함할 수 있습니다. 예를 들어 구현을 단순화하도록 유틸리티 컴포넌트를 사용하는 기회가 있을 수 있습니다. 그러나 이 유틸리티 컴포넌트의 사용은 클라이언트에
노출해서는 안 되는 세부사항입니다. 이 추가 종속성은 실현 파트로 별도의 다이어그램에서 캡처되어야 합니다.
전체 세부 스펙에서 클라이언트가 서브시스템을 사용하는 데 필요한 모든 사항을 정의합니다. 즉, 코드에서 일 대 일로 대응하도록 모든 공용 가시적 요소 및 노출된 요소를 정제함을 의미합니다. 서브시스템 동작을
지정하기 위해 도입된 분석 클래스는 서브시스템 실현과 독립적이어야 하므로 상위 레벨의 추상으로 남아 있어야 합니다.
서브시스템의 실현 요소는 코드에 가깝게 맞춰야 합니다.
이 주제에 대한 몇 가지 추가 논의를 보려면 기법:
디자인에서 코드로 맵핑을 참조하십시오.
모델링
디자인 서브시스템은 UML 2.0 컴포넌트 또는 UML 1.5 서브시스템으로 모델링할 수 있습니다. 이들 구조는 모듈화, 캡슐화 및 런타임에 실행 가능한 인스턴스와 같이 거의 동등한 모델링 기능을 제공합니다.
다음은 이들 모델링 옵션에 대한 일부 추가 고려사항입니다.
-
UML 1.5 서브시스템은 명시적으로 "스펙" 및 "실현"의 개념을 포함합니다(위에서 제목이 서브시스템
스펙 및 실현인 섹션에서 정의함). UML 2.0 컴포넌트는 스펙(하나 이상의 제공 및 필수 인터페이스 양식) 및 실현(동작을 실현하는 하나 이상의 클래스 및 하위 컴포넌트로 구성된 내부 구현)의
개념을 지원합니다.
-
UML 1.5 서브시스템은 패키지이기도 합니다. UML 2.0 컴포넌트에는 패키지 기능이 있습니다. 즉, 잠재적으로 큰 모델 세트 요소를 소유하고 가져올 수 있음을 의미합니다.
그러나 전반적으로 이 개념은 교환 가능한 방식으로 사용할 수 있습니다. 디자인 서브시스템을 UML 1.5 서브시스템으로 표시할 지 또는 UML 2.0 컴포넌트로 표시할 지에 대한 결정은 프로젝트에 대해 사용자
조정된 프로젝트 가이드라인에 문서화되어 있습니다.
비주얼 모델링 도구에서 UML 1.5 패키지는 지원하지만 UML 1.5 서브시스템은 지원하지 않는 경우 <<subsystem>>으로 스테레오타입화된 패키지를 사용하여 서브시스템을 표시할 수
있습니다.
서브시스템 종속성 제한사항
제목이 서브시스템 종속성 제한사항인 섹션에서 언급한 동일한 종속성 제한사항 및 논의가 UML 1.5 서브시스템으로
모델링한 디자인 서브시스템에도 적용됩니다.
다음은 UML 1.5의 서브시스템 및 패키지 종속성에 대한 예제입니다.
디자인 모델의 서브시스템 및 패키지 종속성
서브시스템 스펙 및 실현(realization)
UML 1.5에서는 다음과 같습니다.
서브시스템의 컨텐츠는 두 개의 서브세트, 1) 스펙 요소 및 2) 실현 요소로 나뉩니다. 스펙 요소는 서브시스템의 오퍼레이션 및 수령과 함께 실현 요소에서 제공하는 동작의 추상 스펙을 제공하기 위해
사용됩니다. 실현 요소의 콜렉션은 실제 시스템에서 동작 단위의 내부를 모델링합니다.
스펙 및 실현의 분리를 통해 서브시스템에 대한 별도의 설명 두 가지를 얻을 수 있습니다. 스펙은 클라이언트가 서브시스템을 사용할 때 알아야 하는 내용을 정의하는 계약 역할을 합니다. 실현은 구현자를 안내하도록
고안된 자세한 내부 디자인입니다.
모델링 환경에서 직접 지원되지 않는 경우 스펙 및 실현을 모델링할 때 사용하는 한 가지 옵션은 각 서브시스템 내부에 두 개의 패키지, 스펙 및 실현을 두는 것입니다.
스펙에 대한 한 가지 동기는 다중 실현을 지원하는 것입니다. UML 1.x에서는 직접 지원되지 않습니다. UML 1.5 서브시스템을 사용하여 다중 실현을 지원하려면 별도의 "실현" 서브시스템을 작성하고 각 실현
서브시스템에서 스펙 서브시스템으로 실현을 가져오십시오.
기본적으로 UML 2.0에 적용되는 스펙 및 실현에 대한 동일한 고려사항이 여기에도 적용됩니다(설명은 사용 시기 및 방법, 종속성 및 구현에 대한 관계 참조).
추가 정보
자세한 정보는 UML 1.x 및 UML 2.0의 차이점을 참조하십시오.
|