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 RSA online Help are marked with .

Overview

This tool mentor assumes that a structured Design Model has been created as part of Activity: Architectural Analysis following the steps outlined in Tool Mentor: Performing Architectural Analysis Using Rational Software Architect.

The following steps are performed in this tool mentor:

Additional Tool Information

Use Design Patterns and MechanismsTo top of page

Incorporating a pattern and/or mechanism is effectively performing many of the subsequent steps in this tool mentor (adding new classes, operations, attributes, and relationships), but in accordance with the rules defined by the pattern or mechanism.

If the pattern is in the RSA library, the "apply pattern" is experience is highly interactive. In RSA, a pattern is a special kind of transformation, "optimized for interactive, piecewise elaboration primarily in a single metamodel and within the same level of abstraction, and often within the same model". See the Model Driven Development and Model Driven Architecture and Analysis Mechanisms concepts.

For information on using patterns, refer to Applying Patterns.

Create Initial Design Classes To top of page

  1. Add a class diagram to the model. See Adding Class Diagrams to Model Elements.
  2. Add design classes to the class diagram. See Adding Classifiers to Class Diagrams.
  3. Document each class. See Documenting Model Elements.

For more information, refer to Modeling Static Structure with Class Diagrams.

Identify Persistent Classes To top of page

A class can be marked as persistent. If an MDD (see Model Driven Development and Model Driven Architecture) approach is taken, the profile applied to the model will contain specific stereotypes which will enable the architect to mark the classes that he wants to persist. The transform will use this extra information in combination with the type mappings and generate the appropriate code or a more refined model. For more information, refer to Analysis Mechanisms, Design: Transform Model to Model and Design: Transform Model to Code

In J2EE development, persistency is commonly implemented using entity EJBs. See Tool Mentor: Identifying Design Elements using Rational Software Architect for details.

Refer to Specifying the Persistance Property .

Define Class Visibility To top of page

For each class, determine the class visibility within the package where it resides.

Refer to Specifying Visibility.

Define Operations To top of page

  1. Add operations to each class. See Adding Operations to Classifiers in Diagrams.
  2. Add parameters to operations. See Adding Parameters to Operations.
  3. Specify visibility of operations. See Specifying Visibility.

For more information, refer to Managing Attributes and Operations in Classifiers.

Define Methods To top of page

A description of how an operation is to be implemented might be added to the operation description.

A sequence diagram might optionally be used to describe a method. See the RSA online Help topic Documenting Model Elements.

For more information, refer to Sequence Diagrams.

Define States To top of page

A state machine might optionally be used.

For more information, refer to State Machine Diagrams.

Define Attributes To top of page

  1. Define attributes. See Attributes.
  2. Add attributes to classifiers. See Adding Attributes to Classifiers in Diagrams.
  3. Specify visibility. See Specifying Visibility.

Define Dependencies To top of page

Refer to Dependency Relationships.

Define AssociationsTo top of page

  1. Add association relationships. See Adding Association Relationships .
  2. Specify the kind of each association. See Adding Relationships .

Define Internal Structure To top of page

Refer to the structured classes topics within Modeling Static Structure with Class Diagrams.

Define Generalizations To top of page

Refer to Relationships.

Resolve Use-Case Collisions To top of page

Refer to Specifying the Concurrency Property for Operations .

Handle Nonfunctional Requirements in General To top of page

Nonfunctional requirements often drive a class to incorporate specific design mechanisms using collaborations and patterns. Often the use of a framework component is sufficient to satisfy a nonfunctional requirement. (See Tool Mentor: Identifying Design Elements Using Rational Software Architect.)

For more information, refer to Applying Patterns.

Evaluate the Results To top of page

It might be helpful to publish any models to html format. Also note that diagrams can be copied from the RSA tool to Microsoft Word and other programs.

For more information, refer to Publishing Models for Review Outside the Modeling Tool and to the following tutorials:

  • Generating Standard Model Reports
  • Generating Custom Model Reports
  • Publishing Models to Web

Additional Tool InformationTo top of page

Tours:

  • Patterns

Tutorials:

  • Applying the XYZ Pattern
  • Creating a Diagram with RSA
  • Analysis: Create the Sequence Diagram

Samples:

  • Model for Pattern Application
  • Pattern

Rational Unified Process   2003.06.15