Overview

This tool mentor assumes that a set of structured models has already been created, in accordance with the Model Structure Guidelines for RSx.

The following steps are performed in this tool mentor:

• Develop Architecture Overview
• Survey Available Assets
• Define the High-Level Organization of Subsystems
• Identify Key Abstractions
• Identify Stereotypical Interactions
• Develop Deployment Overview
• Identify Analysis Mechanisms
• Review the Results

Additional Tool Information

Develop Architecture Overview

For this step, the tool can be used in two ways:

• as a drawing tool for creating informal diagrams that describe the architecture overview
• as a UML modeling tool to create formal semantic models that specify most details of a solution and from which significant portions of the implementation can be automatically generated, using model-to-model and model-to-code transformations.

For J2EE applications, there are a number of standard deployment configurations on which you can base your initial architecture. For creating a set of diagrams, you will want to use a combination of elements from the Deployment and Geometric Shapes drawers from the palette.

For more information, refer to the following white papers for guidance on structuring models:

• Model Structure Guidelines for RSx
• Model Driven Development and Model Driven Architecture

Survey Available Assets

Note: some of the tool capabilities mentioned in this section are not supported in RSM.

The architect must consider the reuse of in-place assets, including existing models. The tool also offers extensive support for automated architectural analysis, enabling the use to perform architecture discovery through high-level software visualization and patterns and anti-patterns detection. For more information, refer to the Architectural Discovery, Analysis and Control guidelines.

Identify Transformation Requirements

The tool can be used in three ways:

1. As a drawing tool for creating informal diagrams that describe the architecture overview.
2. As a UML modeling tool to create formal semantic models that specify most details of an solution and from which additional details can be automatically generated, using model-to-model and model-to-code transformations.
3. As a UML modeling tool to create formal semantic models that specify most details of a solution. Transformations occur, but they are performed manually.

If you are working under either scenario 2 or 3 (above), then thought must go into the transformations that will be needed. In a best case scenario, the transformation that is needed will already exist and will provide the necessary functionality.

If you are working under scenario 2 (above) and the transformation does not quite meet your needs, then you will need to do one of the following:

• Extend the existing transformation.
• Update the transformation by changing the code of the transformation.
• Create a new transformation that either feeds into or accepts output from the existing transformation.
• If reuse is not possible and you need to create a new standalone transformation, you may want to use the existing template as an example/starting point.

Hint: There are sample transformations that you can reuse or use as a starting point for your own transformation: business model to use case model, use case model to analysis model, and analysis model to design model.

If you need to create a new transformation, use the following 6 steps to guide you:

1. Create a transformation plug-in project
2. Specify type of Source and Target Model
3. Specify Applicable Profiles
4. Add rules to the transformation
5. Implement transformation specific behavior
6. Test the transformation

Identify Reusable Patterns

In addition to looking for transformations to reuse, it is important to think of the relevant patterns that may be applicable to your project. As with transformations, the best-case scenario is that the patterns you require already exist as needed.

If the patterns identified do not quite fit your needs, you have a number of options:

1. Create a new pattern that works in conjunction with the existing pattern
2. Update the pattern so that it does suit your needs
3. Use the existing pattern as a blueprint/sample as you build a new pattern that better fits your needs

Refer to the help category Extending RSx functionality (RSx stands for RSA, RSM or RSD).

If you decide to create your own pattern, use the following 6 steps to guide you:

1. Create a pattern library
2. Add a pattern to the pattern library
3. Add template parameters to the pattern
4. Specify dependencies between template parameters
5. Implement pattern specific behavior
6. Test the pattern

Identify Reusable Profiles

Review your inventory of available profiles and decide if you will need to augment this collection of profiles. Profiles can be a useful mechanism to assist in adding detail and precision to your model without tying you to a specific implementation. Another aspect to consider is the inter-relationship between patterns, transformations and profiles. These mechanisms can be used alone, but often offer a higher level of productivity when used together.

Identify Reusable Models and Code Elements

The architect must consider the reuse of in-place assets, including existing models. The tool also offers extensive support for automated architectural analysis, enabling the user to perform architecture discovery through high-level software visualization and patterns and anti-patterns detection. For more information, refer to the Architectural Discovery, Analysis and Control guidelines. .

There is also a tutorial titled: Creating Architectural Control Rules and Reviewing the Architecture of an Application where you can get a better understanding of some of the automation features in the tool to evaluate existing assets.

Check developerWorks for Assets

Note that the Rational Technical Library on the IBM developerWorks contains assets that you might find useful.

Use RAS and the Asset Explorer

When working with the Reusable Asset Specification (RAS), you will want to switch to the RAS Perspective in the tool workbench. A key view in the perspective is the Asset Explorer, which allows you to connect to an existing repository, navigate thru repositories or create repositories containing RAS assets. In addition, an asset stored in a repository can be commented on by users of the system - providing another mechanism to help you in your selection of assets.

For more information, refer to:

• RAS Assets - RAS Asset to Import/Export 
• Tutorials and samples for importing and exporting RAS assets 
• Packaging Assets for Reuse
• Finding RAS Assets

Define the High-Level Organization of Subsystems

• layering strategy
• componentization strategy (driven in turn by concerns of functional cohesion and loose coupling)
• project-specific division of labor

If a Model Driven Development (MDD) approach using automated transformations is taken, the model-to-model and model-to-code transformations introduce additional concerns regarding model structures. For instance, you may wish to align the packages of your design model to reflect the set of projects in which you will develop the implementation. Alternatively, a "mapping model" can be used to define how the implementation artifacts of the solution will be organized into projects and folders, and how the design model constructs will map into those projects and folders. See Specifying File Names for the Output of a UML Transformation.

If you are not using automated transformations as part of your MDD approach, then you must take steps to provide the information that is embedded in the automated transformation:

• Additional diagrams
• Notes on diagrams
• Use Profiles
• Use Constraints
• Additional documentation that details the mapping

The tool can also support the need to organize elements in more than one way, in order to accommodate all the stakeholders and their specific perspectives. The solution is to use <<perspective>> packages which separates the organization of the design model elements from the diagrammatic views of the model's content, enabling you to create as many other views as are necessary, views which can reflect orthogonal organizational approaches. In addition with the communication of the design ideas represented in your model, this approach can also assist in helping you to gain a better understanding of the elements that comprise your solution.

For more information, refer to the following white papers for guidance on structuring models:

• Model Structure Guidelines for RSx
• Layering Strategies
• Model Driven Development and Model Driven Architecture

Identify Key Abstractions 

Capture key abstractions in class diagrams with brief descriptions of each class. To do this:

1. Open the Design Model. If you plan on maintaining a separate Analysis Model, then the same kind of information should be also recorded in that model.
2. Navigate to the package containing key abstractions. An alternative is to use a Key Abstractions <<perspective>> package. See Model Structure Guidelines for RSx.
3. Add a class diagram. See Adding Class Diagrams to Model Elements.
4. Add classes to the diagram, stereotyped as <<entity>>. See Creating and Modifying Class Diagrams and Applying Stereotypes to Model Elements.
5. Add a description to each class using the Documentation tab in the Properties View. See Documenting Model Elements.
6. Optionally associate a document with the class: in the Model Explorer, right click the model element to which you want to link a file, and then click Add UML > URL . See Linking Model Elements to External Files.
7. Define any relationships that exist between the classes. See Relationships.
   • Add association relationships.
   • Specify the kinds of association relationships.
   • Add generalization relationships.

For more information, refer to Modeling Static Structure by Using Class Diagrams.

Identify Stereotypical Interactions

This step is included only when performing this activity during inception.

The purpose of this step is to identify those interactions, between key abstractions in the system, that characterize or are representative of significant kinds of activity in the system. These interactions are captured as Use-Case Realizations.

For guidance on creating Use-Case Realizations, see Use-Case Analysis.

When working with iteration diagrams, it is quick and easy to switch between Communication Diagram and Sequence Diagram views:

1. Add either a Sequence or Communication Diagram to your model. This will create the diagram within an owning Interaction.
2. Add model elements to the diagram created as needed, to represent the interaction.
3. To add the companion diagram, right-click on the Interaction and select Add Diagram > Communication Diagram.
4. If you started with a Communication Diagram, the flow is the same, except after right-clicking on the interaction you select Add Diagram > Sequence Diagram.

Develop Deployment Overview

1. Add a deployment diagram to the Deployment Model.
2. Add nodes to the diagram.
3. Use Stereotyped Node from the Deployment drawer in the palette and use one of the predefined types of nodes. Note that most of the predefined nodes have customized graphical representations related to the type of the node.
4. Add associations between nodes.

Additional tips:

1. Use notes and color as visual cues to draw attention to important features of your diagram.
2. Provide details consistent with level of abstraction required. Expose only those adornments that are essential to understanding.
3. 1. Use Delete from Diagram to remove undesired elements from a diagram. This will remove the elements from the diagram but not impact the underlying model.
   2. Use Filters to hide\expose details. Right clicking on model elements in a diagram and selecting Filters can access this.
4. Use elements from the Geometric Shapes drawer to add any additional information that needs to be captured, but is not well represented by elements found in the Deployment drawer.
5. Focus on communicating one aspect of a system's static deployment view. No single deployment diagram need capture everything about a system's deployment view.
6. Use <<perspective>> packages as needed to bring together model elements to provide an additional or alternate view.
7. If more detail and precision is needed for the diagram, use profiles, constraints, notes and the documentation tab to record the information.

Identify Analysis Mechanisms

There are tool features and capabilities that will help in the bottom-up identification of some Analysis Mechanisms through the support for Architectural Analysis (pattern and anti-pattern detection). The RAS repository is a good place for collecting all the potential candidates for reuse. See Creating Software Modeling Artifacts for Reuse and Applying Patterns for a complete view on what are the requirements for packaging reusable assets.

If you have patterns, transformations,models, written guidance or other artifacts that you wish to share and reuse withing the wider organization, RAS can help. It will allow you to search, review, provide feedback and incorporate a reusable asset in a solution. For additional guidance on working with the Reusable Asset Specification and assets that have been packaged using this specification, refer to:

• RAS Assets - RAS Asset to Import/Export 
• Tutorials and Samples regarding importing and exporting RAS assets 
• Packaging Assets for Reuse
• Finding RAS Assets 

As you work through this step, document each analysis mechanism and its clients. There a number of ways in which the tool can assist you in finding and representing 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 how the mechanisms will fulfill their obligations. 

Review the Results

The results of architectural analysis are preliminary and relatively informal; therefore, reviews should be informal as well. It might be helpful to publish any models to html format. Also note that diagrams can be copied to Microsoft Word and other programs.

For more information, refer to Publishing Models and to the Publishing a Model to Web tutorial.

Additional Tool Information

Tutorials:

• Applying a Pattern
• Create a Pattern
• Understanding the UML Model Hierarchy 
• Introduction to the Modeling Perspective

Samples:

• Patterns - Simple UML Model