I unearthed this report from an OOPSLA 1997 panel titled, “UML: the language of blueprints for software?” We panelists, John Artim, Viktor Ohnjec, Erick Rivas, Jim Rumbaugh, and myself, discussed potential benefits and drawbacks of this new modeling language, called UML, to describe software systems and prognisticated on how standardizing on notation might affect software development. UML stands for the Unified Modeling Language. UML was intended to be a “modeling language” containing all important constructs needed to describe your software design: class diagrams, sequence diagrams, component diagrams, state diagrams, deployment diagrams, use case diagrams, activity diagrams, and more.
At that time, I felt that the line drawn between software analysis and design was blurry. (And that that was a good thing). Analysis models express system requirements. The goal of design is to figure out and depict how the software is organized to support those requirements. Yet analysis and design artefacts seem like two distinct things.
Some—I put myself into that bucket—moved fluidly between analysis and design and coding. For design, I created practical descriptions of how the system was structured into networks of interacting objects—each with distinct responsibilities.
I also valued expressing requirements. Depending on what you needed communicate, we might write use cases. We commonly drew wireframes and workflow diagrams to illustrate expected system behaviors and user-system interactions. And wrote text to define constraints, processing details, and glossary definitions for concepts (that sometimes ended up in our software design as domain objects).
The requirements or the design of a software system need not have a singular focus. If data is important, by all means it needs to be described. When system state (or control of a stateful process) is important, state machine models or event flows can represent how the system should operate.
I encouraged our consultants and clients to create the appropriate descriptions for what was required of their software system. One approach wouldn't work for all situations. But with all these options, I didn’t want us to lose sight of the importance of thinking about and then describing how elements of the software worked together. That was the impetus behind responsibility-driven design.
The panel was held the first week of October, 1997. The Object Management Group (OMG) adopted UML 1.0 (the Unified Modeling Language) standard in November, 1997. At the time, the OMG’s mission was, “to promote the theory and practice of object technology for the development of distributed computing systems. The goal is to provide a common architectural framework for object oriented applications based on widely available interface specifications.”
The OMG’s mission today is more broadly, “To provide a neutral forum where best practices from a wide range of fields can be discussed and standards can be generated that drive the adoption and innovation of cutting-edge technology spanning industries worldwide.” Succinctly, the OMG is in the standards making business.
Let’s take a close look at how we panelists viewed UML…
John Artim worried about the mismatch between methodologies and the modeling capabilities offered by UML:
“With Responsibility Driven Design and Object Behavior Analysis, among others, preferred by a significant number of practitioners, larger projects will, based on methodological preference, continue to experience communication issues and outright schisms among colleagues. Until the strengths and semantics of these complementary notations and methods have been incorporated into UML, it will remain difficult to unite a diverse group of practitioners behind UML.”
His concerns were spot on. If something wasn’t in UML, well, then, how did it fit in with the rest of those “standard” diagrams. Over time, analysis or design representations that weren't part of UML came to be discounted or ignored, and eventually forgotten.
Several panelists were concerned that the OMG standardization process excluded practitioners’ inputs. Indeed, OMG is a membership organization and it is those members who drive the standardization efforts. Voting members tend to be consultancies or tool vendors who have a vested interested in driving standards in directions that support their commercial interests.
The company I worked for at the time, ParcPlace-Digitalk, although an OMG member, wasn’t willing to participate in actively shaping the UML standard. ParcPlace-Digitalk viewed themselves as being in the software programming language and IDE business. Our software consultancy and training group existed primarily to support our customers who bought our platforms. Although my work on responsibility-driven design and Adele Goldberg and Kenny Rubin’s work on object behavior analysis were recognized by management as being unique, they were viewed as mainly something to support our customers. Analysis and design methodology or notations were not recognized as important in their own right, independent from our Smalltalk programming language platform.
From its inception UML was a large language. Jim Rumbaugh asserted, “We have structured the core concepts of UML to be straightforward; however; users of most popular methods SHOULD learn enough in a day to continue working productively in UML.”
Sure, you only need a subset. But one confounding aspect of UML was that you could create a valid UML diagram and show more or less precision and detail. For example, just because there were three compartments you could depict to represent a class didn’t mean you were required to use them all. Legit UML class diagrams can show classes which only include the class name, classes with two or three compartments containing the class name, and some or all of its attributes and operations (see the slide below).
An optional embellishment is to indicate visibility of those attributes and operations. Relationships between classes can be shown, too (again, in more or less detail). And classes optionally can have stereotypes.
It’s all a matter of what you as a designer want to convey and emphasize.
There isn't a single “right” way to draw a UML diagram.
If you think of a class diagram as a detailed “blueprint” to be exactly followed during implementation, lack of details or misleading details can be frustrating. If the diagram has errors, you suspect the entire design.
On the other hand, if you view UML as means to express something interesting about your design, then you could freely use it to sketch design ideas. And be happy to only include those details that you think are critical to understand. UML used this ways is a tool for communicating or reasoning about a design, not for drafting detailed design blueprints.
The confusion about what to include and why you might want to, led me to develop courses I taught to industrial clients on The Art of Telling Your Design Story and Practical UML. Some of my students were thrilled that they didn’t need to include every detail in a sequence or class diagram; others felt deceived when diagrams lacked the details they wanted to see. That was (and still is) a big problem.
At the panel I also worried that:
“UML does not address many intrinsically, non object-oriented details about systems that are important to model….nor does it particularly well describe dynamic relationships between objects, patterns, algorithmic hot-spots, event models, object subassemblies or subsystems, Bertrand Meyer’s notion of contracts, invariants, business rules, or many of the artifacts of our own Responsibility-Driven Design process.”
Indeed. UML didn’t support everything worth describing about a software system.
From its inception, there was a large gap between what UML was capable of expressing and what architects, designers and developers wanted to show or needed to understand about their system. Although object technology was gaining prominence, structured analysis and design methods were also in use and people were still implementing software in functional or procedural languages. So how did other (non-oo) descriptions fit with UML? Short answer: They didn’t.
I was right about what UML lacked, yet hoped that the UML would grow and adapt with use:
“UML shouldn’t be burdened with having to be all things to all people for all times. I hope UML continues to remain a living language, adapted by people to create new modeling idioms appropriate to the task at hand.”
Key to UML’s continued utility would be the ability to define reasonable subsets and recognizable extensions. Indeed, later versions of UML allowed for that.
However, with the rise in popularity of Agile software development in the 2000s, UML, rightly or wrongly, got pegged as being the epitome of upfront design and analysis descriptions. Those descriptions are commonly viewed by many agile developers as being out of step with the current implementation. To them, design documentation independent from the code has little value. And since their focus is on delivering working code, they rarely see a need for UML.
And so, today, UML literacy is at a low point. Computer science students may learn some basic UML in a software design or engineering course. But this doesn’t translate to on-the-job use.
Some software architects or designers may produce UML diagrams or other design artifacts. What they create depends on their company culture. However, UML is largely irrelevant to most developers who perceive it as quaint, overly focused on object-technology, and too heavy weight for day-to-day use. UML is more like Esperanto than a vibrant living language.
Did standardizing on UML notation stifle design innovation? Well, no. Over time, software development has sorted out into those who buy into brand name methodologies and tools and notations, and those who mostly take a code-first approach. But the need to effectively communicate both essential details and nuances of complex software systems has never been greater. There's room for continued innovation.