Overview

The following steps are performed to manage subsystems:

1. Create subsystems in the Design Model
2. Create subsystem interfaces
3. Create classes within the subsystem
4. Document package and subsystem dependencies
5. Document subsystem contents
6. Document subsystem behavior

1. Create 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. Create 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 realized by 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 dependencies 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. Create classes within the subsystem

To create classes inside the subsystem, see Tool Mentor: Managing Classes.

With the exception of the subsystem's "subsystem proxy", 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. Ideally, the interfaces realized by the subsystem should be defined outside the package that represents the subsystem (so that the subsystem is easily replaceable), but if defined inside the package representing the subsystem, must also be visible.

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