面向对象分析与设计（第3版）（修订版）

1.5.1 分解的作用
1.5.2 抽象的作用
1.5.3 层次结构的作用
1.6 复杂系统的设计
1.6.1 作为科学和艺术的工程
1.6.2 设计的含义
1.7 小结
第2章 对象模型
2.1 对象模型的演进
2.1.1 程序设计语言的换代
2.1.2第一代和第二代早期程序设计语言的拓扑结构
2.1.3第二代后期和第三代早期程序设计语言的结构
2.1.4第三代后期程序设计语言的结构
2.1.5 基于对象和面向对象的程序设计语言的结构
2.2 对象模型基础
2.2.1 面向对象编程
2.2.2 面向对象设计
2.2.3 面向对象分析
2.3 对象模型要素
2.3.1 抽象的意义
2.3.2 封装的意义
2.3.3 模块化的意义
2.3.4 层次结构的意义
2.3.5 类型的意义
2.3.6 并发的意义
2.3.7 持久的意义
2.4 应用对象模型
2.4.1 对象模型的好处
2.4.2 开放式问题
2.5 小结
第3章 类与对象
3.1 对象的本质
3.1.1 什么是对象，什么不是对象
3.1.2 状态
3.1.3 行为
3.1.4 标识符
3.2 对象之间的关系
3.2.1 链接
3.2.2 聚合
3.3 类的本质
3.3.1 什么是类，什么不是类
3.3.2 接口和实现
3.3.3 类的生命周期
3.4 类之间的关系
3.4.1 关联
3.4.2 继承
3.4.3 聚合
3.4.4 依赖关系
3.5 类与对象的互动
3.5.1 类与对象的关系
3.5.2 类与对象在分析和设计中的角色
3.6 创建高品质的类与对象
3.6.1 评判一种抽象的品质
3.6.2 选择操作
3.6.3 选择关系
3.6.4 选择实现
3.7 小结
第4章 分类
4.1 正确分类的重要性
4.1.1 分类的困难
4.1.2 分类的增量和迭代本质
4.2 确定类和对象
4.2.1 经典方法和现代方法
4.2.2 面向对象分析
4.3 关键抽象与机制
4.3.1 确定关键抽象
4.3.2 识别机制
4.4 小结
第2篇 方法
第5章 表示法
5.1 统一建模语言
5.1.1 简单历史回顾
5.1.2 模型与多重视图
5.1.3 图分类
5.1.4 在实践中使用图
5.1.5 概念模型、逻辑模型和物理模型
5.1.6 工具的角色
5.1.7 面向对象开发的产品
5.1.8 规模上的伸缩
5.1.9 UML的语法和语义
5.1.1 0UML2.0信息资源
5.2 包图
5.2.1 基本概念：包表示法
5.2.2 基本概念：元素的可见性
5.2.3 基本概念：依赖关系
5.2.4 基本概念：包图
5.2.5 高级概念：导入和访问
5.3 组件图
5.3.1 基本概念：组件表示法
5.3.2 基本概念：组件图
5.3.3 基本概念：组件接口
5.3.4 基本概念：组件实现
5.3.5 高级概念：组件的内部结构
5.4 部署图
5.4.1 基本概念：工件表示法
5.4.2 基本概念：节点表示法
5.4.3 基本概念：部署图
5.5 用例图
5.5.1 基本概念：执行者
5.5.2 基本概念：用例
5.5.3 基本概念：用例图
5.5.4 高级概念：include和extend关系
5.5.5 高级概念：泛化
5.6 活动图
5.6.1 基本概念：动作
5.6.2 基本概念：开始和停止
5.6.3 基本概念：判断节点和合并节点
5.6.4 基本概念：分区
5.6.5 高级概念：分叉、结合和并发
5.6.6 高级概念：对象流
5.6.7 高级概念：其他元素
5.7 类图
5.7.1 基本概念：类表示法
5.7.2 基本概念：类关系
5.7.3 高级概念：模板（参数化）类
5.7.4 高级概念：可见性
5.7.5 高级概念：关联端名称和限定符
5.7.6 高级概念：约束
5.7.7 高级概念：关联类和注解
5.8 序列图
5.8.1 基本概念：对象与交互
5.8.2 基本概念：生命线与消息
5.8.3 高级概念：销毁事件
5.8.4 高级概念：执行说明
5.8.5 高级概念：交互使用
5.8.6 高级概念：控制结构
5.9 交互概述图
5.9.1 基本概念：框
5.9.2 基本概念：控制流元素
5.9.3 基本概念：交互图元素
5.10 组合结构图
5.10.1 基本概念：组合结构的部分
5.10.2 基本概念：组合结构的部分与接口
5.10.3 基本概念：组合结构连接器
5.10.4 高级概念：协作
5.11 状态机图
5.11.1 基本概念：初始状态、最终状态和简单状态
5.11.2 基本概念：转换与事件
5.11.3 高级概念：状态活动——入口活动、执行活动和出口活动
5.11.4 高级概念：控制转换
5.11.5 高级概念：复合状态与嵌套状态
5.11.6 高级概念：并发与控制
5.11.7 高级概念：子状态机状态
5.11.8 高级概念：其他状态机图元素
5.12 时间图
5.12.1 基本概念：更多相同之处
5.12.2 基本概念：布局
5.12.3 基本概念：事件
5.12.4 基本概念：约束
5.12.5 高级概念：另一种表示形式
5.12.6 高级概念：事件与消息
5.13 对象图
5.13.1 基本概念：对象
5.13.2 基本概念：对象关系
5.13.3 高级概念：端点名称和限定符
5.14 通信图
5.14.1 基本概念：对象、链接和消息
5.14.2 基本概念：顺序表达式
5.14.3 高级概念：消息与同步
5.14.4 高级概念：迭代子句和约束条件
5.15 小结
第6章 过程
6.1 首要原则
6.1.1 成功项目的特征
6.1.2 追求理性的开发过程
6.2 宏观过程：软件开发生命周期
6.2.1 概述
6.2.2 宏观过程的内容维：科目
6.2.3 宏观过程的时间维：里程碑和阶段
6.2.4 宏观过程的时间维：迭代
6.2.5 发行计划
6.3 微观过程：分析与设计过程
6.3.1 概述
6.3.2 抽象层次
6.3.3 活动
6.3.4 产品
6.3.5 微观过程与抽象层次
6.3.6 识别元素
6.3.7 确定元素间的协作
6.3.8 确定元素间的关系
6.3.9 详细确定元素的语义
6.4 小结
第7章 实战
7.1 管理和计划
7.1.1 风险管理
7.1.2 任务计划
7.1.3 开发复查
7.2 人员配备
7.2.1 资源配置
7.2.2 开发团队角色
7.3 发布版本管理
7.3.1 配置管理和版本控制
7.3.2 集成
7.3.3 测试
7.4 复用
7.4.1 复用的元素
7.4.2 建立复用制度
7.5 质量保证和测量指标
7.5.1 软件质量
7.5.2 面向对象测量指标
7.6 文档化
7.6.1 开发遗产
7.6.2 文档化的内容
7.7 工具
7.7.1 工具种类
7.7.2 组织上的意义
7.8 特殊主题
7.8.1 领域特定问题
7.8.2 采纳面向对象技术
7.9 面向对象开发的好处和风险
7.9.1 面向对象开发的好处
7.9.2 面向对象开发的风险
7.10 小结
第3篇 应用
第8章 系统架构——基于卫星的导航
8.1 初始
8.1.1 卫星导航系统的需求
8.1.2 定义问题的边界
8.1.3 确定任务用例
8.1.4 确定系统用例
8.2 细化
8.2.1 开发一个好的架构
8.2.2 定义架构开发活动
8.2.3 验证所建议的系统架构
8.2.4 分配非功能需求和确定接口
8.2.5 规定系统架构及其部署
8.2.6 分解系统架构
8.3 构造
8.4 交付之后
8.4.1 添加新的功能
8.4.2 改变目标硬件
第9章 控制系统——交通管理
9.1 初始
9.1.1 列车交通管理系统的需求
9.1.2 决定系统用例
9.2 细化
9.2.1 分析系统功能
9.2.2 定义TTMS架构
9.2.3 从系统工程到硬件和软件工程
9.2.4 关键抽象和机制
9.3 构造
9.3.1 消息传送
9.3.2 列车时刻表计划
9.3.3 显示信息
9.3.4 传感器数据采集
9.3.5 发布版本管理
9.3.6 系统架构
9.3.7 子系统规格说明
9.4 交付之后
第10章 人工智能——密码分析
10.1 初始
10.1.1 密码分析需求
10.1.2 定义问题的边界
10.1.3 黑板框架的架构
10.1.4 知识源的分析
10.2 细化
10.2.1 黑板对象
10.2.2 依赖和认定
10.3 构造
10.3.1 设计黑板对象
10.3.2 设计知识源
10.3.3 设计控制器
10.3.4 集成黑板框架
10.3.5 添加新的知识源
10.4 交付之后
10.4.1 系统增强
10.4.2 改变需求
第11章 数据采集——气象监测站
11.1 初始
11.1.1 气象监测站需求
11.1.2 定义问题的边界
11.1.3 场景
11.2 细化
11.2.1 气象监测系统用例
11.2.2 架构框架
11.3 构造
11.3.1 帧机制
11.3.2 发布计划
11.3.3 传感器机制
11.3.4 显示机制
11.3.5 用户界面机制
11.4 交付之后
第12章 Web应用——休假跟踪系统
12.1 初始
12.1.1 需求
12.1.2 用例模型
12.2 细化
12.2.1 部署视图
12.2.2 逻辑视图
12.2.3 进程视图
12.2.4 实现视图
12.2.5 用例视图
12.3 构造
12.3.1 用户体验模型
12.3.2 分析和设计模型
12.3.3 实体
12.3.4 控制器
12.3.5 Web页面和用户界面
12.4 交付和交付之后
附录A 面向对象编程语言
附录B 进一步阅读
注解
术语表

.　　对于有经验的 OOAD 实践者，本书从不同的角度提供了价值。
　　即使对于有经验的实践者， UML 2.0 也是新的。这是可以看到的表示法方面的重要区别。
　　根据前一版本所收到的反馈，更加关注建模。
　　通过本书的概念部分的学习，可以了解在面向对象的世界中，"为什么事情总是像它们现在的样子"。许多人可能从没研究过面向对象（ OO）概念本身的发展，即使有所了解，在初次学习 OO 方法时，也许未能理解其重要性。
　　本书这一版和以前的版本相比有四项主要区别，如下所示。
　　1． UML 2.0 已经正式得到了通过，第 5 章将介绍 UML 2.0。为了加强读者对这种表示法的理解，特别区分了它的基本元素和高级元素。
　　2．这一版在应用程序的章节中引入了一些新的领域和背景。例如，应用程序的领域范围很广，包括从高级系统架构到基于 Web 的系统的设计细节等各种不同层次的抽象。
　　3．在前一版出版时，作为 OO 编程的概念来说， C++相对还是比较新的。
　　读者告诉我们，这种强调不再是主要的考虑。现在有大量的 OO 编程和技术书籍及培训，还有许多为 OO 开发而设计的编程语言。因此，大部分关于编码的讨论被删除了。
　　4．最后，响应读者的要求，这一版更关注 OOAD 建模方面。应用程序章
　　节将展示如何利用 UML，其中每一章强调了整个开发生命周期中的一个阶段。
　　本书的目标
　　本书在面向对象系统构建方面提供了实用指导。它的具体目标如下。
　　提供对对象模型的基础概念及其发展变化的正确理解；
　　帮助读者掌握面向对象分析和设计的表示法和过程；
　　介绍在不同的问题域中面向对象分析和设计的实际应用。
　　本书介绍的概念都基于牢固的理论基础，但本书首先是一本注重实效的书，面向架构师和软件开发者等软件工程实践者的实际需要。
　　读者对象
　　本书既是为计算机专业人员也是为学生编写的。
　　对于实际系统和软件的开发者，本书将展示如何高效地利用面向对象技术来解决实际问题。
　　对于系统分析师或架构师，本书将利用面向对象的分析与设计，提供一条从需求到实现的途径。 我们帮助分析人员或架构师提高识别能力，以区分不好的面向对象的结构与好的面向对象的结构，并在现实情况反常时权衡可选的设计方案。也许最重要的就是，我们提供了一些让复杂系统变得有条理的新方法。
　　对于项目经理，本书可以帮助他们更好地理解开发团队的资源分配、软件品质、测量指标以及管理与复杂软件系统相关的风险。
　　对于学生，本书提供了一些必要的指导，使得学生能够开始掌握复杂系统开发的科学与艺术中的一些重要技巧。
　　本书不仅适合专业研讨班和个人学习使用， 也适合作为高等院校本科生和研究生课程的教材。因为它主要阐述了软件开发的方法，所以非常适合软件工程和高级编程等课程， 也可以作为涉及具体面向对象编程语言的课程的补充阅读材料。
　　本书的组织结构
　　本书分成 3 篇：概念、方法和应用，其中穿插了大量的补充材料。
　　概念
　　第 1 篇研究软件的内在复杂性及其表现方式。 本书将对象模型作为一种手段来帮助我们管理这种复杂性，详细地研究了对象模型的基本元素--抽象、封装、模块化、层次结构，讨论了"什么是类？"以及"什么是对象？"等基本问题。由于确定有意义的类和对象是面向对象开发中的关键任务，因此我们花了相当多的时间来研究分类的本质。具体来说，我们研究了生物学、语言学和心理学等其他学科中的分类方法， 然后将这些经验应用到发现软件系统中类和对象的问题上。
　　方法
　　第 2 篇基于对象模型提出了复杂系统开发的一种方法。 针对面向对象的分
　　析与设计，首先提出了一套图形表示法（即 UML），然后是一个通用的过程框架。还研究了面向对象开发的实践，具体来说，就是它在软件开发生命周期中的位置以及它对于项目管理意味着什么。
　　应用程序
　　第 3 篇提供了一组（ 5 个）不简单的例子，涉及不同问题域：系统架构、控制系统、密码分析、数据获取和 Web 开发。之所以选择这些问题域，是因为它们是软件工程师实践过程中遇到的复杂问题的代表。 展示某些原则如何应用于简单的问题是很容易的， 但是因为我们关注的是为现实世界构建有用的系统，所以我们对如何将对象模型应用于复杂应用程序更加感兴趣。软件系统的开发不同于按菜谱做菜，因此我们强调应用程序的增量式开发，这种开发以一些正确的原则和良好的模型作为指导。
　　补充材料
　　本书中穿插了大量的补充材料。多数章节中都有补充材料，这些材料对重要的主题提供了相关的信息。本书包括了一个关于面向对象编程语言的附录，其中总结了一些常见语言的特征，还提供了常用术语的词汇表，以及一个扩展的分类参考书目，列出了关于对象模型的参考资料。
　　工具说明
　　读者总是会问创建本书中的图使用了什么工具。 我们主要使用两个很好的工具来画图： IBM Rational Software Architect 和 Sparx Systems Enterprise Architect。为什么不只用一个？市场的实际情况是，没有哪一种工具可以做所有的事情。实践 OOAD 的时间越长，最后就会发现有些特别的情况是所有工具都不支持的。（在这种情况下，可能需要寻求基本的绘图工具来展示你的想法。）但是，不要让这些很少的情况阻止你使用健壮的 OOAD 工具，如我们提到的这两种工具。
　　本书的阅读方法
　　对于本书可以一页一页地读，也可以不按现有的组织形式阅读。如果想对对象模型中的基本概念或面向对象开发的动机有较深的理解， 那么就应该从第1 章开始依次读下去。如果只对面向对象开发分析与设计中的表示法和过程感兴趣，就从第 5 章和第 6 章开始阅读。第 7 章对使用这种方法管理项目的管理者来说特别有用。如果对针对特定问题域的面向对象技术的应用程序更感兴趣，则可以在第 8～12 章中任选一章或者全部阅读。
　　致 谢
　　我把本书献给我的妻子 Jan，感谢她的爱和支持。
　　在第 1 版和第 2 版的写作过程中，一些人促成了我的面向对象开发思想。
　　对于他们的贡献，我特别要感谢，他们是： Sam Adams、 Mike Akroid、 Glenn Andert、 Sid Bailin、 Kent Beck、 Dave Bernstein、 Daniel Bobrow、 Dick Bolz、Dave Bulman、 Kayvan Carun、 Dave Collins、 Damian Conway、 Steve Cook、 Jim Coplien、 Brad Cox、 Ward Cunningham、 Tom DeMarco、 Mike Devlin、 Richard Gabriel、 William Genemaras、 Adele Goldberg、 Ian Graham、 Tony Hoare、 Jon Hopkins、 Michael Jackson、 Ralph Johnson、 James Kempf、 Norm Kerth、 Jordan Kreindler、 Doug Lea、 Phil Levy、 Barbara Liskov、 Cliff Longman、 James MacFarlane、 Masoud Milani、 Harlan Mills、 Robert Murray、 Steve Neis、 Gene Ouye、 Dave Parnas、 Bill Riddel、 Mary Beth Rosson、 Kenny Rubin、 Jim Rumbaugh、Kurt Schmucker、 Ed Seidewitz、 Dan Shiffman、 Dave Stevenson、 Bjarne Stroustrup、Dave Thomas、 Mike Vilot、 Tony Wasserman、 Peter Wegner、 Iseult White、 John Williams、 Lloyd Williams、 Niklaus Wirth、 Mario Wolczko 和 Ed Yourdon。
　　本书的相当一部分实践来自我参与并在世界各地开发的复杂软件系统， 这些系统的开发公司包括 Alcatel、 Andersen Consulting、 Apple、 AT&T、 Autotrol、Bell Northern Research、 Boeing、 Borland、 Computer Sciences Corporation、 Contel、Ericsson、 Ferranti、 General Electric、 GTE、 Holland Signaal、 Hughes Aircraft Company、 IBM、 Lockheed、 Martin Marietta、 Motorola、 NTT、 Philips、 Rockwell International、 Shell Oil、 Symantec、 Taligent 和 TRW。我曾有机会与数百名专业软件工程师和他们的经理协作，我要谢谢他们的帮助，是他们让本书与真实世界的问题相关。
　　特别要感谢 Rational 对我的工作的支持。还要谢谢 Tony Hall，他的卡通画给本书带来了亮点，否则这本书就只是一本乏味的技术书籍。最后，我要谢谢我的 3只猫--Camy、 Annie 和 Shadow，在我写作的许多个深夜，它们总是陪伴着我。
　　--Grady Booch
　　我要感谢我的家人，他们必须忍受我参与编写这本书的漫长日子。感谢我的父母，他们培育了我高尚的职业道德。感谢 Mary T.O' Brien，她为我提供了这个机会，这才使我开始了大量的后续工作。感谢 Chris Guzikowski 帮助推动这项工作直至完成。我要感谢合著者，感谢你们允许我加入这项工作，也感谢你们在这个项目中的努力工作和贡献。最后，我要衷心感谢 Grady 多年前编写的本书的第 1 版， 这本书是关于面向对象分析与设计最早的、 最基础的书之一。
　　--Bob Maksimchuk
　　我想表达对家人的感激，他们给了我爱和支持，这是我所有努力的基础。感谢 Grady 给我机会，让我能够在他的经典著作的第 3 版中做出贡献。最后，我要感谢 Bob Maksimchuk 在我成为一名作者的过程中所给予的指导。
　　--Mike Engle
　　我要将本书献给我的母亲 Jean Smith，她鼓励我参加这项工作。我也要表达我对家人 Russell、 Alyssa 和 Logan 的爱和感激，感谢他们的支持和鼓励。感谢 Bob Maksimchuk 和 Mike Engle，是他们让我有机会参与这项工作。
　　--Bobbi J. Young
　　我要特别感谢我的丈夫 Bob 和两个孩子--Katherine 和 Ryan，他们的爱和支持给我了真正的灵感。
　　--Kelli A. Houston
　　感 谢 我 们 的 审 稿 者 ， 特 别 是 Davyd Norris 和 Brian Lyons 。 感 谢Addison-Wesley 所有参与本书的其他工作人员，特别是 Chris Zahn，他不仅参与了这项工作，而且保持了这项长时间工作的连贯性。

.　　一个表达式也是一个图灵机，其中的操作数是输入，求值的结果是输出。一个函数也是图灵机，参数是输出，返回值是输出。编程或设计软件就是在通用图灵机的基础上，设计一个具体的图灵机。我们设计软件接受怎样的输入，设计软件内部的状态，设计表示计算规则的代码，设计软件的输出。
　　近年来逐渐流行的函数式编程，就是建立在这个抽象的基础上。而且函数式编程的思想由来已久，可以追溯到最古老的高级语言之一： Lisp。这种思想非常简单：给定一个输入集合，经过函数的处理，给出一个输出集合。由此也导出了 Map-Reduce 等流行的架构设计模式： 一个计算集群仍然是一个图灵机。纯粹的函数有一点不足， 它没有内部状态。 可以说， 它是简化了的图灵机。但在有些时候，我们确实需要内部状态。根据内部状态的不同，对于同样的输入，可能给出不一样的输出。于是便有了闭包的概念，它是一个函数加上相关的上下文环境状态。这样，我们可以毫无困难地构建任何具体的图灵机（好吧，正确实现一个算法还是比较困难的）。
　　闭包可以看成是拥有内部状态的函数，这就相当于一个简单的对象，它只有一个方法。反过来，对象可以看成是几个闭包，它们共享了内部状态。所以有人说：闭包是懒人的对象，对象是懒人的闭包。因此，函数式编程和面向对象思想，在底层基础上是一致的。
　　面向对象思想的历史和函数式一样久远。实际上，它们都是我们在设计算法时的一种抽象。只有利用抽象概念，才能实现人与人之间的沟通。"你想吃苹果吗？"这里的"苹果"就是一个抽象概念，它隐藏了苹果实现的许多细节。人的大脑喜欢工作在一组抽象概念上。名词是结构或存在的抽象，动词是行为或过程的抽象。
　　我们在设计算法时，既需要函数抽象，也需要对象抽象。今天，面向对象和函数式编程的思想在各种编程语言中融合，可以说是殊途同归。
　　抽象是强大的工具，但用得不好，也会产生不良的后果。最重要的问题，就是创建太多不必要的抽象。毕竟，抽象只是我们脑中的概念，我们可以创造出任何概念。比如上帝和各种鬼神，直到科学家说，在科学的系统里不需要假设存在一个上帝。面向对象在这方面遇到的问题比较多。举例来说，一个 Java的 Hello world 程序，就要涉及好几个概念，直接导致程序的代码比较长。而在函数式编程中， 这通常只是一次函数调用。又比如， 在一个使用 Struts、 Spring、Hibernate 构建的 Java Web 应用程序中，处理一个 Get 请求的调用栈，可能是长长的一串。数据在不同的概念抽象之间反复倒手，白白浪费了计算资源。
　　任何两种观点都是互补的。 面向对象思想在过去的软件开发中取得了辉煌的成绩。函数式编程让我们能从另一个角度审视面向对象，更进一步体会面向对象抽象的强大，也发现面向对象中一些误用的地方。如无必要，勿增实体。也许我们不需要假设以太的存在，就能解释光在真空中的传播。
　　多年后重读这本书， 促使我重新思考， 需要利用哪些抽象来设计我的算法。
　　这些年来，这本书让我受益良多，再次向大家郑重推荐。
　　王海鹏
　　2016 年 1 月 5 日