UML’s Standard Is Looser Than You Think
Not long ago, methodology wars consumed modeling discussions—furious debates over which notation to adopt. Most of the time, the choice didn’t matter, yet the arguments generated more heat than light. The UML largely ended those fights by providing a common notation. But as teams are now discovering, the standard doesn’t settle every question. A growing number of detailed issues have no definitive answer.
Why the ambiguity? Largely because modeling methods, object-oriented or otherwise, never were very formal. Definitions were left to intuition, gaps were plentiful, and formal-methods advocates criticized this lack of rigor. In practice, though, informality often proved an advantage: loosely defined methods were generally more useful than rigorous ones in real projects.
The UML does have formal elements, with the meta-model—a UML model describing UML’s own structure—at its core. Yet even the meta-model leaves significant gaps. It defines an attribute as a kind of structural feature whose type is a classifier, but what does that actually mean in Java: a field, a pair of get and set operations, or an operation parameter? Ask ten UML experts and the only agreement you’ll get is that the answer includes “it depends.” The meta-model’s primary purpose is to define well-formed models so CASE tools can eventually interoperate—a long way from a truly rigorous standard.
Living with Multiple Interpretations
This means you’ll encounter varied interpretations of the UML across books, training, and project documentation—far less variation than between pre-UML methods, but variation nonetheless. Teams must develop a consensus interpretation for issues as they arise. In doing so, be wary of anyone asserting with certainty that one interpretation is right and another wrong. Some things are cut and dried; many are not.
When choosing an interpretation, the overriding principle is knowing what you’re using the UML for. If your CASE tool generates code, the tool’s code generator dictates the interpretation. Otherwise, choose the interpretation that best supports communication with other people. That is the real value of the standard: encouraging common interpretation of diagrams.
Interpretation of the UML will parallel that of a natural language like English, not a defined language like ANSI C. No single authority will pronounce on UML semantics. The closest body is the OMG’s analysis and design task force, which holds the key to the standard, but it will never rule on all issues. Where it does rule, common practice may diverge—much like the French language academy outlawing faire du shopping without stopping its adoption. Here, UML mavens—those who comment on correct and tasteful usage—will help shape common practice. The three amigos will be especially influential figures, but their writings carry weight rather than absolute authority.
Expect outright notational deviations as well as interpretive ones. Where people perceive important gaps, they’ll propose extensions, some fitting through UML’s own stereotypes, others deviating from OMG documents. Whether such extensions survive depends entirely on whether others pick them up.
Choosing What Works
For communication, look at influential sources when you choose an interpretation or consider an extension. Their views should inform the decision, but shouldn’t settle it. In the end, pick what’s most useful for your project—an interpretation that reduces clutter or improves visual clarity is legitimate, even if less traveled. You must make clear to readers that you’re taking a less common route, but it can be well worth it. Keep to the common usage where you can, but don’t let pronouncements rule you. The UML is there to serve you, not the other way around.
This natural-language view also predicts how UML will evolve. Natural languages grow as people push them in various directions; whatever proves useful enters common usage and gradually standardizes, while the rest fades. We’ll see considerable pushing at UML’s edges over the next few years—a good thing for keeping the standard vibrant. Pre-UML methods saw similar evolution, with many ideas folding into UML. A common base makes that process easier and may accelerate UML’s development. Expect the standard to evolve; expect official release to lag behind best practice.
The CASE Tool Trade-Off
CASE tools play an unusual role here, and their decisions affect your modeling options. The UML’s chief advantage for CASE vendors is freeing them from supporting multiple methods, so they can focus on doing something useful. But supporting the UML forces tools to adopt the meta-model and face the same interpretation issues. Code generators in particular make divergent decisions—not just about what code to emit, but about what the UML constructs they generate are intended to mean. So the UML in one CASE tool doesn’t necessarily mean the same thing as the UML in another.
Many CASE tools sell diagram checking as a feature meant to prevent mistakes. That rubs me wrong. When I know what I want to do, being blocked by a tool that can’t accommodate it is deeply irritating. Proponents frame it as a boon for junior developers, but a solid code review process beats mechanical checking. Tools miss the subtleties of human communication. Don’t let a CASE tool dictate what you draw—your judgment can outperform it any day.
