Microsoft FUD against MDA

Charles Betz has linked to an article by Microsoft’s Steve Cook on MDA. Read it, the come back. The article contains an important lesson: how to create FUD(Fear, Uncertainty, Doubt) in the most sophisticated way. These two paragraphs are a good example:

Nevertheless, an approach like MDA can indeed be helpful for some application areas. Some vendors have shown that building a Web application to run within the J2EE (Java 2 Platform, Enterprise Edition) environment can be simplified by building UML models of the data entities and components involved, and mapping these models into the various J2EE artifacts. However, as we mentioned earlier, for developers to adopt such an approach it is vital for the overall process to be agile and to not introduce unnecessary transitions and barriers such as irreversible code-generation and debugging problems.

Building J2EE apps with an MDA approach is not something “some vendors have shown”, it’s very quickly becoming the standard way of building sophisticated enterprise applications. Trying to create some sort of lock-in between MDA and J2EE is totally misleading. We have used our own and other MDA products, as have our competitors, to aid customers in building applications based on a wide range of platforms, which of course include, but are not limited, to J2EE - ranging from CORBA to COBOL. It’s definitely true, though, that J2EE is the most important platform to be targeted by MDA tool vendors, the reason for that being, in my experience, that most enterprise applications today are built on J2EE. Also, pretty cleverly hidden between the lines, is the notion that somehow current MDA tools (you know, those that are tied to J2EE, hah) suffer from what the author calls the “agility problem”. This is also very misleading — no MDA tool worth the label has this problem. FUD, pure and simple.

Extending the reach of MDA into other areas will be difficult. The OMG’s definition of “platform” is vague, and the only real example is J2EE. Using models to assist with creation of J2EE applications is a valid pragmatic step on the road towards using models successfully in software development. In fact, there are very few standardized mappings between platform-independent and platformspecific models; the only ones that exist target the Java platform, although there are non-standard commercial implementations that claim to be MDA compliant and target other platforms.

First of all, it seems illogical for the author to make a case for domain-specific modeling languages, and then demand that there should be more standardized mappings (and following from that, standardized domain languages) inside MDA. To target other platforms, i.e. those for which no standardized mapping exists (which is essentially everything, since nobody uses the low-level EJB profiles because they are useless), is absolutely within the standards. This is another good example of twisting the truth — somehow doing things that are not standardized at all becomes doing non-standard (with every casual reader will read as violating some existing standard). (As an aside, the section’s summary does not summarize what is claimed in the previous paragraphs; while I agree that the name “MDA” itself is rather dumb, the rest seems to be just a bit of mud thrown around). Next, the author starts to beat up the UML:

UMLAsBlueprint raises the bar for UML. Here the objective is to integrate one or more UML models as first-class artifacts within a software development process. […] When we try to do this, we immediately find problems with UML, because it does not translate very directly into the technologies that we use. For example, a UML class cannot be used directly to depict a C# class because a UML class does not support the notion of properties while a C# class does. Similarly, a UML interface cannot be used directly to depict a Java interface becauinterface does not contain static fields while a Java interface does.

It is astoundingly trivial to add support for properties or static fields in Java interfaces to UML models by using stereotypes and/or tagged values appropriately. In case there is any doubt, I could easily draw up a valid UML model and use it to generate C# including properties or Java interfaces with static fields. IMO, though, platform-specific details like these don’t have any value in MDA/UML models anyway … but that is another story.

The technology of “UML profiles” is intended to offer flexibility in the blueprinting world by permitting a limited level of extensibility to the language, but practice has found that the very limited level of extensibility provided by profiles does not permit a seamless mapping from UML into popular target technologies.

That is an outrageous and unfounded claim, as lots of successful MDA project that have done just that clearly demonstrate. In the next section, the author explains that Microsoft will add its own, proprietary views to the UML. Worried about standards? No need, just read this:

Although the diagrams are not legal UML by the letter of the standard, the meaning of the diagrams is readily apparent to anybody that understands the UML conventions.

Oh, great, so it’s obvious to a human who looks at the diagrams. It’s also obvious that these non-standard extensions will kill any desired interoperability. While I like MOF and XMI conceptually, I dislike the implementation of those concepts, which I deem to be too complex and rather academic in many places. I disagree that being able to store model information in a standardized way is not important, though; I think that a sound model for representing the information is a lot more important than a nice UI on top of it. Then again, I can understand why a company like Microsoft would view this differently. Concerning XMI interoperability, there definitely are problems; still, we were able to build a product that can import XMI written by half a dozen different CASE tools. Whether, conceptually, it’s better to have domain-specific exchange formats that a single format like XMI reminds me of the XML/RDF debates; there are valid arguments for both views. To summarize my personal view on this: Unless follow-up articles provide more value, this is a lot less than what one would have expected from somebody as Steve Cook.