Guidelines: Implementation Subsystem
 |
An implementation subsystem is a collection of components and other implementation subsystems that are used to structure the implementation model by dividing it into smaller parts. |
Topics
Explanation 
A basic way of reducing complexity in an implementation model containing hundreds of components, is to use implementation subsystems.
Subsystems 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 subsystems in Rational/Apex for C++ or Ada, or packages using Java.
Exporting Components
An implementation subsystem controls the external visibility of its contents. A component can be referenced by components outside the subsystem, if it is made visible ("exported") by its declaring subsystem.
All components (and contained subsystem) in a subsystem are visible outside a subsystem by default. This means that any component outside this subsystem can reference all components. For example, in C++ this means that components outside can #include all components 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 in design. For more information, see the Activity: Structure the Implementation Model.
You should decide how the design model relate to the implementation model; this should be captured in the Design Guidelines specific to the project.
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.
