Overview

This tool mentor assumes that you have defined the top level structure of your Implementation Model as described in the Model Structure Guidelines for RSx. The steps in this tool mentor permit this initial structure to be refined.

The following steps are performed in this tool mentor:

• Establish the Implementation Model Structure
• Adjust Implementation Subsystems
• Define Imports for Each Implementation Subsystem
• Decide How to Treat Executables (and Other Derived Objects)
• Decide How to Treat Test Assets
• Update the Implementation View
• Evaluate the Implementation Model

Establish the Implementation Model Structure

The recommended approach is MDD - Model Driven Development (see Model Driven Development and Model Driven Architecture). If this approach is followed by the development team, the Implementation Model is strongly driven by the organization of the Design Model. As Implementation Subsystems are identified, they should be modeled as packages or subsystems in the Design Model. Generally speaking, when you identify the packages in the Design Model, you should be considering how those will map to tool specific projects. Larger subsystems typically map to their own projects, finer-grained packages typically map to source folders within projects. Refer to the sections of the Model Structure Guidelines for RSx that discuss Project Structures and the internal organization of the Implementation and Design Models.

The Implementation View could be defined by using <<perspective>> packages, containing diagrams which show dependencies between the subsystems. Depending upon what kind of transformation is applied to the Design Model, the dependencies you define among the packages/subsystems might map to 3GL import declarations and project dependency declarations in the project metadata.

Once code has been generated, more detailed UML diagrams could be produced, showing the implementation-level constructs and their relationships, by creating Class Diagrams directly in the projects and populating them by dragging implementation artifacts onto them. Refer to online Help topics related to the UML Visual Editor for Java.

If you require references to specific classes, interfaces, packages, etc. from a code library to be represented in you implementation model you can use the code visualization capabilities of the product to create those representations. The following jar files contain files that may be of interest to you as you design and develop J2EE applications:

• j2ee.jar, jsf-api.jar, soap.jar, soap-sec.jar (all under the lib directory)
• core.jar, xml.jar, security.jar (all under java\jre\lib directory)

When you need to reference an element from one of these libraries in your model, perform the following steps:

1. Create a new Java project and add references to libraries
2. Open the diagram that you wish to add the visualized element
3. Switch to the Java Perspective
4. Find the element (package, class, interface, etc.) that you wish to add your model
5. Right-click on the element and select Visualize > Add to Current Diagram

If there is a need to represent the actual projects and packages in which you expect the code and related files to reside, prior to any code generation, an Implementation Overview Model might be useful. For more information, see the Implementation Model related topics in the Model Structure Guidelines for RSx white paper.

Adjust Implementation Subsystems

The following is a sequence of steps that will help you adjusting the implementation subsystems:

1. Identify subsystems causing issues, for example cyclic dependency, using:
2. • Topic and browse diagrams
   • Architectural Discovery
   • Code Review / Structural Code Analysis
3. Create a new subsystem
4. Move the identified elements to the new subsystem
5. Draw new dependencies 

Define Imports for Each Implementation Subsystem

In an MDD environment, the dependencies in the Implementation Model will mirror very closely the ones defined explicitly or implicitly in the Design Model. The specifics are determined by the code generation transformations applied to the Design Model.

In addition to the input model, there are other artifacts that are necessary to perform a transformation. A transformation process requires a transformation definition and its transformation rules.

A transformation rule provides a description that the transformation process uses to convert one element in the source model to zero or more elements in the target model. Specifically, it maps elements from one level of abstraction to its more detailed counterparts at a lower level of abstraction.

If you are using manual transformation – you will need to ensure that you are providing sufficient guidance to your developers as they transform the design model to code. In essence, you need to provide a transformation definition, which includes a set of transformation rules. This additional guidance can be in the form of:

• Elements from documented profiles
• Notes in the model
• Additional information in the Software Architecture Document
• Development Guidelines

If an Implementation Overview Model is used, this will be the place to show the anticipated dependencies among the projects and packages, which can prove helpful in identifying system build requirements (see Model Structure Guidelines for RSx).

Decide How to Treat Executables (and Other Derived Objects)

In an MDD environment, depending upon what kind of transformation is applied to the Design Model, various types of deployable artifacts might be generated. For example, from elements such as <<control>> and <<entity>> classes, session and entity EJB might be generated for a J2EE target, including: the code for the implementation classes plus the interfaces plus deployment descriptor content that allocates the EJBs to EJB JARs and maps those JARs to EARs.

You can choose to model deployable artifacts at the conceptual level, using a deployment model. If you choose to do so, you will model them using UML nodes and artifacts. At the current time, the transformations packaged with the tool do not leverage the semantics of such diagrams to generate deployment data, so your diagrams will be purely conceptual and useful only as documentation.

Optionally, you could also depict actual implementation artifacts in such diagrams by dropping them onto the canvas and connecting them (using dependencies) to the conceptual elements of the diagram.

Decide How to Treat Test Assets

A key consideration that will impact the structure of your test assets will be the decision as to how you create your test assets.

You can choose to use the Automated Component test capabilities to create your tests. If that is the case, then one or more separate test case projects are set up for you as part of the creation process. One key benefit of using this feature is that you can utilize an initial code generation and use the stubs of the code to drive the test case creation.

Keep the project repository organized as a set or hierarchy of directories. It is recommended that the test assets be kept in separate test directories segregating the different types of test; unit test, integration test, system test.

Update the Implementation View

If there is a separate Implementation View, it must be maintained. The general recommendation presented in the Model Structure Guidelines for RSx white paper is to use the <<perspective>> packages, containing diagrams which show dependencies between the subsystems.

Evaluate the Implementation Model

You want to make sure that your subsystem dependencies (and other dependencies) continue to follow best practices as the system evolves. To this end, use Architectural Discovery, Code Review in general and Structural Analysis in particular to verify that the models are following best practices.

As mentioned earlier, you may also want to take time to introduce custom rules that can be used to enforce the dependencies that you have identified. During the manual portion of the review, you will want to make note of any rules that have not yet been developed and add them into the set of rules for the next iteration.

It can be helpful to publish 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.