What's good about UML

by Niranjan Ramakrishnan

To paraphrase Stephen Colbert from his recent speech, where he said something about that government being best which governs least, one reason I like UML is because of the large number of things on which it is silent. Instead of coming up with impossible figures for every conceivable need, it has contented itself with a few diagrams, and left the door wide open for text. Notes is one example. Constraints is another. Both can be written up. As is the idea of elaborating use cases, of which more below.

UML is very good about making visual the structural connections between classes. The Object Model Diagram is elegant, a pleasure fully discernible only to those who have lived through the era of Boochian clouds. The idea of breaking down all connections between classes/objects into subtyping, association, aggregation or composition is clean and simple. Rearranging these relationships is also relatively easy.

The State diagrams are similarly natural. This is a natural outgrowth of Harel's Statecharts of old and the state transition diagrams of systems theory. I love the way states can be fitted within superstates, and putting the resulting arrangment into an object model. This forms the State design pattern, whose benefit is to offer a surrogate class hieararchy for state-dependent behavior, without having to subject a class to the harrowing experience of choosing to align along one axis of behavior or another. Yes, you can have it all (in this case).

The places where UML is weakest, in my view, are all related to the historical weakness of all such attempts, the efforts to capture algorithmic logic in pictures. From the oldest days of the flowchart (an old professor of mine used to remark that it was easier to write the program than it was to draw the flowchart!), this has seemed more trouble than it was worth, Still, it is invaluable to have a documentation of which classes interact in the process of executing a use case, and in what sequence. The Collaboration Diagram actually combines the Object Model Diagram with the elements of algorithm to give a sense of both the structural and procedural interconnections. This is a contribution from HP's old Fusion Methodology. However, it is rarely used any more, and in my 9 years of teaching UML, I have come across almost no organization that prefers Collaboration Diagrams to Sequence Diagrams.

Activity Diagrams are an afterthought, and were not part of the original release of the UML, if memory serves. They were introduced when it was discovered that the UML was a popular tool for modeling workflow. Their chief contribution is to provide a way to explore parallelism in workflow execution. A further afterthought was to introduce the so-called 'swimlanes' to accommodate objects. They are used as a brainstorming tool at the beginning of the project, and as a documentation tool at the end.

We have left out the first of all the UML diagrams -- the Use Case Diagrams. My own experience is that the diagrams are more historical than useful. After all, how much benefit is drawn from pointing out that such and such an actor calls upon such and such a use case? Still, for whatever it is worth, it may provide a bird's eye-view of the entire project. This is hardly to say that the use case exercise is without value. Far from it. The benefit of the use case exercise lies in the elaborations, namely, the writing down of the pre and post conditions and exceptions that lie in the path of a use case. This exercise provides an low-budget preview of what lies ahead in the logical progression of the application.


Reference Courses:

Object-Oriented Analysis and Design - Using the UML
Object-Oriented Design Patterns

Archives: See PSJ Archives