Appendix C. A History of UML
UML has not always been the de facto modeling language that it is today. In fact, not so long ago, everyone involved in complex system modeling was using a plethora of different modeling languages—some formal, some informal—and each had its own associated development approach.
Nowhere was the problem more apparent than in software modeling. Object orientation had just become a fully recognized technique for developing software, and it did not take long for new modeling methods to start incorporating this revolutionary technique into their practices.
Unfortunately, even though object-oriented software modeling was seen as a good thing, the mess of different and conflicting approaches to modeling cancelled out a lot of the advantages that modeling promised. If you were designing using one modeling language and another member of your group was using another modeling language, the advantages of communicating designs to each other were completely lost. Software and system groups were forced to pick a modeling language, knowing that their choice was potentially a dangerous decision that could exclude other groups from easily joining the design effort.
This time of confusion and chaos in the software modeling world is now rather dramatically referred to as the “method wars.” Three of the primary protagonists in these method wars were Grady Booch, Ivar Jacobson, and James Rumbaugh. Each of these innovators had their own software development methods and a modeling language with their own distinct notation. More importantly, they also headed up their own community of users that evangelized their approach to software modeling. It was these three approaches to software development and their associated languages and notation that were to form the basis of UML.
Take One Part OOAD...
Grady Booch’s approach was named Object-Oriented Analysis and Design (OOAD), or less formally, the Booch method. These grand titles encompassed a method that included a modeling language constructed of diagrams to show classes, state, state transitions, interactions, modules, and processes.
This formidable collection of diagrams was probably best known for its class notations, which were depicted as clouds and a selection of arrows with simple names such as has a that could be used to specify different types of inter-class relationships, as shown in Figure C-1.
The cloud notational style and the simple naming of Booch’s inter-class relationship arrows worked themselves into the hearts of adopters to such a degree that even to this day, they reminisce about the clouds. In fact the use of either the cloud notation or the rectangle notation for classes prompted some of the most vehement, and useless, arguments during the inception of UML.
...with a Sprinkling of OOSE...
Ivar Jacobson and his Object-Oriented Software Engineering (OOSE) approach is probably best known for the revolutionary technique of mapping requirements to object-oriented software designs, called use cases. There was a definite focus in OOSE to accurately capture and model the problem domain, and use cases were a key technique in achieving this as part of a requirements model.
OOSE was not just about requirements, though; it also had corresponding models for analysis and design. The analysis model in OOSE was one in which object relationships could be modeled. It drew distinctions between entity objects that contain data, control objects that control other objects, and interface objects that interact with users or other external systems. UML has inherited these types of objects, and they are particularly popular on sequence diagrams (see Chapter 7).
The design model allowed you to describe how the system behaves using state transition and interaction diagrams, which—although the notation has changed—are still present to some extent in UML today. Communication diagrams are covered in Chapter 8; state machine diagrams are covered in Chapter 14.
To complete the picture, the OOSE also specified implementation and test models. An implementation model captured how use cases were mapped to the underlying system implementation and the test model closed the loop by showing how use cases could drive the development of a system’s tests.
Despite all of these various models, use cases are the thing that OOSE will be most noted for; see Figure C-2 for an example. UML has gone through various iterations over the years, but of all the UML constructs, use cases is the one technique that’s remained unchanged.
...Add a Dash of OMT...
If Booch’s OOAD brought class modeling and Jacobson’s OOSE gave us use cases, state transitions, and interaction modeling, then James Rumbaugh added his object modeling technique (OMT). Although Booch’s class and object diagrams were well loved by his adopters (those clouds again), it was the class and object diagram notation from OMT that most influenced what was to come. The OMT’s notation for its object view was arguably simpler to draw, even if its interclass relationships were not as intuitive as Booch’s (see Figure C-3).
That is not to say that object and class diagram notation was all that OMT added to the mix. The OMT also had notation for diagrams showing the dynamic qualities of software, namely sequence diagrams.
...and Bake for 10 to 15 Years
It is not an understatement to say that the modeling world was in a mess (it was a war, after all!). The mere suggestion of a unified approach to modeling was likely to bring passionate objections as modeling practitioners protected their skills, tools, and—most importantly—approaches.
But it was time for a change. In early 1996, Ivar Jacobson gave Richard Mark Soley a call at home, late at night as always, and confirmed that the time was ripe to standardize on a modeling language and bring an end to the modeling method wars. At this point, the modeling tools market was worth about $30 million worldwide total, split among several vendors. The largest vendor was Rational Software Corporation, but even at this point Rational was only a $25 million company—small fish compared to software behemoths such as Microsoft and IBM.
As a first step, Soley and Jacobson made a list all of the major methodologists and invited them to come to an Object Management Group (OMG) meeting to explore the possibility of developing a standard. Little did they know just how important and successful that meeting would be. The OMG was traditionally a standards body that specifically targeted distributed systems; however, in an act of excellent foresight, the group organized its first meeting targeted at creating a standard modeling language Hosted by Tandem Computer in San Jose, California, almost every major methodologist or representative of every major methodologist made it to that meeting. According to legend, the organizers were very careful to leave all the windows open so that the room would not explode with the number of egos—it was a very impressive assembly. Early on, it was realized that the most difficult facet of the meeting probably would be finding the right person to chair it. They needed somebody who would be recognized as a methodologist, who was also sufficiently impartial and focused, and who could actually guide the meeting towards a useful conclusion.
Mary Loomis was that person. Back then, Mary was a research director at Hewlett-Packard, and she was on the team at General Electric that had developed the OMT methodology. Mary was the perfect person to keep all those egos in check. Very quickly, Mary managed to get all the gurus in the room to actually make progress toward an agreement. The goal was not a technical discussion about which technologies to use, or whether to draw a class as a box or a cloud, but to determine how to develop a Unified Modeling Language.
This is what the OMG brought into the mix. The OMG excelled at getting direct competitors to agree on issues, which was the most important aspect of getting to a Unified Modeling Language. Participants agreed that:
It was time for a standard.
They would attempt to use the OMG standards process to develop that standard.
These two simple goals were really an amazing achievement. At that point in time, the OMG had used only its standards process to develop specific distributed object computing standards, such as CORBA and its services. The OMG had never created anything like development standards, which is what a UML specification would have to be. Without a doubt, managing a community as passionate as the methodologists and, on top of that, building a successful standard that everyone could sign up for was new and hazardous territory for the OMG.
But the OMG was in the middle of a transition. During part of that transition, it recognized that one of the group’s biggest strengths was its standards process itself and not any specific technology. Following its process, the OMG developed and sent a requirements document to the industry that described precisely what was needed of a standard modeling language. It was then up to industry to send in their own ideas for how they could meet those requirements.
By the middle of 1997, the OMG had received what was to be an acceptable single joint proposal for a standard modeling language. Written by 21 different companies, this joint proposal was the product of a merger between each of those company’s own proposals. The whole process came to an end in September 1997 when the OMG published a specification for a standard modeling language, but there was a slight problem with its preferred name. The OMG had decided to name the standard modeling language the Unified Modeling Language, but UML as a name was already owned by one of the companies that had agreed to the original joint proposal—Rational Software Corporation.
Rational Software employed Jacobson, Booch, and Rumbaugh—collectively known as the three amigos—and had already given a huge amount of input into the development of the OMG’s standard, as well as continuing on with research toward their own joint specification for a modeling language. The Rational modeling language brought together the three amigos’ considerably popular methodologies and toolsets, but unfortunately it too had also been called the Unified Modeling Language.
It was crunch time; would the industry slip back into confusion with both the OMG and Rational’s UML, or would the OMG have to find a new name entirely and thereby lose any name recognition that the UML brand had already gained? As it happens, there was a particularly happy ending to this story. To solve the naming nightmare, the OMG achieved something that was nothing short of a coup.
The OMG were able to convince Rational, even though there was already some considerable marketing value to the UML brand, to donate at no charge both the UML name and the cube logo (see Figure C-4). This way, the OMG could go ahead with a truly open standard modeling language, which could officially be named UML.
For a couple of years afterward, people thought that only Rational was involved in the development of the UML specification, largely because the UML name and logo originated with Rational, and Rational Rose was the most popular modeling tool at the time. In fact, some companies did not want the standard modeling language to be called UML because they believed the public would continue to associate the UML name with Rational. Those fears have proved largely unfounded over time, and now more than 90 percent of practitioners recognize that UML is a standard owned and managed by the OMG.
UML has undergone several revisions as it evolves to accommodate various new industry advances and best-practice techniques. The original input from Jacobson, Booch, and Rumbaugh, although still very important, now happily works alongside the other full set of possible UML 2.0 diagrams, as shown in Figure C-5.
Systems development techniques, particularly software systems, are in a vibrant state of flux most of the time. This means that any unified approach to modeling software must be flexible and open to new approaches to still be of practical use; however, with UML, there is finally a common language for expressing your models.
Special thanks to Richard Mark Soley for all the first-hand anecdotes and explanations about how the OMG process worked and why it was ideal for standardizing UML.