UML  «Prev  Next»

Why was UML created?

The UML was a milestone in the history of software methodologies, and represented a continuum of change in software development techniques. The UML was created out of controversy over the best methodology to use to develop and specify software. Dozens of methods were and are in use, each with a loyal following. Unfortunately, many of us were forced to choose between these warring factions and bear the overhead and frustration of finding software tools and training.

Three Amigos

In 1994, Grady Booch and James Rumbaugh, the two market share leaders in object-oriented (OO) software methods, formally joined forces to develop a notation standard. A year later, they published the Unified Method version 0.8. Ivar Jacobson, yet another of the most noteworthy names in OO development, joined the team. The team of Rumbaugh, Booch and Jacobson were soon after referred to as the "three amigos" within OO circles.

OMG RFP

At the same time, the Object Management Group (OMG) was establishing the Object-Oriented Analysis and Design OOA Task Force.
In June 1996, the task force issued a request for proposal (RFP) for a standardized metamodel and technology to support the exchange of CASE tool models. This was an important first effort in developing a standard for specifying software systems and working toward an end to the notation wars plaguing our industry. The RFP allowed only CASE tool vendors responsible for implementing the standard to sponsor proposals.
By October 1996, a number of leading CASE tool manufacturers, including IBM and Microsoft, had partnered with Rational Software to sponsor the UML proposal to the task force.
In November 1997, the OMG formally approved the UML version 1.1. In the next lesson, the UML specification will be discussed.

Purpose of Notations

Notations enable us to articulate complex ideas succinctly and precisely. In projects involving many participants, often of different technical and cultural backgrounds, accuracy and clarity are critical as the cost of miscommunication increases rapidly. For a notation to enable accurate communication, it must come with well-defined semantics, it must be well suited for representing a given aspect of a system, and it must be well understood among project participants. In the latter lies the strength of standards and conventions: when a notation is used by a large number of participants, there is little room for misinterpretation and ambiguity. Conversely, when many dialects of a notation exist, or when a very specialized notation is used, the notation users are prone to misunderstandings as each user imposes its own interpretation.
UML provides a spectrum of notations for representing different aspects of a system and has been accepted as a standard notation in the industry. In this module, we first describe the concepts of modeling in general and object-oriented modeling in particular. We then describe five fundamental notations of UML that we use throughout the course:
  1. use case diagrams,
  2. class diagrams,
  3. interaction diagrams,
  4. state machine diagrams, and.
  5. activity diagrams
For each of these notations, we describe its basic semantics and provide examples. We revisit these notations in detail in later modules as we describe the activities that use them. Specialized notations such as UML deployment diagrams are introduced later.

Goal of UML

The goal of UML is to provide a standard notation that can be used by all object-oriented methods and to select and integrate the best elements of precursor notations. For example, UML includes the use case diagrams introduced by OOSE and uses many features of the OMT class diagrams. UML also includes new concepts that were not present in other major methods at the time, such as extension mechanisms and a constraint language. UML has been designed for a broad range of applications. Hence, it provides constructs for a broad range of systems and activities (for example, distributed systems, analysis, system design, deployment). System development focuses on three different models of the system.