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 set of structured models has already been created, in accordance with the Model Structure Guidelines for Rational Software Architect.

The following steps are performed in this tool mentor:

Additional Tool Information

Develop Architecture Overview  To top of page

For this step RSA can be used in two ways:

  • as a drawing tool for creating informal diagrams that describe the architecture overview
  • as a UML modeling tool to create formal semantic models that specify most details of a solution and from which significant portions of the implementation can be automatically generated, using RSA model-to-model and model-to-code transformations.

For more information, refer to the following white papers for guidance on structuring models:

Survey Available Assets To top of page

The architect must consider the reuse of in-place assets, including existing RSA models. RSA also offers extensive support for automated architectural analysis, enabling the use to perform architecture discovery through high-level software visualization and patterns and anti-patterns detection. For more information, refer to the Architectural Discovery, Analysis and Control guidelines.

Note that the Rational Technical Library on the IBM developerWorks contains assets that you might find useful.

Define the High-Level Organization of Subsystems To top of page

Your decisions about how the solution will be organized into components, services, and subsystems are captured in the design model (e.g. an EIT Design Model) and based upon architectural considerations such as:

  • layering strategy
  • componentization strategy (driven in turn by concerns of functional cohesion and loose coupling)
  • project-specific division of labor

If a Model Driven Development (MDD) approach is taken, the model-to-model and model-to-code transformations introduce additional concerns regarding model structures. For instance, you may wish to align the packages of your RSA design model to reflect the set of RSA projects in which you will develop the implementation. Alternatively, a "mapping model" can be used to define how the implementation artifacts of the solution will be organized into projects and folders, and how the design model constructs will map into those projects and folders.

RSA can also support the need to organize elements in more than one way, in order to accommodate all the stakeholders and their specific perspectives. The solution is to use <<perspective>> packages which separates the organization of the design model elements from the diagrammatic views of the model's content, enabling you to create as many other views as are necessary, views which can reflect orthogonal organizational approaches.

For more information, refer to the following white papers for guidance on structuring models:

Identify Key Abstractions  To top of page

Capture key abstractions in class diagrams with brief descriptions of each class. To do this:

  1. Open the Design Model.
  2. Navigate to the package containing key abstractions. An alternative is to use a Key Abstractions <<perspective>> package. See Model Structure Guidelines for Rational Software Architect.
  3. Add a class diagram. See Adding Class Diagrams to Model Elements.
  4. Add classes to the diagram, stereotyped as <<entity>>. See Creating and Modifying Class Diagrams and Applying Stereotypes.
  5. Add a description to each class using the Documentation tab in the Properties View. See Documenting Model Elements.
  6. Optionally associate a document with the class: in the Model Explorer, right click the model element to which you want to link a file, and then click New UML > URL . See Linking External Files to Model Elements.
  7. Define any relationships that exist between the classes. See Relationships.
    • Add association relationships.
    • Specify the kinds of association relationships.
    • Add generalization relationships.

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

Identify Stereotypical Interactions To top of page

This step is included only when performing this activity during inception.

The purpose of this step is to identify those interactions, between key abstractions in the system, that characterize or are representative of significant kinds of activity in the system. These interactions are captured as Use-Case Realizations.

For guidance on creating Use-Case Realizations in RSA, see Tool Mentor: Performing Use-Case Analysis Using Rational Software Architect.

Develop Deployment Overview To top of page

  1. Add a deployment diagram to the Deployment Model.
  2. Add nodes to the diagram.
  3. Add associations between nodes.

Identify Analysis Mechanisms  To top of page

There is no RSA specific guidance for this step. There are though RSA features and capabilities that might help in the bottom-up identification of some Analysis Mechanisms through the RSA support for Architectural Analysis (pattern and anti-pattern detection). The RAS repository is a good place for collecting all the potential candidates for reuse. See Packaging Patterns for Reuse and Applying Patterns for a complete view on what are the requirements for packaging reusable assets.

Review the ResultsTo top of page

The results of architectural analysis are preliminary and relatively informal; therefore, reviews should be informal as well. It might be helpful to publish any models to html format. Also note that diagrams can be copied from RSA 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:

  • RAS
  • Patterns

Tutorials:

  • Applying the XYZ Pattern
  • Analysis: Create the Analysis Model
  • Design: Create an N-Tier Design Model
  • Design: Common Elements Layer Design Model

Samples:

  • Model for Pattern Application
  • Patterns

Rational Unified Process   2003.06.15