An Implementation Subsystem is a set of Implementation Elements. Implementation Subsystems structure the Implementation Model by dividing it into smaller parts that can be separately integrated and tested.  
Other Relationships:  Part Of Implementation Model
Role:  Implementer 
Optionality/Occurrence:  Recommended. Elaboration phase.
Templates and Reports: 
     
Examples: 
     
UML Representation:  Package in the implementation model, either its top-level package, or stereotyped as <<implementation subsystem>>. 
More Information:   
Input to Activities:    Output from Activities:   

Purpose To top of page

The following people will use the implementation subsystem:

  • Software architects use it to structure the implementation model into parts that can be separately integrated and tested.
  • 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 initially defined in the implementation view, and so are of primary importance at development time.

Properties To top of page

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" 
Implementation Elements  The Implementation Elements directly contained in the subsystem, including files and directories.  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 To top of page

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 To top of page

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 contents of the subsystem, including files, directories, and nested implementation subsystems, form a cohesive part of the implementation suitable for separate integration and test.
  • 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) elements of the subsystem.

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

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

Tailoring To top of page

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



Rational Unified Process   2003.06.13