Artifact: Design Subsystem
| A part of a system that encapsulates behavior, exposes a set of interfaces, and packages other model elements. From the outside, a subsystem is a single design model element that collaborates with other model elements to fulfill its responsibilities. The externally visible interfaces and their behavior is referred to as the subsystem specification. On the inside, a subsystem is a collection of model elements (design classes and other subsystems) that realize the interfaces and behavior of the subsystem specification. This is referred to as the subsystem realization. | |
| Other Relationships: | Part Of Design Model |
| Role: | Designer |
| Optionality/Occurrence: | Optional for simple systems composed only of classes and packages. |
| Templates and Reports: | - Report: Design Package/Subsystem |
| Examples: | |
| UML Representation: | Design Subsystems are modeled as UML 2.0 components. UML also defines a stereotype for component named <<subsystem>>, indicating that this may be used, for example, to represent large scale structures. See Guidelines: Design Subsystem for representation. |
| More Information: | - Report: Design Package/Subsystem - Checklist: Design Subsystem - Guideline: Design Subsystem |
| Input to Activities: - Subsystem Design - Use-Case Design | Output from Activities: - Identify Design Elements - Identify Design Mechanisms - Incorporate Existing Design Elements - Subsystem Design |
Purpose
A Design Subsystem encapsulates behavior, providing explicit and formal interfaces, and does not (by convention) expose its internal contents. This provides the ability to completely encapsulate the interactions of a number of classes and/or subsystems. The ‘encapsulation’ ability of design subsystems is contrasted by that of the Artifact: Design Package, which does not realize interfaces. Packages are used primarily for configuration management and model organization, where subsystems provide additional behavioral semantics.
Timing
The Design Subsystem is created during Elaboration Phase, as major functionality is partitioned into ‘chunks’ which can be developed.
Responsibility
A Designer is responsible for the integrity of the design subsystem, ensuring that:
- The subsystem encapsulates its contents, only exposing contained behavior through interfaces it realizes.
- The operations of the interfaces the Subsystem realizes are distributed to contained classes or subsystems.
- The subsystem properly implements its interfaces.
Tailoring
Design Subsystems are an important means of decomposing large systems into understandable parts. They are particularly useful in component-based development to specify components (see Concepts: Component) expected to be independently developed, re-used, or replaced.
Important tailoring decisions related to Design Subsystems are:
- whether and when to separate specification from realization (see Guidelines: Design Subsystem)
- whether or not to model subsystem interfaces localized into ports (see [Activity: Subsystem Design](../activities/ac_subds.md#Document Subsystem Elements))
This tailoring decision should be captured in Artifact: Project Specific Guidelines.
UML 1.x Representation
An important tailoring decision is whether to model design subsystems as UML 2.0 components or UML 1.5 subsystems (see Guidelines: Design Subsystem).
Refer to Differences Between UML 1.x and UML 2.0for more information.