Blueprint for code automation

Early adopters of Model Driven Architecture face cultural barriers, but the payoff promises savings in time and money and better code quality.

Wisconsin is replacing its collection of disparate mainframe- and client/server-based unemployment insurance benefits applications with a Web system. But instead of starting the project by writing pages of specifications to describe the business processes, the team drew pictures.

The state's Department of Workforce Development hired a trainer to teach its Cobol programmers and business users the Unified Modeling Language, and the team mapped out UML diagrams on computers to document the requirements for the new applications.

Wisconsin is part of a small but committed group of organizations that is turning to a set of standards collectively known as Model Driven Architecture (MDA) that's being developed by Needham, Mass.-based Object Management Group Inc. They use UML and code-generating tools to build applications, and if all goes well, they use programming languages only sparingly to fill in the business logic. OMG CEO Richard Soley says he knows of two companies that are generating 100% of their code through the MDA approach.

But automatic code generation is only one of the benefits that early adopters are finding. They say they're also reducing development time and costs, improving code quality, promoting code reuse and doing a better job of meeting application requirements.

Lee Carter, a project director at the Wisconsin Workforce Development Department, says it's helpful that business users and IT staffers can now speak the same language when they work on requirements. "It allows us to really focus on our business needs and not have to think about all the underlying technology until it's time to think about the technology," he says.

Blueprint for Code Automation
Image Credit: Richard Downs
To map out requirements, developers and business analysts use stick figures and lines to illustrate the various use-case scenarios, such as how an incomplete application is processed or how a rejected applicant's appeal is handled. They replace the stick figures with boxes to show how the computer systems are connected. Once a series of activity, sequence, collaboration and other diagrams to design and document the new applications is ready, a tool transforms the models into the bulk of the application code, Carter says.

He says the diagrams documenting the applications can be retrieved at any time, even years down the road, because they're captured electronically with standards-based tools from IBM's Rational Software division. "Diagrams make so much more sense than writing pages and pages of narrative that just get stuffed into a 3-inch binder that nobody ever looks at again," he says. "We can trace from business requirements to code, or code back to business requirements."

To ease the transition to MDA, the project team brought in a qualified service provider, St. Paul, Minn.-based Adaptive Team Collaboration Inc., from the OMG's MDA FastStart program. Chris Armstrong, chief technology officer at ATC, has alternately served as mentor, trainer, counselor, psychiatrist and, most recently, process auditor, Carter says.

Another critical decision was selecting Dublin-based Curam Software's J2EE-based framework for building applications specific to the government social-services sector. The business requirements that the Wisconsin team specified through UML and defined through a platform-independent model (PIM) effectively integrate into the Curam software, Carter says. Systems integrator Tier Technologies Inc. also helped with the work.

Carter says that so far, the project is exceeding expectations. The team completed project requirements 60 days ahead of schedule. The first production release of the application is due in November, with other pieces to follow during the next two years. That's a shorter time frame than for similar projects states are undertaking using traditional approaches, Carter says.

PFPC Inc. in Wilmington, Del., a provider of IT outsourcing services and applications for the investment management industry, says customer projects that previously took six months to complete are taking four using MDA.

Michael Harte, the company's CIO, says the MDA approach is instilling discipline in his staff, leading to greater accuracy. Because the process forces more work to be produced upfront, serious design flaws can be discovered earlier than they could in the past.

Ian Maung, a senior architect at PFPC, notes that the MDA approach helps developers who work in different geographic locations to communicate better because they're able to understand the interfaces their colleagues expect.

Maung says that in the future, MDA might enable easier switches between runtime platforms, since the business and application logic is defined independently of the platform, and the PIM could simply be revised to generate a new platform-specific model. He hopes action semantics in UML 2.0 might pave the way for 100% code generation to standards-based platforms such as J2EE, and MDA ultimately may enable customized code generation.

Although the UML/MDA approach is gaining increasingly wider adoption by application architects, UML usage includes no more than 15% of developers, according to several analysts' estimates. Critics say its complexity can be daunting, and the cultural change for IT shops accustomed to pounding out code can be difficult to negotiate.

Analyst Carl Zetie at Forrester Research Inc. says few development teams have the patience to go deep into a project and not have a line of code to show for it. "With conventional IT shops, there's always the urge to code, and that to me is the single biggest barrier to any kind of modeling," he says.

Thomas Murphy, an analyst at Meta Group Inc., says many developers are skeptical based on past experiences with 4GL tools that produced code that was hard to maintain. He predicts that the use of model-driven and declarative approaches to development will increase—but not necessarily with the UML/MDA approach, which faces many challenges.

Early adopters are aware of many of them. For example, Maung says tools that claim to fully support standards often don't. And Per Gyllstrom, chief architect at PFPC, notes that some developers fear they may be displaced if an entire application can be generated through models and tools. It's important, he says, to start with small projects to convince skeptics of MDA's merits.

Although one of the benefits of MDA is code reuse, developers can be reluctant to trust a colleague's code or code that has been generated by a tool.

Fireman's Fund Insurance Co. in Novato, Calif., encountered such resistance while undertaking a major project to overhaul its claims system, which went into production in 2000. A seven-person team skilled in object-oriented development used a set of UML class models from IBM called the Insurance Application Architecture (IAA) to generate code into an Enterprise JavaBeans-based framework for persistence, messaging, events and object distribution.

Rational Rose scripts produced over 80% of the architectural code, and Fireman's Fund later switched to a code-generation tool from Montreal-based Codagen Technologies Corp. Within weeks, Codagen's rules engine and reusable templates eliminated the need for Rose scripts to do the transformation from model to code.

But the effort stalled as priorities shifted, and tension mounted between the core architecture team and the developers who had to hand-code the business logic, says Bill Nadal, an enterprise architect at Fireman's Fund.

The enterprise architecture team picked up the torch again in 2002, when it designed a blueprint for a reusable component stack with the aid of Peter Herzum, an expert in component-oriented software manufacturing. The team's goal was a "software factory" approach to development, in which components would be reused and snapped together like Legos to build applications.

A proof of concept done with Herzum Software LLC and Codagen targeted IBM's MQSeries Financial Edition, which used the IAA class models and Rose scripts to generate services and XML-based messages, Nadal says. The team demonstrated that, using the MDA approach, code could be automatically generated for persistence classes, service interfaces and XML messages.

Enterprise architects at Fireman's Fund are currently using their component blueprints to build core foundation models and services for security, context management and metadata management. In the future, they plan to focus on business-level components.

"Everyone thinks an enterprisewide approach takes longer and is more expensive," says Nadal. "It actually means you may build a higher-quality component once instead of many times across individual projects. MDA is an important step in achieving that goal."

Building an Application Using MDA

User develops a platform-independent model to represent desired business functionality and behavior — but not technology details.

An MDA-compliant tool applies standard mapping to generate a platform-specific model, for middleware based on J2EE or XML/SOAP, from PIM.

MDA tool generates all or most of implementation code for deployment technology.

Copyright © 2004 IDG Communications, Inc.

Shop Tech Products at Amazon