Columns

Product Review: Optimal Java

• By Richard Seegmiller
• March 1, 2004

Compuware OptimalJ 3.1
Compuware Corp.
Detroit, Mich.
(800) 521-9353
www.compuware.com

Rating: 4 out of 5

My company, Micro-News Network, used OptimalJ 3.1 to develop a standalone app for sale to customers. This project required the app to scale to enterprise-level systems in a service offering. We faced a tight delivery schedule and evolving refinements to the requirements. We needed a development framework that would let us modify the underlying data model and express it in usable code without significantly impacting previous development.

We concluded that Java, and J2EE, would give us the scalability and portability we needed to develop an app that would run on standalone PCs through enterprise systems on Solaris and Linux. We chose OptimalJ because it would allow us to build our app using principles from MDA. From those data models, we could generate the basic code necessary to support the model.

We had experience with various languages, Unix systems administration, and three-tier Web and firewall services, but little experience with Java development or J2EE frameworks, so we purchased OptimalJ with five man-weeks of consulting to help get us up to speed. It was a fairly steep onramp to learn how to use the product.

Installation was straightforward, but a little time-consuming. Components bundled on the OptimalJ CD include the OptimalJ 3.1 dev tool, as well as the optional Dreamweaver 4.0, the JBuilder plug-in, the IBM WSAD plug-in, the SunONE plug-in and the FlexLM license manager.

Once the Sun JDK 1.4.1_03 is installed, the setup program runs and takes a few minutes; additional configuration to set up the solid database license, the OptimalJ license, and the OptimalJ user directory and project workspaces took about two hours. The licensing process uses FlexLM technology, and both fixed-seat and floating licenses are available. The installation of the bundled Dreamweaver software took only a few minutes.

OptimalJ uses the modeling layers defined by the OMG, including: the Domain Model, the Application Model and the Code Model. The typical approach and methodology for software development begins with the definition of the data elements involved, also known as the data model. Next, the functions to operate on those data elements are defined, followed by business logic. The programmer then maps these data models, functions and business logic to the chosen language and/or technology framework. But the traditional programmer may not use such a structured approach, and this is where many problems arise -- and it is where the real value of OptimalJ can be seen.

The OptimalJ development framework enforces the definition of the data model and functions, followed by the development of use cases and business logic. Additional coding is required to enforce business logic, create use cases and define navigation. But in total, OptimalJ produces about 60% to 80% of the code.

After the initial setup of a new project in OptimalJ, you define your data model in a Model View using a graphical editor. Each box in this view represents a class. Solid lines between boxes represent associations between classes. Arrows (not shown) between boxes represent a sub-class relationship of a super-class. Each class may have a collection of attributes. When the model is transformed to a J2EE implementation, these attributes are represented as fields in data objects.

The Model View layer is also where you define the services that will operate on the classes. These services are represented as methods when the model is transformed to a J2EE implementation.

With the data model and services defined in the Domain Model view, the DBMS, EJB and Web tiers need to be created. Doing this in OptimalJ is an uncomplicated process. You apply transformations from the Domain Model to the Application Model to the Code Model.

With the data model and services defined in the Domain Model view, all that is required to create the Application Model class and service patterns for the EJB and Web tiers is a mouse click. To update the Application Model with these classes and service patterns, switch to the Application Model view and click through. A few more clicks generate the code for the Code Model. In the Code Model view, a few more clicks compile the code. At this point, all the Java 2 code is created for the various tiers in the J2EE model, and a default user interface and Web browser navigation is complete.

To create the DBMS, start the database engine, then select from the OptimalJ menu to generate the DBMS from the Domain Model. This action generates SQL code to create, drop and initialize tables in the target database. Switch to the Code Model view, select the target database meta-model and start the SQL Workbench. This tool allows you to create, drop and/or initialize SQL scripts and apply them to the database. Choose CREATE in the SQL Workbench and ExecuteBatch to create all the tables as defined by the Domain Model.

With the DBMS, EJB and Web tiers created, the EJB and app servers need to be started. From the Code Model view it is simple to select the EJB folder and start the EJB server. To start the app server, navigate in the Code Model view to the mount point for the Web tier. The MainMenu.jsp file is selected and the app server started. By default, the Tomcat/Apache server is used.

Next, a Web browser appears and presents the default user interface as created by OptimalJ. Through this default user interface, all the capabilities to Create, Read, Update and Delete records and assign associations, as defined by the Domain Model, are available. The developer can now define the presentation and the navigation for the app, and apply the required business logic to the app framework.

We did have a few problems with the tool. We ran into occasional corruption or confusion in the UserDir, which holds the project descriptors. This requires the user to re-create UserDir, reconfigure options in OptimalJ and reload the project -- a 15-minute process that had no adverse effect on the project files. In addition, the EJB server does not start reliably within OptimalJ, although it usually starts fine after a few retries.

Despite these nitpicks, and my complaint about the sharp learning curve, the product proved to be effective and reduced the expense of developing and maintaining J2EE apps. It allows developers flexibility in deployment, selection of technologies and scalability. And Compuware is positioned to plug new and evolving technologies into the tool, allowing developers to reuse their models, re-target their apps for new technology, and fill in the business logic at a lower cost than traditional development techniques.

System Requirements: Intel Pentium III or higher; 512 MB memory; display of 1024x768 or higher; 250 MB disk space; Sun Java SDK 1.4.1; Windows NT/2000/XP Pro or Linux Red Hat 7.3 OS.

Pricing and Availability: Licenses per named developer start at $800 for the Developer Edition, $5,000 for the Professional Edition and $10,000 for the Architecture Edition.

Pros:
* Allows users to diagrammatically document and enforce an architectural design. (What gets built is what was designed.)
* Provides for easy deployment of the defined app to a variety of database technologies, EJB servers and Web application servers.
* Reduces coding time.
* Provides a complete IDE.

Cons:
* Steep learning curve.
* No undo for model editing.
* Occasional corruption or confusion in the UserDir, which holds the project descriptors.
* EJB server does not start reliably within OptimalJ. Usually starts fine after a few retries.