TIM

SYSTEMS ANALYSIS & DESIGN An Object-Oriented Approach with UML

5 T H E D I T I O N

D E N N I S W I X O M T E G A R D E N

Visible Analyst is a “hands-on” tool for teaching students all aspects of analysis and design including dynamic rules, consistency checking, managing change, and understanding the integration issues across an IT project. Visible Analyst prepares students to enter the IT world as business or data architects, analysts, designers, and modelers.

Visit us at www.visible.com to learn more.

YOU CAN Start Today with the Visible Analyst!

Only takes 2 minutes to install! Save… 33% discount!

Please visit http://store.visible.com/Wiley.aspx to purchase and register with your information (see below) and obtain a valid license for your student edition of the software. To purchase the discounted software you will need to enter the following code:

978112014

Email support is provided to all registered students at [email protected]. Your registration includes

the latest release of the Visible Analyst Student Edition (software)

the Visible Analyst eTutorial a preloaded Sample Instructional

Project access to Webcast “How to” and “Get

Started” Instructional Videos.

Visible Analyst Student Edition Educating tomorrow’s developers today

Disclaimer: The publisher of the textbook does not sponsor, review, or make decisions about Visible Analyst software, and will not be responsible for, or involved in, any changes to the software.

System Analysis & Design A n O bject -O riented A pproach with UML

Fift h Edition

Alan Dennis Indiana University

Barbara Haley Wixom Massachusetts Institute of Technology

David Tegarden Virginia Tech

With contributions by Elaine Seeman, East Carolina University

VP & EXECUTIVE PUBLISHER: Don Fowley EXECUTIVE EDITOR: Beth Lang Golub CONTENT EDITOR: Mary O’Sullivan ASSOCIATE EDITOR: Ellen Keohane MARKETING MANAGER: Christopher Ruel ASSOCIATE PRODUCTION MANAGER: Joyce Poh DESIGNER: Wendy Lai

Cover Image: © Christopher Boswell/Shutterstock

Th is book was set in 10/12 Minion pro by Aptara and printed and bound by Courier Kendallville. Th e cover was printed by Courier Kendallville.

Th is book is printed on acid-free paper .

Founded in 1807, John Wiley & Sons, Inc. has been a valued source of knowledge and understanding for more than 200 years, helping people around the world meet their needs and fulfi ll their aspirations. Our company is built on a foundation of principles that include responsibility to the communities we serve and where we live and work. In 2008, we launched a Corporate Citizenship Initiative, a global eff ort to address the environmental, social, economic, and ethical challenges we face in our business. Among the issues we are addressing are carbon impact, paper specifi cations and procurement, ethical conduct within our business and among our vendors, and community and charitable support. For more information, please visit our website: www.wiley.com/go/citizenship.

Copyright © 2015, 2012, 2009 John Wiley & Sons, Inc. All rights reserved. No part of this publication may be repro- duced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photo- copying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923 (Web site: www.copyright.com). Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030-5774, (201) 748-6011, fax (201) 748-6008, or online at: www.wiley.com/go/permissions.

Evaluation copies are provided to qualifi ed academics and professionals for review purposes only, for use in their courses during the next academic year. Th ese copies are licensed and may not be sold or transferred to a third party. Upon completion of the review period, please return the evaluation copy to Wiley. Return instruc- tions and a free of charge return shipping label are available at: www.wiley.com/go/returnlabel. If you have chosen to adopt this textbook for use in your course, please accept this book as your complimentary desk copy. Outside of the United States, please contact your local sales representative.

Library of Congress Cataloging-in-Publication Data

Dennis, Alan. Systems analysis & design : an object-oriented approach with UML/Alan Dennis, Indiana University, Barbara Haley Wixom, Massachusetts Institute of Technology, David Tegarden, Virginia Tech; with contributions by Elaine Seeman, East Carolina University.–Fift h edition. pages cm Includes bibliographical references and index.

ISBN 978-1-118-80467-4 (pbk. : alk. paper) 1. System analysis. 2. System design. 3. UML (Computer science) I. Wixom, Barbara Haley, 1969-II. Tegarden, David Paul. III. Seeman, Elaine. IV. Title. V. Title: System analysis and design. QA402.D395 2015 004.2’1–dc23

2014048338

Printed in the United States of America

10 9 8 7 6 5 4 3 2 1

PURPOSE OF THIS BOOK Systems Analysis and Design (SAD) is an exciting, active fi eld in which analysts continually learn new techniques and approaches to develop systems more eff ectively and effi ciently. However, there is a core set of skills that all analysts need to know—no matter what approach or methodology is used. All information systems projects move through the four phases of planning, analysis, design, and implementation; all projects require analysts to gather requirements, model the business needs, and create blueprints for how the system should be built; and all projects require an understanding of organizational behavior con- cepts like change management and team building. Today, the cost of developing modern soft ware is composed primarily of the cost associated with the developers themselves and not the computers. As such, object-oriented approaches to developing information systems hold much promise in controlling these costs.

Today, the most exciting change to systems analysis and design is the move to object-oriented techniques, which view a system as a collection of self-contained objects that have both data and processes. Th is change has been accelerated through the crea- tion of the Unifi ed Modeling Language (UML). UML provides a common vocabulary of object-oriented terms and diagramming techniques that is rich enough to model any sys- tems development project from analysis through implementation.

Th is book captures the dynamic aspects of the fi eld by keeping students focused on doing SAD while presenting the core set of skills that we feel every systems analyst needs to know today and in the future. Th is book builds on our professional experience as systems analysts and on our experience in teaching SAD in the classroom.

Th is book will be of particular interest to instructors who have students do a major project as part of their course. Each chapter describes one part of the process, provides clear explanations on how to do it, gives a detailed example, and then has exercises for the students to practice. In this way, students can leave the course with experience that will form a rich foundation for further work as a systems analyst.

OUTSTANDING FEATURES

A Focus on Doing SAD Th e goal of this book is to enable students to do SAD—not just read about it, but under- stand the issues so that they can actually analyze and design systems. Th e book introduces each major technique, explains what it is, explains how to do it, presents an example, and provides Your Turn opportunities with each chapter for students to practice each new tech- nique before they do it for real in a project. Th e Your Turn boxes are posted online at www. wiley.com/college/dennis. Aft er reading each chapter, the student will be able to perform that step in the system development process.

P R E F A C E

v

vi Preface

Rich Examples of Success and Failure Th is book has a running online case study (accessible from www.wiley.com/go/dennis/ casestudy ) about a fi ctitious health care company called Patterson Superstore. Each chapter of the case study shows how the concepts are applied in situations at Patterson Superstore. In this way, the running case serves as a template that students can apply to their own work. Each chapter also includes numerous Concepts in Action boxes, which are posted online at www.wiley.com/college/dennis. Th ese boxes describe how real companies succeeded—and failed—in performing the activities in the chapter. Many of these examples are drawn from our own experiences as systems analysts.

Real World Focus The skills that students learn in a systems analysis and design course should mirror the work that they ultimately will do in real organizations. We have tried to make this book as “real” as possible by building extensively on our experience as professional sys- tems analysts for organizations, such as Arthur Andersen, IBM, the U.S. Department of Defense, and the Australian Army. We have also worked with a diverse industry advisory board of IS professionals and consultants in developing the book and have incorporated their stories, feedback, and advice throughout. Many students who use this book will eventually use the skills on the job in a business environment, and we believe they will have a competitive edge in understanding what successful practition- ers feel is relevant in the real world.

Project Approach We have presented the topics in this book in the order in which an analyst encounters them in a typical project. Although the presentation is necessarily linear (because students have to learn concepts in the way in which they build on each other), we emphasize the iterative, complex nature of SAD as the book unfolds. Th e presentation of the material should align well with courses that encourage students to work on projects because it presents topics as students need to apply them.

WHAT’S NEW IN THIS EDITION ■ A completely new, expanded case study on an integrated health clinic delivery

system has been written to accompany the fi ft h e dition. Th e entire case study is posted online. At the end of each chapter in the text, a short synopsis of the case is provided.

■ Th e text has been streamlined to focus on the essentials and therefore, to enhance student understanding. Selected m aterial s like the “Your Turn” and “Concepts in Action” boxes have been moved online and can be accessed at www.wiley.com/ college/dennis .

■ Th roughout the book , there is a greater emphasis on verifying, validating, and testing, as well as the incremental and iterative development of systems.

■ In Chapter 2, there is more content on Agile techniques , including scrum meet- ings, product backlog, and sprints.

■ In Chapter 3, we have increased focus on soft ware quality and user stories. ■ We have added new examples throughout the book and clarifi ed explanations to

help students learn some of the more diffi cult concepts.

Preface vii

■ Chapter 10 includes more coverage of mobile computing , including specifi cs on navigation, input, and output. Th is chapter also has a new section on games, multidimensional information visualization, augmented reality, and virtual reality.

■ Chapter 11 includes new material o n ubiquitous computing and the Internet of Th ings. ■ Testing has been expanded in Chapter 12.

ORGANIZATION OF THIS BOOK Th is book is loosely organized around the phases and workfl ows of the enhanced Unifi ed Process. Each chapter has been written to teach students specifi c tasks that analysts need to accomplish over the course of a project, and the deliverables that will be produced from the tasks. As students complete the chapters, they will realize the iterative and incremental nature of the tasks in object-oriented systems development.

Chapter 1 introduces the SDLC, systems development methodologies, roles and skills needed for a systems analyst, the basic characteristics of object-oriented systems, object-oriented systems analysis, the Unifi ed Process, and the UML. Chapter 2 presents topics related to the project management workfl ow of the Unifi ed Process, including pro- ject identifi cation, system request, feasibility analysis, project selection, traditional project management tools (including work breakdown structures, network diagrams, and PERT analysis), project eff ort estimation using use-case points, evolutionary work breakdown structures, iterative workplans, scope management, timeboxing, risk management, and staffi ng the project. Chapter 2 also addresses issues related to the Environment and Infra- structure management workfl ows of the Unifi ed Process.

Part One focuses on creating analysis models. Chapter 3 introduces students to an assort- ment of requirements analysis strategies a variety of requirements-gathering techniques that are used to determine the functional and nonfunctional requirements of the system, and to a system proposal. Chapter 4 focuses on constructing business process and functional models using use - case diagrams, activity diagrams, and use - case descriptions. Chapter 5 addresses producing structural models using CRC cards, class diagrams, and object diagrams. Chapter 6 tackles creating behavioral models using sequence diagrams, communication diagrams, behavioral state machines, and CRUDE analysis and matrices. Chapters 4 through 6 also cover the verifi cation and validation of the models described in each chapter.

Part Two addresses design modeling. In Chapter 7, students learn how to verify and validate the analysis models created during analysis modeling and to evolve the analysis models into design models via the use of factoring, partitions, and layers. Th e students also learn to create an alternative matrix that can be used to compare custom, packaged, and outsourcing alternatives. Chapter 8 concentrates on designing the individual classes and their respective methods through the use of contracts and method specifi cations. Chapter 9 presents the issues involved in designing persistence for objects. Th ese issues include the diff erent storage formats that can be used for object persistence, how to map an object- oriented design into the chosen storage format, and how to design a set of data access and manipulation classes that act as a translator between the classes in the application and the object persistence. Th is chapter also focuses on the nonfunctional requirements that impact the data management layer. Chapter 10 presents the design of the human–computer interaction layer, where students learn how to design user interfaces using use scenarios, windows navigation diagrams, storyboards, windows layout diagrams, user interface prototypes, real use cases, interface standards, and user interface templates; to perform user interface evaluations using heuristic evaluation, walkthrough evaluation, interactive evaluation, and formal usability testing; and to address nonfunctional requirements such

viii Preface

as user interface layout, content awareness, aesthetics, user experience, and consistency. Th is chapter also addresses issues related to mobile computing, social media, games, multi dimensional information visualizations, immersive environments, and international and cultural issues with regard to user interface design. Chapter 11 focuses on the phys- ical architecture and infrastructure design, which includes deployment diagrams and hardware/soft ware specifi cation. In today’s world, this also includes issues related to cloud computing, ubiquitous computing, the Internet of things, and green IT. Th is chapter, like the previous design chapters, covers the impact that nonfunctional requirements can have on the physical architecture layer.

Part Th ree provides material that is related to the construction, installation, and operations of the system. Chapter 12 focuses on system construction, where students learn how to build, test, and document the system. Installation and operations are covered in Chapter 13, where students learn about the conversion plan, change management plan, support plan, and project assessment. Additionally, these chapters address the issues related to developing systems in a fl at world, where developers and users are distributed throughout the world.

SUPPLEMENTS www.wiley.com/college/dennis

Instructor Book Companion Web s ite ■ PowerPoint slides : I nstructors can tailor the slides to their classroom needs .

S tudents can use them to guide their reading and studying activities. ■ Test Bank : I ncludes a variety of questions ranging from multiple-choice, true/

false, and short answer questions. A computerized, Respondus version of the Test Bank is also available.

■ Instructor’s Manual : P rovides resources to support the instructor both inside and out of the classroom. Th e manual includes short experiential exercises that instr uctors can use to help students experience and understand key topics in each chapter. Short stories have been provided by people working in both corpo- rate and consulting environments for instructors to insert into lectures to make concepts more colorful and real. Additional minicases for every chapter allow students to perform some of the key concepts that were learned in the chapter. Solutions to end of chapter questions and exercises are provided.

Student Book Companion Web s ite ■ A collection of templates and worksheets consisting of electronic versions of

selected fi gures from the book. ■ A completely new, expanded case study on an integrated health clinic delivery

system has been written to accompany the fi ft h edition. Th is case study is online only. It can be accessed at www.wiley.com/go/dennis/casestudy .

■ “Your Turn” and “Concepts in Action” boxes from the fourth edition have been moved online and can be accessed from the student companion site.

Wiley E-Text: Powered by VitalSource Th is Wiley e-text off ers students continuing access to materials for their course. Your students can access content on a mobile device, online from any Internet-connected computer, or by a computer via download. With dynamic features built into this e-text, students can search across content, highlight, and take notes that they can share with teachers and classmates.

Preface ix

Visible Analyst Wiley has partnered with Visible Analyst to give students a discounted price for Visible Analyst soft ware, an intuitive modeling tool for all aspects of traditional or object-oriented systems analysis and design. All new copies of the text will have a Key Code (printed on a page near the front of this text) that will provide a discount on Visible Analyst soft ware. To obtain the soft ware, students should visit http://store.visible.com/Wiley.aspx and enter their Key Code. Students who buy a new print text or digital e-book will receive one-third off the price of a downloadable edition of the soft ware with a 6-month license. With the soft ware, they will also receive tutorials, how-to videos, and a sample project. Students who buy used copies of this text may buy Visible Analyst at full price using the URL provided.

Project Management Soft ware You can download a 60-day trial of Microsoft Project Professional 2013 from the following Web site: www.microsoft .com/en-us/evalcenter/evaluate-project-professional-2013 . Note that Microsoft has changed its policy and no longer off ers the 120-day trial previously available.

Another option now available to education institutions adopting this Wiley titl e is a free introductory 3-year membership for DreamSpark Premium. DreamSpark Premium is designed to provide the easiest and most inexpensive way for academic departments to make the latest Microsoft soft ware available in labs, classrooms, and on student and instructor PCs. Microsoft Project soft ware is available through this Wiley and Microsoft publishing partnership, free of charge with the adoption of any qualifi ed Wiley title. Each copy of Microsoft Project is the full version of the soft ware, with no time limitation, and can be used indefi nitely for educational purposes. Contact your Wiley sales representative for details. For more information about the DreamSpark Premium program, contact drmspkna@Microsoft .com .

ACKNOWLEDGMENTS Th anks to Elaine Seeman for her feedback on every chapter in this book as well as for her work writing the new online case study. We would like to thank the following reviewers for their helpful and insightful comments on the fi ft h edition: Mohammad Dadashzadeh, Oakland University; Xiaodong Deng, Oakland University ; Th omas W. Dillon, James Madison University; Bryan Goda, University of Washington, Tacoma; Kathleen S. Hartzel, Duquesne University; Rajkumar Kempaiah, Stevens Institute of Technology; Sung-kwan Kim, University of Arkansas at Little Rock; Richard McCarthy, Quinnipiac University; Donald McCracken, Grantham University; Osama A. Morad, Southern New Hampshire University; Fred Niederman, Saint Louis University; Linda Plotnick, Jacksonville State University; Vladimir V. Riabov, Rivier University ; Richard Schilhavy, Guilford College; Tod Sedbrook, University of Northern Colorado; Steven C. Shaff er, Penn State University; Michael Smith, Georgia Institute of Technology; and John Wetsch, Southern New Hampshire University.

We would also like to thank the following reviewers for their helpful and insight- ful comments on the fi rst, second, third , and fourth editions: Evans Adams, Fort Lewis College; Murugan Anandarajon, Drexel University; Ron Anson, Boise State University; Noushin Ashrafi , University of Massachusetts, Boston; Dirk Baldwin, University of Wisconsin-Parkside; Robert Barker, University of Louisville; Qing Cao, University of Missouri–Kansas City; David Champion, DeVry University, Columbus, OH campus; Jeff Cummings, Indiana University; Junhua Ding, East Carolina University; Robert Dollinger,

x Preface

University of Wisconsin-Stevens Point; Abhijit Dutt, Carnegie Mellon University; Terry Fox, Baylor University; Ahmad Ghafarian, North Georgia College & State U niversity; Donald Golden, Cleve land State University; Cleotilde Gonzalez, Carnegie Melon University; Daniel V. Goulet, University of Wisconsin–Stevens Point; Harvey Hayashi, Loyalist College of Applied Arts and Technology; Yujong Hwang, DePaul University; Scott James, Saginaw Valley State University; Zongliang Jiang, North Carolina A&T State University; Raymond Kirsch, La Salle University; Rajiv Kishore, State University of New York–Buff alo; Ravindra Krovi, University of Akron; Jean-Piere Kuilboer, University of Massachusetts, Boston; Gilliean Lee, Lander University; Leo Legorreta, California State University Sacramento; Diane Lending, James Madison University; Steve Machon, DeVry University; Fernando Maymí , West Point University; Daniel Mittleman, DePaulUniversity; Makoto Nakayama, DePaul University; Fred Niederman, Saint Louis University; Parasuraman Nurani, DeVry University; H. Robert Pajkowski, DeVry Institute of Technology, Scarborough, Ontario; June S. Park, University of Iowa; Graham Peace, West Virginia University; Tom Pettay, DeVry Institute of Technology, Columbus,Ohio; Selwyn Piramuthu, University of Florida; J. Drew Procaccino, Rider University; Neil Ramiller, Portland State University; Eliot Rich, University at Albany, State University of New York; Marcus Rothenberger, University of Wisconsin–Milwaukee; Carl Scott, University of Houston; Keng Siau,University of Nebraska–Lincoln; Ift ikhar Sikder , Cleveland State University; Jonathan Trower, Baylor University; June Verner, Drexel University; Anna Wachholz, Sheridan College; Bill Watson, Indiana University- Purdue University Indianapolis; Randy S.Weinberg, Carnegie Mellon University; Eli J.Weissman, DeVry Institute of Technology, Long Island City, NY; Heinz Roland Weistroff er, Virginia Commonwealth University; Amy Wilson, DeVry Institute of Technology, Decatur, GA; Amy Woszczynski, Kennesaw State University; Vincent C. Yen, Wright State University ; Fan Zhao, Florida Gulf Coast University; and Dan Zhu, Iowa State University.

xi

C O N T E N T S

Preface v

Chapter 1

Introduction to Systems Analysis and Design 1 Introduction 1 The Systems Development Life Cycle 2

Planning 3 Analysis 3 Design 4 Implementation 4

Systems Development Methodologies 5 Structured Design 6 Rapid Application Development (RAD) 8 Agile Development 12 Selecting the Appropriate Development

Methodology 15 Typical Systems Analyst Roles and Skills 17

Business Analyst 18 Systems Analyst 18 Infrastructure Analyst 18 Change Management Analyst 19 Project Manager 19

Basic Characteristics of Object-Oriented Systems 19

Classes and Objects 19 Methods and Messages 20 Encapsulation and Information Hiding 20 Inheritance 21 Polymorphism and Dynamic Binding 22

Object-Oriented Systems Analysis and Design (OOSAD) 23

Use-Case Driven 24 Architecture-Centric 24 Iterative and Incremental 24 Benefi ts of Object-Oriented Systems

Analysis and Design 25 The Unified Process 25

Phases 26 Workfl ows 28 Extensions to the Unifi ed Process 30

The Unified Modeling Language 34 applying the concepts at patterson

superstore 36 Chapter Review 36

Chapter 2

Project Management 41 Introduction 41 Project Identification 43

System Request 44 Feasibility Analysis 45

Technical Feasibility 45 Economic Feasibility 46 Organizational Feasibility 51

Project Selection 53 Traditional Project Management Tools 54

Work Breakdown Structures 55 Gantt Chart 56 Network Diagram 57

Project Effort Estimation 58 Creating and Managing the Workplan 63

Evolutionary Work Breakdown Structures and Iterative Workplans 63

Managing Scope 67 Timeboxing 68 Refi ning Estimates 69 Managing Risk 70

Staffing the Project 71 Characteristics of a Jelled Team 71 Staffi ng Plan 73 Motivation 75 Handling Confl ict 76

Environment and Infrastructure Management 76

CASE Tools 77 Standards 77 Documentation 78

Applying the Concepts at Patterson Superstore 80

Chapter Review 80

■ PART ONE ANALYSIS MODELING 85 Chapter 3

Requirements Determination 86 Introduction 86 Requirements Determination 87

Defi ning a Requirement 87 Requirements Defi nition 89 Determining Requirements 89 Creating a Requirements Defi nition 91 Real-World Problems with Requirements

Determination 91 Requirements Analysis Strategies 92

Problem Analysis 92 Root Cause Analysis 92 Duration Analysis 93 Activity-Based Costing 94 Informal Benchmarking 94 Outcome Analysis 95 Technology Analysis 95 Activity Elimination 95

Requirements-Gathering Techniques 95 Interviews 96 Joint Application Development (JAD) 100 Questionnaires 104 Document Analysis 106 Observation 108 Selecting the Appropriate Techniques 108

Alternative Requirements Documentation Techniques 110

Concept Maps 110 User Stories 112

The System Proposal 113 Applying the Concepts at Patterson

Superstore 114 Chapter review 114

Chapter 4 Business Process and Functional Modeling 119 Introduction 119 Business Process Identification with Use

Cases and Use-Case Diagrams 121 Elements of Use-Case Diagrams 121 Identifying the Major Use Cases 126

Creating a Use-Case Diagram 127 Business Process Modeling with Activity

Diagrams 129 Elements of an Activity Diagram 131 Guidelines for Creating Activity

Diagrams 136 Creating Activity Diagrams 137

Business Process Documentation with Use Cases and Use-Case Descriptions 140

Types of Use Cases 141 Elements of a Use-Case Description 141 Guidelines for Creating Use-Case

Descriptions 145 Creating Use Case Descriptions 146

Verifying and Validating the Business Processes and Functional Models 153

Verifi cation and Validation through Walkthroughs 153

Functional Model Verifi cation and Validation 154

Applying the Concepts at Patterson Superstore 157

Chapter Review 157

Chapter 5

Structural Modeling 163 Introduction 163 Structural Models 164

Classes, Attributes, and Operations 164

Relationships 165 Object Identification 166

Textual Analysis 166 Brainstorming 167 Common Object Lists 169 Patterns 169

Crc Cards 172 Responsibilities and Collaborations 172 Elements of a CRC Card 173 Role-Playing CRC Cards with

Use Cases 174 Class Diagrams 176

Elements of a Class Diagram 176 Simplifying Class Diagrams 184 Object Diagrams 184

Creating Structural Models Using CRC Cards and Class Diagrams 185

Campus Housing Example 187 Library Example 187

xii Contents

Verifying and Validating the Structural Model 194

Applying the Concepts at Patterson Superstore 197

Chapter Review 198

Chapter 6

Behavioral Modeling 202 Introduction 202 Behavioral Models 203 Interaction Diagrams 204

Objects, Operations, and Messages 204 Sequence Diagrams 204 Communication Diagrams 216

Behavioral State Machines 221 States, Events, Transitions, Actions, and

Activities 221 Elements of a Behavioral State Machine 222 Creating a Behavioral State Machine 226

Crude Analysis 229 Verifying and Validating the Behavioral

Model 233 Applying the Concepts at Patterson

Superstore 235 Chapter Review 235

■ PART TWO DESIGN MODELING 239 Chapter 7

Moving on to Design 240 Introduction 240 Verifying and Validating the Analysis

Models 242 Balancing Functional and Structural

Models 242 Balancing Functional and Behavioral

Models 243 Balancing Structural and Behavioral

Models 251 Summary 254

Evolving the Analysis Models into Design Models 257

Factoring 257 Partitions and Collaborations 258 Layers 259

Packages and Package Diagrams 262 Guidelines for Creating Package

Diagrams 264 Creating Package Diagrams 266 Verifying and Validating Package

Diagrams 266 Design Strategies 268

Custom Development 268 Packaged Soft ware 269 Outsourcing 270 Selecting a Design Strategy 272

Selecting an Acquisition Strategy 273 Alternative Matrix 274

Applying the Concepts at Patterson Superstore 276

Chapter Review 276

Chapter 8

Class and Method Design 280 Introduction 280 Review of the Basic Characteristics

of Object Orientation 282 Classes, Objects, Methods, and Messages 282 Encapsulation and Information Hiding 282 Polymorphism and Dynamic Binding 282 Inheritance 284

Design Criteria 286 Coupling 286 Cohesion 289 Connascence 292

Object Design Activities 293 Adding Specifi cations 293 Identifying Opportunities for Reuse 294 Restructuring the Design 297 Optimizing the Design 298 Mapping Problem-Domain Classes to

Implementation Languages 300 Constraints and Contracts 304

Types of Constraints 306 Elements of a Contract 306

Method Specification 314 General Information 314 Events 314 Message Passing 315 Algorithm Specifi cations 316 Example 318

Verifying and Validating Class and Method Design 319

Contents xiii

Applying the Concepts at Patterson Superstore 322

Chapter review 322

Chapter 9

Data Management Layer Design 326 Introduction 326 Object Persistence Formats 327

Sequential and Random Access Files 327 Relational Databases 330 Object-Relational Databases 332 Object-Oriented Databases 332 NoSQL Data Stores 333 Selecting an Object Persistence Format 335

Mapping Problem Domain Objects to Object Persistence Formats 337

Mapping Problem Domain Objects to an OODBMS Format 338

Mapping Problem Domain Objects to an ORDBMS Format 341

Mapping Problem Domain Objects to a RDBMS Format 344

Optimizing Rdbms-Based Object Storage 346

Optimizing Storage Effi ciency 347 Optimizing Data Access Speed 351 Estimating Data Storage Size 356

Designing Data Access and Manipulation Classes 357

Nonfunctional Requirements and Data Management Layer Design 360

Verifying and Validating the Data Management Layer 361

Applying the Concepts at Patterson Superstore 362

Chapter Review 362

Chapter 10

Human–Computer Interaction Layer Design 367 Iintroduction 367 Principles for User Interface Design 368

Layout 369 Content Awareness 369

Aesthetics 370 User Experience 371 Consistency 371 Minimizing User Eff ort 372

User Interface Design Process 372 Use Scenario Development 373 Navigation Structure Design 375 Interface Standards Design 376 Interface Design Prototyping 377 Interface Evaluation 380 Common Sense Approach to User

Interface Design 382 Navigation Design 383

Basic Principles 383 Types of Navigation Controls 384 Messages 386 Navigation Design Documentation 387

Input Design 387 Basic Principles 387 Types of Inputs 390 Input Validation 391

Output Design 392 Basic Principles 392 Types of Outputs 394 Media 394

Mobile Computing and User Interface Design 395

Social Media and User Interface Design 398

Games, Multi-Dimensional Information Visualizations, and Immersive Environments 400

Games, Gamifi cation, and User Interface Design 400

Multidimensional Information Visualization Design 402

User Interface Design and Immersive Environments 404

International and Cultural Issues and User Interface Design 406

Multilingual Requirements 406 Color 407 Cultural Diff erences 407

Nonfunctional Requirements And Human- Computer Interaction Layer Design 410

Applying The Concepts At Patterson Superstore 411

Chapter review 411

xiv Contents

Chapter 11

Physical Architecture Layer Design 418 Introduction 418 Elements of the Physical Architecture

Layer 419 Architectural Components 419 Server-Based Architectures 420 Client-Based Architectures 420 Client–Server Architectures 421 Client–Server Tiers 422 Selecting a Physical Architecture 424

Cloud Computing 426 Ubiquitous Computing and the Internet

of Things 428 Green IT 431 Infrastructure Design 432

Deployment Diagram 432 Network Model 434

Hardware and System Software Specifications 438

Nonfunctional Requirements and Physical Architecture Layer Design 440

Operational Requirements 441 Performance Requirements 442 Security Requirements 444 Cultural and Political Requirements 447 Synopsis 448

Verifying and Validating the Physical Architecture Layer 449

Applying the Concepts at Patterson Superstore 450

Chapter Review 450

■ PART THREE CONSTRUCTION, INSTALLATION, AND OPERATIONS 455 Chapter 12

Construction 456 Introduction 456 Managing Programming 457

Assigning Programmers 457 Coordinating Activities 458

Managing the Schedule 458 Cultural Issues 460

Developing Documentation 462 Types of Documentation 463 Designing Documentation Structure 463 Writing Documentation Topics 465 Identifying Navigation Terms 465

Designing Tests 467 Testing and Object Orientation 468 Test Planning 469 Unit Tests 471 Integration Tests 475 System Tests 476 Acceptance Tests 477

Applying the Concepts at Patterson Superstore 478

Chapter Review 478

Chapter 13

Installation and Operations 481 Introduction 481 Cultural Issues and Information

Technology Adoption 483 Conversion 485

Conversion Style 486 Conversion Location 486 Conversion Modules 487 Selecting the Appropriate Conversion

Strategy 488 Change Management 489

Understanding Resistance to Change 490 Revising Management Policies 491 Assessing Costs and Benefi ts 492 Motivating Adoption 493 Enabling Adoption: Training 495

Post-Implementation Activities 497 System Support 497 System Maintenance 498 Project Assessment 500

Applying the Concepts at Patterson Superstore 502

Chapter Review 502

Index 507

Contents xv

Chapter 1 introduces the systems development life cycle (SDLC), the fundamental four- phase model (planning, analysis, design, and implementation) common to all information systems development projects. It describes the evolution of system development method- ologies and discusses the roles and skills required of a systems analyst. Th e chapter then overviews the basic characteristics of object-oriented systems and the fundamentals of object-oriented systems analysis and design and closes with a description of the Unifi ed Process and its extensions and the Unifi ed Modeling Language.

OBJECTIVES

■ Understand the fundamental systems development life cycle and its four phases ■ Understand the evolution of systems development methodologies ■ Be familiar with the diff erent roles played by and the skills of a systems analyst ■ Be familiar with the basic characteristics of object-oriented systems ■ Be familiar with the fundamental principles of object-oriented systems analysis

and design ■ Be familiar with the Unifi ed Process, its extensions, and the Unifi ed Modeling

Language

INTRODUCTION The systems development life cycle (SDLC) is the process of understanding how an infor- mation system (IS) can support business needs by designing a system, building it, and delivering it to users. If you have taken a programming class or have programmed on your own, this probably sounds pretty simple. Unfortunately, it is not. A 1996 survey by the Standish Group found that 42 percent of all corporate IS projects were abandoned before completion. A similar study conducted in 1996 by the General Accounting Office found 53 percent of all U.S. government IS projects were abandoned. Unfortunately, many of the systems that are not abandoned are delivered to the users significantly late, cost far more than planned, and have fewer features than originally planned. For exam- ple, IAG Consulting reports that 80 percent of the projects were over time, 72 percent were over budget, and 55 percent contained less than the full functionality; Panorama Consulting Solutions reports that 54 percent of the ERP projects were over time, 56 percent were over budget, and 48 percent delivered less than 50 percent of the initial benefi ts; and  an IBM study reports that 59 percent of the projects missed one or more of on time, within budget, and quality constraints.1 Although we would like to promote this book as a silver bullet that will keep you from IS failures, we readily admit that a silver bullet that guarantees IS development success simply does not exist. Instead, this book provides you

1

C H A P T E R 1

Introduction to Systems Analysis and Design

2 C h a p t e r 1   Introduction to Systems Analysis and Design

with several fundamental concepts and many practical techniques that you can use to improve the probability of success.

Th e key person in the SDLC is the systems analyst, who analyzes the business situation, identifi es opportunities for improvements, and designs an information system to implement them. Being a systems analyst is one of the most interesting, exciting, and challenging jobs around. Systems analysts work with a variety of people and learn how they conduct business. Specifi cally, they work with a team of systems analysts, programmers, and others on a com- mon mission. Systems analysts feel the satisfaction of seeing systems that they designed and developed make a signifi cant business impact, knowing that they contributed unique skills to make that happen.

However, the primary objective of a systems analyst is not to create a wonderful sys- tem; instead, it is to create value for the organization, which for most companies means increasing profi ts (government agencies and not-for-profi t organizations measure value diff erently). Many failed systems have been abandoned because the analysts tried to build a wonderful system without clearly understanding how the system would fi t with an organi- zation’s goals, current business processes, and other information systems to provide value. An investment in an information system is like any other investment. Th e goal is not to acquire the tool, because the tool is simply a means to an end; the goal is to enable the organization to perform work better so that it can earn greater profi ts or serve its constit- uents more eff ectively.

Th is book introduces the fundamental skills a systems analyst needs. Th is pragmatic book discusses best practices in systems development; it does not present a general survey of systems development that covers everything about the topic. By defi nition, systems analysts do things and challenge the current way that organizations work. To get the most out of this book, you will need to actively apply to your own systems development project the ideas and concepts in the examples. Th is book guides you through all the steps for delivering a successful informa- tion system. By the time you fi nish the book, you won’t be an expert analyst, but you will be ready to start building systems for real.

THE SYSTEMS DEVELOPMENT LIFE CYCLE In many ways, building an information system is similar to building a house. First, the house (or the information system) starts with a basic idea. Second, this idea is transformed into a simple drawing that is shown to the customer and refi ned (oft en through several drawings, each improving on the last) until the customer agrees that the picture depicts what he or she wants. Th ird, a set of blueprints is designed that presents much more detailed information about the house (e.g., the type of water faucets or where the telephone jacks will be placed). Finally, the house is built following the blueprints, oft en with some changes directed by the customer as the house is erected.

Th e SDLC has a similar set of four fundamental phases: planning, analysis, design, and implementation. Diff erent projects might emphasize diff erent parts of the SDLC or approach the SDLC phases in diff erent ways, but all projects have elements of these four phases. Each phase is itself composed of a series of steps, which rely upon techniques that produce deliverables (specifi c documents and fi les that provide understanding about the project).

1 For more information on the problem, see Capers Jones, Patterns of Soft ware System Failure and Success (London: International Th ompson Computer Press, 1996); KeithEllis, Business Analysis Benchmark: Th e Impact of Business Requirements on the Success of Technology Projects (2008). Retrieved May 2014 from IAG Consulting, www.iag.biz; H. H. Jorgensen, L. Owen, and A. Neus, Making Change Work (2008). Retrieved May 2014 from IBM, www.ibm. com; Panorama Consulting Solutions, 2012 ERP Report (2012). Retrieved May 2014 from Panorama- Consulting.com.

The Systems Development Life Cycle  3

For example, in applying for admission to a university, all students go through the same phases: information gathering, applying, and accepting. Each of these phases has steps; for example, information gathering includes steps such as searching for schools, requesting infor- mation, and reading brochures. Students then use techniques (e.g., Internet searching) that can be applied to steps (e.g., requesting information) to create deliverables (e.g., evaluations of diff erent aspects of universities).

In many projects, the SDLC phases and steps proceed in a logical path from start to fi n- ish. In other projects, the project teams move through the steps consecutively, incrementally, iteratively, or in other patterns. In this section, we describe the phases, the actions, and some of the techniques that are used to accomplish the steps at a very high level.

For now, there are two important points to understand about the SDLC. First, you should get a general sense of the phases and steps through which IS projects move and some of the techniques that produce certain deliverables. Second, it is important to understand that the SDLC is a process of gradual refi nement. Th e deliverables produced in the analysis phase pro- vide a general idea of the shape of the new system. Th ese deliverables are used as input to the design phase, which then refi nes them to produce a set of deliverables that describes in much more detailed terms exactly how the system will be built. Th ese deliverables, in turn, are used in the implementation phase to produce the actual system. Each phase refi nes and elaborates on the work done previously.

Planning Th e planning phase is the fundamental process of understanding why an information sys- tem should be built and determining how the project team will go about building it. It has two steps:

1. During project initiation, the system’s business value to the organization is identifi ed: How will it lower costs or increase revenues? Most ideas for new systems come from outside the IS area (e.g., from the marketing department, accounting department) in the form of a system request. A system request presents a brief summary of a business need, and it explains how a system that supports the need will create business value. Th e IS department works together with the person or department that generated the request (called the project sponsor) to conduct a feasibility analysis.

Th e system request and feasibility analysis are presented to an information sys- tems approval committee (sometimes called a steering committee), which decides whether the project should be undertaken.

2. Once the project is approved, it enters project management. During project man- agement, the project manager creates a workplan, staff s the project, and puts tech- niques in place to help the project team control and direct the project through the entire SDLC. Th e deliverable for project management is a project plan, which describes how the project team will go about developing the system.

Analysis Th e analysis phase answers the questions of who will use the system, what the system will do, and where and when it will be used. During this phase, the project team investigates any current system(s), identifi es opportunities for improvement, and develops a concept for the new system. Th is phase has three steps:

1. An analysis strategy is developed to guide the project team’s eff orts. Such a strategy usually includes an analysis of the current system (called the as-is system) and its problems and then ways to design a new system (called the to-be system).

4 C h a p t e r 1   Introduction to Systems Analysis and Design

2. Th e next step is requirements gathering (e.g., through interviews or questionnaires). Th e analysis of this information—in conjunction with input from the project sponsor and many other people—leads to the development of a concept for a new system. Th e system concept is then used as a basis to develop a set of business analysis models, which describe how the business will operate if the new system is developed.

3. Th e analyses, system concept, and models are combined into a document called the system proposal, which is presented to the project sponsor and other key deci- sion makers (e.g., members of the approval committee) who decide whether the project should continue to move forward.

Th e system proposal is the initial deliverable that describes what business requirements the new system should meet. Because it is really the fi rst step in the design of the new system, some experts argue that it is inappropriate to use the term “analysis” as the name for this phase; some argue a better name would be “analysis and initial design.” Most organizations continue to use the name analysis for this phase, however, so we use it in this book as well. Just keep in mind that the deliverable from the analysis phase is both an analysis and a high-level initial design for the new system.

Design Th e design phase decides how the system will operate, in terms of the hardware, soft ware, and network infrastructure; the user interface, forms, and reports; and the specifi c programs, databases, and fi les that will be needed. Although most of the strategic decisions about the system were made in the development of the system concept during the analysis phase, the steps in the design phase determine exactly how the system will operate. Th e design phase has four steps:

1. Th e design strategy is fi rst developed. It clarifi es whether the system will be devel- oped by the company’s own programmers, whether the system will be outsourced to another fi rm (usually a consulting fi rm), or whether the company will buy an existing soft ware package.

2. Th is leads to the development of the basic architecture design for the system, which describes the hardware, soft ware, and network infrastructure to be used. In most cases, the system will add or change the infrastructure that already exists in the organization. Th e interface design specifi es how the users will move through the sys- tem (e.g., navigation methods such as menus and on-screen buttons) and the forms and reports that the system will use.

3. Th e database and fi le specifi cations are developed. Th ese defi ne exactly what data will be stored and where they will be stored.

4. Th e analyst team develops the program design, which defi nes the programs that need to be written and exactly what each program will do.

Th is collection of deliverables (architecture design, interface design, database and fi le specifi ca- tions, and program design) is the system specifi cation that is handed to the programming team for implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another decision is made by the project sponsor and approval committee about whether to terminate the project or continue.

Implementation Th e fi nal phase in the SDLC is the implementation phase, during which the system is actually built (or purchased, in the case of a packaged soft ware design). Th is is the phase that usually

Systems Development Methodologies  5

2 Th e classic modern process-centered methodology is that by Edward Yourdon, Modern Structured Analysis (Englewood Cliff s, NJ: Yourdon Press, 1989). An example of a data-centered methodology is information engi- neering; see James Martin, Information Engineering, vols. 1–3 (Englewood Cliff s, NJ: Prentice Hall, 1989). A widely accepted standardized non–object-oriented methodology that balances processes and data is IDEF; see FIPS 183, Integration Defi nition for Function Modeling, Federal Information Processing Standards Publications, U.S. Depart- ment of Commerce, 1993. 3 A good reference for comparing systems development methodologies is Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996).

gets the most attention, because for most systems it is the longest and most expensive single part of the development process. Th is phase has three steps:

1. System construction is the fi rst step. Th e system is built and tested to ensure that it performs as designed. Because the cost of bugs can be immense, testing is one of the most critical steps in implementation. Most organizations give more time and attention to testing than to writing the programs in the fi rst place.

2. Th e system is installed. Installation is the process by which the old system is turned off and the new one is turned on. One of the most important aspects of conversion is the development of a training plan to teach users how to use the new system and help manage the changes caused by the new system.

3. Th e analyst team establishes a support plan for the system. Th is plan usually includes a formal or informal post-implementation review as well as a systematic way for identifying major and minor changes needed for the system.

SYSTEMS DEVELOPMENT METHODOLOGIES A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of steps and deliverables). Th ere are many diff erent systems development methodologies, and each one is unique, based on the order and focus it places on each SDLC phase. Some methodolo- gies are formal standards used by government agencies, whereas others have been developed by consulting fi rms to sell to clients. Many organizations have internal methodologies that have been honed over the years, and they explain exactly how each phase of the SDLC is to be performed in that company.

Th ere are many ways to categorize methodologies. One way is by looking at whether they focus on business processes or the data that support the business. A process-centered methodology emphasizes process models as the core of the system concept. In Figure 1-1, for example, process-centered methodologies would focus fi rst on defi ning the processes (e.g., assemble sandwich ingredients). Data-centered methodologies emphasize data models as the core of the system concept. In Figure 1-1, data-centered methodologies would focus fi rst on defi ning the contents of the storage areas (e.g., refrigerator) and how the contents were organ- ized.2 By contrast, object-oriented methodologies attempt to balance the focus between process and data by incorporating both into one model. In Figure 1-1, these methodologies would focus fi rst on defi ning the major elements of the system (e.g., sandwiches, lunches) and look at the processes and data involved with each element.

Another important factor in categorizing methodologies is the sequencing of the SDLC phases and the amount of time and eff ort devoted to each.3 In the early days of computing, programmers did not understand the need for formal and well-planned life-cycle meth- odologies. Th ey tended to move directly from a very simple planning phase right into the construction step of the implementation phase—in other words, from a very fuzzy, not-well- thought-out system request into writing code. Th is is the same approach that you sometimes use when writing programs for a programming class. It can work for small programs that

6 C h a p t e r 1   Introduction to Systems Analysis and Design

require only one programmer, but if the requirements are complex or unclear, you might miss important aspects of the problem and have to start all over again, throwing away part of the program (and the time and eff ort spent writing it). Th is approach also makes teamwork diffi cult because members have little idea about what needs to be accomplished and how to work together to produce a fi nal product. In this section, we describe three diff erent classes of system development methodologies: structured design, rapid application development, and agile development.

Structured Design Th e fi rst category of systems development methodologies is called structured design. Th ese methodologies became dominant in the 1980s, replacing the previous ad hoc and

FIGURE 1-1    A Simple Behavioral Model for Making a Simple Lunch

GetJelly

GetPeanutButter

GetCookies

GetBread

CreateSandwich

GetMilk

CreateLunch

GetLunchBag

PutLunchInBag

aParent aRefrigerator aCupboard aSandwich aLunch aLunchBag

Systems Development Methodologies  7

undisciplined approach. Structured design methodologies adopt a formal step-by-step approach to the SDLC that moves logically from one phase to the next. Numerous pro- cess-centered and data-centered methodologies follow the basic approach of the two struc- tured design categories outlined next.

Waterfall Development Th e original structured design methodology (still used today) is waterfall development. With waterfall development-based methodologies, the analysts and users proceed in sequence from one phase to the next (see Figure 1-2). Th e key deliverables for each phase are typically very long (oft en hundreds of pages in length) and are presented to the project sponsor for approval as the project moves from phase to phase. Once the sponsor approves the work that was conducted for a phase, the phase ends and the next one begins. Th is methodology is referred to as waterfall development because it moves forward from phase to phase in the same manner as a waterfall. Although it is possible to go backward in the SDLC (e.g., from design back to analysis), it is extremely diffi cult (imagine yourself as a salmon trying to swim upstream against a waterfall, as shown in Figure 1-2).

Structured design also introduced the use of formal modeling or diagramming tech- niques to describe the basic business processes and the data that support them. Traditional structured design uses one set of diagrams to represent the processes and a separate set of diagrams to represent data. Because two sets of diagrams are used, the systems analyst must decide which set to develop fi rst and use as the core of the system: process-model diagrams or data-model diagrams.

Th e two key advantages of the structured design waterfall approach are that it identi- fi es system requirements long before programming begins and it minimizes changes to the requirements as the project proceeds. Th e two key disadvantages are that the design must be completely specifi ed before programming begins and that a long time elapses between the completion of the system proposal in the analysis phase and the delivery of the system (usu- ally many months or years). If the project team misses important requirements, expensive post-implementation programming may be needed (imagine yourself trying to design a car on paper; how likely would you be to remember interior lights that come on when the doors open or to specify the right number of valves on the engine?). A system can also require signifi cant rework because the business environment has changed from the time when the analysis phase occurred.

FIGURE 1-2 A Waterfall Development-Based Methodology

System

Planning

Analysis

Design

Implementation

8 C h a p t e r 1   Introduction to Systems Analysis and Design

Parallel Development Parallel development methodology attempts to address the problem of long delays between the analysis phase and the delivery of the system. Instead of doing design and implementation in sequence, it performs a general design for the whole system and then divides the project into a series of distinct subprojects that can be designed and implemented in parallel. Once all subprojects are complete, the separate pieces are integrated and the system is delivered (see Figure 1-3).

Th e primary advantage of this methodology is that it can reduce the time to deliver a system; thus, there is less chance of changes in the business environment causing rework. However, sometimes the subprojects are not completely independent; design decisions made in one subproject can aff ect another, and the end of the project can require signifi cant integration eff orts.

Rapid Application Development (RAD) A second category of methodologies includes rapid application development (RAD)-based methodologies. Th ese are a newer class of systems development methodologies that emerged in the 1990s. RAD-based methodologies attempt to address both weaknesses of structured design methodologies by adjusting the SDLC phases to get some part of the system devel- oped quickly and into the hands of the users. In this way, the users can better understand the system and suggest revisions that bring the system closer to what is needed.4

4 One of the best RAD books is Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996).

FIGURE 1-3    A Parallel Development-Based Methodology

System

Planning

Analysis

Design

Implementation

Design

Integration

Implementation

Design

Implementation

Design

Subproject 2

Subproject 1

Subproject 3

Systems Development Methodologies  9

Most RAD-based methodologies recommend that analysts use special techniques and  computer tools to speed up the analysis, design, and implementation phases, such as computer-aided soft ware engineering (CASE) tools, joint application design (JAD) sessions, fourth-generation or visual programming languages that simplify and speed up programming, and code generators that automatically produce programs from design specifi cations. Th e combination of the changed SDLC phases and the use of these tools and techniques improves the speed and quality of systems development. However, there is one possible subtle problem with RAD-based methodologies: managing user expectations. Owing to the use of the tools and techniques that can improve the speed and quality of systems development, user expectations of what is possible can change dramatically. As a user better understands the information tech- nology (IT), the systems requirements tend to expand. Th is was less of a problem when using methodologies that spent a lot of time thoroughly documenting requirements.

Phased Development A phased development-based methodology breaks an overall system into a series of versions that are developed sequentially. Th e analysis phase identifi es the overall system concept, and the project team, users, and system sponsor then categorize the requirements into a series of versions. Th e most important and fundamental requirements are bundled into the fi rst version of the system. Th e analysis phase then leads into design and implementation—but only with the set of requirements identifi ed for version 1 (see Figure 1-4).

Once version 1 is implemented, work begins on version 2. Additional analysis is per- formed based on the previously identifi ed requirements and combined with new ideas and issues that arose from the users’ experience with version 1. Version 2 then is designed and implemented, and work immediately begins on the next version. Th is process continues until the system is complete or is no longer in use.

Phased development-based methodologies have the advantage of quickly getting a useful system into the hands of the users. Although the system does not perform all the functions the users need at fi rst, it does begin to provide business value sooner than if the system were deliv- ered aft er completion, as is the case with the waterfall and parallel methodologies. Likewise, because users begin to work with the system sooner, they are more likely to identify important additional requirements sooner than with structured design situations.

Th e major drawback to phased development is that users begin to work with systems that are intentionally incomplete. It is critical to identify the most important and useful features and include them in the fi rst version and to manage users’ expectations along the way.

Prototyping A prototyping-based methodology performs the analysis, design, and imple- mentation phases concurrently, and all three phases are performed repeatedly in a cycle until the system is completed. With these methodologies, the basics of analysis and design are performed, and work immediately begins on a system prototype, a quick-and-dirty program that provides a minimal amount of features. Th e fi rst prototype is usually the fi rst part of the system that is used. Th is is shown to the users and the project sponsor, who provide com- ments. Th ese comments are used to reanalyze, redesign, and reimplement a second prototype, which provides a few more features. Th is process continues in a cycle until the analysts, users, and sponsor agree that the prototype provides enough functionality to be installed and used in the organization. Aft er the prototype (now called the “system”) is installed, refi nement occurs until it is accepted as the new system (see Figure 1-5).

Th e key advantage of a prototyping-based methodology is that it very quickly provides a system with which the users can interact, even if it is not ready for widespread organizational use at fi rst. Prototyping reassures the users that the project team is working on the system (there are no long delays in which the users see little progress), and prototyping helps to more quickly refi ne real requirements.

1 0 C h a p t e r 1   Introduction to Systems Analysis and Design

FIGURE 1-4    A Phased Development-Based Methodology

System version 1

Planning

Analysis

Analysis

Implementation

Design

Analysis

Implementation

Design

Analysis

Implementation

Design

System version 2

System version 3

FIGURE 1-5 A Prototyping-Based Methodology

System prototype

System

Planning

Analysis

Design

Implementation

Implementation

Systems Development Methodologies  11

Th e major problem with prototyping is that its fast-paced system releases challenge attempts to conduct careful, methodical analysis. Oft en the prototype undergoes such signif- icant changes that many initial design decisions become poor ones. Th is can cause problems in the development of complex systems because fundamental issues and problems are not rec- ognized until well into the development process. Imagine building a car and discovering late in the prototyping process that you have to take the whole engine out to change the oil (because no one thought about the need to change the oil until aft er it had been driven 10,000 miles).

Throwaway Prototyping Th rowaway prototyping-based methodologies are similar to prototyping-based methodologies in that they include the development of prototypes; how- ever, throwaway prototypes are done at a diff erent point in the SDLC. Th ese prototypes are used for a very diff erent purpose than those previously discussed, and they have a very diff er- ent appearance (see Figure 1-6).

Th e throwaway prototyping-based methodologies have a relatively thorough analy- sis phase that is used to gather information and to develop ideas for the system concept. However, users might not completely understand many of the features they suggest, and there may be challenging technical issues to be solved. Each of these issues is examined by analyz- ing, designing, and building a design prototype. A design prototype is not a working system; it is a product that represents a part of the system that needs additional refi nement, and it contains only enough detail to enable users to understand the issues under consideration. For example, suppose users are not completely clear on how an order-entry system should work. In this case, a series of mock-up screens appear to be a system, but they really do nothing. Or suppose that the project team needs to develop a sophisticated graphics program in Java. Th e team could write a portion of the program with pretend data to ensure that they could do a full-blown program successfully.

A system developed using this type of methodology relies on several design prototypes during the analysis and design phases. Each of the prototypes is used to minimize the risk associated with the system by confi rming that important issues are understood before the real system is built. Once the issues are resolved, the project moves into design and implementa- tion. At this point, the design prototypes are thrown away, which is an important diff erence between these methodologies and prototyping methodologies, in which the prototypes evolve into the fi nal system.

FIGURE 1-6    A Throwaway Prototyping-Based Methodology

Design prototype

System

Analysis

Analysis

Design

Implementation

Planning

Implementation

Design

1 2 C h a p t e r 1   Introduction to Systems Analysis and Design

Th rowaway prototyping-based methodologies balance the benefi ts of well-thought-out analysis and design phases with the advantages of using prototypes to refi ne key issues before a system is built. It can take longer to deliver the fi nal system as compared to prototyping- based methodologies, but this type of methodology usually produces more stable and reliable systems.

Agile Development5 A third category of systems development methodologies is still emerging today: agile devel- opment. All agile development methodologies are based on the agile manifesto and a set of twelve principles. Th e emphasis of the manifesto is to focus the developers on the working conditions of the developers, the working soft ware, the customers, and addressing changing requirements instead of focusing on detailed systems development processes, tools, all- inclusive documentation, legal contracts, and detailed plans. Th ese programming-centric methodologies have few rules and practices, all of which are fairly easy to follow. Th ese meth- odologies are typically based only on the twelve principles of agile soft ware. Th ese principles include the following:

■ Soft ware is delivered early and continuously through the development process, satis- fying the customer.

■ Changing requirements are embraced regardless of when they occur in the develop- ment process.

■ Working soft ware is delivered frequently to the customer. ■ Customers and developers work together to solve the business problem. ■ Motivated individuals create solutions; provide them the tools and environment they

need, and trust them to deliver. ■ Face-to-face communication within the development team is the most effi cient and

eff ective method of gathering requirements. ■ Th e primary measure of progress is working, executing soft ware. ■ Both customers and developers should work at a pace that is sustainable. Th at is, the

level of work could be maintained indefi nitely without any worker burnout. ■ Agility is heightened through attention to both technical excellence and good design. ■ Simplicity, the avoidance of unnecessary work, is essential. ■ Self-organizing teams develop the best architectures, requirements, and designs. ■ Development teams regularly refl ect on how to improve their development

processes. Based on these principles, agile methodologies focus on streamlining the system-development process by eliminating much of the modeling and documentation overhead and the time spent on those tasks. Instead, projects emphasize simple, iterative application development.6 All agile development methodologies follow a simple cycle through the traditional phases of the systems development process (see Figure 1-7). Virtually all agile methodologies are used in conjunction with object-oriented technologies.

5 Th ree good sources of information on agile development and object-oriented systems are S. W. Ambler, Agile Modeling: Eff ective Practices for Extreme Programming and the Unifi ed Process (New York: Wiley, 2002); C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison-Wesley, 2004); R. C. Martin, Agile Soft ware Development: Principles, Patterns, and Practices (Upper Saddle River, NJ: Prentice Hall, 2003). 6 See Agile Alliance, www.agilealliance.com.

Systems Development Methodologies  13

However, agile methodologies do have critics. One of the major criticisms deals with today’s business environment, where much of the actual information systems development is off shored, outsourced, and/or subcontracted. Given agile development methodologies requiring co-location of the development team, this seems to be a very unrealistic assump- tion. A second major criticism is that if agile development is not carefully managed, and by defi nition it is not, the development process can devolve into a prototyping approach that essentially becomes a “programmers gone wild” environment where programmers attempt to hack together solutions. A third major criticism, based on the lack of actual documen- tation created during the development of the soft ware, raises issues regarding the auditability of the systems being created. Without suffi cient documentation, neither the system nor the systems-development process can be assured. A fourth major criticism is based on whether agile approaches can deliver large mission-critical systems.

Even with these criticisms, given the potential for agile approaches to address the application backlog and to provide timely solutions to many business problems, agile approaches should be considered in some circumstances. Furthermore, many of the tech- niques encouraged by attending to the underlying purpose of the agile manifesto and the set of twelve agile principles are very useful in object-oriented systems development. Two of the more popular examples of agile development methodologies are extreme programming (XP) and Scrum.

Extreme Programming7 Extreme programming (XP) is founded on four core values: com- munication, simplicity, feedback, and courage. Th ese four values provide a foundation that XP developers use to create any system. First, the developers must provide rapid feedback to the end users on a continuous basis. Second, XP requires developers to follow the KISS principle.8 Th ird, developers must make incremental changes to grow the system, and they must not only accept change, they must embrace change. Fourth, developers must have a quality-fi rst mentality. XP also supports team members in developing their own skills. Th ree of the key principles that XP uses to create successful systems are continuous testing, simple coding performed by pairs of developers, and close interactions with end users to build sys- tems very quickly.

7 For more information, see K. Beck, eXtreme Programming Explained: Embrace Change (Reading, MA: Addison- Wesley, 2000); C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison-Wesley, 2004); M. Lippert, S. Roock, and H. Wolf, eXtreme Programming in Action: Practical Experiences from Real World Projects (New York: Wiley, 2002); www.extremeprogramming.org. 8 Keep it simple, stupid.

FIGURE 1-7 Typical Agile Development Methodology

Implementation

Design

Analysis

System

Planning

1 4 C h a p t e r 1   Introduction to Systems Analysis and Design

Testing and effi cient coding practices are the core of XP. Code is tested each day and is placed into an integrative testing environment. If bugs exist, the code is backed out until it is completely free of errors.

An XP project begins with user stories that describe what the system needs to do. Th en, programmers code in small, simple modules and test to meet those needs. Users are required to be available to clear up questions and issues as they arise. Standards are very important to minimize confusion, so XP teams use a common set of names, descriptions, and coding practices. XP projects deliver results sooner than even the RAD approaches, and they rarely get bogged down in gathering requirements for the system.

XP adherents claim many strengths associated with developing soft ware using XP. Programmers work closely with all stakeholders, and communication among all stakehold- ers is improved. Continuous testing of the evolving system is encouraged. Th e system is developed in an evolutionary and incremental manner, which allows the requirements to evolve as the stakeholders understand the potential that the technology has in providing a solution to their problem. Estimation is task driven and is performed by the programmer who will implement the solution for the task under consideration. Because all programming is done in pairs, a shared responsibility for each soft ware component develops among the programmers. Finally, the quality of the fi nal product increases during each iteration.

For small projects with highly motivated, cohesive, stable, and experienced teams, XP should work just fi ne. However, if the project is not small or the teams aren’t jelled,9 the suc- cess of an XP development eff ort is doubtful. Th is tends to throw into doubt the whole idea of bringing outside contractors into an existing team environment using XP.10 Th e chance of outsiders jelling with insiders might simply be too optimistic. XP requires a great deal of discipline, otherwise projects will become unfocused and chaotic. XP is recommended only for small groups of developers—no more than ten developers—and it is not advised for large mission-critical applications. Owing to the lack of analysis and design documentation, there is only code documentation associated with XP, so maintaining large systems built with XP may be impossible. And because mission-critical business information systems tend to exist for a long time, the utility of XP as a business information system development methodology is in doubt. Finally, the methodology needs a lot of on-site user input, something to which many business units cannot commit.11 However, some of the techniques associated with XP are useful in object-oriented systems development. For example, user stories, pair pro- gramming, and continuous testing are invaluable tools from which object-oriented systems development could benefi t.

Scrum12 Scrum is a term that is well known to rugby fans. In rugby, a scrum is used to restart a game. In a nutshell, the creators of the Scrum method believe that no matter how much you plan, as soon as the soft ware begins to be developed, chaos breaks out and the

9 A jelled team is one that has low turnover, a strong sense of identity, a sense of eliteness, a feeling that they jointly own the product being developed, and enjoyment in working together. For more information regarding jelled teams, see T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams (New York: Dorset/House, 1987). 10 Considering the tendency for off shore outsourcing, this is a major obstacle for XP to overcome. For more infor- mation on off shore outsourcing, see P. Th ibodeau, “ITAA Panel Debates Outsourcing Pros, Cons,” Computerworld Morning Update (September 25, 2003); S. W. Ambler, “Chicken Little Was Right,” Soft ware Development (October 2003). 11 Many of the observations on the utility of XP as a development approach were based on conversations with Brian Henderson-Sellers. 12 For more information, see C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison- Wesley, 2004); K. Schwaber and M. Beedle, Agile Soft ware Development with Scrum (Upper Saddle River, NJ: Prentice Hall, 2001); R. Wysocki, Eff ective Project Management: Traditional, Agile, Extreme, 5th Ed. (Indianapolis, IN: Wiley Publishing, 2009).

Systems Development Methodologies  15

plans go out the window.13 Th e best you can do is to react to where the proverbial rugby ball squirts out. You then sprint with the ball until the next scrum. In the case of the Scrum methodology, a sprint lasts thirty working days. At the end of the sprint, a system is deliv- ered to the customer.

Of all systems development approaches, on the surface, Scrum is the most chaotic. To control some of the innate chaos, Scrum development focuses on a few key practices. Teams are self-organized and self-directed. Unlike other approaches, Scrum teams do not have a des- ignated team leader. Instead, teams organize themselves in a symbiotic manner and set their own goals for each sprint (iteration). Once a sprint has begun, Scrum teams do not consider any additional requirements. Any new requirements that are uncovered are placed on a back- log of requirements that still need to be addressed. At the beginning of every workday, a Scrum meeting takes place. At the end of each sprint, the team demonstrates the soft ware to the client. Based on the results of the sprint, a new plan is begun for the next sprint.

Scrum meetings are one of the most interesting aspects of the Scrum development pro- cess. Th e team members attend the meetings, but anyone can attend. However, with very few exceptions, only team members may speak. One prominent exception is management providing feedback on the business relevance of the work being performed by the specifi c team. In this meeting, all team members stand in a circle and report on what they accom- plished during the previous day, state what they plan to do today, and describe anything that blocked progress the previous day. To enable continuous progress, any block identifi ed is dealt with within one hour. From a Scrum point of view, it is better to make a “bad” deci- sion about a block at this point in development than to not make a decision. Because the meetings take place each day, a bad decision can easily be undone. Larman14 suggests that each team member should report any additional requirements that have been uncovered during the sprint and anything that the team member learned that could be useful for other team members to know.

One of the major criticisms of Scrum, as with all agile methodologies, is that it is ques- tionable whether Scrum can scale up to develop very large, mission-critical systems. A typical Scrum team size is no more than seven members. Th e only organizing principle put forth by Scrum followers to address this criticism is to organize a scrum of scrums. Each team meets every day, and aft er the team meeting takes place, a representative (not leader) of each team attends a scrum-of-scrums meeting. Th is continues until the progress of entire system has been determined. Depending on the number of teams involved, this approach to managing a large project is doubtful. However, as in XP and other agile development approaches, many of the ideas and techniques associated with Scrum development are useful in object-oriented systems development, such as the focus of a Scrum meeting, the evolutionary and incremen- tal approach to identifying requirements, and the incremental and iterative approach to the development of the system.

Selecting the Appropriate Development Methodology Because there are many methodologies, the fi rst challenge faced by analysts is selecting which methodology to use. Choosing a methodology is not simple, because no one methodology is always best. (If it were, we’d simply use it everywhere!) Many organizations have standards and policies to guide the choice of methodology. You will fi nd that organizations range from

13 Scrum developers are not the fi rst to question the use of plans. One of President Eisenhower’s favorite maxims was, “In preparing for battle I have always found that plans are useless, but planning is indispensable.” M. Dobson, Streetwise Project Management: How to Manage People, Processes, and Time to Achieve the Results You Need (Avon, MA: F+W Publications, 2003), p. 43. 14 C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison-Wesley, 2004).

1 6 C h a p t e r 1   Introduction to Systems Analysis and Design

having one “approved” methodology to having several methodology options to having no formal policies at all.

Figure 1-8 summarizes some important criteria for selecting a methodology. One impor- tant item not discussed in this fi gure is the degree of experience of the analyst team. Many of the RAD-based methodologies require the use of new tools and techniques that have a signifi cant learning curve. Oft en these tools and techniques increase the complexity of the project and require extra time for learning. However, once they are adopted and the team becomes experienced, the tools and techniques can signifi cantly increase the speed at which the methodology can deliver a fi nal system.

Clarity of User Requirements When the user requirements for a system are unclear, it is diffi cult to understand them by talking about them and explaining them with written reports. Users normally need to interact with technology to really understand what a new system can do and how to best apply it to their needs. RAD and agile methodologies are usually more appropriate when user requirements are unclear.

Familiarity with Technology When the system will use new technology with which the ana- lysts and programmers are not familiar, early application of the new technology in the meth- odology will improve the chance of success. If the system is designed without some familiarity with the base technology, risks increase because the tools might not be capable of doing what is needed. Th rowaway prototyping-based methodologies are particularly appropriate if users lack familiarity with technology because they explicitly encourage the developers to develop design prototypes for areas with high risks. Phased development-based methodologies create opportunities to investigate the technology in some depth before the design is complete. Also, owing to the programming-centric nature of agile methodologies, both XP and Scrum are appropriate. Although you might think prototyping-based methodologies are also appropriate, they are much less so because the early prototypes that are built usually only scratch the surface of the new technology. It is generally only aft er several prototypes and several months that the developers discover weaknesses or problems in the new technology.

System Complexity Complex systems require careful and detailed analysis and design. Th rowaway prototyping-based methodologies are particularly well suited to such detailed analysis and design, but prototyping-based methodologies are not. Th e traditional structured

Ability to Develop Systems

Structured Methodologies RAD Methodologies

Agile Methodologies

Waterfall Parallel Phased Prototyping Throwaway Prototyping XP SCRUM

With Unclear User Requirements Poor Poor Good Excellent Excellent Excellent Excellent

With Unfamiliar Technology Poor Poor Good Poor Excellent Good Good

That Are Complex Good Good Good Poor Excellent Good Good

That Are Reliable Good Good Good Poor Excellent Excellent Excellent

With a Short Time Schedule Poor Good Excellent Excellent Good Excellent Excellent

With Schedule Visibility Poor Poor Excellent Excellent Good Excellent Excellent

FIGURE 1-8    Criteria for Selecting a Methodology

Typical Systems Analyst Roles and Skills  17

design-based methodologies can handle complex systems, but without the ability to get the system or prototypes into the users’ hands early on, some key issues may be overlooked. Although phased development-based methodologies enable users to interact with the system early in the process, we have observed that project teams who follow these tend to devote less attention to the analysis of the complete problem domain than they might using other meth- odologies. Finally, agile methodologies are a mixed bag when it comes to system complexity. If the system is going to be a large one, agile methodologies will perform poorly. However, if the system is small to medium size, then agile approaches will be excellent. We rate them good on these criteria.

System Reliability System reliability is usually an important factor in system development; aft er all, who wants an unreliable system? However, reliability is just one factor among several. For some applications, reliability is truly critical (e.g., medical equipment, mis- sile-control systems), whereas for other applications (e.g., games, Internet video) it is merely important. Because throwaway prototyping methodologies combine detailed analysis and design phases with the ability for the project team to test many diff erent approaches through design prototypes before completing the design, they are appropriate when system reliability is a high priority. Prototyping methodologies are generally not a good choice when reliability is critical because it lacks the careful analysis and design phases that are essential for depend- able systems. However, owing to the heavy focus on testing, evolutionary and incremental identifi cation of requirements, and iterative and incremental development, agile methods may be the best overall approach.

Short Time Schedules RAD-based and agile methodologies are excellent choices when timelines are short because they best enable the project team to adjust the functionality in the system based on a specifi c delivery date, and if the project schedule starts to slip, it can be readjusted by removing functionality from the version or prototype under development. Waterfall-based methodologies are the worst choice when time is at a premium because they do not allow easy schedule changes.

Schedule Visibility One of the greatest challenges in systems development is determining whether a project is on schedule. Th is is particularly true of the structured design method- ologies because design and implementation occur at the end of the project. Th e RAD-based methodologies move many of the critical design decisions earlier in the project to help project managers recognize and address risk factors and keep expectations in check. However, given the daily progress meetings associated with Agile approaches, schedule visibility is always on the proverbial front burner.

TYPICAL SYSTEMS ANALYST ROLES AND SKILLS It is clear from the various phases and steps performed during the SDLC that the project team needs a variety of skills. Project members are change agents who identify ways to improve an organization, build an information system to support them, and train and motivate others to use the system. Understanding what to change and how to change it—and convincing others of the need for change—requires a wide range of skills. Th ese skills can be broken down into six major categories: technical, business, analytical, interpersonal, management, and ethical.

Analysts must have the technical skills to understand the organization’s existing techni- cal environment, the technology that will make up the new system, and the way both can fi t into an integrated technical solution. Business skills are required to understand how IT can be

1 8 C h a p t e r 1   Introduction to Systems Analysis and Design

applied to business situations and to ensure that the IT delivers real business value. Analysts are continuous problem solvers at both the project and the organizational level, and they put their analytical skills to the test regularly.

Analysts oft en need to communicate eff ectively one-on-one with users and business man- agers (who oft en have little experience with technology) and with programmers (who oft en have more technical expertise than the analyst). Th ey must be able to give presentations to large and small groups and write reports. Not only do they need to have strong interpersonal abilities, but they also need to manage people with whom they work and they need to manage the pressure and risks associated with unclear situations.

Finally, analysts must deal fairly, honestly, and ethically with other project team mem- bers, managers, and system users. Analysts oft en deal with confi dential information or infor- mation that, if shared with others, could cause harm (e.g., dissent among employees); it is important to maintain confi dence and trust with all people.

In addition to these six general skill sets, analysts require many specifi c skills associated with roles performed on a project. In the early days of systems development, most organiza- tions expected one person, the analyst, to have all the specifi c skills needed to conduct a sys- tems development project. Some small organizations still expect one person to perform many roles, but because organizations and technology have become more complex, most large organizations now build project teams containing several individuals with clearly defi ned responsibilities. Diff erent organizations divide the roles diff erently. Most IS teams include many other individuals, such as the programmers, who actually write the programs that make up the system, and technical writers, who prepare the help screens and other documentation (e.g., users manuals and systems manuals).

Business Analyst A business analyst focuses on the business issues surrounding the system. Th ese issues include identifying the business value that the system will create, developing ideas and suggestions for how the business processes can be improved, and designing the new processes and policies in conjunction with the systems analyst. Th is individual likely has business experience and some type of professional training. He or she represents the interests of the project sponsor and the ultimate users of the system. A business analyst assists in the planning and design phases but is most active in the analysis phase.

Systems Analyst A systems analyst focuses on the IS issues surrounding the system. Th is person develops ideas and suggestions for how information technology can improve business processes, designs the new business processes with help from the business analyst, designs the new information sys- tem, and ensures that all IS standards are maintained. A systems analyst likely has signifi cant training and experience in analysis and design, programming, and even areas of the business. He or she represents the interests of the IS department and works intensively through the pro- ject but perhaps less so during the implementation phase.

Infrastructure Analyst An infrastructure analyst focuses on the technical issues surrounding how the system will interact with the organization’s technical infrastructure (e.g., hardware, soft ware, networks, and databases). An infrastructure analyst’s tasks include ensuring that the new information system conforms to organizational standards and identifying infrastructure changes needed to support the system. Th is individual probably has signifi cant training and experience in

Basic Characteristics of Object-Oriented Systems  19

networking, database administration, and various hardware and soft ware products. He or she represents the interests of the organization and IS group that will ultimately have to operate and support the new system once it has been installed. An infrastructure analyst works throughout the project but perhaps less so during planning and analysis phases.

Change Management Analyst A change management analyst focuses on the people and management issues surrounding the system installation. Th e roles of this person include ensuring that the adequate docu- mentation and support are available to users, providing user training on the new system, and developing strategies to overcome resistance to change. Th is individual should have signifi - cant training and experience in organizational behavior in general and change management in particular. He or she represents the interests of the project sponsor and users for whom the system is being designed. A change management analyst works most actively during the implementation phase but begins laying the groundwork for change during the analysis and design phases.

Project Manager A project manager is responsible for ensuring that the project is completed on time and within budget and that the system delivers all benefi ts intended by the project sponsor. Th e role of the project manager includes managing the team members, developing the project plan, assigning resources, and being the primary point of contact when people outside the team have questions about the project. Th is individual likely has signifi cant experience in project management and has probably worked for many years as a systems analyst beforehand. He or she represents the interests of the IS department and the project sponsor. Th e project man- ager works intensely during all phases of the project.

BASIC CHARACTERISTICS OF OBJECT-ORIENTED SYSTEMS Object-oriented systems focus on capturing the structure and behavior of information sys- tems in little modules that encompass both data and process. Th ese little modules are known as objects. In this section, we describe the basic characteristics of object-oriented systems, which include classes, objects, methods, messages, encapsulation, information hiding, inher- itance, polymorphism, and dynamic binding.15

Classes and Objects A class is the general template we use to defi ne and create specifi c instances, or objects. Every object is associated with a class. For example, all the objects that capture information about patients could fall into a class called Patient, because there are attributes (e.g., name, address, birth date, phone, and insurance carrier) and methods (e.g., make appointment, calculate last visit, change status, and provide medical history) that all patients share (see Figure 1-9).

An object is an instantiation of a class. In other words, an object is a person, place, or thing about which we want to capture information. If we were building an appointment sys- tem for a doctor’s offi ce, classes might include Doctor, Patient, and Appointment. Th e specifi c patients, such as Jim Maloney, Mary Wilson, and Th eresa Marks, are considered instances, or objects, of the patient class (see Figure 1-9).

15 In Chapter 8, we review the basic characteristics of object-oriented systems in more detail.

2 0 C h a p t e r 1   Introduction to Systems Analysis and Design

Each object has attributes that describe information about the object, such as a patient’s name, birth date, address, and phone number. Attributes are also used to represent relation- ships between objects; for example, there could be a department attribute in an employee object with a value of a department object that captures in which department the employee object works. Th e state of an object is defi ned by the value of its attributes and its relationships with other objects at a particular point in time. For example, a patient might have a state of new or current or former.

Each object also has behaviors. Th e behaviors specify what the object can do. For exam- ple, an appointment object can probably schedule a new appointment, delete an appointment, and locate the next available appointment. In object-oriented programming, behaviors are implemented as methods (see the next section).

One of the more confusing aspects of object-oriented systems development is the fact that in most object-oriented programming languages, both classes and instances of classes can have attributes and methods. Class attributes and methods tend to be used to model attributes (or methods) that deal with issues related to all instances of the class. For example, to create a new patient object, a message is sent to the Patient class to create a new instance of itself. However, in this book, we focus primarily on attributes and methods of objects and not of classes.

Methods and Messages Methods implement an object’s behavior. A method is nothing more than an action that an object can perform. Messages are information sent to objects to trigger methods. A message is essentially a function or procedure call from one object to another object. For example, if a patient is new to the doctor’s offi ce, the receptionist sends a create message to the application. Th e patient class receives the create message and executes its create() method which then creates a new object: aPatient (see Figure 1-10).

Encapsulation and Information Hiding Th e ideas of encapsulation and information hiding are interrelated in object-oriented systems. However, neither of the terms is new. Encapsulation is simply the combination of process and data into a single entity. Information hiding was fi rst promoted in structured systems development. Th e principle of information hiding suggests that only the information

FIGURE 1-9 Classes and Objects

Patient

-name -address -birthdate -phone -insurance carrier +make appointment() +calculate last visit() +change status() +provides medical history() +create()

Mary Wilson : PatientJim Maloney : Patient Theresa Marks : Patient

Basic Characteristics of Object-Oriented Systems  21

required to use a soft ware module be published to the user of the module. Typically, this implies that the information required to be passed to the module and the information returned from the module are published. Exactly how the module implements the required functionality is not relevant. We really do not care how the object performs its functions, as long as the functions occur. In object-oriented systems, combining encapsulation with the information-hiding principle supports treating objects as black boxes.

Th e fact that we can use an object by calling methods is the key to reusability because it shields the internal workings of the object from changes in the outside system, and it keeps the system from being aff ected when changes are made to an object. In Figure 1-10, notice how a message (create) is sent to an object, yet the internal algorithms needed to respond to the message are hidden from other parts of the system. Th e only information that an object needs to know is the set of operations, or methods, that other objects can perform and what messages need to be sent to trigger them.

Inheritance Inheritance, as an information systems development characteristic, was proposed in data modeling in the late 1970s and the early 1980s. Th e data modeling literature suggests using inheritance to identify higher-level, or more general, classes of objects. Common sets of attributes and methods can be organized into superclasses. Typically, classes are arranged in a hierarchy whereby the superclasses, or general classes, are at the top and the subclasses, or specifi c classes, are at the bottom. In Figure 1-11, Person is a superclass to the classes Doctor and Patient. Doctor, in turn, is a superclass to General Practitioner and Specialist. Notice how a class (e.g., Doctor) can serve as a superclass and subclass concurrently. Th e relationship between the class and its superclass is known as the a-kind-of relationship. For example in Figure 1-11, a General Practitioner is a-kind-of Doctor, which is a-kind-of Person.

Subclasses inherit the appropriate attributes and methods from the superclasses above them. Th at is, each subclass contains attributes and methods from its parent superclass. For example, Figure 1-11 shows that both Doctor and Patient are subclasses of Person and there- fore inherit the attributes and methods of the Person class. Inheritance makes it simpler to defi ne classes. Instead of repeating the attributes and methods in the Doctor and Patient classes separately, the attributes and methods that are common to both are placed in the Person class and inherited by the classes below it. Notice how much more effi cient inheritance hierarchies of object classes are than the same objects without an inheritance hierarchy (see Figure 1-12).

Most classes throughout a hierarchy lead to instances; any class that has instances is called a concrete class. For example, if Mary Wilson and Jim Maloney are instances of the Patient class, Patient would be considered a concrete class (see Figure 1-9). Some classes do not produce instances because they are used merely as templates for other,

FIGURE 1-10 Messages and Methods

Receptionist

create

Patient

-name -address -birthdate -phone -insurance carrier

+make appointment() +calculate last visit() +change status() +provides medical history() +create()

aPatient

2 2 C h a p t e r 1   Introduction to Systems Analysis and Design

more-specific classes (especially classes located high up in a hierarchy). The classes are referred to as abstract classes. Person is an example of an abstract class. Instead of creating objects from Person, we create instances representing the more-specifi c classes of Specialist and Patient, both types of Person (see Figure 1-11).

Polymorphism and Dynamic Binding Polymorphism means that the same message can be interpreted diff erently by diff erent classes of objects. For example, inserting a patient means something diff erent than inserting an appointment. Th erefore, diff erent pieces of information need to be collected and stored. Luckily, we do not have to be concerned with how something is done when using objects. We can simply send a message to an object, and that object will be responsible for interpret- ing the message appropriately. For example, if an artist sent the message Draw yourself to a

FIGURE 1-11 Class Hierarchy with Abstract and Concrete Classes

Person

Doctor Patient

SpecialistGeneral Practitioner

Abstract classes

Concrete classes

FIGURE 1-12    Inheritance Advantage?

Patient

-name -address -birthdate -phone -insurance carrier +updateBirthDate() +updateInsuranceCarrier()

Person

-name -address -birthdate -phone +updateBirthDate()

Doctor

Doctor

-name -address -birthdate -phone -medicalSchoolSpecialty +updateBirthDate() +updateMedicalSchoolSpecialty()

VS.

-medicalSchoolSpecialty +updateMedicalSchoolSpecialty()

Patient

-insurance carrier

+updateInsuranceCarrier()

Object-Oriented Systems Analysis and Design (OOSAD)  23

square object, a circle object, and a triangle object, the results would be very diff erent, even though the message is the same. Notice in Figure 1-13 how each object responds appropri- ately (and diff erently) even though the messages are identical.

Polymorphism is made possible through dynamic binding. Dynamic, or late, binding is a technique that delays typing the object until run-time. Th e specifi c method that is actu- ally called is not chosen by the object-oriented system until the system is running. Th is is in contrast to static binding. In a statically bound system, the type of object is determined at compile-time. Th erefore, the developer has to choose which method should be called instead of allowing the system to do it. Th is is why most traditional programming lan- guages have complicated decision logic based on the diff erent types of objects in a system. For example, in a traditional programming language, instead of sending the message Draw yourself to the diff erent types of graphical objects in Figure 1-13, we would have to write decision logic using a case statement or a set of if statements to determine what kind of graphical object we wanted to draw, and we would have to name each draw function dif- ferently (e.g., draw square, draw circle, or draw triangle). Th is obviously makes the system much more complicated and diffi cult to understand.

OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN (OOSAD) Object-oriented approaches to developing information systems, technically speaking, can use any of the traditional methodologies. However, the object-oriented approaches are most asso- ciated with a phased development RAD or agile methodology. Th e primary diff erence between a traditional approach like structured design and an object-oriented approach is how a prob- lem is decomposed. In traditional approaches, the problem-decomposition process is either process-centric or data-centric. However, processes and data are so closely related that it is diffi cult to pick one or the other as the primary focus. Based on this lack of congruence with the real world, new object-oriented methodologies have emerged that use the RAD-based sequence of SDLC phases but attempt to balance the emphasis between process and data by focusing the decomposition of problems on objects that contain both data and processes.

FIGURE 1-13 Polymorphism

D ra

w Yo

ur se

lf

DrawYourself

D raw

Yourself

aTriangle

aSquare

aCircle

anArtist

2 4 C h a p t e r 1   Introduction to Systems Analysis and Design

16 Grady Booch, Ivar Jacobson, and James Rumbaugh, Th e Unifi ed Modeling Language User Guide (Reading, MA: Addison-Wesley, 1999). 17 For those of you who have experience with traditional structured analysis and design, this is one of the most unusual aspects of object-oriented analysis and design using UML. Unlike structured approaches, object-oriented approaches stress focusing on just one use case at a time and distributing that single use case over a set of communicating and collaborating objects.

According to the creators of the Unifi ed Modeling Language (UML), Grady Booch, Ivar Jacobson, and James Rumbaugh,16 any modern object-oriented approach to developing infor- mation systems must be use-case driven, architecture-centric, and iterative and incremental.

Use-Case Driven Use-case driven means that use cases are the primary modeling tools defi ning the behavior of the system. A use case describes how the user interacts with the system to perform some activ- ity, such as placing an order, making a reservation, or searching for information. Th e use cases are used to identify and to communicate the requirements for the system to the programmers who must write the system. Use cases are inherently simple because they focus on only one business process at a time. In contrast, the process model diagrams used by traditional struc- tured and RAD methodologies are far more complex because they require the systems analyst and user to develop models of the entire system. With traditional methodologies, each system is decomposed into a set of subsystems, which are, in turn, decomposed into further subsys- tems, and so on. Th is goes on until no further process decomposition makes sense, and it oft en requires dozens of pages of interlocking diagrams. In contrast, a use case focuses on only one business process at a time, so developing models is much simpler.17

Architecture-Centric Any modern approach to systems analysis and design should be architecture-centric. Architecture-centric means that the underlying soft ware architecture of the evolving system specifi cation drives the specifi cation, construction, and documentation of the system. Modern object-oriented systems analysis and design approaches should support at least three separate but interrelated architectural views of a system: functional, static, and dynamic. Th e functional, or external, view describes the behavior of the system from the perspective of the user. Th e structural, or static, view describes the system in terms of attributes, methods, classes, and relationships. Th e behavioral, or dynamic, view describes the behavior of the system in terms of messages passed among objects and state changes within an object.

Iterative and Incremental Modern object-oriented systems analysis and design approaches emphasize iterative and incremental development that undergoes continuous testing and refi nement throughout the life of the project. Th is implies that the systems analysts develop their understanding of a user’s problem by building up the three architectural views little by little. Th e systems analyst does this by working with the user to create a functional representation of the system under study. Next, the analyst attempts to build a structural representation of the evolving system. Using the structural representation of the system, the analyst distributes the functionality of the system over the evolving structure to create a behavioral representation of the evolving system. As an analyst works with the user in developing the three architectural views of the evolving system, the analyst iterates over each of and among the views. Th at is, as the analyst better understands the structural and behavioral views, the analyst uncovers missing require- ments or misrepresentations in the functional view. Th is, in turn, can cause changes to be

The Unifi ed Process  25

cascaded back through the structural and behavioral views. All three architectural views of the system are interlinked and dependent on each other (see Figure 1-14). As each increment and iteration is completed, a more-complete representation of the user’s real functional requirements is uncovered.

Benefi ts of Object-Oriented Systems Analysis and Design Concepts in the object-oriented approach enable analysts to break a complex system into smaller, more-manageable modules, work on the modules individually, and easily piece the modules back together to form an information system. Th is modularity makes systems devel- opment easier to grasp, easier to share among members of a project team, and easier to com- municate to users, who are needed to provide requirements and confi rm how well the system meets the requirements throughout the systems development process. By modularizing systems development, the project team actually is creating reusable pieces that can be plugged into other systems eff orts or used as starting points for other projects. Ultimately, this can save time because new projects don’t have to start completely from scratch.

THE UNIFIED PROCESS Th e Unifi ed Process is a specifi c methodology that maps out when and how to use the var- ious Unifi ed Modeling Language (UML) techniques for object-oriented analysis and design. Th e primary contributors were Grady Booch, Ivar Jacobsen, and James Rumbaugh. Whereas the UML provides structural support for developing the structure and behavior of an infor- mation system, the Unifi ed Process provides the behavioral support. Th e Unifi ed Process, of course, is use-case driven, architecture-centric, and iterative and incremental. Furthermore, the Unifi ed Process is a two-dimensional systems development process described by a set of phases and workfl ows. Th e phases are inception, elaboration, construction, and transition. Th e workfl ows include business modeling, requirements, analysis, design, implementation, test, deployment, confi guration and change management, project management, and environ- ment.18 Figure 1-15 depicts the Unifi ed Process.

FIGURE 1-14 Iterative and Incremental Development

18 Th e material in this section is based on Khawar Zaman Ahmed and Cary E. Umrysh, Developing Enterprise Java Applications with J2EE and UML (Boston, MA: Addison-Wesley, 2002); Jim Arlow and Ila Neustadt, UML and Th e Unifi ed Process: Practical Object-Oriented Analysis & Design (Boston, MA: Addison-Wesley, 2002); Peter Eeles, Kelli Houston, and Wojtek Kozacynski, Building J2EE Applications with the Rational Unifi ed Process (Boston, MA: Addison-Wesley, 2003); Ivar Jacobson, Grady Booch, and James Rumbaugh, Th e Unifi ed Soft ware Development Process (Reading, MA: Addison-Wesley, 1999); Phillipe Krutchten, Th e Rational Unifi ed Process: An Introduction, 2nd Ed. (Boston, MA: Addison-Wesley, 2000); “Rational Unifi ed Process: Best Practices for Soft ware Development Teams,” Rational Soft ware White Paper, TP026B, Rev 11/01.

Functional view

Structural view

Behavioral view

Object-Oriented

2 6 C h a p t e r 1   Introduction to Systems Analysis and Design

Phases Th e phases of the Unifi ed Process support an analyst in developing information systems in an iterative and incremental manner. Th e phases describe how an information system evolves through time. Depending on which development phase the evolving system is currently in, the level of activity varies over the workfl ows. Th e curve in Figure 1-15 associated with each workfl ow approximates the amount of activity that takes place during the specifi c phase. For example, the inception phase primarily involves the business modeling and requirements work- fl ows, while practically ignoring the test and deployment workfl ows. Each phase contains a set of iterations, and each iteration uses the various workfl ows to create an incremental version of the evolving system. As the system evolves through the phases, it improves and becomes more complete. Each phase has objectives, a focus of activity over the workfl ows, and incremental deliverables. Each of the phases is described next.

Inception In many ways, the inception phase is very similar to the planning phase of a tra- ditional SDLC approach. In this phase, a business case is made for the proposed system. Th is includes feasibility analysis that should answer questions such as the following:

Do we have the technical capability to build it (technical feasibility)? If we build it, will it provide business value (economic feasibility)? If we build it, will it be used by the organization (organizational feasibility)?

FIGURE 1-15    The Unifi ed Process

Business Modeling

Phases Inception

Supporting Workflows

Elaboration Construction Transition

Requirements

Analysis

Design

Implementation

Configuration and Change Management

Iter 1

… Iter i

Iter i + 1

… Iter j

Iter j + 1

… Iter k

Iter k + 1

… Iter m

Project Management

Environment

Test

Deployment

Phases Inception

Engineering Workflows

Elaboration Construction Transition

The Unifi ed Process  27

19 With UML comprising fi ft een diff erent, related diagramming techniques, keeping the diagrams coordinated and the diff erent versions of the evolving system synchronized is typically beyond the capabilities of a mere mortal systems devel- oper. Th ese tools typically include project management and CASE tools. We describe the use of these tools in Chapter 2.

To answer these questions, the development team performs work related primarily to the business modeling, requirements, and analysis workfl ows. In some cases, depending on the technical diffi culties that could be encountered during the development of the system, a throwaway prototype is developed. Th is implies that the design, implementation, and test workfl ows could also be involved. Th e project management and environment supporting workfl ows are very relevant to this phase. Th e primary deliverables from the inception phase are a vision document that sets the scope of the project; identifi es the primary requirements and constraints; sets up an initial project plan; and describes the feasibility of and risks asso- ciated with the project, the adoption of the necessary environment to develop the system, and some aspects of the problem domain classes being implemented and tested.

Elaboration When we typically think about object-oriented systems analysis and design, the activities related to the elaboration phase of the Unifi ed Process are the most relevant. Th e analysis and design workfl ows are the primary focus during this phase. Th e elaboration phase continues with developing the vision document, including fi nalizing the business case, revising the risk assessment, and completing a project plan in suffi cient detail to allow the stakeholders to be able to agree with constructing the actual fi nal system. It deals with gathering the requirements, building the UML structural and behavioral models of the problem domain, and detailing how the problem domain models fi t into the evolving system architecture. Developers are involved with all but the deployment engineering workfl ow in this phase. As the developers iterate over the workfl ows, the importance of addressing confi guration and change management becomes apparent. Also, the development tools acquired during the inception phase become critical to the success of the project during this phase.19 Th e primary deliverables of this phase include the UML structure and behavior diagrams and an executable of a baseline version of the evolving information system. Th e baseline version serves as the foundation for all later iterations. By providing a solid founda- tion at this point, the developers have a basis for completing the system in the construction and transition phases.

Construction Th e construction phase focuses heavily on programming the evolving infor- mation system. Th is phase is primarily concerned with the implementation workfl ow. How- ever, the requirements workfl ow and the analysis and design workfl ows also are involved with this phase. It is during this phase that missing requirements are identifi ed and the analysis and design models are fi nally completed. Typically, there are iterations of the workfl ows during this phase, and during the last iteration, the deployment workfl ow kicks into high gear. Th e confi guration and change management workfl ow, with its version-con- trol activities, becomes extremely important during the construction phase. At times, an iteration has to be rolled back. Without good version controls, rolling back to a previous version (incremental implementation) of the system is nearly impossible. Th e primary deliverable of this phase is an implementation of the system that can be released for beta and acceptance testing.

Transition Like the construction phase, the transition phase addresses aspects typically associated with the implementation phase of a traditional SDLC approach. Its primary focus is on the testing and deployment workfl ows. Essentially, the business modeling, requirements, and analysis workfl ows should have been completed in earlier iterations of the evolving information system. Furthermore, the testing workfl ow will have been

2 8 C h a p t e r 1   Introduction to Systems Analysis and Design

executing during the earlier phases of the evolving system. Depending on the results from the testing workfl ow, some redesign and programming activities on the design and implementation workfl ows could be necessary, but they should be minimal at this point. From a managerial perspective, the project management, confi guration and change man- agement, and environment are involved. Some of the activities that take place are beta and acceptance testing, fi ne-tuning the design and implementation, user training, and rolling out the fi nal product onto a production platform. Obviously, the primary deliverable is the actual executable information system. Th e other deliverables include user manuals, a plan to support the users, and a plan for upgrading the information system in the future.

Workfl ows Th e workfl ows describe the tasks or activities that a developer performs to evolve an infor- mation system over time. Th e workfl ows of the Unifi ed Process are grouped into two broad categories: engineering and supporting.

Engineering Workfl ows Engineering workfl ows include business-modeling, requirements, analysis, design, implementation, test, and deployment workfl ows. Th e engineering work- fl ows deal with the activities that produce the technical product (i.e., the information system).

Business Modeling Workfl ow Th e business-modeling workfl ow uncovers problems and identifi es potential projects within a user organization. Th is workfl ow aids management in understanding the scope of the projects that can improve the effi ciency and eff ectiveness of a user organization. Th e primary purpose of business modeling is to ensure that both developer and user organizations understand where and how the to-be-developed information system fi ts into the business processes of the user organization. Th is workfl ow is primarily exe- cuted during the inception phase to ensure that we develop information systems that make business sense. Th e activities that take place on this workfl ow are most closely associated with the planning phase of the traditional SDLC; however, requirements gathering, and use-case and business process modeling techniques also help us to understand the business situation.

Requirements Workfl ow In the Unifi ed Process, the requirements workfl ow includes elic- iting both functional and nonfunctional requirements. Typically, requirements are gathered from project stakeholders, such as end users, managers within the end user organization, and even customers. Th e requirements workfl ow is used the most during the inception and elab- oration phases. Th e identifi ed requirements are very helpful for developing the vision docu- ment and the use cases used throughout the development process. Additional requirements tend to be discovered throughout the development process. In fact, only the transition phase tends to have few, if any, additional requirements identifi ed.

Analysis Workfl ow Th e analysis workfl ow primarily addresses the creation of an analysis model of the problem domain. In the Unifi ed Process, the analyst begins designing the archi- tecture associated with the problem domain; using the UML, the analyst creates structural and behavior diagrams that depict a description of the problem domain classes and their inter- actions. Th e primary purpose of the analysis workfl ow is to ensure that both the developer and user organizations understand the underlying problem and its domain without overana- lyzing. If they are not careful, analysts can create analysis paralysis, which occurs when the project becomes so bogged down with analysis that the system is never actually designed or implemented. A second purpose of the analysis workfl ow is to identify useful reusable classes for class libraries. By reusing predefi ned classes, the analyst can avoid reinventing the wheel

The Unifi ed Process  29

when creating the structural and behavior diagrams. Th e analysis workfl ow is predominantly associated with the elaboration phase, but like the requirements workfl ow, it is possible that additional analysis will be required throughout the development process.

Design Workfl ow Th e design workfl ow transitions the analysis model into a form that can be used to implement the system: the design model. Whereas the analysis workfl ow concen- trated on understanding the problem domain, the design workfl ow focuses on developing a solution that will execute in a specifi c environment. Basically, the design workfl ow simply enhances the description of the evolving system by adding classes that address the environ- ment of the system to the evolving analysis model. Th e design workfl ow uses activities such as detailed problem domain class design, optimization of the evolving information system, database design, user-interface design, and physical architecture design. Th e design workfl ow is associated primarily with the elaboration and construction phases of the Unifi ed Process.

Implementation Workfl ow Th e primary purpose of the implementation workfl ow is to create an executable solution based on the design model (i.e., programming). Th is includes not only writing new classes but also incorporating reusable classes from executable class libraries into the evolving solution. As with any programming activity, the new classes and their interactions with the incorporated reusable classes must be tested. Finally, in the case of multiple groups performing the implementation of the information system, the implementers also must integrate the separate, individually tested modules to create an executable version of the system. Th e implementation workfl ow is associated primarily with the elaboration and construction phases.

Testing Workfl ow Th e primary purpose of the testing workfl ow is to increase the quality of the evolving system. Testing goes beyond the simple unit testing associated with the implementation workfl ow. In this case, testing also includes testing the integration of all modules used to implement the system, user acceptance testing, and the actual alpha test- ing of the soft ware. Practically speaking, testing should go on throughout the development of the system; testing of the analysis and design models occurs during the elaboration and construction phases, whereas implementation testing is performed primarily during the construction and, to some degree, transition phases. Basically, at the end of each iteration during the development of the information system, some type of test should be performed.

Deployment Workfl ow Th e deployment workfl ow is most associated with the transition phase of the Unifi ed Process. Th e deployment workfl ow includes activities such as soft ware packaging, distribution, installation, and beta testing. When actually deploying the new sys- tem into a user organization, the developers might have to convert the current data, interface the new soft ware with the existing soft ware, and train the end user to use the new system.

Supporting Workfl ows Th e supporting workfl ows include the project management, con- fi guration and change management, and environment workfl ows. Th e supporting workfl ows focus on the managerial aspects of information systems development.

Project Management Workfl ow Whereas the other workfl ows associated with the Unifi ed Process are technically active during all four phases, the project management workfl ow is the only truly cross-phase workfl ow. Th e development process supports incremental and iterative development, so information systems tend to grow or evolve over time. At the end of each iteration, a new incremental version of the system is ready for delivery. Th e project management workfl ow is quite important owing to the complexity of the two-dimensional

3 0 C h a p t e r 1   Introduction to Systems Analysis and Design

development model of the Unifi ed Process (workfl ows and phases). Th is workfl ow’s activities include identifying and managing risks, managing scope, estimating the time to complete each iteration and the entire project, estimating the cost of the individual iteration and the whole project, and tracking the progress being made toward the fi nal version of the evolving information system.

Confi guration and Change Management Workfl ow Th e primary purpose of the confi gu- ration and change management workfl ow is to keep track of the state of the evolving system. In a nutshell, the evolving information system comprises a set of artifacts (e.g., diagrams, source code, and executables). During the development process, these artifacts are modifi ed. A substantial amount of work—and, hence, money—is involved in developing the artifacts. Th e artifacts themselves should be handled as any expensive asset would be handled—access controls must be put into place to safeguard the artifacts from being stolen or destroyed. Fur- thermore, because the artifacts are modifi ed on a regular, if not continuous, basis, good ver- sion control mechanisms should be established. Finally, a good deal of project management information needs to be captured (e.g., author, time, and location of each modifi cation). Th e confi guration and change management workfl ow is associated mostly with the construction and transition phases.

Environment Workfl ow During the development of an information system, the develop- ment team needs to use diff erent tools and processes. Th e environment workfl ow addresses these needs. For example, a CASE tool that supports the development of an object-oriented information system via the UML could be required. Other tools necessary include pro- gramming environments, project management tools, and confi guration management tools. Th e environment workfl ow involves acquiring and installing these tools. Even though this workfl ow can be active during all of the phases of the Unifi ed Process, it should be involved primarily with the inception phase.

Extensions to the Unifi ed Process As large and as complex as the Unifi ed Process is, many authors have pointed out a set of critical weaknesses. First, the Unifi ed Process does not address staffi ng, budgeting, or contract management issues. Th ese activities were explicitly left out of the Unifi ed Process. Second, the Unifi ed Process does not address issues relating to maintenance, operations, or support of the product once it has been delivered. Th us, it is not a complete soft ware process; it is only a development process. Th ird, the Unifi ed Process does not address cross- or inter-project issues. Considering the importance of reuse in object-oriented systems development and the fact that in many organizations employees work on many diff erent projects at the same time, leaving out inter-project issues is a major omission.

To address these omissions, Ambler and Constantine suggest adding a production phase and two workfl ows: the operations and support workfl ow and the infrastructure management workfl ow (see Figure 1-16).20 In addition to these new workfl ows, the test, deployment, and environment workfl ows are modifi ed, and the project management and the confi guration and change management workfl ows are extended into the production phase. Th ese extensions

20 S. W. Ambler and L. L. Constantine, Th e Unifi ed Process Inception Phase: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S. W. Ambler and L. L. Constantine, Th e Unifi ed Process Elaboration Phase: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S. W. Ambler and L. L. Constantine, Th e Unifi ed Process Construction Phase: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S. W. Ambler and L. L. Constantine, Th e Unifi ed Process Transition and Production Phases: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2002).

The Unifi ed Process  31

are based on alternative object-oriented soft ware processes: the OPEN process (Object-oriented Process, Environment, and Notation) and the Object-Oriented Soft ware Process.21

Production Phase Th e production phase is concerned primarily with issues related to the soft ware product aft er it has been successfully deployed. Th is phase focuses on issues related to updating, maintaining, and operating the soft ware. Unlike the previous phases, there are no iterations or incremental deliverables. If a new release of the soft ware is to be developed,

21 S. W. Ambler, Process Patterns—Building Large-Scale Systems Using Object Technology (Cambridge, UK: SIGS Books/Cambridge University Press, 1998); S. W. Ambler, More Process Patterns—Delivering Large-Scale Systems Using Object Technology (Cambridge, UK: SIGS Books/Cambridge University Press, 1999); I. Graham, B. Henderson- Sellers, and H. Younessi, Th e OPEN Process Specifi cation (Harlow, UK: Addison-Wesley, 1997); B. Henderson-Sellers and B. Unhelkar, OPEN Modeling with UML (Harlow, UK: Addison-Wesley, 2000).

FIGURE 1-16   The Enhanced Unifi ed Process

Business Modeling

Phases Inception

Supporting Workflows

Elaboration Construction Transition Production

Requirements

Analysis

Design

Implementation

Configuration and Change Management

Infrastructure Management

Project Management

Environment

Operations and Support

Iter 1

… Iter i

Iter i + 1

… Iter j

Iter j + 1

… Iter k

Iter k + 1

… Iter m

Test

Deployment

Phases Inception

Engineering Workflows

Elaboration Construction Transition Production

3 2 C h a p t e r 1   Introduction to Systems Analysis and Design

then the developers must begin a new run through the fi rst four phases. Based on the activi- ties that take place during this phase, no engineering workfl ows are relevant. Th e supporting workfl ows that are active during this phase include the confi guration and change manage- ment workfl ow, the project management workfl ow, the new operations and support work- fl ow, and the infrastructure management workfl ow.

Operations and Support Workfl ow Th e operations and support workfl ow, as you might guess, addresses issues related to supporting the current version of the soft ware and operating the soft ware on a daily basis. Activities include creating plans for the operation and support of the soft ware product once it has been deployed, creating training and user documentation, putting into place necessary backup procedures, monitoring and optimizing the performance of the soft ware, and performing corrective maintenance on the soft ware. Th is workfl ow becomes active during the construction phase; its level of activity increases throughout the transition and, fi nally, the production phase. Th e workfl ow fi nally drops off when the current version of the soft ware is replaced by a new version. Many developers are under the false impression that once the soft ware has been delivered to the customer, their work is fi nished. In most cases, the work of supporting the soft ware product is much more costly and time consuming than the original development. At that point, the developer’s work may have just begun.

Infrastructure Management Workfl ow Th e infrastructure management workfl ow’s primary purpose is to support the development of the infrastructure necessary to develop object- oriented systems. Activities such as development and modifi cation of libraries, standards, and enterprise models are very important. When the development and maintenance of a problem-domain architecture model goes beyond the scope of a single project and reuse is going to occur, the infrastructure management workfl ow is essential. Another very impor- tant set of cross-project activities is the improvement of the soft ware development process. Because the activities on this workfl ow tend to aff ect many projects and the Unifi ed Process focuses only on a specifi c project, the Unifi ed Process tends to ignore these activities (i.e., they are simply beyond the scope and purpose of the Unifi ed Process).

Existing Workfl ow Modifi cations and Extensions In addition to the workfl ows that were added to address defi ciencies contained in the Unifi ed Process, existing workfl ows had to be modifi ed and/or extended into the production phase. Th ese workfl ows include the test, deployment, environment, project management, and confi guration and change management workfl ows.

Test Workfl ow For high-quality information systems to be developed, testing should be done on every deliverable, including those created during the inception phase. Otherwise, less than high-quality systems will be delivered to the customer.

Deployment Workfl ow Legacy systems exist in most corporations today, and these systems have databases associated with them that must be converted to interact with the new systems. Owing to the complexity of deploying new systems, the conversion requires signifi cant plan- ning. Th erefore, the activities on the deployment workfl ow need to begin in the inception phase instead of waiting until the end of the construction phase, as suggested by the Unifi ed Process.

Environment Workfl ow Th e environment workfl ow needs to be modifi ed to include activ- ities related to setting up the operations and production environment. Th e actual work per- formed is similar to the work related to setting up the development environment that was performed during the inception phase. In this case, the additional work is performed during the transition phase.

The Unifi ed Process  33

Project Management Workfl ow Even though the project management workfl ow does not include staffi ng the project, managing the contracts among the customers and vendors, and managing the project’s budget, these activities are crucial to the success of any soft ware development project. We suggest extending project management to include these activities. Th is workfl ow should additionally occur in the production phase to address issues such as training, staff management, and client relationship management.

Confi guration and Change Management Workfl ow Th e confi guration and change manage- ment workfl ow is extended into the new production phase. Activities performed during the production phase include identifying potential improvements to the operational system and assessing the potential impact of the proposed changes. Once developers have identifi ed these changes and understood their impact, they can schedule the changes to be made and deployed with future releases.

Figure 1-17 shows the chapters in which the Enhanced Unifi ed Process’s phases and workfl ows are covered. Given the off shore outsourcing and automation of information

Enhanced UP Phases Chapters

Inception 2–4

Elaboration 3–11

Construction 8, 12

Transition 12–13

Production 13

Enhanced UP Engineering Workfl ows Chapters

Business Modeling 2–5

Requirements 3–5, 10

Analysis 3–7

Design 7–11

Implementation 9, 12

Test 4–7, 12

Deployment 13

Enhanced UP Supporting Workfl ows Chapters

Project Management 2, 13

Confi guration and Change Management

13

Environment 2

Operations and Support 13

Infrastructure Management

2

FIGURE 1-17    The Enhanced Unifi ed Process and the Textbook Organization

3 4 C h a p t e r 1   Introduction to Systems Analysis and Design

technology,22 in this textbook, we focus primarily on the elaboration phase and the busi- ness modeling, requirements, analysis, design, and project management workfl ows of the Enhanced Unifi ed Process. However, as Figure 1-17 shows, the other phases and workfl ows are covered. In many object-oriented systems development environments today, code generation is supported. Th us, from a business perspective, we believe the activities associated with these workfl ows are the most important.

THE UNIFIED MODELING L ANGUAGE Until 1995, object concepts were popular but implemented in many diff erent ways by diff erent developers. Each developer had his or her own methodology and notation (e.g., Booch, Coad, Moses, OMT, OOSE, SOMA).23 Th en in 1995, Rational Soft ware brought three industry leaders together to create a single approach to object-oriented systems development. Grady Booch, Ivar Jacobson, and James Rumbaugh worked with others to create a standard set of diagramming techniques known as the Unifi ed Modeling Language (UML). Th e objective of UML was to provide a common vocabulary of object-oriented terms and diagramming techniques rich enough to model any systems development pro- ject from analysis through implementation. In November 1997, the Object Management Group (OMG) formally accepted UML as the standard for all object developers. During the following years, the UML has gone through multiple minor revisions. Th e current version of UML is Version 2.5.

Version 2.5 of the UML defi nes a set of fi ft een diagramming techniques used to model a system. Th e diagrams are broken into two major groupings: one for modeling the structure of a system and one for modeling behavior. Structure diagrams provide a way to represent the data and static relationships in an information system. Th e structure diagrams include class, object, package, deployment, component, composite structure, and profi le diagrams. Behavior diagrams provide the analyst with a way to depict the dynamic relationships among the instances or objects that represent the business information system. Th ey also allow mod- eling of the dynamic behavior of individual objects throughout their lifetime. Th e behavior diagrams support the analyst in modeling the functional requirements of an evolving infor- mation system. Th e behavior modeling diagrams include activity, sequence, communication, interaction overview, timing, behavior state machine, protocol state machine, and use-case diagrams.24 Figure 1-18 provides an overview of these diagrams.

22 See Th omas L. Friedman, Th e World Is Flat: A Brief History of the Twenty-First Century, Updated and Expanded Edition (New York: Farrar, Straus, and Giroux, 2006); Daniel H. Pink, A Whole New Mind: Why Right-Brainers Will Rule the Future (New York: Riverhead Books, 2006). 23 See Grady Booch, Object-Oriented Analysis and Design with Applications, 2nd Ed. (Redwood City, CA: Benjamin/ Cummings, 1994); Peter Coad and Edward Yourdon, Object-Oriented Analysis, 2nd Ed. (Englewood Cliff s, NJ: Yourdon Press, 1991); Peter Coad and Edward Yourdon, Object-Oriented Design (Englewood Cliff s, NJ: Yourdon Press, 1991); Brian Henderson-Sellers and Julian Edwards, Book Two of Object-Oriented Knowledge: Th e Working Object (Sydney, Australia: Prentice Hall, 1994); James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen, Object-Oriented Modeling and Design (Englewood Cliff s, NJ: Prentice Hall, 1991); Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard, Object-Oriented Soft ware Engineering: A Use Case Approach (Wokingham, England: Addison-Wesley, 1992); Ian Graham, Migrating to Object Technology (Wokingham, England: Addison-Wesley, 1994). 24 Th e material contained in this section is based on the Unifi ed Modeling Language: Superstructure Version 2.4, ptc/2010-11-14 (www.uml.org). Additional useful references include Michael Jesse Chonoles and James A. Schardt, UML 2 for Dummies (Indianapolis, IN: Wiley, 2003); Hans-Erik Eriksson, Magnus Penker, Brian Lyons, and David Fado, UML 2 Toolkit (Indianapolis, IN: Wiley, 2004); Kendall Scott, Fast Track UML 2.0 (Berkeley, CA: Apress, 2004). For a complete description of all diagrams, see www.uml.org.

The Unifi ed Modeling Language  35

Structure Diagrams

Class Illustrate the relationships between classes modeled Analysis, Design in the system

Object Illustrate the relationships between objects modeled Analysis, Design in the system; used when actual instances of the classes will better communicate the model

Package Group other UML elements together to form Analysis, Design, higher-level constructs Implementation

Deployment Show the physical architecture of the system; can also Physical Design, be used to show software components being deployed Implementation onto the physical architecture

Component Illustrate the physical relationships among the software Physical Design, components Implementation

Composite Structure Design Illustrate the internal structure of a class, i.e., the Analysis, Design relationships among the parts of a class

Profi le Used to develop extensions to the UML itself None

Behavioral Diagrams

Activity Illustrate business workfl ows independent of classes, the fl ow Analysis, Design of activities in a use case, or detailed design of a method

Sequence Model the behavior of objects within a use case; Analysis, Design focuses on the time-based ordering of an activity

Communication Model the behavior of objects within a use case; Analysis, Design focus on the communication among a set of collaborating objects of an activity

Interaction Overview Illustrate an overview of the fl ow of control of a process Analysis, Design

Timing Illustrate the interaction among a set of objects and the state Analysis, Design changes they go through along a time axis

Behavioral State Machine Examine the behavior of one class Analysis, Design

Protocol State Machine Illustrate the dependencies among the different Analysis, Design interfaces of a class

Use-Case Capture business requirements for the system and illustrate Analysis the interaction between the system and its environment

FIGURE 1-18    UML 2.5 Diagram Summary

Diagram Name Used to... Primary Phase

Depending on where in the development process the system is, diff erent diagrams play a more important role. In some cases, the same diagramming technique is used throughout the development process. In that case, the diagrams start off very conceptual and abstract. As the system is developed, the diagrams evolve to include details that ultimately lead to generating and developing code. In other words, the diagrams move from documenting the requirements to laying out the design. Overall, the consistent notation, integration among the diagramming techniques, and application of the diagrams across the entire development process make the UML a powerful and fl exible language for analysts and developers. Later chapters provide more detail on using a subset of the UML in object-oriented systems analysis

3 6 C h a p t e r 1   Introduction to Systems Analysis and Design

and design. In particular, these chapters describe activity, use-case, class, object, sequence, communication, package, and deployment diagrams and the behavior state machines. We also introduce an optional UML diagram, the windows navigation diagram, that is an exten- sion to the behavioral state machine that is used to design user navigation through an infor- mation system’s user interfaces.

APPLYING THE CONCEPTS AT PATTERSON SUPERSTORE Th is course will introduce many new concepts regarding object-oriented analysis and design. To make these concepts more relevant and understandable, we will apply the concepts, introduced in each chapter, to a fi ctitious company called Patterson Superstore.

Patterson is a retail chain established in Pittsburgh, PA, in 1985. Currently, Patterson uses a mobile application to facilitate prescription order, notifi cation, and auto refi ll ser- vices. Th is service is widely used by Patterson’s client base, and Patterson has leveraged this mobile app to gain an advantage over less technically advanced competitors.

Clients now want to use this technology to access health clinic services. Th e Vice President of Pharmacy Services, Max Ross, would like to use this opportunity to position Patterson as a leader in the use of technology use for clinic access. Th e system that he envisions will enable real-time communication with medical personnel (audio, video, and text), mobile appointment scheduling, telehealth assessment, and diagnosis of minor problems through video house calls. Th roughout the book, we will revisit Patterson Superstore to see how the concepts introduced in each chapter aff ect this project.

You can fi nd the rest of the case at: www.wiley.com/go/dennis/casestudy

CHAPTER REVIEW Aft er reading and studying this chapter, you should be able to:

Describe the four primary phases of the Systems Development Life Cycle (SDLC). Explain the evolution of system development methodologies from process-centric to data-centric to RAD-based

methodologies. Explain the diff erent roles played by a systems analyst in the process of developing information systems. Describe the basic characteristics of object-oriented systems: objects, attributes, methods, messages, encapsulation,

information hiding, polymorphism, dynamic binding, and inheritance. Discuss the three basic characteristics of all object-oriented systems analysis and design approach: use-case driven,

architecture-centric, and iterative and incremental development. Describe the Unifi ed Process. List and categorize, as to their primary purpose, the diff erent diagrams associated with the Unifi ed Modeling

Language (UML).

KEY TERMS

Abstract classes Agile development A-kind-of Analysis model Analysis paralysis

Analysis phase Analysis strategy Analysis workfl ow Approval committee Architecture-centric

Architecture design As-is system Attribute Behavior Behavior diagrams

Behavioral view Business analyst Business modeling

workfl ow Change agent

Questions  37

Change management analyst

Class Concrete classes Confi guration and change

management workfl ow Construction Construction phase Database and fi le

specifi cation Data-centered

methodology Deliverable Deployment workfl ow Design model Design phase Design prototype Design strategy Design workfl ow Dynamic binding Dynamic view Elaboration phase Encapsulation Engineering workfl ow Environment

workfl ow

External view Extreme programming (XP) Feasibility analysis Functional view Gradual refi nement Implementation phase Implementation workfl ow Inception phase Incremental Information hiding Infrastructure analyst Infrastructure management

workfl ow Inherit Inheritance Instance Interface design Iterative Message Method Methodology Object Object Management

Group (OMG) Object-oriented

methodologies

Operations and support workfl ow

Parallel development Phased development Phases Planning phase Polymorphism Process-centered methodology Production phase Program design Programmer Project management Project management

workfl ow Project manager Project plan Project sponsor Prototyping Rapid application development

(RAD) Requirements gathering Requirements workfl ow Scrum State Static binding Static view

Structural view Structure diagrams Structured design Subclass Superclass Support plan System proposal System prototype System request System specifi cation Systems analyst Systems development life

cycle (SDLC) Technical writer Testing workfl ow Th rowaway prototyping Training plan Transition phase Unifi ed Modeling Language

(UML) Use case Use-case driven Version Waterfall development Workfl ows Workplan

QUESTIONS

1. Compare and contrast phases, steps, techniques, and deliverables.

2. Describe the major phases in the SDLC. 3. Describe the principal steps in the planning phase.

What are the major deliverables? 4. Describe the principal steps in the analysis phase.

What are the major deliverables? 5. Describe the principal steps in the design phase. What

are the major deliverables? 6. Describe the principal steps in the implementation

phase. What are the major deliverables? 7. What are the roles of a project sponsor and the

approval committee? 8. What does gradual refi nement mean in the context of

SDLC? 9. Compare and contrast process-centered methodolo-

gies with data-centered methodologies. 10. Compare and contrast structured design-based meth-

odologies in general to RAD-based methodologies in general.

11. Compare and contrast extreme programming and throwaway prototyping.

12. Describe the major elements in and issues with water- fall development.

13. Describe the major elements in and issues with parallel development.

14. Describe the major elements in and issues with phased development.

15. Describe the major elements in and issues with prototyping.

16. Describe the major elements in and issues with throw- away prototyping.

17. Describe the major elements in and issues with XP. 18. Describe the major elements in and issues with

Scrum. 19. What are the key factors in selecting a methodology? 20. What are the major roles played by a systems analyst

on a project team? 21. Compare and contrast the role of a systems analyst,

business analyst, and infrastructure analyst. 22. What is the diff erence between classes and objects? 23. What are methods and messages? 24. Why are encapsulation and information hiding

important characteristics of object-oriented systems?

3 8 C h a p t e r 1   Introduction to Systems Analysis and Design

EXERCISES

A. Suppose you are a project manager using a water- fall development-based methodology on a large and complex project. Your manager has just read the latest article in Computerworld that advocates replacing this methodology with prototyping and comes to you requesting that you switch. What would you say?

B. Th e basic types of methodologies discussed in this chapter can be combined and integrated to form new hybrid methodologies. Suppose you were to com- bine throwaway prototyping with the use of waterfall development. What would the methodology look like? Draw a picture (similar to those in Figures 1–2 through 1–7). How would this new methodology compare to the others?

C. Look on the Web for diff erent kinds of job opportu- nities that are available for people who want analyst positions? Compare and contrast the skills that the ads ask for to the skills that we presented in this chapter.

D. Th ink about your ideal analyst position. Write an ad to hire someone for that position. What requirements would the job have? What skills and experience would be required? How would an applicant be able to demon- strate having the appropriate skills and experience?

E. Using your favorite Web search engine, fi nd alterna- tive descriptions of the basic characteristics of object- oriented systems.

F. Look up object-oriented programming in Wikipedia. Write a short report based on its entry.

G. Choose an object-oriented programming language, such as C++, Java, Objective-C, Smalltalk, or VB.Net, and use the Web to fi nd out how the language supports the basic characteristics of object-oriented systems.

H. Assume that you have been assigned the task of cre- ating an object-oriented system that could be used to support students in fi nding an appropriate apartment

to live in next semester. What are the diff erent types of objects (i.e., classes) you would want to include in your system? What attributes or methods would you want to include in their defi nition? Is it possible to arrange them into an inheritance hierarchy? If so, do it. If not, why not?

I. Create an inheritance hierarchy that could be used to represent the following classes: accountant, customer, department, employee, manager, organization, and salesperson.

J. Investigate IBM’s Rational Unifi ed Process (RUP) on the Web. RUP is a commercial version that extends aspects of the Unifi ed Process. Write a brief memo describing how it is related to the Unifi ed Process as described in this chapter. (Hint: A good website with which to begin is www-01. ibm.com/soft ware/rational/rup/.)

K. Suppose you are a project manager who typically has been using a waterfall development-based methodol- ogy on a large and complex project. Your manager has just read the latest article in Computerworld that advo- cates replacing this methodology with the Unifi ed Process and comes to you requesting you to switch. What do you say?

L. Suppose you are an analyst working for a small com- pany to develop an accounting system. Would you use the Unifi ed Process to develop the system, or would you prefer one of the other approaches? Why?

M. Suppose you are an analyst developing a new infor- mation system to automate the sales transactions and manage inventory for each retail store in a large chain. Th e system would be installed at each store and exchange data with a mainframe computer at the company’s head offi ce. Would you use the Unifi ed Process to develop the system, or would you prefer one of the other approaches? Why?

25. What is meant by polymorphism when applied to object-oriented systems?

26. Compare and contrast dynamic and static binding. 27. What is a use case? 28. What is meant by use-case driven? 29. What is the Unifi ed Modeling Language? 30. Who is the Object Management Group? 31. What is the primary purpose of structure diagrams?

Give some examples of structure diagrams. 32. For what are behavior diagrams used? Give some

examples of behavior diagrams.

33. Why is it important for an OOSAD approach to be architecture-centric?

34. What does it mean for an OOSAD approach to be incremental and iterative?

35. What are the phases and workfl ows of the Unifi ed Process?

36. Compare the phases of the Unifi ed Process with the phases of the waterfall model.

37. Which phase in the SDLC is most important? Why? 38. Describe the major elements and issues with an object-

oriented approach to developing information systems.

Minicases  39

N. Suppose you are an analyst working for a small com- pany to develop an accounting system. What type of methodology would you use? Why?

O. Suppose you are an analyst developing a new execu- tive information system intended to provide key stra- tegic information from existing corporate databases to senior executives to help in their decision making. What type of methodology would you use? Why?

P. Investigate the Unifi ed Modeling Language on the Web. Write a paragraph news brief describing the current state of the UML. (Hint: A good website with which to begin is www.uml.org.)

Q. Investigate the Object Management Group (OMG) on the Web. Write a report describing the purpose of the OMG and what it is involved with besides the UML. (Hint: A good website with which to begin is www.omg.org.)

R. Using the Web, fi nd a set of CASE tools that support the UML. A couple of examples include Poseidon, Rational Rose, and Visual Paradigm. Find at least two more. Write a short report describing how well they support the UML, and make a recommendation as to which one you believe would be best for a project team to use in developing an object-oriented information system using the UML.

MINICASES

1. Barbara Singleton, manager of western regional sales at the WAMAP Company, requested that the IS department develop a sales force management and tracking system that would enable her to better mon- itor the performance of her sales staff . Unfortunately, owing to the massive backlog of work facing the IS department, her request was given a low priority. Aft er six months of inaction by the IS department, Barbara decided to take matters into her own hands. Based on the advice of friends, Barbara purchased simple database soft ware and constructed a sales force management and tracking system on her own.

Although Barbara’s system has been “completed” for about six weeks, it still has many features that do not work correctly, and some functions are full of errors. Barbara’s assistant is so mistrustful of the system that she has secretly gone back to using her old paper-based system, because it is much more reliable.

Over dinner one evening, Barbara complained to a systems analyst friend, “I don’t know what went wrong with this project. It seemed pretty simple to me. Th ose IS guys wanted me to follow this elaborate set of steps and tasks, but I didn’t think all that really applied to a PC-based system. I just thought I could build this system and tweak it around until I got what I wanted without all the fuss and bother of the meth- odology the IS guys were pushing. I mean, doesn’t that just apply to their big, expensive systems?”

Assuming you are Barbara’s systems analyst friend, how would you respond to her complaint?

2. Marcus Weber, IS project manager at ICAN Mutual Insurance Co., is reviewing the staffi ng arrangements for his next major project, the development of an expert system-based underwriter’s assistant. Th is new

system will involve a whole new way for the under- writers to perform their tasks. Th e underwriter’s assis- tant system will function as sort of an underwriting supervisor, reviewing key elements of each applica- tion, checking for consistency in the underwriter’s decisions, and ensuring that no critical factors have been overlooked. Th e goal of the new system is to improve the quality of the underwriters’ decisions and to improve underwriters’ productivity. It is expected that the new system will substantially change the way the underwriting staff do their jobs.

Marcus is dismayed to learn that because of budget constraints, he must choose between one of two availa- ble staff members. Barry Filmore has had considerable experience and training in individual and organiza- tional behavior. Barry has worked on several other projects in which the end users had to make signifi cant adjustments to the new system, and Barry seems to have a knack for anticipating problems and smoothing the transition to a new work environment. Marcus had hoped to have Barry’s involvement in this project.

Marcus’s other potential staff member is Kim Dan- ville. Prior to joining ICAN Mutual, Kim had con- siderable work experience with the expert system technologies that ICAN has chosen for this expert system project. Marcus was counting on Kim to help integrate the new expert system technology into ICAN’s systems environment, and also to provide on-the-job training and insights to the other develop- ers on this team.

Given that Marcus’s budget will only permit him to add Barry or Kim to this project team, but not both, what choice do you recommend for him? Justify your answer.

4 0 C h a p t e r 1   Introduction to Systems Analysis and Design

3. Joe Brown, the president of Roanoke Manufacturing, requested that Jack Jones, the MIS department man- ager, investigate the viability of selling their products over the Web. Currently, the MIS department is still using an IBM mainframe as their primary deploy- ment environment. As a fi rst step, Jack contacted his friends at IBM to see if they had any suggestions as to how Roanoke Manufacturing could move toward sup- porting sales in an electronic commerce environment while keeping their mainframe as their main system. His friends explained that IBM (www.ibm.com) now supports Java and Linux on their mainframes. Jack has also learned that IBM owns Rational (www-01.ibm. com/soft ware/rational/), the creator of the UML and the Unifi ed Process. Jack’s friends suggested that Jack investigate using object-oriented systems as a basis for

developing the new system. Th ey also suggested that using the Rational Unifi ed Process (RUP), Java, and vir- tual Linux machines on his current mainframe as a way to support the move toward a distributed electronic commerce system would protect his current investment in his legacy systems while allowing the new system to be developed in a more modern manner. Even though Jack’s IBM friends were very persuasive, Jack is still a little wary about moving his operation from a struc- tured systems approach to this new object-oriented approach. Assuming that you are one of Jack’s IBM friends, how would you convince him to move toward using an object-oriented systems development method, such as RUP, and using Java and Linux as a basis for developing and deploying the new system on Roanoke Manufacturing’s current mainframe?

This chapter primarily describes the project management workfl ow of the Unifi ed Process. Th e fi rst step in the process is to identify a project that will deliver value to the business and to create a system request that provides basic information about the proposed system. Second, the analysts perform a feasibility analysis to determine the technical, economic, and organizational feasibility of the system; if appropriate, the system is selected and the develop- ment project begins. Th ird, the project manager estimates the functionality of the project and identifi es the tasks that need to be performed. Fourth, the manager staff s the project. Finally, the manager identifi es the tools, standards, and process to be used; identifi es opportunities for reuse; determines how the current project fi ts into the portfolio of projects currently under development; and identifi es opportunities to update the overall structure of the fi rm’s port- folio of systems current in use.

OBJECTIVES

■ Understand the importance of linking the information system to business needs. ■ Be able to create a system request. ■ Understand how to assess technical, economic, and organizational feasibility. ■ Be able to perform a feasibility analysis. ■ Understand how projects are selected in some organizations. ■ Become familiar with work breakdown structures, Gantt charts, and network diagrams. ■ Become familiar with use-case–driven eff ort estimation. ■ Be able to create an iterative project workplan. ■ Understand how to manage the scope, refi ne the estimates, and manage the risk

of a project. ■ Become familiar with how to staff a project. ■ Understand how the environment and infrastructure workfl ows interact with

the project management workfl ow.

INTRODUCTION Most projects occurring in people’s lives, such as weddings or graduation celebrations, require planning and management. Months are spent in advance identifying and per- forming all the tasks that need to get done, such as sending out invitations and selecting a menu, and time and money are carefully allocated among them. Along the way, decisions are recorded, problems are addressed, and changes are made. Th e increasing popularity of the party planner, a person whose sole job is to coordinate a party, suggests how tough this job can be. In the end, the success of any party has a lot to do with the eff ort that went into planning along the way. System development projects can be much more complicated than the projects we encounter in our personal lives—usually, more people are involved (e.g., the

41

C H A P T E R 2

Project Management

4 2 C h a p t e r 2   Project Management

organization), the costs are higher, and more tasks need to be completed. Owing to the complexity of soft ware and soft ware development, it is virtually impossible to “know” all of the possible things that could happen during system development projects. Th erefore, it is not surprising that “party planners” exist for information systems projects: Th ey are called project managers.

Project management is the process of planning and controlling the development of a system within a specifi ed time frame at a minimum cost with the right functionality.1 In general, a project is a set of activities with a starting point and an ending point meant to create a system that brings value to the business. A project manager has the primary respon- sibility for managing the hundreds of tasks and roles that need to be carefully coordinated. Today, project management is an actual profession, and analysts spend years working on projects before tackling the management of them. However, in many cases, unreasonable demands set by project sponsors and business managers can make project management very diffi cult. Too oft en, the approach of the holiday season, the chance at winning a proposal with a low bid, or a funding opportunity pressures project managers to promise systems long before they are able to deliver them. Th ese overly optimistic timetables are thought to be one of the biggest problems that projects face; instead of pushing a project forward faster, they result in delays. Another source is the changing nature of information technology. An innovation in information technology may look so attractive that organizations embrace projects using this technology without assessing whether the technology adds value to the organization; instead the technology itself seems important in its own right. Problems can usually be traced back to the very beginning of the development of the system, where too little attention was given to identifying the business value and understanding the risks asso- ciated with the project.

During the inception phase of the Unifi ed Process of a new systems development pro- ject, someone—a manager, staff member, sales representative, or systems analyst—typically identifi es some business value that can be gained from using information technology. New systems development projects should start from a business need or opportunity. Many ideas for new systems or improvements to existing ones arise from the application of a new tech- nology, but an understanding of technology is usually secondary to a solid understanding of the business and its objectives. Th is does not mean that technical people should not recom- mend new systems projects. In fact, the ideal situation is for both IT people (i.e., the experts in systems) and business people (i.e., the experts in business) to work closely to fi nd ways for technology to support business needs. In this way, organizations can leverage the exciting innovative technologies that are available while ensuring that projects are based upon real business objectives, such as increasing sales, improving customer service, and decreasing operating expenses. Ultimately, information systems need to aff ect the organization’s bot- tom line (in a positive way!). To ensure that a real business need is being addressed, the aff ected business organization (called the project sponsor), proposes the new systems devel- opment project using a system request. Th e system request eff ectively kicks off the inception

1 For a very good comprehensive description of project management for information systems, see R.K. Wysocki, Eff ective Project Management: Traditional, Agile, Extreme, 5th Ed. (Indianapolis, IN: Wiley Publishing, 2009). Also, the Project Management Institute (www.pmi.org) and the Information Systems Community of Practice of the Project Management Institute (is.vc.pmi.org) have valuable resources on information systems pro- ject management. Finally, the following are good books on project management for object-oriented projects: G. Booch, Object Solutions: Managing the Object-Oriented Project (Menlo Park, CA: Addison-Wesley, 1996); M. R. Cantor, Object-Oriented Project Management with UML (New York: Wiley, 1998); A. Cockburn, Surviving Object-Oriented Projects: A Manager’s Guide (Reading, MA: Addison-Wesley, 1998); I. Jacobson, G. Booch, and J. Rumbaugh, Th e Unifi ed Soft ware Development Process (Reading, MA: Addison-Wesley, 1999); W. Royce, Soft ware Project Management: A Unifi ed Framework (Reading, MA: Addison-Wesley, 1998).

Project Identifi cation  43

phase for the new systems development project. Th e request is forwarded to an approval committee for consideration. Th e approval committee reviews the request and makes an initial determination of whether to investigate the proposal or not. If the committee initially approves the request, the systems development team gathers more information to determine the feasibility of the project.

A feasibility analysis plays an important role in deciding whether to proceed with an information systems development project. It examines the technical, economic, and organi- zational pros and cons of developing the system, and it gives the organization a slightly more detailed picture of the advantages of investing in the system as well as any obstacles that could arise. In most cases, the project sponsor works closely with the development team to develop the feasibility analysis. Once the feasibility analysis has been completed, it is submitted to the approval committee, along with a revised system request. Th e committee then decides whether to approve the project, decline the project, or table it until additional information is available. Projects are selected by weighing risks and returns and by making trade-off s at the organizational level.

Once the committee has approved a project, the development team must carefully plan for the actual development of the system. Because we are following a Unifi ed Process-based approach, the systems development workplan will evolve throughout the development pro- cess. Given this evolutionary approach, one critical success factor for project management is to start with a realistic assessment of the work that needs to be accomplished and then man- age the project according to that assessment. Th is can be achieved by carefully creating and managing the workplan, estimating the eff ort to develop the system, staffi ng the project, and coordinating project activities.

In addition to covering the above material, this chapter also covers three traditional pro- ject management tools that are very useful to manage object-oriented systems development projects: work breakdown structures, Gantt charts, and network diagrams.

PROJECT IDENTIFICATION A project is identifi ed when someone in the organization identifi es a business need to build a system. Th is could occur within a business unit or IT, come from a steering committee charged with identifying business opportunities, or evolve from a recommendation made by external consultants. Examples of business needs include supporting a new marketing campaign, reaching out to a new type of customer, or improving interactions with suppliers. Sometimes, needs arise from some kind of “pain” within the organization, such as a drop in market share, poor customer service levels, or increased competition. Other times, new busi- ness initiatives and strategies are created, and a system is required to enable them.

Business needs also can surface when the organization identifi es unique and compet- itive ways of using IT. Many organizations keep an eye on emerging technology, which is technology that is still being developed and is not yet viable for widespread business use. For example, if companies stay abreast of technology such as the augmented reality, games, smart cards, and mobile devices, they can develop business strategies that leverage the capabilities of these technologies and introduce them into the marketplace as a fi rst mover. Ideally, they can take advantage of this fi rst-mover advantage by making money and continuing to innovate while competitors trail behind.

Th e project sponsor is someone who recognizes the strong business need for a system and has an interest in seeing the system succeed. He or she will work throughout the development process to make sure that the project is moving in the right direction from the perspective of the

4 4 C h a p t e r 2   Project Management

business. Th e project sponsor serves as the primary point of contact for the system. Usually, the sponsor of the project is from a business function, such as marketing, accounting, or fi nance; however, members of the IT area also can sponsor or cosponsor a project.

The size or scope of a project determines the kind of sponsor needed. A small departmental system might require sponsorship from only a single manager, whereas a large organizational initiative might need support from the entire senior management team and even the CEO. If a project is purely technical in nature (e.g., improvements to the existing IT infrastructure or research into the viability of an emerging technology), then sponsorship from IT is appropriate. When projects have great importance to the business yet are technically complex, joint sponsorship by both the business and IT may be necessary.

Th e business need drives the high-level business requirements for the system. Requirements are what the information system will do, or the functionality it will contain. Th ey need to be explained at a high level so that the approval committee and, ultimately, the project team understand what the business expects from the fi nal product. Business requirements are the features and capabilities the information system will have to include, such as the ability to collect customer orders online or the ability for suppliers to receive inventory information as orders are placed and sales are made.

Th e project sponsor also should have an idea of the business value to be gained from the system, both in tangible and intangible ways. Tangible value can be quantifi ed and measured easily (e.g., 2 percent reduction in operating costs). An intangible value results from an intui- tive belief that the system provides important, but hard-to-measure, benefi ts to the organiza- tion (e.g., improved customer service or a better competitive position).

Once the project sponsor identifi es a project that meets an important business need and he or she can identify the system’s business requirements and value, it is time to formally initiate the project. In most organizations, project initiation begins with a document called a system request.

System Request A system request is a document that describes the business reasons for building a system and the value that the system is expected to provide. Th e project sponsor usually completes this form as part of a formal system project selection process within the organization. Most system requests include fi ve elements: project sponsor, business need, business require- ments, business value, and special issues. Th e sponsor describes the person who will serve as the primary contact for the project, and the business need presents the reasons prompting the project. Th e business requirements of the project refer to the business capabilities that the system will need to have, and the business value describes the benefi ts that the organization should expect from the system. Special issues are included on the document as a catch-all for other information that should be considered in assessing the project. For example, the project may need to be completed by a specifi c deadline. Project teams need to be aware of any special circumstances that could aff ect the outcome of the system. Figure 2-1 shows a template for a system request.

Th e completed system request is submitted to the approval committee for consideration. Th is approval committee could be a company steering committee that meets regularly to make information systems decisions, a senior executive who has control of organizational resources, or any other decision-making body that governs the use of business investments. Th e committee reviews the system request and makes an initial determination, based on the information provided, of whether to investigate the proposal or not. If so, the next step is to conduct a feasibility analysis.

Feasibility Analysis  45

FEASIBILITY ANALYSIS Once the need for the system and its business requirements have been defi ned, it is time to create a more detailed business case to better understand the opportunities and limitations associated with the proposed project. Feasibility analysis guides the organization in determin- ing whether or not to proceed with a project. Feasibility analysis also identifi es the important risks associated with the project that must be addressed if the project is approved. As with the system request, each organization has its own process and format for the feasibility analysis, but most include three types: technical feasibility, economic feasibility, and organizational feasibility. Th e results of these analyses are combined into a feasibility study, which is given to the approval committee (see Figure 2-2).

Although we now discuss feasibility analysis within the context of initiating a project, most project teams will revise their feasibility study throughout the development process and revisit its contents at various checkpoints during the project. If at any point the project’s risks and limitations outweigh its benefi ts, the project team may decide to cancel the project or make necessary improvements.

Technical Feasibility Th e fi rst type of feasibility analysis addresses the technical feasibility of the project: the extent to which the system can be successfully designed, developed, and installed by the IT group.

System Request—Name of Project

Project Sponsor: Name of project sponsor

Business Need: Short description of business need

Business Requirements: Description of business requirements

Business Value: Expected value that the system will provide

Special Issues or Constraints: Any additional information that may be relevant to the stakeholders

FIGURE 2-1 System Request Template

Technical Feasibility: Can We Build It?

• Familiarity with Functional area: Less familiarity generates more risk

• Familiarity with Technology: Less familiarity generates more risk

• Project Size: Large projects have more risk

• Compatibility: The harder it is to integrate the system with the company’s existing technology, the higher the risk

Economic Feasibility: Should We Build It?

• Development costs

• Annual operating costs

• Annual benefi ts (cost savings and revenues)

• Intangible costs and benefi ts

Organizational Feasibility: If We Build It, Will They Come?

• Is the project strategically aligned with the business?

• Project champion(s)

• Senior management

• Users

• Other stakeholders

FIGURE 2-2 Feasibility Analysis Assessment Factors

4 6 C h a p t e r 2   Project Management

Technical feasibility analysis is in essence a technical risk analysis that strives to answer this question: Can we build it?2

Many risks can endanger the successful completion of a project. First is the users’ and analysts’ lack of familiarity with the functional area. When analysts are unfamiliar with the business functional area, they have a greater chance of misunderstanding the users or of missing opportunities for improvement. Th e risk increases dramatically when the users themselves are less familiar with an application, such as with the development of a system to support a business innovation. In general, developing new systems is riskier than producing extensions to an existing system because existing systems tend to be better understood.

Familiarity with the technology is another important source of technical risk. When a system uses technology that has not been used before within the organization, there is a greater chance that problems will occur and delays will be incurred because of the need to learn how to use the technology. Risk increases dramatically when the technology itself is new.

Project size is an important consideration, whether measured as the number of people on the development team, the length of time it will take to complete the project, or the number of distinct features in the system. Larger projects present more risk, both because they are more complicated to manage and because there is a greater chance that important system require- ments will be overlooked or misunderstood. Furthermore, the extent to which the project is highly integrated with other systems can cause problems because complexity increases when many systems must work together.

Finally, project teams need to consider the compatibility of the new system with the technology that already exists in the organization. Systems are rarely built in a vacuum—they are built in organizations that already have numerous systems in place. New technology and applications need to integrate with the existing environment for many reasons. Th ey might rely on data from existing systems, they might produce data that feed other applications, and they might have to use the company’s existing communications infrastructure.

Th e assessment of a project’s technical feasibility is not cut and dried because in many cases, some interpretation of the underlying conditions is needed. One approach is to com- pare the project under consideration with prior projects undertaken by the organization. Another option is to consult with experienced IT professionals in the organization or exter- nal IT consultants; oft en they are able to judge whether a project is feasible from a technical perspective.

Economic Feasibility Th e second element of a feasibility analysis is to perform an economic feasibility analy- sis (also called a cost–benefi t analysis), which identifi es the fi nancial risk associated with the project. It attempts to answer the question, Should we build the system? Economic feasibility is determined by identifying costs and benefi ts associated with the system, assign- ing values to them, and then calculating the cash fl ow and return on investment for the project. Th e more expensive the project, the more rigorous and detailed the analysis should be. Figure 2-3 lists the steps in performing a cost–benefi t analysis; each step is described in the following sections.

2 We use build it in the broadest sense. Organizations can also choose to buy a commercial soft ware package and install it, in which case, the question might be, Can we select the right package and successfully install it?

Feasibility Analysis  47

Identifying Costs and Benefi ts Th e fi rst task when developing an economic feasibility anal- ysis is to identify the kinds of costs and benefi ts the system will have and list them along the left -hand column of a spreadsheet. Figure 2-4 lists examples of costs and benefi ts that may be included.

1. Identifi ng Costs and Benefi ts List the tangible costs and benefi ts for the project. Include both one-time and recurring costs.

2. Assigning Values to Costs and Benefi ts Work with business users and IT professionals to create numbers for each of the costs and benefi ts. Even intangibles should be valued if at all possible.

3. Determining Cash Flow Project what the costs and benefi ts will be over a period of time, usually three to fi ve years. Apply a growth rate to the numbers, if necessary.

4. Determining Net Present Value (NPV) Calculate what the value of future costs and ben- efi ts are if measured by today’s standards. You will need to select a rate of growth to apply the NPV formula.

5. Determining Return on Investment (ROI) Calculate how much money the organization will receive in return for the investment it will make using the ROI formula.

6. Determining the Break-Even Point Find the fi rst year in which the system has greater benefi ts than costs. Apply the break-even formula using fi gures from that year. This will help you understand how long it will take before the system creates real value for the organization.

7. Graphing the Break-Even Point Plot the yearly costs and benefi ts on a line graph. The point at which the lines cross is the break-even point.

FIGURE 2-3 Steps for Con- ducting Economic Feasibility

FIGURE 2-4 Example Costs and Benefi ts for Eco- nomic Feasibility

Development Team Salaries Software Upgrades

Consultant Fees Software Licensing Fees

Development Training Hardware Repairs

Hardware and Software Hardware Upgrades

Vendor Installation Operational Team Salaries

Offi ce Space and Equipment Communications Charges

Data Conversion Costs User Training

Increased Sales Increased Market Share

Reductions in Staff Increased Brand Recognition

Reductions in Inventory Higher Quality Products

Reductions in IT Costs Improved Customer Service

Better Supplier Prices Better Supplier Relations

Development Costs Operational Costs

Tangible Benefi ts Intangible Benefi ts

4 8 C h a p t e r 2   Project Management

Costs and benefi ts can be broken down into four categories: development costs, oper- ational costs, tangible benefi ts, and intangibles. Development costs are tangible expenses incurred during the construction of the system, such as salaries for the project team, hard- ware and soft ware expenses, consultant fees, training, and offi ce space and equipment. Development costs are usually thought of as one-time costs. Operational costs are tangible costs required to operate the system, such as the salaries for operations staff , soft ware licens- ing fees, equipment upgrades, and communications charges. Operational costs are usually thought of as ongoing costs.

Revenues and cost savings are the tangible benefi ts the system enables the organization to collect or the tangible expenses the system enables the organization to avoid. Tangible benefi ts could include increased sales, reductions in staff , and reductions in inventory. Of course, a project also can aff ect the organization’s bottom line by reaping intangible benefi ts or incurring intangible costs. Intangible costs and benefi ts are more diffi cult to incorporate into the economic feasibility because they are based on intuition and belief rather than “hard numbers.” Nonetheless, they should be listed in the spreadsheet along with the tan- gible items.

Assigning Values to Costs and Benefi ts Once the types of costs and benefi ts have been identifi ed, analysts assign specifi c dollar values to them. Th is might seem impossible; how can someone quantify costs and benefi ts that haven’t happened yet? And how can those predictions be realistic? Although this task is very diffi cult, analysts have to do the best they can to come up with reasonable numbers for all the costs and benefi ts. Only then can the approval committee make an educated decision about whether or not to move ahead with the project.

Th e best strategy for estimating costs and benefi ts is to rely on the people who have the clearest understanding of them. For example, costs and benefi ts related to the technology or the project itself can be provided by the company’s IT group or external consultants, and business users can develop the numbers associated with the business (e.g., sales projections, order levels). Analysts can also consider past projects, industry reports, and vendor infor- mation, although these approaches probably will be a bit less accurate. All the estimates will probably be revised as the project proceeds.

Sometimes it is acceptable for analysts to list intangible benefi ts, such as improved customer service, without assigning a dollar value, whereas other times they have to make estimates regarding the value of an intangible benefi t. If at all possible, they should quantify intangible costs or benefi ts. Otherwise, it will not be apparent whether the costs and benefi ts have been realized. Consider a system that is supposed to improve customer service. Th is is intangible, but assume that the greater customer service will decrease the number of customer complaints by 10 percent each year over three years and that $200,000 is spent on phone charges and phone operators who handle complaint calls. Suddenly there are some very tangible numbers with which to set goals and measure the original intangible benefi t.

Figure 2-5 shows costs and benefi ts along with assigned dollar values. Notice that the customer service intangible benefi t has been quantifi ed based on fewer customer complaint phone calls. Th e intangible benefi t of being able to off er services that competitors currently off er was not quantifi ed, but it was listed so that the approval committee will consider the benefi t when assessing the system’s economic feasibility.

Determining Cash Flow A formal cost–benefi t analysis usually contains costs and benefi ts over a selected number of years (usually three to fi ve years) to show cash fl ow over time

Feasibility Analysis  49

(see Figure 2-6). When using this cash-fl ow method, the years are listed across the top of the spreadsheet to represent the time period for analysis, and numeric values are entered in the appropriate cells within the spreadsheet’s body. Sometimes fi xed amounts are entered into the columns. For example, Figure 2-6 lists the same amount for customer complaint calls and inventory costs for all fi ve years. Usually amounts are augmented by some rate of growth to adjust for infl ation or business improvements, as shown by the 6 percent increase that is added to the sales numbers in the sample spreadsheet. Finally, totals are added to determine what the overall benefi ts will be; the higher the overall total, the greater the economic feasi- bility of the solution.

Determining Net Present Value and Return on Investment Th ere are several problems with the cash-fl ow method—(1) it does not consider the time value of money (i.e., a dollar today is not worth a dollar tomorrow), and (2) it does not show the overall “bang for the buck” that the organization is receiving from its investment. Th erefore, some project teams add additional calculations to the spreadsheet to provide the approval committee with a more- accurate picture of the project’s worth.

Net present value (NPV) is used to compare the present value of future cash fl ows with the investment outlay required to implement the project. For example, if you have a friend who owes you a dollar today but instead gives you a dollar three years from now, you’ve been had! Given a 10 percent increase in value, you’ll be receiving the equivalent of 75 cents in today’s terms.

NPV can be calculated in many diff erent ways, some of which are extremely complex. Figure 2-7 shows a basic calculation that can be used in your cash fl ow analysis to get more

Benefi tsa

Increased sales 500,000

Improved customer serviceb 70,000

Reduced inventory costs 68,000

Total benefi ts 638,000

Development costs

2 servers @ $125,000 250,000

Printer 100,000

Software licenses 34,825

Server software 10,945

Development labor 1,236,525

Total development costs 1,632,295

Operational costs

Hardware 54,000

Software 20,000

Operational labor 111,788

Total operational costs 185,788

Total costs 1,818,083

a An important yet intangible benefi t will be the ability to offer services that our competitors currently offer. b Customer service numbers have been based on reduced costs for customer complaint phone calls.

FIGURE 2-5 Assigning Values to Costs and Benefi ts

relevant values. In Figure 2-6, the present value of the costs and benefi ts are calculated fi rst (i.e., they are shown at a discounted rate). Th en, net present value is calculated, and it shows the discounted rate of the combined costs and benefi ts.

Th e return on investment (ROI) is a calculation listed somewhere on the spreadsheet that measures the amount of money an organization receives in return for the money it spends. A high ROI results when benefi ts far outweigh costs. ROI is determined by fi nding the total benefi ts less the costs of the system and dividing that number by the total costs of the system (see Figure 2-7). ROI can be determined per year or for the entire project over a period of time. One drawback of ROI is that it considers only the end points of the investment, not the cash fl ow in between, so it should not be used as the sole indicator of a project’s worth. Th e spreadsheet in Figure 2-6 shows an ROI fi gure.

Determining the Break-Even Point If the project team needs to perform a rigorous cost– benefi t analysis, it might need to include information about the length of time before the project will break even, or when the returns will match the amount invested in the project.

FIGURE 2-6 Cost–Benefi t Analysis

Increased sales 500,000 530,000 561,800 595,508 631,238

Reduction in customer complaint calls 70,000 70,000 70,000 70,000 70,000

Reduced inventory costs 68,000 68,000 68,000 68,000 68,000

TOTAL BENEFITS: 638,000 668,000 699,800 733,508 769,238

PV OF BENEFITS: 619,417 629,654 640,416 651,712 663,552 3,204,752

PV OF ALL BENEFITS: 619,417 1,249,072 1,889,488 2,541,200 3,204,752

2 Servers @ $125,000 250,000 0 0 0 0

Printer 100,000 0 0 0 0

Software licenses 34,825 0 0 0 0

Server software 10,945 0 0 0 0

Development labor 1,236,525 0 0 0 0

TOTAL DEVELOPMENT COSTS: 1,632,295 0 0 0 0

Hardware 54,000 81,261 81,261 81,261 81,261

Software 20,000 20,000 20,000 20,000 20,000

Operational labor 111,788 116,260 120,910 125,746 130,776

TOTAL OPERATIONAL COSTS: 185,788 217,521 222,171 227,007 232,037

TOTAL COSTS: 1,818,083 217,521 222,171 227,007 232,037

PV OF COSTS: 1,765,129 205,034 203,318 201,693 200,157 2,575,331

PV OF ALL COSTS: 1,765,129 1,970,163 2,173,481 2,375,174 2,575,331

TOTAL PROJECT BENEFITS COSTS: (1,180,083) 450,479 477,629 506,501 537,201

YEARLY NPV: (1,145,712) 424,620 437,098 450,019 463,395 629,421

CUMULATIVE NPV: (1,145,712) (721,091) (283,993) 166,026 629,421

RETURN ON INVESTMENT: 24.44% (629,421/2,575,331)

BREAK-EVEN POINT: 3.63 years [break-even occurs in year 4; (450,019 2 166,026)/450,019 5 0.63]

INTANGIBLE BENEFITS: This service is currently provided by competitors Improved customer satisfaction

2015 2016 2017 2018 2019 Total

5 0 C h a p t e r 2   Project Management

Th e greater the time it takes to break even, the riskier the project. Th e break-even point is determined by looking at the cash fl ow over time and identifying the year in which the ben- efi ts are larger than the costs (see Figure 2-6). Th en, the diff erence between the yearly and cumulative NPV for that year is divided by the yearly NPV to determine how far into the year the break-even point will occur. See Figure 2-7 for the break-even calculation. Th e break-even point also can be depicted graphically, as shown in Figure 2-8. Th e cumulative present value of the costs and benefi ts for each year is plotted on a line graph; the point at which the lines cross is the break-even point.

Organizational Feasibility Th e fi nal type of feasibility analysis is to assess the organizational feasibility of the system, how well the system ultimately will be accepted by its users and incorporated into the ongo- ing operations of the organization. Th ere are many organizational factors that can have an

Present Value (PV) The amount of an investment today Amount compared to that same amount in the future, taking into account infl ation and time.

(1 1 interest rate)n

n 5 number of years in future

Net Present Value (NPV) The present value of benefi t less the present PV Benefi ts 2 PV Costs value of costs.

Return on Investment (ROI) The amount of revenues or cost savings results Total benefi ts 2 Total costs from a given investment.

Total costs

Break-Even Point The point in time at which the costs of the Yearly NPV* 2 Cumulative NPV project equal the value it has delivered.

Yearly NPV*

*Use the Yearly NPV amount from the fi rst year in which the project has a positive cash fl ow.

Add the above amount to the year in which the project has a positive cash fl ow.

Calculation Defi nition Formula

FIGURE 2-7 Financial Calculations Used for Cost–Benefi t Analysis

Break-even point 1 2 3 54

0

500,000

1,000,000

1,500,000

2,000,000

D o ll ar

s

2,500,000

3,500,000

Years

3,000,000 Costs Benefits

FIGURE 2-8 Break-Even Graph

Feasibility Analysis  51

eff ect on the project, and seasoned developers know that organizational feasibility can be the most diffi cult feasibility dimension to assess. In essence, an organizational feasibility analysis attempts to answer the question, If we build it, will they come?

One way to assess the organizational feasibility of the project is to understand how well the goals of the project align with business objectives. Strategic alignment is the fi t between the project and business strategy—the greater the alignment, the less risky the project will be from an organizational feasibility perspective. For example, if the marketing department has decided to become more customer focused, then a CRM project that produces integrated customer information would have strong strategic alignment with marketing’s goal. Many IT projects fail when the IT department initiates them, because there is little or no alignment with business unit or organizational strategies.

A second way to assess organizational feasibility is to conduct a stakeholder analysis.3 A stakeholder is a person, group, or organization that can aff ect (or will be aff ected by) a new system. In general, the most important stakeholders in the introduction of a new system are the project champion, system users, and organizational management (see Figure 2-9), but systems sometimes aff ect other stakeholders as well. For example, the IS department can be a stakeholder of a system because IS jobs or roles may be changed signifi cantly aft er its implementation.

Th e champion is a high-level, non–information systems executive who is usually the project sponsor who created the system request. Th e champion supports the project with time, resources (e.g., money), and political support within the organization by communicat- ing the importance of the system to other organizational decision makers. More than one champion is preferable because if the champion leaves the organization, the support could leave as well.

Whereas champions provide day-to-day support for the system, organizational manage- ment support conveys to the rest of the organization the belief that the system will make a

Champion A champion: • Make a presentation about the objectives of the • Initiates the project project and the proposed benefi ts to those executives • Promotes the project who will benefi t directly from the system • Allocates his or her time to project • Create a prototype of the system to demonstrate its • Provides resources potential value

Organizational Organizational managers: • Make a presentation to management about the Management • Know about the project objectives of the project and the proposed benefi ts • Budget enough money for the project • Market the benefi ts of the system using memos and • Encourage users to accept and use the system organizational newsletters • Encourage the champion to talk about the project

with his or her peers

System Users Users: • Assign users offi cial roles on the project team • Make decisions that infl uence the project • Assign users specifi c tasks to perform with clear • Perform hands-on activities for the project deadlines • Ultimately determine whether the project is • Ask for regular feedback from users (e.g., at successful by using or not using the system weekly meetings)

Role Techniques for Improvement

FIGURE 2-9 Some Important Stakeholders for Organizational Feasibility

5 2 C h a p t e r 2   Project Management

3 A good book that presents a series of stakeholder analysis techniques is R. O. Mason and I. I. Mittroff , Challenging Strategic Planning Assumptions: Th eory, Cases, and Techniques (New York: Wiley, 1981).

valuable contribution and that necessary resources will be made available. Ideally, manage- ment should encourage people in the organization to use the system and to accept the many changes that the system will likely create.

A third important group of stakeholders are the system users who ultimately use the system once it has been installed in the organization. Too oft en, the project team meets with users at the beginning of a project and then disappears until aft er the system is created. In this situation, rarely does the fi nal product meet the expectations and needs of those who are supposed to use it because needs change and users become savvier as the project progresses. User participation should be promoted throughout the development process by getting users involved in the development of the system (e.g., performing tasks, providing feedback, making decisions).

Finally, the feasibility study helps organizations make wiser investments by forcing pro- ject teams to consider technical, economic, and organizational factors that can aff ect their projects. It protects IT professionals from criticism by keeping the business units educated about decisions and positioned as the leaders in the decision-making process. Remember, the feasibility study should be revised several times during the project at points where the project team makes critical decisions about the system (e.g., before each iteration of the development process).

PROJECT SELECTION Once the feasibility analysis has been completed, it is submitted to the approval committee, along with a revised system request. Th e committee then decides whether to approve the project, decline the project, or table it until additional information is available. At the pro- ject level, the committee considers the value of the project by examining the business need (found in the system request) and the risks of building the system (presented in the feasibility analysis).

Before approving the project, however, the committee also considers the project from an organizational perspective; it has to keep in mind the company’s entire portfolio of projects. Th is way of managing projects is called portfolio management. Portfolio management takes into consideration the diff erent kinds of projects that exist in an organization—large and small, high risk and low risk, strategic and tactical. (See Figure 2-10 for the diff erent ways of

Size What is the size? How many people are needed to work on the project?

Cost How much will the project cost the organization?

Purpose What is the purpose of the project? Is it meant to improve the technical infrastructure? Support a current business strategy?

Improve operations? Demonstrate a new innovation?

Length How long will the project take before completion? How much time will go by before value is delivered to the business?

Risk How likely is it that the project will succeed or fail?

Scope How much of the organization is affected by the system? A department? A division? The entire corporation?

Return on investment How much money does the organization expect to receive in return for the amount the project costs?

FIGURE 2-10 Ways to Classify Projects

Project Selection  53

classifying projects.) A good project portfolio has the most appropriate mix of projects for the organization’s needs. Th e committee acts as portfolio manager with the goal of maximizing the cost–benefi t performance and other important factors of the projects in their portfolio. For example, an organization might want to keep high-risk projects to less than 20 percent of its total project portfolio.

Th e approval committee must be selective about where to allocate resources. Th is involves trade-off s in which the organization must give up something in return for something else to keep its portfolio well balanced. If there are three potentially high-payoff projects, yet all have very high risk, then perhaps only one of the projects will be selected. Also, there are times when a system at the project level makes good business sense, but it does not make sense at the organization level. Th us, a project may show a very strong ROI and support important business needs for a part of the company, but it is not selected. Th is could happen for many reasons—because there is no money in the budget for another system, the organ- ization is about to go through some kind of change (e.g., a merger), projects that meet the same business requirements already are under way, or the system does not align well with the current or future corporate strategy.

TRADITIONAL PROJECT MANAGEMENT TOOLS Before we get to actually creating a workplan that is suitable to manage and control an object-oriented systems development project, we need to introduce a set of project man- agement tools that have been used to successfully manage traditional soft ware development projects (and many other types of projects): a work-breakdown structure, a Gantt chart, and a network diagram. To begin with, we must fi rst understand what a task is. A task is a unit of work that will be performed by a member or members of the development team, such as feasibility analysis. Each task is described by information such as its name, start and com- pletion dates, person assigned to complete the task, deliverables, completion status, priority, resources needed, estimated time to complete the task, and the actual time it took to complete the task (see Figure 2-11). Th e fi rst thing a project manager must do is to identify the tasks that need to be accomplished and determine how long each task will take. Tasks and their identifi cation and documentation are the basis of all three of these tools. Once the tasks have been identifi ed and documented, they are organized within a work breakdown structure that is used to drive the creation of Gantt charts and network diagrams that can be used to graphi- cally portray a traditional workplan. Th ese techniques help a project manager understand and manage the project’s progress over time.

Name of the task Perform economic feasibility

Start date Jan 05, 2015

Completion date Jan 19, 2015

Person assigned to the task Project sponsor: Mary Smith

Deliverable(s) Cost-benefi t analysis

Completion status Open

Priority High

Resources that are needed Spreadsheet software

Estimated time 16 hours

Actual time 14.5 hours

Workplan Information Example

FIGURE 2-11 Task Information

5 4 C h a p t e r 2   Project Management

Work Breakdown Structures A project manager can use a structured, top-down approach whereby high-level tasks are fi rst defi ned and then broken down into subtasks. For example, Figure 2-12 shows a list of high- level tasks needed to implement a new IT training class. Some of the main steps in the process include identifying vendors, creating and administering a survey, and building new class- rooms. Each step is then broken down in turn and numbered in a hierarchical fashion. Th ere are eight subtasks (i.e., 7.1–7.8) for creating and administering a survey, and there are three subtasks (7.2.1–7.2.3) that make up the review initial survey task. A list of tasks hierarchically numbered in this way is called a work breakdown structure (WBS). Th e number of tasks and level of detail depend on the complexity and size of the project. At a minimum, the WBS must include the duration of the task, the current status of the task (i.e., open, complete), and the task dependencies, which occur when one task cannot be performed until another task is com- pleted. For example, Figure 2-12 shows that incorporating changes to the survey (task 7.4) takes a week to perform, but it cannot occur until aft er the survey is reviewed (task 7.2) and pilot tested (task 7.3). Key milestones, or important dates, are also identifi ed on the workplan.

Th ere are two basic approaches to organizing a traditional WBS: by development phase or by product. For example, if a fi rm decided that it needed to develop a website, the fi rm could create a WBS based on the inception, elaboration, construction, and transition phases of the Unifi ed Process. In this case, a typical task that would take place during incep- tion would be feasibility analysis. Th is task would be broken down into the diff erent types of feasibility analysis: technical, economic, and organizational. Each of these would be further broken down into a set of subtasks. Alternatively, the fi rm could organize the workplan along the lines of the diff erent products to be developed. For example, in the case of a web- site, the products could include applets, application servers, database servers, the various sets of Web pages to be designed, a site map, and so on. Th en these would be further decomposed

1 Identify vendors 2 Complete

2 Review training materials 6 1 Complete

3 Compare vendors 2 2 In Progress

4 Negotiate with vendors 3 3 Open

5 Develop communications information 4 1 In Progress

6 Disseminate information 2 5 Open

7 Create and administer survey 4 6 Open

7.1 Create initial survey 1 Open

7.2 Review initial survey 1 7.1 Open

7.2.1 Review by Director of IT Training 1 Open

7.2.2 Review by Project Sponsor 1 Open

7.2.3 Review by Representative Trainee 1 Open

7.3 Pilot test initial survey 1 7.1 Open

7.4 Incorporate survey changes 1 7.2, 7.3 Open

7.5 Create distribution list 0.5 Open

7.6 Send survey to distribution list 0.5 7.4, 7.5 Open

7.7 Send follow-up message 0.5 7.6 Open

7.8 Collect completed surveys 1 7.6 Open

8 Analyze results and choose vendor 2 4, 7 Open

9 Build new classrooms 11 1 In Progress

10 Develop course options 3 8, 9 Open

Task Duration Number Task Name (in weeks) Dependency Status

FIGURE 2-12 Work Breakdown Structure

Traditional Project Management Tools  55

into the diff erent tasks associated with the phases of the development process. Either way, once the overall structure is determined, tasks are identifi ed and included in the WBS. We return to the topic of WBSs and their use in iterative planning later in this chapter.

Gantt Chart A Gantt chart is a horizontal bar chart that shows the same task information as the project WBS but in a graphical way. Sometimes a picture really is worth a thousand words, and the Gantt chart can communicate the high-level status of a project much faster and easier than the WBS. Creating a Gantt chart is simple and can be done using a spreadsheet package, graphics soft ware, or a project management package.

First, tasks are listed as rows in the chart, and time is listed across the top in increments based on the needs of the projects (see Figure 2-13). A short project may be divided into

ID

1

2

3

4

5

Identify vendors

Review training materials Compare vendors

Negotiate with vendors Develop communications information Disseminate information

Create and administer survey Analyze results and choose

Build new classroom

Develop course options Budget Meeting

Software Installation

6

7

8

9

10

11

12

2 wks Wed 1/1/15

Wed 1/1/15

Wed 2/12/15

Wed 2/26/15

Wed 1/15/15

Wed 2/12/15

Wed 2/26/15

Wed 3/26/15

Wed 1/15/15

Wed 4/9/15

Wed 1/15/15

Tue 4/1/15

6 wks Barbara

Barbara

Barbara

Alan

Alan

Alan

Alan

Alan

David

D

2 wks

3 wks

4 wks

2 wks

4 wks

2 wks

11 wks

3 wks

2

3

1

5

6

4, 7

1

8, 9

1 day

1 day

Task Name Duration Start

Tue 1/14/15

Tue 2/11/15

Tue 2/25/15

Tue 3/8/15

Tue 2/11/15

Tue 2/25/15

Tue 3/25/15

Tue 4/8/15

Tue 4/1/15

Tue 4/29/15

Wed 1/15/15

Tue 4/1/15

Finish 12/29 1/5 1/12

1/15

4/1

1/19 1/26 2/2 2/9 2/16 2/23 3/2 3/9 3/16 3/23 3/30 4/6 4/13 4/20 4/27 Prede

January February March April M

FIGURE 2-13 Gantt Chart

5 6 C h a p t e r 2   Project Management

hours or days, whereas a medium-sized project may be represented using weeks or months. Horizontal bars are drawn to represent the duration of each task; the bar’s beginning and end mark exactly when the task will begin and end. As people work on tasks, the appropriate bars are fi lled in proportionately to how much of the task is fi nished. Too many tasks on a Gantt chart can become confusing, so it’s best to limit the number of tasks to around twenty or thirty. If there are more tasks, break them down into subtasks and create Gantt charts for each level of detail.

Th ere are many things a project manager can see quickly by looking at a Gantt chart. In addition to seeing how long tasks are and how far along they are, the project manager also can tell which tasks are sequential, which tasks occur at the same time, and which tasks overlap in some way. He or she can get a quick view of tasks that are ahead of schedule and behind schedule by drawing a vertical line on today’s date. If a bar is not fi lled in and is to the left of the line, that task is behind schedule.

Th ere are a few special notations that can be placed on a Gantt chart. Project mile- stones are shown using upside-down triangles or diamonds. Arrows are drawn between the task bars to show task dependencies. Sometimes, the names of people assigned to each task are listed next to the task bars to show what human resources have been allocated to the tasks.

Network Diagram A second graphical way to look at project workplan information is the network diagram that lays out the project tasks in a fl owchart (see Figure 2-14).

Program Evaluation and Review Technique (PERT) is a network analysis technique that can be used when the individual task time estimates are fairly uncertain. Instead of simply putting a point estimate for the duration estimate, PERT uses three time estimates: optimistic,

Software installation

12

Tue 4/1/15

1 day Tue

Tue 4/1/15

Budget meeting

11

Wed 1/15/15

1 day Wed

Wed 1/15/15

Identify vendors

1

Wed 1/1/15

2 wks Tue

Tue 1/14/15 Build new classroom

9

Wed 1/15/15

11 wks Tue

Tue 4/1/15

Compare vendors

3

Wed 2/12/15

2 wks Tue

Tue 2/25/15

Negotiate with vendors

4

Wed 2/26/15

3 wks Tue

Tue 3/18/15

Review training materials

2

Wed 1/1/15

6 wks Tue

Tue 2/11/15

Develop communications Information 5

Wed 1/15/15

4 wks Tue

Tue 2/11/15

Disseminate information

6

Wed 2/12/15

2 wks Tue

Tue 2/25/15

Create and administer survey 7

Wed 2/26/15

4 wks Tue

Tue 3/25/15

Analyze results and choose vendor 8

Wed 3/26/15

2 wks Tue

Tue 4/8/15

Develop course options

10

Wed 4/9/15

3 wks Tue

Tue 4/29/15

FIGURE 2-14 Network Diagram

Traditional Project Management Tools  57

most likely, and a pessimistic. It then combines the three estimates into a single weighted average estimate using the following formula:

PERT weighted average 5 optimistic estimate 1 (4 * most likely estimate)

1 pessimistic estimate

6

Th e network diagram is drawn as a node-and-arc type of graph that shows time estimates in the nodes and task dependencies on the arcs. Each node represents an individual task, and a line connecting two nodes represents the dependency between two tasks. Partially completed tasks are usually displayed with a diagonal line through the node, and completed tasks con- tain crossed lines.

Network diagrams are the best way to communicate task dependencies because they lay out the tasks in the order in which they need to be completed. Th e critical path method (CPM) simply allows the identifi cation of the critical path in the network. Th e critical path is the longest path from the project inception to completion. Th e critical path shows all the tasks that must be completed on schedule for a project as a whole to fi nish on schedule. If any tasks on the critical path take longer than expected, the entire project will fall behind. Each task on the critical path is a critical task, and they are usually depicted in a unique way; in Figure 2-14 they are shown with double borders (see tasks 5, 6, 7, 8, and 10). CPM can be used with or without PERT.

PROJECT EFFORT ESTIMATION Th e science (or art) of project management is in making trade-off s among three important con- cepts: the functionality of the system, the time to complete the project (when the project will be fi nished), and the cost of the project. Th ink of these three things as interdependent levers that the project manager controls throughout the development of the system. Whenever one lever is pulled, the other two levers are aff ected in some way. For example, if a project manager needs to readjust a deadline to an earlier date, then the only solutions are to decrease the functionality of the system or to increase costs by adding more people or having them work overtime. Oft en, a project manager has to work with the project sponsor to change the goals of the project, such as developing a system with less functionality or extending the deadline for the fi nal system, so that the project has reasonable goals that can be met. In the beginning of the project, the manager needs to estimate each of these levers and then continuously assess how to roll out the project in a way that meets the organization’s needs. Estimation is the process of assigning projected values for time and eff ort. Th e estimates developed at the start of a project are usually based on a range of possible values and gradually become more specifi c as the project moves forward. Th at is, the range of values for the inception phase will be much greater than for the transition phase.

Th e numbers used to calculate these estimates can be taken from projects with similar tasks and technologies or provided by experienced developers. Generally speaking, the num- bers should be conservative. A good practice is to keep track of the actual values for time and eff ort during the development process so that numbers can be refi ned along the way and the next project can benefi t from real data.

Th ere are a variety of ways to estimate the time required to build a system. Because the Unifi ed Process is use-case driven, we use an approach that is based on use cases: use-case points.4 Use-case points, originally developed by Gustav Karner of Objectory AB,5 are based

4 Th e material in this section is based on descriptions of use-case points contained in Raul R. Reed, Jr., Developing Applications with Java and UML (Reading, MA: Addison-Wesley, 2002); Geri Schneider and Jason P. Winters, Apply- ing Use Cases: A Practical Guide (Reading, MA: Addison-Wesley, 1998); Kirsten Ribu, “Estimating Object-Oriented Soft ware Projects with Use Cases” (Master’s thesis, University of Oslo, 2001). 5 Objectory AB was acquired by Rational in 1995 and Rational is now part of IBM.

5 8 C h a p t e r 2   Project Management

on unique features of use cases and object orientation. From a practical point of view, to estimate eff ort using use-case points, the use cases and the use-case diagram must have been created.6

Use-case models have two primary constructs: actors and use cases. An actor repre- sents a role that a user of the system plays, not a specifi c user. For example, a role could be secretary or manager. Actors can also represent other systems that will interact with the system under development. For use-case point estimation purposes, actors can be classifi ed as simple, average, or complex. Simple actors are separate systems with which the current system must communicate through a well-defi ned application program interface (API). Average actors are separate systems that interact with the current system using standard communication protocols, such as TCP/IP, FTP, or HTTP, or an external database that can be accessed using standard SQL. Complex actors are typically end users commu- nicating with the system. Once all of the actors have been categorized as being simple, average, or complex, the project manager counts the number of actors in each category and enters the values into the unadjusted actor-weighting table contained in the use-case point– estimation worksheet (see Figure 2-15). Th e project manager then computes the Unadjusted Actor Weight Total (UAW). Th is is computed by summing the individual results that were computed by multiplying the weighting factor by the number of actors of each type. For example, if we assume that the use-case diagram has zero simple, zero average, and four complex actors that interact with the system being developed, the UAW will equal 12 (see Figure 2-16).

A use case represents a major business process that the system will perform that benefi ts the actor(s) in some manner. Depending on the number of unique transactions that the use case must address, a use case can be categorized as being simple, average, or complex. A use case is classifi ed as simple if it supports one to three transactions, as average if it supports four to seven transactions, or as complex if it supports more than seven transactions. Once all of the use cases have been successfully categorized, the project manager enters the number of each type of use case into the unadjusted use-case weighting table contained in the use-case point–estimation worksheet (see Figure 2-15). By multiplying by the appropriate weights and summing the results, we get the value for the unadjusted use-case weight total (UUCW). For example, if we assume that we have three simple use cases, four average use cases, and one complex use case, the value for the unadjusted use-case weight total is 70 (see Figure 2-16). Next, the project manager computes the value of the unadjusted use-case points (UUCP) by simply summing the unadjusted actor weight total and the unadjusted use-case weight total. In this case the value of the UUCP equals 82 (see Figure 2-16).

Use-case point-based estimation also has a set of factors that are used to adjust the use-case point value. In this case, there are two sets of factors: technical complexity factors (TCFs) and environmental factors (EFs). Th ere are thirteen separate technical factors and eight separate environmental factors. Th e purpose of these factors is to allow the project as a whole to be evaluated for the complexity of the system being developed and the expe- rience levels of the development staff , respectively. Obviously, these types of factors can aff ect the eff ort that a team requires to develop a system. Each of these factors is assigned a value between 0 and 5, 0 indicating that the factor is irrelevant to the system under con- sideration and 5 indicating that the factor is essential for the system to be successful. Th e assigned values are then multiplied by their respective weights. Th ese weighted values are then summed up to create a technical factor value (TFactor) and an environmental factor value (EFactor) (see Figure 2-15).

6 We cover the details of use-case modeling in Chapter 4.

Project Effort Estimation  59

FIGURE 2-15 Use-Case Point–Estimation Worksheet

Unadjusted Actor Weighting Table:

Actor Type Description Weighting Factor Number Result

Simple External System with well-defi ned API 1 Average External System using a protocol-based 2 interface, e.g., HTTP, TCT/IP, or a database Complex Human 3 Unadjusted Actor Weight Total (UAW)

Unadjusted Use Case Weighting Table:

Use-Case Type Description Weighting Factor Number Result

Simple 1–3 transactions 5 Average 4–7 transactions 10 Complex >7 transactions 15 Unadjusted Use-Case Weight Total (UUCW)

Unadjusted Use Case Points (UUCP) 5 UAW 1 UUCW

Technical Complexity Factors:

Factor Number Description Weight Assigned Value (0–5) Weighted Value Notes

T1 Distributed system 2.0 T2 Response time or throughput 1.0 performance objectives T3 End-user online effi ciency 1.0 T4 Complex internal processing 1.0 T5 Reusability of code 1.0 T6 Ease of installation 0.5 T7 Ease of use 0.5 T8 Portability 2.0 T9 Ease of change 1.0 T10 Concurrency 1.0 T11 Special security objectives included 1.0 T12 Direct access for third parties 1.0 T13 Special user training required 1.0 Technical Factor Value (TFactor)

Technical Complexity Factor (TCF) 5 0.6 1 (0.01 * TFactor)

Environmental Factors:

Factor Number Description Weight Assigned Value (0–5) Weighted Value Notes

E1 Familiarity with system 1.5 development process being used E2 Application experience 0.5 E3 Object-oriented experience 1.0 E4 Lead analyst capability 0.5 E5 Motivation 1.0 E6 Requirements stability 2.0 E7 Part time staff –1.0 E8 Diffi culty of programming language –1.0 Environmental Factor Value (EFactor)

Environmental Factor (EF) 5 1.4 1 (20.03 * EFactor) Adjusted Use Case Points (UCP) 5 UUCP * TCF * ECF Effort in Person Hours 5 UCP * PHM

TEMPLATE can be found at www.wiley.com /college/dennis

6 0 C h a p t e r 2   Project Management

FIGURE 2-16 Use-Case Point Estimation for the Appointment System

Unadjusted Actor Weighting Table:

Actor Type Description Weighting Factor Number Result

Simple External system with well-defi ned API 1 0 0 Average External system using a protocol-based 2 0 0 interface, e.g., HTTP, TCT/IP, or a database Complex Human 3 4 12 Unadjusted Actor Weight Total (UAW) 12

Unadjusted Use-Case Weighting Table:

Use Case Type Description Weighting Factor Number Result

Simple 1–3 transactions 5 3 15 Average 4–7 transactions 10 4 40 Complex >7 transactions 15 1 15 Unadjusted Use Case Weight Total (UUCW) 70

Unadjusted Use-Case Points (UUCP) 5 UAW 1 UUCW 82 5 12 1 70

Technical Complexity Factors:

Factor Number Description Weight Assigned Value (0–5) Weighted Value Notes

T1 Distributed system 2.0 0 0 T2 Response time or throughput 1.0 5 5 performance objectives T3 End-user online effi ciency 1.0 3 3 T4 Complex internal processing 1.0 1 1 T5 Reusability of code 1.0 1 1 T6 Ease of installation 0.5 2 1 T7 Ease of use 0.5 4 2 T8 Portability 2.0 0 0 T9 Ease of change 1.0 2 2 T10 Concurrency 1.0 0 0 T11 Special security objectives included 1.0 0 0 T12 Direct access for third parties 1.0 0 0 T13 Special user training required 1.0 0 0 Technical Factor Value (TFactor) 15

Technical Complexity Factor (TCF) 5 0.6 1 (0.01 * TFactor) 0.75 5 0.6 1 (0.01 * 15)

Environmental Factors:

Factor Number Description Weight Assigned Value (0–5) Weighted Value Notes

E1 Familiarity with system 1.5 4 6 development process being used E2 Application experience 0.5 4 2 E3 Object-oriented experience 1.0 4 4 E4 Lead analyst capability 0.5 5 2.5 E5 Motivation 1.0 5 5 E6 Requirements stability 2.0 5 10 E7 Part-time staff –1.0 0 0 E8 Diffi culty of programming language –1.0 4 –4.0 Environmental Factor Value (EFactor) 25.5

Environmental Factor (EF) 5 1.4 1 (20.03 * EFactor) 0.635 5 1.4 1 (20.03 * 25.5) Adjusted Use Case Points (UCP) 5 UUCP * TCF * ECF 33.3375 5 70 * 0.75 * 0.635 Effort in person-hours 5 UCP * PHM 666.75 5 20 * 33.3375

Project Effort Estimation  61

Th e technical factors include the following (see Figure 2-15):

■ Whether the system is going to be a distributed system ■ Th e importance of response time ■ Th e effi ciency level of the end user using the system ■ Th e complexity of the internal processing of the system ■ Th e importance of code reuse ■ How easy the installation process has to be ■ Th e importance of the ease of using the system ■ How important it is for the system to be able to be ported to another platform ■ Whether system maintenance is important ■ Whether the system is going to have to handle parallel and concurrent

processing ■ Th e level of special security required ■ Th e level of system access by third parties ■ Whether special end user training is to be required.

Assuming the values for the technical factors are T1 (0), T2 (5), T3 (3), T4 (1), T5 (1), T6 (2), T7 (4), T8 (0), T9 (2), T10 (0), T11 (0), T12 (0), and T13 (0), respectively, the technical factor value (TFactor) is computed as the weighted sum of the individual technical factors. In this case TFactor equals 15 (see Figure 2-16). Plugging this value into the technical complexity factor (TCF) equation (0.6 1 (.01 * TFactor)) of the use-case point worksheet gives a value of .75 for the TCF of the system (see Figures 2-15 and 2-16).

Th e environmental factors include the following (see Figure 2-15):

■ Th e level of experience the development staff has with the development process being used

■ Th e application being developed ■ Th e level of object-oriented experience ■ Th e level of capability of the lead analyst ■ Th e level of motivation of the development team to deliver the system ■ Th e stability of the requirements ■ Whether part-time staff have to be included as part of the development team ■ Th e diffi culty of the programming language being used to implement the system

Assuming the values for the environmental factors were E1 (4), E2 (4), E3 (4), E4 (5), E5 (5), E6 (5), E7 (0), and E8 (4) gives an environmental factor value (EFactor) of 25.5 (see Figure 2-16). Like the TFactor, Efactor is simply the sum of the weighted values. Using the envi- ronmental factor (EF) equation (1.4 1 (20.03 * EFactor)) of the use-case point worksheet produces a value of .635 for the EF of the system (see Figures 2-15 and 2-16). Plugging the TCF and EF values, along with the UUCP value computed earlier, into the adjusted use-case points equation (UUCP * TCF * EF) of the worksheet yields a value of 33.3375 adjusted use- case points (UCP) (see Figure 2-16).

Now that we know the estimated size of the system by means of the value of the adjusted use-case points, we are ready to estimate the eff ort required to build the system. In Karner’s original work, he suggested simply multiplying the number of use-case points by 20 to estimate the number of person-hours required to build the system. However, based on additional experiences using use-case points, a decision rule to determine the value of the

6 2 C h a p t e r 2   Project Management

person-hours multiplier (PHM) has been created that suggests using either 20 or 28, based on the values assigned to the individual environmental factors. Th e decision rule is:

If the sum of (number of Efactors E1 through E6 assigned value , 3) and (number of Efactors E7 and E8 assigned value . 3) < 2 PHM 5 20 Else If the sum of (number of Efactors E1 through E6 assigned value , 3) and (number of Efactors E7 and E8 assigned value . 3) 5 3 or 4 PHM 5 28

Else Rethink project; it has too high of a risk for failure

Based on these rules, because none of Efactors E1 through E6 have a value less than 3 and only Efactor E8 has a value greater than 3, the sum of the number EFactors is 1. Th us, the system should use a PHM of 20. Plugging the values for UCP (33.3375) and PHM (20) into the eff ort equation (UCP * PHM) gives an estimated number of person-hours of 666.75 hours (see Figures 2-15 and 2-16).

CREATING AND MANAGING THE WORKPL AN Once a project manager has a general idea of the functionality and eff ort for the project, he or she creates a workplan, which is a dynamic schedule that records and keeps track of all the tasks that need to be accomplished over the course of the project. Th e workplan lists each task, along with important information about it, such as when it needs to be completed, the person assigned to do the work, and any deliverables that will result. Th e level of detail and the amount of information captured by the workplan depend on the needs of the project, and the detail usually increases as the project progresses.

Th e overall objectives for the system should be listed on the system request, and it is the project manager’s job to identify all the tasks that need to be accomplished to meet those objectives. Th is sounds like a daunting task. How can someone know everything that needs to be done to build a system that has never been built before?

One approach for identifying tasks is to get a list of tasks that has already been devel- oped and to modify it. Th ere are standard lists of tasks, or methodologies, that are available for use as a starting point. As we stated in Chapter 1, a methodology is a formalized approach to implementing a systems development process (i.e., it is a list of steps and deliverables). A project manager can take an existing methodology, select the steps and deliverables that apply to the current project, and add them to the workplan. If an existing methodology is not available within the organization, methodologies can be purchased from consultants or ven- dors, or books such as this textbook can serve as a guide. Because most organizations have a methodology they use for projects, using an existing methodology is the most popular way to create a workplan. In our case, because we are using a Unifi ed Process-based methodology, we can use the phases, workfl ows, and iterations as a starting point to create an evolutionary work breakdown structure and an iterative workplan.

Evolutionary Work Breakdown Structures and Iterative Workplans7 Because object-oriented systems approaches to systems analysis and design support incre- mental and iterative development, any project planning approach for object-oriented systems 7 Th is material in this section is based on Walker Royce, Soft ware Project Management: A Unifi ed Framework (Read- ing, MA: Addison-Wesley, 1998).

Creating and Managing the Workplan  63

development also requires an incremental and iterative process. In the description of the enhanced Unifi ed Process in Chapter 1, the development process was organized around iterations, phases, and workfl ows. In many ways, a workplan for an incremental and iterative development process is organized in a similar manner. For each iteration, there are diff erent tasks executed on each workfl ow. Th is section describes an incremental and iterative process using evolutionary WBSs for project planning that can be used with object-oriented systems development.

Evolutionary WBSs allow the analyst to develop an iterative workplan. First, evolutionary WBSs are organized in a standard manner across all projects: by workfl ows, phases, and then the specifi c tasks that are accomplished during an individual iteration. Second, evolutionary WBSs are created in an incremental and iterative manner. Th is encourages a more realistic view of both cost and schedule estimation. Th ird, because the structure of an evolutionary WBS is not tied to any specifi c project, evolutionary WBSs enable the comparison of the current project to earlier projects. Th is supports learning from past successes and failures.

In the case of the enhanced Unifi ed Process, the workfl ows are the major points listed in the WBS. Next, each workfl ow is decomposed along the phases of the enhanced Unifi ed Process. Aft er that, each phase is decomposed along the tasks that are to be completed to cre- ate the deliverables associated with an individual iteration contained in each phase (see Figure 1-16). Th e template for the fi rst two levels of an evolutionary WBS for the enhanced Unifi ed Process would look like Figure 2-17.

As each iteration through the development process is completed, additional iterations and tasks are added to the WBS (i.e., the WBS evolves along with the evolving information system).8

I. Business Modeling a. Inception b. Elaboration c. Construction d. Transition e. Production

II. Requirements a. Inception b. Elaboration c. Construction d. Transition e. Production

III. Analysis a. Inception b. Elaboration c. Construction d. Transition e. Production

IV. Design a. Inception b. Elaboration c. Construction d. Transition e. Production

V. Implementation a. Inception b. Elaboration c. Construction d. Transition e. Production

VI. Test a. Inception b. Elaboration c. Construction d. Transition e. Production

VII. Deployment a. Inception b. Elaboration c. Construction d. Transition e. Production

VIII. Confi guration and Change Management a. Inception b. Elaboration c. Construction d. Transition e. Production

IX. Project Management a. Inception b. Elaboration c. Construction d. Transition e. Production

X. Environment a. Inception b. Elaboration c. Construction d. Transition e. Production

XI. Operations and Support a. Inception b. Elaboration c. Construction d. Transition e. Production

XII. Infrastructure Management a. Inception b. Elaboration c. Construction d. Transition e. Production

FIGURE 2-17 E volutionary WBS Template for the Enhanced Unifi ed Process

8 Good sources that help explain this approach are Phillippe Krutchen, “Planning an Iterative Project,” Th e Rational Edge (October 2002); Eric Lopes Cordoza and D. J. de Villiers, “Project Planning Best Practices,” Th e Rational Edge (August 2003).

6 4 C h a p t e r 2   Project Management

For example, typical activities for the inception phase of the project management workfl ow would include identifying the project, performing the feasibility analysis, selecting the project, and estimating the eff ort. Th e inception phase of the requirements workfl ow would include determining the requirements gathering and analysis techniques, identifying functional and nonfunctional requirements, interviewing stakeholders, developing a vision document, and developing use cases. Probably no tasks are associated with the inception phase of the operations and support workfl ow. A sample evolutionary WBS for planning the inception phase of the enhanced Unifi ed Process, based on Figures 1-16 and 2-17, is shown in Figure 2-18. Notice the last two tasks for the project management workfl ow are “create workplan for fi rst iteration of the elaboration phase” and “assess the inception phase”; the last two things to do are to plan for the next iteration in the development of the evolving system and to assess the current iteration. As the project moves through later phases, each workfl ow has tasks added to its iterations. For example, the analysis workfl ow will have the creation of the functional, structural, and behav- ioral models during the elaboration phase. Finally, when an iteration includes a lot of complex tasks, traditional tools, such as Gantt charts and network diagrams, can be used to detail the workplan for that specifi c iteration.

FIGURE 2-18 Evolutionary WBS for a Single Iteration-Based Inception Phase

Duration Dependency

I. Business Modeling a. Inception 1. Understand current business situation 0.50 days 2. Uncover business process problems 0.25 days 3. Identify potential projects 0.25 days b. Elaboration c. Construction d. Transition e. Production

II. Requirements a. Inception 1. Identify appropriate requirements-analysis technique 0.25 days 2. Identify appropriate requirements-gathering techniques 0.25 days 3. Identify functional and nonfunctional requirements II.a.1, II.a.2 A. Perform JAD sessions 3 days B. Perform document analysis 5 days II.a.3.A C. Conduct interviews II.a.3.A 1. Interview project sponsor 0.5 days 2. Interview inventory system contact 0.5 days 3. Interview special order system contact 0.5 days 4. Interview ISP contact 0.5 days 5. Interview CD Selection Web contact 0.5 days 6. Interview other personnel 1 day D. Observe retail store processes 0.5 days II.a.3.A 4. Analyze current systems 4 days II.a.1, II.a.2 5. Create requirements defi nition II.a.3, II.a.4 A. Determine requirements to track 1 day B. Compile requirements as they are elicited 5 days II.a.5.A C. Review requirements with sponsor 2 days II.a.5.B b. Elaboration c. Construction d. Transition e. Production

Creating and Managing the Workplan  65

FIGURE 2-18 Continued

Duration Dependency

III. Analysis a. Inception 1. Identify business processes 3 days 2. Identify use cases 3 days III.a.1 b. Elaboration c. Construction d. Transition e. Production

IV. Design a. Inception 1. Identify potential classes 3 days III.a b. Elaboration c. Construction d. Transition e. Production

V. Implementation a. Inception b. Elaboration c. Construction d. Transition e. Production

VI. Test a. Inception b. Elaboration c. Construction d. Transition e. Production

VII. Deployment a. Inception b. Elaboration c. Construction d. Transition e. Production

VIII. Confi guration and Change Management a. Inception 1. Identify necessary access controls for developed artifacts 0.25 days 2. Identify version control mechanisms for developed artifacts 0.25 days b. Elaboration c. Construction d. Transition e. Production

IX. Project Management a. Inception 1. Create workplan for the inception phase 1 day 2. Create system request 1 day 3. Perform feasibility analysis IX.a.2 A. Perform technical feasibility analysis 1 day B. Perform economic feasibility analysis 2 days C. Perform organizational feasibility analysis 2 days

6 6 C h a p t e r 2   Project Management

Duration Dependency

4. Identify project effort 0.50 days IX.a.3 5. Identify staffi ng requirements 0.50 days IX.a.4 6. Compute cost estimate 0.50 days IX.a.5 7. Create workplan for fi rst iteration of the

elaboration phase 1 day IX.a.1 8. Assess inception phase 1 day I.a, II.a, III.a IV.a, V.a, VI.a VII.a, VIII.a, IX.a, X.a, XI.a XII.a b. Elaboration c. Construction d. Transition e. Production

X. Environment a. Inception 1. Acquire and install CASE tool 0.25 days 2. Acquire and install programming environment 0.25 days 3. Acquire and install confi guration and change

management tools 0.25 days 4. Acquire and install project management tools 0.25 days b. Elaboration c. Construction d. Transition e. Production

XI. Operations and Support a. Inception b. Elaboration c. Construction d. Transition e. Production

XII. Infrastructure Management a. Inception 1. Identify appropriate standards and enterprise models 0.25 days 2. Identify reuse opportunities, such as patterns,

frameworks, and libraries 0.50 days 3. Identify similar past projects 0.25 days b. Elaboration c. Construction d. Transition e. Production

FIGURE 2-18 Continued

Managing Scope An analyst may assume that a project will be safe from scheduling problems because he or she carefully estimated and planned the project up front. However, the most common reason for schedule and cost overruns—scope creep—occurs aft er the project is under way. Scope creep happens when new requirements are added to the project aft er the original project scope was defi ned and frozen. It can happen for many reasons: Users might suddenly understand the

Creating and Managing the Workplan  67

potential of the new system and realize new functionality that would be useful; developers might discover interesting capabilities to which they become very attached; a senior manager might decide to let this system support a new strategy that was developed at a recent board meeting.

Fortunately, using an iterative and incremental development process allows the team to deal with changing requirements in an eff ective way. However, the more extensive the change becomes, the greater the impact on cost and schedule. Th e keys are to identify the require- ments as well as possible in the beginning of the project and to apply analysis techniques eff ectively. For example, if needs are fuzzy at the project’s onset, a combination of intensive meetings with the users and prototyping would allow users to “experience” the requirements and better visualize how the system could support their needs.

Of course, some requirements may be missed no matter what precautions are taken. However, the project manager should allow only absolutely necessary requirements to be added aft er the project begins. Even at that point, members of the project team should care- fully assess the ramifi cations of the addition and present the assessment to the users. Any change that is implemented should be carefully tracked so that an audit trail exists to measure the change’s impact.

Sometimes changes cannot be incorporated into the present system even though they truly would be benefi cial. In this case, these additions should be recorded as future enhance- ments to the system. Th e project manager can off er to provide functionality in future releases of the system, thus getting around telling someone “no.”

A couple of useful agile techniques to manage the scope of the project while attempting to satisfy the client are daily scrum meetings and the product backlog used with Scrum. Essentially a daily scrum meeting is a very short, typically fi ft een minutes, meeting that keeps the development team up to date as to the current status of the evolving system. Th e content of the meeting typically only covers what has been accomplished since the previous meeting, what will be accomplished before the next meeting, and what obstacles could come up that could prevent progress from being made. Also, new requested features could be brought up. However, all proposed additional features are simply added to the product backlog that could be considered during the next iteration or timebox (sprint in Scrum’s nomenclature). Th e product backlog is essentially a prioritized list of the functional requirements that will be completed during the current iteration. In Scrum, only the client is allowed to modify the product backlog. In this manner, the development team always has a list of the current set of critical requirements. As long as the project is relatively small, this approach to scope man- agement is very eff ective.

Timeboxing Another approach to scope management is a technique called timeboxing. Up until now, we have described task-oriented projects. In other words, we have described projects that have a schedule driven by the tasks that need to be accomplished, so the greater number of tasks and requirements, the longer the project will take. Some companies have little patience for devel- opment projects that take a long time, and these companies take a time-oriented approach that places meeting a deadline above delivering functionality.

Th ink about the use of word processing soft ware. For 80 percent of the time, only 20 percent of the features, such as the spelling checker, boldfacing, and cutting and pasting, are used. Other features, such as document merging and creating mailing labels, may be nice to have, but they are not a part of day-to-day needs. Th e same goes for other soft ware applications; most users rely on only a small subset of their capabilities. Ironically, most developers agree that typically 75 percent of a system can be provided relatively quickly, with the remaining 25 percent of the functionality demanding most of the time.

6 8 C h a p t e r 2   Project Management

To resolve this incongruency, the technique of timeboxing has become quite popular, especially when using RAD and agile methodologies. Th is technique sets a fi xed deadline for a project and delivers the system by that deadline no matter what, even if functionality needs to be reduced. Timeboxing ensures that project teams don’t get hung up on the fi nal fi nishing touches that can drag out indefi nitely, and it satisfi es the business by providing a product within a relatively short time frame.

Several steps are involved in implementing timeboxing on a project. First, set the date of delivery for the proposed goals. Th e deadline should not be impossible to meet, so it is best to let the project team determine a realistic due date. If you recall from Chapter 1, the Scrum agile methodology sets all of its timeboxes (sprint) to thirty working days. Next, build the core of the system to be delivered; you will fi nd that timeboxing helps create a sense of urgency and helps keep the focus on the most important features. Because the schedule is absolutely fi xed, functionality that cannot be completed needs to be postponed. It helps if the team prioritizes a list of features beforehand to keep track of what functionality the users absolutely need. Quality cannot be compromised, regardless of other constraints, so it is important that the time allocated to activities is not shortened unless the requirements are changed (e.g., don’t reduce the time allocated to testing without reducing features). At the end of the time period, a high-quality system is delivered, but it is likely that future iterations will be needed to make changes and enhancements. In that case, the timeboxing approach can be used once again.

Refi ning Estimates Th e estimates that are produced during inception need to be refi ned as the project progresses. Th is does not mean that estimates were poorly done at the start of the project; rather, it is virtually impossible to develop an exact assessment of the project’s schedule at the beginning of the development process. A project manager should expect to be satisfi ed with broad ranges of estimates that become more and more specifi c as the project’s product becomes better defi ned.

During planning, when a system is fi rst requested, the project sponsor and project manager attempt to predict how long the development process will take, how much it will cost, and what it will ultimately do when it is delivered (i.e., its functionality). However, the estimates are based on very little knowledge of the system. As the system moves into the elaboration, more information is gathered, the system concept is developed, and the estimates become even more accurate and precise. As the system moves closer to completion, the accu- racy and precision increase, until it is delivered.

According to one of the leading experts in soft ware development,9 a well-done project plan (prepared at the end of inception) has a 100 percent margin of error for project cost and a 25 percent margin of error for schedule time. In other words, if a carefully done project plan estimates that a project will cost $100,000 and take twenty weeks, the project will actually cost between $0 and $200,000 and take between fi ft een and twenty-fi ve weeks.

What happens if you overshoot an estimate (e.g., analysis ends up lasting two weeks longer than expected)? Th ere are a number of ways to adjust future estimates. If the project team fi nishes a step ahead of schedule, most project managers shift the deadlines sooner by the same amount but do not adjust the promised completion date. Th e challenge, however, occurs when the project team is late in meeting a scheduled date. Th ree possible responses to missed schedule dates are presented in Figure 2-19. If, early in the project, an estimate proves to be too optimistic, planners should not expect to make up for lost time—very few projects

9 Barry W. Boehm et al., “Cost Models for Future Soft ware Life Cycle Processes: COCOMO 2.0,” in J. D. Arthur and S. M. Henry (eds.), Annals of Soft ware Engineering: Special Volume on Soft ware Process and Product Measurement (Amsterdam: J. C. Baltzer AG Science Publishers, 1995).

Creating and Managing the Workplan  69

end up doing this. Instead, they should change future estimates to include an increase similar to the one that was experienced. For example, if the fi rst phase was completed 10 percent over schedule, planners should increase the rest of their estimates by 10 percent.

Managing Risk One fi nal facet of project management is risk management, the process of assessing and addressing the risks that are associated with developing a project. Many things can cause risks: weak personnel, scope creep, poor design, and overly optimistic estimates. Th e project team must be aware of potential risks so that problems can be avoided or controlled well ahead of time.

Typically, project teams create a risk assessment, or a document that tracks potential risks along with an evaluation of the likelihood of each risk and its potential impact on the project (Figure 2-20). A paragraph or two is also included to explain potential ways that the risk can be addressed. Th ere are many options: Th e risk could be publicized, avoided, or even elim- inated by dealing with its root cause. For example, imagine that a project team plans to use new technology but its members have identifi ed a risk in the fact that its members do not have the right technical skills. Th ey believe that tasks may take much longer to perform because of a high learning curve. One plan of attack could be to eliminate the root cause of the risk—the lack of technical experience by team members—by fi nding the time and resources needed to provide proper training to the team.

Most project managers keep abreast of potential risks, even prioritizing them according to their magnitude and importance. Over time, the list of risks will change as some items are removed and others surface. Th e best project managers, however, work hard to keep risks from having an impact on the schedule and costs associated with the project.

If you assume the rest of the project is Do not change schedule. High risk simpler than the part that was late and is also simpler than believed when the original schedule estimates were made, you can make up lost time.

If you assume the rest of the project is Increase the entire schedule by the Moderate risk simpler than the part that was late total amount of time that you are and is no more complex than the behind (e.g., if you missed the original estimate assumed, you can’t scheduled date by two weeks, move make up the lost time, but you will the rest of the schedule dates to two not lose time on the rest of the weeks later). If you included padded project. time at the end of the project in the original schedule, you might not have to change the promised system delivery date; you’ll just use up the padded time.

If you assume that the rest of the Increase the entire schedule by the Low risk project is as complex as the part percentage of weeks that you are that was late (your original estimates behind (e.g., if you are two weeks were too optimistic), then all the late on part of the project that was scheduled dates in the future supposed to take eight weeks, you underestimate the real time required need to increase all remaining by the same percentage as the part time estimates by 25 percent). If that was late. this moves the new delivery date beyond what is acceptable to the project sponsor, the scope of the project must be reduced.

Assumptions Actions Level of Risk

FIGURE 2-19 Possible Actions When a Schedule Date Is Missed

7 0 C h a p t e r 2   Project Management

STAFFING THE PROJECT Staffi ng the project includes determining how many people should be assigned to the project, matching people’s skills with the needs of the project, motivating them to meet the project’s objectives, and minimizing the confl ict that will occur over time. Th e deliverables for this part of project management are a staffi ng plan, which describes the number and kinds of people who will work on the project, the overall reporting structure, and the project charter, which describes the project’s objectives and rules. However, before describing the development of a staffi ng plan, how to motivate people, and how to handle confl ict, we describe a set of char- acteristics of jelled teams.

Characteristics of a Jelled Team10 Th e idea of a jelled team has existed for a long time. Most (if not all) student groups are not representative of the idea of a jelled team, and you may have never had the opportunity to appreciate the eff ectiveness of a true team. In fact, DeMarco and Lister point out that teams are not created; they are grown. Typically, in class projects, students are assigned or asked to form a group, which makes the ability to grow a team very limited. However, growing devel- opment teams is crucial in information systems development. Th e whole set of agile soft ware development approaches hinges on growing jelled teams. Otherwise, agile development approaches would totally fail.

According to DeMarco and Lister,11 “[a] jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts. Th e production of such a team is greater than that of the same people working in unjelled form.” Th ey go on to state that a jelled “team can become almost unstoppable, a juggernaut for success.” When is the last time that you worked with a group on a class project that could be described “a juggernaut for success”? Demarco and Lister identify fi ve characteristics of a jelled team.

10 Th e material in the section is based on T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams, 2nd Ed. (New York: Dorset House, 1999); P. Lencioni, Th e Five Dysfunctions of a Team: A Leadership Fable (San Francisco: Jossey-Bass, 2002). 11 T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams, 2nd Ed., p. 123.

Risk Assessment

RISK 1: The development of this system likely will be slowed considerably because project team members have not programmed in Java prior to this project.

Likelihood of risk: High probability of risk.

Potential impact on the project: This risk will probably increase the time to complete programming tasks by 50 percent.

Ways to address this risk:

It is very important that time and resources are allocated to up-front training in Java for the programmers who are used for this project. Adequate training will reduce the initial learning curve for Java when programming begins. Additionally, outside Java expertise should be brought in for at least some part of the early programming tasks. This person should be used to provide experiential knowledge to the project team so that Java-related issues (of which novice Java programmers would be unaware) are overcome.

RISK 2: …

FIGURE 2-20 Sample Risk Assessment

Staffi ng the Project  71

First, jelled teams have a very low turnover during a project. Typically, members of a jelled team feel a responsibility to the other team members. Th is responsibility is felt so intensely that for a member to leave the team, the member would feel that they were letting the team down and that they were breaking a bond of trust.

Second, jelled teams have a strong sense of identity. In many classes, when you are part of a group, the group chooses some cute name to identify the group and diff erentiate it from the other groups. However, in this case, it is not simply the choosing of a name. It is instead evolv- ing every member into something that only exists within the team. Th is can be seen when members of the team tend to do non–work-related activities together, e.g., do lunch together as a team or form a basketball team composed of only members of the development team.

Th ird, the strong sense of identity tends to lead the team into feeling a sense of eliteness. Th e members of a jelled development team almost have a swagger about the way they relate to nonteam employees. Good examples that come to mind that possess this sense of eliteness outside of the scope of information systems development teams are certain sports teams, U.S. Navy Seal teams, or big city police force SWAT teams. In all three examples, each team member is highly competent in his or her specialty area, and each other team member knows (not thinks) that he or she can depend on the team members performing his or her individual jobs with a very high-level of skill.

Fourth, during the development process, jelled teams feel that the team owns the infor- mation system being developed and not any one individual member. In many ways, you could almost say that jelled teams are a little communistic in nature. By this we mean that the individ- ual contributions to the eff ort are not important to a true team. Th e only things that matter are the output of the team. However, this is not to imply that a member who does not deliver his or her fair share will not go unpunished. In a jelled team, any member who is not producing is actu- ally breaking his or her bond of trust with the other team members (see the fi rst characteristic).

Th e fi nal characteristic of a jelled team is that team members really enjoy (have fun) doing their work. Th e members actually like to go to work and be with their team members. Much of this can be attributed to the level of challenge they receive. If the project is challeng- ing and the members of the team are going to learn something from completing the project, the members of a jelled team will enjoy tackling the project.

When a team jells, they will avoid the fi ve dysfunctions of a team defi ned by Lencioni. Lack of trust is the primary cause of a team becoming dysfunctional. Lencioni describes four other causes of a team becoming dysfunctional that can come from the lack of trust. First, dysfunctional teams fear confl ict, whereas members of a jelled team never fear confl ict.12 Going to a member of a jelled team and admitting that you do not know how to do something is no big deal. In fact, it provides a method for the team member to help out, which would increase the level of trust between the two members. Second, dysfunctional teams do not have a commitment to the team from the individual members. Instead, they tend to focus on their individual performance instead of the team’s performance. Th is can even be to the detriment of the development team. Obviously, this is not an issue for jelled teams. Th ird, dysfunctional teams try to avoid accountability. With jelled teams, accountability is not an issue. Members of a jelled team feel a high level of responsibility to the other team members. No team mem- ber ever wants to let down the team. Furthermore, owing to the bond that holds jelled teams together, no member has any problem with holding other members accountable for their per- formance (or lack of performance). Fourth, dysfunctional teams do not pay attention to the team’s results. Again, in this case, the cause of this dysfunction is that the individual members only focus on their individual goals. From a team management perspective, the team leader should focus on getting the goals of the team aligned; a jelled team will attain the goals.

12 When confl ict occurs, it is necessary to address it in an eff ective manner. We discuss how to handle confl ict later in the chapter.

7 2 C h a p t e r 2   Project Management

Staffi ng Plan Th e fi rst step to staffi ng is determining the average number of staff needed for the project. To calculate this fi gure, divide the total person-months of eff ort by the optimal schedule. So to complete a forty-person-month project in ten months, a team should have an average of four full-time staff members, although this may change over time as diff erent specialists enter and leave the team (e.g., business analysts, programmers, technical writers).

Many times, the temptation is to assign more staff to a project to shorten the project’s length, but this is not a wise move. Adding staff resources does not translate into increased productivity; staff size and productivity share a disproportionate relationship, mainly because it is more diffi cult to coordinate a large number of staff members. Th e more a team grows, the more diffi cult it becomes to manage. Imagine how easy it is to work on a two-person project team: Th e team members share a single line of communication. But adding two peo- ple increases the number of communication lines to six, and greater increases lead to more dramatic gains in communication complexity. Figure 2-21 illustrates the impact of adding team members to a project team.

One way to reduce effi ciency losses on teams is to understand the complexity that is cre- ated in numbers and to build in a reporting structure that tempers its eff ects. Th e general rule

Two-person team Four-person team

Eight-person teamSix-person team

FIGURE 2-21 Increasing Com- plexity with Larger Teams

Staffi ng the Project  73

is to keep team sizes to fewer than eight to ten people; therefore, if more people are needed, create sub-teams. In this way, the project manager can keep the communication eff ective within small teams, which, in turn, communicate to a contact at a higher level in the project.

Aft er the project manager understands how many people are needed for the project, he or she creates a staffi ng plan that lists the roles and the proposed reporting structure that are required for the project. Typically, a project has one project manager who oversees the overall progress of the development eff ort, with the core of the team comprising the various types of analysts described in Chapter 1. A functional lead is usually assigned to manage a group of analysts, and a technical lead oversees the progress of a group of programmers and more technical staff members.

Th ere are many structures for project teams; Figure 2-22 illustrates one possible confi g- uration of a project team. Aft er the roles are defi ned and the structure is in place, the project manager needs to think about which people can fi ll each role. Oft en, one person fi lls more than one role on a project team.

When you make assignments, remember that people have technical skills and interper- sonal skills, and both are important on a project. Technical skills are useful when working with technical tasks (e.g., programming in Java) and in trying to understand the various roles that technology plays in the particular project (e.g., how a Web server should be con- fi gured on the basis of a projected number of hits from customers). Interpersonal skills, on the other hand, include interpersonal and communication abilities that are used when dealing with business users, senior management executives, and other members of the project team. Th ey are particularly critical when performing the requirements- gathering activities and when addressing organizational feasibility issues. Each project requires unique technical and interpersonal skills.

Ideally, project roles are fi lled with people who have the right skills for the job. However, the people who fi t the roles best might not be available; they may be working on other projects, or they might not exist in the company. Th erefore, assigning project team members really is a combination of fi nding people with the appropriate skill sets and fi nding people who are available. When the skills of the available project team members do not match what is actually required by the project, the project manager has several options to improve the situation. First, people can be pulled off other projects, and resources can be shuffl ed around. Th is is the most disruptive approach from the organization’s perspective. Another approach is to use outside help—such as a consultant or contractor—to train team members and start them off on the right foot. Mentoring may also be an option; a project team member can be sent to work on another similar project so that he or she can return with skills to apply to the current job.

Functional lead

Project manager

ProgrammerAnalyst Analyst Analyst Programmer

Technical lead

FIGURE 2-22 Possible Reporting Structure

7 4 C h a p t e r 2   Project Management

Motivation Assigning people to tasks isn’t enough; project managers need to motivate the people to ensure a project’s success. Motivation has been found to be the number one infl uence on people’s performance,13 but determining how to motivate the team can be quite diffi cult. You might think that good project managers motivate their staff by rewarding them with money and bonuses, but most project managers agree that this is the last thing that should be done. Th e more oft en managers reward team members with money, the more they expect it—and most times monetary motivation won’t work. Pink14 has suggested a set of principles to follow to motivate individuals in twenty-fi rst century fi rms. In this section, we adapt his suggestions to information systems development teams.

Pink suggests considering using some form of the 20 percent time rule to motivate individuals. Th is rule suggests that 20 percent of an employee’s time should be spent on some idea in which he or she believes. Th e project does not have to be related to the project at hand. On the surface, this sounds like a colossal waste of time, but this idea should not be discarded. Google’s Gmail and Google News were developed using the 20 percent time rule. If 20 percent sounds too high, Pink suggests that you consider 10 percent to begin with.

He recommends that fi rms should be willing to fund small “Now Th at” awards. Th ese awards are given as small signs of appreciation for doing a great job. However, these awards are not given by a manager to an employee but from an employee to a peer of the employee. Th e awards are monetary, but they are very small, typically $50. As such, they really are not relevant from a mon- etary perspective. However, they are very relevant because they are given by one of the employee’s colleagues to show that some action that the employee did was appreciated.

Pink endorses the idea of applying Robert Reich’s (President’s Clinton’s Secretary of Labor) pronoun test. If an employee (or team member) refers to the fi rm (the team) as “they,” then there is the real possibility that the employee feels disengaged or possibly alienated. On the other hand, when employees refer to the fi rm as “we,” they obviously feel like they are part of the organization. From a team perspective, this could be an indication that the team has begun to jell.

Pink suggests that management should periodically consider giving each employee a day on which he or she can work on anything he or she wants. In some ways, this is related to the 20 percent rule. It does not necessarily require one day a week (20 percent), but it does require some deliverable. Th e deliverable can be a new utility program that could be used by lots of diff erent projects, it could be a new prototype of a new soft ware product, or it could be an improvement for a business process that is used internally. Th e goal is to provide team members with the ability to focus on interesting and challenging problems that might (or might not) provide results to the fi rm’s bottom line. Regardless, it demonstrates an amount of trust and respect that the fi rm has for its employees.

He recommends that managers remove the issue of compensation from the motivation equation. By this, he means that all employees should be paid a suffi cient amount so that com- pensation awards are not an issue. Technical employees on project teams are much more moti- vated by recognition, achievement, the work itself, responsibility, advancement, and the chance to learn new skills.15 Simplistic fi nancial awards, such as raises that are perceived as being unjust, can actually demotivate the overall team and lower overall performance.

13 Barry W. Boehm, Soft ware Engineering Economics (Englewood Cliff s, NJ: Prentice Hall, 1981). One of the best books on managing project teams is that by Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams (New York: Dorset House, 1987). 14 D. H. Pink, Drive: Th e Surprising Truth About What Motivates Us (New York, NY: Riverhead Books, 2009). 15 F. H. Hertzberg, “One More Time: How Do You Motivate Employees?” Harvard Business Review (January– February 1968).

Staffi ng the Project  75

He advocates that twenty-fi rst century bosses (team leaders) need to be willing to give up control. Many of the agile development approaches make similar suggestions. Appelo16 suggests that an open door policy that is supported by a team leader actually can be self-defeating. In the case of soft ware development teams, an open door policy implies that the team leader has a door that can be left open, whereas the poor individual team member does not have an offi ce with a door. In this case, Appelo suggests that the team leader move from the offi ce with a door to the same shared space in which the team resides. One of Pink’s other ideas is for the team leader to not use controlling language such as telling the team member that he or she “must” do some- thing. Instead, the team leader should ask the team member to “consider” or “think about” the idea. In some ways, a true team leader should never receive credit for any ideas associated with the team. Instead, a team leader should make suggestions and encourage the team members to consider ideas and, most importantly, let the team member and the team receive the credit.

Pink provides evidence that intrinsic motivation is very important for twenty-fi rst century knowledge workers. Pink suggests that intrinsically motivating individuals requires providing them with a degree of autonomy, supporting them in such a way that they can master their area of expertise, and encouraging them to pursue projects with a purpose. Providing team members with autonomy relates to the jelled team concept of trust. Team leaders need to trust the team members to deliver the soft ware for which they are responsible. Supporting team members so that they can master their area of expertise can be as simple as providing support to attend confer- ences, seminars, and training sessions that deal with the member’s area of expertise. It also could imply providing the team member with a high-end development environment. For example, when building information visualization and virtual reality applications, special hardware and soft ware environments can make it much easier to master the technology to develop the appli- cation. Finally, today it is very important for team members to feel that what they are doing can make a diff erence. A team leader should encourage the team members to tackle problems that can impact people’s lives. Th is can easily be accomplished through the use of the 20 percent rule.

Handling Confl ict Th e third component of staffi ng is organizing the project to minimize confl ict among group members. Group cohesiveness (the attraction that members feel to the group and to other members) contributes more to productivity than do project members’ individual capabil- ities or experiences.17 Clearly defi ning the roles on the project and holding team members accountable for their tasks are a good way to begin mitigating potential confl ict on a project. Some project managers develop a project charter, which lists the project’s norms and ground rules. For example, the charter may describe when the project team should be at work, when staff meetings will be held, how the group will communicate with each other, and what are the procedures for updating the workplan as tasks are completed. Figure 2-23 lists additional techniques that can be used at the start of a project to keep confl ict to a minimum.

ENVIRONMENT AND INFRASTRUCTURE MANAGEMENT Th e environment and infrastructure management workfl ows support the development team throughout the development process. Th e environment workfl ow primarily deals with choosing the correct set of tools that will be used throughout the development process and

16 J. Appelo, Management 3.0: Leading Agile Developers, Developing Agile Leaders (Upper Saddle River, NJ: Addison-Wesley, 2011). 17 B. Lakhanpal, “Understanding the Factors Infl uencing the Performance of Soft ware Development Groups: An Exploratory Group-Level Analysis,” Information and Soft ware Technology 35, no. 8 (1993): 468–473.

7 6 C h a p t e r 2   Project Management

identifying the appropriate set of standards to be followed during the development process. Infrastructure management workfl ow deals with choosing the appropriate level and type of documentation that will be created during the development process. Other activities asso- ciated with the infrastructure management workfl ow include developing, modifying, and reusing predefi ned components, frameworks, libraries, and patterns. Th e topic of reuse is discussed in later chapters (see Chapters 5 and 8).

CASE Tools Computer-aided soft ware engineering (CASE) is a category of soft ware that automates all or part of the development process. Some CASE soft ware packages are used primarily to support the analysis workfl ow to create integrated diagrams of the system and to store information regarding the system components, whereas others support the design workfl ow that can be used to generate code for database tables and system functionality. Other CASE tools contain functionality that supports tasks throughout the system-development process. CASE comes in a wide assortment of fl avors in terms of complexity and functionality, and many good tools are available in the marketplace to support object-oriented systems development (e.g., ArgoUml, Enterprise Architect, Poseidon, Visual Paradigm, and IBM’s Rational Rose).

Th e benefi ts of using CASE are numerous. With CASE tools, tasks can be completed and altered faster, development documentation is centralized, and information is illustrated through diagrams, which are typically easier to understand. Potentially, CASE can reduce maintenance costs, improve soft ware quality, and enforce discipline. Some project teams even use CASE to assess the magnitude of changes to the project. Many modern CASE tools that support object-oriented systems development support a development technique known as round-trip engineering. Round-trip engineering supports not only code generation but also the reverse engineering of UML diagrams from code. In this way, the system can evolve via diagrams and via code in a round-trip manner.

Of course, like anything else, CASE should not be considered a silver bullet for project development. Th e advanced CASE tools are complex applications that require signifi cant training and experience to achieve real benefi ts. Our experience has shown that CASE is a helpful way to support the communication and sharing of project diagrams and technical specifi cations as long as it is used by trained developers who have applied CASE on past pro- jects. All CASE tools use a CASE repository to store diagrams, models, and I/O designs and to ensure consistency across iterations.

Standards Project team members need to work together, and most project management soft ware and CASE tools support them by providing access privileges to everyone working on the system. However, without set procedures, collaboration can result in confusion. To make matters worse,

• Clearly defi ne plans for the project.

• Make sure that the team understands how the project is important to the organization.

• Develop detailed operating procedures and communicate these to the team members.

• Develop a project charter.

• Develop schedule commitments ahead of time.

• Forecast other priorities and their possible impact on the project.

Source: H. J. Thamhain and D. L. Wilemon, “Confl ict Management in Project Life Cycles,” Sloan Manage- ment Review (Spring 1975).

FIGURE 2-23 Confl ict-Avoidance Strategies

Environment and Infrastructure Management  77

people sometimes are reassigned in the middle of a project. It is important that their project knowledge does not leave with them and that their replacements can get up to speed quickly.

One way to make certain that everyone is performing tasks in the same way and following the same procedures is to create standards that the project team must follow. Standards can include formal rules for naming fi les, forms that must be completed when goals are reached, and programming guidelines. Figure 2-24 shows some examples of the types of standards that a project can create. When a team forms standards and then follows them, the project can be completed faster because task coordination becomes less complex.

Standards work best when they are created at the beginning of each major phase of the project and communicated clearly to the entire project team. As the team moves forward, new standards are added when necessary. Some standards (e.g., fi le naming conventions, status reporting) are applied during the entire development process, whereas others (e.g., program- ming guidelines) are appropriate only for certain tasks.

Documentation Finally, during the inception phase of the infrastructure workfl ow, project teams establish good documentation standards that include detailed information about the tasks of the Unifi ed Process. Typically, the standards for the required documentation are set by the development organization. Th e development team only needs to ascertain which documentation standards are appropriate for the current systems development project. Oft en, the documentation is stored in a project binder(s) that contains all the deliverables and all the internal communication

FIGURE 2-24 A Sampling of Project Standards

Documentation standards The date and project name should appear as a header on all documentation.

All margins should be set to 1 inch.

All deliverables should be added to the project binder and recorded in its table of contents.

Coding standards All modules of code should include a header that lists the programmer, last date of update, and a short description of the

purpose of the code.

Indentation should be used to indicate loops, if-then-else statements, and case statements.

On average, every program should include one line of comments for every fi ve lines of code.

Procedural standards Record actual task progress in the work plan every Monday morning by 10 AM.

Report to project update meeting on Fridays at 3:30 PM.

All changes to a requirements document must be approved by the project manager.

Specifi cation requirement standards Name of program to be created

Description of the program’s purpose

Special calculations that need to be computed

Business rules that must be incorporated into the program

Pseudocode

Due date

User interface design standards Labels will appear in boldface text, left-justifi ed, and followed by a colon.

The tab order of the screen will move from top left to bottom right.

Accelerator keys will be provided for all updatable fi elds.

Types of Standards Examples

7 8 C h a p t e r 2   Project Management

that takes place—the history of the project. Th e good news is that Unifi ed Process has a set of standard documentation that is expected. Th e documentation typically includes the system request, the feasibility analysis, the original and later versions of the eff ort estimation, the evolving workplan, and UML diagrams for the functional, structural, and behavioral models.

A poor project management practice is waiting until the last minute to create documentation; this typically leads to an undocumented system that no one understands. Good project teams learn to document a system’s history as it evolves while the details are still fresh in their memory. In most CASE tools that support object-oriented systems development, some of the documentation can be automated. For example, if the programming language chosen to implement the system in is Java, then it is possible to automatically create HTML manual pages that will describe the classes being implemented. Th is is accomplished through the javadoc18 tool that is part of the Java development environment. Other tools enable the developer to automatically generate HTML documentation for the UML diagrams, e.g., umldoc, which is part of the Poseidon for UML CASE tool.19 Even though virtually all developers hate creating documentation and documentation takes valuable time, it is a good investment that will pay off in the long run.

18 See Oracle, Javadoc Tool. Retrieved May 2014 from www.oracle.com. www.oracle.com/technetwork/java/javase/ documentation/index-jsp-135444.html. 19 See Gentleware, umldoc, an overview, retrieved May 2014 from /www.gentleware.com. www.gentleware.com/ fi leadmin/media/viewlets/text/UMLdoc.viewlet/UMLdoc_viewlet_swf.html.

Environment and Infrastructure Management  79

As Seattle University’s David Umphress has pointed out, watching most organizations develop systems is like watching reruns of Gilligan’s Island. At the begin- ning of each episode, someone comes up with a cockamamie scheme to get off the island, and it seems to work for a while, but something goes wrong and the castaways fi nd themselves right back where they started—stuck on the island. Similarly, most companies start new projects with grand ideas that seem to work, only to make a classic mistake and deliver the project behind schedule, over budget, or both. Here we sum- marize four classic mistakes in the planning and project management aspects of the project and discuss how to avoid them:

1. Overly optimistic schedule: Wishful thinking can lead to an overly optimistic schedule that causes analysis and design to be cut short (missing key requirements) and puts intense pressure on the programmers, who produce poor code (full of bugs).

Solution: Don’t infl ate time estimates; instead, explicitly schedule slack time at the end of each phase to account for the variability in estimates.

2. Failing to monitor the schedule: If the team does not regularly report progress, no one knows if the project is on schedule.

Solution: Require team members to report progress (or the lack of progress) honestly every week. There is no penalty for reporting a lack of progress, but there are immediate sanctions for a misleading report.

3. Failing to update the schedule: When a part of the schedule falls behind (e.g., information gathering uses all the slack in item 1 plus 2 weeks), a project team often thinks it can make up the time later by working faster. It can’t. This is an early warning that the entire schedule is too optimistic.

Solution: Immediately revise the schedule and inform the project sponsor of the new end date or use time- boxing to reduce functionality or move it into future versions.

4. Adding people to a late project: When a project misses a schedule, the temptation is to add more people to speed it up. This makes the project take longer because it increases coordination problems and requires staff to take time to explain what has already been done.

Solution: Revise the schedule, use timeboxing, throw away bug-fi lled code, and add people only to work on an isolated part of the project.

Based upon Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996), pp. 29–50.

Avoiding Classic Planning MistakesPRACTICAL

TIP

CHAPTER REVIEW Aft er reading and studying this chapter, you should be able to:

Explain the ways that projects are identifi ed and initiated. Explain why it is important to link the information system to business needs of the organization. Describe the purpose of the systems request and explain the contents of its sections. Create a systems request for a proposed project. Discuss the purpose of the feasibility study. Describe the issues that are considered when evaluating a project’s technical feasibility. Develop an economic feasibility assessment for a project. Understand and evaluate the organizational feasibility of a project. Explain how projects are selected. Describe a task. Create a standard work breakdown structure, a Gantt Chart, and a Network Diagram. Perform PERT analysis and identify the critical path. Estimate the system development eff ort using use-case points. Create an evolutionary work breakdown structure. Describe how iterative and incremental development using timeboxing addresses scope management. Describe the characteristics of a “jelled” team. Describe issues relating to motivating soft ware developers. Describe the importance of CASE tools, standards, and documentation managing soft ware development projects.

KEY TERMS

Actor Adjusted use-case

points (UCP) Application program

interface (API) Approval committee Average actors Average use case

Break-even point Business need Business requirement Business value Cash fl ow method Champion Compatibility Complex actors

Complex use case Computer-aided soft ware

engineering (CASE) CASE repository Cost–benefi t analysis Critical path method Critical task Development costs

Documentation Economic feasibility Eff ort Emerging Technology Environmental factor (EF) Environmental factor value

(EFactor) Estimation

8 0 C h a p t e r 2   Project Management

APPLYING THE CONCEPTS AT PATTERSON SUPERSTORE In Chapter 2, we look more closely at the completed system request that Max Ross and his team develop for the Integrated Health Clinic Delivery system, including the business needs, business requirements, and business values and constraints. We will also examine the feasibility analysis that accompanies and justifi es the system request. Finally, we will examine how the project eff ort was estimated, see how the project will be staff ed and managed, and look at the Evolutionary Work Breakdown Structure for Version 1 of the Integrated Health Clinic Delivery System.

As we progress through the text, examining how Patterson navigates through the sys- tems analysis and design and development processes will help us understand real-world implementation of the concepts presented.

You can fi nd the rest of the case at: www.wiley.com/go/dennis/casestudy

Evolutionary WBS Familiarity with the

functional area Familiarity with the

technology Feasibility analysis Feasibility study First mover Functional lead Functionality Gantt chart Group cohesiveness Intangible benefi ts Intangible costs Intangible value Iterative workplan Interpersonal skills Methodology Milestone Motivation Net present value (NPV)

Network Diagram Node Operational costs Organizational feasibility Organizational management Person-hours multiplier

(PHM) Program evaluation and

review technique (PERT) Portfolio management Project Project binder Project charter Project initiation Project management Project management

soft ware Project manager Project size Project sponsor Reporting structure

Return on investment (ROI)

Risk assessment Risk management Risks Round-trip engineering Scope creep Simple actors Simple use case Special issues Staffi ng plan Stakeholder Stakeholder analysis Standards Strategic alignment System request System users Tangible benefi ts Tangible value Task Task dependency

Technical complexity factor (TCF)

Technical factor value (TFactor)

Technical feasibility Technical lead Technical risk analysis Technical skills Timeboxing Trade-off s Unadjusted actor weight

total (UAW) Unadjusted use-case points

(UUCP) Unadjusted use-case weight

total (UUCW) Use case Use-case points Work breakdown structure

(WBS) Workplan

QUESTIONS

1. Give three examples of business needs for a system. 2. What is the purpose of an approval committee? Who

is usually on this committee? 3. Why should the system request be created by a busi-

ness person as opposed to an IS professional? 4. What is the diff erence between intangible value and

tangible value? Give three examples of each. 5. What are the purposes of the system request and the

feasibility analysis? How are they used in the project selection process?

6. Describe two special issues that may be important to list on a system request.

7. Describe the three techniques for feasibility analysis. 8. Describe a risky project in terms of technical feasibil-

ity. Describe a project that would not be considered risky.

9. What are the steps for assessing economic feasibility? Describe each step.

10. List two intangible benefi ts. Describe how these bene- fi ts can be quantifi ed.

11. List two tangible benefi ts and two operational costs for a system. How would you determine the values that should be assigned to each item?

12. Explain the net present value and return on invest- ment for a cost–benefi t analysis. Why would these calculations be used?

13. What is the break-even point for the project? How is it calculated?

14. What is stakeholder analysis? Discuss three stakehold- ers that would be relevant for most projects.

15. Why do many projects end up having unreasonable deadlines? How should a project manager react to unreasonable demands?

16. What are the trade-off s that project managers must manage?

17. Compare and contrast the Gantt chart with the net- work diagram.

18. Some companies hire consulting fi rms to develop the initial project plans and manage the project but use their own analysts and programmers to develop the system. Why do you think some companies do this?

19. What is a use-case point? For what is it used? 20. What process do we use to estimate systems develop-

ment based on use cases? 21. Name two ways to identify the tasks that need to be

accomplished over the course of a project. 22. What are the problems associated with conventional

WBSs? 23. What is an evolutionary WBS? How does it address

the problems associated with a conventional WBS? 24. What is an iterative workplan? 25. What is scope creep, and how can it be managed?

Questions  81

8 2 C h a p t e r 2   Project Management

EXERCISES

A. Locate a news article in an IT trade magazine (e.g., Computerworld ) about an organization that is imple- menting a new computer system. Describe the tangi- ble and intangible value that the organization is likely to realize from the new system.

B. Car dealers have realized how profi table it can be to sell automobiles using the Web. Pretend that you work for a local car dealership that is part of a large chain such as CarMax. Create a system request you might use to develop a Web-based sales system. Remember to list special issues that are relevant to the project.

C. Suppose that you are interested in buying a new com- puter. Create a cost–benefi t analysis that illustrates the return on investment that you would receive from making this purchase. Computer-related web- sites (e.g., Apple, Dell, HP) should have real tangible costs that you can include in your analysis. Project your numbers out to include a three-year period and provide the net present value of the fi nal total.

D. Th e Amazon.com website originally sold books; then the management of the company decided to extend their Web-based system to include other products. How would you have assessed the feasibility of this venture when the idea fi rst came up? How risky would you have considered the project that implemented this idea? Why?

E. Interview someone who works in a large organization and ask him or her to describe the approval process that exists for approving new development projects. What do they think about the process? What are the problems? What are the benefi ts?

F. Visit a project management website, such as the Project Management Institute (www.pmi.org). Most have links to project management soft ware products, white papers, and research. Examine some of the links for project management to better understand a variety of Internet sites that contain information related to this chapter.

G. Select a specifi c project management topic such as CASE, project management soft ware, or timeboxing and search for information on that topic using the

Web. Any search engine (e.g., Bing, Google) can pro- vide a starting point for your eff orts.

H. Pretend that the career services offi ce at your univer- sity wants to develop a system that collects student résumés and makes them available to students and recruiters over the Web. Students should be able to input their résumé information into a standard résumé template. Th e information then is presented in a résumé format, and it also is placed in a database that can be queried using an online search form. You have been put in charge of the project. Develop a plan for estimating the project. How long do you think it would take for you and three other students to complete the project? Provide support for the schedule that you propose.

I. Refer to the situation in exercise H. You have been told that recruiting season begins a month from today and that the new system must be used. How would you approach this situation? Describe what you can do as the project manager to make sure that your team does not burn out from unreasonable deadlines and commitments.

J. Consider the system described in exercise H. Create a workplan listing the tasks that will need to be com- pleted to meet the project’s objectives. Create a Gantt chart and a network diagram in a project management tool (e.g., Microsoft Project) or using a spreadsheet package to graphically show the high-level tasks of the project.

K. Suppose that you are in charge of the project that is described in exercise H and the project will be staff ed by members of your class. Do your classmates have all the right skills to implement such a project? If not, how will you go about making sure that the proper skills are available to get the job done?

L. Complete a use-case point worksheet to estimate the eff ort to build the system described in exercises H, I, J, and K. You will need to make assumptions regarding the actors, the use cases, and the technical complexity and environmental factors.

26. What is timeboxing, and why is it used? 27. Create a list of potential risks that could aff ect the

outcome of a project. 28. Describe the diff erences between a technical lead and

a functional lead. How are they similar? 29. Describe three technical skills and three interpersonal

skills that are very important to have on any project.

30. What are the best ways to motivate a team? What are the worst ways?

31. List three techniques to reduce confl ict. 32. Describe three types of standards and provide exam-

ples of each. 33. What belongs in the project binder? How is the pro-

ject binder organized?

M. Consider the application that is used at your school to register for classes. Complete a use-case point work- sheet to estimate the eff ort to build such an applica- tion. You will need to make some assumptions about the application’s interfaces and the various factors that aff ect its complexity.

N. Pretend that your instructor has asked you and two friends to create a Web page to describe the course to potential students and provide current class informa- tion (e.g., syllabus, assignments, readings) to current students. You have been assigned the role of leader, so you will need to coordinate your activities and those of your classmates until the project is completed. Describe how you would apply the project manage- ment techniques that you have learned in this chapter in this situation. Include descriptions of how you would create a workplan, staff the project, and coordi- nate all activities—yours and those of your classmates.

O. Select two project management soft ware packages and research them using the Web or trade magazines. Describe the features of the two packages. If you were a project manager, which one would you use to help support your job? Why?

P. In 1997, Oxford Health Plans had a computer problem that caused the company to overestimate revenue and underestimate medical costs. Problems were caused by the migration of its claims processing system from the Pick operating system to a UNIX-based system that uses Oracle database soft ware and hardware from Pyramid Technology. As a result, Oxford’s stock price plummeted, and fi xing the system became the number one priority for the company. Suppose that you have been placed in charge of managing the repair of the claims processing system. Obviously, the project team will not be in good spirits. How will you motivate team members to meet the project’s objectives?

MINICASES

1. Th e Amberssen Specialty Company is a chain of twelve retail stores that sell a variety of imported gift items, gourmet chocolates, cheeses, and wines in the Toronto area. Amberssen has an IS staff of three people who have created a simple but eff ective information system of networked point-of-sale registers at the stores and a centralized accounting system at the company head- quarters. Harry Hilman, the head of Amberssens IS group, has just received the following memo from Bill Amberssen, Sales Director (and son of Amberssen’s founder).

Harry—it’s time Amberssen Specialty launched itself on the Internet. Many of our competitors are already there, selling to customers without the expense of a retail storefront, and we should be there too. I project that we could double or triple our annual revenues by selling our products on the Internet. I’d like to have this ready by Th anks- giving, in time for the prime holiday gift -shopping season. Bill

Aft er pondering this memo for several days, Harry scheduled a meeting with Bill so that he could clarify Bill’s vision of this venture. Using the standard con- tent of a system request as your guide, prepare a list of questions that Harry needs to have answered about this project.

2. Th e Decker Company maintains a fl eet of ten service trucks and crews that provide a variety of plumbing, heating, and cooling repair services to residential cus-

tomers. Currently, it takes on average about six hours before a service team responds to a service request. Each truck and crew averages twelve service calls per week, and the average revenue earned per service call is $150. Each truck is in service fi ft y weeks per year. Owing to the diffi culty in scheduling and routing, there is considerable slack time for each truck and crew during a typical week.

In an eff ort to more effi ciently schedule the trucks and crews and improve their productivity, Decker management is evaluating the purchase of a prewritten routing and scheduling soft ware package. Th e benefi ts of the system will include reduced response time to service requests and more productive service teams, but management is having trouble quantifying these benefi ts.

One approach is to make an estimate of how much service response time will decrease with the new system, which then can be used to project the increase in the number of service calls made each week. For example, if the system permits the average service response time to fall to four hours, management believes that each truck will be able to make sixteen service calls per week on average—an increase of four calls per week. With each truck making four additional calls per week and the average revenue per call at $150, the revenue increase per truck per week is $600 (4 3 $150). With ten trucks in service fi ft y weeks per year, the average annual revenue increase will be $300,000 ($600 3 10 3 50).

Minicases  83

Decker Company management is unsure whether the new system will enable response time to fall to four hours on average or if it will be some other number. Th erefore, management has developed the following range of outcomes that may be possible outcomes of the new system, along with probability estimates of each outcome’s occurring.

New Response Time # Calls/Truck/Week Likelihood 2 hours 20 20% 3 hours 18 30% 4 hours 16 50%

Given these fi gures, prepare a spreadsheet model that computes the expected value of the annual revenues to be produced by this new system.

3. Emily Pemberton is an IS project manager facing a dif- fi cult situation. Emily works for the First Trust Bank, which has recently acquired the City National Bank. Before the acquisition, First Trust and City National were bitter rivals, fi ercely competing for market share in the region. Following the acrimonious takeover, numerous staff were laid off in many banking areas, including IS. Key individuals were retained from both banks’ IS areas, however, and were assigned to a new consolidated IS department. Emily has been made pro- ject manager for the fi rst signifi cant IS project since the takeover, and she faces the task of integrating staff ers from both banks on her team. Th e project they are undertaking will be highly visible within the organi- zation, and the time frame for the project is somewhat demanding. Emily believes that the team can meet the project goals successfully, but success will require that the team become cohesive quickly and that potential confl icts be avoided. What strategies do you suggest that Emily implement in order to help ensure a suc- cessfully functioning project team?

4. Tom, Jan, and Julie are IS majors at Great State Uni- versity. Th ese students have been assigned a class project by one of their professors, requiring them to develop a new Web-based system to collect and update information on the IS program’s alumni. Th is system will be used by the IS graduates to enter job and address information as they graduate and then make changes to that information as they change jobs and/or addresses. Th eir professor also has a number of queries that she is interested in being able to imple- ment. Based on their preliminary discussions with

their professor, the students have determined that the only actor is an IS graduate. Th ey identifi ed one sim- ple use case, four average use cases, and two complex use cases. You need to assign reasonable values to each of the technical complexity and environmental factors. Calculate the eff ort for this project.

5. In looking for a capstone project for your fi nal MIS course, you found a possible project. Th e master gar- deners in Blint County have created a database of all of the plants in their arboretum. Th e database is actu- ally a spreadsheet created by one of the volunteers. Along with providing a plant inventory, it is used to print labels of all of the plants that the other master gardeners grow for the annual plant. More than 5,000 plants are supplied each year by 100 garden- ers from their home gardens. Because the type and numbers of plants change each year and because the members e-mail the information in varying formats, label printing has become an onerous task. Pam, who prints the labels each year, wants help in mak- ing this task manageable. She provided an example of a typical email as well as the type of information she needs.

E-mail Lilies—labels needed 32– Lilium lancifolium / lilium tigrinum Tiger Lily perennial light shade 4’

Ice plant (pink)—labels needed 3 Delosperma cooperi Hardy Ice Plant succulent full sun 2–5”

Information for Labels Botanical Name

Common Name Plant Type Light Requirement Height and Width

In order to have this accepted as your project, you need to form a team with the necessary skills and to create a systems request. How would you approach this project? What additional information do you need from Pam in order to begin estimating the scope of this project? Assuming that you have received this information, create a systems request. Also create a list of skills needed, the number of team members required, and a project plan.

8 4 C h a p t e r 2   Project Management

Analysis modeling answers the questions of who will use the system, what the system will do, and where and when it will be used. During analysis, detailed requirements are identifi ed and a system proposal is created. Th e team then produces the functional model (use-case diagram, activity diagrams, and use-case descriptions), structural model (CRC cards and class diagram, and object diagrams), and behavioral models (sequence diagrams, communication diagrams, behavioral state machines, and a CRUDE matrix).

CHAPTER 3 Requirements Determination

CHAPTER 4 Business Process and Functional

Modeling

CHAPTER 5 Structural Modeling

CHAPTER 6 Behavioral Modeling

R eq

u irem

en ts

D efi n

itio n

System P ro

p o sal

U se-C

ase D

escrip tio

n s

O b ject

D iagram

s C

ru d e

M atrix

U se-C

ase D

iagram s

A ctivity

D iagram

s C

R C

C ard

s C

lass D

iagram s

Seq u en

ce D

iagram s

C o m

m u

n icatio

n D

iagram s

B eh

avio ral

State M ach

in es

P A R T O N E Analysis Modeling

86

One of the fi rst activities of an analyst is to determine the business requirements for a new system. Th is chapter begins by presenting the requirements defi nition, a document that lists the new system’s capabilities. It then describes how to analyze requirements using require- ments analysis strategies and how to gather requirements using interviews, JAD sessions, questionnaires, document analysis, and observation. Th e chapter also describes a set of alter- native requirements-documentation techniques and describes the system proposal document that pulls everything together.

OBJECTIVES

■ Understand how to create a requirements defi nition ■ Become familiar with requirements-analysis techniques ■ Understand when to use each requirements-analysis technique ■ Understand how to gather requirements using interviews, JAD sessions, questionnaires,

document analysis, and observation ■ Understand the use of concept maps, story cards, and task lists as requirements-

documentation techniques ■ Understand when to use each requirements-gathering technique ■ Be able to begin creating a system proposal

INTRODUCTION Th e systems development process aids an organization in moving from the current system (oft en called the as-is system) to the new system (oft en called the to-be system). Th e output of planning, discussed in Chapter 2, is the system request, which provides general ideas for the to-be system, defi nes the project’s scope, and provides the initial workplan. Analysis takes the general ideas in the system request and refi nes them into a detailed requirements defi nition (this chapter), functional models (Chapter 4), structural models (Chapter 5), and behavioral models (Chapter 6) that together form the system proposal. Th e system proposal also includes revised project management deliverables, such as the feasibility analysis and the workplan (Chapter 2).

Th e output of analysis, the system proposal, is presented to the approval committee, who decides if the project is to continue. If approved, the system proposal moves into design, and its elements (requirements defi nition and functional, structural, and behavioral models) are used as inputs to the steps in design. Th is further refi nes them and defi nes in much more detail how the system will be built.

Th e line between analysis and design is very blurry. Th is is because the deliverables created during analysis are really the fi rst step in the design of the new system. Many of the major design decisions for the new system are found in the analysis deliverables. It is

C H A P T E R 3

Requirements Determination

Requirements Determination  87

important to remember that the deliverables from analysis are really the fi rst step in the design of the new system.

In many ways, because it is here that the major elements of the system fi rst emerge, the requirements-determination step is the single most critical step of the entire system devel- opment process. During requirements determination, the system is easy to change because little work has been done yet. As the system moves through the system development process, it becomes harder and harder to return to requirements determination and to make major changes because of all of the rework that is involved. Several studies have shown that more than half of all system failures are due to problems with the requirements.1 Th is is why the iterative approaches of object-oriented methodologies are so eff ective—small batches of requirements can be identifi ed and implemented in incremental stages, allowing the overall system to evolve over time.

REQUIREMENTS DETERMINATION Th e purpose of requirements determination is to turn the very high-level explanation of the business requirements stated in the system request into a more precise list of require- ments that can be used as inputs to the rest of analysis (creating functional, structural, and behavioral models). Th is expansion of the requirements ultimately leads to the design of the system.

Defi ning a Requirement A requirement is simply a statement of what the system must do or what characteristic it must have. During analysis, requirements are written from the perspective of the busi- nessperson, and they focus on the “what” of the system. Because they focus on the needs of the business user, they are usually called business requirements (and sometimes user requirements). Later in design, business requirements evolve to become more technical, and they describe how the system will be implemented. Requirements in design are writ- ten from the developer’s perspective, and they are usually called system requirements.

We want to stress that there is no black-and-white line dividing a business requirement and a system requirement—and some companies use the terms interchangeably. Th e impor- tant thing to remember is that a requirement is a statement of what the system must do, and requirements will change over time as the project moves from inception to elaboration to construction. Requirements evolve from detailed statements of the business capabilities that a system should have to detailed statements of the technical way the capabilities will be implemented in the new system.

Requirements can be either functional or nonfunctional in nature. A functional require- ment relates directly to a process a system has to perform or information it needs to contain. For example, requirements stating that a system must have the ability to search for available inventory or to report actual and budgeted expenses are functional requirements. Functional requirements fl ow directly into the creation of functional, structural, and behavioral models that represent the functionality of the evolving system (see Chapters 4, 5, and 6).

Nonfunctional requirements refer to behavioral properties that the system must have, such as performance and usability. Th e ability to access the system using a Web browser is considered a nonfunctional requirement. Nonfunctional requirements can infl uence the rest of analysis (functional, structural, and behavioral models) but oft en do so only indirectly; nonfunctional requirements are used primarily in design when decisions are made about the database, the user interface, the hardware and soft ware, and the system’s underlying physical architecture. 1 For example, see Th e Scope of Soft ware Development Project Failures (Dennis, MA: Th e Standish Group, 1995).

8 8 C h a p t e r 3   Requirements Determination

Nonfunctional requirements describe a variety of characteristics regarding the system: operational, performance, security, and cultural and political. Operational requirements address issues related to the physical and technical requirements in which the system will operate. Performance requirements address issues related to the speed, capacity, and reli- ability of the system. Security requirements deal with issues with regard to who has access to the system and under what specifi c circumstances. Cultural and political requirements deal with issues related to the cultural, political factors and legal requirements that aff ect the system. Th ese characteristics do not describe business processes or information, but they are very important in understanding what the fi nal system should be like. Nonfunctional requirements primarily aff ect decisions that will be made during the design of a system. We will return to this topic later in the book when we discuss design (see Chapters 9, 10, and 11).

One area of information systems development that focused on diff erentiating functional and nonfunctional requirements is soft ware quality. Th ere have been many diff erent models proposed to measure the quality of soft ware. However, virtually all of them diff erentiate func- tional and nonfunctional requirements. From a quality perspective, functional quality is related to the degree that the soft ware meets the functional requirements, i.e., how much of the actual problem is solved by the soft ware solution provided. Whereas, the nonfunctional requirements are associated with the effi ciency, maintainability, portability, reliability, reusability, testability, and usability quality dimensions. As stated above, the nonfunctional related dimensions are associated primarily with the actual detailed design and implementation of the system.

When considering ISO 9000 compliance, quality dimensions are further decomposed into those that the user can see (external) and those that the user cannot see (internal). Th e external nonfunctional dimensions include effi ciency, reliability, and usability, whereas the internal nonfunctional dimensions include maintainability, portability, reusability, and testability. From a user perspective, the external dimensions are more important. If the system is simply too diffi cult to use, regardless how well the system solves the problem, the user will simply not use the system. In other words, from a user’s perspective, for an information system to be successful, the system must not only meet the functional specifi cation, but it must also meet the external nonfunctional specifi cations. From a developer perspective, the internal dimen- sions are also important. For example, given that successful systems tend to be long-lived and multiplatform, both the maintainability and portability dimensions can have strategic implica- tions for the system being developed. Also, given the agile development approaches being used in industry today, the development of reusable and testable soft ware is crucial.

Th ree additional topics that have infl uenced information system requirements are the Sarbanes-Oxley Act, COBIT (Control OBjectives for Information and related Technology) compliance and Capability Maturity Model compliance. Depending on the system being con- sidered, these three topics could aff ect the defi nition of a system’s functional requirements, nonfunctional requirements, or both. Th e Sarbanes-Oxley Act, for example, mandates addi- tional functional and nonfunctional requirements. Th ese include additional security concerns (nonfunctional) and specifi c information requirements that management must now provide (functional). When developing fi nancial information systems, information system developers should be sure to include Sarbanes-Oxley expertise in the development team. Moreover, a client could insist on COBIT compliance or that a specifi c Capability Maturity Model level had been reached in order for the fi rm to be considered as a possible vendor to supply the system under consideration. Obviously, these types of requirements add to the nonfunctional requirements. Further discussion of these topics is beyond the scope of this book.2

2 A concise discussion of the Sarbanes-Oxley Act is presented in G. P. Lander, What is Sarbanes-Oxley? (New York: McGraw-Hill, 2004). A good reference for Sarbanes-Oxley Act-based security requirements is D. C. Brewer, Security Controls for Sarbanes-Oxley Section 404 IT Compliance: Authorization, Authentication, and Access (Indianapolis, IN: Wiley, 2006). For detailed information on COBIT, see www.isaca.org; for ISO 9000, see www.iso.org; and for details on the Capability Maturity Model, see www.sei.cmu.edu/cmmi/.

Requirements Determination  89

Another recent topic that infl uences requirements for some systems is globalization. For example, a global information supply chain generates a large number of additional nonfunc- tional requirements. If the necessary operational environments do not exist for a mobile solu- tion to be developed, it is important to adapt the solution to the local environment. Or, it may not be reasonable to expect to deploy a high-technology-based solution in an area that does not have the necessary power and communications infrastructure. In some cases, we may need to consider supporting some parts of the global information supply chain with manual—rather than automated—systems.

Manual systems have an entirely diff erent set of requirements that create diff erent per- formance expectations and additional security concerns. Furthermore, cultural and political concerns are potentially paramount. A simple example that aff ects the design of user inter- faces is the proper use of color on forms (on a screen or paper). Diff erent cultures interpret diff erent colors diff erently. In other words, in a global, multicultural business environment, addressing cultural concerns goes well beyond simply having a multilingual user interface. We must be able to adapt the global solution to the local realities. Friedman refers to these concerns as glocalization.3 Otherwise, we will simply create another example of a failed infor- mation system development project.

Requirements Defi nition Th e requirements defi nition report—usually just called the requirements defi nition—is a straightforward text report that simply lists the functional and nonfunctional requirements in an outline format. Figure 3-1 shows a sample requirements defi nition for an appointment system for a typical doctor’s offi ce. Notice it contains both functional and nonfunctional requirements. Th e functional requirements include managing appointments, producing schedules, and recording the availability of the individual doctors. Th e nonfunctional require- ments include items such as the expected amount of time that it takes to store a new appoint- ment, the need to support wireless printing, and which types of employees have access to the diff erent parts of the system.

Th e requirements are numbered in a legal or outline format so that each requirement is clearly identifi ed. Th e requirements are fi rst grouped into functional and nonfunctional requirements; within each of those headings, they are further grouped by the type of nonfunc- tional requirement or by function.

Sometimes business requirements are prioritized on the requirements defi nition. Th ey can be ranked as having high, medium, or low importance in the new system, or they can be labeled with the version of the system that will address the requirement (e.g., release 1, release 2, release 3). Th is practice is particularly important when using object-oriented meth- odologies since they deliver systems in an incremental manner.

Th e most obvious purpose of the requirements defi nition is to provide the information needed by the other deliverables in analysis, which include functional, structural, and behav- ioral models, and to support activities in design. Th e most important purpose of the require- ments defi nition, however, is to defi ne the scope of the system. Th e document describes to the analysts exactly what the system needs to end up doing. When discrepancies arise, the document serves as the place to go for clarifi cation.

Determining Requirements Determining requirements for the requirements defi nition is both a business task and an information technology task. In the early days of computing, there was a presumption that

3 T. L. Friedman, Th e World is Flat: A Brief History of the Twenty-First Century, Updated and Expanded Edition. (New York: Farrar, Straus, and Giroux, 2006.)

9 0 C h a p t e r 3   Requirements Determination

the systems analysts, as experts with computer systems, were in the best position to defi ne how a computer system should operate. Many systems failed because they did not adequately address the true business needs of the users. Gradually, the presumption changed so that the users, as the business experts, were seen as being the best position to defi ne how a computer system should operate. However, many systems failed to deliver performance benefi ts because users simply automated an existing ineffi cient system, and they failed to incorporate new opportunities off ered by technology.

Th erefore, the most eff ective approach is to have both business people and analysts working together to determine business requirements. Sometimes, however, users don’t know exactly what they want, and analysts need to help them discover their needs. A set of strategies has become popular to help analysts do problem analysis, root cause analysis, dura- tion analysis, activity-based costing, informal benchmarking, outcome analysis, technology analysis, and activity elimination. Analysts can use these tools when they need to guide the users in explaining what is wanted from a system. Th ese strategies work similarly. Th ey help users critically examine the current state of systems and processes (the as-is system), identify exactly what needs to change, and develop a concept for a new system (the to-be system).

Functional Requirements

1. Manage Appointments 1.1. Patient makes new appointment. 1.2. Patient changes appointment. 1.3. Patient cancels appointment.

2. Produce Schedule 2.1. Office Manager checks daily schedule. 2.2. Office Manager prints daily schedule.

3. Record Doctor Availability 3.1. Doctor updates schedule

Nonfunctional Requirements

1. Operational Requirements 1.1. The system will operate in Windows environment. 1.2. The system should be able to connect to printers wirelessly. 1.3. The system should automatically back up at the end of each day.

2. Performance Requirements 2.1. The system will store a new appointment in 2 seconds or less. 2.2. The system will retrieve the daily appointment schedule in 2 seconds or less.

3. Security Requirements 3.1. Only doctors can set their availability. 3.2. Only a manager can produce a schedule.

4. Cultural and Political Requirements 4.1. No special cultural and political requirements are anticipated.

FIGURE 3-1 Sample Requirements Defi nition

Requirements Determination  91

Although these strategies enable the analyst to help users create a vision for the new system, they are not suffi cient for extracting information about the detailed business require- ments that are needed to build it. Th erefore, analysts use a portfolio of requirements-gathering techniques to acquire information from users. Th e analyst has many techniques from which to choose: interviews, questionnaires, observation, joint application development (JAD), and document analysis. Th e information gathered using these techniques is critically analyzed and used to craft the requirements defi nition report.

Creating a Requirements Defi nition Creating a requirements defi nition is an iterative and ongoing process whereby the analyst collects information with requirements-gathering techniques (e.g., interviews, document analysis), critically analyzes the information to identify appropriate business requirements for the system, and adds the requirements to the requirements defi nition report. Th e require- ments defi nition is kept up to date so that the project team and business users can refer to it and get a clear understanding of the new system.

To create a requirements defi nition, the project team fi rst determines the kinds of func- tional and nonfunctional requirements that they will collect about the system (of course, these may change over time). Th ese become the main sections of the document. Next, the analysts use a variety of requirements-gathering techniques to collect information, and they list the business requirements that were identifi ed from that information. Finally, the analysts work with the entire project team and the business users to verify, change, and complete the list and to help prioritize the importance of the requirements that were identifi ed.

Th is process continues throughout analysis, and the requirements defi nition evolves over time as new requirements are identifi ed and as the project moves into later phases of the Unifi ed Process. Beware: Th e evolution of the requirements defi nition must be carefully man- aged. Th e project team cannot keep adding to the requirements defi nition, or the system will keep growing and growing and never get fi nished. Instead, the project team carefully identifi es requirements and evaluates which ones fi t within the scope of the system. When a requirement refl ects a real business need but is not within the scope of the current system or current release, it is either added on a list of future requirements or given a low priority. Th e management of requirements (and system scope) is one of the hardest parts of managing a project.

Real-World Problems with Requirements Determination Avison and Fitzgerald provide us with a set of problems that can arise with regard to deter- mining the set of requirements with which to be dealt.4 First, the analyst might not have access to the correct set of users to uncover the complete set of requirements. Th is can lead to requirements being missed, misrepresented, and/or overspecifi ed. Second, the specifi cation of the requirements may be inadequate. Th is can be especially true with the lightweight tech- niques associated with agile methodologies. Th ird, some requirements are simply unknowa- ble at the beginning of a development process. However, as the system is developed, the users and analysts will get a better understanding of both the domain issues and the applicable tech- nology. Th is can cause new functional and nonfunctional requirements to be identifi ed and current requirements to evolve or be canceled. Iterative and incremental-based development methodologies, such as the Unifi ed Process and agile, can help in this case. Fourth, verifying and validating of requirements can be very diffi cult. We take up this topic in the chapters that deal with the creation of functional (Chapter 4), structural (Chapter 5), and behavioral (Chapter 6) models.

4 See D. Avison and G. Fitzgerald, Information Systems Development: Methodologies, Techniques, & Tools, 4th Ed. (London: McGraw-Hill, 2006).

9 2 C h a p t e r 3   Requirements Determination

REQUIREMENTS ANALYSIS STRATEGIES Before the project team can determine what requirements are appropriate for a given system, there needs to be a clear vision of the kind of system that will be created and the level of change that it will bring to the organization. Th e basic process of analysis is divided into three steps: understanding the as-is system, identifying improvements, and developing require- ments for the to-be system.

Sometimes the fi rst step (i.e., understanding the as-is system) is skipped or is performed in a cursory manner. Th is happens when no current system exists, if the existing system and processes are irrelevant to the future system, or if the project team is using a RAD or agile development methodology in which the as-is system is not emphasized. Newer RAD, agile, and object-oriented methodologies, such as phased development, prototyping, throwaway prototyping, extreme pro- gramming, and Scrum (see Chapter 1) focus almost exclusively on improvements and the to-be system requirements, and they spend little time investigating the current as-is system.

Requirements analysis strategies help the analyst lead users through the analysis steps so that the vision of the system can be developed. Requirements analysis strategies and requirements-gathering techniques go hand in hand. Analysts use requirements-gathering techniques to collect information; requirements analysis strategies drive the kind of infor- mation that is gathered and how it is ultimately analyzed. Th e requirements analysis strat- egies and requirements gathering happen concurrently and are complementary activities.

To move the users from the as-is system to the to-be system, an analyst needs strong critical thinking skills. Critical thinking is the ability to recognize strengths and weaknesses and recast an idea in an improved form, and critical thinking skills are needed to really under- stand issues and develop new business processes. Th ese skills are also needed to thoroughly examine the results of requirements gathering, to identify business requirements, and to translate those requirements into a concept for the new system.

Problem Analysis Th e most straightforward (and probably the most commonly used) requirements-analysis technique is problem analysis. Problem analysis means asking the users and managers to identify problems with the as-is system and to describe how to solve them in the to-be system. Most users have a very good idea of the changes they would like to see, and most are quite vocal about suggesting them. Most changes tend to solve problems rather than capitalize on opportunities, but the latter is possible as well. Improvements from problem analysis tend to be small and incremental (e.g., provide more space in which to type the customer’s address; provide a new report that currently does not exist).

Th is type of improvement oft en is very eff ective at improving a system’s effi ciency or ease of use. However, it oft en provides only minor improvements in business value—the new system is better than the old, but it may be hard to identify signifi cant monetary benefi ts from the new system.

Root Cause Analysis Th e ideas produced by problem analysis tend to be solutions to problems. All solutions make assumptions about the nature of the problem, assumptions that might or might not be valid. In our experience, users (and most people in general) tend to quickly jump to solutions with- out fully considering the nature of the problem. Sometimes the solutions are appropriate, but many times they address a symptom of the problem, not the true problem or root cause itself.5

5 Two good books that discuss the diffi culty in fi nding the root causes to problems are: E. M. Goldratt and J. Cox, Th e Goal (Croton-on-Hudson, NY: North River Press, 1986); E. M. Goldratt, Th e Haystack Syndrome (Croton-on-Hudson, NY: North River Press, 1990).

Requirements Analysis Strategies  93

For example, suppose a fi rm notices that its users report inventory stock-outs. Th e cost of inventory stock-outs can be quite signifi cant. In this case, since they happen frequently, custom- ers could fi nd another source for the items that they are purchasing from the fi rm. It is in the fi rm’s interest to determine the underlying cause and not simply provide a knee-jerk reaction such as arbitrarily increasing the amount of inventory kept on hand. In the business world, the challenge lies in identifying the root cause—few real-world problems are simple. Th e users typically propose a set of causes for the problem under consideration. Th e solutions that users propose can address either symptoms or root causes, but without a careful analysis, it is diffi cult to tell which one is addressed.

Root cause analysis, therefore, focuses on problems, not solutions. Th e analyst starts by having the users generate a list of problems with the current system and then prioritize the problems in order of importance. Starting with the most important, the users and/or the analysts then generate all the possible root causes for the problems. Each possible root cause is investigated (starting with the most likely or easiest to check) until the true root causes are identifi ed. If any possible root causes are identifi ed for several problems, those should be investigated fi rst, because there is a good chance they are the real root causes infl uencing the symptom problems. In our example, there are several possible root causes:

■ Th e fi rm’s supplier might not be delivering orders to the fi rm in a timely manner. ■ Th ere could be a problem with the fi rm’s inventory controls. ■ Th e reorder level and quantities could be set wrong.

Sometimes, using a hierarchical chart to represent the causal relationships helps with the analysis. As Figure 3-2 shows, there are many possible root causes that underlie the higher-level causes identifi ed. Th e key point in root cause analysis is always to challenge the obvious.

Duration Analysis Duration analysis requires a detailed examination of the amount of time it takes to perform each process in the current as-is system. Th e analysts begin by determining the total amount of time it takes, on average, to perform a set of business processes for a typical input. Th ey then time each of the individual steps (or subprocesses) in the business process. Th e time to

Frequent Inventory Stock-Outs

Order Approval Late

Identifying Vendor Delayed

Delay in Sending Order to Vendor

Delays in Order Processing

Late Recording of Sales

Late Recording of Purchases Received

Infrequent Manual Inventory Reconciliation

Problems with Inventory Controls

Reorder point set too low

Reorder Quantity (EOQ) set too low

Incorrect Reorder Level and Quantities

FIGURE 3-2 Root Cause Analysis for Inventory Stock-Outs

complete the basic step is then totaled and compared to the total for the overall process. A signifi cant diff erence between the two—and in our experience the total time oft en can be 10 or even 100 times longer than the sum of the parts—indicates that this part of the process is badly in need of a major overhaul.

For example, suppose that the analysts are working on a home mortgage system and dis- cover that on average, it takes thirty days for the bank to approve a mortgage. Th ey then look at each of the basic steps in the process (e.g., data entry, credit check, title search, appraisal) and fi nd that the total amount of time actually spent on each mortgage is about eight hours. Th is is a strong indication that the overall process is badly broken, because it takes thirty days to perform one day’s work.

Th ese problems probably occur because the process is badly fragmented. Many diff erent people must perform diff erent activities before the process fi nishes. In the mortgage exam- ple, the application probably sits on many people’s desks for long periods of time before it is processed.

Processes in which many diff erent people work on small parts of the inputs are prime candidates for process integration or parallelization. Process integration means changing the fundamental process so that fewer people work on the input, which oft en requires changing the processes and retraining staff to perform a wider range of duties. Process parallelization means changing the process so that all the individual steps are performed at the same time. For example, in the mortgage application case, there is probably no reason that the credit check cannot be performed at the same time as the appraisal and title check.

Activity-Based Costing Activity-based costing is a similar analysis; it examines the cost of each major process or step in a business process rather than the time taken.6 Th e analysts identify the costs associated with each of the basic functional steps or processes, identify the most costly processes, and focus their improvement eff orts on them.

Assigning costs is conceptually simple. Analysts simply examine the direct cost of labor and materials for each input. Materials costs are easily assigned in a manufacturing process, whereas labor costs are usually calculated based on the amount of time spent on the input and the hourly cost of the staff . However, as you may recall from a managerial accounting course, there are indirect costs, such as rent, depreciation, and so on, that also can be included in activity costs.

Informal Benchmarking Benchmarking refers to studying how other organizations perform a business process in order to learn how your organization can do something better. Benchmarking helps the organization by introducing ideas that employees may never have considered but that have the potential to add value.

Informal benchmarking is fairly common for customer-facing business processes (i.e., processes that interact with the customer). With informal benchmarking, the managers and analysts think about other organizations or visit them as customers to watch how the business process is performed. In many cases, the business studied may be a known leader in the indus- try or simply a related fi rm.

6 Many books have been written on activity-based costing. Useful ones include K. B. Burk and D. W. Webster, Activity-Based Costing (Fairfax, VA: American Management Systems, 1994); D. T. Hicks, Activity-Based Costing: Making It Work for Small and Mid-sized Companies (New York: Wiley, 1998). Th e two books by Eli Goldratt men- tioned previously (Th e Goal and Th e Haystack Syndrome) also off er unique insights into costing.

9 4 C h a p t e r 3   Requirements Determination

Requirements-Gathering Techniques  95

Outcome Analysis Outcome analysis focuses on understanding the fundamental outcomes that provide value to customers. Although these outcomes sound as though they should be obvious, they oft en are not. For example, consider an insurance company. One of its customers has just had a car accident. What is the fundamental outcome from the customer’s perspective? Traditionally, insurance companies have answered this question by assuming the customer wants to receive the insurance payment quickly. To the customer, however, the payment is only a means to the real outcome: a repaired car. Th e insurance company might benefi t by extending its view of the business process past its traditional boundaries to include not paying for repairs but performing the repairs or contracting with an authorized body shop to do them.

With this approach, system analysts encourage the managers and project sponsor to pretend they are customers and to think carefully about what the organization’s products and services enable the customers to do—and what they could enable the customer to do.

Technology Analysis Many major changes in business since the turn of the century have been enabled by new technologies. Technology analysis starts by having the analysts and managers develop a list of important and interesting technologies. Th en the group systematically identifi es how every technology could be applied to the business process and identifi es how the business would benefi t. It is important to note the technology analysis in no way implies adopting technology for technology’s sake. Rather the focus is on using new technologies to meet the goals of the organization.

Activity Elimination Activity elimination is exactly what it sounds like. Th e analysts and managers work together to identify how the organization could eliminate each activity in the business process, how the function could operate without it, and what eff ects are likely to occur. Initially, managers are reluctant to conclude that processes can be eliminated, but this is a force-fi t exercise in that they must eliminate each activity. In some cases, the results are silly; nonetheless, participants must address every activity in the business process.

REQUIREMENTS-GATHERING TECHNIQUES An analyst is very much like a detective (and business users are sometimes like elusive sus- pects). He or she knows that there is a problem to be solved and therefore must look for clues that uncover the solution. Unfortunately, the clues are not always obvious (and are oft en missed), so the analyst needs to notice details, talk with witnesses, and follow leads just as Sherlock Holmes would have done. Th e best analysts thoroughly gather requirements using a variety of techniques and make sure that the current business processes and the needs for the new system are well understood before moving into design. Analysts don’t want to discover later that they have key requirements wrong—such surprises late in the development process can cause all kinds of problems.

Th e requirements-gathering process is used for building political support for the pro- ject and establishing trust and rapport between the project team building the system and the users who ultimately will choose to use or not use the system. Involving someone in the process implies that the project teams view that person as an important resource and value his or her opinions. All the key stakeholders (the people who can aff ect the system or who will be aff ected by the system) must be included in the requirements-gathering process. Th e

stakeholders might include managers, employees, staff members, and even some customers and suppliers. If a key person is not involved, that individual might feel slighted, which can cause problems during implementation (e.g., How could they have developed the system without my input?).

Th e second challenge of requirements gathering is choosing the way(s) information is collected. Th ere are many techniques for gathering requirements that vary from asking people questions to watching them work. In this section, we focus on the fi ve most commonly used techniques: interviews, JAD sessions (a special type of group meeting), questionnaires, docu- ment analysis, and observation. Each technique has its own strengths and weaknesses, many of which are complementary, so most projects use a combination of techniques.7

Interviews An interview is the most commonly used requirements-gathering technique. Aft er all, it is natural—if you need to know something, you usually ask someone. In general, interviews are conducted one-on-one (one interviewer and one interviewee), but sometimes, owing to time constraints, several people are interviewed at the same time. Th ere are fi ve basic steps to the inter- view process: selecting interviewees, designing interview questions, preparing for the interview, conducting the interview, and postinterview follow-up.8

Th e fi rst step in interviewing is to create an interview schedule listing who will be interviewed, when, and for what purpose (see Figure 3-3). Th e schedule can be an informal list that is used to help set up meeting times or a formal list that is incorporated into the workplan. Th e people who appear on the interview schedule are selected based on the analyst’s information needs. Th e project sponsor, key business users, and other members of the project team can help the analyst determine who in the organization can best provide important information about requirements. Th ese people are listed on the interview schedule in the order in which they should be interviewed.

People at diff erent levels of the organization have varying perspectives on the system, so it is important to include both managers who manage the processes and staff who actually perform the processes to gain both high-level and low-level perspectives on an issue. Also, the kinds of interview subjects needed can change over time. For example, at the start of the project, the analyst has a limited understanding of the as-is business process. It is common to begin by interviewing one or two senior managers to get a strategic view and then to move to midlevel managers who can provide broad, overarching information about the business process and the expected role of the system being developed. Once the analyst has a good understanding of the big picture, lower-level managers and staff members can fi ll in the exact details of how the process works. Like most other things about systems analysis, this is an iterative process—starting with senior managers, moving to midlevel managers, then staff members, back to midlevel managers, and so on, depending upon what information is needed along the way.

It is quite common for the list of interviewees to grow, oft en by 50 to 75 percent. As peo- ple are interviewed, more information that is needed and additional people who can provide the information will probably be identifi ed.

7 Some excellent books that address the importance of gathering requirements and various techniques include Alan M. Davis, Soft ware Requirements: Objects, Functions, & States, Revision (Englewood Cliff s, NJ: Prentice Hall, 1993); Gerald Kotonya and Ian Sommerville, Requirements Engineering (Chichester, England: Wiley, 1998); Dean Leffi ngwell and Don Widrig, Managing Soft ware Requirements: A Unifi ed Approach (Reading, MA: Addison-Wesley, 2000). 8 A good book on interviewing is that by Brian James, Th e Systems Analysis Interview (Manchester, England: NCC Blackwell, 1989).

1. Select Interviewees

9 6 C h a p t e r 3   Requirements Determination

Requirements-Gathering Techniques  97

Th ere are three types of interview questions: closed-ended questions, open-ended questions, and probing questions. Closed-ended questions are those that require a specifi c answer. Th ey are similar to multiple-choice or arithmetic questions on an exam (see Figure 3-4). Closed- ended questions are used when an analyst is looking for specifi c, precise information (e.g., how many credit card requests are received per day). In general, precise questions are best. For example, rather than asking, Do you handle a lot of requests? it is better to ask, How many requests do you process per day? Closed-ended questions enable analysts to control the inter- view and obtain the information they need. However, these types of questions don’t uncover why the answer is the way it is, nor do they uncover information that the interviewer does not think to ask for ahead of time.

Open-ended questions are those that leave room for elaboration on the part of the inter- viewee. Th ey are similar in many ways to essay questions that you might fi nd on an exam (see Figure 3-4 for examples). Open-ended questions are designed to gather rich information and give the interviewee more control over the information that is revealed during the interview. Sometimes the information that the interviewee chooses to discuss uncovers information that is just as important as the answer (e.g., if the interviewee talks only about other departments when asked for problems, it may suggest that he or she is reluctant to admit his or her own problems).

Th e third type of question is the probing question. Probing questions follow up on what has just been discussed in order to learn more, and they oft en are used when the interviewer is unclear about an interviewee’s answer. Th ey encourage the interviewee to expand on or to con- fi rm information from a previous response, and they signal that the interviewer is listening and is interested in the topic under discussion. Many beginning analysts are reluctant to use probing questions because they are afraid that the interviewee might be off ended at being challenged or because they believe it shows that they didn’t understand what the interviewee said. When done politely, probing questions can be a powerful tool in requirements gathering.

In general, an interviewer should not ask questions about information that is readily available from other sources. For example, rather than asking what information is used to perform to a task, it is simpler to show the interviewee a form or report (see the section on document analysis) and ask what information on it is used. Th is helps focus the interviewee on the task and saves time, because the interviewee does not need to describe the information detail—he or she just needs to point it out on the form or report.

No type of question is better than another, and a combination of questions is usually used during an interview. At the initial stage of an IS development project, the as-is process can

2. Design Interview Questions

FIGURE 3-3 Sample Interview Schedule

Andria McClellan Director, Accounting Strategic vision for new Mon., March 1 accounting system 8:00–10:00 AM

Jennifer Draper Manager, Accounts Current problems with Mon., March 1 Receivable accounts receivable 2:00–3:15 PM process; future goals

Mark Goodin Manager, Accounts Current problems with Mon., March 1 Payable accounts payable 4:00–5:15 PM process; future goals

Anne Asher Supervisor, Data Entry Accounts receivable and Wed., March 3 payable processes 10:00–11:00 AM

Fernando Merce Data Entry Clerk Accounts receivable and Wed., March 3 payable processes 1:00–3:00 PM

Purpose of Name Position Interview Meeting

be unclear, so the interview process begins with unstructured interviews, interviews that seek broad and roughly defi ned information. In this case, the interviewer has a general sense of the information needed but has few closed-ended questions to ask. Th ese are the most challeng- ing interviews to conduct because they require the interviewer to ask open-ended questions and probe for important information on the fl y.

As the project progresses, the analyst comes to understand the business process much better and needs very specifi c information about how business processes are performed (e.g., exactly how a customer credit card is approved). At this time, the analyst conducts structured interviews, in which specifi c sets of questions are developed before the interviews. Th ere usually are more closed-ended questions in a structured interview than in the unstructured approach.

No matter what kind of interview is being conducted, interview questions must be organized into a logical sequence so that the interview fl ows well. For example, when trying to gather information about the current business process, it can be useful to move in logical order through the process or from the most important issues to the least important.

Th ere are two fundamental approaches to organizing the interview questions: top down or bottom up (see Figure 3-5). With the top-down interview, the interviewer starts with broad, general issues and gradually works toward more-specifi c ones. With the bottom-up interview, the interviewer starts with very specifi c questions and moves to broad questions. In practice, analysts mix the two approaches, starting with broad, general issues, moving to specifi c ques- tions, and then returning to general issues.

Th e top-down approach is an appropriate strategy for most interviews (it is certainly the most common approach). Th e top-down approach enables the interviewee to become accus- tomed to the topic before he or she needs to provide specifi cs. It also enables the interviewer to understand the issues before moving to the details because the interviewer might not have suffi cient information at the start of the interview to ask very specifi c questions. Perhaps most importantly, the top-down approach enables the interviewee to raise a set of big-picture issues before becoming enmeshed in details, so the interviewer is less likely to miss important issues.

One case in which the bottom-up strategy may be preferred is when the analyst already has gathered a lot of information about issues and just needs to fi ll in some holes with details. Bottom-up interviewing may be appropriate if lower-level staff members feel threatened or unable to answer high-level questions. For example, How can we improve customer service? might be too broad a question for a customer service clerk, whereas a specifi c question is readily answerable (e.g., How can we speed up customer returns?). In any event, all interviews should begin with noncontroversial questions and then gradually move into more contentious issues aft er the interviewer has developed some rapport with the interviewee.

Closed-ended questions • How many telephone orders are received per day?

• How do customers place orders?

• What information is missing from the monthly sales report?

Open-ended questions • What do you think about the current system?

• What are some of the problems you face on a daily basis?

• What are some of the improvements you would like to see in a new system?

Probing questions • Why?

• Can you give me an example?

• Can you explain that in a bit more detail?

FIGURE 3-4 Three Types of Questions

Types of Questions Examples

9 8 C h a p t e r 3   Requirements Determination

Requirements-Gathering Techniques  99

It is important to prepare for the interview in the same way that you would prepare to give a presentation. Th e interviewer should have a general interview plan listing the questions to be asked in the appropriate order, should anticipate possible answers and provide follow-up with them, and should identify segues between related topics. Th e interviewer should con- fi rm the areas in which the interviewee has knowledge so as not to ask questions that the interviewee cannot answer. Review the topic areas, the questions, and the interview plan, and clearly decide which have the greatest priority in case time runs short.

In general, structured interviews with closed-ended questions take more time to prepare than unstructured interviews. Some beginning analysts prefer unstructured interviews, think- ing that they can wing it. Th is is very dangerous and oft en counterproductive, because any information not gathered in the fi rst interview will require follow-up eff orts, and most users do not like to be interviewed repeatedly about the same issues.

Th e interviewer should be sure to prepare the interviewee as well. When the interview is scheduled, the interviewee should be told the reason for the interview and the areas that will be discussed far enough in advance so that he or she has time to think about the issues and organize his or her thoughts. Th is is particularly important when the interviewer is an outsider to the organization and for lower-level employees, who oft en are not asked for their opinions and who may be uncertain about why they are being interviewed.

Th e fi rst goal is to build rapport with the interviewee, so that he or she trusts the inter- viewer and is willing to tell the whole truth, not just give the answers that he or she thinks are wanted. Th e interviewer should appear to be a professional and unbiased, independent seeker of information. Th e interview should start with an explanation of why the inter- viewer is there and why he or she has chosen to interview the person; then the interviewer should move into the planned interview questions.

It is critical to carefully record all the information that the interviewee provides. In our experience, the best approach is to take careful notes—write down everything the interviewee says, even if it does not appear immediately relevant. Th e interviewer shouldn’t be afraid to ask the person to slow down or to pause while writing, because this is a clear indication that the interviewee’s information is important. One potentially controversial issue is whether or not to tape-record an interview. Recording ensures that the interviewer does not miss important

3. Prepare for the Interview

4. Conduct the Interview

FIGURE 3-5 Top-Down and Bottom-Up Questioning Strategies

High-level: Very general

Top-Down

Bottom-Up

Medium-level: Moderately specific

Low-level: Very specific

How can order processing

be improved?

How can we reduce the number of times that customers return items

they’ve ordered?

How can we reduce the number of errors in order processing (e.g., shipping

the wrong products)?

points, but it can be intimidating for the interviewee. Most organizations have policies or generally accepted practices about the recording of interviews, so they should be determined before an interview. If the interviewer is worried about missing information and cannot tape the interview, then he or she can bring along a second person to take detailed notes.

As the interview progresses, it is important to understand the issues that are discussed. If the interviewer does not understand something, he or she should ask for clarifi cation. Th e interviewer should not be afraid to ask dumb questions, because the only thing worse than appearing dumb is to be dumb by not understanding something. If the interviewer doesn’t understand something during the interview, he or she certainly won’t understand it aft erwards. Jargon should be recognized and defi ned; any jargon not understood should be clarifi ed. One good strategy to increase understanding during an interview is to periodically summarize the key points that the interviewee is communicating. Th is avoids misunder- standings and also demonstrates that the interviewer is listening.

Finally, facts should be separated from opinion. Th e interviewee may say, for example, We process too many credit card requests. Th is is an opinion, and it is useful to follow this up with a probing question requesting support for the statement (e.g., Oh, how many do you process in a day?). It is helpful to check the facts because any diff erences between the facts and the interviewee’s opinions can point out key areas for improvement. Suppose the inter- viewee complains about a high or increasing number of errors, but the logs show that errors have been decreasing. Th is suggests that errors are viewed as a very important problem that should be addressed by the new system, even if they are declining.

As the interview draws to a close, the interviewee should have time to ask questions or provide information that he or she thinks is important but was not part of the interview plan. In most cases, the interviewee has no additional concerns or information, but in some cases this leads to unanticipated, but important, information. Likewise, it can be useful to ask the interviewee if there are other people who should be interviewed. Th e interview should end on time (if necessary, some topics can be omitted or another interview can be scheduled).

As a last step in the interview, the interviewer should briefl y explain what will happen. Th e interviewer shouldn’t prematurely promise certain features in the new system or a spe- cifi c delivery date, but he or she should reassure the interviewee that his or her time was well spent and very helpful to the project.

Aft er the interview is over, the analyst needs to prepare an interview report that describes the information from the interview (Figure 3-6). Th e report contains interview notes, information that was collected over the course of the interview and is summarized in a useful format. In general, the interview report should be written within forty-eight hours of the interview, because the longer the interviewer waits, the more likely he or she is to forget information.

Oft en, the interview report is sent to the interviewee with a request to read it and inform the analyst of clarifi cations or updates. Th e interviewee needs to be convinced that the inter- viewer genuinely wants his or her corrections to the report. Usually there are few changes, but the need for any signifi cant changes suggests that a second interview will be required. Never distribute someone’s information without prior approval.

Joint Application Development (JAD) JAD is an information-gathering technique that allows the project team, users, and management to work together to identify requirements for the system. IBM developed the JAD technique in the late 1970s, and it is oft en the most useful method for collecting information from users.9

9 More information on JAD can be found in J. Wood and D. Silver, Joint Application Development (New York: Wiley, 1989); Alan Cline, “Joint Application Development for Requirements Collection and Management,” http:// www.carolla.com/wp-jad.htm.

5. Post-Interview Follow-up

1 0 0 C h a p t e r 3   Requirements Determination

Requirements-Gathering Techniques  101

Capers Jones claims that JAD can reduce scope creep by 50 percent and prevent the system’s requirements from being too specifi c or too vague, both of which cause trouble during later stages of the development process.10

JAD is a structured process in which ten to twenty users meet together under the direc- tion of a facilitator skilled in JAD techniques. Th e facilitator sets the meeting agenda and guides the discussion but does not join in the discussion as a participant. He or she does not provide ideas or opinions on the topics under discussion so as to remain neutral during the session. Th e facilitator must be an expert in both group-process techniques and systems- analysis and design techniques. One or two scribes assist the facilitator by recording notes, making copies, and so on. Oft en the scribes use computers and CASE tools to record infor- mation as the JAD session proceedings.

Th e JAD group meets for several hours, several days, or several weeks until all the issues have been discussed and the needed information is collected. Most JAD sessions take place in a specially prepared meeting room, away from the participants’ offi ces so that they are not interrupted. Th e meeting room is usually arranged in a U-shape so that all participants can easily see each other. At the front of the room (the open part of the U), are a whiteboard, fl ip chart, and/or overhead projector for use by the facilitator leading the discussion.

FIGURE 3-6 Interview Report

Interview Notes Approved by: Linda Estey

Person Interviewed: Linda Estey,

Director, Human Resources

Interviewer: Barbara Wixom

Purpose of Interview:

• Understand reports produced for Human Resources by the current system

• Determine information requirements for future system

Summary of Interview:

• Sample reports of all current HR reports are attached to this report. The information that is not used and missing information are noted on the reports.

• Two biggest problems with the current system are:

1. The data are too old (the HR Department needs information within two days of month end; currently, information is provided to them after a three-week delay)

2. The data are of poor quality (often reports must be reconciled with departmental HR database)

• The most common data errors found in the current system include incorrect job level information and missing salary information.

Open Items:

• Get current employee roster report from Mary Skudrna (extension 4355).

• Verify calculations used to determine vacation time with Mary Skudrna.

• Schedule interview with Jim Wack (extension 2337) regarding the reasons for data quality problems.

Detailed Notes: See attached transcript.

10 See Kevin Strehlo, “Catching up with the Jones and ‘Requirement’ Creep,” Infoworld (July 29, 1996); Kevin Strehlo, “Th e Makings of a Happy Customer: Specifying Project X,” Infoworld (November 11, 1996).

JAD suff ers from the traditional problems associated with groups: Sometimes people are reluctant to challenge the opinions of others (particularly their boss), a few people oft en dominate the discussion, and not everyone participates. In a fi ft een-member group, for exam- ple, if everyone participates equally, then each person can talk for only four minutes each hour and must listen for the remaining fi ft y-six minutes—not a very effi cient way to collect information.

A new form of JAD called electronic JAD, or e-JAD, attempts to overcome these prob- lems by using groupware. In an e-JAD meeting room, each participant uses special soft ware on a networked computer to send anonymous ideas and opinions to everyone else. In this way, all participants can contribute at the same time without fear of reprisal from people with diff ering opinions. Initial research suggests that e-JAD can reduce the time required to run JAD sessions by 50 to 80 percent.11 A good JAD approach follows a set of fi ve steps.

JAD participants are selected in the same way as are interview participants, based on the information they can contribute in order to provide a broad mix of organizational levels and to build political support for the new system. Th e need for all JAD participants to be away from their offi ce at the same time can be a major problem. Th e offi ce might need to be closed or operate with a skeleton staff until the JAD sessions are complete.

11 For more information on e-JAD, see A. R. Dennis, G. S. Hayes, and R. M. Daniels, “Business Process Modeling with Groupware,” Journal of Management Information Systems 15, no. 4 (1999): 115–142.

1. Select Participants

1 0 2 C h a p t e r 3   Requirements Determination

Interpersonal skills are skills that enable you to develop rapport with others, and they are very important for interviewing. They help you to communicate with others effectively. Some people develop good interpersonal skills at an early age; they simply seem to know how to communicate and interact with others. Other people are less lucky and need to work hard to develop their skills.

Interpersonal skills, like most skills, can be learned. Here are some tips:

• Don’t worry, be happy. Happy people radiate con- fi dence and project their feelings on others. Try inter- viewing someone while smiling and then interviewing someone else while frowning and see what happens.

• Pay attention. Pay attention to what the other person is saying (which is harder than you might think). See how many times you catch yourself with your mind on something other than the conversation at hand.

• Summarize key points. At the end of each major theme or idea that someone explains, repeat the key points back to the speaker (e.g., Let me make sure I

understand. The key issues are. . . .”). This demon- strates that you consider the information important, and it also forces you to pay attention (you can’t repeat what you didn’t hear).

• Be succinct. When you speak, be succinct. The goal in interviewing (and in much of life) is to learn, not to impress. The more you speak, the less time you give to others.

• Be honest. Answer all questions truthfully, and if you don’t know the answer, say so.

• Watch body language (yours and theirs). The way a person sits or stands conveys much information. In general, a person who is interested in what you are saying sits or leans forward, makes eye contact, and often touches his or her face. A person leaning away from you or with an arm over the back of a chair is uninterested. Crossed arms indicate defensiveness or uncertainty, and steepling (sitting with hands raised in front of the body with fi ngertips touching) indi- cates a feeling of superiority.

3-1 Developing Interpersonal SkillsPRACTICAL

TIP

Requirements-Gathering Techniques  103

Ideally, the participants who are released from regular duties to attend the JAD sessions should be the very best people in that business unit. However, without strong management support, JAD sessions can fail because those selected to attend the JAD session are people who are less likely to be missed (i.e., the least competent people).

Th e facilitator should be someone who is an expert in JAD or e-JAD techniques and, ideally, someone who has experience with the business under discussion. In many cases, the JAD facilitator is a consultant external to the organization because the organization might not have a recurring need for JAD or e-JAD expertise. Developing and maintaining this expertise in-house can be expensive.

JAD sessions can run from as little as half a day to several weeks, depending upon the size and scope of the project. In our experience, most JAD sessions tend to last fi ve to ten days, spread over a three-week period. Most e-JAD sessions tend to last one to four days in a one-week period. JAD and e-JAD sessions usually go beyond collecting information and move into anal- ysis. For example, the users and the analysts collectively can create analysis deliverables, such as the functional models or the requirements defi nition.

JAD sessions usually are designed and structured using the same principles as inter- views. Most JAD sessions are designed to collect specifi c information from users, and this requires developing a set of questions before the meeting. One diff erence between JAD and interviewing is that all JAD sessions are structured—they must be carefully planned. In general, closed-ended questions are seldom used because they do not spark the open and frank discussion that is typical of JAD. In our experience, it is better to proceed top down in JAD sessions when gathering information. Typically thirty minutes is allocated to each separate agenda item, and frequent breaks are scheduled throughout the day because participants tire easily.

As with interviewing, it is important to prepare the analysts and participants for a JAD session. Because the sessions can go beyond the depth of a typical interview and are usually conducted off -site, participants may be more concerned about how to prepare. It is impor- tant that the participants understand what is expected of them. If the goal of the JAD session, for example, is to develop an understanding of the current system, then participants can bring procedure manuals and documents with them. If the goal is to identify improvements for a system, then before they come to the JAD session they can think about how they would improve the system.

Most JAD sessions follow a formal agenda, and most have formal ground rules that defi ne appro- priate behavior. Common ground rules include following the schedule, respecting others’ opin- ions, accepting disagreement, and ensuring that only one person talks at a time.

Th e role of a JAD facilitator can be challenging. Many participants come to a JAD session with strong feelings about the system to be discussed. Channeling these feelings so that the ses- sion moves forward in a positive direction and getting participants to recognize and accept—but not necessarily agree on—opinions and situations diff erent from their own requires signifi cant expertise in systems analysis and design, JAD, and interpersonal skills. Few systems analysts attempt to facilitate JAD sessions without being trained in JAD techniques, and most apprentice with a skilled JAD facilitator before they attempt to lead their fi rst session.

Th e JAD facilitator performs three key functions. First, he or she ensures that the group sticks to the agenda. Th e only reason to digress from the agenda is when it becomes clear to the facilitator, project leader, and project sponsor that the JAD session has produced some new information that is unexpected and requires the JAD session (and perhaps the project) to move in a new direction. When participants attempt to divert the discussion away from the

4. Conducting a JAD Session

2. Design a JAD Session

3. Preparing for a JAD Session

agenda, the facilitator must be fi rm but polite in leading discussion back to the agenda and getting the group back on track.

Second, the facilitator must help the group understand the technical terms and jargon that surround the system-development process and help the participants understand the specifi c analysis techniques used. Participants are experts in their area, or their part of the business, but they are not experts in systems analysis. Th e facilitator must, therefore, minimize the learning required and teach participants how to eff ectively provide the right information.

Th ird, the facilitator records the group’s input on a public display area, which can be a whiteboard, fl ip chart, or computer display. He or she structures the information that the group provides and helps the group recognize key issues and important solutions. Th e facil- itator must remain neutral at all times and simply help the group through the process. Th e moment the facilitator off ers an opinion on an issue, the group will see him or her not as a neutral party but rather as someone who could be attempting to sway the group into some predetermined solution.

However, this does not mean that the facilitator should not try to help the group resolve issues. For example, if two items appear to be the same to the facilitator, the facilitator should not say, “I think these may be similar.” Instead, the facilitator should ask, “Are these similar?” If the group decides they are, the facilitator can combine them and move on. However, if the group decides they are not similar (despite what the facilitator believes), the facilitator should accept the decision and move on. Th e group is always right, and the facilitator has no opinion.

As with interviews, a JAD post-session report is prepared and circulated among session attendees. Th e post-session report is essentially the same as the interview report in Figure 3-6. Because the JAD sessions are longer and provide more information, it usually takes a week or two aft er the JAD session before the report is complete.

Questionnaires A questionnaire is a set of written questions used to obtain information from individ- uals. Questionnaires are oft en used when there is a large number of people from whom information and opinions are needed. In our experience, questionnaires are a common technique with systems intended for use outside the organization (e.g., by customers or vendors) or for systems with business users spread across many geographic locations. Most people automatically think of paper when they think of questionnaires, but today more questionnaires are being distributed in electronic form, either via e-mail or on the Web. Electronic distribution can save a signifi cant amount of money as compared to dis- tributing paper questionnaires. A good process to use when using questionnaires follows four steps.

As with interviews and JAD sessions, the fi rst step is to identify the individuals to whom the questionnaire will be sent. However, it is not usual to select every person who could provide useful information. Th e standard approach is to select a sample, or subset, of people who are representative of an entire group. Sampling guidelines are discussed in most statistics books, and most business schools include courses that cover the topic, so we do not discuss it here. Th e important point in selecting a sample, however, is to realize that not everyone who receives a questionnaire will actually complete it. On average, only 30 to 50 percent of paper and e-mail questionnaires are returned. Response rates for Web-based questionnaires tend to be signifi cantly lower (oft en only 5 to 30 percent).

1 0 4 C h a p t e r 3   Requirements Determination

1. Select Participants

5. Post-JAD Follow-up

Requirements-Gathering Techniques  105

Managing Problems in JAD Sessions

I have run more than a hundred JAD sessions and have learned several standard “facilitator tricks.” Here are some common problems and some ways to deal with them.

• Domination. The facilitator should ensure that no one person dominates the group discussion. The only way to deal with someone who dominates is head on. Dur- ing a break, approach the person, thank him or her for his or her insightful comments, and ask the person to help you make sure that others also participate.

• Noncontributors. Drawing out people who have par- ticipated very little is challenging because you want to bring them into the conversation so that they will contribute again. The best approach is to ask a direct factual question that you are certain they can answer. And it helps to ask the question in a long way to give them time to think. For example, “Pat, I know you’ve worked shipping orders a long time. You’ve probably been in the shipping department longer than anyone else. Could you help us understand exactly what hap- pens when an order is received in shipping?”

• Side discussions. Sometimes participants engage in side conversations and fail to pay attention to the group. The easiest solution is simply to walk close to the people and continue to facilitate right in front of them. Few people will continue a side conversion when you are two feet from them and the entire group’s attention is on you and them.

• Agenda merry-go-round. The merry-go-round occurs when a group member keeps returning to the same issue every few minutes and won’t let go. One solu- tion is to let the person have fi ve minutes to ramble on about the issue while you carefully write down every point on a fl ip chart or computer fi le. This fl ip chart or fi le is then posted conspicuously on the wall. When the person brings up the issue again, you interrupt them, walk to the paper and ask them what to add. If they mention something already on the list,

you quickly interrupt, point out that it is there, and ask what other information to add. Don’t let them repeat the same point, but write any new information.

• Violent agreement. Some of the worst disagreements occur when participants really agree on the issues but don’t realize that they agree because they are using different terms. An example is arguing whether a glass is half empty or half full; they agree on the facts but can’t agree on the words. In this case, the facilitator has to translate the terms into different words and fi nd common ground so the parties rec- ognize that they really agree.

• Unresolved confl ict. In some cases, participants don’t agree and can’t understand how to determine what alternatives are better. You can help by structur- ing the issue. Ask for criteria by which the group will identify a good alternative (e.g., “Suppose this idea really did improve customer service. How would I recognize the improved customer service?”). Then once you have a list of criteria, ask the group to assess the alternatives using them.

• True confl ict. Sometimes, despite every attempt, par- ticipants just can’t agree on an issue. The solution is to postpone the discussion and move on. Document the issue as an open issue and list it prominently on a fl ip chart. Have the group return to the issue hours later. Often the issue will have resolved itself by then and you haven’t wasted time on it. If the issue cannot be resolved later, move it to the list of issues to be decided by the project sponsor or some other more senior member of management.

• Humor. Humor is one of the most powerful tools a facilitator has and thus must be used judiciously. The best JAD humor is always in context; never tell jokes but take the opportunity to fi nd the humor in the situation.

Alan Dennis

PRACTICAL

TIP

Because the information on a questionnaire cannot be immediately clarifi ed for a confused respondent, developing good questions is critical for questionnaires. Questions on question- naires must be very clearly written and leave little room for misunderstanding, so closed-ended questions tend to be most commonly used. Questions must clearly enable the analyst to sep- arate facts from opinions. Opinion questions oft en ask respondents the extent to which they agree or disagree (e.g., Are network problems common?), whereas factual questions seek more

2. Designing a Questionnaire

precise values (e.g., How oft en does a network problem occur: once an hour, once a day, once a week?). See Figure 3-7 for guidelines on questionnaire design.

Perhaps the most obvious issue—but one that is sometimes overlooked—is to have a clear understanding of how the information collected from the questionnaire will be analyzed and used. Th is issue must be addressed before the questionnaire is distributed, because it is too late aft erward.

Questions should be relatively consistent in style, so that the respondent does not have to read instructions for each question before answering it. It is generally good practice to group related questions together to make them simpler to answer. Some experts suggest that ques- tionnaires should start with questions important to respondents, so that the questionnaire immediately grabs their interest and induces them to answer it. Perhaps the most important step is to have several colleagues review the questionnaire and then pretest it with a few people drawn from the groups to whom it will be sent. It is surprising how oft en seemingly simple questions can be misunderstood.

Th e key issue in administering the questionnaire is getting participants to complete the questionnaire and send it back. Dozens of marketing research books have been written about ways to improve response rates. Commonly used techniques include clearly explaining why the questionnaire is being conducted and why the respondent has been selected, stating a date by which the questionnaire is to be returned, off ering an inducement to complete the ques- tionnaire (e.g., a free pen), and off ering to supply a summary of the questionnaire responses. Systems analysts have additional techniques to improve response rates inside the organiza- tion, such as personally handing out the questionnaire and personally contacting those who have not returned them aft er a week or two, as well as requesting the respondents’ supervisors to administer the questionnaires in a group meeting.

It is helpful to process the returned questionnaires and develop a questionnaire report soon aft er the questionnaire deadline. Th is ensures that the analysis process proceeds in a timely fashion and that respondents who requested copies of the results receive them promptly.

Document Analysis Project teams oft en use document analysis to understand the as-is system. Under ideal cir- cumstances, the project team that developed the existing system will have produced docu- mentation that was then updated by all subsequent projects. In this case, the project team can start by reviewing the documentation and examining the system itself.

Unfortunately, many systems are not well documented because project teams fail to document their projects along the way, and when the projects are over, there is no time to go back and document. Th erefore, there might not be much technical documentation about the current systems available, or it might not contain updated information about recent sys- tem changes. However, many helpful documents do exist in an organization: paper reports,

3. Administering the Questionnaire

4. Questionnaire Follow-up

1 0 6 C h a p t e r 3   Requirements Determination

• Begin with nonthreatening and interesting questions. • Group items into logically coherent sections. • Do not put important items at the very end of the questionnaire. • Do not crowd a page with too many items. • Avoid abbreviations. • Avoid biased or suggestive items or terms. • Number questions to avoid confusion. • Pretest the questionnaire to identify confusing questions. • Provide anonymity to respondents.

FIGURE 3-7 Good Questionnaire Design

memorandums, policy manuals, user-training manuals, organization charts, forms, and, of course, the user interface with the existing system.

But these documents tell only part of the story. Th ey represent the formal system that the organization uses. Quite oft en, the real, or informal, system diff ers from the formal one, and these diff erences, particularly large ones, give strong indications of what needs to be changed. For example, forms or reports that are never used should probably be eliminated. Likewise, boxes or questions on forms that are never fi lled in (or are used for other purposes) should be rethought. See Figure 3-8 for an example of how a document can be interpreted.

Th e most powerful indication that the system needs to be changed is when users create their own forms or add additional information to existing ones. Such changes clearly demonstrate the need for improvements to existing systems. Th us, it is useful to review both blank and completed forms to identify these deviations. Likewise, when users access multiple reports to satisfy their information needs, it is a clear sign that new information or new infor- mation formats are needed.

Name: Buffy Pat Smith

Pet’s Name: Buffy Collie 7/6/99

Address: 100 Central Court. Apartment 10

Toronto, Ontario K7L 3N6

Phone Number: 555-3400

416-

Do you have insurance: yes

Insurance Company: Pet’s Mutual

Policy Number: KA-5493243

CENTRAL VETERINARY CLINIC Patient Information Card

The staff had to add additional information about the type of animal and the animal’s date of birth. This information should be added to the new form in the to-be system.

The customer made a mistake. This should be labeled Owner’s Name to prevent confusion.

The customer did not include area code in the phone number. This should be made more clear.

FIGURE 3-8 Performing a Document Analysis

Requirements-Gathering Techniques  107

Observation Observation, the act of watching processes being performed, is a powerful tool for gathering information about the as-is system because it enables the analyst to see the reality of a situa- tion, rather than listening to others describe it in interviews or JAD sessions. Several research studies have shown that many managers really do not remember how they work and how they allocate their time. (Quick, how many hours did you spend last week on each of your courses?) Observation is a good way to check the validity of information gathered from indi- rect sources such as interviews and questionnaires.

In many ways, the analyst becomes an anthropologist as he or she walks through the organization and observes the business system as it functions. Th e goal is to keep a low pro- fi le, to not interrupt those working, and to not infl uence those being observed. Nonetheless, it is important to understand that what analysts observe may not be the normal day-to-day routine because people tend to be extremely careful in their behavior when they are being watched. Even though normal practice may be to break formal organizational rules, the observer is unlikely to see this. (Remember how you drove the last time a police car followed you?) Th us, what you see might not be what you get.

Observation is oft en used to supplement interview information. Th e location of a person’s offi ce and its furnishings give clues to the person’s power and infl uence in the organization and can be used to support or refute information given in an interview. For example, an analyst might become skeptical of someone who claims to use the existing computer system exten- sively if the computer is never turned on while the analyst visits. In most cases, observation supports the information that users provide in interviews. When it does not, it is an important signal that extra care must be taken in analyzing the business system.

Selecting the Appropriate Techniques Each of the requirements-gathering techniques discussed earlier has strengths and weak- nesses. No one technique is always better than the others, and in practice most projects use a combination of techniques. Th us, it is important to understand the strengths and weaknesses of each technique and when to use each (see Figure 3-9). One issue not discussed is that of the analysts’ experience. In general, document analysis and observation require the least amount of training, whereas JAD sessions are the most challenging.

Type of Information Th e fi rst characteristic is the type of information. Some techniques are more suited for use at diff erent stages of the analysis process, whether understanding the as-is system, identifying improvements, or developing the to-be system. Interviews and JAD are commonly used in all three stages. In contrast, document analysis and observation usually are most helpful for understanding the as-is, although occasionally they provide information about

FIGURE 3-9 Table of Requirements-Gathering Techniques

Type of information As-is, improvements, As-is, improvements, As-is, improvements As-is As-is to-be to-be

Depth of information High High Medium Low Low

Breadth of information Low Medium High High Low

Integration of information Low High Low Low Low

User involvement Medium High Low Low Low

Cost Medium Low to Medium Low Low Low to Medium

Joint Application Document Interviews Design Questionnaires Analysis Observation

1 0 8 C h a p t e r 3   Requirements Determination

current problems that need to be improved. Questionnaires are oft en used to gather informa- tion about the as-is system as well as general information about improvements.

Depth of Information Th e depth of information refers to how rich and detailed the infor- mation is that the technique usually produces and the extent to which the technique is useful for obtaining not only facts and opinions but also an understanding of why those facts and opinions exist. Interviews and JAD sessions are very useful for providing a good depth of rich and detailed information and helping the analyst to understand the reasons behind them. At the other extreme, document analysis and observation are useful for obtaining facts, but little beyond that. Questionnaires can provide a medium depth of information, soliciting both facts and opinions with little understanding of why they exist.

Breadth of Information Breadth of information refers to the range of information and infor- mation sources that can be easily collected using the chosen technique. Questionnaires and document analysis are both easily capable of soliciting a wide range of information from a large number of information sources. In contrast, interviews and observation require the analyst to visit each information source individually and, therefore, take more time. JAD sessions are in the middle because many information sources are brought together at the same time.

Integration of Information One of the most challenging aspects of requirements gather- ing is integrating the information from diff erent sources. Simply put, diff erent people can provide confl icting information. Combining this information and attempting to resolve diff erences in opinions or facts is usually very time consuming because it means contacting each information source in turn, explaining the discrepancy, and attempting to refi ne the information. In many cases, the individual wrongly perceives that the analyst is challenging his or her information, when in fact it is another user in the organization who is doing so. Th is can make the user defensive and make it hard to resolve the diff erences.

All techniques suff er integration problems to some degree, but JAD sessions are designed to improve integration because all information is integrated when it is collected, not aft er- ward. If two users provide confl icting information, the confl ict becomes immediately obvi- ous, as does the source of the confl ict. Th e immediate integration of information is the single most important benefi t of JAD that distinguishes it from other techniques, and this is why most organizations use JAD for important projects.

User Involvement User involvement refers to the amount of time and energy the intended users of the new system must devote to the analysis process. It is generally agreed that as users become more involved in the analysis process, the chance of success increases. However, user involvement can have a signifi cant cost, and not all users are willing to contribute valuable time and energy. Questionnaires, document analysis, and observation place the least burden on users, whereas JAD sessions require the greatest eff ort.

Cost Cost is always an important consideration. In general, questionnaires, document analysis, and observation are low-cost techniques (although observation can be quite time consuming). Th e low cost does not imply that they are more or less eff ective than the other techniques. Interviews and JAD sessions generally have moderate costs. In general, JAD ses- sions are much more expensive initially, because they require many users to be absent from their offi ces for signifi cant periods of time, and they oft en involve highly paid consultants. However, JAD sessions signifi cantly reduce the time spent in information integration and thus can cost less in the long term.

Combining Techniques In practice, requirements gathering combines a series of diff erent tech- niques. Most analysts start by using interviews with senior manager(s) to gain an understanding of the project and the big-picture issues. From these interviews, it becomes clear whether large or small changes are anticipated. Th ese interviews are oft en followed with analysis of documents

Requirements-Gathering Techniques  109

12 See B. Henderson-Sellers, A. Simons, and H. Younessi, Th e OPEN Toolbox of Techniques (Harlow, England: Addison-Wesley, 1998). 13 For more information on concept mapping, see J. D. Novak and D. B. Gowin, Learning How to Learn (Cambridge, UK: Cambridge University Press, 1984); J. D. Novak, Learning, Creating, and Using Knowledge: Concept MapsTM as Facilitative Tools in Schools and Corporations (Mahwah, NJ: Lawrence Erlbaum Associates, Publishers, 1998). Also, a free concept mapping tool is available from the Institute of Human and Machine Cognition at cmap.ihmc.us.

1 1 0 C h a p t e r 3   Requirements Determination

and policies to gain some understanding of the as-is system. Usually interviews come next to gather the rest of the information needed for the as-is picture.

In our experience, identifying improvements is most commonly done using JAD sessions because the JAD session enables the users and key stakeholders to work together through an analysis technique and come to a shared understanding of the possibilities for the to-be sys- tem. Occasionally, these JAD sessions are followed by questionnaires sent to a much wider set of users or potential users to see whether the opinions of those who participated in the JAD sessions are widely shared.

Developing the concept for the to-be system is oft en done through interviews with senior managers, followed by JAD sessions with users of all levels to make sure that the key needs of the new system are well understood.

ALTERNATIVE REQUIREMENTS DOCUMENTATION TECHNIQUES Some other very useful requirements-gathering and documentation techniques include throwaway prototyping, use cases, role-playing CRC cards with use-case-based scenarios, concept mapping, and recording user stories on story cards and task lists. Th rowaway pro- totyping was described in Chapter 1. In essence, throwaway prototypes are created to better understand some aspect of the new system. In many cases, they are used to test out some technical aspect of a nonfunctional requirement, such as connecting a client workstation to a server. If you have never done this before, it will be a lot easier to develop a very small example system to test out the necessary design of the connection from the client workstation to the server instead of trying to do it the fi rst time with the full-blown system. Th rowaway proto- typing is very useful in designing user interfaces (see Chapter 10).

Use cases, as described in Chapter 1, are the fundamental approach that the Unifi ed Process and Unifi ed Modeling Language (UML) use to document and gather functional requirements. We describe them in Chapter 4. Role-playing CRC cards with use-case-based scenarios are very useful when creating functional (see Chapter 4), structural (see Chapter 5), and behavioral (see Chapter 6) models. We describe this approach in Chapter 5. Th e remainder of this section describes the use of concept mapping recording user stories on story cards and task lists.

Concept Maps Concept maps represent meaningful relationships between concepts. Th ey are useful for focusing individuals on the small number of key ideas on which they should concentrate. A concept map is essentially a node-and-arc representation, where the nodes represent the individual requirements and the arcs represent the relationships among the requirements. Each arc is labeled with a relationship name. Concept maps also have been recommended as a possible technique to support modeling requirements for object-oriented systems develop- ment and knowledge-management systems.12 Concept mapping is an educational psychology technique that has been used in schools, corporations, and health care agencies to facilitate learning, understanding, and knowledge creation.13 Th e advantage of the concept-mapping approach to representing requirements over the typical textual approach (see Figure 3-1) is that a concept map is not limited to a hierarchical representation. Concept maps allow the rela- tionships among the functional and nonfunctional requirements to be explicitly represented. Figure 3-10 shows a concept map that portrays the information contained in the requirements

R eq

u ir

em en

ts

C u lt

u ra

l an

d Po

li ti

ca l

R eq

u ir

em en

ts

N o n fu

n ct

io n al

R eq

u ir

em en

ts Se

cu ri

ty R

eq u ir

em en

ts

O p er

at io

n al

R eq

u ir

em en

ts

Pe rf

o rm

an ce

R eq

u ir

em en

ts

B ac

ku p S

ch ed

u le

D ai

ly

Su p p o rt

W ir

el es

s P ri

n ti

n g

St o re

N ew

A p p o in

tm en

t in

2 S

ec o n d s

o r

Le ss

R et

ri ev

e D

ai ly

A p p o in

tm en

t Sc

h ed

u le

i n 2

Se co

n d s

o r

Le ss

O p er

at e

in W

in d o w

s En

vi ro

n m

en t

M ak

e A

p p o in

tm en

t C

an ce

l A p p o in

tm en

t P ri

n t

Sc h ed

u le

U p d at

e Sc

h ed

u le

C h ec

k Sc

h ed

u le

C h an

ge A

p p o in

tm en

t

M an

ag e

A p p o in

tm en

ts P ro

d u ce

S ch

ed u le

Fu n ct

io n al

R eq

u ir

em en

ts

R ec

o rd

D o ct

o r

A va

il ab

il it

y

O n ly

M an

ag er

s C

an P ro

d u ce

S ch

ed u le

O n ly

D o ct

o rs

S et

A va

il ab

il it

y im

p ac

ts

im p ac

ts

im p ac

ts

im p ac

ts

im p ac

ts

im p ac

ts

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

F IG

U R

E 3

-1 0

S am

p le

R e

q u

ir e

m e

n ts

C o

n ce

p t

M ap

111

defi nition shown in Figure 3-1. By using a concept map to represent the requirements instead of the textual approach, the relationship between the functional and nonfunctional require- ments can be made explicit. For example, the two security requirements Only Doctors Set Availability and Only Managers Can Produce Schedule are explicitly linked to the Record Doctor Availability and Produce Schedule functional requirements, respectively. Th is is very diffi cult to represent in a text-only version of the requirements defi nition. Also, by having the user and analyst focus on the graphical layout of the map, additional requirements can be discovered. One obvious issue with this approach is that if the number of requirements becomes many and the relationships between them become complex, then the number of nodes and arcs will become so intertwined that the advantage of being able to explicitly see the relationships will be lost. However, by combining both text and concept-map representations, it is possible to leverage the strength of both textual and graphical representations to more completely represent the requirements.

User Stories User stories, along with their associated story cards and task lists, are associated with the agile development approaches. User stories have been shown to be very useful in gathering requirements in a nonthreatening manner that respects the user’s point of view. Th ey are typically captured using story cards (index cards) and are recorded on a task list (or from a Scrum perspective, on the product backlog). Both story cards and task lists are considered to be lightweight approaches to documenting and gathering requirements.14 Stories capture both functional and nonfunctional requirements. For example, with regard to the doctor’s offi ce appointment example, a functional requirement-based story could be:

As a secretary, I want to be able to schedule appointments for our patients so that we can meet our patients’ needs.

While an operational nonfunctional requirement-based story could be:

As a secretary, I want to be able to print the daily schedule using wireless technology so that all printing can be performed using a shared printer without having to deal with printer cables connecting all of the computers to the printer.

Once the story is written down, it is discussed to determine the amount of eff ort it will take to implement it. During the discussion, a task list is created for the story. If the story is deemed to be too large—e.g., there are too many tasks on the task list—the story is split up into multiple stories each being recorded on its own story card and the tasks are allocated across the new stories. In many shops, once a set of tasks has been identifi ed with a story, the story and its tasks are taped on a wall together so that all members of the development team can see the requirements. Th e story can be prioritized by importance by placing a rat- ing on the card. Th e story can also be evaluated for the level of risk associated with it. Th e importance level and amount of risk associated with the story can be used to help choose which requirements to implement fi rst. Th e advantage of using story cards and task lists to document requirements is that they are very low tech, high touch, easily updatable, and very portable.

1 1 2 C h a p t e r 3   Requirements Determination

14 For more information on story cards and task lists see M. Cohn, User Stories Applied: For Agile Soft ware Development (Boston, MA: Addison-Wesley, 2004); B. Rinzler, Telling Stories: A Short Path to Writing Better Soft ware Requirements (Indianapolis, IN: Wiley, 2009); M. Lippert, S. Roock, H. Wolf, eXtreme Programming in Action: Practical Experiences from Real World Projects (Chichester, England: Wiley & Sons, Ltd., 2002); C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston, MA: Addison-Wesley, 2004).

1. Table of Contents

2. Executive Summary

A summary of all the essential information in the proposal so that a busy executive can read it quickly and decide what parts of the proposal to read in more depth.

3. System Request

The revised system request form (see Chapter 2).

4. Workplan

The original workplan, revised after having completed analysis (see Chapter 2).

5. Feasibility Analysis

A revised feasibility analysis, using the information from analysis (see Chapter 2).

6. Requirements Defi nition

A list of the functional and nonfunctional business requirements for the system (this chapter).

7. Functional Model

An activity diagram, a set of use-case descriptions, and a use-case diagram that illustrate the basic processes or external functionality that the system needs to support (see Chapter 4).

8. Structural Models

A set of CRC cards, class diagram, and object diagrams that describe the structural aspects of the to-be system (see Chapter 5). This may also include structural models of the current as-is system that will be replaced.

9. Behavioral Models

A set of sequence diagrams, communication diagrams, behavioral-state machines, and a CRUDE matrix that describe the internal behavior of the to-be system (see Chapter 6). This may include behavioral models of the as-is system that will be replaced.

10. Appendices

These contain additional material relevant to the proposal, often used to support the recommended system. This might include results of a questionnaire survey or interviews, industry reports and statistics, and so on.

FIGURE 3-11 System Proposal Template

15 Depending on the client, much more detailed specifi cations may be required; for example the Department of Defense, NASA, IEEE/ANSI, and the Naval Research Laboratory all have very specifi c formats that must be followed. For more information on these more detailed specifi cations, see A. M Davis, Soft ware Requirements, Revision (Upper Saddle River, NJ: Prentice Hall, 1993); G. Kotonya and I. Sommerville, Requirements Engineering (Chichester, England: Wiley, 1998); R. H. Th ayer and M. Dorfman (eds.), Soft ware Requirements Engineering, 2nd Ed. (Los Alamitos, CA: IEEE Computer Society Press, 1997).

THE SYSTEM PROPOSAL A system proposal brings together into a single comprehensive document the material created during planning and analysis. Th e system proposal typically includes an executive summary, the system request, the workplan, the feasibility analysis, the requirements defi nition, and the evolving models that describe the new system. Th e evolving models include functional models (see Chapter 4), structural models (see Chapter 5), and behavioral models (see Chapter 6).15 Th e executive summary provides all critical information in a very concise form. It can be thought of as a summary of the complete proposal. Its purpose is to allow a busy executive to quickly read through it and determine which parts of the proposal he or she needs to go through more thoroughly. Th e executive summary is typically no more than a single page long. Figure 3-11 provides a template for a system proposal and references to where the other sections of the proposal are described.

The System Proposal  113

CHAPTER REVIEW Aft er reading and studying this chapter, you should be able to:

Create a requirements defi nition. Diff erentiate between a functional and a nonfunctional requirement. Discuss the problem analysis requirements strategy. Discuss the root cause analysis requirements strategy. Discuss the duration analysis requirements strategy. Discuss the activity-based costing analysis requirements strategy. Discuss the informal benchmarking analysis requirements strategy. Discuss the outcome analysis requirements strategy. Discuss the technology analysis requirements strategy. Discuss the activity elimination requirements strategy. Discuss how to use interviews to gather requirements. Discuss how to use joint application development to gather requirements. Discuss how to use questionnaires to gather requirements. Discuss how to use document analysis to gather requirements. Discuss how to use observation to gather requirements. Describe how to use concept maps to document requirements. Describe how to use story cards and task lists to document requirements. Describe the purpose and contents of system proposal.

KEY TERMS

Activity elimination Activity-based costing Analysis As-is system Benchmarking

Bottom-up interview Breadth of analysis Business requirements Closed-ended question Concept mapping

Concept maps Critical thinking skills Document analysis Duration analysis Electronic JAD (e-JAD)

Facilitator Formal system Functional requirements Ground rules Informal benchmarking

1 1 4 C h a p t e r 3   Requirements Determination

APPLYING THE CONCEPTS AT PATTERSON SUPERSTORE Chapter 3 introduced requirements determination for object-oriented systems develop- ment projects. Determining the system’s requirements is the most important activity in the systems development process. A requirement is WHAT the system must do or WHAT characteristics it must have. If the requirements are not fully or correctly defi ned, the sys- tem developed is unlikely to meet the needs of the user. In other words, if the requirements are wrong, the system will be wrong.

In this chapter’s installment of the Patterson Superstore case, we see the require- ments analysis and requirement-gathering techniques that the analysts used to determine requirements for Version 1 of the Integrated Health Clinic Delivery System. We also see the functional and nonfunctional requirements that were developed and an initial draft of the developing systems proposal for the project. Th is systems proposal will be fi nalized aft er the functional (Chapter 4), structural (Chapter 5), and behavioral (Chapter 6) modeling of the system has been completed.

You can fi nd the rest of the case at: www.wiley.com/go/dennis/casestudy

Informal system Interpersonal skills Interview Interview notes Interview report Interview schedule JAD (joint application

development) Nonfunctional requirements Observation

Open-ended question Outcome analysis Parallelization Process Integration Post-session report Potential business value Probing question Problem analysis Project cost Questionnaire

Requirement Requirements defi nition Requirements

determination Risk Root cause Root cause analysis Sample Scribe Story cards

Structured interview System proposal System requirements Task lists, 144 Technology analysis To-be system Top-down interview Unstructured interview User stories Walkthrough

QUESTIONS

1. What are the key deliverables that are created during analysis? What is the fi nal deliverable from analysis, and what does it contain?

2. What is the diff erence between an as-is system and a to-be system?

3. What is the purpose of the requirements defi nition? 4. What are the three basic steps of the analysis process?

Which step is sometimes skipped or done in a cursory fashion? Why?

5. Compare and contrast problem analysis and root cause analysis. Under what conditions would you use problem analysis? Under what conditions would you use root cause analysis?

6. Compare and contrast duration analysis and activity- based costing.

7. Describe the fi ve major steps in conducting interviews. 8. Explain the diff erences among a closed-ended ques-

tion, an open-ended question, and a probing question. When would you use each?

9. Explain the diff erences between unstructured inter- views and structured interviews. When would you use each approach?

10. Explain the diff erence between a top-down and bottom-up interview approach. When would you use each approach?

11. How are participants selected for interviews and JAD sessions?

12. How can you diff erentiate between facts and opinions? Why can both be useful?

13. Describe the fi ve major steps in conducting JAD sessions.

14. How does a JAD facilitator diff er from a scribe? 15. What are the three primary things that a facilitator

does in conducting the JAD session? 16. What is e-JAD, and why might a company be inter-

ested in using it? 17. How does designing questions for questionnaires diff er

from designing questions for interviews or JAD sessions? 18. What are typical response rates for questionnaires,

and how can you improve them? 19. What is document analysis? 20. How does the formal system diff er from the informal

system? How does document analysis help you under- stand both?

21. What are the key aspects of using observation in the information-gathering process?

22. Explain factors that can be used to select information- gathering techniques.

23. What is the primary advantage that concept maps have over traditional textual requirements documents techniques?

24. What are some of the advantages of using story cards and task lists as a requirements-gathering and docu- mentation technique?

25. What information is typically included in a system proposal?

26. What is the purpose of the executive summary of the system proposal?

EXERCISES

A. Review the Amazon.com website. Develop the requirements defi nition for the site. Create a list of functional business requirements that the system meets. What diff erent kinds of nonfunctional business

requirements does the system meet? Provide exam- ples for each kind.

B. Suppose you are going to build a new system that auto- mates or improves the interview process for the career

Exercises  115

services department of your school. Develop a require- ments defi nition for the new system. Include both functional and nonfunctional system requirements. Pretend you will release the system in three diff erent versions. Prioritize the requirements accordingly.

C. Describe in very general terms the as-is business process for registering for classes at your university. Collaborate with another student in your class, and evaluate the process using problem analysis and root cause analysis. Based on your work, list some improve- ments that you have identifi ed.

D. Describe in very general terms the as-is business pro- cess for applying for admission at your university. Collaborate with another student in your class, and evaluate the process using informal benchmarking. Based on your work, list some improvements that you have identifi ed.

E. Describe in very general terms the as-is business process for registering for classes at your university. Collaborate with another student in your class, and evaluate the process using activity elimination. Based on your work, list some improvements that you have identifi ed.

F. Suppose your university is having a dramatic increase in enrollment and is having diffi culty fi nding enough seats in courses for students. Perform a technology analysis to identify new ways to help students com- plete their studies and graduate.

G. Suppose you are the analyst charged with developing a new system for the university bookstore so that students can order books online and have them delivered to their dorms or off -campus housing. What requirements- gathering techniques will you use? Describe in detail how you would apply the techniques.

H. Suppose you are the analyst charged with developing a new system to help senior managers make bet- ter strategic decisions. What requirements-gathering techniques will you use? Describe in detail how you would apply the techniques.

I. Find a partner and interview each other about what tasks each did in the last job you held (full-time, part-time, past, or current). If you haven’t worked before, then assume your job is being a student. Before you do this, develop a brief interview plan. Aft er your partner interviews you, identify the type of interview, interview approach, and types of ques- tions used.

J. Find a group of students and run a sixty-minute JAD session on improving alumni relations at your university. Develop a brief JAD plan, select two tech- niques that will help identify improvements, and then develop an agenda. Conduct the session using the agenda, and write your post-session report.

K. Find a questionnaire on the Web that has been created to capture customer information. Describe the pur- pose of the survey, the way questions are worded, and how the questions have been organized. How can it be improved? How will the responses be analyzed?

L. Develop a questionnaire that will help gather infor- mation regarding processes at a popular restaurant or the college cafeteria (e.g., ordering, customer ser- vice). Give the questionnaire to ten to fi ft een students, analyze the responses, and write a brief report that describes the results.

M. Contact the career services department at your uni- versity, and fi nd all the pertinent documents designed to help students fi nd permanent and/or part-time jobs. Analyze the documents and write a brief report.

MINICASES

1. Th e State Firefi ghter’s Association has a membership of 15,000. Th e purpose of the organization is to pro- vide some fi nancial support to the families of deceased member fi refi ghters and to organize a conference each year bringing together fi refi ghters from all over the state. Members are billed dues and calls annually. Calls are additional funds required to take care of payments made to the families of deceased members. Th e bookkeeping work for the association is handled by the elected treasurer, Bob Smith, although it is widely known that his wife, Laura, does all the work.

Bob runs unopposed each year at the election, because no one wants to take over the tedious and time- consuming job of tracking memberships. Bob is paid a stipend of $8,000 per year, but his wife spends well over twenty hours per week on the job. Th e organiza- tion, however, is not happy with their performance.

A computer system is used to track the billing and receipt of funds. Th is system was developed in 1984 by a computer science student and his father. Th e system is a DOS-based system written using dBase 3. Th e most immediate problem facing the treasurer and

1 1 6 C h a p t e r 3   Requirements Determination

his wife is the fact that the soft ware package no longer exists, and there is no one around who knows how to maintain the system. One query, in particular, takes seventeen hours to run. Over the years, they have just avoided running this query, although the information in it would be quite useful. Questions from mem- bers concerning their statements cannot easily be answered. Usually Bob or Laura just jots down the inquiry and returns a call with the answer. Sometimes it takes three to fi ve hours to fi nd the information needed to answer the question. Oft en, they have to perform calculations manually because the system was not programmed to handle certain types of que- ries. When member information is entered into the system, each fi eld is presented one at a time, which makes it very diffi cult to return to a fi eld and correct a value that was entered. Sometimes a new member is entered but disappears from the records. Th e report of membership used in the conference materials does not alphabetize members by city. Only cities are listed in the correct order.

What requirements analysis strategy or strategies would you recommend for this situation? Explain your answer.

2. Brian Callahan, IS project manager, is just about ready to depart for an urgent meeting called by Joe Campbell, manager of manufacturing operations. A major project sponsored by Joe recently cleared the approval hurdle, and Brian helped bring the project through project initiation. Now that the approval committee has given the go-ahead, Brian has been working on the project’s analysis plan.

One evening, while playing golf with a friend who works in the manufacturing operations department, Brian learned that Joe wants to push the project’s time frame up from Brian’s original estimate of thirteen months. Brian’s friend overheard Joe say, “I can’t see why that IS project team needs to spend all that time analyzing things. Th ey’ve got two weeks scheduled just to look at the existing system! Th at seems like a real waste. I want that team to get going on building my system.”

Because Brian has a little inside knowledge about Joe’s agenda for this meeting, he has been considering how to handle Joe. What do you suggest Brian tell Joe?

3. Barry has recently been assigned to a project team that will be developing a new retail store management sys- tem for a chain of submarine sandwich shops. Barry has several years of experience in programming, but he has not done much analysis in his career. He was a

little nervous about the new work he would be doing, but he was confi dent he could handle any assignment he was given.

One of Barry’s fi rst assignments was to visit one of the submarine sandwich shops and prepare an observation report on how the store operates. Barry planned to arrive at the store around noon, but he chose a store in an area of town he was unfamiliar with, and due to traffi c delays and diffi culty in fi nd- ing the store, he did not arrive until 1:30. Th e store manager was not expecting him and refused to let a stranger behind the counter until Barry had her contact the project sponsor (the director of store management) at company headquarters to verify who he was and what his purpose was.

Aft er fi nally securing permission to observe, Barry stationed himself prominently in the work area behind the counter so that he could see everything. Th e staff had to maneuver around him as they went about their tasks, but there were only minor occa- sional collisions. Barry noticed that the store staff seemed to be going about their work very slowly and deliberately, but he supposed that was because the store wasn’t very busy. At fi rst, Barry questioned each worker about what he or she was doing, but the store manager eventually asked him not to interrupt their work so much—he was interfering with their service to the customers.

By 3:30, Barry was a little bored. He decided to leave, fi guring he could get back to the offi ce and prepare his report before 5:00 that day. He was sure his team leader would be pleased with his quick completion of his assignment. As he drove, he refl ected, “Th ere really won’t be much to say in this report. All they do is take the order, make the sandwich, collect the payment, and hand over the order. It’s really simple!” Barry’s confi dence in his analytical skills soared as he anticipated his team leader’s praise.

Back at the store, the store manager shook her head, commenting to her staff , “He comes here at the slowest time of day on the slowest day of the week. He never even looked at all the work I was doing in the back room while he was here—summarizing yester- day’s sales, checking inventory on hand, making up resupply orders for the weekend . . . plus he never even considered our store-opening and -closing procedures. I hate to think that the new store management system is going to be built by someone like that. I’d better contact Chuck [the director of store management] and let him know what went on here today.”

Minicases  117

1 1 8 C h a p t e r 3   Requirements Determination

Evaluate Barry’s conduct of the observation assignment.

4. Anne has been given the task of conducting a survey of sales clerks who will be using a new order-entry sys- tem being developed for a household products catalog company. Th e goal of the survey is to identify the clerks’ opinions on the strengths and weaknesses of the current system. Th ere are about 50 clerks who work in three diff erent cities, so a survey seemed like an ideal way of gathering the needed information from the clerks.

Anne developed the questionnaire carefully and pretested it on several sales supervisors who were available at corporate headquarters. Aft er revising it based on their suggestions, she sent a paper version of the questionnaire to each clerk, asking that it be

returned within one week. Aft er one week, she had only three completed questionnaires returned. Aft er another week, Anne received just two more completed questionnaires. Feeling somewhat desperate, Anne then sent out an e-mail version of the questionnaire, again to all the clerks, asking them to respond to the questionnaire by e-mail as soon as possible. She received two e-mail questionnaires and three mes- sages from clerks who had completed the paper ver- sion expressing annoyance at being bothered with the same questionnaire a second time. At this point, Anne has just a 14 percent response rate, which she is sure will not please her team leader. What suggestions do you have that could have improved Anne’s response rate to the questionnaire?

Functional models describe business processes and the interaction of an information sys- tem with its environment. In object-oriented systems development, two types of models are used to describe the functionality of an information system: use cases and activity diagrams. Use cases are used to describe the basic functions of the information system. Activity dia- grams support the logical modeling of business processes and workfl ows. Both can be used to describe the current as-is system and the to-be system being developed. Th is chapter describes business process and functional modeling as a means to document and understand require- ments and to understand the functional or external behavior of the system.

OBJECTIVES

■ Understand the process used to identify business processes and use cases. ■ Understand the process used to create use-case diagrams. ■ Understand the process used to model business processes with activity diagrams. ■ Understand the rules and style guidelines for activity diagrams. ■ Understand the process used to create use-case descriptions. ■ Understand the rules and style guidelines for use-case descriptions. ■ Be able to create functional models of business processes using use-case diagrams,

activity diagrams, and use-case descriptions.

INTRODUCTION Th e previous chapter discussed popular requirements-gathering techniques, such as inter- viewing, JAD, and observation. Using these techniques, the analyst determined the require- ments and created a requirements defi nition. Th e requirements defi nition defi ned what the system is to do. In this chapter, we discuss how the information that is gathered using these techniques is organized and presented in the form of use-case and activity diagrams and use-case descriptions. Because Unifi ed Modeling Language (UML) has been accepted as the standard notation by the Object Management Group (OMG), almost all object-oriented development projects today use these models to document and organize the requirements that are obtained during the analysis workfl ow.1

119

1 Other, similar techniques that are commonly used in non-UML projects are task modeling and scenario-based design. For task modeling, see Ian Graham, Migrating to Object Technology (Reading, MA: Addison-Wesley, 1995); Ian Graham, Brian Henderson-Sellers, and Houman Younessi, Th e OPEN Process Specifi cation (Reading, MA: Addi- son-Wesley, 1997). For scenario-based design, see John M. Carroll, Scenario-Based Design: Envisioning Work and Technology in System Development (New York: Wiley, 1995).

C H A P T E R 4

Business Process and Functional Modeling

120  C h a p t e r 4 Business Process and Functional Modeling

As pointed out in Chapter 1, all object-oriented systems development approaches are use-case driven, architecture-centric, and iterative and incremental. A use case is a formal way of representing the way a business sys tem interacts with its environment. Essentially, a use case is a high-level overview of the business processes in a business information system. From a practical perspective, use cases represent the entire basis for an object-oriented system. Use cases can document the current system (i.e., as-is system) or the new system being developed (i.e., to-be system). Given that object-oriented systems are use-case driven, use cases also form the foundation for testing (see Chapter 12) and user-interface design (see Chapter 10). Two forms of use-case driven testing are walkthroughs (described later in this chapter) and role-playing (described in Chapter 5).

From an architecture-centric perspective, use-case modeling supports the creation of an external or functional view of a business process in that it shows how the users view the process rather than the internal mechanisms by which the process and supporting systems operate. Th e structural and behavioral architecture-based views are described in Chapters 5 and 6, respectively. Finally, all object-oriented systems development approaches are developed in an incremental and iterative manner. Even though we present the three architectural views in a sequential manner, this is done primarily for pedagogical rea- sons. You will find that you will need to not only iterate across the business process and functional models (described in this chapter), you will also have to iterate across all three architectural views to fully capture and represent the requirements for a business information system.

Activity diagrams are typically used to augment our understanding of the business pro- cesses and our use-case model. Technically, an activity diagram can be used for any type of process-modeling activity.2 In this chapter, we describe their use in the context of business process modeling. Process models depict how a business system operates. Th ey illustrate the processes or activities that are performed and how objects (data) move among them. A process model can be used to document a current system (i.e., as-is system) or a new system being developed (i.e., to-be system), whether computerized or not. Many diff erent process-modeling techniques are in use today.3

Activity diagrams and use cases are logical models—models that describe the busi- ness domain’s activities without suggesting how they are conducted. Logical models are sometimes referred to as problem domain models. Reading a use-case or activity diagram, in principle, should not indicate if an activity is computerized or manual, if a piece of information is collected by paper form or via the Web, or if information is placed in a filing cabinet or a large database. These physical details are defined during design when the logical models are refined into physical models. These models provide infor- mation that is needed to ultimately build the system. By focusing on logical activities first, analysts can focus on how the business should run without being distracted with implementation details.

2 We actually used an activity diagram to describe a simple process in Chapter 1 (see Figure 1-1). 3 Another commonly used process-modeling technique is IDEF0. IDEF0 is used extensively throughout the U.S. federal government. For more information about IDEF0, see FIPS 183: Integration Defi nition for Function Modeling (IDEF0), Federal Information Processing Standards Publications (Washington, DC: U.S. Department of Commerce, 1993). From an object-oriented perspective, a good book that uses the UML to address business process modeling is Hans-Erik Eriksson and Magnus Penker, Business Modeling with UML (New York: Wiley, 2000). Finally, a new process modeling technique is BPMN (Business Process Modeling Notation). A good book that compares the notation and use of BPMN to UML’s activity diagram is Martin Schedlbauer, Th e Art of Business Process Modeling: Th e Business Analysts Guide to Process Modeling with UML & BPMN (Sudbury, MA: Th e Cathris Group, 2010).

Last h1  121Business Process Identifi cation with Use Cases and Use-Case Diagrams  121

As a fi rst step, the project team gathers requirements from the users (see Chapter 3). Using the gathered requirements, the project team then identifi es the business processes and their environment using use cases and use-case diagrams. Next, users work closely with the team to model the business processes in the form of activity diagrams, and the team docu- ments the business processes described in the use-case and activity diagrams by creating a use-case description for each use case. Finally, the team verifi es and validates the business processes by ensuring that all three models (use-case diagram, activity diagram(s), and use- case descriptions) agree with one another. Once the current understanding of the business processes is documented in the functional models, the team is ready to move on to structural modeling (see Chapter 5).

In this chapter, we fi rst describe business process identifi cation using use cases and use-case diagrams. Second, we describe business process modeling with activity dia- grams. Th ird, we describe use-case descriptions, their elements, and a set of guidelines for creating them. Fourth, we describe the process of verifi cation and validation of the business process and functional models.

BUSINESS PROCESS IDENTIFICATION WITH USE CASES AND USE-CASE DIAGRAMS

In the previous chapter, we learned about strategies and techniques that are useful in iden- tifying the diff erent business processes of a system so that a requirements defi nition could be created. In this section, we learn how to begin modeling business processes with use cases and the use-case diagram. An analyst can employ use cases and the use-case diagram to better understand the functionality of the system at a very high level. Typically, because a use-case diagram provides a simple, straightforward way of communicating to the users exactly what the system will do, a use-case diagram is drawn when gathering and defi ning requirements for the system. In this manner, the use-case diagram can encourage the users to provide additional high-level requirements. A use-case diagram illustrates in a very simple way the main functions of the system and the diff erent kinds of users that will interact with it. Figure 4-1 describes the basic syntax rules for a use-case diagram. Figure 4-2 presents a use-case diagram for the doctor’s offi ce appointment system introduced in the previous chapter. We can see from the diagram that patients, doctors, and management personnel will use the appointment system to manage appointments, record availability, and produce schedules, respectively.

Elements of Use-Case Diagrams Th e elements of a use-case diagram include actors, use cases, subject boundaries, and a set of relationships among actors, actors and use cases, and use cases. Th ese relationships consist of association, include, extend, and generalization relationships. Each of these elements is described next.

Actors Th e stick fi gures on the diagram represent actors (see Figure 4-1). An actor is not a specifi c user but instead is a role that a user can play while interacting with the system. An actor can also represent another system in which the current system interacts. In this case, the actor optionally can be represented by a rectangle containing <<actor>> and the name of the system. Basically, actors represent the principal elements in the environment in which

122  C h a p t e r 4 Business Process and Functional Modeling

An actor:

■ Is a person or system that derives benefit from and is external to the subject. ■ Is depicted as either a stick figure (default) or, if a nonhuman actor is involved, a

rectangle with <<actor>> in it (alternative). ■ Is labeled with its role. ■ Can be associated with other actors using a specialization/superclass association,

denoted by an arrow with a hollow arrowhead. ■ Is placed outside the subject boundary.

A use case:

■ Represents a major piece of system functionality. ■ Can extend another use case. ■ Can include another use case. ■ Is placed inside the system boundary. ■ Is labeled with a descriptive verb–noun phrase.

A subject boundary:

■ Includes the name of the subject inside or on top. ■ Represents the scope of the subject, e.g., a system or an individual

business process.

An include relationship:

■ Represents the inclusion of the functionality of one use case within another. ■ Has an arrow drawn from the base use case to the used use case.

An extend relationship:

■ Represents the extension of the use case to include optional behavior. ■ Has an arrow drawn from the extension use case to the base use case.

A generalization relationship:

■ Represents a specialized use case to a more generalized one. ■ Has an arrow drawn from the specialized use case to the base use case.

An association relationship:

■ Links an actor with the use case(s) with which it interacts.

<<actor>> Actor/Role

Subject

Actor/Role

Use Case

<<include>>

<<extend>>

* *

FIGURE 4-1  Syntax for Use-Case Diagram

the system operates. Actors can provide input to the system, receive output from the system, or both. Th e diagram in Figure 4-2 shows that three actors will interact with the appointment system (a patient, a doctor, and management).

Sometimes an actor plays a specialized role of a more general type of actor. For example, there may be times when a new patient interacts with the system in a way that is somewhat diff erent from a general patient. In this case, a specialized actor (i.e., new patient) can be placed on the model, shown using a line with a hollow triangle at the end of the more- general

Business Process Identifi cation with Use Cases and Use-Case Diagrams  123

actor (i.e., patient). Th e specialized actor inherits the behavior of the more general actor and extends it in some way (see Figure 4-3).

Association Use cases are connected to actors through association relationships; these rela- tionships show with which use cases the actors interact (see Figure 4-1). A line drawn from an actor to a use case depicts an association. Th e association typically represents two-way communication between the use case and the actor. If the communication is only one way, then a solid arrowhead can be used to designate the direction of the fl ow of information.

Appointment System

Patient

Produce Schedules

Manage Appointments

Management

Doctor

Record Availability

* *

* *

* *

Appointment System

Patient

New Patient

Produce Schedules

Manage Appointments

Management

Doctor

Record Availability

* *

* *

* * FIGURE 4-3 Use-Case Diagram with a Specialized Actor

FIGURE 4-2 Use-Case Diagram for the Appointment System

124  C h a p t e r 4 Business Process and Functional Modeling

For example, in Figure 4-2 the Patient actor communicates with the Manage Appointments use case. Because there are no arrowheads on the association, the communication is two- way. Finally, it is possible to represent the multiplicity of the association. Figure 4-2 shows an asterisk (*) at either end of the association between the Patient and the Manage Appoint- ments use case. Th is simply indicates that an individual patient (instance of the Patient actor) executes the Manage Appointments use case as many times as he or she wishes and that it is possible for the appointment part of the Manage Appointments use case to be executed by many diff erent patients. In most cases, this type of many-to-many relationship is appropri- ate. However, it is possible to restrict the number of patients who can be associated with the Manage Appointments use case. We discuss the multiplicity issue in detail in the next chapter in regard to class diagrams.

Use Case A use case, depicted by an oval in the UML, is a major process that the system performs and that benefi ts an actor or actors in some way (see Figure 4-1); it is labeled using a descriptive verb–noun phrase. We can tell from Figure 4-2 that the system has three primary use cases: Manage Appointments, Produce Schedule, and Record Availability.

Th ere are times when a use case includes, extends, or generalizes the functionality of another use case in the diagram. Th ese are shown using include, extend, and generalization relationships. To increase the ease of understanding a use-case diagram, higher-level use cases are normally drawn above the lower-level ones. It may be easier to understand these relation- ships with the help of examples. Let’s assume that every time a patient makes an appointment, the patient is asked to verify payment arrangements. However, it is occasionally necessary to actually make new payment arrangements. Th erefore, we may want to have a use case called Make Payment Arrangements that extends the Manage Appointments use case to include this additional functionality. In Figure 4-4, an arrow labeled with extend was drawn from the Make Payment Arrangements use case to the Manage Appointment use case to denote this special use-case relationship. Th e Make Payment Arrangements use case was drawn lower than the Manage Appointments use case.

Similarly, there are times when a single use case contains common functions that are used by other use cases. For example, suppose there is a use case called Manage Schedule that performs some routine tasks needed to maintain the doctor’s offi ce appointment schedule, and the two use cases Record Availability and Produce Schedule both perform the routine tasks. Figure 4-4 shows how we can design the system so that Manage Schedule is a shared use case that is used by others. An arrow labeled with include is used to denote the include relationship, and the included use case is drawn below the use cases that contain it. Notice that the arrows are drawn from the Record Availability and Produce Schedule use cases to the common Manage Schedule use case.

Finally, there are times when it makes sense to use a generalization relationship to simplify the individual use cases. For example in Figure 4-4, the Manage Appointments use case has been specialized to include a use case for an Old Patient and a New Patient. Th e Make Old Patient Appt use case inherits the functionality of the Manage Appointments use case (including the Make Payment Arrangements use-case extension) and extends its own functionality with the Update Patient Information use case. Th e Make New Patient Appt use case also inherits all the functionality of the generic Manage Appointments use case and calls the Create New Patient use case, which includes the functionality neces- sary to insert the new patient into the patient database. Th e generalization relationship is represented as an unlabeled hollow arrow with the more general use case being higher than the lower use cases. Also, notice that we have added a second specialized actor, Old Patient, and that the Patient actor is now simply a generalization of the Old and New Patient actors.

Last h1  125Business Process Identifi cation with Use Cases and Use-Case Diagrams  125

Subject Boundary Th e use cases are enclosed within a subject boundary, which is a box that defi nes the scope of the system and clearly delineates what parts of the diagram are external or internal to it (see Figure 4-1). One of the more diffi cult decisions to make is where to draw the subject boundary. A subject boundary can be used to separate a soft - ware system from its environment, a subsystem from other subsystems within the soft ware system, or an individual process in a soft ware system. Th ey also can be used to separate an information system, including both soft ware and internal actors, from its environment. Care should be taken to decide what the scope of the information system is to be.

Th e name of the subject can appear either inside or on top of the box. Th e subject boundary is drawn based on the scope of the system. In the appointment system, we assumed that the Management and Doctor actors are outside of the scope of the system; that is, they use the system. We could have included a receptionist as an actor. However, in this case, we assumed that the receptionist is an internal actor who is part of the Manage Appointments

Appointment System

Patient

New Patient

Old Patient

Produce Schedules

Update Patient Information

Make Payment Arrangements

Make Old Patient Appt

Make New Patient Appt

Create New Patient

Manage Appointments

Management

Doctor

Record Availability

Manage Schedule

<< ex

te nd

>>

<<e xten

d>>

< <

in cl

ud e>

>

<<include>>

<<include>>

* *

*

*

* *

* *

FIGURE 4-4  Extend and Include Relationships

126  C h a p t e r 4 Business Process and Functional Modeling

use case with which the Patient actor interacts. Th erefore, the receptionist is not drawn on the diagram.4

Identifying the Major Use Cases Th e fi rst step is to review the requirements defi nition (see Figure 3-1). Th is helps the analyst to get a complete overview of the underlying business process being modeled.

Th e second step is to identify the subject’s boundaries. Th is helps the analyst to identify the scope of the system. However, as we work through the development process, the boundary of the system most likely will change.

Th e third step is to identify the primary actors and their goals. Th e primary actors involved with the system come from a list of stakeholders and users. Recall that a stakeholder is a per- son, group, or organization that can aff ect (or will be aff ected by) a new system, whereas an actor is a role that a stakeholder or user plays, not a specifi c user (e.g., doctor, not Dr. Jones). Th e goals represent the functionality that the system must provide the actor for the system to be a success. Identifying the tasks that each actor must perform can facilitate this. For example, does the actor need to create, read, update, delete, or execute (CRUDE)5 any infor- mation currently in the system, are there any external changes of which an actor must inform the system, or is there any information that the system should give the actor? Steps 2 and 3 are intertwined. As actors are identifi ed and their goals are uncovered, the boundary of the system will change.

Th e fourth step is to simply identify the business processes and major use cases. Rather than jumping into one use case and describing it completely at this point, we only want to identify the use cases. Identifying only the major use cases at this time prevents the users and analysts from forgetting key business processes and helps the users explain the overall set of business processes for which they are responsible. It is important at this point to understand and defi ne acronyms and jargon so that the project team and others from outside the user group can clearly understand the use cases. Again, the requirements defi nition is a very useful beginning point for this step.

Th e fi fth step is to carefully review the current set of use cases. It may be necessary to split some of them into multiple use cases or merge some of them into a single use case. Also, based on the current set, a new use case may be identifi ed. You should remember that iden- tifying use cases is an iterative process, with users oft en changing their minds about what a use case is and what it includes. It is very easy to get trapped in the details at this point, so you need to remember that the goal at this step is to only identify the major use cases. For example, in the doctor’s offi ce example in Figure 4-2, we defi ned one use case as Manage Appointments. Th is use case included the cases for both new patients and existing patients, as well as for when a patient changes or cancels an appointment. We could have defi ned each of these activities (makes an appointment, changes an appointment, or cancels an appoint- ment) as separate use cases, but this would have created a huge set of small use cases.

Th e trick is to select the right size so that you end up with three to nine use cases in each system. If the project team discovers many more than eight use cases, this suggests that the use cases are too small or that the system boundary is too big. If more than nine use cases exist, the

4 In other non-UML approaches to object-oriented systems development, it is possible to represent external actors along with internal actors. In this example, the receptionist would be considered an internal actor (see Graham, Migrating to Object Technology, and Graham, Henderson-Sellers, and Younessi, Th e OPEN Process Specifi cation). 5 We describe the use of CRUDE analysis and matrices in Chapter 6.

1. Review Require - ments Defi nition

2. Identify Subject’s Boundaries

3. Identify Primary Actors & Goals

4. Identify Business Processes & Major

Use Cases

5. Review Current Set of Use Cases

Last h1  127Business Process Identifi cation with Use Cases and Use-Case Diagrams  127

use cases should be grouped together into packages (i.e., logical groups of use cases) to make the diagrams easier to read and keep the models at a reasonable level of complexity. It is simple at that point to sort the use cases and group together these small use cases into larger use cases that include several small ones or to change the system boundaries.6

Creating a Use-Case Diagram Basically, drawing the use-case diagram is straightforward once use cases have been detailed. Th e actual use-case diagram encourages the use of information hiding. Th e only parts drawn on the use-case diagram are the system boundary, the use cases themselves, the actors, and the various associations between these components. Th e major strength of the use-case diagram is that it provides the user with an overview of the business processes. However, remember that any time a use case changes, it could aff ect the use case diagram. Th ere are four major steps in drawing a use-case diagram.

First, we place and draw the use cases on the diagram. Th ese are taken directly from the major use cases previously identifi ed. Special use-case associations (include, extend, or generaliza- tion) are also added to the model at this point. Be careful in laying out the diagram. Th ere is no formal order to the use cases, so they can be placed in whatever fashion is needed to make the diagram easy to read and to minimize the number of lines that cross. It oft en is necessary to redraw the diagram several times with use cases in diff erent places to make the diagram easy to read. Also, for understandability purposes, there should be no more than three to nine use cases on the model counting use cases that have been factored out and now are associated with another use case through the include, extend, or generalization relationships.

Second, the actors are placed and drawn on the diagram. To minimize the number of lines that cross on the diagram, the actors should be placed near the use cases with which they are associated.

Th ird, the subject boundary is drawn. Th is forms the border of the subject, separating use cases (i.e., the subject’s functionality) from actors (i.e., the roles of the external users).

Th e fourth and last step is to add associations by drawing lines to connect the actors to the use cases with which they interact. No order is implied by the diagram, and the items added along the way do not have to be placed in a particular order; therefore, it might help to rearrange the symbols a bit to minimize the number of lines that cross, making the diagram less confusing.

Campus Housing Example Identify the actors and major use cases for the following high- level business processes in a housing system run by the campus housing service. Th e campus housing service helps students fi nd apartments. Apartment owners complete information forms about the available rental units (e.g., location, number of bedrooms, monthly rent), which are then entered into a database. Students can search this database via the Web to fi nd apartments that meet their needs (e.g., a two-bedroom apartment for $400 or less per month within a half mile of campus) and contact the apartment owners directly to see the apartment and possibly rent it. Apartment owners call the service to delete their listing when they have rented their apartment(s).

As a fi rst step, we identify the primary actors, major business processes, and major use cases. In this case, the primary actors are the apartment owners and the students. Th e goal of

6 For those familiar with structured analysis and design, packages serve a similar purpose as the leveling and balancing processes used in data fl ow diagramming. Packages are described in Chapter 7.

1. Place & Draw Use Cases

2. Place & Draw Actors

3. Draw Subject Boundary

4. Add Associations

128  C h a p t e r 4 Business Process and Functional Modeling

the primary actors is both sides of a rental transaction, i.e., to rent the apartments. Th e major business processes and use cases to allow the actors to realize their goal are to maintain the available rental unit information for the apartment owners and to fi nd appropriate rental units to consider for the students. Using the identifi ed actors and use cases and following the pro- cess described above, the use-case diagram in Figure 4-5 was created. Notice that the diagram only includes two use cases and two actors. In this case, the Maintain Available Rental Unit Information use case actually includes two separate subprocesses. Th e apartment owners can add a rental unit that has become available, and they can delete a rental unit that has been rented and is no longer available. A student can search the Search Available Rental Units use case by using three separate criteria: distance from campus, number of bedrooms, and monthly rent. Th ese criteria can be used individually or by any combination of the three. We will return to this example in the next section of the chapter. However, before we move on, we next describe a slightly more involved system for a university library.

Library Example Th e functional requirements for an automated university library circulation system include the need to support searching, borrowing, and book-maintenance activities. Th e system should support searching by title, author, keywords, and ISBN. Searching the library’s collection database should be available on terminals in the library and available to potential borrowers via the Web. If the book of interest is currently checked out, a valid borrower should be allowed to request the book to be returned. Once the book has been checked back in, the borrower requesting the book should be notifi ed of the book’s availability.

Th e borrowing activities are built around checking books out and returning books by bor- rowers. Th ere are three types of borrowers: students, faculty or staff , and guests. Regardless of the type of borrower, the borrower must have a valid ID card. If the borrower is a student, hav- ing the system check with the registrar’s student database validates the ID card. If the borrower is a faculty or staff member, having the system check with the personnel offi ce’s employee data- base validates the ID card. If the borrower is a guest, the ID card is checked against the library’s own borrower database. If the ID card is valid, the system must also check to determine whether the borrower has any overdue books or unpaid fi nes. If the ID card is invalid, the borrower has overdue books, or the borrower has unpaid fi nes, the system must reject the borrower’s request to check out a book, otherwise the borrower’s request should be honored. If a book is checked out, the system must update the library’s collection database to refl ect the book’s new status.

Th e book-maintenance activities deal with adding and removing books from the library’s book collection. Th is requires a library manager to both logically and physically add and remove the book. Books being purchased by the library or books being returned in a damaged state typically cause these activities. If a book is determined to be damaged when it is returned and it needs to be removed from the collection, the last borrower will be assessed a fi ne. However, if the book can be repaired, depending on the cost of the repair, the borrower might not be assessed a fi ne. Every Monday, the library sends reminder e-mails to borrowers who have overdue books. If a book is overdue more than two weeks, the borrower is assessed a fi ne. Depending on how long the book remains overdue, the borrower can be assessed additional fi nes every Monday.

Campus Housing System

Apartment Owner

Maintain Available Rental Unit Information* *

* * Student

Search Available Rental Units

FIGURE 4-5 Campus Housing Use-Case Diagram

To begin we need to identify the major use cases and create a use-case diagram that represents the high-level business processes in the business situation just described. Based on the steps to identify the major use cases, we need to review the requirements defi nition and identify the boundaries (scope) of the problem. Based on the description of the problem, it is obvious that the system to be created is limited to managing the library’s book collection. Th e next thing we need to do is to identify the primary actors and business processes that need to be supported by the system. Based on the functional requirements described, the primary actors are borrowers and librarians, whereas the primary business processes are borrowing books, returning books, searching the book collection, maintaining the book collection, and processing overdue books. Now that we have identifi ed all of the actors and major use cases, we can draw the use-case diagram that represents an overview of the library’s book collection manage- ment system (see Figure 4-6). Notice the addition of two nonhuman actors (Personnel Offi ce and Registrar Offi ce).

BUSINESS PROCESS MODELING WITH ACTIVITY DIAGRAMS Business process models describe the diff erent activities that, when combined, support a busi- ness process. Business processes typically cut across functional departments (e.g., the creation of a new product involves many diff erent activities that combine the eff orts of many employees

Library Book Collection

Management System

Maintain Book Collection

Process Overdue Books

Librarian

Borrow Books * *

* *

*

*

*

Borrower *

*

* *

*

<<actor>> Personnel Office

* <<actor>>

Registrar Office

Search Collection

Return Books

FIGURE 4-6 Library Book Collection Management System Use-Case Diagram

Business Process Modeling with Activity Diagrams  129

130  C h a p t e r 4 Business Process and Functional Modeling

in many departments). From an object-oriented perspective, these processes cut across mul- tiple objects. Many of the earlier object-oriented systems development approaches tended to ignore business process modeling. However, today we realize that modeling business pro- cesses themselves is a very constructive activity that can be used to make sense of the gathered requirements (see Chapter 3). Th e one potential problem of building business process models, from an object-oriented systems development perspective, is that they tend to reinforce a functional decomposition mindset. However, as long as they are used properly, business pro- cess models are very powerful tools for communicating the analyst’s current understanding of the requirements to the user.

Martin Schedlbauer provides a set of best practices to follow when modeling business processes.7

■ Be realistic, because it is virtually impossible to identify everything that is included in a business process at this point in the evolution of the system. Even if we could identify everything, everything is not equally important.

■ Be agile because even though we might not identify every single feature of a business process, the features that we do identify should be identifi ed in a rigorous manner.

■ All modeling is a collaborative/social activity. Th erefore, business process mode- ling must be performed with teams, not by individuals. When an individual creates a model, the chance of mixing up or omitting important tasks is greatly increased.

■ Do not use a CASE tool to do the modeling but use whiteboards instead. However, once the process is understood, it is a good idea to use a CASE tool to doc- ument the process.

■ Process modeling should be done in an iterative manner. As you better understand a business process, you will need to return to the documented version of the process and revise it.

■ When modeling a business process, stay focused on that specifi c process. If tasks associated with other business processes are identifi ed, simply record them on a to-do list and get back to the business process that you are currently modeling.

■ Remember that a business process model is an abstraction of reality. By that, we mean that you should not include every minor task in the current description of the business process. Remember, you cannot aff ord to lose sight of the proverbial forest for the sake of detailed understanding of a single tree. Too many details at this point in the evolution of the system can cause confusion and actually prevent you from solving the underlying problem being addressed by the new system.

Activity diagrams are used to model the behavior in a business process independent of objects. Activity diagrams can be used to model everything from a high-level business workfl ow that involves many diff erent use cases, to the details of an individual use case, all the way down to the specifi c details of an individual method. In a nutshell, activity diagrams can be used to model any type of process.8 In this chapter, we restrict our coverage of activity diagrams to documenting and modeling high-level business processes.

7 Martin Schedlbauer, Th e Art of Business Process Modeling: Th e Business Analysts Guide to Process Modeling with UML & BPMN (Sudbury, MA: Th e Cathris Group, 2010). 8 Technically speaking, activity diagrams combine process-modeling ideas from many diff erent techniques, includ- ing event models, statecharts, and Petri nets. However, UML 2.0’s activity diagram has more in common with Petri nets than the other process-modeling techniques. For a good description of using Petri nets to model busi- ness workfl ows, see Wil van der Aalst and Kees van Hee, Workfl ow Management: Models, Methods, and Systems (Cambridge, MA: MIT Press, 2002).

Business Process Modeling with Activity Diagrams  131

Elements of an Activity Diagram Activity diagrams portray the primary activities and the relationships among the activities in a process. Figure 4-7 shows the syntax of an activity diagram. Figure 4-8 presents a simple activity diagram that represents the Manage Appointments use case of the appointment sys- tem for the doctor’s offi ce example.9

Actions and Activities Actions and activities are performed for some specifi c business reason. Actions and activities can represent manual or computerized behavior. Th ey are depicted in an activity diagram as a rounded rectangle (see Figure 4-7). Th ey should have a name that begins with a verb and ends with a noun (e.g., Get Patient Information or Make Payment Arrangements). Names should be short, yet contain enough information so that the reader can easily understand exactly what they do. Th e only diff erence between an action and an activity is that an activity can be decomposed further into a set of activities and/or actions, whereas an action represents a simple nondecomposable piece of the overall behavior being modeled. Typically, only activities are used for business process or workfl ow modeling. In most cases, each activity is associated with a use case. Th e activity diagram in Figure 4-8 shows a set of separate but related activities for the Manage Appointments use case (see Figures 4-2, 4-3, and 4-4): Get Patient Information, Update Patient Information, Create New Patient, Make Payment Arrangements, Make New Appointment, Change Appointment, and Cancel Appointment. Notice that the Make Payment Arrangements and Make New Appointment activities appear twice in the diagram: once for an “old” patient and once for a “new” patient.

Object Nodes Activities and actions typically modify or transform objects. Object nodes model these objects in an activity diagram. Object nodes are portrayed in an activity diagram as rectangles (see Figure 4-7). Th e name of the class of the object is written inside the rectan- gle. Essentially, object nodes represent the fl ow of information from one activity to another activity. Th e simple appointment system portrayed in Figure 4-8 shows object nodes fl owing from Get Patient Information activity.

Control Flows and Object Flows Th ere are two diff erent types of fl ows in activity dia- grams: control and object (see Figure 4-7). Control fl ows model the paths of execution through a business process. A control fl ow is portrayed as a solid line with an arrowhead on it showing the direction of fl ow. Control fl ows can be attached only to actions or activ- ities. Figure 4-8 portrays a set of control fl ows through the doctor’s offi ce’s appointment system. Object fl ows model the fl ow of objects through a business process. Because activi- ties and actions modify or transform objects, object fl ows are necessary to show the actual objects that fl ow into and out of the actions or activities. An object fl ow is depicted as a dashed line with an arrowhead on it showing the direction of fl ow. An individual object fl ow must be attached to an action or activity on one end and an object node on the other end. Figure 4-8 portrays a set of control and object fl ows through the appointment system of a doctor’s offi ce.

9 Owing to the actual complexity of the syntax of activity diagrams, we follow a minimalist philosophy in our coverage [see John M. Carrol, Th e Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill (Cambridge, MA: MIT Press, 1990)]. However, the material contained in this section is based on the Unifi ed Mod- eling Language: Superstructure Version 2.5, ptc/2010-11-14 (www.uml.org). Additional useful references include Michael Jesse Chonoles and James A. Schardt, UML 2 for Dummies (Indianapolis, IN: Wiley, 2003); Hans-Erik Eriksson, Magnus Penker, Brian Lyons, and David Fado, UML 2 Toolkit (Indianapolis: Wiley, 2004); Kendall Scott, Fast Track UML 2.0 (Berkeley, CA: Apress, 2004). For a complete description of all diagrams, see www.uml.org.

132  C h a p t e r 4 Business Process and Functional Modeling

An action: ■ Is a simple, nondecomposable piece of behavior. ■ Is labeled by its name.

An activity: ■ Is used to represent a set of actions. ■ Is labeled by its name.

Activity

Action

An object node: ■ Is used to represent an object that is connected to a set of object flows. ■ Is labeled by its class name.

A decision node:

■ Is used to represent a test condition to ensure that the control flow or object flow only goes down one path.

■ Is labeled with the decision criteria to continue down the specific path.

A control flow:

■ Shows the sequence of execution.

A final-activity node:

■ Is used to stop all control flows and object flows in an activity (or action).

An initial node:

■ Portrays the beginning of a set of actions or activities.

A merge node:

■ Is used to bring back together different decision paths that were created using a decision node.

A fork node:

Is used to split behavior into a set of parallel or concurrent flows of activities (or

A swimlane:

A join node:

Is used to bring back together a set of parallel or concurrent flows of activities (or

An object flow:

■ Shows the flow of an object from one activity (or action) to another activity (or action).

A final-flow node:

■ Is used to stop a specific control flow or object flow.

Swimlane

[Decision Criteria]

[Decision Criteria]

Is used to break up an activity diagram into rows and columns to assign the individual activities (or actions) to the individuals or objects that are responsible for executing the activity (or action)

Is labeled with the name of the individual or object responsible

Class Name

actions)

actions)

FIGURE 4-7  Syntax for an Activity Diagram

Control Nodes Th ere are seven diff erent types of control nodes in an activity diagram: initial, fi nal-activity, fi nal-fl ow, decision, merge, fork, and join (see Figure 4-7). An initial node por- trays the beginning of a set of actions or activities. An initial node is shown as a small fi lled-in circle. A fi nal-activity node is used to stop the process being modeled. Any time a fi nal-activity

Business Process Modeling with Activity Diagrams  133

Get Patient Information

Appt Request Info

Appt Request Info

Create New Patient

Update Patient Information

[New Patient][Old Patient]

[Create] [Change]

Cancel Appointment Change AppointmentCreate Appointment

Make Payment Arrangements

Create Appointment

Make Payment Arrangements

[New Info]

[New Arrange]

[Cancel]

FIGURE 4-8  Activity Diagram for the Manage Appointments Use Case

node is reached, all actions and activities are ended immediately, regardless of whether they are completed. A fi nal-activity node is represented as a circle surrounding a small, fi lled-in circle, making it resemble a bull’s-eye. A fi nal-fl ow node is similar to a fi nal-activity node, except that it stops a specifi c path of execution through the business process but allows the other concur- rent or parallel paths to continue. A fi nal-fl ow node is shown as a small circle with an X in it.

134  C h a p t e r 4 Business Process and Functional Modeling

Th e decision and merge nodes support modeling the decision structure of a business pro- cess. Th e decision node is used to represent the actual test condition that determines which of the paths exiting the decision node is to be traversed. In this case, each exiting path must be labeled with a guard condition. A guard condition represents the value of the test for that particular path to be executed. For example, in Figure 4-8, the decision node immediately below the Get Patient Information activity has two mutually exclusive paths that could be executed: one for old, or previous, patients and the other for new patients. Th e merge node is used to bring back together multiple mutually exclusive paths that have been split based on an earlier decision (e.g., the old- and new-patient paths in Figure 4-8 are brought back together near the bottom of the diagram). However, sometimes, for clarity, it is better not to use a merge node. For example, in Figure 4-9, which of the two activity diagrams, both representing an overview level of an order process, is easier to understand, the one on the left or the one on the right? Th e one on the left contains a merge node for the More Items on Order question, but the one on the right does not. In a sense, the decision node is playing double duty in the diagram on the right: It also serves as a merge node. Technically speaking, we should not omit the merge node; however,

[Item Available] [Item Not Available]

[More Items on Order]

[No More Items on Order]

Place Order

Process Order

Back Order ItemProcess Item Process Item

[Item Available] [Item Not Available]

[More Items on Order]

[No More Items on Order]

Place Order

Process Order

Back Order Item

FIGURE 4-9  Two Very Similar Activity Diagrams

Business Process Modeling with Activity Diagrams  135

sometimes being technically correct according to the UML’s diagramming rules actually causes the diagram to become confusing. From a business process modeling perspective, a good deal of common sense can go a long way.

Th e fork and join nodes allow parallel and concurrent processes to be modeled (see Figure 4-7). Th e fork node is used to split the behavior of the business process into multiple parallel or concurrent fl ows. Unlike the decision node, the paths are not mutually exclusive (i.e., both paths are executed concurrently). For example, in Figure 4-10, the fork node

firstParent secondParent

GetJelly GetBread

GetDrink GetDessert

GetPeanutButter

CreateSandwich

CreateLunch

GetLunchBox

PutLunchInBox

FIGURE 4-10 Activity Diagram for Making a School Box Lunch

136  C h a p t e r 4 Business Process and Functional Modeling

is used to show that two concurrent, parallel processes are to be executed. In this case, each process is executed by two separate processors (parents). Th e purpose of the join node is sim- ilar to that of the merge node. Th e join node simply brings back together the separate parallel or concurrent fl ows in the business process into a single fl ow.

Swimlanes Activity diagrams can model a business process independent of any object imple- mentation. However, there are times when it helps to break up an activity diagram in such a way that it can be used to assign responsibility to objects or individuals who would actually perform the activity. Th is is especially useful when modeling a business workfl ow and is accomplished through the use of swimlanes. In Figure 4-10, the swimlanes are used to break up among two parents the making of a school lunch comprising a peanut butter and jelly sandwich, a drink, and dessert. In this case, we use vertical swimlanes. We could also draw the activity diagram using more of a left -to-right orientation instead of a top-down orientation. In that case, the swimlanes are drawn horizontally.

In an actual business workfl ow, there would be activities that should be associated with roles of individuals involved in the business workfl ow (e.g., employees or customers) and the activities to be accomplished by the information system being created. Th is association of activities with external roles, internal roles, and the system is very useful when creating the use-case descriptions described later in this chapter.

Guidelines for Creating Activity Diagrams Scott Ambler suggests the following guidelines when creating activity diagrams:10

■ Because an activity diagram can be used to model any kind of process, you should set the context or scope of the activity being modeled. Once you have determined the scope, you should give the diagram an appropriate title.

■ You must identify the activities, control fl ows, and object fl ows that occur between the activities.

■ You should identify any decisions that are part of the process being modeled. ■ You should attempt to identify any prospects for parallelism in the process. ■ You should draw the activity diagram.

When drawing an activity diagram, the diagram should be limited to a single initial node that starts the process being modeled. Th is node should be placed at the top or top left of the diagram, depending on the complexity of the diagram. For most business processes, there should only be a single fi nal-activity node. Th is node should be placed at the bottom or bot- tom right of the diagram (see Figures 4-8, 4-9, and 4-10). Because most high-level business processes are sequential, not parallel, the use of a fi nal-fl ow node should be limited.

When modeling high-level business processes or workfl ows, only the more important decisions should be included in the activity diagrams. In those cases, the guard conditions associated with the outfl ows of the decision nodes should be mutually exclusive. Th e outfl ows and guard conditions should form a complete set (i.e., all potential values of the decision are associated with one of the fl ows).

As in decision modeling, forks and joins should be included only to represent the more important parallel activities in the process. For example, an alternative version of Figure 4-10

10 Th e guidelines presented here are based on work done by Scott Ambler. For more details, see Scott W. Ambler, Th e Object Primer: Th e Application Developer’s Guide to Object Orientation and the UML, 2nd Ed. (Cambridge, England: Cambridge University Press/SIGS Books, 2001); Scott W. Ambler, Th e Elements of UML Style (Cambridge, England: Cambridge University Press, 2003).

Business Process Modeling with Activity Diagrams  137

might not include the forks and joins associated with the Get Jelly, Get Bread, Get Peanut Butter, Get Drink, and Get Dessert activities. Th is would greatly simplify the diagram.11

When laying out the activity diagram, line crossings should be minimized to enhance the readability of the diagram. Th e activities on the diagram should also be laid out in a left - to-right and/or top-to-bottom order based on the order in which the activities are executed. For example, in Figure 4-10, the Create Sandwich activity takes place before the Create Lunch activity.

Swimlanes should be used only to simplify the understanding of an activity diagram. Furthermore, the swimlanes should enhance the readability of a diagram. For example, when using a horizontal orientation for swimlanes, the top swimlane should represent the most important object or individual involved with the process. Th e order of the remain- ing swimlanes should be based on minimizing the number of fl ows crossing the diff erent swimlanes. Also, when there are object fl ows among the activities associated with the dif- ferent individuals (swimlanes) executing the activities of the process, it is useful to show the actual object fl owing from one individual to another individual by including an object node between the two individuals (i.e., between the two swimlanes). Th is, of course, aff ects how the swimlanes should be placed on the diagram.

Finally, any activity that does not have any outfl ows or any infl ows should be challenged. Activities with no outfl ows are referred to as black-hole activities. If the activity is truly an end point in the diagram, the activity should have a control fl ow from it to a fi nal-activity or fi nal-fl ow node. An activity that does not have any infl ow is known as a miracle activity. In this case, the activity is missing an infl ow either from the initial node of the diagram or from another activity.

Creating Activity Diagrams Th ere are fi ve steps in creating an activity diagram to document and model a business process. First, you must choose a business process that was previously identifi ed to model. To do this, you should review the requirements defi nition (see Figure 3-1) and the use-case diagram (see Figures 4-2, 4-3, and 4-4) created to represent the requirements. You should also review all of the documentation created during the requirements-gathering process (see Chapter 3), e.g., reports created that documented interviews or observations, any output from any JAD sessions, any analysis of any questionnaires used, and any story cards or task lists created. In most cases, the use cases on the use-case diagram will be the best place to start. For example, in the appointment system, we had identifi ed three primary use cases: Manage Appointments, Produce Schedule, and Record Doctor Availability. We also identifi ed a whole set of minor use cases (these will be useful in identifying the elements of the activity diagram).

Second, identify the set of activities necessary to support the business process. For exam- ple, in Figure 3-1, three processes are identifi ed as being part of the Manage Appointments business process. Also, by reviewing the use-case diagram (see Figure 4-4), we see that fi ve minor use cases are associated with the Manage Appointments major use case. Based on this information, we can identify a set of activities. In this case, the activities are Update Patient Information, Make Payment Arrangements, Create New Patient, Create Appointment, Cancel Appointment, and Change Appointment.

Th ird, identify the control fl ows and nodes necessary to document the logic of the business process. For example, in Figure 4-4, the Make Payment Arrangements and Update Patient

11 In fact, the only reason we depicted the diagram in Figure 4-10 with the multiple fork and join nodes was to demonstrate that it could be done.

1. Choose a Business Process

2. Identify Activities

3. Identify Control Flows & Nodes

138  C h a p t e r 4 Business Process and Functional Modeling

Information use cases are extensions to the Manage Appointments and Make Old Patient Appt uses cases. We know that these use cases are executed only in certain circumstances. From this we can infer that the activity diagram must include some decision and merge nodes. Based on the requirements defi nition (see Figure 3-1), we can infer another set of deci- sion and merge nodes based on the Create Appointment, Cancel Appointment, and Change Appointment activities identifi ed in the previous step.

Fourth, identify the object fl ows and nodes necessary to support the logic of the business process. Typically object nodes and fl ows are not shown on many activity diagrams used to model a business process. Th e primary exception is if information captured by the system in one activity is used in an activity that is performed later, but not immediately aft er the activity that captured the information. In the appointment example, it is obvious that we need to be able to determine whether the patient is an old or new patient and the type of action that the patient would like to have performed (create, cancel, or change an appointment). It is obvious that a new patient cannot cancel or change an appointment because the patient is by defi nition a new patient. Obviously, we need to capture this type of information at the beginning of the business process and use it when required. For example, in the appointment problem, we need to have a Get Patient Information activity that captures the appropriate information and makes it available at the appropriate time in the process.

Fift h, lay out and draw the activity diagram to document the business process. For esthetic and understandability reasons, just as when drawing a use-case diagram, you should attempt to minimize potential line crossings. Based on the previous steps and carefully laying out the diagram, the activity diagram in Figure 4-8 was created to document the Manage Appointments business process.

Campus Housing Example Th e fi rst step in detailing the identifi ed business processes (Maintain Available Rental Unit Information and Search Available Rental Units) is to choose one of them. In this example, we are going to focus on the Maintain Available Rental Unit Information associated with the apartment owners. Based on the earlier description, there are two separate activities (subprocesses): one to add a rental unit and one to delete a rental unit. To add a rental unit, the apartment owner must provide the campus housing service with the location of the apartment, the number of bedrooms in the apartment, and the monthly rent of the apartment. To delete an apartment, the apartment owners must tell the campus housing service that the specifi c apartment has been rented and is no longer available. Using this information, the activity diagram that represents the logical description of the Maintain Available Rental Unit Information use case is portrayed in Figure 4-11. Notice that there is absolutely no reference to fi lling out a form, entering the information into a database, or searching the database. Th ere are actually many diff erent potential ways in which the apart- ment information could be captured, e.g., on a manual form, on a computerized form, on a Web form, and via a mobile interface. In fact, we might want to be able to support all of them. Also, there are many diff erent ways in which the information can be stored. However, at this stage of development, all design and implementation details should be ignored. We are only interested in capturing the functional requirements. Once we have successfully modeled the functional requirements, we can move on to the nonfunctional requirements, design, and implementation details. We will return to this example in the next section of the chapter. However, before we move on, we next describe the activity diagram for the Borrow Books use case of the university library problem.

4. Identify Object Flows & Nodes

5. Lay Out & Draw Diagram

Business Process Modeling with Activity Diagrams  139

Library Example As with the Campus Housing example, the fi rst step is to choose a business process to model. In this case, we want to create an activity diagram for the Borrow Books use case (see Figure 4-6). Th e functional requirements for this use case were:

Th e borrowing activities are built around checking books out and returning books by borrowers. Th ere are three types of borrowers: students, faculty or staff , and guests. Regardless of the type of borrower, the borrower must have a valid ID card. If the bor- rower is a student, having the system check with the registrar’s student database vali- dates the ID card. If the borrower is a faculty or staff member, having the system check with the personnel offi ce’s employee database validates the ID card. If the borrower is a guest, the ID card is checked against the library’s own borrower database. If the ID card is valid, the system must also check to determine whether the borrower has any overdue books or unpaid fi nes. If the ID card is invalid, the borrower has overdue books, or the borrower has unpaid fi nes, the system must reject the borrower’s request to check out a book, otherwise the borrower’s request should be honored.

Th e second step to model a business process is to identify the activities that make up the pro- cess. Based on the requirements for the Borrow Books use case, we can identify three major activities: Validate ID Card, Check for Overdue Books and Fines, and Check Out Books. Th e third step is to identify the control fl ows and control nodes necessary to model the decision logic of the business process. In this case, there obviously will have to be an initial node, a fi nal-fl ow node, and a set of decision and merge nodes for each decision to be made. Th e fourth step is to identify the object fl ows and object nodes necessary to complete the descrip- tion of the business process. In this case, there really is no need to include object nodes and fl ows. Finally, we can lay out the diagram (see Figure 4-12).

FIGURE 4-11 Campus Housing Maintain Available Rental Unit Information Activity Diagram

[Apartment Rented][Apartment Available]

Delete Rental UnitCapture Location

Capture Number of Bedrooms

Capture Monthly Rent

Add Rental Unit

140  C h a p t e r 4 Business Process and Functional Modeling

BUSINESS PROCESS DOCUMENTATION WITH USE CASES AND USE-CASE DESCRIPTIONS

Use-case diagrams provided a bird’s-eye view of the basic functionality of the business pro- cesses contained in the evolving system. Activity diagrams, in a sense, open up the black box of each business process by providing a more-detailed graphical view of the underlying activities that support each business process. Use-case descriptions provide a means to more fully doc- ument the diff erent aspects of each individual use case.12 Th e use-case descriptions are based on the identifi ed requirements, use-case diagram, and the activity diagram descriptions of the business processes. Use-case descriptions contain all the information needed to document the functionality of the business processes.13

Use cases are the primary drivers for all the UML diagramming techniques. A use case communicates at a high level what the system needs to do, and all the UML diagramming tech- niques build on this by presenting the use-case functionality in a diff erent way for a diff erent purpose. Use cases are the building blocks by which the system is designed and built.

12 For a more detailed description of use-case modeling, see Alistair Cockburn, Writing Eff ective Use Cases (Reading, MA: Addison-Wesley, 2001). 13 Nonfunctional requirements, such as reliability requirements and performance requirements, are oft en docu- mented outside of the use case through more traditional requirements documents. See Gerald Kotonya and Ian Sommerville, Requirements Engineering (Chichester, England: Wiley, 1998); Benjamin L. Kovitz, Practical Soft ware Requirements: A Manual of Content & Style (Greenwich, CT: Manning, 1999); Dean Leffi ngwell and Don Widrig, Managing Soft ware Requirements: A Unifi ed Approach (Reading, MA: Addison-Wesley, 2000); Richard H. Th ayer, M. Dorfman, and Sidney C. Bailin (eds.), Soft ware Requirements Engineering, 2nd Ed. (Los Alamitos, CA: IEEE Computer Society, 1997).

[Valid Card]

[No Overdue Books & No Fines]

Validate ID Card

Check Out Books

Check for Overdue Books and Fines

FIGURE 4-12 Activity Diagram for the Borrow Books Use Case

Business Process Documentation with Use Cases and Use-Case Descriptions  141

Use cases capture the typical interaction of the system with the system’s users (end users and other systems). Th ese interactions represent the external, or functional, view of the system from the perspective of the user. Each use case describes one and only one function in which users interact with the system. Although a use case may contain several paths that a user can take while interacting with the system, each possible execution path through the use case is referred to as a scenario. Another way to look at a scenario is as if a scenario is an instantiation of a specifi c use case. Scenarios are used extensively in behavioral modeling (see Chapter 6). Finally, by identifying all scenarios and trying to execute them through role-playing CRC cards (see Chapter 5), you will be testing the clarity and completeness of your evolving understanding of the system being developed.14

When creating use-case descriptions, the project team must work closely with the users to fully document the functional requirements. Organizing the functional requirements and docu- menting them in a use-case description are a relatively simple process, but it takes considerable practice to ensure that the descriptions are complete enough to use in structural (Chapter 5) and behavioral (Chapter 6) modeling. Th e best place to begin is to review the use-case and activity diagrams. Th e key thing to remember is that each use case is associated with one and only one role that users have in the system. For example, a receptionist in a doctor’s offi ce may play mul- tiple roles—he or she can make appointments, answer the telephone, fi le medical records, wel- come patients, and so on. It is possible that multiple users will play the same role. Th erefore, use cases should be associated with the roles played by the users and not with the users themselves.

Types of Use Cases Th ere are many diff erent types of use cases. We suggest two separate dimensions on which to classify a use case based on the purpose of the use case and the amount of information that the use case contains: overview versus detail and essential versus real.

An overview use case is used to enable the analyst and user to agree on a high-level over- view of the requirements. Typically, overview use cases are created very early in the process of understanding the system requirements, and they document only basic information about the use case, such as its name; ID number; primary actor; type; a brief description; and the relationships among the actors, actors and use cases, and use cases. Th ese can easily be created immediately aft er the creation of the use-case diagram.

Once the user and the analyst agree upon a high-level overview of the requirements, the overview use cases are converted to detail use cases. A detail use case typically documents, as far as possible, all the information needed for the use case. Th ese can be based on the activities and control fl ows contained in the activity diagrams.

An essential use case is one that describes only the minimum essential issues necessary to understand the required functionality. A real use case goes farther and describes a specifi c set of steps. For example, an essential use case in a doctor offi ce might say that the receptionist should attempt to match the patient’s desired appointment times with the available times, whereas a real use case might say that the receptionist should look up the available dates on the calendar using Google Calendar to determine if the requested appointment times were available. Th e primary diff erence is that essential use cases are implementation independent, whereas real use cases are detailed descriptions of how to use the system once it is imple- mented. Th us, real use cases tend to be used only in the design, implementation, and testing.

Elements of a Use-Case Description A use-case description contains all the information needed to build the structural (Chapter 5) and behavioral (Chapter 6) diagrams that follow, but it expresses the information in a less-formal

14 For presentation purposes, we defer discussion of role-playing to Chapter 5.

142  C h a p t e r 4 Business Process and Functional Modeling

way that is usually simpler for users to understand. Figure 4-13 shows a sample use-case description.15 A use-case description has three basic parts: overview information, relationships, and the fl ow of events.

Overview Information Th e overview information identifi es the use case and provides basic background information about the use case. Th e use-case name should be a verb–noun phrase (e.g., Make Old Patient Appt). Th e use-case ID number provides a unique way to fi nd every use case and also enables the team to trace design decisions back to a specifi c requirement. Th e use-case type is either overview or detail and essential or real. Th e primary actor is usually the trigger of the use case—the person or thing that starts the execution of the use case. Th e primary purpose of the use case is to meet the goal of the primary actor. Th e brief description is typically a single sentence that describes the essence of the use case.

Th e importance level can be used to prioritize the use cases. Th e importance level enables the users to explicitly prioritize which business functions are most important and need to be part of the fi rst version of the system and which are less important and can wait until later versions if necessary. Th e importance level can use a fuzzy scale, such as high, medium, and low (e.g., in Figure 4-13 we have assigned an importance level of high to the Make Old Patient Appt use case). It can also be done more formally using a weighted average of a set of criteria. For example, Larman16 suggests rating each use case over the following criteria using a scale from zero to fi ve:

■ Th e use case represents an important business process. ■ Th e use case supports revenue generation or cost reduction. ■ Technology needed to support the use case is new or risky and therefore requires

considerable research. ■ Functionality described in the use case is complex, risky, and/or time critical.

Depending on a use case’s complexity, it may be useful to consider splitting its imple- mentation over several diff erent versions.

■ Th e use case could increase understanding of the evolving design relative to the eff ort expended.

A use case may have multiple stakeholders that have an interest in the use case. Each use case lists each of the stakeholders with each one’s interest in the use case (e.g., Old Patient and Doctor). Th e stakeholders’ list always includes the primary actor (e.g., Old Patient).

Each use case typically has a trigger—the event that causes the use case to begin (e.g., Old Patient calls and asks for a new appointment or asks to cancel or change an existing appoint- ment). A trigger can be an external trigger, such as a customer placing an order or the fi re alarm ringing, or it can be a temporal trigger, such as a book being overdue at the library or the need to pay the rent.

Relationships Use-case relationships explain how the use case is related to other use cases and users. Th ere are four basic types of relationships: association, extend, include, and gener- alization. An association relationship documents the communication that takes place between the use case and the actors that use the use case. An actor is the UML representation for the

15 Currently there is no standard set of elements for a use case. Th e elements described in this section are based on recommendations contained in Alistair Cockburn, Writing Eff ective Use Cases (Reading, MA: Addison-Wesley, 2001); Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unifi ed Process, 2nd Ed. (Upper Saddle River, NJ: Prentice Hall, 2002); Brian Henderson-Sellers and Bhuvan Unhelkar, OPEN Modeling with UML (Reading, MA: Addison-Wesley, 2000). Also see Graham, Migrating to Object Technology. 16 Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design.

Business Process Documentation with Use Cases and Use-Case Descriptions  143

Use Case Name:

Primary Actor:

Stakeholders and Interests:

Brief Description:

ID: Importance Level:

Trigger:

Normal Flow of Events:

SubFlows:

Alternate/Exceptional Flows:

Type: External

Make Old Patient Appt 2 Low

Old Patient

Old Patient – wants to make, change, or cancel an appointment Doctor – wants to ensure patient’s needs are met in a timely manner

Use Case Type: Detail, Essential

Patient calls and asks for a new appointment or asks to cancel or change an existing appointment

Old Patient

Update Patient Information Manage Appointments

1. The Patient contacts the office regarding an appointment. 2. The Patient provides the Receptionist with his or her name and address. 3. If the Patient’s information has changed Execute the Update Patient Information use case. 4. If the Patient’s payment arrangements has changed Execute the Make Payments Arrangements use case. 5. The Receptionist asks Patient if he or she would like to make a new appointment, cancel an existing appointment, or change an existing appointment.

S-1: New Appointment 1. The Receptionist asks the Patient for possible appointment times. 2. The Receptionist matches the Patient’s desired appointment times with available dates and times and schedules the new appointment.

S-2: Cancel Appointment 1. The Receptionist asks the Patient for the old appointment time. 2. The Receptionist finds the current appointment in the appointment file and cancels it.

S-3: Change Appointment 1. The Receptionist performs the S-2: cancel appointment subflow. 2. The Receptionist performs the S-1: new appointment subflow.

S-1, 2a1: The Receptionist proposes some alternative appointment times based on what is available in the appointment schedule. S-1, 2a2: The Patient chooses one of the proposed times or decides not to make an appointment.

6. The Receptionist provides the results of the transaction to the Patient.

This use case describes how we make an appointment as well as changing or canceling an appointment for a previously seen patient.

Relationships: Association: Include: Extend: Generalization:

If the patient wants to make a new appointment, the S-1: new appointment subflow is performed. If the patient wants to cancel an existing appointment, the S-2: cancel appointment subflow is performed. If the patient wants to change an existing appointment, the S-3: change appointment subflow is performed.

FIGURE 4-13  Sample Use-Case Description

role that a user plays in the use case. For example, in Figure 4-13, the Make Old Patient Appt use case is associated with the actor Old Patient (see Figure 4-4). In this case, a patient makes an appointment. All actors involved in the use case are documented with the association relationship.

TEMPLATE can be found at www.wiley.com /college/dennis

144  C h a p t e r 4 Business Process and Functional Modeling

An include relationship represents the mandatory inclusion of another use case. Th e include relationship enables functional decomposition—the breaking up of a complex use case into several simpler ones. For example, in Figure 4-4, the Manage Schedule use case was considered to be complex and complete enough to be factored out as a separate use case that could be executed by the Produce Schedules and Record Availability use cases. Th e include relationship also enables parts of use cases to be reused by creating them as separate use cases.

An extend relationship represents the extension of the functionality of the use case to incorporate optional behavior. In Figure 4-13, the Make Old Patient Appt use case condi- tionally uses the Update Patient Information use case. Th is use case is executed only if the patient’s information has changed.

Th e generalization relationship allows use cases to support inheritance. For example, the use case in Figure 4-4, the Manage Appointments use case, was specialized so that a new patient would be associated with the Make New Patient Appt and an old patient could be associated with a Make Old Patient Appt. Th e common, or generalized, behav- ior that both the Make New Patient Appointment and Make Old Patient Appointment use cases contain would be placed in the generalized Manage Appointments use case. In other words, the Make New Patient Appointment and Make Old Patient Appointment use cases would inherit the common functionality from the Manage Appointments use case. Th e specialized behavior would be placed in the appropriate specialized use case. For example, the extend relationship to the Update Patient Information use case would be placed with the specialized Make Old Patient Appointment use case.

Flow of Events Finally, the individual steps within the business process are described. Th ree diff erent categories of steps, or fl ows of events, can be documented: normal fl ow of events, subfl ows, and alternative, or exceptional, fl ows:

■ Th e normal fl ow of events includes only steps that normally are executed in a use case. Th e steps are listed in the order in which they are performed. In Figure 4-13, the patient and the receptionist have a conversation regarding the patient’s name, address, and action to be performed.

■ In some cases, the normal fl ow of events should be decomposed into a set of subfl ows to keep the normal fl ow of events as simple as possible. In Figure 4-13, we have identifi ed three subfl ows: Create Appointment, Cancel Appointment, and Change Appointment. Each of the steps of the subfl ows is listed. Th ese subfl ows are based on the control fl ow logic in the activity diagram representation of the business process (see Figure 4-7). Alternatively, we could replace a subfl ow with a separate use case that could be incorporated via the include relationships (see the earlier discussion). However, this should be done only if the newly created use case makes sense by itself. For example, in Figure 4-13, does it make sense to factor out a Create Appointment, Cancel Appointment, and/or Change Appointment use case? If it does, then the spe- cifi c subfl ow(s) should be replaced with a call to the related use case, and the use case should be added to the include relationship list.

■ Alternative or exceptional fl ows are ones that do happen but are not considered to be the norm. Th ese must be documented. For example, in Figure 4-13, we have identi- fi ed two alternative or exceptional fl ows. Th e fi rst one simply addresses the situation that occurs when the set of requested appointment times is not available. Th e second one is simply a second step to the alternative fl ow. Like the subfl ows, the primary purpose of separating out alternate or exceptional fl ows is to keep the normal fl ow of events as simple as possible. Again, as with the subfl ows, it is possible to replace the alternate or exceptional fl ows with separate use cases that could be integrated via the extend relationship (see the earlier discussion).

Business Process Documentation with Use Cases and Use-Case Descriptions  145

When should events be factored out from the normal fl ow of events into subfl ows? When should subfl ows and/or alternative or exceptional fl ows be factored out into separate use cases? Or when should things simply be left alone? Th e primary criteria should be based on the level of complexity that the use case entails. Th e more diffi cult it is to understand the use case, the more likely events should be factored out into subfl ows, or subfl ows and/or alternative or exceptional fl ows should be factored out into separate use cases that are called by the current use case. Th is, of course, creates more use cases. Th erefore, the use-case diagram will become more cluttered. In other words, the choice that the analyst must make is to have a more complex use-case dia- gram with simpler use cases or have a simpler use-case diagram with more complex use cases. Practically speaking, we must decide which makes more sense. Th is varies greatly, depending on the problem and the client. Remember, we are trying to represent, in a manner as complete and concise as possible, our understanding of the business processes that we are investigating so that the client can validate the requirements that we are modeling. Th erefore, there really is no single right answer. It really depends on the analyst, the client, and the problem.

Optional Characteristics Other characteristics of use cases can be documented by use-case descriptions. Th ese include the level of complexity of the use case; the estimated amount of time it takes to execute the use case; the system with which the use case is associated; specifi c data fl ows between the primary actor and the use case; any specifi c attribute, constraint, or operation associated with the use case; any preconditions that must be satisfi ed for the use case to execute; or any guarantees that can be made based on the execution of the use case. As we noted at the beginning of this section, there is no standard set of characteristics of a use case that must be captured. We suggest that the information contained in Figure 4-13 is the minimal amount to be captured.

Guidelines for Creating Use-Case Descriptions17 Th e essence of a use case is the fl ow of events. Writing the fl ow of events in a manner that is useful for later stages of development generally comes with experience.

First, write each individual step in the form subject–verb–direct object and, optionally, preposition–indirect object. Th is form has become known as SVDPI sentences. Th is form of sentence has proved to be useful in identifying classes and operations (see Chapter 5). For example, in Figure 4-13, the fi rst step in the normal fl ow of events, the Patient contacts the offi ce regarding an appointment, suggests the possibility of three classes of objects: Patient, Offi ce, and Appointment. Th is approach simplifi es the process of identifying the classes in the structural model (see Chapter 5). SVDPI sentences cannot be used for all steps, but they should be used whenever possible.

Second, make clear who or what is the initiator of the action and who or what is the receiver of the action in each step. Normally, the initiator should be the subject of the sen- tence and the receiver should be the direct object of the sentence. For example, in Figure 4-13, the second step, Patient provides the Receptionist with his or her name and address, clearly portrays the Patient as the initiator and the Receptionist as the receiver.

Th ird, write the step from the perspective of an independent observer. To accomplish this, each step might have to be written fi rst from the perspective of both the initiator and the receiver. Based on the two points of view, the bird’s-eye view version can then be written. For example, in Figure 4-13, the Patient provides the Receptionist with his or her name and address, neither the patient’s nor the receptionist’s perspective is represented.

Fourth, write each step at the same level of abstraction. Each step should make about the same amount of progress toward completing the use case as each of the other steps.

17 Th ese guidelines are based on Cockburn, Writing Eff ective Use Cases, and Graham, Migrating to Object Technology.

146  C h a p t e r 4 Business Process and Functional Modeling

On high-level use cases, the amount of progress could be very substantial, whereas in a low-level use case, each step could represent only incremental progress. For example, in Figure 4-13, each step represents about the same amount of eff ort to complete.

Fift h, ensure that the use case contains a sensible set of actions. Each use case should represent a transaction. Th erefore, each use case should comprise four parts:

1. Th e primary actor initiates the execution of the use case by sending a request (and possibly data) to the system.

2. Th e system ensures that the request (and data) is valid. 3. Th e system processes the request (and data) and possibly changes its own internal state. 4. Th e system sends the primary actor the result of the processing.

For example, in Figure 4-13, the patient requests an appointment (steps 1 and 2), the receptionist determines whether any of the patient’s information has changed or not (step 3), the receptionist determines whether the patient’s payments arrangements have changed or not (step 4), the receptionist sets up the appointment transaction (step 5), and the receptionist provides the results of the transaction to the patient (step 6).

Th e sixth guideline is the KISS principle. If the use case becomes too complex and/or too long, the use case should be decomposed into a set of use cases. Furthermore, if the normal fl ow of events of the use case becomes too complex, subfl ows should be used. For example, in Figure 4-13, the fi ft h step in the normal fl ow of events was suffi ciently complex to decompose it into three separate subfl ows. However, care must be taken to avoid the possibility of decomposing too much. Most decomposition should be done with classes (see Chapter 5).

Th e seventh guideline deals with repeating steps. Normally, in a programming language, we put loop defi nition and controls at the beginning of the loop. However, because the use- case steps are written in simple English, it is normally better to simply write Repeat steps A through E until some condition is met aft er step E. It makes the use case more readable to people unfamiliar with programming.

Creating Use Case Descriptions Use cases provide a bird’s-eye view of the business processes contained in the evolving system. Th e use-case diagram depicts the communication path between the actors and the system. Use cases and their use-case description documentation tend to be used to model both the contexts of the system and the detailed requirements for the system. Even though the pri- mary purpose of use cases is to document the functional requirements of the system, they also are used as a basis for testing the evolving system. In this section, we provide a set of steps that can be used to guide the actual creation of a use-case description for each use case in the use- case diagram based on the requirements defi nition and the use-case and activity diagrams.18 Th ese steps are performed in order, but of course the analyst oft en cycles among them in an iterative fashion as he or she moves from one use case to another use case.

Th e fi rst step is to choose one of the use cases to document with a use-case description. Using the importance level of the use case can help do this. For example, in Figure 4-13, the Make Old Patient Appt use case has an importance level of high. As such, it should be one of the earlier use

18 Th e approach in this section is based on the work of Cockburn, Writing Eff ective Use Cases; Graham, Migrating to Object Technology; George Marakas and Joyce Elam, “Semantic Structuring in Analyst Acquisition and Representa- tion of Facts in Requirements Analysis,” Information Systems Research 9, no. 1 (1998): 37–63; Alan Dennis, Glenda Hayes, and Robert Daniels, “Business Process Modeling with Group Support Systems,” Journal of Management Information Systems 15, no. 4 (1999): 115–142.

1. Choose a Use Case

Business Process Documentation with Use Cases and Use-Case Descriptions  147

cases to be expanded. Th e criteria suggested by Larman19 can also be used to set the prioritization of the use cases, as noted earlier. An alternative approach suggests that each use case should be voted on by each member of the development team. In this approach, each team member is given a set of “dots” that they can use to vote on the use cases. Th ey can use all of their dots to vote for a single use case, or they can spread them over a set of use cases. Th e use cases then can be ranked in order of the number of dots received. Use case descriptions are created for the individual use cases based on the rank order.20

Th e second step is to create an overview description of the use case; that is, name the primary actor, set the type for the use case, list all of the identifi ed stakeholders and their interests in the use case, identify the level of importance of the use case, give a brief description of the use case, give the trigger information for the use case, and list the relationships in which the use case participates.

Th e third step is to fi ll in the steps of the normal fl ow of events required to describe each use case. Th e steps focus on what the business process does to complete the use case, as opposed to what actions the users or other external entities do. In general, the steps should be listed in the order in which they are performed, from fi rst to last. Remember to write the steps in an SVDPI form whenever possible. In writing the use case, remember the seven guidelines described earlier. Th e goal at this point is to describe how the chosen use case operates. One of the best ways to begin to understand how an actor works through a use case is to visualize per- forming the steps in the use case—i.e., role play. Th e techniques of visualizing how to interact with the system and of thinking about how other systems work (informal benchmarking) are important techniques that help analysts and users understand how systems work and how to write a use case. Both techniques (visualization and informal benchmarking) are common in practice. It is important to remember that at this point in the development of a use case, we are interested only in the typical successful execution of the use case. If we try to think of all of the possible combinations of activities that could go on, we will never get anything written. At this point, we are looking only for the three to seven major steps. Focus only on performing the typical process that the use case represents.

Th e fourth step is to ensure that the steps listed in the normal fl ow of events are not too complex or too long. Each step should be about the same size as the others. For example, if we were writing steps for preparing a meal, steps such as take fork out of drawer and put fork on table are much smaller than prepare cake using mix. If we end up with more than seven steps or steps that vary greatly in size, we should go back and review each step carefully and possibly rewrite the steps.

One good approach to produce the steps for a use case is to have the users visualize themselves actually performing the use case and to have them write down the steps as if they were writing a recipe for a cookbook. In most cases, the users will be able to quickly defi ne what they do in the as-is model. Defi ning the steps for to-be use cases might take a bit more coaching. In our experience, the descriptions of the steps change greatly as users work through a use case. Our advice is to use a blackboard or whiteboard (or paper with pencil) that can be easily erased to develop the list of steps, and then write the list on the use-case form. It should be written on the use-case form only aft er the set of steps is fairly well defi ned.

19 Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. 20 C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston, MA: Addison-Wesley, 2004).

2. Create Overview Description

3. Describe the Normal Flow of Events

4. Check the Normal Flow of Events

148  C h a p t e r 4 Business Process and Functional Modeling

Th e fi fth step focuses on identifying and writing the alternative or exceptional fl ows. Alternative or exceptional fl ows are fl ows of success that represent optional or exceptional behavior. Th ey tend to occur infrequently or as a result of a normal fl ow failing. Th ey should be labeled so that there is no doubt as to which normal fl ow of events it is related. For example in Figure 4-13, alternative/exceptional fl ow S-1, 2a1 executes when step 2 of subfl ow S-1 fails (i.e., the requested appointment time was not available). Like the normal fl ows and subfl ows, alternative or exceptional fl ows should be written in the SVDPI form whenever possible.

Th e sixth step is to carefully review the use-case description and confi rm that the use case is correct as written, which means reviewing the use case with the users to make sure each step is correct.21 Th e review should look for opportunities to simplify a use case by decomposing it into a set of smaller use cases, merging it with others, looking for common aspects in both the semantics and syntax of the use cases, and identifying new use cases. Th is is also the time to look into adding the include, extend, and/or generalization relationships between use cases. Th e most powerful way to confi rm a use case is to ask the user to role-play, or execute the process using the written steps in the use case. Th e analyst hands the user pieces of paper labeled with the major inputs to the use case and has the user follow the written steps like a recipe to make sure that those steps really can produce the outputs defi ned for the use case using its inputs.

Th e seventh and fi nal step is to iterate the entire set of steps again. Users oft en change their minds about what is a use case and what it includes. It is very easy to get trapped in the details at this point, so remember that the goal is to just address the major use cases. Th erefore, the analyst should continue to iterate these steps until he or she and the users believe that a suffi cient number of use cases have been documented to begin identifying candidate classes for the structural model (see Chapter 5). As candidate classes are identifi ed, it is likely that additional use cases will be uncovered.

Campus Housing Example Th e fi rst step in documenting a use case with a use-case descrip- tion is to choose a use case. For instructional purposes, we use the same use case used earlier with the activity diagrams; the Maintain Available Rental Unit Information, which is associ- ated with the apartment owners. Th e next step is to create an Overview Description of the use case. In this case, the primary actor is the apartment owner. Given that the use-case descrip- tion documents the detailed logic steps for the use case, the type of use case is Detailed and Essential. Th e Stakeholders include the apartment owners and the campus housing service. Th eir respective interests are to advertise their available apartments and to provide a service that enables the apartment owners to rent their available apartments. Th e Brief Description for this use case is “Th is use case describes how the campus housing service can maintain an up-to-date listing of available apartments.” Th e trigger for the use case is when an apartment owner wants to add or delete an available apartment. As such, the trigger is “fi red” from outside of the system. In this case, the apartment owner’s action triggers this use case. Th ere is only one Association relationship between this use case and its Primary Actor: Apartment Owner. Figure 4-14 documents this information.

Next, we document and verify the logical steps necessary to successfully execute this use case. Th at is, we document the normal fl ow of events, check the normal fl ow of events (pos- sibly identifying subfl ows), identify any alternative or exceptional fl ows, and then carefully review the description to be sure that it is complete. If you recall, in this specifi c example, the apartment owners provided information to add a rental unit to the available rental units or provided information that identifi ed an available unit that was no longer available and needed

21 Th is process is related to role-playing, which is discussed in Chapter 5.

5. Identify Alternative or Exceptional Flows

6. Review the Use- Case Description

7. Repeat Until Done

Business Process Documentation with Use Cases and Use-Case Descriptions  149

to be deleted from the list of available rental units. Th ese two processes were treated as two subprocesses of the Maintain Available Rental Unit Information use case. Now that we have to determine which of these subprocesses is to be treated as the Normal Flow of Events and which is to be treated as an Alternative or Exceptional Flow. However, upon further refl ection, the question as to whether these should be separated into two independent use cases or whether they should remained together should be investigated. Th is is a great example where moving from one representation (activity diagram) to another representation (use case description) in an iterative and incremental manner raises issues that were not readily apparent. In this example, it is probably better to replace the Maintain Available Rental Unit Information use case with two simpler use cases: one for adding a rental unit and one for deleting a rental unit. Consequently, we now have to change the use-case diagram (see Figure 4-15) and create two activity diagrams to replace the earlier ones (see Figure 4-16). And, we must create two use- case descriptions to replace the one that we just begun (see Figures 4-17 and 4-18). We will return to this example in the next chapter when we begin to create a structural model for the campus housing service. However, next we return to the university library problem.

Use Case Name:

Primary Actor:

Stakeholders and Interests:

Brief Description:

ID: Importance Level:

Trigger:

Type: External

Maintain Available Rental Unit Information 1 High

Apartment Owner

Apartment Owner—wants to advertise available apartment Campus Housing Service—provides a service that enables the apartment owners to rent their available apartments

Use Case Type: Detail, Essential

Apartment Owner wants to add or delete an available apartment

Apartment Owner

This use case describes how the campus housing service can maintain an up-to-date listing of available apartments.

Relationships: Association: Include: Extend: Generalization:

Campus Housing System

Apartment Owner

Add Apartment

Delete Apartment

* * *

* *

* Student

Search Available Rental Units

FIGURE 4-14  Campus Housing Maintain Available Rental Unit Information Overview Use-Case Description

FIGURE 4-15 Campus Housing Use-Case Diagram

150  C h a p t e r 4 Business Process and Functional Modeling

Capture Location

Capture Number of Bedrooms

Capture Monthly Rent

Add Apartment

Capture Apartment Identifier

Delete Apartment

FIGURE 4-16 Campus Add and Delete Apartment Activity Diagrams

Use Case Name:

Primary Actor:

Stakeholders and Interests:

Brief Description:

ID: Importance Level:

Trigger:

Normal Flow of Events:

SubFlows:

Alternate/Exceptional Flows:

Type: External

Add Apartment 1 High

Apartment Owner

Apartment Owner—wants to advertise available apartment Campus Housing Service—provides a service that enables the apartment owners to rent their available apartments

Use Case Type: Detail, Essential

Apartment Owner wants to add an available apartment

Apartment Owner

1. Capture the location of the apartment. 2. Capture the number of bedrooms in the apartment. 3. Capture the monthly rent of the apartment. 4. Add the apartment to the listing of available apartments.

This use case describes how the campus housing service can maintain an up-to-date listing of available apartments.

Relationships: Association: Include: Extend: Generalization:

FIGURE 4-17  Campus Housing Service Add an Apartment Use-Case Description

Business Process Documentation with Use Cases and Use-Case Descriptions  151

FIGURE 4-18  Campus Housing Service Delete an Apartment Use-Case Description

Use Case Name:

Primary Actor:

Stakeholders and Interests:

Brief Description:

ID: Importance Level:

Trigger:

Normal Flow of Events:

SubFlows:

Alternate/Exceptional Flows:

Type: External

Delete Apartment 2 High

Apartment Owner

Apartment Owner—wants to delist apartment Campus Housing Service—provides a service that enables the apartment owners to rent their available apartments

Use Case Type: Detail, Essential

Apartment Owner wants to delete an available apartment

Apartment Owner

1. Capture the apartment identifier. 2. Delete the apartment from the listing of available apartments.

This use case describes how the campus housing service can maintain an up-to-date listing of available apartments.

Relationships: Association: Include: Extend: Generalization:

Library Example As with the Campus Housing example, the first step to document busi- ness processes with use-case descriptions is to choose a use case. Because we previously chose the Borrow Books use case in the Library Collection Management System example, we will stay with it. Next, we need to create the overview description. In this case, we have to go back and look at the use case diagram (see Figure 4-6) that describes the external behavior of the Library Collection Management System and the activity diagram (see Fig- ure 4-12) that describes the functionality of the Borrow Books use case. It also is a good idea to refer back, once again, to the functional requirements that drove the creation of the Borrow Books use case. Here they are:

Th e borrowing activities are built around checking books out and returning books by borrowers. Th ere are three types of borrowers: students, faculty or staff , and guests. Regardless of the type of borrower, the borrower must have a valid ID card. If the borrower is a student, having the system check with the registrar’s student database validates the ID card. If the borrower is a faculty or staff member, having the system check with the personnel offi ce’s employee database validates the ID card. If the bor- rower is a guest, the ID card is checked against the library’s own borrower database. If the ID card is valid, the system must also check to determine whether the borrower has any overdue books or unpaid fi nes. If the ID card is invalid, the borrower has overdue books, or the borrower has unpaid fi nes, the system must reject the borrow- er’s request to check out a book, otherwise the borrower’s request should be honored.

Based on these three critical pieces of information and using the use-case description tem- plate (see Figure 4-13), we can create the overview description of the Borrow Books use case (see Figure 4-19).

152  C h a p t e r 4 Business Process and Functional Modeling

By carefully reviewing the functional requirements (above) and the activity diagram (Figure 4-12), we can easily identify the Normal Flow of Events for the Borrow Books use case. Furthermore, it is possible to decide whether any of the events contained in the Normal Flow of Events list should be decomposed using Subfl ows or other use cases that would need to be included. In the latter case, we would have to modify the Relationships section of the overview description and modify the use-case diagram to refl ect this addition. Also, based on the logic structure of the activity diagram, it is possible to identify the alternative exceptional fl ows to the normal fl ow of events for the Borrow Books use case. Based on the overall simplicity of the Borrow Books use case, we decided not to decompose the process using either subfl ows or included use cases. However, due to the logic structure laid out in the activity diagram, there were two alternate/exceptional fl ows identifi ed. Figure 4-20 depicts the Normal Flow of Events, Subfl ows, and Alternative/Exceptional Flows sections of the Borrow Books use-case description.

Association: Borrower, Personnel Office, Registrar’s Office Include:

Extend: Generalization:

Use Case Name:

Primary Actor:

Stakeholders and Interests:

Brief Description:

Trigger:

Type: External

Use Case Type:

Relationships:

Borrow Books ID: 2 Importance Level: High

Borrower

Borrower brings books to check out desk.

Detail, Essential

This use case describes how books are checked out of the library.

Borrower—wants to check outbooks Librarian—wants to ensure borrower only gets books deserved

FIGURE 4-19  Overview Description for the Borrow Books Use Case

FIGURE 4-20  Flow Descriptions for the Borrow Books Use Case

Normal Flow of Events:

SubFlows:

1. The Borrower brings books to the Librarian at the check out desk. 2. The Borrower provides Librarian their ID card. 3. The Librarian checks the validity of the ID Card. If the Borrower is a Student Borrower, Validate ID Card against Registrar's Database. If the Borrower is a Faculty/Staff Borrower, Validate ID Card against Personnel Database. If the Borrower is a Guest Borrower, Validate ID Card against Library's Guest Database. 4. The Librarian checks whether the Borrower has any overdue books and/or fines 5. The Borrower checks out the books

Alternate/Exceptional Flows: 4a The ID Card is invalid, the book request is rejected. 5a The Borrower either has overdue books, fines, or both, the book request is rejected.

Verifying and Validating the Business Processes and Functional Models  153

VERIFYING AND VALIDATING THE BUSINESS PROCESSES AND FUNCTIONAL MODELS22

Before we move on to structural (Chapter 5) and behavioral (Chapter 6) modeling, we need to verify and validate the current set of functional models to ensure that they faithfully represent the business processes under consideration. Th is includes testing the fi delity of each model; for example, we must be sure that the activity diagram(s), use-case descriptions, and use-case diagrams all describe the same functional requirements. Before we describe the specifi c tests to consider, we describe walkthroughs, a manual approach that supports verifying and vali- dating the evolving models.23

Verifi cation and Validation through Walkthroughs A walkthrough is essentially a peer review of a product. In the case of the functional models, a walkthrough is a review of the diff erent models and diagrams created during functional modeling. Th is review typically is completed by a team whose members come from the development team and the client. Th e purpose of a walkthrough is to thoroughly test the fi delity of the functional models to the functional requirements and to ensure that the models are consistent. Th at is, a walkthrough uncovers errors or faults in the evolving specifi cation. However, a walkthrough does not correct errors—it simply identifi es them. Error correction is to be accomplished by the team aft er the walkthrough is completed.

Walkthroughs are very interactive. As the presenter walks through the representation, members of the walkthrough team should ask questions regarding the representation. For example, if the presenter is walking through an activity diagram, another member of the team could ask why certain activities or objects were not included. Th e actual process of simply presenting the representation to a new set of eyes can uncover obvious misunderstandings and omissions. In many cases, the representation creator can get lost in the proverbial trees and not see the forest.24 In fact, many times the act of walking through the representation causes a presenter to see the error himself or herself. For psychological reasons, hearing the representation helps the analyst to see the representation more completely.25 Th erefore, the representation creators should regularly do a walkthrough of the models themselves by read- ing the representations out loud to themselves, regardless of how they think it might make them look.

Th ere are specifi ed roles that diff erent members of the walkthrough team can play. Th e fi rst is the presenter role. Th is should be played by the person who is primarily responsible for the specifi c representation being reviewed. Th is individual presents the representation to the walkthrough team. Th e second role is recorder, or scribe. Th e recorder should be a member of the analysis team. Th is individual carefully takes the minutes of the meeting by recording all signifi cant events that occur during the walkthrough. In particular, all errors that are uncovered must be documented so that the analysis team can address them. Another important role is to have someone who raises issues regarding maintenance of

22 Th e material in this section has been adapted from E. Yourdon, Modern Structured Analysis (Englewood Cliff s, NJ: Prentice Hall, 1989). Verifying and validating are types of testing. 23 Even though many modern CASE tools can automate much of the verifying and validating of the analysis models, we feel that it is paramount that systems analysts understand the principles of verifi cation and validation. Furthermore, some tools, such as Visio, that support UML diagramming are only diagramming tools. Regardless, the analyst is expected to perform all diagramming correctly. 24 In fact, all joking aside, in many cases the developer is down at the knothole level and can’t even see the tree, let alone the forest. 25 Th is has to do with using diff erent senses. Because our haptic senses are the most sensitive, touching the representa- tion would be best. However, it is not clear how one can touch a use case or a class.

154  C h a p t e r 4 Business Process and Functional Modeling

the representation. Yourdon refers to this individual as a maintenance oracle.26 Owing to the emphasis on reusability in object-oriented development, this role becomes particularly crucial. Finally, someone must be responsible for calling, setting up, and running the walk- through meetings.

For a walkthrough to be successful, the members of the walkthrough team must be fully prepared. All materials to be reviewed must be distributed with suffi cient time for the team members to review them before the actual meeting. All team members should be expected to mark up the representations so that during the walkthrough meeting, all relevant issues can be discussed. Otherwise, the walkthrough will be ineffi cient and ineff ective. During the actual meeting, as the presenter is walking through the representation, the team members should point out any potential errors or misunderstandings. In many cases, the errors and misunderstandings are caused by invalid assumptions that would not be uncovered without the walkthrough.

One potential danger of walkthroughs is when management decides the results of uncovering errors in the representation are a refl ection of an analyst’s capability. Th is must be avoided at all costs. Otherwise, the underlying purpose of the walkthrough—to improve the fi delity of the representation—will be thwarted. Depending on the organization, it may be necessary to omit management from the walkthrough process. If not, the walkthrough process could break down into a slugfest to make some team members to look good by destroying the presenter. To say the least, this is obviously counterproductive.

Functional Model Verifi cation and Validation We have suggested three different representations for the functional model: activity dia- grams, use-case descriptions, and use-case diagrams. In this section, we describe a set of rules to ensure that these three representations are consistent among themselves.

First, when comparing an activity diagram to a use-case description, there should be at least one event recorded in the normal fl ow of events, subfl ows, or alternative/exceptional fl ows of the use-case description for each activity or action that is included on an activity dia- gram, and each event should be associated with an activity or action. For example, in Figure 4-4, there is an activity labeled Get Patient Information that is associated with the fi rst two events contained in the normal fl ow of events of the use-case description shown in Figure 4-13.

Second, all objects portrayed as an object node in an activity diagram must be mentioned in an event in the normal fl ow of events, subfl ows, or alternative/exceptional fl ows of the use-case description. For example, the activity diagram in Figure 4-4 portrays an Appt object, and the use- case description refers to a new appointment and changing or canceling an existing appointment.

Th ird, sequential order of the events in a use-case description should occur in the same sequential order of the activities contained in an activity diagram. For example in Figures 4-4 and 4-13, the events associated with the Get Patient Information activity (events 1 and 2) should occur before the events associated with the Make Payment Arrangements activity (event 4).

Fourth, when comparing a use-case description to a use-case diagram, there must be one and only one use-case description for each use case, and vice versa. For example, Figure 4-13 portrays the use-case description of the Make Old Patient Appt use case. However,  the use-case diagram shown in Figure 4-4, the activity diagram shown in Figure 4-8, and the use- case description given in Figure 4-13 are inconsistent with each other. In this case, the use-case diagram implies that the Make Payment Arrangements use case is optional regardless of whether the patient is a new or old patient. However, when we review the activity diagram, we see that it is an optional activity for old patients, but a required activity for a new patient. Th erefore, only one of the diagrams is correct. In this instance, the use-case diagram needs to be corrected. Th e new corrected use-case diagram is shown in Figure 4-21.

26 See Appendix D of Yourdon, Modern Structured Analysis.

Verifying and Validating the Business Processes and Functional Models  155

Fift h, all actors listed in a use-case description must be portrayed on the use-case dia- gram. Each actor must have an association link that connects it to the use case and must be listed with the association relationships in the use-case description. For example, the Old Patient actor is listed in the use-case description of the Make Old Patient Appt use case (see Figure 4-13), it is listed with the association relationships in the Make Old Patient Appt use- case description, and it is connected to the use case in the use-case diagram (see Figure 4-21).

Sixth, in some organizations, we should also include the stakeholders listed in the use- case description as actors in the use-case diagram. For example, there could have been an association between the Doctor actor and the Make Old Patient Appt use case (see Figures 4-13 and 4-21). However, in this case it was decided not to include this association because the Doctor never participates in the Make Old Patient Appt use case.27

Appointment System

Patient

New Patient

Old Patient

Produce Schedules

Update Patient Information

Make Old Patient Appt

Make New Patient Appt

Make Payment Arrangements

Create New Patient

Manage Appointments

Management

Doctor

Record Availability Manage

Schedule

<< ex

te nd

>>

< < ex

te nd

> >

< <

in cl

ud e>

>

<<include>>

<<include>>

*

*

*

*

**

* *

< < include>

>

FIGURE 4-21  Modifi ed Use-Case Diagram for the Appointment System

27 Another possibility could have been to include a Receptionist actor. However, we had previously decided that the Receptionist was in fact part of the Appointment System and not simply a user of the system. If UML supported the idea of internal actors, or actor-to-actor associations, this implicit association could easily be made explicit by having the Patient actor communicate with the Receptionist actor directly, regardless of whether the Receptionist actor was part of the system or not. See footnote 4.

156  C h a p t e r 4 Business Process and Functional Modeling

Seventh, all other relationships listed in a use-case description (include, extend, and generalization) must be portrayed on a use-case diagram. For example, in Figure 4-13, there is an extend relationship listed with the Update Patient Information use case, and in Figure 4-21, we see that it appears on the diagram between the two use cases.

Finally, there are many diagram-specifi c requirements that must be enforced. For exam- ple, in an activity diagram a decision node can be connected to activity or action nodes only with a control fl ow, and for every decision node there should be a matching merge node. Every type of node and fl ow has diff erent restrictions. However, the complete restrictions for all the UML diagrams are beyond the scope of this text.28 Th e concept map in Figure 4-22 portrays the associations among the functional models.

28 A good reference for these types of restrictions is S.W. Ambler, Th e Elements of UML 2.0 Style (Cambridge, UK: Cambridge University Press, 2005).

Use Cases

Scenarios

Activity Diagram

Object Nodes

Object Flows

Activities/Actions

Stakeholders

Relationships

Control Flows

Events

Actors

Flows

Including

Contains

HasKinds

Contains

Contains

Have

AssociatedWith AssociatedWith

AssociatedWith

AssociatedWith

AssociatedWith

AssociatedWith

AssociatedWith

Use-Case Diagram

Functional Models

Use-Case Descriptions

FIGURE 4-22  Interrelationships among Functional Models

Key Terms  157

KEY TERMS

Action Activity Activity diagram Actor Alternative fl ows Association relationship Black-hole activities Brief description Control fl ow Control node Decision node Detail use case

Errors Essential use case Exceptional fl ows Extend relationship External trigger Faults Final-activity node Final-fl ow node Flow of events Fork node Functional decomposition Generalization relationship

Guard condition Importance level Include relationship Inheritance Initial node Iterate Join node Logical model Maintenance oracle Merge node Miracle activity Normal fl ow of events

Object fl ow Object node Overview use cases Packages Physical model Presenter Primary actor Process models Real use case Recorder Relationships Role

APPLYING THE CONCEPTS AT PATTERSON SUPERSTORE In this chapter, you learned about business processes and functional models. Object- oriented systems are developed in an incremental and iterative manner. Th is is especially true when the phased approach is used as in the Patterson Superstore case. Th e team fi rst developed a use-case diagram for the entire Integrated Health Clinic Delivery System. Next, the team moved into modeling the processes of Version 1 of the system by creating an activity diagram and use-case description for Schedule Appointment. You will also see these models revisited and developed in further iterations as more information is uncovered. Th e three versions of the Integrated Health Clinic Delivery System will each go through individual process and functional modeling as well as structural and behavior modeling with iteration across all of these tasks.

You can fi nd the rest of the case at: www.wiley.com/go/dennis/casestudy

CHAPTER REVIEW Aft er reading and studying this chapter, you should be able to:

Explain the purpose of a use case in business process and functional modeling. Describe the diff erent elements of a use-case diagram. Create use-case diagrams that portray how business information systems interact with their environment. Explain how to model a specifi c use case with an activity diagram. Describe the diff erent elements of an activity diagram. Create an activity diagram that represents a specifi c use case. Document a business process with a use-case description. Describe the diff erent types of use cases. Describe the diff erent elements of a use-case description. Create a use-case description that represents a specifi c use case. Verify and validate the evolving functional model using walkthroughs. Verify and validate the functional model by ensuring the consistency of the three functional representations: use-

case diagrams, activity diagrams, and use-case descriptions.

158  C h a p t e r 4 Business Process and Functional Modeling

Scenario Scribe Specialized actor Stakeholders Subfl ows

Subject boundary SVDPI Swim lanes Temporal trigger Test

Trigger Use case Use-case description Use-case diagram Use-case ID number

Use-case name Use-case type Validation Verifi cation Walkthrough

QUESTIONS

1. Why is business process modeling important? 2. How do you create use cases? 3. Why do we strive to have about three to nine major

use cases in a business process? 4. How do you create use-case diagrams? 5. How is use-case diagramming related to functional

modeling? 6. Explain the following terms: actor, use case, system

boundary, relationship. Use layperson’s language, as though you were describing them to a user.

7. Every association must be connected to at least one _______ and one _________. Why?

8. What are some heuristics for creating a use-case diagram? 9. Why is iteration important in creating use cases? 10. What is the purpose of an activity diagram? 11. What is the diff erence between an activity and an

action? 12. What is the purpose of a fork node? 13. What are the diff erent types of control nodes? 14. What is the diff erence between a control fl ow and an

object fl ow? 15. What is an object node? 16. Explain how a detail use case diff ers from an overview

use case. When are each used? 17. How does an essential use case diff er from a real use case?

18. What are the major elements of an overview use case? 19. What are the major elements of a detail use case? 20. What is the viewpoint of a use case, and why is it

important? 21. What are some guidelines for designing a set of use

cases? Give two examples of the extend associations on a use-case diagram. Give two examples for the include associations.

22. Which of the following could be an actor found on a use-case diagram? Why?

Ms. Mary Smith Supplier Customer Internet customer Mr. John Seals Data entry clerk Database administrator

23. What is CRUD? Why is it useful? 24. What is a walkthrough? How does it relate to verifi ca-

tion and validation? 25. What are the diff erent roles played during a walk-

through? What are their purposes? 26. How are the diff erent functional models related, and

how does this aff ect the verifi cation and validation of the models?

EXERCISES

A. Investigate the UML website at the Object Manage- ment Group (www.uml.org). Write a paragraph news brief on the current state of UML (e.g., the cur- rent version and when it will be released, future improvements).

B. Investigate the Object Management Group. Write a brief memo describing what it is, its purpose, and its infl uence on UML and the object approach to systems development. (Hint: A good resource is www.omg.org.)

C. Draw a use-case diagram and a set of activity dia- grams for the process of buying glasses from the viewpoint of the patient. Th e fi rst step is to see an eye doctor who will give you a prescription. Once you have a prescription, you go to an optical dispensary, where you select your frames and place the order for your glasses. Once the glasses have been made, you return to the store for a fi tting and pay for the glasses.

D. Create a set of detailed use-case descriptions for the process of buying glasses in exercise C.

Exercises  159

E. Draw a use-case diagram and a set of activity dia- grams for the following doctor’s offi ce system. When- ever new patients are seen for the fi rst time, they complete a patient information form that asks their name, address, phone number, and brief medical history, which are stored in the patient information fi le. When a patient calls to schedule a new appoint- ment or change an existing appointment, the recep- tionist checks the appointment fi le for an available time. Once a good time is found for the patient, the appointment is scheduled. If the patient is a new patient, an incomplete entry is made in the patient’s fi le; the full information will be collected when the patient arrives for the appointment. Because appoint- ments are oft en made far in advance, the receptionist usually mails a reminder postcard to each patient two weeks before the appointment.

F. Create a set of detail use-case descriptions for the dentist’s offi ce system in exercise E.

G. Draw a use-case diagram and a set of activity dia- grams for an online university registration system. Th e system should enable the staff of each academic department to examine the courses off ered by their department, add and remove courses, and change the information about them (e.g., the maximum number of students permitted). It should permit students to examine currently available courses, add and drop courses to and from their schedules, and examine the courses for which they are enrolled. Department staff should be able to print a variety of reports about the courses and the students enrolled in them. Th e system should ensure that no student takes too many courses and that students who have any unpaid fees are not permitted to register (assume that fees data are main- tained by the university’s fi nancial offi ce, which the registration system accesses but does not change).

H. Create a set of detailed use-case descriptions for the online university registration system in exercise G.

I. Draw a use-case diagram and a set of activity dia- grams for the following system. A Real Estate Inc. (AREI) sells houses. People who want to sell their houses sign a contract with AREI and provide infor- mation on their house. Th is information is kept in a database by AREI, and a subset of this information is sent to the citywide multiple-listing service used by all real estate agents. AREI works with two types of potential buyers. Some buyers have an interest in one specifi c house. In this case, AREI prints information from its database, which the real estate agent uses to

help show the house to the buyer (a process beyond the scope of the system to be modeled). Other buyers seek AREI’s advice in fi nding a house that meets their needs. In this case, the buyer completes a buyer infor- mation form that is entered into a buyer database, and AREI real estate agents use its information to search AREI’s database and the multiple-listing service for houses that meet their needs. Th e results of these searches are printed and used to help the real estate agent show houses to the buyer.

J. Create a set of detailed use-case descriptions for the real estate system in exercise I.

K. Perform a verifi cation and validation walkthrough of the functional models of the real estate system described in exercises I and J.

L. Draw a use-case diagram and a set of activity dia- grams for the following system. A Video Store (AVS) runs a series of fairly standard video stores. Before a video can be put on the shelf, it must be cataloged and entered into the video database. Every customer must have a valid AVS customer card in order to rent a video. Customers rent videos for three days at a time. Every time a customer rents a video, the system must ensure that he or she does not have any overdue videos. If so, the overdue videos must be returned and an overdue fee paid before customer can rent more videos. Likewise, if the customer has returned overdue videos but has not paid the overdue fee, the fee must be paid before new videos can be rented. Every morn- ing, the store manager prints a report that lists over- due videos. If a video is two or more days overdue, the manager calls the customer to remind him or her to return the video. If a video is returned in damaged condition, the manager removes it from the video database and may sometimes charge the customer.

M. Create a set of detailed use-case descriptions for the video system in exercise L.

N. Perform a verifi cation and validation walkthrough of the functional models of the video store system described in exercises L and M.

O. Draw a use-case diagram and a set of activity dia- grams for a gym membership system. When mem- bers join the gym, they pay a fee for a certain length of time. Most memberships are for one year, but memberships as short as two months are available. Th roughout the year, the gym off ers a variety of discounts on their regular membership prices (e.g., two memberships for the price of one for Valentine’s day). It is common for members to pay diff erent

160  C h a p t e r 4 Business Process and Functional Modeling

amounts for the same length of membership. Th e gym wants to mail out reminder letters to members asking them to renew their memberships one month before their memberships expire. Some members have become angry when asked to renew at a much higher rate than their original membership contract, so the club wants to track the prices paid so that the manager can override the regular prices with spe- cial prices when members are asked to renew. Th e system must track these new prices so that renewals can be processed accurately. One of the problems in the industry is the high turnover rate of members. Although some members remain active for many years, about half of the members do not renew their memberships. Th is is a major problem, because the gym spends a lot in advertising to attract each new member. Th e manager wants the system to track each time a member comes into the gym. Th e system will then identify the heavy users and generate a report so that the manager can ask them to renew their mem- berships early, perhaps off ering them a reduced rate for early renewal. Likewise, the system should identify members who have not visited the gym in more than a month, so the manager can call them and attempt to reinterest them in the gym.

P. Create a set of detailed use-case descriptions for the system in exercise O.

Q. Perform a verifi cation and validation walkthrough of the functional models of the gym membership system described in exercises O and P.

R. Draw a use-case diagram and a set of activity dia- grams for the following system. Picnics R Us (PRU) is a small catering fi rm with fi ve employees. During a typical summer weekend, PRU caters fi ft een pic- nics with twenty to fi ft y people each. Th e business has grown rapidly over the past year, and the owner wants to install a new computer system for man- aging the ordering and buying process. PRU has a set of ten standard menus. When potential cus- tomers call, the receptionist describes the menus to them. If the customer decides to book a picnic, the receptionist records the customer information (e.g., name, address, phone number) and the information about the picnic (e.g., place, date, time, which one of the standard menus, total price) on a contract. Th e customer is then faxed a copy of the contract and must sign and return it along with a deposit (oft en a credit card or by debit card) before the picnic is offi cially booked. Th e remaining money is collected when the picnic is delivered. Sometimes, the cus-

tomer wants something special (e.g., birthday cake). In this case, the receptionist takes the information and gives it to  the owner, who determines the cost; the receptionist then calls the customer back with the price information. Sometimes the customer accepts the price; other times, the customer requests some changes that have to go back to the owner for a new cost estimate. Each week, the owner looks through the picnics scheduled for that weekend and orders the supplies (e.g., plates) and food (e.g., bread, chicken) needed to make them. Th e owner would like to use the system for marketing as well. It should be able to track how customers learned about PRU and identify repeat customers, so that PRU can mail special off ers to them. Th e owner also wants to track the picnics for which PRU sent a contract, but the customer never signed the contract and actually booked a picnic.

S. Create a set of detailed use-case descriptions for the system in exercise R.

T. Perform a verifi cation and validation walkthrough of the functional models of the catering system described in exercises R and S.

U. Draw a use-case diagram and a set of activity dia- grams for the following system. Of-the-Month Club (OTMC) is an innovative young fi rm that sells memberships to people who have an interest in certain products. People pay membership fees for one year and each month receive a product by mail. For example, OTMC has a coff ee-of-the-month club that sends members one pound of special coff ee each month. OTMC currently has six memberships (coff ee, wine, beer, cigars, fl owers, and computer games), each of which costs a diff erent amount. Cus- tomers usually belong to just one, but some belong to two or more. When people join OTMC, the tele- phone operator records the name, mailing address, phone number, e-mail address, credit-card infor- mation, start date, and membership service(s) (e.g., coff ee). Some customers request a double or triple membership (e.g., two pounds of coff ee, three cases of beer). Th e computer game membership operates a bit diff erently from the others. In this case, the member must also select the type of game (action, arcade, fantasy/science fi ction, educational, etc.) and age level. OTMC is planning to greatly expand the number of memberships it off ers (e.g., video games, movies, toys, cheese, fruit, and vegetables), so the system needs to accommodate this future expansion. OTMC is also planning to off er three-month and six-month memberships.

Minicases  161

V. Create a set of detailed use-case descriptions for the system in exercise U.

W. Perform a verifi cation and validation walkthrough of

the functional models of the Of-the-Month Club sys- tem described in exercises U and V.

MINICASES

1. Williams Specialty Company is a small printing and engraving organization. When Pat Williams, the owner, brought computers into the business offi ce fi ve years ago, the business was very small and very simple. Pat was able to use an inexpensive PC-based account- ing system to handle the basic information-processing needs of the fi rm. As time has gone on, however, the business has grown and the work being performed has become signifi cantly more complex. Th e simple accounting soft ware still in use is no longer adequate to keep track of many of the company’s sophisticated deals and arrangements with its customers.

Pat has a staff of four people in the business offi ce who are familiar with the intricacies of the company’s record-keeping requirements. Pat recently met with her staff to discuss her plan to hire an IS consulting fi rm to evaluate the organization’s information sys- tem needs and recommend a strategy for upgrading its computer system. Th e staff are excited about the prospect of a new system, because the current system causes them much annoyance. No one on the staff has ever done anything like this before, however, and they are a little wary of the consultants who will be con- ducting the project.

Assume that you are a systems analyst on the con- sulting team assigned to the Williams Specialty Co. engagement. At your fi rst meeting with the Williams staff , you want to be sure that they understand the work that your team will be performing and how they will participate in that work.

a. Explain, in clear, nontechnical terms, the goals of the analysis of the project.

b. Explain, in clear, nontechnical terms, how func- tional models will be used by the project team to model the identifi ed business processes. Explain what these models are, what they represent in the system, and how they will be used by the team.

2. Professional and Scientifi c Staff Management (PSSM) is a unique type of temporary staffi ng agency. Many organizations today hire highly skilled technical employees on a short-term, temporary basis to assist with special projects or to provide a needed technical skill. PSSM negotiates contracts with its client com-

panies in which it agrees to provide temporary staff in specifi c job categories for a specifi ed cost. For exam- ple, PSSM has a contract with an oil and gas explora- tion company in which it agrees to supply geologists with at least a master’s degree for $5,000 per week. PSSM has contracts with a wide range of companies and can place almost any type of professional or sci- entifi c staff members, from computer programmers to geologists to astrophysicists.

When a PSSM client company determines that it will need a temporary professional or scientifi c employee, it issues a staffi ng request against the con- tract it had previously negotiated with PSSM. When PSSM’s contract manager receives a staffi ng request, the contract number referenced on the staffi ng request is entered into the contract database. Using informa- tion from the database, the contract manager reviews the terms and conditions of the contract and deter- mines whether the staffi ng request is valid. Th e staff - ing request is valid if the contract has not expired, the type of professional or scientifi c employee requested is listed on the original contract, and the requested fee falls within the negotiated fee range. If the staffi ng request is not valid, the contract manager sends the staffi ng request back to the client with a letter stating why the staffi ng request cannot be fi lled, and a copy of the letter is fi led. If the staffi ng request is valid, the contract manager enters the staffi ng request into the staffi ng request database as an outstanding staffi ng request. Th e staffi ng request is then sent to the PSSM placement department.

In the placement department, the type of staff member, experience, and qualifi cations requested on the staffi ng request are checked against the data- base of available professional and scientifi c staff . If a qualifi ed individual is found, he or she is marked “reserved” in the staff database. If a qualifi ed individ- ual cannot be found in the database or is not imme- diately available, the placement department creates a memo that explains the inability to meet the staffi ng request and attaches it to the staffi ng request. All staffi ng requests are then sent to the arrangements department.

162  C h a p t e r 4 Business Process and Functional Modeling

In the arrangements department, the prospective temporary employee is contacted and asked to agree to the placement. Aft er the placement details have been worked out and agreed to, the staff member is marked “placed” in the staff database. A copy of the staffi ng request and a bill for the placement fee is sent to the client. Finally, the staffi ng request, the “unable-to-fi ll” memo (if any), and a copy of the placement fee bill are sent to the contract manager. If the staffi ng request was fi lled, the contract manager closes the open staff - ing request in the staffi ng request database. If the

staffi ng request could not be fi lled, the client is notifi ed. Th e staffi ng request, placement fee bill, and unable-to- fi ll memo are then fi led in the contract offi ce.

a. Create a use-case diagram for the system described here.

b. Create a set of activity diagrams for the business processes described here.

c. For each major use case identifi ed in the use-case diagram, develop both an overview and a detail use-case description.

d. Verify and validate the functional models.

163163

A structural, or conceptual, model describes the structure of the objects that support the business processes in an organization. During analysis, the structural model presents the logical organization of the objects without indicating how they are stored, created, or manipulated so that analysts can focus on the business, without being distracted by tech- nical details. Later during design, the structural model is updated to refl ect exactly how the objects will be stored in databases and fi les. Th is chapter describes class–responsibility– collaboration (CRC) cards, class diagrams, and object diagrams, which are used to create the structural model.

OBJECTIVES

■ Understand the rules and style guidelines for creating CRC cards, class diagrams, and object diagrams.

■ Understand the processes used to create CRC cards, class diagrams, and object diagrams. ■ Be able to create CRC cards, class diagrams, and object diagrams. ■ Understand the relationship among the structural models. ■ Understand the relationship between the structural and functional models.

INTRODUCTION During analysis, analysts create business process and functional models to represent how the business system will behave. At the same time, analysts need to understand the information that is used and created by the business system (e.g., customer information, order informa- tion). In this chapter, we discuss how the objects underlying the behavior modeled in the business process and functional models are organized and presented.

As pointed out in Chapter 1, all object-oriented systems development approaches are use-case driven, architecture-centric, and iterative and incremental. Use cases, described in Chapter 4, form the foundation on which the business information system is created. From an architecture-centric perspective, structural modeling supports the creation of an internal structural or static view of a business information system in that it shows how the system is structured to support the underlying business processes. Finally, as with business process and functional modeling, you will fi nd that you will need to not only iterate across the structural models (described in this chapter), but you will also have to iterate across all three architec- tural views (functional, structural, and behavioral) to fully capture and represent the require- ments for a business information system.

A structural model is a formal way of representing the objects that are used and created by a business system. It illustrates people, places, or things about which information is captured and how they are related to one another. Th e structural model is drawn using an iterative process in which the model becomes more detailed and less conceptual over time. In analysis, analysts draw a conceptual model, which shows the logical organization of the objects without

C H A P T E R 5

Structural Modeling

1 6 4 C h a p t e r 5   Structural Modeling

indicating how the objects are stored, created, or manipulated. Because this model is free from any implementation or technical details, the analysts can focus more easily on matching the model to the real business requirements of the system.

In design, analysts evolve the conceptual structural model into a design model that refl ects how the objects will be organized in databases and soft ware. At this point, the model is checked for redundancy, and the analysts investigate ways to make the objects easy to retrieve. Th e specifi cs of the design model are discussed in detail in the design chapters.

STRUCTURAL MODELS Every time a systems analyst encounters a new problem to solve, the analyst must learn the underlying problem domain. Th e goal of the analyst is to discover the key objects contained in the problem domain and to build a structural model. Object-oriented modeling allows the analyst to reduce the semantic gap between the underlying problem domain and the evolving structural model. However, the real world and the world of soft ware are very diff erent. Th e real world tends to be messy, whereas the world of soft ware must be neat and logical. Th us, an exact mapping between the structural model and the problem domain may not be possible. In fact, it might not even be desirable.

One of the primary purposes of the structural model is to create a vocabulary that can be used by the analyst and the users. Structural models represent the things, ideas, or concepts contained in the domain of the problem. Th ey also allow the representation of the relation- ships among the things, ideas, or concepts. By creating a structural model of the problem domain, the analyst creates the vocabulary necessary for the analyst and users to communi- cate eff ectively.

It is important to remember that at this stage of development, the structural model does not represent soft ware components or classes in an object-oriented programming language, even though the structural model does contain analysis classes, attributes, operations, and the relation- ships among the analysis classes. Th e refi nement of these initial classes into programming-level objects comes later. Nonetheless, the structural model at this point should represent the respon- sibilities of each class and the collaborations among the classes. Typically, structural models are depicted using CRC cards, class diagrams, and, in some cases, object diagrams. However, before describing CRC cards, class diagrams, and object diagrams, we describe the basic elements of structural models: classes, attributes, operations, and relationships.

Classes, Attributes, and Operations A class is a general template that we use to create specifi c instances, or objects, in the problem domain. All objects of a given class are identical in structure and behavior but contain diff er- ent data in their attributes. Th ere are two general kinds of classes of interest during analysis: concrete and abstract. Normally, when an analyst describes the application domain classes, he or she is referring to concrete classes; that is, concrete classes are used to create objects. Abstract classes do not actually exist in the real world; they are simply useful abstractions. For example, from an employee class and a customer class, we may identify a generalization of the two classes and name the abstract class person. We might not actually instantiate the person class in the system itself, instead creating and using only employees and customers.1

1 Because abstract classes are essentially not necessary and are not instantiated, arguments have been made that it would be better not to include any of them in the description of the evolving system at this stage of development (see J. Evermann and Y. Wand, “Towards Ontologically Based Semantics for UML Constructs,” in H. S. Junii, S. Jajodia, and A. Solvberg (eds.) ER 2001, Lecture Notes in Computer Science 2224 (Berlin: Springer-Verlag, 2001): 354–367). However, because abstract classes traditionally have been included at this stage of development, we also include them.

Structural Models  165

A second classifi cation of classes is the type of real-world thing that a class repre- sents. Th ere are domain classes, user-interface classes, data structure classes, fi le structure classes, operating environment classes, document classes, and various types of multimedia classes. At this point in the development of our evolving system, we are interested only in domain classes. Later in design and implementation, the other types of classes become more relevant.

An attribute of an analysis class represents a piece of information that is relevant to the description of the class within the application domain of the problem being investigated. An attribute contains information the analyst or user feels the system should keep track of. For example, a possible relevant attribute of an employee class is employee name, whereas one that might not be as relevant is hair color. Both describe something about an employee, but hair color is probably not all that useful for most business applications. Only attributes that are important to the task should be included in the class. Finally, only attributes that are primitive or atomic types (i.e., integers, strings, doubles, date, time, Boolean, etc.) should be added. Most complex or compound attributes are really placeholders for relationships between classes. Th erefore, they should be modeled as relationships, not as attributes (see the next section).

Th e behavior of an analysis class is defi ned in an operation or service. In later phases, the operations are converted to methods. However, because methods are more related to imple- mentation, at this point in the development we use the term operation to describe the actions to which the instances of the class are capable of responding. Like attributes, only problem domain–specifi c operations that are relevant to the problem being investigated should be considered. For example, it is normally required that classes provide means of creating instances, deleting instances, accessing individual attribute values, setting individual attrib- ute values, accessing individual relationship values, and removing individual relationship values. However, at this point in the development of the evolving system, the analyst should avoid cluttering up the defi nition of the class with these basic types of operations and focus only on relevant problem domain–specifi c operations.

Relationships Th ere are many diff erent types of relationships that can be defi ned, but all can be classifi ed into three basic categories of data abstraction mechanisms: generalization relationships, aggregation relationships, and association relationships. Th ese data-abstraction mecha- nisms allow the analyst to focus on the important dimensions while ignoring nonessen- tial dimensions. As with attributes, the analyst must be careful to include only relevant relationships.

Generalization Relationships Th e generalization abstraction enables the analyst to create classes that inherit attributes and operations of other classes. Th e analyst creates a super- class that contains basic attributes and operations that will be used in several subclasses. Th e subclasses inherit the attributes and operations of their superclass and can also contain attributes and operations that are unique just to them. For example, a customer class and an employee class can be generalized into a person class by extracting the attributes and operations both have in common and placing them into the new superclass, person. In this way, the analyst can reduce the redundancy in the class defi nitions so that the common elements are defi ned once and then reused in the subclasses. Generalization is represented with the a-kind-of relationship, so that we say that an employee is a-kind-of person.

Th e analyst also can use the opposite of generalization. Specialization uncovers additional classes by allowing new subclasses to be created from an existing class. For example, an employee class can be specialized into a secretary class and an engineer class.

1 6 6 C h a p t e r 5   Structural Modeling

Furthermore, generalization relationships between classes can be combined to form gener- alization hierarchies. Based on the previous examples, a secretary class and an engineer class can be subclasses of an employee class, which in turn could be a subclass of a person class. Th is would be read as a secretary and an engineer are a-kind-of employee and a customer and an employee are a-kind-of person.

Th e generalization data abstraction is a very powerful mechanism that encourages the analyst to focus on the properties that make each class unique by allowing the similarities to be factored into superclasses. However, to ensure that the semantics of the subclasses are maintained, the analyst should apply the principle of substitutability. By this we mean that the subclass should be capable of substituting for the superclass anywhere that uses the super- class (e.g., anywhere we use the employee superclass, we could also logically use its secretary subclass). By focusing on the a-kind-of interpretation of the generalization relationship, the principle of substitutability is applied.

Aggregation Relationships Generally speaking, all aggregation relationships relate parts to wholes or assemblies. For our purposes, we use the a-part-of or has-parts semantic relationship to represent the aggregation abstraction. For example, a door is a-part-of a car, an employee is a-part-of a department, or a department is a-part-of an organization. Like the generalization relationship, aggregation relationships can be combined into aggregation hierarchies. For example, a piston is a-part-of an engine, and an engine is a-part-of a car.

Aggregation relationships are bidirectional. Th e fl ip side of aggregation is decomposition. Th e analyst can use decomposition to uncover parts of a class that should be modeled sepa- rately. For example, if a door and an engine are a-part-of a car, then a car has-parts door and engine. Th e analyst can bounce around between the various parts to uncover new parts. For example, the analyst can ask, What other parts are there to a car? or To which other assem- blies can a door belong?

Association Relationships Th ere are other types of relationships that do not fi t neatly into a generalization (a-kind-of) or aggregation (a-part-of) framework. Technically speaking, these relationships are usually a weaker form of the aggregation relationship. For example, a patient schedules an appointment. It could be argued that a patient is a-part-of an appoint- ment. However, there is a clear semantic diff erence between this type of relationship and one that models the relationship between doors and cars or even workers and unions. Th us, they are simply considered to be associations between instances of classes.

OBJECT IDENTIFICATION Diff erent approaches have been suggested to aid the analyst in identifying a set of candidate objects for the structural model. Th e four most common approaches are textual analysis, brainstorming, common object lists, and patterns. Most analysts use a combination of these techniques to make sure that no important objects and object attributes, operations, and relationships have been overlooked.

Textual Analysis Th e analyst performs textual analysis by reviewing the use-case diagrams and examining the text in the use-case descriptions to identify potential objects, attributes, operations, and relationships. Th e nouns in the use case suggest possible classes, and the verbs suggest pos- sible operations. Figure 5-1 presents a summary of useful guidelines. Th e textual analysis of

Object Identifi cation  167

use-case descriptions has been criticized as being too simple, but because its primary pur- pose is to create an initial rough-cut structural model, its simplicity is a major advantage. For example, if we applied these rules to the Make Old Patient Appt use case described in Chapter 4 and replicated in Figure 5-2, we can easily identify potential objects for an old patient, doctor, appointment, patient, offi ce, receptionist, name, address, patient informa- tion, payment, date, and time. We also can easily identify potential operations that can be associated with the identifi ed objects. For example, patient contacts offi ce, makes a new appointment, cancels an existing appointment, changes an existing appointment, matches requested appointment times and dates with requested times and dates, and fi nds current appointment.

Brainstorming Brainstorming is a discovery technique that has been used successfully in identifying candi- date classes. Essentially, in this context, brainstorming is a process that a set of individuals sitting around a table suggest potential classes that could be useful for the problem under consideration. Typically, a brainstorming session is kicked off by a facilitator who asks the set of individuals to address a specifi c question or statement that frames the session. For example, using the appointment problem described previously, the facilitator could ask the development team and users to think about their experiences of making appointments and to identify candidate classes based on their past experiences. Notice that this approach does not use the functional models developed earlier. It simply asks the participants to identify the objects with which they have interacted. For example, a potential set of objects that come to mind are doctors, nurses, receptionists, appointment, illness, treatment, prescrip- tions, insurance card, and medical records. Once a suffi cient number of candidate objects have been identifi ed, the participants should discuss and select which of the candidate objects should be considered further. Once these have been identifi ed, further brainstorm- ing can take place to identify potential attributes, operations, and relationships for each of the identifi ed objects.

Bellin and Simone2 have suggested a set of useful principles to guide a brainstorming session. First, all suggestions should be taken seriously. At this point in the development

• A common or improper noun implies a class of objects. • A proper noun or direct reference implies an instance of a class. • A collective noun implies a class of objects made up of groups of instances of another class. • An adjective implies an attribute of an object. • A doing verb implies an operation. • A being verb implies a classifi cation relationship between an object and its class. • A having verb implies an aggregation or association relationship. • A transitive verb implies an operation. • An intransitive verb implies an exception. • A predicate or descriptive verb phrase implies an operation. • An adverb implies an attribute of a relationship or an operation.

Adapted from: These guidelines are based on Russell J. Abbott, “Program Design by Informal English Descriptions,” Communications of the ACM 26, no. 11 (1983): 882–894; Peter P-S Chen, “English Sentence Structure and Entity-Relationship Diagrams,” Information Sciences: An International Journal 29, no. 2–3 (1983): 127–149; Ian Graham, Migrating to Object Technology (Reading, MA: Addison Wesley Longman, 1995).

FIGURE 5-1 Textual Analysis Guidelines

2 D. Bellin and S. S. Simone, Th e CRC Card Book (Reading, MA: Addison-Wesley, 1997).

1 6 8 C h a p t e r 5   Structural Modeling

FIGURE 5-2  Use-Case Description (Figure 4-13)

Use Case Name:

Primary Actor:

Stakeholders and Interests:

Brief Description:

ID: Importance Level:

Trigger:

Normal Flow of Events:

SubFlows:

Alternate/Exceptional Flows:

Type: External

Make Old Patient Appt 2 Low

Old Patient

Old Patient – wants to make, change, or cancel an appointment Doctor – wants to ensure patient’s needs are met in a timely manner

Use Case Type: Detail, Essential

Patient calls and asks for a new appointment or asks to cancel or change an existing appointment.

Old Patient

Update Patient Information Manage Appointments

1. The Patient contacts the office regarding an appointment. 2. The Patient provides the Receptionist with his or her name and address. 3. If the Patient’s information has changed Execute the Update Patient Information use case. 4. If the Patient’s payment arrangements has changed Execute the Make Payments Arrangements use case. 5. The Receptionist asks Patient if he or she would like to make a new appointment, cancel an existing appointment, or change an existing appointment.

S-1: New Appointment 1. The Receptionist asks the Patient for possible appointment times. 2. The Receptionist matches the Patient’s desired appointment times with available dates and times and schedules the new appointment.

S-2: Cancel Appointment 1. The Receptionist asks the Patient for the old appointment time. 2. The Receptionist finds the current appointment in the appointment file and cancels it.

S-3: Change Appointment 1. The Receptionist performs the S-2: cancel appointment subflow. 2. The Receptionist performs the S-1: new appointment subflow.

S-1, 2a1: The Receptionist proposes some alternative appointment times based on what is available in the appointment schedule. S-1, 2a2: The Patient chooses one of the proposed times or decides not to make an appointment.

6. The Receptionist provides the results of the transaction to the Patient.

This use case describes how we make an appointment as well as changing or canceling an appointment for a previously seen patient.

Relationships: Association: Include: Extend: Generalization:

If the patient wants to make a new appointment, the S-1: new appointment subflow is performed. If the patient wants to cancel an existing appointment, the S-2: cancel appointment subflow is performed. If the patient wants to change an existing appointment, the S-3: change appointment subflow is performed.

TEMPLATE can be found at www.wiley.com /college/dennis

Object Identifi cation  169

of the system, it is much better to have to delete something later than to accidentally leave something critical out. Second, all participants should begin thinking fast and furiously. Aft er all ideas are out on the proverbial table, then the participants can be encouraged to ponder the candidate classes they have identifi ed. Th ird, the facilitator must manage the fast and furious thinking process. Otherwise, the process will be chaotic. Furthermore, the facilitator should ensure that all participants are involved and that a few participants do not dominate the process. To get the most complete view of the problem, we suggest using a round-robin approach wherein participants take turns suggesting candidate classes. Another approach is to use an electronic brainstorming tool that supports anonymity.3 Fourth, the facilitator can use humor to break the ice so that all participants can feel comfortable in making suggestions.

Common Object Lists As its name implies, a common object list is simply a list of objects common to the business domain of the system. Several categories of objects have been found to help the analyst in creating the list, such as physical or tangible things, incidents, roles, and interactions.4 Analysts should fi rst look for physical, or tangible, things in the business domain. Th ese could include books, desks, chairs, and offi ce equipment. Normally, these types of objects are the easiest to identify. Incidents are events that occur in the business domain, such as meetings, fl ights, performances, or accidents. Reviewing the use cases can readily identify the roles that the people play in the problem, such as doctor, nurse, patient, or receptionist. Typically, an interaction is a transaction that takes place in the business domain, such as a sales transac- tion. Other types of objects that can be identifi ed include places, containers, organizations, business records, catalogs, and policies. In rare cases, processes themselves may need infor- mation stored about them. In these cases, processes may need an object, in addition to a use case, to represent them. Finally, there are libraries of reusable objects that have been created for diff erent business domains. For example, with regard to the appointment problem, the Common Open Source Medical Objects5 could be useful to investigate for potential objects that should be included.

Patterns Th e idea of using patterns is a relatively new area in object-oriented systems development.6 Th ere have been many defi nitions of exactly what a pattern is. From our perspective, a pat- tern is simply a useful group of collaborating classes that provide a solution to a commonly occurring problem. Because patterns provide a solution to commonly occurring problems, they are reusable.

3 A.R. Dennis, J.S. Valacich, T. Connolly, and B.E. Wynne, “Process Structuring in Electronic Brainstorming,” Information Systems Research 7, no. 2 (June 1996): 268–277. 4 For example, see C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design (Englewood Cliff s, NJ: Prentice Hall, 1998); S. Shlaer and S. J. Mellor, Object-Oriented Systems Analysis: Modeling the World in Data (Englewood Cliff s, NJ: Yourdon Press, 1988). 5 See Common Open Source Medical Objects, Sourceforge, sourceforge.net/projects/cosmos/. 6 Many books have been devoted to this topic. For example, see P. Coad, D. North, and M. Mayfi eld, Object Mod- els: Strategies, Patterns, & Applications, 2nd Ed. (Englewood Cliff s, NJ: Prentice Hall, 1997); H.-E. Eriksson and M. Penker, Business Modeling with UML: Business Patterns at Work (New York: Wiley, 2000); M. Fowler, Analysis Patterns: Reusable Object Models (Reading, MA: Addison-Wesley, 1997); E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Soft ware (Reading, MA: Addison-Wesley, 1995); David C. Hay, Data Model Patterns: Conventions of Th ought (New York: Dorset House, 1996); L. Silverston, Th e Data Model Resource Book: A Library of Universal Data Models for All Enterprises, Volume 1, Revised Ed. (New York, NY; Wiley, 2001).

1 7 0 C h a p t e r 5   Structural Modeling

FIGURE 5-3  Sample Patterns

Place

Transaction Transaction Line Item Item

Participant

0..*

0..*

1..*

1..1

1..1

1..1 1..10..*

Transaction Account

2..21..1

1..10..*

OrganizationPerson

Party

ServiceGood

Product

Entry

An architect, Christopher Alexander, has inspired much of the work associated with using patterns in object-oriented systems development. According to Alexander and his col- leagues,7 it is possible to make very sophisticated buildings by stringing together commonly found patterns, rather than creating entirely new concepts and designs. In a similar man- ner, it is possible to put together commonly found object-oriented patterns to form elegant object-oriented information systems. For example, many business transactions involve the same types of objects and interactions. Virtually all transactions would require a transaction class, a transaction line item class, an item class, a location class, and a participant class. By reusing these existing patterns of classes, we can more quickly and more completely defi ne the system than if we start with a blank piece of paper.

Many types of patterns have been proposed, ranging from high-level business-oriented patterns to more low-level design patterns. For example, Figure 5-3 depicts a set of useful analysis patterns.8 Figure 5-4 portrays a class diagram that we created by merging the patterns contained in Figure 5-3 into a single reusable pattern. In this case, we merged the Transaction– Entry–Account pattern (located at the bottom left of Figure 5-3) with the Place–Transaction– Participant–Transaction Line Item–Item pattern (located at the top left of Figure 5-3) on the

7 C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel, A Pattern Language (New York: Oxford University Press, 1977). 8 Th e patterns are portrayed using UML Class Diagrams. We describe the syntax of the diagrams later in this chapter. Th e specifi c patterns shown have been adapted from patterns described in P. Coad, D. North, and M. Mayfi eld, Object Models: Strategies, Patterns, & Applications, 2nd Ed.; M. Fowler, Analysis Patterns: Reusable Object Models; L. Silverston, Th e Data Model Resource Book: A Library of Universal Data Models for All Enterprises, Volume 1, Revised Edition.

Object Identifi cation  171

FIGURE 5-4  Sample Integration of Sample Patterns

Place

Transaction Transaction Line Item Item

Participant

0..*

0..*

1..*

1..1

1..1

1..1 1..10..*

1..12..2

OrganizationPerson

ServiceGood

Account

0..*1..1

Entry

common Transaction class. Next, we merged the Party–Person–Organization (located at the top right of Figure 5-3) by merging the Participant and Party classes. Finally, we extended the Item class by merging the Item class with the Product class of the Product–Good–Service pattern (located at the bottom right of Figure 5-3).

In this manner, using patterns from diff erent sources in enables the development team to leverage knowledge beyond that of the immediate team members and allows the team to develop more complete and robust models of the problem domain. For example, in the case of the appointment problem, we can look at the objects previously identifi ed through textual analysis, brainstorming, and/or common object lists and see if it makes sense to map any of them into any predefi ned reusable patterns. In this specifi c case, we can look at an appointment as a type of transaction in which a doctor’s offi ce participates. By looking at an appointment as a type of transaction, we can apply the pattern we created in Figure 5-4 and discover a set of pre- viously unidentifi ed objects, such as Place, Patient as a type of Participant, and Transaction Line Items that are associated with diff erent types of Items (Goods and/or Services). Discovering these specifi c additional objects could be useful in developing the billing side of the appoint- ment system. Even though these additional objects could be applicable, they were not uncov- ered using the other techniques.

Based on this simple example, it is obvious that using patterns to develop structural models can be advantageous. Figure 5-5 lists some common business domains for which patterns have been developed and their source. If we are developing a business information system in one of these business domains, then the patterns developed for that domain may be a very useful starting point in identifying needed classes and their attributes, operations, and relationships.

1 7 2 C h a p t e r 5   Structural Modeling

CRC CARDS CRC (Class–Responsibility–Collaboration) cards are used to document the responsibilities and collaborations of a class. In some object-oriented systems-development methodologies, CRC cards are seen to be an alternative competitor to the Unifi ed Process employment of use cases and class diagrams. However, we see them as a useful, low-tech approach that can compli- ment a typical high-tech Unifi ed Process approach that uses CASE tools. We use an extended form of the CRC card to capture all relevant information associated with a class.9 We describe the elements of our CRC cards later, aft er we explain responsibilities and collaborations.

Responsibilities and Collaborations Responsibilities of a class can be broken into two separate types: knowing and doing. Knowing responsibilities are those things that an instance of a class must be capable of know- ing. An instance of a class typically knows the values of its attributes and its relationships. Doing responsibilities are those things that an instance of a class must be capable of doing. In this case, an instance of a class can execute its operations or it can request a second instance, which it knows about, to execute one of its operations on behalf of the fi rst instance.

Th e structural model describes the objects necessary to support the business processes modeled by the use cases. Most use cases involve a set of several classes, not just one class.

9  Our CRC cards are based on the work of D. Bellin and S. S. Simone, Th e CRC Card Book (Reading, MA: Addison- Wesley, 1997); I. Graham, Migrating to Object Technology (Wokingham, England: Addison-Wesley, 1995); B. Henderson-Sellers and B. Unhelkar, OPEN modeling with UML (Harlow, England: Addison-Wesley, 2000).

Business Domains Sources of Patterns

Accounting 3, 4

Actor-Role 2

Assembly-Part 1

Container-Content 1

Contract 2, 4

Document 2, 4

Employment 2, 4

Financial Derivative Contracts 3

Geographic Location 2, 4

Group-Member 1

Interaction 1

Material Requirements Planning 4

Organization and Party 2, 3

Plan 1, 3

Process Manufacturing 4

Trading 3

Transactions 1, 4

1. Peter Coad, David North, and Mark Mayfi eld, Object Models: Strategies, Patterns, and Applications, 2nd Ed. (Englewood Cliffs, NJ: Prentice Hall, 1997).

2. Hans-Erik Eriksson and Magnus Penker, Business Modeling with UML: Business Patterns at Work (New York: Wiley, 2000).

3. Martin Fowler, Analysis Patterns: Reusable Object Models (Reading, MA: Addison-Wesley, 1997).

4. David C. Hay, Data Model Patterns: Conventions of Thought (New York, NY, Dorset House, 1996). FIGURE 5-5 Useful Patterns

CRC Cards  173

Th ese classes form collaborations. Collaborations allow the analyst to think in terms of clients, servers, and contracts.10 A client object is an instance of a class that sends a request to an instance of another class for an operation to be executed. A server object is the instance that receives the request from the client object. A contract formalizes the interactions between the client and server objects. Chapter 8 provides a more-detailed explanation of contracts and examples of their use.

An analyst can use the idea of class responsibilities and client–server–contract collabo- rations to help identify the classes, along with the attributes, operations, and relationships, involved with a use case. One of the easiest ways to use CRC cards in developing a structural model is through anthropomorphism—pretending that the classes have human characteris- tics. Members of the development team can either ask questions of themselves or be asked questions by other members of the team. Typically the questions asked are of the form:

Who or what are you? What do you know? What can you do?

Th e answers to the questions are then used to add detail to the evolving CRC cards. For example, in the appointment problem, a member of the team can pretend that he or she is an appointment. In this case, the appointment would answer that he or she knows about the doc- tor and patient who participate in the appointment and they would know the date and time of the appointment. Furthermore, an appointment would have to know how to create itself, delete itself, and to possibly change diff erent aspects of itself. In some cases, this approach will uncover additional objects that have to be added to the evolving structural model.

Elements of a CRC Card Th e set of CRC cards contains all the information necessary to build a logical structural model of the problem under investigation. Figure 5-6 shows a sample CRC card. Each CRC card cap- tures and describes the essential elements of a class. Th e front of the card contains the class’s name, ID, type, description, associated use cases, responsibilities, and collaborators. Th e name of a class should be a noun (but not a proper noun, such as the name of a specifi c person or thing). Just like the use cases, in later stages of development, it is important to be able to trace back design decisions to specifi c requirements. In conjunction with the list of associated use cases, the ID number for each class can be used to accomplish this. Th e description is simply a brief statement that can be used as a textual defi nition for the class. Th e responsibilities of the class tend to be the operations that the class must contain (i.e., the doing responsibilities).

Th e back of a CRC card contains the attributes and relationships of the class. Th e attributes of the class represent the knowing responsibilities that each instance of the class has to meet. Typically, the data type of each attribute is listed with the name of the attribute (e.g., the amount attribute is double and the insurance carrier is text). Th ree types of relationships typically are captured at this point: generalization, aggregation, and other associations. In Figure 5-6, we see that a Patient is a-kind-of Person and that a Patient is associated with Appointments.

CRC cards are used to document the essential properties of a class. However, once the cards are fi lled out, the analyst can use the cards and anthropomorphisms in role-playing (described in the next section) to uncover missing properties by executing the diff erent

10 For more information, see K. Beck and W. Cunningham, “A Laboratory for Teaching Object-Oriented Th ink- ing,” Proceedings of OOPSLA, SIGPLAN Notices, 24, no. 10 (1989): 1–6; B. Henderson-Sellers and B. Unhelkar, OPEN Modeling with UML (Harlow, England: Addison-Wesley, 2000); C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design (Englewood Cliff s, NJ: Prentice Hall, 1998); B. Meyer, Object- Oriented Soft ware Construction (Englewood Cliff s, NJ: Prentice Hall, 1994); R. Wirfs-Brock, B. Wilkerson, and L. Wiener, Designing Object-Oriented Soft ware (Englewood Cliff s, NJ, Prentice Hall, 1990).

1 7 4 C h a p t e r 5   Structural Modeling

FIGURE 5-6 Sample CRC Card

Front:

Class Name: Old Patient ID: 3

Calculate last visit

Make appointment

Change status

Provide medical history

Responsibilities

Associated Use Cases: 2Description: An individual who needs to receive or has received medical attention

Type: Concrete, Domain

Appointment

Medical history

Collaborators

Back:

Attributes:

Insurance carrier (text)

Amount (double)

Relationships:

Generalization (a-kind-of): Person

Aggregation (has-parts): Medical History

Other Associations: Appointment

scenarios associated with the use cases (see Chapter 4). Role-playing also can be used as a basis to test the clarity and completeness of the evolving representation of the system.

Role-Playing CRC Cards with Use Cases11, 12 In addition to the object identifi cation approaches described earlier (textual analysis, brain- storming, common object lists, and patterns), CRC cards can be used in a role-playing exercise that has been shown to be useful in discovering additional objects, attributes, relationships, and operations. Furthermore, in addition to walkthroughs, described later in this chapter, role-playing is very useful in testing the fi delity of the evolving structural model. In general, members of the team perform roles associated with the actors and objects previously identifi ed

11 Th is step is related to the verifi cation and validation of the analysis models (functional, structural, and behavioral). Because this deals with verifi cation and validation that take place between the models, in this case functional and structural, we will return to this topic in Chapter 7. 12 Our role-playing approach is based on the work of D. Bellin and S. S. Simone, Th e CRC Card Book (Reading, MA: Addison-Wesley, 1997).

CRC Cards  175

with the diff erent use cases. Technically speaking, the members of the team perform the dif- ferent steps associated with a specifi c scenario of a use case. Remember, a scenario is a single, unique execution path through a use case. A useful place to look for the diff erent scenarios of a use case is the activity diagrams (e.g., see Figures 4-8, 4-9, 4-10, and 4-12). A diff erent scenario exists for each time a decision node causes a split in the execution path of the use case. Also, scenarios can be identifi ed from the alternative/exceptional fl ows in a use-case description. Considering the incremental and iterative nature and that activity diagrams and use-case descriptions should contain the same information, reviewing both representations will ensure that relevant scenarios are not missed.

Th e fi rst step is to review the use-case descriptions (see Figure 5-2). Th is allows the team to pick a specifi c use case to role-play. Even though it is tempting to try to complete as many use cases as possible in a short time, the team should not choose the easiest use cases fi rst. Instead, at this point in the development of the system, the team should choose the use case that is the most important, the most complex, or the least understood.

Th e second step is to identify the relevant roles that are to be played. Each role is associated with either an actor or an object. To choose the relevant objects, the team reviews each of the CRC cards and picks the ones that are associated with the chosen use case. For example, in Figure 5-6, we see that the CRC card that represents the Old Patient class is associated with Use Case number 2. So if we were going to role-play the Make Old Patient Appt use case (see Figure 5-2), we would need to include the Old Patient CRC card. By reviewing the use-case description, we can easily identify the Old Patient and Doctor actors (see Primary Actor and Stakeholders section of the use case description in Figure 5-2). By reading the event section of the use-case description, we identify the internal actor role of Receptionist. Aft er identifying all of the relevant roles, we assign each one to a diff erent member of the team.

Th e third step is to role-play scenarios of the use case by having the team members per- form each one. To do this, each team member must pretend that he or she is an instance of the role assigned to him or her. For example, if a team member was assigned the role of the Receptionist, then he or she would have to be able to perform the diff erent steps in the scenario associated with the Receptionist. In the case of the change appointment scenario, this would include steps 2, 5, 6, S-3, S-1, and S-2. However, when this scenario is performed (role-played), it would be discovered that steps 1, 3, and 4 were incomplete. For example, in Step 1, what actually occurs? Does the Patient make a phone call? If so, who answers the phone? In other words, a lot of information contained in the use-case description is only identifi ed in an implicit, not explicit, manner. When the information is not identifi ed explicitly, there is a lot of room for interpretation, which requires the team members to make assumptions. It is much better to remove the need to make an assumption by making each step explicit. In this case, Step 1 of the Normal Flow of Events should be modifi ed. Once the step has been fi xed, the scenario is tried again. Th is process is repeated until the scenario can be executed to a successful conclusion. Once the scenario has successfully concluded, the next scenario is performed. Th is is repeated until all of the scenarios of the use case can be performed successfully. 13

Th e fourth step is to simply repeat steps 1 through 3 for the remaining use cases.

13 In some cases, some scenarios are only executed in very rare circumstances. So, from a practical perspective, each scenario could be prioritized individually and only “important” scenarios would have to be implemented for the fi rst release of the system. Only those scenarios would have to be tested at this point in the evolution of the system.

2. Identify Relevant Actors and Objects

3. Role-Play Scenarios

1. Review Use Cases

4. Repeat Steps 1 through 3

1 7 6 C h a p t e r 5   Structural Modeling

CL ASS DIAGRAMS A class diagram is a static model that shows the classes and the relationships among classes that remain constant in the system over time. Th e class diagram depicts classes, which include both behaviors and states, with the relationships between the classes. Th e following sections present the elements of the class diagram, diff erent approaches that can be used to simplify a class diagram, and an alternative structure diagram: the object diagram.

Elements of a Class Diagram Figure 5-7 shows a class diagram that was created to refl ect the classes and relationships associated with the appointment system. Th is diagram is based on the classes uncov- ered through the object identifi cation techniques and the role-playing of the CRC cards described earlier.

Class Th e main building block of a class diagram is the class, which stores and manages information in the system (see Figure 5-8). During analysis, classes refer to the people, places, and things about which the system will capture information. Later, during design and implementation, classes can refer to implementation-specifi c artifacts such as win- dows, forms, and other objects used to build the system. Each class is drawn using a three- part rectangle, with the class’s name at the top, attributes in the middle, and operations at the bottom. We can see that the classes identifi ed earlier, such as Participant, Doctor, Patient, Receptionist, Medical History, Appointment, and Symptom, are included in Figure 5-7. Th e attributes of a class and their values defi ne the state of each object created from the class, and the behavior is represented by the operations.

Attributes are properties of the class about which we want to capture information (see Figure 5-8). Notice that the Participant class in Figure 5-7 contains the attributes: lastname, fi rstname, address, phone, and birthdate. At times, you might want to store derived attributes, which are attributes that can be calculated or derived; these special attributes are denoted by placing a slash (/) before the attribute’s name. Notice how the person class contains a derived attribute called /age, which can be derived by subtracting the patient’s birth date from the current date. It is also possible to show the visibility of the attribute on the diagram. Visibility relates to the level of information hiding to be enforced for the attribute. Th e visibility of an attribute can be public (+), protected (#), or private (−). A public attribute is one that is not hidden from any other object. As such, other objects can modify its value. A protected attribute is one that is hidden from all other classes except its immediate subclasses. A private attribute is one that is hidden from all other classes. Th e default visibility for an attribute is normally private.

Operations are actions or functions that a class can perform (see Figure 5-8). Th e func- tions that are available to all classes (e.g., create a new instance, return a value for a particular attribute, set a value for a particular attribute, delete an instance) are not explicitly shown within the class rectangle. Instead, only operations unique to the class are included, such as the cancel without notice operation in the Appointment class and the calculate last visit operation in the Patient class in Figure 5-7. Notice that both the operations are followed by parentheses, which contain the parameter(s) needed by the operation. If an operation has no parameters, the parentheses are still shown but are empty. As with attributes, the visibility of an operation can be designated public, protected, or private. Th e default visibility for an operation is normally public.

Th ere are four kinds of operations that a class can contain: constructor, query, update, and destructor. A constructor operation creates a new instance of a class. For example, the patient class may have a method called insert (), which creates a new patient instance as

177

FI G

U R

E 5

-7   

S am

p le

C la

ss D

ia g

ra m

A cc

o u n t

Em p lo

ye e0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

1. .*

1. .*

1. .*

1. .*

1 .. 1

1 .. 1

1. .*

1 .. 1

1 .. 1

0 .. 1

1 .. 1

1 .. 1

1 .. 1

1 .. 1

1 .. 1

1 .. 1

D eb

it

C re

d it

En tr

y A

p p o in

tm en

t

-t im

e -d

at e

-r ea

so n

+ ca

n ce

l w

it h o u t n o ti ce

()

Pa ti

en t

-i n su

ra n ce

c ar

ri er

+ m

ak e

ap p o in

tm en

t( )

+ ca

lc u la

te l as

t vi

si t( )

+ ch

an ge

s ta

tu s(

) +

p ro

vi d es

m ed

ic al

h is

to ry

()

Pa rt

ic ip

an t

-l as

tn am

e -fi

rs tn

am e

-a d d re

ss -p

h o n e

-b ir

th d at

e -/

ag e

It em

Tr an

sa ct

io n L

in e

It em

h as

h as

co n ta

in s

A ss

ig n ed

T o

+ p

ri m

ar y

in su

ra n ce

ca rr

ie r

D o ct

o r

R ec

ep ti

o n is

t N

u rs

e

M ed

ic al

H is

to ry

-h ea

rt d

is ea

se -h

ig h b

lo o d p

re ss

u re

-d ia

b et

es -a

ll er

gi es

p ro

vi d es

su ff er

s

schedules

lo ca

te d A

t

G o o d

Se rv

ic e

P re

sc ri

p ti

o n

B ra

ce P hy

si ca

l C

h ec

ku p

Sy m

p to

m Il

ln es

s

P la

ce

Tr ea

tm en

t

m ed

ic at

io n

in st

ru ct

io n s

sy m

p to

m s

ev er

it y

-a m

o u n t

-n am

e -d

es cr

ip ti o n

1 7 8 C h a p t e r 5   Structural Modeling

FIGURE 5-8 Class Diagram Syntax

A class:

• Has a name typed in bold and centered in its top compartment. • Has a list of attributes in its middle compartment.

• Represents a kind of person, place, or thing about which the system will need to capture and store information.

• Has a list of operations in its bottom compartment.

attribute name /derived attribute name

operation name ()

• Does not explicitly show operations that are available to all classes. An attribute: • Represents properties that describe the state of an object. • Can be derived from other attributes, shown by placing a slash before the attribute’s name. An operation: • Represents the actions or functions that a class can perform. • Can be classified as a constructor, query, or update operation. • Includes parentheses that may contain parameters or information needed to perform the operation. An association: • Represents a relationship between multiple classes or a class and itself.

A generalization:

• Is labeled using a verb phrase or a role name, whichever better represents the relationship.

An aggregation: • Represents a logical a-part-of relationship between multiple classes or a class and itself. • Is a special form of an association. A composition: • Represents a physical a-part-of relationship between multiple classes or a class and itself • Is a special form of an association.

• Can exist between one or more classes.

• Represents a-kind-of relationship between multiple classes.

• Contains multiplicity symbols, which represent the minimum and maximum times a class instance can be associated with the related class instance.

Class1

-Attribute-1 +Operation-1()

AssociatedWith 0..* 1

0..* 1IsPartOf

1..* 1IsPartOf

patients are entered into the system. As we just mentioned, if an operation implements one of the basic functions (e.g., create a new instance), it is normally not explicitly shown on the class diagram, so typically we do not see constructor methods explicitly on the class diagram.

A query operation makes information about the state of an object available to other objects, but it does not alter the object in any way. For instance, the calculate last visit () operation that determines when a patient last visited the doctor’s offi ce will result in the object’s being accessed by the system, but it will not make any change to its information. If a query method merely asks for information from attributes in the class (e.g., a patient’s name, address, phone), then it is not shown on the diagram because we assume that all objects have operations that produce the values of their attributes.

Class Diagrams  179

An update operation changes the value of some or all the object’s attributes, which may result in a change in the object’s state. Consider changing the status of a patient from new to current with a method called change status() or associating a patient with a particular appointment with make appointment (appointment). If the result of the operation can change the state of the object, then the operation must be explicitly included on the class diagram. On the other hand, if the update operation is a simple assignment operation, it can be omitted from the diagram.

A destructor operation simply deletes or removes the object from the system. For exam- ple, if an employee object no longer represents an actual employee associated with the fi rm, the employee could need to be removed from the employee database, and a destructor opera- tion would be used to implement this behavior. However, deleting an object is one of the basic functions and therefore would not be included on the class diagram.

Relationships A primary purpose of a class diagram is to show the relationships, or asso- ciations, that classes have with one another. Th ese are depicted on the diagram by drawing lines between classes (see Figure 5-8). When multiple classes share a relationship (or a class shares a relationship with itself), a line is drawn and labeled with either the name of the relationship or the roles that the classes play in the relationship. For example, in Figure 5-7 the two classes patient and appointment are associated with one another whenever a patient schedules an appointment. Th us, a line labeled schedules connects patient and appointment, representing exactly how the two classes are related to each other. Also, notice that there is a small solid triangle beside the name of the relationship. Th e triangle allows a direction to be associated with the name of the relationship. In Figure 5-7, the schedules relationship includes a triangle, indicating that the relationship is to be read as “patient schedules appointment.” Inclusion of the triangle simply increases the readability of the diagram. In Figure 5-9, three additional examples of associations are portrayed: An Invoice is AssociatedWith a Purchase Order (and vice versa), a Pilot Flies an Aircraft , and a Spare Tire IsLocatedIn a Trunk.

Sometimes a class is related to itself, as in the case of a patient being the primary insur- ance carrier for other patients (e.g., spouse, children). In Figure 5-7, notice that a line was drawn between the patient class and itself and called primary insurance carrier to depict the role that the class plays in the relationship. Notice that a plus (+) sign is placed before the label to communicate that it is a role as opposed to the name of the relationship. When labeling an association, we use either a relationship name or a role name (not both), which- ever communicates a more thorough understanding of the model.

FIGURE 5-9 Sample Association

Purchase Order

Aircraft

TrunkSpare Tire

Pilot

Invoice

0..* 1

0..* 0..*

Flies

0..1 0..1

IsLocatedIn

AssociatedWith

1 8 0 C h a p t e r 5   Structural Modeling

Relationships also have multiplicity, which documents how an instance of an object can be associated with other instances. Numbers are placed on the association path to denote the minimum and maximum instances that can be related through the association in the format minimum number.. maximum number (see Figure 5-10). Th e numbers specify the relation- ship from the class at the far end of the relationship line to the end with the number. For exam- ple, in Figure 5-7, there is a 0..* on the appointment end of the patient schedules appointment relationship. Th is means that a patient can be associated with zero through many diff erent appointments. At the patient end of this same relationship, there is a 1..1, meaning that an appointment must be associated with one and only one patient. In Figure  5-9, we see that an instance of the Invoice class must be AssociatedWith one instance of the Purchase Order class and that an instance of the Purchase Order class may be AssociatedWith zero or more instances of the Invoice class, that an instance of the Pilot class Flies zero or more instances of the Aircraft class, and that an instance of the Aircraft class may be fl own by zero or more instances of the Pilot class. Finally, we see that an instance the Spare Tire class IsLocatedIn zero or one instance of the Trunk class, whereas an instance of the Trunk class can contain zero or one instance of the Spare Tire class.

Th ere are times when a relationship itself has associated properties, especially when its classes share a many-to-many relationship. In these cases, a class called an association class is formed, which has its own attributes and operations.14 It is shown as a rectangle attached

1

0..*

1..*

0..1

2..4

1..3,5

Exactly one A department has one and only one boss.

Zero or more

One or more

Zero or one

Specified range

Multiple, disjoint ranges

An employee has zero to many children.

A boss is responsible for one or more employees.

An employee can be married to zero or one spouse.

An employee can take from two to four vacations each year.

An employee is a member of one to three or five committees.

Department Boss 1

Employee Child 0..*

Boss Employee 1..*

Employee Spouse 0..1

Employee Vacation 2..4

Employee Committee 1..3,5

FIGURE 5-10 Multiplicity

14 For those familiar with data modeling, associative classes serve a purpose similar to the one the associative entity serves in ER diagramming.

Class Diagrams  181

by a dashed line to the association path, and the rectangle’s name matches the label of the association. Th ink about the case of capturing information about illnesses and symptoms. An illness (e.g., the fl u) can be associated with many symptoms (e.g., sore throat, fever), and a symptom (e.g., sore throat) can be associated with many illnesses (e.g., the fl u, strep throat, the common cold). Figure 5-7 shows how an association class can capture informa- tion about remedies that change depending on the various combinations. For example, a sore throat caused by strep throat requires antibiotics, whereas treatment for a sore throat from the fl u or a cold could be throat lozenges or hot tea. Another way to decide when to use an association class is when attributes that belong to the intersection of the two classes involved in the association must be captured. We can visually think about an association class as a Venn diagram. For example, in Figure 5-11, the Grade idea is really an intersection of the Student and Course classes, because a grade exists only at the intersection of these two ideas. Another example shown in Figure 5-11 is that a job may be viewed as the inter- section between a Person and a Company. Most oft en, classes are related through a normal association; however, there are two special cases of an association that you will see appear quite oft en: generalization and aggregation.

Generalization and Aggregation Associations A generalization association shows that one class (subclass) inherits from another class (superclass), meaning that the properties and operations of the superclass are also valid for objects of the subclass. Th e generalization path is shown with a solid line from the subclass to the superclass and a hollow arrow point- ing at the superclass (see Figure 5-8). For example, Figure 5-7 communicates that doctors, nurses, and receptionists are all kinds of employees and those employees and patients are kinds of participants. Remember that the generalization relationship occurs when you need to use words like “is a kind of” to describe the relationship. Some additional examples of generalization are given in Figure 5-12. For example, Cardinal is a-kind-of Bird, which is a-kind-of Animal; a General Practitioner is a-kind-of Physician, which is a-kind-of Person; and a Truck is a-kind-of Land Vehicle, which is a-kind-of Vehicle.

An aggregation association is used when classes actually comprise other classes. For example, think about a doctor’s offi ce that has decided to create health care teams that include doctors, nurses, and administrative personnel. As patients enter the offi ce, they are assigned to a health care team, which cares for their needs during their visits. We could

FIGURE 5-11  Sample Association Classes

CourseStudent 0..* 0..*

Grade

Student CourseGrade

CompanyPerson 0..* 0..*

Job

Person CompanyJob

1 8 2 C h a p t e r 5   Structural Modeling

include this new knowledge in Figure 5-7 by adding two new classes (Administrative Personnel and Health Team) and aggregation relationships from the Doctor, the Nurse, and the new Administrative Personnel classes to the new Health Team class. A diamond is placed nearest the class representing the aggregation (health care team), and lines are drawn from the diamond to connect the classes that serve as its parts (doctors, nurses, and administrative personnel). Typically, you can identify these kinds of associations when you need to use words like “is a part of” or “is made up of” to describe the relationship. However, from a UML perspective, there are two types of aggregation associations: aggregation and composition (see Figure 5-8).

Aggregation is used to portray logical a-part-of relationships and is depicted on a UML class diagram by a hollow or white diamond. For example in Figure 5-13, three logical

FIGURE 5-12  Sample Generalizations

TroutCardinal

FishBird

Animal

CarTruck

Land

HelicopterPlane

Air

SubmarineShip

Sea

PatientPhysician

SpecialistGeneral Practitioner

Person

Vehicle

Class Diagrams  183

aggregations are shown. Logical implies that it is possible for a part to be associated with multiple wholes or that is relatively simple for the part to be removed from the whole. For example, an instance of the Employee class IsPartOf an instance of at least one instance of the Department class, an instance of the Wheel class IsPartOf an instance of the Vehicle class, and an instance of the Desk class IsPartOf an instance of the Offi ce class. Obviously, in many cases an employee can be associated with more than one department, and it is relatively easy to remove a wheel from a vehicle or move a desk from an offi ce.

Composition is used to portray a physical part of relationships and is shown by a black diamond. Physical implies that the part can be associated with only a single whole. For exam- ple in Figure 5-14, three physical compositions are illustrated: an instance of a door can be a part of only a single instance of a car, an instance of a room can be a part of an instance only of a single building, and an instance of a button can be a part of only a single mouse. However, in many cases, the distinction that you can achieve by including aggregation (white diamonds) and composition (black diamonds) in a class diagram might not be worth the price of add- ing additional graphical notation for the client to learn. Th erefore, many UML experts view the inclusion of aggregation and composition notation to the UML class diagram as simply “syntactic sugar” and not necessary because the same information can always be portrayed by simply using the association syntax.

FIGURE 5-13 Sample Aggregation Associations

Department

Vehicle

OfficeDesk

Wheel

Employee 1..* 1..*

1..* 1

IsPartOf

IsPartOf

IsPartOf0..* 1

FIGURE 5-14 Sample Composition Associations

Car

Building

MouseButton

Room

Door 1..* 1

1..* 1

IsPartOf

IsPartOf

IsPartOf1..* 1

1 8 4 C h a p t e r 5   Structural Modeling

15 See footnote 1. 16 For those familiar with structured analysis and design, packages serve a purpose similar to the leveling and bal- ancing processes used in data fl ow diagramming. Packages and package diagrams are described in more detail in Chapter 7.

Simplifying Class Diagrams When a class diagram is fully populated with all the classes and relationships for a real- world system, the class diagram can become very diffi cult to interpret (i.e., can be very complex). When this occurs, it is sometimes necessary to simplify the diagram. One way to simplify the class diagram is to show only concrete classes.15 However, depending on the number of associations that are connected to abstract classes—and thus inherited down to the concrete classes—this particular suggestion could make the diagram more diffi cult to comprehend.

A second way to simplify the class diagram is through the use of a view mechanism. Views were developed originally with relational database management systems to show only a subset of the information contained in the database. In this case, the view would be a useful subset of the class diagram, such as a use-case view that shows only the classes and relation- ships relevant to a particular use case. A second view could be to show only a particular type of relationship: aggregation, association, or generalization. A third type of view is to restrict the information shown with each class, for example, show only the name of the class, the name and attributes, or the name and operations. Th ese view mechanisms can be combined to further simplify the diagram.

A third approach to simplifying a class diagram is through the use of packages (i.e., logical groups of classes). To make the diagrams easier to read and keep the models at a reasonable level of complexity, the classes can be grouped together into packages. Packages are general constructs that can be applied to any of the elements in UML models. In Chapter 4, we introduced the package idea to simplify use-case diagrams. In the case of class diagrams, it is simple to sort the classes into groups based on the relationships that they share.16

Object Diagrams Although class diagrams are necessary to document the structure of the classes, a second type of static structure diagram, called an object diagram, can be useful in revealing addi- tional information. An object diagram is essentially an instantiation of all or part of a class diagram. Instantiation means to create an instance of the class with a set of appropriate attribute values.

Object diagrams can be very useful when trying to uncover details of a class. Generally speaking, it is easier to think in terms of concrete objects (instances) rather than abstrac- tions of objects (classes). For example in Figure 5-15, a portion of the class diagram in Figure 5-7 has been copied and instantiated. Th e top part of the fi gure simply is a copy of a small view of the overall class diagram. Th e lower portion is the object diagram that instantiates that subset of classes. By reviewing the actual instances involved, John Doe, Appt1, Symptom1, and Dr. Smith, we may discover additional relevant attributes, relation- ships, and/or operations or possibly misplaced attributes, relationships, and/or operations. For example, an appointment has a reason attribute. Upon closer examination, the rea- son attribute might have been better modeled as an association with the Symptom class. Currently, the Symptom class is associated with the Patient class. Aft er reviewing the object diagram, this seems to be in error. Th erefore, we should modify the class diagram to refl ect this new understanding of the problem.

Creating Structural Models Using CRC Cards And Class Diagrams  185

FIGURE 5-15  Sample Object Diagram

Patient

-amount -insurance carrier

+make appointment() +calculate last visit() +change status() +provide medical history()

0..*

0..*

0..* 0..*

1..*

1..*

1..1

1..1

Appointment

-time -date -reason

+cancel without notice()

+primary insurance carrier

Doctor

Symptom

-name suffers

schedules

assignedTo

Participant

-lastname -firstname -address -phone -birthdate -/age

Symptom1: Symptom

name = Muscle Pain

John Doe: Patient

lastname = Doe firstname = John address = 1000 Main St phone = 555-555-5555 birthdate = 01/01/72 / age = 40 amount = 0.00 insurance carrier = JD Health Ins

time = 3:00 date = 7/7/2012 reason = Pain in Neck

Appt1: Appointment

lastname = Smith firstname = Jane address = Doctor’s Clinic phone = 999-999-9999 birthdate : 12/12/64 / age = 48

Dr. Smith: Doctor

CREATING STRUCTURAL MODELS USING CRC CARDS AND CL ASS DIAGRAMS

Creating a structural model is an incremental and iterative process whereby the analyst makes a rough cut of the model and then refi nes it over time. Structural models can become quite complex—in fact, there are systems that have hundreds of classes. It is important to remember that CRC cards and class diagrams can be used to describe both the as-is and to-be structural models of the evolving system, but they are most oft en used for the to-be model. Th ere are many diff erent ways to identify a set of candidate objects and to create CRC cards and class diagrams. Today most object identifi cation begins with the use cases

1 8 6 C h a p t e r 5   Structural Modeling

identifi ed for the problem (see Chapter 4). In this section, we describe a use-case–driven process that can be used to create the structural model of a problem domain.

We could begin creating the structural model with a class diagram instead of CRC cards. However, owing to the low-tech nature and the ease of role-playing use-case scenarios with CRC cards, we prefer to create the CRC cards fi rst and then transfer the informa- tion from the CRC cards into a class diagram later. As a result, the fi rst step of our rec- ommended process is to create CRC cards. Performing textual analysis on the use-case descriptions does this. If you recall, the normal fl ow of events, subfl ows, and alternative/ exceptional fl ows of the use-case description were written in a special form called Subject– Verb–Direct-Object–Preposition–Indirect object (SVDPI). By writing the use-case events in this form, it is easier to use the guidelines for textual analysis in Figure 5-1 to identify the objects. Reviewing the primary actors, stakeholders and interests, and brief descriptions of each use case allows additional candidate objects to be identifi ed. It is useful to go back and review the original requirements to look for information that was not included in the text of the use cases. Record all the uncovered information for each candidate object on a CRC card.

Th e second step is to review the CRC cards to determine if additional candidate objects, attributes, operations, and relationships are missing. In conjunction with this review, using the brainstorming and common object list approaches described earlier can aid the team in identifying missing classes, attributes, operations, and relationships. For example, the team could start a brainstorming session with a set of questions such as:

■ What are the tangible things associated with the problem? ■ What are the roles played by the people in the problem domain? ■ What incidents and interactions take place in the problem domain?

As you can readily see, by beginning with the use-case descriptions, many of these questions already have partial answers. For example, the primary actors and stakeholders are the roles that are played by the people in the problem domain. However, it is possible to uncover additional roles not thought of previously. Th is obviously would cause the use-case descriptions, and possi- bly the use-case diagram, to be modifi ed and possibly expanded. As in the previous step, be sure to record all the uncovered information onto the CRC cards. Th is includes any modifi cations uncovered for any previously identifi ed candidate objects and any information regarding any new candidate objects identifi ed.

Th e third step is to role-play each use-case scenario using the CRC cards. Each CRC card should be assigned to an individual who will perform the operations for the class on the CRC card. As the performers act out their roles, the system tends to break down. When this occurs, additional objects, attributes, operations, or relationships will be identifi ed. Again, as in the previous steps, any time any new information is discovered, new CRC cards are created or modifi cations to existing CRC cards are made.

Th e fourth step is to create the class diagram based on the CRC cards. Information con- tained on the CRC cards is transferred to the class diagrams. Th e responsibilities are trans- ferred as operations; the attributes are drawn as attributes; and the relationships are drawn as generalization, aggregation, or association relationships. However, the class diagram also requires that the visibility of the attributes and operations be known. As a general rule, attributes are private and operations are public. Th erefore, unless the analyst has a

4. Create Class Diagram

2. Review CRC Cards

3. Role-Play the CRC Cards

1. Create CRC Cards

Creating Structural Models Using CRC Cards And Class Diagrams  187

5. Review Class Diagram

6. Incorporate Patterns

7. Review the Model

good reason to change the default visibility of these properties, then the defaults should be accepted. Finally, the analyst should examine the model for additional opportunities to use aggregation or generalization relationships. Th ese types of relationships can simplify the individual class descriptions. As in the previous steps, all changes must be recorded on the CRC cards.

Th e fi fth step is to review the structural model for missing and/or unnecessary classes, attrib- utes, operations, and relationships. Until this step, the focus of the process has been on add- ing information to the evolving model. At this point, the focus begins to switch from simply adding information to also challenging the reasons for including the information contained in the model. One very useful approach here is to play devil’s advocate, where a team member, just for the sake of being a pain in the neck, challenges the reasoning for including all aspects of the model.

Th e sixth step is to incorporate useful patterns into the evolving structural model. A useful pattern is one that would allow the analyst to more fully describe the underlying domain of the problem being investigated. Looking at the collection of patterns available (Figure 5-5) and comparing the classes contained in the patterns with those in the evolving class dia- gram enable this. Aft er identifying the useful patterns, the analyst incorporates the iden- tifi ed patterns into the class diagram and modifi es the aff ected CRC cards. Th is includes adding and removing classes, attributes, operations, and/or relationships.

Th e seventh and fi nal step is to validate the structural model, including both the CRC cards and the class diagram. We discuss this content in the next section of the chapter and in Chapter 7.

Campus Housing Example In the previous chapter, we identifi ed a set of use cases (Add an Apartment, Delete an Apartment, and Search Available Rental Units) for the campus housing service that helps students fi nd apartments. By reviewing the use cases, we can easily determine that the cam- pus housing service must keep track of information for each available apartment and its owner. Th e information to be captured for each apartment is the location of the apartment, the number of bedrooms in the apartment, the monthly rent, and how far the apartment is from the campus. Regarding the owner of the apartment, we need to capture the owner’s contact information (e.g., name, address, phone number, e-mail address). Since students are simply users of the system, there is no need to capture any information regarding them; that is, in this case, students are simply actors. Finally, with regards to relationships among the classes, there is a single, optional, one to many association relationship that links the two classes together. Th e Apartment Owner CRC card is portrayed in Figure 5-16, and the class diagram for this situation is shown in Figure 5-17.

Library Example As with the Campus Housing example, the fi rst step is to create the CRC cards that repre- sent the classes in the structural model. In the previous chapter, we used the Library Book Collection Management System example to describe the process of creating the functional models (use-case and activity diagrams and use-case descriptions). In this chapter, we fol- low the same familiar example. Because we are following a use-case-driven approach to object-oriented systems development, we fi rst review the events described in the use-case descriptions (see Figure 5-18).

1 8 8 C h a p t e r 5   Structural Modeling

Front:

Class Name: Apartment Owner ID: 1

Delete apartment

Add apartment Responsibilities

Associated Use Cases: 2Description: An apartment owner who has apartments for rent

Type: Concrete, Domain

Apartment

Apartment

Collaborators

Back:

Attributes:

Address (address)

Phone number (PhoneNumber)

Email (EmailAddress)

Name (string)

Relationships:

Generalization (a-kind-of):

Aggregation (has-parts):

Other Associations: ApartmentFIGURE 5-16 Campus Housing Apartment Owner CRC Card

Next, we perform textual analysis on the events by applying the textual analysis rules described in Figure 5-1. In this case, we can quickly identify the need to include classes for Borrower, Books, Librarian, Check Out Desk, ID Card, Student Borrower, Faculty/ Staff Borrower, Guest Borrower, Registrar’s Database, Personnel Database, Library’s Guest Database, Overdue Books, Fines, Book Request. We also can easily identify opera- tions to “check the validity” of a book request, to “check out” the books, and to “reject” a book request. Furthermore, the events suggest a “brings” relationship between Borrower and Books and a “provides” relationship between Borrower and Librarian. Th is step

FIGURE 5-17 Campus Housing Class Diagram

Apartment Owner Apartment

0..1 0..*

Creating Structural Models Using CRC Cards And Class Diagrams  189

also suggests that we should review the overview section of the use-case description (see Figure 5-19). In this case, the only additional information gleaned from the use-case description is the possible inclusion of classes for Personnel Offi ce and Registrar’s Offi ce. Th is same process would also be completed for the remaining use cases contained in the functional model: Process Overdue Books, Maintain Book Collection, Search Collection, and Return Books (see Figure 4-6). Since we did not discuss these use cases in the previous chapter, we will review the problem description as a basis for beginning the next step (see Figure 5-20).

Normal Flow of Events:

SubFlows:

1. The Borrower brings books to the Librarian at the check out desk. 2. The Borrower provides Librarian his or her ID card. 3. The Librarian checks the validity of the ID Card. If the Borrower is a Student Borrower, Validate ID Card against Registrar’s Database. If the Borrower is a Faculty/Staff Borrower, Validate ID Card against Personnel Database. If the Borrower is a Guest Borrower, Validate ID Card against Library’s Guest Database. 4. The Librarian checks whether the Borrower has any overdue books and/or fines. 5. The Borrower checks out the books.

Alternate/Exceptional Flows: 4a. The ID Card is invalid, the book request is rejected. 5a. The Borrower either has overdue books fines, or both, the book request is rejected.

FIGURE 5-18  Flow Descriptions for the Borrow Books Use Case (Figure 4-21)

Association: Borrower, Personnel Office, Registrar’s Office Include: Extend: Generalization :

Use Case Name:

Primary Actor:

Stakeholders and Interests:

Brief Description:

ID: Importance Level:

Trigger:

Type: External

Use Case Type:

Relationships:

Borrow Books 2 High

Borrower

Borrower brings books to check out desk.

Detail, Essential

This use case describes how books are checked out of the library.

Borrower—wants to check out books Librarian—wants to ensure borrower only gets books deserved

FIGURE 5-19  Overview Description for the Borrow Books Use Case (Figure 4-20)

1 9 0 C h a p t e r 5   Structural Modeling

Th e second step is to review the CRC cards to determine if there is any informa- tion missing. In the case of the library system, because we only used the Borrow Books use-case description, some information is obviously missing. By reviewing Figure 5-20, we see that we need to include the ability to search the book collection by title, author, keywords, and ISBN. Th is obviously implies a Book Collection class with four diff erent search operations: Search By Title, Search By Author, Search By Keywords, and Search By ISBN. Interestingly, the description also implies either a set of subclasses or states for the Book class: Checked Out, Overdue, Requested, Available, and Damaged. We will return to the issue of states versus subclasses in the next chapter. Th e description implies many additional operations, including Returning Books, Requesting Books, Adding Books, Removing Books, Repairing Books, Fining Borrowers, and Emailing Reminders.

Next, we should use our own library experience to brainstorm potential additional classes, attributes, operations, and relationships that could be useful to include in the Library Book Collection Management System. In our library, there is also the need to Retrieve Books From Storage, Move Books to Storage, Request Books from the Interlibrary Loan System, Return Books to the Interlibrary Loan System, and Deal with E-Books. You also could include classes for Journals, DVDs, and other media. As you can see, many classes, attributes, operations, and relationships can be identifi ed.

Th e third step, role-playing the CRC cards, requires us to apply the three role-playing steps described earlier:

■ Review Use Cases ■ Identify Relevant Actors and Objects ■ Role Play Scenarios

FIGURE 5-20 Overview Description of the Library Book Collection Management System

The functional requirements for an automated university library circulation system include the need to support searching, borrowing, and book-maintenance activities. The system should support searching by title, author, keywords, and ISBN. Searching the library’s collection database should be available on terminals in the library and available to potential borrowers via the World Wide Web. If the book of interest is currently checked out, a valid borrower should be allowed to request the book to be returned. Once the book has been checked back in, the borrower requesting the book should be notifi ed of the book’s availability.

The borrowing activities are built around checking books out and returning books by borrowers. There are three types of borrowers: students, faculty and staff, and guests. Regardless of the type of borrower, the borrower must have a valid ID card. If the borrower is a student, having the system check with the registrar’s student database validates the ID card. If the borrower is a faculty or staff member, having the system check with the personnel offi ce’s employee database validates the ID card. If the borrower is a guest, the ID card is checked against the library’s own borrower database. If the ID card is valid, the system must also check to determine whether the borrower has any overdue books or unpaid fi nes. If the ID card is invalid, the borrower has overdue books, or the borrower has unpaid fi nes, the system must reject the borrower’s request to check out a book; otherwise the borrower’s request should be honored. If a book is checked out, the system must update the library’s collection database to refl ect the book’s new status.

The book-maintenance activities deal with adding and removing books from the library’s book collection. This requires a library manager to both logically and physically add and remove the book. Books being purchased by the library or books being returned in a damaged state typically cause these activities. If a book is determined to be damaged when it is returned and it needs to be removed from the collection, the last borrower will be assessed a fi ne. However, if the book can be repaired, depending on the cost of the repair, the borrower might not be assessed a fi ne. Finally, every Monday, the library sends reminder e-mails to borrowers who have overdue books. If a book is overdue more than two weeks, the borrower is assessed a fi ne. Depending on how long the book remains overdue, the borrower can be assessed additional fi nes every Monday.

Creating Structural Models Using CRC Cards And Class Diagrams  191

For our purposes, we will use the Borrow Books use case to demonstrate. Th e relevant actors include Student Borrowers, Faculty/Staff Borrowers, Guest Borrowers, Librarians, Personnel Offi ce, and Registrar’s Offi ce. Th ese can be easily gleaned from the overview section of the use-case description (see Figure 5-19) and the use-case diagram (see Figure 4-6). Th e relevant objects seem to include Books, Borrower, and ID Card. Finally, to role-play the scenarios, we need to assign the roles to the diff erent members of the team and try to perform each of the paths through the events of the use-case (see Figure 5-18). Based on the Events of the use case and the use case’s activity diagram (see Figure 5-21), we can quickly identify nine scenarios, three for each type of Borrower (Student, Faculty/ Staff , and Guest): Valid ID and No Overdue Books & No Fines, Valid ID only, and no Valid ID. When role-playing these scenarios, one question arises: What happens to the books that are requested when the request is rejected? Based on the current functional and structural models, the books are left sitting on the check out desk. Th at doesn’t quite seem right. In reality, the books are reshelved. In fact, the notion of reshelving books is also relevant to when books are checked back in or aft er books have been repaired. Furthermore, the idea of adding books to the collection should also include the operation of shelving the books. As you should readily see, building structural models will also help uncover behavior that was omitted when building the functional models. Remember, object-oriented systems develop- ment is not only use-case driven but also is incremental and iterative.

Th e fourth step is to put everything together and to draw the class diagram. Figure  5-22 represents the fi rst cut at drawing the class diagram for the Library Book Collection Management System. Th e classes identifi ed in the previous steps have been linked with other classes via asso- ciation, aggregation, and generalization relationships. For simplicity purposes, we only show the classes and their relationships; not their attributes, operations, or even the multiplicities on the association relationships.

FIGURE 5-21   Activity Diagram for the Borrow Books Use Case (Figure 4-12)

[Valid Card]

[No Overdue Books & No Fines]

Validate ID Card

Check Out Books

Check for Overdue Books and Fines

192

B o o k

C o ll ec

ti o n

B o rr

o w

er ID

St u d en

t

Li b ra

ri an

St u d en

t ID

R eg

is tr

ar ’s

D B

Pe rs

o n n el

D B

Fa cu

lt y/

St af

f ID

Li b ra

ry D

B

G u es

t ID

Fa cu

lt y/

St af

f G

u es

t Fi

n e

R eq

u es

t

Li b ra

ry

Sh el

f R

es h el

vi n g

C h ec

k O

u t

D es

k

St o ra

ge Pe

rs O

ff R

eg is

tr ar

O ff

In te

rL ib

ra ry

L o an

S ys

te m

B o o k

D V

D

Lo ca

ti o n

B o o k

Lo ca

ti o n

Jo u rn

al O

th er

M ed

ia

M ed

ia

* 1

FI G

U R

E 5 -2

2   

Fi rs

t- C

u t

C la

ss D

ia g

ra m

f o

r th

e L

ib ra

ry B

o o

k C

o ll

e ct

io n

S ys

te m

Creating Structural Models Using CRC Cards And Class Diagrams  193

FIGURE 5-23 Second-Cut Class Diagram for the Library Book Collection System

Student

Borrower Book

Guest Storage

Book Location

LibraryInterLibrary Loan System

Book Collection

Faculty/Staff

Librarian

0..* 0..* 1..10..*

1 *

Th e fi fth step is to carefully review what has been created. Not only should you look for any missing classes, attributes, operations, and/or relationships, but you should also challenge every aspect of the current model. Specifi cally, are there classes, attributes, operations, and/or relationships that should be removed from the model? If so, there may be classes on the diagram that should have been modeled as attributes. For example, the Student, Fac/Staff , and Guest IDs should have been attributes with their respective classes. Furthermore, because this is a book collection management system, the inclusion of other media seems to be inappropriate. Finally, the Personnel Offi ce and Registrar’s Offi ce are actually only actors in the system, not objects. Based on all of these deletions, a new version of the class diagram was drawn (see Figure 5-23). Th is diagram is much simpler and easier to understand.

Th e sixth step, incorporating useful patterns, enables us to take advantage of knowledge that was developed elsewhere. In this case, the pattern used in the library problem includes too many ideas that are not relevant to the current problem. However, by looking back to Figure 5-3, we see that one of the original patterns (the Place, Transaction, Participant, Transaction Line Item, and Item pattern—see the top left of the fi gure) is relevant. We incorporate that pattern into the class diagram by replacing Place by Check Out Desk, Participant by Borrower, Transaction by Check Out Trans, and Item by Book (Figure 5-24). Technically speaking, each of these replacements is simply a pattern customized to the problem at hand. We also then add the Transaction Line Item class that we had missed in the original structural model.

Th e seventh step is to review the current state of the structural model. Needless to say, the CRC card version and the class diagram version are no longer in agreement with each other. We return to this step in the next section of the chapter.

1 9 4 C h a p t e r 5   Structural Modeling

VERIFYING AND VALIDATING THE STRUCTURAL MODEL 17 Before we move on to creating behavioral models (see Chapter 6) of the problem domain, we need to verify and validate the structural model. In the previous chapter, we introduced the notion of walkthroughs as a way to verify and validate business processes and functional models. In this chapter, we combine walkthroughs with the power of role-playing as a way to more completely verify and validate the structural model that will underlie the business processes and functional models. In fact, all of the object identifi cation approaches described in this chapter can be viewed as a way to test the fi delity of the structural model. Because we have already introduced the idea of role-playing the CRC cards and object identifi cation, in this section we focus on performing walkthroughs.

In this case, the verifi cation and validation of the structural model are accomplished during a formal review meeting using a walkthrough approach in which an analyst presents the model to a team of developers and users. Th e analyst walks through the model, explaining each part of the model and all the reasoning behind the decision to include each of the classes in the structural model. Th is explanation includes justifi cations for the attributes, operations, and relationships associated with the classes. Each class should be linked back to at least one use case; otherwise, the purpose of including the class in the structural model will not be

17 Th e material in this section has been adapted from E. Yourdon, Modern Structured Analysis (Englewood Cliff s, NJ: Prentice Hall, 1989).

FIGURE 5-24  Class Diagram with Incorporated Pattern for the Library Book Collection System

Check Out Trans Transaction Line Item Book

Check Out Desk

Storage

Book Location

LibraryInterLibrary Loan System

Book Collection

Student

Borrower

GuestFaculty/Staff

Librarian

1..1 0..* 1..10..*

1..1 0..*

0..* 1..1

1..11..*

1 *

Verifying and Validating the Structural Model  195

understood. Also including people outside the development team who produced the model can bring a fresh perspective to the model and uncover missing objects.

Previously, we suggested three representations that could be used for structural mode- ling: CRC cards, class diagrams, and object diagrams. Because an object diagram is simply an instantiation of some part of a class diagram, we limit our discussion to CRC cards and class diagrams. Similar to how we verifi ed and validated the business process and func- tional models in the last chapter, we provide a set of rules that will test the consistency within the structural models. For example purposes, we use the appointment problem described in Chapter 4 and in this chapter. An example of the CRC card for the old patient class is shown in Figure 5-6, and the associated class diagram is portrayed in Figure 5-7.

First, every CRC card should be associated with a class on the class diagram, and vice versa. In the appointment example, the Old Patient class represented by the CRC card does not seem to be included on the class diagram. However, there is a Patient class on the class diagram (see Figures 5-6 and 5-7). Th e Old Patient CRC card most likely should be changed to simply Patient.

Second, the responsibilities listed on the front of the CRC card must be included as operations in a class on a class diagram, and vice versa. Th e make appointment responsibil- ity on the new Patient CRC card also appears as the make appointment() operation in the Patient class on the class diagram. Every responsibility and operation must be checked.

Th ird, collaborators on the front of the CRC card imply some type of relationship on the back of the CRC card and some type of association that is connected to the associated class on the class diagram. Th e appointment collaborator on the front of the CRC card also appears as another association on the back of the CRC card and as an association on the class diagram that connects the Patient class with the Appointment class.

Fourth, attributes listed on the back of the CRC card must be included as attributes in a class on a class diagram, and vice versa. For example, the amount attribute on the new Patient CRC card is included in the attribute list of the Patient class on the class diagram.

Fift h, the object type of the attributes listed on the back of the CRC card and with the attributes in the attribute list of the class on a class diagram implies an association from the class to the class of the object type. For example, technically speaking, the amount attribute implies an association with the double type. However, simple types such as int and double are never shown on a class diagram. Furthermore, depending on the problem domain, object types such as Person, Address, or Date might not be explicitly shown either. However, if we know that messages are being sent to instances of those object types, we probably should include these implied associations as relationships.

Sixth, the relationships included on the back of the CRC card must be portrayed using the appropriate notation on the class diagram. For example in Figure 5-6, instances of the Patient class are a-kind-of Person, it has instances of the Medical History class as part of it, and it has an association with instances of the Appointment class. Th us, the association from the Patient class to the Person class should indicate that the Person class is a generalization of its subclasses, including the Patient class; the association from the Patient class to the Medical History class should be in the form of an aggregation association (a white diamond); and the association between instances of the Patient class and instances of the Appointment class should be a simple association. However, when we review the class diagram in Figure 5-7, this is not what we fi nd. If you recall, we included in the class diagram the transaction pattern portrayed in Figure 5-4. When we did this, many changes were made to the classes contained in the class diagram. All of these changes should have been cascaded back through all of the CRC cards. In this case, the CRC card for the Patient class should show that a Patient is a-kind-of Participant (not Person) and that the relationship from Patient to Medical History should be a simple association (see Figure 5-25).

1 9 6 C h a p t e r 5   Structural Modeling

FIGURE 5-25 Patient CRC Card

Front:

Class Name: Patient ID: 3

Medical history

Make appointment Appointment

Change status

Calculate last visit

Provide medical history

Responsibilities

Associated Use Cases: 2Description: An individual who needs to receive or has received medical attention

Type: Concrete, Domain

Collaborators

Back:

Attributes:

Insurance carrier (text)

Amount (double)

Relationships:

Generalization (a-kind-of):

Aggregation (has-parts):

Other Associations: Appointment, Medical History

Participant

Seventh, an association class, such as the Treatment class in Figure 5-7, should be created only if there is indeed some unique characteristic (attribute, operation, or relationship) about the intersection of the connecting classes. If no unique characteristic exists, then the associ- ation class should be removed and only an association between the two connecting classes should be displayed.

Finally, as in the functional models, specifi c representation rules must be enforced. For example, a class cannot be a subclass of itself. Th e Patient CRC card cannot list Patient with the generalization relationships on the back of the CRC card, nor can a generalization rela- tionship be drawn from the Patient class to itself. Again, all the detailed restrictions for each representation are beyond the scope of this book.18 Figure 5-26 portrays the associations among the structural models.

18 A good reference for these types of restrictions is S.W. Ambler, Th e Elements of UML 2.0 Style (Cambridge, UK: Cambridge University Press, 2005).

Verifying and Validating the Structural Model  197

Structural Models

Including

Contains Contains

Contains

Class Diagram

Responsibilities

Collaborators

Association Aggregation

Composition

Attributes

Classes

Type

CRC Cards

Objects

Object Diagram

Contains

Represents

Associations/ Relationships

Have

HasKinds

Generalization

Association Class

HasKindsHasKinds

AssociatedWith

AssociatedWith

AssociatedWith

AssociatedWith

Operations

InstanceOf

FIGURE 5-26  Interrelationships among Structural Models

APPLYING THE CONCEPTS AT PATTERSON SUPERSTORE In Chapter 4, you learned how the functional models were developed in an iterative manner. Aft er creating the functional model for the Mobile Scheduling (Version 1) of the Integrated Health Clinic Delivery System, the team had a good understanding of the business processes. Now it is time to identify the key data and to develop the structural model of the objects that support those business processes. Structural modeling for Mobile Scheduling (Version 1) involves creating, verifying, and validating CRC cards, class diagram, and object diagrams.

You can fi nd the rest of the case at: www.wiley.com/go/dennis/casestudy

1 9 8 C h a p t e r 5   Structural Modeling

CHAPTER REVIEW Aft er reading and studying this chapter, you should be able to:

Describe the purpose of a structural model. Describe the diff erent elements of a structural model. Explain the diff erence between abstract and concrete classes. Describe the three general types of relationships typically used in a structural model. Create a structural model using textual analysis of use-case descriptions, brainstorming, common object lists,

and patterns. Explain the purpose of a CRC card in structural modeling. Create a structural model using CRC cards. Describe the diff erent elements of a CRC card. Describe how to role-play CRC cards using use-case scenarios. Describe the diff erent elements of a class diagram. Describe the four basic operations that can be represented on a class diagram. Explain the diff erences between the types of relationships supported on a class diagram. Create a class diagram that represents a structural model. Describe the diff erent elements of an object diagram. Create an object diagram that represents an instantiation of a portion of a class diagram. Verify and validate the evolving structural model using role-playing and walkthroughs. Verify and validate the functional model by ensuring the consistency of the three structural representations: CRC

cards, class diagrams, and object diagrams.

KEY TERMS

A-kind-of A-part-of Abstract class Aggregation association Assemblies Association Association class Attribute Brainstorming Class Class diagram Client Collaboration Common object list Conceptual model Concrete class

Constructor operation Contract Class–Responsibility–

Collaboration (CRC) CRC cards Decomposition Derived attribute Doing responsibility Destructor operation Generalization

association Has-parts Incidents Instance Interactions Knowing responsibility

Method Multiplicity Object Object diagram Operation Package Parts Pattern Private Protected Public Query operation Responsibility Role-playing Roles Server

State Static model Static structure

diagram Structural model Subclass Substitutability Superclass SVDPI Tangible things Textual analysis Update operation View Visibility Wholes

QUESTIONS

1. Describe to a businessperson the multiplicity of a rela- tionship between two classes.

2. Why are assumptions important to a structural model?

3. What is an association class?

4. Contrast the following sets of terms: object, class, method, attribute, superclass, subclass, concrete class, abstract class.

5. Give three examples of derived attributes that may exist on a class diagram. How would they be denoted on the class diagram?

Exercises  199

EXERCISES

A. Create a CRC card for each of the following classes: Movie (title, producer, length, director, genre) Ticket (price, adult or child, showtime, movie) Patron (name, adult or child, age)

B. Create a class diagram based on the CRC cards you created for exercise A.

C. Create a CRC card for each of the following classes. Consider that the entities represent a system for a patient billing system. Include only the attributes that would be appropriate for this context. Patient (age, name, hobbies, blood type, occupation, insurance carrier, address, phone) Insurance carrier (name, number of patients on plan, address, contact name, phone) Doctor (specialty, provider identifi cation number, golf handicap, age, phone, name)

D. Create a class diagram based on the CRC cards you created for exercise C.

E. Draw a class diagram for each of the following situations: 1. Whenever new patients are seen for the fi rst time,

they complete a patient information form that asks their name, address, phone number, and insurance carrier, which are stored in the patient information fi le. Patients can be signed up with only one carrier,

but they must be signed up to be seen by the doctor. Each time a patient visits the doctor, an insurance claim is sent to the carrier for payment. Th e claim must contain information about the visit, such as the date, purpose, and cost. It would be possible for a patient to submit two claims on the same day.

2. Th e state of Georgia is interested in designing a system that will track its researchers. Information of interest includes researcher name, title, position, researcher’s university name, university location, uni- versity enrollment, and researcher’s research inter- ests. Researchers are associated with one institution, and each researcher has several research interests.

3. A department store has a wedding registry. Th is registry keeps information about the customer (usually the bride), the products that the store carries, and the products for which each customer registers. Customers typically register for a large number of products, and many customers register for the same products.

4. Jim Smith’s dealership sells Fords, Hondas, and Toyotas. In order to get in touch with these man- ufacturers easily, the dealership keeps informa- tion about each of them. Th e dealership keeps information about the models of cars from each

6. What are the diff erent types of visibility? How would they be denoted on a class diagram?

7. Draw the relationships that are described by the fol- lowing business rules. Include the multiplicities for each relationship. A patient must be assigned to only one doctor, and a

doctor can have one or many patients. An employee has one phone extension, and a unique

phone extension is assigned to an employee. A movie theater shows at least one movie, and a movie

can be shown at up to four other movie theaters around town.

A movie either has one star, two costars, or more than ten people starring together. A star must be in at least one movie.

8. How do you designate the reading direction of a rela- tionship on a class diagram?

9. For what is an association class used in a class dia- gram? Give an example of an association class that

may be found in a class diagram that captures students and the courses that they have taken.

10. Give two examples of aggregation, generalization, and association relationships. How is each type of associa- tion depicted on a class diagram?

11. Identify the following operations as constructor, query, or update. Which operations would not need to be shown in the class rectangle?

Calculate employee raise (raise percent) Calculate sick days () Increment number of employee vacation days () Locate employee name () Place request for vacation (vacation day) Find employee address () Insert employee () Change employee address () Insert spouse ()

12. How are the diff erent structural models related, and how does this aff ect verifi cation and validation of the model?

2 0 0 C h a p t e r 5   Structural Modeling

manufacturer, including dealer price, model name, and series (e.g., Honda, Civic, LX). Additionally, the dealership also keeps all sales information, including buyer’s name, address and phone number, car purchased, and amount paid.

F. Create object diagrams based on the class diagrams you drew for exercise F.

G. Examine the class diagrams that you created for exer- cise F. How would the models change (if at all) based on these new assumptions?

1. Two patients have the same fi rst and last names. 2. Researchers can be associated with more than one

institution. 3. Th e store would like to keep track of purchase

items. 4. Many buyers have purchased multiple cars from

Jim over time because he is such a good dealer. H. Visit a website that allows customers to order a

product over the Web (e.g., Amazon.com). Create a structural model (CRC cards and class diagram) that the site must need to support its business process. Include classes to show what they need information about. Be sure to include the attributes and operations to represent the type of information they use and cre- ate. Finally, draw relationships, making assumptions about how the classes are related.

I. Using the seven-step process described in this chapter, create a structural model (CRC cards and class dia- gram) for exercise C in Chapter 4.

J. Perform a verifi cation and validation walkthrough for the structural model created for exercise J.

K. Using the seven-step process described in this chapter, create a structural model for exercise E in Chapter 4.

L. Perform a verifi cation and validation walkthrough for the structural model created for exercise L.

M. Using the seven-step process described in this chapter, create a structural model for exercise G in Chapter 4.

N. Perform a verifi cation and validation walkthrough for the structural model created for exercise N.

O. Using the seven-step process described in this chapter, create a structural model for exercise I in Chapter 4.

P. Perform a verifi cation and validation walkthrough for the structural model created for exercise P.

Q. Using the seven-step process described in this chapter, create a structural model for exercise L in Chapter 4.

R. Perform a verifi cation and validation walkthrough for the structural model created for exercise R.

S. Using the seven-step process described in this chapter, create a structural model for exercise O in Chapter 4.

T. Perform a verifi cation and validation walkthrough for the structural model created for exercise T.

U. Using the seven-step process described in this chapter, create a structural model for exercise R in Chapter 4.

V. Perform a verifi cation and validation walkthrough for the structural model created for exercise V.

W. Using the seven-step process described in this chapter, create a structural model for exercise U in Chapter 4.

X. Perform a verifi cation and validation walkthrough for the structural model created for exercise X.

MINICASES

1. West Star Marinas is a chain of twelve marinas that off er lakeside service to boaters; service and repair of boats, motors, and marine equipment; and sales of boats, motors, and other marine accessories. Th e sys- tems development project team at West Star Marinas has been hard at work on a project that eventually will link all the marina’s facilities into one unifi ed, networked system.

Th e project team has developed a use-case diagram of the current system. Th is model has been carefully checked. Last week, the team invited a number of system users to role-play the various use cases, and

the use cases were refi ned to the users’ satisfaction. Right now, the project manager feels confi dent that the as-is system has been adequately represented in the use-case diagram.

Th e director of operations for West Star is the sponsor of this project. He sat in on the role-playing of the use cases and was very pleased by the thorough job the team had done in developing the model. He made it clear to you, the project manager, that he was anxious to see your team begin work on the use cases for the to-be system. He was a little skeptical that it was necessary for your team to spend any

Minicases  201

time modeling the current system in the fi rst place but grudgingly admitted that the team really seemed to understand the business aft er going through that work.

Th e methodology you are following, however, specifi es that the team should now turn its attention to developing the structural models for the as-is sys- tem. When you stated this to the project sponsor, he seemed confused and a little irritated. “You are going to spend even more time looking at the current sys- tem? I thought you were done with that! Why is this necessary? I want to see some progress on the way things will work in the future!”

What is your response to the director of operations? Why do we perform structural modeling? Is there any benefi t to developing a structural model of the current system at all? How do the use cases and use-case dia- gram help us develop the structural model?

2. Holiday Travel Vehicles sells new recreational vehi- cles and travel trailers. When new vehicles arrive at Holiday Travel Vehicles, a new vehicle record is cre- ated. Included in the new vehicle record are a vehicle serial number, name, model, year, manufacturer, and base cost.

When a customer arrives at Holiday Travel Vehi- cles, he or she works with a salesperson to negotiate a vehicle purchase. When a purchase has been agreed upon, a sales invoice is completed by the salesperson. Th e invoice summarizes the purchase, including full customer information, information on the trade-in vehicle (if any), the trade-in allowance, and infor- mation on the purchased vehicle. If the customer requests dealer-installed options, they are listed on the invoice as well. Th e invoice also summarizes the fi nal negotiated price, plus any applicable taxes and license fees. Th e transaction concludes with a customer signa- ture on the sales invoice.

a. Identify the classes described in the preceding scenario (you should fi nd six). Create CRC cards for each class. Customers are assigned a customer ID when they

make their fi rst purchase from Holiday Travel Vehi- cles. Name, address, and phone number are recorded for the customer. Th e trade-in vehicle is described by a serial number, make, model, and year. Dealer-installed options are described by an option code, description, and price.

b. Develop a list of attributes for each class. Place the attributes onto the CRC cards. Each invoice lists just one customer. A person does

not become a customer until he or she purchases a vehicle. Over time, a customer may purchase a num- ber of vehicles from Holiday Travel Vehicles.

Every invoice must be fi lled out by only one sales- person. A new salesperson might not have sold any vehicles, but experienced salespeople have probably sold many vehicles.

Each invoice only lists one new vehicle. If a new vehicle in inventory has not been sold, there will be no invoice for it. Once the vehicle sells, there will be just one invoice for it.

A customer may decide to have no options added to the vehicle or may choose to add many options. An option may be listed on no invoices, or it may be listed on many invoices.

A customer may trade in no more than one vehicle on a purchase of a new vehicle. Th e trade-in vehicle may be sold to another customer who later trades it in on another Holiday Travel vehicle.

c. Based on the preceding business rules in force at Holiday Travel Vehicles and CRC cards, draw a class diagram and document the relationships with the appropriate multiplicities. Remember to update the CRC cards.

202

Behavioral models describe the internal dynamic aspects of an information system that supports the business processes in an organization. During analysis, behavioral models describe what the internal logic of the processes is without specifying how the processes are to be implemented. Later, in the design and implementation phases, the detailed design of the operations contained in the object is fully specifi ed. In this chapter, we describe three Unifi ed Modeling Language (UML) diagrams that are used in behavioral modeling (sequence diagrams, communication diagrams, and behavioral state machines) and CRUDE (create, read, update, delete, execute) matrices.

OBJECTIVES

■ Understand the rules and style guidelines for sequence and communication diagrams and behavioral state machines.

■ Understand the processes used to create sequence and communication diagrams, behavioral state machines, and CRUDE matrices.

■ Be able to create sequence and communication diagrams, behavioral state machines, and CRUDE matrices.

■ Understand the relationship between the behavioral models and the structural and functional models.

INTRODUCTION Th e previous two chapters discussed how analysts create both business process and functional models and structural models. Systems analysts use business process and functional models to describe the functional or external behavioral view of an information system. And, they use structural models to depict the internal structural or static view of an information system. In this chapter, we discuss how analysts use behavioral models to represent the internal behavior or dynamic view of an information system.

By supporting all three views (functional, structural, and behavioral), object-oriented systems analysis and design supports an architecture-centric approach to developing infor- mation systems. Furthermore, the behavioral view is driven by the original use cases uncov- ered during business process and functional modeling. As such, behavioral modeling is also use case driven. Finally, as with business process and functional modeling and structural modeling, you will fi nd that you will need to not only iterate across the behavioral models (described in this chapter), but you will also have to iterate across all three architectural views (functional, structural, and behavioral) to capture and represent the requirements for a business information system.

Th ere are two types of behavioral models. First, there are behavioral models used to rep- resent the underlying details of a business process portrayed by a use-case model. In UML,

C H A P T E R 6

Behavioral Modeling

Behavioral Models  203

interaction diagrams (sequence and communication) are used for this type of behavioral model. Practically speaking, interaction diagrams allow the analyst to model the distribution of the behavior of the system over the actors and objects in the system. In this way, we can easily see how actors and objects collaborate to provide the functionality defi ned in a use case. Second, a behavioral model is used to represent the changes that occur in the underlying data. UML uses behavioral state machines for this.

During analysis, analysts use behavioral models to capture a basic understanding of the dynamic aspects of the underlying business process. Traditionally, behavioral models have been used primarily during design, where analysts refi ne the behavioral models to include implementation details (see Chapter 8). For now, our focus is on what the dynamic view of the evolving system is and not on how the dynamic aspect of the system will be implemented.

In this chapter, we concentrate on creating behavioral models of the underlying busi- ness process. Using the interaction diagrams (sequence and communication diagrams) and behavioral state machines, it is possible to give a complete view of the dynamic aspects of the evolving business information system. We fi rst describe behavioral models and their components. We then describe each of the diagrams, how they are created, and how they are related to the functional and structural models described in Chapters 4 and 5. Finally, we describe CRUDE analysis and the process to verify and validate the behavioral models.

BEHAVIORAL MODELS When an analyst is attempting to understand the underlying application domain of a problem, he or she must consider both structural and behavioral aspects of the problem. Unlike other approaches to the development of information systems, object-oriented approaches attempt to view the underlying application domain in a holistic manner. By viewing the problem domain as a set of use cases that are supported by a set of collabo- rating objects, object-oriented approaches allow an analyst to minimize the semantic gap between the real-world set of objects and the evolving object-oriented model of the prob- lem domain. However, as we pointed out in the previous chapter, the real world tends to be messy; because soft ware must be logical to work, perfect modeling of the application domain is nearly impossible.

One of the primary purposes of behavioral models is to show how the underlying objects in a problem domain will work together to form a collaboration to support each of the use cases. Whereas structural models represent the objects and the relationships between them, behavioral models depict the internal view of the business process that a use case describes. Th e process can be shown by the interaction that takes place between the objects that collaborate to support a use case through the use of interaction (sequence and communication) diagrams. It is also possible to show the eff ect that the set of use cases that make up the system has on the objects in the system through the use of behavioral state machines.

Creating behavioral models is an iterative process that iterates not only over the indi- vidual behavioral models [e.g., interaction (sequence and communication) diagrams and behavioral state machines] but also over the functional (see Chapter 4) and structural (see Chapter 5) models. As the behavioral models are created, it is not unusual to make changes to the functional and structural models. In this chapter, we describe interaction diagrams, behavioral state machines, and CRUDE analysis and when to use each.

2 0 4 C h a p t e r 6   Behavioral Modeling

INTERACTION DIAGRAMS One of the primary diff erences between class diagrams and interaction diagrams, besides the obvious diff erence that one describes structure and the other behavior, is that the modeling focus on a class diagram is at the class level, whereas the interaction diagrams focus on the object level. In this section, we review objects, operations, and messages and we cover the two diff erent diagrams (sequence and communication) that can be used to model the interactions that take place between the objects in an information system.

Objects, Operations, and Messages An object is an instantiation of a class, i.e., an actual person, place, or thing about which we want to capture information. If we were building an appointment system for a doctor’s offi ce, classes might include doctor, patient, and appointment. Th e specifi c patients, such as Jim Maloney, Mary Wilson, and Th eresa Marks, are considered objects—i.e., instances of the patient class.

Each object has attributes that describe information about the object, such as a patient’s name, birth date, address, and phone number. Each object also has behaviors. At this point in the development of the evolving system, the behaviors are described by operations. An operation is nothing more than an action that an object can perform. For example, an appointment object can probably schedule a new appointment, delete an appointment, and locate the next available appointment. Later on during the development of the evolving system, the behaviors will be implemented as methods.

Each object also can send and receive messages. Messages are information sent to objects to tell an object to execute one of its behaviors. Essentially, a message is a function or proce- dure call from one object to another object. For example, if a patient is new to the doctor’s offi ce, the system sends an insert message to the application. Th e patient object receives the instruction (the message) and does what it needs to do to insert the new patient into the sys- tem (the behavior).

Sequence Diagrams Sequence diagrams are one of two types of interaction diagrams. Th ey illustrate the objects that participate in a use case and the messages that pass between them over time for one use case. A sequence diagram is a dynamic model that shows the explicit sequence of messages that are passed between objects in a defi ned interaction. Because sequence diagrams empha- size the time-based ordering of the activity that takes place among a set of objects, they are very helpful for understanding real-time specifi cations and complex use cases.

Th e sequence diagram can be a generic sequence diagram that shows all possible scenar- ios1 for a use case, but usually each analyst develops a set of instance sequence diagrams, each of which depicts a single scenario within the use case. If you are interested in understanding the fl ow of control of a scenario by time, you should use a sequence diagram to depict this information. Th e diagrams are used throughout the analysis and design phases. However, the design diagrams are very implementation specifi c, oft en including database objects or specifi c user interface components as the objects.

Elements of a Sequence Diagram Figure 6-1 shows an instance sequence diagram that depicts the objects and messages for the Make Old Patient Appt use case, which describes the process by which an existing patient creates a new appointment or cancels or reschedules an appointment

1 Remember that a scenario is a single executable path through a use case.

Interaction Diagrams  205

RequestAppt(name, address)

NewCancelChangeAppt?()

ApptTimes?()

aPatient

LookUpPatient()

aReceptionist

[aPatient Exists] LookupBills()

MatchAppts()

CreateAppt()

aPatient:Patient :UnpaidBill :Appointment

sd Make Appt Use Case

FIGURE 6-1    Example Sequence Diagram

for the doctor’s offi ce appointment system. In this specifi c instance, the Make Old Patient Appt process is portrayed.

Actors and objects that participate in the sequence are placed across the top of the dia- gram using actor symbols from the use-case diagram and object symbols from the object diagram (see Figure 6-2). Notice that the actors and objects in Figure 6-1 are aPatient, aRe- ceptionist, aPatient, UnpaidBill, and Appointment.2 For each of the objects, the name of the class of which they are an instance is given aft er the object’s name (e.g., aPatient means that aPatient is an instance of the Patient class).

A dotted line runs vertically below each actor and object to denote the lifeline of the actors and objects over time (see Figure 6-1).3 Sometimes an object creates a temporary object; in this case, an X is placed at the end of the lifeline at the point where the object is destroyed (not shown). For example, think about a shopping cart object for a Web com- merce application. Th e shopping cart is used for temporarily capturing line items for an order, but once the order is confi rmed, the shopping cart is no longer needed. In this case, an X would be located at the point at which the shopping cart object is destroyed. When objects continue to exist in the system aft er they are used in the sequence diagram, then the lifeline continues to the bottom of the diagram (this is the case with all of the objects in Figure 6-1).

2 In some versions of the sequence diagram, object symbols are used as surrogates for the actors. However, for clarity, we recommend using actor symbols for actors instead. 3 Technically speaking, in UML 2.0 the lifeline actually refers to both the object (actor) and the dashed line drawn vertically underneath the object (actor). However, we prefer to use the older terminology because it is more descriptive of what is actually being represented.

2 0 6 C h a p t e r 6   Behavioral Modeling

Context

An actor:

■ Is a person or system that derives benefit from and is external to the system. ■ Participates in a sequence by sending and/or receiving messages. ■ Is placed across the top of the diagram. ■ Is depicted either as a stick figure (default) or, if a nonhuman actor is involved, as

a rectangle with <<actor>> in it (alternative).

An object:

■ Participates in a sequence by sending and/or receiving messages. ■ Is placed across the top of the diagram.

A lifeline:

■ Denotes the life of an object during a sequence. ■ Contains an X at the point at which the class no longer interacts.

An execution occurrence:

■ Is a long narrow rectangle placed atop a lifeline. ■ Denotes when an object is sending or receiving messages.

A message:

■ Conveys information from one object to another one. ■ A operation call is labeled with the message being sent and a solid arrow, whereas

a return is labeled with the value being returned and shown as a dashed arrow.

A guard condition:

■ Represents a test that must be met for the message to be sent.

<<actor>> anActor

anActor

aMessage()

[aGuardCondition]:aMessage()

ReturnValue

For object destruction:

■ An X is placed at the end of an object’s lifeline to show that it is going out of existence.

A frame:

■ Indicates the context of the sequence diagram.

X

Term and Definition Symbol

anObject : aClass

FIGURE 6-2    Sequence Diagram Syntax

A thin rectangular box, called the execution occurrence, is overlaid onto the lifeline to show when the classes are sending and receiving messages (see Figure 6-2). A message is a communication between objects that conveys information with the expectation that

Interaction Diagrams  207

activity will ensue. Many diff erent types of messages can be portrayed on a sequence diagram. However, in the case of using sequence diagrams to model use cases, two types of messages are typically used: operation call and return. Operation call messages passed between objects are shown using solid lines connecting two objects with an arrow on the line showing which way the message is being passed. Argument values for the message are placed in parentheses next to the message’s name. Th e order of messages goes from the top to the bottom of the page, so messages located higher on the diagram represent messages that occur earlier on in the sequence, versus the lower messages that occur later. A return message is depicted as a dashed line with an arrow on the end of the line portraying the direction of the return. Th e information being returned is used to label the arrow. However, because adding return mes- sages tends to clutter the diagram, unless the return messages add a lot of information to the diagram, they can be omitted. For example, in Figure 6-1, no return messages are depicted.4 In Figure 6-1, LookUpPatient() is a message sent from the actor aReceptionist to the object aPatient to determine whether the aPatient actor is a current patient.

At times a message is sent only if a condition is met. In those cases, the condition is placed between a set of brackets, [ ]—for example, [aPatient Exists] LookupBills(). Th e condition is placed in front of the message name. However, when using a sequence diagram to model a specifi c scenario, conditions are typically not shown on any single sequence diagram. Instead, conditions are implied only through the existence of diff erent sequence diagrams.

An object can send a message to itself, e.g., Create Sandwich in Figure 6-3. Th is is known as self-delegation. Sometimes, an object creates another object. Th is is shown by the message being sent directly to an object instead of its lifeline.

Figure 6-3 portrays two additional examples of instance-specifi c sequence diagrams. Th e fi rst one is related to the Make Lunch use case that was described in the activity diagram por- trayed in Figure 4-10. Th e second one is related to the Place Order use case associated with the activity diagram in Figure 4-9. In both examples, the diagrams simply represent a single scenario. Notice in the Make Lunch sequence diagram there is a message being sent from an actor to itself [CreateSandwich()]. Depending on the complexity of the scenario being modeled, this particular message could have been eliminated. Obviously, both the process of making a lunch and placing an order can be quite a bit more complex. However, from a learning point of view, you should be able to see how the sequence diagrams and the activity diagrams relate to one another.

Guidelines for Creating Sequence Diagrams Ambler5 provides a set of guidelines when drawing sequence diagrams. In this section, we review six of them.

■ Try to have the messages not only in a top-to-bottom order but also, when possible, in a left -to-right order. Given that Western cultures tend to read left to right and top to bottom, a sequence diagram is much easier to interpret if the messages are ordered as much as possible in the same way. To accomplish this, order the actors and objects along the top of the diagram in the order that they participate in the scenario of the use case.

■ If an actor and an object conceptually represent the same idea, one inside of the soft ware and the other outside, label them with the same name. In fact, this implies that they exist in both the use-case diagram (as an actor) and in the class diagram

4 However, some CASE tools require the return messages to be displayed. Obviously, when you are using these tools, you have to include the return messages on the diagram. 5 S.W. Ambler, Th e Elements of UML 2.0 Style (Cambridge, England: Cambridge University Press, 2005).

2 0 8 C h a p t e r 6   Behavioral Modeling

(as a class). At fi rst glance, this might seem to lead to confusion. However, if they do indeed represent the same idea, then they should have the same name. For example, a customer actor interacts with the system and the system stores information about the customer. In this case, they do indeed represent the same conceptual idea.

■ Th e initiator of the scenario—actor or object—should be the drawn as the farthest left item in the diagram. Th is guideline is essentially a specialization of the fi rst guideline. In this case, it relates specifi cally to the actor or object that triggers the scenario.

■ When there are multiple objects of the same type, be sure to include a name for the object in addition to the class of the object. For example, in the making a lunch example (see Figure 6-3) there are two objects of type Parent. As such, they should be named. Otherwise, you can simply use the class name. Th is will simplify the diagram. In this case, the Child object did not have to be named. We could have simply placed a colon in front of the classname instead.

sd Make Lunch Use Case

sd Submit Order Use Case

MakeLunch

Lunch

aChild:Child firstParent:Parent secondParent:Parent

CreateLunch

Sandwich

Lunch

GetSandwich

Create Sandwich

SubmitOrderRequest()

OrderRejected

aCustomer:Customer aSalesPerson:SalesPerson

SubmitCreditRequest()

CreditDenied

aCustomer:Customer

FIGURE 6-3 Additional Sample Instance-Specifi c Sequence Diagrams

Interaction Diagrams  209

■ Show return values only when they are not obvious. Showing all of the returns tends to make a sequence diagram more complex and potentially diffi cult to comprehend. In many cases, less is more. Only show the returns that actually add information for the reader of the diagram.

■ Justify message names and return values near the arrowhead of the message and return arrows, respectively. Th is makes it much easier to interpret the messages and their return values.

Creating a Sequence Diagram In this section, we describe a six-step process used to create a sequence diagram.6 Th e fi rst step in the process is to determine the context of the sequence diagram. Th e context of the diagram can be a system, a use case, or a scenario of a use case. Th e context of the diagram is depicted as a labeled frame around the diagram (see Figures 6-1, 6-2, and 6-3). Most commonly, it is one use-case scenario. Figure 6-1 portrays the instance-specifi c sequence diagram for the scenario from the Make Old Patient Appt use case given in Figure 4-13 for making a new appointment for an existing patient. For each possible scenario for the Make Old Patient Appt use case, a separate instance-specifi c sequence diagram would be created. On the surface, this seems to be a lot of potentially redundant and useless work. However, at this point in the representation of a system, we are still trying to completely understand the problem. Th is process of creating instance-specifi c sequence diagrams for each scenario instead of creating a single generic sequence diagram for the entire use case will enable the developers to attain a more complete understanding of the problem being addressed. Each instance-specifi c sequence diagram is fairly simple to interpret, whereas a generic sequence diagram can be very complex. Th e testing of a specifi c use case is accomplished in a much easier manner by validating and verifying the complete- ness of the set of instance-specifi c sequence diagrams instead of trying to work through a single complex generic sequence diagram.

Th e second step is to identify the actors and objects that participate in the sequence being modeled—i.e., the actors and objects that interact with each other during the use-case scenario. Th e actors were identifi ed during the creation of the functional model, whereas the objects are identifi ed during the development of the structural model. Th ese are the classes on which the objects of the sequence diagram for this scenario will be based. One very useful approach to identifying all of the scenarios associated with a use case is to role-play the CRC cards (see Chapter 5). Th is can help you identify potentially missing operations that are necessary to support the business process, which the use case is representing, in a complete manner. Also, during role-playing, it is likely that new classes, and hence new objects, will be uncovered.7 Don’t worry too much about identifying all the objects perfectly; remember that the behavioral modeling process is iterative. Usually, the sequence diagrams are revised multiple times during the behavioral modeling processes.

Th e third step is to set the lifeline for each object. To do this, you need to draw a vertical dot- ted line below each class to represent the class’s existence during the sequence. An X should be placed below the object at the point on the lifeline where the object goes out of existence.

Th e fourth step is to add the messages to the diagram. Th is is done by drawing arrows to represent the messages being passed from object to object, with the arrow pointing in the message’s transmission direction. Th e arrows should be placed in order from the fi rst message

6 Th e approach described in this section is adapted from Grady Booch, James Rumbaugh, and Ivar Jacobson, Th e Unifi ed Modeling Language User Guide (Reading, MA: Addison-Wesley, 1999). 7 Th is obviously will cause you to go back and modify the structural model (see Chapter 5).

1. Set Context

2. Identify Actors and Objects

4. Add Messages

3. Set Lifeline

2 1 0 C h a p t e r 6   Behavioral Modeling

(at the top) to the last (at the bottom) to show time sequence. Any parameters passed along with the messages should be placed in parentheses next to the message’s name. If a message is expected to be returned as a response to a message, then the return message is not explicitly shown on the diagram.

Th e fi fth step is to place the execution occurrence on each object’s lifeline by drawing a narrow rectangle box over the lifelines to represent when the classes are sending and receiving messages.

Th e sixth and fi nal step is to validate the sequence diagram. Th e purpose of this step is to guarantee that the sequence diagram completely represents the underlying process. Th is is done by guaranteeing that the diagram depicts all the steps in the process.8

Campus Housing Example In Chapters 4 and 5, we created a set of functional and structural models for the campus housing service. In this section, we are going to use those models to create a sequence diagram for the Add Apartment use case. As stated above, the fi rst thing we should do is to set the context, which is in this case the Add Apartment use case. Second, we must identify the actors and objects that will participate in the execution of the use case. To do this, we should review the functional and structural models that were created for the campus housing service problem in Chapters 4 and 5. Figure 6-4 replicates these representations.

5. Place Execution Occurrence

6. Validate

Campus Housing System

Apartment Owner

Add Apartment

Delete Apartment

* * *

* *

* Student

Search Available Rental Units

Campus Housing Use-Case Diagram (Figure 4-15)

8 We describe validation in more detail later in this chapter.

Capture Location

Capture Number of Bedrooms

Capture Monthly Rent

Add Apartment

Capture Apartment Identifier

Delete Apartment

Campus Add and Delete Apartment Activity Diagrams (Figure 4-16)

FIGURE 6-4    Campus Housing Service Functional and Structural Models

Interaction Diagrams  211

Use Case Name:

Primary Actor:

Stakeholders and Interests:

Brief Description:

ID: Importance Level:

Trigger:

Normal Flow of Events:

SubFlows:

Alternate/Exceptional Flows:

Type: External

Add Apartment 1 High

Apartment Owner

Apartment Owner – wants to advertise available apartment Campus Housing Service – provides a service that enables the apartment owners to rent their available apartments

Use Case Type: Detail, Essential

Apartment Owner wants to add an available apartment

Apartment Owner

1. Capture the location of the apartment. 2. Capture the number of bedrooms in the apartment. 3. Capture the monthly rent of the apartment. 4. Add the apartment to the listing of available apartments.

This use case describes how the campus housing service can maintain an up-to-date listing of available apartments.

Relationships: Association: Include: Extend: Generalization:

Campus Housing Service Add an Apartment Use Case Description (Figure 4-17)

Use Case Name:

Primary Actor:

Stakeholders and Interests:

Brief Description:

ID: Importance Level:

Trigger:

Normal Flow of Events:

SubFlows:

Alternate/Exceptional Flows:

Type: External

Delete Apartment 2 High

Apartment Owner

Apartment Owner – wants to delist apartment Campus Housing Service – provides a service that enables the apartment owners to rent their available apartments

Use Case Type: Detail, Essential

Apartment Owner wants to delete an available apartment

Apartment Owner

1. Capture the apartment identifier. 2. Delete the apartment from the listing of available apartments.

This use case describes how the campus housing service can maintain an up-to-date listing of available apartments.

Relationships: Association: Include: Extend: Generalization:

Campus Housing Service Delete an Apartment Use Case Description (Figure 4-18)

FIGURE 6-4    Continued

2 1 2 C h a p t e r 6   Behavioral Modeling

Based on the functional and structural representations, we see that the actors involved in the use case are the Apartment Owner and the Campus Housing Service itself. By looking through the Normal Flow of Events and the activity diagram, we see that the only object that seems to be relevant is the instance of the Apartment class that is being added. Given that there are no Alternate/Exceptional Flows or any decisions being made in the Normal Flow of Events, nor are there any decisions in the activity diagram associated with the Add

Front:

Class Name: Apartment Owner ID: 1

Delete Apartment

Add Apartment Responsibilities

Associated Use Cases: 2Description: An apartment owner who has apartments for rent

Type: Concrete, Domain

Apartment

Apartment

Collaborators

Back:

Attributes:

Address (address)

Phone number (phone number)

Email (Email address)

Name (string)

Relationships:

Generalization (a-kind-of):

Aggregation (has-parts):

Other Associations: Apartment

Campus Housing Apartment Owner CRC Card (Figure 5-16)

Apartment Owner Apartment

0..1 0..*

Campus Housing Class Diagram (Figure 5-17)

FIGURE 6-4    Continued

Interaction Diagrams  213

Apartment use case, there is only one scenario to be portrayed. Consequently, there is only one instance-specifi c sequence diagram to be created. Figure 6-5 depicts the sequence dia- gram for this use case.

Library Example In the previous chapters, we have demonstrated the diagramming and modeling processes using the Borrow Books use case of the Library Book Collection Man- agement System. When considering instance-specifi c scenario diagrams, we need to draw one sequence diagram per scenario. In the case of the Borrow Books use case in Chapter 4, there are nine diff erent scenarios. Th erefore, for this one use case, there would be nine separate diagrams. In this example, we are setting the context of the sequence diagram to only one specifi c scenario of the Borrow Books use case: Students who have a valid ID and do not have any overdue books or any fi nes. Th e other scenarios include Students without a valid ID, Students with a valid ID but who owe fi nes or have overdue books, and the same three sce- narios for the other two types of Borrowers: Faculty/Staff and Guest. In this example, we are only drawing the one sequence diagram for the Students with a valid ID scenario. To begin with, we should review the Flow of Events of the use-case description (see Figure 6-6), the activity diagram (see Figure 6-7), and the use-case diagram (see Figure 6-8).

Add Apartment()

Apartment Information

Request Apartment Information()

anApartment

Apartment Owner Campus Housing Service

Create(ApartmentInformation)

anApartment

Apartment

FIGURE 6-5 Sequence Diagram for the Add Apartment Use Case

FIGURE 6-6    Flow of Events Section of the Use-Case Description of the Borrow Books Use Case

Normal Flow of Events:

SubFlows:

1. The Borrower brings books to the Librarian at the check out desk. 2. The Borrower provides Librarian their ID card. 3. The Librarian checks the validity of the ID Card. If the Borrower is a Student Borrower, Validate ID Card against Registrar’s Database. If the Borrower is a Faculty/Staff Borrower, Validate ID Card against Personnel Database. If the Borrower is a Guest Borrower, Validate ID Card against Library’s Guest Database. 4. The Librarian checks whether the Borrower has any overdue books and/or fines. 5. The Borrower checks out the books.

Alternate/Exceptional Flows: 4a. The ID Card is invalid, the book request is rejected. 5a. The Borrower either has overdue books, fines, or both, the book request is rejected.

2 1 4 C h a p t e r 6   Behavioral Modeling

FIGURE 6-7 Activity Diagram of the Borrow Books Use Case (Figure 4-12)

Validate ID Card

Check for Overdue Books and Fines

Check Out Books

[Valid Card]

[No Overdue Books & No Fines]

FIGURE 6-8 Use-Case Diagram for the Library Book Collection Management System (Figure 4-6)

Process Overdue Books

Library Book Collection

Management System

Maintain Book Collection

Borrow Books

Search Collection

Return Books

*

* * *

*

*

*

*

* *

*

*

<<actor>> Personnel Office

<<actor>> Registrar Office

Librarian

*

Borrower

Interaction Diagrams  215

Th e next step is to identify the actors and objects involved in the scenario. By study- ing the fl ow of events and the use-case diagram, we identify students, librarians, and the registrar’s database as actors and borrowers, the book collection, and books as the objects. We place the actors and objects across the top of the diagram based on the ordering of their appearance in the normal fl ow of events. Th e next step involves simply drawing the lifelines beneath the actors and objects in the scenario. Th e fourth step is to add the actual messages to the diagram. To do this, we again review the actual steps taken when executing this scenario by reviewing the fl ow of events (see Figure 6-6) and the activity diagram (see Figure 6-7). We also should review any results from the role-playing of the CRC cards (see Chapter 5). Th is will help us to properly portray where the functionality is located. For example, in Figure 6-9, the Librarian executes the CheckOutBooks() pro- cedure (the Student sends the message CheckOutBooks () to ask the Librarian to execute the CheckOutBooks () procedure) when the student hands the librarian the books to check out. Th e Librarian in return asks the Student for the ID card. When the student hands the ID Card to the Librarian, the Librarian asks the Registrar’s Database to exe- cute the ValidID() procedure when the Librarian passes the student’s ID number over to the database system to ask the database system to validate the student’s ID number. Th is continues until the ID Card and Books are returned to the student. Once we have decided from whom the messages are to be sent and to whom they are sent, we can place the messages on the diagram. Th e fi fth step then is to add the execution occurrence to the diagrams to  show when each actor or object is in the process of executing one of its operations. Next, we must validate the diagram. Finally, we should replicate this process for the other eight scenarios.

FIGURE 6-9 Sequence Diagram of the Borrow Books Use Case for Students with a Valid ID and No Overdue Books or Fines

sd Borrow Books Use Case

:Student

Books

BookAccts

FindBook(BookID)

BookAcct

FindBooks(BookID)

No

ValidID(ID Number)

Yes

ID

IDCard?()

CheckOutBooks(Books)

:Librarian Registrar’s Database :Book:Fine Database :BookCollection

Overdue Books or Fines(ID)

2 1 6 C h a p t e r 6   Behavioral Modeling

Communication Diagrams Communication diagrams, like sequence diagrams, essentially provide a view of the dynamic aspects of an object-oriented system. Th ey can show how the members of a set of objects collaborate to implement a use case or a use-case scenario. Th ey can also be used to model all the interactions among a set of collaborating objects, in other words, a collabora- tion (see CRC cards in Chapter 5). In this case, a communication diagram can portray how dependent the diff erent objects are on one another.9 A communication diagram is essen- tially an object diagram that shows message-passing relationships instead of aggregation or generalization associations. Communication diagrams are very useful to show process patterns (i.e., patterns of activity that occur over a set of collaborating classes).

Communication diagrams are equivalent to sequence diagrams, but they emphasize the fl ow of messages through a set of objects, whereas the sequence diagrams focus on the time ordering of the messages being passed. Th erefore, to understand the fl ow of control over a set of collaborating objects or to understand which objects collaborate to support business processes, a communication diagram can be used. For time ordering of the messages, a sequence diagram should be used. In some cases, both can be used to more fully understand the dynamic activity of the system.

Elements of a Communication Diagram Figure 6-10 shows a communication diagram for the Make Old Patient Appt use case. Like the sequence diagram in Figure 6-1, the Make Old Patient Appt process is portrayed.

Actors and objects that collaborate to execute the use case are placed on the commu- nication diagram in a manner to emphasize the message passing that takes place between them. Notice that the actors and objects in Figure 6-10 are the same ones in Figure 6-1: aPatient, aReceptionist, aPatient, UnpaidBill, and Appointment.10 Again, as with the sequence diagram, for each of the objects, the name of the class of which they are an instance is given after the object’s name (e.g., aPatient: Patient). (The communication

9 We return to this idea of dependency in Chapters 7 and 8. 10 In some versions of the communication diagram, object symbols are used as surrogates for the actors. However, again we recommend using actor symbols for actors instead.

FIGURE 6-10    Sample Communication Diagram

sd Make Appt Use Case

aPatient

1: RequestAppt(name, address)

4: NewCancelChangeAppt?

5: ApptTimes?

aReceptionist

2: L ook

UpP atie

nt()

3: [aPatient Exists] LookupBills()

7: CreateAppt()

6: MatchAppts()

:Appointment

aPatient:Patient

:UnpaidBill

Interaction Diagrams  217

diagram syntax is given in Figure 6-11.) Unlike the sequence diagram, the communica- tion diagram does not have a means to explicitly show an object being deleted or created. It is assumed that when a delete, destroy, or remove message is sent to an object, it will go out of existence, and a create or new message will cause a new object to come into existence. Another difference between the two interaction diagrams is that the communi- cation diagram never shows returns from message sends, whereas the sequence diagram can optionally show them.

An association is shown between actors and objects with an undirected line. For exam- ple, an association is shown between the aPatient and aReceptionist actors. Messages are shown as labels on the associations. Included with the labels are lines with arrows showing the direction of the message being sent. For example, in Figure 6-10, the aPatient actor sends the RequestAppt() message to the aReceptionist actor, and the aReceptionist actor

FIGURE 6-11   Communication Diagram Syntax

An actor:

■ Is a person or system that derives benefit from and is external to the system. ■ Participates in a collaboration by sending and/or receiving messages.

An object:

■ Participates in a collaboration by sending and/or receiving messages.

An association:

■ Shows an association between actors and/or objects. ■ Is used to send messages.

A message:

■ Conveys information from one object to another one. ■ Has direction shown using an arrowhead. ■ Has sequence shown by a sequence number.

A frame:

■ Indicates the context of the communication diagram.

A guard condition:

■ Represents a test that must be met for the message to be sent.

<<actor>> anActor

anActor

Context

SeqNumber: aMessage

SeqNumber: [aGuardCondition]: aMessage

Term and Definition Symbol

■ Is depicted either as a stick figure (default) or, if a nonhuman actor is involved, as a rectangle with <<actor>> in it (alternative).

anObject : aClass

2 1 8 C h a p t e r 6   Behavioral Modeling

sends the NewCancelChangeAppt?() and the ApptTimes?() messages to the aPatient actor. Th e sequence of the message sends is designated with a sequence number. In Figure 6-10, the RequestAppt() message is the fi rst message sent, whereas the NewCancelChangeAppt?() and the ApptTimes?() messages are the fourth and fi ft h message sent, respectively.

Like the sequence diagram, the communication diagram can represent conditional mes- sages. For example, in Figure 6-10, the LookupBills() message is sent only if the [aPa- tient exists] condition is met. If a message is repeatedly sent, an asterisk is placed aft er the sequence number. Finally, an association that loops onto an object shows self-delegation. Th e message is shown as the label of the association.

When a communication diagram is fully populated with all the objects, it can become very complex and diffi cult to understand. When this occurs, it is necessary to simplify the diagram. One approach to simplifying a communication diagram, like use-case diagrams (see Chapter 4) and class diagrams (see Chapter 5), is through the use of packages (i.e., logical groups of classes). In the case of communication diagrams, its objects are grouped together based on the messages sent to and received from the other objects.11

Figure 6-12 provides two additional examples of communication diagrams. Th ese dia- grams are equivalent to the sequence diagrams contained in Figure 6-3. However, when comparing the communication diagrams to the sequence diagrams in these fi gures, you see that quite a bit of information is lost. For example, the CreateSandwich() message is nowhere to be found. However, the primary purpose of the communication diagram is to show how the diff erent actors and classes interact, and this is exactly the information that is included.

Guidelines for Creating Communication Diagrams Ambler12 provides a set of guidelines when drawing communication diagrams. In this section, in addition to the fi rst four guide- lines for drawing sequence diagrams, we consider two more.

■ Use the correct diagram for the information you are interested in communicating with the user. Communication diagrams allow the team to easily identify a set of objects that are intertwined. Do not use communication diagrams to model process fl ow. Instead, you should use an activity diagram with swimlanes that represent

11 For those familiar with structured analysis and design, packages serve a purpose similar to the leveling and bal- ancing processes used in data fl ow diagramming. Packages and package diagrams are described in Chapter 7. 12 S.W. Ambler, Th e Elements of UML 2.0 Style (Cambridge, England: Cambridge University Press, 2005).

FIGURE 6-12 Additional Sample Communication Diagrams

sd Make Lunch Use Case

2: CreateLunch 3: GetSandwich1: MakeLunch

aChild:Child firstParent:Parent secondParent:Parent

sd Submit Order Use Case

aCustomer:Customer 1: SubmitOrderRequest() 2: SubmitCreditRequest()

aCustomer:Customer aSalesPerson:SalesPerson

Interaction Diagrams  219

objects (see Chapter 4). On the other hand, it would be very diffi cult to “see” how the objects collaborated in an activity diagram.

■ When trying to understand the sequencing of messages, a sequence diagram should be used instead of a communication diagram. As in the previous guideline, this guide- line essentially suggests that you should use the diagram that was designed to deal with the issue at hand. Even though communication diagrams can show sequencing of messages, this was never meant to be their primary purpose.

Creating a Communication Diagram13 Remember that a communication diagram is basically an object diagram that shows message-passing relationships instead of aggregation or generalization associations. In this section, we describe a fi ve-step process used to build a communication diagram. Th e fi rst step in the process is to determine the context of the com- munication diagram. Like a sequence diagram, the context of the diagram can be a system, a use case, or a scenario of a use case. Th e context of the diagram is depicted as a labeled frame around the diagram (see Figures 6-10, 6-11, and 6-12).

Th e second step is to identify the objects (actors) and the associations that link the objects (actors) that participate in the collaboration together. Remember, the objects that partici- pate in the collaboration are instances of the classes identifi ed during the development of the structural model (see Chapter 5). Like the sequence-diagramming process, it is likely that additional objects, and hence classes, will be discovered. Again, this is normal because the underlying development process is iterative and incremental. In addition to the com- munication diagram being modifi ed, the sequence diagrams and structural model probably also have to be modifi ed. Additional functional requirements might also be uncovered, hence requiring the functional models to be modifi ed as well (see Chapter 4).

Th e third step is to lay out the objects (actors) and their associations on the communication diagram by placing them together based on the associations that they have with the other objects in the collaboration. By focusing on the associations between the objects (actors) and minimizing the number of associations that cross over one another, we can increase the understandability of the diagram.

Th e fourth step is to add the messages to the associations between the objects. We do this by adding the name of the message(s) to the association link between the objects and an arrow showing the direction of the message being sent. Each message has a sequence num- ber associated with it to portray the time-based ordering of the message.14

Th e fi fth and fi nal step is to validate the communication diagram. Th e purpose of this step is to guarantee that the communication diagram faithfully portrays the underlying pro- cess(es). Th is is done by ensuring that all steps in the process are depicted on the diagram.

Campus Housing Example As with the sequence diagram example, we return to the Add Apartment use case for the Campus Housing Service. To begin with, we again set the context for the communication diagram (the Add Apartment use case). Next, we identify the objects (Apartment), actors (Apartment Owner and Campus Housing Service), and

13 Th e approach described in this section is adapted from Booch, Rumbaugh, and Jacobson, Th e Unifi ed Modeling Language User Guide. 14 However, remember the sequence diagram portrays the time-based ordering of the messages in a top-down manner. If your focus is on the time-based ordering of the messages, we recommend that you also use the sequence diagram.

1. Set Context

3. Lay Out Diagram

4. Add Messages

2. Identify Objects, Actors, &

Associations

5. Validate

2 2 0 C h a p t e r 6   Behavioral Modeling

associations (links between the Apartment Owner actor and the Campus Housing Service actor and links between the Campus Housing Service actor and the Apartment object). Using this information, we lay out the diagram showing the actors, objects, and associ- ations between them. Finally, we label the associations with the appropriate messages. Figure 6-13 depicts the communication diagram for this use case.

Library Example As with the sequence diagramming example, we return to the Borrow Books use case of the Library Book Collection Management System. In this case, to set the context of the diagram, we visit the Student without a valid ID and Student with a Valid ID but owes fi nes or has overdue books scenarios. We create two communication diagrams, one for each scenario. As with the sequence-diagramming process, we review the Flow of Events of the use-case description (see Figure 6-6), the activity diagram (see Figure 6-7), and the use case diagram (see Figure 6-8).

Th e next step is to identify the actor, objects, and associations involved in the scenario. In both scenarios, the actors are Student, Librarian, and the Registrar’s Database. However, because the process is aborted very early in the Student without a valid ID scenario, there are no objects in the scenario. Th e Student with a Valid ID but owes fi nes or has overdue books scenario does include one object: Borrower. Both scenarios have an association between the Student and Librarian actors and the Librarian and Registrar’s Database actor. Th e Student with a Valid ID but owes fi nes or has overdue books scenario also has an association between the Librarian actor and the Borrower object.

Th e next step is to lay out the diagram. In both cases, because the student initiates the process, we place the Student actor to the far left of the diagram. We then place the other actors on the diagram in the order in which they participate in the process. We also place the :Borrower object to the far bottom right of the diagram that represents the Student with a Valid ID but owes fi nes or has overdue books scenario to refl ect the left -to-right and top-to-bottom direction of reading for most Western cultures.

Now we place the relevant associations between the actors and objects that participate in the scenarios. In this step, we add the messages to the associations. We again review the fl ow of events (see Figure 6-6) of the use-case description to identify the directionality and con- tent of the messages. Figures 6-14 and 6-15 portray the communication diagrams created.

FIGURE 6-13 Communication Diagram for the Add Apartment Use Case

Apartment

1: Add Apartment

2: RequestApartmentinformation 3: Create(ApartmentInformation)

Apartment Owner Campus Housing Service

FIGURE 6-14 Communication Diagram for the Student without a Valid ID

sd Borrow Books Use Case

:Student

1: Checkout Books (Books)

2: IDCard?()

:Librarian

3: ValidID(IDNumber) Registrar’s Database

Behavioral State Machines  221

Th e last step is to validate the diagrams. As with sequence diagrams, because we are drawing instance specifi c versions of the communication diagram, we must also draw the remaining seven diagrams for the other scenarios.

BEHAVIORAL STATE MACHINES Some of the classes in the class diagrams represent a set of objects that are quite dynamic in that they pass through a variety of states over the course of their existence. For example, a patient can change over time from being new to current to former based on his or her status with the doctor’s offi ce. A behavioral state machine is a dynamic model that shows the diff er- ent states through which a single object passes during its life in response to events, along with its responses and actions. Typically, behavioral state machines are not used for all objects; rather, behavioral state machines are used with complex objects to further defi ne them and to help simplify the design of algorithms for their methods. Th e behavioral state machine shows the diff erent states of the object and what events cause the object to change from one state to another. Behavioral state machines should be used to help understand the dynamic aspects of a single class and how its instances evolve over time15 unlike interaction diagrams that show how a particular use case or use-case scenario is executed over a set of classes.

In this section, we describe states, events, transitions, actions, and activities. We also explain how behavioral state machines model the state changes through which complex objects pass. As with interaction diagrams, when we create a behavioral state machine for an object, it is possible that we will uncover additional events that need to be included in the functional model (see Chapter 4) and additional operations that need to be included in the structural model (see Chapter 5), so our interaction diagrams might have to be modifi ed again. Because object-oriented development is iterative and incremental, this continuous modifi cation of the evolving models (functional, structural, and behavioral) of the system is to be expected.

States, Events, Transitions, Actions, and Activities Th e state of an object is defi ned by the value of its attributes and its relationships with other objects at a particular point in time. For example, a patient might have a state of new, current, or former. Th e attributes or properties of an object aff ect the state that it is in; however, not

15 Some authors refer to this as modeling an object’s life cycle.

FIGURE 6-15 Communication Diagram for the Student with a Valid ID but Owes Fines or Has Overdue Books

sd Borrow Books Use Case

:Student

1: Checkout Books (Books)

2: IDCard?()

:Librarian

3: ValidID(IDNumber)

4: Overdue Books or Fines()

:Borrower

Registrar’s Database

2 2 2 C h a p t e r 6   Behavioral Modeling

all attributes or attribute changes will make a diff erence. For example, think about a patient’s address. Th ose attributes make very little diff erence to changes in a patient’s state. However, if states were based on a patient’s geographic location (e.g., in-town patients were treated diff er- ently than out-of-town patients), changes to the patient’s address would infl uence state changes.

An event is something that takes place at a certain point in time and changes a value or values that describe an object, which, in turn, changes the object’s state. It can be a des- ignated condition becoming true, the receipt of the call for a method by an object, or the passage of a designated period of time. Th e state of the object determines exactly what the response will be.

A transition is a relationship that represents the movement of an object from one state to another state. Some transitions have a guard condition. A guard condition is a Boolean expression that includes attribute values, which allows a transition to occur only if the condi- tion is true. An object typically moves from one state to another based on the outcome of an action triggered by an event. An action is an atomic, nondecomposable process that cannot be interrupted. From a practical perspective, actions take zero time, and they are associated with a transition. In contrast, an activity is a nonatomic, decomposable process that can be interrupted. Activities take a long period of time to complete, and they can be started and stopped by an action.

Elements of a Behavioral State Machine Figure 6-16 presents an example of a behavioral state machine representing the patient class in the context of a hospital environment. From this diagram, we can tell that a patient enters a hospital and is admitted aft er checking in. If a doctor fi nds the patient to be healthy, he or she is released and is no longer considered a patient aft er two weeks elapse. If a patient is found to be unhealthy, he or she remains under observation until the diagnosis changes.

A state is a set of values that describes an object at a specifi c point in time and represents a point in an object’s life in which it satisfi es some condition, performs some action, or waits for something to happen (see Figure 6-17). In Figure 6-16 states include entering, admitted, released, and under observation. A state is depicted by a state symbol, which is a rectangle with rounded corners with a descriptive label that communicates a particular state. Th ere are two exceptions. An initial state is shown using a small, fi lled-in circle, and an object’s fi nal state is shown as a circle surrounding a small, fi lled-in circle. Th ese exceptions depict when an object begins and ceases to exist, respectively.

FIGURE 6-16    Sample Behavioral State Machine Diagram

Patient

Enters Hospital Checks In [Diagnosis = Healthy] [> 2 weeks] Entering Admitted Released

Under Observation

[Diagnosis = Unhealthy]

[Diagnosis = Healthy]

Behavioral State Machines  223

FIGURE 6-17    Behavioral State Machine Diagram Syntax

A state:

■ Is shown as a rectangle with rounded corners. ■ Has a name that represents the state of an object.

An initial state:

■ Is shown as a small, filled-in circle. ■ Represents the point at which an object begins to exist.

A final state:

■ Is shown as a circle surrounding a small, filled-in circle (bull's-eye). ■ Represents the completion of activity.

An event:

■ Is a noteworthy occurrence that triggers a change in state. ■ Can be a designated condition becoming true, the receipt of an explicit signal

from one object to another, or the passage of a designated period of time. ■ Is used to label a transition.

A transition:

■ Indicates that an object in the first state will enter the second state. ■ Is triggered by the occurrence of the event labeling the transition. ■ Is shown as a solid arrow from one state to another, labeled by the event name.

A frame:

■ Indicates the context of the behavioral state machine. Context

anEvent

aState

Term and Definition Symbol

Arrows are used to connect the state symbols, representing the transitions between states. Each arrow is labeled with the appropriate event name and any parameters or condi- tions that may apply. For example, the two transitions from admitted to released and under observation contain guard conditions. As in the other behavioral diagrams, in many cases it is useful to explicitly show the context of the behavioral state machine using a frame.

Figure 6-18 depicts two additional behavioral state machines. Th e fi rst one is for the lunch object that was associated with the Make Lunch use-case scenario of Figures 6-3 and 6-12. In this case, there is obviously additional information that has been captured about the lunch object. For example, the scenario of Figures 6-3 and 6-12 did not include information regarding the lunch being taken out of the box or being eaten. Th is implies additional use cases and/or use-case scenarios that would have to be included in a system dealing with lunch processing. Th e second behavioral state machine deals with the life cycle of an order. Th e order object is associated with the submit order use-case scenario described in Figures 6-3 and 6-12. As in the lunch example, there is quite a bit of additional informa- tion contained in this behavioral state machine. For an order-processing system, additional

224

F IG

U R

E 6

-1 8

   A

d d

it io

n al

B e

h av

io ra

l S

ta te

M ac

h in

e D

ia g

ra m

s

O rd

er

D en

ie d

O rd

er i s

cr ea

te d

C u st

o m

er su

b m

it s

o rd

er

C u st

o m

er ed

it s

o rd

er in

fo rm

at io

n

A u th

o ri

za ti

o n

= D

en ie

d

O rd

er s

en t

fo r

cr ed

it au

th o ri

za ti

o n

C u st

o m

er w

it h d ra

w s

o rd

er r

eq u es

t

O rd

er s

en t to

cu st

o m

er

C u

st o

m er

ac ce

p ts

sh ip

m en

t R

ec ei

ve d

A u th

o ri

za ti

o n

= A

p p ro

ve d

O rd

er i s

cl o

se d

In P

ro ce

ss O

rd er

ed P ro

ce ss

in g

P la

ce d

Sh ip

p ed

Lu n ch

[C re

at ed

] [P

la ce

d In

B o x]

[T ak

en O

u tO

fB o x]

[E at

en ]

C re

at ed

P ac

ke d

B ei

n g

Ea te

n

Behavioral State Machines  225

sequence and communication diagrams would be necessary to completely represent all the processing associated with an order object. Obviously, because behavioral state machines can uncover additional processing requirements, they can be very useful in fi lling out the complete description of an evolving system.

Sometimes, states and subclasses can be confused. For example, in Figure 6-19, are the classes Freshman, Sophomore, Junior, and Senior subclasses of the class Undergraduate or are they states that an instance of the Undergraduate class goes through during its lifetime? In this case, the latter is the better answer. When trying to identify all potential classes

Graduate

Student

DoctoralMasters

Freshman

VS.

&

[Accepted]

SophomoreFreshman

Undergraduate

Undergraduate

SeniorJunior DoctoralMasters

Graduate

Student

Sophomore

[>30 Hours Earned]

Junior

[>60 Hours Earned]

Senior

[>90 Hours Earned]

[Graduate]

FIGURE 6-19    States versus Subclasses

2 2 6 C h a p t e r 6   Behavioral Modeling

during structural modeling (see Chapter 5), you might actually identify states of the rele- vant superclass instead of subclasses. Th is is another example of how tightly intertwined the functional, structural, and behavioral models can be. From a modeling perspective, although we eventually removed the Freshman, Sophomore, Junior, and Senior subclasses from the structural model, capturing that information during structural modeling and removing it based on discoveries made during behavioral modeling were preferable to omitting it and taking a chance of missing a crucial piece of information about the problem domain. Remember, object-oriented development is iterative and incremental. As we pro- gress to a correct model of the problem domain, we will make many mistakes.

Guidelines for Creating Behavioral State Machines As with the sequence and communi- cation diagrams, Amble suggests a set of guidelines when drawing behavior state machines. In this case, we consider six of his recommendations.16

■ Create a behavioral state machine for objects whose behavior changes based on the state of the object. In other words, do not create a behavioral state machine for an object whose behavior is always the same regardless of its state. Th ese objects are too simple.

■ To adhere to the left -to-right and top-to-bottom reading conventions of Western cultures, the initial state should be drawn in the top left corner of the diagram and the fi nal state should be drawn in the bottom right of the diagram.

■ Make sure that the names of the states are simple, intuitively obvious, and descrip- tive. For example in Figure 6-16, the state names of the patient object are Entering, Admitted, Under Observation, and Released.

■ Question black hole and miracle states. These types of states are problematic for the same reason black hole and miracle activities are a problem for activity diagrams (see Chapter 4). Black hole states, states that an object goes into and never comes out of, most likely are actually fi nal states. Miracle states, states that an object comes out of but never went into, most likely are initial states.

■ Be sure that all guard conditions are mutually exclusive (not overlapping). For example, in Figure 6-16, the guard condition [Diagnosis = Healthy] and the guard condition [Diagnosis = Unhealthy] do not overlap. However, if you created a guard condition of [x >= 0] and a second guard condition [x <= 0], the guard conditions overlap when x = 0, and it is not clear to which state the object would transition. Th is would obviously cause confusion.

■ All transitions should be associated with a message and operation. Otherwise, the state of the object could never change. Even though this may be stating the obvi- ous, there have been numerous times that analysts forget to go back and ensure that this is indeed true.

Creating a Behavioral State Machine Behavioral state machines are drawn to depict an instance of a single class from a class dia- gram. Typically, the classes are very dynamic and complex, requiring a good understanding of their states over time and events triggering changes. You should examine your class diagram to identify which classes undergo a complex series of state changes and draw a diagram for each of them. In this section, we describe a fi ve-step process used to build a behavioral state machine.17 Like the other behavioral models, the fi rst step in the process is determining the

16 S.W. Ambler, Th e Elements of UML 2.0 Style (Cambridge, England: Cambridge University Press, 2005). 17 Th e approach described in this section is adapted from Booch, Rumbaugh, and Jacobson, Th e Unifi ed Modeling Language User Guide.

1. Set Context

Behavioral State Machines  227

context of the behavioral state machine, which is shown in the label of the frame of the dia- gram. Th e context of a behavioral state machine is usually a class. However, it also could be a set of classes, a subsystem, or an entire system.

Th e second step is to identify the various states that an object will have over its lifetime. Th is includes establishing the boundaries of the existence of an object by identifying the initial and fi nal states of an object. We also must identify the states of an object. Th e information necessary to perform this is gleaned from reading the use-case descriptions, talking with users, and relying on the requirements-gathering techniques that you learned about in Chapter 3. An easy way to identify the states of an object is to write the steps of what hap- pens to an object over time, from start to fi nish, similar to how the normal fl ow of events section of a use-case description would be created.

Th e third step is to determine the sequence of the states that an object will pass through dur- ing its lifetime. Using this sequence, the states are placed onto the behavioral state machine in a left -to-right order.

Th e fourth step is to identify the transitions between the states of the objects and to add the events, actions, and guard conditions associated with the transitions. Th e events are the trig- gers that cause an object to move from one state to the next state. In other words, an event causes an action to execute that changes the value(s) of an object’s attribute(s) in a signifi cant manner. Th e actions are typically operations contained within the object. Also, guard condi- tions can model a set of test conditions that must be met for the transition to occur. At this point in the process, the transitions are drawn between the relevant states and labeled with the event, action, or guard condition.

Th e fi fth step is to validate the behavioral state machine by making sure that each state is reachable and that it is possible to leave all states except for fi nal states. Obviously, if an iden- tifi ed state is not reachable, either a transition is missing or the state was identifi ed in error. Only fi nal states can be a dead end from the perspective of an object’s life cycle.

Campus Housing Example Based on the functional and structural models for the campus housing service (see Figure 6-4), the sequence diagram for the Add Apartment use case (see Figure 6-5), and the communication diagram for the Add Apartment use case (see Figure 6-13), in this section, we are going to create a behavioral state machine for the Apartment class. By reviewing all of the representations, it is obvious that the behavioral state machine will be very simple. In this case, an apartment comes into existence when it is added and goes out of existence when it is deleted. Its only state is For Rent. Figure 6-20 depicts the behavioral state machine for this class.

2. Identify Object States

3. Lay Out Diagram

4. Add Transitions

5. Validate

FIGURE 6-20    Behavioral State Machine for the Apartment Class

[Add] [Delete] For Rent

2 2 8 C h a p t e r 6   Behavioral Modeling

FIGURE 6-21    Class Diagram for the Library Book Collection Management System

Check Out Trans

0..*

1..1

Borrower

1..1

0..*

Check Out Desk

Transaction Line Item Book Book Location

0..* 1..11..1 1..* 0..* 1..1

*

1

GuestStudent Faculty/Staff

Librarian

StorageInterlibrary Loan System Library

Book Collection

Library Example Th e fi rst step in drawing a behavioral state machine is to set the context. For our purposes, the context typically is an instance of a class that has multiple states and whose behavior depends upon the state in which it currently resides. As suggested earlier, we should review the class diagram (see Figure 6-21) to identify the “interesting” classes. In the case of the Library Book Collection Management System, the obvious class to consider is the Book class.

Th e next step is to identify the diff erent states through which an instance of the Book class can traverse during its lifetime. Good places to look for possible state changes are the use-case descriptions (see Figure 6-6), the activity diagrams (see Figure 6-7), the sequence diagrams (see Figure 6-9), and the communication diagrams (see Figures 6-14 and 6-15). In the case of a book, even though the states may be similar, you must be careful in identifying the states asso- ciated with an instance of the Book class and not the states associated with the physical book itself. In Chapter 5, we observed that there were a number of implied states to consider. Th ese included Checked Out, Overdue, Requested, Available, and Damaged. If the book is damaged, the book could either be repaired and put back into circulation or it could be too damaged to repair and be removed from circulation instead. Even though a Borrower could be fi ned for an overdue or damaged book, being fi ned is not a state of a book, it is a state of a borrower.

Next, we lay out the diagram by ordering the states in a sequential manner based on the life cycle of a book. For example, it probably makes no sense to have a book to go from a repaired state to a damaged state. However, going from a damaged state to a repaired state makes sense. Nor does it make sense for a book to go from an available state directly to an overdue state. However, the converse makes sense. Th e states we identifi ed for a book object include Available, Checked Out, Overdue, Requested, Damaged, and Being Repaired. Next we added the transitions between the states and labeled them with the appropriate guard

Crude Analysis  229

conditions. Th e behavioral state machine for an instance of the Book class is portrayed in Figure 6-22.

Finally, we validate the diagram by checking for missing states or transitions and ensur- ing that there are no black hole or miracle states.

CRUDE ANALYSIS One useful technique to identify how the underlying objects in the problem domain work together to collaborate in support of the use cases is CRUDE analysis.18 CRUDE analysis uses a CRUDE matrix , in which each interaction among objects is labeled with a letter for the type of interaction: C for create, R for read or reference, U for update, D for delete, and E for execute. In an object-oriented approach, a class/actor-by-class/actor matrix is used.19 Each cell in the matrix represents the interaction between instances of the classes. For example, in Figure 6-1, an instance of the Receptionist actor creates an instance of the Appointment class. Assuming a Row:Column ordering, a C is placed in the cell Receptionist:Appointment. Also, in Figure 6-1, an instance of the Receptionist actor references an instance of the Appointments class. In this case, an R is placed in the Receptionist:Appointments cell. Figure 6-23 shows the CRUDE matrix based on the Make Old Patient Appt use case.

Unlike the interaction diagrams and behavioral state machines, a CRUDE matrix is most useful as a system-wide representation. Once a CRUDE matrix is completed for the entire

FIGURE 6-22    Behavioral State Machine for an Instance of the Book Class in the Library Book Collection Management System

Book

Damaged

[Added To Collection]

[Borrower Checks in Book]

[Borrower Checks in Book]

[Borrower Checks in Book] [Another Borrower Requests Book]

[Borrowing Time Expires]

[Borrower Checks Out Book]

[Borrower Returns Book Damaged]

[Book Sent to be Repaired]

[Book Too Damaged]

[Book Repaired]

[Book Too Damaged][Book Taken Out of Circulation]

[Borrower Returns Book Damaged]

[Borrower Returns Book Damaged]

[Another Borrower Requests Book]

Checked Out Overdue

Being Repaired

Available Requested

18 CRUD analysis has typically been associated with structured analysis and design [see Alan Dennis, Barbara Haley Wixom and Roberta M. Roth, Systems Analysis Design, 3nd ed. (New York: Wiley, 2006)] and information engi- neering [see James Martin, Information Engineering, Book II Planning and Analysis (Englewood Cliff s, NJ: Prentice Hall, 1990)]. In our case, we have simply adapted it to object-oriented systems development. In the case of object orientation, we have added an E to allow us to document the execution of operations that do not create, read, update, or delete but that instead simply are executed for possible side-eff ect purposes. Specifi c details on collaborations are described in Chapter 7. 19 Another useful but more-detailed form of the CRUDE matrix is a Class/Actor:Operation-by-Class/Actor:Oper- ation matrix. For validation and verifi cation purposes, this more-detailed matrix is more useful. However, for our purposes at this point in our discussion, the Class/Actor-by-Class/Actor matrix is suffi cient.

2 3 0 C h a p t e r 6   Behavioral Modeling

FIGURE 6-23    CRUDE Matrix for the Make Old Patient Apt Use Case

Receptionist PatientList Patient UnpaidBills Appointments Appointment

Receptionist RU CRUD R RU CRUD

PatientList R

Patient

UnpaidBills

Appointments R

Appointment

FIGURE 6-24    Campus Housing Service CRUDE Matrix

Apartment Owner Actor

Student Actor

Apartment Owner Class

Apartment Class

Apartment Owner Actor C,D

Student Actor R R

Apartment Owner Class

Apartment Class

system, the matrix can be scanned quickly to ensure that every class can be instantiated. Each type of interaction can be validated for each class. For example, if a class represents only tem- porary objects, then the column in the matrix should have a D in it somewhere. Otherwise, the instances of the class will never be deleted. Because a data warehouse contains historical data, objects that are to be stored in one should not have any U or D entries in their associated columns. In this way, CRUDE analysis can be used as a way to partially validate the interac- tions among the objects in an object-oriented system. Finally, the more interactions among a set of classes, the more likely they should be clustered together in a collaboration. However, the number and type of interactions are only an estimate at this point in the development of the system. Care should be taken when using this technique to cluster classes to identify collaborations. We return to this subject in the next chapter when we deal with partitions and collaborations.

CRUDE analysis also can be used to identify complex objects. Th e more (C)reate, (U)pdate, or (D)elete entries in the column associated with a class, the more likely the instances of the class have a complex life cycle. As such, these objects are candidates for state modeling with a behavioral state machine.

Campus Housing Example In Chapters 4 and 5, we created a set of functional and structural models for the campus housing service. In this section, we are going to use those models as a basis for performing a CRUDE analysis. Th e fi rst thing we need to do is to identify all of the actors and the classes that are involved in the campus housing service example. In this case, the actors are apartment owner and student, and the classes are apartment owner and apart- ment. Given this, our CRUDE matrix is a 4x4 matrix. In this simple example, we only support creating, reading, and deleting instances. Specifi cally, an apartment owner actor can create and delete instances of apartment, while a student actor can read instances of apartment and apartment owner. Figure 6-24 depicts the CRUDE matrix for the campus housing service.

Crude Analysis  231

FIGURE 6-25    Corrected Campus Housing Service CRUDE Matrix

Apartment Owner Actor

Student Actor

Staff Member Actor

Apartment Owner Class

Apartment Class

Apartment Owner Actor C,D

Student Actor R R

Staff Member Actor C,D

Apartment Owner Class

Apartment Class

However, upon review of the matrix, even though instances of apartment owner are read, they are never created or deleted. Unless the instances of apartment owner are cre- ated with another system, this is an impossible situation. Th is is another example of why we follow an iterative and incremental approach in object-oriented systems development. In this case, by creating a CRUDE matrix, we discovered an additional requirement that had previously been overlooked. Consequently, we need to go back and add additional use cases that add and delete apartment owners that are associated with an additional campus housing service staff member actor that executes them (see Figure 6-25). Obviously, at this point in time we should modify the use-case diagram; add activity diagrams; add sequence diagrams; add communication diagrams; and review the class diagrams, CRC cards, and behavioral state machines to ensure that they are still correct. We will leave those modifi ca- tions to you and move on next to the library problem that we have been using in this and the previous chapters.

Library Example Th e best way to create a CRUDE matrix is to conceptually merge the sequence and communication diagrams that model all of the scenarios of all of the use cases in a system. Th e easiest way to accomplish this is simply to create an empty class/actor- by-class/actor matrix. In the case of the Library Book Collection Management System, we have six actors (Student, Faculty/Staff , Guest, Librarian, Personnel Offi ce, and Registrar’s Offi ce) and eight classes (Book, Book Collection, Student, Faculty/Staff , Guest, Interlibrary Loan System, Library, and Storage). Once this matrix has been laid out, role-playing the scenarios will show which actors and classes interact with each other. Based on the type of interaction, record a C, R, U, D, or E in the appropriate cell of the matrix. Do this repeat- edly until all of the scenarios of all of the use cases have been executed. Th e CRUDE matrix for the Library Book Collection Management System is shown in Figure 6-26. One of the functions that the matrix can serve is to begin the validation process of the entire system. In this case, by quickly reviewing the matrix we can see that absolutely nothing seems to be interacting with the Library and Storage objects. Th is raises an important question as to whether these objects should exist or not. If nothing calls or uses them and they don’t call or use anything, then why are they part of this system? Either they should be removed from the current representation of the system, or we have managed to miss some interac- tion. Knowing this allows us to go back to the user, in this case the Librarian, and ask what should be done.

St u d en

t A

ct o r

Fa cu

lt y/

St

af f

A ct

o r

G u es

t A

ct o r

L ib

ra ri

an

A ct

o r

Pe rs

o n

n el

O

ffi c

e A

ct o

r

R eg

is tr

ar ’s

O

ffi c

e A

ct o

r B

o o

k B

o o

k C

o ll

ec ti

o n

St u

d en

t C

la ss

Fa cu

lt y/

St

af f

C la

ss G

u es

t C

la ss

In te

rl ib

ra ry

Lo

an S

ys te

m Li

b ra

ry St

o ra

ge

St u d en

t A

ct o r

E R

,E R

E

Fa cu

lt y/

St af

f A

ct o r

E R

,E R

E

G u es

t A

ct o r

E R

,E R

E

Li b ra

ri an

A

ct o r

E E

E R

,E R

,E C

,R ,U

,D ,E

R ,U

,E R

,U R

,U C

,R ,U

,D ,E

R ,E

Pe rs

o n n el

O

ffi c

e A

ct o r

R eg

is tr

ar ’s

O

ffi c

e A

ct o r

B o o k

B o o k

C o ll ec

ti o n

St u d en

t C

la ss

Fa cu

lt y/

St af

f C

la ss

G u es

t C

la ss

In te

rl ib

ra ry

Lo

an S

ys te

m

Li b ra

ry

St o ra

ge

F IG

U R

E 6

-2 6

   C

R U

D E

M at

ri x

fo r

th e

L ib

ra ry

B o

o k

C o

ll e

ct io

n M

an ag

e m

e n

t S

ys te

m

232

Verifying and Validating the Behavioral Model  233

VERIFYING AND VALIDATING THE BEHAVIORAL MODEL20 In this chapter, we described three diff erent diagrams (sequence diagram, communication diagram, and behavioral state machine) and CRUDE matrices that could be used to represent the behavioral model. Th e sequence and communication diagrams modeled the interaction among instances of classes that work together to support the business processes included in a system, the behavioral state machine described the state changes through which an object traverses during its lifetime, and the CRUDE matrix represented a system-level overview of the interactions among the objects in the system. In this chapter, we combine walkthroughs with CRUDE matrices to more completely verify and validate the behavioral models. Since we covered CRUDE analysis and matrices in the previous section, we focus only on walk- throughs in this section. We again use the appointment system and focus on Figures 6-1, 6-10, 6-16, and 6-23 to describe a set of rules that can be used to ensure that the behavioral model is internally consistent.

First, every actor and object included on a sequence diagram must be included as an actor and an object on a communication diagram, and vice versa. For example, in Figures 6-1 and 6-10, the aReceptionist actor and the Patients object appear on both diagrams.

Second, if there is a message on the sequence diagram, there must be an association on the communications diagram, and vice versa. For example, Figure 6-1 portrays a message being sent from the aReceptionist actor to the Patient object, and a matching association appears in the corresponding communication diagram (see Figure 6-10).

Th ird, every message that is included on a sequence diagram must appear as a message on an association in the corresponding communication diagram, and vice versa. For example, the LookUpPatient() message sent by the aReceptionist actor to the Patient object on the sequence diagram (see Figure 6-1) appears as a message on the association between the aReceptionist actor and the Patient object on the communication diagram (see Figure 6-10).

Fourth, if a guard condition appears on a message in the sequence diagram, there must be an equivalent guard condition on the corresponding communication diagram, and vice versa. For example, the message sent from the aReceptionist actor to the UnpaidBills object has a guard condition of [aPatient Exists] (see Figure 6-1). Figure 6-10 shows the matching guard condition included on the communication diagram.

Fift h, the sequence number included as part of a message label in a communications diagram implies the sequential order in which the message will be sent. Th erefore, it must correspond to the top-down ordering of the messages being sent on the sequence diagram. For example, the LookUpPatient message sent from the aReceptionist actor to the Patient object on the sequence diagram (see Figure 6-1) is the second from the top of the diagram. Th e LookUpPatient message sent from the aReceptionist actor to the Patients object on the communications diagram (see Figure 6-10) is labeled with the number 2.21

Sixth, all transitions contained in a behavior state machine must be associated with a message being sent on a sequence and communication diagram, and it must be classifi ed as a (C)reate, (U)pdate, or (D)elete message in a CRUDE matrix. For example, in Figure 6-16 the Checks In transition must be associated with a message in the corresponding sequence and communication diagrams. Furthermore, it should be associated with an (U)pdate entry in the CRUDE matrix associated with the hospital patient system.

Seventh, all entries in a CRUDE matrix imply a message being sent from an actor or object to another actor or object. If the entry is a (C)reate, (U)pdate, or (D)elete, then there must be an

20 Th e material in this section has been adapted from E. Yourdon, Modern Structured Analysis (Englewood Cliff s, NJ: Prentice Hall, 1989). 21 Th ere are more complicated numbering schemes that could be used. However, for our purposes, a simple sequen- tial number is suffi cient.

2 3 4 C h a p t e r 6   Behavioral Modeling

FIGURE 6-27    Interrelationships among Behavioral Models

Including

HasKinds

Contains

HasKinds

Describe Contains Contains

Contains

AssociatedWith AssociatedWith

Interaction Diagram

Behavioral Models

Sequence DiagramCommunication Diagram

Objects Actors

Delete

Update

States

Create

Messages Cell Entries Transitions

CRUD Matrix

Associations

Read

Behavioral State Machine

22 We have delayed the description of designing operations and methods until Chapter 8. Th erefore, the detailed infor- mation required to understand a specifi c message has not been created yet. However, in many cases, enough information will already have been created to validate many of the transitions in behavioral state machines and CRUDE matrices. 23 A good reference for these types of restrictions is S.W. Ambler, Th e Elements of UML 2.0 Style (Cambridge, England: Cambridge University Press, 2005).

associated transition in a behavioral state machine that represents the instances of the receiving class. For example in Figure 6-23 the R and U entries in the Receptionist row and Appointments column imply that instances of the Receptionist actor will read and update instances of the Appointments class. Th us, there should be read and update messages on the sequence and communication diagrams corresponding with the appointments processes. Reviewing Figures 6-1 and 6-10, we see that there is a message, MatchAppts(), from the aReceptionist actor to the Appointments object. However, based on this review, it is unclear whether the MatchAppts() message represents a read, an update, or both. Th erefore, additional analysis is required.22 Because there is an (U)pdate message involved, there must be a transition on a behavioral state machine that portrays the life cycle of an Appointments object.

Finally, many representation-specifi c rules have been proposed. However, as in the other models, these rules are beyond the scope of this section on verifi cation and validation.23 Figure 6-27 portrays the associations among the behavioral models.

Key Terms  235

APPLYING THE CONCEPTS AT PATTERSON SUPERSTORE Aft er developing the functional and structural models, the project manager, Ruby Ross, tasked the team with developing the behavioral models for the Mobile Scheduling (Version 1) of the Integrated Health Clinic Delivery System. Th e behavioral models include the interactions diagram (sequence and communications) as well as the behavioral state machine. In addition, the team created a CRUDE matrix to analyze the collaboration between the objects identifi ed during structural modeling. While the structural model depicted the static aspects of the system, behavioral models show the internal dynamic aspects of the system. By modeling both the static (structural) and dynamic (behavioral) aspects of a system, object-oriented systems analysis and design attempts to view the underlying problem domain in a holistic way.

You can fi nd the rest of the case at: www.wiley.com/go/dennis/casestudy

CHAPTER REVIEW Aft er reading and studying this chapter, you should be able to:

Describe the purpose of the behavioral models. Describe the purpose of the interaction diagrams. Describe the diff erent elements of the sequence diagrams. Create a behavioral model using a sequence diagram. Describe the diff erent elements of the communication diagrams. Create a behavioral model using a communication diagram. Explain the purpose of a behavioral state machine. Describe the diff erent elements of the behavioral state machines. Create a behavioral model using a behavioral state machine. Describe the purpose of CRUDE analysis. Create a behavioral model using a CRUDE matrix. Verify and validate the evolving behavioral model using CRUDE analysis and walkthroughs. Verify and validate the functional model by ensuring the consistency of the four behavioral representations:

sequence diagrams, communication diagrams, behavioral state machines, and a CRUDE matrix.

KEY TERMS

Action Activity Actor Association Attributes Behavior Behavior models Behavioral state machines Black hole states Class Class diagram Collaboration

Communication diagram Condition CRC cards CRUDE analysis CRUDE matrix Dynamic model Event Execution occurrence Final state Frame Generic sequence diagram Guard condition

Initial state Instance Instance sequence

diagram Lifeline Message Method Miracle states Object Operation Operation call message Packages

Return message Scenario Self-delegation Sequence

diagram State State symbol Temporary object Transition Trigger Use case

2 3 6 C h a p t e r 6   Behavioral Modeling

1. How is behavioral modeling related to functional and structural modeling?

2. How does a use case relate to a sequence diagram? A communication diagram?

3. Contrast the following sets of terms: state, behavior, class, object, action, and activity.

4. Why is iteration important when creating a behavioral model?

5. What are the main building blocks for the sequence diagram? How are they represented on the model?

6. How do you show that a temporary object is to go out of existence on a sequence diagram?

7. Do lifelines always continue down the entire page of a sequence diagram? Explain.

8. Describe the steps used to create a sequence diagram. 9. When drawing a sequence diagram, what guidelines

should you follow? 10. Describe the main building blocks for the commu-

nication diagram and how they are represented on the model.

11. How do you show the sequence of messages on a communication diagram?

12. How do you show the direction of a message on a communication diagram?

13. Describe the steps used to create a communication diagram.

14. When drawing a communication diagram, what guidelines should you follow?

15. Are states always depicted using rounded rectangles on a behavioral state machine? Explain.

16. What kinds of events can lead to state transitions on a behavioral state machine?

17. What are the steps in building a behavioral state machine?

18. When drawing a behavioral state machine, what guidelines should you follow?

19. How are guard conditions shown on a behavioral state machine?

20. Describe the type of class that is best represented by a behavioral state machine. Give two examples of classes that would be good candidates for a behavioral state machine.

21. What is CRUDE analysis, and what is it used for? 22. Identify the models that contain each of the following

components: actor, association, class, extends, asso- ciation, fi nal state, guard condition, initial state, links, message, multiplicity, object, state, transition, and update operation.

QUESTIONS

EXERCISES

A. Th ink about sending a fi rst-class letter to an interna- tional pen pal. Describe the process that the letter goes through to get from your initial creation of the letter to being read by your friend, from the letter’s perspec- tive. Draw a behavioral state machine that depicts the states that the letter moves through.

B. Draw a behavioral state machine that describes the various states that a travel authorization can have through its approval process. A travel authorization form is used in most companies to approve travel expenses for employees. Typically, an employee fi lls out a blank form and sends it to his or her boss for a signature. If the amount is fairly small (<$300), then the boss signs the form and routes it to accounts pay- able to be input into the accounting system. Th e sys- tem cuts a check that is sent to the employee for the right amount, and aft er the check is cashed, the form is fi led away with the canceled check. If the check is not cashed within 90 days, the travel form expires. When the amount of the travel voucher is a large

amount (>$300), then the boss signs the form and sends it to the CFO, along with a paragraph explain- ing the purpose of the travel; the CFO signs the form and passes it along to accounts payable. Of course, the boss and the CFO can reject the travel authori- zation form if they do not feel that the expenses are reasonable. In this case, the employee can change the form to include more explanation or decide to pay the expenses.

C. Th ink about the system that handles student admissions at your university. Th e primary function of the system should be able to track a student from the request for information through the admissions process until the student is either admitted to the school or rejected. 1. Write a use-case description that can describe an

Admit Student use case. Assume that applicants who are children of alumni

are handled diff erently from other applicants. Also, assume that a generic Update Student Information use case is available for your system to use.

Minicases  237

2. Create a use-case diagram that includes all of the above use cases.

Assume that an admissions form includes the con- tents of the form, SAT information, and references. Additional information is captured about children of alumni, such as their parent’s graduation year, contact information, and college major. 3. Create a class diagram for the use cases identifi ed

with questions 1 and 2. Also, be sure to include the above information.

Assume that a temporary student object is used by the system to hold information about people before they send in an admission form. Aft er the form is sent in, these people are considered students. 4. Create sequence diagrams for the scenarios of the

above use cases. 5. Create a communication diagram for the scenarios

of the above use cases. 6. Create a behavioral state machine to depict a person

as he or she moves through the admissions process. 7. Perform a CRUDE analysis to show the interactiv-

ity of the objects in the system. D. For the A Real Estate Inc. problem in Chapters 4

(exercises I, J, and K) and 5 (exercises P and Q): 1. Choose one use case and, for each scenario, create

a sequence diagram. 2. Create a communication diagram for each scenario

of the use case chosen in Question 1. 3. Create a behavioral state machine to depict one

of the classes on the class diagram you created for Chapter 5, exercise P.

4. Perform a CRUDE analysis to show the interactiv- ity of the objects in the system.

5. Perform a verifi cation and validation walkthrough of the problem.

E. For the A Video Store problem in Chapters 4 (exer- cises L, M, and N) and 5 (exercises R and S): 1. Choose one use case and, for each scenario, create

a sequence diagram. 2. Create a communication diagram for each scenario

of the use case chosen in Question 1. 3. Create a behavioral state machine to depict one

of the classes on the class diagram you created for Chapter 5, exercise R.

4. Perform a CRUDE analysis to show the interactiv- ity of the objects in the system.

5. Perform a verifi cation and validation walkthrough of the problem.

F. For the gym membership problem in Chapters 4 (exer- cises O, P, and Q) and 5 (exercises T and U): 1. Choose one use case and, for each scenario, create

a sequence diagram. 2. Create a communication diagram for each scenario

of the use case chosen in Question 1. 3. Create a behavioral state machine to depict one

of the classes on the class diagram you created for Chapter 5, exercise T.

4. Perform a CRUDE analysis to show the interactiv- ity of the objects in the system.

5. Perform a verifi cation and validation walkthrough of the problem.

G. For the Picnics R Us problem in Chapters 4 (exercises R, S, and T) and 5 (exercises V and W): 1. Choose one use case and, for each scenario, create

a sequence diagram. 2. Create a communication diagram for each scenario

of the use case chosen in Question 1. 3. Create a behavioral state machine to depict one

of the classes on the class diagram you created for Chapter 5, exercise V.

4. Perform a CRUDE analysis to show the interactiv- ity of the objects in the system.

5. Perform a verifi cation and validation walkthrough of the problem.

H. For the Of-the-Month-Club problem in Chapters 4 (exercises U, V, and W) and 5 (exercises X and Y): 1. Choose one use case and, for each scenario, create

a sequence diagram. 2. Create a communication diagram for each scenario

of the use case chosen in Question 1. 3. Create a behavioral state machine to depict one

of the classes on the class diagram you created for Chapter 5, exercise X.

4. Perform a CRUDE analysis to show the interactiv- ity of the objects in the system.

5. Perform a verifi cation and validation walkthrough of the problem.

1. Refer to the functional model (use-case diagram, activity diagrams, and use-case descriptions) you pre- pared for the Professional and Scientifi c Staff Manage-

ment (PSSM) Minicase in Chapter 4. Based on your performance, PSSM was so satisfi ed that it wanted you to develop both the structural and behavioral models

MINICASES

2 3 8 C h a p t e r 6   Behavioral Modeling

so that it could more fully understand both the inter- action that would take place between the users and the system and the system itself in greater detail. a. Create both CRC cards and a class diagram based

on the functional models created in Chapter 4. b. Create a sequence and a communication diagram

for each scenario of each use case identifi ed in the functional model.

c. Create a behavioral state machine for each of the complex classes in the class diagram.

d. Perform a CRUDE analysis to show the interactiv- ity of the objects in the system.

e. Perform a verifi cation and validation walkthrough of each model: functional, structural, and behavioral.

2. Refer to the structural model (CRC cards and class dia- gram) that you created for the Holiday Travel Vehicles Minicase in Chapter 5. Based on your performance, Holiday Travel Vehicles was so satisfi ed that it wanted you to develop both the functional and behavioral

models so that it could more fully understand both the interaction that would take place between the users and the system and the system itself in greater detail. a. Based on the structural model you created in Chap-

ter 5 and the problem description in Chapter 5, create a functional model (use case diagram, activity dia- grams, and use case descriptions) for the business processes associated with the Holiday Travel Vehi- cles sales system.

b. Create a sequence and a communication diagram for each scenario of each use case identifi ed in the functional model.

c. Create a behavioral state machine for each of the complex classes in the class diagram.

d. Perform a CRUDE analysis to show the interactiv- ity of the objects in the system.

e. Perform a verifi cation and validation walk- through of each model: functional, structural, and behavioral.

Sto ryb

o ard

s

U ser In

terface P ro

to typ

es C

o n

tracts In

terface T em

p lates

W in

d o

w s

N avigatio

n

D iagram

s

Whereas analysis modeling concentrated on the functional requirements of the evolving system, design modeling incorporates the nonfunctional requirements. Th at is, design modeling focuses on how the system will operate. First, the project team verifi es and validates the analysis models (functional, structural, and behavioral). Next, a set of factored and partitioned analysis models are created. Th e class and method designs are illustrated using the class specifi cations (using CRC cards and class diagrams), contracts, and method specifi cations. Next, the data management layer is addressed by designing the actual database or fi le structure to be used for object persistence, and a set of classes that will map the class specifi cations into the object persistence format chosen. Concurrently, the team produces the user interface layer design using use scenarios, windows navigation diagrams, real use cases, interface templates, storyboards, windows layout diagrams, and user interface prototypes. Th e physical architecture layer design is created using deployment diagrams and hardware soft ware specifi cations. Th is collection of deliverables represents the system specifi cation that is handed to the programming team for implementation.

CHAPTER 7 Moving on to Design

CHAPTER 8 Class and

Method Design

CHAPTER 9 Data

Management Layer Design

CHAPTER 10 Human

Computer Interaction Layer

Design

CHAPTER 11 Physical

Architecture Layer Design

Facto red

/ P artitio

n ed

Fu

n ctio

n al M

o d el

Facto red

/ P artitio

n ed

B

eh avio

ral M o d el

Facto red

/ P artitio

n ed

Stru

ctu ral M

o d el

P ackage

D iagram

sAltern ative

M atrix

C lass

Sp ecifi catio

n s

M eth

o d

Sp ecifi catio

n s

O b

ject P

ersisten ce

D esign

D ata A

ccess &

M an

ip u

latio n

C

lass D esign

U se

Scen ario

s R

eal U se C

ases P A R T T W O

Design Modeling W

in d

o w

s Layo

u t

D iagram

s

D ep

lo ym

en t

D iagram

s

H ard

w are/

So ftw

are Sp

ecifi catio n

240

Object-oriented system development uses the requirements that were gathered during analysis to create a blueprint for the future system. A successful object-oriented design builds upon what was learned in earlier phases and leads to a smooth implementation by creating a clear, accurate plan of what needs to be done. Th is chapter describes the initial transition from analysis to design and presents three ways to approach the design for the new system.

OBJECTIVES

■ Understand the verifi cation and validation of the analysis models. ■ Understand the transition from analysis to design. ■ Understand the use of factoring, partitions, and layers. ■ Be able to create package diagrams. ■ Be familiar with the custom, packaged, and outsource design alternatives. ■ Be able to create an alternative matrix.

INTRODUCTION Th e purpose of analysis is to fi gure out what the business needs are. Th e purpose of design is to decide how to build the system. Th e major activity that takes place during design is evolving the set of analysis representations into design representations.

Th roughout design, the project team carefully considers the new system with respect to the current environment and systems that exist within the organization as a whole. Major considerations in determining how the system will work include environmental fac- tors, such as integrating with existing systems, converting data from legacy systems, and leveraging skills that exist in-house. Although the planning and analysis are undertaken to develop a possible system, the goal of design is to create a blueprint for a system that can be implemented.

An important initial part of design is to examine several design strategies and decide which will be used to build the system. Systems can be built from scratch, purchased and customized, or outsourced to others, and the project team needs to investigate the via- bility of each alternative. Th is decision infl uences the tasks that are to be accomplished during design.

At the same time, detailed design of the individual classes and methods that are used to map out the nuts and bolts of the system and how they are to be stored must still be completed. Techniques such as CRC cards, class diagrams, contract specifi cation, method specifi cation, and database design provide the fi nal design details in preparation for the implementation

C H A P T E R 7

Moving on to Design

Introduction  241

phase, and they ensure that programmers have suffi cient information to build the right sys- tem effi ciently. Th ese topics are covered in Chapters 8 and 9.

Design also includes activities such as designing the user interface, system inputs, and system outputs, which involve the ways that the user interacts with the system. Chapter 10 describes these three activities in detail, along with techniques such as storyboarding and prototyping, which help the project team design a system that meets the needs of its users and is satisfying to use.

Finally, physical architecture decisions are made regarding the hardware and soft ware that will be purchased to support the new system and the way that the processing of the system will be organized. For example, the system can be organized so that its processing is centralized at one location, distributed, or both centralized and distributed, and each solution off ers unique benefi ts and challenges to the project team. Because global issues and security infl uence the implementation plans that are made, they need to be considered along with the system’s technical architecture. Physical architecture, security, and global issues are described in Chapter 11.

Th e many steps of design are highly interrelated and, as with the steps in analysis, the analysts oft en go back and forth among them. For example, prototyping in the interface design step oft en uncovers additional information that is needed in the system. Alternatively, a system that is being designed for an organization that has centralized systems might require substantial hardware and soft ware investments if the project team decides to change to a sys- tem in which all the processing is distributed.

Avoiding Classic Design

In Chapter 2, we discussed several classic mistakes and how to avoid them. Here, we summarize four classic mis- takes in design and discuss how to avoid them.

1. Reducing design time: If time is short, there is a temptation to reduce the time spent in “unproduc- tive” activities such as design so that the team can jump into “productive” programming. This results in missing important details that have to be investi- gated later at a much higher time and cost (usually at least ten times higher).

Solution: If time pressure is intense, use timeboxing to eliminate functionality or move it into future versions.

2. Feature creep: Even if you are successful at avoiding scope creep, about 25 percent of system require- ments will still change. And, changes—big and small—can signifi cantly increase time and cost.

Solution: Ensure that all changes are vital and that the users are aware of the impact on cost and time. Try to move proposed changes into future versions.

3. Silver bullet syndrome: Analysts sometimes believe the marketing claims for some design tools that claim to solve all problems and magically reduce time and costs. No one tool or technique can eliminate overall time or costs by more than 25 percent (although some can reduce individual steps by this much).

Solution: If a design tool has claims that appear too good to be true, just say no.

4. Switching tools midproject: Sometimes analysts switch to what appears to be a better tool during design in the hopes of saving time or costs. Usually, any benefi ts are outweighed by the need to learn the new tool. This also applies even to minor upgrades to current tools.

Solution: Don’t switch or upgrade unless there is a compelling need for specifi c features in the new tool, and then explicitly increase the schedule to include learning time.

Based upon material from Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1966).

PRACTICAL

TIP

2 4 2 C h a p t e r 7   Moving on to Design

VERIFYING AND VALIDATING THE ANALYSIS MODELS1 Before we evolve our analysis representations into design representations, we need to verify and validate the current set of analysis models to ensure that they faithfully represent the problem domain under consideration. Th is includes testing the fi delity of each model; for example, we must be sure that the activity diagram(s), use-case descriptions, and use- case diagrams all describe the same functional requirements. It also involves testing the fi delity between the models; for instance, transitions on a behavioral state machine are associated with operations contained in a class diagram. In Chapters 4, 5, and 6, we focused on verifying and validating the individual models: function, structural, and behavioral. In this chapter, we center our attention on ensuring that the diff erent models are consistent. Figure 7-1 portrays the fact that the object-oriented analysis models are highly interrelated. For example, do the functional and structural models agree? What about the functional and behavioral models? And fi nally, are the structural and behavioral models trustworthy? In this section, we describe a set of rules that are useful to verify and validate the intersections of the analysis models. Depending on the specifi c constructs of each actual model, diff erent inter- relationships are relevant. Th e process of ensuring the consistency among them is known as balancing the models.

Balancing Functional and Structural Models To balance the functional and structural models, we must ensure that the two sets of models are consistent with each other. Th at is, the activity diagrams, use-case descriptions, and use-case diagrams must agree with the CRC cards and class diagrams that represent the evolving model of the problem domain. Figure 7-2 shows the interrelationships between the functional and structural models. By reviewing this fi gure, we uncover four sets of associations between the models. Th is gives us a place to begin balancing the functional and structural models.2

First, every class on a class diagram and every CRC card must be associated with at least one use case, and vice versa. For example, the CRC card portrayed in Figure 7-3 and its related class contained in the class diagram (see Figure 7-4) are associated with the Make Old Patient Appt use case described in Figure 7-5.

Second, every activity or action contained in an activity diagram (see Figure 7-6) and every event contained in a use-case description (see Figure 7-5) should be related to one or more responsibilities on a CRC card and one or more operations in a class on a class diagram and vice versa. For example, the Get Patient Information activity on the example activity diagram (see Figure 7-6) and the fi rst two events on the use-case description (see Figure 7-5) are associated with the make appointment responsibility on the CRC card (see Figure 7-3) and the makeAppointment() operation in the Patient class on the class diagram (see Figure 7-4).

Th ird, every object node on an activity diagram must be associated with an instance of a class on a class diagram (i.e., an object) and a CRC card or an attribute contained in a class and on a CRC card. However, in Figure 7-6, there is an object node, Appt Request Info, that does not seem to be related to any class in the class diagram portrayed in Figure 7-4. Th us, either the activity or class diagram is in error or the object node must represent an attrib- ute. In this case, it does not seem to represent an attribute. We could add a class to the

1 Th e material in this section is based upon material from E. Yourdon, Modern Structured Analysis (Englewood Cliff s, NJ: Prentice Hall, 1989). Verifying and validating are a type of testing. We also describe testing in Chapter 12. 2 Role-playing the CRC cards (see Chapter 5) also can be very useful in verifying and validating the relationships among the functional and structural models.

Verifying and Validating the Analysis Models  243

class diagram that creates temporary objects associated with the object node on the activity diagram. However, it is unclear what operations, if any, would be associated with these temporary objects. Th erefore, a better solution would be to delete the Appt Request Info object nodes from the activity diagram. In reality, this object node represented only a set of bundled attribute values, i.e., data that would be used in the appointment system process (see Figure 7-7).

Fourth, every attribute and association/aggregation relationships contained on a CRC card (and connected to a class on a class diagram) should be related to the subject or object of an event in a use-case description. For example, in Figure 7-5, the second event states: Th e Patient provides the Receptionist with his or her name and address. By reviewing the CRC card in Figure 7-3 and the class diagram in Figure 7-4, we see that the Patient class is a subclass of the Participant class and hence inherits all the attributes, associations, and operations defi ned with the Participant class, where name and address attributes are defi ned.

Balancing Functional and Behavioral Models As in balancing the functional and structural models, we must ensure the consistency of the two sets of models. In this case, the activity diagrams, use-case descriptions, and use-case diagrams must agree with the sequence diagrams, communication diagrams, behavioral state machines, and CRUDE matrix. Figure 7-8 portrays the relationships between the functional and behavioral models. Based on these interrelationships, we see that there are four areas with which we must be concerned.3

First, the sequence and communication diagrams must be associated with a use case on the use-case diagram and a use-case description. For example, the sequence diagram in Figure 7-9 and the communication diagram in Figure 7-10 are related to scenarios of the Make Old Patient Appt use case that appears in the use-case description in Figure 7-5 and the use-case diagram in Figure 7-11.

Second, actors on sequence diagrams, communication diagrams, and/or CRUDE matrices must be associated with actors on the use-case diagram or referenced in the use- case description, and vice versa. For example, the aPatient actor in the sequence diagram in Figure 7-9, the communication diagram in Figure 7-10, and the Patient row and column in the CRUDE matrix in Figure 7-12 appears in the use-case diagram in Figure 7-11 and the use-case description in Figure 7-5. However, the aReceptionist does not appear in the use-case diagram but is referenced in the events associated with the Make Old Patient Appt use-case description. In this case, the aReceptionist actor is obviously an internal actor, which cannot be portrayed on UML’s use-case diagram.

FIGURE 7-1 Object-Oriented Analysis Models

Functional Models

Structural Models

Behavioral Models

3 Performing CRUDE analysis (see Chapter 6) could also be useful in reviewing the intersections among the func- tional and behavioral models.

2 4 4

F IG

U R

E 7

-2   

R e

la ti

o n

sh ip

s am

o n

g F

u n

ct io

n al

a n

d S

tr u

ct u

ra l

M o

d e

ls

In cl

u d

in g

C o n ta

in s

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

In st

an ce

O f

R ep

re se

n ts

H av

e

H as

K in

d s

H as

K in

d s

H as

K in

d sC o

n ta

in s

In cl

u d in

g

C o n ta

in s

H as

K in

d s

C o n ta

in s

C o n ta

in s

H av

e

C o

n ta

in s

C o n ta

in s

St ru

ct u

ra l M

o d

el s

C R

C C

ar d s

O b

je ct

D ia

gr am

C la

ss D

ia gr

am

C o ll

ab o ra

to rs

R es

p o n si

b il

it ie

s

Ty p

e

O b

je ct

s

C la

ss es

A gg

re ga

ti o

n

A ss

o ci

at io

n

G en

er al

iz at

io n

A ss

o ci

at io

n s/

R el

at io

n sh

ip s

C o

m p

o si

ti o

n A

ss o

ci at

io n

C la

ss

Fu n ct

io n al

M o d el

s

U se

-C as

e D

ia gr

am

A ct

iv it

y D

ia gr

am

A ct

iv it

ie s/

A ct

io n s

U se

C as

e D

es cr

ip ti

o n s

Fl o w

s Ev

en ts

A ct

o rs

O b je

ct N

o d es

St ak

eh o ld

er s

R el

at io

n sh

ip s

O b je

ct F

lo w

s

C o n tr

o l Fl

o w

s

U se

C as

es

Sc en

ar io

s

A tt

ri b u te

s

O p er

at io

n s

Verifying and Validating the Analysis Models  245

Th ird, messages on sequence and communication diagrams, transitions on behavioral state machines, and entries in a CRUDE matrix must be related to activities and actions on an activity diagram and events listed in a use-case description, and vice versa. For example, the CreateAppt() message on the sequence and communication diagrams (see Figures 7-9 and 7-10) is related to the CreateAppointment activity (see Figure 7-7) and the S-1: New Appointment subfl ow on the use-case description (see Figure 7-5). Th e C entry in the Receptionist Appointment cell of the CRUDE matrix is also associated with these messages, activity, and subfl ow.

Fourth, all complex objects represented by an object node in an activity diagram must have a behavioral state machine that represents the object’s lifecycle, and vice versa. As stated in Chapter 6, complex objects tend to be very dynamic and pass through a variety of states during their lifetimes. However, in this case because we no longer have any object nodes in the activity diagram (see Figure 7-7), there is no necessity for a behavioral state machine to be created based on the activity diagram.

Front:

Class Name: Patient ID: 3

Change status

Medical history

Calculate last visit Make appointment Appointment

Provide medical history

Responsibilities

Associated Use Cases: 2Description: An individual who needs to receive or has received medical attention

Type: Concrete, Domain

Collaborators

Back:

Attributes:

Insurance carrier (text)

Amount (double)

Relationships:

Generalization (a-kind-of):

Aggregation (has-parts):

Other Associations: Appointment, Medical History

Participant

FIGURE 7-3 Old Patient CRC Card (Figure 5-25)

A cc

o u n t

Em p lo

ye e

0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

1. .*

1. .*

1. .*

1. .*

1. .*

1 .. 1

v 1 ..

1

1 ..

1

1 ..

1

1 ..

1

0 ..

1 1 ..

1 1 .. 1

1 ..

1

1 .. 1

1 .. 1

1 ..

1

D eb

it

C re

d it

En tr

y A

p p o in

tm en

t

-t im

e -d

at e

-r ea

so n

+ ca

n ce

l w

it h o u t

n o ti

ce ()

Pa ti

en t

-a m

o u n t

-i n su

ra n ce

c ar

ri er

+ m

ak e

ap p o in

tm en

t( )

+ ca

lc u la

te l

as t

vi si

t( )

+ ch

an ge

s ta

tu s(

) +

p ro

vi d es

m ed

ic al

h is

to ry

()

Pa rt

ic ip

an t

-l as

tn am

e -fi

rs tn

am e

-a d d re

ss -p

h o n e

-b ir

th d at

e -/

ag e

It em

Tr an

sa ct

io n L

in e

It em

h as

h as

co n

ta in

s

A ss

ig n ed

T o

D o ct

o r

R ec

ep ti

o n is

t N

u rs

e

M ed

ic al

H is

to ry

-h ea

rt d

is ea

se -h

ig h b

lo o d p

re ss

u re

-d ia

b et

es -a

ll er

gi es

p ro

vi d es

su ff

er s

schedules

lo ca

te d A

t

G o

o d

Se rv

ic e

P re

sc ri

p ti

o n

B ra

ce P

hy si

ca l

C h

ec ku

p

Sy m

p to

m Il

ln es

s

P la

ce

Tr ea

tm en

t

m ed

ic at

io n

in st

ru ct

io n

s sy

m p

to m

s ev

er it y

+ p

ri m

ar y

in su

ra n ce

ca rr

ie r

-n am

e -d

es cr

ip ti o

n

F IG

U R

E 7

-4   

A p

p o

in tm

e n

t P

ro b

le m

C la

ss D

ia g

ra m

( Fi

g u

re 5

-7 )

2 4 6

Verifying and Validating the Analysis Models  247

FIGURE 7-5    Use-Case Description for the Make Old Patient Appt Use Case (Figure 4-13)

Use-Case Name:

Primary Actor:

Stakeholders and Interests:

Brief Description:

ID: Importance Level:

Trigger:

Normal Flow of Events:

SubFlows:

Alternate/Exceptional Flows:

Type: External

Make Old Patient Appt 2 Low

Old Patient

Old patient - wants to make, change, or cancel an appointment Doctor - wants to ensure patient’s needs are met in a timely manner

Use Case Type: Detail, Essential

Patient calls and asks for a new appointment or asks to cancel or change an existing appointment

Old Patient

Update Patient Information Manage Appointments

1. The Patient contacts the office regarding an appointment. 2. The Patient provides the Receptionist with his or her name and address. 3. If the Patient’s information has changed Execute the Update Patient Information use case. 4. If the Patient’s payment arrangements has changed Execute the Make Payments Arrangements use case. 5. The Receptionist asks Patient if he or she would like to make a new appointment, cancel an existing appointment, or change an existing appointment.

S-1: New Appointment 1. The Receptionist asks the Patient for possible appointment times. 2. The Receptionist matches the Patient’s desired appointment times with available dates and times and schedules the new appointment.

S-2: Cancel Appointment 1. The Receptionist asks the Patient for the old appointment time. 2. The Receptionist finds the current appointment in the appointment file and cancels it.

S-3: Change Appointment 1. The Receptionist performs the S-2: cancel appointment subflow. 2. The Receptionist performs the S-1: new appointment subflow.

S-1, 2a1: The Receptionist proposes some alternative appointment times based on what is available in the appointment schedule. S-1, 2a2: The Patient chooses one of the proposed times or decides not to make an appointment.

6. The Receptionist provides the results of the transaction to the Patient.

This use case describes how we make an appointment as well as changing or canceling an appointment for a previously seen patient.

Relationships: Association: Include: Extend: Generalization:

If the patient wants to make a new appointment, the S-1: new appointment subflow is performed. If the patient wants to cancel an existing appointment, the S-2: cancel appointment subflow is performed. If the patient wants to change an existing appointment, the S-3: change appointment subflow is performed.

TEMPLATE can be found at www.wiley.com /college/dennis

2 4 8 C h a p t e r 7   Moving on to Design

Get Patient Information

Appt Request Info

Appt Request InfoCreate New Patient

Update Patient Information

[New Patient][Old Patient]

[Change]

Cancel Appointment Change AppointmentCreate Appointment

Make Payment Arrangements

Create Appointment

Make Payment Arrangements

[New Info]

[New Arrange]

[Cancel]

[Create]

FIGURE 7-6    Activity Diagram for the Manage Appointments Use Case (Figure 4-8)

Get Patient Information

Create New Patient

Update Patient Information

[New Patient][Old Patient]

[Change]

Cancel Appointment Change AppointmentCreate Appointment

Make Payment Arrangements

Create Appointment

Make Payment Arrangements

[New Info]

[New Arrange]

[Cancel]

[Create]

FIGURE 7-7    Corrected Activity Diagram for the Manage Appointments Use Case

Verifying and Validating the Analysis Models  249

In cl

u d in

g

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

C o n ta

in s

D es

cr ib

e

In cl

u d in

g

C o n ta

in s

C o n ta

in s

C o n ta

in s

H as

K in

d s

H as

K in

d s

C o n ta

in s

C o n ta

in s

H av

e

H as

K in

d s

C o n ta

in s

B eh

av io

ra l M

o d el

s

C R

U D

E M

at ri

x

C o m

m u n ic

at io

n D

ia gr

am

A ss

o ci

at io

n s

M es

sa ge

s

Se q u en

ce D

ia gr

am

C el

l En

tr ie

s Tr

an si

ti o n s

St at

es

A ct

iv it

y D

ia gr

am

U se

-C as

e D

ia gr

am

U se

-C as

e D

es cr

ip ti

o n s

O b je

ct N

o d es

A ct

iv it

ie s/

A ct

io n s

St ak

eh o ld

er s

R el

at io

n sh

ip s

U p d at

e C

re at

e

O b je

ct s

U se

C as

es

C o n tr

o l Fl

o w

s O

b je

ct F

lo w

s

Fl o w

s

Ev en

ts

A ct

o rs

Fu n ct

io n al

M o d el

s

B eh

av io

ra l St

at e

M ac

h in

e

In te

ra ct

io n D

ia gr

am

R ea

d

D el

et e

Sc en

ar io

s

A ct

o rs

F IG

U R

E 7

-8   

R e

la ti

o n

sh ip

s b

e tw

e e

n F

u n

ct io

n al

a n

d B

e h

av io

ra l

M o

d e

ls

2 5 0

Verifying and Validating the Analysis Models  251

sd Make Appt Use Case

RequestAppt(name, address)

NewCancelChangeAppt?()

ApptTimes?()

aPatient

LookUpPatient()

aReceptionist

[aPatient Exists] LookupBills()

MatchAppts()

CreateAppt()

aPatient:Patient :UnpaidBill :Appointment

FIGURE 7-9 Sequence Diagram for a Scenario of the Make Old Patient Appt Use Case (Figure 6-1)

sd Make Appt Use Case

aPatient

1: RequestAppt(name, address)

4: NewCancelChangeAppt?

5: ApptTimes?

aReceptionist

2: L ook

Up Pati

ent ()

3: [aPatient Exists] LookupBills()

7: CreateAppt

6: MatchAppts

:Appointment

aPatient:Patient

:UnpaidBill

FIGURE 7-10    Communication Diagram for a Scenario of the Make Old Patient Appt Use Case (Figure 6-10)

Balancing Structural and Behavioral Models To discover the relationships between the structural and behavioral models, we use the concept map in Figure 7-13. In this case, there are fi ve areas in which we must ensure the consistency between the models.4

4 Role-playing (see Chapter 5) and CRUDE analysis (see Chapter 6) also can be very useful in this undertaking.

2 5 2 C h a p t e r 7   Moving on to Design

Appointment System

Patient

New Patient

Old Patient

Update Patient Information

Make Old Patient Appt

Make New Patient Appt

Make Payment Arrangements

Create New Patient

Manage Appointments

<< ex

te nd

>>

< <

in cl

ud e>

>

*

*

*

*

< < include>

>

< < ex

te nd

> >

Produce Schedules

Management

Doctor

Record Availability

Manage Schedule

<<include>>

<<include>>

* *

* *

FIGURE 7-11    Modifi ed Use-Case Diagram for the Appointment System (Figure 4-21)

FIGURE 7-12    CRUDE Matrix for the Make Old Patient Apt Use Case (Figure 6-23)

Receptionist RU CRUD R RU CRUD

PatientList R

Patient

UnpaidBills

Appointments R

Appointment

Receptionist PatientList Patient UnpaidBills Appointments Appointment

A ss

o ci

at ed

W it

h

St ru

ct u ra

l M

o d

el s

C R

C C

ar d s

In cl

u d in

g

C o n ta

in s

C o n ta

in s

In st

an ce

O f

R ep

re se

n ts

C o n ta

in s

A ss

o ci

at io

n s/

R el

at io

n sh

ip s

A tt

ri b u te

s

H av

e

Ty p e

O p er

at io

n s

R es

p o n si

b il it

ie s

C o n ta

in s

In cl

u d in

g

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

G en

er al

iz at

io n

A ct

o rs

H as

K in

d s

H as

K in

d s

H as

K in

d s

H as

K in

d s

H as

K in

d s

A ss

o ci

at io

n A

gg re

ga ti

o n

C o n ta

in s

A ss

o ci

at io

n s

C o m

m u n ic

at io

n D

ia gr

am Se

q u en

ce D

ia gr

am

In te

ra ct

io n D

ia gr

am

B eh

av io

ra l M

o d el

s

C R

U D

E M

at ri

x

C o n ta

in s

D es

cr ib

e

O b je

ct s

O b je

ct s

M es

sa ge

s

C o n ta

in s

C o n ta

in s

D el

et e

Tr an

si ti

o n s

R ea

d

C re

at e

C el

l En

tr ie

s

St at

es

C la

ss D

ia gr

am O

b je

ct D

ia gr

am

C o ll ab

o ra

to rs

A ss

o ci

at io

n C

la ss

C o m

p o si

ti o n

U p d at

e

B eh

av io

ra l St

at e

M ac

h in

e

C la

ss es

F IG

U R

E 7

-1 3

   R

e la

ti o

n sh

ip s

b e

tw e

e n

S tr

u ct

u ra

l an

d B

e h

av io

ra l

M o

d e

ls

253

2 5 4 C h a p t e r 7   Moving on to Design

First, objects that appear in a CRUDE matrix must be associated with classes that are represented by CRC cards and appear on the class diagram, and vice versa. For example, the Patient class in the CRUDE matrix in Figure 7-12 is associated with the CRC card in Figure 7-3 and the Patient class in the class diagram in Figure 7-4.

Second, because behavioral state machines represent the life cycle of complex objects, they must be associated with instances (objects) of classes on a class diagram and with a CRC card that represents the class of the instance. For example, the behavioral state machine that describes an instance of a Patient class in Figure 7-14 implies that a Patient class exists on a related class diagram (see Figure 7-4) and that a CRC card exists for the related class (see Figure 7-3).

Th ird, communication and sequence diagrams contain objects that must be an instan- tiation of a class that is represented by a CRC card and is located on a class diagram. For example, Figure 7-9 and Figure 7-10 have an anAppt object that is an instantiation of the Appointment class. Th erefore, the Appointment class must exist in the class diagram (see Figure 7-4), and a CRC card should exist that describes it. However, there is an object on the communication and sequence diagrams associated with a class that did not exist on the class diagram: UnpaidBill. At this point, the analyst must decide to either modify the class diagram by adding these classes or rethink the communication and sequence diagrams. In this case, it is better to add the class to the class diagram (see Figure 7-15).

Fourth, messages contained on the sequence and communication diagrams, transitions on behavioral state machines, and cell entries on a CRUDE matrix must be associated with responsibilities and associations on CRC cards and operations in classes and asso ciations connected to the classes on class diagrams. For example, the CreateAppt() message on the sequence and communication diagrams (see Figures 7-9 and 7-10) relate to the makeAp- pointment operation of the Patient class and the schedules association between the Patient and Appointment classes on the class diagram (see Figure 7-15).

Fift h, the states in a behavioral state machine must be associated with diff erent values of an attribute or set of attributes that describe an object. For example, the behavioral state machine for the hospital patient object implies that there should be an attribute, possibly current status, which needs to be included in the defi nition of the class.

Summary Figure 7-16 portrays a concept map that is a complete picture of the interrelationships among the diagrams covered in this section. It is obvious from the complexity of this

FIGURE 7-14    Behavioral State Machine for Hospital Patient (Figure 6-16)

Patient

Enters Hospital Checks In [Diagnosis = Healthy] [> 2 weeks] Entering Admitted Released

Under Observation

[Diagnosis = Unhealthy]

[Diagnosis = Healthy]

A cc

o u n t

Em p lo

ye e

0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

1. .*

1. .*

1. .*

1. .*

1. .*

1 .. 1

1 ..

1

1 ..

1

1 ..

1

0 ..

1

1 ..

1

1 ..

1

1 .. 1

1 ..

1

1 ..

1 1

.. 1

1 ..

1

D eb

it

C re

d it

En tr

y A

p p o in

tm en

t

-t im

e -d

at e

-r ea

so n

+ ca

n ce

l w

it h o u t

n o ti

ce ()

Pa ti

en t

-a m

o u n t

-i n su

ra n ce

c ar

ri er

+ m

ak e

ap p o in

tm en

t( )

+ ca

lc u la

te l

as t

vi si

t( )

+ ch

an ge

s ta

tu s(

) +

p ro

vi d es

m ed

ic al

h is

to ry

()

Pa rt

ic ip

an t

-l as

tn am

e -fi

rs tn

am e

-a d d re

ss -p

h o n e

-b ir

th d at

e -/

ag e

It em

Tr an

sa ct

io n L

in e

It em

h as

h as

co n

ta in

s

A ss

ig n ed

T o

+ p

ri m

ar y

in su

ra n ce

c ar

ri er

D o

ct o r

R ec

ep ti

o n is

t U

n p ai

d B

il l

N u rs

e

M ed

ic al

H is

to ry

-h ea

rt d

is ea

se -h

ig h b

lo o d p

re ss

u re

-d ia

b et

es -a

ll er

gi es

p ro

vi d es

su ff

er s

o w

esschedules

lo ca

te d A

t

G o

o d

Se rv

ic e

P re

sc ri

p ti

o n

B ra

ce P

hy si

ca l

C h

ec ku

p

Sy m

p to

m Il

ln es

s

P la

ce

Tr ea

tm en

t

m ed

ic at

io n

in st

ru ct

io n

s sy

m p

to m

s ev

er it y

-n am

e -d

es cr

ip ti o

n

F IG

U R

E 7

-1 5

   C

o rr

e ct

e d

A p

p o

in tm

e n

t S

ys te

m C

la ss

D ia

g ra

m

255

In cl

u d in

g C o n ta

in s

C o n ta

in s

C o n ta

in s

R ep

re se

n ts

C o n ta

in s

H as

K in

d s

H as

K in

d s

H as

K in

d s

H av

e H

as K

in d s

In cl

u d in

g

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h A

ss o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h

A ss

o ci

at ed

W it

h A

ss o ci

at ed

W it

h A

ss o ci

at ed

W it

h

In cl

u d es

H as

K in

d s

In cl

u d in

g

C o n ta

in s

C o n ta

in s

C o n ta

in sC

o n ta

in s

C o n ta

in s

C o n ta

in s

C o n ta

in s

H as

K in

d s

St ru

ct u ra

l M

o d el

s

C R

C C

ar d s

O b je

ct D

ia gr

am C

la ss

D ia

gr am

C o ll ab

o ra

to rs A tt

ri b u te

s

O p er

at io

n s

Ty p e

C la

ss es

A ss

o ci

at io

n s/

R el

at io

n sh

ip s

A gg

re ga

ti o n

G en

er al

iz at

io n

C o m

p o si

ti o n

A ss

o ci

at io

n C

la ss

B eh

av io

ra l M

o d el

s

O b je

ct -O

ri en

te d A

n al

ys is

M o d el

s

In te

ra ct

io n D

ia gr

am

B eh

av io

ra l St

at e

M ac

h in

e C

R U

D E

M at

ri x

C o m

m u n ic

at io

n D

ia gr

am

M es

sa ge

s

Se q u en

ce D

ia gr

am

C el

l En

tr ie

s

A ct

iv it

y D

ia gr

am U

se -C

as e

D ia

gr am

U se

C as

e D

es cr

ip ti

o n s

O b je

ct F

lo w

s C

o n tr

o l Fl

o w

s

O b je

ct N

o d es

A ct

iv it

ie s/

A ct

io n s

Fl o w

s

St ak

eh o ld

er s

R el

at io

n sh

ip s

Ev en

ts

D el

et e

R ea

d

U p d at

e

C re

at e

Sc en

ar io

s

Fu n ct

io n al

M o d el

s

A ct

o rs

O b je

ct s

A ss

o ci

at ed

W it

h

Tr an

si ti

o n s

St at

es

A ss

o ci

at io

n

H av

e

U se

C as

es R

es p o n si

b il it

ie s

In st

an ce

O f

A ss

o ci

at ed

W it

h

F IG

U R

E 7

-1 6

   In

te rr

e la

ti o

n sh

ip s

am o

n g

O b

je ct

-O ri

e n

te d

A n

al ys

is M

o d

e ls

2 5 6

Evolving the Analysis Models into Design Models  257

fi gure that balancing all the functional, structural, and behavioral models is a very time- consuming, tedious, and diffi cult task. However, without paying this level of attention to the evolving models that represent the system, the models will not provide a sound foundation on which to design and build the system.

EVOLVING THE ANALYSIS MODELS INTO DESIGN MODELS Now that we have successfully verifi ed and validated our analysis models, we need to begin evolving them into appropriate design models. Th e purpose of the analysis models was to represent the underlying business problem domain as a set of collaborating objects. In other words, the analysis activities defi ned the functional requirements. To achieve this, the analysis activities ignored nonfunctional requirements such as performance and the system environment issues (e.g., distributed or centralized processing, user-interface issues, and database issues). In contrast, the primary purpose of the design models is to increase the likelihood of successfully delivering a system that implements the functional requirements in a manner that is aff ordable and easily maintainable. Th erefore, in systems design, we address both the functional and nonfunctional requirements.

From an object-oriented perspective, system design models simply refi ne the system analysis models by adding system environment (or solution domain) details to them and refi ning the problem domain information already contained in the analysis models. When evolving the analysis model into the design model, you should fi rst carefully review the use cases and the current set of classes (their operations and attributes and the relationships between them). Are all the classes necessary? Are there any missing classes? Are the classes fully defi ned? Are any attributes or methods missing? Do the classes have any unnecessary attributes and methods? Is the current representation of the evolving system optimal? Obviously, if we have already verifi ed and validated the analysis models, quite a bit of this has already taken place. Yet, object-oriented systems development is both incremental and iterative. Th erefore, we must review the analysis models again. However, this time we begin looking at the models of the problem domain through a design lens. In this step, we make modifi cations to the prob- lem domain models that will enhance the effi ciency and eff ectiveness of the evolving system.

In the following sections, we introduce factoring, partitions and collaborations, and layers as a way to evolve problem domain-oriented analysis models into optimal solu- tion domain-oriented design models. From an enhanced Unifi ed Process perspective (see Figure 1-16), we are moving from the analysis workfl ow to the design workfl ow, and we are moving further into the Elaboration phase and partially into the Construction phase.

Factoring Factoring is the process of separating out a module into a stand-alone module. Th e new module can be a new class or a new method. For example, when reviewing a set of classes, it may be discovered that they have a similar set of attributes and methods. Th us, it might make sense to factor out the similarities into a separate class. Depending on whether the new class should be in a superclass relationship to the existing classes or not, the new class can be related to the existing classes through a generalization (a-kind-of) or possibly through an aggregation (has-parts) relationship. Using the appointment system example, if the Employee class had not been identified, we could possibly identify it at this stage by factoring out the similar methods and attributes from the Nurse, Receptionist, and Doctor classes. In this case, we would relate the new class (Employee) to the existing classes using the generalization (a-kind-of) relationship. Obviously, by extension we also could have created the Participant class if it had not been previously identifi ed.

Abstraction and refi nement are two processes closely related to factoring. Abstraction deals with the creation of a higher-level idea from a set of ideas. Identifying the Employee class is an example of abstracting from a set of lower classes to a higher one. In some cases, the abstraction process identifi es abstract classes, whereas in other situations, it identifi es additional concrete classes.5 Th e refi nement process is the opposite of the abstraction process. In the appointment system example, we could identify additional subclasses of the Employee class, such as Secretary and Bookkeeper. Of course we would add the new classes only if there were suffi cient diff erences among them. Otherwise, the more general class, Employee, would suffi ce.

Partitions and Collaborations Based on all the factoring, refi ning, and abstracting that can take place to the evolving system, the sheer size of the system representation can overload the user and the developer. At this point in the evolution of the system, it might make sense to split the representation into a set of partitions. A partition is the object-oriented equivalent of a subsystem,6 where a sub- system is a decomposition of a larger system into its component systems (e.g., an accounting information system could be functionally decomposed into an accounts-payable system, an accounts-receivable system, a payroll system, etc.). From an object- oriented perspective, partitions are based on the pattern of activity (messages sent) among the objects in an object- oriented system. We describe an easy approach to model partitions and collaborations later in this chapter: packages and package diagrams.

A good place to look for potential partitions is the collaborations modeled in UML’s com- munication diagrams (see Chapter 6). If you recall, one useful way to identify collaborations is to create a communication diagram for each use case. However, because an individual class can support multiple use cases, an individual class can participate in multiple use-case-based col- laborations. In cases where classes are supporting multiple use cases, the collaborations should be merged. Th e class diagram should be reviewed to see how the diff erent classes are related to one another. For example, if attributes of a class have complex object types, such as Person, Address, or Department, and these object types were not modeled as associations in the class diagram, we need to recognize these implied associations. Creating a diagram that combines the class diagram with the communication diagrams can be very useful to show to what degree the classes are coupled.7 Th e greater the coupling between classes, the more likely the classes should be grouped together in a collaboration or partition. By looking at a CRUDE matrix, we can use CRUDE analysis (see Chapter 6) to identify potential classes on which to merge collaborations.

One of the easiest techniques to identify the classes that could be grouped to form a collaboration is through the use of cluster analysis or multiple dimensional scaling. Th ese statistical techniques enable the team to objectively group classes together based on their affi nity for each other. Th e affi nity can be based on semantic relationships, diff erent types of messages being sent between them (e.g., create, read, update, delete, or execute), or some weighted combination of both. Th ere are many diff erent similarity measures and many diff erent algorithms on which the clusters can be based, so one must be careful when using these techniques. Always make sure that the collaborations identifi ed using these techniques

2 5 8 C h a p t e r 7   Moving on to Design

5 See Chapter 5 for the diff erences between abstract and concrete classes. 6 Some authors refer to partitions as subsystems [e.g., see R. Wirfs-Brock, B. Wilkerson, and L. Weiner, Designing Object-Oriented Soft ware (Englewood Cliff s, NJ: Prentice Hall, 1990)], whereas others refer to them as layers [e.g., see I. Graham, Migrating to Object Technology (Reading, MA: Addison-Wesley, 1994)]. However, we have chosen to use the term partition [C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design (Englewood Cliff s, NJ: Prentice Hall, 1998)] to minimize confusion between subsystems in a traditional systems development approach and layers associated with Rational’s Unifi ed Approach. 7 We describe the concept of coupling in Chapter 8.

Evolving the Analysis Models into Design Models  259

make sense from the problem domain perspective. Just because a mathematical algorithm suggests that the classes belong together does not make it so. However, this is a good approach to create a fi rst-cut set of collaborations.

Depending on the complexity of the merged collaboration, it may be useful in decompos- ing the collaboration into multiple partitions. In this case, in addition to having collaborations between objects, it is possible to have collaborations among partitions. Th e general rule is the more messages sent between objects, the more likely the objects belong in the same partition. Th e fewer messages sent, the less likely the two objects belong together.

Another useful approach to identifying potential partitions is to model each collab- oration between objects in terms of clients, servers, and contracts. A client is an instance of a class that sends a message to an instance of another class for a method to be executed; a server is the instance of a class that receives the message; and a contract is the specifi ca- tion that formalizes the interactions between the client and server objects (see Chapters 5 and 8). Th is approach allows the developer to build up potential partitions by looking at the contracts that have been specifi ed between objects. In this case, the more contracts there are between objects, the more likely that the objects belong in the same partition. Th e fewer con- tracts, the less chance there is that the two classes belong in the same partition.

Remember, the primary purpose of identifying collaborations and partitions is to deter- mine which classes should be grouped together in design.

Layers Until this point in the development of our system, we have focused only on the problem domain; we have totally ignored the system environment (data management, user interface, and physical architecture). To successfully evolve the analysis model of the system into a design model of the system, we must add the system environment information. One useful way to do this, without overloading the developer, is to use layers. A layer represents an ele- ment of the soft ware architecture of the evolving system. We have focused only on one layer in the evolving soft ware architecture: the problem domain layer. Th ere should be a layer for each of the diff erent elements of the system environment (e.g., data management, user inter- face, physical architecture). Like partitions and collaborations, layers also can be portrayed using packages and package diagrams (see the next section of this chapter).

Th e idea of separating the diff erent elements of the architecture into separate layers can be traced back to the MVC architecture of Smalltalk.8 When Smalltalk was fi rst created,9 the authors decided to separate the application logic from the logic of the user interface. In this manner, it was possible to easily develop diff erent user interfaces that worked with the same application. To accomplish this, they created the Model–View–Controller (MVC) architecture, where Models implemented the application logic (problem domain) and Views and Controllers implemented the logic for the user interface. Views handled the output, and Controllers handled the input. Because graphical user interfaces were fi rst developed in the Smalltalk language, the MVC architecture served as the foundation for virtually all graphical user interfaces that have been developed today (including the Mac interfaces, the Windows family, and the various Unix-based GUI environments).

8 See S. Lewis, Th e Art and Science of Smalltalk: An Introduction to Object-Oriented Programming Using Visual-Works (Englewood Cliff s, NJ: Prentice Hall, 1995). 9 Smalltalk was invented in the early 1970s by a soft ware-development research team at Xerox PARC. It introduced many new ideas into the area of programming languages (e.g., object orientation, windows-based user interfaces, reusable class library, and the development environment). In many ways, Smalltalk is the parent of all object-based and object-oriented languages, such as Visual Basic, C++, and Java.

Based on Smalltalk’s innovative MVC architecture, many diff erent soft ware layers have been proposed.10 We suggest the following layers on which to base soft ware architecture: foundation, problem domain, data management, human–computer interaction, and phys- ical architecture (see Figure 7-17). Each layer limits the types of classes that can exist on it (e.g., only user interface classes may exist on the human–computer interaction layer).

Foundation Th e foundation layer is, in many ways, a very uninteresting layer. It contains classes that are necessary for any object-oriented application to exist. Th ey include classes that represent fundamental data types (e.g., integers, real numbers, characters, strings), classes that represent fundamental data structures, sometimes referred to as container classes (e.g., lists, trees, graphs, sets, stacks, queues), and classes that represent useful abstractions, sometimes referred to as utility classes (e.g., date, time, money). Th ese classes are rarely, if ever, modi- fi ed by a developer. Th ey are simply used. Today, the classes found on this layer are typically included with the object-oriented development environments.

Problem Domain Th e problem-domain layer is what we have focused our attention on up until now. At this stage in the development of our system, we need to further detail the classes so that we can implement them in an eff ective and effi cient manner. Many issues need to be addressed when designing classes, no matter on which layer they appear. For example, there are issues related to factoring, cohesion and coupling, connascence, encapsulation, proper use of inheritance and polymorphism, constraints, contract specifi cation, and detailed method design. Th ese issues are discussed in Chapter 8.

Data Management Th e data management layer addresses the issues involving the persistence of the objects contained in the system. Th e types of classes that appear in this layer deal with how objects can be stored and retrieved. Th e classes contained in this layer are called the Data Access and Manipulation (DAM) classes. Th e DAM classes allow the problem domain classes to be independent of the storage used and, hence, increase the portability of the evolving system. Some of the issues related to this layer include choice of the storage format and optimization. Th ere is a plethora of diff erent options in which to choose to store objects. Th ese include sequential fi les, random access fi les, relational databases, object/relational databases, object-oriented databases,

2 6 0 C h a p t e r 7   Moving on to Design

Foundation Date, Enumeration 7, 8

Problem Domain Employee, Customer 4, 5, 6, 7, 8

Data Management DataInputStream, 8, 9 FileInputStream

Human–Computer Interaction Button, Panel 8, 10

Physical Architecture ServerSocket, URLConnection 8, 11

FIGURE 7-17 Layers and Sample Classes

Layers Examples Relevant Chapters

10 For example, Problem Domain, Human Interaction, Task Management, and Data Management [P. Coad and E. Yourdon, Object-Oriented Design (Englewood Cliff s, NJ: Yourdon Press, 1991)]; Domain, Application, and Interface (I. Graham, Migrating to Object Technology [Reading, MA: Addison-Wesley, 1994)]; Domain, Service, and Presentation [C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design (Englewood Cliff s, NJ: Prentice Hall, 1998)]; Business, View, and Access [A. Bahrami, Object-Oriented Systems Development using the Unifi ed Modeling Language (New York: McGraw-Hill, 1999)]; Application- Specifi c, Application-General, Middleware, System-Soft ware [I. Jacobson, G. Booch, and J. Rumbaugh, Th e Uni- fi ed Soft ware Development Process (Reading, MA: Addison-Wesley, 1999)]; Foundation, Architecture, Business, and Application [M. Page-Jones, Fundamentals of Object-Oriented Design in UML (Reading, MA: Addison- Wesley, 2000)].

and NoSQL data stores. Each of these options has been optimized to provide solutions for diff er- ent access and storage problems. Today, from a practical perspective, there is no single solution that optimally serves all applications. Th e correct solution is most likely some combination of the diff erent storage options. A complete description of all the issues related to the data manage- ment layer is well beyond the scope of this book.11 However, we do present the fundamentals in Chapter 9.

Human–Computer Interaction Th e human–computer interaction layer contains classes asso- ciated with the View and Controller idea from Smalltalk. Th e primary purpose of this layer is to keep the specifi c user-interface implementation separate from the problem domain classes. Th is increases the portability of the evolving system. Typical classes found on this layer include classes that can be used to represent buttons, windows, text fi elds, scroll bars, check boxes, drop-down lists, and many other classes that represent user-interface elements.

When designing the user interface for an application, many issues must be addressed: How important is consistency across diff erent user interfaces? What about diff ering levels of user experience? How is the user expected to be able to navigate through the system? What about help systems and online manuals? What types of input elements should be included? What types of output elements should be included? Other questions that must be addressed are related to the platform on which the soft ware will be deployed. For example, is the application going to run on a stand-alone computer, is it going to be distributed, or is the application going mobile? If it is expected to run on mobile devices, what type of platform: notebooks, tablets, or phones? Will it be deployed using Web technology, which runs on multiple devices, or will it be created using apps that are based on Android from Google, iOS from Apple, or Windows from Microsoft ? Depending on the answer to these questions, diff erent types of user interfaces are possible.

With the advent of social networking platforms, such as Facebook, Twitter, blogs, YouTube, and LinkedIn, the implications for the user interface can be mind boggling. Depending on the application, diff erent social networking platforms may be appropriate for diff erent aspects of the application. Furthermore, each of the diff erent social networking plat- forms enables (or prevents) consideration of diff erent types of user interfaces. Finally, with the potential audience of your application being global, many diff erent cultural issues will arise in the design and development of culturally aware user interfaces (such as multilingual requirements). Obviously, a complete description of all the issues related to human–computer interaction is beyond the scope of this book.12 However, from the user’s perspective, the user interface is the system. We present the basic issues in user interface design in Chapter 10.

Physical Architecture Th e physical architecture layer addresses how the soft ware will exe- cute on specifi c computers and networks. Th is layer includes classes that deal with commu- nication between the soft ware and the computer’s operating system and the network. For example, classes that address how to interact with the various ports on a specifi c computer are included in this layer.

Evolving the Analysis Models into Design Models  261

11 Th ere are many good database design books that are relevant to this layer; see, for example, M. Gillenson, Fundamentals of Database Management Systems (Hoboken, NJ: John Wiley & Sons, 2005); F. R. McFadden, J. A. Hoff er, and Mary B. Prescott, Modern Database Management, 4th Ed. (Reading, MA: Addison-Wesley, 1998); M. Blaha and W. Premerlani, Object-Oriented Modeling and Design for Database Applications (Englewood Cliff s, NJ: Prentice Hall, 1998); R. J. Muller, Database Design for Smarties: Using UML for Data Modeling (San Francisco: Morgan Kaufmann, 1999). 12 Books on user interface design that address these issues include B. Schheiderman, Designing the User Interface: Strategies for Eff ective Human Computer Interaction, 3rd Ed. (Reading, MA: Addison-Wesley, 1998); J. Tidwell, Designing Interfaces: Patterns for Eff ective Interaction Design, 2nd Ed. (Sebastopol, CA: O’Reilly Media, 2010); S. Krug, Don’t Make Me Th ink: A Common Sense Approach to Web Usability (Berkeley, CA: New Riders Publishing, 2006); N. Singh and A. Pereira, Th e Culturally Customized Web Site: Customizing Web Sites for the Global Market- place (Oxford, UK: Elsevier, 2005).

Unlike in the foundation layer, many design issues must be addressed before choosing the appropriate set of classes for this layer. Th ese design issues include the choice of a computing or network architecture (such as the various client-server architectures), the actual design of a network, hardware and server soft ware specifi cation, and security issues. Other issues that must be addressed with the design of this layer include computer hardware and soft ware confi gu- ration (choice of operating systems, such as Linux, Mac OSX, and Windows; processor types and speeds; amount of memory; data storage; and input/output technology), standardization, virtualization, grid computing, distributed computing, and Web services. Th is then leads us to one of the proverbial gorillas on the corner. What do you do with the cloud? Th e cloud is essen- tially a form of distributed computing. In this case, the cloud allows you to treat the platform, infrastructure, soft ware, and even business processes as remote services that can be managed by another fi rm. In many ways, the cloud allows much of IT to be outsourced (see the discussion of outsourcing later in this chapter). Also as brought up with the human–computer interaction layer, the whole issue of mobile computing is very relevant to this layer. In particular, the diff erent devices, such as phones and tablets, are relevant and the way they will communicate with each other, such as through cellular networks or WiFi, is also important.

Finally, given the amount of power that IT requires today, the whole topic of Green IT must be addressed. Topics that need to be addressed related to Green IT are the location of the data center, data center cooling, alternative power sources, reduction of consumables, the idea of a paperless offi ce, Energy Star compliance, and the potential impact of virtualization, the cloud, and mobile computing. Like the data management and human–computer interaction layers, a complete description of all the issues related to the physical architecture is beyond the scope of this book.13 However, we do present the basic issues in Chapter 11.

PACKAGES AND PACKAGE DIAGRAMS In UML, collaborations, partitions, and layers can be represented by a higher-level construct: a package.14 In fact, a package serves the same purpose as a folder on your computer. When pack- ages are used in programming languages such as Java, packages are actually implemented as fold- ers. A package is a general construct that can be applied to any of the elements in UML models. In Chapter 4, we introduced the idea of packages as a way to group use cases together to make the use-case diagrams easier to read and to keep the models at a reasonable level of complexity. In Chapters 5 and 6, we did the same thing for class and communication diagrams, respectively. In this section, we describe a package diagram: a diagram composed only of packages. A package diagram is eff ectively a class diagram that only shows packages.

Th e symbol for a package is similar to a tabbed folder (see Figure 7-18). Depending on where a package is used, packages can participate in diff erent types of relationships. For example, in a class diagram, packages represent groupings of classes. Th erefore, aggregation and association relationships are possible.

In a package diagram, it is useful to depict a new relationship, the dependency rela- tionship. A dependency relationship is portrayed by a dashed arrow (see Figure 7-18). A dependency relationship represents the fact that a modifi cation dependency exists between two packages. Th at is, it is possible that a change in one package could cause a change to

2 6 2 C h a p t e r 7   Moving on to Design

13 Some books that cover these topics include S. D. Burd, Systems Architecture, 6th Ed. (Boston: Course Technology, 2011); I. Englander, Th e Architecture of Computer Hardware, Systems Soft ware, & Networking: An Information Technology Approach (Hoboken, NJ: Wiley, 2009); K.K. Hausman and S. Cook, IT Architecture for Dummies (Hoboken, NJ: Wiley Publishing, 2011). 14 Th is discussion is based on material in Chapter 7 of M. Fowler with K. Scott, UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd Ed. (Reading, MA: Addison-Wesley, 2004).

Packages and Package Diagrams  263

be required in another package. Figure 7-19 portrays the dependencies among the diff erent layers (foundation, problem domain, data management, human–computer interaction, and physical architecture). For example, if a change occurs in the problem domain layer, it most likely will cause changes to occur in the human–computer interaction, physical architecture, and data management layers. Notice that these layers point to the problem domain layer and therefore are dependent on it. However, the reverse is not true.15 Also note that all layers are dependent upon the foundation layer. Th is is due to the contents of the foundation layer being the fundamental classes from which all other classes will be built. Consequently, any changes made to this layer could have ramifi cabitons to all other layers.

At the class level, there could be many causes for dependencies among classes. For example, if the protocol for a method is changed, then this causes the interface for all

A package:

■ Is a logical grouping of UML elements. ■ Is used to simplify UML diagrams by grouping related elements into a single

higher-level element.

A dependency relationship:

■ Represents a dependency between packages: If a package is changed, the dependent package also could have to be modified.

■ Has an arrow drawn from the dependent package toward the package on which it is dependent.

Package

FIGURE 7-18    Syntax for Package Diagram

Human–Computer Interaction

Problem Domain

Physical Architecture Data Management

Foundation

FIGURE 7-19 Package Diagram of Dependency Relationships among Layers

15 A useful side eff ect of the dependencies among the layers is that the project manager can divide the project team up into separate subteams: one for each design layer. Th is is possible because each of the design layers is dependent on the problem domain layer, which has been the focus of analysis. In design, the team can gain some productivity-based effi ciency by working on the diff erent layer designs in parallel.

2 6 4 C h a p t e r 7   Moving on to Design

objects of this class to change. Th erefore, all classes that have objects that send messages to the instances of the modifi ed class might have to be modifi ed. Capturing dependency relationships among the classes and packages helps the organization in maintaining object-oriented information systems.

Collaborations, partitions, and layers are modeled as packages in UML. Collaborations are normally factored into a set of partitions, which are typically placed on a layer. Partitions can be composed of other partitions. Also, it is possible to have classes in partitions, which are contained in another partition, which is placed on a layer. All these groupings are represented using packages in UML. Remember that a package is simply a generic grouping construct used to simplify UML models through the use of composition.16

A simple package diagram, based on the appointment system example from the previ- ous chapters, is shown in Figure 7-20. Th is diagram portrays only a very small portion of the entire system. In this case, we see that the Patient UI, Patient-DAM, and Patient Table classes depend on the Patient class. Furthermore, the Patient-DAM class depends on the Patient Table class. Th e same can be seen with the classes dealing with the actual appointments. By isolating the Problem Domain classes (such as the Patient and Appt classes) from the actual object- persistence classes (such as the Patient Table and Appt Table classes) through the use of the intermediate Data Management classes (Patient-DAM and Appt-DAM classes), we isolate the Problem Domain classes from the actual storage medium.17 Th is greatly simplifi es the main- tenance and increases the reusability of the Problem Domain classes. Of course, in a complete description of a real system, there would be many more dependencies.

Guidelines for Creating Package Diagrams As with the UML diagrams described in the earlier chapters, we provide a set of guidelines that we have adapted from Ambler to create package diagrams.18 In this case, we off er six guidelines.

■ Use package diagrams to logically organize designs. Specifi cally, use packages to group classes together when there is an inheritance, aggregation, or composition relationship between them or when the classes form a collaboration.

■ In some cases, inheritance, aggregation, or association relationships exist between packages. In those cases, for readability purposes, try to support inher- itance relationships vertically, with the package containing the superclass being placed above the package containing the subclass. Use horizontal placement to support aggregation and association relationships, with the packages being placed side by side.

■ When a dependency relationship exists on a diagram, it implies that there is at least one semantic relationship between elements of the two packages. Th e direction of the dependency is typically from the subclass to the superclass, from the whole to the part, and with contracts, from the client to the server. In other words, a subclass is dependent on the existence of a superclass, a whole is dependent upon its parts existing, and a client can’t send a message to a nonexist- ent server.

16 For those familiar with traditional approaches, such as structured analysis and design, packages serve a similar purpose as the leveling and balancing processes used in data fl ow diagramming. 17 Th ese issues are described in more detail in Chapter 9. 18 S. W. Ambler, Th e Elements of UML 2.0 Style (Cambridge, UK: Cambridge University Press, 2005).

■ When using packages to group use cases together, be sure to include the actors and the associations that they have with the use cases grouped in the package. Th is will allow the diagram’s user to better understand the context of the diagram.

■ Give each package a simple, but descriptive name to provide the package dia- gram user with enough information to understand what the package encapsulates. Otherwise, the user will have to drill-down or open up the package to understand the package’s purpose.

■ Be sure that packages are cohesive. For a package to be cohesive, the classes con- tained in the package, in some sense, belong together. A simple, but not perfect, rule to follow when grouping classes together in a package is that the more the classes depend on each other, the more likely they belong together in a package.

HCI Layer

Appt Sys UI

Patient UI Appt UI

PD Layer

Appt Sys

Patient Appt

DM Layer

Patient-DAM Appt-DAM

Patient Table Appt Table FIGURE 7-20 Partial Package Diagram of the Appointment System

Packages and Package Diagrams  265

2 6 6 C h a p t e r 7   Moving on to Design

Creating Package Diagrams In this section, we describe a simple fi ve-step process to create package diagrams. Th e fi rst step is to set the context for the package diagram. Remember, packages can be used to model partitions and/or layers. Revisiting the appointment system again, let’s set the context as the problem domain layer.

Th e second step is to cluster the classes together into partitions based on the relationships that the classes share. Th e relationships include generalization, aggregation, the various associations, and the message sending that takes place between the objects in the system. To identify the packages in the appointment system, we should look at the diff erent anal- ysis models [e.g., the class diagram (see Figure 7-15), the communication diagrams (see Figure 7-10)], and the CRUDE matrix (see Figure 7-12). Classes in a generalization hierarchy should be kept together in a single partition.

Th e third step is to place the clustered classes together in a partition and model the partitions as packages. Figure 7-21 portrays fi ve packages in the PD Layer: Account Pkg, Participant Pkg, Patient Pkg, Appointment Pkg, and Treatment Pkg.

Th e fourth step is to identify the dependency relationships among the packages. We accom- plish this by reviewing the relationships that cross the boundaries of the packages to uncover potential dependencies. In the appointment system, we see association relationships that connect the Account Pkg with the Appointment Pkg (via the associations between the Entry class and the Appointment class), the Participant Pkg with the Appointment Pkg (via the association between the Doctor class and the Appointment class), the Patient Pkg, which is contained within the Participant Pkg, with the Appointment Pkg (via the association between the Patient and Appointment classes), and the Patient Pkg with the Treatment Pkg (via the association between the Patient and Symptom classes).

Th e fi fth step is to lay out and draw the diagram. Using the guidelines, place the packages and dependency relationships in the diagram. In the case of the Appointment system, there are dependency relationships between the Account Pkg and the Appointment Pkg, the Participant Pkg and the Appointment Pkg, the Patient Pkg and the Appointment Pkg, and the Patient Pkg and the Treatment Pkg. To increase the understandability of the dependency relationships among the diff erent packages, a pure package diagram that shows only the dependency relationships among the packages can be created (see Figure 7-22).

Verifying and Validating Package Diagrams Like all the previous models, package diagrams need to be verifi ed and validated. In this case, the package diagrams were derived primarily from the class diagram, the communications diagrams, and the CRUDE matrix. Only two areas need to be reviewed.

First, the identifi ed packages must make sense from a problem domain point of view. For example, in the context of an appointment system, the packages in Figure 7-22 (Participant, Patient, Appt, Account, and Treatment) seem to be reasonable.

Second, all dependency relationships must be based on message-sending relationships on the communications diagram, cell entries in the CRUDE matrix, and associations on the class diagram. In the case of the appointment system, the identifi ed dependency relationships are reasonable (see Figures 7-10, 7-12, 7-15, and 7-22).

1. Set Context

2. Cluster Classes

3. Create Packages

4. Identify Dependencies

5. Lay Out and Draw Diagram

267

P D

L ay

er

A cc

o u n t

P kg

A cc

o u n t

h as

1 .. 1

1 ..

1 ..*

1 ..

1

1 ..

1

1 ..

1

1 ..

1

1 ..

1

0 ..

1 1 ..

1

1 ..

1

1 .. 1

1 .. 1

0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

0. .*

1. .*

0. .*

0. .*

1. .*

1. .*

1. .*

h as

It em

co n

ta in

s En

tr y

D eb

it

C re

d it

A p p o in

tm en

t P kg

Pa rt

ic ip

an t

P kg

-t im

e -d

at e

-r ea

so n

+ ca

n ce

l w

it h o u t n o ti ce

()

lo ca

te d A

t

P la

ce P re

sc ri

p ti

o n

G o

o d

Se rv

ic e

B ra

ce P

hy si

ca l

C h

ec ku

p

Tr an

sa ct

io n L

in e

It em

A ss

ig n ed

To

Pa ti

en t

P kg

Pa rt

ic ip

an t

-l as

tn am

e -fi

rs tn

am e

-a d d re

ss -p

h o n e

-b ir

th d

at e

-/ a

ge

schedules

Em p lo

ye e

D o ct

o r

R ec

ep ti

o n is

t N

u rs

e

Pa ti

en t

-a m

o u n t

-i n su

ra n ce

c ar

ri er

+ m

ak e

ap p o in

tm en

t( )

+ ca

lc u la

te l

as t

vi si

t( )

+ ch

an ge

s ta

tu s(

) +

p ro

vi d es

m ed

ic al

h is

to ry

()

su ff

er s

p ro

vi d es

+ p

ri m

ar y

in su

ra n ce

ca rr

ie r

U n p ai

d B

il l

M ed

ic al

H is

to ry

-h ea

rt d

is ea

se -h

ig h b

lo o d p

re ss

u re

-d ia

b et

es -a

ll er

gi es

Sy m

p to

m

-d es

cr ip

ti o

n

Tr ea

tm en

t m

ed ic

at io

n in

st ru

ct io

n s

sy m

p to

m s

ev er

it y

-n am

e Il

ln es

s

o w

es

A p p o in

tm en

t

Tr ea

tm en

t P kg

F IG

U R

E 7

-2 1

   P

ac k

ag e

D ia

g ra

m o

f th

e P

D L

ay e

r o

f th

e A

p p

o in

tm e

n t

P ro

b le

m

2 6 8 C h a p t e r 7   Moving on to Design

PD Layer

Account Pkg

Patient Pkg

Appointment Pkg

Treatment Pkg

Participant Pkg

FIGURE 7-22    Overview Package Diagram of the PD Layer for the Appointment System

DESIGN STRATEGIES Until now, we have assumed that the system will be built and implemented by the project team; however, there are actually three ways to approach the creation of a new system: devel- oping a custom application in-house, buying and customizing a packaged system, and rely- ing on an external vendor, developer, or service provider to build the system. Each of these choices has strengths and weaknesses, and each is more appropriate in diff erent scenarios. Th e following sections describe each design choice in turn, and then we present criteria that you can use to select one of the three approaches for your project.

Custom Development Many project teams assume that custom development, or building a new system from scratch, is the best way to create a system. For one thing, teams have complete control over the way the system looks and functions. Custom development also allows developers to be fl exible and creative in the way they solve business problems. Additionally, a custom application is easier to change to include components that take advantage of current technologies that can support such strategic eff orts.

Design Strategies  269

Building a system in-house also builds technical skills and functional knowledge within the company. As developers work with business users, their understanding of the business grows and they become better able to align IS with strategies and needs. Th ese same develop- ers climb the technology learning curve so that future projects applying similar technology require much less eff ort.

Custom application development, however, requires dedicated eff ort that involves long hours and hard work. Many companies have a development staff who already is overcom- mitted to fi lling huge backlogs of systems requests and just does not have time for another project. Also, a variety of skills—technical, interpersonal, functional, project management, and modeling—must be in place for the project to move ahead smoothly. IS professionals, especially highly skilled individuals, are quite diffi cult to hire and retain.

Th e risks associated with building a system from the ground up can be quite high, and there is no guarantee that the project will succeed. Developers could be pulled away to work on other projects, technical obstacles could cause unexpected delays, and the business users could become impatient with a growing timeline.

Packaged Soft ware Many business needs are not unique, and because it makes little sense to reinvent the wheel, many organizations buy packaged soft ware that has already been written rather than develop- ing their own custom solution. In fact, there are thousands of commercially available soft ware programs that have already been written to serve a multitude of purposes. Th ink about your own need for a word processor—did you ever consider writing your own word processing soft ware? Th at would be very silly considering the number of good soft ware packages availa- ble that are relatively inexpensive.

Similarly, most companies have needs that can be met quite well by packaged soft - ware, such as payroll or accounts receivable. It can be much more effi cient to buy pro- grams that have already been created, tested, and proven. Moreover, a packaged system can be bought and installed in a relatively short time when compared with a custom system. Plus, packaged systems incorporate the expertise and experience of the vendor who created the soft ware.

Packaged soft ware can range from reusable components to small, single-function tools to huge, all-encompassing systems such as enterprise resource planning (ERP) appli- cations that are installed to automate an entire business. Implementing ERP systems is a process in which large organizations spend millions of dollars installing packages by com- panies such as SAP or Oracle and then change their businesses accordingly. Installing ERP soft ware is much more diffi cult than installing small application packages because benefi ts can be harder to realize and problems are much more serious.

However, there are problems related to packaged soft ware. For example, companies buying packaged systems must accept the functionality that is provided by the system, and rarely is there a perfect fi t. If the packaged system is large in scope, its implementation could mean a substantial change in the way the company does business. Letting technology drive the business can be dangerous.

Most packaged applications allow customization, or the manipulation of system param- eters to change the way certain features work. For example, the package might have a way to accept information about your company or the company logo that would then appear on input screens. Or an accounting soft ware package could off er a choice of various ways to handle cash fl ow or inventory control so that it can support the accounting practices in diff erent organiza- tions. If the amount of customization is not enough and the soft ware package has a few fea- tures that don’t quite work the way the company needs it to work, the project team can create workarounds.

2 7 0 C h a p t e r 7   Moving on to Design

A workaround is a custom-built add-on program that interfaces with the packaged appli- cation to handle special needs. It can be a nice way to create needed functionality that does not exist in the soft ware package. But workarounds should be a last resort for several reasons. First, workarounds are not supported by the vendor who supplied the packaged soft ware, so upgrades to the main system might make the workaround ineff ective. Also, if problems arise, vendors have a tendency to blame the workaround as the culprit and refuse to provide support.

Although choosing a packaged soft ware system is simpler than custom development, it too can benefi t from following a formal methodology, just as if a custom application were being built.

Systems integration refers to the process of building new systems by combining pack- aged software, existing legacy systems, and new software written to integrate these. Many consulting firms specialize in systems integration, so it is not uncommon for companies to select the packaged software option and then outsource the integration of a variety of packages to a consulting firm. (Outsourcing is discussed in the next section.)

Th e key challenge in systems integration is fi nding ways to integrate the data produced by the diff erent packages and legacy systems. Integration oft en hinges on taking data produced by one package or system and reformatting it for use in another package or system. Th e project team starts by examining the data produced by and needed by the diff erent packages or systems and identifying the transformations that must occur to move the data from one to the other. In many cases, this involves fooling the diff erent packages or systems into thinking that the data were produced by an existing program module that the package or system expects to produce the data rather than the new package or system that is being integrated.

A third approach is through the use of an object wrapper.19 An object wrapper is essen- tially an object that “wraps around” a legacy system, enabling an object-oriented system to send messages to the legacy system. Eff ectively, object wrappers create an application pro- gram interface (API) to the legacy system. Th e creation of an object wrapper protects the corporation’s investment in the legacy system.

Outsourcing Th e design choice that requires the least amount of in-house resources is outsourcing— hiring an external vendor, developer, or service provider to create the system. Outsourcing has become quite popular in recent years. Some estimate that as many as 50 percent of companies with IT budgets of more than $5 million are currently outsourcing or evaluat- ing the approach.

With outsourcing, the decision making and/or management control of a business function is transferred to an outside supplier. Th is transfer requires two-way coordination, exchange of information, and trust between the supplier and the business. From an IT per- spective, IT outsourcing can include hiring consultants to solve a specifi c problem, hiring contract programmers to implement a solution, hiring a fi rm to manage the IT function and assets of a company, or actually outsourcing the entire IT function to a separate fi rm. Today, through the use of application service providers (ASPs), Web services technology, and cloud services, it is possible to use a pay-as-you-go approach for a soft ware package.20 Essentially, IT outsourcing involves hiring a third party to perform some IT function that traditionally would be performed in-house.

Th ere can be great benefi t to having someone else develop a company’s system. Th e out- side company may be more experienced in the technology or have more resources, such as

19 Ian Graham, Object-Oriented Methods: Principles & Practice, 3rd Ed. (Reading, MA: Addison-Wesley, 2001). 20 For an economic explanation of how this could work, see H. Baetjer, Soft ware as Capital: An Economic Perspective on Soft ware Engineering (Los Alamitos, CA: IEEE Computer Society Press, 1997).

experienced programmers. Many companies embark upon outsourcing deals to reduce costs, whereas others see it as an opportunity to add value to the business.

For whatever reason, outsourcing can be a good alternative for a new system. However, it does not come without costs. If you decide to leave the creation of a new system in the hands of someone else, you could compromise confi dential information or lose control over future development. In-house professionals are not benefi ting from the skills that could be learned from the project; instead, the expertise is transferred to the outside organ- ization. Ultimately, important skills can walk right out the door at the end of the contract. Furthermore, when off shore outsourcing is being considered, we must also be cognizant of language issues, time-zone diff erences, and cultural diff erences (e.g., acceptable business practices as understood in one country that may be unacceptable in another). All these concerns, if not dealt with properly, can prevail over any advantage that outsourcing or off - shore outsourcing could realize.

Most risks can be addressed if a company decides to outsource, but two are par- ticularly important. First, the company must thoroughly assess the requirements for the project—a company should never outsource what is not understood. If rigorous planning and analysis has occurred, then the company should be well aware of its needs. Second, the company should carefully choose a vendor, developer, or service with a proven track record with the type of system and technology that its system needs.

Th ree primary types of contracts can be drawn to control the outsourcing deal. A time-and-arrangements contract is very fl exible because a company agrees to pay for whatever time and expenses are needed to get the job done. Of course, this agreement could result in a large bill that exceeds initial estimates. Th is works best when the company and the outsourcer are unclear about what it is going to take to fi nish the job.

A company will pay no more than expected with a fi xed-price contract because if the out- sourcer exceeds the agreed-upon price, it will have to absorb the costs. Outsourcers are much more careful about defi ning requirements clearly up front, and there is little fl exibility for change.

Th e type of contract gaining in popularity is the value-added contract, whereby the out- sourcer reaps some percentage of the completed system’s benefi ts. Th e company has very little risk in this case, but it must expect to share the wealth once the system is in place.

Creating fair contracts is an art because fl exibility must be carefully balanced with clearly defi ned terms. Oft en, needs change over time. Th erefore, the contract should not be so specifi c and rigid that alterations cannot be made. Th ink about how quickly mobile technology has changed. It is diffi cult to foresee how a project might evolve over a long period of time. Short-term contracts help leave room for reassessment if needs change or if relationships are not working out the way both parties expected. In all cases, the relationship with the outsourcer should be viewed as a part- nership where both parties benefi t and communicate openly.

Managing the outsourcing relationship is a full-time job. Th us, someone needs to be assigned full time to manage the outsourcer, and the level of that person should be appropriate for the size of the job (a multimillion dollar outsourcing engagement should be handled by a high-level executive). Th roughout the relationship, progress should be tracked and measured against prede- termined goals. If a company does embark upon an outsourcing design strategy, it should be sure to get adequate information. Many books have been written that provide much more detailed information on the topic.21 Figure 7-23 summarizes some guidelines for outsourcing.

21 For more information on outsourcing, we recommend M. Lacity and R. Hirschheim, Information Systems Out- sourcing: Myths, Metaphors, and Realities (New York, NY: Wiley, 1993); L. Willcocks and G. Fitzgerald, A Business Guide to Outsourcing Information Technology (London: Business Intelligence, 1994); E. Carmel, Off shoring Infor- mation Technology: Sourcing and Outsourcing to a Global Workforce (Cambridge, England: Cambridge University Press, 2005); J. K. Halvey and B. M. Melby, Information Technology Outsourcing Transactions: Process, Strategies, and Contracts, 2nd Ed. (Hoboken, NJ: Wiley, 2005); T. L. Friedman, Th e World Is Flat: A Brief History of the Twenty-First Century, Updated and Expanded Edition (New York: Farrar, Straus, and Giroux, 2006).

Design Strategies  271

2 7 2 C h a p t e r 7   Moving on to Design

Selecting a Design Strategy Each of the design strategies just discussed has its strengths and weaknesses, and no one strat- egy is inherently better than the others. Th us, it is important to understand the strengths and weaknesses of each strategy and when to use each. Figure 7-24 summarizes the characteristics of each strategy.

Business Need If the business need for the system is common and technical solutions already exist that can meet the business need of the system, it makes little sense to build a custom application. Packaged systems are good alternatives for common business needs. A custom alternative should be explored when the business need is unique or has special requirements. Usually, if the business need is not critical to the company, then outsourcing is the best choice—someone outside of the organization can be responsible for the application development.

In-house Experience If in-house experience exists for all the functional and technical needs of the system, it will be easier to build a custom application than if these skills do not exist. A packaged system may be a better alternative for companies that do not have the technical skills to build the desired system. For example, a project team that does not have mobile tech- nology skills might want to consider outsourcing those aspects of the system.

Project Skills Th e skills that are applied during projects are either technical (e.g., Java, SQL) or functional (e.g., security), and diff erent design alternatives are more viable, depending on

• Keep the lines of communication open between you and your outsourcer.

• Defi ne and stabilize requirements before signing a contact.

• View the outsourcing relationship as a partnership.

• Select the vendor, developer or service provider carefully.

• Assign a person to managing the relationship.

• Don’t outsource what you don’t understand.

• Emphasize fl exible requirements, long-term relationships and short-term contracts.

FIGURE 7-23 Outsourcing Guidelines

Outsourcing

Business Need The business need is unique. The business need is common. The business need is not core to the business.

In-house Experience In-house functional and In-house functional In-house functional or technical technical experience exists. experience exists. experience does not exist.

Project Skills There is a desire to The skills are not strategic. The decision to outsource is a build in-house skills. strategic decision.

Project Management The project has a highly The project has a project The project has a highly skilled skilled project manager manager who can coordinate project manager at the level of and a proven methodology. the vendor’s efforts. the organization that matches the scope of the outsourcing deal.

Time frame The time frame is fl exible. The time frame is short. The time frame is short or fl exible.

Use Custom Use a Packaged Use Outsourcing Development When… System When… When…

FIGURE 7-24    Selecting a Design Strategy

Selecting an Acquisition Strategy  273

how important the skills are to the company’s strategy. For example, if certain functional and technical expertise that relates to mobile application development is important to an organi- zation because it expects mobile to play an important role in its sales over time, then it makes sense for the company to develop mobile applications in-house, using company employees so that the skills can be developed and improved. On the other hand, some skills, such as network security, may be beyond the technical expertise of employees or not of interest to the company’s strategists—it is just an operational issue that needs to be addressed. In this case, packaged systems or outsourcing should be considered so that internal employees can focus on other business-critical applications and skills.

Project Management Custom applications require excellent project management and a proven methodology. So many things, such as funding obstacles, staffi ng holdups, and overly demanding business users, can push a project off -track. Th erefore, the project team should choose to develop a custom application only if it is certain that the underlying coordination and control mechanisms will be in place. Packaged and outsourcing alternatives also need to be managed; however, they are more shielded from internal obstacles because the external parties have their own objectives and priorities (e.g., it may be easier for an outside contractor to say no to a user than it is for a person within the company). Typically, packaged and outsourcing alternatives have their own methodologies, which can benefi t companies that do not have an appropriate methodology to use.

Time Frame When time is a factor, the project team should probably start looking for a system that is already built and tested. In this way, the company will have a good idea of how long the package will take to put in place and what the fi nal result will contain. Th e time frame for custom applications is hard to pin down, especially when you consider how many projects end up missing important deadlines. If a company must choose the custom development alternative and the time frame is very short, it should consider using techniques such as timeboxing to manage this problem. Th e time to produce a system using outsourcing really depends on the system and the outsourcer’s resources. If a service provider has ser- vices in place that can be used to support the company’s needs, then a business need could be implemented quickly. Otherwise, an outsourcing solution could take as long as a custom development initiative.

SELECTING AN ACQUISITION STRATEGY Once the project team has a good understanding of how well each design strategy fi ts with the project’s needs, it must begin to understand exactly how to implement these strategies. For exam- ple, what tools and technology would be used if a custom alternative were selected? What vendors make packaged systems that address the project’s needs? What service providers would be able to build this system if the application were outsourced? Th is information can be obtained from peo- ple working in the IS department and from recommendations by business users. Alternatively, the project team can contact other companies with similar needs and investigate the types of systems that they have put in place. Vendors and consultants usually are willing to provide information about various tools and solutions in the form of brochures, product demonstrations, and information seminars. However, a company should be sure to validate the information it receives from vendors and consultants. Aft er all, they are trying to make a sale. Th erefore, they may stretch the capabilities of their tool by focusing on only the positive aspects of the tool while omitting the tool’s drawbacks.

It is likely that the project team will identify several ways that a system could be con- structed aft er weighing the specifi c design options. For example, the project team might have

2 7 4 C h a p t e r 7   Moving on to Design

found three vendors that make packaged systems that potentially could meet the project’s needs. Or the team may be debating over whether to develop a system using Java as a devel- opment tool and the database management system from Oracle or to outsource the develop- ment eff ort to a consulting fi rm such as Accenture or CGI. Each alternative has pros and cons associated with it that need to be considered, and only one solution can be selected in the end.

To aid in this decision, additional information should be collected. Project teams employ several approaches to gather additional information that is needed. One helpful tool is the request for proposal (RFP), a document that solicits a formal proposal from a potential vendor, developer, or service provider. RFPs describe in detail the system or service that is needed, and vendors respond by describing in detail how they could supply those needs.

Although there is no standard way of writing an RFP, it should include certain key facts that the vendor requires, such as a detailed description of needs, any special technical needs or circumstances, evaluation criteria, procedures to follow, and a timetable. In a large project, the RFP can be hundreds of pages long, since it is essential that all required project details are included.

Th e RFP is not just a way to gather information. Rather, it results in a vendor proposal that is a binding off er to accomplish the tasks described in the RFP. Th e vendor proposal includes a schedule and a price for which the work is to be performed. Once the winning vendor proposal is chosen, a contract for the work is developed and signed by both parties.

For smaller projects with smaller budgets, the request for information (RFI) may be suffi cient. An RFI is a shorter, less detailed request that is sent to potential vendors to obtain general information about their products and services. Sometimes, the RFI is used to deter- mine which vendors have the capability to perform a service. It is oft en then followed up with an RFP to the qualifi ed vendors.

When a list of equipment is so complete that the vendor need only provide a price, with- out any analysis or description of what is needed, the request for quote (RFQ) may be used. For example, if twenty long-range RFID tag readers are needed from the manufacturer on a certain date at a certain location, the RFQ can be used. If an item is described, but a specifi c manufacturer’s product is not named, then extensive testing will be required to verify fulfi ll- ment of the specifi cations.

Alternative Matrix An alternative matrix can be used to organize the pros and cons of the design alternatives so that the best solution will be chosen in the end (see Figure 7-25). Th is matrix is created using the same steps as the feasibility analysis, which was presented in Chapter 2. Th e only diff erence is that the alternative matrix combines several feasibility analyses into one matrix so that the alternatives can easily be compared. An alternative matrix is a grid that contains the technical, budget, and organizational feasibilities for each system candidate, pros and cons associated with adopting each solution, and other information that is helpful when making comparisons. Sometimes weights are provided for diff erent parts of the matrix to show when some criteria are more important to the fi nal decision.

To create the alternative matrix, draw a grid with the alternatives across the top and dif- ferent criteria (e.g., feasibilities, pros, cons, and other miscellaneous criteria) along the side. Next, fi ll in the grid with detailed descriptions about each alternative. Th is becomes a useful document for discussion because it clearly presents the alternatives being reviewed and com- parable characteristics for each one.

Sometimes, weights and scores are added to the alternative matrix to create a weighted alternative matrix that communicates the project’s most important criteria and the alternatives that best address them. A scorecard is built by adding a column labeled “weight” that includes

Selecting an Acquisition Strategy  275

a number depicting how much each criterion matters to the fi nal decision. Typically, analysts take 100 points and spread them out across the criteria appropriately. If fi ve criteria were used and all mattered equally, then each criterion would receive a weight of 20. However, if costs were the most important criterion for choosing an alternative, it might receive 60 points, and the other four criteria might get only 10 points each.

Th en, the analysts add to the matrix a column called “Score” that communicates how well each alternative meets the criteria. Usually, number ranges like 1 to 5 or 1 to 10 are used to rate the appropriateness of the alternatives by the criteria. So, for the cost criterion, the least expensive alternative may receive a 5 on a 1-to-5 scale, whereas a costly alternative would receive a 1. Weighted scores are computed with each criterion’s weight multiplied by the score it was given for each alternative. Th en, the weighted scores are totaled for each alternative. Th e highest weighted score achieves the best match for our criteria. When numbers are used in the alternative matrix, project teams can make decisions quantitatively and on the basis of hard numbers.

It should be pointed out, however, that the score assigned to the criteria for each alternative is nothing more than a subjective assignment. Consequently, it is entirely possible for an analyst to skew the analysis according to his or her own biases. In other words, the weighted alternative matrix can be made to support whichever alternative you prefer and yet retains the appearance of an objective, rational analysis. To avoid the problem of a biased analysis, each analyst on the team could develop ratings independently; then, the ratings could be compared and discrepan- cies resolved in an open team discussion.

Th e fi nal step, of course, is to decide which solution to design and implement. Th e deci- sion should be made by a combination of business users and technical professionals aft er the issues involved with the diff erent alternatives are well understood. Once the decision is fi nalized, design can continue as needed, based on the selected alternative.

Technical Issues:

Criterion 1 20 5 100 3 60 3 60 Criterion 2 10 3 30 3 30 5 50 Criterion 3 10 2 20 1 10 3 30

Economic Issues:

Criterion 4 25 Supporting 3 75 Supporting 3 75 Supporting 5 125 Criterion 5 10 Information 3 30 Information 1 10 Information 5 50

Organizational Issues:

Criterion 6 10 5 50 5 50 3 30 Criterion 7 10 3 30 3 30 1 10 Criterion 8 5 3 15 1 5 1 5

TOTAL 100 350 270 360

* This denotes how well the alternative meets the criteria. 1 = poor fi t; 5 = perfect fi t.

Relative Alternative 1: Alternative 2: Alternative 3: Evaluation Importance Custom Score Weighted Custom Score Weighted Packaged Score Weighted Criteria (Weight) Application (1–5)* Score Application (1–5)* Score Software (1–5)* Score Using VB.NET Using Java Product ABC

FIGURE 7-25    Sample Alternative Matrix Using Weights

▲

▲

▲

▲

▲

▲

2 7 6 C h a p t e r 7   Moving on to Design

APPLYING THE CONCEPTS AT PATTERSON SUPERSTORE Th e team had one major task to complete before moving into design. Aft er developing and verifying the functional, structural, and behavioral models, they now had to validate that the functional, structural, and behavioral models developed in analysis agreed with each other. In other words, they needed to balance the functional, structural, and behavioral models. As you will see, this activity revealed inconsistencies and uncovered new informa- tion about the system that they hope to implement. Aft er creating corrected iterations of each of the three types of models, the team explored design alternatives and determined a design strategy.

You can fi nd the rest of the case at: www.wiley.com/go/dennis/casestudy

CHAPTER REVIEW Aft er reading and studying this chapter, you should be able to:

Describe the purpose of balancing the analysis models. Balance the functional models with the structural models. Balance the functional models with the behavioral models. Balance the structural models with the behavioral models. Describe the purpose of the factoring, refi nement, and abstraction processes. Describe the purpose of partitions and collaborations. Name and describe the layers. Explain the purpose of a package diagram. Describe the diff erent elements of the package diagram. Create a package diagram to model partitions and layers. Verify and validate package diagrams using walkthroughs. Describe the pros and cons of the three basic design strategies. Describe the basis of selecting a design strategy. Explain how and when to use RFPs, RFIs, and RFQs to gather information from vendors. Describe how to use a weighted alternative matrix to select an acquisition strategy.

KEY TERMS

A-kind-of Abstract classes Abstraction Aggregation Alternative matrix Balancing the models Class Client Collaboration Concrete classes Contract Controller Custom development Customization

Data management layer Dependency relationship Enterprise resource

systems (ERP) Factoring Fixed-price contract Foundation layer Generalization Has-parts Human–computer

interaction layer Layer Message Method

Model Model-View-Controller

(MVC) Module Object wrapper Outsourcing Package Package diagram Packaged soft ware Partition Physical architecture

layer Problem domain layer Refi nement

Request for information (RFI)

Request for proposals (RFP)

Server Smalltalk Systems integration Time-and-arrangements

contract Validation Value-added contract Verifi cation View Workaround

Exercises  277

QUESTIONS

1. Explain the primary diff erence between an analysis model and a design model.

2. What is meant by balancing the models? 3. What are the interrelationships among the functional,

structural, and behavioral models that need to be tested? 4. What does factoring mean? How is it related to

abstraction and refi nement? 5. What is a partition? How does a partition relate to a

collaboration? 6. What is a layer? Name the diff erent layers. 7. What is the purpose of the diff erent layers? 8. Describe the diff erent types of classes that can appear

on each of the layers. 9. What issues or questions arise on each of the diff erent

layers? 10. What is a package? How are packages related to parti-

tions and layers? 11. What is a dependency relationship? How do you iden-

tify them? 12. What are the fi ve steps for identifying packages and

creating package diagrams?

13. What needs to be verifi ed and validated in package diagrams?

14. When drawing package diagrams, what guidelines should you follow?

15. What situations are most appropriate for a custom development design strategy?

16. What are some problems with using a packaged soft - ware approach to building a new system? How can these problems be addressed?

17. Why do companies invest in ERP systems? 18. What are the pros and cons of using a workaround? 19. When is outsourcing considered a good design strat-

egy? When is it not appropriate? 20. What is an object wrapper? 21. What is systems integration? Explain the challenges. 22. What are the diff erences between the time-and-

arrangements, fi xed-price, and value-added contracts for outsourcing?

23. How are the alternative matrix and feasibility analysis related?

24. What is an RFP? How is this diff erent from an RFI?

EXERCISES

A. For the A Real Estate Inc. problem in Chapters 4 (exer- cises I, J, and K), 5 (exercises P and Q), and 6 (exercise D):

1. Perform a verifi cation and validation walkthrough of the functional, structural, and behavioral models to ensure that all between-model issues have been resolved.

2. Using the communication diagrams and the CRUDE matrix, create a package diagram of the problem domain layer.

3. Perform a verifi cation and validation walkthrough of the package diagram.

4. Based on the analysis models that have been created and your current understanding of the fi rm’s posi- tion, what design strategy would you recommend? Why?

B. For the A Video Store problem in Chapters 4 (exercises L, M, and N), 5 (exercises R and S), and 6 (exercise E):

1. Perform a verifi cation and validation walkthrough of the functional, structural, and behavioral models to ensure that all between-model issues have been resolved.

2. Using the communication diagrams and the CRUDE matrix, create a package diagram of the problem domain layer.

3. Perform a verifi cation and validation walkthrough of the package diagram.

4. Based on the analysis models that have been created and your current understanding of the fi rm’s position, what design strategy would you recommend? Why?

C. For the health club membership problem in Chap- ters 4 (exercises O, P, and Q), 5 (exercises T and U), and 6 (exercise F):

1. Perform a verifi cation and validation walkthrough of the functional, structural, and behavioral models to ensure that all between-model issues have been resolved.

2. Using the communication diagrams and the CRUDE matrix, create a package diagram of the problem domain layer.

3. Perform a verifi cation and validation walkthrough of the package diagram.

2 7 8 C h a p t e r 7   Moving on to Design

4. Based on the analysis models that have been created and your current understanding of the fi rm’s posi- tion, what design strategy would you recommend? Why?

D. For the Picnics R Us problem in Chapters 4 (exercises R, S, and T), 5 (exercises V and W), and 6 (exercise G):

1. Perform a verifi cation and validation walkthrough of the functional, structural, and behavioral models to ensure that all between-model issues have been resolved.

2. Using the communication diagrams and the CRUDE matrix, create a package diagram of the problem domain layer.

3. Perform a verifi cation and validation walkthrough of the package diagram.

4. Based on the analysis models that have been created and your current understanding of the fi rm’s posi- tion, what design strategy would you recommend? Why?

E. For the Of-the-Month-Club problem in Chapters 4 (exercises U, V, and W), 5 (exercises X and Y), and 6 (exercise H):

1. Perform a verifi cation and validation walkthrough of the functional, structural, and behavioral models

to ensure that all between-model issues have been resolved.

2. Using the communication diagrams and the CRUDE matrix, create a package diagram of the problem domain layer.

3. Perform a verifi cation and validation walkthrough of the package diagram.

4. Based on the analysis models that have been created and your current understanding of the fi rm’s posi- tion, what design strategy would you recommend? Why?

F. Suppose you are leading a project that will implement a new course-enrollment system for your univer- sity. You are thinking about either using a packaged course-enrollment application or outsourcing the job to an external consultant. Create an outline for an RFP to which interested vendors and consultants could respond.

G. Suppose you and your friends are starting a small busi- ness painting houses in the summertime. You need to buy a soft ware package that handles the fi nancial trans- actions of the business. Create an alternative matrix that compares three packaged systems (e.g., Quicken, MS Money, Quickbooks). Which alternative appears to be the best choice?

MINICASES

1. Susan, president of MOTO, Inc., a human resources management fi rm, is refl ecting on the client man- agement soft ware system her organization purchased four years ago. At that time, the fi rm had just gone through a major growth spurt, and the mixture of automated and manual procedures that had been used to manage client accounts became unwieldy. Susan and Nancy, her IS department head, researched and selected the package that is currently used. Susan had heard about the soft ware at a professional con- ference she attended, and, at least initially, it worked fairly well for the fi rm. Some of their procedures had to change to fi t the package, but they expected that and were prepared for it.

Since that time, MOTO, Inc., has continued to grow, not only through an expansion of the client base but also through the acquisition of several smaller employment-related businesses. MOTO, Inc., is a much diff erent business than it was four years ago. Along with expanding to off er more diversifi ed human

resources management services, the fi rm’s support staff has also expanded. Susan and Nancy are particu- larly proud of the IS department they have built up over the years. Using strong ties with a local university, an attractive compensation package, and a good working environment, the IS department is well staff ed with competent, innovative people, plus a steady stream of college interns that keeps the department fresh and lively. One of the IS teams pioneered the use of the Internet to off er MOTO’s services to a whole new market segment, an experiment that has proved very successful.

It seems clear that a major change is needed in the client-management soft ware, and Susan has already begun to plan fi nancially to undertake such a project. Th is soft ware is a central part of MOTO’s operations, and Susan wants to be sure that a high-quality system is obtained this time. She knows that the vendor of their current system has made some revisions and additions to its product line. A number of other

Minicases  279

soft ware vendors also off er products that may be suitable. Some of these vendors did not exist when the purchase was made four years ago. Susan is also con- sidering Nancy’s suggestion that the IS department develop a custom soft ware application.

a. Outline the issues that Susan should consider that would support the development of a custom soft - ware application in-house.

b. Outline the issues that Susan should consider that would support the purchase of a software package.

c. Within the context of a systems-development pro- ject, when should the decision of make-versus-buy be made? How should Susan proceed? Explain your answer.

2. Refer to minicase 1 (West Star Marinas) in Chapter 5. Aft er all the analysis models (both the as-is and to-be models) for West Star Marinas were completed, the director of operations fi nally understood why it was important to understand the as-is system before delv- ing into the development of the to-be system. How- ever, you now tell him that the to-be models are only the problem-domain portion of the design. He is now very confused. Aft er explaining to him the advantages of using a layered approach to developing the system, he says, “I don’t care about reusability or mainte- nance. I only want the system to be implemented as soon as possible. You IS types are always trying to pull a fast one on the users. Just get the system completed.”

What is your response to the Director of Operations? Do you jump into implementation as he seems to want? What do you do next?

3. Refer to the analysis models that you created for pro- fessional and scientifi c staff management (PSSM) for minicase 2 in Chapter 4 and for minicase 1 in Chapter 6.

a. Perform a verifi cation and validation walkthrough of the functional, structural, and behavioral models to ensure that all between-model issues have been resolved.

b. Using the communication diagrams and the CRUDE matrix, create a package diagram of the problem domain layer.

c. Perform a verifi cation and validation walkthrough of the package diagram.

d. Based on the analysis models that have been cre- ated and your current understanding of the fi rm’s position, what design strategy would you recom- mend? Why?

4. Refer to the analysis models that you created for Holiday Travel Vehicles for minicase 2 in Chapter 5 and for minicase 2 in Chapter 6.

a. Perform a verifi cation and validation walkthrough of the functional, structural, and behavioral models to ensure that all between-model issues have been resolved.

b. Using the communication diagrams and the CRUDE matrix, create a package diagram of the problem domain layer.

c. Perform a verifi cation and validation walkthrough of the package diagram.

d. Based on the analysis models that have been created and your current understanding of the fi rm’s position, what design strategy would you recommend? Why?

The most important step of the design phase is designing the individual classes and meth- ods. Object-oriented systems can be quite complex, so analysts need to create instructions and guidelines for programmers that clearly describe what the system must do. Th is chapter presents a set of criteria, activities, and techniques used to design classes and methods. Together they are used to ensure that the object-oriented design communicates how the system needs to be coded.

OBJECTIVES

■ Become familiar with coupling, cohesion, and connascence. ■ Be able to specify, restructure, and optimize object designs. ■ Be able to identify the reuse of predefi ned classes, libraries, frameworks, and components. ■ Be able to specify constraints and contracts. ■ Be able to create a method specifi cation.

INTRODUCTION WARNING: Th is material may be hazardous to your mental stability. Not really, but now that we have your attention, you must realize that this material is fairly technical in nature and that it is extremely important in today’s “fl at” world. Today, much of the actual implemen- tation will be done in a diff erent geographic location than where the analysis and design are performed. We must ensure that the design is specifi ed in a “correct” manner and that there is no, or at least minimal, ambiguity in the design specifi cation.

In today’s fl at world, the common language spoken among developers is very likely to be UML and some object-oriented language, such as Java, and not English. English has always been and always will be ambiguous. Furthermore, to what variety of English do we refer? As both Oscar Wilde and George Bernard Shaw independently pointed out, the United States and England are divided by a common language.

Practically speaking, Class and Method design is where all the work actually gets done during design. No matter which layer you are focusing on, the classes, which will be used to create the system objects, must be designed. Some people believe that with reusable class libraries and off -the-shelf components, this type of low-level, or detailed, design is a waste of time and that we should jump immediately into the “real” work: coding the system. However, past experience shows that low-level, or detailed, design is critical despite the use of libraries and components. Detailed design is still very important for three reasons. First, with today’s modern CASE tools, quite a bit of the actual code can be generated by the tool from the detailed design. Second, even preexisting classes and components need to be understood, organized, and pieced together. Th ird, it is still common for the project team

C H A P T E R 8

Class and Method Design

280

Introduction  281

to have to write some code and produce original classes that support the application logic of the system.

Jumping right into coding will guarantee disastrous results. For example, even though the use of layers can simplify the individual classes, they can increase the complexity of the interactions between them. If the classes are not designed carefully, the resulting system can be very ineffi cient. Or worse, the instances of the classes (i.e., the objects) will not be capable of communicating with each other, which will result in the system’s not working properly.

In an object-oriented system, changes can take place at diff erent levels of abstraction. Th ese levels include variable, method, class/object, package,1 library, and/or application/ system levels (see Figure 8-1). Th e changes that take place at one level can aff ect other levels (e.g., changes to a class can aff ect the package level, which can aff ect both the system level and the library level, which in turn can cause changes back down at the class level). Finally, changes can occur at diff erent levels at the same time.

Th e good news is that the detailed design of the individual classes and methods is fairly straightforward. Th e interactions among the objects on the problem-domain layer have been designed, in some detail, during analysis (see Chapters 4 through 6). Th e other layers (data management, human–computer interaction, and physical architecture) are highly dependent on the problem-domain layer. Th erefore, if the problem-domain classes are designed correctly, the design of the classes on the other layers will fall into place, relatively speaking.

Th at being said, it has been our experience that many project teams are much too quick at jumping into writing code for the classes without fi rst designing them. Some of this has been caused by the fact that object-oriented systems analysis and design has evolved from object-oriented programming. Until recently there has been a general lack of accepted guide- lines on how to design and develop eff ective object-oriented systems. However, with the

Class/Object

Package

System

Library

Variable Method FIGURE 8-1 Levels of Abstraction in Object-Oriented Systems

Source: Based on material from David P. Tegarden, Steven D. Sheetz, and David E. Monarchi, “A Software Complexity Model of Object-Oriented Systems,” Decision Support Systems 13 (March 1995): 241–262.

1 A package is a group of collaborating objects. Other names for a package include cluster, partition, pattern, subject, and subsystem.