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.

We can summarize those two points by saying that UML is concerned with description, and not with process.

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.
• Version 2.5 was approved in June, 2015.

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.]

Some of the Major UML Diagrams (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.

More on UML Class Diagrams in Particular and How They Represent Class Relationships

If if you are not working in a "software production environment" and making day-to-day use of UML, it may still be very helpful to employ one or more of the above diagrams to assist your own understanding of the software you are developing and enable you to better discuss the development and any problems that arise with others. Of particular use by almost anyone working with object-oriented (or just object-based) code is the Class Diagram, so here are some further details about those:

• A UML Class Diagram is a "box" or "rectangle" containing three compartments: the top one for the class name, the middle one for a list of the data members and the bottom one for a list of the class methods.
• The amount of information in the middle and bottom compartments will depend on your current needs. In the beginning a Class Diagram may contain only the name of the class, with the other two compartments being empty.
• The public, protected and private members of a class are indicated, respectively, by a preceding +, # or - sign.
• Any non-trivial program will generally involve several (and possibly many) classes, and those classes will necessarily have different kinds of "relationships". It is important to have some sense of the various possibilities:

  Inheritance (or "generalization" as you go up the hierarchy, "specialization" as you go down)
  Inheritance is an "is-a" type of relationship, or an "is-a-kind-of" type of relationship. An alternate (and perhaps better) conceptual model may be to think of it as a "may-be-substituted-for" relationship (if you're going up an inheritance hierarcy). Or, if you are going down an inheritance hierarchy you can think of inheritance as a "may-be-replaced-by" relationship.

  Examples

  • A Student "may be substituted for" a Person because a Student "is a" Person.
  • A Person "may be replaced by" a Student because, once again, a Student "is a" Person.

  Inheritance can be one of two types: Class Inheritance or Interface Inheritance. Inheritance is a parent-child relationship in which we create a new class (or interface) by using existing class (or interface) code. It is just like saying that "A is a type of B".

  Examples

  • We might say, "An Apple is a type of Fruit."
  • Or we might say, "A Ferrari is a type of Car."

  Many classes can inherit from a single class, but no single class can inherit from (extend) more than one class. However, interfaces are not classes, so an interface can inherit from (extend) more than one other interface.

  Association (of which Composition and Aggregation are Special Cases)
  Association is the most general of class relationships and encompasses pretty much any "logical connection" or "working relationship" between classes. Association can also model the idea of "containment" (the "has-a" type of relationship), in the sense that it establishes a "structural" relationship between two classes in which (at a minimum) an object of one class is "connected" to an object of another class, generallly by having a reference to that other object as one of its member variables. An association relationship can be one-to-one, one-to-many, many-to-one, or many-to-many (see the table of "multiplicities" below). In such a relationship either one object "works for" another or two (or more) objects work for each other, or "cooperate". The different objects involved may or may not exist independently of one another (that is, each object may or may not have its own lifetime), and this is where the distinction between a relationship that is "just association" as opposed to the more specific composition or aggregation comes into play.

  Examples

  • A Person "borrows from" a Bank.
  • A Student "eats at" a Cafeteria.
  • A Teacher "instructs" a Student.

  Composition
  Composition is a special kind of Association which directly models the "has-a" relationship (sometimes referred to as an "is-a-part-of" relationship) and represents "strong containment" in the sense that we have a whole/part relationship in which the whole and its parts "come and go as one". Using composition generally means means using instance variables in a class that are objects of other classes. In the composition relationship both entities are interdependent, and sometimes one object may be thought of as the "owner" of another.

  Examples

  • An Engine "is part of" a Car (a Car "has an" Engine). When a car goes to the dump, so too (usually) does the engine.
  • A Heart "is part of" a Body (a Body "has a" Heart). When a body dies, so too (usually) does the heart.

  Aggregation
  Aggregation is also a special kind of Association which also models the "has-a" relationship, but represents a "weaker containment" than that of Composition. Aggregation is more of a one-way association in which the whole and its parts do not "live and die together".

  Examples

  • A Student "has an" Address, but an address need not be related to any student.
  • A Bank "has a" Customer, but either can die and the other can quite happily carry on.
  • A Car has a Passenger, but either can disappear without any effect on the other
  • .

  Dependency
  Dependency is the relationship in which one class object depends on another class object's specification. This typically occurs when an object of one class "uses" an object of another class (as a method parameter or a local variable, for example, but not as an instance variable), and a change in the specification of the class being used will typically require an update to the dependent object's class.

  Examples

  • A Purse class may depend on (i.e., "use") a Coin class in order to compute the total amount of money contained in a Purse object. If the interface to the Coin class is changed in some way, then one or more methods in the Purse class interface that take a Coin object as a parameter and perhaps call one or more of its methods may have to be changed as well.
  • If a Psychiatrist object's examine() method takes a Patient object as an argument and calls the Patient object's queryMood() method, then if the name or argument list of the queryMood() method changes you will have to update how the Psychiatrist object calls this method.
• Different styles of arrows (arrow shafts and arrow heads) indicate different relationships between classes in a UML Class Diagram, 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:

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.