UML: The Unified Modeling Language

What the Unified Modeling Language (UML) Is and Isn't

• What UML is: A tool that provides a graphical notation for expressing software concepts, including object-oriented designs, and communicating them to others.
• What UML is not: A tool for describing how to develop object-oriented software.

A Brief History of UML and the "Three Amigos"

• Various OO modeling languages started to appear between the mid-1970s and the late 1980s. These were the so-called "first-generation" modeling languages.
• The number of modeling languages and methods increased from fewer than 10 to more than 50 in the period from 1989 to 1994.
• The so-called "method wars" broke out between various groups and individuals, with each one hyping their own approach.
• Users began to tire of the "method wars", and long for a broadly-supported, general-purpose modeling language.
• In the mid-1990s, three of the major approaches start to converge:
  • The "Booch method", from Grady Booch of Rational Software
  • OMT (Object Modeling Technique), from Jim Rumbaugh at General Electric
  • OOSE (Object-Oriented Software Engineering), from Ivar Jacobson at Ericsson
• At the OOPSLA95 Conference Rumbaugh and Booch joined forces and started the process that eventually led to the "Unified Modeling Language", or UML.
• In 1996 Jacobson got on board with Booch and Rumbaugh. These three individuals became known as the "Three Amigos".
• During the next few years, UML became an amalgam of their various approaches, along with some other ideas, underwent further development, and eventually was endorsed by the OMG (Object Management Group) on November 17, 1997.
• In mid-2001 UML Version 2.0, which represented a major upgrade, was released, and was eventually approved in 2003.

Various Views of a System

• User View
  The question here concerns the various scenarios that will be executed by human users and/or external systems? That is, the interest is in what will happen, but not how it will happen. [Example: Use cases can be used to model the scenarios.]
• Structural View
  The question here concerns the static aspects of the system (the classes and objects, and the relationships among them, that are deemed necessary after examining the vocabulary of the problem domain [Example: one class inherits from another class.]
• Behavioral View
  The question here concerns the dynamic aspects of the solution, including interactions and collaborations of the various parts of the system. [Example: One class provides data to another class.]
• Implementation View
  The question here concerns the structural and behavioral aspects of the actual "realization" of the solution. [Example: a "component" might consist of several interacting classes.]
• Environment View
  The question here concerns the structural and behavioral aspects of the "environment" in which the solution is ultimately realized. [Example: One part of the software must be on a server, and another part must be on a client.]

The Major UML Diagrams (prior to UML 2.0) (in alphabetical order)

• Activity Diagram
  Shows the flows among activities associated with a given object.
• Collaboration Diagram
  Shows the organization of the objects that interact using a given set of messages.
• Component Diagram
  Shows a collection of related components. (A "component" is a physical and replaceable part of a system that conforms to, and realizes, a set of interfaces.)
• Deployment Diagram
  Shows a collection of "nodes" in the deployment structure, as well as the dependencies and associations of those nodes. (A "node" is a piece of hardware that represents some kind of computational resource.)
• Sequence Diagram
  Shows the time ordering of messages that go back and forth between objects.
• Statechart Diagram (also called a State Diagram)
  Shows an object's "state machine", which is just a fancy term for a combination of the following:
  • The states an object can assume during its life.
  • The events to which that object can respond.
  • The possible responses the object can make to those events.
  • The transitions that occur between the object's states.
• Static Structure Diagram (includes the Class Diagram and the Object Diagram)
  Shows classes and the various relationships in which they are involved (or specific objects and the relationships in which they are involved).
• Use Case Diagram
  Shows "actors" and "use cases" in such a way that
  • The actor that "executes" a given use case usually appears on the left-hand side of the diagram.
  • The use cases themselves appear in the center.
  • Any other actors involved in a given use case tend to appear on the right-hand side.
  • Arrows show which actors are involved in which use cases.

Some UML Notational Features to Remember

You should be familiar with the following notational features of UML that show up in various diagrams, in class diagrams in particular:

• The public, protected and private members of a class are indicated, respectively, by a preceding +, # or - sign.
• Different styles of arrows (arrow shafts and arrow heads) indicate different relationships between classes, as illustrated in the following diagram:

  

• The different possible multiplicities (the number of things involved in a relationship) and their symbols, are summarized in the following table:

  Symbol	Meaning
  1	Exactly 1
  4, 7, 9	Exactly 4, exactly 7, or exactly 9
  0..1	Zero or one
  3..7	A value in the range from 3 to 7, inclusive
  *	Zero or more (an unlimited number)
  0..*	Same as above
  1..*	One or more

Microsoft Visio

Microsoft Visio is one of many tools that can be used to draw UML diagrams. Any of the diagrams mentioned above can be drawn using this tool, along with lines, arrows, multiplicities, and other features to help us understand the relationships between the entities in these diagrams. There is also a free MS Visio viewer that can be downloaded and installed from Microsoft's site. It cannot produce Visio diagrams but it can view diagrams that have been produced with the full program.

List of All Topics