2、主成功场景和所有场景扩展都包含的元素
|
|
主成功场景 |
扩展场景 |
|
场景执行的条件 |
前置条件加上触发事件 |
扩展条件 |
|
完成的目标 |
用例的名称 |
完成用例目标，或者是在处理扩展场景后重新进入主成功场景 |
|
执行步骤集 |
场景主体 |
|
|
结束条件 |
结束时完成的目标 |
|
|
作为场景片断的、可能的扩展集 |
用例模板中的扩展部分 |
可以嵌入到扩展体中，或者写在扩展体里面，或者就写在扩展体的后面 |
3、场景主体：每个场景或片段被描述为由不同执行者完成目标的活动序列
序列即无判断和循环，这是用例描述的基本特点。
这一节解释了第二章的一个疑问：
场景主题必须把这三步描述完成（括号里文字是例子）：两个执行者之间的交互（“顾客输入地址”）——为了保护项目相关人员利益的确认过程（“系统确认PIN密码”）——满足项目相关人员利益的内部变化（“系统从余额中扣除一定数量的金额”）
4、执行步骤时对用例的补充，并且都有统一的语法形式，在一个简单活动中，执行者完成任务或向另外的执行者发送信息。
5、执行步骤的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大原则，目的就是为了让用例成为用户和开发人员沟通的桥梁，所以语言要简单易懂，而且要逻辑清晰。
6、步骤编号使步骤更清晰，并在扩展部分给出引用的位置。完整的用例格式需要编号。