Front Matter.2

Instructor’s Manual to accompany

An Introduction to Object-Oriented

Systems Analysis and Design with UML and

the Unified ProcessStephen R. Schach

Vanderbilt University

Prepared byStephen R. Schach

Vanderbilt University

Kristin C. IrwinVanderbilt University

Lauren S. SchachMacquarie University

David M. SchachNorthwestern University

McGraw-Hill

1221 Avenue of the AmericasNew York, NY 10020

Instructor’s Solutions Manual to accompany AN INTRODUCTION TO OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN WITH UML AND THE UNIFIED PROCESS by Stephen R. Schach.

Copyright © 2004 by McGraw-Hill, Inc.

All rights reserved under International and Pan-American Copyright Convention. No part of this book may be reproduced in any form or by any means, electronic or mechanical, includ-ing photocopying, without permission in writing from the publisher, except for classroom use for instructors using AN INTRODUCTION TO OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN WITH UML AND THE UNIFIED PROCESS as a course text, and provided that the reproduced materials are retrieved by the instructor and either perma-nently secured or destroyed after such classroom use. All inquiries should be addressed to McGraw-Hill, Inc., 1221 Avenue of the Americas, New York, NY 10020. Published in the United States by McGraw-Hill, Inc.

The programs in this book have been included for their instructional value. They have been tested with care but are not guaranteed for any particular purpose. The publisher does not offer any warranties or representations, nor does it accept any liabilities with respect to the programs.

Many of the designations used by manufactures and sellers to distinguish their products are claimed as trademarks. The publisher has made every attempt to supply trademark informa-tion about manufacturers and their products mentioned in this book.

ISBN:

Manufactured in the United States of America

ii

To our families

iii

The following are registered trademarks:

LinuxPowerPointRational Rose

iv

CONTENTS

To the Instructor................................................................................................................... vi

Chapter 1. Introduction to Information Systems..............................................................1–1

Chapter 2. How Information Systems are Developed......................................................2–1

Chapter 3. The Object-Oriented Paradigm......................................................................3–1

Chapter 4. The Requirements Workflow I.......................................................................4–1

Chapter 5. The Requirements Workflow II.....................................................................5–1

Chapter 6. The Object-Oriented Analysis Workflow I....................................................6–1

Chapter 7. The Object-Oriented Analysis Workflow II...................................................7–1

Chapter 8. The Object-Oriented Design Workflow.........................................................8–1

Chapter 9. The Workflows and Phases of the Unified Process........................................9–1

Chapter 10. More on UML.............................................................................................. 10–1

Chapter 11. CASE.......................................................................................................... 11–1

Chapter 12. Teams.......................................................................................................... 12–1

Chapter 13. Testing......................................................................................................... 13–1

Chapter 14. Management Issues...................................................................................... 14–1

Chapter 15. Planning and Estimating..............................................................................15–1

Chapter 16. Maintenance................................................................................................ 16–1

Chapter 17. User-Interface Design..................................................................................17–1

Chapter 18. Web-Based Information Systems.................................................................18–1

Chapter 19. Database Management Systems...................................................................19–1

Chapter 20. Technical Topics.......................................................................................... 20–1

v

TO THE INSTRUCTOR

An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process is a textbook intended for business students. No previous knowledge of program-ming is required. The wide variety of problems allows the instructor to focus the course in a way that will achieve his or her desired course objectives.

HOW THIS INSTRUCTOR’S MANUAL IS ORGANIZED

This preface contains teaching suggestions relating to the book as a whole. Each chapter consists of material relating to the corresponding chapter of An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process, namely, teaching suggestions for that specific chapter and solutions to the review questions, problems, systems analysis and design projects, and term project component(s) for that chapter.

ABOUT THE PROBLEM SETS

There are four different types of problems: review questions, problems, the two systems analysis and design projects, and the term project. The problems are of different types, including essay-type problems, numerical problems, and problems that essentially require nothing more than understanding what was taught in class. The instructor may select from the problem sets for each chapter.

I strongly recommend that the two systems analysis and design projects be assigned to the class. These projects require the student to perform the systems analysis and design for two very different kinds of information systems, namely, an automated library and an ATM. Solving these problems requires a student to understand the requirements and analysis work-flow of the Unified Process. I also strongly recommend that the class be assigned the term project, a larger and more complex information system than the other two.

vi

In my opinion, it is most important that students get experience working in teams building an information system. In the real world, information systems are almost invariably developed by teams, and I believe that we shortchange our students if we do not give them this experi-ence. The size of the team is critical. Three is the smallest team that cannot collaborate over a standard telephone; the term project in the book was designed for teams of that size, and it works well. Of course, few students are considerate enough to ensure that the class size will always be a multiple of three—there will usually have to be one or two teams of size four! The problem with teams of more than three members is that one or two students always seem to end up doing all the work, whereas a team of three usually shares the load evenly among the team members.

An important issue is whether to assign students to teams or allow students to choose their own. On the one hand, over 20 years’ experience of team projects has convinced me that students should choose their own teams. Invariably, of course, when I call for the names of team members a few students have not joined a team. These students I assign to their own team, and this is the team that comes to me with problems of the “we can’t get along with one another” variety.

On the other hand, there is also the fairness aspect. My experience is that the top students form their own teams, as do the weaker students. Furthermore, in the real world, employees have little or no say in the make-up of the teams in which they work. On balance, therefore, I currently lean toward assigned teams based on the last name of the student as it appears in the class roll.

A difficulty that can arise with teams, whether assigned or chosen by the team members, is that one team member complains that he or she is doing all the work, and that it is unfair that all the team members should get the same grade for the project. To obviate this problem, the members of each team evaluate the extent to which their fellow team members contributed to the team. I then give 10% of the overall grade for team effort. For example, if a student feels that a specific member of the team tried his or her utmost to contribute to every assign-ment, then the student would give that team member 10/10. On the other hand, if the team member never came to team meetings and did not contribute anything toward the team effort, then the student would give that team member 0/10 for the team effort grade.

The problems based on the case studies were included because many instructors feel that beginners can learn more from modifying or extending an existing solution than by strug-gling to create a new solution from scratch. This approach is particularly appropriate to the study of information systems. After all, the majority of information system professionals modify (maintain) existing information systems, rather than create (develop) new informa-tion systems.

How many of the problems should be assigned to the class? This will depend on what is considered a “reasonable” amount of work at your university or college. I think that the bare minimum is: all the review questions, both the systems analysis and design projects (done individually or in teams), the term project (excluding 8.14, 9.8, and 13.9) done in teams, plus as many of the problems as you feel are appropriate for the class.

vii

I consider the most important problems to be 5.7 and 7.10, followed by 5.5, 5.6, 7.8, and 7.9. At the end of the course, I feel that I have succeeded if the students have learned how to per-form the requirements and analysis workflows, functioning as members of a team.

The term project has been designed generically. That is to say, it consists of 12 components that can be applied to any term project of the instructor’s choosing, not just the project in An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process. The project has been broken up into pieces so that the instructor can soon detect if a team has fallen behind. If this happens, remedial action can quickly be taken to help the team get back on track. Also, asking for 12 different items to be handed in on 12 different occasions usually results in documentation of higher quality than if the requirements work-flow, analysis workflow, and so on are all handed in at the end of the semester. Finally, it is much easier to grade 12 smaller pieces of a term project during the semester than one gargantuan project at a time when there are end-of-semester deadlines to meet. These remarks are even more pertinent if the instructor assigns the implementation of the term project as well.

CASE TOOLS

You will probably want your students to use a CASE environment for some of the exercises, as well as for the term project. Three environments are mentioned at the end of Section 11.7: Rational Rose, System Architect, and ArgoUML.

Rational Rose is the industry standard. However, many universities and colleges have found it hard to install Rose. Rational gives Rose to colleges free of charge on a year-to-year basis; however, my experiences over the years with the Rational Seed Program have not been ideal. Finally, the Rational Seed Program applies only to university and college computers—it does not extend to student or faculty computers.

System Architect is easy to use and easy to install. It is possible that, in the future, versions of this book may be sold with a System Architect CD attached, at a small additional cost; please contact your McGraw-Hill representative if you are interested in your students using System Architect.

ArgoUML is open-source (that is, free) software. Details on how to install ArgoUML and how to use it can be found at argouml.tigris.org. In addition, future versions of this book may be sold with an ArgoUML CD (at no additional cost).

LECTURE SCHEDULES

Returning to the lecture material, the entire book can be comfortably covered in one semes-ter, including time for questions and discussion.

viii

Lecture 1 Course objectives, introduction to project teamsLectures 2–3 Chapter 1Lectures 4–5 Chapter 2Lectures 6–7 Chapter 3Lecture 8 Review of Part 1; introduction to the CASE tool to be used

by the class for the term projectLectures 9–11 Chapter 4Lectures 12–13 Chapter 5Lectures 14–16 Chapter 6Lectures 17–18 Chapter 7Lectures 19–20 Chapter 8Lectures 21–22 Chapter 9Lectures 23–24 Chapter 10Lecture 25 Review of Part 2Lecture 26 Midterm examinationLectures 27–28 Chapter 11Lectures 29–30 Chapter 12Lectures 31–32 Chapter 13Lectures 33–34 Chapter 14Lectures 35–36 Chapter 15Lectures 37–38 Chapter 16Lectures 39–40 Chapter 17Lecture 41 Chapter 18Lecture 42 Chapter 19 Lectures 43–44 Chapter 20Lecture 45 Course review and wrap-up

When this book is used for a quarter-based course, the instructor will probably cover Parts 1 and 2 as above (Lectures 1 through 25), with the mid-semester examination scheduled earlier than Lecture 26. Then, he or she will select topics from Part 3 for the remainder of the course.

The material can be presented in a number of different ways. Personally, I recommend the use of PowerPoint slides for the many diagrams in this book. After all, UML is a graphical language, and the students need to see the various diagrams in order to appreciate what the instructor is saying. Detailed PowerPoint lecture notes are available and can downloaded from the Web site for this book, www.mhhe.com/schach/.

In fact, it does not really matter how An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process is taught—all that is really needed is enthusi-asm. I hope that you will have as much fun and satisfaction teaching from An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process as I have had in writing the book.

Stephen R. Schach

ix

x

Instructor’s Manual for Systems Analysis and Design by Schach—Chapter 1

CHAPTER 1

INTRODUCTION TO INFORMATION SYSTEMS

From the start of the course, the instructor is faced with a dilemma. On the one hand, from both research and practical experience we know that the object-oriented paradigm is superior to the traditional paradigm. On the other hand, many of the students in the class will work on traditional software when they graduate, if not sooner. My approach is simply to state from time to time, in a matter-of-fact way, that the object-oriented paradigm is superior to the traditional paradigm.

The material in this chapter is needed later in the book. I therefore suggest that you cover all the topics of Chapter 1.

REVIEW QUESTIONS FOR CHAPTER 1

1. Custom information systems; commercial off-the-shelf packages.

2 An ERP is much larger and more expensive than COTS. It is intended to satisfy all the information system needs of an organization, and needs to be customized for each installation.

3. Requirements; analysis; design; implementation; maintenance; retirement.

4. Requirements phase: Requirements document.Analysis phase: Specification document; project management plan.Design phase: Design document.Implementation phase: Computer program.Maintenance phase: Modified documentation from previous phases.Retirement phase: Why it was retired, when, and by whom.

5. Requirements phase: The client’s needs are determined.Analysis phase: The specification document and the project management plan are drawn up. The specifications describe what will be built.Design phase: The design is drawn up. The design describes how it will be built.Implementation phase: The information system is programmed.Maintenance phase: The information system is modified.

1–1


Retirement phase: The information system is decommissioned.

6. Planning needs to be done at the beginning of the project, and especially at the end of the analysis phase. Furthermore, management needs to monitor the plan all through the project.

7. Testing needs to be performed continually.

8. Documentation must be carried out in parallel with all other activities.

9. Systems analysis: The requirements and analysis phases.Analysis: The second development phase.

10. Two dollars, three dollars, or even more, depending on whom you believe.

11. Corrective maintenance: Fixing faults.Perfective maintenance: Extending the functionality of the information system.Adaptive maintenance: Changes to the information system required as a result of changes to the environment in which the information system operates.

12. Organizations whose primary activity is producing software.Organizations for which software is not a primary product.

PROBLEM SOLUTIONS

1.1: An instructor builds a database for student grades.The owner of a small business writes his or her own packages for inventory and ac-counts payable.

1.2 The developer fully understands the client’s requirements. Also, the specifications will be unambiguously understood. In fact, communication problems of all kinds are minimized.

1.3 The objectives and activities of the two phases are so different that it makes no sense at all. The requirements phase is a somewhat informal process of determining the client’s needs, whereas the activities of the analysis phase consist of drawing up a precise statement of exactly what the information system is to do, followed by the drawing up of a detailed plan for doing it.

1.4 No. Testing must never be a separate phase, but an intrinsic and essential co-activity of all phases.

1.5 The task of the systems analyst is to work with the client to find out what the client’s real needs are. Accordingly, Morgan Cuttler is responsible for the delivery of the 56,943 pairs of boots. With regard to prevention, there are three things that Morgan

1–2


should have done. First, he should have examined Jethro’s formula more carefully. Second, the project management plan should have included specific tests for the part of the information system that implemented Jethro’s formula. Third, Morgan should have included some sort of reasonableness check so that, if that part of the program wanted to order more than, say, 100 pairs of boots, manual intervention by Jethro was required.

1.6 Try to find a solution using COTS (packages). If this fails, determine which of the constraints (time, cost, functionality) can be relaxed, and provide a solution that fits the remaining constraints. If this fails, do not make promises that cannot be kept, but rather provide data such as hardware invoices and software development schedules showing the unreasonableness of the total request.

1.7 A wide variety of definitions are applicable, including those incorporating concepts like “organized,” “unified,” or “whole.”

1.8 If an information system performs useful work, but is for some reason no longer maintainable, then it is likely that the information system will be rewritten so that it can continue to perform useful work, rather than being retired. True retirement takes place only if the perceived need for the information system has completely disap-peared.

1.9 Maintenance becomes difficult, because the only way to understand the information system as a whole is to read the source code of the entire information system. Also, the sole documentation on an individual module is the source code of that module. In addition, lack of documentation means that the chance of a regression fault in-creases.

1–3


CHAPTER 2

HOW INFORMATION SYSTEMS ARE DEVELOPED

The aim of this chapter is to explain iteration and incrementation. There are two mini case studies, the Winburg mini case study and the Teal Tractors mini case study, both of which are included to show that iteration and incrementation are intrinsic aspects of information system development and maintenance.

Three life-cycle models are presented: the traditional waterfall life-cycle model, the Unified Process life-cycle model, and the evolution tree model. The latter two models are designed for modeling incrementation and incrementation. Problem 2.4 shows that the waterfall life-cycle model is inadequate in this respect.

The concepts of iteration and incrementation are so central to object-oriented information systems that it is absolutely essential for every student to understand both concepts before proceeding. If this means devoting an extra lecture to Chapter 2, then so be it—there is no point in starting Part 2 until the two concepts are thoroughly understood by the whole class.

I have taught various versions of Figure 2.4 for nearly 10 years now. My experience is that almost no-one understands it the first time I explain it, but almost everyone in the class catches on the second time.


1. An evolution tree is a diagram that displays all the versions of the requirements, specification, design, and implementation of an information system. The evolution tree explicitly reflects maintenance activities. The evolution tree thus shows how the information system evolves (that is, its evolution).

2. A life-cycle model is the series of steps through which the information progresses as it is developed and maintained.

3. The waterfall model shows the phases through which an information system passes, together with feedback loops that can be followed if the information system needs to be modified.

2–1


4. An artifact is a constituent component of an information system.

5. A baseline is a complete set of artifacts.

6. First, an information system is a model of the real world, and the real world is con-tinually changing. Second, information technology professionals, being human, make mistakes, and these mistakes need to be corrected.

7. As shown in Figure 2.4, the earlier the change is made, the less it costs.

8. The requirements change while the information system is being developed.

9. A regression fault is a change made to one part of the information that adversely af-fects an apparently unrelated part of the information system.

10. Miller's Law states that a human being can concentrate on only about seven chunks (units of information) at any one time.

11. Iteration means repetition (that is, doing the same thing again, in order to improve it); incrementation means addition or augmentation.

12. A workflow is a set of activities.

13. The architecture is the set of component modules and how they interrelate.

14. Robustness is the ability to handle extensions and changes without falling apart.

15. The iterative and incremental life-cycle model offers multiple opportunities to check correctness; the robustness of the architecture can be determined early in the life cycle; we can resolve risks early; we always have a working version of the infor-mation system.

16. Maintenance occurs whenever an information system is modified.

PROBLEM SOLUTIONS

2.1 Approximately $100. From Figure 2.4 of An Introduction to Object-Oriented Analy-sis and Design with UML and the Unified Process, the ratio of the cost of detecting and correcting a fault during the maintenance phase to the cost of detecting and cor-recting it during the analysis phase is approximately 184 to 1.

2–2


Figure 2.1. Waterfall model representation of the Winburg mini case study.

2.2 Approximately $500. From Figure 2.4 of An Introduction to Object-Oriented Analy-sis and Design with UML and the Unified Process, the ratio of cost of detecting and correcting a fault during the maintenance phase to the cost of detecting and correct-ing it during the implementation phase is approximately 37 to 1.

2.3 Point out that 60% to 70% of all detected faults are requirements, analysis, or design faults, and thus the request to find faults early is reasonable.

2.4 Figure 2.1 shows the waterfall model representation of the Winburg mini case study. (This figure is identical to Figure 2.3 of An Introduction to Object-Oriented Analysis and Design with UML and the Unified Process.) The problem is that the figure does not show the sequence of events, that is, which artifact follows which. It is therefore less effective than the evolution tree.

2–3

Development

Maintenance

Requirements

Analysis

Design

Implementation


Figure 2.2. Evolution tree for the Winburg mini case study with single precision numbers used from the beginning.

2.5 Episode 2 falls away, and Figure 2.2 shows the resulting evolution tree

2.6 Because of Miller’s Law we cannot develop an information system in a single step, and therefore we need to use stepwise refinement.

2.8 Incrementation.

2.9 A workflow is a set of activities. An artifact is a constituent component of an information system.A workflow creates or modifies one or more artifacts. A baseline is a set of artifacts.

2.10 The Unified Process life-cycle model is equivalent to a sequence of waterfall life-cycle models.

2.11 Traditional temporal maintenance is a subset of operational maintenance. That is, all changes to an information system constitute operational maintenance, but only those performed after installation constitute temporal maintenance.

2–4

Requirements3

Analysis3

Design3

Implementation3

Requirements1

Design1

Implementation1

Design4

Implementation4

Development

Maintenance

Episode 1 Episode 4Episode 3

Analysis1


CHAPTER 3

THE OBJECT-ORIENTED PARADIGM

This chapter contains a nontechnical introduction to the object-oriented paradigm. Instead of following the usual route, namely, defining a class to be an abstract data type that supports inheritance, I define a class as a set of objects that have the same set of attributes and the same set of operations. Thus, the student can understand objects and classes in an easy and straightforward way.

It might seem more appropriate for the material on information hiding to be covered in Chapter 20 with the other more technical material. There are two reasons why it needs to be taught in Chapter 3. First, responsibility-driven design needs to be taught before Chapter 8. Second, virtually every CASE tool displays the visibility prefixes of the attributes and meth-ods of classes, and so students need to know about visibility prefixes before starting Part 2.


1. This was the first time that information system development had been treated as a methodical discipline rather than a creative activity—any paradigm is surely better than no paradigm at all.

2. The traditional paradigm essentially ignored the data of a program and focused on the actions perform by that program.

3. A class is a set of objects that have the same set of attributes and the same set of operations. An object is an instance of a class.

4. Inheritance is an implementation of the generalization relationship.

5. Aggregation is a special case of association.

6. Information hiding is a way of enhancing maintainability by making implementation details invisible outside an object.

7. When a message is sent to an object, it is totally irrelevant how that request is carried out.

3–1


The module that sends the message is not even permitted to know how the attributes of the object are implemented. The total responsibility for carrying out all aspects of the message rests with the ob-ject receiving the message.

8. Three earlier methodologies for performing object-oriented analysis and design.

9. Both.

PROBLEM SOLUTIONS

3.1 See Figure 3.1.

3.2 See Figure 3.2.

Figure 3.1. UML model of people’s handedness.

3–2

People Class

Left-Handed Class Right-Handed ClassAmbidextrous Class


Figure 3.2. UML model of personal computers.

Figure 3.3. UML model of an insurance policies insuring policyholders.

Figure 3.4. UML model of policyholders paying premiums.

3–3

Computer Class

CPU Class Printer ClassKeyboard ClassMonitor Class

Apartment Class

Rental Unit Class Condominium Class

monthlyRental purchasePrice

insures

Policy ClassPolicyholder Class

Policyholder Classpays premium

Policy Class


Figure 3.5. UML model for apartments.

3.3 See Figure 3.3.

3.4 See Figure 3.4.

3.5 See Figure 3.5.

Figure 3.6. UML model for library books.

3–4

Library Book Class

Reserve Book Class Circulating Book Class

borrower

accessionNumber

Children’s Book Class General Book Class

recommendedAgeRange


Figure 3.7. UML model for bank statements.

3.6 See Figure 3.6

3.7 See Figure 3.7.

3–5

numberdateamount

Bank Statement Class

Opening Balance Class Deposit ClassCheck Class Closing Balance Class

dateamount


CHAPTER 4

THE REQUIREMENTS WORKFLOW. I

My experience when teaching the Osbert Oglesby case study is that the obvious incongruities (for example, a selling price of 2.15 times the purchase price) help to focus the discussion in class on the key issues. Students, in my experience, ask fewer questions about irrelevant details of a case study when they appreciate that the case study has been put together for the sole purpose of helping them to learn.

Problem 4.9 has been included as an easy introduction to the systems analysis and design projects (Problems 5.5 and 5.6).


1. A systems analyst works with the client and future users of the information system to determine what the client’s needs are.

2. First, the client may not fully appreciate what is going on in his or her own organiza-tion. Second, information systems are complex.

3. Requirements elicitation is the process of determining the client’s requirements; re-quirements analysis is the process of refining and extending those requirements.

4. A glossary can help to reduce misunderstandings caused by terminological misinter-pretation.

5. In a structured interview, all the questions are preplanned. In an unstructured inter-view, any question may be posed.

6. The subjects of the videotape may view this as an unwarranted invasion of their pri-vacy. Also, for every hour videotaped, at least one systems analyst has to spend at least one hour viewing the tape.

7. A model of an interaction between the information system itself and users of that information system (actors).

4–1


8. An actor is a member of the world outside the information system that interacts with the information system.

9. A use-case diagram is a set of use cases.

10. First, the customer may initiate the Buy a Painting and Sell a Painting use cases. Second, the customer plays a critical part in both use cases by providing data that are entered into the information system by Osbert.

11. A functional requirement specifies an action that the information system must be able to perform. A nonfunctional requirement specifies properties of the information sys-tem itself.

PROBLEM SOLUTIONS

4.1 No, an information system may be built to computerize only part of the operations of an organization.

4.2 The information system must run under Linux.

4.3 On average, queries of Type 4 must be answered within 3 seconds.

4.4 There can always be a mistake in any formula. Such a mistake could result in Osbert offering too high or too low a price when buying a painting. Both possibilities will have adverse business consequences. If he offers too much, his profit will be cut when he subsequently sells the painting (he may even make a loss on the painting); if he offers too little, the buyer will not sell the painting to Osbert. Before proceeding with the computerization project, the formula should be applied to a number of painting and the results shown to Osbert for checking.

4.5 Again, there can always be a mistake in any formula. One consequence of such a mistake is that Osbert will buy paintings for which there is no real demand.

4.6 See Figure 4.1.

4–2


Figure 4.1. Use case for selling a painting on contingency.

Brief description:

The Sell a Painting on Contingency use case enables Osbert Oglesby to sell a painting on contingency. Step-by-step description:

The painting is accepted for sale and hung in Osbert’s gallery.

1 If the painting is sold within 3 months, Osbert and the owner share the selling price equally.

2. If not, the painting is returned to its owner and no money changes hands.

Figure 4.2. Description of the Sell a Painting on Contingency use case.

4.7 See Figure 4.2.

4–3

Osbert OglesbyInformation System

Sell a Paintingon Contingency

Osbert Owner


Figure 4.3. Modified use-case diagram for the Osbert Oglesby case study.

1.4 Contingency sales report:The system displays a list of all contingency sales during the past year.The names of the owners (if any) are in alphabetical order. Each owner’s name appears on one line. The various works sold on behalf of that owner appear on successive lines, in order of date of sale. For each work, the output is in the following order: sale date, classification, artist’s last name, painting title, previously agreed selling price.

Figure 4.4. Addition to the description of the Produce a Report use case.

4.8 The modified use-case diagram is shown in Figure 4.3. The additions to the Produce a Report use case are shown in Figure 4.4.

4–4

Owner

SellerBuy a Painting

OsbertOglesbyInformation System

Sell a Painting

Osbert

Produce a Report

BuyerSell a Paintingon Contingency

Owner

SellerBuy a Painting

OsbertOglesbyInformation System

Sell a Painting

Osbert

Produce a Report

BuyerSell a Paintingon Contingency


Figure 4.5. The use case Balance Checkbook.

Brief description:

The Balance Checkbook use case enables the account holder to balance his or her checkbook.Step-by-step description:

1. Sort the checks in check-number order. For each check, find an entry in the bank statement that matches the check number. If no such entry is found, the statement is in error. Otherwise, mark that entry, and verify that the amount for that entry is the same as that on the check. If the amounts do not match, then the statement is in error.

2. Sort the deposit slips according to date of deposit. For each deposit slip, find an entry in the statement that matches the date of deposit and the amount of the deposit. Mark that entry. If no such entry is found, the statement is in error.

3. After all checks and deposits have been processed, verify that all items on the statement have been marked. If not, the statement is in error.

4. Add the amount of all deposits to the beginning balance, and from that sum subtract the total of all the checks. If the result of that subtraction is not equal to the ending balance then the statement is in error, otherwise, it is correct.

Figure 4.6. Description of the Balance Checkbook use case.

4.9 The following assumptions are made: There are no service charges, no ATM with-drawals. The only transactions that are allowed are checks and deposits. All checks bear a number. The account holder has a pile of canceled checks and a pile of deposit slips.

The only use case is shown in Figure 4.5, and its description in Figure 4.6.

4–5

Balance Checkbook

Check BookInformation System

AccountHolder


CHAPTER 5

THE REQUIREMENTS WORKFLOW. II

I created the MSG Foundation case study to show that it is possible for the number of use cases to decrease as well as increase. Students seem utterly flabbergasted when they see this, but it is an important lesson.

Some students find the computation of the weekly grant somewhat daunting, so I have in-cluded Review Questions 4 and 5 to provide an additional incentive for them to master this material. In the real world, most information systems include computations that are far more complex than the grant computation.

I included Just in Case You Wanted to Know Box 5.1 to save me the trouble of continually correcting the way some students insist on pronouncing the word “mortgage.”

Most of Chapter 5 is a review of Chapter 4. Nevertheless, I would urge you to teach Chapter 5 as thoroughly as Chapter 4. Students rarely grasp Chapter 4 as deeply as I would like, and I use Chapter 5 to ensure that they really understand the requirements workflow.

I view Systems Analysis and Design Projects 5.5 and 5.6 as essential. The only way that students can learn the workflows of the Unified Process is by performing them repeatedly.


1. An actor is a role (see Section 4.5.3 of An Introduction to Systems Analysis and De-sign with UML and the Unified Process). Applicants and borrowers are two different roles of the same couple.

2. First, Applicants initiate the Apply for an MSG Mortgage and Borrowers initiate some scenarios of Compute Weekly Repayment Amount use case by declaring their current weekly incomes. Second, in both use cases, these actors provide the data that are entered into the information system by the MSG Staff Member.

3. Figure 5.9 depicts the initial business model, whereas Figure 5.10 shows the initial requirements. Although applying for a mortgage certainly is part of MSG’s business

5–1


activities, the trustees have excluded from the initial pilot project all aspects that do not relate to computing the funds available each week for mortgages.

4. Each year, the borrowers have to pay the annual property tax and the annual home-owner’s insurance premium. Instead of asking them to pay each of those two amounts in one lump sum, money that they are unlikely to have, they pay 1/52nd of the sum of these two payments into an escrow account each week. Then, when the premiums become due, the money in the escrow account is used for the payments.

5. The purpose of the grant is to ensure that the borrowers do not have to pay more than 28 percent of their weekly income in mortgage payments. So, first the total mortgage payment is computed as the sum of the weekly principal and interest payment, to-gether with the weekly escrow payment.

Now, if this quantity is less than 28 percent of the borrowers’ weekly income, then the borrowers pay this amount in full (Step 1.4) and no grant is needed. However, if the total mortgage payment is more than 28 percent of their weekly income, then they pay only 28 percent, and the difference is made up in the form of a grant.

In this way, the mortgage payment is paid in full each week, but the borrowers never pay more than 28 percent of their income toward their mortgage.

6. A use case models an interaction between the information system itself and users of the information system (actors). In the lower diagram of Figure 5.26 of An Introduc-tion to Systems Analysis and Design with UML and the Unified Process, use case Estimate Payments and Grants for Week does not interact with an actor and therefore cannot be a use case in its own right. Instead, it is a portion of use case Estimate Funds Available for Week, as reflected in the top diagram of Figure 5.26.

5–2


Balance The amount of the loan still owing.Capital Synonym for principal.Closing costs Other costs involved in buying a house, such as legal costs and

various taxes.Deposit An initial installment toward the total cost of the house.Escrow account A savings account managed by the finance company into which the

weekly installments toward the annual insurance premium and annual real estate tax payment are deposited, and from which the annual insurance premium and the annual real estate tax payment are paid.

Interest A cost of borrowing money, computed as a fraction of the amount owing.

Mortgage A loan in which real estate is pledged as security for the loan.P & I Abbreviation for “principal and interest.”Points A cost of borrowing money, computed as a fraction of the total amount

borrowed.Principal The lump sum borrowed.Principal and interest

An installment payment consisting of the interest plus the fraction of the principal for that installment.

Figure 5.1. The initial glossary of the MSG Foundation information system.

PROBLEM SOLUTIONS

5.1 See Figure 5.1.

5–3


Brief description:

When a couple applies for a mortgage, the Apply for an MSG Mortgage use case enables an MSG staff member to determine whether the mortgage can be granted.Step-by-step description:

1. The MSG staff member checks:

1.1 Whether the couple has been legally married for at least 1 year but not more than 10 years.

1.2 Whether there is proof that both were employed full-time for at least 48 weeks of the preceding year.

1.3 Whether the price of the home that the couple wishes to purchase is below the published median price for homes in that area for the past 12 months.

1.4 Whether the installments on a fixed-rate 30-year 90 percent mortgage would exceed 28 percent of their combined gross income and/or if they do not have sufficient savings to pay 10 percent of the cost of the home plus $7,000.

1.5 Whether the foundation has sufficient funds this week to purchase the home.

2. If all these conditions are satisfied, the mortgage is granted.

Figure 5.2. Description of the Apply for an MSG Mortgage use case.

5.3 The description of the Apply for an MSG Mortgage use case is shown in Figure 5.2.

5.4 The restructuring itself would not change—there would simply be another use case.

5–4


Figure 5.3. The use-case diagram for the library circulation system.

5.5 The use-case diagram for the library appears in Figure 5.3. The descriptions of the use cases are shown in Figures 5.4 though 5.8.

5–5

Borrower

Check Out Book

Return Book

Library CirculationSystem

Query Catalog

Hold Book

Add or RemoveBook

Librarian


Brief description:

The Check Out Book use case enables a borrower to check out a book with the aid of a librarian.Step-by-step description:

The borrower hands the book and his or her card to the librarian.

1 The librarian enters C at the computer terminal, then scans the bar codes on the book and on the borrower’s card.

2. If the book had a hold on it for another borrower, the librarian does not allow the borrower to check that book out.

3. If the book had a hold on it for that borrower, the system clears the hold and then updates the relevant book data.

4. If there was no hold on the book, the system updates the relevant book data.

Unless there was a hold on the book for another borrower, the librarian stamps the book and hands it to the borrower.

The librarian returns the card to the borrower.

Figure 5.4. The Check Out Book use case.

Brief description:

The Return Book use case enables a borrower to return a book with the aid of a librarian.Step-by-step description:

The borrower hands the book and his or her card to the librarian.

1 The librarian enters R at the computer terminal, then scans the bar code on the book.

2. The system updates the relevant book data.

The librarian sets the book aside to be returned to the book stacks.

Figure 5.5. The Return Book use case.

5–6


Brief description:

The Add or Remove Book use case enables a librarian to add a book to or remove it from the library collection.Step-by-step description:

1 The librarian enters + at the computer terminal, then scans the bar code on the new book.

2. The system inserts the relevant book data.

The librarian sets the book aside to be placed in the book stacks.

Figure 5.6. The Add or Remove Book use case.

Brief description:

The Hold Book use case enables a librarian to place a hold on a book for a borrower.Step-by-step description:

The borrower hands the librarian a form bearing the number of the book, together with his or her card.

1 The librarian enters H at the computer terminal, then types in the book number and scans the bar code on the borrower’s card.

2. If there already is a hold on the book for another reader, the system displays a message to this effect.

3. If there is no hold on the book, the system updates the relevant book data.

The librarian returns the card to the borrower, and sets aside the form for recycling.

Figure 5.7. The Hold Book use case.

5–7


Brief description:

The Query Catalog use case enables a borrower to query the catalog.Step-by-step description:

1 To determine all the books in the library by a specific author, the librarian or borrower enters A= followed by the author’s name.

2. To determine all the books in the library with a specific title, the librarian or borrower enters T= followed by the title.

3. To determine all the books in the library in a specific subject area, the librarian or borrower enters S= followed by the subject area.

Figure 5.8. The Query Catalog use case.

The initial business model includes all the use cases of the use case diagram of Figure 5.3, together with their descriptions.

. The initial requirements also include all these use cases, together with their descrip-tions.

5.6 The use-case diagram for the ATM is shown in Figure 5.9, and the descriptions of the use cases are shown in Figures 5.10 through 5.13.

5–8


Figure 5.9. The use-case diagram for the ATM information system.

5–9

Determine Balance

ATMInformation System

Deposit Funds

Withdraw Funds

Transfer Funds

Customer


Brief description:

The Deposit Funds use case enables the customer to deposit funds at the ATM.Step-by-step description:

1. The customer inserts his or her card into the ATM and then enters his or her PIN.

2. The ATM verifies that the PIN is correct. If not, the transaction is terminated and the ATM returns the card.

3. The menu appears on the screen.

4. The customer chooses to deposit funds.

5. The customer selects an account.

6. The customer enters the amount to be deposited.

The ATM opens its deposit slot. The customer puts the envelope containing the deposit into the slot. The ATM takes the envelope and closes the slot.

7. The information system sends a message to update the customer’s account balance once the contents of the envelope have been checked.

8. The ATM prints a receipt showing the date, the amount of the deposit, the account number, and the balance before deposit.

9. The menu reappears on the screen.

10. The customer chooses to quit. The ATM returns the card.

Figure 5.10. Description of the Deposit Funds use case.

5–10


Brief description:

The Withdraw Funds use case enables the customer to withdraw funds from the ATM.Step-by-step description:

1. The customer inserts the card into the ATM and then enters his or her PIN.



4. The customer chooses to withdraw funds.


6. The customer enters the amount to be withdrawn (up to $200 in units of $20).

7. The ATM checks that the customer has adequate funds in his or her account. If not, the transaction is terminated and the ATM returns the card.

The ATM gives the money to the customer.

8. The information system sends a message to update the customer’s account balance to reflect the withdrawal.

9. The ATM prints a receipt showing the date, the amount of the withdrawal, the account number, and the balance after the withdrawal.



Figure 5.11. Description of the Withdraw Funds use case.

5–11


Brief description:

The Determine Balance use case enables the customer to determine an account balance at the ATM.Step-by-step description:




4. The customer chooses to determine his or her balance.


6. The ATM displays the account balance on the screen.



Figure 5.12. Description of the Determine Balance use case.

5–12


Brief description:

The Transfer Funds use case enables the customer to transfer funds between accounts at the ATM.Step-by-step description:




4. The customer chooses to transfer funds.

5. The customer selects the source account.

6. The customer selects the destination account.

7. The customer enters the amount to be transferred.

8. The ATM checks that the customer has adequate funds in his or her source account. If not, the transaction is terminated and the ATM returns the card.

9. The information system updates the balance in both the source and the destination account.

10. The ATM prints a receipt showing the date, the amount transferred, the account numbers, and the balances in both accounts after the transfer.



Figure 5.13. Description of the Transfer Funds use case.

The initial business model includes all the use cases of the use case diagram of Figure 5.9, together with their descriptions.

. The initial requirements also include all these use cases, together with their descrip-tions.

TERM PROJECT

5–13


5.7 The initial glossary appears in Figure 5.14.

Accounts payable Money ChocAn is obligated to pay to providers for services they have rendered

Chocolate A food prepared from ground roasted cacao beans that is truly delicious but can be addictive.

Chocoholics Anonymous (ChocAn)

An organization dedicated to helping people addicted to chocolate in all its glorious forms.

Electronic fund transfer (EFT)

An automated process by which funds are transferred from one bank account to another. In the case of ChocAn, funds are transferred on a weekly basis to the bank accounts of the individual providers.

Invalid number A number that identifies a member who is inactive or a number that is not in the information system.

Member number A 9-digit number that uniquely identifies each member of ChocAn.

Member status Active, Inactive, Suspended.Magnetic tape A data storage medium where the EFT data are kept.Member suspended The member number is valid but the member has not paid

his or her duesProvider An individual who provides services to paying members of

ChocAn, including dietitians, internists, and exercise specialists.

Provider directory A directory that holds the service codes, descriptions of the services, and the amount to be paid for each service.

Provider number A 9-digit number that uniquely identifies each ChocAn provider.

Provider status Active, Inactive.Provider type Internist, Dietitian, Exercise Specialist.Service code A 6-digit number that uniquely identifies a service provided

to a member. (For example, 598470 denotes a session with a dietitian.)

Validation The process of checking that the member’s number is correct and that the member has paid all dues currently owed.

Visit An occasion on which a consultation, exercise session, or other service is provided to a member.

5–14


Figure 5.14. Initial ChocAn glossary.

Figure 5.15. Use-case diagram for ChocAn.

The use case Maintain Member combines use cases Add Member and Update Member, and similarly for Maintain Provider. The use-case diagram is shown in Figure 5.15. Descriptions of the use cases appear in Figures 5.16 through 5.22.

5–15

Provider

ChocAnInformation

System

Member

MaintainMember

MaintainProvider

VerifyMember Status

Add Visit

Print MemberReport

Print ProviderReport

Print ManagerReport

Print EFTReport

«include»


Brief description:

The Maintain Member use case enables a provider to enter new member data or update existing member data given by the member.Step-by-step description:

1. The provider enters or updates data given by the member: NameAddressCityStateZIP codeDate of last paymentStatus (Active, Inactive, Suspended)

Figure 5.16. Description of the Maintain Member use case for ChocAn.

Brief description:

The Maintain Provider use case enables a provider to enter new provider data or update existing provider data.Step-by-step description:

1. The provider enters or updates provider information including:NameAddressCityStateZIP codeType (Internist, Dietitian, Exercise Specialist)Status (Active, Inactive)

Figure 5.17. Description of the Maintain Provider use case for ChocAn.

5–16


Brief description:

The Verify Member Status use case enables the provider to validate a member’s status by entering the member number into the system.Step-by-step description:

1 The provider enters the member number that is to be validated.

2. The ChocAn information system informs the provider regarding the member status.

Figure 5.18. Description of the Verify Member Status use case for ChocAn.

Brief description:

The Add Visit use case enables a provider to enter details of a member’s visit into the ChocAn information system.Step-by-step description:

1. The provider enters the member number.

2 The ChocAn information system checks whether the member number is valid. If so, the provider enters his or her provider number.

3. Then information is written by the ChocAn information system to a file, including:Current date and timeDate of visitProvider name, number, and typeMember name and numberService code, name, and description of visitAdditional comments

Figure 5.19. Description of the Add Visit use case for ChocAn.

5–17


Brief description:

The Print Member Report use case enables a member to receive a list of all the services provided to that member during the current week.Step-by-step description:

1. The ChocAn information system prints a report of all visits by each member during the current week, including:

Member name, number, address, city, state, ZIP code.For each service provided:

Date of serviceProvider nameService name

Figure 5.20. Description of the Print Member Report use case for ChocAn.

Brief description:

The Print Provider Report use case enables a provider to receive a list of all the services provided by that provider during the current week. Step-by-step description:

1. The ChocAn information system prints a report of services provided by each provider during the current week, including:

Provider name, number, address, city, state, ZIP code.For each service provided:

Date of serviceDate and time data received from computerMember name and numberService codeFee to be paid

Total number of consultations with membersTotal fee for the week

Figure 5.21. Description of the Print Provider Report use case for ChocAn.

5–18


Brief description:

The Print EFT Report enables the ChocAn information system to print a list of funds to be transferred to the providers’ bank accounts.Step-by-step description:

1. The ChocAn information system prints the EFT report including:Provider name and numberAmount to be transferred to provider’s account

Figure 5.22. Description of the Print EFT Report use case for ChocAn.

Brief description:

The Print Manager Report use case enables a ChocAn manager to print the Accounts Payable report summarizing the fees to be paid for the current week and the total number of visits to providers.Step-by-step description:

1. The ChocAn information system prints a report including:The name of every provider to be paid for the current weekThe number of consultations each provider hadHis or her total fee for the weekThe total number of providers who had visits that weekThe total number of consultations for the weekThe overall fee total

Figure 5.23. Description of the Print Manager Report use case for ChocAn.

The initial business model includes all the use cases of Figure 5.15, together with their descriptions.

The initial requirements include all the use cases of Figure 5.15, together with their descriptions.

5–19


CHAPTER 6

THE OBJECT-ORIENTED ANALYSIS WORKFLOW. I

It is important to stress that repeated iteration is an intrinsic quality of the object-oriented paradigm in general, and of object-oriented analysis in particular. The student has to know that he or she will have to iterate a number of times between use-case modeling, class modeling, and dynamic modeling before arriving at an acceptable solution.

I strongly urge you to assign Problems 6.19 through 24. The best way for a student to learn how to do the analysis workflow is by doing it from scratch.


1. A boundary class models the interaction between the information system and its ac-tors.A control class models complex computations and algorithms.An entity class models information that is long lived.

2. They have nothing to do with the interaction between the actor (Osbert) and the in-formation system. They are essentially comments.

3. In functional modeling we present scenarios of all the use cases. In class modeling we determine the entity classes and their attributes, determine the interrelationships and interactions between the entity classes, and present this infor-mation in the form of a class diagram. In dynamic modeling we determine the operations (actions) performed by or to each entity class or subclass, and present this information in the form of a statechart.

4. An exception scenario depicts a scenario that is not normal. An extended scenario is a normal scenario together with exceptions.

5. An event causes a transition between states.

6. To realize a use case means to accomplish or achieve it.

6–1


Osbert Oglesby wishes to sell a painting.

1. Osbert enters the description of the painting.

2. The information system displays the target selling price (2.15 times the purchase price).

Osbert makes an offer based on the target selling price. The offer is accepted by the seller.

3. Osbert enters sales information (date of sale, name and address of buyer, actual selling price).

Possible Alternatives:

A. The buyer turns down Osbert’s bid.

Figure 6.1. An extended scenario of the use case Sell a Painting.

7. An interaction diagram depicts the realization of a specific scenario of the use case. There are two types of interaction diagram, a collaboration diagram (which looks like a class diagram with numbered events) and a sequence diagram in which the classes are represented by lifelines, and the numbered events appear in sequence order.

PROBLEM SOLUTIONS

6.1 The purpose of noun extraction is to find the classes. The other parts of speech are irrelevant for that purpose.

6.2 See Figure 6.1.

6.3 See Figure 6.2.

6–2


1. Osbert requests a report of all paintings he purchased during the past year.

2. The system displays all paintings purchased during the past year. The output is in the order: classification, purchase date, artist’s last name, painting title, suggested maximum purchase price, and actual purchase price. Any painting purchased for more than the maximum purchase price computed by the algorithm is flagged (by placing an asterisk before the classification). This report is sorted by classification and by date of purchase within classification. The average ratio of the actual purchase price to the algorithm’s suggested maximum purchase price for all the paintings in the report is displayed at the end of the report.

Figure 6.2. A scenario of the use case Produce a Report.

1. Osbert requests a change to the fashionability coefficient for an artist.

2. Osbert specifies the name of the artist and the new fashionability coefficient.

3. The information system updates the fashionability coefficient for that artist.Possible alternatives:

A. Osbert specifies an artist whose name is not in the system.

B. Osbert misspells the name of the artist.

Figure 6.3. An extended scenario of the use case Modify a Fashionability Coefficient.

6.4 See Figure 6.3.

6.5 First, there is generally not enough information during the analysis workflow to do this correctly. Second, there is a good chance that the class diagram will have to be changed in the course of iteration and incrementation, and the less material that has to be reorganized, the better.

6.6 See Figure 6.4.

6–3


Brief description:

The Buy a Masterwork use case enables Osbert Oglesby to buy a masterwork. Step-by-step description:

1. Osbert inputs the details of the masterwork he is considering buying. These are:Description of paintingFirst name of artist (20 characters, followed by ? if there is uncertainty)Last name of artist (20 characters, followed by ? if there is uncertainty)Title of work (40 characters, followed by ? if there is uncertainty)Year of work (yyyy, followed by ? if there is uncertainty)Height (cm)Width (cm)Medium (oil, watercolor, other medium)Subject (portrait, still life, landscape, other subject)

2. The information system responds with the maximum purchase price Osbert should offer, computed as follows:

The information system computes the coefficient of similarity between each painting for which there is an auction record and the painting under consideration for purchase. Question marks in the first four painting attributes are to be ignored.

The information system scores 1 for a match on medium, otherwise 0.The information system scores 1 for a match on subject, otherwise 0.It adds these two numbers, multiplies by the area of the smaller of the two paintings, and divides by the area of the larger of the two.The resulting number is the coefficient of similarity.

The information system finds the auctioned painting with the largest nonzero coefficient of similarity. If there is no such painting, Osbert will not buy the painting under consideration.The information system computes the maximum purchase price by adding to the auction price of the most similar work 8.5%, compounded annually, for each year since that auction.Then, if the picture was painted in the 21st century, it multiplies that figure by 0.25, otherwise it multiplies it by (21 – c) / (22 – c), where c is the century in which the work was painted (12 < c < 21).

3. If Osbert buys the painting, he enters further details. These are:Date of purchase (mm/dd/yyyy)Name of seller (30 characters)Address of seller (40 characters)Actual purchase price (up to $99,999,999)

4. The information system then records the following:

6–4


Maximum purchase price determined by the algorithm (up to $99,999,999)Target selling price (2.15 times the purchase price)

Figure 6.4. Description of the use case Buy a Masterwork

Brief description:

The Buy Other Painting use case enables Osbert Oglesby to buy an other painting. Step-by-step description:

1. Osbert inputs the details of the other painting he is considering buying. These are:

Description of paintingFirst name of artist (20 characters, followed by ? if there is uncertainty)Last name of artist (20 characters, followed by ? if there is uncertainty)Title of work (40 characters, followed by ? if there is uncertainty)Year of work (yyyy, followed by ? if there is uncertainty)Height (cm)Width (cm)Medium (oil, watercolor, other medium)Subject (portrait, still life, landscape, other subject)


The information system computes the maximum purchase price from the formula F A, where F is a constant for that artist (fashionability coefficient) and A is the area of the canvas in square centimeters. If there is no fashionability coefficient for that artist, Osbert will not buy the painting under consideration.

3. If Osbert buys the painting, he enters further details. These are:Date of purchase (mm/dd/yyyy)Name of seller (30 characters)Address of seller (40 characters)Actual purchase price (up to $99,999,999)

4. The information system then records the following:Maximum purchase price determined by the algorithm (up to $99,999,999)Target selling price (2.15 times the purchase price)

Figure 6.5. Description of the use case Bay Other Painting.

6.7 See Figure 6.5.

6–5


Brief description:

The Produce a Purchases Report use case enables Osbert Oglesby to obtain information on paintings he has bought in the past year.Step-by-step description:

1. The system displays all paintings purchased during the past year. The output is in the order: classification, purchase date, artist’s last name, painting title, suggested maximum purchase price, and actual purchase price.Any painting purchased for more than the maximum purchase price computed by the algorithm is flagged (by placing an asterisk before the classification). This report is sorted by classification and by date of purchase within classification. The average ratio of the actual purchase price to the algorithm’s suggested maximum purchase price for all the paintings in the report is displayed at the end of the report.

Figure 6.6. Description of the use case Produce a Purchases Report.

Brief description:

The Produce a Sales Report use case enables Osbert Oglesby to obtain information on paintings he has sold in the past year.Step-by-step description:

1. The system displays all paintings sold during the past year.The output is in the following order: classification, sale date, artist’s last name, painting title, target selling price, and actual selling price. Any painting sold at a price of 5 percent or more below the target selling price is flagged (by placing an asterisk before the classification). This report is sorted by classification and by date of sale within classification.

2. The average ratio of the actual selling price to the target selling price for all of the paintings in the report is displayed at the end of the report.

Figure 6.7. Description of the use case Produce a Sales Report.

6.8 See Figure 6.6.

6.9 See Figure 6.7.

6–6


Brief description:

The Produce a Future Trends Report use case enables Osbert Oglesby to detect new trends in the art market.Step-by-step description:

1. The system displays all artists whose works have been sold at a price that has exceeded the target selling price in every instance during the past year. For an artist to appear in this report, at least two of his or her works must have been sold in that period. The names of the relevant artists (if any) are in alphabetical order. Each name appears on one line of the screen. The various works sold appear on successive lines, in order of date of sale. For each work, the output is in the following order: sale date, classification, painting title, target selling price, and actual selling price.

Figure 6.8. Description of the use case Produce a Future Trends Report.

6.10 See Figure 6.8.

6–7


1. Osbert inputs the details of the other painting he is considering buying. These are:

Description of paintingFirst name of artist (20 characters, followed by ? if there is uncertainty)Last name of artist (20 characters, followed by ? if there is uncertainty)Title of work (40 characters, followed by ? if there is uncertainty)Year of work (yyyy, followed by ? if there is uncertainty)Height (cm)Width (cm)Medium (oil, watercolor, other medium)Subject (portrait, still life, landscape, other subject)


The information system computes the maximum purchase price from the formula F A, where F is a constant for that artist (fashionability coefficient) and A is the area of the canvas in square centimeters.

Osbert makes an offer below this maximum price. The seller accepts the offer.

3. Osbert enters details regarding the sale. These are:Date of purchase (mm/dd/yyyy)Name of seller (30 characters)Address of seller (40 characters)Actual purchase price (up to $99,999,999)

4. The information system then records the following:Maximum purchase price determined by the algorithm (up to $99,999,999)Target selling price (2.15 times the purchase price)

Possible alternatives:

A. The seller turns down Osbert’s offer.

B. There is no fashionability coefficient for that artist, so Osbert will not buy the painting under consideration.

Figure 6.9. Extended scenario of the use case Buy Other Painting.


6–8


Figure 6.10. Collaboration diagram of the realization of scenario of Figure 6.9.


6–9

: User Interface Class

: Compute Other Painting

Price Class

: Fashionability Class

: OtherPainting Class 1: Give other

paintingdetails

9: Give sellerdetails

2: Transfer other paintingdetails

10: Transfer sellerdetails

3: Createnewobject

11: Request update

5: Transferartist’s name

7: Provide price

13: Send acknow-ledgment

4: Returnnew object

12: Send acknowledg-ment

6: Returnfashionabilitycoefficient

8: Display price

14: Displayacknow-ledgment

Osbert

Seller

Data that the seller providesfor Osbert to enter

[new]


Figure 6.11. Sequence diagram of the realization of scenario of Figure 6.9.

Osbert inputs the details of the other painting he is considering buying (1). The information system determines the fashionability coefficient of the artist (2–6). It then computes the maximum price that Osbert should offer using the formula provided (7, 8).Osbert now makes an offer. His offer is accepted, and he supplies details regarding the seller (9), which are then used to update the other painting data (10–14).

Figure 6.12. The flow of events of the interaction diagrams of Figures 6.10 and 6.11.



6–10

Seller: User

InterfaceClass

: Compute Other Painting

Price Class

: Fashionability Class

: Other Painting Class

1: Give other painting details

2: Transfer otherpainting details

3: Create new object

7: Provide price

9: Give seller details

10: Transfer seller details

11: Request update

5: Transfer artist ’s name

4: Return new object

6: Return fashionability coefficient

8: Display price

12: Send acknowledgment


14: Display acknowledgment

Osbert

Data that the seller provides for Osbert to enter


1. Osbert requests a future trends report

2. The system displays all artists whose works have been sold at a price that has exceeded the target selling price in every instance during the past year. The report includes all artists who have had at least two of his or her works sold in that period. The names of the relevant artists (if any) are in alphabetical order. Each name appears on one line of the screen. The various works sold appear on successive lines, in order of date of sale. For each work, the output is in the following order: sale date, classification, painting title, target selling price, and actual selling price.

Possible Alternatives:

A. No artists qualify for the report.

Figure 6.13. Extended scenario of the use case Produce a Future Trends Report.

Figure 6.14. Collaboration diagram of the realization of scenario of Figure 6.13.



6–11

: User Interface Class

: Compute Future Trends

Class

1: Request futuretrends report

2: Transferreport request

5: Formatreport

: GalleryPainting

Class

3: Browsegallerypaintings

4: Returnrelevantartist details

8: Displaycompletionmessage

6: Send completionmessageOsbert :Future Trends

Report Class

7: Send completionmessage


Figure 6.15. Sequence diagram of the realization of scenario of Figure 6.13.

Osbert requests a future trends report (1). The information system scans all the paintings bought during the last year (2–3), compiles (4) and prints (5) the report, then informs Osbert that the report has been printed (6–8).

Figure 6.16. Flow of events of interaction diagrams of Figures 6.14 and 6.15.



6–12

: UserInterface

ClassOsbert

: GalleryPaintings

Class

: Compute Future Trends

Class

: Future TrendsReport Class

1: Request futuretrendsreport

2: Transferreport request

5: Format report

3: Browsegallerypaintings

4: Returnrelevantartist details

8: Displaycompletionmessage

6: Send completionmessage 7: Send

completionmessage


1. Sort the checks in check-number order. For each check, there is an entry marked in the bank statement that matches the check number, and the amount for that entry is the same as that on the check.

2. Sort the deposit slips according to date of deposit. For each deposit slip, there is an entry marked in the statement that matches the date of deposit and the amount of the deposit.

3. All items on the statement have been marked.

4. Add the amount of all deposits to the beginning balance, and from that sum subtract the total of all the checks. The result is equal to the ending balance.

A. For at least one check, there is an entry in the bank statement that does not match the check number.

B. For at least one check, there is an entry in the bank statement that matches the check number, but the amount for that entry is not the same as that on the check.

C. For at least one deposit slip, there is an entry in the statement that does not match the date of the deposit.

D. For at least one deposit slip, there is an entry in the statement that does not match the amount of the deposit.

E. After all checks and deposits have been processed, one or more items on the statement have not been marked.

F. The result of adding the amount of all deposits to the beginning balance, and from that sum subtracting the total of all the checks, is not equal to the ending balance.

Figure 6.17. Extended scenario for the information system to determine whether a bank statement is correct.

6.19 An extended scenario for the use case of Problem 4.9 appears in Figures 6.17.

6.20 Candidate entity classes are determined using noun extraction.

Description of information system in a single paragraph: An information system for determining whether a bank statement is correct is to be constructed. The data to be used are: the balance at the beginning of the month; the number, date, and amount of each check; the date and amount of each deposit; and the balance at the end of the month.

Identify the nouns: An information system for determining whether a bank statement is correct is to be constructed. The data to be used are: the balance at the beginning

6–13


of the month; the number, date, and amount of each check; the date and amount of each deposit; and the balance at the end of the month.

Figure 6.18. Initial class diagram for the information system to determine whether a bank statement is correct.

Figure 6.19. Initial statechart of the information system to determine whether a bank statement is correct.

With regard to the nouns in the previous paragraph, system, balance, data, and month are abstract nouns and are therefore unlikely to be classes. Also, number, date, and amount relate to the checks, and date and amount relate to the deposits. This leaves Balance Class, Check Class, and Deposit Slip Class as candidate entity classes.

The initial class diagram is shown in Figure 6.18.

6.21 The initial statechart is shown in Figure 6.19.

6.22 The boundary class is Screen Class.The control class is Determine Correctness Class.

6–14

Starting

Sort the checks in check-number order.Sort the deposit slips in date of deposit order.

Finishing

Report whether the statement balances.

Determining Whether Statement is Correct

Determine whether the statement balances.

Check ClassBalance Class Deposit Slip Class


Figure 6.20. Class diagram showing the classes that realize the use case of the information system to determine whether a bank statement is correct.

6.23 The class diagram for the use case is shown in Figure 6.20

6–15

ScreenClass

DetermineCorrectness

Class

CheckClassAccount

Holder

BalanceClass

DepositSlip

Class


Figure 6.21. A collaboration diagram of the realization of the normal scenario of Figure 6.17 of the use case of the information system to determine whether a bank statement is correct.

6–16

: ScreenClass

: DetermineCorrectness

Class

: CheckClassAccount

Holder

: DepositSlip

Class

: BalanceClass

1: Requestdeterminationof correctness

2: Transferrequest

3: Request beginning,ending balances

10: Displayresult ofcomputation

9: Sendresult ofcomputation

4: Returnbalances

5: Request sortedchecks

6: Returnsorted checks

7: Request sorteddeposit skips

8: Return sorteddeposit slips


The account holder requests the information system to determine whether a bank statement is correct (1–2). The system obtains the beginning and ending balances (3–4), sorted checks (5–6), and sorted deposit slips (7–8). The information system then determines whether the bank statement is correct, and informs the account holder in this regard (9–10).

Figure 6.22. The flow of events of the realization of the scenario of Figure 6.17 of the Check of the information system to determine whether a bank statement is correct.

6.24 The collaboration diagram is shown in Figure 6.21, the flow of events in Figure 6.22, and the equivalent sequence diagram in Figure 6.23.

Figure 6.23. A sequence diagram equivalent to the collaboration diagram of Figure 6.21. The flow of events is therefore as shown in Figure 6.22.

6–17

: ScreenClass

: DetermineCorrectness

Class

: Check Class

: Balance Class

AccountHolder

: DepositSlip

Class 1: Requestdeterminationof correctness

2: Transfer request

3: Request beginning,ending balances

10: Display result of computation

9: Send resultof computation

4: Return balances

5: Request sorted checks

6: Return sorted checks

7: Request sorted deposit skips

8: Return sorted deposit slips


CHAPTER 7

THE OBJECT-ORIENTED ANALYSIS WORKFLOW. II

As with Chapters 4 and 5, most of Chapter 7 is a review of Chapter 6. Nevertheless, as with Chapter 5, I strongly suggest that you teach Chapter 7 as thoroughly as Chapter 6. Many students have difficulty in fully understanding the concepts of object-oriented analysis, and especially the role of iteration in determining the class diagram. Students generally welcome the fact that Chapter 7 affords them an opportunity to cover the material of Chapter 6 a sec-ond time, but applied to a different case study.


1. A change in the annual property tax changes the weekly payment (Step 3.1 of Figure 7.4 of An Introduction to Object-Oriented Analysis and Design with UML and the Unified Process). A grant is paid if the weekly payment exceeds 28 percent of the combined weekly income.

2. The two subclasses will share attributes and/or operations and thereby reduce the total number of attributes and/or operations. This will make both development and maintenance easier.

3. First, there are attributes and properties that appertain to the information system as whole, rather than to a specific class. Second, an object is needed that will initiate the execution of the information system.

4. The interaction diagrams form part of the “specification document.” The client is not going to approve the specification document unless he or she understands exactly what the proposed information system will do, and an interaction diagram without its associated written description is inadequate for this purpose.

5. A use case models all possible sets of interactions between actors (entities external to the information system) and the information system itself.A scenario is one specific instance of the associated use case.

7–1


An MSG Foundation staff member wants to update the expected annual return on an investment.

1. The staff member enters the new value of the expected annual return on the investment.

2. The information system changes the date on which the expected annual return was updated to that day’s date.

Possible alternatives:

A. The staff member enters the investment number incorrectly.

B. The staff member enters a negative number for the new value of the expected annual return on the investment.

Figure 7.1. An extended scenario of managing an investment.

A description of a use case provides a written account of the details of the use caseA realization is the set of classes that realize (achieve or accomplish) the use case.An interaction diagram depicts the objects and the messages sent between them in the realization of that one specific scenario.

6. Determine every role in which an individual can interact with the information system.

7. An actor is a role in which an individual can interact with the information system. The term worker is used to denote a particular role played by an individual.

8. For each role (actor), there will be one or more use cases. Thus, having found the actors, the use cases are straightforward.

9. A working program that exhibits the key behavior of the target information system.

10. The client can understand how the target information system will behave just as well from the interaction diagrams and their written flow of events as from a rapid proto-type—a scenario is a particular execution sequence of the proposed information sys-tem, as is each execution of the rapid prototype.

PROBLEM SOLUTIONS

7.1 See Figure 7.1.

7–2


An MSG Foundation staff member wants to update the estimated annual operating expenses.

1. The staff member enters the new value of the estimated annual operating expenses.

2. The information system changes the date on which the estimated annual operating expenses were updated to that day’s date.

Possible alternative:

A. The staff member enters zero or a negative number for the new value of the estimated annual operating expenses.

Figure 7.2. An extended scenario of updating the estimated annual operating expenses.

An MSG staff member inputs the new annual property tax for a mortgage (1, 2). The information system updates the mortgage record (3), and informs the staff member that this has been done (4–6).

Figure 7.3. The flow of events of the interaction diagrams for updating the annual property tax.

An MSG staff member inputs the new weekly income of the couple (1, 2). The information system updates the mortgage record (3), and informs the MSG staff member that this has been done (4–6).

Figure 7.4. The flow of events of the interaction diagrams for updating weekly income.

An MSG staff member inputs the new annual operating expenses (1). The information system updates the record (2), and informs the MSG staff member that this has been done (3, 4).

Figure 7.5. The flow of events of the interaction diagrams for updating the annual operating expenses.

7.2 See Figure 7.2.

7.3 See Figure 7.3

7.4 See Figure 7.4.

7.5 Delete the Possible alternative box from Figure 7.2.

7.6 See Figure 7.5.

7–3


An MSG staff member requests that the list of mortgages be printed (1, 2). The information system does so (3), and informs the staff member that this has been done (3, 4).

Figure 7.6. The flow of events of the interaction diagrams for printing the list of mortgages.

A borrower hands a book and his or her card to a librarian.


2. The system determines that there is no hold on the book for another borrower.


The librarian stamps the book and hands it to the borrower, together with the card.

Figure 7.7. First scenario of the Check Out Book use case.



2. The system determines that the book has a hold on it for another borrower.

The librarian does not allow the borrower to check that book out. The librarian returns the card to the borrower.

Figure 7.8. Second scenario of the Check Out Book use case.

7.7 See Figure 7.6.

7.8 In this solution, subheadings are underlined.

Scenarios for the use cases of Problem 5.5 appear in Figures 7.7 through 7.17.

7–4



1. The librarian enters C at the computer terminal, then scans the bar codes on the book and on the borrower’s card.

2. The system determines that the book has a hold on it for that borrower.

3. The system clears the hold and then updates the relevant book data.

The librarian stamps the book and hands it to the borrower, together with the card.

Figure 7.9. Third scenario of the Check Out Book use case.


1 The librarian enters R at the computer terminal, then scans the bar code on the book.


The librarian sets the book aside to be returned to the book stacks.

Figure 7.10. Scenario for the Return Book use case.

1 A librarian enters + at the computer terminal, then scans the bar code on a new book.

2. The system inserts the relevant book data.

The librarian sets the book aside to be placed in the book stacks.

Figure 7.11. Scenario for the Add or Remove Book use case.

1 A librarian enters – at the computer terminal, then scans the bar code on a book.

2. The system removes the relevant book data.

The librarian sets the book aside to be pulped.

Figure 7.12. Scenario for the Add or Remove Book use case.

7–5


A borrower hands a librarian a form bearing the number of a book, together with his or her card.


There already is a hold on the book for another reader.

2. The system displays a message to this effect.

The librarian informs the borrower, returns the card, and sets aside the form for recycling.

Figure 7.13. First scenario for the Hold Book use case.

A borrower hands a librarian a form bearing the number of a book, together with his or her card.


There is no hold on the book for another reader.


The librarian returns the card to the borrower, and sets aside the form for recycling.

Figure 7.14. Second scenario for the Hold Book use case.

1 A borrower enters A= followed by an author’s name.

Figure 7.15. First scenario for the Query Catalog use case.

1 A librarian enters T= followed by the title of a book.

Figure 7.16. Second scenario for the Query Catalog use case.

1 A borrower enters S= followed by a subject area.

Figure 7.17. Third scenario for the Query Catalog use case.

7–6


Figure 7.18. Initial class diagram for the library information system.

Candidate entity classes are determined using noun extraction.

Description of information system in a single paragraph: An automated library circu-lation system is to be constructed. Each book in the library, as well as each bor-rower, can be identified by a bar code. A book can be checked out, provided it is not being held for another borrower; at most one borrower can place a hold on a book checked out by another borrower. When a book is returned, it is checked in by a librarian. Borrowers and librarians are permitted to query a catalog of library holdings.

Identify the nouns: An automated library circulation system is to be constructed. Each book in the library, as well as each borrower, can be identified by a bar code. A book can be checked out provided it is not being held for another borrower; at most one borrower can place a hold on a book checked out by another borrower. When a book is returned, it is checked in by a librarian. Borrowers and librarians are permitted to query a catalog of library holdings.With regard to the nouns in the previous paragraph, borrower and librarian are actors, and bar code is an attribute of a book and of a borrower. Accordingly, these nouns cannot correspond to classes. In addition, library, hold, holding, and system are ab-stract nouns. Finally, catalog is information that relates to books. This leaves Book Class as the sole candidate class.

(In a real library, there would probably be a Borrower Class so that a librarian can determine which books have been checked out by a specific borrower. For sim-plicity, this problem has been set up so that no class of that kind is needed.)


7–7

Book ClassLibrary Application Class


Figure 7.19. Initial statechart of the library information system.

The initial statechart is shown in Figure 7.19.

The initial boundary classes are Librarian Screen Class (used by the librarians) and Query Screen Class (used by both the librarians and the borrowers).The initial control class is Library Control Class.

7–8

addbook

selected

Library Information System Loop

returnbook

selected

holdbook

selected

removebook

selected

check outbook selected

Checking Out Book

Enter book intosystem.

Adding Book

Returning BookClear borrowernumber.

Remove book fromsystem.

Removing Book

Return value ofrelevant field.

Querying Catalog

Holding BookSet hold flag.

Update borrowernumber.Clear hold flag, ifapplicable.

queryselected


Figure 7.20. Class diagram showing the classes that realize the Check Out Book and Return Book use cases of the library information system.

Figure 7.21. A collaboration diagram of the realization of the scenarios of Figures 7.7 and 7.9 of the Check Out Book use case of the library information system.

Use case Check Out Book :

The class diagram for the Check Out Book use case is shown in Figure 7.20.

First consider the scenario of Figure 7.7. The collaboration diagram is shown in Fig-ure 7.21, the flow of events in Figure 7.22, and the equivalent sequence diagram in Figure 7.23.

7–9

: LibrarianScreen Class

: LibraryControl

Class

: BookClassLibrarian

Borrower

The borrower provides data entered by the librarian

1: Give bookdetails

2: Transfer bookdetails

3: Determineholdstatus

5: Updatebookdetails

8: Display holdstatus

7: Sendhold status

4: Returnholdstatus

6: Sendacknow-ledgment

LibrarianScreen Class

LibraryControl

Class

BookClass

Librarian

Borrower



The librarian inputs the details of the book the borrower wishes to check out (1). The information system determines the hold status of the relevant book data (2–4), updates the book data (5), and informs the librarian that the book is not on hold (6–8).

Figure 7.22. The flow of events of the realization of the scenarios of Figures 7.7 and 7.9 of the Check Out Book use case of the library information system.


7–10

Borrower: Librarian

ScreenClass

: LibraryControlClass

: Book ClassLibrarian

Data provided by the borrowerentered by the librarian

1: Give book details

2: Transfer book details

3: Determine hold status

8: Display hold status

7: Send hold status

4: Return hold status

5: Update book details



Figure 7.24. A collaboration diagram of the realization of the scenario of Figure 7.8 of the Check Out Book use case of the library information system.

The librarian inputs the details of the book the borrower wishes to check out (1). The information system determines the hold status of the relevant book (2–4), and informs the librarian that the book is on hold for another reader (5–6).

Figure 7.25. The flow of events of the realization of the scenario of Figure 7.8 of the Check Out Book use case of the library information system.

We continue analyzing use case Check Out Book by considering the scenario of Fig-ure 7.8. The collaboration diagram is shown in Figure 7.24, the flow of events in Figure 7.25, and the equivalent sequence diagram in Figure 7.26.

7–11


: LibraryControl

Class


Borrower


1: Give bookdetails



6: Displayholdstatus

5: Return holdstatus

4: Returnholdstatus



7–12

Borrower: Librarian

ScreenClass











Figure 7.27. A collaboration diagram of the realization of the scenario of Figure 7.10 of the Return Book use case of the library information system.

The librarian inputs the details of the book the borrower wishes to return (1). The information system updates the book data (2–3), and informs the librarian that this has been done (4–6).

Figure 7.28. The flow of events of the realization of the scenario of Figure 7.10 of the Return Book use case of the library information system.

Use case Return Book :

The class diagram is again Figure 7.20. Consider the scenario of Figure 7.10. The collaboration diagram is shown in Figure 7.27, the flow of events in Figure 7.28, and the equivalent sequence diagram in Figure 7.29.

7–13


: LibraryControl

Class


Borrower


1: Give bookdetails


3: Update book data






Figure 7.30. Class diagram showing the classes that realize the Add Book and Remove Book use case of the library information system.

Use case Add or Remove Book :

The class diagram is shown in Figure 7.30. Consider the scenarios of Figure 7.11 and Figure 7.12. The collaboration diagram is shown in Figure 7.31, the flow of events in Figure 7.32, and the equivalent sequence diagram in Figure 7.33

.

7–14


LibraryControl

Class

BookClass

Librarian

Borrower: Librarian

ScreenClass






3: Update book data

6: Displayacknowledgment




Figure 7.31. A collaboration diagram of the realization of the scenarios of Figures 7.11 and 7.12 of the Add or Remove Book use cases of the library information system.

The librarian inputs the details of the book he or she wishes to add or remove (1). The information system updates the book data (2–3), and informs the librarian that this has been done (4–6).

Figure 7.32. The flow of events of the realization of the scenarios of Figures 7.11 and 7.12 of the Add or Remove Book use case of the library information system, respectively.

Figure 7.33. A sequence diagram equivalent to the collaboration diagram of Figure 7.31. The flow of events is therefore again shown in Figure 7.32.

7–15


: LibraryControl

Class


1: Give bookdetails


3: Update book data




: LibrarianScreenClass





3: Update book data

6: Display acknowledgment




Figure 7.34. Class diagram showing the classes that realize the Hold Book use case of the library information system.

Figure 7.35. A collaboration diagram of the realization of the scenario of Figure 7.13 of the Hold Book use case of the library information system.

Use case Hold Book :

The class diagram is shown in Figure 7.34.

First consider the scenario of Figure 7.13. The collaboration diagram is shown in Figure 7.35, the flow of events in Figure 7.36, and the corresponding sequence dia-gram in Figure 7.37.

7–16


LibraryControl

Class

BookClass

Librarian

Borrower



: LibraryControl

Class


Borrower


1: Give bookdetails





4: Returnholdstatus


The librarian inputs the details of the book on which the borrower wishes a hold to be placed (1). The information system determines the hold status of the relevant book data (2–3), and informs the librarian that the book is on hold for another reader (4–6).

Figure 7.36. The flow of events of the realization of the scenario of Figure 7.13 of the Hold Book use case of the library information system.

Figure 7.37. A sequence diagram equivalent to the collaboration diagram of Figure 7.35. The flow of events therefore is shown in Figure 7.36.

7–17

Borrower: Librarian

ScreenClass











Figure 7.38. A collaboration diagram of the realization of the scenario of Figure 7.14 of the Hold Book use case of the library information system.

The librarian inputs the details of the book on which the borrower wishes a hold to be placed (1). The information system determines the hold status of the relevant book data (2–3), and informs the librarian that the book is now on hold for that reader (4–6).

Figure 7.39. The flow of events of the realization of the scenario of Figure 7.14 of the Check Out Book use case of the library information system.

Now consider the scenario of Figure 7.14. The collaboration diagram is shown in Figure 7.38, the flow of events in Figure 7.39, and the corresponding sequence dia-gram in Figure 7.40

7–18


: LibraryControl

Class


Borrower


1: Give bookdetails





4: Returnholdstatus



7–19

Borrower: Librarian

ScreenClass











Figure 7.41. Class diagram showing the classes that realize the Query Catalog use case of the li-brary information system.

Figure 7.42. A collaboration diagram of the realization of the scenarios of Figure 7.15 and 7.17 of the Query Catalog use case of the library information system.

The borrower inputs the details of his or her query (1). The information system determines the answer to the query (2), and sends the answer to the borrower (3–4).

Figure 7.43. The flow of events of the realization of the scenario of Figures 7.15 and 7.17 of the Query Catalog use case of the library information system.

Use case Query Catalog :


First consider the scenario of Figure 7.15. The collaboration diagram is shown in Figure 7.42, the flow of events in Figure 7.43, and the corresponding sequence dia-gram in Figure 7.44.

7–20

: QueryScreen Class

: BookClass

Librarian

Borrower

1: Give querydetails

2: Transfer querydetails

3: Send query answer

4: Displayquery answer


BookClass

Librarian

Borrower



Figure 7.45. A collaboration diagram of the realization of the scenario of Figure 7.16 of the Query Catalog use case of the library information system.

Now consider the scenario of Figure 7.16. The collaboration diagram is shown in Figure 7.45, the flow of events in Figure 7.46, and the corresponding sequence diagram in Figure 7.47.

7–21

: QueryScreen Class

: BookClass

Librarian

Borrower 1: Give

querydetails

2: Transfer querydetails


4: Displayquery answer

Borrower: QueryScreenClass


1: Give query details

2: Transfer query details


4: Display query answer


The librarian inputs the details of his or her query (1). The information system determines the answer to the query (2), and sends the answer to the librarian (3–4).

Figure 7.46. The flow of events of the realization of the scenario of Figure 7.16 of the Query Catalog use case of the library information system.


Finally, consider the scenario of Figure 7.17. The collaboration diagram is identical to Figure 7.42, the flow of events to Figure 7.43, and the corresponding sequence diagram to Figure 7.44.

7–22

Borrower: Librarian

ScreenClass


1: Give query details

2: Transfer query details


4: Display query answer


Figure 7.48. Second iteration of the class diagram of the library information system.

The second iteration of the class diagram is shown in Figure 7.48. It combines the class diagrams of Figures 7.18, 7.20, 7.30, 7.34, and 7.41.

7.9 In this solution, headings are underlined.

Scenarios for the use cases of Figure 5.9 appear in Figures 7.49 through 7.53.

7–23


LibraryControl

Class

BookClass

Librarian

Borrower QueryScreen Class

LibraryApplication

Class


1. The customer inserts his or her card into the ATM and then enters his or her PIN.

2. The ATM verifies that the PIN is correct.


4. The customer chooses to deposit funds.


6. The customer enters the amount to be deposited.

The ATM opens its deposit slot. The customer puts the envelope containing the deposit into the slot. The ATM takes the envelope and closes the slot.

7. The information system sends a message to update the customer’s account balance once the contents of the envelope have been checked.

8. The ATM prints a receipt showing the date, the amount of the deposit, the account number, and the balance before deposit.



Figure 7.49. Scenario of the Deposit Funds use case of the ATM information system.







7. The ATM determines that the customer does not have adequate funds in his or her account. Transaction is terminated and the ATM returns the card.

Figure 7.50. First scenario of the Withdraw Funds use case of the ATM information system.

7–24








7. The ATM determines that the customer has adequate funds in his or her account.

The ATM gives the money to the customer.

8. The information system sends a message to update the customer’s account balance to reflect the withdrawal.

9. The ATM prints a receipt showing the date, the amount of the withdrawal, the account number, and the balance after the withdrawal.



Figure 7.51. Second scenario of the Withdraw Funds use case of the ATM information system.

7–25





4. The customer chooses to determine his or her balance.


6. The ATM displays the account balance on the screen.



Figure 7.52. Scenario of the Determine Balance use case of the ATM information system.

7–26





4. The customer chooses to transfer funds.

5. The customer selects the source account.

6. The customer selects the destination account.

7. The customer enters the amount to be transferred.

8. The ATM determines that the customer has adequate funds in his or her source account.

9. The information system updates the balance in both the source account and the destination account.

10. The ATM prints a receipt showing the date, the amount transferred, the account numbers, and the balances in both accounts after the transfer.

11. The menu reappears on screen.


Figure 7.53. Description of the Transfer Funds use case of the ATM information system.


Description of information system in a single paragraph: An information system is to be constructed for an ATM. After a customer’s card has been successfully verified, the customer may deposit and withdraw money from an account, inquire about the balance of an account, and transfer funds between two separate accounts.

Identify the nouns: An information system is to be constructed for an ATM. After a cus-tomer’s card has been successfully verified, the customer may deposit and withdraw money from an account, inquire about the balance of an account, and transfer funds between two separate accounts.

With regard to the nouns in the previous paragraph, ATM, card, and customer do not change while the system is operating; in object-oriented terminology, they do not have an internal state. Also, funds and money are abstract nouns. Finally, balance is a property of account. Thus, the sole candidate entity class is Account Class.

7–27



Figure 7.54. The initial class diagram for the ATM information system.


The boundary class is ATM Screen Class.

The control class is ATM Control Class.

7–28

Account ClassATM Application Class


Figure 7.55. The initial statechart of the ATM information system.

7–29

ATM Information System Loop

determinebalanceselected

transferselected

withdrawalselected

depositselected

Inserting Card Ejecting Cardincorrect PIN

quitselected

correctPIN

Determining Balance

Display balance.

Insert card.Enter PIN.

Eject card.

DepositingFunds

Update balance.Print receipt.

Transfering Funds

Valid Withdrawal

Dispense money. Update balance. Print receipt.

Displaymessage.

Invalid Withdrawal

WithdrawingFunds

Determine ifamount is amultiple of $20and funds areavailable.

Determine if fundsare available.

ValidTransfer

yesno

Displaymessage.

Invalid Transfer

Update balance of both accounts.Print receipt

no yes


Figure 7.56. Class diagram showing the classes that realize all four of the use cases of the ATM information system.

Figure 7.57. A collaboration diagram of the realization of the scenario of Figure 7.49 of the Deposit Funds use case of the ATM information system.

7–30

ATMScreen Class

ATMControl

Class

AccountClass

Customer

: ATMScreen Class

: ATMControl

Class

: AccountClassCustomer

1: Insert card, give PIN 6: Choose to deposit,

specify amount,account

12: Choose to quit



8: Update balanceafter deposit hasbeen checked


5: Present menu 11: Print receipt 13: Return card

2: Transfer PIN 7: Transfer

amount,account

3: Verify PIN


The customer inserts his or her card and inputs PIN details. These are verified by the ATM (1–5). The customer chooses to deposit funds, specifies the amount to be deposited and the account (6–7). The account balance will be updated after the deposit has been checked (8–10). A receipt is printed (11). The customer chooses to quit, and the card is returned (12–13).

Figure 7.58. The flow of events of the realization of the scenario of Figure 7.49 of the Deposit Funds use case of the ATM information system

Use case Deposit Funds :

The class diagram for the Deposit Funds use case is shown in Figure 7.56.

Consider the scenario of Figure 7.49. The collaboration diagram is shown in Figure 7.57, the flow of events in Figure 7.58, and the equivalent sequence diagram in Figure 7.59.


7–31

: ATM Screen Class : Account ClassCustomer


8: Update balance after deposit has been checked


3: Verify PIN

: ATM Control Class

1: Insert card, give PIN

2: Transfer PIN


5: Present menu

7: Transfer amount, account

11: Print receipt

12: Choose to quit

13: Return card

6: Choose to deposit,specify amount, account


Figure 7.60. A collaboration diagram of the realization of the scenario of Figure 7.50 of the Withdraw Funds use case of the ATM information system.

Use case Withdraw Funds :

The class diagram is again Figure 7.56. Consider the scenario of Figure 7.50. The collaboration diagram is shown in Figure 7.60, the flow of events in Figure 7.61, and the equivalent sequence diagram in Figure 7.62.

7–32

: ATMScreen Class

: ATMControl

Class


1: Insert card, give PIN 6: Choose to withdaw,



10: Send message

9: Return account balance

5: Present menu 11: Return card


amount,account

3: Verify PIN

8: Determineaccount balance


The customer inserts his or her card and inputs PIN details. These are verified by the ATM (1–5). The customer chooses to withdraw funds, and specifies the amount to be withdrawn and the account (6–7). The information system determines that there are insufficient funds in the account (8), and the card is returned (9–11).

Figure 7.61. The flow of events of the realization of the scenario of Figure 7.50 of the Withdraw Funds use case of the ATM information system.


7–33


10: Send message

3: Verify PIN

: ATM Control Class


2: Transfer PIN


5: Present menu

7: Transfer account, amount

11: Return card

6: Choose to withdraw,specify amount, account


8: Determine account balance


Figure 7.63. A collaboration diagram of the realization of the scenario of Figure 7.51 of the Withdraw Funds use case of the ATM information system.

The customer inserts his or her card and inputs PIN details. These are verified by the ATM (1–5). The customer chooses to withdraw funds, specifies the amount and the account (6–7). The information system determines that there are sufficient funds in the account (8–10), the money is given to the customer, a receipt is printed (11–13), and the card is returned (14–15).

Figure 7.64. The flow of events of the realization of the scenario of Figure 7.51 of the Withdraw Funds use case of the ATM information system.

Now consider the scenario of Figure 7.51. The collaboration diagram is shown in Figure 7.63, the flow of events in Figure 7.64, and the equivalent sequence diagram in Figure 7.65.

7–34

: ATMScreen Class

: ATMControl

Class

: AccountClass

Customer

1: Insert card, give PIN 6: Choose to withdraw,


14: Choose to quit



8: Detemine accountbalance

10: Update accountbalance

9: Return accountbalance




amount,account

3: Verify PIN


Figure 7.65. A sequence diagram equivalent to the collaboration diagram of Figure 7.63. The flow of events is therefore again shown in Figure 7.62.

7–35



8: Determine account balance


3: Verify PIN

: ATM Control Class


2: Transfer PIN


5: Present menu

7: Transfer amount, account

13: Print receipt

14: Choose to quit

15: Return card

6: Choose to withdraw,specify amount, account

10: Update account balance



Figure 7.66. A collaboration diagram of the realization of the scenario of Figure 7.52 of the Determine Balance use case of the ATM information system.

The customer inserts his or her card and inputs PIN details. These are verified by the ATM (1–5). The customer chooses to determine the balance in a specific account (6–7). The information system determines the balance (8–10), ATM displays the balance (11), and the card is returned (12–13).

Figure 7.67. The flow of events of the realization of the scenario of Figure 7.52 of the Determine Bal-ance use case of the ATM information system.

Use case Determine Balance :

As before, the class diagram is shown in Figure 7.56.

Consider the scenario of Figure 7.52. The collaboration diagram is shown in Figure 7.66, the flow of events in Figure 7.67, and the corresponding sequence diagram in Figure 7.68.

7–36

: ATMScreenClass

: ATMControlClass


1: Insert card, give PIN 6: Choose account,

balance 12: Choose to quit


10: Return balance

8: Determine balance

9: Return balance 5: Present menu 11: Display balance 13: Return card


request

3: Verify PIN


Figure 7.68. A sequence diagram equivalent to the collaboration diagram of Figure 7.66. The flow of events therefore is shown in Figure 7.67.

7–37


10: Return balance

9: Return balance

3: Verify PIN

: ATM Control Class


2: Transfer PIN


5: Present menu

7: Transfer request

11: Display balance

12: Choose to quit

13: Return card

6: Choose account, balance

8: Determine balance


Figure 7.69. A collaboration diagram of the realization of the scenario of Figure 7.53 of the Transfer Funds use case of the ATM information system.

The customer inserts his or her card and inputs PIN details. These are verified by the ATM (1–5). The customer chooses to transfer funds, and specifies the amount to be transferred, the source account and the destination account (6–7). The information system determines that there are sufficient funds in the account (8–10), the money is given to the customer, a receipt is printed (11–13), and the card is returned (14–15).

Figure 7.70. The flow of events of the realization of the scenario of Figure 7.53 of the Transfer Funds use case of the ATM information system.

Use case Transfer Funds :

The class diagram is once again shown in Figure 7.56.

Consider the scenario of Figure 7.53. The collaboration diagram is shown in Figure 7.69, the flow of events in Figure 7.70, and the corresponding sequence diagram in Figure 7.71.

7–38

: ATMScreen Class

: ATMControl

Class

: AccountClass

Customer

1: Insert card, give PIN 6: Choose to transfer,

specify amount,accounts

14: Choose to quit



8: Detemine sourceaccount balance

10: Update accountbalances

9: Return sourceaccount balance




amount,accounts

3: Verify PIN



Figure 7.72. Second iteration of the class diagram of the ATM information system.

The second iteration of the class diagram is shown in Figure 7.72. It combines the class diagrams of Figures 7.54 and 7.56.

7–39

ATM Screen Class ATM Control Class Account ClassCustomer

ATM Application Class



8: Determine source balance

9: Return source balance

3: Verify PIN

: ATM Control Class


2: Transfer PIN


5: Present menu

7: Transfer amount, accounts

13: Print receipt

14: Choose to quit

15: Return card

6: Choose to transfer,specify amount, accounts

10: Update account balances



TERM PROJECT

7.10 In this solution, subheadings are underlined.

Scenarios for the use cases of Figure 5.15 appear in Figures 7.73 through 7.82.

A provider wishes to add a new member.

1. The provider enters new member information:Member nameMember addressMember cityMember stateMember ZIP codeDate last paidMember status (Active, Inactive, Suspended)

2. The system displays a message that the member has been successfully added.

Figure 7.73. First scenario of the Maintain Member use case of the ChocAn information system.

A provider wishes to modify current member information.

1. The provider locates the current member record by searching by member name or member number.

2. The provider edits the member information:Member nameMember addressMember cityMember stateMember ZIP codeDate last paidMember status (Active, Inactive, Suspended)

3. The system displays a message that the member information has been successfully modified.

Figure 7.74. Second scenario of the Maintain Member use case of the ChocAn information system.

7–40


A provider wishes to add a new provider.

1. The provider enters new provider information:Provider nameProvider addressProvider cityProvider stateProvider ZIP codeDate last paidProvider type (Dietitian, Internist, Exercise Specialist) Provider status (Active, Inactive, Suspended)

2. The system displays a message that the provider has been successfully added.

Figure 7.75. First scenario of the Maintain Provider use case of the ChocAn information system.

A provider wishes to modify current provider information.

1. The provider locates the current provider record by searching by provider name or provider number.

2. The provider edits the provider information:Member nameMember addressMember cityMember stateMember ZIP codeDate last paidMember status (Active, Inactive, Suspended)

3. The system displays a message that the provider information has been successfully modified.

Figure 7.76. Second scenario of the Maintain Provider use case of the ChocAn information system.

1. A provider enters a member number to verify member status

2. The system determines whether the member is active, inactive, suspended, or not found.

Figure 7.77. Scenario of the Verify Member Status use case of the ChocAn information system.

7–41


A member visits a provider.

1. The provider enters the member number to verify member status.

2. The system determines that the member is active.

3. The provider enters his or her provider number.

4. The system determines that the provider is active.

5. The provider enters the date of the visit.

6. The name and number of all services available from that provider are displayed on the screen by the system.

7. The provider enters the service number for that visit.

8. The system displays the corresponding service.

9. The provider verifies that the service selected is correct.

10. The provider enters optional comments.

11. The system stores the visit information:Current date and timeDate of visitMember name and numberService codeFee charged for service

12. The system displays a message that the visit has been successfully added.

Figure 7.78. Scenario for the Add Visit use case of the ChocAn information system.

7–42


A ChocAn manager wishes to print a member report.

1 The ChocAn information system prints a report of all visits by each member during the current week, including:

Member name, number, address, city, state, ZIP code.For each service provided:

Date of serviceProvider name

Service name

Figure 7.79. Scenario for the Print Member Report use case of the ChocAn information system.

A ChocAn manager wishes to print a provider report.

1 The ChocAn information system prints a report of services provided by each provider during the current week, including:

Provider name, number, address, city, state, ZIP code.For each service provided:

Date of serviceDate and time data received from computerMember name and numberService codeFee to be paid

Total number of consultations with membersTotal fee for the week

Figure 7.80. Scenario for the Print Provider Report use case of the ChocAn information system.

A ChocAn manager wishes the EFT report to be printed.

1 The ChocAn information system prints the EFT report including:Provider name and numberAmount to be transferred to provider’s account

Figure 7.81. Scenario for the Print EFT Report use case of the ChocAn information system.

7–43


A ChocAn manager wishes to print a manager report.

1 The ChocAn information system prints a report of services provided by each provider during the current week, including:

The name of every provider to be paid for the current weekThe number of consultations each provider hadHis or her total fee for the weekThe total number of providers who had visits that weekThe total number of consultations for the weekThe overall fee total

Figure 7.82. Scenario for the Print Manager Report use case of the ChocAn information system.


Description of information system in a single paragraph: For a monthly fee, mem-bers of ChocAn are entitled to unlimited visits to providers. The services of the pro-viders include those of internists, dietitians, and exercise experts. Reports are printed each week regarding members, providers, and the overall fees payable to providers.

Identify the nouns: For a monthly fee, members of ChocAn are entitled to unlimited visits to providers. The services of the providers include those of internists, dieti-tians, and exercise experts. Reports are printed each week regarding members, pro-viders, and the overall fees payable to providers.

With regard to the nouns in the previous paragraph, internist, dietitian, and exercise expert could be treated two ways. First, they could be considered subclasses of Pro-vider Class. Second, they could be considered attributes of Provider Class. For simplicity, we adopt the second choice, noting that it is easier to add subclasses than to remove them. Also, fee, ChocAn, report, and week are abstract nouns. This leaves Member Information Class, Visit Information Class, Provider Information Class, and Service Information Class as the candidate entity classes.

Now comparing scenarios 7.73 and 7.74 with scenarios 7.75 and 7.76, it is clear that we need to declare a class Person Information Class as a superclass of Member Information Class and Provider Information Class. [A hint in this regard is given to the student in Appendix A—“Both providers and members have name, number, address, city, state, and ZIP code attributes”].


7–44


Figure 7.83. The initial class diagram for the ChocAn information system.

The initial boundary classes are:ChocAn Interface ClassGet Input ClassMember Report ClassProvider Report ClassEFT Report ClassManager Report Class

The initial control classes are:Maintain Member ClassMaintain Provider ClassRequest Service ClassAdd Visit ClassCreate Reports Class


7–45

ServiceInformation Class

VisitInformation Class

PersonInformation Class

MemberInformation Class

ProviderInformation Class

ChocAnApplication Class


Figure 7.84. The initial statechart of the ChocAn information system.

7–46

ChocAn Information System Loop

add visitselected

member statusselected

maintain providerselected

maintain memberselected

quitselected

Add visitinformation formember

MaintainingMember

Mdify or add memberinformation

AddingVisit

VerifyingMember Status

Modify or addprovider information

Verify status ofmember

MaintainingProvider

Print member,provider (EFT), ormanager report

PrintingReports

print reportsselected


Figure 7.85. Class diagram showing the classes that realize the Maintain Member and Verify Member Status use cases of the ChocAn information system.

Figure 7.86. A collaboration diagram of the realization of the scenario of Figure 7.73 of the Main tain Member use case of the ChocAn information system.

Use case Maintain Member :


Consider the scenario of Figure 7.73, the first scenario of the Maintain Member use case. The collaboration diagram is shown in Figure 7.86, the flow of events in Figure 7.87, and the corresponding sequence diagram in Figure 7.88.

7–47

Member

The member providesdata for the providerto enter

Provider ChocAnInterface

Class

MaintainMember

Class

MemberInfo

Class

GetInputClass

Member


Provider : ChocAnInterface

Class

: MaintainMember

Class

: MemberInfo

Class

: GetInputClass

1: Select Add Member option

2: Transferselection

5: Add newmember


3: Supply new member data

4: Return new member data


8: Display acknow-ledgment


The provider enters data provided by the new member (1–3). The ChocAn information system is updated accordingly (4–5). An acknowledgment is displayed (6–8).

Figure 7.87. The flow of events of the realization of the scenario of Figure 7.86 of the Maintain Mem-ber use case of the ChocAn information system.


7–48

Provider : ChocAn InterfaceClass

: Maintain MemberClass

: Member InfoClass

: Get InputClassMember

Data providedby the memberfor the providerto enter

1: Select Add Member option

2: Transfer selection

5: Add new member


3: Supply new member data

4: Return newmember data

7: Send acknowledgment 8: Display

acknowledgment



The provider enters modified data provided by the member (1–3). The ChocAn information system is updated accordingly (4–5). An acknowledgment is displayed (6–8).

Figure 7.90. The flow of events of the realization of the scenario of Figure 7.86 of the Maintain Mem-ber use case of the ChocAn information system.

Now consider the scenario of Figure 7.74, the second scenario of the Maintain Member use case. The collaboration diagram is shown in Figure 7.89, the flow of events in Figure 7.90, and the corresponding sequence diagram in Figure 7.91.

7–49

Member



Class

: MaintainMember

Class

: MemberInfo

Class

: GetInputClass

1: Select ModifyMember option


5: Modifymember data


3: Supply modified member data

4: Return modified member data





7–50



: Member InfoClass




7: Send acknowledgment 8: Display acknow-

ledgment

1: Select ModifyMember option


5: Modify member data

3: Supply modified member data

4: Return modified member data


Figure 7.92. Class diagram showing the classes that realize the Maintain Provider use case of the ChocAn information system.

Figure 7.93. A collaboration diagram of the realization of the scenario of Figure 7.75 of the Main tain Provider use case of the ChocAn information system.

Use case Maintain Provider :


Consider the scenario of Figure 7.75, the first scenario of the Maintain Provider use case. The collaboration diagram is shown in Figure 7.93, the flow of events in Figure 7.94, and the corresponding sequence diagram in Figure 7.95.

7–51


Class

MaintainProvider

Class

ProviderInfo

Class

GetInputClass


Class

: MaintainProvider

Class

: ProviderInfo

Class

: GetInputClass


1: Select Add Provider option


5: Add newprovider

3: Supply new provider data

4: Return new provider data




The new provider enters data (1–3). The ChocAn information system is updated accordingly (4–5). An acknowledgment is displayed (6–8).

Figure 7.94. The flow of events of the realization of the scenario of Figure 7.75 of the Maintain Pro-vider use case of the ChocAn information system.


7–52


: Maintain ProviderClass

: Provider InfoClass

: Get InputClass

1: Select Add Provider option


5: Add new provider


3: Supply new provider data

4: Return new provider data


ledgment



The provider enters modified data (1–3). The ChocAn information system is updated accordingly (4–5). An acknowledgment is displayed (6–8).

Figure 7.97. The flow of events of the realization of the scenario of Figure 7.76 of the Maintain Pro-vider use case of the ChocAn information system.

Now consider the scenario of Figure 7.76, the second scenario of the Maintain Pro-vider use case. The collaboration diagram is shown in Figure 7.96, the flow of events in Figure 7.97, and the corresponding sequence diagram in Figure 7.98.

7–53


Class

: MaintainProvider

Class

: ProviderInfo

Class

: GetInputClass


1: Select ModifyProvider option


5: Modifyprovider data

3: Supply modified provider data

4: Return modified provider data





7–54




: Get InputClass



ledgment

1: Select ModifyProvider option


5: Modify provider data

3: Supply modified provider data

4: Return modified provider data


Figure 7.99. A collaboration diagram of the realization of the scenario of Figure 7.75 of the Verify Member Status use case of the ChocAn information system.

The provider enters the member number, supplied by the member (1–4). The ChocAn information system returns the member status (5–7), which is then displayed (8).

Figure 7.100. The flow of events of the realization of the scenario of Figure 7.77 of the Verify Mem-ber Status use case of the ChocAn information system.

Use case Verify Member Status :


Consider the scenario of Figure 7.77 of the Verify Member Status use case. The col-laboration diagram is shown in Figure 7.99, the flow of events in Figure 7.100, and the corresponding sequence diagram in Figure 7.101.

7–55

Member



Class

: MaintainMember

Class

: MemberInfo

Class

: GetInputClass

1: Select Verify Member Statusoption


5: Requestmember status

6: Return memberstatus

3: Request member number

4: Return membernumber

7: Return memberstatus

8: Display memberstatus



7–56



: Member InfoClass


Data provided by the member for the provider to enter


7: Return member status

8: Display memberstatus

1: Select Verify MemberStatus option

5: Request member status

6: Return member status

3: Request membernumber



Figure 7.102. Class diagram showing the classes that realize the Add Visit use case of the ChocAn information system.

Use case Add Visit :


7–57


Class

Add VisitClass

VisitInfo

Class

GetInputClass

MaintainProvider

Class

ProviderInfo

Class

ServiceInfo

Class

MemberInfo

Class

: MaintainMember

Class

Member


RequestServiceClass


Figure 7.103. A collaboration diagram of the realization of the scenario of Figure 7.78 of the Add Visit use case of the ChocAn information system.

The provider enters the member provided by the member (1–4). The ChocAn information system determines the member's status and other member information (5–8). Now the provider number is used to obtain provider information (9–12). Next, the service code is entered (13–14) and the service name returned, displayed for the provider's approval (15-16), and used to return service information (17–18). The provider provides comments and the date of visit (19–20). Visit information is then recorded and displayed (21–24).

Figure 7.104. The flow of events of the realization of the scenario of Figure 7.78 of the Add Visit use case of the ChocAn information system.

Consider the scenario of Figure 7.78, a scenario of the Add Visit use case. The col-laboration diagram is shown in Figure 7.103, the flow of events in Figure 7.104, and the corresponding sequence diagram in Figure 7.105.

7–58


Class

: Add Visit

Class

: VisitInfo

Class

: GetInputClass

: MaintainProvider

Class

: ProviderInfo

Class

: ServiceInfo

Class

: MemberInfo

Class

1: Select AddVisit option


21: Record visitinformation

22: Transfer visitinformation


19: Request comments and date of visit


20: Return comments anddate of visit

: MaintainMember

Class

5: Transfer membernumber

6: Requestmemberinformation

7: Returnmemberinformation

Member


8: Transfermemberinformation

10: Requestproviderinformation

11: Returnproviderinformation

9: Transferprovidernumber

12: Transferproviderinformation

: RequestServiceClass

14: Requestsevice code

16: Approveservice name

15: Return service name

17: Return serviceinformation

13: Requestservicedata

18: Transfer serviceinformation


24: Display visitinformation


Figure 7.105. A sequence diagram equivalent to the collaboration diagram of Figure 7.103. The flow of events is therefore as shown in Figure 7.104 (Part 1 of 2).

7–59

19: Request comment and date of visit

20: Return commentsand date of visit

21: Record visit information


Provider : Add VisitClass




8: Transfer member information

1: Select Add Visit option


5: Transfer member number



: ChocAn InterfaceClass

: Member InfoClass

6: Request member information

7: Return member information

9: Transfer provider number

13: Request service data

23: Display visitinformation


Figure 7.105. A sequence diagram equivalent to the collaboration diagram of Figure 7.103. The flow of events is therefore as shown in Figure 7.104 (Part 2 of 2).

7–60

22: Transfer visit information

14: Request servicecode

15: Return servicename

16: Approve servicename

17: Return serviceinformation

18: Transfer service information

: Visit InfoClass

: Service InfoClass

: Request ServiceClass


12: Transfer providerinformation


10: Request providerinformation

11: Return providerinformation


Figure 7.106. Class diagram showing the classes that realize the Print Member Report use case of the ChocAn information system.

Figure 7.107. A collaboration diagram of the realization of the scenario of Figure 7.73 of the Print Member Report use case of the ChocAn information system.

Use case Print Member Report:


Consider the scenario of Figure 7.79 of the Print Member Report use case. The col-laboration diagram is shown in Figure 7.107, the flow of events in Figure 7.108, and the corresponding sequence diagram in Figure 7.109.

7–61

ChocAnInterface

Class

CreateReportClass

MemberReportClass

MemberInfo

Class


Class

: CreateReportClass

: MemberReportClass

1: Select Print Reports option 2: Select Print

Member Report 5: Print member

report



4: Return memberinformation



: MemberInfo

Class


The provider requests that a report be printed (1) and that it be the member report (2). Information regarding the member is obtained (3–4), the report printed (5), and an acknowledgment is displayed (6–8).

Figure 7.108. The flow of events of the realization of the scenario of Figure 7.107 of the Print Mem-ber Report use case of the ChocAn information system.


7–62





1: Select PrintReports option

2: Select PrintMember Report

5: Print member report


4: Return memberinformation

: CreateReport Class

: Member InfoClass

: Member ReportClass


Figure 7.110. Class diagram showing the classes that realize the Print Provider Report use case of the ChocAn information system.

Use case Print Provider Report :


Consider the scenario of Figure 7.80 of the Print Provider Report use case. The collaboration diagram is shown in Figure 7.111, the flow of events in Figure 7.112, and the corresponding sequence diagram in Figure 7.113.

7–63


Class

: CreateReportClass

: ProviderReportClass

: ProviderInformation

Class

: ServiceInformation

Class


Figure 7.111. A collaboration diagram of the realization of the scenario of Figure 7.80 of the Print Provider Report use case of the ChocAn information system.

The provider requests that a report be printed (1) and that it be the provider report (2). Information regarding each provider (3–4) and the services provided by that provider (5–6) is obtained and incorporated in the provider report. The provider report is printed (7), and an acknowledgment is displayed (8–10).

Figure 7.112. The flow of events of the realizations of the scenario of Figure 7.111 of the Print Provider Report use case of the ChocAn information system.

7–64


Class

: CreateReportClass

: ProviderReportClass

1: Select Print Reports option

2: Select ProviderReport

7: Print providerreport







Class


Class

5: Requestserviceinformation

6: Returnserviceinformation



Use case Print EFT Report:


Consider the scenario of Figure 7.81 of the Print EFT Report. The collaboration diagram is shown in Figure 7.115, the flow of events in Figure 7.116, and the corresponding sequence diagram in Figure 7.117.

7–65


Provider : Create ReportClass



: Service InfoClass

5: Request service information

6: Return service information

: Provider ReportClass


ProviderReport

7: Print provider report


9: Send acknow-ledgment10: Display

acknow-ledgment

8;: Send acknowledgment


Figure 7.114. Class diagram showing the classes that realize the Print EFT Report use case of the ChocAn information system.

7–66


Class

: CreateReportClass

: EFTReportClass


Class


Class


Figure 7.115. A collaboration diagram of the realization of the scenario of Figure 7.81 of the Print EFT Report use cases of the ChocAn information system.

The provider requests that a report be printed (1) and that it be the EFT report (2). Information regarding each provider (3–4) and the services provided by that provider (5–6) is obtained and incorporated in the EFT report. The EFT report is printed (7), and an acknowledgment is displayed (8–10).

Figure 7.116. The flow of events of the realizations of the scenario of Figure 7.115 of the Print EFT Report use cases of the ChocAn information system.

7–67


Class

: CreateReportClass

: EFTReportClass


2: Select EFT Report

7: Print EFTreport







Class


Class





7–68





: Service InfoClass



: EFT ReportClass


Providerreport

7: Print provider report



acknow-ledgment



Figure 7.118. Class diagram showing the classes that realize the Print Manager Report use case of the ChocAn information system.

Use case Print Manager Report:


Consider the scenario of Figure 7.82 of the Print Manager Report use case. The col-laboration diagram is shown in Figure 7.119, the flow of events in Figure 7.120, and the corresponding sequence diagram in Figure 7.121.

7–69


Class

: CreateReportClass

: ManagerReportClass


Class


Class


Figure 7.119. A collaboration diagram of the realization of the scenario of Figure 7.82 of the Print Manager Report use case of the ChocAn information system.

The provider requests that a report be printed (1) and that it be the print manager report (2). Information regarding each provider (3–4) and the services provided by that provider (5–6) are obtained and incorporated in the print manager report. The report is printed, and an acknowledgment is displayed (8–10).

Figure 7.120. The flow of events of the realization of the scenario of Figure 7.119 of the Print Man-ager Report use case of the ChocAn information system.

7–70


Class

: CreateReportClass

: ManagerReportClass


2: Select PrintManager Report

7: Print managerreport







Class


Class





7–71





: Service InfoClass



: Manager ReportClass


ManagerReport

7: Print manager report



acknow-ledgment



Figure 7.122. Second iteration of the class diagram of the ChocAn information system.

The second iteration of the class diagram is shown in Figure 7.122. It combines the class diagrams of Figures 7.83, 7.85, 7.92, 7.102, 7.106, 7.110, 7.114, and 7.118.

.

7–72

AddVisitClass

ProviderReportClass

ManagerReportClass

EFTReportClass

ProviderInformation

Class

MemberInformation

Class

ChocAnApplication

Class

PersonInformation

Class

MemberReportClass

RequestServiceClass

ServiceInformation

Class

MaintainMember

Class

GetInputClass

ChocAnInterface

Class

VisitInformation

Class

CreateReportClass

MaintainProvider

Class


CHAPTER 8

THE OBJECT-ORIENTED DESIGN WORKFLOW

There is a possible problem in teaching this chapter. It is necessary to point out to the class that some of the design workflow requires knowledge of programming, and therefore is be-yond the scope of this book. However, some students assume that this means that they can skip the entire chapter! It is important to clarify this point.


1. Much of the design workflow requires knowledge of programming, but programming is not a prerequisite for this book.

2. Responsibility-driven design; inheritance.

3. If a class is responsible for a particular operation, that operation must be assigned to that class.

4. If an operation is applicable both to an instance of a superclass and to instances of subclasses of that superclass, then it makes sense to allocate that operation to the superclass.

5. Large-scale information systems (typically, 500,000 lines of code or more).

6. The analysis workflow is partitioned into packages; the implementation workflow into subsystems.

7. It is generally easier to handle a number of smaller systems than one large system.

8. If the project is falling behind schedule, we may choose to relax some of the require-ments, increase the budget, or move the delivery deadline.

9. Redesign it forthwith.

8–1


10. When utilized by a team, the interaction between the members of the team while act-ing out the actions of the classes can highlight missing or incorrect attributes and op-erations in classes.

PROBLEM SOLUTIONS

8.1 Mortgage Class, because dateMortgageIssued is an attribute of Mortgage Class, a class that has no subclasses. Also, it makes little sense to request any other class to carry out this operation.

8.2 Asset Class, so that it can be inherited by both subclasses of Asset Class.

8.3 MSG Foundation Class, because estimatedAnnualOperatingExpenses is an attrib-ute of that class, a class that has no subclasses. Also, it makes little sense to request any other class to carry out this operation.

8.4 None of them. This is a computational operation and should therefore appear in a control class. All the classes in the class diagram of Figure 8.3 are entity classes.

8.5 Painting Class, so that it can be used by Painting Class and all its subclasses.

8.6 Auctioned Painting Class, because getAuctionDate is an attribute of that class, a class that has no subclasses. Also, it makes little sense to request any other class to carry out this operation.

8.7 Gallery Class; attribute dateOfSale appertains to paintings in Gallery Class and its subclasses.

8.8 Gallery Class; attribute sellingPrice appertains to paintings in Gallery Class and its subclasses.

8–2


CLASS Investment Class

RESPONSIBILITY COLLABORATIONCompute expected grants and payments for week

Estimate Funds for Week Class

Initialize, update, and delete investments Manage an Asset ClassGenerate list of investments User Interface ClassPrint list of investments Investments Report Class

Figure 8.1. CRC card for class Investment Class of the MSG Foundation case study.

CLASS Other Painting Class

RESPONSIBILITY COLLABORATIONDetermine maximum price that Osbert should offer for an other painting

Compute Other Painting Class Other Painting Class

Update fashionability coefficient User Interface Class

Figure 8.2. CRC card for class Fashionability Class of the Osbert Oglesby case study.

CLASS Library Control Class

RESPONSIBILITY COLLABORATIONUpdate book data, determine hold status Book ClassSend acknowledgment, return hold status Library Screen Class

Figure 8.3. CRC card for class Library Control Class of the library information system.

8.9 See Figure 8.1.


8.11 See Figure 8.3

8.12 See Figure 8.4

8.13 getName: Person Info ClassaddMember: Maintain Member ClassmodifyProvider: Maintain Provider ClassaddVisit: Visit Info ClassprintEFTReport: EFT Report Class

8–3


8–4


CLASS ATM Control Class

RESPONSIBILITY COLLABORATIONReturn balance, send acknowledgment, send message

ATM Screen Class

Verify PIN, determine balance, update account balance,

Account Class

Figure 8.4. CRC card for class ATM Control Class of the ATM information system.

Figure 8.5. Class diagram (part 1 of 3).

8.14 See Figure 8.5 (in three parts).

8–5

ChocAn Class

Get Input Class

String readString (int maxlength)String readType (int maxlength)String readDate (int maxlength)int readSelection (int maxNumber)int readNumber ()int readCode ()char readStatus (char personType,

int maxlength)

Maintain Member Class

void addMember ()void updateMember ()void verifyMemberStatus ()

Maintain Provider Class

void addProvider ()int updateProvider ()


PersonInfo ClassString Name : 25 charslong Number : 9 digitsString Address : 25 charsString City : 14 charsString State : 2 lettersString Zipcode : 5 digitschar Status : 1 letter

void setName (String newName)void setNumber (long newNumber)void setAddress (String newAddress)void setCity (String newCity)void setState (String newState)void setZipcode (String newZipcode)void setStatus (char newStatus)String getName ()long getNumber ()String getAddress ()String getCIty ()String getState ()String getZipcode ()char getStatus ()int getYear ()String getCurrentDate ()long getNewNumber (String fileName)String findName (String searchString,

String fileName)String findNumber (long searchNumber,

String fileName)void setData(String buffer)void getData ()void getUpdateData ()

Provider Info ClassString Type : 1 char

void setType (String newType)void setAdditionalData (String buffer)void getAdditionalData ()String getType ()int addProviderFile () int updateProviderFile ()

Member Info ClassString lastDatePaid : 10 chars

void setLastDatePaid (string newlastDatePaid)void setAdditionalData (String buffer)void getAdditionalData ()String getLastDatePaid ()int addMemberFile ()int updateMemberFile ()void memberVerification ()

Figure 8.5. Class diagram (Part 2 of 3).

8–6


Figure 8.5. Class diagram (Part 3 of 3).

8–7

Visit Info ClassString dateOfVisit : 10 charsString Comments : 100 chars

void setDateOfVisit (String newDateOfVisit) void setComments (String newComments)String getDateofVisit ()String getComments ()int addVisitFile (MemberInfo currentMember,

ProviderInfo currentProvider,ServiceInfo newService)

Service Info Classint serviceCode : 6 digitsString serviceName : 14 charsString service Description : 40 charsfloat serviceFee : (999.99 max)

void setServiceCode (int newServiceCode)void setServiceName (String newServiceName)void setServiceDescription (String

newServiceDescription)void setServiceFee (float newServiceFee)int getServiceCode ()String getServiceName ()String getServiceDescription ()float getServiceFee ()int setData (int searchCode)

Add Visit Class

void addVisit ()

Request Service Class

int lookupServiceCode ()int providerDirectory ()int verifyServiceCode (String buffer)

Create Report Class

void printMemberReports ()void printProviderReports ()void printReports ()

Member Report Class

int printMemberReports ()

Manager Report Class

void printManagerReport ()

Provider Report Class

int printProviderReports ()

EFT Report Class

void printEftReport ()


CHAPTER 9

THE WORKFLOWS AND PHASES OF THE UNIFIED PROCESS

In Chapter 3, the students have to unlearn the traditional concept of a “phase” and replace it with the Unified Theory concept of a “workflow.” In this chapter, the students discover that there are indeed phases in the Unified Process, but they correspond to increments. I included Figure 9.3 to assist the instructor in this regard.

The way I answer the series of questions that erupt immediately I mention the phases of the Unified Process is to turn to Figure 9.3 and point out that the word “phase” appears in two places in that figure. In addition, I repeatedly mention that the traditional paradigm is one dimensional, whereas the object-oriented paradigm is two-dimensional. Accordingly, addi-tional terminology is needed for that second dimension of the Unified Process, and, unfortu-nately, the word “phase” was chosen.


1. Requirements workflow, analysis workflow, design workflow, implementation work-flow, and test workflow.

2. Management workflow, planning workflow.

3. To implement the target information system in the selected implementation language.

4. Unit testing; integration testing; product testing (not acceptance testing).

5. Unit testing: Test one module (code artifact).Integration testing: Test all the modules that have been unit tested so far.Product testing: Test the complete information system

6. Inception phase; elaboration phase; construction phase; transition phase.

7. To determine whether the proposed information system is economically viable.

8. To refine (elaborate) the artifacts of the previous phase.

9–1


9. To produce the first operational-quality version of the information system.

10. To ensure that the client’s requirements have indeed been met.

11. Ideally, we would first complete the requirements before proceeding to the analysis. Similarly, we would complete all the analysis before starting the design, and so on. In reality, however, all but the most trivial information systems are too large to han-dle as a single unit. Instead, we have to divide the task into increments (phases), and within each increment we have to iterate until we have completed the task under con-struction.

PROBLEM SOLUTIONS

9.1 The claim is correct.

9.2 There is no existing information system with which the new information system can be compared. Accordingly, it will not be possible to run the information system in parallel with an existing one. Therefore, the information system should be subjected to extensive testing.

The client is assumed to be inexperienced with computers. Therefore, special atten-tion should be paid to the analysis workflow and to communication with the client. The information system has to be made as user-friendly as possible.

There is always the possibility of a major design fault, so extensive testing should be performed during the design workflow.

The information system must meet the specified storage requirements and response times. This should not be a major problem because of the small size of the information system, but it needs to be monitored throughout development.

9.3 As above.

9.4 Meet with the developers to determine the cost of the proposed information system. Meet with the management consultant to determine how much Osbert is losing each year as a consequence of his current overpaying for paintings. Compare the cost of the information system with the estimated savings over the next 5 years.

9.5 Meet with the developers to determine the cost of the proposed information system. Meet with a management consultant to determine how much money will be saved by letting the computer do the computations currently performed manually. Also, de-termine whether any money has been lost as a consequence of mistakes in the manual computations. Compare the cost of the computerized system with the projected sav-ings over 5 years.

9–2


9.6 A user manual is essential. It should include a list of common problems that might arise and how to solve them. Because Osbert will not do any maintenance himself, technical manuals will not be delivered to the client.

9.7 A user manual is essential. It should include a list of common problems that might arise and how to solve them. Because the MSG Foundation staff members will not be involved in maintenance, technical manuals will not be delivered to the client.

9.8 Complete implementations of the ChocAn information system in both Java and C++ can be downloaded from www.mhhe.com/schach.

9–3


CHAPTER 10

MORE ON UML

Students are quick to realize that a detailed understanding of UML can result in their getting an interesting and well-paid job, so they are usually keen to learn the material of Chapter 10. However, this eagerness to master UML can be taken too far. In one class I taught, a number of students complained that the material on UML in Chapters 3 through 6 was inadequate for their needs, and they wanted to know more. I told them that we would study UML in depth in Chapter 10. However, even this was not enough for some of them—after I had completed Chapter 10 they wanted to learn still more about UML. I told those students to click on www.omg.com and download the complete UML manual.


1. No, it is a language.

2. The name of the class goes in the top box, the attributes in the middle box, and the operations in the lowest box.

3. An integer. A range. The Kleene star.

4. Aggregation is the UML term for the part–whole relation.Composition is a stronger form of association in which, in addition, every part may belong to only one whole, and, if the whole is deleted, so are the parts.

5. Inheritance is a special case of generalization.

6. Association is an arbitrary relationship between two classes.A class is a set of related objects.When the association between the two classes is modeled as a class, this class is called an association class.

10–1


Figure 10.1. UML class diagram for modeling stock markets

7. A use case is a model of the interaction between external users of an information sys-tem (actors) and the information system itself. A use-case diagram is a set of use cases.

8. Sequence diagrams and collaboration diagrams.

9. An action takes place as part of a transition.An activity is performed when a state is entered.

10. A set of states that share a transition and therefore are grouped together to simplify the statechart.

11. A fork has one incoming transition and many outgoing transitions, each of which starts an activity to be executed in parallel with the other activities. A join has many incoming transitions, each of which leads from an activity executed in parallel with the other activities, and one outgoing transition that is started when all the parallel activities have been completed.A swimlane is a partition within an activity diagram into which related activities are grouped.

12. A large information system should be decomposed into relatively independent pack-ages, represented in UML by a package diagram.

PROBLEM SOLUTIONS


10–2

Stock Market Class


Figure 10.2. UML class diagram for modeling cakes.

Figure 10.3. UML class diagram for modeling dining rooms.



10–3

Cake Class

– eggs– flour– milk– cocoa

– mix ( )– bake ( )– frost ( )+ eat ( )

Dining Room Class

1 1 1

1 4..*

Table Class Chair Class Sideboard Class Fireplace Class

0..1

1

1


Figure 10.4. UML class diagram for modeling dining rooms using aggregation and composition.


10–4

Dining Room Class

1 1 1

1 4..*


0..1

1

1


Figure 10.5. UML class diagram reflecting that a dining room is a specific type of room.

Figure 10.6. UML class diagram for modeling chocolate cakes.



10–5

Cake Class

– eggs– flour– milk– cocoa

– mix ( )– bake ( )– frost ( )+ eat ( )

This is achocolatecake

Dining Room Class

1 1 1

1 4..*


0..1

1

1

Room Class


Figure 10.7. UML statechart for modeling 4'33".


10–6

StartingWalk onto stage holding a stopwatch and the score.Sit at the piano.Put the score and the stopwatch on piano.Open the score.Start the stopwatch.

FinishingClose the score.Pick up the score and the stopwatch.Get up.Leave the stage.

Playing the First MovementLower the lid of the piano.Carefully follow the blank score for 30 seconds.Raise the lid of the piano.

Playing the Third MovementLower the lid of the piano.Carefully follow the blank score for 1 minute 40 seconds.Raise the lid of the piano.

Playing the Second Movement

Lower the lid of the piano.Carefully follow the blank score for 2 minutes 23 seconds.Raise the lid of the piano.


CHAPTER 11

CASE

Even the students who have taken a programming course usually have no experience with multiple versions. Accordingly, they do not appreciate the need for version control tools. Business students, however, generally identify with the concept of managing multiple ver-sions. Then, once they appreciate that even relatively small information systems generate a multiplicity of versions and that these versions need to be managed, they become more re-ceptive to the concept of a version control tool. The next step, configuration control, is then relatively simple to teach.


1. Computer-aided software engineering.

2. A tool is a program that assists in just one aspect of the development and maintenance of an information system. A workbench is a collection of tools that together support one or two activities. An environment supports the complete information system development and mainte-nance life cycle or, at the very least, a large portion of the information system life cycle.

3. A computerized list of all attributes and operations that are defined within the information system.

4. A method is an implementation of an operation.A parameter is data transferred to a method when that method is invoked at run-time.

5. It is convenient to have a manual at one’s fingertips.It is generally quicker to query a manual by computer than to try to find the appro-priate manual and plow through it page by page to find the needed item. It usually is easier to update an online manual than to try to find all the hard-copy versions of a manual within an organization and make the necessary page changes.

6. A version is an instance of a module.A variant is a version constructed for use in a different environment.

11–1


A variation is a version constructed to correct a fault.

7. A version is an instance of a module.The set of the specific versions of the modules from which a given version of the ex-ecutable load image of the complete information system is developed, is called the configuration of that version of the information system.

8. A build tool assists in selecting the correct version of each source-code module to be compiled and then linked together to form a specific version of the information system.

9. A configuration (set of versions) of all the artifacts in the information system.

10. To freeze a version means to insure that that version is never changed.

11. Report generator.Screen generator.Graphical user interface generator.

12. Ease of use.

PROBLEM SOLUTIONS

11.1: A version control tool is essential for all types of development and maintenance of information systems; it may come as part of the operating system.

11.2: A configuration management tool is highly desirable because it is difficult for anyone to keep control over multiple modules, irrespective of the size of the information ser-vices organization. If a configuration management tool costs too much for a small organization, then just a version control tool together with a build tool will have to suffice.

11.3: Paul, Quentin, and Rachel make local copies of each of the four modules, and deter-mine what changes each will make. Each in turn then freezes the current version of all four modules, makes changes, and has the changes tested by the SQA group. The changed version becomes the baseline version, local copies of which are then distrib-uted to the remaining maintenance programmers. The baseline versions of the four modules must be under the personal control of the manager to ensure that this proce-dure is followed exactly in the absence of an automated tool.

11.4: Never. A “corrected” version may be just as faulty as the module it is intended to replace. Also, when dealing with multisite software, not all sites will necessarily in-stall a new module.

11–2


11.5: Given an executable load image, only a configuration control tool can determine which version of each of its components went into it.

11.6: Cost is the major reason. Also, introducing any new technology is considered a time sink.

11.7: The difference between introducing CASE tools in a city administration and in a commercial organization is that cities are generally short of money and are loathe to spend their limited funds on “high tech.” The real problem is to convince the city council (and ultimately, the taxpayers) that investing in CASE tools will save money in the long run. In my personal experience, unless the mayor is personally committed to CASE, little or nothing will be done.

TERM PROJECT

11.8 A minimal set of case tools is as follows:UML modeling tool (Rational Rose or ArgoUML)Coding tool/structure editor (Borland Builder for C++ or JBuilder for Java)Version control software (SourceSafe or CVS)Word processing software, spreadsheet, e-mail, Web browser

11–3


CHAPTER 12

TEAMS

It is important that all students understand that, in the industry, software is produced by teams. This lesson is often hard to accept by some self-styled “stars” who simply have no patience to work on homework and project teams with other, less talented, students. Never-theless, most organizations are not prepared to hire such individualists, no matter how tal-ented they may be.


1. Most information systems are too large to be completed by a single information tech-nology professional within the given time constraints, so a team is needed.

2. The amount of work one person can do in one month.

3. Adding personnel to a late information system project makes it even later.

4. It is all but impossible to find one individual who is both a highly skilled programmer and a successful manager.

5. The roles of highly skilled programmer and successful manager are separated.

6. The partially completed components are put together. The resulting information system is then tested and debugged.

7. Any remaining faults that have been detected so far are fixed and the build is then frozen.

8. The computers of the XP team are set up in the center of a large room lined with small cubicles.

A client representative works with the XP team at all times.

No individual can work overtime for two successive weeks.

12–1


There is no specialization. Instead, all members of the XP team work on all work-flows.

There is no overall design phase before the various builds are constructed. Instead, refactoring is applied.

9. All code is implemented by a team of two programmers sharing a single computer.

PROBLEM SOLUTIONS

12.1: Use a modern hierarchical team—this is a standard application area.

12.2: The approach is hard for an inexperienced programmer to learn unless he or she is the only beginner in a team of experienced programmers. The situation is exacerbated when the managers are inexperienced, too, and therefore probably have no previous experience with synchronize-and-stabilize teams.

12.3: It is likely that one student is more experienced and knowledgeable than the others, and that that student has strong leadership skills, as well.

12.4 The cost would be prohibitive—the information system will be built twice, but the client will surely pay for only one version.

Observed differences between the two teams may be due to differences between indi-vidual programmers, not to team organization. To overcome this problem, multiple copies of the information system would have to be built with both kinds of teams so that statistical methods of comparison can be used.

We cannot determine which team organization is better until the information system has been in maintenance mode for a number of years. That would require both versions to be maintained in parallel for a number of years, adding further to the cost.

It is hard to measure the impact of a team member leaving. His or her replacement will have to be trained and then brought up to speed on the project. (There is no way of forcing all members of both teams to stay until the experiment has been com-pleted!)

12.5: If they each have their own computer, then they will function as two individuals, not a team of two.

12.6 Typical answers range from comments on XP itself to the risk of working for a com-pany that uses agile methods.

12–2


TERM PROJECT

12.7: Any of the team organizations in Chapter 12 will work well on this small project (the democratic team structure cannot be externally imposed).

12–3


CHAPTER 13

TESTING

The major theme of this chapter is that testing is not a separate phase of the life cycle, but an activity that must be carried out continuously throughout the life cycle, from the very begin-ning to the end.

It is important that the distinction between execution-based and nonexecution-based testing be carefully drawn. For many students, the very idea of nonexecution-based testing is diffi-cult to comprehend.


1. Verification is process of determining whether a specific workflow has been correctly carried out; this takes place at the end of each workflow. (Verification is also a synonym for nonexecution-based testing.)Validation is the intensive evaluation process that takes place just before the informa-tion system is delivered to the client to determine whether the information system as a whole satisfies its specifications.

2. Execution-based testing of an artifact means running (“executing”) the artifact on a computer and checking the output.

Nonexecution-based testing consists of reading through the artifact in question as carefully as possible.

3. The extent to which the information system satisfies its specifications.

4. Referring to an error as a bug is a way of casting off responsibility.

5. An error is a mistake made by a programmer.A fault is the standard IEEE terminology for what is popularly called a bug. The bug is the consequence of the programmer’s error.A failure is the observed incorrect behavior of the information system as a conse-quence of a fault.

13–1


6. If serious faults are found in an information system as the delivery deadline ap-proaches, there are two unsatisfactory options. Either the information system can be released on time but full of faults (the choice of the development team), or the devel-opers can fix the information system but deliver it late (the choice of the quality as-surance group). The overall decision should be made by a more senior manager who can decide which of the two choices would be in the best interests of both the devel-opment organization and the client.

7. It is not a good idea for the person responsible for drawing up a document to be the only one responsible for reviewing it.

The advantage of a review by a team of experts is that the different skills of the par -ticipants increase the chances of finding a fault.

A team of skilled individuals working together often generates a synergistic effect.

8. A correction produced by a committee (that is, the inspection team) is likely to be inferior in quality to a correction produced by an individual trained in the necessary techniques.

A correction produced by an inspection team of (say) five individuals will take at least as much time as a correction produced by one person and, therefore, costs five times as much when the salaries of the five participants are considered.

Not all items flagged as faults by an inspection team actually are incorrect.

There is not enough time in an inspection to both detect and correct faults.

9. Overview; preparation; inspection; rework; follow-up.

10. Utility; reliability; robustness; performance; correctness.

11. The programmer should desk-check the program.

Systematic testing must be done by the software quality assurance group.

12. When the information system has been decommissioned and removed from service.

PROBLEM SOLUTIONS

13.1: They are not used—testing is used instead.

13.2: If the organization is restructured so that 23 professionals (28% of 83), including five managers (28% of 17), are concerned solely with SQA, then increased productivity and product quality can be expected. The costs to the company will include

13–2


reorganization time (two day’s labor, approximately 66 × $800 + 17 × $1075, or about $71,100) and training time and costs for the five SQA managers (perhaps $75,000). The total cost of about $150,000 should be recouped in a year even if productivity increases by only 3%.

13.3: Suppose that development is done by five professionals including one manager, while SQA is done by the other two professionals including the other manager. Reorganization costs are now about $6,150 (that is, less than one tenth of the costs for Problem 13.2), and training costs for only one manager are about $15,000. Again, the total cost should soon be recouped.

13.4: The results of the experiments cited at the end of Section 13.2.2 of An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process show that inspections both detect faults and save money.

13.5: Utility: Is it easy to use? How much training is needed for the package to be used ef-fectively? How easy is the documentation to understand? Is the package reasonably priced compared to similar packages on the market? Does it have all the features that we need?

Reliability: How frequently does the package fail? What are the results of such a failure, and how easy is it to resume work?

Robustness: How does the package react to invalid input data? What happens if the machine is turned off while data are in the course of being entered? What happens if the user bangs on the keyboard in the middle of a computation?

Performance: Can the package keep up with our fastest clerks? Can it handle our largest documents? What printers does it support? If it can handle spooling, how many documents can it spool at once? What are its networking capabilities? What is its response time under peak load?

Correctness: Does it function correctly? Are the commands correctly described in the user manual? Does it corrupt files in any way?

13.6: Utility: Is it easy to use? What types of encryption are supported? Can it transfer data between different types of hardware? Is it economically priced compared to similar packages on the market?

Reliability: How accurate is the transmission of both large and small files?

Robustness: What happens if a single node or a combination of nodes goes down? How tolerant of line noise and spikes on the line is the package?

Performance: What speeds of data transfer are supported? How does performance degrade under increased load? Does the package degrade gracefully without loss of

13–3


reliability? How secure is the network? What is the largest file and the smallest file that may be transferred?

Correctness: Does the package transfer files as laid down in the specifications?

13.7: Utility: Is it easy to use? How much training is needed for the package to be used ef-fectively? How easy is the documentation to understand? Is the package reasonably priced compared to similar packages on the market? Does it have all the features that we need?

Reliability: How frequently does the package fail? What are the results of such a failure, and how easy is it to resume work?

Robustness: How does the package react to invalid input data? What happens if the machine is turned off while data are in the course of being entered? What happens if the user bangs on the keyboard in the middle of a computation?

Performance: Can the package keep up with our fastest clerks? Can it handle our largest documents? What printers does it support? If it can handle spooling, how many documents can it spool at once? What are its networking capabilities? What is its response time under peak load?

Correctness: Does it function correctly? Are the commands correctly described in the user manual? Does it corrupt files in any way?

TERM PROJECT

13.8 Utility: Let the client and users use the system while it is still in development.Reliability: Test the program continually and document any failures that occur and the time taken to repair the effect of the failure. Robustness: Let the system analysts and users run the information system, submitting both valid and invalid data.Performance: Let a number of users run the program and enter data at the same time. Measure the overall response time, and determine if the file space on the server is adequate.Correctness: Review all documentation (including the implementation artifacts), and run comprehensive test cases.

13–4


13.9

1. Test cases for adding a member or a provider:

1.1 Test cases for member name, provider name:

Test case: Input: Result: Comments: Passed:Overlong name (25 chars)

Abcdefghijklmnopqr-stuvwxyz

"Too long" Y

No name entered

[return] "Must enter value" Y

Inappropri-ate name

[White space] Blanks To be implemented in version 2.0

N

1.2 Test cases for member address, provider address:

Test case: Input: Result: Comments: Passed:Address too long (24 chars)

1234 Shallow Creek Road

First 22 characters accepted

Prompt is for 25 chars (tested with >25 chars and program failed)

Y

User does not enter an address

[return] "Must enter a value" Y

Inappropri-ate address

3 spaces Accepted User just might have a weird address

N/A

1.3 Test cases for member city, provider city:

Test case: Value Entered: Result: Comments: Passed:City too long (14 chars)

Averylongcitynameishere

"Too long" Y

User does not enter a city


Inappropri-ate city

Several spaces Accepted To be implemented in version 2.0.

N

13–5


1.4 Test cases for member state, provider state:

Test case: Input: Result: Comments: Passed:State too long (> 2 chars)

Asdfasdf "Too long" System makes sure state is exactly 2 chars

Y

State too short (< 2 chars)

[return] Must enter value Y

User does not enter letters

2 spaces Accepts Value To be implemented in version 2.0.

N

1.5 Test cases for member ZIP code, provider ZIP code:

Test case: Input: Result: Comments: Passed:ZIP code too long (> 5 chars)

1234567 Too long Y

ZIP code too short (< 5 chars)

Asdf Not right length Prompt says "< 5 chars"

Y

User does not enter digits

[5 spaces] Accepts value To be implemented in version 2.0.

N

1.6 Test cases for last date paid (only members):

Test case: Input: Result: Comments: Passed:Date too long/short (≠ 9 digits)

12-01-21231 "Not right length" Y

Month/day/ year entered is invalid

34-45-2002 "Month not valid" Month must be between 1 and 12

Y

Day entered is not valid for the month entered

02-30-2002 "Day entered not valid" Day must be between 1 and 29 from month 2

Y

User does not enter a value

[return] "Not right length" Must enter a value Y

13–6


1.7 Test cases for provider type:

Test case: Input: Result: Comments: Passed:Type too long (> 1 character)

Ie "Too long failure" Y

Invalid type–not I, D, or E

q "Incorrect type" Y


[return] "Incorrect type" Y


[space] "Incorrect type" Y

1.8 Test cases for status

Test case: Input: Result: Comments: Passed:Status too long (> 1 char)

qq "Failure" Y

User does not enter an A, I, (or S for a member)

q "Failure" Y


[return] "Failure" Y

2. Test cases for updating a member or provider:

[If the user does not know the number or the name of the member or provider, then it is impossible to exit from the search. This will be fixed in Version 2.0]

2.1 Test cases for searching for a member name or provider name:

Test case: Input: Result: Comments: Passed:User does not enter a name


Member or provider name entered is not in the file

Someone "Arrayindexoutofbounds exception at Person.findName(226)"

Error not reproducible

Y

Member or provider list file does not exist

"Printing output.txt IO Exception. Name entered is not found in file."

Continues execution back at main menu

Y

13–7


2.2 Test cases for searching for a member number or provider number:

Test case: Input: Result: Comments: Passed:User does not enter a number

[return] "Incorrect input" Y

Member or provider number entered not in file

123456789 "Invalid entry" Y

Member or provider list file does not exist

(.txt file was deleted) "Printing output.txt IO Exception. Number entered is not found in file."

Continues execution back at main menu

Y

Member number too long, not valid (> 9 digits)

1234567890123 Incorrect input Please try again. Y

2.3. Test cases for changing a member or provider attribute:

Test case: Input: Result: Comments: Passed:User does not enter a 'y'es or 'n'o

x "Please enter 'y' or 'n' " Y


[Enter] "Please enter a value". Y

2.4 through 2.11. Same as the corresponding add member and add provider test cases (Tables 1.1 through 1.8)

3. Test cases for verifying a member number:

Test case: Input: Result: Comments: Passed:Member number too long (> 9 digits)

555555555555 "Please enter value of 9 digits"

Y

Member number is not in file

999999999 "Member Number not found. Try Again."

Y

Member file does not exist

"IOException: Member file not found." Information system then exits.

Y

13–8


4. Test cases for adding a visit:

4.1. Test cases for entering a member number:

Test case: Input: Result: Comments: Passed:Member number too long (> 9 digits)

666666666666 "Please enter a number with 9 digits – try again"

Y

Member number does not exist

999999999 "Member number not found – try again"

Y

Member number inactive or suspended

"Inactive/Suspended Member" – Information system exits to main menu

Only active members can make visits

Y

4.2. Test cases for provider number:

Test case: Input: Result: Comments: Passed:Provider number too long (> 9 digits)

8888888888888 "Please enter a number with 9 digits – try again"

Y

Provider number not found

99999999 Provider number not found – try again:

Y

4.3. Test cases for date of visit:

Test case: Input: Result: Comments: Passed:Date too long/short (≠ 10 digits)

17 "Date too short – please try again with date (mm-dd-yyyy)"

Y

Month/day/ year entered is invalid

06-78-2002 "Day invalid. Please enter day between 01 and 30"

Y

Day entered is not valid for the month entered

06-31-2002 "Day invalid. Please enter day between 01 and 30"

Y


[Enter] "Please enter a value" Y

13–9


4.4 Test cases for entering a Service Code:

Test case: Input: Result: Comments: Passed:Service code too long

123456789 "Please enter service code with 6 digits"

Y

Service code does not exist

999999 "Service code not found – please re-enter the code"

Prints out Provider Directory again to assist the user in reentering the service code

Y

4.5 Test cases for verifying service code entered:

Test case: Input: Result: Comments: Passed:User does not enter 'y'es or 'n'o

x "Please enter 'y' or 'n' – try again"

Y

User enters 'n'o – for service code incorrect

n Prints out Provider Directory again and asks user to select a different code

Providing a detailed description ensures this is the correct service

Y

4.6. Test cases for entering optional Comments:

Test case: Input: Result: Comments: Passed:No Comments are entered

[Enter] Accepted Comments are optional

Y

Comments entered are too long (> 100 chars)

Comment Comment Comment Comment Comment Comment... Comment Comment ...

"Value entered is too long. Please enter comments of 100 chars of less"

Y

5. File tests:

5.1. Tests that an added visit is written correctly to the file:

Test: Value Entered: Result: Comments: Passed:Is the information written to the file?

N/A Yes Y

Is the information in the file correct?

N/A Yes Y

13–10


6. Tests of printed reports:

6.1 Tests of printing the member reports:

Test: Input: Result: Comments: Passed:Is the report printed?

N/A Member and visit information is printed

Y

Is the report printed correctly?

N/A Yes. Y

6.2 Tests of printing the provider and EFT reports:

Test: Input: Result: Comments: Passed:Are the provider reports printed?

N/A Provider and visit information are printed

Y

Are the provider reports printed correctly?

N/A Yes Y

Is the EFT Report printed?

N/A Yes Y

Is the EFT Report correct?

N/A Yes Y

6.3 Tests of printing the manager report:

Test: Input: Result: Comments: Passed:Is the report printed?

N/A Provider and fee totals are printed.

Y

Is the report printed correctly?

N/A Yes Y

13–11


6.4. Tests of printing all the reports:

Test: Input: Result: Comments: Passed:Are all reports printed?

N/A Yes Y

Are all reports printed correctly?

N/A Yes Y

Is the visit list file flushed and emptied?

Yes Y

13–12


CHAPTER 14

MANAGEMENT ISSUES

Many of the more technically minded students show a marked lack of interest in management material. I motivate them by pointing out that the better competent information systems professionals are promoted to managerial positions within 3 to 5 years.

I have not mentioned in Section 14.4 that the critical path is the shortest path through the network; I like my students to figure that out by themselves.


1. The comparison of estimated future benefits against projected future costs.

2. Process improvement.

3. Initial level: No information system management practices are in place in the organi-zation. Instead, everything is done on an ad hoc basis.Repeatable level: Basic information system project management practices are in place. Defined level: The process for information system development is fully documented. Both the managerial and technical aspects of the process are clearly defined, and con-tinual efforts are made to improve the process wherever possible.Managed level: Quality and productivity goals are set for each project.Optimizing level: The organization works toward continuous process improvement.

4. A series of five related standards applicable to a wide variety of industrial activities, with the aim of process improvement.

5. An international process improvement initiative.

6. Size; cost; duration; effort; quality.

7. Critical path management/program evaluation review techniques.

14–1


8. The path through the chart that consists of critical activities only (or, the shortest path through the network).

9. C++; Java.COBOL

10. Accidental reuse occurs when the developers of a new information system realize that an artifact of a previously developed information system can be reused in the new information system.Deliberate reuse is the utilization of information system artifacts constructed specifi-cally for possible future reuse.

11. The not invented here (NIH) syndrome.The danger of reusing faulty artifacts.The problem of artifact retrieval.Reuse is expensive. Legal issues.

12. Reuse refers to using artifacts of one information system to facilitate developing a different information system with different functionality.Portability is the ease with which an information system can be adapted to run on a variety of different hardware–operating system combinations.

13. Hardware incompatibilities.Operating system incompatibilities.Compiler incompatibilities.

14. A good information system can be implemented, over its lifetime, on three or more different hardware configurations.

PROBLEM SOLUTIONS

14.1: Cost–benefit analysis will help the committee to decide whether it would be more ad-vantageous for the Concordian government to do nothing, or take active steps to alle-viate the problem.

Health care costs are of two types, preventative medicine (inoculating the populace, assuming that a vaccine exists) and treating the victims. The cost of preventative medicine can be estimated by multiplying the total number of Concordians by the cost of inoculation; the latter figure can be furnished by the Department of Health on the basis of previous inoculation campaigns. The cost of future treatment can be esti-mated using data regarding the cost of treating current victims of the disease; its fu-ture incidence can be estimated using epidemiological methods. The total treatment cost is then the cost per victim times the estimated future number of victims.

14–2


Loss of earnings and taxes for two weeks’ sickness can be estimated from tax records, assuming that the disease attacks members of every socioeconomic group equally.

Pain and discomfort can be estimated by examining the awards for damages in civil suits with a similar level of discomfit.

Gratitude towards the government could be estimated by multiplying the cost (in government spending) of buying a vote by the number of votes estimated to be lost to the opposition if the disease is not eradicated; the latter figure can be obtained by taking an opinion poll.

14.2: Provide information technology education for all employees, including managers. This is a necessary prerequisite for advancement to maturity level 2.

14.3: A CASE environment implicitly or explicitly incorporates a process. An organiza-tion that has reached level 3 has a fully documented process in place, and a CASE environment can then be used to automate that process. However, introducing a CASE environment to a level 1 or level 2 organization almost invariably has the effect of imposing a process (that may or may not be appropriate) onto an organiza-tion that is not ready to adopt any process at all. The result is usually disastrous.

14.4: Unlike an environment, a CASE tool does not impose a process. Thus, almost any CASE tool that is relevant to the individual tasks being performed will help the or-ganization. For example, a version control tool will assist in keeping track of the dif-ferent versions of a source file.

14.5: Path ADJ takes 23 days.Path ABCDJ takes 24 days.Path ABEFGHJ takes 22 days.The critical path is therefore ABEFGHJ.

14.6: Path ABEJ takes 27 daysPath ABFJ takes 27 daysPath ACFJ takes 23 daysPath ACGJ takes 24 daysPath ADGJ takes 20 daysPath ADHJ takes 21 daysThe critical activities are therefore AD, DG, and GJ.

14.7: If a code artifact is reused unchanged then it has already been designed, coded, tested, and documented. These steps therefore do not need to be repeated, thereby reducing the cost of the information system. Nevertheless, the code artifact still has to undergo integration testing; there is no cost saving here.

14.8: The reused module does not have to be redesigned or recoded (other than the change of sign), resulting in the same cost saving as before. However, the changed module

14–3


has to be unit tested and documented at additional cost, though probably less than if the module had been built from scratch. Integration testing should be the same as when the module is reused unchanged.

14.9: The fault should have been detected during the workflow in which it was decided to reuse the Ariane 4 Inertial Reference System alignment software (probably the design workflow, although it is possible that the decision was made earlier). Testing is an integral part of every workflow; the fault should therefore have been detected during that workflow.

14.10: Use object-oriented techniques; document code artifacts meticulously; the code artifacts for searching and updating the catalog should be written generically; the routines for reading bar codes should be able to handle any standard bar code; the query-handling component should use standard techniques such as menus that can be reused in other information systems, rather than a graphical user interface.

14.11: Use object-oriented techniques; code the information system in a programming language that is widely used; document the code artifacts meticulously; the user interface should be able to handle any similar sort of dialog; isolate the input and output components in separate code artifacts; design the information system in such a way that it can be understood by an accountant.

14.12: Use object-oriented techniques; code the information system in a language that is widely used; document the code artifacts meticulously; use standard communications protocols; use standard security protocols.

14.13: Raytheon Missile Systems Division: Reuse rates of 60% are possible.

Toshiba Software Factory: Strong management backing can lead to reuse of large artifacts.

NASA Software: Reuse is possible even without management backing, but is less cost-effective that way.

GTE Data Services: Financial rewards are a powerful mechanism for promoting re-use.

Hewlett-Packard: Large cost savings are possible as a consequence of reuse.

European Space Agency: Artifacts developed in one context must be retested when reused in a different context.

14.14: Use a standard programming language and adhere strictly to the standard for that lan-guage; use a popular operating system; meticulously maintain documentation; the design should allow for different cataloguing schemes (Dewey, Library of Congress, and so on) and different bar-coding schemes.

14–4


14.15: Use a standard programming language and adhere strictly to the standard for that lan-guage; use a popular operating system; meticulously maintain documentation.

14.16: Use a standard programming language and adhere strictly to the standard for that lan-guage; use a popular operating system; meticulously maintain documentation; gener-alized accounting practices should be followed, rather than those of one specific bank.

TERM PROJECT

14.17 The answer to this question depends on how the project was designed and imple-mented. In general, however, portions that handle data input and data update can probably be reused, with modifications.

14–5


CHAPTER 15

PLANNING AND ESTIMATING

Many students have little practical experience of either planning or estimating. Before teaching this material, it is essential to make sure that the students understand the importance of these activities within a business context.

The FFP metric is of little intrinsic value. However, I find that its simplicity makes it easy for me to teach other estimation methods, especially function points, once they have under-stood the FFP metric.


1. We do not have enough information at that point to be able to draw up a meaningful plan for the complete project.

2. The internal cost is the cost to the developers.The external cost is the cost to the client.

3. Too many variables are involved, especially human factors.

4. Creation of source code is only a small part of the total information system develop-ment effort.

Implementing the same information system in two different languages will result in versions with different numbers of lines of code.

It often is unclear exactly how to count lines of code.

Not all the code written is delivered to the client.

It is unclear how to count generated lines of code.

5. A number of experts are asked to arrive at an estimate by comparing the target infor-mation system to completed information systems with which the expert was actively involved, and noting the similarities and differences.

15–1


6. Experts work independently at producing an estimate and a rationale for that esti-mate. These estimates and rationales then are distributed to all the experts, who now produce a second estimate. This process of estimation and distribution continues until the experts can agree within an accepted tolerance. No group meetings take place during the iteration process.

7. A metric is used as input to a model for determining information system cost.

8. A project function is work that continues throughout the project and does not relate to any specific workflow of information system development.An activity is a major unit of work that has precise beginning and ending dates; con-sumes resources, such as computer time or person-days; and results in work products such as a budget, design artifacts, schedules, source code, or user’s manual. A task, a component of an activity, is the smallest unit of work subject to manage-ment accountability. The major resources required to build an information system are the people who will develop the information system, the hardware on which the information system is to run, and the support software such as operating systems, text editors, and version control systems.

9. A milestone is the completion of a work product.

PROBLEM SOLUTIONS

15.1: A “millstone” is a heavy burden; some organizations have difficulties meeting mile-stones at the promised time.

15.2: A milestone is the completion of a work product. Once a work product has been re-viewed and agreed on, it becomes a baseline and can be changed only through formal procedures.

15.3: (i) From Equation (15.1), size S = Fi + Fl + Pr = 7 + 50 + 86 = 143

(ii) From Equation (15.1), cost C = d S = 932 143 = $133,276

(iii) Productivity = (133,276 – 136,500)/133,276 or 2.42% lower than the com-pany average.

15.4: It is easy to measure, either manually or using a simple CASE tool. But more impor-tantly, it is easy for management to comprehend.

15.5: First obtain independent COCOMO and function point estimates as a check. Assum-ing that the predictions do not change significantly, the next step is to discuss the information system with experienced information system professionals, and ask them

15–2


to come up with estimates based on their experience (“expert judgment by analogy”). Use their estimates to try to decide whether the COCOMO or function point estimator is more likely to be an accurate predictor of the cost of the information system. If this, too, fails, then use the function point estimate on the grounds that it is generally less damaging in the long run to overestimate than to underestimate cost.

15.6: Although it is true that every information system is maintained, the maintenance need not be performed by the organization that is responsible for the development.

TERM PROJECT

15.7: Appendix A is an informal statement of the client’s requirements. Until the specification document has been drawn up, a cost or duration estimate is likely to be wildly inaccurate.

15.8 The project management plan presented here is a project management plan for devel-opment of the Chocoholics Anonymous information system by a small information system development organization consisting of three individuals, namely Alex, the owner of the company, and two systems analysts, Barbara and Chris.

1. Overview.

1.1. Project Overview.

1.1.1 Purpose, Scope, and Objectives. The objective of this project is to develop an information system that will assist the management of Chocoholics Anonymous in keeping track of the current members and providers currently at ChocAn and the ser-vices provided. The information system will allow the addition and modification of both member and provider records, verification of members, and the recording of consultation visits. The information system will also print out weekly reports, in-cluding the accounts payable (manager) report, member reports, provider reports, and an electronic funds transfer report, to provide a record of all visits and fees accumulated.

1.1.2 Assumptions and Constraints. Constraints include the following:

The deadline must be met.The budget constraint must be met.The information system must be reliable.The architecture must be open so that additional functionality may be added later.The information system must be user-friendly

1.1.3 Project Deliverables. The complete source code with user and operations manuals will be delivered 10 weeks after the project commences. The client will be responsible for acquiring the recommended hardware and system software by the time the information system is delivered.

15–3


1.1.4 Schedule and Budget Summary. The duration, budget, and personnel requirements of each workflow are as follows:

Requirements workflow (1 week, two team members, $3,600)Analysis workflow (2 weeks, two team members, $7,200)Design workflow (2 weeks, two team members, $7,200)Implementation workflow (3 weeks, three team members, $16,200)Test workflow (2 weeks, three team members, $10,800)

The total development time is 10 weeks and the total internal cost is $45,000.

1.2. Evolution of the Project Management Plan. All changes in the project man-agement plan must be agreed to by Alex before they are implemented. All changes should be documented in order to keep the project management plan correct and up to date.

2. Reference materials. All artifacts will conform to our company coding, docu-mentation, and testing standards.

3. Definitions and Acronyms.ChocAn—Chocoholics Anonymous, our client.EFT – electronic funds transfer (automated transfer of funds to the providers’ bank accounts)

4. Project Organization.

4.1 External Interfaces. All the work on this project will be performed by Alex, Barbara, and Chris. Alex will meet weekly with the client to report progress and dis-cuss possible changes and modifications.

4.2 Internal Structure. The development team consists of Alex (owner), Barbara, and Chris (systems analysts).

4.3 Roles and Responsibilities. The specification workflow was performed by Barbara and Chris, and checked by the client at meetings between Alex and the client. The design workflow will be shared between Barbara and Chris, and Alex will check the overall design. The implementation workflow will be performed by Alex, Barbara, and Chris. They will test each other’s code; Alex will conduct integration testing. Extensive testing will then be performed by all three and the client.

5. Managerial Process Plans.

15–4


5.1 Estimation Plan. As previously stated, the total development time is estimated to be 10 weeks and the total internal cost will be $45,000. These figures were ob-tained by expert judgment by analogy, that is, by comparison with similar projects.

5.1.2 Staffing Plan. Alex is needed for the entire 10 weeks, for the first 5 weeks in only a managerial capacity and the second 5 weeks as both manager and pro-grammer. Barbara and Chris are needed for the entire 10 weeks, for the first 5 weeks as systems analysts and designers, for the second 5 weeks as programmers and testers.

5.1.3 Resource Acquisition Plan. All necessary hardware, software, and CASE tools for building the information system are already available. The information sys-tem will be installed on hardware to be acquired by the client.

5.1.4 Project Staff Training Plan. No additional staff training is needed for this project.

5.2 Work Plan.

5.2.1–2 Work Activities and Schedule Allocation.

Week 1: Met with client, determined requirements artifacts. Inspected require-ments artifacts.

Weeks 2, 3: Produced analysis artifacts, inspected analysis artifacts. Assembled specification document, client approved it. Produced project management plan, in-spected project management plan.

Weeks 4, 5: Produce design artifacts, inspect design artifacts.

Week 6–10: Implementation and inspection of each module; unit testing; docu-mentation; integration of each module; integration testing; product testing; docu-mentation inspection.

5.2.3 Resource Allocation. The three team members will work separately on their assigned artifacts. Alex’s assigned role will be to monitor the daily progress of the other two, oversee implementation, be responsible for overall quality, and interact with the client. Team members will meet at the end of each day and discuss problems and progress. Formal meetings with the client will be held at the end of each week to report progress and determine if any changes need to be made. Alex will ensure that schedule and budget requirements are met. Risk management will also be Alex’s responsibility.

Minimizing faults and maximizing user-friendliness will be Alex’s priorities. Alex has overall responsibility for all documentation and has to ensure that it is up to date.

15–5


5.2.4 Budget Allocation. The budget for each workflow is as follows:

Requirements workflow: $3,600Analysis workflow: $7,200Design workflow: $7,200Implementation workflow: $16,200Testing workflow $10,800

Total: $45,000

5.3 Control Plan. Any major changes that will affect the milestones or the budget will have to be approved by Alex, and documented. There will be no outside quality assurance personnel involved. The benefits of having someone other than the individual who carried out the development task to do the testing will be accom-plished by each person testing another person’s work products.

Alex will be responsible for ensuring that the project is completed on time and within budget. This will be accomplished through daily meetings with the team members. At each meeting, Barbara and Chris will present the day’s progress and problems. Alex will determine whether they are progressing as expected, and whether they are following the specification document and the project management plan. Any major problems faced by the team members will immediately be reported to Alex.

5.4 Risk Management Plan. The risk factors and the tracking mechanisms are as follows:

There is no existing information system with which the new information system can be compared. Accordingly, it will not be possible to run the information system in parallel with an existing one. Therefore, the information system should be subjected to extensive testing.

The client (ChocAn management) is assumed to be inexperienced with computers; most providers are likely to be inexperienced, too. Therefore, special attention should be paid to the analysis workflow and communication with the client. The information system has to be made as user-friendly as possible.

There is always the possibility of a major design fault, so extensive testing will be performed during the design workflow. Also, each of the team members will initially test his or her own code and then test the code of another member. Alex will be responsible for integration testing, and will be in charge of product testing.

The information must meet the specified storage requirements and response times. This should not be a major problem because of the small size of the information sys-tem, but it will be monitored by Alex throughout development.

5.5 Project Close-out Plan. Not applicable here.

15–6


6. Technical Process Plans.

6.1 Process Model. The Unified Process will be used.

6.2 Methods, Tools, and Techniques. The workflows will be performed in ac-cordance with the Unified Process. The information system will be implemented in Java.

6.3 Infrastructure Plan. The information system will be developed using ArgoUML running under Linux on a personal computer.

6.4 Product Acceptance Plan. Acceptance of the information system by our client will be achieved by following the steps of the Unified Process.

7. Supporting Process Plan.

7.1 Configuration Management Plan. CVS will be used throughout for all arti-facts.

7.2 Testing Plan. The testing workflow of the Unified Process will be performed.

7.3 Documentation Plan. Documentation will be produced as specified in the Uni-fied Process.

7.4–5 Quality Assurance Plan, Reviews and Audits Plan. Barbara and Chris will test each other’s code and Alex will conduct integration testing. Extensive prod-uct testing will then be performed by all three.

7.6 Problem Resolution Plan. As stated in 5.3, any major problems faced by the team members will immediately be reported to Alex.

7.7 Subcontractor Management Plan. Not applicable here.

7.8 Process Improvement Plan. All activities will be conducted in accord with the company plan to advance from CMM level 2 to level 3 within 2 years.

8. Additional Plans.

Additional Components.

Security: An individual password will be needed by each manager and provider to use the information system.

Training: Training for ChocAn management and staff will be performed by Alex at the time of delivery. Because the information system is straightforward to use, 1 day

15–7


is sufficient for ChocAn training. Alex will answer questions at no cost for the first year of use. ChocAn management will be responsible for organizing training of the providers.

Information System Maintenance: Corrective maintenance will be performed by the team at no cost for a period of 12 months. A separate contract will be drawn up regarding enhancement.

15–8


CHAPTER 16

MAINTENANCE

I have found that this chapter is a good place to repeat the message regarding the importance of maintenance. I think that the mini case study of Section 16.4 is worth teaching in some detail, because it illustrates so many aspects of maintenance. (Like the other anecdotes in An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process, this one is also perfectly true. I have disguised the country and the name of the organization to protect the innocent. Instructors who would like to know the real names are welcome to contact me.)

Section 16.8 covers reverse engineering. The topic is becoming increasingly important as more and more organizations attempt to upgrade their information systems.


1. The process that occurs when an information system artifact is modified either be-cause of a problem or because of a need for improvement or adaptation.

2. Corrective maintenance: Correcting a fault of any kind.Perfective maintenance: Improving the effectiveness of the information system.Adaptive maintenance: Reacting to changes in the environment in which the informa-tion system operates.

3. Maintenance is a thankless task in every way.

The user’s problems have frequently been caused by the individuals who developed the information system, not the maintainer.

The information system itself may have been badly constructed, adding to the frustra-tions of the maintainer.

Maintenance is looked down on by many information system developers who con-sider development to be a glamorous job and maintenance to be drudgework fit only for beginners or incompetents.

16–1


4. The problem with the information system, no provision for expansion, was caused by the developer, not the maintainer.

The client frequently does not understand that maintenance can be difficult or, in some instances, all but impossible.

All information system development must be carried out with an eye on future main-tenance.

5. Information services organizations usually are understaffed, with a large backlog of work.

It almost always is cheaper to make a number of changes, test them all, change all the documentation, and install the new version than it is to perform each change sepa-rately, test it, document it, install the new version, and then repeat the entire cycle for the next change.

6. If the client is willing to pay the price, there is no solution.

7. If a class with subclasses is changed in any way, then this change is propagated to all its subclasses.

8. An information system in current use but developed at least 15 or 20 years ago.

9. Reengineering is the process of reverse engineering followed by forward engineering.Restructuring is the process of improving the information system without changing its functionality.Forward engineering is the usual development process that proceeds from analysis through design to code.Reverse engineering is the process of starting with the code and attempting to recre-ate the design artifacts or even the analysis artifacts.

10. When performing maintenance, there is always the risk of introducing a regression fault.

PROBLEM SOLUTIONS

16.1: Maintenance usually involves changes to other people’s work, so it is mistakenly viewed as a noncreative task. Also, because development of a complete information system usually involves many more person-months than one single maintenance task, development tasks produce more revenue than maintenance tasks, and hence better professionals are put to work meeting the development deadlines to bring in the money. The flaw in this argument can be seen by comparing the total annual revenue from development to the revenue from maintenance.

16–2


16.2: Every computer can, in theory, be infected with viruses. Thus, certain code artifacts will have multiple variations so that the information system can be run on many different computers and operating systems.

Turning now to the individual viruses, it is true that a given virus will usually be spe-cific to a certain hardware/operating system combination. However, there are those who will modify a virus so that it infects other hardware and/or operating systems. Thus, many of the code artifacts that check for the presence of a specific virus will also have to be able to be run on a wide variety of different computers and operating systems.

16.3: There are different cataloguing schemes for books; there are also different bar-coding schemes. In addition, some libraries may not be able to afford bar-code scanners and will use keyboard input. There are different operating systems and different hard-ware on which the library system may be implemented. There are different types of libraries with different circulation policies. Also, some libraries are branches of an overall library system, all sharing the same books.

16.4: There are an immense variety of personal computers/operating systems on which such an information system could be implemented.

16.5: ATM hardware will vary from bank to bank, as will the hardware/operating system of the computer controlling the ATM network. Each bank will have different policies regarding the operations that may be performed at an ATM; for example, credit cards may not be supported, or only one credit card account. The maximum amount of money that can be withdrawn per day may vary. Also, if the ATM system is implemented in other countries, aspects of the system will have to be changed. Finally, not only banks use ATMs, but also a wide variety of other financial institutions.

16.6: Necessary qualities include a broad range of information technology skills (especially documentation) and superb diagnostic skills. Good interpersonal skills are desirable, especially if he or she will be dealing with clients.

16.7: Because of the possibility that the organization will expand or be sold to someone else, one-person software maintenance should not be different in any way from main-tenance by a larger organization.

16.8: Data stored in file: name of information system; serial number of client’s version; version configuration, including hardware, operating system, and compiler details; date and time fault was detected; fault category (some sort of categorization scheme must be set up); details of any error messages reported by the information system or operating system; name of person reporting the fault; textual description of the problem; repair status of fault, including recommended ways to work around it; previous reports that seem to be related to this fault; management information such as name of maintenance programmer, and time devoted to each change.

16–3


Queries that could be answered include: fault status; billing information for each information system, configuration, version, and/or client; reported fault rates by information system, configuration, version, client, hardware, operating system, and/or fault category; correlations between these variables; which keywords occur frequently in textual descriptions.

A query that could not be answered: precisely how to fix a specific fault.

16–4


CHAPTER 17

USER-INTERFACE DESIGN

My experience is that few students initially view the telephone as an input–output device, but that every student soon identifies strongly with the bank example of Section 17.1. I therefore return to that example repeatedly when I teach this material.

The material on metaphors also strikes a family chord. Again, it is worthwhile to capitalize on this familiarity when teaching Section 17.4. Students who bring their laptops to class are sometimes willing to talk about the metaphors of the icons on their screens.


1. A lack of consistency leads to errors, frustration, and a strong negative attitude on the part of the customer toward the business.

2. Menu; desktop; drag-and-drop; sheet of paper; window; icon.

3. Whitespace: Use it freely.Color: Use as few colors as possible, and use them consistently.Fonts: Use as few fonts as possible, and use them consistently.

4. The user interface that each user sees has been carefully tailored to his or her skill level.

5. Decide on the elements of the user interface.Put together a preliminary design that incorporates just the bare elements themselves.Check that this preliminary iteration of the elements of the user interface is adequate. Determine how to express those elements. Produce the prototype user interface.

PROBLEM SOLUTIONS

17–1


17.1 First name of artistLast name of artistTitle of workYear of workHeight WidthMedium (oil, watercolor, other medium)Subject (portrait, still life, landscape, other subject)Maximum purchase priceDate of purchaseName of sellerAddress of sellerActual purchase price

17.2 Classification (masterpiece, masterwork, other painting)Sale dateLast name of artistPainting titleTarget selling priceActual selling price Asterisk denoting that the painting was sold at a price of 5 percent or more below the target selling priceAverage ratio of actual selling price to target selling price for all paintings in the report

17.3 Name of mortgageePriceDate mortgage was issuedCurrent weekly incomeDate weekly income was last updatedAnnual property taxDate annual property tax was last updatedAnnual insurance premiumDate annual insurance premium was last updatedMortgage balance

17.4 Estimated annual operating expensesDate estimated annual operating expenses were last updated

17.5 See Figures 17.1 through 17.3.

17–2


Welcome to First Bank of Purgatory.For information on your checking account, press 1.For information on your savings account, press 2.For information on your credit card account, press 3.For any other information, press 4.To hear these choices again, press 7.

Figure 17.1. Amended first menu from the bank computer

For your account balance, press 1.For information on a specific check, press 2.For information on the last 5 items credited to your account, press 3.For information on the last 10 items paid, press 4.To hear these choices again, press 7.To return to the previous menu, press 8.To return to the main menu, press 9.

Figure 17.2. Amended second menu from the bank computer.

To determine the status of one check number, press 1.To determine the status of a range of check numbers, press 2.To hear these choices again, press 7.To return to the previous menu, press 8.To return to the main menu, press 9

Figure 17.3. Amended third menu from the bank computer.

TERM PROJECT

17.6 The elements of use case Verify Member Status are member numbermember status (active, inactive, suspended, or not found).

The elements of use case Modify Provider (part of Maintain Provider) are:provider nameprovider numberprovider addressprovider cityprovider stateprovider ZIP codeprovider typeprovider status

17–3


CHAPTER 18

WEB-BASED INFORMATION SYSTEMS

The purpose of this chapter is to point out to the students that, within the information system context, there is nothing particularly special about the World Wide Web. As a result, the Web has no specific consequences for object-oriented analysis and design.


1. There is essentially no interaction between user and computer from the initiation of the program until its termination.

2. Interactive means that the user types in data when the program requests input. Timesharing means that each user receives a successive slice of computer time.

3. In a client–server network, a number of personal computers, the clients, are connected to a central computer with a large amount of disk storage, the server.

4. The mutual cooperation of compiled code from different vendors, implemented in different languages and running on different platforms.

PROBLEM SOLUTIONS

18.1 Both support only one user at a time, and both are similar in computing power. One major difference between the two was that the personal computer cost more than 1,000 times less than a first-generation computer and weighed more than 1,000 times less than its counterpart from 35 years before.

18.2 They are both networks of computers connected to servers. A client–server network consists of a number of clients connected to only one server, whereas the Web con-sists of hundreds of millions of clients and hundreds of thousands of servers. The Web is highly heterogeneous, that is, it runs on an essentially unlimited variety of different hardware and operating systems. Also, the clients are connected to the servers in a wide variety of different ways.

18–1


18.3 Essentially none.

18.4 Other than certain nonfunctional requirements with regard to communications (and therefore to security and reliability), essentially none.

TERM PROJECT

18.5 The major risk involved is security. There are many hackers and viruses on the Web that try to infiltrate and destroy online sites and businesses. Security precautions will need to be taken to protect members’ and providers’ information. For example, a password will have to be assigned to each provider to allow access the system. Also, antivirus software will have to be up-to-date on all systems and servers of ChocAn.

18–2


CHAPTER 19

DATABASE MANAGEMENT SYSTEMS

This chapter has two purposes. First, the material is intended to motivate students for the database course by giving them an introduction to the sorts of problems that databases solve. Second, I think it is important that a course on object-oriented analysis and design should give a brief introduction to the concept of an object-oriented database.


1. A collection of data records organized in a way that will facilitate the storage and retrieval of the data by the company’s information systems.

2. The software that runs the database.

3. A file is simply a collection of data. A database is an organized collection of data (see Question 1).

4. The primary key identifies each record in a specific table. When this key is used to identify records in a different table, the key is called a for-eign key.

PROBLEM SOLUTIONS

19.1 Database instructions are embedded within the source code.

19.2 The traditional database management system now has two tasks. In addition to managing the database, it also has to convert data from traditional to object-oriented format, and vice versa. That is, records have to be converted to objects, and conversely. In this way, the object-oriented information system can communicate with the traditional database management system.

19.3 Object-oriented database management systems are still too complex for use by most information technology services groups.

19–1


Existing traditional information systems would have to be totally rewritten, at enor-mous cost, to be able to access an object-oriented database.

19.4 Traditional databases solve the problem of redundant information, the update anomaly, and the deletion anomaly.

19.5 Because STAMPS has a traditional database management system that meets all their needs, it would be a waste of money to discard their entire information system and install an object-oriented information system instead.

TERM PROJECT

19.6: It could be done, but the complexity of most object-oriented database systems would make it hard to complete the project on time and within budget.

19–2


CHAPTER 20

TECHNICAL TOPICS

There are two schools of thought regarding polymorphism and dynamic binding. Some in-structors feel that the material is too advanced for the first course in object-oriented analysis and design. Others feel that polymorphism and dynamic binding are fundamental concepts of the object-oriented paradigm, and that every student therefore needs to have a basic understanding of the concepts.


1. The source code is written in a language such as COBOL, C, C++, or Java.The source code written by the programmer is compiled (translated) into compiled code by the compiler.Then, the linker combines the compiled code with the run-time routines it needs to form an executable load image.

2. A code artifact.

3. In a well-designed modular information system, functionality coincides with module boundaries. This makes maintenance easier and less fault-prone.

4. The extent to which the methods of the module are strongly related to one another, and weakly related to the methods of the other modules.

5. Different versions of a method are defined, all with the same name.

6. At run-time, the information system decides which version of the polymorphic method to execute.

7. Ease in development.

8. At run-time, we cannot tell which version was executed.

20–1


PROBLEM SOLUTIONS

20.1 Terminology in common use is extremely hard to change.

20.2 Nothing. The object-oriented compiler takes care of it.

20.3 Without dynamic binding, the programmer has to specify which version of the method is to be used at run time. This effectively means that there is no polymor-phism.

20.4 If there is no polymorphism, there is only one version of each method, so there can be no dynamic binding.

20–2

Documents

Front Matter.2