《编写有效用例》第一篇阅读体会
十月十日，第一篇阅读体会，时间过得飞快，国庆假期回来还没几天就到了时间，看这本书的时间也很少。
编写有效用例为软件开发人员编写用例提供了一种“基本、具体和实用的”指南。本书完整地叙述了有关用例的初级概念、中级概念以及高级概念，并提供了大量的好用例和坏用例的编写实例。从需求的层次上来讲需求包括业务需求、用户需求、功能需求、非功能需求。本书通过使用有效用例来收集与提取用户需求，描述详细的用户需求细节。按照完整正式用例格式与非正式用例格式编写用例；编写有效用例需要注意的一些细节问题。
一、需求与用例之间的关系
1、 用例确实是需求。如果用例编写恰当，可以准确地对系统必须做什么进行详细的描述。
2、 用例不是所有的需求。用例不详细地描述外部接口、数据格式、业务规则和复杂公式。用例只是收集了所有需求中的一部分。
二、如何编写一个好的用例
想学会如何阅读用例是很容易的，但是学会编写一个好的用例却不容易。编写者必须掌握三个概念：
范围：真正被谈论的系统是什么？
主执行者：谁有要实现的目标？
层次：目标的层次是高还是低？
UML用例图
UML中的用例图是由椭圆、箭头和一些“小人”图符组成，它并不是用来捕获用例的。椭圆和箭头显示了用例的打包和分解，而不是用例的内容。
所有这些不同的用例格式都表达了大致相同的基本信息。用例之所以被广泛采用的主要原因是，用例详细地描述了系统被使用时的行为细节，使得用户能够明白新系统到底是什么样的。可以按照用例模版格式来书写用例，但是一个用例模版是不够的，至少要有两个用例模版：一个是非正式的（或随意的），在要求不严的项目中使用；另一个是完整正式的，在要求严格的项目中使用。任何项目都可以根据自己的实际情况对其加以调整。下面给出一个采用这两种风格编写而成的同一用例。
完整正式用例格式中一些概念
范围——用来描述项目开发人员负责的设计工作的边界，以便与应由其他人负责的设计工作或已经完成的设计工作相区别。
项目相关人员是指契约的参与者。
执行者是指任何具有行为的事物。执行者可能是一个人、一个公司或组织、一个计算机程序或一个计算机系统（硬件、软件或软硬件兼备的系统）。可以从系统的项目相关人员、用例的主执行者、被设计系统本身、用例的辅助执行者、内部执行者中寻找执行者。
三个命名的目标层次（用户目标、概要层次目标、子功能层次）
用户目标是主执行者努力使工作得以完成的目标，或是用户使用系统的目标，是基本业务过程。
概要层次目标包含多个用户目标。在描述系统时，它们有三方面的功能：显示用户目标运行的语境；显示相关目标的生命周期顺序；为低层用例提供一个目录表。
子功能层次的目标是指那些在实现用户目标时可能会被用到的目标。
前置条件是指该条件已经通过其他用例的执行进行了设置。用例的前置条件声明了启动该用例之前系统必须满足的条件。
最小保证是系统向项目相关人员作出的最低承诺，尤其是在主执行者的目标不能被满足的情况下。
成功保证说明了用例成功结束后项目相关人员的哪些利益得到了满足，用例可以通过执行主场景获得成功，也可以通过执行可选路径获得成功。
触发事件指明了启动用例的事件。有时，用例执行过程的第一步紧接着触发事件发生，有时触发事件就是用例中的第一步操作。
场景和步骤：
主成功场景就是主执行者完成了目标，所有项目相关人员的利益都被满足了的场景。
执行步骤时对用例的补充，并且都有统一的语法形式，在一个简单活动中，执行者完成任务或向另外的执行者发送信息。
执行步骤的10大准则
（1）使用简单的语法；
句子结构应该非常简单：主语……谓语动词……直接宾语……前置短语
例如 系统……从帐户余额中扣除……一定数量……
（2）明确地写出“谁控制球”；
作者举了踢足球的场景的例子，说明了不管步骤的执行者如何变化，都要遵循（1）描述的格式。
（3）从俯视的角度来编写用例；
从用户的角度来写用例，而不是从系统内部来描述系统
（4）显示过程向前推移；
可能是翻译的问题，意思应该是如果过程繁杂，超过了9步，那么考虑提高目标层次，即“向前推移”
（5）显示执行者的意图而不是动作；
通过操纵系统的用户界面来描述用户的动作，这是在编写用例时常见的一种严重错误，它使得编写的目标处于一个很低的层次。我把它叫做“界面细节描述（interface detail description）”。在需求文档中，我们只关心界面所要达到的意图，总结在执行者之间传递的信息。可将这些低层次的步骤合并成一个步骤。
（6）包含“合理”的活动集；
用例描述为了表现一个事务，分解成了四个步骤，而这些步骤各有其复杂度，书中给出了五种形式，一种比一种分步多，作者倾向于中间第三和第四种形式，不过他也提出要视具体步骤复杂度来确定采用什么形式
（7）“确认”而不是“检查是否”
这是一个经常犯的错误，写用例不是写程序流程，不需要用选择语法，需要选择的时候，在扩展场景里体现。
（8）可选择地提及时间限制；
（9）习惯用语：“用户让系统A与系统B交互”；
要分开来写，用户与系统A怎么怎么样，然后系统A和系统B怎么怎么样，这样用户才能看的懂。
（10）习惯用语：“循环执行步骤X到Y，直到条件满足”；
同（7），但如果需要重复的话，可直接在重复的步骤的前面和后面说明即可。
总之，这10大原则，目的就是为了让用例成为用户和开发人员沟通的桥梁，所以语言要简单易懂，而且要逻辑清晰。
扩展实质上是一个从主用例中被拆分的用例。扩展开始于一个与它相关的条件。它包含了一个执行步骤的序列，该序列描述了在这个条件下发生了什么。扩展以完成或放弃扩展目标作为结束。
技术和数据的变化：
扩展说明了系统所完成的目标是不同的，但有时需要表达“有多种不同方法来完成相同目标”。系统所完成的目标是相同的，但怎样做可能不同。这通常是因为技术的变化或输入数据的不同。应该将这些变化写到“技术和数据变化”列表，而不是写到扩展部分中。如果决定使用UML用例图，那么你可以为一个基本步骤创建一个空的。一般性的基用例，为每个变化创建一个具体的用例。
连接用例说明了用例关系中的include和extend关系。包括子用例和扩展用例。
1）、子用例：一个执行步骤可以是一个简单的步骤或者是另外一个用例的名称。
一般的，步骤如果用下划线或楷体字区别开写的话，这个步骤就是子用例。
2）、扩展用例
两个用例之间需要另外一种连接，这种连接很像扩展机制。其具有以下特征：
（1） 有一个主活动，主活动可以被中断
（2） 主活动可以被多种方式中断，并且不能控制中断
可以考虑使用与描述场景扩展相同的机制，但这里是创建新用例。新用例称为扩展用例（extension use case）它除了是独立的用例之外，其他都与场景扩展相同。扩展用例从一个条件开始，在基用例中该条件可能满足的地方被引用。应将所有的条件都放到模板的触发事件部分中。
编写有效用例需要注意的一些细节问题
1、每个用例易于阅读，不考虑GUI用户界面设计，项目相关人员的需要的保证（最小保证和成功保证），设置合理的前置条件，对用例进行通过、失败测试。
2、注意业务范围和系统范围，控制用例集中的质量问题。
3、处理用例注意扩展到多少个用例才合适，执行者扮演什么角色。