How to use Unified Modeling Language in IT architecture diagrams

Diagrams, blueprints, and schematics are foundational elements in architectural design. Whether you're designing a hotel or an e-commerce system, you can't build something of any complexity without them. Yet, there are still many places in the software business where system diagramming is somewhat improvisational. This might be OK for coming up with ideas on the back of a napkin. Still, a more formal, detailed approach to diagramming is needed when it's time to turn an intriguing concept into an achievable architecture.

Fortunately, that formal approach exists. It's called the Unified Modeling Language (UML).

UML is not getting much attention these days on the front pages of popular technical sites. It should. UML provides a standard to describe software systems in a very detailed manner graphically.

This article provides a brief overview of UML's origins. In two companion articles, I offer a more detailed description of UML's particulars, including examples of the various diagram types it supports.

These articles are for a general technical audience. However, to get the full benefit from the parts that detail the different diagrams, it's helpful to have a general understanding of application programming and some knowledge of classes, interfaces, and objects.

How UML came to be

Some significant enterprise architects and application developers created UML because they got tired of the plethora of roll-your-own diagramming styles prevalent in the industry.

It seemed as if every company had its own way of diagramming systems. The variety of diagramming styles affected productivity and increased the cost of doing business. An architect changing jobs to a new company had to take the time to learn how the new company's diagrams worked and what they represented. This "getting up to speed" labor can incur significant overhead.

Thus came the impetus to create a standard diagramming format.

The motivation behind creating UML was to mirror the way structural architects use the same methods to draw building blueprints, making it possible for any construction company to put up a high-rise building designed by any architect. In the same manner, applying a standard to diagramming software would make it possible for any developer in any company to work on any system designed by any architect. Of course, this assumes all parties follow the same diagramming standard.

[ Learn how to navigate uncertainty within your organization. Download Culture matters: The IT executive's guide to building open teams. ]

In 1996, Rational Software developed the early version of UML under the authorship of Grady Booch, Ivar Jacobson, and James Rumbaugh. Each had already made significant contributions to the software industry with their own diagramming techniques. Their goal was to unify their work into a single standard and publish it as the Unified Modeling Language (UML).

In 1997, they submitted their specification to the Object Management Group (OMG) for adoption consideration. OMG is a nonprofit standards organization supported by some of the biggest names in technology, including Red Hat, Microsoft, Salesforce, and Toshiba.

OMG accepted the specification and, in November 1997, adopted UML as a standard.

The UML specification has gone through many version upgrades since its release. The current release is version 2.5.1, released in 2017 and runs nearly 800 pages in length. It's a big spec.

Exploring UML's details

In the world of software development, the devil is always in the details, and UML has a lot of details—more than I can cover in an introductory article. The most important thing to understand about UML is this: UML defines a standard set of diagram types and symbols you can use to describe just about any aspect of an enterprise architecture.

You can think of each diagram type as a formal graphical language, on par with hieroglyphics. As such, every aspect of the given diagram has a specific meaning. Each line and geometric shape means something special, and each arrowhead has a predefined meaning. There is no making it up as you go along. You're either "speaking" UML diagrams and symbols or not; the specification is that precise. However, the language is flexible enough to allow a variety of styles of expression using the symbols and diagram syntax the language specifies.

[ Find out how to use everyday tools to solve data management challenges at scale. ]

UML is indeed immense. Fortunately, you don't have to gobble UML up all at once. You can take it in pieces. The place to start is with understanding the two basic types of UML diagrams: static and dynamic diagrams.

Static versus dynamic diagrams

Static diagrams describe the state of a system—like a snapshot of a system in motion. Dynamic diagrams describe the system in motion. The figure below illustrates the organizational hierarchy of UML diagrams. Notice that the dynamic diagrams have an organizational hierarchy that is slightly different from static diagrams. The dynamic diagram type interaction does not represent an actual diagram. Instead, it defines a subset of diagrams.

Image

In two companion articles, I provide a detailed description of each of the diagram types. In one article, I describe and show the various types of static diagrams. In the other, I'll describe and show the types of dynamic diagrams. Read those articles to become familiar with the basics of UML diagramming.

Putting it all together

UML is a comprehensive yet daunting approach to technical diagramming. There are a lot of details in the specification that can take years to master. But, given the fast pace of IT in today's demanding world, many architects and developers don't have all the time necessary to master UML in its entirety. Fortunately, UML is flexible enough to implement it on a "take what you like, leave the rest" basis. You don't have to use all the symbols all the time. All you need to do is make sure the diagrams and symbols you are using conform to the UML conventions.

The important thing to understand about the benefit of using UML is that it's consistent. Remember, UML was intended from the start to be a way for architects and developers to describe systems in a uniform and consistent manner graphically. The creators of UML just got tired of the individual approaches to diagramming large-scale software systems that were commonplace throughout the industry.

At the least, UML provides a conventional way to describe systems so that you can understand them easily and quickly. The specification has been around long enough that those reading a UML diagram understand its meaning intuitively without incurring the overhead that goes with taking the time to learn a custom set of symbols.

As experienced enterprise architects know, a software system is only as good as the description—before coding begins. One misinterpreted symbol can result in implementation errors that can cost thousands of dollars and hundreds of work hours to rectify. The consistency and detail that UML offers can go a long way to ensuring that the system an architect designs is the system that gets implemented.