Datasheet

Chapter 1 ✦ What Is UML?

Since UML 2.0 is pending as of the writing of this book, I have included both UML

1.4.1 and UML 2.0. I hope this will help those of you who might be using modeling

tools based on UML 1.4.1 until you are able to upgrade. At the same time it should

give you some insights for evaluating either your existing vendor’s implementation

of UML 2.0 or other new modeling products. For a more complete explanation of

this approach, refer to “How to read this book” in the Preface.

When the OMG added Action Semantics to the 1.4 specification, it originally called

it “UML 1.4 with Action Semantics.” It later appeared on the OMG site as UML 1.5.

So don’t be surprised if I accidentally bounce between references to 1.4 and 1.5.

The rest of this chapter discusses

✦ The history of the UML through version 1.4

✦ The goals, scope, and features of the UML

✦ The objectives of UML 2.0

✦ The role of the Object Management Group (OMG)

✦ How UML fits into the bigger picture: The OMG’s Model-Driven Architecture

(MDA) initiative

Understanding the History Behind UML

UML is designed specifically to represent object-oriented (OO) systems. Object-

oriented development techniques describe software as a set of cooperating blocks

of information and behavior. For example, a performance at a theater would be

coded as a discrete module with its own data about dates and time, and behavior

such as schedule, cancel, or reschedule all rolled together. This was a stark depar-

ture from the old notion that data resides in files and behavior lives in programs.

The effect of this simple idea, the combining of data and behavior into objects, had

a profound effect on application design. As early as the 1970s, a number of methods

were developed to exploit the new object-oriented (OO) programming concepts.

Developers quickly recognized that object orientation made possible a develop-

ment process in which the way that they talk about the application corresponds

directly to how they code it. They also found that it was relatively easy to draw

(model) the objects so that they could talk about the design. Each object was repre-

sented as an element on a diagram. Because the model elements were almost identi-

cal to the code elements, the transition from model to code was simple and

efficient. Moving design discussions up to the models instead of the code helped

the developers deal with design issues at a high level of abstraction without getting

caught up in the coding syntax.

Note

03 526049 Ch01.qxd 8/20/03 11:47 PM Page 5