|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.
||Package in the implementation model, either its
top-level package, or stereotyped as «implementation subsystem».
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
- 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.
name of the subsystem
attribute "Name" on model element
brief description of the role and purpose of the subsystem
value, of type "short text"
components directly contained in the subsystem
via the meta-aggregation "owns"
relationships directly contained in the subsystem
diagrams directly contained in the subsystem
subsystems directly contained in the subsystem
import dependencies from the subsystem to other subsystems
by an enclosing subsystem, via the meta-aggregation "owns"
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.
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
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.
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.
© 1987 - 2001 Rational Software Corporation