The Unified Process Explained [1 ed.] 0201742047, 9780201742046

Citation preview

> _ KENDALL SCOTT

Vrom the Library of Garth Casdorph 404-995-0844 PO Box 13199, ATL, GA

—————

The Unified Process Explained

The Unified Process Explained Kendall Scott

vv Addison-Wesley 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 with initial capital letters or in all

capitals. The author 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 special sales. For more information, please contact: Pearson Education Corporate Sales Division 201 W. 103rd Street Indianapolis, IN 46290 (800) 428-5331 [email protected] Visit us on the Web at www.aw.com/cseng/ Library of Congress Cataloging-in-Publication Data Scott, Kendall

The unified process explained / Kendall Scott. eeu: Includes bibliographical references and index. ISBN 0-201-74204-7 (alk. paper) 1. Computer software—Development. 2. Software engineering. I. Title. QA76.76.D47 $35 2002 005.1—dc21 2001053366 Copyright © 2002 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. ISBN 0-201-74204-7 Text printed on recycled paper 123456789 10-CRS—0504030201 First printing, November 2001

Contents

OSU CTT 0 1ST Siege an

nO ote in REP AAC

IARUEN oRRORRRIO O14 © 12 conBP EReEN ae XV

DN Hae eee a Pelee attics tasted dies a veade tt ates dibtiauctccpanen BURT ARIE Xvil NIST ATLETISSS 3.000)EC 5 in ts nS eA ee eos Ea eRe XV1i Orsanizariom-Old Mis OOK. Metin Me rarest scdscdscveal desea lela deccouseaotees XVill JANGSTORIES 120aVS10 aa l e Oae e ORRAST M neSe o x ORNATE

CON CTNACWS fetch

hat

peg oes Reccunietel haynes sAnauuc ary Ge? 2a ne l

BOUTON csc een tees teria aol, Hain hes Rel aay, 2 aes 1 Tl SLODY Ate ceetet enna tbs ated ate iA SapeeeN apes 55. Gagsaccee 2 Bice Case ype iit meet tiie: 8d aexcgeys se Re ieee isi eae 3 A ERE CRUNLG Be OTN EI Oe arcades sn iaee nick han mm er etednnac tot + Widerstanding theiBig Pictures...u.cscettee: Ste wise ccm 5 Organizing the Development Bitort iit. Savas evs cacs. iad 6 Factlitating the Possibilities for: Reuse:..:..:. tetas cactccne 6 RV OUVE GMO NSICIik.< trot! causadcadetarcti cease mange Da ian oceaenadeces 6 Ganding fed sesC ase Sia ic.ic..2. von cey wate suse one eet hen eaaasecconsee 7 iterative 2nd LACreMental 5.1.15

ierae 1) ene. Re

a

ay4:

ab

vt

ses

iP

=

inf

if

iea

hr ike

a

ne

ef

aC

ie.»

a

aes

’

oe ip sores

:

hi fen

ta)

ee

Mn,

RAD

Per

.

oe ee jiPorer ers ;

n

>»

i

ie

=

oa

dh ES

a

Sf

all

Seat

om

Poe

our

eT

ee a: es Peres

beget

gry

at

a

Mitten

-

at

‘f LS)

Ute

in’ 7

~e

tea, sal)

VE PE icy

py

a:

ee

(nee

ty

a

ee

i,

ek

re

*

gy wo =} Li?

—

;

ore is

=

bee

vy

eis ge|

i

“

wast

ie

ie

ny

raf

ot ;

ee

wave

ms .

an Si

Ae

a

Chapter 5

The Implementation Workflow Introduction The fundamental goal of the Implementation workflow is for the development team to build a working version of the system that it can deliver to beta customers for evaluation. The primary result of this workflow is the implementation model, which contains the source code and executables that together form the implemented system. The team also expands the deployment model, which gets started during the Design phase (see “Deployment Model” in Chapter 4), to reflect the physical distribution of the various pieces of the software. The implementation model represents the real-world realization of the contents of the design model. Each element of that model becomes part of a component, which is a physical and replaceable part of the system that conforms to, and realizes, a set of interfaces. Similarly, the full deployment model reflects the real-world realization of the architecture that has been evolving as work has proceeded on the various models.

CHAPTER 5’ W

THE IMPLEMENTATION WORKFLOW

Artifacts The following subsections describe the various artifacts that may be generated within the Implementation workflow.

Component A component is a physical and replaceable part of a system that conforms to, and realizes, a set of interfaces. (See “Interface” in Chapter 4 for an introduction to interfaces.) There are some important differences between components and classes: ¢

A component is a physical thing that lives on some piece of hardware; a class is a conceptual thing that is physically realized within a component.

¢

Something talking to a component can generally access the operations it encompasses only through its interfaces, and that thing cannot access a component’s attributes directly at all. A class can expose its attributes to subclasses or to everyone.

The UML assigns components to one of three categories.

¢

A deployment component is an executable part of a system. The UML defines two stereotypes for use on deployment components: «executable», which usually indicates a binary (EXE) file, and «library», which indicates a static or dynamic object library such as a DLL.

¢

A work product component is a component that’s part of the system but isn’t executable. There are three UML-defined stereotypes for work product components: «table» (for a database table), «file» (for a file that contains source code), and «document». Within the Unified Process, «file» components package design classes (see “Design Class” in Chapter 4) and their interfaces.

¢

An execution component is created as a result of an executing system. One kind of execution component is a COM+ object, which a system creates as an instantiation of a DLL at runtime.

A component diagram shows a collection of related components. You might think of a component diagram as a type of class diagram that shows components instead of classes. This kind of diagram can show the various kinds of relationships that components can have, which are the same as the ones classes

ARTIFACTS

can have. Generally, though, the focus will be on the interfaces that components expose and use, and the dependencies that exist among the various components. (Dependency arrows on a component diagram show how each component uses interfaces exposed by other components.) Figure 5-1 shows a component diagram for our bookstore that uses the standard UML notation for components. =

UML Pi

See “Component Diagrams” in Chapter 10 of UML Explained for more about component diagrams.

Interface

The two notations for the relationships between components and interfaces are the same as those for classes (see “Interface” in Chapter 4) and interfaces.

«page»

search. html

«page»

a

front.html

«executable»

search.exe

table.

book.tbl

Figure 5-1: Component Diagram

«table»

author.tbl

CHAPTER 5:

¥W THE IMPLEMENTATION

C }-—S

WORKFLOW

Accounting

General Ledger «interface» General Ledger

Shopping Cart Page Customer

Delete Item

=

zee Display

Update Quantity and Cost

Shopping Cart

Figure 8-3: Robustness Diagram for Edit Contents of Shopping Cart

CHAPTER 8 W

THE ELABORATION PHASE

Analyze a Class The team expands the definitions of the analysis classes associated with all of the use case realizations—analysis being built within the given iteration. These become part of the analysis model. The architect adds the architecturally significant analysis classes to the architecture description. The team building The Internet Bookstore defined analysis classes in parallel with their robustness analysis efforts. Figure 8-4 shows some of the analysis classes they had defined after Iteration 4.

|

Purchase Order ID authorizedBy dueDate

Category Stock

Book

Item title

ee

ee

ISBN key Words

[4 GL Account

Shopping Cart name number debitOrCredit

Order ID totalAmount datePlaced

Customer

Account emailAddress

ID password

{encrypted}

Figure 8-4: Analysis-Level Class Diagram After Iteration 4

DESIGN ACTIVITIES

Note the {encrypted} tagged value assigned to the password attribute within the Account class. This is indicative of the kind of detail that the team should feel free to start adding to attributes during analysis.

Analyze a Package The component engineers add the use case realizations—analysis and analysis classes associated with each current iteration to the analysis packages outlined by the architect. They may also break packages up, merge packages, or both, while ensuring that the integrity of the packages remains intact. The team building The Internet Bookstore decided, during Iteration 3, that package Order Processing and Inventory needed to be broken into two packages. Figure 8-5 shows the effects of this change. The figure shows that the Inventory package received the interfaces that were formerly part of the combined Order Processing/Inventory package, and that now the Order Processing package has dependencies on those interfaces.

Design Activities The following subsections describe the Design workflow activities that are of interest during the Elaboration phase.

Perform Architectural Design The architect does significant expansion of the deployment model and the design model from the versions done during the Inception phase. (See “Perform Architectural Design” in Chapter 4 for details.)

Inventory

Order Processing

Fulfill Order

|

|

Ship Order

. Retrieval

purchase Order iy 0) ae ince ee nar


collaboration A collection of classes and other elements that work together to provide some behavior. collaboration diagram A UML diagram that focuses on the organization of the objects that participate in a given set of messages. component A physical and replaceable part of a system that conforms to, and realizes, a set of interfaces.

component diagram A UML diagram that shows a collection of related components. component engineer A worker who, within various workflows, is responsible for the definitions of the various aspects of one or more analysis classes and the contents of one or more analysis packages; for the definitions of the various aspects of one or more design classes and the contents of one or more design subsystems; for the source code of one or more «file» components and the contents of one or more implementation subsystems; and for building one or more test components.

conformance-directed testing A kind of testing, the goals of which involve executing tests designed to establish conformance to customer requirements. Construction phase The phase during which the development team tries to build a system capable of operating successfully in beta customer environments. control flow graph A graph that shows which chunks of code can be followed by which other chunks. control object An object represented in the analysis model that embodies application logic. cycle A period of time within a development project that ends with the release of a version of the system to customers.

defect A problem with the system that developers need to track and resolve. deployment component A component that represents an executable part of a system.

deployment diagram A UML diagram that shows a collection of nodes and the dependencies and associations among those nodes. deployment model A model that defines the physical organization of the system in terms of computational nodes.

GLOSSARY

Design a Class An activity that involves expanding the definition of a design class that participates in one or more use case realizations—design. Design a Subsystem An activity that involves designing a design subsystem that was defined during architectural design.

Design a Use Case An activity that involves building a use case realization— design for a use case. design class A class specified to the level of detail appropriate to the Design workflow, which generally means that a design class contains a full set of attributes and operations and a richer set of details about things like

visibility. design-level class diagram A class diagram whose primary contents are design classes.

design model A model that contains use case realizations—design, as well as associated design classes, that realize the functionality specified by the use cases contained within the use case model, the analysis model, and

the supplementary requirements. design subsystem A UML package that contains design classes, class and subsystem interfaces, and use case realizations—design.

Design Test An activity that involves designing the various levels of tests that QA staff need to perform on each build of the evolving system, as well as the procedures they’ll follow to carry out those tests. Design workflow The set of activities aimed at building the design model.

Detail a Use Case An activity that involves writing text for the basic course of action and alternate courses of action for a use case. domain model A model that captures the important real-world things and concepts that belong to the “problem space,” which defines the problem that the new system is being built to solve, in the form of classes and the various kinds of relationships among them. Elaboration phase The phase during which the development team tries to establish the ability to build the new system given the financial constraints, schedule constraints, and other kinds of constraints that the

development project faces. entity object An object represented in the analysis model that contains longlived information, such as that associated with databases.

V

GLOSSARY

Evaluate Test An activity that involves evaluating the results of integration and system testing by comparing those results to the appropriate quality goals described in the test plan. exceptional flow of events A path through a use case that represents an error condition or a path that the actor and the system take less frequently. Synonym: alternate course of action. execution component A component created as a result of an executing system.

extend A relationship within which a base use case implicitly includes the behavior of another use case at one or more specified extension points. extension point A point in a use case from which an extend relationship goes out to another use case.

fault-directed testing A kind of testing, the goals of which involve executing tests designed to have a high probability of revealing faults. feature list A document that identifies and briefly describes suggestions that can be seen as candidate requirements. Find Actors and Use Cases An activity that involves discovering the human and non-human actors that will be interacting with the system, and putting together a set of use cases that reflect the behavior those actors will be performing in conjunction with the system.

flow of events A path through a use case. framework An architectural pattern that provides a template one can use to extend applications.

glossary A collection of the various terms, specific to the system, that are in use in the other project artifacts. grammatical inspection A task that involves analyzing a document, such as a requirements document or functional specification, and circling or highlighting nouns that might become classes and verbs that might become associations between classes. Synonym: noun-verb analysis. Implement a Class An activity that involves expanding the definition of a design class and building a «file» component, or expanding an existing «file» component, to contain the class, and generating code for the

GLOSSARY

operations that the design class specifies and for the various relationships in which that class is involved. Implement a Subsystem An activity that involves building an implementation subsystem that was defined during architectural implementation.

implementation-based testing Testing that tries to verify the internal workings of the code inside a method, class, or component. Synonyms: structural testing and white-box testing. implementation model A model that contains components and implementation subsystems that realize the functionality specified by the use cases contained within the use case model, the contents of the design model, and the supplementary requirements. implementation subsystem A package that contains components and interfaces connected to components and other implementation subsystems.

Implementation workflow The set of activities aimed at building the implementation model. Implement Test An activity that involves creating test components that automate test procedures by using a test automation tool, programming the components, or both. Inception phase The phase during which the development team tries to establish the case for the viability of the proposed system. include A relationship within which one use case explicitly includes the behavior of another use case at a specified point within a basic course of action or an alternate course of action.

increment A release of the system that contains added or improved functionality over and above the previous release. An increment is the result of a completed iteration. Initial Operational Capability The major milestone associated with the Construction phase. Integrate the System An activity that involves creating or expanding the integration build plan so that it reflects the contents of the next build of the system, and integrating the various pieces of that build together before integration testing begins.

GLOSSARY

integration build plan A plan that describes the builds that will occur within an iteration.

integration tester A worker who is responsible for performing integration testing. interface A collection of operations that represent services offered by a class,

subsystem, or component.

.

iteration A mini-project that results in an increment. Life-Cycle Architecture The major milestone associated with the Elaboration phase. Life-Cycle Objectives The major milestone associated with the /nception phase. main flow of events The sunny-day scenario of a use case, the main start-tofinish path that the actor and the system will follow under normal circumstances. Synonym: basic course of action.

major milestone A point at which managers make important decisions about whether to proceed with development, and, if so, what’s required.

method flow graph A graph that shows how an object reaches various states in response to what’s going on inside of a method execution. model A simplification of reality that helps people understand the complexity inherent in software. A model represents a complete view of the system from some viewpoint.

node A piece of hardware that represents some kind of computational resource, which generally has memory and may have processing capability. noun-verb analysis A task that involves analyzing a document, such as a requirements document or functional specification, and circling or highlighting nouns that might become classes and verbs that might become associations between classes. Synonym: grammatical inspection. package A conceptual grouping of pieces of a model.

pattern A solution to a problem that’s common to a variety of contexts. Perform Architectural Analysis An activity that involves creating outlines of the analysis model and of the architecture as a whole.

GLOSSARY

Perform Architectural Design An activity that involves creating outlines of the deployment model and the design model. Perform Architectural Implementation An activity that involves identifying architecturally significant components and mapping the associated executable components onto nodes.

Perform Integration Test An activity that involves performing manual and automated integration testing. Perform System Test An activity that involves performing manual and automated system testing. Perform Unit Test An activity that involves producing executable code from a «file» component, then performing specification tests and structural tests on that code independent of other components. phase The span of time between two major milestones. The Unified Process defines four phases: the /nception phase, the Elaboration phase, the Construction phase, and the Transition phase. Plan Test An activity that involves building the test plan, which describes the QA resources that will be available for testing and the schedule of tests, as well as the test strategy, which specifies what tests will be performed within each iteration and things like required levels of code coverage. Prioritize the Use Cases An activity that involves assigning priorities, based on technical and nontechnical considerations, to the various use cases.

Product Release The major milestone associated with the Transition phase. Prototype the User Interface An activity that involves building the userinterface prototypes. realization The relationship between an interface and a class or component that provides the interface’s operations, or between a use case and the collaboration that represents the implementation of that use case. realize To provide a concrete representation of an abstract concept.

Requirements risk The risk of not building the right system—the system that the customers are paying for—by not understanding the requirements and not using associated use cases to drive development. Requirements workflow The set of activities aimed at building the use case model.

GLOSSARY

responsibility-based testing Testing that tries to verify the behavior of a given component without considering what’s inside the component. Synonyms: black-box testing and specification testing. robustness analysis A task that involves taking each sentence of a use case,

determining the boundary objects, entity objects, and control objects that it needs in order to address the behavior it specifies, and drawing those objects and their relationships. robustness diagram A special form of UML collaboration diagram that contains a use case realization—analysis.

sequence diagram A UML diagram that focuses on the time ordering of the messages that go back and forth between objects. service An atomic (indivisible) chunk of functionality that appears in one or more use cases. service package A special type of analysis package that models a service.

service subsystem A special type of design subsystem that models a service. specification testing Testing that tries to verify the behavior of a given component without considering what’s inside the component. Synonyms: black-box testing and responsibility-based testing.

state diagram See statechart diagram. statechart diagram A UML diagram that shows the different states that an object can assume during its life, the transitions that can happen between those states, and the various kinds of events that the object can respond to, as well as the nature of those responses. structural testing Testing that tries to verify the internal workings of the code inside a method, class, or component. Synonyms: implementation-based testing and white-box testing. Structure the Use Case Model An activity that involves breaking up use cases in search of simpler ones. supplementary requirement A nonfunctional requirement that deals with an issue such as performance, security, backup, or constraints imposed from

outside the system, such as those involving regulatory agencies. system analyst A worker who focuses on capturing the requirements related to the use cases.

GLOSSARY

system integrator A worker who is responsible for designing the integration build plan and performing incremental integration of builds. system tester A worker who is responsible for performing system testing. Technical risks Risks associated with the various technologies that will come into play during the project and with issues such as performance and the “-jlities” (reliability, scalability, and so forth). test case A specification of how one should test part of a system, including the inputs, the expected outputs, and the conditions under which the test should occur. test component A piece of code that automates all or parts of one or more test procedures. test engineer A worker who is responsible for planning integration, system, and regression testing, selecting and describing test cases and corresponding fest procedures, ensuring the completeness and consistency of the test model, and evaluating the results of testing. test evaluation An evaluation of the results of a set of tests that generally includes a list of defects and their priority levels, as well as statistical information, such as the ratio of defects to lines of code. test model A package that contains the test cases, test procedures, and test components for the system being built.

test plan A document that describes the QA resources that will be available for testing and the schedule of tests, as well as the test strategy, which specifies what tests will be performed within each iteration and details such as required levels of code coverage. test procedure A specification of how to perform all or parts of one or more test cases.

Test workflow The set of activities aimed at building the test model. Transition phase The phase during which the development team tries to roll out the fully functional system to its customers. use case A sequence of actions that an actor performs within a system to achieve a particular goal. use case diagram A UML diagram that shows actors, use cases, and the relationships among them.

WV

GLOSSARY

use case engineer A worker who builds one or more use case realizations— analysis and one or more use case realizations—design. use case model A model that captures the functional requirements of the system. This model allows the project stakeholders to agree on the capabilities of the system and the conditions to which it must conform. use case realization—analysis A collaboration that describes how the actor(s) and the system perform a given use case, in terms of analysis classes. use case realization—design A collaboration that describes how the actor(s) and the system perform a given use case, in terms of design classes.

use case specifier A worker who writes detailed descriptions of the main flow of events and exceptional flows of events for one or more use cases. user-interface designer A worker who provides the visual shaping of the user-interface prototype that one or more actors will use. white-box testing Testing that tries to verify the internal workings of the code inside a method, class, or component. Synonyms: implementation-based testing and structural testing. worker A role played by an individual, or a group of individuals working together as a team, on a project.

workflow A set of activities that various project workers perform. The Unified Process defines five core workflows: the Requirements workflow, the Analysis workflow, the Design workflow, the Implementation workflow, and the Jest workflow. work product component A component that is part of the system but is not executable. work unit A set of business entities.

Index

A active class and architectural design defined 50 activities Analysis workflow 44 Design workflow

63

62, 63

Implementation workflow 76 Requirements workflow 28 Test workflow 82 activity 18 activity diagram defined 51 example 52 and use cases 34 actor

and business model defined

30

4, 24

and domain model 30 examples 24, 31 finding 30 and requirements 31 versus worker 18 alternate course of action defined 25 examples 34, 109 length of text 33 Ambler, Scott

110

Analysis and Design workflow (RUP) 148 analysis class attributes 46 defined 38 and design class 50 expanding 45 refining 46

reuse 41 types 38 analysis model and architecture description defined 42 as deliverable

42

95,110, 132

and deployment model 50 and design model 49, 50 example 96 introduction 37 refining and expanding 49 and use case model 14, 37, 42 analysis package building 46 defined 41 and design model 63 and design subsystems 56 dividing up tasks 46 examples

42, 113

and use case packages 45 Analysis workflow and Construction phase 131 and Elaboration phase 109 and Inception phase 95 introduction 37 overview 15 analysis-level class diagram 40, 112 Analyze a Class activity in Construction phase 132 defined 45 in Elaboration phase 112 Analyze a Package activity in Construction phase 133 defined 46 in Elaboration phase 113

INDEX

Analyze a Use Case activity in Construction phase 132 defined 45 in Elaboration phase 110 in Inception phase 95 architect Perform Architectural Analysis activity 44 Perform Architectural Design activity 62 Perform Architectural Implementation activity 75 Prioritize the Use Cases activity 33 roles 28, 43, 60, 74 architectural baseline building 122 defined 101 as deliverable 102 evaluating 122 as evaluation criterion 103 initial definition 12 and models 12, 17 as small, skinny system 12 and system integration 136 testing 124 architectural patterns 6, 63, 64 architectural risks 10 architecturally significant elements of analysis model 42 elements of deployment model 59 elements of design model 57 elements of implementation model

WS use cases

26

architecture analyzing 44 defined 5 designing 62 implementing 75 and iterative and incremental development 8 layers 110 modifying 127 real-world realization 69 reasons for importance

and use cases 7 architecture description analysis model 42 defined 5

5, 6, 7

as deliverable

106, 110, 129, 145

deployment model 59 design model 57 implementation model 73 outline 44 purpose 6 and risks 10 use case model 26 architecture-centric 5 artifact 18 artifacts Analysis workflow 38 Design workflow 50 Implementation workflow 70 Requirements workflow 21 Test workflow 79

B basic course of action defined 25 examples

34, 94, 109 length of text 33 Beck, Kent 151, 153 beta release and Construction phase 127 installing 143 releasing 142 big picture 6 black-box testing and test cases 79 and test procedures 80 and unit testing 77 blueprint 49 Booch, Grady 3 boundary object defined 38 examples 40, 111 notation 38 brainstorming 29 Build the Business Model activity defined 30 in Elaboration phase 105 in Inception phase 92 Build the Domain Model activity defined 29 in Elaboration phase 104 in Inception phase 91

INDEX

builds defined

implementing 75 responsibilities 46 class diagram analysis-level 40 defined 22 design-level 54 domain-level 23

8

and integration build plan 73 and stubs 136 and system integration 78 business actor 23 business case completing 145 defined 99

examples

as deliverable 100, 126, 140 as evaluation criterion 90, 104

finalizing 12 and Inception phase initial version 99 making 125 starting 11 updating 140 and vision statement business entity 23 business model and actors 30 building 30

collaboration defined 39 examples 41, 65 collaboration diagram defined 53 example 55 component versus class 70 defined 70 and design classes 76

89

examples

defined 20, 23 as deliverable 92, 105

business use case model

23

c candidate architecture defined 87 as deliverable 92 and Elaboration phase 12 as evaluation criterion 90 expanding into baseline 109 and Inception phase 12 initial definition 11 candidate requirements 20 change control board 143 class analyzing 45 designing 65

77

cohesion 45, 46 Coleman, Russ 123

87

and domain model 30 and Requirements workflow 30 and use cases 30 Business Modeling workfiow (RUP) business object model 23 business processes 20 business use case 23

22,91, 105, 112, 117

class flow graph

148

71, 72

and nodes 58 testing 76 component diagram defined 70 examples 71, 119, 120 component engineer Analyze a Class activity 46 Analyze a Package activity 46 Design a Class activity 65 Design a Subsystem activity 66 Implement a Class activity 76 Implement a Subsystem activity 78 Implement Test activity 84 Perform Unit Test activity 77 roles

43, 62, 74, 81

component-based development (CBD) 6 concurrency and active classes 50 on activity diagram 51 and architectural design 63 Configuration and Change Management workflow (RUP) 149 conformance-directed testing constraint 21

83

INDEX

Construction phase deliverables 128, 129, 132, 133, 135, 137, 140 evaluation criteria 129 and five workflows 127 overview 13 planning 126, 128 primary goal 127 tasks 13 context 91 inside versus outside 99 reaching agreement 20 context diagram 31 control flow graph 77 control object defined 39 examples

40, 111

notation 39 and state diagrams 51 coupling 46 of analysis packages 45 of classes 46 of design subsystems 66 of implementation subsystems coverage 84 cycle 10

78

D defect defined 80 and test evaluation 81 and test model 79 and Transition phase 143 Deployment artifact set 150 deployment component 70 deployment diagram defined 59 example 60 deployment model and analysis model 50 and architecture description defined 58 as deliverable

96, 114, 133

example contents expanding 69

61, 114

introduction 49 and use case model 14 deployment package and deployment model 59 example 61 Deployment workflow (RUP) Design a Class activity in Construction phase 134 defined 65 in Elaboration phase 115 Design a Subsystem activity in Construction phase 134 defined 66 in Elaboration phase 116 Design a Use Case activity in Construction phase 133 defined 64 in Elaboration phase 114 Design artifact set 149 design class and analysis class 50 attributes 66 and components 76 defined 50 expanding 75 operations 65 reuse 56 design mechanisms 63 design model and analysis model 49, 50 and analysis packages 63 and architecture description defined 56 as deliverable

149

57

96, 114, 115, 133

example contents

57,58, 98, 115, 117 and implementation model 69 introduction 49 and use case model 14 design package and design model 56

59

examples

57, 58

design patterns 64 design subsystem and analysis packages defined 56

56

INDEX

example 134 and implementation subsystems Design Test activity in Construction phase 137 defined 83 in Elaboration phase 123 Design workflow and Construction phase 133 and Elaboration phase 113 and Inception phase 95 introduction 49 overview 15 design-level class diagram 54 Detail a Use Case activity in Construction phase 131 defined 33 in Elaboration phase 108 in Inception phase 94 document stereotype 70

72, 78

5

domain model

and actors 30 building 29 and business model 30 defined 20, 22 as deliverable 91, 104 and prototypes 32 and Requirements workflow 29 and use cases 30, 33 domain-level class diagram 23, 91, 105

Elaboration phase deliverables

102, 103, 104, 105, 106, 110,

114, 115, 118, 121, 126 evaluation criteria 103 and five workflows 102 overview 12 planning 100, 103 primary goals 101 tasks 12 engineering artifacts 18 entity object defined

examples notation

39

40, 111 39

Environment workflow (RUP) 149 Evaluate Test activity in Construction phase 139 defined 84 in Elaboration phase 124 example project introduction 1 Iteration 1 91, 92, 93, 94, 95, 97 Iteration 2 104, 106, 107, 108, 110, ISS MGR ser 23 Iteration 3 104, 106, 107, 108, 111, HS Tol 175123 Iteration 4 104, 106, 107, 108, 111, LOM TOMO Oe DID 28 Iteration 5 130, 131, 132, 133, 134, 136, 137, 138, 139 Iteration 6 131, 135, 136, 137, 138, exceptional flow of events defined 25 examples 34, 109 length of text 33 executable stereotype 70 execution component 70 extend relationship defined 35 example 36 extension point defined 35 example 36 Extreme Programming (XP) common ground with RUP 154 development practices 153 differences from RUP 155 fundamental principles 152 versus ICONIX process 157 initial definition 151 values 151

F fault efficiency 83 fault-directed testing 83 feature list defined 20 as deliverable 88 and Inception phase 88

111, 113, 112, D4 135, 139

INDEX

feature sufficiency 83 file stereotype 70 Find Actors and Use Cases activity in Construction phase 129 defined 30 in Elaboration phase 106 in Inception phase 92 flow of events 25 flowchart

as deliverable 118, 135 and design model 69 example contents 119, 120

and use case model 14 implementation package example 73 and implementation model 72 implementation subsystem defined 72 and design subsystems 72, 78 Implementation workflow and Construction phase 135 and Elaboration phase 118 introduction 69 overview 15

34, 51

framework defined 63 example 65 functional decomposition

4

G generalization examples 36 of use cases 36 glossary and Build the Domain Model activity defined 23 grammatical inspection 29

Implementation workflow (RUP)

29

I ICONIX process big picture 158 versus Extreme Programming (XP) versus RUP 157 traceability 157 -ilities 10,90

Implement a Class activity in Construction phase 135 defined 75 in Elaboration phase 120 Implement a Subsystem activity in Construction phase 136 defined 78 in Elaboration phase 122 Implement Test activity in Construction phase 137 defined 84 in Elaboration phase 123 Implementation artifact set 150 implementation model and architecture description 73 building 75 defined 72

157

148 implementation-baséd testing 77 Inception phase deliverables 88, 89, 90, 91, 92, 93, 95, 96, 100 evaluation criteria 90 and five workflows 88 overview 11 planning 89 primary goal 87 tasks 11 include relationship defined 35 examples 35 increment

7, 16

Initial Operational Capability major milestone 13 Integrate the System activity in Construction phase 136 defined 78 in Elaboration phase 122 integration build plan creating 78 defined 73 expanding 78 integration tester Perform Integration Test activity 84 roles 81 integration testing defined 83 performing 84

INDEX

interface class 55

design 15 implementation 15 and iterative and incremental development WY test 16 use case 14 Model-View-Controller (MVC) architectural pattern 65 momentum 9

component 71 defined 55 examples 56, 72 Internet time iteration

6

assessing 98, 125, 139, 145 defined 7, 16 iterative and incremental advantages 7, 8,9

basic steps illustrated

and models

N

16 17

17

J Jacobson, Ivar

2, 3, 23, 157

JAD see Joint Application Development (JAD) Joint Application Development (JAD) 31

negative testing 80 node defined 58 examples 59, 60 nonfunctional requirements 32, 83 capturing 32 defined 21 and supplementary requirements 26 and system testing 83 noun-verb analysis 29

L library stereotype 70 Life-Cycle Architecture major milestone 12 Life-Cycle Objectives major milestone 12

O

M

Objectory 2,3 OML see Open Modeling Language (OML) Open Modeling Language (OML) 36

main fiow of events defined 25 examples 34, 94, 109 length of text 33 maintenance 6

ie package analyzing 46 defined 25

major milestone defined 10 Initial Operational Capability Life-Cycle Architecture 12 Life-Cycle Objectives 12 Product Release 13 make versus buy 10 management artifacts 18 Management artifact set 149 method flow graph 77

models analysis 15 and architectural baseline defined 1 deployment 15

17

examples

13

26, 42, 57,58, 61, 65, 67, 73,

113 patterns architectural

6, 63

defined 63 design 64 examples

64, 65

Perform Architectural Analysis activity in Construction phase 132 defined 44 in Elaboration phase 109 in Inception phase 95 Perform Architectural Design activity in Construction phase 133 defined 62

INDEX

Perform Architectural Design activity, continued in Elaboration phase 113 in Inception phase. 96 Perform Architectural Implementation activity defined 75 in Elaboration phase 118 Perform Integration Test activity in Construction phase 138 defined 84 in Elaboration phase 124 Perform System Test activity in Construction phase 138 defined 84 in Elaboration phase 124 Perform Unit Test activity in Construction phase 135 defined 77 in Elaboration phase 121 phase assessing 99, 125, 139, 145 defined 10 phases Construction 13 Elaboration 12 Inception 11 Transition 13 Plan Test activity in Construction phase 136 defined 82 in Elaboration phase 122 postmortem

8, 17, 146

Prioritize the Use Cases activity in Construction phase 131 defined 33 in Elaboration phase 108 in Inception phase 93 problem space 22, 29, 158 Product Release major milestone 13 Project Management workflow (RUP) project plan as deliverable 89, 103, 129 initial version 89 updating 17, 103, 128, 142 prototype

and actors as artifact

30, 32 25

148

and domain model 32 and ICONIX process 158 and requirements 8, 25 and use cases 21, 30, 32 Prototype the User Interface activity in Construction phase 130 defined 32 in Elaboration phase 107 Proxy design pattern 64

R Rational Objectory Process (ROP) 3 Rational Unified Process (RUP) See RUP realization 55 realize 55 regression testing 83 requirements and actors 31 dealing with changes 8 difficulty in capturing 19 as evaluation criteria 90, 103 and features 21 negotiating 8, 10, 19, 21, 38 and system testing 83 traceability 157 and use cases 4, 21, 33 Requirements artifact set 149 requirements risk 8, 10, 102 Requirements workflow and Construction phase 129 and Elaboration phase 104 and Inception phase 91 introduction 19 overview 14 Requirements workflow (RUP) 148 responsibility-based testing 77 reuse of analysis classes 41 and Analysis workflow 37 and architecture 5, 6 of design classes 56 of project artifacts 146 of test cases 83 right system 10, 19

INDEX

risk list as deliverable

sequence diagram 90, 104

initial version 90 updating 17 risks categories 9 and Construction phase 127 critical 11, 16, 87, 90, 101, 103, 127 and Elaboration phase 101,102 as evaluation criteria 90, 103

|

and Inception phase 87 and iterative and incremental development

8, 9

preliminary assessment 89 significant 12, 93, 101, 102, 103, 108, 127 and test design 83 and test planning 83 robustness analysis defined 39 and ICONIX process 159 and use cases 45 robustness diagram and Analyze a Use Case activity 45 characteristics 45 defined 40 and Design a Use Case activity 64 examples

40, 96, 97, 111 and packages 42 Rosenberg, Doug 29, 157 Rumbaugh, Jim 3 RUP common ground with XP 154 contents 147 differences from XP 155 history 3 versus ICONIX process 157 versus Unified Process 1 workflows 147 ruthless prioritization 8

S scaffolding 6 scope as evaluation criterion 90 defining 11 and Inception phase 87

defined 52 examples 54,116, 117 service 41]

service package 41 service subsystem 56 small, skinny system 12 special requirements and Analysis workflow 45, 46 defined 32 and Design workflow 65 and Requirements workflow 32 specification testing 77 state diagram defined 51 example 53 and unit testing 77 statechart diagram defined 51 example 53 storyboards 25 stress testing 80 structural testing 77 Structure the Use Case Model activity in Construction phase 131 defined 35 in Elaboration phase 109 subsystem designing 66 examples 67 implementing 78 supplementary requirements 26, 32 system analyst Build the Business Model activity 30 Build the Domain Model activity 29 Find Actors and Use Cases activity 30, 135 roles 27 Structure the Use Case Model activity 35 system integrator Integrate the System activity 78 roles 75 system tester

Perform System Test activity roles 82

84

INDEX

system testing focus 83 performing 84

introduction 79 overview 15

T table stereotype technical risks

70 10, 102

test case and black-box testing 79 defined 79 integration testing 83 reusing 83 system testing 83 and test procedures 80 and white-box testing 80 test component

creating 84 defined 80 test engineer Design Test activity 83 Evaluate Test activity 84 Plan Test activity 82 roles 81 test evaluation building 84 defined 81 test harness 80 test model

Test workflow (RUP) 148 three amigos 3 traceability of classes 65 of models 49 of packages 46, 63, 65 of requirements 4, 32, 157 of subsystems 65, 72, 78 Transition phase deliverables 143, 144, 145 evaluation criteria 142 and five workflows 141 overview 13 planning 140, 142 primary goal 141 tasks 13

U use case alternate course of action 25 analyzing 45 and architecture 7 basic course of action 25 and black-box testing 79 and business model 30

building

83

defined

contents

83, 84

designing 64 detailing 33

defined

80

as deliverable

121, 137

and use case model 14 test plan defined 80 developing 82 test procedure and black-box testing 80 defined 80 reusing 83 and test components 80 and white-box testing 80 test script 80 test strategy 83 Test workflow and Construction phase 136 and Elaboration phase 122

4, 21, 24

and domain model

30, 33

examples 25, 31 exceptional flow of events 25 and extend relationship 35 features 4 finding 30 generalization 36 good qualities 33 and ICONIX process 158 and include relationship 35 main flow of events 25 prioritizing 33 and prototypes 21 and requirements 21, 33 versus requirements 4 and system decomposition 4

INDEX

and system testing 83 and test planning 83 use case diagram defined

examples

20, 31

31, 93, 94, 107, 130

use case driven

4, 157 use case engineer Analyze a Use Case activity 45 Design a Use Case activity 64 roles 43, 61 use case model and analysis model 37 and architecture description 26 defined 25 as deliverable 92, 106, 129 example contents 26 and other models 14 refining and expanding 37 structuring 35 use case package and analysis packages 45 dividing up tasks 32 example 26 use case ranking list 93 use case realization—analysis defined 39 examples 41 realizing physically 51 use case realization—design defined 51 example 54 and integration testing 83 and white-box testing 80 use case specifier Detail a Use Case activity 33 roles. 27, user acceptance testing 143 user interface attributes 46 prototyping 32 user manual 21, 144

user-interface designer Prototype the User Interface activity 32 roles 27 user-interface prototype as artifact 25 building 32

Vv vision statement

89

WwW waterfall 8 white-box testing and test cases 80 and test procedures 80 and unit testing 77 work product component 70 work unit 23 worker versus actor 18 defined 18 inRUP 150 workers Analysis workflow 43 Design workflow 59 Implementation workflow 74 Requirements workflow 27 Test workflow 81 workflow 13 workflows Analysis 15 Design 15 Implementation 15 Requirements 14 est 1S wrapping 56

xX XP See Extreme Programming

151

Also Available from Addison-Wesley

TI ‘Use Case DRIVEN

Use Case Driven Object Modeling with UML by Doug Rosenberg and Kendall Scott

Opject MODELING with UML

0-201-43289-7

© ©1999 ¢ Paperback © 192 pages

A PRACTICAL APPROACH DOUG ROSENBERG wer kK NDALL »

Use Case Driven Object Modeling with UML provides practical guidance that shows developers how:to produce UML models with minimal startup time, while maintaining traceability from user requirements through detailed designing and coding. The authors present proven methods for driving the object modeling process forward in a straightforward manner.

Applying Use Case Driven Object Modeling with UML A PPLYING Use Cask Driven OBJECT MOobeLine with UML

An Annotated e-Commerce Example by Doug Rosenberg and Kendall Scott

AN ANwotaTeD &-CoMMeRCE EXAMPLE

0-201-73039-1

¢ ©2001 ¢ Paperback © 176 pages

This companion workbook to Use Case Driven Object Modeling with UML bridges the gap between the theory presented in the authors’ first book, and the practical issues involved in the development of an Internet/e-Commerce application. Uniquely conceived as a workbook, featuring an e-Commerce system for an online bookstore as a running example, the book dissects its design in detail, demonstrates the most common design mistakes, and reveals the correct solutions.

UML Explained by Kendall Scott 0-201-72182-1

>

© Ouich: yetthorough introduction te UM

GY,

= Keyconcepts exptoinad in a ight and engaging manner 5

» Filed with Utl, diagrams and clear explanations

KENDALL SCOTT

* ©2001 © Paperback ¢ 176 pages

Assuming no prior knowledge of the UML, object-oriented design, or programming fundamentals, this book fully explains basic concepts and terminology such as objects, classes, and use cases. It shows how the UML integrates with an iterative and incremental process.

Free, indepth articles and

Solutions from experts you know and trust.

Supplements

Master the skills you need, when you need them

Choose from industry leading books, ebooks, and training products

Achieve industry certification

and advance your career Get answers when you need them from live Homteposta Pblic Question

Post of View Public Questions and Projects

Cigale aetedakecoxa

Post 4 question orproject and see what others are asking

experts or InformlT’s

ane Nektaken ore

Fone

Post 4 Public Guestion

re keen, henpay

Posts Pes

Post a question and the most qualified Experts wil

How caciPest

comprehensive library

Welcome toinformiT Vmtm tying tay tofreeyourming,Neo.ButcanonlyshowyouthedoorVouire 7 hestowalkthrough —_{‘Save your Avery yore conte theonethat Saveyou contreget

—Mormneus, Themetre

‘and become preregstared toask

ourexperts questons,Joie ws!>

Uru expert Cayid Banded this week viking about thenaw Unux 2.4.0redives frewall sofware, Netiiter replaces theLinuc 2.20ipohaine sofwane ardtheUrax 20.0) lpfadn sofmaieDavidalso dsousses system logging, andinedand TOPWrappers:

Pro a

More.

Ah DavidCarel abou Nertlter, systemlogging,andinetdandTOPWappes. jp

also locks atTOP

Cordguraten forinetdcoreWisepers

Hew Articles 1092000 Yaw | This artole wkes 2 quck lock attwoimportant system condguration fles:|natd.contand ca also looks atTOP Wappers ocniguaton brination 1030.00 beable |THis artolelocks at» coupleofhearchtect! xinananting nx 24.0 ledoesnolgoin-depth; is meant tointtoduoe youto M : | inthetid artolain teWitdess Aoo.ass Protaool es, sur ors Chis 3 jeexplore thefeatures ofWMLIn more detail aLnts foutvariclein teWirdess Azcess Pickod sates, aufors Chis Bannattad paste of thelanguage basios behind WMLSoiipt. an pie |tee As Cee aydine iia tartrecha raging expeotators bothof delivered podwts and Jenioes rand tesupportassoctatad withfem, Theinertoftvs3 Golals © axplovehowtemawet Gpramos of baapploaten saareca anenrestwelna pesiortmror, Inside te rouctva ce fat ouremerr play Wis i ll oonparywares© dosoonmeste, bhava: salibuyeurelly Alaloarseonspal adherence wr sucess Los Columbuswlksabouta orlfcal facetofeopare ton: Gd¥e | Conponack Sarces, treOral nameforCOM,are desioned wsurpor ining Yared sys ternsbuiltcncomponent technclagy.. Inmary ways,OON+ Issimply

www.informit.com

Fa

es

Visit InformIT pla

and get great content A from ew Addison

Wesley a

¢ Advance notice of forthcoming editions of the book * Related book recommendations ¢ Chapter excerpts and supplements of forthcoming titles ¢ Information about special contests and promotions

throughout the year ¢ Notices and reminders about author appearances,

Contact us If you are interested in writing a book or manuscripts prior to publication, please Editorial Department Addison-Wesley Professional 75 Arlington Street, Suite 300 Boston, MA 02116 USA

Email: [email protected]

Visit us on the Web; http://www.aw.com/cseng

Object Technology

THE UNIFIED PROCESS Euplained he Rational Unified Process (RUP) has been widely adopted across the software industry. However, many software developers and managers—especially those working in medium-to-small development organizations — are hesitant to delve into this seemingly complex and time-consuming topic. The Unified Process Explained is a concise, accessible, and practical guide that’s meant to help significantly shorten the learning curve for practitioners unfamiliar with this methodology. It explains the essentials of the Unified Process (the RUP’s core elements), guides you through the process step-by-step, and shows how you can put the methodology to.work on your next project.

The book starts with a useful overview of the history, motivation, key concepts, and terminology of the Unified Process. The author then details the five pillars of development: requirements, analysis, design, implementation, and test workflows. In addition, the book enumerates the four phases of Unified Process development: inception, me gbygation, construction, and transition; and it shows how the workflows are

integrated into these phasés n laying out the details of this integeanere the book illustrates the Unified Process’s most useful feature — its #erative nature. ae

With this book as your guide, you dillgain an understanding of important concepts and activities such as: ¢ ¢ ¢ ¢ ¢ * ¢ ¢

Iterations and increments , Business and domain modeling Identifying actors and use cases Prototyping the user interface Robustness analysis Design and deployment models Statechart and activity diagrams Implementation models

A large-scale example of an Internet bookstore runs throughout the book to illustrate concepts and techniques. The industry-standard Unified Modeling Language is used to express structure and function. The Unified Process Explained demystifies this valuable methodology and will lead you on your way to successfully applying the Rational Unified Process. D

i]

Kendall Scott is a UML trainer andconultara

————=

writer, he is skilled in converting complex, teh

===

He is the author of UML Explained and co-auth

Ss

UML, Applying Use Case Driven Object Modeling,

—all published by Addison-Wesley.

, pe

===

SS Ely

——=—"r

SF

http://www.aw.com/cseng/ Cover design by Katie Noyes

4 ~'

ee ee —— fee Ge

om

RE

ew,

PROCESS EsPLAINED

rie

te ta

ACH

mo

ae

,

wy

oo oc

: 2

9e0281

‘3

-@ Text printed on recycled paper

vv Addison-Wesley

ISBN

U-cUb-rstcus.

Pearson Education:

$34.99 US

= $52.50 CANADA