Surviving object-oriented projects: 对象软件项目求生法则

265 Pages·3.722 MB·English

by  Cockburn, Alistair(Editor)

Development: The Team
SmallWritingTeam Restrict the number of people refining any one work product to just two
or three people. Use a TwoTierReview process to include more people.
ParticipatingAudience Actively involve your customers and internal stakeholders in the use
case development process when possible.
BalancedTeam Staff the team with people from different specialties to champion the
interests of the stakeholders in the development process. Make sure the
team contains both designers and end users.
Development: The Process
BreadthBeforeDepth Conserve your energy by developing an overview of your use cases first
and then progressively add detail, working across a group of related use
cases.
SpiralDevelopment Develop use cases in an iterative, breadth-first manner, with each itera-
tion progressively increasing the precision and accuracy of the use case
set.
MultipleForms Select the format based on the risks associated with the project and the
preferences of the people involved.
TwoTierReview Hold two types of review: The first by a smaller, internal team, possibly
many times. The second by the complete group, perhaps just once.
QuittingTime Stop developing use cases once they are complete and satisfactorily meet
audience needs.
WritersLicense Small differences in writing style are inevitable. Once a use case passes
the tests for QuittingTime, the writer can claim “writer’s license” on
small stylistic differences.
Development: Editing
RedistributeTheWealth Move a long, unwieldy passage or an overly complex extension to its own
user case.
MergeDroplets Merge related tiny use cases or use case fragments into the use cases
that relate to the same goal.
CleanHouse Remove those use cases that do not add value to your system or that are
no longer in your active list.
Structure: The Use Case Relationships
CommonSubBehavior Express shared courses of action with lower-level, included use cases.
InterruptsAsExtensions Create an extension use case when an alternative course of action inter-
rupts a number of steps in a scenario.
PromotedAlternative Consider moving complex alternatives that overly dominate a use case
into a separate use case.
(CapturedAbstraction) (Consider creating a generalized, abstract use case. Put each distinct vari-
ant scenario that specializes the abstraction in its own, specialized use
case.)
Structure: The Use Case Set
SharedClearVision Prepare a statement of purpose for the system that clearly describes the
objectives of the system and supports the mission of the organization.
Freely distribute it to everyone involved with the project.
VisibleBoundary Establish a visible boundary between the system and its environment
by enumerating both the equipment and people that interact with the
system.
ClearCastOfCharacters Identify the actors the system must interact with and the role each plays
with respect to the system. Clearly describe each.
UserValuedTransactions Identify the valuable services that the system delivers to the actors to
satisfy their business purposes.
EverUnfoldingStory Organize the use case set as a hierarchical story that can be either
unfolded to get more detail or folded up to hide detail and show more
context.
Structure: The Use Case
CompleteSingleGoal Write each use case to address one complete and well-defined goal. That
goal may be at any level in the EveryUnfoldingStory.
VerbPhraseName Name the use case with an active verb phrase that represents the goal of
the primary actor.
ScenarioPlusFragments Write the success story line as a simple scenario without any consider-
ation for possible failures. Below it, place story fragments that show
what alternatives may occur.
ExhaustiveAlternatives Capture all alternatives and failures that must be handled in the use case.
Adornments Create additional fields in the use case template that are outside the
scenario text, to hold the supplementary information that is useful to
associate with the use case.
PreciseAndReadable Write the use case to be readable enough so that the stakeholders bother
to read and evaluate it, and precise enough so that the developers under-
stand what they are building.
Structure: The Scenario
DetectableConditions Include only detectable conditions. Merge conditions that have the same
net effect on the system.
LeveledSteps Keep scenarios to three to nine steps. Ideally, the steps are all at similar
levels and at a level of abstraction just below the use case goal.
Structure: The Step
ActorIntentAccomplished Write each step to show clearly which actor is performing the action,
and what the actor gets accomplished.
ForwardProgress Eliminate or merge steps that do not advance the actor. Simplify passages
that distract the reader from this progress.
TechnologyNeutral Write each step in a technology-neutral manner.
Patterns for
Effective Use Cases
The Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
For more information check out http://www.awprofessional.com/
Agile software development centers on four values identified in the Agile Alliance’s Manifesto:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
The development of Agile software requires innovation and responsiveness, based on generatingand
sharing knowledge within a development team and with the customer. Agile software developers
draw on the strengths of customers, users, and developers, finding just enough process to balance
quality and agility.
The books in The Agile Software Development Seriesfocus on sharing the experiences of such
Agile developers. Individual books address individual techniques (such as Use Cases), group tech-
niques (such as collaborative decision making), and proven solutions to different problems from a
variety of organizational cultures. The result is a core of Agile best practicesthat will enrich your
experience and improve your work.
Titles in the Series:
Alistair Cockburn, Surviving Object-Oriented Projects, ISBN 0-201-49834-0
Alistair Cockburn, Writing Effective Use Cases, ISBN 0-201-70225-8
Lars Mathiassen, Jan Pries-Heje, and Ojelanki Ngwenyama, Improving Software Organizations:
From Principles to Practice, ISBN 0-201-75820-2
Alistair Cockburn, Agile Software Development, ISBN 0-201-69969-9
Jim Highsmith, Agile Software Development Ecosystems, ISBN 0-201-76043-6
Steve Adolph, Paul Bramble, Alistair Cockburn, and Andy Pols, Patterns for Effective Use Cases,
ISBN 0-201-72184-8
Patterns for
Effective Use Cases
Steve Adolph and Paul Bramble
With Contributions by Alistair Cockburn and Andy Pols
(cid:2)
(cid:3)(cid:3)
Addison-Wesley
Boston • San Francisco • New York • Toronto • Montreal
London • Munich • Paris • Madrid
Capetown • Sydney • Tokyo • Singapore • Mexico City
vi
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 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 as-
sumed for incidental or consequential damages in connection with or arising out of the use of the
information or programs contained herein.
The publisher offers discounts on this book when ordered in quantity for bulk purchases and special
sales. For more information, please contact:
U.S. Corporate and Government Sales
[phone]
[email protected]
For sales outside of the U.S., please contact:
International Sales
[phone]
[email protected]
Visit Addison-Wesley on the Web: www.awprofessional.com
Library of Congress Cataloging-in-Publication Data
Patterns for effective use cases / Steve Adolph . . . [et al.].
p. cm.
Includes bibliographical references and index.
ISBN 0-201-72184-8
1. Software patterns. 2. Application software—Development. 3. Use cases (Systems
engineering) I. Adolph, U.S.
QA76.76.P37 P38 2003
005.1—dc21 2002074419
Copyright © 2003 by Pearson Education, Inc.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or
transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or oth-
erwise, without the prior consent of the publisher. Printed in the United States of America. Published
simultaneously in Canada.
For information on obtaining permission for use of material from this work, please submit a written
request to:
Pearson Education, Inc.
Rights and Contracts Department
75 Arlington Street, Suite 300
Boston, MA 02116
Fax: [phone]
ISBN 0-201-72184-8
Text printed on recycled paper
1 2 3 4 5 6 7 8 9 10—CRS—0605040302
First printing, August 2002
Photo credits appear on page 219.
vii
To my best friend and wife Fariba. For all your support
and patience, thank you.
—Steve
To Christine, Elizabeth, Michael, and Rebecca, for all
your love and support, and to Mom and Dad for teaching
me many things, including how to write.
—Paul
To all the people at the original use case patterns work-
shop for generating ideas, and to Fariba, Deanna, and
Christine for graciously hosting our mini-PLUC work-
shops.
—Alistair
To Steve, Paul, and Alistair for their patience.
—Andy
This page intentionally left blank
Contents
Foreword by Craig Larman xiii
Preface xv
Acknowledgments xxi
Chapter 1 What Is a Quality Use Case? 1
1.1 Why Use Cases at All?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
1.2 What’s So Hard about Telling Good Stories? . . . . . . . . . . . . . . . . . . . . . . . . .2
1.3 Why a Use Case Pattern Language? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
1.4 What Are Patterns? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
1.5 How Should I Use This Pattern Language?. . . . . . . . . . . . . . . . . . . . . . . . . . .9
1.6 What Is the Use Case Pattern Form?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Stepping through a Sample Pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Organization of the Pattern Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Development Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Structural Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.8 Supplement: A Brief Tutorial on Writing Use Cases. . . . . . . . . . . . . . . . . . .23
Chapter 2 The Team 29
2.1 Team Organizational Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
2.2 SmallWritingTeam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
ix