基本信息·出版社：机械工业出版社 ·页码：350 页 ·出版日期：2009年02月 ·ISBN：711125502X/9787111255024 ·条形码：9787111255024 ·版本：第1版 · ...
| 商家名称 |
信用等级 |
购买信息 |
订购本书 |
|
|
 |
面向对象软件工程 |
 |
|
|
面向对象软件工程 |
|
基本信息·出版社：机械工业出版社
·页码：350 页
·出版日期：2009年02月
·ISBN：711125502X/9787111255024
·条形码：9787111255024
·版本：第1版
·装帧：平装
·开本：16
·正文语种：中文
·丛书名：计算机科学丛书
·外文书名：Object-oriented software engineering
·图书品牌：华章图书
内容简介 《面向对象软件工程》从面向对象范型出发对软件工程进行重新演绎，全面、系统、清晰地介绍了面向对象软件工程的基本概念、原理、方法和工具，通过实例说明了面向对象软件开发的整个过程。《面向对象软件工程》分为两个部分：第一部分介绍了面向对象软件工程的基本理论；第二部分以工作流的形式介绍了软件生命周期。
作者简介 Stephen R．Schach，1972年获魏兹曼科学院理科硕士学位，1973年获开普敦大学应用数学博士学位，目前任教于美国范德比尔特大学计算机科学系。他著有多部有关软件工程、面向对象软件工程、面向对象系统分析与设计的教材。他还在国际上广泛讲授软件工程方面的课程，包括复用、CASE和面向对象范型等。
编辑推荐 《面向对象软件工程》特色
●包括面向对象生命周期模型、面向对象分析、面向对象设计，以及面向对象软件的测试和维护。
●讨论了文档、维护、复用、可移植性、测试和CASE工具等的重要性。
●包括了能力成熟度模型（CMM）和人员能力成熟度模型（P-CMM）的内容。
●与语言无关。实例代码对于C++和Java语言背景的读者同样清晰。
●包括600余篇当前热点研究文章、经典文献和书籍的参考文献。
●包含2个用于说明完整软件生命周期的运行实例，还有7个较小的实例，分别用于突出说明特定的主题。基于统一过程、Java和C++语言的完整源码可从作者网站（www.mhhe.com/schach）下载。
●包括5种类型的习题，分别是概念理解、项目分析、课程设计、论文研读和实例修改。
目录 出版者的话
译者序
前言
第一部分 面向对象软件工程简介
第1章 面向对象软件工程的范畴3
1.1 历史方面4
1.2 经济方面6
1.3 维护方面6
1.3.1 现代软件维护观点8
1.3.2 交付后维护的重要性9
1.4 需求、分析和设计方面10
1.5 团队开发11
1.6 没有计划阶段的原因12
1.7 没有测试阶段的原因12
1.8 没有文档阶段的原因13
1.9 面向对象范型13
1.10 术语15
1.11 道德规范问题17
本章回顾18
延伸阅读材料18
习题19
参考文献20
第2章 软件生命周期模型23
2.1 理想软件开发23
2.2 Winburg小型案例研究23
2.3 Winburg小型案例研究经验25
2.4 TealTractors公司小型案例研究25
2.5 迭代与增量26
2.6 Winburg小型案例研究再探28
2.7 迭代和增量的风险及其他29
2.8 管理迭代与增量31
2.9 其他生命周期模型31
2.9.1 边写边改生命周期模型32
2.9.2 瀑布生命周期模型32
2.9.3 快速原型生命周期模型33
2.9.4 开源生命周期模型34
2.9.5 敏捷过程35
2.9.6 同步稳定生命周期模型37
2.9.7 螺旋生命周期模型38
2.1 0生命周期模型的比较40
本章回顾41
延伸阅读材料41
习题42
参考文献43
第3章 软件过程46
3.1 统一过程47
3.2 迭代与增量48
3.3 需求工作流49
3.4 分析工作流50
3.5 设计工作流51
3.6 实现工作流52
3.7 测试工作流52
3.7.1 需求制品53
3.7.2 分析制品53
3.7.3 设计制品53
3.7.4 实现制品53
3.8 交付后维护54
3.9 退役55
3.10 统一过程的阶段55
3.10.1 初始阶段56
3.10.2 细化阶段57
3.10.3 构造阶段58
3.10.4 移交阶段58
3.11 一维与二维生命周期模型对比59
3.12 改进软件过程60
3.13 能力成熟度模型60
3.14 软件过程改进的其他方面62
3.15 软件过程改进的成本与收益62
本章回顾64
延伸阅读材料64
习题65
参考文献65
第4章 软件团队68
4.1 团队组织68
4.2 民主团队方式69
4.3 主程序员团队方式70
4.3.1 《纽约时报》项目71
4.3.2 主程序员团队方式的不切实际性72
4.4 超越主程序员和民主团队72
4.5 同步-稳定团队73
4.6 敏捷过程团队74
4.7 开源编程团队74
4.8 人力资源能力成熟度模型75
4.9 选择合适的团队组织75
本章回顾76
延伸阅读材料76
习题77
参考文献77
第5章 软件工程工具79
5.1 逐步求精79
5.2 成本-效益分析法82
5.3 软件度量83
5.4 CASE84
5.5 CASE的分类85
5.6 CASE的范围86
5.7 软件版本88
5.7.1 修订版89
5.7.2 变体89
5.8 配置控制89
5.8.1 交付后维护期间的配置控制91
5.8.2 基线91
5.8.3 产品开发过程中的配置控制91
5.9 建造工具92
5.10 使用CASE技术提高生产力93
本章回顾93
延伸阅读材料93
习题94
参考文献95
第6章 测试97
6.1 质量问题97
6.1.1 软件质量保证98
6.1.2 管理独立性98
6.2 基于非执行的测试99
6.2.1 走查99
6.2.2 管理走查100
6.2.3 审查100
6.2.4 走查和审查的对比102
6.2.5 评审的优缺点102
6.2.6 审查的度量方法102
6.3 基于执行的测试103
6.4 应该测试什么103
6.4.1 实用性104
6.4.2 可靠性104
6.4.3 健壮性104
6.4.4 性能105
6.4.5 正确性105
6.5 测试与正确性证明106
6.5.1 正确性证明的例子106
6.5.2 正确性证明小型实例研究108
6.5.3 正确性证明和软件工程109
6.6 由谁来完成基于执行的测试111
6.7 测试何时停止112
本章回顾112
延伸阅读材料112
习题113
参考文献114
第7章从模块到对象117
7.1 什么是模块117
7.2 内聚119
7.2.1 偶然性内聚119
7.2.2 逻辑性内聚120
7.2.3 时间性内聚120
7.2.4 过程性内聚121
7.2.5 通信性内聚121
7.2.6 功能性内聚121
7.2.7 信息性内聚121
7.2.8 内聚示例122
7.3 耦合122
7.3.1 内容耦合122
7.3.2 公共耦合123
7.3.3 控制耦合124
7.3.4 印记耦合125
7.3.5 数据耦合125
7.3.6 耦合示例126
7.3.7 耦合的重要性126
7.4 数据封装127
7.4.1 数据封装和开发128
7.4.2 数据封装和维护129
7.5 抽象数据类型133
7.6 信息隐藏134
7.7 对象135
7.8 继承、多态和动态绑定137
7.9 面向对象范型139
本章回顾140
延伸阅读材料141
习题141
参考文献142
第8章 可复用性和可移植性144
8.1 复用的概念145
8.2 复用的障碍146
8.3 复用案例研究147
8.3.1 雷锡恩导弹系统部门147
8.3.2 欧洲航天局148
8.4 对象和复用149
8.5 在设计和实现过程中的复用149
8.5.1 设计复用149
8.5.2 应用架构150
8.5.3 设计模式151
8.5.4 软件体系结构152
8.5.5 基于组件的软件工程153
8.6 关于设计模式的更多内容153
8.6.1 FLIC小型案例研究153
8.6.2 适配器设计模式154
8.6.3 桥接设计模式154
8.6.4 迭代器设计模式155
8.6.5 抽象工厂设计模式156
8.7 设计模式的范畴159
8.8 设计模式的优点和缺点159
8.9 复用和交付后的维护160
8.10 可移植性161
8.10.1 硬件的不兼容性161
8.10.2 操作系统的不兼容性162
8.10.3 数值计算软件的不兼容性162
8.10.4 编译器的不兼容性163
8.11 为什么需要可移植性165
8.12实现可移植性的技术166
8.12.1 可移植的系统软件166
8.12.2 可移植的应用软件166
8.12.3 可移植数据167
8.12.4 基于Web的应用程序167
本章回顾168
延伸阅读材料168
习题169
参考文献170
第9章计划与估算174
9.1 计划活动与软件过程174
9.2 估算项目周期和成本175
9.2.1 产品规模的衡量标准176
9.2.2 成本估算技术178
9.2.3 中级COCOMO180
9.2.4 COCOMOII182
9.2.5 跟踪周期和成本估算183
9.3 估算探讨183
9.4 软件项目管理计划的组成184
9.5 软件项目管理计划框架185
9.6 IEEE软件项目管理计划186
9.7 对测试进行计划188
9.8 培训需求188
9.9 文档标准189
9.1 0计划和估算的CASE工具189
9.1 1测试软件项目管理计划190
本章回顾190
延伸阅读材料190
习题191
参考文献192
第二部分 软件生命周期工作流
第10章需求工作流196
10.1 确定什么是客户所需196
10.2 需求工作流概述197
10.3 域的理解197
10.4 业务模型198
10.4.1 访谈198
10.4.2 其他技术198
10.4.3 用例199
10.5 初始需求200
10.6 对应用域的初始理解：MSG基金会实例研究200
10.7 初始业务模型：MSG基金会实例研究202
10.8 初始需求：MSG基金会实例研究204
10.9 需求工作流继续：MSG基金会实例研究205
10.1 0修订需求：MSG基金会实例研究206
10.1 1测试工作流：MSG基金会实例研究211
10.1 2什么是面向对象的需求217
10.1 3快速原型218
10.1 4人为因素218
10.1 5复用快速原型219
10.1 6需求工作流的CASE工具220
10.1 7需求工作流的度量220
10.1 8需求工作流的挑战220
本章回顾221
延伸阅读材料222
习题222
参考文献223
第11章 分析工作流224
11.1 规格说明文档224
11.2 非形式化规格说明225
11.3 小型案例研究的正确性证明回顾226
11.4 分析工作流227
11.5 实体类的提取228
11.6 电梯问题228
11.7 功能建模：电梯问题案例研究229
11.8 实体类建模：电梯问题案例研究230
11.8.1 名词提取230
11.8.2 CRC卡片232
11.9 动态建模：电梯问题案例研究233
11.10 测试工作流：电梯问题案例研究235
11.11 提取边界类和控制类237
11.12 初始功能建模：MSG基金会案例研究238
11.13 初始类图：MSG基金会案例研究239
11.14 初始动态建模:MSG基金会案例研究240
11.15 修订实体类：MSG基金会案例研究242
11.16 提取边界类：MSG基金会案例研究243
11.17 提取控制类：MSG基金会案例研究243
11.18 用例实现：MSG基金会案例研究243
11.18.1 EstimateFundsAvailableforWeek用例244
11.18.2 ManageanAsset用例248
11.18.3 UpdateEstimatedAnnualOperatingExpenses用例251
11.18.4 ProduceaReport用例252
11.19 类图增量：MSG基金会案例研究256
11.20 软件项目管理计划：MSG基金会案例研究257
11.21 测试工作流：MSG基金会案例研究257
11.22 统一过程中的规格说明文档257
11.23 更多关于参与者和用例的内容258
11.24 支持分析工作流的CASE工具259
11.25 分析工作流的挑战259
本章回顾259
延伸阅读材料260
习题260
参考文献262
第12章 设计工作流264
12.1 面向对象设计264
12.2 面向对象设计：电梯问题案例研究268
12.3 面向对象设计：MSG基金会案例研究270
12.4 设计工作流272
12.5 测试工作流：设计273
12.6 测试工作流：MSG基金会案例273
12.7 详细设计的形式化技术273
12.8 实时设计技术274
12.9 用于设计的CASE工具274
12.10 设计的度量275
12.11 设计工作流面临的挑战276
本章回顾277
延伸阅读材料277
习题277
参考文献278
第13章 实现工作流280
13.1 选择编程语言280
13.2 良好的编程实践282
13.2.1 使用一致和有意义的变量名282
13.2.2 自文档化代码的问题283
13.2.3 使用参数284
13.2.4 为增加可读性的代码编排284
13.2.5 嵌套的if语句285
13.3 编码标准286
13.4 代码复用286
13.5 集成286
13.5.1 自顶向下的集成287
13.5.2 自底向上的集成288
13.5.3 三明治集成288
13.5.4 集成技术289
13.5.5 集成管理290
13.6 实现工作流290
13.7 实现工作流：MSG基金会案例研究290
13.8 测试工作流：实现290
13.9 测试用例的选择290
13.9.1 规格说明测试与代码测试291
13.9.2 规格说明测试的可行性291
13.9.3 代码测试的可行性291
13.10 黑盒单元测试技术293
13.10.1 等价测试和边界值分析293
13.10.2 功能测试294
13.11 黑盒测试用例：MSG基金会案例研究294
13.12 玻璃盒单元测试技术296
13.12.1 结构测试：语句、分支和路径覆盖296
13.12.2 复杂性度量297
13.13 代码走查和审查298
13.14 单元测试技术的比较298
13.15 净室298
13.16 测试中的问题299
13.17 单元测试的管理方面内容301
13.18 何时重写而不是调试代码制品301
13.19 集成测试302
13.20 产品测试303
13.21 验收测试303
13.22 测试流：MSG基金会案例研究304
13.23 用于实现的CASE工具304
13.23.1 软件开发全过程的CASE工具304
13.23.2 集成开发环境304
13.23.3 商业应用环境305
13.23.4 公共工具基础结构305
13.23.5 环境的潜在问题306
13.24 测试工作流的CASE工具306
13.25 实现工作流的度量306
13.26 实现工作流面临的挑战307
本章回顾307
延伸阅读材料308
习题309
参考文献310
第14章 交付后维护313
14.1 开发与维护313
14.2 为什么交付后维护是必要的314
14.3 交付后维护程序员要求具备什么314
14.4 交付后维护小型案例研究316
14.5 交付后维护的管理317
14.5.1 缺陷报告317
14.5.2 授权对产品的修改318
14.5.3 确保可维护性318
14.5.4 反复维护的问题319
14.6 维护问题319
14.7 交付后维护技能与开发技能321
14.8 逆向工程321
14.9 交付后维护期间的测试322
14.10 交付后维护的CASE工具323
14.11 交付后维护的度量323
14.12 交付后维护：MSG基金会案例研究323
14.13 交付后维护面临的挑战323
本章回顾323
延伸阅读材料324
习题324
参考文献325
第15章 UML的进一步讨论327
15.1 UML不是一种方法学327
15.2 类图327
15.2.1 聚合328
15.2.2 多重性329
15.2.3 组合329
15.2.4 泛化330
15.2.5 关联330
15.3 注释330
15.4 用例图330
15.5 构造型331
15.6 交互图331
15.7 状态图333
15.8 活动图335
15.9 包335
15.10 组件图336
15.11 部署图336
15.12 UML图回顾336
15.13 UML和迭代336
本章回顾337
延伸阅读材料337
习题337
参考文献337
附录338
附录A 学期项目：Osric办公用品和装饰公司项目338
附录B 软件工程资源340
附录C 需求工作流：MSG基金会案例研究341
附录D 分析工作流：MSG基金会案例研究341
附录E 软件工程管理计划：MSG基金会案例研究341
附录F设计工作流：MSG基金会案例研究345
附录G实现工作流：MSG基金会案例研究（C++版）349
附录H实现工作流：MSG基金会案例研究（Java版）349
附录I测试工作流：MSG基金会案例研究350
……
序言 软件工程的目标是按时交付满足客户需要、未超出预算、无错误、能随需求变化易于修改的软件。
在计算机界，范型一词最早用于描述编程风格。编程范型可以看成是程序员对程序执行的看法，而一些语言是专门为某个特定的范型设计的，当然也有一些语言支持多种范型。由于编程语言和软件开发的密切关系，范型一词也被引申至软件工程领域。面向对象的软件工程（object-oriented software engineering）就是一门利用面向对象范型实现软件工程目标的学科。
本书的作者Stephen R. Schach博
文摘 第1章面向对象软件工程的范畴
学习目标
通过本章学习，读者应能：
·了解面向对象软件工程的定义。
·解释现在面向对象范型被广泛接受的原因。
·论述软件工程各方面的含义。
·描述现代维护观点。
·论述持续计划、测试和编制文档的重要性。
·认识遵守伦理规范的重要性。
这是一个众所周知的故事，有一个公司的主管一天收到了一份计算机生成的账单，账单的金额为0.00美元，他与朋友一起尽情地讥讽了“愚蠢的计算机”一番后将账单扔掉了，一个月以后，他收到了一份标记过期30天的类似账单，接着，第3张账单也来了。又一个月之后，第4张账单来了，同时附有一份通知，提示如果不及时付清这个0.00美元的账单将可能采取法律行动。
第5张账单，上面标记过期120天，没有任何提示，直白而粗鲁地威胁道，如果不立即付清账单，将采取所有必须的法律手段。这位主管担心自己公司的信用会受到这个疯狂机器的影响，于是找了一位软件工程师朋友，跟他讲了这件恼人的事情。软件工程师忍住笑，让主管邮寄去一张0.00美元的支票。这产生了期望的结果，几天后一张0.00美元的收据寄来了，主管小心翼翼地收好这张收据，以防将来计算机宣称那张0.00美元的账单他还没有支付。
这个故事有一个不太为人知晓的结局。几天后，银行经理召见了这位主管。银行经理拿着一张0.00美元支票问他，“这是你的支票吗？”
这位主管回答：“是的”。
“那你能告诉我为什么要签署一张0.00美元的支票吗?”银行经理问道。
于是，整个故事被重新讲述了一遍。当主管讲完时，经理盯住他，温和地问道“你付0.00美元对我们计算机系统会造成什么后果，你想过吗？”
计算机专业人员虽然会觉得这个故事可笑，但是也会感到一些窘迫。毕竟，任何一个人所设计或完成的产品，在其原型阶段，都有可能出现类似寄送催讨0.00美元信件这种问题。目前，虽然在测试中总能发现此类错误，但是计算机专业人员的笑声会包含一种恐惧感，他们担心这种错误没有在产品交付给顾客前被检测出来。
插图：
