In-Depth
Tools for the code generation
- By Johanna Ambrosio
- June 30, 2003
 | Model-Driven Architecture, or MDA, embodies the conundrum: Is the glass half full or is it half empty? Even though the MDA standard is still evolving, many products claim to be compliant with it and early adopters are developing apps with them. |
MDA vendors claim that today’s products can generate between 40% and 80% of the completed code for a given app based on models created with UML, and customers and analysts back up those claims. MDA’s purported benefits go beyond automatic code generation and the reduction of development costs, but those advantages are longer-term and most have yet to be proven outside of theoretical conversations. They include factors like eventual code and model reuse, and more effective fulfillment of user requirements. One advantage touted by the MDA camp is the ability to swap out underlying technologies -- OSs or languages, for example -- by simply revamping the platform-specific model and then regenerating the applications.
Still, a split remains between current users of these products -- mostly architects who speak UML or another modeling language -- and the targeted group of developers who believe they can do a better job of writing apps than any code generator. And it is developers that need to be convinced that these tools can make their work lives more meaningful by allowing them to concentrate on the creative stuff.
Developer distrust
This distrust is not unearned. Developers have heard about magic bullets for years, and earlier attempts (remember CASE?) at this failed because they over-promised and under-delivered. But this time around, advocates say, the products are based on an industry standard from the OMG, the originator of CORBA and other technologies that are well-known and well-loved by developers (see the related story “MDA: What is in the standard?”).
Another huge difference: Today’s MDA products, while they have some holes and can be expensive, do work.
Another issue has to do with career prospects. Some developers feel that using MDA tools will make their language-specific knowledge and skill sets obsolete. According to some analysts, this is happening anyway.
“I expect that the success of MDA will follow the success of outsourcing,” said Tim Sloane, director of business modeling at the Aberdeen Group in Boston. “I don’t like the concept of IT jobs going offshore, but I’m hard-pressed to see how we’re going to stop it. I honestly believe that the IT industry is more dysfunctional than the auto industry [was when it] faced restructuring and everything went to Taiwan.”
In Sloane’s view, software failures cost billions of dollars each year. And more importantly, the apps that result often bear little resemblance to the functionality business users originally requested from their development organizations.
“I ask IT managers whether they have a process that takes input from users about the success of a project — and most tell me ‘no,’” said Sloane.
A forced march
Given the potential savings and the linkage to requirements that MDA promises, many analysts say it is only a matter of time before MDA-like environments will be mandated by management. Michael Blechar, vice president and research director at Gartner Inc. in Stamford, Conn., calls it a “forced march.” Right, wrong or indifferent, he said, “it’s going to happen. It’s effectively a done deal.”
Still, none of this will happen overnight. “We’re looking at five years at a minimum,” said David Frankel, an independent consultant in Chico, Calif., and author of a book about MDA.
Industry watchers liken the use of MDA by developers to the earlier days of programming. Once upon a time, everything was hand-coded in Assembler. But then third-generation languages (3GLs) happened, and programmers resisted these because they felt -- correctly -- that they could generate more optimal code than a machine could. But compilers became better, with more efficient algorithms, and hardware became less expensive. As developers learned they could trust them, there was a gradual changeover to the new languages and compilers. Industry watchers predict a similar cycle for MDA tools.
Early MDA adopters include Deutsche Bank, Austrian Railways and the Swedish Parliament. The technology is particularly prevalent with systems integrators -- CGI, Lockheed Martin and others have projects ongoing.
Cris Kobryn, chief technologist at MDA vendor Telelogic, Irvine, Calif., said that there has been a lot of interest in MDA from the development organizations in engineering firms. These companies -- in the aerospace, telecommunications, automotive and manufacturing sectors -- typically long ago adopted computer-assisted manufacturing (CAM) and computer-assisted design (CAD), and are looking to apply similar discipline to their software process.
Vendors such as IBM (with Rational) and Borland (with TogetherSoft) have made acquisitions that will allow them to further incorporate MDA into their development tools. IBM and Borland acquired vendors that provide visual or other types of analysis and design tools -- the front end of the MDA process -- and are partnering with others to help on the code-generation end.
The tools
Currently, there are at least 40 tools that incorporate at least one of the major aspects of MDA: UML-based modeling; transformation between the app’s overall design models and the models that are specific to the underlying computing architecture (.NET, EJB and so on); and the generation of code in a specific language.
Jon Siegel, the OMG’s vice president of technology transfer, calls MDA adoption in the marketplace “extremely enthusiastic,” and said there are another “couple of dozen” products in the works. The OMG does not necessarily know about them all, he noted, because vendors need not license or pay to use OMG standards. Still, he said, MDA adoption has caught on faster than any other OMG standard.
Tools generally fall into two camps. One is the “full-boat” environment that includes UML modeler, transformation engine and code generation. Only a few tools are in this space, among them ArcStyler from Interactive Objects Software GmbH, XDE from IBM Rational and OptimalJ from Compuware Corp.
The other camp, comprising the majority of the tools on the market today, are code generators that take input from existing UML modeling tools -- Rational Rose or No Magic Inc.’s MagicDraw UML, for example -- and then generate code from those models. Tools here include Codagen Technology Corp.’s Architect and Telelogic’s Tau.
Another type of categorization could also be considered. These are the tools that existed before the MDA specification but which are still considered by their makers to be MDA-compliant, as well as “pure-play” MDA vendors committed to matching the official standard.
Vendors in each camp are happy to throw stones.
Richard Hubert, CEO and founder of Interactive Objects in Frieburg, Germany, said most of the tools “generate basic skeletal code from models.” In comparison, his firm’s ArcStyler provides multiple levels of modeling via pluggable “cartridges” that start with the high-level business model and then generate subsequent levels of abstraction from the UML technical model to the Web services model, and then the code.
“It’s tuned modeling that’s appropriate for each step of the software development life cycle,” Hubert explained.
He called the code generator-only class of tool “sub-standard” because “it’s very work-intensive to move back and forth between the modeling tool, generator and coding environment. Developers are used to making quick changes, hitting the compile button, seeing the errors and then going back into the code -- all within the same environment,” said Hubert.
Vendors on the code generation side of the house point to the expense of buying the full-boat environment and say it means customers will need to adopt another UML modeling tool instead of the one they already use. Working within your existing modeling environment also reduces the learning curve for MDA in general, assuming that everyone on the project is up to speed in UML (which is, admittedly, a big assumption).
In addition, customers want fast payback on their MDA tools, pointed out Michel Brassard, chief technology officer and founder of Codagen in Montreal.
“Our customers said they didn’t want to develop a model, develop another model, develop another model and then generate code,” said Brassard. “They wanted to do a model, then do the code. For commercial applications, ROI is key.”
The holes
None of the tools is perfect; all have some holes because it is still early going in MDA-land. For example, there are certain kinds of apps that have UML profiles completed, said consultant Frankel, including real-time embedded systems and certain types of distributed systems. But there are many others that do not yet have specific UML profiles, and these need to be complete to be able to do widespread modeling of a wide variety of apps.
“This is a huge part of the maturation process,” Frankel explained. “But there are plenty of applications that can be generated today -- this is the low-hanging fruit -- and part of being an early adopter is knowing where to use MDA successfully.”
Another issue, Frankel said, is that it can be hard to keep all the various models in sync with any hand-finishing work that is later done on the code. “If you don’t have management procedures in place, you can get out of sync,” he said.
The real world
But customers are finding their way. AIM Investments, based in Denver, is an 11,500-employee company that owns Invesco and other financial concerns. Wes Williams, a software architect at AIM, said he has been using MDA “for just about everything I do.” His current project is an integration effort that includes drawing UML domain models, applying J2EE patterns and then applying design patterns on top of that. He is using IBM Rational’s XDE, among other tools.
“UML will never generate the functional code,” Williams said, “but it does generate the architectural shell” that he then hands over to the coders on his team. When they are done, he reverse-engineers what they have done and then adjusts the model to reflect their changes or additions.
He likes the approach because “when we do generate code, it’s more likely to be correct. And as an architect, I can ensure that the code is being developed according to good quality principles.” In addition, Williams feels that it shortens the overall development time (although he has no metrics on the specifics of that).
Williams estimates that MDA generates about 50% to 60% of the application code, but it depends on the application.
Success with MDA depends a great deal on the coder’s fluency in UML. And it is “like learning a foreign language,” Williams said. “It’s one thing to know the vocabulary; it’s another to think in the language and speak it fluently.”
The second is what developers need to be successful with MDA. “We require class diagrams and collaboration diagrams” from coders, he explained. “It’s painful at first, because they’re learning to think and speak in a new language. But when that happens, you get the benefits of the model-driven architecture.”
Gartner’s Blechar estimates that perhaps 15% to 20% of all organizations are using truly integrated model-driven development. These are the ones using models throughout the development life cycle as opposed to those that use models for requirements analysis, for example, and then put aside the models once the “serious” coding happens.
Organizations in this 20% group are most likely to move to MDA the fastest, as they already have the people and processes to understand modeling in place.
“Unfortunately,” Blechar explained, “the majority of companies don’t have these people. A lot of companies will assume the everyday developer will know how to design reusable components.”
But, Blechar said, that has not traditionally been a programming discipline. Reusability is “about pattern recognition, resolving disputes over politics and cultures, and managing versions and configurations of multiple releases. It requires teaming in ways that most programmers aren’t used to.”
Many programmers today are focused on re-assembling new services or apps from existing components, he noted, or they are doing integration projects.
Although the logical conclusion of MDA -- if it is implemented fully -- will mean vast changes to a development organization, there is no need to start there. Aberdeen’s Sloane suggested that a more intuitive place to begin might be for an architect to use MDA tools to design models and generate the business logic and technical architecture models, and to then generate the stubs of the source code.
Coders are then handed this, and can modify or add to the source code as needed. The code is checked against the models, which validate whether the code has lived up to the architectural guidelines.
Bob Carasik, an enterprise architect at Wells Fargo in San Francisco, said that going with MDA is “a matter of the project leadership making the decision to do so, and then making the tools available.” Wells Fargo is using MDA to convert interfaces written in CORBA to interfaces written in J2EE with XML messaging. Almost all the bank’s apps use these interfaces, including mainframes, client apps that run various online apps and the corporate telephone response center.
In the bank’s case, in-house developers handcrafted the tools used to make the switch from CORBA middleware. “It’s paid off tremendously because we have so many interfaces to convert,” Carasik said. And “it wasn’t necessarily a case of using MDA -- it was more about how do we convert these interfaces, and what are the tools that are appropriate.
“You don’t change the development cycle overnight. You introduce concepts one at a time, with a clear rationale of why people are asked to do things,” Carasik said. “I’d tell developers to go for it because there’s increasing demand for these skills, and these techniques are needed.”
Read the related stories “MDA: What is in the standard?” by Johana Ambrosio, and “IBM Rational unveils RAD tool” by John K. Waters