Artifact: Design Subsystem

Artifacts > Analysis & Design Artifact Set > Design Model... > Design Subsystem

Design Subsystem	A model element which has the semantics of a package (it can contain other model elements) and a class (it has behavior). The behavior of the subsystem is provided by classes or other subsystems it contains. A subsystem realizes one or more interfaces, which define the behavior it can perform.
UML representation:	Subsystem
Role:	Designer
Optionality:	Optional for simple systems composed only of classes and packages.
Reports:	Design-Model Survey Design Package/Subsystem
More information:	Guidelines:Design Subsystem Checkpoints:Design Subsystem
Purpose Properties Timing Responsibility Tailoring

Input to Activities:

Implement Test Components and Subsystems

Use-Case Design

Subsystem Design

Output from Activities:

Identify Design Elements

Identify Design Mechanisms

Incorporate Existing Design Elements

Subsystem Design

Purpose

Design Subsystems are used to encapsulate behavior inside a "package" which is provides explicit and formal interfaces, and which (by convention) does not expose any of its internal contents. It is used as a unit of behavior in the system, which provides the ability to completely encapsulate the interactions of a number of class and/or subsystems. The 'encapsulation' ability of design subsystems is contrasted by that of the Artifact: Design Package, which does not realize interfaces, and may expose contents which are marked 'public'. Packages are used primarily for configuration management and model organization, where subsystems provide additional behavioral semantics.

Properties

Property Name	Brief Description	UML Representation
Name	The name of the subsystem	attribute
Brief Description	The short description of the role and purpose, or the "theme" of the subsystem.	attribute
Interfaces	associations to realized interfaces	realization association
Contents	aggregation associations to contained model elements	aggregation association
Dependencies	dependency associations to interfaces or packages on which the subsystem depends	dependency
Diagrams	Any diagrams local to the subsystem, such as class diagrams or statechart diagrams.	Owned by an enclosing package, via the aggregation "owns".

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 useful in several contexts:

To model large-grained structures in the design model. These subsystems will typically be decomposed into other subsystems, and eventually classes, and represent large subsystems or systems which are used to compose the system. A small system will not tend to use subsystems in this way.
To model components in the design model. These subsystems generally have a 1:1 mapping to an executable component in the Implementation Model. Here you are modeling something at design time which you intend to be a separately constructed thing—a component—at implementation time. This separately constructed thing will itself be built from several classes (or subsystems). Contrast this with the first case, where, in the implementation model, the design subsystem may become simply a notional boundary around a collection of classes (which become components in the implementation model).

Rational Unified Process