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.
|