I’m often asked by audiences, visitors to Microsoft and journalists to explain our position with respect to UML (e.g. VSLive! Interview). Many people who read our views on model driven development, as described in these postings and other places, assume that our emphasis on domain specific (modeling) languages, or DSLs, somehow has put us into an anti-UML position. We want to make it clear that this is not true. While I laughed out loud at some points in Alex Bell’s excellent article in March 2004 ACM Queue called Death By UML Fever, we still agree with many of the points made by Grady Booch in his response. Before UML, there was an unproductive diversity of modeling approaches, and their convergence into UML 1.0 was a significant step forward in using models in software development.
But for whatever reasons, the existence of UML and UML-based tools, has not significantly changed the way developers build applications. Nor has it significantly contributed to developer productivity. Since Microsoft ships one of the most-used UML tools – those based on
This was one of the driving forces behind
Those same whiteboards in offices in my corridor are also covered with scrawled code. But again – these are sketches – they are rarely point-perfect compilable program source. That’s a key difference for developers. Any artifact that contributes to actual software development must be capable of manipulation digitally. Source code has a well-defined syntax, a comprehensible semantics – often defined behaviorally by the compiler’s transformation of it to lower level code or IL – and can be manipulated consistently by compilers, debuggers and re-factoring programs, to name but a few. To be useful to developers, a model must have the same status as source code. It too must have a precise syntax, a comprehensible semantics, and well-defined mappings to source code or other well-defined models. And it must be more than just documentation.
Take the Whitehorse Service Designer, for example. It’s not just documentation, although it can serve that purpose. Rather it allows a developer (or architect) to focus on one aspect of her system – the connectivity between services in a service-based architecture. She can design this aspect of the system before building projects, WSDL files, code and schemas, or ask the tool to document connectivity between services if those artifacts already exist. Since connectivity information is scattered throughout many development artifacts, the holistic view such a diagram gives is fundamentally useful even though all the information it conveys could be deduced by careful scrutiny of the implementation artifacts. The Service Designer has a well-defined syntax (its DSL metamodel), and predictable, always-synchronized mappings to the various implementation artifacts. The underlying designer framework plays the role of a compiler for Service Designer diagrams, much like the role played by a traditional compiler with respect to source code files.
But, you say, why couldn’t the
Well, when we looked at the direction the UML 2.0 specification had taken, we realized that there were several reasons this could still not be the basis for development artifacts that were anything more than documentation of a system. Since no natural sub-language of UML fits the requirements for service connectivity, we would have had to resort describing our Service Connectivity DSL using stereotypes and tags on an existing UML sub-language. This would have led to an overly complicated model within what has been described by many in the industry as an already bloated and complex specification. Using standard UML notation, in which an existing shape corresponding to whatever sub-language we’d extended is reused, would have compromised the readability and clarity of the diagrams. Lastly, we’d have been dogged by the lack of precision in the specification in key areas, and the mismatch of type-systems inherent in UML compared to the
For these reasons, we elected to define the Service Connectivity DSL using a purpose-built metamodel, itself defined as a member of a family of related metamodels. This gives us a natural and precise foundation for service connectivity, and gives us a high-fidelity mapping to the underlying implementation artifacts which includes, of course, some amount of code. This is the same conclusion we have reached on other focused development tasks, and led to similar DSLs for the Class Designer and the Logical Data Center Designer described in other postings. Support for extensible DSLs, built as a family, with well-defined mappings between them and other development artifacts has thus become the basis of Microsoft’s model driven development strategy.
To summarize, we’d recommend using UML and UML-based tools for
- White boarding,
- Conceptual drawings that do not directly relate to code.
We’d recommend precisely defined DSLs and DSL-based tools for
- Precise abstractions from which code is generated
- Precise abstractions that map to variabilities in frameworks and components
- Precise mappings between DSLs
- Conceptual drawings that have precisely specifiable mappings to other DSLs or to code artifacts.
We’d recommend neither of the above for visual programming of detailed program logic (or at least for many years yet), despite Grady Booch’s optimism about executable UML expressed in an interview for the British Computer Society Bulletin that can be found here.