Why it’s OK not to use (or even know!) UML

UML is bandied about so much these days that it’s considered by many to be standard. It’s standardized, but to be standard it’s got to be in use almost everywhere. Everywhere important, at least. Domain-Specific Modeling and Model Driven Architecture by Steve Cook (PDF) assures us that we who feel uncomfortable with UML’s claims to universality are, in fact, in good company.

Where I work, we do pretty much pure object-oriented designs; every once in a while someone dares put an aspect of our design into UML form. If you only casually use UML, it’s never really obvious what it’s trying to say. If everybody in the room only casually uses UML, you can easily (and sometimes gleefully) spend precious meeting time discussing what exactly an open diamond with a star next to it means. Any reasonably complex system is not interpretable at a glance since “[m]odels are typically decorated with a lot of symbols and textual elements that must be carefully inspected to see the real meaning.”

Steve works for Microsoft and has concisely defined their viewpoint of the state of MDA. They are, all in all, quite excited about it.

“The development of domain-specific models, patterns, and frameworks, organized into software value chains — product lines, promises to industrialize the production of software similar to the way in which the production of many household goods was industrialized in the last century.*”

Those who’ve watched Microsoft get ‘excited’ about things over the years will either:

1. Wait for the other shoe to drop.
2. Start crying like a child because the thing MS is excited about is their company’s market.
3. Start slapping together white papers and PowerPoints to make their technology look eminently buyable — so they can sell out to Microsoft for the highest possible price.

He talks about “domain-specific modeling language” as being far more useful than UML’s more universal approach. This makes sense in light of the effort needed to get UML used at the developer level, where it was intended. It’s not a tool that developers easily take to because it runs against limits so quickly, like it’s complete inability to be used as a two-way specification (ability to work in both model and generated code easily) and the fact that “it does not translate very directly into [common] technologies.”

“a UML class cannot be used directly to depict a C# class because [it] does not support the notion of properties … a UML interface cannot be used directly to depict a Java interface because [it] does not contain static fields”

While these are tiny details when viewed from the ivory tower of a specification developer, they are showstoppers as far as a developer using UML is concerned. Microsoft is dead-on in using “UML to the extent that it provides recognizable notation for well-understood concepts” and creating “new conventions” where its vaunted universality is not quite up to snuff.

We should hardly be surprised to see that Microsoft is going to ‘embrace and extend’ UML. They’ve gone to the trouble of writing a whole paper giving good, logical reasons why they’re going to use proprietary …ahem, domain-specific … modeling languages in their tools. We can hardly complain though since the promise of UML as a universal tool was ever a mirage. That Microsoft is forging ahead with their own standard is a foregone conclusion, but at least they are quite justified this time. We, as developers, simply run the risk of getting another de-facto standard which is “whatever Microsoft uses and supports”. Those who develop for the web know how much fun it is when Microsoft’s attention wanders and leaves the world addicted to its half-assed standards.

UML − Unified or Universal Modeling Language? by Dave Thomas (JOT) is a fun read, which tells a bit of the history of UML’s development. Throughout, he hits quite often on his main point:

“Doesn’t it seem odd that a language intended to help developers whose most productive tools are textual editors, outliners, and IDEs has no nice syntactic expression?**”

Essentially the same argument brought by Steve Cook: UML is not getting accepted because of systemic problems that can never be addressed because the parts seen as problems by developers were deliberately designed by people who didn’t use it in the real world. UML is “yet another committee attempt to unify the world in a single grand language — the vain quest for a ‘computer Esperanto’.”

No more being chained to code! Or implementations! Or platforms!

“You just draw the pictures; mix in a few textual specifications, and model-driven code generators will eliminate the need for low-level programming (and programmers!).”

This interpretation of the goals of modeling languages is similar to Steve Cook’s excitement at the coming “industial age” of software engineering. We, as developers, should not allow grinding capitalist interest use the modeling languages we design to obviate us within our lifetimes. We should make sure that they, first and foremost, fulfill our needs and make our work easier and more fun, not to mention our products more stable/more maintainable/etc.; whether or not a corporate bottom-line is improved is secondary to us. There are already plenty of people designing our world for bottom-lines; you damned well better make sure you’re pushing back to keep the world better for yourself.

“We need to ensure that important new languages for programming and design have actually been used and tested in real applications before they are foisted on programmers. Standards groups can then play their proper role, which is to develop language standards that are based on real-world best practices.”