Tool Mentor: Identifying
Design Elements 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
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.
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:
- Create class diagrams as needed. See
Adding Class Diagrams to Model Elements.
- Add signals. See
Creating and Modifying Class Diagrams.
- Add a brief description to each design element. See
Documenting Model Elements.
- Add generalization relationships between signals, if applicable.
For more information about class diagrams, see
Modeling Static Structure with Class Diagrams.
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.
- Create class diagrams as needed. See
Adding
Class Diagrams to Model Elements .
- Add subsystems and classes. See
Creating
and Modifying Class Diagrams .
- Add a brief description to each design element. See
Documenting
Model Elements .
- (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 .
- 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.
The following steps apply to large-granularity subsystems:
- 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.
- Add interface dependencies.
- Map subsystems to interfaces by adding a realization relationship from the
subsystem to the interface.
- Document the interface, including required behavior. See
Documenting
Model Elements .
- Add operations to the interface. See
Adding
Operations to Classifiers in Diagrams .
- Add a description to each operation. See
Documenting
Model Elements .
- Add parameters to each operation. See
Adding
Operations to Classifiers in Diagrams .
- 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.
Tours:
RAS
Patterns
Tutorials:
Applying the XYZ Pattern
Samples:
Model for Pattern Application
Patterns
Cheat Sheets:
Identifying
Design Elements
|