결과물:
|
![]() |
작동을 캡슐화하고 인터페이스 세트를 노출하며 기타 모델 요소를 패키지하는 시스템 파트. 외부에서 서브시스템은 기타 모델 요소와 공동 작업으로 해당 책임을 수행하는 단일 설계 모델입니다. 외부적으로 가시적인 인터페이스 및 해당 작동은 서브시스템 스펙이라고 합니다. 내부에서 서브시스템은 서브시스템 스펙의 작동 및 인터페이스를 구현하는 모델 요소의 콜렉션(설계 클래스 및 기타 서브시스템)입니다. 이는 서브시스템 구현이라고 합니다. |
---|---|
기타 관계: |
다음 파트 설계 모델
|
역할: | 설계자 |
선택 가능성/발생 시기: | 클래스 및 패키지로만 구성된 단일 시스템의 선택사항. |
템플리트 및 보고서: |
|
예: | |
UML 표시: | 설계 서브시스템은 UML 2.0 컴포넌트로서 모델화됩니다. UML은 또한 <<subsystem>>이라는 컴포넌트의 전형을 정의하여 예를 들어 대규모 구조를 표시하는 데 사용할 수도 있음을 표시합니다. 표현은 가이드라인: 설계 서브시스템을 참조하십시오. |
자세한 정보: |
활동 정보: | 활동 결과: |
설계 서브시스템이 작동을 캡슐화하여 명시적이고 공적 인터페이스를 제공하며 내부 컨텐츠를 노출하지 않습니다(규정상). 이로써 여러 클래스 및/또는 서브시스템의 상호 작용을 완전히 캡슐화할 수 있는 기능을 제공합니다. 설계 서브시스템의 '캡슐화' 기능은 인터페이스를 구현하지 않는 결과물: 설계 패키지의 해당 기능과 대조됩니다. 패키지는 주로 형상 관리와 모델 조직에 사용됩니다. 여기서 서브시스템이 추가 작동 의미론을 제공합니다.
주된 기능이 개발될 수 있는 '덩어리'로 파티션됨에 따라 설계 서브시스템이 구현 단계 중에 작성됩니다.
설계자는 설계 서브시스템의 무결성에 책임이 있으며 다음을 확인해야 합니다.
설계 서브시스템은 대형 시스템을 이해 가능한 파트로 분해하는 중요한 수단입니다. 컴포넌트 기반 개발시, 독립적으로 개발되어 재사용되고 바꾸기되도록 예상되는 컴포넌트(개념: 컴포넌트 참조)를 지정하는 데 특히 유용합니다.
설계 서브시스템 관련 중요한 조정 결정은 다음과 같습니다.
이 조정 결정은 결과물: 프로젝트 특정
가이드라인에서 캡처되어야 합니다.
중요한 조정 결정은 설계 서브시스템을 UML 2.0 컴포넌트 또는 UML 1.5 서브시스템으로 모델화할지의 여부입니다(가이드라인: 설계 서브시스템 참조).
자세한 정보는 UML 1.x와 UML 2.0의 차이점 을 참조하십시오.
Rational Unified Process
|