UML 2 and the Unified Process _ Practical Object-Oriented Analysis and Design [2 ed.] 0321321278, 2005004126

Citation preview

UML2 and

the nified Process, Second Edition

The Addison-Wesley Object Technology Series Grady Booch, Ivar Jacobson, and James Rumbaugh, Series Editors For more information, check out the series web site at www.awprofessional.com/otseries. Ahmed/Unuysh, Developing Ente1prise Java Applications with J2E£fM andUML Arlow/Neustadt, Ente,prise Patterns and MDA: Building Better Software with Archetype Patterns and UML Arlow/Neustadt, UML 2 and the Unified Process, Second Edition Armour/Miller, Advanced Use Case Modeling: Software Systems Bellin/Simone, The CRC Card Book Bergstrom/Raberg, Adopting the Rational Unified Process: Success with theRUP Binder, Testing Object-Oriented Systems: Models, Patterns, and Tools Bittner/Spence, Use Case Modeling Booch, Object Solutions: Managing the Object-Oriented Project Booch, Object-OlientedAnalysis and Design with Applications, 2E Booch/Bryan, Software Engineeling with ADA, 3E Booch/Rurnbaugh/Jacobson, The Unified Modeling Language User Guide, Second Edition Box et al., Effective COM: 50 Ways to Improve Your COM and MTSbased Applications Buckley/Pulsipher, 17w Arl of ClearCase® Deployment Carlson, Modeling XML Applications with UML: Practical e-Busbwss Applications Clarke/Baniassad, Aspect-O,iented Analysis and Design Collins, Designing Object-Oliented User Inteifaces Conallen, Building Web Applications with UML, 2E Denney, Succeeding with Use Cases D'Souza/Wills, Objects, Components, and Frameworks with UML: 17w Catalysis(SM) Approach Douglass, Doing Hard Time: Developing Real-1inw Systems with UML, Objects, Fra,neworks, and Patterns Douglass, Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems Douglass, Real 1inw UML, 3E: Advances in The UML for Real-Time Systems E.eles et al., Building J2E£fM Applications with the Rational Unified Process Fowler, Analysis Patterns: Reusable Object Models Fowler, UML Distilled, 3E: A Brief Guide to the Standard Object Modeling Language Fowler et al., Refactoring: Improving the Design ofExisting Code Gomaa, Designing Concurrent, Distributed, and Real-Time Applications withUML Gomaa, Designing Software Product Lilws with UML Heinckiens, Building Scalable Database Applications: Object-O,iented Design, Architectures, and Implementations Hofmeister/Nord/Dilip, Applied Software Architecture Jacobson/Booch/Rurnbaugh, The Unified Software Development Process Jacobson/Ng, Aspect-O1iented Software Development with Use Cases Jordan, C++ Object Databases: Progra,mning with the ODMG Standard Kleppe/Warmer/Bast, MDA Explained: 17w Model Dliven Architecture™: Practice and Promise Kroll/Kruchten, The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP

Kruchten, 17w Rational Unified Process, 3E: An Introduction LaLonde, Discovering Smalltalk Lau, The A11 of Objects: Object-Oriented Design and An:hitecture Leffingwell/Widrig, Managing Software Requirements, 2E: A Use Case Approach Manassis, Practical Software Engilweling: Analysis and Design for the .NET Plaifonn Marshall, Ente,prise Modeling with UML: Designing Succesefitl Software through Busilwss Analysis McGregor/Sykes, A Practical Guide to Testing Object-Oliented Software Mellor/Balcer, Executable UML· A Foundation for Model-Dliven Architecture Mellor et al., MDA Distilled: Plinciples ofModel-Dliven Architecture Naiburg/Maksimchuk, UMLforDatabase Design Oestereich, Developing Software with UML, 2E: Object-Oliented Analysis and Design in Practice Page-Jones, Fundamentals of Object-Oriented Design in UML Pohl, Object-O1iented Programming Using C++, 2E Pollice et al. Software Developmentfor Small Teams: A RUP-Centric Approach Quatrani, Visual Modeling with Rational Rose 2002 and UML Rector/Sells, ATL Internals Reed, Developing Applications with Visual Basic and UML Rosenberg/Scott, Applying Use Case Dliven Object Modeling with UML: An A111wtated e-Commerce Example Rosenberg/Scott, Use Case Dliven Object Modeling with UML· A Practical Approach Royce, Software Project Management: A Unified Framework Rurnbaugh/Jacobson/Booch, The Unified Modeling Language Reference Manual Schneider/Wmters, Applying Use Cases, 2E: A Practical Guide Smith, IBM Smalltalk Smith/Williams, Peifonnance Solutions: A Practical Guide to Creating Responsive, Scalable Software Thach/Fang/So, Visual Modeling Technique Thach/Puttick, Object Tech,wlogy in Application Development, Second Edition Unhelkar, Process Quality Assurance for UML-Based Projects Warmer/Kleppe, 171e Object Constraint Language, 2E: Getting Your Models Ready for MDA White, Software Configuration Manage1nent Strategies and Rational ClearCase®: A Practical Introduction

The Component Software Series Clemens Szyperski, Series Editor For more information, check out the series web site at www.awprofessional.com/csseries. Cheesman/Daniels, UML Components: A Simple Process for Specifying Component-Based Software Szyperski, Component Software, 2E: Beyond Object-Oliented Programming

JIM ARLOW AND ILA NEUSTADT

UM 2 an th Unifie Pr C ' Se nd E iti n Practical Object-Oriented Analysis and Design

., "'-., Addison-Wesley Upper Saddle River, NJ • Boston• Indianapolis • 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 the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The UML™ logo is a trademark or registered trademark of the Object Management Group, Inc., in the United States and other countries. 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 excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales (800) 382-3419 [email protected] For sales outside the U.S., please contact: International Sales [email protected] Visit us on the Web: www.awprofessional.com

Library of Congress Cataloging-in-Publication Data Arlow, Jim, 1960UML 2 and the unified process : practical object-oriented analysis and design / Jim Arlow, Ila Neustadt.2nd ed. p. cm. Includes bibliographical references and index. ISBN 0-321-32127-8 (pbk.: alk. paper) 1. Object-oriented methods (Computer science) 2. Computer software--Development. 3. UML (Computer science) I. Neustadt, Ila. IL Title. QA76.9.O35A74 2005 005.l'l-dc22 2005004126 Copyright© 2005 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc. Rights and Contracts Department One Lake Street Upper Saddle River, NJ 07 458 ISBN 0-321-32127-8 Text printed in the United States on recycled paper at Courier in Westford, Massachusetts. Second printing, February 2006

To our parents

Contents Acknowledgments Preface

Part1 1

Introducing UML and UP

1

What is UML?

3

1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11

2

xvii xix

Chapter roadmap What is UML? The birth of UML MDA - the future of UML Why "unified"? Objects and UML UML structure UML building blocks UML common mechanisms Architecture What we have learned

3 5 5 7 9 10 10 11 15 23 24

What is the Unified Process?

27

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10

27 28 29 32 34 34 35 37 39 44

Chapter roadmap What is UP? The birth of UP UP and the Rational Unified Process Instantiating UP for your project UP axioms UP is an iterative and incremental process UP structure UP phases What we have learned

ix

x

Contents

3 The requirements workflow 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Chapter roadmap The requirements workflow Software requirements - metamodel Requirements workflow detail The importance of requirements Defining requirements Finding requirements What we have learned

4 Use case modeling 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

Chapter roadmap Use case modeling UP activity: Find actors and use cases UP activity: Detail a use case Use case specification Requirements tracing When to apply use case modeling What we have learned

5 Advanced use case modeling 5.1 5.2 5.3 5.4

PartJ

Chapter roadmap Actor generalization Use case generalization

5.5

«include» «extend»

5.6 5.7 5.8

When to use advanced features Hints and tips for writing use cases What we have learned

Analysis

6 The analysis workflow 6.1 6.2

Chapter roadmap The analysis workflow

49 49

51 52 53 55 55 61 65 67 67 69 69 77 78 90 91 92

95 95 97 99

102 105 110 111 113 117 119 119 120

Contents

6.3 6.4 6.5 6.6

7

Analysis artifacts - metamodel Analysis workflow detail Analysis model - rules of thumb What we have learned

125

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8

125 127 131 132 136 147 148 151

8.1 8.2 8.3 8.4 8.5 8.6

10

121 122 122 124

Objects and classes Chapter roadmap What are objects? UML object notation What are classes? UML class notation Scope Object construction and destruction What we have learned

8 Finding analysis classes

9

xi

Chapter roadmap UP activity: Analyze a use case What are analysis classes? Finding classes Creating a first-cut analysis model What we have learned

155 155 157 158 163 171 172

Relationships

175

9.1 9.2 9.3 9.4 9.5 9.6

175 177 177 180 195 201

Chapter roadmap What is a relationship? What is a link? What is an association? What is a dependency? What we have learned

Inheritance and polymorphism

205

10.1 10.2 10.3 10.4 10.5 10.6

205 206 208 211 215 221

Chapter roadmap Generalization Class inheritance Polymorphism Advanced generalization What we have learned

•

0

•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

xii

Contents

11

Analysis packages 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8

12

Use case realization 12.1 12.2 12.3 12.4 12.5 12.6 12.7 12.8 12.9 12.10 12.11 12.12

13

Chapter roadmap UP activity: Analyze a use case What are use case realizations? Use case realization - elements Interactions Lifelines Messages Interaction diagrams Sequence diagrams Combined fragments and operators Communication diagrams What we have learned

Advanced use case realization 13.1 13.2 13.3 13.4

14

Chapter roadmap What is a package? Packages and namespaces Nested packages Package dependencies Package generalization Architectural analysis What we have learned

Chapter roadmap Interaction occurrences Continuations What we have learned

Activity diagrams 14.1 14.2 14.3 14.4 14.5 14.6 14.7

Chapter roadmap What are activity diagrams? Activity diagrams and the UP Activities Activity semantics Activity partitions Action nodes

223 223 224 226 227 228 231 231 235 239 239 241 242 243 244 244 246 248 249 256 264 268 273 273 274 279 281 283 283 284 285 286 288 290 293

• • • • • • • • • • • .. . . . . . . . . . . . . . . . 1;10• •

•

o• • • • • • • • • • • • • • ao • • oo o••a ••

•1;1 • • • • •

•

•

•

•

• • • • .. • • • • • • • • • •

•

••

o • • • • • • • • • • • • .. • • • • • • • o • • • • • • • • •o • • • • • • • •

Contents

Control nodes Object nodes Pins What we have learned

297 301 305 307

Advanced activity diagrams

309

14.8 14.9 14.10 14.11

15

15.1 15.2 15.3 15.4 15.5 15.6 15.7 15.8 15.9 15.10 15.11 15.12 15.13

Part

16

Chapter roadmap Connectors Interruptible activity regions Exception handling Expansion nodes Sending signals and accepting events Streaming Advanced object flow features Multicast and multireceive Parameter sets «centralBuffer» node Interaction overview diagrams What we have learned

309 311 311 312 313 314 317 318 320 321 322 323 325

Design

329

The design workflow

331

16.1 16.2 16.3 16.4 16.5 16.6

17

xiii

Chapter roadmap The design workflow Design artifacts - metamodel Design workflow detail UP activity: Architectural design What we have learned

Design classes 17.1 17.2 17.3 17.4 17.5 17.6 17.7

Chapter roadmap UP activity: Design a class What are design classes? Anatomy of a design class Well-formed design classes Inheritance Templates

331 332 333 337 338 339 341 341 342 344 345 347 350 354

1;,

>!J ~>(IO

6

{I>

0

AA~ 0

0

0

,t./ Q (II Q O ~, Q Ill O

ti Q :0

Q

O Q 6

Q ~

tl- 0 #-

Q

Q Q

Preface

Read the "What we have learned" section. Go back to any section that takes your interest and read it. Fast Track is a quick and efficient way to read this book. You may be pleasantly surprised at how much you can pick up! Note that Fast Track works best if you can first formulate a clear idea of the information you want to obtain. For example "I want to understand how to do use case modeling."

Reference If you need to know a particular part of UML or learn a particular technique, we have provided a detailed index and table of contents that should help you locate the information you need quickly and efficiently. The text is carefully cross-referenced to help you to do this.

Revision There are two strategies for revision with this text. If you need to refresh your knowledge of UML as quickly and efficiently

as possible, read the outline summaries of each chapter in the "What we have learned" section. When you don't understand something, go back and read the appropriate section. If you have more time, you can also browse through each chapter study-

ing the diagrams and reading the margin notes.

Dipping If you have a few minutes to spare, you might pick up the book and open it

at random. We have tried to ensure that there is something interesting on every page. Even if you already know UML quite well, you may still discover new things to learn.

Book roadmap Figure 2 shows a roadmap for this book. We have indicated where chapters may be read in any order and where there are advanced techniques that you may choose to skip on first reading.

Part1 Introducing UM. and UP

Part 2:

Requirements Chapter 4: Use case modeling peamadvancedtechnlques]

Chapter 5: Advanced use case modeling

Part 3: Analy.,ls

peam how to find enely.,ls classes]

Peamaboutpackages]

Chapter 8: Anding analy&ls classes

Chapter 11:Analysls packages

Chapter 10: Inheritance and polymorphism

Chapter 12: Use case reallzatlon Peamadvanced t e c h n i q u e s ) , - - - - - - - - - - - - - -

< " > - - - - - - - ; , { Chapter 13:Advanced use case realization

peam advanced techniques] ,-C-ha-pt-er-15-,Ad-va-nc-ed-a-ct_lvl_ty_dla-g-ram_s.._

Part4: Design

Chapter 19: Interfaces and components

Chapter 22: Advanced state machines

Chapter 23: The Implementation workflow

peam about OCLJ

< : > - - - - - - - - - - ; > ! Chapter25:lntroductlontoOCL Part 6: Supplemenlery

material [study an example model) < :>--'-----'-----'---'----;>! Appendix 1: Example use case model

peam aboutappl~ng XML to use cases J r - - - - - - - ~ < ~>---c;_;_..;;._ _ _ _--;;/ Appendix 2:XMLand use cases

Figure 2

xxiii

part

1

Introducing UML and UP

,,

chapter

1 What is UML?

1.1

Chapter roadmap This chapter provides a brief overview of the history and high-level structure of the UML. We mention many topics that will be expanded in later chapters. Beginners should start by learning about UML history and principles. If you have experience in UML, or are satisfied that you already know enough about UML history, you can skip straight to Section 1. 7 and the discussion of UML structure. There are three main strands to this discussion, which may be read in any order. You can find out about UML building blocks (1.8), UML common mechanisms (1.9), and architecture and UML (1.10).

3

.a::-

peam about UML history] 1.3 The birth of UML

1.4 MDA • the future of UML peam about UML principles]

1.5 Why "unified"?

1.6 Objects and UML

peam about UML building blocks]

peam about UML common mechanisms]

1.8 UML building blocks

1.9 UML common mechanisms

1.8.2 Relationships

1.9.1 Specifications

1.9.2 Adornments

1.9.3 Common dMsions

peam aboutarch!ecture and UML] '

1.9.4 Extensibility mechanisms

1.9.3.1 Classifier and instance

1.9.3.2 Interface and implementation

1.9.4.3 Tagged values

1.11 What we have learned

Figureu

1.10 Architecture

'

r,

~~

Q

"o

t> Q Q,..,:, to>- Q

o o

Q

o u

111

a

111

u o u u a

Q 0

Q :it> u o

~ Q

a~ a tl G

a r,

tt> >:. ~~

Q

o o

-0 f/t

w

◊

Introducing UML and UP

MDA mandates a degree of automation of this process that is, as yet, rarely achieved. In MDA, software is produced through a series of model transformations aided by an MDA modeling tool. An abstract computer-independent model (CIM) is used as a basis for a platform-independent model (PIM). The PIM is transformed into a platform-specific model (PSM) that is transformed into code. The MDA notion of model is quite general, and code is considered to be just a very concrete kind of model. Figure 1.3 illustrates the MDA model transformation chain.

MDA

Computer-A independent· model (CIM)

r-\

L--y'

Platform- A independent model (PIM)

map

Platform-A specific model (PSM)

Figure 1.3

The CIM is a model at a very high level of abstraction that captures key requirements of the system and the vocabulary of the problem domain in a way that is independent of computers. It is really a model of that part of the business that you are going to automate. Creation of this model is optional, and if you choose to create it, you use it as a basis for producing the PIM. The PIM is a model that expresses the business semantics of the software system independently of any underlying platform (such as EJB, .NET, and so on). The PIM is generally at roughly the same level of abstraction as the analysis model that we will talk about later in this book, but it is more complete. This is necessarily so, as it has to provide a sufficiently complete basis to be transformed into a PSM from which code can be generated. A point worth noting is that the term "platform independent" means very little unless you define the platform or platforms from which you wish to be independent! Different MDA tools support different levels of platform independence. The PIM is adorned with platform-specific information to create the PSM. Source code is generated from the PSM against the target platform.

Q Q AA# V, (J ,:,

Q

"o

I,)

Q""

x,

u 1:>o

I)() 1;.

o

,;i ~ " '

Q

a

IJ ,;i

o

~

t>"

ti l::i 1~ '(IQ GQ

no -o u oo o

in (I t.1

o ,.., o a o "Ar.>

Introducing UML and UP

Implementation languages and platforms - UML is language neutral and platform neutral. Naturally, it has excellent support for pure 00 languages (Smalltalk, Java, C#, etc.), but it is also effective for hybrid 00 languages such as C++ and object-based languages such as Visual Basic. It has even been used to model for non-00 languages such as C. Development processes - although UP and its variants are probably the preferred development processes for 00 systems, UML can (and does) support many other software engineering processes. Its own internal concepts - UML valiantly tries to be consistent and uniform in its application of a small set of internal concepts. It doesn't (as yet) always succeed, but it is still a big improvement on prior attempts.

1.6 UML models the world as systems of interacting objects. An object is a cohesive cluster of data and function.

Objects and UML The basic premise of UML is that we can model software and other systems as collections of interacting objects. This is clearly a great fit with 00 software systems and languages, but it also works very well for business processes and other applications. There are two aspects to a UML model. Static structure - this describes what types of objects are important for modeling the system and how they are related. Dynamic behavior - this describes the life cycles of these objects and how they interact with each other to deliver the required system functionality. These two aspects of the UML model go hand-in-glove, and one is not truly complete without the other. We look at objects (and classes) in full detail in Chapter 7. Until we get there, just think of an object as being a cohesive cluster of data and behavior. In other words, objects contain information and can perform functions.

1.7 UML structure You can begin to understand how UML works as a visual language by looking at its structure. This is illustrated in Figure 1.4 (as you will see later, this is a valid UML diagram). This structure consists of building blocks - these are the basic UML modeling elements, relationships, and diagrams; common mechanisms - common UML ways of achieving specific goals; architecture - the UML view of system architecture.

Chapter

1

What is UML?

11

UML

Building blocks

Common mechanisms

Architecture

Figure 1.4

Understanding the structure of UML gives us a useful organizing principle for the rest of the information presented in this book. It also highlights that UML is, itself, a designed and architected system. In fact, UML has been modeled and designed using UML! This design is the UML metamodel.

1.8

UML building blocks According to The Unified Modeling Language User Guide [Booch 2], UML is composed of just three building blocks (see Figure 1.5). Things - these are the modeling elements themselves. Relationships - these tie things together. Relationships specify how two or more things are semantically related. Diagrams - these are views into UML models. They show collections of things that "tell a story" about the software system and are our way of visualizing what the system will do (analysis-level diagrams) or how it will do it (design-level diagrams).

Building blocks

Things

Figure 1.5

Relationships

Diagrams

o~

~Q

12

o e, o,;::,

#

~

o"' o a #a

e,

a o

Part 1

ti

o oo a o o o o o o

Q

o

«> o QO

1:1

a o oar; a r;

ia,

o

~o~

Q

o o oo oo o ,oo oo

~

OQ

o

e, Q

a o \} o,:, o o

t;,

o

t;,

o

Q

o

Q

o oo

f;I

o o;z as a o a o a

Q

e,

oa

Q

coo o o

-1>00

o ooo o

r:t OQ

o

Q

ou o

,a,

o

Introducing UML and UP

We'll look at the different types of building blocks in a little more detail in the next three sections.

1.8.1

Things UML things may be partitioned into

"Things" are the nouns of a UML model.

structural things - the nouns of a UML model, such as class, interface, collaboration, use case, active class, component, node; behavioral things - the verbs of a UML model, such as interactions, activities, state machines; grouping things - the package, which is used to group semantically related modeling elements into cohesive units; annotational things - the note, which may be appended to the model to capture ad hoc information, very much like a yellow sticky note. We'll look at these things, and how they are usefully applied in UML modeling, in Part 2 onwards.

1.8.2

Relationships Relationships allow you to show on a model how two or more things relate to each other. Thinking of families, and the relationships between all of the people in a family, gives you a pretty good idea of the role relationships play in UML models-they allow you to capture meaningful (semantic) connections between things. For example, UML relationships that apply to the structural and grouping things in a model are summarized in Table 1.1. Understanding the exact semantics of the different types of relationship is a very important part of UML modeling, but we will defer a detailed exploration of these semantics until later sections of the book.

1.8.3

Diagrams are only views into the model.

Diagrams In all UML modeling tools, when you create a new thing or new relationship, it is added to the model. The model is the repository of all the things and relationships that you have created to help describe the required behavior of the software system you are trying to design. Diagrams are windows or views into the model. The diagram is not the model itself! This is actually a very important distinction, as a thing or relationship may be deleted from a diagram, or even from all diagrams, but may still exist in the model. In fact, it will stay in the model until explicitly deleted from it. A common error of novice UML modelers is to delete things from diagrams but leave them in the model.

001;1,e,QqUtJ"-l!l"-0"•"••••1At>\\lt1ac,Qt>aooooq,oool\tOQottoq,0111oaou.oaoa,::1000000000001:roaoQa,:,111at1aoa11at1aQ'l'IQoooooQ01,1:01:toaoaoaoaoaoaoo••

Chapter 1

What is UML?

13

Table1.1 Type of relationship

UMLsyntax source target

Dependency

-----------;>

9.5

The description of a set of links between objects

9.4

The target element is a part of the source element

18.4

A strong (more constrained) form of aggregation

18.5

The source element contains the target element

11.4

[>

The source element is a specialization of the more general target element and may be substituted for it

10.2

-----------[>

The source element guarantees to carry out the contract specified by the target element

12.3

Aggregation

Composition

•

Containment

E9

Realization

Section

The source element depends on the target element and may be affected by changes to it

Association

Generalization

Brief semantics

There are thirteen different types of UML diagrams, and these are listed in Figure 1.6. In the figure, each box represents a type of diagram. When the text in the box is in italics, it represents an abstract category of diagram types. So, for example, there are six different types of StructureDiagram. Normal text indicates a concrete diagram that you could actually create. Shaded boxes indicate concrete diagram types that are new in UML 2. We can usefully divide this set of diagrams into those that model the static structure of the system (the static model) and those that model the dynamic structure of the system (the dynamic model). The static model captures the things and the structural relationships ·between things; the dynamic model captures how things interact to generate the required behavior of the software system. We'll look at both the static and dynamic models from Part 2 onwards. There is no specific order in which UML diagrams are created, although you typically start with a use case diagram to define the system scope. In fact, you often work on several diagrams in parallel, refining each one as you

#

\li O ll}Q O O # 'II

Q t:I Q r;, o t:> o

1

o c

Q Q

t:i

a" o

Q

o to a o" o o

Q"'

I.'


o

Q II)

o,:,

t> 1'1-

o o u o

Q

o o

Q"

o o u

11>

Chapter

Vision and requirements

o

Q

2

r:i

o

~~

o" o

1.1> r,

n

r, l.'>

a o

ts () i:, Q I.'! Q Ill Q,:, () ,:, Q O Q Q O Q Q f;'l OU () U tJ

2

e

ti C/1 () t'I Q t'I Q It f;> I); Q O Q (; Q- Q a

Part 1

o a o a o oo no o

Q

coo o o o coo

o a o

i,

o

01:-

a

o no o

Q

o

9

o

Q

o a o

I.'>

o

~~

o

00 Q

o.:.

t> 01:- ~Q

o oo oof;I o

Introducing UML and UP

UP is a mature, open SEP from the authors of UML.

Whereas RUP is a Rational process product, UP is an open SEP from the authors of UML. Not surprisingly, UP and RUP are closely related. We have chosen to use UP rather than RUP in this book as it is an open SEP, accessible to all, and is not tied to any specific product or vendor.

UP and the Rational Unified Process RUP is a commercial product that extends UP.

UP and RUP are much more similar than they are different.

The Rational Unified Process (RUP) is a commercial version of UP from IBM, who took over Rational Corporation in 2003. It supplies all of the standards, tools, and other necessities that are not included in UP and that you would otherwise have to provide for yourself. It also comes with a rich, web-based envi~onment that includes complete process documentation and "tool mentors" for each of the tools. Back in 1999 RUP was pretty much a straight implementation of UP. However, RUP has moved on a lot since then and now extends UP in many important ways. Nowadays, we should view UP as the open, general case and RUP as a specific commercial subclass that both extends and overrides UP features. But RUP and UP still remain much more similar than different. The main differences are those of completeness and detail rather than semantic or ideological differences. The basic workflows of 00 analysis and design are sufficiently similar that a description from the UP perspective will be just as useful for RUP users. By choosing to use UP in this book, we make the text suitable for the majority of 00 analysts and designers who are not using RUP, and also for the significant and growing minority who are. Both UP and RUP model the who, when, and what of the software development process, but they do so slightly differently. The latest version of RUP has some terminological and syntactic differences to UP, although semantics of the process elements remain essentially the same. Figure 2.4 shows how the RUP process icons map to the UP icons we use in this book. Notice that there is a «trace» relationship between the RUP icon and the original UP icon. In UML a «trace» relationship is a special type of dependency between model elements that indicates that the element at the beginning of the «trace» relationship is a historical development of the element pointed to by the arrow. This describes the relationship between UP and RUP model elements perfectly. To model the "who" of the SEP, UP introduces the concept of the worker. This describes a role played by an individual or team within the project. Each worker may be realized by many individuals or teams, and each individual or team may perform as many different workers. In RUP workers are actually called "roles", but the semantics remain the same.

Q!/>tJC'>(?l,',QQQ-QQQUC-QQQQUQt;tQQQ,:0(tQQQt,J:,t,1:,(?!/>Q1bOQQ!/>QU.OQQQQOt\'QQ

Chapter 2

UP

0

RUP

«trace»

0

oo no

oq, o Q o

Q

o t1

Q ""

"o o " o 1> o

Q

n,,, a o 0 o o o oo o a o

UseCase.sss

AdditemToBasket

2

l. None

l. Customer

l. None

l. The Customer adds an item to their shopping basket.

l. The Customer is browsing products.

l. The Customer selects a product 2. The Customer selects "add item" . 3. The system adds the i tern to the Customer's shopping basket. 4. : inc: Di sp 1ayBasket

l. A product has been added to the Customer's basket. 2. The contents of the basket are displayed.

l. None

l. None

Figure A2.3

Appendix

2

XML and use cases

565

.=..lgJ29

1. The Customer selects □ pre.duel

2. The Customer selects 'add item". 3. The system adds the ii.em to lh e C usl.ooler's shopping basket.

4.

:inc:DisplatB □ skel

1. A product has been added to the Customer's bask'8l. 2. The cont en ls of the basket are displsy€d.

1. None

8.26 X 11.69 in

Figure A2.4

0

llil ~,;, \;)

o

\:I f'1,::.

i,"

566

Q

~ Q;:,

o~o,;,-,,,"

Part 6

AcceptPai mentl3YCard 1

ti

o

ti#

a o

1:1

o

t'I

Q

o o

e,,;,

o o

01:1

\'loo

1;1

o

1;1

o ao a o a o

III f; tit

o -'-' o o1to o o o o o

0001:1 01:1

o a" ao ~., a o

Q

o a" ,no o o..., o

Oil>

o a••.., o • u o a a•

t>

o o

QI•

eo o o • o• o o

Supplementary material

i

AcceptPaymentByCard,BadCarcf Acce,pt~~y111e,ntByCard,CreditCardPay111e,: ~~ce,ptP,aymentByCard,CreditLimitExceed[ Add!tem ToBasket AddProductToCatalog BrowseProd-uc-ts-~--CancelOpenOrder checkout CloseOrder CreateNewCustomer,____ _ . ereaferiiewuseroeietecustomer DeleteProductFromCatalog . beleteUser

~1il

1. The Customer is logged on to the s_ystem. 2. Some inventor_y items have been provisionall_y reserved for the Customer.

~m~ 1. The use case begins when the Customer accepts the order.

n-----------------------12. The s_ystem retrieves the Customer's credit card details.

CardProcessingCompany 3. The s_ystem sends a message to the CardProcessingCompan}• that includes merchant identifier, merchant authentication, name on , ,_c_us_to_m_-e_r_·····_···_--·-_----_-···_·-·-_··_····-_···_--_.......................................... card, number of card, expir_y date of card, amount of transaction. Dispatcher 4. The CardProcessingCompany authorises the transaction. InventorySystem . .. ·-·· 5. The s_ystem notifies the Cu,,tomer that the card transaction has been accepted. sh~pkeep_er_____ 6. The s_ystem gives the C1.1stomer an order reference number for tracking the order. SystemAdministrator 7. The s_ystem tells the lnventor.11System to reserve the required items. User··········· 8. The s_ystem sends the order to the Dispatcher. ·· 9. The s_ystem changes the order's state to pending. i 10. The s_ystem displa_ys an order confirmation that the Customer ma_y print out. !~ 1. The order status has been set to pending. 2. The Customer's credit card has been debited b_y the appropriate amount. 3. Some inventor_y items have been reserved to cover the order. 4. The order has been sent to the Dispatcher.

figureA2.5

Nt.ci,

o o o

Bibliography [Alexander 1], Writing Better Requirements, Ian F. Alexander, Richard Stevens, Ian Alexander, Addison-Wesley, 2002, ISBN 0321131630 [Ambler 1], The Unified Process Inception Phase, Scott W. Ambler, Larry L. Constantine, CMP Books, 2000, ISBN 1929629109 [Ambler 2], The Unified Process Elaboration Phase, Scott W. Ambler, Larry L. Constantine, Roger Smith, CMP Books, 2000, ISBN 1929629052 [Ambler 3], The Unified Process Construction Phase, Scott W. Ambler, Larry L. Constantine, CMP Books, 2000, ISBN 192962901X [Arlow 1], Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML, Jim Arlow, Ila Neustadt, Addison-Wesley, 2004, ISBN 032111230X [Booch 1], Object Solutions, Grady Booch, Addison-Wesley, 1995, ISBN 0805305947 [Booch 2], The Unified Modeling Language User Guide, Grady Booch, Ivar Jacobson, James Rumbaugh, Addison-Wesley, 1998, ISBN 0201571684 [Chomsky 1], Syntactic Structures, Noam Chomsky, Peter Lang Publishing, 1975, ISBN 3110154129 [Frankel 1], Model Driven Architecture: Applying MDA to Enterprise Computing, David S. Frankel, John Wiley & Sons, 2003, ISBN 0471319201 [Gamma 1], Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison-Wesley, 1995, ISBN 0201633612 [Harel 1], Modeling Reactive Systems with Statecharts: The Statemate Approach, David Harel, Michal Politi, McGraw Hill, 1998, ISBN 0070262055 Uacobson l], Unified Software Development Process, Ivar Jacobson, Grady Booch, James Rumbaugh, Addison-Wesley, 1999, ISBN 0201571692 [Kay 1], XSLT Programmer's Reference, 2nd Edition, Michael Kay, Wrox Press Inc., 2001, ISBN 1861005067 [Kleppe 1], MDA Explained: The Model Driven Architecture -Practice and Promise, Anneke Kleppe, Jos Warmer, Wim Bast, Addison-Wesley, 2001, ISBN 032119442X

• • o a o • o • o • • • » • o • o • • • • o • • o • • n • o" •

568

Part 6

in

o·fl o • • • o o • • o • o o o •

111 •

•

•

•

o• • • o • o • • • o • • • • • o o o

41' •

•

o • • • o o • o •,,

111

o o • • • • o • o • o • o o • • o o"" n a o o o a o • o • o • o o

ll:I' •

o

Supplementary material

[Kroll 1], The Rational Unified Process Made Easy: A Practitioner's Guide to Rational Unified Process, Per Kroll, Philippe Kruchten, Grady Booch, AddisonWesley, 2003, ISBN 0321166094 [Kruchten l], The Rational Unified Process, An Introduction, Philippe Kruchten, Addison-Wesley, 2000, ISBN 0201707101 [Kruchten 2], "The 4+1 View of Architecture", Philippe Kruchten, IEEE Software, 12(6) Nov. 1995, pp. 45-50 [Leffingwell 1], Managing Software Requirements: A Use Case Approach, 2nd Edition, Dean Leffingwell, Don Widrig, Addison-Wesley, 2003, ISBN 032112247X [Meyer 1], Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1997, ISBN 0136291554 [Mellor 1], Agile MDA, Stephen J Mellor, MDA Journal, June 2004, www.bptrends.com

[OCLl],.Unified Modeling Language: OCL, version 2.0, www.omg.org [Pitts 1], XML Black Book, 2nd Edition, Natalie Pitts, Coriolis Group, 2000, ISBN 1576107833 [Rumbaugh 1], The Unified Modeling Language Reference Manual, 2nd Edition, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison-Wesley, 2004, ISBN 0321245628 [Standish 1], The CHAOS Report (1994), The Standish Group, www.standishgroup.com/sample_research/chaos_l 994_1. php [UML2S], Unified Modeling Language: Superstructure, version 2.0, www.omg.org [Warmer 1], The Object Constraint Language: Getting Your Models Ready for MDA, Jos Warmer, Anneke Kleppe, Addison-Wesley, 2003, ISBN 0321179366

Index Abbreviations in class names, 13 7 abs operation, 508 Abstract classes, 210, 391 Abstract operations, 210-211 Abstraction in class inheritance, 210-211 dependencies in, 198-200 levels of, 211 Accept event actions in activity diagrams, 314-317 time, 296-297 Access for collections, 515 scope for, 147-148 «access» dependency, 200, 229-230 Acronyms in class names, 137 Action nodes, 293-294 accept time event, 296-297 in activity diagrams, 286-287 call, 294-296, 537 with tokens, 288-289 Actions in states, 444-445 for transitions, 446 Activations in lifelines, 246 in sequence diagrams, 253 Active classes in concurrency, 420-422 Activities in activity diagrams. See Activity diagrams in states, 443-445 in UP and RUP, 33 Activity diagrams, 283-285 action nodes in accept time event, 296-297 call, 294-296

execution of, 293-294 with tokens, 288-289 activities in, 286-288 partitions, 290-293 semantics, 288-289 advanced, 309-310 central buffer nodes in, 322-323 connectors in, 311 control nodes in, 286, 297-301 decision and merge, 298-299 fork and join, 300-301 initial and final, 298 events in, 314-317 exception handling in, 312-313 expansion nodes in, 313-314 features of, 285 interaction overview, form of, 323-325 interruptible activity regions in, 311-312 multicast and multireceive in, 320-321 object flows in, 286, 318-320 object nodes in, 286, 301-305 activity parameters in, 304-305 as buffers, 302-303 in representation of, 305-306 state representation in, 303 OCL in, 537 parameter sets in, 321-322 signals in, 314-317 streaming in, 317-318 summary, 307-308, 325-327 in unified process, 285-286 Activity parameters in object nodes, 304-305 Activity partitions, 290-293 Actor classifier, 19

570

Index

Actors in use case modeling, 69-70 generalization of, 97-99 identifying, 72-73 in specification, 80 primary, 80 secondary, 80 time as, 73 Adornments, 17-18, 136 after keyword, 453 Aggregation vs. composition, 134, 363-364 vs. inheritance, 351-352 semantics, 364-367 Algorithms, plug-in, 405 alllnstances operation, 505-506 alt operator, 257 branching with, 258-261 with continuations, 280-281 Alternative flows, 85-88 finding, 89 number of, 89-90 Analysis classes, 155-158 in analysis packages, 224 diagrams for, 243 features of, 158-159, 160-161 finding archetype patterns for, 170-171 by CRC analysis, 165-167 by noun/verb analysis, 163-165 by RUP stereotypes, 167-169 first-cut analysis models, 171 parts of, 15 9-160 rules of thumb, 162-163 summary, 172-173 Analysis models and design models, 334 rules of thumb, 122-123 in use case realization-design, 416 Analysis packages. See Packages Analysis relationships. See Relationships

Analysis workflow, 119 activity diagrams for, 286 artifacts metamodel, 121 detail of, 122 features of, 120 models for, 122-123 summary, 124 and operator, 507 AndroMDA tool, 9 any operator, 519 append operator, 518 Archetype patterns, 170-171 Architectural analysis, 231-232 Architecturally significant components, 482 Architecture, 23-24 in design workflow, 338-339 in implementation workflow, 482-483 and layering pattern, 406-407 ArcStyler tool, 9 Arrow operator(->) for collection operations, 513 «artifact» stereotype, 486-488 Artifacts, 33 in analysis workflow, 121 in deployment, 486-490 in design workflow, 333-335 in implementation workflow, 477-478 manifesting components, 400, 486 trace relationships, 335 asBag operator, 514 asOrderedSet operator, 514 asSequence operator, 514 assert operator, 258 asSet operator, 514 Associations in aggregation, 366 attributes and, 190-191 bidirectional, 376-377 classes for, 191-193, 377-378 of components, 400

Index

features of, 180-181 inherited, 542-544 for interfaces, 390 multiplicity in, 182-187 navigability of, 187-189 in OCL navigation, 523-526, 540-543 qualified features of, 193-194 navigation through, 541-542 refining, 363 reflexive, 185 syntax of, 181-182 types of many-to-many, 375-376 many-to-one, 3 70-3 71 one-to-many, 3 71 one-to-one, 369-370 Asterisks (*) in communication diagrams, 265-266 Asymmetry in aggregation, 365-366 of composition, 367 Asynchronous communication for submachines, 467 in use case realization, 246-24 7 at operator, 516 Atomic behavior in concurrency, 424 in design classes, 348 attach operation, 545 Attributes analysis class, 15 9 associations and, 190-191 component, 400 and composition, 368 constraints on, 256 design class, 344-346 for interfaces, 390 object, 132

of requirements, 59-60 scope of, 147-148 and state, 443 syntax, 138-142 visibility, 138-139 Automatic transitions, 446 Axioms, 34-35 Backplanes, semantic, 16 Bags, 374, 512 Base use cases, 103 Baselines, 3 7 Behavioral state machines, 440 Behaviors call action nodes and, 294-296 of object nodes, 303 of objects, 127-128 reusing, 465 Benefit attribute, 60 Bidirectional associations, 179, 376-377 Bidirectional links, 179 Bidirectional relationships, 234 «bind» stereotype, 355-356 Binding, 355-356 Black boxes components as, 399-400 subsystems as, 426 body: expression, 503, 530-531 Booch, Grady, 7, 31 Booch method, 5-6 Boolean type features of, 507-508 iterator operations, 519-520 semantics of, 140 Boundaries packages defining, 224 in use case modeling, 71 «boundary» RUP stereotype, 167-168 Brainstorming in CRC analysis, 166 for requirements, 64

571

• • • • • • o • • • • • • • • • o • • • • • • • o o • • •f;'.1- • • • • • • o •

572

o •a••••

o • • • • • •o • • o • • • • • • • • • • • • • • o • • • oo c • • o • • • o • •

o• • •

11

••a••"•••••• o o

•••'Ct -o •

-o • • • • • • o • • • •

Index

Branching in communication diagrams, 267-268 in interaction overview diagrams, 324 in main flow, 82-85 with opt and alt, 258-261 transitions, 448 break operator iteration with, 261-263 semantics of, 25 7 Brief descriptions, use case, 80 Buffers, object nodes as, 302-303, 322-323 «buildComponent» stereotype, 402 Building blocks, UML, 11-15 Business models activity diagrams for, 285, 286 in use case modeling, 70 C++ language abstract classes in, 391 constructors in, 148, 247-248 destructors in, 150, 247-248 inheritance in, 351 interface names in, 392 link implementation in, 177 overriding operations in, 209 primitive types in, 368 template support for, 356 C#language constructors in, 148, 247-248 destructors in, 150, 247-248 inheritance in, 351, 352 template support for, 356 Call action nodes, 294-296, 536 «call» dependency, 19 7 Call events, 449-450 CBD (component-based development), 399 «centralBuffer» nodes, 322-323 «centralBuffer» stereotype, 303 Change events, 452-453 Child packages, 231 Choice pseudo-states, 448

CIM (computer-independent model), 8 Class classifier, 19 Class generalization, 207 Class scope, 147 Class style notation for interfaces, 391-392 Classes, 125, 132-134 abstract, 210, 391 activity partitions for, 291 analysis. See Analysis classes association, 191-193, 377-378 attributes for, 138-142 dependencies between, 19 5-196 design. See Design classes designing, 342-344 finding, 163-171 inheritance in, 208-211, 350-354 instantiation of, 135 moving between packages, 233 names of, 13 7 names in object names, 132 notation for. See Notation and objects, 134-135 operations for, 142-146 partitioning, 219 as powertypes, 218-220 relationships with. See Relationships state machines for modeling, 440-441 stereotype syn tax for, 146 structured, 3 79-382 summary, 151-153 as templates, 132 templates for, 354-356 Classification, 133-134 Classifiers and instances, 18 structured, 3 78-3 79 in use case realizations, 244 Cohesion for analysis packages, 233 in design classes, 349

Index

Collaboration messages for, 130 in structured classifiers, 379 Collaborators in CRC analysis, 165-167 collect operator for collections, 525 for iterators, 519 Collections, 141 features of, 511-513 loops for, 263 maps, 374 operations for, 371-372, 513 access, 515 comparison, 514 conversion, 514 query, 514-515 selection, 516-518 working with, 371-374 collectNested operator for collections, 525 for iterators, 519 Colons(:) in names action, 292 object, 132 package, 226 powertype, 219 Color in UML models, 20 Combined fragments, 256-25 7 branching in, 258-261 iterations in, 261-263 Commas (,) for actions, 292 Comments, 504-505 Common mechanisms adornments, 17-18 divisions, 18-19 extensibility, 19-22 specifications, 15-17 Communication. See Messages Communication diagrams, 264-265 branching in, 267-268 concurrency in, 425-426 iteration in, 265-266

Comparison operations for collections, 514 in OCL, 506 {complete} constraint, 217 Complete models, 17 Completeness in design classes, 34 7-348 Complex deviations in specifications, 81 Complex nesting of packages, 227 Complexity with interfaces, 408 Component-based development (CBD), 399 Component-based modeling, 170-171 Component classifier, 19 Components, 389-390 activity partitions for, 291 architecturally significant, 482 from artifacts, 486 features of, 399-402 in interfaces, 399 stereotypes, 402 subsystems, 403 summary, 410-411 Composite icons, 459 Composite states features of, 458-460 orthogonal, 462-465 simple, 460-462 Composite structured diagrams, 381 Composition vs. aggregation, 134, 363-364 attributes and, 368 semantics, 367-368 with structured classes, 378-382 Computer-independent model (CIM), 8 concat operator, 509 Conceptual entities, classes for, 170 Concrete operations vs. abstract, 210 overriding, 214 Concurrency, 419 active classes in, 420-422 in communication diagrams, 425-426 fork and join control nodes for, 299-301

573

574

Index

Concurrency, continued in interaction overview diagrams, 324 in sequence diagrams, 422-425 Conditional extensions, 109 Conditions in communication diagrams, 267 Configuration management, packages for, 224 Connecting transitions for state machine, 447 Connectors and links, 177-178 in activity diagrams, 311 in communication diagrams, 265 of components, 400-401 in object diagrams, 178-179 paths for, 179-180 in structured classifiers, 378-379, 381 consider operator, 258 Consistent models, 17 Constraint languages, 499 Constraints, 20 in association classes, 3 78 on expansion nodes, 313-314 generalization, 217 in interfaces, 390 multiplicity, 182-187 in OCL, 503 in sequence diagrams, 254-256 in structured classifiers, 379-380 in timing diagrams, 42 7 Construction phase, 37-39, 41-43, 476 Constructor operations, 135, 148-150, 247-248 Context classifiers, 244 Context-free questions in requirements interviews, 63 Context in OCL expression, 501-502 package, 500-501 Contextual instances, navigation within, 522-523 Continuations in use case realizations, 279-281 Continuous streaming in activity diagrams, 317-318

Contracts abstract classes as, 210 interfaces as, 391 in polymorphism, 212 Control flows in activity diagrams, 286 Control nodes in activity diagrams, 286-287, 297-301 decision and merge, 298-299 fork and join, 299-301 initial and final, 298 «control» RUP stereotype, 167, 168-169 Conversion operations for collections, 514 in OCL, 506 Could have requirements, 59 count operator, 515 Coupling in analysis classes, 161 in analysis models, 123 in analysis packages, 233 in architectural analysis, 232 in design classes, 350 inheritance in, 351 CRC analysis, finding classes by, 165-167 «create» stereotype, 248 Creation messages in use case realizations, 247-248 critical operator, 25 7, 422-423 Curved paths for links, 180 Cyclic package dependencies, 234-235 Data-hiding, 127-130 Decision control nodes, 298-299 «decisionlnput» stereotype, 298 Declarative languages, 498 Decomposition, functional, 112-113 Decoupling components, 400-401 layers, 406 Deep history in state machines, 469-470 Deep inheritance trees, 162

Index

def: expression, 503, 531-533 Default values in parameters, 145 Define operation, 503 Deleting filters for, 61-62 packages, 233 Dependencies, 195-196 in abstraction, 198-200 «derive», 199 «refine», 199 «substitute», 198 «trace», 198, 229 in aggregation, 365 in bidirectional associations, 376-377 of components, 400-401 in composition, 367 interfaces for, 408 between layers, 406 of packages, 228-230, 234-235 permission, 200 «access», 200, 229-230 «import», 200, 229 «permit», 200 usage, 196-198 «call», 197 «instantiate», 134-135, 198 «parameter», 19 7-198 «send», 198 «use», 196-197, 228-229 Deployment, 481 architectural implementation, 482-483 artifacts in, 486-489 diagrams for, 483-484 example, 491 nodes in, 484-485 summary, 491-492 in use case realization design, 416 views, 23 «deployment spec» stereotype, 488 derive: expression, 503, 533-534 «derive» dependency, 199 Derived value operator, 503

Descriptions in specifications, 80 Descriptor form of deployment diagrams, 483 Design classes, 341-342 anatomy of, 345-34 7 features of, 344-345 inheritance in, 350-354 nested, 357 relationships between, 363 summary, 358-360 templates for, 354-356 well-formed, 347-349 Design workflow, 331 architectural design in, 338-339 artifacts metamodel, 333-335 for classes, 342-344 detail of, 33 7-338 features of, 332-333 multiple models in, 336-33 7 relationships in, 335 summary, 339-340 Designing to contracts, 391 with interfaces, 404-407 subsystems, 389 «destroy» stereotype, 248 Destruction messages, 247-248 Destructor operation, 148-150, 247-248 detach operation, 545 Detail in analysis workflow, 122 in design workflow, 33 7-338 in implementation workflow, 478-479 in requirements workflow, 53-54 in use cases, 77-78 Deviations in specifications, 81 Device boundary classes, 167-168 «device» stereotype, 484 Diagrams, 12-15 activity. See Activity diagrams analysis class, 243-244 class, 136-137

575

t:>o

,t1

oo

576

Ii';,*

e,

o,:, 1,11oa111:, #a# 00 0 -o 0 o o

t1

o

ro1

0 o o u ooh,, a au a o 'ill o 'ill q, c r.> a"' o e, o -1> oo w,;i o

at)

•o

O O O O Q OQ Q Q

Q OQ (1 Q O Q tJ t'IO til Q ¢1 0

Ill ,ti-Qt)

ti Q ti 0 0 0 0

uo

Q

00 Q

Q

OU Q t'I Q la Q Ill Q t'I Q Q Q GO QO t.l Q OOQ Q QQ O

~

tJ Q

(I ¢1 Qt'I Q

Q O

co

Q O

O ♦ O

O Q(I: 0

Q OQQ l,li O Q tJ ¢1 Q Ci Q t'I Q

Index

isUnique operator, 519 iterate operator, 521-522 Iteration in communication diagrams, 265-266 in interaction overview diagrams, 324 with loop and break, 261-263 operations for, 518-522 in unified process, 35-37 Iterative expansion nodes, 314 iUML tool, 9 J2EE server, 490-491 Jacobson, Ivar, 29-31 JAR (Java ARchive) files, 400 «JAR» stereotype, 489 Java language collections in, 3 72 constructors in, 148, 247-248 destructors in, 150, 247-248 inheritance in, 351, 352 interfaces in, 391 links implementation in, 177 nested classes in, 35 7 overriding in, 209 primitive types in, 368 profiles for, 489 standard libraries in, 393, 407 template support for, 356 «JavaClassFile» stereotype, 489 «JavaSourceFile» stereotype, 489 ]Mechanic for Java tool, 348-349 Join control nodes, 300-301 Junction pseudo-states, 447 Keys for maps, 374 Keywords in expressions, 504 in OCL, 504-505 Languages for analysis models, 123 constraint, 499

declarative, 498 filters in, 61-62 Last-in, first-out (LIFO) buffers, 303 last operation, 516 Layers in architecture arranging, 231-232 patterns in, 406-407 Less than signs ( O lit O O ,GOO Ill' 4' 0 4 9 #

592

Q.

4t #

Q 0"'

'II•

0 Ill • • 0 0 ti> QI, 0 0 Q # . # I l l ' 0 Q G Q II~ II O O O

(II

Q #

:r, #WOO O O . 0 {II>#

Q O Q O O O Q # I ) # 0 #\'IO 1:11 0

0 # 0 9 0 0 0 0. Q O Q O Q -

Cl O O O O ti> 0 ti O O Q O O O O O O fll O 9 0 0 0 1.1 ff~

Index

Visual Basic language interface names in, 392 template support for, 356 Want to have requirements, 59 Well-formed design classes, 347-349 Well-formed requirements, 56-57 when keyword, 453 While loops in main flow, 85 in sequence diagrams, 263

Windows. See Diagrams Workers, 32-33 Workflow analysis. See Analysis workflow design. See Design and design workflow implementation. See Implementation iteration, 36-3 7 requirements. See Requirements Workshops for requirements, 64 WxPython library, 433-434 xor operator, 507