Tool Mentor: Identifying Design Mechanisms Using Rational Software Development Platform |
This tool mentor describes how to identify design mechanisms using the IBM Rational Software Delivery Platform modeling environment.
Tool: Rational Software Architect
Relationships
Related Elements | Detail Component Model
Main Description
### Overview The following steps are performed in this tool mentor: Categorize Clients of Analysis Mechanisms Inventory the Implementation Mechanisms Map Design Mechanisms to Implementation Mechanisms Document Architectural Mechanisms 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 action 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 help you find the clients of each mechanism, and document this information: Find clients by right-clicking the mechanism and selecting 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. ### Inventory the Implementation Mechanisms The RAS repository is a good place for collecting all of 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. ### Map Design Mechanisms to Implementation Mechanisms Note: some of the tool capabilities mentioned in this section are not supported in Rational Software Modeler. 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". 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 that 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. 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. ### Additional Tool Information Tutorials: Applying a Pattern Create a Pattern Samples: RAS Assets - RAS Asset to Import/Export Patterns - Simple UML Model
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.