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:
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:
Create a new Java project and add references to libraries
Open the diagram that you wish to add the visualized element
Switch to the Java Perspective
Find the element (package, class, interface, etc.) that you wish to add your model
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.
The following is a sequence of steps that will help you adjusting the implementation subsystems:
Identify subsystems causing issues, for example cyclic dependency, using:
Topic and browse diagrams
Code Review / Structural Code Analysis
Create a new subsystem
Move the identified elements to the new subsystem
Draw new dependencies
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
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).
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.
A key consideration that will impact the structure of your test assets will be the decision as to how you create your
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
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.
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.
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
For more information, refer to Publishing Models and to the Publishing a Model to Web tutorial.