Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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.