UML Explained

About

Features

Description

There are dozens of Unified Modeling Language (UML) books, but virtually all of them assume their readers have significant experience with modeling or object-oriented development. Not this one. Written by the co-author of the best selling UML Distilled, this book is utterly authoritative -- and it's also the simplest, least technical guide to UML ever written. With it, every participant in the modeling process can learn to master UML, starting from scratch. Begin by understanding the real value of modeling in software development and other endeavors, and how UML was explicitly designed to support iterative and incremental processes. Watch a project team use UML to identify the real-world objects associated with their business problem; capture scenarios that describe user actions and system responses ("use cases"); and define a system's functional requirements. Learn how UML helps teams identify relationships amongst objects that must be implemented to address a system's requirements. Next, use UML to describe business and process workflows; to determine how all of a system's objects will work together; and to specify how a distributed software system will actually be built.

Sample Content

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:
umlch2.pdf

Table of Contents

Preface.


Organization of This Book.


Background.


Acknowledgments.


1. Why the UML?


2. The UML and Process.


3. Identifying Relevant Real-World Things.


4. Capturing Requirements.


5. Expressing How Things Work Together.


6. Refining the Structure of Things.


7. Describing Flows.


8. Tracking the Lives of Things.


9. Showing How Groups of Things Work Together.


10. Describing How Things Will Be Built.


Glossary.


Index.

Preface

When I started seriously considering writing a proposal for a book about the Unified Modeling Language (UML), Amazon.com listed about 62 books whose titles contained "UML." By my reckoning, 61 of those books were aimed at programmers and other highly technically oriented people. The other one introduced its example system more than halfway through the book and, a few pages into that chapter, started showing figures with way too many things in them for a beginner to be able to handle. It became clear to me that what was missing was a book that approaches the UML from the standpoint of what relatively nontechnical people need to understand in doing their jobs--like how to capture requirements--rather than starting with the diagrams, as most of these other UML books do.

I wrote this book literally for "the rest of us," people who see the UML from the outside looking in. UML Distilled (Fowler and Scott, Addison-Wesley, 1997), for instance, made certain assumptions about its readers, namely, that they were comfortable with object-oriented terminology and concepts and that, for the most part, they were already using one or another of the approaches designed by the "three amigos," the creators of the UML--Grady Booch, Jim Rumbaugh, and Ivar Jacobson. For every set of modelers and analysts and developers who sank their teeth into Martin Fowler's brilliantly conceived book, though, there were at least a few people who wanted to know about this cool language but didn't quite know where to start. If you're in that latter group, this book may be for you.

I'm not assuming any knowledge of object orientation (OO). (Note that although the UML certainly is applicable in non-OO contexts, such as data modeling, the language was explicitly designed for use with OO.) If you find yourself reading a definition you're already familiar with, you should be able to skip that paragraph (or subsection or section) without any problem. I've also focused on capturing what I think are the most important aspects of the UML for people who probably aren't at the center of development efforts but still need to know what's what. The UML is a pretty big language; I suggest you visit my UML Dictionary (http://usecasedriven.com/UML.htm) and the UML Resource Center (http://www.rational.com/UML) if you want to explore it in depth.

I made my living as a technical writer for 16 years, translating complicated subject matter into reader-friendly documents and manuals. Now I make my living as a trainer and mentor, teaching people about the UML and about the approach to software development that Use Case Driven Modeling with UML (Rosenberg and Scott, Addison-Wesley, 1999) advocates. I'd like to think that this book reflects my years of experience.

Organization of This Book

Chapter 1, Why the UML?, describes why it's important to learn about the UML. This includes an explanation of the crucial nature of visual modeling. The chapter also offers some history about how the UML evolved and an overview of the key underlying principles of the language.

Chapter 2, The UML and Process, explains that even though the UML is technically process independent, it's been explicitly designed to work within the context of an iterative and incremental process. This discussion includes an overview of the Unified Process and a look at how the phrases "use case driven," "architecture-centric," and "iterative and incremental" will appear, in one form or another, throughout the rest of the book.

Chapter 3, Identifying Relevant Real-World Things, describes how a project team uses the UML in identifying, and beginning to refine, the things and concepts in the real world of relevance to the problem that the team is trying to solve with the new system. This chapter introduces The Internet Bookstore, a proposed online bookstore that will serve as a running example throughout the rest of the book.

Chapter 4, Capturing Requirements, describes how people can use what are known as "use cases," which are scenarios that include user actions and system responses, to explore, negotiate, and refine functional requirements. The chapter also addresses the role that prototyping plays in the development and refinement of use cases.

Chapter 5, Expressing How Things Work Together, describes how a project team explores how objects work together to address the behavior specified by use cases, as well as other required system behavior. This includes a discussion of robustness analysis, which uses extensions to the UML that are specific to the Unified Process.

Chapter 6, Refining the Structure of Things, describes the tasks involved in refining and expanding the domain model, which contains the real-world things and concepts first discussed in Chapter 3, and how this effort happens in response to the work involved in modeling interactions (discussed in Chapter 5).

Chapter 7, Describing Flows, describes how you can use the UML to describe business and process workflows. The chapter also discusses how you capture the behavior of a system that can have multiple activities occurring at once.

Chapter 8, Tracking the Lives of Things, describes how the UML represents the lifetimes of objects as they carry out the work of the system. This discussion includes a look at how certain kinds of objects can exist in more than one state at the same time.

Chapter 9, Showing How Groups of Things Work Together, describes how a team can use various UML constructs and diagrams to illustrate how groups of things will work together in the system, on a conceptual level. This includes the UML definitions of terms such as "pattern" and "framework" that are increasingly important in the realm of software development.

Chapter 10, Describing How Things Will Be Built, describes the ways that one shows how the system being designed will actually be built, in terms of packages of software called "components," and how those components will be geographically distributed in the new system.

The book also includes a glossary, which contains definitions for all the terms introduced in the body of the text, and a complete index.

Background

This book has been in the works for a long time.

The story starts in the spring of 1996. I was living in Dallas, getting a little bored making my living as a technical writer, cranking out software documentation for programmers I'd never meet. I decided to approach Rational about getting some kind of job that would get me closer to actual customers.

That conversation didn't lead to anything in the way of a job, but it did lead to me getting a copy of the 0.8 version of the documentation set for what was then called the Unified Method, written by Grady Booch (who I'd heard of) and James Rumbaugh (who I hadn't). After a quick glance at the densely packaged paragraphs and the scary diagrams (one had 15 boxes and 19 lines), I put it aside.

My relentlessly curious nature caused me to pick up the book again soon after that. Then I spent several hours trying to make sense out of it. I finally realized that I was looking at something fairly significant, and that the only way I'd be able to really understand it would be to rewrite it. I was just beginning to follow the comp.object newsgroup on the Internet, so I decided, on a lark, to post a query that read something like this: "What would you think if a professional writer rewrote this material?"

Grady Booch wrote back and said "Go for it!"

This was more than a little disorienting. On the one hand, I was encouraged to get a positive response; on the other hand, I thought, "Great. The first thing I did is annoy Grady Booch." When I asked him what he meant, though, he told me that he and Jim and Ivar Jacobson (whose name would appear on the cover of the next version of the Unified Method documentation) were all likely to write 600-page books, and there was a good chance they wouldn"t be ready for a long time. Then he said that if I were to write a concise guide to the Unified Method--say, 150 pages--people would buy it.

So, I put together a proposal and sent it to Addison-Wesley, on my birthday (never mind which one). I was pretty dubious about it, given that I knew almost nothing about object orientation, but I figured I had nothing to lose.

Over the next six months, the proposal didn't get accepted, but it wasn't exactly rejected either. I decided to move to San Francisco at the end of 1996, and soon after that, interesting things started happening.

I met the editor to whom I'd submitted the proposal, Carter Shanklin, at Rational's user conference early in 1997. He said that my proposed book wasn't going to be viable, but also that he was ready to do a deal for the first book about what was now called the Unified Modeling Language (UML), and that he'd be interested in having me involved in some way.

Around that time, I met Jim and Ivar. (Grady was at Oracle, so unfortunately I didn't get a chance to meet him then and thank him for helping me get to that point. Oddly enough, I was working for Oracle at the time.) There were various ideas bouncing around about how this book was going to get done, but in the end, Booch, Jacobson, and Rumbaugh weren't directly involved in the production of the book. Instead, Carter brought Martin Fowler, whose recently published Analysis Patterns was already getting great reviews, and myself together to see if the chemistry was right for cranking a book out in, oh, four months.

I had no idea whether we could come anywhere near meeting that deadline, but I figured I'd give it a shot. Martin already had about half the book written when we got started, which helped considerably. The first thing I did was take a chunk of about 75 pages of text and diagrams and turn it into a reviewable piece of material, making decisions about subsections and mixing up paragraph lengths and many other things--over a period of three days, which included one full day of work for Oracle--and we were off to the races. I guess UML Distilled came out pretty well, all things considered.

After the book came out, I wanted to publish something in my own voice, so I put together the first version of my UML Dictionary. This was based on the official documentation that Rational submitted to the Object Management Group (OMG) in the spring of 1997, when it was first seeking approval of the UML as a standard. The text was still fairly stiff, but at least I was getting a good handle on the material.

The Dictionary led to another book deal (Use Case Driven Object Modeling, with Doug Rosenberg), and now, here I am with my first solo book.

Acknowledgments

I'd like to thank the Academy...

Let's start again.

I'd like to thank the several thousand people who've played crucial roles in my development as an author. In alphabetical order...

Maybe not.

I'd like to extend special thanks to the following Lucky 13: Guy and Nancy Scott, who had the good sense to put me on the right path and then (mostly) stay out of the way; Jonathan Leach, intellectual foil supreme; Lisa Silipigni, who helps me remember every day to fight the good fight; Grady Booch, without whom I wouldn't have been able to write this book; Martin Fowler, for letting me produce the world's best UML book; Carter Shanklin, Paul Becker, and Ross Venables, past and present representatives of a class organization, Addison-Wesley; Doug Rosenberg, who supplied the inspiration for the running example, taught me how to do robustness analysis, and provides me a healthy living as a UML trainer and mentor; Laura Danoff, for at least trying to read my other books; Robert Pirsig, who posed the questions that keep me going; and Hunter Faires, the greatest teacher ever.

Kendall Scott
Harrison, Tennessee
February 2001
kendall@usecasedriven.com
http://usecasedriven.com

0201721821P04062001

Index

A

abstract class

defined 75

example 76

notation 76

action

defined 59, 89

examples 64, 90, 103

notation 60, 61, 62, 63, 90

active class

defined 96

example 97

notation 97

active object

defined 96

example 97

notation 97

activity

defined 89

examples 90

notation 90

activity diagram

defined 94

example 95

actor

defined 39

examples 40

notation 40

addOnly property, 79

adornments

and classes 26

notes 35

aggregation

defined 27

examples 30

notation 29, 30

alternate course of action

defined 43

examples 44, 46

analysis class

and packages 72

types 53

analysis model

analysis classes 53

Analysis workflow 15

and architecture 15

defined 14

packages of classes 37

robustness diagrams 72

and use case model 13

use cases 49

analysis package 72, 73

Analysis workflow

activities 14

and frameworks 117

robustness analysis 53

and Unified Process phases 15

architectural baseline 11, 19

architecture 7

architecture-centric 11

association

defined 25

examples 26, 27, 28

name 26, 27

navigation 27

notation 26

association class

defined 30

example 33

notation 32

attribute

defined 22

details 79

examples 22

full form 78

B

balking message 72

basic course of action

defined 43

examples 43, 45

behavior allocation 88

black-box testing 17, 52

Booch method 6

Booch, Grady xiii, xvi, 4, 6

boundary object

defined 54

examples 55, 56, 57

and Model-View-Controller pattern 118

notation 54

branch

defined 90

example 91

notation 91

C

call action

defined 60

examples 61

notation 60

call event 99

candidate architecture 10, 11

change event 100

changeable property 79

child

defined 28

examples 32

class

versus component 122

defined 23

examples 24, 38

interface 84

notation 23, 24, 38

notation (described) 38

versus object 23

and use case text 44

class diagram

defined 32

example 34

collaboration

defined 111

examples 112, 118

and frameworks 117

notation 112

collaboration diagram

defined 70

elements 70

example 71

component

versus class 122

defined 121

examples 123, 125

and nodes 126

notation 122

versus package 121

component diagram

defined 124

examples 125

locationtagged value 128

composite state

defined 106

examples 107, 110

notation 107

composition 119, 125

concurrent property 80

concurrent substate

defined 109

examples 110

notation 110

constraint

defined 82

examples 83

notation 82

Construction phase

Analysis workflow 15

Design workflow 16

Implementation workflow 16

Requirements workflow 14

tasks 12

Test workflow 17

control object

defined 54

examples 56, 58

and Model-View-Controller pattern 118

notation 55

create action

defined 61

notation 62

cycle 9

D

data hiding 22

deferred event 106

dependency

and components 124

defined 76

examples 77, 125

notation 77

deployment component

defined 123

example 124

deployment diagram

defined 127

example 127

deployment model

architecture 15

defined 15

deployment diagrams 128

Design workflow 15

and use case model 13

use cases 50

deployment package 128

deployment view

defined 8

deployment model 15

design class 87

design model

and analysis model 66

architecture 15

defined 15

Design workflow 15

and use case model 13

use cases 50

design package 74, 87, 98, 110, 129

design pattern

defined 114

example 116

sample behavior 117

sample structure 116

design view

analysis model 15

defined 7

design model 15

Design workflow

activities 15

collaboration diagrams 70

sequence diagrams 65

and Unified Process phases 15

destroy action

defined 62

notation 63

document stereotype 123

domain model

defined 38

refining and expanding 75

and use case text 44

E

Elaboration phase

Analysis workflow 15

Design workflow 16

Implementation workflow 16

Requirements workflow 14

tasks 11

Test workflow 17

encapsulation 22

entity object

defined 54

example 58

and Model-View-Controller pattern 118

notation 54

entry action 105

event

defined 99

examples 103, 104, 107

exceptional flow of events

defined 43

examples 44, 46

exceptions 63

executable stereotype 123

execution component 123

exit action 106

extend

defined 47

example 48

notation 48

extension points

defined 47

example 48

F

file stereotype 123

final state

defined 105

on activity diagram 94

on statechart diagram 105

flowchart 91

focus of control 65

fork

defined 92

example 93

notation 92

forward engineering 3

Fowler, Martin xiii, xvii

framework

defined 117

example 118

notation 118

frozen property 79

G

generalization

defined 28

examples 32, 50, 76

notation 31, 49

and use cases 48

guard condition

defined 91, 103

examples 104

notation 103

guarded property 80

H

history state

defined 108

example 109

notation 108

I

implementation model

architecture 16

component diagrams 128

defined 16

Implementation workflow 16

and use case model 13

use cases 50

implementation package 128

implementation view

defined 8

implementation model 16

Implementation workflow

activities 16

and Unified Process phases 16

Inception phase

Analysis workflow 15

Design workflow 15

Implementation workflow 16

Requirements workflow 14

tasks 10

Test workflow 17

include

defined 46

examples 47

notation 47

increment 17

inheritance 29

Initial Operational Capability|

major milestone 12

initial state

defined 105

on activity diagram 94

on statechart diagram 105

instance 23

interaction diagrams 71

interface

class 84

component 121

defined 84

examples 85, 123

notation 84, 122

internal transition 106

isQuery property 80

iteration 17

iterative and incremental

defined 17

illustrated 18

J

Jacobson, Ivar xiii, xvi, 4, 5, 6

join

defined 92

example 93

notation 92

L

library stereotype 123

Life-Cycle Architecture major milestone 12

Life-Cycle Objectives major milestone 11

lifeline 60, 65

location tagged value 128

lollipop notation 84, 122

M

main flow of events

defined 43

examples 43, 45

major milestone

defined 9

Initial Operational Capability 12

Life-Cycle Architecture 12

Life-Cycle Objectives 11

Product Release 12

mechanism

defined 114

and frameworks 117

merge

defined 90

example 91

notation 91

message

defined 59

examples 66, 67, 68

on sequence diagrams 65

method

defined 22

versus operation 23

method wars 4

model

construction 3

defined 1

documentation 3

good qualities 3

specification 2

visualization 2

Model-View-Controller architectural pattern 117, 118

multiple inheritance 29

multiplicity

allowable values 27

and associations 27

and attributes 79

examples 28

MVC pattern 117

N

N-ary association 26

navigation 27

node

defined 126

examples 126, 127

notation 126

note

defined 35

examples 36

notation 36

O

object

versus class 23

defined 21

essential aspects 21

notation 34

object diagram

defined 34

example 35

object flow

defined 94

examples 97

Object Management Group (OMG) xvii, 7

Object Modeling Technique (OMT) 5

Objectory process 4

OMG xvii, 7

OMT 5

operation

defined 23

details 81

full form 80

P

package

versus component 121

defined 36

examples 37, 51, 73, 74, 87, 98, 110, 118, 128, 129

notation 37, 50

parameterized collaboration

defined 114

notation 115

parent

defined 28

example 32

path name

defined 38

examples 38

pattern

architectural 117

defined 114

design 114

notation 115

phase

Construction 12

defined 9

Elaboration 11

Inception 10

Transition 12

physical diagrams 128

polymorphism 29

private visibility

defined 78

examples 78

process

defined 96

stereotype 98

process view

analysis model 15

defined 8

design model 15

Product Release major milestone 12

protected visibility

defined 78

examples 78

prototyping 14, 51

Proxy design pattern

behavior 117

illustrated 116

structure 116

public visibility

defined 78

examples 78

R

realization

defined 84, 112

examples 113, 123

notation 113

Requirements workflow

activities 13

prototyping 14

and Unified Process phases 14

responsibility

defined 24

notation 25

return action

defined 60

example 61

notation 61

reverse engineering

defined 3

and use cases 51

robustness analysis

defined 53

example 59

rules 56

robustness diagram

defined 55

example 59

and packages 73

role

defined 27

examples 28

round-trip engineering 3

Rumbaugh, Jim xiii, xvi, 4, 5, 6

S

self-aggregation 30

self-transition

defined 102

example 103

notation 102

send action

defined 63

example 64

notation 63

sequence diagram

defined 64

elements 65

example 69

timing constraint 72

sequence numbers 70

sequential property 80

sequential substate

defined 106

examples 107

notation 107

signal

defined 63, 99

examples 65

notation 64

single inheritance 29

source state 101

Standard Template Library (STL) 85

state

defined 100

examples 101

notation 100

state diagram

defined 104

example 105

state machine 104

statechart diagram

defined 104

example 105

stereotype

defined 81

examples 82

notation 81

Unified Process 82

STL 85

subclass

defined 28

examples 32

substate

concurrent 109

defined 106

examples 107, 110

sequential 106

substitutability 29

subsystem

defined 118

examples 119

notation 119

superclass

defined 28

example 32

swimlane

defined 94

examples 96

synchronization bar

defined 92

examples 93

notation 92

system

defined 118

example 119

notation 119

T

table stereotype 123

tagged value

defined 83

examples 83

notation 83

target state 101

template class

defined 85

example 86

notation 86

test model

defined 16

Test workflow 17

and use case model 13

use cases 52

Test workflow

activities 16

and Unified Process phases 17

thread

defined 96

stereotype 98

time event 99

time expression

defined 71

example 72

timeout message 72

timing constraint

defined 71

example 72

timing mark

defined 71

example 72

traceability 73

transition

defined 92, 101

examples 102, 103

notation 101, 102

Transition phase

Analysis workflow 15

Design workflow 16

Implementation workflow 16

Requirements workflow 14

tasks 12

Test workflow 17

triggerless transition 94, 101

U

Unified Method xvi, 6

Unified Process

Analysis workflow 14

basic models 13

Construction phase 12

Design workflow 15

Elaboration phase 11

extensions 82

Implementation workflow 16

Inception phase 10

major milestones 10

and Objectory 5

phases 10

Requirements workflow 13

Test workflow 16

Transition phase 12

Unified Process-Specific Extensions 82

use case

alternate course of action 43

basic course of action 43

defined 40

examples 41, 43, 45

exceptional flow of events 43

and extend relationship 47

generalization 48

and include relationship 46

main flow of events 43

notation 41

and prototyping 51

use case diagram

defined 41

example 42

notation 42

use case driven 87, 98, 110

use case model

and architecture 14

contents 41

as contractual agreement 46

defined 13

and Requirements workflow 14

use case realization--analysis 112

use case view

defined 7

use case model 14

user manual 51

V

view

defined 7

types 8

visibility

defined 77

examples 78

levels 78

W

white-box testing 17, 59

work product component

defined 123

examples 124

workflow

Analysis 14

defined 13

Design 15

Implementation 16

Requirements 13

Test 16



Updates

Submit Errata