本书论述运用UML（统一建模语言）和模式进行对象建模的方法和技巧，重点讨论了如何使用面向对象的分析和设计技术来建造一个健壮的和易于维护的系统。
全书叙述清晰、图文并茂、实例丰富，是一部来自于大量经验的总结性论著，适合在学习和工作中需要运用面向对象技术的高校师生或工程技术人员使用，特别适用于对面向对象技术有一定了解但希望进一步提高开发水平的应用开发人员。
姚淑珍（女），北京航空航天大学计算机科学与工程系副教授。1989年获硕士学位。研究方向为软件工程、面向对象技术、分布式计算。已在国内外重要期刊和学术会议发表论文30余篇，并获多项国家及部委科技成果奖和个入奖。
李虎（男），北京航空航天大学计算机系博士生，研究方向为软件工程、Agent技术、面向对象技术，发表论文近10篇。
感谢你阅读本书！现在你的手里已经有了这本面向对象的分析与设计世界的实用指南和引路图了。下面要说明本书将如何使你受益。
首先，帮助体设计健壮的和易于维护的对象系统。在软件开发过程中对象技术的使用日益增多——甚至随着Java语言的广泛采用，这种对象技术的使用还会更多——掌握面向对象的分析技术对建立一个健壮的和易于维护的面向对象系统来说是至关重要的。掌握这项技术同样也为你开辟了成为构架设计师。分析人员和设计人员的新机会。
第二，提供从需求确定、系统分析、设计到编码这个过程的引路围。如果你是一位面向对象分析和设计方面的新手，那你一定会面对这样一个难题：如何进行面向对象的分析和设计这一复杂课题？本书为你提供了一个表达准确的引路图，以使你能够一步一步地从需求分析开始一直走到程序编码。
第三，教你运用UML描述分析和设计模型。统一建模语言（Unified Modeling Language，UML）是作为一种标准的建模表示法应运而生的，因此掌握它对你大有用处。本书将为你讲授使用UML表示法进行面向对象分析与设计的技巧。
第四，运用“四人”模式（gang-of-fou）和GRASP模式改进设计。设计模式是面向对象分析方面的专家们所总结的“最好的做法”。本书将教你使用设计模式，包括目前流行的“四人模式”，以及最为重要的GRASP模式。GRASP模式能够反映出面向对象设计中有关职责分配方面的基本原则和方法。学习和运用模式技术会有助于你更快地掌握分析和设计技术。
第五，通过一套精细的表述方式进行卓有成效地学习。全书的组织结构和重点内容是基于作者多年培养和训练人们使用面向对象分析和设计技巧所积累的经验总结。本书通过提供一套精练的、被证明是正确的和高效率的方法来使这些经验结晶能够在书中体现出来，以使你对本书的投资和阅读能够得到最佳的回报。
第六，通过符合实际的例子辅助学习。书中详细描述了一个学习案例——以便尽可能符合实际地展示完整的面向对象的分析和设计过程。本书还深入细致地探讨了问题的各个方面细节。这个学习案例是一个符合实际的练习题。
第七，学会把设计转换成代码。本书展示了如何将面向对象的设计制品转换成 Java语言程序代码的方法。
第八，设计出一种分层的系统体系结构。本书阐述了如何设计分层的系统体系结构以及如何将图形用户界面层与应用领域和系统服务层联系起来。这个问题在实际应用中意义重大但却往往会被人们所忽视。
最后，设计出系统框架。书中还介绍了如何设计面向对象的框架，并特别介绍了如何将这种设计方法应用于框架的创建以便用于数据库中的持久化存储。
目标
本书的主要目标是：
通过应用一套可以解释的设计原则和启发式的教学法帮助学生和开发人员创建更好的面向对象的设计。
通过学习和运用本书所提供的信息和技术，你将能够更加熟练地从概念和过程两个方面来理解问题，并能够运用对象技术设计更加完善的问题解决方案。
适用读者
本书适用于以下读者：
对面向对象程序设计语言有一定使用经验，但还不熟悉或不很熟悉面向对象分析与设计技巧的开发人员。
在计算机科学或软件工程课程中学习对象技术的学生。
对面向对象分析与设计有一定熟悉程度，并想进一步学习统一建模语言表示法和运用设计模式的人，或者想磨练和提高自己的分析设计技巧的人。
预备知识
为了更好地从本书受益，读者必须具备以下一些预备知识：
面向对象的程序设计语言（如C＋＋、 Java或Smalltalk）方面的知识和使用经验。
了解对象技术的基本概念，如类、实例、接口、多态、封装和继承等。
本书中没有给出上述的对象技术中最基本概念的定义。
本书的组织
本书的基本组织思路是：以类似于软件项目开发所经历的两个迭代开发周期的顺序来引入面向对象分析与设计的各个专题。第一个迭代开发周期中引入了一定的分析与设计。第二个迭代开发周期又引入了新的分析和设计专题，与此同时，还将对前一个周期中的专题进行更深入的讨论。见图1所示。
本书目的
尽管对象技术很有发展前景，但是如果不能正确地使用某些技巧的话，人们将很难意识到对象技术所具有的潜力。我的目标是通过运用面向对象分析与设计技巧来促进对象技术的成功应用，以及促进人们在这方面技术能力的提高。我这样做的原因在于我已经察觉到我所提到的
致谢
首先要感谢所有使用、学习UML和面向对象分析与设计技术的人，我写这本书正是要帮助他们，同时他们也是我最好的老师。
这里要特别感谢本书（或其中部分章节）的审阅者，包括Kent、Bech、Jens Colddewey。Clay Davis、 Tom Heruska、Luke Hohmann、David Norris、David Nunn、 Brett Schuchert以及整个水星组（Mercury team）。感谢 Grady M对本书相关教学材料的审阅。还要感谢 Jim Rtnnbsngh，他就书中UML和软件过程之间的关系等内容提出了很多反馈意见。
因为还有许多人对书中有关模型和过程等内容提出了宝贵意见，所以在此我还要感谢Todd Grvin、John Hebley、Tom Heruska、David Norris、 David Nunn、 Charles Rop和 Raj Wall等。
非常感谢GradyBooc、Ivar Jacobson和Jim Rumbaugh。正是他们三位合作开发了统一建模语言并创建了一个标准的、开放的模型表示法，这在当前无章可循的大环境下是深受业界欢迎的。此外，我还从他们的主张中学到了很多东西。
感谢我的同事Jef Newsom为本书增加Java解决方案的案例学习内容。
感谢我的出版商Prentice-Hall公司的Paul Becker，正是他坚信本书是值得出版的好书。
最后，谢谢Graham Glass提供的一切便利。
关于作者
作者拥有计算机科学学士和硕士学位，他从1978年开始应用从4GL编程、逻辑程序设计到面向对象程序设计等各种软件技术，从事从大型计算机到微机等各种平台上的大型软件系统和小型软件系统的开发。
在20世纪80年代初期，作者钟情于人工智能和知识系统中的程序设计技术，并从那时起开始接触到面向对象的程序设计（使用 Lisp语言）。他从1984年开始使用和讲授LISP语言的面向对象程序设计，到1986年改用 Smalltalk，到1991年变为 C＋＋，最近又开始使用 Java语言，并结合程序设计讲授各种面向对象的分析和设计方法。他在对象技术领域指导和帮助过的学生超过2000人。
作者现任ObjectSpace公司的首席讲师，Obectspace是一家专门研究分布式计算、agent技术和对象技术的公司。
读者可以通过电子邮箱：clarman＠acm.org与作者本人联系。
排版约定
新出现的术语用黑体印刷。
类名或者方法名如果保持英文原文用斜体印刷，如果译为中文用楷体印刷。
相关作者的参考文献用方括号括住的文献缩写来引用，如［Bob67」。
“--”符号用作类名和类中方法名之间的连接符，如ClassName--methodName（）。
（美）Craig Larman：暂无简介
姚淑珍 李虎 等：暂无简介
面向对象方法以其超越传统方法的技术先进性越来越得到更多的重视，但技术的先进性不能完全代表一种新生事物的最后成功，还要看它是否能得到有效的推广。统一建模语言（UML）的产生为这种推广规定了一致的表示，诸多开发过程模型为技术的应用提供了宏观的指导。但开发者往往会说：“面对一个应用，我了解UML也知道应基于用况，以体系结构为核心，采用迭代、增量模式，来实施开发过程。但我仍困惑，从何入手，具体该怎么做广如果您也有这样疑问的话，本书将为您提供开发过程和设计方法的指导。
本书给出了一个开发过程示例，它描述了一个可能的活动序列和开发周期。通过一个学习案例——销售点终端系统的开发过程引导，尽可能实际地展示面向对象的分析和设计过程，以及所面临的问题及其解决办法。本书还通过讲授GRASP等典型模式帮助您有效学习和使用面向对象分析与设计的实用技巧。这些技巧是使用对象技术和面向对象编程语言（例如C＋＋、Ja－va或Smlltalk）开发出设计良好、结构健壮和易于维护的软件系统所必不可少的。
本书是一部来自于大量经验的总结性论著，服务对象是学习或工作中运用面向对象技术的教师、学生或工程技术人员，特别适用于对面向对象技术有一定了解但希望进一步提高开发水平的应用开发人员。
本书由姚淑珍、李虎负责翻译，胡斌、姚志强、黄涛、黄听、许正华、张翼翻译了部分内容。大家集思广益、畅所欲言、反复推敲，形成了对原文的基本一致和较透彻的理解。
在翻译中我们尽量融入了多年来从事软件工程的经验和面向对象开发的实践体会，但也难免存在由于知识局限和时间仓促的原因造成的翻译错误和遗漏，敬请广大读者指正。我们会接受您的批评，并向原书作者表示歉意。
译者
2002年1月于北京
第一部分结论
第1章 面向对象的分析与设计
1．1 运用UML、模式和面向对象的分析与设计技术
1．2 分配职责
1．3 什么是分析和设计
1．4 什么是面向对象的分析和设计
1．5 类比--组织MicroChaos公司的业务
1．5．1 MicroChaos公司正迅速发展壮大
1．5．2 什么是业务过程
1．5．3 组织中的角色是什么
1．5．4 谁该干什么？他们之间如何协作
1．6 面向对象的分析与设计的例子
1．6．l 定义用况
1．6．2 定义概念模型
1．6．3 定义协作图
1．6．4 定义设计类图
1．6．5 掷骰子游戏例子的总结
1．7 面向对象的与面向功能的分析与设计
1．8 警告："分析"和"设计"可能引起术语上的"冲突"
1．9 统一建模语言
第2章 开发过程导论
2．l 导言
2. 1．l 推荐的过程和模型--RPM
2．1．2 讨论范围
2．2 UML和开发过程
2．3 高层步骤
2．4 迭代开发
2．4．1 确定开发周期的时间企
2．4．2 用况和迭代开发周期
2．4．3 划分用况的层次
2．5 计划和细化阶段
2．6 构造阶段--开发周期
2．7 选择制品创建的时机
2．7．1 何时创建概念模型
2．7．2 何时创建扩展用况
第3章 定义模型和制品
3．l 导言
3．2 建模系统
3．3 样例模型
3. 4 制品之间的关系
第二部分 计划和细化阶段
第4章 学习案例：销售点终端
4．1 销售点终端系统
4．2 系统体系结构的层次和学习案例的重点
4. 3 我们的策略：反复学习和反复开发
第5章 理解需求
5．1 导言
5．2 需求
5．3 总体问题陈述
5．4 顾客
5．5 目标
5．6 系统功能
5．6．1 功能的分类
5．6．2 基本功能
5．6．3 处理支付的功能
5．7 系统属性
5．8 需求阶段的其他制品
第6章 用况：对过程的描述
6．1 导言
6．2 活动及其相互间的依赖关系
6．3 用况
6．3．1 高层用况举例：购买商品
6．3．2 扩展用况举例：用现金购买商品
6．3．3 扩展格式的说明
6．4 参与者
6．5 使用用况时的常见错误
6．6 用况的识别
6．7 用况和领域过程
6．8 用况、系统功能和可跟踪性
6．9 用况图
6．10 用况的格式
6．10．1 高层格式
6．10．2 扩展格式
6．11 系统及其边界
6．12 主要、次要和可任选的用况
6．13 基本用况和真实用况
6．13．1 基本用况
6．13．2 真实用况
6．13．3 购买商品的基本用况
6．13．4 购买商品的真实用况
6．14 表示法要点
6．14．l 用况的命名
6．14．2 扩展用况的开始部分
6．14．3 判定点和分支的表示法
6．15 一个开发过程中的用况
6．15. l 计划和细化阶段的步骤
6．15．2 迭代开发周期阶段中的步骤
6．16 销售点终端系统的处理步骤
6．16．l 识别参与者和用况
6．16．2 用高层格式书写用况
6．16．3 绘制系统的用况图
6．16．4 为用况增加关联
6．16．5 书写一部分扩展的基本用况
6．16．6 在必要情况下书写一些真实用况
6．16．7 划分用况的层次
6．17 样例模型
第7章 用况的分类和时间调度
7．1 导言
7．2 将用况调度分配到开发周期中实现
7．2．1 用况和开发周期
7．2．2 用况的分类
7．3 销售点终端应用系统中的用况分类
7．4 "系统启动"用况
7．5 销售点终端应用系统中用况的时间调度
7．5．1 创建复杂用况的多个版本
7．5．2 用况分配
7．6 "购买商品"用况的版本
7．6．1 购买商品一版本1
7．6．2 购买商品一版本2
7．7 小结
第8章 开始进入一个开发周期
第三部分 分析阶段（1）
第9章 建立一个概念模型
9．1 导言
9．2 活动及其相互之间的依赖关系
9．3 概念模型
9．3．1 理解领域词汇
9．3．2 概念模型不是软件设计模型
9．3．3 概念
9．3．4 概念模型和问题分解
9．3．5 销售点终端系统问题域中的概念
9．4 识别概念的策略
9．4．l 使用概念目录列表来找出概念
9．4．2 根据名词性短语找出概念
9．5 销售点终端问题域中的候选概念
9．5．1 报告类对象--模型中包括收据吗
9．5．2 销售点终端系统的概念模型（只包括概念）
9．6 建立概念模型的指导原则
9．6．l 怎样建立一个概念模型
9．6．2 事物的命名和建模：制图者的方法
9．6．3 在识别概念时常犯的错误
9．7 类似概念的解析--POST和Register
9．8 非现实世界中的概念建模
9．9 规格说明或描述型概念
9．9．1 对规格说明的需求
9．9．2 什么时候需要规格说明型概念
9．9．3 另一个规格说明的例子
9．10 UML中有关术语的定义
9．11 样例模型
第10章 概念摸型--添加关联
10．l 导言
10．2 关联
10．3 关联的UML表示法
10．4 找出关联--通用关联列表
10．5 关联应该精细到什么程度
10．6 关联原则
10．7 角色
10．8 关税的命名
10．9 两个类型间的多重关联
10．10 关联和它的实现
10．11 销售点问题域中的关联
10．11．1 在商店中不能被遗忘的一些关系
10．11．2 使用关联核对列表的分类
10．12 销售点系统的概念模型
10．12．1 只保存"需要知道"型关联吗
10．12. 2 "需要知道"型关联和"理解"型关联
第11章 概念模型--添加属性
11．l 导言
11．2 属性
11．3 属性的UML表示法
11．4 有效的属性类型
11．4．l 保持属性的简单性
11．4．2 分析和设计相比：属性如何用代码来实现
11．4．3 纳数据值
11．4．4 设计问题蔓延：避免使用外部键属性
11．5 非简单属性类型
11. 6 对属性的数量和单位建模
11．7 销售点系统中的属性
11．8 销售点模型中的属性
11．9 从SalesLineItem到Item的多重性
11．10 销售点系统的概念模型
11．11 小结
第12章 在术语表中记录术语
12．1 导言
12．2 术语表
12．3 活动及其相互之间的依赖关系
12．4 销售点系统的术语表的示例
第13章 系统行为--系统顺序图
13．1 导言
13．2 活动及其相互之间的依赖关系
13．3 系统行为
13．4 系统顺序图
13．5 系统顺序图的例子
13．6 系统事件和系统操作
13．7 如何建立一个系统顺序图
13．8 系统顺序图和其他制品
13．9 系统事件和系统边界
13．10 系统事件和操作的命名
13．11 显示出用况的文本描述
13．12 样例模型
第14章 系统行为--契约
14．l 导言
14．2 活动及其相互之间的依赖关系
14．3 系统行为
14．4 契约
14．5 契约举例--enterItem
14．6 契约段
14．7 如何建立一个契约
14．8 后置条件
14．8．l 后置条件与概念模型相关
14．8．2 使用后置条件的优点
14．9 后置条件的核心：舞台和帷幕
14．10 讨论--enterItem的后置条件
14．10．1 实例的创建和销毁
14 10．2 属性的修改
14．10．3 关联的形成和破裂
14．11 后置条件应该详细到什么程度
14．12 描述设计细节和算法--注释
14．13 前置条件
14．14 对书写契约的一些建议
14．15 用况enterItem的契约
14．15．l enterItem的契约
14．15．2 endSale的契约
14．15．3 makePayment的契约
14．16 用况 StartUp的契约
14．17 概念模型的修改
14．18 样例模型
第四部分 设计阶段（1）
第15章 从分析到设计
15．l 分析阶段的总结
15．2 设计阶段的开始
第16章 描述真实用况
16．l 导言
16．2 活动及其相互之间的依赖关系
16．3 真实用况
16．4 举例--购买商品一版本1
16．5 样例模型
第17章 协作图
17. 1 导言
17．2 活动及其相互之间的依赖关系
17．3 交互图
17．4 协作图举例：makePayment
17．5 交互图是一个很有价值的制品
17．6 本章只介绍表示法
17．7 阅读后面的章节来学习设计原则
17．8 如何建立协作图
17．9 协作图的基本表示法
17．9. 1 类和实例的表示法
17．9．2 链的表示法
17．9. 3 消息的表示法
17．9．4 参数的表示法
17．9．5 返回值的表示法
17．9．6 消息的语法
17．9．7 传送到"self"或"this"的消息表示法
17．9．8 迭代的表示法
17．9．9 实例创建的表示法
17．9．10 消息序号的表示法
17．9．11 条件消息的表示法
17．9．12 互斥条件路径的表示法
17．9．13 实例集的表示法
17．9．14 传递给多对象的消息表示法
17．9．15 发送给类对象的消息表示法
17．10 样例模型
第18章 GRASP：职责分配模式
18．1 导言
18．2 活动及其相互之间的依赖关系
18．3 设计优良的交互围很有价值
18．4 职责和方法
18．5 职责和交互团
18．6 模式
18．6．1 模式通常不包含新的设计思想
18．6．2 模式带有名称
18．6．3 模式被命名后有利于增进交流
18．7 GRAS：职责分配中通用原则的模式
18．8 UML类图表示法
18．9 专家
18．10 创建者
18．11 低耦合度
18．12 高聚合度
18．13 控制者
18．14 职责、角色扮演和CRC卡
第19章 运用对象和模式设计一个解决方案
19．1 导言
19．2 交工图和其他制品
19．2．1 交五圈和系统事件
19．2．2 交互图和契约
19．2．3 后置条件只是一个估计
19．2．4 协作图和概念模型
19．3 销售点系统的概念模型
19．4 销售点系统的协作图
19．5 协作图：enterItem
19．5．1 选择控制者类
19．5. 2 显示商品描述信息和价格
19．5．3 创建一个新的Sale实例
19．5．4 创建一个新的SalesLineItem实例
19．5．5 查找一个ProductSpecification
19．5．6 ProductCatalog实例的可见性
19．5．7 从一个数据库中检索ProductSpecification对象
19. 5．8 enterItem的协作图
19．5．9 发送给多对象的消息
19．6 协作图：endSale
19．6．1 选择控制者类
19．6．2 设置Sale.isComplete属性值
19．6．3 显示信息
19．6．4 计算销售项总额
19．6．5 计算销售项总额的协作图
19．7 协作图：makePayment
19．7．1 选择控制者类
19．7．2 创建支付项
19．7．3 记录销售项
19．7．4 计算余额
19．8 协作图：StartUp
19．8．1 何时建立startUp的协作图
19．8．2 应用程序如何启动
19. 8．3 startUp系统操作的解释
19．8．4 销售点应用系统的 StartUP操作
19．8．5 选择初始化领域对象
19．8．6 持久化对象：ProductSpecification
19．8．7 Store－crecte（）的协作图
19．9 从表示层到领域层的连接
19．10 小结
第20章 判定可见性
20．1 导言
20．2 对象之间的可见性
20．3 可见性
20．3．l 属性可见性
20．3．2 参数可见性
20．3．3 局部声明可见性
20. 3. 4 全局可见性
20．4 可见性的UML表示法
第21章 设计类图
21．1 导言
21．2 活动及其相互之间的依赖关系
21．3 何时创建设计类图
21．4 设计类图示例
21．5 设计类图
21. 6 如何建立设计类图
21．7 概念模型和设计类图的对比
21．8 建立销售点系统的设计类图
21．8．1 识别出软件类并画出它们
21．8．2 添加方法名
21．8．3 方法名：所要考虑的问题
21. 8．4 方法名--crecte
21．8．5 方法名--访问方法
21．8．6 方法名--多对象
21．8．7 方法名--独立于程序设计语言的语法
21．8．8 方法名--添加更多的
类型信息
21．8．9 添加关联和导航
21．8．10 添加依赖关系
21．9 成员细节的表示法
21．10 样例模型
21．11 小结
第22章 系统设计要点
22．1 导言
22．2 经典的三层体系结构
22．3 面向对象的多层体系结构
22．3．1 应用逻辑层的分解
22．3．2 超过三层--多层体系结构
22．3. 3 部署
22．3．4 多层体系结构的动机
22．4 用UML包描述体系结构
22．4．1 包的UML表示法
22．4. 2 体系结构包图
22．4．3 包和依赖关系举例
22．5 包的识别
22．6 层和划分
22．7 两个包中类之间的可见性
22．8 服务包接口--虚包模式
22．9 窗口不直接对外可见--模型一视图分离模式
22．9．1 模型一视图分离的意义
22．9．2 模型一视图分离和间接通信
22．10 一个系统中的间接通信
22．10．1 出版一订阅模式
22．10．2 回调
22．10．3 事件通知系统
22．11 应用协调者
22．11．1 应用协调者和窗口对象
22．11．2 自产的应用协调者
22．12 存储和持久化
22．13 样倒模型
第五部分 构造阶段（1）
第23章 设计到代码的映射
23．1 导言
23．2 程序设计与开发过程
23．2．1 构造阶段的创造性和改变
23．2．2 代码的改变和迭代的过程
23．2．3 代码的改变、CASE工具和逆向工程
23．3 将设计映射到代码
23．4 从设计类图创建类的定义
23．4．1 用方法和简单属性定义一个类
23．4．2 加入引用属性
23．4．3 引用民性与角色名
23．5 根据协作图创建方法
23．5．1 POST类的enterItem方法
23．5．2 POST类的isNewSale方法
23．6 更新类的定义
23．7 代码中的包容器／集合类
23．8 异常和错误处理
23．9 定义Sale类的makeLineItem方法
23．10 实现的顺序
23．11 从设计映射到代码的小结
第24章 用Java实现的程序方案
第六部分 分析阶段（2）
第25章 选择第二个开发周期的需求
25．1 第二个开发周期的需求
25．2 假定和简化
第26章 关联多个用况
26．1 导言
26．2 何时创建单独的用况
26．3 使用includes关系的用况图
26. 4 使用includes关系的用况文档
26．4．1 例子
26．4．2 Buy Items用况
26．4．3 Pay by Cash用况
26．4．4 Pay by Credit用况
26．4．5 Pay by Check用况
第27章 扩展概念模型
27．1 销售点终端系统中的新概念
27．1．1 概念目录列表
27．1．2 针对用况采用名词短语策略来
直找概念
27．1．3 授权服务事务处理
27．1．4 POST概念模型--草案1
第28章 泛化
28．1 泛化
28．2 定义超类型和子类型
28. 2．l 泛化和类型定义
28．2．2 泛化和类型集合
28．2．3 于类型定义的符合
28．2．4 子类型集合的符合
28．2．5 什么是正确的子类型
28．3 何时定义一个子类型
28．4 何时定义一个超类型
28．5 销售点终端系统的类型层次
28．5．1 支付类型
28．5．2 授权服务类型
28．5. 3 授权事务类型
28．6 抽象类型
28．6．1 抽象类型的UML表示法
28．6．2 抽象类和抽象方法
28．7 对变化的状态建模
28．8 类层次和继承
第29章 包：组织模型元素的单位
29．1 导言
29．2 包的UML表示法
29．2．1 所有权和引用
29．2．2 包依赖
29．2．3 没有包图的包说明
29．3 如何划分概念模型
29．4 销售点终端系统的概念模型中的包
第30章 润饰概念模型
30．1 导言
30．2 关联类型
30．3 聚合与组成
30．3．1 UML中的聚合
30．3．2 组成聚合--实心菱形
30．3．3 共享聚合--空心菱形
30．3．4 如何确定聚合
30．3．5 显示出聚会的好处
30．3．6 销售点终端模型中的聚合
30．4 关联角色的名称
30．5 作为概念的角色与关联中的角色的对比
30．6 派生元素
30．7 限定关联
30．8 递归关联或自反关联
第31章 概念模型--总结
31．1 导言
31．2 领域概念包
31．3 核心服杂包
31．4 支付
31．5 产品
31．6 销售
31．7 授权事务
第32章 系统行为
32．1 系统顺序图
32．1．1 Buying Items用况的公共起点
32．1．2 信用卡支付
32．1．3 支票支付
32．2 新的系统事件
32. 3 契约
第33章 状态图中的行为建模
33．1 导言
33．2 事件、状态和转移
33．3 状态图
33．4 用况状态图
33．5 系统状态图
33．6 销售点应用系统的用况状态图
33．6．1 Buy Items用况
33．6．2 Start Up用况
33．7 需要状态图的类型
33. 7．1 状态无关和状态相关类型
33. 7．2 常见的状态相关类型和类
33．8 销售点应用系统中的其他状态图
33．9 说明外部和内部事件
33．9．1 事件类型
33．9．2 内部事件的状态图
33．10 其他的状态图表示法
33．10．1 转移动作和监护条件
33．10．2 嵌套状态
第七部分 设计阶段（2）
第34章 GRASP：用于职责分配的更多模式
34．1 GRAS：通用职责分配软件模式
34．2 多态
34．3 纯虚构
34．4 中介者
34．5 "不要和陌生人讲话"
第35章 用更多的模式进行设计
35．1 导言
35．2 状态（GoF）
35．3 多态（GRAS）
35．4 独身（GoF）
35．4．1 代码示例
35．4．2 独身的UML速记法
35．4．3 实现
35．5 远程代理和代理（GoF）
35. 6 虚包和设备代理（GoF）
35．6．1 包装
35．6．2 虚包
35 6．3 设备代理
35. 6．4 中介者
35. 6．5 封装和序列化
35．6．6 使用远程代理和设备代理
35．7 命令（GcF）
35．7．1 CreditPaymentApprovalReply--execute消息
35．7．2 CreditPaymentDenialReply--execute消息
35．8 结论
第八部分专题
第36章 其他的UML表示法
36．1 导言
36．2 通用的表示法
36．2．1 注解与约束
36．2．2 依赖关系
36．2．3 构造型与特性的规格说明
36. 3 接口
36．4 实现图
36．4．1 构件图
36．4．2 实施图
36．5 协作图中的异步消息
36．6 包接口
第37章 开发过程问题
37．1 导言
37．2 起因
37．3 一个成功过程的指导原则
37．4 迭代和增量开发
37．4．1 瀑布模型的生命周期的缺点
37．4．2 迭代开发的生命周期
37．5 用况驱动的开发
37．6 系统结构上的早期重点
37．7 开发中的各个阶段
37．7．1 产品版本发布
37．7．2 主要开发步骤
37．7．3 产品版本发布与开发周期
37. 7．4 计划和细化阶段
37．7．5 以调查研究为重点的构造阶段
37．7．6 主构造阶段
37．7．7 实施阶段
37．7．8 开发周期中的分析阶段
37．7．9 开发周期中的设计阶段
37．7．10 开发周期中的构造阶段
37．7．11 开发周期中的测试阶段
37．8 开发周期的长度
37．9 开发周期问题
37．9．1 并行的开发小组和开发周期
37．9．2 不明显的需求和技术体系结构
37．9．3 系统开发用况
37．9．4 并行开发过程中的依赖关系
37．10 体系结构层开发的时间调度
第38章 框架、模式和持久化
38．1 导言
38．2 问题：持久化对象
38．3 解决方案：持久化框架
38．4 什么是框架
38．5 框架的功能
38．6 PeristentObject超类
38．7 关键思想
38．8 映射--用关系表来表示对象模式
38．9 对象身份--对象标识符模式
38．10 代理--数据库代理模式
38．11 框架设计--模板方法模式
38．12 具体化一一一一M板方法模式
38．13 缓存对象--缓存管理模式
38．14 智能引用--虚拟代理、桥模式
38．14．1 泛化的虚拟代理
38．14．2 不需要公用的PersistentObject超类
38．14．3 虚拟代理的实现
38．15 虚拟代理和数据库代理
38．15．1 虚拟代理和数据库代理的连续--工厂方法模式
38．15．2 为每件事物都设置一个代理
38．16 如何用关系表来表示关系
38．17 复杂对象实例化模式
38．17．1 问题：具体化一个组合关系层次
38．17．2 解决方案：请求式具体化
38．17．3 实例：chlesLinelem的具体化
38．18 事务操作
38．18．1 对象的事务状态
38．18．2 变"脏"
38．18．3 被删除
38．18．4 提交操作
38．18．5 回滚操作
38．19 在持久化存储器中寻找对象
38．20 其他设计方案
38．20．1 元数据和参数化的代理
38．20．2 查询对象
38．20．3 改变代理程序和内存中的数据库代理
38．20．4 事务处理状态与多缓存
38．21 尚待解决的问题
附录A 推荐读物
附录B 样例开发活动和样例模型
参考文献
术语表
索引
