Two weeks ago,posted a titled “Microsoft and Domain Specific Languages”. The posting is part of a running debate between Grady, and my colleagues at Microsoft and .
While there are several points in the posting on which Grady and I disagree, which I will address over the course of the next few postings, there are also several points on which we agree. In particular, we share the conviction that packaging knowledge for reuse in patterns, languages, frameworks, tools and other form factors is “the right next stage in cutting the Gordian knot of software”. You can read about what we think is required to accelerate this type of knowledge reuse in Microsoft’s work on patterns, led by David Trowbridge and , and about , and .
That said, the devil is in the details of how to automate more of the software life cycle using metadata captured by models, a goal often described as model driven development. At least that’s the goal here at Microsoft. Of course, that is not the goal for which UML was developed. It was developed to provide a common notation for the practice of object oriented analysis and design (OOA&D), as described.
So, is it fair to judge the UML on how well it measures up as a medium for model driven development? Well, one might not think so, except for the fact that it is being promoted by a standards organization (i.e., the), not only as A medium, but as THE (official, sanctioned, approved, acceptable and appropriate) medium. The implication is that the UML has already been demonstrated to be the most appropriate medium for model driven development, and that the burden of proof falls not to the UML, nor to its promoters, but to those who would use some other medium.
This debate, then, is about the suitability of the Unified Modeling Language (UML) as a medium for developing source artifacts from which running systems are created, and for capturing information about those systems (i.e., metadata) that can be used to automate activities across the software life cycle.
The first point in Grady’s posting on which we disagree is his claim that Microsoft has rejected the UML in favor of proprietary domain-specific languages. Of course, this is not an accurate description of our position, which we have stated publicly on many occasions. We have not rejected the UML. Rather, we agree with Grady that UML has indeed proven to be very useful as a repository for notational conventions that support a range of modeling styles. There is no question that this was a valuable contribution that significantly advanced the practice of modeling, as traditionally understood, where the focus is primarily on creating documentation that describes system structure or behavior.
What we have rejected is the claim that the UML is the most appropriate medium for model driven development, where models are used as source artifacts that are compiled, interpreted, or otherwise used to automate software life cycle activities. On this point, we agree with Grady that UML is not appropriate for all purposes. After all, it is a unified modeling language, so called because it was developed to integrate notational styles used by multiple methodologists, not a universal language that can solve all problems.
Clearly, developing, testing, deploying, managing and maintaining software are quite different than creating documentation. One obvious difference is that models used for development must have semantics defined precisely enough to support computation, not just human interpretation. A second is that models used for automation must fit well into the software development process, and the file oriented world in which it is practiced.
Perhaps, instead of trying to bend an existing language designed for designed for creating documentation to the duties of this new and promising approach to software development, we would do better to come at the question from the opposite direction, and ask what the most appropriate language or languages would look like. On this point, we agree with
I’ll have a lot more to say about this topic, and about the broader question of how to practice model driven development effectively in subsequent postings.