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

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

Additional Tool Information

Architecturally significant design elements may be documented in a separate Logical View, that is maintained as design elements are identified. The general recommendation in RSA is to use <<perspective>> packages. See Model Structure Guidelines for Rational Software Architect for more information on this topic.

Identify Events and Signals To top of page

The characteristics of events, also called triggers in UML 2.0 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 RSA 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 Adding Class Diagrams to Model Elements.
  2. Add signals. See Creating and Modifying Class Diagrams.
  3. Add a brief description to each design element. See Documenting Model Elements.
  4. Add generalization relationships between signals, if applicable.

For more information about class diagrams, see Modeling Static Structure with Class Diagrams.

Identify Classes, Active Classes and Subsystems To top of page

Design elements are generally created in the following three ways:

  • Expanding a pattern
  • Modeling
  • Coding and reverse engineering

These approaches are explained in the sections that follow.

Expanding a Pattern

In RSA a pattern is a special kind of transformation that is optimized for interactive, piece-wise elaboration, primarily in a single meta-model and within the same level of abstraction, and often within the same model. For more information, refer to Analysis Mechanisms.

See Authoring Patterns and Applying Patterns in the RSA online Help.

Modeling

The RSA tool supports a model-driven approach to software development (see Model Driven Development and Model Driven Architecture and Analysis Mechanisms), wherein you construct a set of models that eventually includes a design model and generate implementation artifacts (3GL code, descriptors, etc.) from the design model using Transformations. In some cases the code-generating Transformations will take analysis classes as inputs, but primarily they will be driven by design elements. For more information, see: Design: Transform Model to Model and Design: Transform Model to Code .

In a traditional development approach you will 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 by using "trace" dependencies to the analysis classes.

  1. Create class diagrams as needed. See Adding Class Diagrams to Model Elements .
  2. Add subsystems and classes. See Creating and Modifying Class Diagrams .
  3. Add a brief description to each design element. See Documenting Model Elements .
  4. (optional) Add traceability to analysis classes by using "trace" dependencies from your design elements to the analysis classes on which they were based.See Adding Abstraction Relationships .
  5. Organize the design elements into subsystems and packages. Refer to the white paper Model Structure Guidelines for Rational Software Architect.

For more information about class diagrams, see Modeling Static Structure with Class Diagrams .

Coding and Reverse Engineering

A different approach is a "code first" approach: the code is the main driver either because already exists (for example in a non-greenfield development cycle) or the team needs to tackle some specific project risks by coding a prototype to validate a complex concept. As part of the support for Architecture Discovery and Recovery (see the Architectural Discovery, Analysis and Control guidelines), the RSA's code visualization capability can automatically populate topic diagrams, such as package structure, class internals, inheritance trees, and collaborations. The goal of this activity is not only to understand the existing code, but also to extract a model of the application, which could be used in conjunction with other specific models to generate the new version of the application, by using transformations.

Once you have generated or composed a UML diagram of existing code, you have these options for leveraging the code depictions as part of your design model:

  • Harvest a UML depiction of a code element into your design model, as a true semantic model element. This creates a new UML element in the design model that has no connection to the code item that was harvested. It does however have properties (for instance attributes and operations) that reflect the properties of the harvested code item. Because it is a true UML semantic element, new code can be generated from it (in other words it has the same status within the design model as any design element that was defined through the greenfield modeling process described previously earlier.)
  • Place a visual reference to the code element into a diagram that resides within your design model. This reference itself has no semantic meaning within the design model, and no new code will be generated from it. It is, as its name implies, just a reference to the actual code element. However, you can draw relationships between the code reference and the semantic design elements in the design model. Those relationships do have semantic meaning within the design model and they do affect code generation.

For more information, refer to Modeling Static Structure with Class Diagrams in the RSA online Help.

Identify Subsystem Interfaces To top of page

The following steps apply to large-granularity subsystems:

  1. For each subsystem, identify a set of candidate interfaces. If you previously created analysis classes, and did analysis-level use case realizations, you will now decide how those operations are to be grouped together and exposed as the interfaces of particular components or services. Add interfaces to an existing component diagram, or create new component diagrams as needed. See Adding Shapes.
  2. Add interface dependencies.
  3. Map subsystems to interfaces by adding a realization relationship from the subsystem to the interface.
  4. Document the interface, including required behavior. See Documenting Model Elements .
  5. Add operations to the interface. See Adding Operations to Classifiers in Diagrams .
  6. Add a description to each operation. See Documenting Model Elements .
  7. Add parameters to each operation. See Adding Operations to Classifiers in Diagrams .
  8. Organize the interfaces into packages.

In UML 2.0 subsystems are large components and could be represented as structured classes with ports and/or interfaces. See the on-line help specific UML 2.0 topics.

Additional Tool InformationTo top of page

Tours:

  • RAS
  • Patterns

Tutorials:

  • Applying the XYZ Pattern

Samples:

  • Model for Pattern Application
  • Patterns

Cheat Sheets:

  • Identifying Design Elements

Rational Unified Process   2003.06.15