주제

서브시스템 사용법 페이지 맨 위

서브시스템은 시스템을 다음과 같은 서브시스템으로 파티션하기 위한 여러 가지 보충 방법으로 사용될 수 있습니다.

  • 독립적으로 주문, 구성 또는 전달할 수 있는 서브시스템
  • 인터페이스가 변경되지 않고 남아 있는 한 독립적으로 개발할 수 있는 서브시스템
  • 분산된 계산 가능 노드 세트에서 독립적으로 전개할 수 있는 서브시스템
  • 시스템의 다른 부분을 중단하지 않고 독립적으로 변경할 수 있는 서브시스템

따라서 서브시스템은 단일 설계 클래스보다 큰 컴포넌트(컴포넌트 기본 개발에서 교체 가능한 어셈블리 단위) 모델링에 이상적입니다.

게다가 서브시스템은 다음을 수행할 수 있습니다.

  • 시스템을 핵심 자원을 통해 제한된 보안을 제공할 수 있는 단위로 파티션합니다.
  • 설계에 기존의 제품 또는 외부 시스템을 표현합니다.

서브시스템 식별 페이지 맨 위

단독으로 작동하는 단일 설계 클래스의 책임이 아닌 작동을 구체화할 경우 복잡한 분석 클래스는 설계 서브시스템으로 맵핑됩니다. 협력 클래스 세트로 구현될 경우에도 복잡한 설계 클래스가 서브시스템이 될 수 있습니다.

서브시스템은 각각의 팀에 의해 독립적으로 개발될 시스템의 일부를 식별하는 좋은 수단도 됩니다. 협력 설계 요소가 협력하여 패키지 내에 완전히 포함될 경우, 서브시스템은 단순한 패키지가 제공하는 것보다 우수한 캡슐화 형식을 제공할 수 있습니다. 서브시스템 내의 컨텐츠 및 협력은 하나 이상의 인터페이스 뒤에 완전히 분리되므로 서브시스템의 클라이언트는 인터페이스에만 종속됩니다. 서브시스템의 설계자는 외부 종속성과 완전히 분리됩니다. 설계자(또는 설계 팀)는 인스턴스를 구현하는 방법을 지정해야 하나 외부 종속성에 영향을 미치지 않고 자유롭게 내부 서브시스템을 변경할 수 있습니다. 대규모의 독립 팀을 가진 대형 시스템에서 공식 인터페이스에서 제공하는 구조적 시행과 결합하여 이 정도 분리가 된다는 것은 단순한 패키지를 능가하는 서브시스템을 선택하는 강력한 이유가 됩니다.

설계 시스템은 서브시스템이 제공하는 서비스를 사용할 때 서브시스템 클라이언트가 서브시스템의 내부 설계를 전혀 인식하지 않는 방법으로 이러한 협력을 캡슐화하는 데 사용됩니다. 협력에 관련된 클래스/서브시스템은 자기들 끼리만 상호 작용하여 잘 정의된 결과 세트를 생성하며, 협력 및 해당 협력 설계 요소는 서브시스템 내에 캡슐화되어야 합니다.

이 규칙은 협력 서브세트에도 적용될 수 있습니다. 협력의 어떤 부분 또는 전체를 캡슐화하여 단순화할 수 있으며 이렇게 하면 설계를 이해해기가 훨씬 쉬워집니다.

힌트

힌트

자세히

선택사항 찾기 특정 협력(또는 서브협업)이 선택사항 작동이면 이를 서브시스템 내에 포함시키십시오. 제거, 갱신 또는 대안으로 바꿀 수 있는 기능은 독립적 기능으로 간주합니다.
시스템의 사용자 인터페이스 찾기 사용자 인터페이스가 시스템 내의 엔티티 클래스와 비교적 독립적인 경우(두 개를 독립적으로 변경할 수 있으므로 독립적으로 변경할 경우) 수평적으로 통합되는 서브시스템을 작성하십시오. 관련된 사용자 인터페이스 경계 클래스를 함께 서브시스템으로 그룹화하고 관련 엔티티 클래스를 다른 서브시스템으로 그룹화하십시오.
표시되는 사용자 인터페이스 및 엔티티 클래스가 긴밀하게 결합되어 있으면(한 트리거를 변경하면 다른 트리거도 변경해야 함) 수직적으로 통합되는 서브시스템을 작성하십시오. 관련된 경계 및 엔티티 클래스를 공통 서브시스템에 포함시키십시오.
액터 찾기 각 액터는 독립적으로 시스템에 대한 요구사항을 변경시키므로 두 액터가 사용하는 기능을 별도로 분리하십시오.
외부 시스템 또는 장치에 대한 액세스를 캡슐화하는 서브시스템 작성
설계 요소 간의 결합 또는 응집력 찾기 결합 또는 응집력이 높은 클래스/서브시스템은 협력하여 서비스 세트를 제공합니다. 결합도가 높은 요소를 서브시스템으로 구성하고 결합도가 낮은 요소별로 분리하십시오. 어떤 경우에는 응집력이 높은 책임을 가진 더 작은 클래스로 클래스를 분할하거나 서브시스템을 적절히 재파티션하여 결합력이 낮은 요소를 완전히 제거할 수도 있습니다.
대체 찾기 특정 기능에 대해 여러 레벨의 서비스가 지정되어 있으면 (예: 고, 중 및 저 사용 가능성) 각 서비스 레벨을 각각 동일한 인터페이스 세트를 구현하는 별도의 서브시스템으로 나타내십시오. 이를 수행하여 서브시스템을 다른 서브시스템으로 대체할 수 있습니다.
분배 관찰 특정 시스템에 대해 각각 다른 노드에서 실행되는 복수의 인스턴스가 있다 해도 많은 구조에서 노드에 걸쳐 컴포넌트의 단일 인스턴스를 분할하는 것은 불가능합니다. 노드에 걸쳐 서브시스템 작동을 분할해야 하는 경우, 서브시스템을 좀더 제약이 많은 더 작은 서브시스템(각각 단일 컴포넌트를 나타냄)으로 분해하는 것이 좋습니다.   각 노드에 있어야 하는 노드를 결정한 후, 원래 서브시스템의 책임 및 관련 요소를 적절히 분배하여 해당 기능을 '소유'할 새 서브시스템을 작성하십시오.   새 서브시스템은 원래 서브시스템에 대해 내부적입니다.

설계를 서브시스템으로 조직했으면 유스 케이스 구현을 알맞게 갱신하십시오.

서브시스템 모델링 페이지 맨 위

설계 서브시스템은 UML 컴포넌트를 사용하여 모델화됩니다. 이 구성은 다음과 같은 모델링 기능을 제공합니다.

  • 보다 큰 단위의 시스템 파티를 정의하기 위해 클래스를 그룹화할 수 있습니다.
  • 내부 구현으로부터 가시적인 인터페이스를 분리할 수 있습니다.
  • 런타임시 실행되는 인스턴스를 가질 수 있습니다.

다른 고려사항은 다음과 같습니다.

  • 각 설계 서브시스템에는 이름 및 간략한 설명을 제공해야 합니다.
  • 원래 분석 클래스의 책임을 새로 작성한 클래스로 이관하고 서브시스템의 설명을 사용하여 책임을 문서화해야 합니다.

참고: UML 2.0은 <<서브시스템>>이라는 컴포넌트의 스테레오타입도 정의하여 서브시스템이 사용될 수 있음을 나타냅니다(예: 대규모 구조를 표현할 경우에). RUP 설계 서브시스템은 대형 구조일 수도 있고 소형 구조일 수도 있습니다. 둘 다 RUP Perspective에서 보면 설계 서브시스템입니다. 이는 소프트웨어 아키텍트가 결정해야 할 문제입니다(예: 컴포넌트로 합성된 컴포넌트를 <<서브시스템>>이라고 할지 여부).

기존의 제품을 표현하는 서브시스템 페이지 맨 위

기존의 제품이 인터페이스를 내보내는 제품(예: 조작 또는 영수증일 수도 있음)이지만 숨겨진 구현을 상세히 보존할 경우, 논리 보기에 서브시스템으로 모델화할 수 있습니다.   서브시스템으로 표현할 수 있는, 시스템이 사용하는 제품의 예에는 다음이 포함됩니다.

  • 통신 소프트웨어(미들웨어).
  • 데이터베이스 액세스 지원(RDBMS 맵핑 지원).
  • 어플리케이션 특정 제품.

유형 콜렉션 및 데이터 구조와 같은 기존의 일부 제품(예: 스택, 목록, 큐)은 더 많은 작동을 표시하기 때문에 패키지라고 표현하는 것이 더 낫습니다. 이들은 중요하고 유용한 패키지의 특정 내용으로서, 패키지가 아닌 단지 컨테이너입니다.  

필요에 의해서든 아니면 모델화된 작동의 본질에 대한 설계자의 판단에 따라서든 단순히 인터페이스를 내보낼 경우, math 라이브러리와 같은 공통 유틸리티는 서브시스템으로 표현될수 있습니다.   서브시스템은 객체 지향 구조입니다(모델화된 컴포넌트이기 때문에). 서브시스템은 인스턴스를 가질 수 있습니다(설계자가 그렇게 지정한 경우). UML은 스테레오타입이 클래스인 유틸리티 (유틸리티는 인스턴스가 없음) 내의 글로벌 변수 및 프로시저 그룹을 모델화하는 다른 방법을 제공합니다.  

제품을 표시할 서브시스템을 정의할 때 제품 인터페이스를 표현할 하나 이상의 인터페이스도 정의하십시오.

서브시스템 종속성 제한사항 페이지 맨 위

설계 서브시스템(UML 구성요소로 모델화됨)은 의미론적인 면에서 다릅니다. 서브시스템은 이를 구현하는 하나 이상의 인터페이스를 통해 작동을 제공합니다. 패키지는 작동을 제공하지 않습니다. 패키지는 단지 작동을 제공하는 것들의 컨테이너입니다.

패키지가 아닌 서브시스템을 사용하는 이유는 서브시스템은 컨텐츠를 캡슐화하여 인터페이스를 통해서만 작동을 제공하기 때문입니다. 서브시스템을 사용하면, 패키지와는 달리 서브시스템의 인터페이스가 변경되지 않은 한 시스템의 컨텐츠 및 내부 작동을 자유롭게 변경할 수 있습니다. 서브시스템은 '대체 가능한 설계' 요소도 제공합니다. 동일한 인터페이스(또는 <<스펙>> 구성요소)를 구현하는 임의의 두 <<구현화>> 컴포넌트는 상호 변경가능합니다.

모델에서 서브시스템을 대체할 수 있으려면 몇 가지 규칙을 지켜야 합니다.

  • 서브시스템은 컨텐츠의 노출을 최소화해야 합니다. 서브시스템에 포함된 요소에 'public' 가시성이 없어 서브시스템 외부의 요소가 서브시스템 내부의 특정 요소의 존재 여부에 의존하지 않는 것이 가장 이상적입니다. 몇 가지 예외는 다음과 같습니다.
    • 일부 기술에서 서브시스템의 외부는 UML 인터페이스로 모델화할 수 없습니다. 예를 들어, Java 인터페이스는 클래스 스테레오타입으로 모델화됩니다.
    • 서브시스템 설계는 UML 인터페이스보다는 클래스를 많이 노출해야 합니다. 예를 들어, "위임" 또는 "액세스" 클래스를 사용하여 다른 클래스의 복잡한 협력을 숨길 수 있습니다. 대신 일반 패키지를 사용할 수 있으나, 캡슐화 작동에 대한 의도를 강조하고 내부 세부사항을 숨기기 위해 서브시스템을 사용할 수 있습니다.

  • 서브시스템의 외부가 UML 인터페이스가 아닌 경우, 서브시스템의 시각적 요소를 표시하는 다이어그램("외부 보기"라고 하는 다이어그램을 예로 들 수 있음)을 갖는 데 도움이 됩니다.
  • 서브시스템은 서브시스템 인터페이스(및 위에 설명된 예외 케이스에서 공용으로 볼 수 있는 서브시스템 요소)에 대한 종속성을 정의해야 합니다. 추가로 여러 서브시스템이 인터페이스 세트 또는 클래스 정의를 공동으로 공유할 수 있습니다. 이 경우 이러한 서브시스템은 공통 요소를 포함하는 패키지의 컨텐츠를 '가져옵니다'. 이는 구조의 낮은 계층에 있는 패키지에 더 공통적이므로 서브시스템 간에 전달해야 하는 클래스의 공통 정의를 일관성있게 정의할 수 있게 합니다.

서브시스템 및 패키지 종속성 예제가 다음에 나와 있습니다.

첨부 텍스트에 설명된 다이어그램

설계 모델의 서브시스템 및 패키지 종속성

서브시스템 스펙 및 구현 페이지 맨 위

정의페이지 맨 위

UML([UML04])은 다음에 대해 기술합니다.

컴포넌트(예: 별개의 스펙과 구현 정의를 가진 컴포넌트를 모델화하기 위한 <<스펙>> 및 <<구현>>(하나의 스펙이 여러 구현을 가질 수 있음))에 적용되는 여러 개의 UML 표준 스테레오타입이 존재합니다.

<<스펙>> 스테레오타입을 가진 구성요소는 이러한 객체의 실제 구현을 정의하지 않고 객체 도메인을 지정합니다. 이 구성요소는 제공된 필수 인터페이스만 가지며 정의의 일부로 구현 클래스 및 서브구성요소를 갖도록 되어 있지는 않습니다.

<<구현>> 스테레오타입을 가진 컴포넌트는 객체 도메인을 지정하며 이러한 객체의 실제 구현을 정의합니다. 예를 들어, <<구현>> 스테레오타입을 가진 컴포넌트는 별도의 <<스펙>> 컴포넌트에 지정된 작동을 구현하는 구현 클래스 및 서브 컴포넌트만을 갖습니다.

스펙 및 구현을 본질적으로 분리하면 서브시스템에 대한 두 개의 다른 설명이 있을 수 있습니다. 스펙은 클라이언트가 서브시스템을 사용하기 위해 알아야 하는 모든 것을 정의하는 계약입니다. 구현은 구현자를 안내하도록 만들어진 상세한 내부 설계입니다. 복수의 구현을 지원하려면, 별도의 "구현" 서브시스템을 작성하고 각 구현 서브시스템에서 스펙 서브시스템으로의 구현을 작성하십시오.

사용 시기 및 방법페이지 맨 위

서브시스템의 내부 상태 및 작동이 비교적 간단하면 표시된 인터페이스, 작동을 설명하는 상태 다이어그램 및 설명 텍스트만으로도 충분히 서브시스템을 지정할 수 있습니다.

보다 복잡한 내부 상태 및 작동의 경우, 분석 클래스를 사용하여 높은 추상 레벨로 서브시스템을 지정할 수 있습니다. 대형 시스템의 경우, 서브시스템 스펙은 유스 케이스도 포함할 수 있습니다. Rational Unified Process를 사용하여 대형 시스템 개발을 참조하십시오.

다음과 같은 경우에는 구현과 별도로 상세한 스펙을 제공하는 것이 가장 중요합니다.

  • 서브시스템 구현의 내부 상태 또는 작동이 복잡하고 클라이언트가 효율적으로 사용할 수 있도록 가능하면 간단히 스펙 요구사항을 표현해야 합니다.
  • 서브시스템이 여러 시스템에 대한 어셈블리로 사용되는 재사용 가능 "어셈블리 컴포넌트"입니다 (개념: 컴포넌트 참조).
  • 서브시스템의 내부는 별도의 구조에 의해 개발될 것으로 예상됩니다.
  • 서브시스템에 대해 복수의 구현을 작성해야 합니다.
  • 외부에서 볼 수 있는 작동은 변경하지 않고 중요한 내부 변경사항을 갖고 있는 다른 버전으로 바꿀 것으로 예상합니다.

누군가가 서브시스템의 구현이 스펙과 호환되는지 확인해야 하기 때문에 별도의 스펙을 유지보수하는 데 노력이 필요합니다. 별도의 스펙, 구현 클래스 및 협력을 작성해야 하는지와 작성 시기에 대한 기준은 ../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website결과물: 프로젝트 특정 가이드라인에 설명되어 있습니다.

종속성페이지 맨 위

스펙은 해당 종속성을 정의해야 합니다. 종속성은 인터페이스 및 다른 서브시스템에 있는 인터페이스 및 가시적인 요소이며 서브시스템의 모든 호환 가능한 구현에서 사용 가능해야 하는 패키지입니다.

구현은 추가 종속성을 갖고 있으며 구현자 또는 설계자가 도입합니다. 예를 들어, 구현을 단순화하기 위해 유틸리티 컴포넌트를 사용할 기회가 있을 수 있습니다. 그러나 이 유틸리티 컴포넌트를 사용하면 세부사항을 클라이언트에게 표시할 필요가 없습니다. 이 추가 종속성은 별도의 다이어그램에서 구현의 일부로 캡처되어야 합니다.

구현 관계페이지 맨 위

아주 자세한 스펙은 클라이언트가 서브시스템을 사용하는 데 필요한 모든 것을 정의합니다. 이는 코드와 일 대 일로 대응하도록 표시된 인터페이스와 모든 가시적인 공용 요소를 정제함을 의미합니다. 서브시스템의 작동을 지정하기 위해 도입된 분석 클래스는 모든 서브시스템 구현과 독립적이기 때문에 상위 레벨의 추상으로 유지됩니다.

서브시스템의 구현 요소는 코드와 근접해져야 합니다.

이 주제에 대한 자세한 토론 내용은 개념: 설계에서 코드로 맵핑을 참조하십시오.

UML 1.x 표현페이지 맨 위

모델링

설계 서브시스템은 UML 2.0 컴포넌트 또는 UML 1.5 서브시스템으로 모델화될 수 있습니다. 이러한 구성은 모듈 방식, 캡슐화 및 런타임시 실행할 수 있는 인스턴스와 같이 거의 동등한 모델링 기능을 제공합니다.

이 모델링 선택사항에 대한 일부 추가 고려사항은 다음과 같습니다.

  • UML 1.5 서브시스템에는 명시적으로 "스펙" 및 "구현"(위의 서브시스템 스펙 및 구현에 정의되어 있음) 개념이 포함되어 있었습니다. UML 2.0 컴포넌트는 스펙(하나 이상의 제공된 필수 인터페이스 양식) 및 구현(해당 작동을 구현하는 하나 이상의 클래스 및 서브 컴포넌트로 구성되는 내부 구현) 개념을 지원합니다.
  • UML 1.5 서브시스템도 패키지입니다. UML 2.0 컴포넌트는 패키징 기능을 갖고 있으며 이는 대단히 큰 모델 요소 세트를 소유하고 가져올 수 있음을 의미합니다.

그러나 전반적으로 이 표기법은 상호 교환적으로 사용될 수 있습니다. 설계 서브시스템을 UML 1.5 서브시스템으로 표시할지 또는 UML 2.0 컴포넌트로 표시할지를 결정하는 것은 해당 프로세스/프로젝트에 맞게 조정된 ../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website 프로젝트 특정 가이드라인에 문서화되어 있습니다.

비주얼 모델링 툴이 UML 1.5 패키지는 지원하나 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   2003.06.15