Guidelines: Implementation
Subsystem
Topics
Explanation
A basic way of reducing complexity in an implementation model containing hundreds of elements, is to use implementation subsystems.
Subsystems typically take the form of directories, with additional structural or management information. For example, a subsystem can be created as a directory or a folder in a file system, or a subsystem in Rational Apex for C++ or Ada, or packages using Java. In Rational XDE developments, a Subsystem is a "project" as defined by the Integrated Development Environment (IDE).
The implementation subsystem is the implementation analogue of design package (or large grained design subsystem). The implementation model and the implementation subsystems are the target of the implementation view, and so are of primary importance at development time.
Exporting Elements
An implementation subsystem controls the external visibility of its contents. An element can be referenced by elements outside the subsystem, if it is made visible ("exported") by its declaring subsystem.
All elements (and contained subsystems) in a subsystem are typically visible outside a subsystem by default. This means that any element outside this subsystem can reference all elements. For example, in C++ this means that elements outside can #include all elements inside the subsystem.
Use
The implementation model can be more or less close to the design model, depending on how you map the design packages to implementation subsystems in the implementation model.
It is recommended to keep the mapping one to one, i.e. one design package should be mapped to one implementation subsystem. The primary reason for that is to have a seamless traceability from design to code.
There are situations where you need the subsystems in implementation to differ
from the packages and subsystems in design. For more information, see the Activity:
Structure the Implementation Model. If and how to represent this mapping
should be covered by the
Artifact: Project Specific
Guidelines
You can partition a system into subsystems for many reasons. The same criteria as in design apply in implementation. For more information, see Guidelines: Design Package.
