基本信息出版社：机械工业出版社
页码：558 页
出版日期：2009年03月
ISBN：7111265262/9787111265269
条形码：9787111265269
版本：第1版
装帧：平装
开本：16
正文语种：英语
丛书名：经典原版书库
图书品牌：华章图书

内容简介 《面向对象软件工程 (英文版)》是英文影印版系列，SteDhen R．Schach：Object．Oriented Software Engineering(ISBN 978—0-07—352333—0) Copyright@2008 by The McGraw—Hill Companies，Inc
Original language published by The McGraw—Hill Companies，Inc．A11 rights reserved-No part of this publication may be reproduced or distributed in any means，or stored in adatabase or retrieval system，without the prior written permission of the publisher．
Authorized English language reprint edition jointly published by McGraw—Hill EducationrAsial Co．and China Machine Press．This edition is authorized for sale in the People's Republic ofChina 0nIu excluding Hong Kong，Macao SARs and Taiwan．Unauthorized export ofthis edition is aviolation 0fthe Copyright Act．Violation ofthis Law is subject to Civil and Criminal Penalties．
作者简介 Stephen R-Schach，1972年获魏兹曼科学院物理学理科硕士学位。1973年获开普敦大学应用数学博士学位，目前任教于美国范德比尔特大学计算机科学系。他著有多部有关软件工程、面向对象软件工程，面向对象系统分析与设计的教材。他还在国际上广泛讲授软件工程方面的课程，包括复用、CASE和面向对象范型等。
编辑推荐 《面向对象软件工程 (英文版)》从面向对象范型出发对软件工程进行重新演绎.全面、系统、清晰地介绍了面向对象软件工程的基本概念、原理、方法和工具.通过实例说明了面向对象软件开发的整个过程。
《面向对象软件工程 (英文版)》分为两个部分：第一部分介绍了面向对象软件工程的基本理论；第二部分以工作流的形式介绍了软件生命周期。
包括面向对象生命周期模型、面向对象分析、面向对象设计。以及面向对象软件的测试和维护。
讨论了文档、维护、复用、可移植性、测试和CASEI具等的重要性。
包括了能力成熟度模型（CMM）和人员能力成熟度模型（PCMM）的内容。
与语言无关。实例代码对于C++和Java语言背景的读者同样清晰。
包括600余篇当前热点研究文章、经典文献和书籍的参考文献。
包含2个用于说明完整软件生命周期的运行实例，还有7个较小的实例，分别用于突出说明特定的主题。基于统一过程、Java和C++语言的完整源码可从作者网站（www.mhhe.com/schach）下载。
包括5种类型的习题。分别是概念理解、项目分析、课程设计、论文研读和实例修改。
目录
PART ONE
INTRODUCTION TO OBJECTORIENTED SOFTWARE
ENGINEERING
Chapter 1
The Scope of Object-Oriented Software
Engineering
学习目标
1.1 Historical Aspects
1.2 Economic Aspects
1.3 Maintenance Aspects
1.3.1 The Modern View of Maintenance
1.3.2 The Importance of Postdelivery Maintenance
1.4 Requirements, Analysis, and Design Aspects
1.S Team Development Aspects
1.6 Why There Is No Planning Phase
1.7 Why There Is No Testing Phase
1.8 Why There Is No Documentation Phase
1.9 The Object-Oriented Paradigm
1.10 Terminology
1.11 Ethical Issues
Chapter Review
For Further Reading
Key Terms
习题
References

Chapter 2
Software Life-Cycle Models
学习目标
2.1 Software Development in Theory
2.2 Winburg MiniCase Study
2.3 Lessons of the Winburg Mini Case Study
2.4 Teal Tractors Mini Case Study
2.5 Iteration and Incrementation
2.6 Winburg Mini Case Study Revisited
2.7 Risks and Other Aspects of Iteration and Incrementation
2.8 Managing Iteration and Incrementation
2.9 Other Life-Cycle Models
2.9.1 Code-and-Fix Life-Cycle Model
2.9.2 Waterfall Life-Cycle Model
2.9.3 Rapid-Prototyping Life-Cycle Model
2.9.4 Open-Source Life-Cycle Model
2.9.5 Agile Processes
2.9.6 Synchronize-and-Stabilize Life-Cycle Model
2.9.7 Spiral Life-Cycle Model
2.10 Comparison of Life-CycleModels
Chapter Review
For Further Reading
Key Terms
习题
References

Chapter 3
The Software Process
学习目标
3.1 The Unified Process
3.2 Iteration and Incrementation
3.3 The Requirements Workflow
3.4 The Analysis Workflow
3.5 The Design Workflow
3.6 The Implementation Workflow
3.7 The Test Workflow
3.7.1 Requirements Artifacts
3.7.2 Analysis Artifacts
3.7.3 DesignArtifacts
3.7.4 Implementation Artifacts
3.8 Postdelivery Maintenance
3.9 Retirement
3.10 The Phases of the Unified Process
3.10.1 The Inception Phase
3.10.2 The Elaboration Phase
3.10.3 The Construction Phase
3.10.4 The Transition Phase
3.11 One-versus Two-Dimensional Life-Cycle Models
3.12 Improving the Software Process
3.13 Capability Maturity Models
3.14 Other Software Process Improvement Initiatives
3.15 Costs and Benefits of Software Process Improvement
Chapter Review
For Further Reading
Key Terms
习题
References

Chapter 4
Teams
学习目标
4.1 Team Organization
4.2 Democratic Team Approach
4.2.1 Analysis of the Democratic Team Approach
4.3 Chief Programmer Team Approach
4.3.1 The New York Times Project
4.3.2 Impracticality of the Chief Programmer Team Approach
4.4 Beyond Chief Programmer and Democratic Teams
4.5 Synchronize-and-Stabilize Teams
4.6 Teams for Agile Processes
4.7 Open-Source Programming Teams
4.8 People Capability Maturity Model
4.9 Choosing an Appropriate Team Organization
Chapter Review
For Further Reading
Key Terms
Problems
习题

Chapter 5
TheTools of TheTrade
学习目标
5.1 Stepwise Refinement
5.1.1 Stepwise Refinement Mini Case Study
5.2 Cost-Benefit Analysis
5.3 Software Metrics
5.4 CASE
5.5 Taxonomy of CASE
5.6 Scope of CASE
5.7 Software Versions
5.7.1 Revisions
5.7.2 Variations
5.8 Configuration Control
5.8.1 Configuration Control during
Postdelivery Maintenance
5.8.2 Baselines
5.8.3 Configuration Control during Development
5.9 Build Tools
S.10 Productivity Gains with CASE Technology
Chapter Review
For Further Reading
Key Terms
习题
References

Chapter 6
Testing
学习目标
6.1 Quality Issues
6.1.1 Software Quality Assurance
6.1.2 Managerial lndependence
6.2 Non-Execution-Based Testing
6.2.1 Walkthroughs
6.2.2 Managing Walkthroughs
6.2.3 Inspections
6.2.4 Comparison of Inspections and Walkthroughs
6.2.5 Strengths and Weaknesses of Reviews
6.2.6 Metrics for Inspections
6.3 Execution-Based Testing
6.4 What Should Be Tested？
6.4.1 Utility
6.4.2 Reliability
6.4.3 Robustness
6.4.4 Performance
6.4.5 Correctness
6.5 Testing versus Correctness Proofs
6.5.1 Example of a Correctness Proof
6.5.2 Correctness Proof Mini Case Study
6.5.3 Correcmess Proofs and Software Engineering
6.6 Who Should Perform Execution-Based Testing？
6.7 When Testing Stops
Chapter Review
ForFurther Reading
Key Terms
习题
References

Chapter 7
From Modules to Objects
学习目标
7.1 What lsaModule？
7.2 Cohesion
7.2.1 Coincidental Cohesion
7.2.2 Logical Cohesion
7.2.3 Temporal Cohesion
7.2.4 Procedural Cohesion
7.2.5 Communicational Cohesion
7.2.6 Functional Cohesion
7.2.7 Informational Cohesion
7.2.8 Cohesion Example
7.3 Coupling
7.3.1 Content Coupling
7.3.2 Common Couping
7.3.3 Control Coupling
7.3.4 Stamp Coupling
7.3.5 Data Coupling
7.3.6 Coupling Example
7.3.7 The hnportance of Coupling
7.4 Data Encapsulation
7.4.1 Data Encapsulation and Development
7.4.2 Data Encapsulation and Maintenance
7.5 Abstract Data Types
7.6 Information Hiding
7.7 Objects
7.8 Inheritance, Polymorphism, and Dynamic Binding
7.9 The Object-Oriented Paradigm
Chapter Review
For Further Reading
Key Terms
习题
References

Chapter 8
Reusability and Portability
学习目标
8.1 Reuse Concepts
8.2 Impediments to Reuse
8.3 ReuseCase Studies
8.3.1 Raytheon Missile Svstems Division
8.3.2 European Space Agency
8.4 Objects and Reuse
8.5 Reuse during Design and Implementation
8.5.1 Design Reuse
8.5.2 Application Frameworks
8.5.3 Design Patterns
8.5.4 Software Architecture
8.5.5 Component-Based Software Engineering
8.6 More on Design Patterns
8.6.1 FLIC Mini Case Studv
8.6.2 Adapter Design Pattern
8.6.3 Bridge Design Pattern
8.6.4 lterator Design Pattern
8.6.5 Abstract Factoo' Design Pattern
8.7 Categories of Design Patterns
8.8 Strengths and Weaknesses of Design Patterns
8.9 Reuse and Postdelivery Maintenance
8.10 Portability
8.10.1 Hardware Incompatibilities
8.10.2 Operating System Incompatibilities
8.10.3 Numerical Softare Incompatibilities
8.10.4 Compiler Incompatibilities
8.11 Why Portability？
8.12 Techniques for Achieving Portability
8.12.1 Portable System Software
8.12.2 Portable Application Software
8.12.3 Portable Data
8.12.4 Web-BasedApplications
Chapter Review
For Further Reading
Key Terms
习题
References

Chapter 9
Planning and Estimating
学习目标
9.1 Planning and the Software Process
9.2 Estimating Duration and Cost
9.2.1 Metrics for the Size of a Product
9.2.2 Techniques of Cost Estimation
9.2.3 Intermediate COCOMO
9.2.4 COCOMO II
9.2.5 Tracking Duration and
Estimates
9.3 Estimation Issues
9.4 Components of a Software Project Management Plan
9.5 Software Project Management Plan Framework
9.6 IEEE Software Project Management Plan
9.7 Planning Testing
9.8 Training Requirements
9.9 Documentation Standards
9.10 CASE Tools for Planning and Estimating
9.11 Testing the Software Project Management Plan
Chapter Review
For Further Reading
Key Terms
习题
References
PART TWO
THE WORKFLOWS OF THE
SOFTWARE LIFE CYCLE

Chapter 10
The Requirements Workflow
学习目标
10.1 Determining What the Client Needs
10.2 Overview of the Requirements Workflow
10.3 Understanding the Domain
10.4 The Business Model
10.4.1 Interviewing
10.4.2 OtherTechniques
10.4.3 Use Cases
10.5 Initial Requirements
10.6 Initial Understanding of the Domain: The MSG Foundation Case Study
10.7 Initial Business Model: The MSG Foundation Case Study
10.8 Initial Requirements: The MSG Foundation Case Study
10.9 Continuing the Requirements Workflow:The MSG Foundation Case Study
10.10 Revising the Requirements: The MSG Foundation Case Study
10.11 The Test Workflow: The MSG Foundation Case Study
10.12 What Are Object-Oriented Requirements？
10.13 Rapid Prototyping
10.14 Human Factors
10.15 Reusing the Rapid Prototype
10.16 CASE Tools for the Requirements Workflow
10.17 Metrics for the Requirements Workflow
10.18 Challenges of the Requirements Workflow
Chapter Review
For Further Reading
Key Terms
Case Study Key Terms
习题
References

Chapter 11
The Analysis Workflow
学习目标
11.1 The Specification Document
11.2 Informal Specifications
11.3 Correctness Proof Mini Case Study Redux

Chapter 12 The Design Workflow
Chapter 14 Postdelivery Maintenance
Chapter 15 More onUML
Bibliography
Appendix A Term Project：Osric’s 0mce Appliances
and Deeor
Appendix B
Software Engineering Resources
Appendix C
The Requirements Workflow：The MSG
Foundation Case Study
Appendix D
The Analysis Workflow：The MSG
Foundation Case Study
Appendix E
Software Project Management Plan：
The MSG Foundation Case Study
Appendix F
The Design Workflow：The MSG
Foundation Case Study
Appendix G
The Implementation蚪brkflow：The MSG
Foondation Case Study fC++Versionl
Appendix H
The Implementation Workfluw：The MSG
Foundation Case Study fJava Version)
Appendix I
The Test Workflow：The MSG Foundation
Case Study
……
序言 The wheel has turned full circle.
In 1988, I wrote a textbook entitled Software Engineering. Virtually the only mention of the object-oriented paradigm in that book was one section that described object-oriented design.
By 1994, the object-oriented paradigm was starting to gain acceptance in the software industry, so I wrote a textbook called Classical and Object-Oriented Software Engineering. Six years later, however, the object-oriented paradigm had become more important than the classical paradigm. To reflect this change,I switched the order of the two topics in the title of the textbook I wrote in 2000,and called it Object-Oriented and Classical Software Engineering.
Nowadays, use of the classical paradigm is largely restricted to maintaining legacy software. Students learn C++ or Java as their first programming language,and object-oriented languages are used in subsequent computer science and computer engineering courses. Students expect that, when they graduate, they will work for a company that uses the object-oriented paradigm. The object-oriented paradigm has all but squeezed out the classical paradigm. And that is why I have written a textbook entitled Object-Oriented Software Engineering.
文摘 As explained in Section 3.13, without measurements （or metrics） it is impossible to dettect problems early in the software process, before they get out of hand. In this way, metrics can serve as an early warning system for potential problems. A wide variety of metrics can be used. For example, lines of code （LOC） is one way of measuring the size of a product （see Section 9.2.l）. If LOC measurements are taken at regular intervals, they provide a measure of how fast the project is progressing. In addition, the number of faults per 1000 lines of code is a measure of software quality. After all, it is of little use if a programmer consistently turns out 2000 lines of code a month but half of them have to be thrown away because they are unacceptable. Accordingly, LOC in isolation is not a very meaningful metric.
Once the product has been installed on the client's computer, a metric such as mean time between failures provides management an indication of its reliability. If a certain product fails every other day, its quality is clearly lower than that of a similar product that on average runs for 9 months without a failure.
Certain metrics can be applied throughout the software process. For example, for each workflow, we can measure the effort in person-months （I person-month is the-amount of work done by one person in 1 month）. Staff turnover is another important metric. High turnover adversely affects current projects because it takes time for a new employee to learn the relevant facts about the project （see Section 4.1）. In addition, new employees may have to be trained in aspects of the software process; if new employees are less educated in software engineering than the individuals they replace, then the process as a whole may suffer. Of course, cost is an essential metric that must also be monitored continually throughout the entire process.
A number of different metrics are described in this book. Some are product metrics;they measure some aspect
……