软件工程面向对象传统的方法第八版stephen著习题答案.pdf-资料库

c90bdc9e-bd16-49c2-853d-871185a5acf2.pdf-第1页.png

第1页 / 共283页

c90bdc9e-bd16-49c2-853d-871185a5acf2.pdf-第2页.png

第2页 / 共283页

c90bdc9e-bd16-49c2-853d-871185a5acf2.pdf-第3页.png

第3页 / 共283页

c90bdc9e-bd16-49c2-853d-871185a5acf2.pdf-第4页.png

第4页 / 共283页

c90bdc9e-bd16-49c2-853d-871185a5acf2.pdf-第5页.png

第5页 / 共283页

c90bdc9e-bd16-49c2-853d-871185a5acf2.pdf-第6页.png

第6页 / 共283页

c90bdc9e-bd16-49c2-853d-871185a5acf2.pdf-第7页.png

第7页 / 共283页

c90bdc9e-bd16-49c2-853d-871185a5acf2.pdf-第8页.png

第8页 / 共283页

i Instructor’s Solutions Manual to accompany OBJECT-ORIENTED AND CLASSICAL SOFTWARE ENGINEERING Seventh Edition Stephen R. Schach Vanderbilt University Prepared by Stephen R. Schach Vanderbilt University Kristin C. Irwin Lauren S. Ryder McGraw-Hill 1221 Avenue of the Americas New York, NY 10020

ii Instructor’s Solutions Manual to accompany OBJECT-ORIENTED AND CLASSICAL SOFT- WARE ENGINEERING, SEVENTH EDITION by Stephen R. Schach. Copyright © 2007 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, including photo- copying, without permission in writing from the publisher, except for classroom use for instruc- tors using OBJECT-ORIENTED AND CLASSICAL SOFTWARE ENGINEERING, SEVENTH EDITION as a course text, and provided that the reproduced materials are retrieved by the in- structor and either permanently 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 information about manufacturers and their products mentioned in this book. ISBN: Manufactured in the United States of America

To our families iii

iv THE FOLLOWING ARE REGISTERED TRADEMARKS: IBM Rational Rose Microsoft Visual C++ UNIX

v Preface Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 CONTENTS .................................................................................................. vi The Scope of Software Engineering ......................................1–1 Software Life-Cycle Models ..................................................2–1 The Software Process.............................................................3–1 Teams ....................................................................................4–1 The Tools of the Trade...........................................................5–1 Testing....................................................................................6–1 From Modules to Objects.......................................................7–1 Reusability and Portability.....................................................8–1 Planning and Estimating ........................................................9–1 Requirements .......................................................................10–1 Classical Analysis ................................................................11–1 Object-Oriented Analysis.....................................................12–1 Design ..................................................................................13–1 Implementation ....................................................................14–1 Postdelivery Maintenance ....................................................15–1 More on UML ......................................................................16–1

vi TO THE INSTRUCTOR Object-Oriented and Classical Software Engineering can be used as a textbook at two different levels. The material can be used for a junior/senior level course, or for a first year graduate-level course. Furthermore, it can be used for a one-semester or a two-semester software engineering course sequence. Not only does the instructor have the freedom to present the lecture material at the appropriate level for the class, but the wide variety of problems allows the instructor to focus the course in a way that will achieve the 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 Object-Oriented and Classical Software Engineering, namely, teaching suggestions for that specific chapter and solutions to the problems and term project component for that chapter. ABOUT THE PROBLEM SETS There are five different types of problems: exercises, the running object-oriented analysis and design projects, the term project, case study problems, and readings in software engineering. The exercises are of different types, including essay-type problems, numerical problems, and prob- lems that essentially require nothing more than understanding what was taught in class. In my opinion, it is most important that students get experience working in teams developing a software product from beginning to end. In the software industry, almost all products are devel- oped 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.

vii An important issue is whether to assign students to teams or allow students to choose their own. Until recently, I used to let my students choose their own teams. A few years ago, however, I realized that most teams seem to be composed of students of roughly equal ability. Conse- quently, the brighter students did not obtain experience in working with less competent people, experience they would need in the real world; and the weaker students did not learn from the brighter students. In addition, students from non-English speaking backgrounds tended to form their own teams, thereby missing an opportunity to improve their language skills Accordingly, for the past few years I have assigned students to teams on the basis of alphabetical order of first names, and this has worked extremely well. (Using first names rather than last names almost always results in a more random mix of students.) A difficulty that can arise with teams is that one team member complains that he or she is doing all the work, and that it is unfair that all three team members should get the same grade. To obviate this problem, I give 10 percent of the overall grade for team effort; at the end of the course, the members of each team evaluate the extent to which their fellow team members contributed to the team. For example, if a student feels that a specific member of the team tried his or her utmost to contribute to every assignment, 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, the student would give that team member 0/10 for the team effort grade. The case study problems were included because many instructors feel that beginners can learn more from modifying an existing solution than by struggling to create a new solution from scratch. This approach is particularly appropriate to the study of software engineering; after all, the majority of software professionals modify (maintain) existing products, rather than create (develop) new products. I strongly recommend that the three running object-oriented analysis and design projects be as- signed. When I taught a one-semester software engineering course, I assigned the running object-oriented analysis and design projects as team projects. Now that I teach a two-semester course sequence, I assign them as individual projects in the first semester, and the term project is the group project for the second semester. When teaching undergraduate students, I strongly suggest that most of the exercises be assigned, together with either the term project or the case study problems, depending on the abilities of the students. It would be too much to expect the class to complete both the term project and selected case study problems. The fifth type of problem in the text is based on readings in software engineering. This material is more suitable for graduate students than undergraduates. When teaching graduate students, I assign equal weight to the exercises, object-oriented analysis and design projects, readings, and term project. Of course, it is unreasonable to assign all the exercises and readings as well as the entire term project, so I select from the exercises and readings. At the end of the course, I feel that I have succeeded if the students have learned how to specify, plan, design, implement, maintain, test, and so on, working as a member of a team. The best way

viii I can determine this is to make the course project-oriented. I grade the components of the term project extremely carefully. I experiment with the students’ implementations, ask walkthrough- style questions about their designs, and so on. Students generally enjoy showing off their work, so I organize sessions at which I examine the work of each team in the presence of their class- mates; teams have the option of a private demonstration, of course, but no team has as yet chosen this. The term project has been designed generically. That is to say, it consists of fifteen components that can be applied to any term project of the instructor’s choosing, not just the project in Object- Oriented and Classical Software Engineering, seventh edition. 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 fifteen different items to be handed in on fifteen different occasions usually results in documentation of higher quality than if the specifications, design, implementation, and so on are all handed in at the end of the semester. Finally, it is much easier to grade fifteen small pieces of a term project during the semester than one gargantuan project at a time when there are end-of-semester deadlines to meet. LECTURE OUTLINES Returning to the lecture material, I comfortably cover the entire book in one semester, including time for questions and discussion. When teaching a one-semester course to undergraduates, I do it as follows: Lecture 1 Lectures 2–4 Lectures 5–6 Lectures 7–8 Lecture 9 Lectures 10–11 Lectures 12–14 Lectures 15–17 Lectures 18–19 Lectures 20–23 Lecture 24 Lectures 25–27 Lectures 28–31 Lectures 32–35 Lectures 36–37 Lectures 38–39 Lectures 40–41 Lectures 42–44 Lecture 45 Course objectives, introduction to software engineering teams Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 10 Chapter 11 Midterm examination Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 8 Chapter 9 Course review and wrap-up

资料库

软件工程面向对象传统的方法第八版stephen著习题答案.pdf

相关推荐

课程资源

热门标签

最新资料