2.2 Roots

A little history is needed as a preamble to understanding the UML and as a way to introduce a cast of characters.

The context for the development of the UML was the increasing complexity of software as the 1990s began. Mainstream technology couldn't cope with a networked and information-driven world. Rigid organizational boundaries started to leak like the proverbial dike in the face of desktop interactions, virtual connections, and an event-driven competitive environment that demanded more, faster.

In 1991, Thomas Malone and John Rockart provided a picture of the expectations that were beginning to appear everywhere:

The industrial economies are now in the early stages of another transformation that may ultimately be at least as significant as the Industrial Revolution The revolution underway today will be driven not by changes in production but by changes in coordination. Whenever people work together, they must somehow communicate, make decisions, allocate resources, and get products and services to the right place at the right time These new technologies will enable people to coordinate more effectively, to do much more coordination, and to form new, coordination-intensive business structures. (1991, 92)

Malone and Rockart focused on what they called the "networked computer" as the basis for the revolution-in-progress. They emphasized that the term computer was becoming misleading because it suggested a machine for calculating and processing information:

[T]his image of computing does not capture the essence of how computers are used now and how they will be used even more in the future computers and computer networks may well be remembered not as technology used primarily to compute, but as coordination technology. (1991, 92)

Meanwhile, the object-oriented approach was sputtering at the starting gate it was the little engine that could, but usually didn't. The object-oriented languages scene was a gang war landscape, cluttered with acronyms. Compared to their structured brethren, object-oriented methods and development processes were skeletal at best blinkered, inconsistent, and shallow.

Members of the object-oriented fraternity like to see the success of objects as fated, and they view the UML as an element of that inevitable success. From the broader perspective of mainstream computing as defined in the Fortune 500, the picture is a little different. For most big organizations, object-orientation has been an alien force.

As recently as the early years of the '90s, big organization managers were used to the comforts of a few common languages, a relatively homogeneous technology, and a semi-standard development process (the "waterfall"), which was manageable even if spectacularly unsuccessful.

Objects provided none of these comforts, and the perception was that few of the significant object-oriented development efforts demonstrated any real advantages for object-orientation over other, more mainstream approaches. As late as 1993, the Sloan Management Review from MIT had a paper that proclaimed: "(O)bject orientation has low prospects for becoming dominant in large in-house IS organizations" (Fichman and Kemerer 1993, 21). Only a major upheaval would change their world.

The distribution of applications and information in the guise of the Internet phenomenon Rockart and Malone's "networked computer" was, of course, the comet that disturbed the evolutionary equilibrium of the development world. It created what paleobiologist Elizabeth Vrba calls a "turnover pulse" (discussed in Eldredge 1999), which shattered the static rut that information technology had settled into. It also provoked the "speciation" of new technologies, including languages and methods. It created the need and the opportunity: customers wanted the capabilities promised by the new, but the old ways of development couldn't do the job.

Of course, the old ways included the old ways of doing object-oriented development. Change affected the object-oriented community just as much as the mainstream. However, the opportunistic speciation of object-orientation was profoundly advantageous and has resulted in real benefits. The meteoric rise of Java, the standardization of C++, components, the birth and rebirth of CORBA, and the emergence of pattern languages for software design are all results of the changed technological and business ecosystem that dawned with the '90s as is the UML.

2.2.1 Key Players

Another way to understand the development of the UML is in terms of the key players and their roles. Unlike the development of patterns, commercial rather than personal interests drove the development of the UML. Therefore, the personal interactions that formed the backdrop are less significant for our purposes. (For anyone interested, UML Distilled, by Martin Fowler, Kendall Scott, and Ivan Jacobson [1997] has a terrifically wry, wonderfully personalized account of the way the UML emerged from its cocoon.)

There is one personal factor that warrants mentioning, though. It incidentally provides a further comparison with the mainstream. Structured Methods, plus its competitors and variants, resulted from the growing maturity of both the technology and the people in the computer industry in the '60s and '70s. By then, the mainframe world had its own period of heroic hacking and cowboy programming. When software design was a back-of-the-envelope affair, having a personal coding style was a matter of pride; amphetamine-driven, all-night work sessions got the code out; and documentation was non-existent.

The work of Edgar Djykstra in combating the results spaghetti code and unmaintainable programs and the notion of structured programming were milestones in the maturing of mainframe software development. The industry discovered that cowboy programming produced downstream maintenance costs, which were all out of proportion to the original development costs.

As with nuclear power, the initial infatuation with a new technology was replaced by a more seasoned assessment of the long-term costs and benefits. At the same time, as programming and programmers matured, the population of programmers grew and broadened; and communication, training, and control became concerns for business management. The need for a more disciplined approach to development encouraged the creation of methodologies and modeling systems but not yet modeling languages.

Similarly, through the '80s, object-oriented development was dominated by a cowboy mentality, which was further emphasized by the availability of interactive programming tools and the lack of a workable, consistent development process that could provide discipline. Young "techies," pioneering in unknown terrain dominated object-oriented development.

But, as happened in the mainframe world, the commercial realities of development, combined with an increasing personal maturity on the part of the high-profile players in the field, provoked a sea change in attitude. And, as was the case with Structured Methods, a few key players personified the change and provided its leadership. The three players who are most visible in all this are, of course, the "Three Amigos" of the UML: Grady Booch, James Rumbaugh, and Ivar Jacobson. Booch is arguably the methodology granddaddy of the bunch. (I have already mentioned him as a force in the emergence of patterns.)

In the early '80s, Booch introduced the phrase "object-oriented design," notably in his book called Software Engineering with Ada(Booch, Bryan, and Petersen 1993). The book also introduced many of the themes that later object-oriented methods would mine and refine. Based on training courses, which then-Captain Booch and a fellow member of the US Air Force Major Dick Bolz developed for the Air Force Academy in 1979, the book was primarily aimed at programming-language issues rather than system design, but it had a software engineering flavor.

Even then, Booch combined many of the better ideas, which were floating around about how to develop software-using objects, and packaged them with a notation and guidelines into a "lifecycle process." His models were the newly minted Structured Design approaches, which were becoming popular (Berard 1998).

By the late '80s, Booch had left the Air Force and eventually joined Rational Software Corporation. He brought an evolved Booch Method with him, along with his understanding of a need for a formalized approach to design that included a consistent notation.

Ivar Jacobson surfaced publicly a little later than Booch. In 1986 and 1987, he presented papers on object-oriented design at OOPSLA, based on his experience in developing real-time systems in Sweden. A key to his thinking was the notion of taking a black-box approach to design hiding the complexities of the system as a design technique. In his technique, use cases provided the ultimate black box, allowing for a specification of behavior that didn't get muddled by a description of how the behavior was implemented. Instead, the view of the user drove the modeling. They also provided a real way to document requirements and discipline the development so that it was traceable back to what the user wanted.

By the early 1990s, Jacobson's use cases were already being incorporated into a variety of methods, filling a gap that was perceived to exist in the standard design approaches (such as the Booch Method). Jacobson was also contributing an emphasis on models as the core of systems development. As Jacobson put it, "System development is a process of model building" (1995, 309).

James Rumbaugh was, in some ways, the latecomer to the party. While working for General Electric during the '80s, he authored a number of papers that were typically concerned with a data-centric view of object-oriented design. His influence was substantial, however. In 1991, he published (along with the inevitable et. al.) what became the book on object-oriented development,Object-Oriented Modeling and Design (Rumbaugh et al. 1991). The book was the basis for the Object Modeling Technique (OMT), which Rumbaugh popularized. It provided more of a middle ground between Structured approaches and object-oriented design, compared to Booch or many of the other object-oriented methods that were around at the time.

Efforts to reach some sort of unification or standardization of methods had been attempted occasionally during the early '90s but without success. In 1993 and early 1994, the OMG tried to standardize the methods but was roundly criticized for the attempt. Booch even attempted an informal rapprochement but was also unsuccessful. He felt the time was ripe:

Is standardization desirable? Standardization is relevant to consider in the domain of object-oriented methods for two reasons. First, the existing diversity fragments the market and is a barrier to entry by all others than the usual early adopters and is a barrier to creating an industry of third-party vendors that help feed the core industry. Second, even given the diversity of object-oriented methods, there is apparent consensus in what should be modeled during analysis and design. (Booch and Rumbaugh 1996)

He threw in a couple of significant caveats, though:

What than can be standardized? The most obvious target of opportunity is a common object-oriented analysis and design notation. It is entirely inappropriate to try to standardize upon process. How should standardization proceed? The right way to consummate a standard is through a formal standards body, but using that body to hammer out a standard is entirely wrong. Standards wrought by such impersonal bodies are often entirely void of relevance to the real problems of software development. (Booch and Rumbaugh 1996)

Just before that OOPSLA, Rumbaugh made the dramatic announcement that he was leaving General Electric to work with Booch at Rational. He did this, as he explained, to unify their two methods and despite the apparent qualms expressed by Booch.

Rumbaugh expressed his own version of qualms about standardization at OOPSLA: "I am 'for' convergence and 'against' standardization. I think 'standardization' of object-oriented methodologies now is undesirable and unnecessary." He felt the marketplace would sort out the methods wars and added, "In two years the dust will have settled, a few methods will be clear leaders, and there will be a general (if not universal) consensus about certain core modeling concepts" (1996). He was particularly critical of anything done via committee, which he said would "likely produce an inelegant hodgepodge that cuts the heart out of each methodology. Even a panel of methodologists is still a committee subject to the same pressures" (1996).

Rumbaugh admitted that the differences between the two methods were in no way as great as their own self-interests had made them appear (Rational Software Corporation 1995). And their self-interests were substantial. Booch and Rumbaugh had the majority (possibly 85 percent) of the object-oriented method market share by 1994, with Rumbaugh's OMT being the clear leader. However, Jacobson also had a method, and his popular and influential use cases were being adopted by a number of methods, Booch and OMT included.

Their initial Unified Method, identified as version 0.8 of the unified process, was released at OOPSLA. Then, Jacobson joined the unification effort because Rational purchased his Objectory process. So, in a typical act of male bonding, the Three Amigos were born (named after a forgettable comedy of the late '80s and an earlier Disney cartoon).

Difficulties in merging the three processes and time pressures resulted in a switch from producing a Unified Method to the easier target that Booch proposed at OOPSLA: a UML. With this new rubric, Rational released the 0.9 revision in June 1996. After another six months of intense effort involving public feedback, the 1.0 spec of the UML was released for publication in January 1997.

At this point, the final character in the UML drama emerged: the OMG returned to active status. Independently, they formed a task force for standardizing a method and a notation, and several organizations submitted proposals. A consortium of key object technology users and vendors was formed to define a 1.0 specification.

In the end, a UML proposal was hammered out, combining the September 1997 release of Rational's UML 1.1 and some revisions by the OMG. Confusingly enough, the final product was named UML 1.0.

In an ironic twist, the ongoing evolution of the UML is now in the hands of a number of OMG Committees, one of which the Revision Task Force, has Jim Rumbaugh as a very visible and active participant.