Tool Mentor: Structuring
the Implementation Model 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 RSA online Help are marked with .
Overview
This tool mentor assumes that you have defined the top level structure of
your Implementation Model as described in the Model
Structure Guidelines for Rational Studio Architect.
The steps in this tool mentor permit this initial structure to be refined.
The following steps are performed in this tool mentor:
Additional Tool Information
The recommended approach in RSA is MDD - Model Driven Development (see Model
Driven Development and Model Driven Architecture). If this approach is followed
by the development team, the Implementation Model is strongly driven by the
organization of the Design Model. As Implementation Subsystems are identified,
they should be modeled as packages or subsystems in the Design Model. Generally
speaking, when you identify the packages in the Design Model, you should be
considering how those will map to Eclipse/RSA projects. Larger subsystems typically
map to their own projects, finer-grained packages typically map to source folders
within projects. Refer to the sections of the Model
Structure Guidelines for Rational Software Architect that discuss Project
Structures and the internal organization of the Implementation and Design Models.
In RSA the Implementation
View could be defined by using <<perspective>> packages, containing
diagrams which show dependencies between the subsystems. Depending upon what
kind of transformation is applied to the Design Model, the dependencies you
define among the packages/subsystems might map to 3GL import declarations and
project dependency declarations in Eclipse/RSA project metadata.
Once code has been generated, more detailed UML diagrams could be produced,
showing the implementation-level constructs and their relationships, by creating
Class Diagrams directly in the projects and populating them by dragging implementation
artifacts onto them. Refer to online Help topics related to the UML Visual Editor
for Java.
If there is a need to represent the actual RSA projects and packages in which
you expect the code and related files to reside, prior to any code generation,
an Implementation Overview Model might be useful. For more information, see
the Implementation Model related topics in the Model
Structure Guidelines for Rational Software Architect white paper.
There is no RSA specific guidance for this step.
In an MDD environment, the dependencies in the Implementation Model will mirror
very closely the ones defined explicitly or implicitly in the Design Model.
The specifics are determined by the code generation transformations applied
to the Design Model.
If an Implementation Overview Model is used, this will be the place to show
the anticipated dependencies among the projects and packages, which can prove
helpful in identifying system build requirements (see Model
Structure Guidelines for Rational Software Architect).
In an MDD environment, depending upon what kind of transformation is applied
to the Design Model, various types of deployable artifacts might be generated.
For example, from elements such as <<control>> and <<entity>>
classes, session and entity EJB might be generated for a J2EE target, including:
the code for the implementation classes plus the interfaces plus deployment
descriptor content that allocates the EJBs to EJB JARs and maps those JARs to
EARs.
You can choose to model deployable artifacts at the conceptual level, using
an RSA deployment model. If you choose to do so, you will model them using UML
nodes and artifacts. At the current time RSA transformations do not leverage
the semantics of such diagrams to generate deployment data, so your diagrams
will be purely conceptual and useful only as documentation.
Optionally, you could also depict actual implementation artifacts in such
diagrams by dropping them onto the canvas and connecting them (using dependencies)
to the conceptual elements of the diagram.
There is no RSA specific guidance for this step.
If there is a separate Implementation View, it must be maintained. The general
recommendation presented in the
Model Structure Guidelines for Rational Software Architect white paper is to use
the <<perspective>> packages, containing diagrams which show dependencies
between the subsystems.
It can be helpful to publish 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
Cheat Sheets:
Structuring the Implementation Model
|