Artifact: Implementation Subsystem

Artifacts > Implementation Artifact Set > Implementation Model... > Implementation Subsystem

Implementation Subsystem	An implementation subsystem is a collection of components and other implementation subsystems, and is used to structure the implementation model by dividing it into smaller parts.
UML representation:	Package in the implementation model, either its top-level package, or stereotyped as «implementation subsystem».
Role:	Implementer
More information:	Guidelines:Implementation Subsystem
Purpose Properties Timing Responsibility Tailoring

Input to Activities:

Execute Test Suite

Perform Unit Tests

Integrate Components to the System

Output from Activities:

Structure the Implementation Model

Implement Test Components and Subsystems

Purpose

The following people will use the implementation subsystem:

Software architects use it to structure the implementation model.
Those who design the next version of the system use it to understand the structure of the implementation model.
Implementers of other parts of the system use it to understand how their functionality can be used.
Those who test the subsystem use it to plan testing activities.
The project manager uses it as a basis for allocating the implementation work.

The implementation subsystem is the physical analogue of the design package. The implementation model and the implementation subsystems are the target of the implementation view, and so are of primary importance at development time.

Properties

Property Name	Brief Description	UML Representation
Name	The name of the subsystem	The attribute "Name" on model element
Brief Description	A brief description of the role and purpose of the subsystem	Tagged value, of type "short text"
Components	The components directly contained in the subsystem	Owned via the meta-aggregation "owns"
Relationships	The relationships directly contained in the subsystem	- " -
Diagrams	The diagrams directly contained in the subsystem	- " -
Implementation Subsystems	The subsystems directly contained in the subsystem	- " -
Import Dependencies	The import dependencies from the subsystem to other subsystems	Owned by an enclosing subsystem, via the meta-aggregation "owns"

Timing

The software architect defines the subsystems during Elaboration, and allocates them to individuals (or teams). This is done before class implementation is started, and thus enables parallel development of subsystems.

Responsibility

An implementer is responsible for the subsystem, and ensures that:

The subsystem fulfills the requirements made on it.
The import dependencies originating from the subsystem are described so that the effect of future changes can be estimated.
The existence of the direct contents of the subsystem, including its components, and subsystems, is justified and kept consistent.
That the subsystem is kept consistent with the corresponding part of the design model.

The implementer responsible for an implementation subsystem is also responsible for the public (visible) components of the subsystem.

It is recommended that the implementer responsible for an implementation subsystem is also responsible for all its contained components; for more information see Artifact: Component.

If a team of implementers develops an implementation subsystem, one of the team members should be responsible for the subsystem.

Tailoring

It is recommended that you use implementation subsystems. You have to decide how to map packages in design to subsystems in implementation. You have to decide how many levels of subsystems you need.

Rational Unified Process