Purpose

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


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:

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 To top of page

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 To top of page

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 .

For more information about Java modeling, see the following topics in the Rational XDE online Help:

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 (such as a Java Class, EJB, or JSP) 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.

EJBs can be created using J2EE patterns in Rational XDE. Refer to the following topics in the Rational XDE online Help:

To See

Create EJBs

Create a BMP Entity Bean

Create a CMP 1.1 Entity Bean

Create a CMP 2.0 Entity Bean

Specify an EJB Primary Key

Add a Field to a CMP Entity Bean

Create a Stateful Session Bean

Create a Stateless Session Bean

Create a Message-Driven Bean

Create an EJB from an Existing Java Class

Create an EJB's Deployment Descriptor (Without Deploying It)

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

Identify Subsystem Interfaces To top of page

The following steps apply to large-granularity subsystems (larger than individual EJBs):

  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 .) Make certain that you use the Java tab of the toolbox, rather than the UML toolbox, to add Java-specific elements.
  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 .

For EJBs, the following steps apply:

  1. EJB interfaces are generated when the EJB is created, so no separate creation of EJB interfaces is required.
  2. Add interface dependencies. See .
  3. Add methods to the interfaces. See .
  4. Add a description to each operation. See .
  5. Add parameters to each operation. See .

Identify Capsule Protocols To top of page

Capsule and protocol modeling is not supported by Rational XDE.

Rational Unified Process   2003.06.13