A little history is needed as a preamble to understanding the UML and as a way to introduce a cast of
The context for the development of the UML was the increasing complexity of software as the 1990s
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-
intensivebusiness structures. (1991, 92)
Malone and Rockart focused on what they called the "networked computer" as the basis for the revolution-in-progress. They
[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
rememberednot 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
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
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
The distribution of applications and information in the guise of the Internet
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
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
There is one personal factor that
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
Similarly, through the '80s, object-oriented development was dominated by a cowboy
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
Ivar Jacobson surfaced
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
James Rumbaugh was, in some ways, the
Efforts to reach some
Is standardization desirable? Standardization is relevant to consider in the domain of object-oriented methods for two reasons. First, the existing diversity
fragmentsthe market and is a barrier to entry by all others than the usual early adopters and is a barrierto creating an industry of third-party vendorsthat help feed the core industry. Second, even given the diversity of object-oriented methods, there is apparent consensus in what should be modeledduring analysis and design. (Booch and Rumbaugh 1996)
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
hammerout 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
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
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
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
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.