Tool Mentor: Identifying Design Mechanisms Using Rational Software Development Platform
This tool mentor describes how to identify design mechanisms using the SDP modeling environment.
Main Description


The following steps are performed in this tool mentor:

Additional Tool Information

Categorize Clients of Analysis Mechanisms

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: help book iconApplying 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:

  1. Create a Profile Project
  2. Add Stereotypes
  3. Utilize extensions to connect the Stereotypes to UML elements
  4. Test by applying the Profile to a project
  5. Document
  6. Package as a plug-in
  7. Distribute via RAS

The tool can assist you in finding the clients of each mechanism and document this information:

  1. Find clients by right clicking on the mechanism and using Filters > Show Related Elements
  2. Use a Topic Diagram. See: help book iconTopic Diagrams
  3. Use a Browse Diagram. See: help book iconBrowse Diagrams
  4. Use <<perspective>> packages to provide a view of the mechanisms that are used.
  5. 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.

Inventory the Implementation Mechanisms

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: help book iconRAS Assets and help book iconRAS Pattern Assets.

Map Design Mechanisms to Implementation Mechanisms

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 help book iconApplying Patterns and help book iconApplying 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.

Document Architectural Mechanisms

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: help book iconAuthoring Patterns and help book iconPackaging 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.

Additional Tool Information


  • help book iconApplying a Pattern
  • help book iconCreate a Pattern 


  • help book iconRAS Assets - RAS Asset to Import/Export
  • help book iconPatterns - Simple UML Model 

More Information