What Is UML?

To this point, we've taken a fairly informal approach to program design. The five programming steps are a good starting point for thinking about program design. The sideways refinement of the five programming steps is the second phase in designing a program. Using pseudo code to expand the detail of the refinement is extremely helpful in program design. Although the five-programming-step approach to program design is useful, some prefer a more rigorous approach. The Unified Modeling Language, or UML, is such an approach.

The Unified Modeling Language ( UML ) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. ^[1]

^[1] http://cgi.omg.org/news/pr97/umlprimer.html

Simply stated, UML is a formalized methodology for software development.

A Brief History of UML

As mentioned in Chapter 2, object-oriented programming (OOP) has been around since the 1960s. Although OOP was relatively young, several objected-oriented modeling languages were developed between the mid-1970s and late 1980s. By the mid-1990s, more than 50 modeling languages had been developed. Clearly, so many attempts without producing a language that was embraced by the programming community suggests that there was more work to be done.

Part of the problem was competing methodologies. The leading contenders at the time were Jim Rumbaugh (General Electric), Grady Booch (Rational Software), and Ivar Jacobson (Objectory). These three leaders beat each other up for years in a fascinating zero-sum game in the modeling language arena.

In 1994, Rumbaugh left General Electric and joined Booch at Rational Software, thus ganging up on Jacobson. A year later, Rational Software bought Objectory and the three major players (sometimes called the Three Amigos) were under one roof. In June of 1996, UML 0.9 was released.

In the years since then, the Object Management Group (OMG) has served as a focal point for refinements to UML. In mid-2001, OMG members began their work on a major upgrade to UML 2.0. Currently, UML includes visual modeling, simulation, and development environments. A number of UML modeling tools are commercially available. Some of these tools include Rational Rose 2002 from Rational Software Corporation, Describe Enterprise from Embarcadero Technologies, and Visio 2002 from Microsoft. (We'll use Visio 2002 for our UML design efforts, primarily because of university agreements with Microsoft.)

UML Diagrams

UML is a visual tool and employs many types of diagrams. Each UML diagram is designed to let developers and customers view a software system from a different perspective in varying degrees of abstraction. Table 3.1 presents a list of the UML diagrams commonly created by these visual modeling tools.

Table 3.1. Some Common UML Diagrams

Use Case Diagram	Displays the relationship among actors and use cases.
Class Diagram	Models class structure and contents using design elements such as classes, packages, and objects. It also displays relationships such as containment, inheritance, associations, and others.
State Diagram	Displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions.
Sequence Diagram	Displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects).
Collaboration Diagram	Displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages.
Activity Diagram	Displays a special state diagram in which most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing.
Component Diagram	Displays the high-level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at runtime, or combinations of each.
Deployment Diagram	Displays the configuration of runtime processing elements and the software components, processes, and objects that live on them. Software component instances represent runtime manifestations of code units.

Each of the diagrams presented in Table 3.1 deserves a chapter (perhaps more) of its own. However, we are primarily concerned with how UML can be used with class diagrams and how they can help us to develop programs that embrace the philosophy of OOP.

OOA, OOD, and OOP

Just what you need more abbreviations and terms to contend with. Actually, it's not all that bad and we can dispatch these fairly quickly.

Object-Oriented Analysis

Object-oriented analysis, or OOA, is a methodology for the analysis of the software development process. When using OOA, we need to think of everything in the software development process in terms of classes. We talked about classes in Chapter 2 as they related to the hospital elevator example. In that example, each hospital individual (that is, doctor, nurse, patient, and visitor) was a class. You'll also remember that each new individual that we created from a class was called an instance of that class. The OOA process is primarily concerned with how we derived the classes that are needed by the system.

The core issue in OOA is concerned with answering the "What" types of questions that arise in the software development process. Typical OOA questions and concerns are "What are the classes in my program?", "What will my program do?", "What does each class object do to help solve the problem?", and "What are the responsibilities of this class in my program?". At the OOA stage, the emphasis is on the analysis of the objects, tasks , and responsibilities of the actual software system.

Object-Oriented Design

The focal point of object-oriented design phase is concerned with the "How" issues of the software system. Typical issues that are addressed in the design phase include "How will this class gather the data?", "How will this class calculate a tax return?", and "How will this class print the report?". In terms of our discussion from Chapter 2, this level is concerned with all the attributes, properties, and methods of a class.

Therefore, the OOA component seeks to identify the classes that are necessary to accomplish the software objectives. Having done that, OOD focuses on the implementation of those classes and the attributes, properties, and methods that are at the core of each class. Coupling the two activities and developing the links that connect the classes are all part of the complete OOP process.