Tool Mentor: Outlining the Component Model Using Rational Software Development Platform. |
This tool mentor describes how to perform architectural analysis using the IBM Rational Software Delivery Platform modeling environment.
Tool: Rational Software Architect
Relationships
Related Elements | Outline Component Model
Main Description
### Overview This tool mentor assumes that a set of structured models has already been created, in accordance with the Model Structure Guidelines for Rational Software Architect or Rational Software Modeler. 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. ### Survey Available Assets Note: some of the tool capabilities mentioned in this section are not supported in Rational Software Modeler. 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. Identify Transformation Requirements The tool can be used in three 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 an solution, and from which additional details can be automatically generated, using model-to-model and model-to-code transformations. 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 or 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 six steps to guide you: Create a transformation plug-in project Specify type of Source and Target Model Specify Applicable Profiles Add rules to the transformation Implement transformation specific behavior 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: Create a new pattern that works in conjunction with the existing pattern Update the pattern so that it does suit your needs Use the existing pattern as a blueprint or sample as you build a new pattern that better fits your needs Refer to the help category Extending [Rational Software Architect, Rational Software Modeler, or Rational Software Developer] functionality. If you decide to create your own pattern, use the following six steps to guide you: Create a pattern library Add a pattern to the pattern library Add template parameters to the pattern Specify dependencies between template parameters Implement pattern specific behavior 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. There is also a tutorial titled: Creating Architectural Control Rules and Reviewing the Architecture of an Application from which you can get a better understanding of some of the automation features in the tool to evaluate existing assets. Check developerWorks for Assets The Rational Technical Library on the IBM developerWorks Web site 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, which provides 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 Your decisions about how the solution will be organized into components, services, and subsystems are captured in the design model (for example, an EIT Design Model), and based upon architectural considerations such as: 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 of the stakeholders and their specific perspectives. The solution is to use <<perspective>> packages, which technique separates the organization of the design model elements from the diagrammatic views of the model's content. This enables 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. ### Identify Key Abstractions Capture key abstractions in class diagrams with brief descriptions of each class. To do this: 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. Navigate to the package containing key abstractions. An alternative is to use a Key Abstractions <<perspective>> package. Add a class diagram. See Adding Class Diagrams to Model Elements. Add classes to the diagram, stereotyped as <<entity>>. See Creating and Modifying Class Diagrams and Applying Stereotypes to Model Elements. Add a description to each class using the Documentation tab in the Properties view. See Documenting Model Elements. 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. 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. When working with iteration diagrams, it is quick and easy to switch between Communication Diagram and Sequence Diagram views: Add either a Sequence or Communication Diagram to your model. This will create the diagram within an owning Interaction. Add model elements to the diagram created as needed, to represent the interaction. To add the companion diagram, right-click the Interaction and select Add Diagram > Communication Diagram. If you started with a Communication Diagram, the flow is the same, except after right-clicking the interaction you select Add Diagram > Sequence Diagram. ### Develop Deployment Overview Add a deployment diagram to the Deployment Model. Add nodes to the diagram. 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. Add associations between nodes. Additional tips: Use notes and color as visual cues to draw attention to important features of your diagram. Provide details consistent with the level of abstraction required. Expose only those adornments that are essential to understanding. Use Delete from Diagram to remove undesired elements from a diagram. This removes the elements from the diagram, but does not impact the underlying model. Use Filters to hide or expose details. Right-clicking model elements in a diagram and selecting Filters can access this. 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. 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. Use <<perspective>> packages as needed to bring together model elements to provide an additional or alternative view. 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 of 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 within the wider organization, RAS can help. It will allow you to search, review, provide feedback about, 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 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 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
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.