Guideline: Implementation Subsystem








var backPath = './../../../';
var imgPath = './../../../images/';
var nodeInfo=[{view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_Jvt1cAIaEdqEutyfYo0quQ", "_jijhYAIaEdqEutyfYo0quQ", "_n7ZcgN7REdmjRZts2c4ZjQ", "{0F629848-C19E-49AB-A6C1-C8D6A094898A}", "9.455380296721554E-305"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_jD8dUAIbEdqEutyfYo0quQ", "_2ClPcDIcEdqDs_9ORT1Rig", "9.455380296721554E-305"]}];
contentPage.preload(imgPath, backPath, nodeInfo, '', false, false, false);










Guideline: Implementation Subsystem















Implementation Subsystem helps organize an Implementation Model and thus reduce its complexity. This guideline discusses some options to consider when designing the implementation subsystem.






Relationships



Related Elements


Implementation Subsystem






Main Description



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 Task: 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 Guideline: Design Package.





©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();