《编写有效用例》学习笔记

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