In-Depth

Emerging technology: MDA

• November 29, 2002

The model-driven architecture is another "new" technology that is not completely new. A central tenet is that the code for large portions of systems -- sometimes whole applications -- can be generated by machine. In the semiconductor design software world, this type of capability has long been common. In software, compilers and assemblers aside, hand-coding is still preferred.

When the Object Management Group became UML's steward (after successfully creating the CORBA middleware standard, only to have that whelmed by industry infatuation with Java and a whole new slew of technologies), the group set about to add model-to-code bridges under the auspices of MDA. This will become increasingly visible as vendors bring out UML 2.0 tools.

Vendors in the modeling and tools arenas have heartily embraced UML, and many are launching MDA efforts. Count among them Borland, Rational, Telelogic, Interactive Objects, Computer Associates and others.

Even though wizards and other software techniques are common, generated code is still controversial. The question is how much generated code is a good thing. A system may successfully generate program stubs and templates, but performance can be faulty. Even when a generator creates more than 90% of code -- and it is fast code that works -- the effort required to hand-write the final 10% of code can negate the promised productivity advantages.

"MDA is comparable to the early days of the compiler. It is not revolutionary," said Richard Hubert, CEO at Interactive Objects GmBH, whose firm has been generating software, starting with CORBA infrastructure, from models since 1994.

While it may not be well described as a technology increment, and is not revolutionary, it does require people to "change the entire way they design IT systems," Hubert admitted.

"The first time I started thinking about MDA as a good idea was 1995 or 1996, but the tools then were pretty bad," said MDA user Ken Sayers, a technology consultant at Chubb and Son Inc. Sayers noted that he spoke from his experience, and not for Chubb IT as a whole.

MDA is not CASE revisited, however, said Sayers, looking back to those days.

"We had big CASE tools in-house and they flopped, and the managers that got hurt by that will now ask, 'What's the difference?' It is that this is not the same thing; it is our own architecture that we are generating from. And we decide how much is generated, and how much is not."

The MDA approach lets you have models that are in sync with code. Moreover, the document is the model, said Sayers. If you create documentation separate from the model you encounter the kind of problems that stymied CASE, he suggested. MDA is still proving itself at Chubb in a number of perhaps modest-sized applications that have gone into production.

MDA coda: The guess would be that, after the lesson of a CASE industry that oversold its wares, the MDA industry would under-promise on MDA's capabilities. However, that may suggest a level of common sense that seldom surfaces. Over-high hopes are an inhibitor here. While coders, who often do not favor generators, may not have the sway they had when industry was on an all-out dot.com hiring binge, a return to salad days would increase their influence and dampen MDA's future. Changing processes is key to broad MDA success; only big, visible successes can make people change the way they do things, and that requires time.

Prev | Next

Intro | Grid computing | GUI | MDA | Wireless | Agents etc | Laws