Rumbaugh UML 2 0 reference CD

For a tutorial introduction to UML that shows how to model under-a number of common problems, see The Unified Modeling Language User Guide [Booch-99] or UML Distilled [Fowler-04]... Alth

Advanced Praise for The Unified Modeling Language Reference Manual, Second Edition

“If you are a serious user of UML, there is no other book quite like this one I have been involved with the UML specification process for some time, but I still found myself learning things while reading through this book—especially on the changes and new capabilities that have come with UML 2.0 The intimate involvement of the author in the creation and continuing evolution of UML, and the encyclopedic scope of his book, make the work a unique contribution to the UML 2.0 literature,

as the first edition was for UML 1.0.”

—Ed Seidewitz, Chief Architect, InteliData Technologies Corporation

“In addition to the documents of the OMG UML 2.0 Standard, this book is bly the most important source for the Unified Modeling Language It is a detailed reference, covering the mainstream ideas as well as the delicate niches of the lan- guage The Dictionary of Terms offers precise, comprehensive and, perhaps most important, systematic information on all aspects of the UML2.0.”

proba-—Martin Gogolla, Professor for Computer Science, University of Bremen

“Comprehensive and instructive, written by a person with the insights of not only the technical matters, but also the processes that led to the UML language and its version 2.0 This book should be a companion for every serious UML modeler.”

—Øystein Haugen, Ericsson Representative in the OMG UML 2.0 Standardization, Associate Professor, University of Oslo

“This book provides an authoritative and user-oriented account of UML 2.0.”

—Dr Robert France, Department of Computer Science, Colorado State University.

“This is so far the most comprehensive book on UML 2.0 It gives you what the specification does not: real introductions to the various parts of UML, annotated examples, discussions on how to use the new features, and an insight into how and why the new features entered UML 2.0 As one of the persons who was involved in the making of UML 2.0, I can tell that the book is faithful to the specification and to the ideas behind the new features Read this book instead or as a complement to the specification.”

—Birger Møller-Pedersen, Professor, University of Oslo

M L

U

The Unified Modeling Language

Reference Manual

Second Edition

M L

U

The Unified Modeling Language

Reference Manual

Second Edition

Ja m e s Ru m b a u g h Iva r Ja c o b s o n Gra dy B o o c h

Boston • San Francisco • New York • Toronto • Montreal

London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks Where those designations appear in this book and Addison-Wesley was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals.

Unified Modeling Language, UML, and the UML cube logo are trademarks of the Object Management Group Some material in this book is derived from the Object Management Group UML Specification documentation Copyright © 2004 OMG Used by permission of the Object Management Group.

The authors and publisher have taken care in the preparation of this book but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales For more information, please contact:

U.S Corporate and Government Sales

Visit Addison-Wesley on the Web: www.awprofessional.com

Library of Congress Cataloging-in-Publication Data

Rumbaugh, James.

The unified modeling language reference manual / James Rumbaugh, Ivar

Jacobson, Grady Booch. 2nd ed.

p cm.

ISBN 0-321-24562-8

1 Computer software Development 2 UML (Computer science) I.

Jacobson, Ivar II Booch, Grady III Title

QA76.76.D47R86 2004

005.3 dc22

2004012580

Copyright © 2005 by Pearson Education, Inc.

All rights reserved No part of this publication may be reproduced, stored in a retrieval system, or

transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher Printed in the United States of America Published simultaneously

in Canada.

For information on obtaining permission for use of material from this work, please submit a written request to:

Pearson Education, Inc.

Rights and Contracts Department

75 Arlington Street, Suite 300

For Madeline, Nick, and Alex

—Jim

M L

U

Contents

Preface xiii

Part 1: Background Chapter 1: UML Overview 3

Brief Summary of UML 3

UML History 4

Goals of UML 10

Complexity of UML .10

UML Assessment 12

UML Concept Areas 12

Chapter 2: The Nature and Purpose of Models 15

What Is a Model? .15

What Are Models For? .15

Levels of Models 17

What Is in a Model? 19

What Does a Model Mean? 21

Part 2: UML Concepts Chapter 3: UML Walkthrough 25

UML Views 25

Static View 28

Design Views 29

Use Case View 34

State Machine View .35

Activity View 37

Interaction View 37

Deployment View 40

Model Management View 42

Profiles 43

x Contents

Chapter 4: Static View 47

Overview 47

Classifier 48

Relationships 52

Association 53

Generalization 57

Realization 61

Dependency 62

Constraint 65

Instance 66

Chapter 5: Design View 69

Overview 69

Structured Classifier 70

Collaboration 71

Patterns 73

Component 73

Chapter 6: Use Case View 77

Overview 77

Actor 77

Use Case 78

Chapter 7: State Machine View 81

Overview 81

State Machine 81

Event 82

State 84

Transition 85

Composite State 89

Chapter 8: Activity View 95

Overview 95

Activity 96

Activities and Other Views 98

Action 98

Chapter 9: Interaction View 101

Overview 101

Interaction 101

Sequence Diagram 102

Communication Diagram 106

Contents xi

Chapter 10: Deployment View 109

Overview 109

Node .109

Artifact 109

Chapter 11: Model Management View 111

Overview 111

Package 111

Dependencies on Packages .112

Visibility .113

Import 113

Model 114

Chapter 12: Profiles 115

Overview 115

Stereotype .116

Tagged Value 117

Profile 118

Chapter 13: UML Environment 121

Overview 121

Semantics Responsibilities 121

Notation Responsibilities .122

Programming Language Responsibilities 123

Modeling with Tools 124

Part 3: Reference Chapter 14: Dictionary of Terms 129

Part 4: Appendices Appendix A: UML Metamodel 685

Appendix B: Notation Summary 689

Bibliography 703

Index 707

M L

This book is not intended as a guide to the UML standards documents or to theinternal structure of the metamodel contained in them The details of the meta-model are of interest to methodologists and UML tool builders, but most otherdevelopers have little need for the arcane details of the Object Management Group(OMG) documents This book provides all the details of UML that most develop-ers need; in many cases, it makes information explicit that must otherwise besought between the lines of the original documents For those who wish to consultthe source documents, they are on the OMG web site (www.omg.org)

This book is intended as a reference for those who already have some standing of object-oriented technology For beginners, the original books by usand by other authors are listed in the bibliography; although some of the notationhas changed, books such as [Rumbaugh-91], [Jacobson-92], [Booch-94], and[Meyer-88] provide an introduction to object-oriented concepts that is still validand therefore unnecessary to duplicate here [Blaha-05] updates [Rumbaugh-91]using UML notation For a tutorial introduction to UML that shows how to model

under-a number of common problems, see The Unified Modeling Language User Guide

[Booch-99] or UML Distilled [Fowler-04]

xiv Preface

UML does not require a particular development process Although UML may

be used with a variety of development processes, it was designed to support aniterative, incremental, use-case–driven process with a strong architectural focus—the kind we feel is most suitable for the development of modern, complex systems

To place UML in its context as a tool for software development, this book definesthe stages of such a process, but they are not part of the UML standard The Unified Software Development Process [Jacobson-99]describes in detail the kind of process

we believe complements the UML and best supports software development

Second Edition and UML Version

This second edition has been extensively modified from the first edition, whichwas published in 1999 This edition is based on the OMG “adopted” specification

of UML version 2.0, with anticipated changes to the “available” specification beingprepared by an OMG Finalization Task Force Corrections to the book due tochanges in the OMG UML specification will be posted on the publisher’s web sitefor this book at www.awprofessional.com/titles/0321245628 The information inthe book is accurate as of June 2004

Original specification documents and up-to-date information about work onUML and related topics can be found on the OMG web site at www.omg.org

Reference Manual and OMG Specification

UML is a large modeling language with many features A reference manual thatjust repeats the original specification documents would not help readers much As

in any dictionary or encyclopedia, we have had to summarize information asclearly as possible while reducing the amount of material included We have fre-quently chosen to emphasize common usages by omitting obscure special cases orredundant means of representing some concepts This does not mean that thosecapabilities are useless, but most readers should be able to succeed without using

them The Reference Manual should not be regarded as the final authority on the

UML language, however As with any standard, the final authority rests with theofficial specifications, and these should be consulted to resolve disputes

We have tried to follow these principles:

• Explain the main intent of a concept without getting lost in the details of themetamodel representation

• Avoid discussion of abstract metaclasses Modelers must ultimately use concretemetaclasses, which can be described more simply if the internal abstract layersare collapsed

• Avoid discussion of the packaging of the metamodel The packages may be portant to tool builders, but modelers don’t need to know them most of thetime If you need to know, you need to look at the specification in detail anyway

im-Preface xv

• Describe concepts from the complete specification The OMG specification has

a number of intermediate layers and compliance points that greatly complicateunderstanding of UML We describe UML with all of its features If your tooldoes not implement all of the facilities, then some of the features may be un-available to you, but it doesn’t usually hurt to know about them

• Describe concepts from the viewpoint of their normal usage Often the OMGspecification goes to considerable trouble to express concepts in a general way.This is proper for a specification, but we feel that readers often understand con-cepts better if they are presented in a specific context and then generalized Ifyou are worried about the application of a concept in a complex, ambiguous sit-

uation and you feel that the Reference Manual explanation may be inadequate,

check the original specification Unfortunately, however, even the OMG cation is sometimes ambiguous in complex situations

specifi-Outline of the Book

The UML Reference Manual is organized into four parts: (1) an overview of UML

history and of modeling, (2) a survey of UML concepts, (3) an alphabetical nary of UML terms and concepts, and (4) brief appendices

dictio-The first part is an overview of UML—its history, purposes, and uses—to helpyou understand the origin of UML and the need it tries to fill

The second part is a brief survey of UML concepts so that you can put all thefeatures into perspective The survey provides a brief overview of the views UMLsupports and shows how the various constructs work together This part uses anexample that walks through various UML views It contains one chapter for eachkind of UML view This survey is not intended as a full tutorial or as a comprehen-sive description of concepts It serves mainly to summarize and relate the variousUML concepts, providing starting points for detailed readings in the dictionary The third part contains the reference material organized for easy access to eachtopic The bulk of the book is an alphabetical dictionary of all of the concepts andconstructs in UML Each UML term of any importance has its own entry in thedictionary The dictionary is meant to be complete; therefore, everything in theconcept overview in Part 2 is repeated in more detail in the dictionary The same

or similar information has sometimes been repeated in multiple dictionary articles

so that the reader can conveniently find it Some common object-oriented termsthat are not official UML concepts are included to provide context in examplesand discussions

Appendices show the UML metamodel and a summary of UML notation There

is a brief bibliography of major object-oriented books, but no attempt has beenmade to include a comprehensive citation of sources of ideas for UML or other ap-proaches Many of the books in the bibliography contain excellent lists of refer-ences to books and journal articles for those interested in tracking thedevelopment of the ideas

xvi Preface

Dictionary Entry Formatting Conventions

The dictionary part of the book is organized as an alphabetical list of entries, eachdescribing one concept in some detail The articles represent a flat list of UMLconcepts at various conceptual levels A high-level concept typically contains asummary of its subordinate concepts, each of which is fully described in a separatearticle The articles are highly cross-referenced The flat dictionary organizationpermits the description of each concept to be presented at a fairly uniform level ofdetail, without constant shifts in level for the nested descriptions that would benecessary for a sequential presentation The hypertext format of the documentshould also make it convenient for reference It should not be necessary to use theindex much; instead, go directly to the main article in the dictionary for any term

of interest and follow cross-references This format is not necessarily ideal forlearning the language; beginners are advised to read the overview description of

UML found in Part 2 or to read introductory books on UML, such as the UML User Guide [Booch-99].

Dictionary articles have the following divisions, although not all divisions pear in all articles

ap-Headword and brief definition

The name of the concept appears in boldface, set to the left of the body of the cle A brief definition follows in normal type This definition is intended to cap-ture the main idea of the concept, but it may simplify the concept for concisepresentation Refer to the main article for precise semantics

arti-Predefined stereotypes are included as entries A comment in parentheses lowing the entry name identifies the modeling element to which they apply

properties follows the general semantics, often under the subheading Structure In

most cases, properties appear as a table in alphabetical order by property name,with the description of each property on the right If a property has an enumeratedlist of choices, they may be given as an indented sublist In more complicated cases,

a property is given its own article to avoid excessive nesting When properties quire more explanation than permitted by a table, they are described in normaltext with run-in headers in boldface italics In certain cases, the main concept isbest described under several logical subdivisions rather than one list In such cases,

re-additional sections follow or replace the Structure subsection Although several

Preface xvii

A brief description of the concept in one or two sentences

See also related concept

Semantics

A description of the semantics in several paragraphs

Structure

A list of the subordinate concepts within the main concept

usually converted into plain English

enumerated item An enumeration with several values List of values:value The meaning of this value of the item

Another item More complicated topics are described in separate paragraphs.

Changes from UML version 1.x

stereotype entry (stereotype of Class)

Description of the meaning of the stereotype

xviii Preface

organizational mechanisms have been used, their structure should be obvious tothe reader The names of properties are usually stated in plain language rather thanusing internal identifiers from the UML metamodel, but the correspondence ismeant to be obvious

Notation

This section contains a detailed description of the notation for the concept ally, the notation section has a form that parallels the preceding semantics section,which it references, and it often has the same divisions The notation section usu-ally includes one or more diagrams to illustrate the concept The actual notation isprinted in black To help the reader understand the notation, many diagrams con-tain annotations in blue Any material in blue is commentary and is not part of theactual notation

Usu-Style guidelines

This optional section describes widespread style conventions They are not datory, but they are followed within the UML specification itself Recommendedpresentation guidelines may also be given in a separate section

man-Example

This subsection contains examples of notation or illustrations of the use of theconcept Frequently, the examples also treat complicated or potentially confusingsituations If the examples are brief, they may be folded in with another section

Discussion

This section describes subtle issues, clarifies tricky and frequently confused points,and contains other details that would otherwise digress from the more descriptivesemantics section A minority of articles have a discussion section

This section also explains certain design decisions that were made in the opment of the UML, particularly those that may appear counterintuitive or thathave provoked strong controversy Simple differences in taste are generally notcovered

devel-Sometimes we express an opinion on the value (or lack thereof) of certain cepts We recognize that others may disagree with these assessments We have tried

con-to confine opinions con-to the discussion section

History

This section describes changes from UML1 to UML2, sometimes including sons for the changes Minor changes are not usually listed Absence of this sectiondoes not mean that no changes have occurred

rea-Preface xix

Syntax Conventions

Syntax expressions Syntax expressions are given in a modified BNF format in a

sans serif font (Myriad) Literal values that appear in the target sentence areprinted in black, and the names of syntax variables and special syntax operatorsare printed in blue

Text printed in black appears literally in the target string

Punctuation marks (always printed in black) appear literally in the target string.Any word printed in blue ink represents a variable that must be replaced by an-other string or another syntax production in the target string Words may containletters and hyphens If a blue word is italicized or underlined, the actual replace-ment string must be italicized or underlined

In code examples, comments are printed in blue to the right of the code text.Subscripts and L-brackets are used as syntax operators as follows:

expressionopt The expression is optional

expressionlist, A comma-separated list of the expression may appear If

there is zero or one repetition, there is no separator If adifferent punctuation mark than a comma appears in thesubscript, then it is the separator

⎣= expression⎦opt A pair of right angles ties together two or more terms that

are considered a unit for optional or repeated rences In this example, the equal sign and the expressionform one unit that may be omitted or included

occur-Two-level nesting is avoided Particularly convoluted syntax may be simplifiedsomewhat for presentation, but use of such convoluted syntax is likely to be con-fusing for humans anyway and should be avoided

Literal strings In running text, language keywords, names of model elements, and

sample strings from models are shown in a sans serif font (Myriad)

Diagrams In diagrams, blue text and arrows are annotations, that is, explanations

of the diagram notation that do not appear in an actual diagram Any text andsymbols in black are actual diagram notation

CD

This book is accompanied by a CD containing the full text of the book in Adobe®Reader® (PDF) format Using Adobe Reader, the viewer can easily search the bookfor a word or phrase The CD version also contains a clickable table of contents, in-dex, Adobe Reader bookmarks, and extensive hot links (in red) in the bodies of thearticles Simply click on one of the links to jump to the dictionary article for aword or phrase We hope that this CD will be a useful reference aid for readers

xx Preface

Creators of UML

We wish to thank the many collaborators who built the UML specificationthrough years of meetings, heated discussions, writing, and implementation ofideas The list of contributors has grown significantly since UML1, and the OMGspecification no longer lists the major contributors, who number between twentyand fifty depending on the threshold for inclusion, and even more if work influ-encing UML is included It no longer appears possible to compile a complete listwithout overlooking many persons

Most of all, we want to celebrate the hundreds of persons who contributed tothe community of ideas from which UML was drawn—ideas in object-orientedtechnology, software methodology, programming languages, user interfaces, visualprogramming, and numerous other areas of computer science It is impossible tolist them all, or indeed to track even the major chains of influence, without a majorscholarly effort, and this is an engineering book, not a historical review Many ofthem are well known, but many good ideas also came from those who did not havethe good fortune to become widely recognized The bibliography includes a few ofthe lesser-known books that influenced the authors

Acknowledgments

We would like to acknowledge the reviewers who made this book possible For thesecond edition, they include Conrad Bock, Martin Gogolla, Øystein Haugen, Bir-ger Møller-Pedersen, and Ed Seidewitz For the first edition, we received feedbackfrom Mike Blaha, Conrad Bock, Perry Cole, Bruce Douglass, Martin Fowler, EranGery, Pete McBreen, Gunnar Övergaard, Karin Palmkvist, Guus Ramackers, TomSchultz, Ed Seidewitz, and Bran Selic

On a more personal note, I wish to thank Professor Jack Dennis, who inspired

my work in modeling and the work of many other students more than thirty yearsago The ideas from his Computations Structures Group at MIT have borne muchfruit, and they are not the least of the sources of UML I must also thank MaryLoomis and Ashwin Shah, with whom I developed the original ideas of OMT, and

my former colleagues at GE R&D Center, Mike Blaha, Bill Premerlani, Fred Eddy,and Bill Lorensen, with whom I wrote the OMT book

Finally, without the patience of my wife, Madeline, and my sons, Nick and Alex,there would have been no UML and no book about it

James RumbaughCupertino, CaliforniaJune 2004

M L

U

Part 1: Background

This part describes general principles underlying UML, including the natureand purpose of modeling and those aspects of the UML that pervade all functionalareas

M L

U

1

UML Overview

This chapter is a quick overview of UML and what it is good for

Brief Summary of UML

The Unified Modeling Language (UML) is a general-purpose visual modeling guage that is used to specify, visualize, construct, and document the artifacts of asoftware system It captures decisions and understanding about systems that must

lan-be constructed It is used to understand, design, browse, configure, maintain, andcontrol information about such systems It is intended for use with all develop-ment methods, lifecycle stages, application domains, and media The modelinglanguage is intended to unify past experience about modeling techniques and toincorporate current software best practices into a standard approach UML in-cludes semantic concepts, notation, and guidelines It has static, dynamic, envi-ronmental, and organizational parts It is intended to be supported by interactivevisual modeling tools that have code generators and report writers The UMLspecification does not define a standard process but is intended to be useful with

an iterative development process It is intended to support most existing oriented development processes

object-The UML captures information about the static structure and dynamic ior of a system A system is modeled as a collection of discrete objects that interact

behav-to perform work that ultimately benefits an outside user The static structure fines the kinds of objects important to a system and to its implementation, as well

de-as the relationships among the objects The dynamic behavior defines the history

of objects over time and the communications among objects to accomplish goals.Modeling a system from several separate but related viewpoints permits it to beunderstood for different purposes

The UML also contains organizational constructs for arranging models intopackages that permit software teams to partition large systems into workablepieces, to understand and control dependencies among the packages, and to

4 Part 1 • Background

manage the versioning of model units in a complex development environment Itcontains constructs for representing implementation decisions and for organizingrun-time elements into components

UML is not primarily a programming language It can be used to write grams, but it lacks the syntactic and semantic conveniences that most program-ming languages provide to ease the task of programming Tools can provide codegenerators from UML into a variety of programming languages, as well as con-struct reverse-engineered models from existing programs The UML is not ahighly formal language intended for theorem proving There are a number of suchlanguages, but they are not easy to understand or to use for most purposes TheUML is a general-purpose modeling language For specialized domains, such asGUI layout, VLSI circuit design, or rule-based artificial intelligence, a more spe-cialized tool with a special language might be appropriate UML is a discrete mod-eling language It is not intended to model continuous systems such as those found

pro-in engpro-ineerpro-ing and physics UML is pro-intended to be a universal general-purposemodeling language for discrete systems such as those made of software, firmware,

or digital logic

UML History

UML was developed in an effort to simplify and consolidate the large number ofobject-oriented development methods that had emerged

Object-oriented development methods

Development methods for traditional programming languages, such as Cobol andFortran, emerged in the 1970s and became widespread in the 1980s Foremostamong them was Structured Analysis and Structured Design [Yourdon-79] and itsvariants, such as Real-Time Structured Design [Ward-85] and others These meth-ods, originally developed by Constantine, DeMarco, Mellor, Ward, Yourdon, andothers, achieved some penetration into the large system area, especially forgovernment-contracted systems in the aerospace and defense fields, in which con-tracting officers insisted on an organized development process and ample docu-mentation of the system design and implementation The results were not always

as good as hoped for—many computer-aided software engineering (CASE)systems were little more than report generators that extracted designs after theimplementation was complete—but the methods included good ideas that wereoccasionally used effectively in the construction of large systems Commercialapplications were more reluctant to adopt large CASE systems and developmentmethods Most businesses developed software internally for their own needs,without the adversarial relationship between customer and contractors that char-acterized large government projects Commercial systems were perceived to be

Chapter 1 • UML Overview 5

simpler, whether or not this was actually true, and there was less need for review

by outside organizations

The first object-oriented language is generally acknowledged to be Simula-67[Birtwistle-75], developed in Norway in 1967 This language never had a signifi-cant following, although it greatly influenced the developers of several of the laterobject-oriented languages The work of Dahl and Nygaard had a profound influ-ence on the development of object orientation The object-oriented movement be-came active with the widespread availability of Smalltalk in the early 1980s,followed by other object-oriented languages, such as Objective C, C++, Eiffel, andCLOS The actual usage of object-oriented languages was limited at first, butobject-orientation attracted a lot of attention About five years after Smalltalk be-came widely known, the first object-oriented development methods were pub-lished by Shlaer/Mellor [Shlaer-88] and Coad/Yourdon [Coad-91], followed soonthereafter by Booch [Booch-94], Rumbaugh/Blaha/Premerlani/Eddy/Lorensen[Rumbaugh-91] (updated as [Blaha-05]), and Wirfs-Brock/Wilkerson/Wiener[Wirfs-Brock-90] (note that copyright years often begin in July of the previous cal-endar year) These books, added to earlier programming-language design books

by Goldberg/Robson [Goldberg-83], Cox [Cox-86], and Meyer [Meyer-88],started the field of object-oriented methodology The first phase was complete bythe end of 1990 The Objectory book [Jacobson-92] was published slightly later,based on work that had appeared in earlier papers This book took a somewhatdifferent approach, with its focus on use cases and the development process.Over the next five years, a plethora of books on object-oriented methodologyappeared, each with its own set of concepts, definitions, notation, terminology,and process Some added useful new concepts, but overall there was a great simi-larity among the concepts proposed by different authors Many of the newer booksstarted from one or more of the existing methods and made extensions or minorchanges The original authors were not idle either; most of them updated theiroriginal work, often incorporating good ideas from other authors In general,there emerged a pool of common core concepts, together with a wide variety ofconcepts embraced by one or two authors but not widely used Even in the coreconcepts, there were minor discrepancies among methods that made detailedcomparison somewhat treacherous, especially for the casual reader

Unification effort

There were some early attempts to unify concepts among methods A notableexample was Fusion by Coleman and his colleagues [Coleman-94], which in-cluded concepts from OMT [Rumbaugh-91], Booch [Booch-94], and CRC[Wirfs-Brock-90] As it did not involve the original authors, it must be regarded asanother new method rather than as a replacement of several existing methods Thefirst successful attempt to combine and replace existing approaches came when

6 Part 1 • Background

Rumbaugh joined Booch at Rational Software Corporation in 1994 They begancombining the concepts from the OMT and Booch methods, resulting in a firstproposal in 1995 At that time, Jacobson also joined Rational and began workingwith Booch and Rumbaugh Their joint work was called the Unified ModelingLanguage (UML) The momentum gained by having the authors of three of thetop methods working together to unify their approaches shifted the balance in theobject-oriented methodology field, where there had previously been little incen-tive (or at least little willingness) for methodologists to abandon some of their ownconcepts to achieve harmony

In 1996, the Object Management Group (OMG) issued a request for proposalsfor a standard approach to object-oriented modeling UML authors Booch, Jacob-son, and Rumbaugh began working with methodologists and developers fromother companies to produce a proposal attractive to the membership of OMG, aswell as a modeling language that would be widely accepted by tool makers, meth-odologists, and developers who would be the eventual users Several competing ef-forts also were started Eventually, all the proposals coalesced in the final UMLproposal that was submitted to the OMG in September 1997 The final product is acollaboration among many people We began the UML effort and contributed afew good ideas, but the ideas in it are the product of many minds

Standardization

The Unified Modeling Language was adopted unanimously by the membership ofthe OMG as a standard in November 1997 [UML-98] The OMG assumed respon-sibility for the further development of the UML standard Even before final adop-tion, a number of books were published outlining the highlights of the UML.Many tool vendors announced support or planned support for the UML, and sev-eral methodologists announced that they would use UML notation for furtherwork UML has now supplanted most, if not all, of the previous modeling nota-tions in development processes, modeling tools, and articles in the technical litera-ture The emergence of the UML appears to have been attractive to the generalcomputing public because it consolidates the experiences of many authors with anofficial status that has reduced gratuitous divergence among tools

Noteworthy is a series of international research conferences with the title UML yyyy, where yyyy is a year starting with 1998 and continuing annually [UMLConf].

Also note the yearly [ECOOP] and [OOPSLA] conferences dealing with oriented technology in general

object-UML2

After several years of experience using UML, the OMG issued requests for als to upgrade UML to fix problems uncovered by experience of use and to extend

propos-Chapter 1 • UML Overview 7

it with additional capabilities that were desired in several application domains.Proposals were developed from November 2000 to July 2003, with a specification

of UML version 2.0 being adopted by the OMG membership shortly thereafter[UML-04] The adopted specification underwent the normal OMG finalizationprocess to fix bugs and problems encountered in initial implementation, with a fi-nal available specification expected at the end of 2004 or beginning of 2005

In this book, we use the term UML1 to refer to UML specification versions 1.1

to 1.5 and UML2 to refer to UML specification versions 2.0 and higher.

New features In general, UML2 is mostly the same as UML1, especially regarding

the most commonly used, central features Some problem areas have been fied, a few major enhancements have been added, and many small bugs have beenfixed, but users of UML1 should have little trouble using UML2 The new versionmay be considered like a new version of a programming language or an applica-tion Some of the most important changes visible to users are:

modi-• Sequence diagram constructs and notation based largely on the ITU MessageSequence Chart standard, adapted to make it more object-oriented

• Decoupling of activity modeling concepts from state machines and the use ofnotation popular in the business modeling community

• Unification of activity modeling with the action modeling added in UML sion 1.5, to provide a more complete procedural model

ver-• Contextual modeling constructs for the internal composition of classes and laborations These constructs permit both loose and strict encapsulation andthe wiring of internal structures from smaller parts

col-• Repositioning of components as design constructs and artifacts as physical ties that are deployed

enti-Internal mechanisms Other changes affect the internal representation of UML

constructs (the metamodel) and its relationship to other specifications Thesechanges will not concern most users directly, but they are important to toolmakersbecause they affect interoperability across multiple specifications, therefore theywill affect users indirectly:

• Unification of the core of UML with the conceptual modeling parts of MOF(Meta-Object Facility) This permits UML models to be handled by genericMOF tools and repositories

• Restructuring of the UML metamodel to eliminate redundant constructs and topermit reuse of well-defined subsets by other specifications

• Availability of profiles to define domain and technology-specific extensions ofUML

8 Part 1 • Background

Other sources

In addition to the various development methods cited above and a number of ers that came a bit later, certain UML views show strong influences from particularnon-object-oriented sources

oth-The static view, with classes connected by various relationships, is strongly fluenced by Peter Chen’s Entity-Relationship (ER) model originally developed in

in-1976 The influence came into UML through most of the early object-orientedmethods The ER model also heavily influenced database systems The program-ming language world and the database world have unfortunately mostly gone theirseparate ways

State machine models have been used in computer science and electrical neering for many years David Harel’s statecharts are an important extension toclassical state machines that add the concept of nested and orthogonal states.Harel’s ideas were adapted by OMT, and from there into other methods and even-tually into UML, where they form the basis of the state machine view

engi-The sequence diagram notation of UML2 is taken from the ITU Message quence Chart (MSC) standard [ITU-T Z.120], adapted to make it match otherUML concepts better This standard, which has been widely used in the telecom-munications industry, replaces the sequence diagram notation of UML1 by adding

Se-a number of structured constructs to overcome problems in the previous UML1notation The ITU is considering whether to adopt some or all of the changes intothe ITU standard

The structured classifier concepts of UML2 were strongly influenced by the time engineering constructs of SDL [ITU-T Z.100], MSC, and the ROOM method[Selic-94]

real-The activity diagram notation of UML1, and even more that of UML2, isheavily influenced by various business process modeling notations Because nosingle business process modeling notation was dominant, the UML notation wasselected from various sources

There are many other influences of UML, and often the original source of anidea precedes the person who is famous for popularizing it About 20 persons weremajor contributors to the UML1 specification, with many others participating in alesser way Maybe 30 or so played major roles in the development of UML2, withscores of others submitting suggestions, reviewing proposals, and writing books It

is impossible to list everyone who contributed to UML, and the brief referencesthat we have included undoubtedly overlook some important contributors, forwhich we ask understanding

Chapter 1 • UML Overview 9

What does unified mean?

The word unified has the following relevant meanings for UML.

Across historical methods and notations The UML combines the commonly

ac-cepted concepts from many object-oriented methods, selecting a clear definitionfor each concept, as well as a notation and terminology The UML can representmost existing models as well as or better than the original methods can

Across the development lifecycle The UML is seamless from requirements to

de-ployment The same set of concepts and notation can be used in different stages ofdevelopment and even mixed within a single model It is unnecessary to translatefrom one stage to another This seamlessness is critical for iterative, incrementaldevelopment

Across application domains The UML is intended to model most application

do-mains, including those involving systems that are large, complex, real-time, tributed, data or computation intensive, among other properties There may bespecialized areas in which a special-purpose language is more useful, but UML isintended to be as good as or better than any other general-purpose modeling lan-guage for most application areas

dis-Across implementation languages and platforms The UML is intended to be

usable for systems implemented in various implementation languages and forms, including programming languages, databases, 4GLs, organization docu-ments, firmware, and so on The front-end work should be identical or similar inall cases, while the back-end work will differ somewhat for each medium

plat-Across development processes The UML is a modeling language, not a description

of a detailed development process It is intended to be usable as the modeling guage underlying most existing or new development processes, just as a general-purpose programming language can be used in many styles of programming It isparticularly intended to support the iterative, incremental style of developmentthat we recommend

lan-Across internal concepts In constructing the UML metamodel, we made a

deliber-ate effort to discover and represent underlying relationships among various cepts, trying to capture modeling concepts in a broad way applicable to manyknown and unknown situations This process led to a better understanding of theconcepts and a more general applicability of them This was not the original pur-pose of the unification work, but it was one of the most important results

con-10 Part 1 • Background

Goals of UML

There were a number of goals behind the development of UML First and mostimportant, UML is a general-purpose modeling language that all modelers canuse It is nonproprietary and based on common agreement by much of the com-puting community It is meant to include the concepts of the leading methods sothat it can be used as their modeling language At the very least, it was intended tosupersede the models of OMT, Booch, and Objectory, as well as those of other par-ticipants of the proposal It was intended to be as familiar as possible; wheneverpossible, we used notation from OMT, Booch, Objectory, and other leading meth-ods It is meant to support good practices for design, such as encapsulation, sepa-ration of concerns, and capture of the intent of a model construct It is intended toaddress current software development issues, such as large scale, distribution, con-currency, patterns, and team development

UML is not intended to be a complete development method It does not include

a step-by-step development process We believe that a good development process

is crucial to the success of a software development effort, and we propose one in acompanion book [Jacobson-99] It is important to realize that UML and a processfor using UML are two separate things UML is intended to support all, or at leastmost, of the existing development processes UML includes the concepts that webelieve are necessary to support a modern iterative process based on building astrong architecture to solve user-case–driven requirements

A final goal of UML was to be as simple as possible while still being capable ofmodeling the full range of practical systems that need to be built UML needs to beexpressive enough to handle all the concepts that arise in a modern system, such asconcurrency and distribution, as well as software engineering mechanisms, such asencapsulation and components It must be a universal language, like any general-purpose programming language Unfortunately, that means that it cannot be small

if we want it to handle things other than toy systems Modern languages and ern operating systems are more complicated than those of 50 years ago because weexpect much more of them UML has several kinds of models; it is not somethingyou can master in one day It is more complicated than some of its antecedents be-cause it is intended to be more comprehensive But you don’t have to learn it all atonce, any more than you would a programming language, an operating system, or

mod-a complex user mod-applicmod-ation, not to mention mod-a nmod-aturmod-al lmod-angumod-age or skill

Complexity of UML

UML is a large and varied modeling language intended for use on many differentlevels and at many stages of the development lifecycle It has been criticized for be-ing large and complex, but complexity is inherent in any universal application that

is intended for realistic use on real-world problems, such as operating systems,

Chapter 1 • UML Overview 11

programming languages, multimedia editing applications, spreadsheet editors,and desktop publishing systems Such applications can be kept small only at thecost of making them toys, and the developers of UML did not wish it to be a toy.The complexity of UML must be understood in light of its history:

• UML is a product of consensus of persons with varied goals and interests Itshares the qualities of the product of a democratic process It is not as clean orcoherent as the product of a single will It contains superfluous features (but dif-ferent persons might disagree about exactly what is superfluous) It containsoverlapping features that are not always well integrated Most of all, it lacks aconsistent viewpoint Unlike a programming language, which has a fairly nar-row usage, it is intended for all kinds of things, from business modeling tographical programming Wide breadth of applicability usually comes at the ex-pense of specificity

• It was originally the merger of four or five leading modeling approaches, andlater has been the target for accommodating a number of existing notations,such as SDL (Specification and Description Language, [ITU-T Z.100]), variousbusiness modeling languages (which themselves had no single standard), actionlanguages, state machine notations, and so on The desire to preserve previousnotation often creates inconsistencies across features and includes redundantnotation intended to cater to the familiarities of certain usage groups

• The official specification documents have been written by teams of uneven ity There is a wide variation in style, completeness, precision, and consistencyamong various sections of the documents

abil-• UML is not a precise specification in the manner of a formal language though the computer science community holds formality to be a virtue, fewmainstream programming languages are precisely defined, and formal lan-guages are often inaccessible even to experts It should also be noted that model-ing is not the same as coding In the construction industry, blueprints arewritten in an informal style using many conventions that depend on the com-mon sense of the craftsperson, but buildings are built from them successfully

Al-• The semantics sections sometimes contain vague statements without adequateexplanation and examples Terms are introduced in metamodels and not welldistinguished from other terms There are too many fine distinctions that some-one thought important but did not explain clearly

• There is far too much use of generalization at the expense of essential tions The myth that inheritance is always good has been a curse of object-orientation from its earliest days

distinc-• There is a tension between concepts for conceptual modeling and programminglanguage representation, with no consistent guidelines

• UML can be and has been used in many different ways in real-world ment projects

develop-• UML is more than a visual notation UML models can be used to generate codeand test cases This requires an appropriate UML profile, use of tools matched

to the target platform, and choices among various implementation trade-offs

• It is unnecessary to listen too much to UML language lawyers There is no singleright way to use it It is one of many tools that a good developer uses It doesn’thave to be used for everything You can modify it to suit your own needs pro-vided you have the cooperation of your colleagues and software tools

UML Concept Areas

UML concepts and models can be grouped into the following concept areas

Static structure Any precise model must first define the universe of discourse, that

is, the key concepts from the application, their internal properties, and their tionships to each other This group of constructs is the static view Applicationconcepts are modeled as classes, each of which describes discrete objects that holdinformation and communicate to implement behavior The information they hold

rela-is modeled as attributes; the behavior they perform rela-is modeled as operations eral classes can share their common structure using generalization A child classadds incremental structure and behavior to the structure and behavior that it ob-tains by inheritance from the common parent class Objects also have run-timeconnections to other individual objects Such object-to-object relationships aremodeled as associations among classes Some relationships among elements aregrouped together as dependency relationships, including relationships among lev-els of abstraction, binding of template parameters, granting of permission, and us-age of one element by another Classes may have interfaces, which describe theirexternally-visible behavior Other relationships are include and extend dependen-cies of use cases The static view is notated using class diagrams and its variants.The static view can be used to generate most data structure declarations in a pro-gram There are several other kinds of elements in UML diagrams, such asinterfaces, data types, use cases, and signals Collectively, these are called classifiers,

Sev-Chapter 1 • UML Overview 13

and they behave much like classes with certain additions and restrictions on eachkind of classifier

Design constructs UML models are meant for both logical analysis and designs

in-tended for implementation Certain constructs represent design items A tured classifier expands a class into its implementation as a collection of parts heldtogether by connectors A class can encapsulate its internal structure behind exter-nally visible ports A collaboration models a collection of objects that play roleswithin a transient context A component is a replaceable part of a system that con-forms to and provides the realization of a set of interfaces It is intended to be eas-ily substitutable for other components that meet the same specification

struc-Deployment constructs A node is a run-time computing resource that defines a cation An artifact is a physical unit of information or behavior description in acomputing system Artifacts are deployed on nodes An artifact can be a manifes-tation, that is, an implementation, of a component The deployment view de-scribes the configuration of nodes in a running system and the arrangement ofartifacts on them, including manifestation relationships to components

lo-Dynamic behavior There are three ways to model behavior One is the life history

of one object as it interacts with the rest of the world; another is the tion patterns of a set of connected objects as they interact to implement behavior;the third is the evolution of the execution process as it passes through variousactivities

communica-The view of an object in isolation is a state machine—a view of an object as it sponds to events based on its current state, performs actions as part of its response,and transitions to a new state State machines are displayed in state machine dia-grams

re-An interaction overlays a structured classifier or collaboration with the flow ofmessages between parts Interactions are shown in sequence diagrams and com-munication diagrams Sequence diagrams emphasize time sequences, whereascommunication diagrams emphasize object relationships

An activity represents the execution of a computation It is modeled as a set ofactivity nodes connected by control flows and data flows Activities can modelboth sequential and concurrent behavior They include traditional flow-of-controlconstructs, such as decisions and loops Activity diagrams may be used to showcomputations as well as workflows in human organizations

Guiding all the behavior views is a set of use cases, each a description of a slice ofsystem functionality as visible to an actor, an external user of the system The usecase view includes both the static structure of the use cases and their actors as well

as the dynamic sequences of messages among actors and system, usually expressed

as sequence diagrams or just text

14 Part 1 • Background

Model organization Computers can deal with large flat models, but humans

can-not In a large system, the modeling information must be divided into coherentpieces so that teams can work on different parts concurrently Even on a smallersystem, human understanding requires the organization of model content intopackages of modest size Packages are general-purpose hierarchical organizationalunits of UML models They can be used for storage, access control, configurationmanagement, and constructing libraries that contain reusable model fragments Adependency between packages summarizes the dependencies among the packagecontents A dependency among packages can be imposed by the overall system ar-chitecture Then the contents of the packages must conform to the package depen-dencies and to the imposed system architecture

Profiles No matter how complete the facilities in a language, people will want to

make extensions UML contains a limited extensibility capability that should commodate most of the day-to-day needs for extensions, without requiring achange to the basic language A stereotype is a new kind of model element with thesame structure as an existing element, but with additional constraints, a differentinterpretation and icon, and different treatment by code generators and otherback-end tools A stereotype defines a set of tagged values A tagged value is a user-defined attribute that applies to model elements themselves, rather than objects inthe run-time system For example, tagged values may indicate project manage-ment information, code generator guidance, and domain-specific information Aconstraint is a well-formedness condition expressed as a text string in some con-straint language, such as a programming language, special constraint language, ornatural language UML includes a constraint language called OCL A profile is aset of stereotypes and constraints for a particular purpose that can be applied touser packages Profiles can be developed for particular purposes and stored in li-braries for use in user models As with any extensibility mechanism, these mecha-nisms must be used with care because of the risk of producing a private dialectunintelligible to others But they can avoid the need for more radical changes

M L

U

2

The Nature and Purpose of Models

This chapter explains what models are, what they are good for, and how they areused It also explains the various grades of models: ideal, partial, and tool-based

What Is a Model?

A model is a representation in a certain medium of something in the same or other medium The model captures the important aspects of the thing being mod-eled from a certain point of view and simplifies or omits the rest Engineering,architecture, and many other creative fields use models

an-A model is expressed in a medium that is convenient for working Models ofbuildings may be drawings on paper, - figures made of cardboard and papier-mâché, or finite-element equations in a computer A construction model of abuilding shows the appearance of the building but can also be used to make engi-neering and cost calculations

A model of a software system is made in a modeling language, such as UML.The model has both semantics and notation and can take various forms that in-clude both pictures and text The model is intended to be easier to use for certainpurposes than the final system

What Are Models For?

Models are used for several purposes

To capture and precisely state requirements and domain knowledge so that all stakeholders may understand and agree on them Various models of a building

capture requirements about the appearance, traffic patterns, various kinds of ity services, strength against wind and earthquakes, cost, and many other things.Stakeholders include the architect, structural engineer, general contractor, varioussubcontractors, owner, renters, and the city

util-16 Part 1 • Background

Different models of a software system may capture requirements about its cation domain, the ways users will use it, its breakdown into modules, commonpatterns used in its construction, and other things Stakeholders include the archi-tect, analysts, programmers, project manager, customers, funders, end users, andoperators Various kinds of UML models are used

appli-To think about the design of a system An architect uses models on paper, on a

computer, or as - constructs to visualize and experiment with possible designs.The simplicity of creating and modifying small models permits creative thoughtand innovation at little cost

A model of a software system helps developers explore several architectures anddesign solutions easily before writing code A good modeling language allows thedesigner to get the overall architecture right before detailed design begins

To capture design decisions in a mutable form separate from the requirements One

model of a building shows the external appearance agreed to with the customer.Another model shows the internal routing of wires, pipes, and ventilation ducts.There are many ways to implement these services The final model shows a designthat the architect believes is a good one The customer may verify this information,but often customers are not concerned about the details, as long as they work.One model of a software system can capture the external behavior of a systemand the real-world domain information represented by the system Another modelshows the internal classes and operations that implement the external behavior.There are many ways to implement the behavior; the final design model shows oneapproach that the designer believes is a good one

To generate usable work products A model of a building can be used to generate

various kinds of products These include a bill of materials, a simulated animatedwalkthrough, a table of deflections at various wind speeds, and a visualization ofstrain at various points in the frame

A model of a software system can be used to generate class declarations, dure bodies, user interfaces, databases, scenarios of legal use, configuration scripts,and lists of race conditions

proce-To organize, find, filter, retrieve, examine, and edit information about large tems A model of a building organizes information by service: structural, electrical,

sys-plumbing, ventilation, decoration, and so on Unless the model is on a computer,however, finding things and modifying them are not so easy If it is on a computer,changes can be made and recalled easily, and multiple designs can be easily ex-plored while sharing some common elements

A model of a software system organizes information into several views: staticstructure, state machines, interactions, requirements, and so on Each view is aprojection of the information in the complete model as selected for a purpose

Chapter 2 • The Nature and Purpose of Models 17

Keeping a model of any size accurate is impossible without having an editing toolthat manages the model An interactive graphical model editor can present infor-mation in different formats, hide information that is unnecessary for a given pur-pose and show it again later, group related operations together, make changes toindividual elements, as well as change groups of elements with one command, and

so on

To explore multiple solutions economically The advantages and risks of different

design methods for buildings may not be clear at first For example, different structures may interact in complicated ways that cannot be evaluated in an engi-neer’s head Models can explore the various designs and permit calculations ofcosts and risks before the actual building is constructed

sub-Models of a large software system permit several designs to be proposed andcompared The models are not constructed in full detail, of course, but even arough model can expose many issues the final design must deal with Modelingpermits several designs to be considered, at a small cost of implementing any onedesign

To master complex systems An engineering model of a tornado approaching a

building provides understanding that is not possible from a real-world building Areal tornado cannot be produced on demand, and it would destroy the measuringinstruments, anyway Many fast, small, or violent physical processes can now beunderstood using physical models

A model of a large software system permits dealing with complexity that is toodifficult to deal with directly A model can abstract to a level that is comprehensi-ble to humans, without getting lost in details A computer can perform compli-cated analyses on a model in an effort to find possible trouble spots, such as timingerrors and resource overruns A model can determine the potential impact of achange before it is made, by exploring dependencies in the system A model canalso show how to restructure a system to reduce such effects

Levels of Models

Models take on different forms for various purposes and appear at different levels

of abstraction The amount of detail in the model must be adapted to one of thefollowing purposes

Guides to the thought process High-level models built early in a project serve to

fo-cus the thought process of the stakeholders and highlight options They capturerequirements and represent a starting point toward a system design The earlymodels help the originators explore possible options before converging on a sys-tem concept As design progresses, the early models are replaced by more accuratemodels There is no need to preserve every twist and turn of the early exploratory

18 Part 1 • Background

process Its purpose is to produce ideas The final “thinking models” should bepreserved even after the focus shifts to design issues, however Early models do notrequire the detail or precision of an implementation model, and they do not re-quire a full range of implementation concepts Such models use a subset of UMLconstructs, a more limited subset than later design models

When an early model is a complete view of a system at a given precision—forexample, an analysis model of what must be done—then it should be preservedwhen development shifts to the next stage There is an important difference be-tween adding detail (in which case, the chain of reasoning should be preserved)and the normal random-walk process of exploring many dead ends before arriving

at the right solution In the latter case, it is usually overwhelming and unnecessary

to save the entire history except in extraordinary situations in which completetraceability is required

Abstract specifications of the essential structure of a system Models in the analysis

or preliminary design stages focus on the key concepts and mechanisms of theeventual system They correspond in certain ways with the final system But detailsare missing from the model, which must be added explicitly during the design pro-cess The purpose of the abstract models is to get the high-level pervasive issuescorrect before tackling the more localized details These models are intended to beevolved into the final models by a careful process that guarantees that the final sys-tem correctly implements the intent of the earlier models There must be traceabil-ity from these essential models to the full models; otherwise, there is no assurancethat the final system correctly incorporates the key properties that the essentialmodel sought to show Essential models focus on semantic intent They do notneed the full range of implementation options Indeed, low-level performance dis-tinctions often obscure the logical semantics The path from an essential model to

a complete implementation model must be clear and straightforward, however,whether it is generated automatically by a code generator or evolved manually by adesigner

Full specifications of a final system An implementation model includes enough

information to build the system It must include not only the logical semantics ofthe system and the algorithms, data structures, and mechanisms that ensureproper performance, but also organizational decisions about the system artifactsthat are necessary for cooperative work by humans and processing by tools Thiskind of model must include constructs for packaging the model for human under-standing and for computer convenience These are not properties of the target ap-plication itself Rather, they are properties of the construction process

Exemplars of typical or possible systems Well-chosen examples can give insight to

humans and can validate system specifications and implementations Even a largecollection of examples, however, necessarily falls short of a definitive description

Chapter 2 • The Nature and Purpose of Models 19

Ultimately, we need models that specify the general case; that is what a program is,after all Examples of typical data structures, interaction sequences, or object his-tories can help a human trying to understand a complicated situation, however.Examples must be used with some care It is logically impossible to induce the gen-eral case from a set of examples, but well-chosen prototypes are the way most peo-ple think An example model includes instances rather than general descriptors Ittherefore tends to have a different feel than a generic descriptive model Examplemodels usually use only a subset of the UML constructs, those that deal with in-stances Both descriptive models and exemplar models are useful in modeling asystem

Complete or partial descriptions of systems A model can be a complete description

of a single system with no outside references More often, it is organized as a set ofdistinct, discrete units, each of which may be stored and manipulated separately as

a part of the entire description Such models have “loose ends” that must be bound

to other models in a complete system Because the pieces have coherence andmeaning, they can be combined with other pieces in various ways to producemany different systems Achieving reuse is an important goal of good modeling.Models evolve over time Models with greater degrees of detail are derived frommore abstract models, and more concrete models are derived from more logicalmodels For example, a model might start as a high-level view of the entire system,with a few key services in brief detail and no embellishments Over time, muchmore detail is added and variations are introduced Also over time, the focus shiftsfrom a front-end, user-centered logical view to a back-end, implementation-centered physical view As the developers work with a system and understand itbetter, the model must be iterated at all levels to capture that understanding; it isimpossible to understand a large system in a single, linear pass There is no one

“right” form for a model

What Is in a Model?

Semantics and presentation Models have two major aspects: semantic

informa-tion (semantics) and visual presentainforma-tion (notainforma-tion)

The semantic aspect captures the meaning of an application as a network of ical constructs, such as classes, associations, states, use cases, and messages Se-mantic model elements carry the meaning of the model—that is, they convey thesemantics The semantic modeling elements are used for code generation, validitychecking, complexity metrics, and so on The visual appearance is irrelevant to

log-most tools that process models The semantic information is often called the model A semantic model has a syntactic structure, well-formedness rules, and ex-

ecution dynamics These aspects are often described separately (as in the UMLdefinition documents), but they are tightly interrelated parts of a single coherentmodel

20 Part 1 • Background

The visual presentation shows semantic information in a form that can be seen,browsed, and edited by humans Presentation elements carry the visual presenta-tion of the model—that is, they show it in a form directly apprehensible by hu-mans They do not add meaning, but they do organize the presentation toemphasize the arrangement of the model in a usable way They therefore guide hu-man understanding of a model Presentation elements derive their semantics fromsemantic model elements But inasmuch as the layout of the diagrams is supplied

by humans, presentation elements are not completely derivable from logical ments The arrangement of presentation elements may convey connotations aboutsemantic relationships that are too weak or ambiguous to formalize in the seman-tic model but are nevertheless suggestive to humans

ele-Context Models are themselves artifacts in a computer system, and they are used

within a larger context that gives them their full meaning This context includesthe internal organization of the model, annotations about the use of each model inthe overall development process, a set of defaults and assumptions for element cre-ation and manipulation, and a relationship to the environment in which they areused

Models require an internal organization that permits simultaneous use by tiple work groups without undue interference This decomposition is not neededfor semantic reasons—a large monolithic model would be as precise as a set ofmodels organized into coherent packages, maybe even more precise because theorganizational boundaries complicate the job of defining precise semantics Butteams of workers could not work effectively on a large monolithic model withoutconstantly getting in each other’s way Moreover, a monolithic model has no piecesthat can be reused in other situations Finally, changes to a large model have conse-quences that are difficult to determine Changes to a small, isolated piece of a largemodel can be tractable if the model is properly structured into subsystems withwell-defined interfaces In any case, dividing large systems into a hierarchy of well-chosen pieces is the most reliable way to design large systems that humans have in-vented over thousands of years

mul-Models capture semantic information about an application system, but theyalso need to record many kinds of information about the development process it-self, such as the author of a class, the debug status of a procedure, and who is per-mitted to edit a diagram Such information is, at best, peripheral to the semantics

of the system, but it is important to the development process A model of a systemtherefore needs to include both viewpoints This is most easily achieved by regard-ing the project management information as annotations to the semantic model—that is, arbitrary descriptions attached to model elements but whose meaning isoutside the modeling language In UML these annotations are implemented as textstrings whose usage is defined by optional profiles