Deployment Diagrams – Communication Paths

I have found the concept of communication paths in UML deployment diagrams to be quite frustrating for the simple reason that a communication path connects two deployment targets and no more than two. In other words, communication paths do not support the familiar concept of a “bus” / LAN / “high-speed backbone” to which multiple devices are connected.

As a result, while deployment diagrams are very expressive when it comes to portraying devices and nested execution environment and deployed artifacts, when it comes to showing connectivity between devices, they fall short.

After living with this problem for a long time (I pretty much stopped illustrating connectivity between devices), I hit upon the simple idea of modeling a “bus” / LAN / “high-speed backbone” as a node (not a device). This way, I am now able to connect multiple devices to this “bus” / LAN / “high-speed backbone”!

Structure of Deployment Models

Deployment models, while being very expressive, are not easy to organize and manage. Any non-trivial deployment model would require a multitude of devices, execution environments and artifacts (and multiple instances of these) which typically makes the organization of a deployment model somewhat hard.

The following package diagram represents a typical model organization that I have found useful in the J2EE space:

Advanced Unified Modeling Language Tutorial

Since the turn of the millennium, I have been experimenting with the Unified Modeling Language to see how effective it really is in documenting software architecture and design. With the release of UML 2.0 in 2007 (and as a results of all the practice that I have had over the past seven years), I am fully convinced about the expressive power of UML. It is now eminently possible to capture the ideas and essence of software architecture in crisp and clear UML diagrams.

Of course, this requires significant maturity in the art of “modeling” (i.e. the art of taking real world concepts and representing them in the object-oriented computer world) and to a lesser extant requires mastery over the capabilities of UML 2.0.

Every software professional has, at some time of other, tried his / her hand at class diagrams and sequence diagrams, but the real power of UML lies in diagrams other than these. Some of the lesser known (and more powerful) UML diagrams are – package diagrams, component diagrams, deployment diagrams, and composite structure diagrams. Even the sequence diagram has been upgraded with some elegant new constructs that raise its expressive power a couple of notches.

If the average software professional learns to use these diagrams effectively, it will go a long way in halting the commoditization of the software profession.

Having said that, I need to reiterate the point that maturity in the art of modeling is essential for effectiveness and that comes only with time and practice.

“Practice makes perfect, gonna get it right,
gonna get it right,
One night at a time”

– George Strait

Over the next few days I will post some examples of the power of these diagrams (see Pages on the right). Most of my examples will come from the Insurance (P&C and Health) space, but since this space is relevant to all and is intuitive, I hope my readers will not have much trouble understanding them.

Next