Emerging technology: MDA
|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.|
|In the 1980s, as part of the computer-aided software engineering (CASE) trend, Software through Pictures was an early dramatic example of using models to drive code. (STP is now offered by Aonix as StP/UML.) The standardization of model vocabularies around UML in the late 1990s led some people to re-introduce the code generation notion.|
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,"
"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.
computing | GUI
etc | Laws