FREE hit counter and Internet traffic statistics from

Friday, December 05, 2003

Model Driven Development

Very interesting article on modeling languages and distributed applications that foreshadows what will be included in the next release of Visual Studio .NET.

Some would argue (correctly in my view) that abstraction is the most powerful productivity-boosting concept in Computer Science (and in many other aspects of life) and so tools that raise the level of abstraction result in less complexity leading to less grunt work and fewer defects in the code. This is surely the wave of the future.

After reading the article I'm still unsure as to where/if Microsoft's effort dovetails with the Model Driven Architecture of the OMG. Both ideas use models to generate code and attempt to keep the model as a living artifact in the project. However, the MDA/OMG approach is centered on UML and appears to be more focused on platform portability than on the reduction of complexity while the Microsoft effort looks like it is more domain-based, targeted at the Microsoft platform, and does not use UML. I could be wrong on all points of course, being a newbie here. However, Microsoft's document does say that "While abstraction can be used to hide platform differences, we find it much more valuable to use abstraction to reduce complexity of translating requirements into implementations."

The challenges to any model-driven development that I see right off are at least twofold:

1) How do you keep the generated code relevant to the model when changes are made to either end? This is the current problem with tools included in Visual Studio .NET Enterprise Architect and the previous tool based on Rational Rose in Visual Studio 6. Microsoft includes Code Model APIs in the .NET Framework that could help with this and of course the model would likely produce base classes, attributes, and delegates that are hooked to hand-crafted code although it would seem there would at least have to be some minimal interaction here.

2) How do you create models that are granular enough to support real business processes? I can certainly see broad models that support certain kinds of problems but can the models really be made specific enough to produce usable code? I suppose that the DSL approach would allow industries to create the models which would enable them to be very specific and more complex but this is certainly a key challenge.

Lots of food for thought...

No comments: