Compuware OptimalJ: How transformation

WHITE PAPER

patterns transform UML models into

high-quality J2EE applications

1. Introduction 2. OptimalJ and OMGs Model Driven Architecture

Compuware OptimalJ is an advanced enterprise application
development suite that generates complete, working J2EE-compliant
applications directly from a visual model, using sophisticated
transformations to implement accepted best practices for coding to
J2EE specifications. Using a pragmatic implementation of the Object
Management Groups (OMG) Model Driven Architecture (MDA),
OptimalJ helps to simplify J2EE development, enabling architects,
designers and developers to rapidly produce reliable applications.
OptimalJ provides a pragmatic implementation of OMGs Model
Driven Architecture (MDA - http://www.omg.org/mda). MDA
specifications are based on a Platform Independent Model (PIM),
a model expressed in UML which represents business functionality
undistorted by technology issues. MDA-enabled tools transform
the PIM into an extendable Platform Specific Model (PSM) for a
certain target platform (e.g., J2EE). In a subsequent step, the PSM
is transformed into a specific language (e.g., Java).

The three important cornerstones of OptimalJ are discussed in
a series of technical white papers. The cornerstones and a brief
description are presented below:
1. Model-driven development describes how OptimalJ enhances
productivity.
2. Business rules explains how to achieve rapid response to
change.
In OptimalJ, the PIM is named Domain Model and the PSM is
named Application Model. In accordance with MDA, OptimalJ
provides a clear distinction between the models of the domain
and the models of application components. The model-to-model
transformations (i.e. from Domain Model to Application Model)
and model-to-code transformations (i.e., from Application Model to
Code) are implemented in OptimalJ with Transformation Patterns.

3. Patterns describe how transformations are applied to Unified

Modeling Language (UML) models to produce high-quality
J2EE applications.

Before you read our technical white paper series, we encourage you
to gain a general understanding of OptimalJ and its use of MDA by
reading an introduction to OptimalJ at http://www.compuware.com/
products/optimalj/detail.htm

Pragmatic MDA with OptimalJ

The Domain Model in OptimalJ defines the business domain
independent of any specific application and technology detail.
The model is based on the UML modeling standard and consists
of a Class model, a Service model, a Use Case model and a
Process model.
OptimalJ Domain Model
The Application Model is the result of an automated transformation
from the Domain Model. The Application Model is based on a
certain technology (J2EE), but without any coding detail. It describes
the structure and design of the application, by providing a logical
overview of the components contained within each layer of the
application.
>> The Presentation tier contains web components that use data
schemas (i.e., form beans at code level) to exchange data with
the Business Logic tier on one end and the user at the other end.
>> The Business tier consists of EJB-related (3-tier), DAO-related
(2-tier), or a mix between EJB- and DAO-related components.
>> The DBMS tier contains a relational data framework that
consists of tables, columns, keys and other database-related
elements.
2
OptimalJ Application Model
Once the Application Model is in place for the DBMS, Business and
Presentation tiers, the code implementations of defined components
can be generated; i.e., the Java classes, SQL scripts and other
technical items. It is important to note that all code generated by
OptimalJ is compilable and executable code, and adheres to Sun
Microsystems core J2EE patterns1.
3. OptimalJ pattern types
What expert designers know is not to solve every problem from first
principles, but instead reuse solutions that have worked in the past.
In general, patterns are ways to describe these best practicesgood
designsand capture experience in a way that it is possible for
others to reuse and avoid traps and pitfalls. A pattern is not a matter
of discovery. Usually when there is a solution to a certain problem
it can be reverse engineered to a more universal or generic level.
That will result in the pattern. Once you know the pattern, a lot of
design decisions will follow automatically. In addition, patterns also
abstract away from the details and use a terminology which makes it
easier to communicate on a non-ambiguous level. Experts talk about
Delegates and Factories instead of this class does this, that class
does that.
While most patterns are designs on paper, OptimalJ promotes the use
of best practices and good designs by pattern implementations. This
is established by two main categories of patterns: Transformation
Patterns and Functional Patterns.
1 See also OptimalJ white paper Implementing Sun Microsystems Core J2EE Patterns (http://javacentral.
compuware.com/members/downloads/pdf/OJSunpatterns.pdf).
3.1 Transformation Patterns
Transformation Patterns are used to automatically transform the
elements of the Domain Model into the Application Model and
transform from the Application Model into the actual source code.
As shown in the first illustration, the Transformation Patterns are
divided into Technology Patterns (model-to-model transformations)
and Implementation Patterns (model-to-code transformations).
Both patterns are closely related to respectively OMGs Query-View-
Transformations (QVT) and Model2Text (M2T) initiatives.

Technology Patterns
Technology Patterns map the specifications as defined in the
Domain Model to the Application Model level for a specific
technology. In OptimalJ, J2EE-specific Technology Patterns are
primarily used. Technology Patterns are basically rules used for
bridging abstraction levels and transforming one model to another
(Domain Model to Application Model). Technology Patterns do
not generate Java code, but create or update Application Model
elements based on the objects found in the Domain Model.
For example, the transformation of a Domain Class Model to
the EJB model components in the Application Model is defined
by a Technology Pattern. This pattern defines rules that map
DomainClasses to EJBEntityComponents, DomainOperations to
BusinessMethods, and so on. With these mappings, OptimalJ can
create or update EJB model elements based on the objects it finds
in a source Domain Model.
Technology Patterns are OptimalJ modules, so they can be installed,
uninstalled, enabled, disabled or installed in test mode. Technology
Patterns are applied when the Application Model is generated
or updated. The mapping information is saved in pattern nodes.
Every target model element in the Application Model has one or
more pattern nodes. With the information stored in these pattern
nodes, OptimalJ can generate or update a target Application Model
element from a source Domain Model element. This implies that
incremental development is supported because developers can
update the Domain Model and then apply the changes to the target
Application Model over and over again.
Pattern nodes (the gray diamonds in the picture) are used by Technology
Patterns in generating and updating models
The Technology Patterns generate extendable logical components in
the DBMS, Business and Presentation tiers, which are all part of the
Application Model.
>> DBMS components: Generally, a Domain Class in the Domain
Model contains attributes that have to be made persistent.
Technology Patterns in OptimalJ are used to automatically
create the table structure for the database of choice. This results
in an Object-to-Relational mapping with base tables, columns,
primary keys and foreign keys. The architectural logic in the
patterns determines the required elements.
>> Business components: The Business Model always has logical
components for every elementary domain class for which the
attributes have to be made persistent. Technology Patterns are
used to create the definitions of these components based on the
Domain Class definitions in the Domain Model. The Domain
Class definitions are interpreted by the pattern and transformed
into, for example, EJB-specific definitions. There is a tight
relationship between the Business model and the DBMS Model.
If the table is not defined in the DBMS Model, then the EJB or
DAO will not be able to make its attributes persistent. Also, if
an attribute is changed on the Domain Model level, both the
Business component definition and the base table definition
will have to be changed. The logic in the Technology Pattern
determines what changes have to be made in the Application
Model to reflect the changes on the Domain Model level.

3
>> Presentation components: The Presentation Model defines the Domain Patterns are used on a Domain Model level. A Domain
components that are providing services to client components. Pattern is a Domain (UML-class) Model that can be reused. A
OptimalJ, for example, implements web-based client new target Domain Model can be constructed by merging Domain
components, such as Java Server Pages (JSPs) and servlets. Patterns from Domain Pattern libraries. In this way, a new Domain
Technology Patterns not only define the web components in Model can be rapidly constructed based on existing knowledge, like
the Presentation Model, but can also reuse definitions that are a set of building blocks. Domain Patterns are always application- and
already available on the Business Model (i.e., data framework implementation-independent. An example of the use of a Domain
definitions). Pattern is the merging of two existing Domain Classes into one new
Domain Class. By default, all elements of the Domain Pattern are
Implementation Patterns
copied to new elements in the target model. But it is also possible
Implementation Patterns map application specifications as defined
to assign an element from the existing model to an element in the
in the Application Model to compilable and executable code. In
pattern. When the pattern is copied, the element from the pattern
OptimalJ, for example, Java, JSPs, XML and WSDL are used as
is merged with the element in the target model. This technique is
specific implementation languages. Implementation Patterns often
called weaving, extended with some new attributes. Domain Patterns
depend on other Implementation Patterns. The hierarchy of patterns
can be applied using a wizard. After selecting a Domain Pattern
is determined by the logic built into the patterns. For example, the
from the library, a developer specifies how this pattern should be
Implementation Pattern for the Presentation tier depends on the
applied to the target Domain Model. A Domain Pattern is not just a
underlying persistence layer. The underlying technology could be
template with some pre-defined elements, as it allows the assignment
Enterprise Java Beans (EJB), or it could be Data Access Objects
of elements in the existing model to elements in the pattern. This
(DAO), and the Presentation tier would of course communicate
process allows for weaving different patterns and merging a Domain
with these types of objects in different ways. The invocations
Pattern with an already existing Domain Model.
between the several application components and the data exchange
between these components are all transparently generated by the Application Patterns are used on an Application Model level.
Implementation Patterns. Application Patterns follow the same principle as a Domain Pattern,
but now applied on Application Models.
Other examples of Implementation Patterns are the ones that
generate deployment descriptors for the target application server, Code Patterns are used on a Code Model level to describe
and SQL statements needed to query the database. Both make it implementation strategies. An example of an implementation
easy for a developer to immediately test the application from within strategy is the set of patterns described by the Gang of Four2 (GoF
OptimalJ, without the need for complex configuration upfront. patterns, such as ChainOfResponsibility, Decorator, FactoryMethod,
etc.) Code Patterns are closest to the traditional use of code
Like the Technology Patterns, the Implementation Patterns are
templates, as they directly result in the creation of one or a few class
OptimalJ modules, so they can be installed, uninstalled, enabled,
files with pre-defined programming structures. OptimalJ applies
disabled or installed in test mode.
several code patterns when generating code. The developer can
Functional Patterns extend these programming structures to implement the desired
OptimalJ also supports Functional Patterns, which are used at one functionality.
model level to provide productivity improving functionality. For
example, if you have defined two separate Domain Classes in the
Domain Model and you want a new Domain Class that combines
these two, you can reuse their definitions instead of redefining the
new Domain Class. Functional Patterns are targeted to promote
reuse, and as they operate on one model level, there are three types
of Functional Patterns: Domain Patterns, Application Patterns and
Code Patterns.

2 Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable
Object-Oriented Software, (New York: Addison-Wesley) 1994. The authors are collectively known as
the Gang of Four (GoF).

4
3.2 Software Factory Definition 4. Pattern Authoring

As already explained, since the Technology Patterns and With the OptimalJ Architecture Edition, software architects have the
Implementation Patterns are OptimalJ modules they can be installed, option to create and modify Technology Patterns, Implementation
uninstalled, enabled, disabled, or installed in test mode. As such, Patterns and Metamodels. Customization of Transformation Patterns
OptimalJ provides a pluggable pattern architecture. This implies is an extremely powerful functionality in OptimalJ, since it provides
that a software team working with OptimalJ can define their own full control to architects to influence the architecture and the code
Software Factory by making an agreement on which Transformation generated by OptimalJ. In that sense OptimalJ is not a black box
Patterns to use for model and code generation. To be able to repeat code generator that forces architects to use elements of some out-of-
the model and code generation phase, meta-information is required the-box architecture. In this section we will explain how OptimalJ
about which Transformation Patterns were used originally. To protect helps to evolve the architecture over time.
developers from using an incorrect set of Transformation Patterns,
OptimalJ provides a Software Factory Definition (SFD) file. This 4.1 OptimalJ Metamodel
keeps meta-information about the Transformation Pattern modules
OptimalJ provides a set of model types, such as the Class model
in a central place. The SFD is maintained by OptimalJ, and contains
and the EJB model, which can be used to develop J2EE applications
the names and versions of all relevant Transformation Pattern
using MDA. In addition, OptimalJ provides a set of Metamodels that
modules. At the start of each model or code (re)generation the SFD
define the model types that it supports. The OptimalJ Metamodels
is checked. A warning appears when there is a mismatch between
provide an abstract view of the Domain and Application
the Transformation Pattern modules or module versions specified in
Models (e.g., an EJB Metamodel describes the EJB model type).
the SFD file and those which are being used.
Transformation Patterns extract model information from the
OptimalJs pluggable pattern architecture helps to dramatically Metamodels, and use this information to create a new artifact (e.g.,
reduce the cost of upgrading to new technologies. A good example unit of code).
of this is the upgrade from EJB 2.0 to EJB 2.1, where EJB 2.1
OptimalJ uses the Meta Object Facility (MOF) modeling language
introduces a number of new features. With OptimalJ, architects are
developed by the OMG for defining Metamodels. The MOF
able to install the EJB 2.1 pattern, making sure that designers and
provides a standard repository for models and defines a structure that
developers are using this pattern. At startup, OptimalJ will detect
helps multiple groups work with and view the model.
that the repository is based on an EJB 2.1 pattern and that there
is a new pattern installed. As such, the application that will be
regenerated implements a number of EJB 2.1 features automatically.
All custom code in the free blocks will be preserved.

Software Factory support

5
With the OptimalJ Architecture Edition, users can use OptimalJ to
define any Metamodel that they desire and, in addition, define the
related Transformation Patterns, enabling complete control over the
output generated.
OptimalJs repository API allows architects to access the Metamodel.
The repository API is derived directly from the OptimalJ
Metamodels. The API is exposed in the OptimalJ user interface,
where API names and types are displayed in the Explorer and
property sheet views. Metamodel elements provide an Explore
All Features option, which displays all their attributes, including
all attributes inherited from super classes. Users can explore the
repository by using the package tree view or the Meta Class Diagram
for a graphical view. In general, architects only need to use the
interfaces provided; they never need to be concerned with how the
repository is actually implemented.
4.2 Template Pattern Language
OptimalJ provides the Template Pattern Language (TPL), a small
language set which is tailor-made for developing Implementation
Patterns. TPL is designed to simplify writing Implementation Pattern
code and is geared to translate models to syntax-based languages.
TPL is currently used for generating artifacts such as Java, JSP, XML
WSDL, SQL and deployment descriptors from the Application
Model. TPL code is compiled into Java classes which are then added
to OptimalJ as an Implementation Pattern module.
To get a better understanding of the TPL, an analogy can be made
with Java Server Pages (JSP). Originally, Java Servlets were used to
generate HTML code. This proved to be a tedious process, as the
HTML had to be painstakingly implemented as HTML fragments
in Java code. HTML specialists could not contribute, because the
The OptimalJ Metamodel: Tree view and MOF Class Diagram.
6
process relied on Java coding. HTML tools could not assist, because
the HTMLs structure was disrupted by the Java code. Java Server
Pages reversed this problem, by generating the required Servlet
from an HTML file, with the code required for the Servlet added in
escaped blocks, or in custom tags. Now the HTML code could be
developed using normal HTML tools, and could be inspected more
easily. The standard Servlet code could be generated invisibly.
TPL provides the same benefits for code generation for any language,
not just HTML. TPL can be used to write files predominantly in
the target language, with flexible techniques to interact with model
features. TPL allows users to use a range of escape characters, to flip
between escaping the TPL or escaping the target code, and hides a
large amount of the code required for code generators under simple
TPL statements. The TPL is a template-based language. Templates
consist of a declaration and a body. The declaration specifies the
templates name and the list of parameters that the template accepts.
The body contains skeleton code, loops and conditional statements,
and calls to other TPL templates. TPL provides a small set of
statements. The statements provide flow control and skeleton-code
generation facilities. Interactions with the API and expressions are
expressed using Java syntax instead.
TPL enables architects to create the skeleton code of a generated
application using the same syntax and structure as the target code
itself. TPL communicates with the Metamodel repository API
used by OptimalJ, allowing architects to use features of the API
declaratively. For example, creating a new guarded or free block only
involves using the statements GUARD and FREE. The TPL hides
the complexity of these APIs, so the architect can focus on building
the Implementation Pattern.
Sample TPL source, which generates JSP and related code for a web
component.

OptimalJ includes a TPL Editor, which is a text editor that features
syntax highlighting, code completion, free and guarded blocks,
bookmarks, search and so on. The TPL Editor displays errors
reported by the TPL compiler, allowing architects to navigate from
the error to the offending line in the TPL code. The TPL Editor also
reports errors in Java code generated from the TPL code. Architects
can navigate from this to the offending line in the generated Java
code, but they should fix the error in the TPL file, not the Java file
itself.
The use of TPL for implementing or customizing Implementation
Patterns is not mandatory. TPL is compiled into a Java file. People
who prefer to use the Java language instead may go for this option,
but it will take much more time.
Points and replace these files with files of their own designs, or
insert code from their own patterns into files created by OptimalJ.
This implies that architects can extend OptimalJs patterns, but also
override the functionality.
Join Points consist of a definition, an invocation and an
implementation. The definition and invocation of a Join Point is
typically located in one pattern, while Join Point implementations
are located in contributing patterns. Architects must preserve the
contract fulfilled by the original file, which must provide the same
interface to the rest of the application. This ensures that when
Compuware delivers newer versions of these patterns, the Join Points
will be stable and thus will work with the custom-built patterns.

4.3 Join Points

With the OptimalJ Architecture Edition, architects have the option

to create their own Transformation Patterns. Since we assume that
they do not necessarily want to write their patterns from scratch,
they can take OptimalJs default Implementation Patterns and
customize them. When companies change these patterns, however, it
will become difficult for them to upgrade to newer OptimalJ versions
of the Implementation Patterns and easily benefit.

For this purpose OptimalJ contains a solution called Join Points.

Join Points define the parts of an Implementation Pattern where
other patterns are allowed to influence the output. The OptimalJ
Implementation Patterns provide a large number of Join Points
for each file generated. Each Join Point is documented with the
description of its purpose, fully qualified name, file type and links.
Join Points allow architects to create their own pattern extensions
and hook them into OptimalJs default Implementation Patterns.
For example, there is a Join Point defined for each interface and
class file generated for EJBs. Architects can implement these Join The Implementation Pattern on the left requires code from the patterns
on the right.

7
4.4 Pattern Plaza 5. Conclusion

JavaCentrals Pattern Plaza (http://frontline.compuware.com/
javacentral/pattern_plaza/default.asp) aims to promote the
development of OptimalJ Transformation Patterns and stimulate
collaboration amongst developers to exchange knowledge on how
to build OptimalJ patterns and share OptimalJ pattern sources.
Pattern Plaza consists of two main components, a Catalogue for
searching and exchanging OptimalJ Pattern sources and a Forum for
exchanging information amongst developers on the dos and donts
with regards to pattern authoring.
There are three assets that make up OptimalJ: Metamodels,
Technology Patterns (model-to-model transformations) and
Implementation Patterns (model-to-code transformations).
With the OptimalJ Architecture Edition, architects can create,
extend or replace the Metamodels, Technology Patterns and
Implementation Patterns that ship with the product, making
OptimalJ an open and flexible environment, enabling complete
control over the output generated.
The pluggable pattern architecture enables development teams to
enhance OptimalJs model and code generation capabilities in a
modular way. Architects can build a Software Factory upon this
pluggable architecture, that is, a factory to produce models and code
from high-level model definitions enforcing the use of best practices,
standards and guidelines.

To learn more about OptimalJ, visit

www.compuware.com/optimalj

Compuware products and professional servicesdelivering IT value

Compuware Corporation (NASDAQ: CPWR) maximizes the value IT brings to the business by helping CIOs more effectively manage
the business of IT. Compuware solutions accelerate the development, improve the quality and enhance the performance of critical
business systems while enabling CIOs to align and govern the entire IT portfolio, increasing efficiency, cost control and employee
productivity throughout the IT organization. Founded in 1973, Compuware serves the worlds leading IT organizations, including
95 percent of the Fortune 100 companies. Learn more about Compuware at www.compuware.com.

Compuware Corporation Corporate Headquarters

One Campus Martius
Detroit, MI 48226
For regional and international office contacts, please visit our web site at www.compuware.com

All Compuware products and services listed within are trademarks or registered
trademarks of Compuware Corporation. Java and all Java-based marks are trademarks or
registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
All other company or product names are trademarks of their respective owners.
2006 Compuware Corporation 5/06