Tool Mentor: Identifying Design Elements Using Rational XDE Developer - .NET Edition

Purpose

This section provides links to additional information related to this tool mentor.

• Identify Design Elements

The steps in this tool mentor match those in the activity. Links to topics in the Rational XDE™ online Help are marked with .

Overview

In the tool mentor, the following steps are performed for the use cases to be designed in the current iteration:

• Identify Events and Signals
• Identify Classes, Active Classes and Subsystems
• Identify Subsystem Interfaces
• Identify Capsule Protocols

Architecturally significant design elements may be documented in a separate Logical View, that is maintained as design elements are identified. See Rational XDE Model Structure Guidelines.

Identify Events and Signals

The characteristics of events should be captured as needed to drive the identification of the design elements that handle them. This information can be captured informally, such as in a separate document, rather than as part of a Rational XDE model.

Asynchronous communication events can be modeled as signals to express the data that they carry, or to express relationships between signals, such as a generalization relationship. The following substeps describe how to model signals:

1. Create class diagrams as needed. See .
2. Add signals. See .
3. Add a brief description to each design element. See .
4. Add generalization relationships between signals, if applicable. See .

For more information about class diagrams, see . For more information about signals, see .

Identify Classes, Active Classes and Subsystems

Design elements are generally created in the following three ways:

• modeling (by adding to a class diagram)
• expanding a pattern
• coding and reverse engineering

These approaches are explained in the sections that follow.

Expanding a Pattern

You can use design patterns to identify design elements. See in the Rational XDE online Help.

Identify candidate patterns that may be useful. Refer to the following topics in the Rational XDE online Help:

Modeling

Create class diagrams in the Design Model to capture design elements. If you decide to maintain the analysis classes, then you may want to establish traceability dependencies to the analysis classes.

1. Create class diagrams as needed. See .
2. Add subsystems and classes. See .
3. Add a brief description to each design element. See .
4. (optional) Add traceability to analysis classes. See .
5. Organize the design elements into packages. See . Also refer to the white paper Rational XDE Model Structure Guidelines.

For more information about class diagrams, see .

Coding and Reverse Engineering

Another approach is to sketch out the design in code form, reverse engineer it to create a skeletal implementation model, and then drag and drop these classes onto diagrams in the Design Model. Once you have made the decision that a design class will map to an implementation-specific class this approach has the following advantages:

• As an optional alternative, a code editor can be used to sketch out interfaces, methods, and attributes using reverse engineering to reflect these elements in the model.
• Existing code assets can be reverse engineered and contribute to the Design Model.
• Selected elements can be prototyped to validate a complex concept, while using round-trip engineering to keep those prototypes consistent with the Design Model.

For more information, refer to the following topics in Rational XDE online Help:

Identify Subsystem Interfaces

1. For each subsystem, identify a set of candidate interfaces. Add interfaces to an existing class diagram, or create new class diagrams as needed. (See .)
2. Add interface dependencies. See .
3. Map subsystems to interfaces by adding a realization relationship from the subsystem to the interface. See .
4. Document the interface, including required behavior. See .
5. Add methods to the interface. See .
6. Add a description to each operation. See .
7. Add parameters to each method. See .
8. Organize the interfaces into packages. See .

Identify Capsule Protocols

Capsule and protocol modeling is not supported by Rational XDE.

Rational Unified Process