An introduction to object-oriented systems analysis and design with UML and the unified process

1、Instructors Manual to accompany An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process Stephen R. Schach Vanderbilt University Prepared by Stephen R. Schach Vanderbilt University Kristin C. Irwin Vanderbilt University Lauren S. Schach Macquarie University Dav

2、id M. Schach Northwestern University McGraw-Hill 1221 Avenue of the Americas New York, NY 10020 ii Instructors 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

3、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 INTRO

4、DUCTION 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-Hil

5、l, 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 an

6、y 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 manufactur

7、ers and their products mentioned in this book. ISBN: Manufactured in the United States of America iii To our families iv The following are registered trademarks: Linux PowerPoint Rational Rose v CONTENTS To the Instructor.vi Chapter 1.Introduction to Information Systems.11 Chapter 2.How Information

8、Systems are Developed.21 Chapter 3.The Object-Oriented Paradigm.31 Chapter 4.The Requirements Workflow I .41 Chapter 5.The Requirements Workflow II.51 Chapter 6.The Object-Oriented Analysis Workflow I.61 Chapter 7.The Object-Oriented Analysis Workflow II.71 Chapter 8.The Object-Oriented Design Workf

9、low.81 Chapter 9.The Workflows and Phases of the Unified Process.91 Chapter 10. More on UML.101 Chapter 11. CASE.111 Chapter 12. Teams.121 Chapter 13. Testing.131 Chapter 14. Management Issues.141 Chapter 15. Planning and Estimating.151 Chapter 16. Maintenance.161 Chapter 17. User-Interface Design.1

10、71 Chapter 18. Web-Based Information Systems.181 Chapter 19. Database Management Systems.191 Chapter 20. Technical Topics.201 vi 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

11、 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 INSTRUCTORS MANUAL IS ORGANIZED This preface contains teaching suggestions relating to the book as a whole. Each c

12、hapter 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 p

13、rojects, 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 pr

14、oblems, 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 studen

15、t 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

16、 be assigned the term project, a larger and more complex information system than the other two. vii 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

17、 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 stud

18、ents are considerate enough to ensure that the class size will always be a multiple of threethere 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 usu

19、ally 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

20、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 cant get along with one another” variety. On the other hand, there is also the fairness aspect. My experience is that th

21、e 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 cla

22、ss 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

23、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 assignment, then the student would give th

24、at 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 f

25、eel that beginners can learn more from modifying or extending an existing solution than by struggling 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) ex

26、isting information systems, rather than create (develop) new information 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,

27、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. viii I consider the most important problems to be 5.7 and 7.10, followed by 5.5, 5.6,

28、 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 appl

29、ied to any term project of the instructors 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

30、, 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 o

31、f the semester. Finally, it is much easier to grade 12 smaller pieces of a term project during the semester than one gargan- tuan 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

32、 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,

33、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 coll

34、ege computersit 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

35、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 . In addition, future versions of this book may be sold with an ArgoUML CD (at no additional cost). ix

36、 LECTURE SCHEDULES Returning to the lecture material, the entire book can be comfortably covered in one semes- ter, including time for questions and discussion. Lecture 1Course objectives, introduction to project teams Lectures 23Chapter 1 Lectures 45Chapter 2 Lectures 67Chapter 3 Lecture 8Review of

37、 Part 1; introduction to the CASE tool to be used by the class for the term project Lectures 911Chapter 4 Lectures 1213Chapter 5 Lectures 1416Chapter 6 Lectures 1718Chapter 7 Lectures 1920Chapter 8 Lectures 2122Chapter 9 Lectures 2324Chapter 10 Lecture 25Review of Part 2 Lecture 26Midterm examinatio

38、n Lectures 2728Chapter 11 Lectures 2930Chapter 12 Lectures 3132Chapter 13 Lectures 3334Chapter 14 Lectures 3536Chapter 15 Lectures 3738Chapter 16 Lectures 3940Chapter 17 Lecture 41Chapter 18 Lecture 42Chapter 19 Lectures 4344Chapter 20 Lecture 45Course review and wrap-up When this book is used for a

39、 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

40、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

41、 can downloaded from the Web site for this book, In fact, it does not really matter how An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process is taughtall that is really needed is enthusi- asm. I hope that you will have as much fun and satisfaction teaching

42、from An Introduction to x Object-Oriented Systems Analysis and Design with UML and the Unified Process as I have had in writing the book. Stephen R. Schach Instructors Manual for Systems Analysis and Design by SchachChapter 1 11 CHAPTER 1 INTRODUCTION TO INFORMATION SYSTEMS From the start of the cou

43、rse, 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 n

44、ot 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 tra- ditional 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 QUESTION

45、S FOR CHAPTER 1 1.Custom information systems; commercial off-the-shelf packages. 2An 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; imp

46、lementation; 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:

47、 Why it was retired, when, and by whom. 5.Requirements phase: The clients 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 w

48、ill be built. Implementation phase: The information system is programmed. Maintenance phase: The information system is modified. Instructors Manual for Systems Analysis and Design by SchachChapter 1 12 Retirement phase: The information system is decommissioned. 6.Planning needs to be done at the beg

49、inning 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 requireme

50、nts 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 i

51、nformation 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 g

52、rades. The owner of a small business writes his or her own packages for inventory and ac- counts payable. 1.2The developer fully understands the clients requirements. Also, the specifications will be unambiguously understood. In fact, communication problems of all kinds are minimized. 1.3The objecti

53、ves 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 cli- ents needs, whereas the activities of the analysis phase consist of drawing up a pre- cise statement of exactly what the information syst

54、em is to do, followed by the drawing up of a detailed plan for doing it. 1.4No. Testing must never be a separate phase, but an intrinsic and essential co-activity of all phases. 1.5The task of the systems analyst is to work with the client to find out what the clients real needs are. Accordingly, Mo

55、rgan Cuttler is responsible for the delivery of the Instructors Manual for Systems Analysis and Design by SchachChapter 1 13 56,943 pairs of boots. With regard to prevention, there are three things that Morgan should have done. First, he should have examined Jethros formula more carefully. Second, t

56、he project management plan should have included specific tests for the part of the information system that implemented Jethros 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

57、 intervention by Jethro was required. 1.6Try 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, bu

58、t rather provide data such as hardware invoices and software development schedules showing the unreasonableness of the total request. 1.7A wide variety of definitions are applicable, including those incorporating concepts like “organized,” “unified,” or “whole.” 1.8If an information system performs

59、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 disa

60、p- peared. 1.9Maintenance 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 me