Overview
The following steps are performed in this tool mentor:
Additional Tool Information
As part of the support for Model
Driven Development and Model Driven Architecture, the tool provides the capabilities to move from model to code
through the use of transformations. The main approach is based on a combination of type mappings (source model's
classes, their attributes, operations, relationships) and source model marking, defined in profiles. The reason for
this combined method is that in most of the cases the source model does not contain enough information to drive the
transformation. The architect has to add specific 'marks' which enables the transformation to perform. For more
information, refer to Analysis Mechanisms.
Depending on the profiles applied, the clients of analysis mechanisms will have to be 'marked' accordingly, using the
right stereotypes. For more information, see: Applying Transformations.
Note: even if you do not plan on using automated transformations you will find value in using profiles to 'mark' your
model. Base on the profile defined, this additional information added to a model can include stereotypes, properties
and constraints. By defining appropriate profiles, using them appropriately and communicating the meaning behind the
profiles – you can add a great deal of precision to your models which can lead to more effective transformations
(regardless of whether the transformation is automated or performed manually).
The key steps to follow in creating a profile include:
-
Create a Profile Project
-
Add Stereotypes
-
Utilize extensions to connect the Stereotypes to UML elements
-
Test by applying the Profile to a project
-
Document
-
Package as a plug-in
-
Distribute via RAS
The tool can assist you in finding the clients of each mechanism and document this information:
-
Find clients by right clicking on the mechanism and using Filters > Show Related Elements
-
Use a Topic Diagram. See: Topic Diagrams
-
Use a Browse Diagram. See: Browse Diagrams
-
Use <<perspective>> packages to provide a view of the mechanisms that are used.
-
Use <<framework>> packages to provide a view of the internal workings of the mechanisms.
Within the analysis mechanism's framework package, the clients are shown on a Client Usage Diagram, where the clients
have a dependency to the analysis mechanism clas. As part of the same framework package, create a profile
component for each characteristic profile needed. Use the Documentation Tab in the class's Properties View to document
the usage profiles. Group the clients according to their use of characteristic profiles and show the relationships
between clients and profile classes on a Profile Usage Diagram.
The RAS repository is a good place for collecting all the potential candidates for reuse, especially patterns. In
addition, a RAS asset can be a model - which may provide a representation of the Implementation Mechanism. It would
then be possible to store the model representations of your implementation mechanisms in a shared RAS repository and
have the team query this repository as needed.
See: RAS
Assets and RAS
Pattern Assets.
Note: some of the tool capabilities mentioned in this section are not supported in RSM.
If a Model Driven Development approach is taken, this step is performed with the assistance of the transformation
capabilities. There are two kinds of transformations: transforms and patterns. A transform is "a transformation
optimized for batch processing, primarily across metamodels, models and levels of abstraction". A pattern is a
special kind of transformation, "optimized for interactive, piecewise elaboration primarily in a single metamodel and
within the same level of abstraction, and often within the same model". See the Model
Driven Development and Model Driven Architecture and Analysis Mechanisms concepts.
It may turn out that there are a number of implementation mechanisms that would be appropriate for realizing the design
mechanism. One additional factor that should be taken into consideration as you make the selection is whether the
implementation mechanism can be realized via a transformation. Also, watch for implementation mechanisms that are reused
often in your development projects. These are good candidates for automation via patterns and transformations. As part of
the analysis as whether to automate the mapping between the design and implementation mechanism you will need to calculate
the return on the investment needed to automate.
Depending on the profiles applied to the model, a number of transforms are available "out of the box". For the more
advanced user, the tool provides a framework for building customized transformations. See Applying Patterns and Applying
Transformations.
In a more code-centric development environment, some of the mappings could be discovered starting with the existent
code and using the pattern and anti-pattern detection capabilities which are part of the support for Architectural
Analysis. See the Architectural Discovery, Analysis and Control guidelines.
Once the mechanisms have been identified, create an Architecture Mechanisms Mapping Diagram, containing the analysis,
design and implementation mechanisms and the realization relationships between them.
Mechanisms themselves are Design Model elements (such as Design Package, Design Class, and Design Subsystem) that can
be represented in the Design Model as part of their respective design tasks. See Identify Design Elements for guidelines on creating Design Model
elements. Note that a pattern is particularly well suited to documenting a design and implementation mechanism, because
it allows clients of the mechanism to expand the pattern and to generate much of the required design and code. See:
Authoring Patterns
and Packaging Assets
for Reuse .
Other options for documenting the mechanisms include:
-
Using notes on diagrams
-
Additional diagrams that specify the static and dynamic aspects of the mechanism
-
Using constraints
-
Using profiles
-
Deploying models of mechanisms as RAS assets (use the RAS packaging mechanism to hold documentation about the asset
in addition to the asset itself)
An additional aspect to consider when documenting is to define code rules that can be used to enforce how the mechanism
is used. Once the guidelines have been defined, use Code Review to automate the application of the guidelines to ensure
adherence to the specified usage model.
Tutorials:
-
Applying a
Pattern
-
Create a
Pattern
Samples:
-
RAS Assets - RAS
Asset to Import/Export
-
Patterns - Simple
UML Model
|