面向对象软件工程

　　 《面向对象软件工程 （英文版）》从面向对象范型出发对软件工程进行重新演绎.全面、系统、清晰地介绍了面向对象软件工程的基本概念、原理、方法和工具.通过实例说明了面向对象软件开发的整个过程。
《面向对象软件工程 （英文版）》分为两个部分：第一部分介绍了面向对象软件工程的基本理论；第二部分以工作流的形式介绍了软件生命周期。
包括面向对象生命周期模型、面向对象分析、面向对象设计。以及面向对象软件的测试和维护。
讨论了文档、维护、复用、可移植性、测试和CASEI具等的重要性。
包括了能力成熟度模型（CMM）和人员能力成熟度模型（P·CMM）的内容。
与语言无关。实例代码对于C++和Java语言背景的读者同样清晰。
包括600余篇当前热点研究文章、经典文献和书籍的参考文献。
包含2个用于说明完整软件生命周期的运行实例，还有7个较小的实例，分别用于突出说明特定的主题。
包括5种类型的习题。分别是概念理解、项目分析、课程设计、论文研读和实例修改。

　　 《面向对象软件工程 （英文版）》是英文影印版系列，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和面向对象范型等。

PARTONE INTRODUCTION TO OBJECT-ORIENTED SOFTwARE ENGINEERING l
Chapter l The Scope of object-Oriented Software Engineering
学习目标
1.1Historical Aspects
1.2Economic Aspects
1.3Maintenance Aspects
1.3.1The Modern View of Maintenance9
1.3.2 The Importance of Post-delivery Maintenance
1.4Requirements.Analysis.and Design Aspects
1.5 Team Development Aspects
1.6Why There Is No Planning Phase
1.7Why There Is No Testing Phase
1.8Why There Is No Documentation Phase
1.9The Obiect-Oriented Paradigm
1.10Terminology
1.11Ethical Issues
Chapter Review
For Further Reading
Key Terms
习题
References
Chapter 2 Software Life.Cycle Models
学习目标
2.1Software Development in Theory
2.2Winburg Mini Case Study
2.3Lessons of the Winburg Mini Case Study
2.4Teal Tractors Mini Case Study
2.5Iteration and Incrementation
2.6Winburg Mini Case Study Revisited
2.7Risks and Other Aspects of Iteration and lncrementation
2.8Managing Iteration and Incrementation
2.90ther Life—Cycle Models
2.9.1 Code.and.Fix Life-Cycle ModeI
2.9.2Waterfatf Life-Cycle Modef
2.9.3Rapid-Prototyping Life-cycle Modef 50
2.9.4Open-Source Life-Cyle Model
2.9.5Agile Processes
2.9 6Synchronize.and.Stabilize Life-Cycle Model
2.9.7Spiraf Life-Cycle Modef
2.10Comparison of Life—Cycle Models Chapter Review For Further Reading Key Terms
习题
References
Chapter 3 The Software Process
学习目标
3.1The Unified Process
3.2Iteration and Incrementation
3.3The Requirements Wbrkflow
3.4The Analysis workflow
3.SThe Design Workflow
3.6The Implementation Workflow
3.7The Test Workflow 78
3.7.1Requirements Artfacts
3.7.2Analysis Artifacts
3.7.3Design Artifacts
3.7.4Implementation Artifacts
3.8Postdelivery Maintenance
3.9Retirement
3.10The Phases of the Unifled Process
3.10.1The Inception Phase
3.10.2The Elaboration Phase
3.10.3 The Construction Phase
3.10.4The Transition Phase
3.110ne-versus Tw0.Dimensional Life-Cycle Models
3.12Improving the Software Process
3.13Capability Maturity Models
……
PART TWO THE WORKFLOWS OF THE SOFTWARE LIFE CYCLE

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 of the product itself, such as its size or its reliability. Others are process metrics used by the developers to deduce information about the software process. A typical metric of this kind is the efficiency of fault detection during development,that is, the ratio of the number of faults detected during development to the total number of faults detected in the product over its lifetime.
……

　　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 changeI switched the order of the two topics in the title of the textbook I wrote in 2000and 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 languageand 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.