Tool Mentor: Managing Subsystems
Purpose
This tool mentor describes how to represent design subsystems and related artifacts in Rational Rose®.
Related Rational Unified Process Activities: Identify Design Elements, Subsystem Design
Overview
The following steps are performed to manage subsystems:
- Creating Subsystem Interfaces
- Creating Classes within the Subsystem
- Documenting Package and Subsystem Dependencies
- Documenting Subsystem Contents
- Documenting Subsystem Behavior
1. Creating
Subsystems in the Design Model 
You create a subsystem by creating a package in the Design Model and using the Package Specification to assign it a stereotype of "subsystem."
In order to show the subsystem in sequence and collaboration diagrams in Rational Rose, you create a class that acts as a "proxy" for the subsystem in diagrams. To create this class in the subsystem, read about creating a class in Tool Mentor: Managing Classes. This "proxy" class should have the same name as the subsystem, and should be stereotyped "subsystem proxy" to indicate that it exists as a "proxy" for the subsystem.
For
more information, refer to the following topics in the Rational Rose
online help:
-
How To > Create and Work in a Model >Create and Display Stereotypes
- Subsystem Stereotype Package and Subsystem Stereotype Sample
2. Creating Subsystem
Interfaces
See Tool Mentor: Managing Interfaces
In this step, you enable the "subsystem proxy" to provide all of the operations defined by the interfaces of the subsystem. To do this, you first create a new Class Diagram in the subsystem package and give it the name "Interface Realizations." You can then drag and drop the "subsystem proxy" class into the new diagram. Using Rational Rose's drawing tool, you should draw realization associations from the "subsystem proxy" class to the interface classes that the proxy realizes, making sure that all the interface operations are defined in the "subsystem proxy" class. This may require creating one or more operations on the "subsystem proxy" class. See Tool Mentor: Managing Classes for more information.
For
more information, refer to the following topics in the Rational Rose
online help:
-
Realize Relationship
- Interface
3. Creating
Classes within the Subsystem
To create classes inside the subsystem, see Tool Mentor: Managing Classes.
With the exception of the subsystem "subsystem proxy" and the subsystem interfaces, all contents of the subsystem should be "invisible" to model elements outside the subsystem. This is done by setting the class export control to "implementation" in the Class Specification.
4. Documenting
Package and Subsystem Dependencies
You should document the dependencies between packages/subsystems in the Design Model. To do this, you create a new Class Diagram for the Design Model and name it "Package/Subsystem Dependencies." You can then drag and drop the packages and subsystems from the browser into the new diagram. Any existing dependency relationships will be displayed automatically. You can also visually arrange the packages and subsystems into layers in the diagram and use the Text Box tool icon to annotate the layers. Finally, you can create additional package and subsystem dependency relationships using the Dependency tool icon.
For
more information, refer to the Dependency
Relationship topic in the Rational Rose online help:
5. Documenting Subsystem
Contents
Each package and subsystem should contain one or more class diagrams to document and illustrate the classes contained in the package/subsystem.
6. Documenting Subsystem
Behavior
Each Subsystem should have one or more Sequence Diagrams to illustrate how the operations offered by the interfaces of the subsystem are distributed to the contents of the subsystem. For more details, see Tool Mentor: Managing Sequence Diagrams.
The sequence diagram should illustrate how a particular operation offered by a subsystem interface is performed by model elements contained in the subsystem. The left-most object in these "interface operation" diagrams should be the "subsystem proxy" class. The remainder of the objects represent the private classes of the subsystem. The messages between them illustrate how the interface operation is realized.
It is recommended that you name the diagram "<interface name>::<operation name>". This naming convention simplifies future tracing of interface behaviors to the classes which implement the interface operations.
