Channels ▼


UML 2.5: Do You Even Care?

Since its beginnings in 1996, the Object Management Group's Unified Modeling Language (UML) has become all but ubiquitous within the IT community. The effect of the UML on our industry has been impressive — there have been dozens of UML books published, thousands of articles and blogs posted, and thousands of training classes delivered — some by me. UML v2.5 is just about to be released, but I'm not sure that I even care. Here's why.

The UML was originally developed by Rational Software, now a division of IBM (my former employer), in 1996 under the leadership of "The Three Amigos": Jim Rumbaugh, Grady Booch, and Ivar Jacobson. The 1.0 version was proposed in January 1997 and officially adopted by the Object Management Group (OMG) later that year. Since then, the UML has undergone many revisions, with UML 2.0 released in 2005 and most recently UML 2.4.1 in August 2011. An "in process version" of UML 2.5 was published in October 2012 and is expected to be officially released soon. My guess is that it will happen at the next OMG Technical Meeting, being held in Santa Clara the second week of December.

Although I have no doubt that everyone involved with the UML 2.5 release has done a great job, I'm struggling to find a reason to be interested. This is particularly strange given my background with the UML. I've written several UML books, including The Elements of UML 2.0 Style (2005), The Object Primer 3rd Edition (2004), and Jolt Productivity Award winning Building Object Applications that Work (1997). From an agile point of view, showing how to create UML diagrams in an agile manner was an important aspect of Agile Modeling (2002), which came about from the article Extreme Modeling. My point is that my history shows I'm about as pro-UML as you're going to get.

A Simpler Specification?

The goal of UML 2.5 is to simplify and clarify a specification document so as to reduce implementation problems and promote interoperability between tools. There was a significant pushback against UML v2.0 due to its complexity, so simplification is a step in the right direction. One of UML's complexities is the addition of diagrams that seem to have little value for most practitioners. For example, have you ever seen, let alone used, a composite structure diagram, an interaction overview diagram, or a communication diagram? Do you even know what I'm talking about? The good news is that in UML v2.5, the language itself remains virtually unchanged. However, new diagrams are being added for a total of 19 (up from 16 in UML 2.0). The additions are:

  1. Model Diagram, which is a specialization of a Package Diagram (akin to free-form architecture diagrams)
  2. Manifestation Diagram, a specialization of either a Deployment Diagram or Component Diagram that shows how components are manifested in the physical solution
  3. Network Architecture Diagram, which is effectively a high-level Deployment Diagram.

Interestingly, there are still no diagrams specific to user interface or database development. This is simplicity? Sigh.

A second complexity with UML 2.5, at least for tool vendors, is inconsistency in the semantics of the specification itself. The primary focus of the v2.5 release will be cleaning up the specification, which in theory, should lead to better tool interoperability. But to be blunt, I believe that it's time we called BS on modeling tool interoperability. With a few exceptions in the SysML space, tool interoperability has stayed at the "marchitecture" level since the advent of computer-aided software engineering (CASE) tools in the late 1980s; I'll let the marketshare of UML-based Model Driven Architecture (MDA) tools speak for itself. For me, the absolute minimum for tool interoperability means that I can edit a model in tool A, export it to tool B, update it there, and export it back to tool A without loss of information. Furthermore, tool B may not necessarily be a modeling tool. What I really need is this level of interoperability in my entire tool stack, from whatever I use to capture high-level requirements all the way down to running code. Better yet would be tools that truly plug-and-play seamlessly and provide a fully functional solution-delivery stack.

I doubt that we'll ever see meaningful modeling tool operability except in very well-defined spaces, such as where SysML is typically applied. The primary challenges with interoperability aren't technical in nature, they're political. Modeling tool vendors, regardless of their marketing claims, aren't motivated to produce tools that play well with others because that's a great way for them to lose customers. Worse yet, there are even some vendors offering multiple modeling tools that don't interoperate with themselves, let alone another vendor's offerings. The bottom line is that modeling tool interoperability has been "just around the corner" for over a decade and I suspect it will stay there for a long time to come. Follow some of the links provided in the "More UML Reading" section to see my point.

Survey Says…

I'm not the only one who is jaded when it comes to the UML. During the fourth week of October 2013, I ran a mini-survey exploring how people were approaching modeling, including the use of both UML and Business Process Model and Notation (BPMN). There were 162 responses and the survey details can be downloaded free of charge. Every respondent had heard of UML (as I mentioned earlier, UML truly is ubiquitous), but 26% had never heard of BPMN. Only 13% found UML to be very useful, and 45% indicated that UML was useful but they could get by without it. An additional 20% indicated that UML was more trouble than it was worth, and 22% indicated that they don't use UML at all (although 10% of that subset indicated that they had looked at a UML diagram within the past month). In short, the OMG has been very successful in marketing the UML, but not so successful in producing something people find useful.

Perhaps one day, UML-based tools will truly provide the long promised higher level of abstraction that results in a leap in software development productivity. But at this stage, I suspect that any such productivity improvements will come from a very different direction. We'll need to wait and see.

More UML Reading

The OMG's UML v2.5 Beta home page

In 2010, Ivar Jacobson and Steve Cook described the need for simplification and support for better tool integration in The Road Ahead for UML.

An ALM Perfect Storm? by Adrian Bridgwater discusses Atego's Artisan Studio, which leverages both SysML and UML.

Application Lifecycle Management Meets Model-Driven Development by John Carrillo and Scott McKorkle describes their 2008 vision of how ALM and MDD tools can be combined to support the full solution delivery lifecycle.  It's five years later; where are the tools?

SysML: The Systems Modeling Language by Bruce Powel Douglas overviews the relationship and differences between UML and SysML.

In June 2004, I wrote A Road Map to Agile MDA about how to make the OMG's MDA work in practice. This article questioned the viability of the tool-driven, UML-centric vision of the MDA and summarized eight concerns that I had about the MDA. These concerns have stood the test of time.

In MDA: A Motivated Manifesto, written in 2004, Grady Booch described seven reasons why the OMG's MDA strategy should provide a reasonable step up from today's popular development techniques. Those seven points were almost the exact opposite of what I wrote in the Agile MDA article a few months earlier.

The Introduction to UML Diagrams page provides a brief tutorial on the diagrams of UML 2.x.

Scott is a long-time contributor to Dr. Dobb's.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.



"UML 2.5: Do You Even Care?"



One of the reasons why some people are not interested in UML is the poor quality of many UML books. Many and possibly most of them reduce UML to “programming in pictures”, instructing readers on how to use it to do things that they can do better by simply programming. This is the software equivalent of telling owners of modern personal computers on how to they can be used almost like classical typewriters.

However, whenever there is a need to understand software at a level above individual program instructions, something like UML is essential. For example, understanding how a network of interconnected objects realizes a complex end-to-end operation is much more easily explained and understood through a sequence diagram compared to tracing through the mass of code scattered in diverse methods.

Despite Mr. Ambler’s credentials as a UML expert, it appears that he has been misinformed about UML 2.5. There are no “Model”, “Manifestation”, or “Network Architecture” diagrams added in UML 2.5. In fact, the number of UML diagrams has not changed since UML 2.0 was issued over a decade ago. I am not
sure where his figures of 16 and 19 come from, but it would be worthwhile for Mr. Ambler to check the UML 2.5 spec, lest he mislead the readers of DD as well as his UML books.

This is not to say that there are no good reasons to
criticize UML, but, it should be based on facts rather than hearsay.

Finally, I would like to point out that the Object
Management Group (OMG) is a relatively compact organization with less than a dozen employees and no real marketing organization. So, it seems rather unfair to blame them for the successful marketing of UML.

Although UML was heavily marketed during its inception (the "three amigos" etc.), that is long in the past (20 years ago!). So, there must be more than marketing that is needed to explain why UML is still around.


first of all, Ithink it is good thing. but I have few ideas how to impruve it. From point of wiev of the c++ programmer it has some dificulties when whe talk from the point of clas diagrams! well when you use pointers it should have been donesome other way. And just one more thing, why big ompanies juse it to keep some tracks how do classes look like, t should be jused instead of thoe old fasion wizards, to gnerate some code and after to be documentation as well.


Well, in my opinion, UML 2.0 was a disaster. It added a lot of functionality to UML that was not really needed and packaged it in a specification that was poorly written and inconsistent, much worse than its immediate predecessor, UML 1.5. The UML community has been trying to recover from that self-inflicted blow for a decade. While UML 2.5 does not simplify the language itself, at least it brings the spec document to the level of quality it should have been at originally with UML 2.0. In effect, this was a refactoring of the specification that was necessary before any serious functional changes could really be made. But it may, indeed, be too little too late.


"Round-trip engineering" as Rational tried to do it in its tooling, never really worked. The idea that models were models of your code that you somehow had to sync back and forth at the most detailed level was fundamental level was basically wrong. If you are using a traditional programming language, models should be used as a vehicle for communicating things that are hard to see in the code -- big picture architecture, overall design, etc. (which seems to be pretty much how you are using it). If modeling (in UML or anything else) isn't helping you communicate something important better than if you didn't do the modeling, then it is, indeed, a waste of time.


Scott, the UML 2.5 finalization task force has completed. There will be no changes (other than editorial) between the current beta version and the formal version of the spec. (The current version is beta2, which I don't think is public yet -- but it still only has 14 diagrams.)

By the way, prior to UML 2.5, the UML specification actually consisted of two documents, the Infrastructure and the Superstructure. For UML 2.4.1, this was a total of 978 pages. So there really was a net reduction in pages.

Admittedly, the UML 2.5 spec does have more pages than the UML 2.4.1 Supstructure (748 pages). But that was largely from the addition of text to clarify semantics, examples and specification of diagram interchange -- all probably good things.


It was taken from my website:


There are no such diagrams in UML 2.5. These "new diagrams" are from my website:


Ed, I stand corrected. The October 2012 beta version of the UML 2.5 spec does in fact only describe 14 diagrams in it's 809 "simplified" pages. These diagrams are:
- Activity Diagram
- Class Diagram
- Communication Diagram
- Component Diagram
- Composite Structure Diagram
- Deployment diagram
- Interaction Overview Diagram
- Object Diagram
- Package Diagram
- Profile Diagram
- State Machine Diagram
- Sequence Diagram
- Timing Diagram
- Use Case Diagram

The other diagrams that I indicated in the article were culled from other postings on the web, either articles or blogs, discussing work in progress that has happened since the publication of the beta spec. Of course we'll have to wait and see what actually gets published to see if these new diagrams appear at all.


UML is just a horrible notation. It doesn't really express what you need. First what are we doing? Fundamentally, developing a succinct specification then transforming the specification into an algorithm (implementation). For that the best is expressing structure with BNF (eBNF), BNF is not just a language specification tool, but generally useful for any system structure. Then you want to express the state changes, which can be done in a state machine (state diagram or Harel's state charts, which are the only nice part of UML). REST incorporates state transitions for any one particular state (hence you don't need to specify the entire state machine in an interface specification). REST is thus very flexible. UML is anything but flexible and thus not usable in the vast majority of today's software development.

Then there is the idea of design by contract (DbC), which also expresses valid state transitions. UML overlooked this (as indeed most design techniques and interface specs do), but retrofitted it with OCL. Test-driven development is also lacking here - DbC is a much more comprehensive, neater and easier way to do it, since tests are automatically built in to you modules. DbC is built into BON (Business Object Notation) which is altogether a more tasteful and integrated diagramming technique than UML.

What we need in computing is to get back to basics, developing clean, simple, and well-structured systems. UML just takes us in completely the wrong direction.


Scott, I have never heard of the three new diagrams you mention. I checked the UML 2.5 spec, and they are not mentioned there as far as I can tell. There are actually 14 diagrams in UML 2.5 (not 16 or 19). See Annex A of the spec, Figure A.5.

I will agree that 14 is still more than anyone uses, but most do have regular users. Perhaps not Interaction Overview Diagrams (I don't even know if any tools really support that one...), but Composite Structure Diagrams are used quite a bit, for example they are central to a number of profiles, including SysML, SoaML and MARTE (for real time).

-- Ed


Scott, you sound like the child exposing the emperor's lack of clothes. I too was a big fan of UML and really looked forward to the "round-trip engineering" capability that never really seemed to materialize (at least in the C++ world). I didn't really care about the interoperability issue myself and would have gladly been loyal to one vendor who provided that capability at a *reasonable* price.

Today I find Doxygen provides all the UML structural analysis and design I need and TDD unit-tests provide all my behavioral analysis and design for most projects. After I've "doxygenated" a bunch of header files, I have my structural design and after I've completed the implementation in a TDD fashion, I have my behavioral design that I can run at anytime to verify my implementation. Introducing UML to a project adds too much in terms of time and tool costs for a marginally improved understandability and maintainability of the code base and a much larger quantity of material that has to be consistently maintained.


I expect a lot of folks are in the same boat. UML 2.0 was a good release, but it was already more than most people will ever use or need.


Scott, really good article. i've been using UML since its beginnings and I got certified in 2.0 but I found the complications put into the spec distracting. I still use the basics but I have never leveraged any of the functionality that the complicated spec was supposed to enable.