OptimalJ Review
Part 1: MDA Transformations

Introduction

The OMG introduced the Model Driven Architecture (MDA) as a response to continuous technology change in the software development market. The fundamental premise of MDA is that a business application may be modeled using the UML, and then a significant portion of the actual implementation may be generated automatically by transforming the models into code. The advantage of this approach is that applications may become immune to underlying technology changes, which are occurring all the time.

The long-term dividends of the MDA approach could be applications which have lifespans as long as 20 years according to the OMG, much longer than the lifespan of any underlying technology. How much of this claim is mere hype and how much is realizable is open to much lively debate on internet discussion forums.

However, without an understanding of what an MDA tool does, and how well it does it, it is very hard to assess the potential of MDA. To answer this question, we set out to evaluate one of the leading MDA tools on the market - Compuware's OptimalJ (OJ), version 3.1. What we found is a very sophisticated product with both built-in technology pattern transformations for the J2EE platform as well as tools for creating new transformation patterns or for customizing existing ones.

In the first part of this review we will take a look at the MDA technology in OJ, while the second part will focus on out-of-the-box transformations supported by the tool.

The Netbeans Platform

OJ is built on top of the popular Netbeans integrated development environment (IDE), an open source product which is at the foundation of Sun Microsystems' tool platform. In addition, OJ is bundled with three popular open source products for web development: the JBoss EJB server, the Apache Tomcat servlet engine, and the Apache Axis web services engine.

The overall performance of OJ in this environment was found to be very good and OJ provides an exceptionally smooth integration with these other web development products. Although 1 GB of memory is recommended, OJ used approximately 350 MB of total memory during normal operation and could actually run on a machine with only 512 MB, a real feat considering the amount of functionality included in the tool.

Netbeans competes directly with the Eclipse IDE, which has a lot of traction in the Java development market. Compuware has addressed the Eclipse market by providing a plugin for Eclipse, which may be used by developers who receive the J2EE output from the Architect Edition, and are completing the development with custom code. We anticipate that Compuware will provide additional integrations with Eclipse over time.

MDR, MOF and XMI

A cornerstone of the OJ architecture is the Netbeans Metadata Repository (MDR). MDR implements the OMG's Meta-Object Facility (MOF) standard to provide a metadata repository. The metadata stored in the repository describes one or more UML models. MDR supports the import and export of model information using XMI 1.2, the OMG standard for representing a UML model in XML, so UML models developed in other modeling tools may be imported into the Repository. Although OJ does provide its own support for creating UML class diagrams, a primary feature of the tool is its ability to import XMI models into MDR from such leading tools as Rational XDE, Borland Together and Sparx Systems Enterprise Architect.

The Repository API

MDR provides support for programatic access to the modeling information in the Repository through the Java Metadata Interface (JMI), which is a Java standard. However, OJ was developed before JMI became a standard, and therefore provides its own Repository API as well.

In addition, OJ adds a significant amount of metadata to the Repository to support the classes that it uses in the MDA transformation process. As we will see further on, OJ extends many of the classes in the OMG's org.omg.uml.foundation.core package in order to provide a richer environment for performing MDA transformations. There exist several ways in which to introspect the contents of the OJ Repository to facilitate the use of the Repository API, also described below.

ModelDoc: Display a Model

The best starting point to learn how OJ supports the MDA paradigm is with the ModelDoc tutorial which comes with the Architecture Edition. ModelDoc transforms a model into HTML documentation in a manner very similar to the way in which JavaDoc transforms Java code into HTML documentation. The following screen shot shows a sample output from ModelDoc for the Customer class in the CRM sample model (used in many of the OJ tutorials).

As part of our testing, we added two methods in the Domain Model on the Customer class, getFullName and setPreferred. We then ran the ModelDoc transformation, which produced the HTML documentation seen in the screen shot.

A transformation is basically the process of extracting model information from the MOF Repository and using this information to create a new artifact, for example a unit of code in a language like Java or HTML. ModelDoc, like all of the transformations performed by OJ, is implemented using the Template Pattern Language (TPL). TPL provides a high-level code template and scripting environment, similar to the Velocity Template Language. Template languages allow code fragments in the target language to be interspersed with scripting code. The scripting code is used to provide control flow and variable substitutions in the template.

We will look closely at how ModelDoc performs several representative transformations and see right away how well this paradigm, which is at the heart of MDA, works.

However, without understanding what is available in the MOF Repository, it is impossible to begin performing transformations. The problem is that the Repository is a complex web of information, requiring both good documentation as well as powerful navigational tools in order to be able to explore all the MOF elements and attributes available for transformations.

There are three primary tools for deciphering this complex web of information - the Meta Model Explorer, MOF UML diagrams, and the Repository API documentation provided as JavaDoc. We will see how well each of these tools provides documentation for the elements in OJ's MOF repository.

The Explorer

The Explorer contains a Meta Model pane which provides a hierarchical tree navigation tool for exploring the structure of the MOF Repository. The Meta Model pane in the following screen shot shows the DomainOperation class in the DomainClasses package. Under the DomainOperation node, the attributes and methods for this class are shown. In the ModelDoc template, two of these methods are used to display information about an operation: 'returnType' and 'parameter', as seen in the following TPL fragment:

  [FOR(DomainOperation oper IN domainClass.feature)]
    <tr>
     <td>[oper.name]</td>
     <td>
      [IF(oper.returnType != null)]
       [oper.returnType.name]
      [ELSE]
       VOID
      [/IF]
     </td>
     <td>
     <td>
      <code>
      [FOR( DomainParameter dp IN oper.parameter : 
	      (dp.kind.value() != 3) )]
       [dp.type.name]  [dp.name]  :  
	      [RETURNTYPE( dp.kind )] <br />
      [LAST]
       [dp.type.name]  [dp.name]  :  
	      [RETURNTYPE( dp.kind )]
      [/FOR]
      </code>
     </td>
    </tr>

What we quickly found out is that many of the classes in the Repository have rich inheritance hierarchies, and that there is a real need to discover all of the attributes and operations that are accessible from any class. For instance, the attribute 'name' is used in the ModelDoc script to get the name of an operation. Where does this attribute come from and how would one discover this information?

Fortunately, OJ does provide this information in a single viewer. Right clicking on the class and selecting the Explore All Features menu option displays a complete list of all the accessible attributes and operations. In order to see which superclass contains an attribute or operation, click on the name in the popup list and then the Properties pane (underneath the Explorer pane) identifies the container, as seen in the following screen shot. You can see that the attribute 'name' is highlighted in the list of all features, and the Properties pane shows that the container for this attribute is Foundation.Core.ModelElement.

Repository API Documentation

OJ comes with detailed documentation for the full Repository API in the form of JavaDoc HTML pages. These pages greatly facilitate the exploration of inheritance relationships and other associations between the MOF classes.

A search for the 'name' attribute on the DomainOperation JavaDoc page reveals that there is actually a method on the interface org.omg.uml.foundation.core.ModelElement with the signature 'getName()', and clicking on the hyperlink for this method takes you right to the method description in the ModelElement interface. This also highlights an interesting aspect of the Repository API - access to all attributes is provided through the Java Beans pattern of prefixing the attribute with the 'get' prefix to form a method name for accessing an attribute. Hence, 'getName()' returns the value of the 'name' attribute. Since most of the MOF classes are implemented as Java interfaces, which by definition may not have attributes, getters are required anyway.

From the following screen shot of the API documentation, you may also see that DomainOperation actually has a rich inheritance hierarchy, including several interfaces in the org.omg.uml.foundation.core package: such as ModelElement, Feature, BehavioralFeature, and Operation.

The API documentation, because of its effective use of JavaDoc HTML and hyperlinks, provides a more powerful tool for exploration of the MOF Repository than the Explorer. However, it is less integrated with OJ itself. If there were a way to jump to the JavaDoc API documentation for an element in the MOF Repository from the Explorer, that would combine the advantages of each tool.

Using Diagrams Effectively

OJ also provides the ability to generate useful UML diagrams in order to facilitate the visualization of the entities in the MOF Repository and their relationships. To create a UML class diagram for an entity in the repository, select the Meta Model tab in the Explorer pane, select a package, such as DomainClasses, and right click to view the popup menu. On the popup menu, select the first option, Show MOF Class Diagram, and OJ will create a class diagram containing all of the classes in the package, automatically laid out on the screen.

These diagrams are useful to begin seeing the associations between the MOF classes. Notice from the screen shot that a superclass of the DomainOperation class is displayed, called OptimalOperation. OJ allows you to visually explore the inheritance hierarchy of any MOF class by selecting the class, right clicking to bring up a popup menu, and selecting the option Show Superclasses.

Often, the resulting MOF diagram may be large. To assist in navigation, the Explorer pane includes a Diagram Thumbnail View. This tool allows the user to move a viewport rectangle over a miniature view of the entire diagram in order to select the area of interest, which is then shown in the full diagram. The viewport rectangle may be resized as well, providing a zoom capability. Alternatively, the zoom percentage may be set by selecting a value from a dropdown at the top of the diagram viewer.

In order to capture a diagram for use outside of OJ, you may export the diagram using either PNG or SVG formats. SVG export is an advanced feature, so we were pleasantly surprised to find this supported. SVG is a scalable vector graphics format which is supported in browsers through the use of plugins. Since some of the Meta Models are large, SVG can provide powerful navigation for diagrams saved in this format, without requiring OJ to be running.

TPL: OptimalJ's Template Language

Analyzing the ModelDoc TPL fragment looked at earlier, which presented information about methods on a class, several of the key features of this template language can be seen. The fragment begins with a FOR loop, which outputs information for each of the operations on a class:

  [FOR(DomainOperation oper IN domainClass.feature)]

The first thing to notice is that all TPL control statements are surrounded by square brackets [ ]. This distinguishes control statements from the actual text which will be sent to the output file. In the case of this TPL script, HTML elements are output.

The FOR loop allows a variable with the name 'oper' to be bound to each instance of a DomainOperation object in the feature list for a domain class. FOR loops highlight a nice feature of TPL - that objects within collections are typed. This allows an iteration over the collection to identify a subset of elements within the collection on which to perform transformations. Another example of this is the FOR loop to output the attributes on a class:

  [FOR(DomainAttribute attr IN domainClass.feature)]

The next aspect of TPL to notice is how it functions as a template language. This is accomplished simply by allowing all text not included in square brackets to be sent to the output unchanged, while expressions inside brackets are evaluated first, and then the result is sent to the output. For instance, the following line is used to output the name of a class as a cell in an HTML table:

   <td>[oper.name]</td>

As we saw earlier, the DomainOperation held by the variable 'oper' has a 'name' attribute in one of its ancestors which is accessed through the Java Beans getter method 'getName()'.

One more aspect of TPL seen in our code fragment is control-flow. Here, the return type is output if the operation has a return type; otherwise the value VOID is output.

   <td>
    [IF(oper.returnType != null)]
     [oper.returnType.name]
    [ELSE]
     VOID
    [/IF]
   </td>

TPL has a number of additional features beyond our scope, but this small example shows how the Repository API is combined with the TPL to provide a powerful transformation framework with a wide range of expression.

TPL: What is Missing

Now that we have seen the extensive amount of modeling information accessible through the Repository API, and how this information is transformed through TPL, the question is: How well are these two integrated?

One of the most useful features of integrated development environments today is the ability to assist the developer to find the methods and attributes available on a class when the class is used in the code. For instance, after typing the name of a reference to a class, a dropdown including all the methods on the class may be shown to allow a developer to simply select from the list. The current version of OJ provides a basic text editor for entering TPL scripts and this feature is clearly missing.

It would greatly assist the developer if the list of accessible methods for each interface in the Repository API were shown as a dropdown list inside the editor after a period was typed following a variable. This is one of our top recommendations to Compuware for enhancing the ability to write TPL scripts. Fortunately, we were shown a preview of this feature, promised for the next version of OJ. So this level of integration is definitely a priority for Compuware.

Initial MDA Assessment

Our first assessment of OJ's support for MDA is very positive, based on what we've seen of the MOF Repository and TPL.

Summarizing what we've seen of the product so far, OJ provides:

Good Product Integration - integrates very well with Netbeans, Tomcat, JBoss, and Axis.
Rich Repository API - provides an excellent implementation of the MOF using the Netbeans MDR and adds a substantial number of MOF classes of its own to facilitate the creation of MDA transformations.
Very Good Explorer and Diagrams - the Explorer provides powerful navigation for the Meta-Model classes and the UML diagrams give good visual feedback on the relationships between these classes.
Sufficient Template Support - TPL provides a fully functional, easy-to-use and intuitive template and scripting environment. However, the TPL development environment would benefit from better integration with the Repository API. This feature is forthcoming in the next release of OJ.
Strong Performance - makes very good use of memory and performs difficult tasks, such as the creation of large diagrams, with very good performance.

Part 1 this review has focused on the MDA framework provided by OJ. In Part 2 of this review, we will explore how well OJ exploits this framework to implement the MDA paradigm for J2EE development, including support for EJB's, J2EE Patterns, data modeling, and Web Services.

OptimalJ Review Part 1: MDA Transformations