编写有效用例 (2010 年度畅销榜NO.943 )

在本书中，作者Alistair Cockburn凭借自己在面向对象领域的丰富经验，并参考其他专家的良好建议，扩展了典型的用例处理方法，为软件开发人员编写用例提供了一种“基本、具体和实用的”指南。本书完整地叙述了有关用例的初级概念、中级概念以及高级概念，并提供了大量的好用例和坏用例的编写实例。
本书荣获2001年度美国“软件开发”杂志的Productivity Award奖，是一本概念清晰、结构完整、内容丰富的专业图书，适用于不同知识层次的软件工程研究和用例编写人员。

译者序
译者简介
前言

第1章 引言 1
1.1 用例是什么（梗概） 1
用例1 通过万维网购买股票 2
用例2 汽车交通事故索赔 3
用例3 对运到的包装箱进行登记 4
1.2 你的用例不能作为我的用例 5
用例4 买东西(非正式版本) 7
用例5 买东西(完整正式版本) 7
◆ Steve Adolph 在新领域中“发现”需求 10
1.3 需求和用例 11
图1-1 “轮辐和轮轴”需求模型 12
1.3.1 用例作为项目连接结构 13
1.4 用例的增值点 13
1.5 合理安排你的精力 14
1.6 先用一个系统使用叙述热身 15
1.7 练习 16

第一部分 用例体部分

第2章 用例是规范行为的契约 19
2.1 具有目标的执行者之间的交互 19
2.1.1 执行者具有目标 19
图2-1 一个具有目标的执行者请求另一个执行者履行职责 19
2.1.2 目标可能失败 20
2.1.3 交互是复合的 21
2.1.4 用例聚集场景 23
图2-2 条形裤：成功场景和失败场景 23
图2-3 条形裤表现子目标 24
2.2 具有利益的项目相关人员之间的契约 24
图2-4 SuD为主执行者提供服务，同时维护幕后项目相关人员的利益 25
2.3 图形模型 25
图2-5 执行者和项目相关人员 26
图2-6 行为 27
图2-7 用例是职责的激发者 27
图2-8 作为组合的交互 27

第3章 范围 28
表3-1 “内/外”列表 28
3.1 功能范围 28
3.1.1 执行者-目标列表 29
表3-2 执行者-目标列表的示例 29
3.1.2 用例简述 29
表3-3 用例简述的示例 30
3.2 设计范围 30
图3-1 设计范围的大小是任意的 31
◆ 一个简短而真实的故事 31
3.2.1 用图标来突出设计范围 32
3.2.2 设计范围示例 32
(1) 企业—系统的范围 32
用例6 增加新服务(企业) 33
用例7 增加新服务(Acura) 33
(2) 一个应用程序对应多台计算机 34
用例8 输入和更新请求(联合系统) 34
用例9 添加新服务(进入Acura) 34
用例10 通知新服务请求(BSSO中) 35
用例11 更新服务请求(BSSO中) 35
用例12 通知更新后的服务请求(Acura中) 35
3. 基本用例 35
图3-2 Acura-BSSO的用例图 36
图3-3 Acura-BSSO的组合用例图 36
用例13 资源的串行存取 37
用例14 实施资源锁转换策略 38
用例15 实施存取兼容性策略 38
用例16 实施存取选择策略 39
用例17 令服务客户等待获得资源存取权限 39
3.3 最外层用例 40
3.4 使用范围确定的工作产品 41
3.5 练习 42

第4章 项目相关人员和执行者 43
4.1 项目相关人员 43
◆ 一个简短而真实的故事 43
4.2 主执行者 44
4.2.1 主执行者为什么有时是不重要的(而有时又是重要的) 44
4.2.2 执行者和角色 46
4.2.3 刻画主执行者的特点 47
表4-1 执行者概况表的示例 47
4.3 辅助执行者 47
4.4 被讨论系统 48
4.5 内部执行者和白盒用例 48
4.6 练习 48

第5章 三个命名的目标层次 50
图5-1 用例层次 50
5.1 用户目标(蓝色，海平面) 51
◆ 一个简短而真实的故事 52
5.1.1 蓝色的两个层次 52
5.2 概要层次(白色，云朵，风筝) 52
用例18 操作保险单+ 53
5.2.1 重温最外层用例的内容 53
5.3 子功能(靛青色/黑色，海平面以下/蛤) 54
5.3.1 目标层次总结 54
5.4 利用图标来突出目标层次 55
5.5 找出正确的目标层 55
5.5.1 找出用户目标 56
5.5.2 提升和降低目标层次 56
图5-2 通过问“为什么”的问题来转换层次 56
5.6 一个较长的编写实例：“处理申请”的多层次示范 57
用例19 处理申请(业务) 58
用例20 评估工作补偿申请 59
用例21 处理申请(系统)+ 60
用例22 损失登记 62
用例23 查找无论什么(问题陈述) 65
5.7 练习 65

第6章 前置条件、触发事件和保证 66
6.1 前置条件 66
6.2 最小保证 68
6.3 成功保证 68
6.4 触发事件 69
6.5 练习 69

第7章 场景和步骤 71
7.1 主成功场景 71
7.1.1 常见的环境结构 71
7.1.2 场景主体 72
7.2 执行步骤 73
7.2.1 准则 73
准则1：使用简单的语法 73
准则2：明确地写出“谁控制球” 73
准则3：从俯视的角度来编写用例 74
准则4：显示过程向前推移 74
准则5：显示执行者的意图而不是动作 75
准则6：包含“合理”的活动集 76
图7-1 一个事务由四个部分组成 76
准则7：“确认”而不是“检查是否” 77
准则8：可选择地提及时间限制 78
准则9：习惯用语：“用户让系统A与系统B交互” 78
准则10：习惯用语：“循环执行步骤x到y，直到条件满足” 78
7.2.2 编号或不编号 79
7.3 练习 80

第8章 扩展 81
8.1 扩展的基础 81
8.2 扩展条件 82
8.2.1 集中讨论所有可能的失败和可选择的过程 83
准则11：用“检测到什么”的方式来编写条件 83
◆ 一个真实的、令人不快的小故事 84
8.2.2 扩展列表的合理化 85
8.2.3 逐层合并失败 85
8.3 扩展处理 86
准则12：条件处理的缩排方式 88
8.3.1 失败的嵌套 88
8.3.2 从扩展中创建新用例 89
8.4 练习 90
第9章 技术和数据的变化 91
图9-1 在UML中使用具体化方式表现技术变化 92

第10章 连接用例 93
10.1 子用例 93
10.2 扩展用例 93
图10-1 扩展用例的UML图 94
10.2.1 什么时候使用扩展用例 95
10.3 练习 96

第11章 用例格式 97
11.1 供选择的格式 97
11.1.1 完整正式的用例格式 97
用例24 完整正式的用例模板 97
11.1.2 非正式的用例格式 98
用例25 实际登录(非正式版本) 98
11.1.3 单列表格格式 98
表11-1 用例的单列表格格式 98
11.1.4 双列表格格式 99
表11-2 双列表格 100
11.1.5 RUP格式 100
用例26 登记课程 101
11.1.6 条件语句格式 103
11.1.7 Occam格式 103
11.1.8 图形方式 104
11.1.9 UML用例图 104
11.2 影响用例书写格式的因素 104
11.3 五种项目类型的标准 107
11.3.1 需求了解阶段用例 108
用例27 需求了解用例模板—oble a New Biscum 108
11.3.2 业务过程建模用例 108
用例28 业务过程用例模板—Symp a Carstromming 108
11.3.3 确定系统需求用例规模 109
用例29 确定系统需求用例规模模板—Burble the Tramling 109
11.3.4 短期、高强度的项目用例 110
用例30 高强度项目用例模板—Kree a Ranfath 110
11.3.5 详细功能需求用例 110
用例31 用例名称—Nathorize a Permion 110
11.4 总结 111
11.5 练习 111

第二部分 经常讨论的主题

第12章 什么时候才算完成 115
12.1 关于“正在完成” 116

第13章 扩展到多个用例 117
13.1 简单描述每个用例(低精度表示) 117
13.2 创建用例簇 117

第14章 CRUD和参数化用例 119
14.1 CRUD用例 119
用例32 管理报表用例 119
用例33 存储报表用例 121
14.2 参数化用例 123

第15章 业务过程建模 125
15.1 建模与设计 125
15.1.1 从核心业务 125
图15-1 核心业务黑盒 126
图15-2 白盒用例中的新业务设计 126
15.1.2 从业务过程到技术 126
图15-3 白盒用例中的新业务设计（又一次） 127
图15-4 黑盒系统用例中的新业务过程 127
15.1.3 从技术到业务过程 128
15.2 连接业务用例和系统用例 128
◆ Rusty Walters: 业务建模和系统需求 129

第16章 遗漏的需求 131
16.1 数据需求的精度 132
16.2 从用例到其他需求的交叉链接 133
图16-1 翻新图1-1，“轮轴和轮辐”需求模型 133

第17章 用例在整个过程中的作用 135
17.1 用例在项目组织中的作用 135
17.1.1 通过用例标题进行组织 135
表17-1 规划表的示例 135
◆ 一个真实的小故事 136
17.1.2 跨版本处理用例 136
17.1.3 交付完整场景 137
◆ 一个短而真实的集成实例 137
17.2 从用例到任务或特征列表 137
用例34 获得折扣 139
表17-2 “获得折扣”任务列表 139
17.3 从用例到设计 140
◆ 一个真实的小故事 141
17.3.1 面向对象设计者特别注意 141
17.4 从用例到用户界面设计 142
17.5 从用例到测试用例 143
用例35 订购商品，产生发货单（测试用例） 143
表17-3 主成功场景测试（好信用） 144
表17-4 主成功场景测试（坏信用） 144
17.6 实际用例编写 144
17.6.1 分工合作过程 144
17.6.2 用例需要的平均时间 147
17.6.3 从大型团队中收集用例 147
◆ Andy Kraus：从庞大的不同地位的团队那里收集用例 147

第18章 用例概述和极端编程 151
第19章 错误改正 152
19.1 没有系统 152
19.2 没有主执行者 153
19.3 过多的用户接口细节 153
19.4 过低的目标级别 155
19.5 目标和内容不符 156
19.6 用户接口描述过多的改进实例 156
用例36 寻找一种解决方案—修改前 157
用例37 寻找可能的解决方案—修改后 161
第三部分 对忙于编写用例的人的提示

第20章 对每个用例的提示 167
提示1：每个用例都是一篇散文 167
提示2：使用例易于阅读 167
提示3：仅用一种句型 168
提示4：“包含”子用例 168
提示5：谁控制球 169
提示6：正确地得到目标层 169
提示7：不考虑GUI 169
图20-1 问“为什么”来提高层次 170
提示8：两个结局 170
提示9：项目相关人员需要的保证 171
提示10：前置条件 172
提示11：对用例进行通过/失败测试 172
表20-1 对用例进行通过/失败测试 172

第21章 对用例集的提示 174
提示12：一个不断展开的故事 174
提示13：业务范围和系统范围 174
提示14：核心价值和变化 175
提示15：用例集中的质量问题 177

第22章 处理用例的提示 178
提示16：仅仅是第3章(第4章在哪儿呢？) 178
提示17：首先向广度上努力 178
图22-1 工作随着细化而增加 178
提示18：12步秘诀 179
提示19：认识错误的代价 180
提示20：喜欢蓝色牛仔服 180
◆ 一个真实的小故事 180
提示21：处理失败情况 181
提示22：前期和后期的工作标题 181
提示23：执行者扮演角色 181
提示24：大的图画恶作剧 182
图22-2 “妈妈，我想回家。” 182
图22-3 椭圆图形式的语境图 183
表22-1 语境图的执行者-目标列表 183
提示25：大型工具的争论 184
提示26：使用标题和简介的项目计划 185

附 录

附录A UML的用例 189
A.1 椭圆和“小人”图符 189
A.2 UML的包含关系 189
图A-1 包含关系的画法 190
准则13：将高层目标画得高一点 190
A.3 UML的扩展关系 190
图A-2 扩展关系的画法 191
准则14：将扩展用例画得低一点 191
准则15：使用不同形状的箭头 191
A.3.1 正确地使用扩展关系 192
图A-3 扩展一个基用例的三个中断用例 192
A.3.2 扩展点 192
A.4 UML的泛化关系 193
A.4.1 正确地使用泛化关系 193
图A-4 泛化关系的画法 194
准则16：将泛化目标画得高一点 194
A.4.2 泛化的危害 194
图A-5 泛化的危害—终止大交易 195
图A-6 改正后的终止大交易 195
A.5 从属用例与子用例 195
A.6 用例图的画法 196
准则17：语境图中的用户目标 196
准则18：将支持执行者放在右边 196
A.7 代之以编写基于文本的用例 196
附录B 部分练习题答案 198
第3章练习题 198
练习3-1 198
练习3-2 198
图B-1 ATM的设计范围 198
第4章练习题 198
练习4-2 198
练习4-3 199
第5章练习题 199
练习5-1 199
练习5-2 200
第6章练习题 200
练习6-1 200
练习6-4 200
第7章练习题 200
练习7-1 200
练习7-2 201
练习7-4 201
用例38 使用订单处理系统 202
第8章练习题 202
练习8-1 202
练习8-5 203
用例39 通过万维网购买
股票 203
第11章练习题 204
练习11-1 204
用例40 执行清洁火花塞
服务 204
附录C 术语表 205
主要术语 205
用例类型 206
图形 207
附录D 参考文献 208
本书参考图书目录 208
本书参考文章目录 208
有用的在线资源 209
索引 210

为了描述行为需求、软件系统或业务流程，用例正在被越来越多的人所使用。初听起来，编写用例似乎是件很容易的事—只需要写清楚如何使用系统就可以了。但是，当提笔编写时，首先碰到的问题就是：“到底应该写些什么？多写一些？还是少写一些？详细程度如何？”这些问题确实很难回答。编写用例就像写散文一样，全部困难在于既要采用单调的写作方式，又要富有完美的表达能力。很难说什么样的用例是好的用例，但是我们却可以去考虑：如何去写，才能写出好的用例。 本书给出了我在用例编写和培训中总结出的一些指导性原则：应该如何思考，需要作何观察，最终写出更好的用例和用例集。 本书还给出了大量的例子，既有好的用例，也有不好的用例，以及在不同情况下的编写方式。最重要的是要记住，我们需要的是有用的用例，而不必是一个最好的用例。有时即使是很平常的用例也很有用，甚至远胜于编写许多需求文档。所以无需太紧张，只要写出的东西可读，就说明你已经作出了贡献。 本书的读者 本书主要是针对业界专业人员自学而编写的，因此在组织方式上也有所侧重，就像一本自学指南。本书由浅入深，每一部分都包括概念、示例、提示和练习(以及部分答案)。 编写用例的培训教师应给出适当的解释和示例。课程设计人员可以围绕本书设计课程资料，在必要时作为指定读物发布（由于我对许多练习都给出了答案，因此他们必须编写属于自己的考试材料）。 本书的组织 本书开始部分是一般性的引言，之后对用例体部分进行了更详细的阐述，然后是常见的问题，对忙于编写用例的人的提示，以及最后的注意事项。 “引言”部分对重要概念作了初步介绍，依次讨论了以下问题：“用例是什么样的？”、“何时编写用例？”和“什么样的用例是合法的？”。所有问题的答案都是根据具体情况（如时间、地点、人员及编写的理由等）而确定的。关于这几个问题的讨论虽从本章开始，但实际上贯穿本书。 “第一部分，用例体部分”，由若干章组成，分别阐述了需要掌握的重要概念，以及应编写的模板。这些章包括“用例是规范行为的契约”、“范围”、“项目相关人员和执行者”、“三个命名的目标层次”、“前置条件、触发事件和保证”、“场景和步骤”、“扩展”、“技术和数据的变化”、“连接用例”和“用例格式”。 “第二部分，经常讨论的主题”，列举了反复出现的特殊问题：“什么时候才算完成了？”、“扩展到多个用例”、“CRUD和参数化用例”、“业务过程建模”、“遗漏的需求”、“用例在整个过程中的作用”、“用例概述和极端编程”和“错误改正”。 “第三部分，对忙于编写用例的人的提示”，包含了一组提示，针对那些已经阅读完本书，或者已经了解这些资料，想要回顾一下关键概念的人们。这部分包括：“对每个用例的提示”、“对用例集的提示”和“处理用例的提示”。 本书概念的来源 在20世纪60年代后期，Ivar Jacobson在爱立信公司电话系统工作时提出了后来成为众所周知的“用例”。在20世纪80年代后期，他将用例引进了面向对象编程领域，在面向对象编程领域内人们认识到用例可以填补需求分析过程中一个明显的空白。我在20世纪90年代初参与了Jacobson的课程。他和他的小组没用我所使用的目标（goal）和目标失败（goal failure）这两个词，但最后我终于明白了他们曾经使用过类似的概念。经过几次比较，他和我都发现我们两个模型之间没有显著的区别。我慢慢地根据最近的想法扩展了他的模型。 在1994年我为IBM顾问组编写用例指南时，建立了执行者（Actor）和目标（Goal）概念模型。从而把用例中一些难以理解的事情解释清楚了，并且为如何构造和编写用例提供了指导。从1995年开始，执行者和目标模型就在http://members.aol.com/acockburn以及后来的www.usecase.org中正式使用，最后出现在1997年《面向对象编程杂志》上我写的一篇文章中，题为“构造带目标的用例”。 从1994年到1999年，尽管在理论上还有几个松散的分支，但用例模型的概念基本保持稳定。在教授和培训过程中，我终于明白了人们为什么在简单的概念上花费了大量时间（我竟然从来没想到，我第一次尝试时也犯过很多同样的错误！）。这些想法，加上执行者和目标模型中一些不合理之处，产生了本书以及项目相关人员（Stakeholder）和利益（Interest）模型，该模型是本书提出的一个新概念。 统一建模语言（Unified Modeling Language, UML）对这些概念只有很小影响，反之亦然。Jacobson以前的一个同事Gunnar Overgaard编写了大量UML用例的资料，并且保持了Jacobson的风格。然而UML标准开发组受画图工具的影响很大，以至于用例的文本特征在标准中消失了。Gunnar Overgaard 和Ivar Jacobson讨论了我提出的概念，并向我保证这些关于用例的大部分概念都适合于放在UML的一个椭圆图中，因此既不会影响UML，也不会受UML标准所提出的概念影响。这意味着你可以使用本书的概念，并与UML 1.3用例标准兼容。另一方面，如果你只读了UML标准，由于它根本没有讨论用例的内容以及如何去编写，那么你也不知道用例到底是什么、如何使用，并且还可能产生一个危险的想法，即用例是由图形而不是由文本构成的。本书的目的是告诉你如何编写有效的用例，而标准很少谈及这些内容，因此我把对UML的评述单独地放在附录A中。 本书所用的实例 本书编写的实例尽可能取自实际项目，并且有些实例看起来可能不太完美。我所要展示的是，这些实例对项目组的需求来说已经足够了，并且用例编写过程中的那些不完美之处是在误差和经济允许的范围内。 Addison-Wesley的编辑们说服我把这些实例从原有形式中整理出来，以便强调它们正确的形式，而不是它们实际的和可用的形式。希望你通过阅读这些实例发现一些有用之处，并了解项目中的实际编写过程。你可以应用我在这些实例中采用的一些规则，并找到改进它们的方法。这种事情经常发生。因为改进一个人编写的实例是一件永无止境的事情，所以我接受这个挑战和任何批评意见。 “软件专业人员集锦”中的用例 “软件专业人员集锦”（The Crystal Collection for Software Professionals）只是图书选集之一，强调了一直被忽略的、发挥人的能动性的软件开发技术。其中一些书讨论了某种技术，一些书讨论了项目中的角色，一些书讨论了开发组协作的观点。 “集锦”遵循下面两个原则： 软件开发是创造和交流相互作用的游戏。当我们提高开发人员的个人技术和开发组协作效率时，它得到了改进。 不同的项目有不同的需求。系统有不同的特征，由大小不同的开发组研制，并且开发组成员有着不同的价值观，优先考虑的事情也不同。因此不可能定义一个最好的软件开发方法。 “集锦”中的基础读物—《Software Development as a Cooperative Game》—详细描述了这样一些观点：软件开发是一种合作游戏，方法学是一种合作文化，以及方法学系列化。该书分别对方法学的不同侧面、技术与活动、工作产品和标准进行了讨论。用例需要讨论的精髓出现在本书的1.2节“你的用例不能作为我的用例”。 《编写有效用例》是一本技术指南，描述用例编写的基本过程。尽管你可以在几乎所有项目中使用这些技术，但是必须根据每个项目的实际需要选择模板和编写标准。