Tool Mentor: Performing
Architectural Analysis Using Rational Software Architect
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
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:
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.
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:
Capture key abstractions in class diagrams with brief descriptions of each
class. To do this:
- Open the Design Model.
- 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.
- Add a class diagram. See
Adding Class Diagrams to Model Elements.
- Add classes to the diagram, stereotyped as <<entity>>. See
Creating and Modifying Class Diagrams and
Applying Stereotypes.
- Add a description to each class using the Documentation tab in the Properties
View. See
Documenting Model Elements.
- 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.
- 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.
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.
- Add a deployment diagram to the Deployment Model.
- Add nodes to the diagram.
- Add associations between nodes.
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.
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
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
|