用Use Cases捕获需求

概述 

开发者们经常通过一些典型的情节去理解系统并知晓系统如何工作，不幸的是他们虽然努力地去做了这些工作却很少以一种有效的方式去说明，Use Cases正是一种形式化捕获这些情节的技术。 

仅管Use Cases在一本对象方面的书《Object Oriented Software Engineering》中有过定义，是跟那些对象结合在一起的，但这项技术实际上是独立于面向对象的，Use Cases是既能捕获商业处理流程又能捕获系统需求的有效方法，并且它本身比较简单和容易掌握。 

使需求有利于回顾 

以正规形式捕获这些情节的原因是有利于用户和开发者进行回顾，这里有2点关于一些实用需求符号的明确标准要遵循： 

1） 它必须让情节的发起者和回顾者都很容易理解 

2） 它不需包括一些关于系统样式和内容的决策 

实用的需求是评估设计和最终实现系统的客观需求。 

对于这些需求来说，必须要做的是以一种可实现的并不受约束的方式去捕获风险承担者的需要和期望。 

Use Cases使需求有利于回顾 

Use Cases已经得到越来越广泛的应用，它与其它需求捕获技术相比，它成功的原因在于： 

1  Use Cases把系统当作一个黑盒 

2  Use Case 使在需求中看到实现的决定变得更加容易 

最后一点源于第一点的补充，一个Use Case没有指定任何这些需求相关的系统的内部结构，所以说，如果这个Use Case中陈述了“提交改变到定单数据库”、“显示结果到Web页面”等的话，那么内部结构是显而易见的，并造成对设计的潜在约束。 

为什么这些需求不指定内部结构的原因是，说明的内部结构给设计者带来了额外的约束，没有这些约束设计者们能更自由地建立一个正确实现客观可见行为的系统，并存在出现突破方案的可能性。 

Use Cases的工业接受 

Use Cases第一次被正式的描述是在6年前（1992年），从那以后它就被最主要的面向对象的方法采用，同时作为描述现在和将来的操作模式的有用技术被商业再生工程团体（Business Process ReEngineering Community）采用。 

Use Cases最近它们自己取得在UML（Unified Modeling Language）中有效的地位和位置而得到了突出的进步。UML已经被OMG（对象管理组织）计划做为对象系统的标准语言。 

什么是Use Cases？ 

Use Cases本身是用户或其它系统与正在设计的系统的一个交互，是为了达到一个目标。术语Actor（行为者）是用来描述有这个目标的人或系统，这个术语是用来强调有这个目标的任何人或系统。目标的本身是用行为动词开始的短语表达的，如：“Customer : place order”、“Clerk : reorder stock”等。 

情节的角色 

在Use Cases中不同的情节显示了目标怎样成功或失败，成功的情节是目标达到了，失败的情节是目标没有达到。这个的好处是因为目标总结了系统的各种使用的意图，用户能看到被设想怎样地使用这个系统，并且不必等到出现第一个原型或是比较糟糕的等到系统被开发出来才发现什么时候系统并不全面地支持他们的目标。 


Use Cases将做成多大？ 

试图决定Use Case的大小是一个很有趣的话题，处理这件事的一个方法是将Use Case的大小跟它的意图和范围关联起来，对于一个真正大的范围来说，一个Use Case并不要在一个系统中处理那么多，但这些系统都用于同一商业领域，称为Business Use Case，它把整个公司看作一个黑盒和Actor关于公司目标的说明。这些Business Use Case的情节不容许假定任何公司内部的结构，一个客户将向公司下一个定单而不是客户服务部门。 

对于系统发展而言，Use Case的范围限制一个单一的系统，这是Use Cases最通常的形式，我们称之为System Use Case，它把整个系统看作是一个黑盒，它不指定任何内部结构并且仅受限于问题域的语言描述。 

Use Cases的另一范围是设计子系统和系统内部组件的，称为Implementation Use Cases，它把组件看作一个黑盒，并且这些Actors是区分它的成员。例如：可能会用Implementation Use Cases去说明应用系统中email组件的需求。 

给出了这些分类，关于Use Case的大小话题变得容易了，设计这些项的范围来调整整个大小。帮助系统设计者，每个Use Case只描述没有大的分支的行为的单个线索。违背这个规定，Use Case看起来通常是不准确的或含糊的，作为测试说明的资源和参考，它也是很难使用的。 

看看System Use Case的例子，“从数据库中查询低库存的”它太小了，容易跟需求的实现细节混淆。对比一下，作为System Use Case，“仓库管理”就太大了，它不能实现作为没有大的分支的行为的单一线索的原则，并且从系统的观点来说，它很难说明成功的目标，但它可以做为一个好的Business Use Case，对于配件部门来说，它可以定义“仓库管理”这一成功的目标（可能是根据库存调整、配件验收、成本操作等）。 

这些Business Use Case的好处是它们能用于区分其它的Use Cases，就如：“仓库管理”可用于组织这些用于实际管理仓库的Use Cases。 

Use Cases的正式定义 

Use Case：特殊行为者（Actor）的价值的量化结果的提交 

正如前面所说的，Actors可以是人也可以是正在设计的系统与之交互的外部系统，一个Use Case要求有一个量化的结果，从单个线索的需要提交。做为量化结果的组成，目标要么成功要么失败，没有其它的情况。 

达到主要Actor的目标定义为成功，结果没有迎合主要Actor的目标定义为失败，不同的情节显示了成功或失败的途径。 

Use Cases的说明 

Use Cases的好处是一些情节能用不同程度的正规化的文字说明。每个情节涉及Use Cases中单一的途径，细节是条件组。 

不正规的文本描述也能使用，不过当条件较多和可能失败的情况下它们很难跟随下去。开始试图理解需求时，不正规的叙述风格也是非常有用的，然而随着Use Cases的进展，使用更加正规的机制去说明Use Cases才是有用的。 

下面是客户对Use Case“下定单”的粗略概略： 

“确定客户，找出需要的并且仓库里还有的物品并检查客户信用额是否够用” 


　结构化叙述的格式已经被证明是非常有效的。这个格式所做的事是描述每一个情节的行为者：目标语句对的顺序。在这个顺序中，每一个行为者：目标的语句对都假设前一个的目标是成功的，右面是一个简单的范例： 

Use Cases认为我们正在设计的系统是一个单一的黑盒，根本没有任何内部结构被记录下来，并且它被认为是一个情节产生的目的及对应单一的行为者（Actor）。这些Use Cases没有表示任何关于系统内部的东东，只是表示系统将达到什么样的目标及由什么（人或其它系统）操作和负责。





处理目标失败-----延伸部分 

下面要做的是确定以上的每一步中可能会发生的失败，对于这种情况那些可能造成失败的条件做为延伸部分来捕获。这些扩展是通过在失败条件下直到可以重新入轨或失败的情节来处理的。 

失败条件的分离使情节变得可读了，一般情况都是以最简单的途径通过Use Cases的，它的每一步，行为者（Actor）的目标都是成功的。分开列出所有可能造成失败的条件给予了更好的品质保证。回顾者可以很容易的检查是否所有造成失败的条件都被指定及哪些潜在的条件被忽略。失败的情节要么可以恢复要么不可以恢复，可恢复的情节最终取得成功，不可恢复的情节直接失败。 

失败中的失败 

当失败情节下还有其它失败发生，需特别的标示出来，也就是说，在延伸部分中用更长的前缀标记更深一层的失败情节，如：1a1b、客户是个不讲信用的，它的恢复通过1a1b1。 

为什么使用结构化叙述格式 

结构化叙述的价值在于它是可驳倒的描述，所谓可驳倒的描述是它足够明确，以至可以给人去争辩和提出异议。 

“流程不是那样的” 

“为什么开单之前不检查是否有用呢？” 

“你少了好几步哦” 

对比之下，那种用非正规叙述形式描述的粗略概略是很难去驳倒的，但它有利于早期对问题域的理解。 

可驳倒的描述方式的价值的另一种描绘是，当你说明Use Cases时期望从用户和开发者处获得关于Use Cases品质的反馈。自想在开发过程的中及早的得到修正，它是非常有价值的。用户典型的反馈是不同顺序的问题，可能是平行的或是缺少的步骤。开发者典型的反馈是关系到特殊失败条件的意思和如何检测到它是否清晰的要求。 

Use Cases的图形符号 

这里是Use Cases的图形符号描述，UML中一个单一的“Stick-Man”符号标示行为者（Actor），用椭圆标示Use Cases，如图一所示。这些图对于你想看到Use Cases之间如何关联的“大图”和获得系统上下文的大体描述来说是非常重要的。 



Use Cases图没有显示不同的情节，它们的意图是显示行为者和Use Cases之间的关系。所以Use Cases图需求用结构化叙述文本来补充。UML提供一些可供选择的图来显示不同的情节，这些常规的图形有交互图、活动图、顺序图、状态图等。使用这些图的主要缺点是它们不象文本一样是紧密的，但它们能用于给出Use Case的整体感觉。对于这些图的协定的参考请见《UML Distilled》，作者Martin Fowler。 

需求重用取得 

按行为者：目标（Actor：Goal）的格式来描述Use Case的作用是它容许公共的功能性分解出来做为独立的Use Case。当执行公共部分的时候是指用于主要Use Case的。比如：Use Case下定单中的“确定客户”这一步骤可以用于其他Use Cases。 

Use Cases之间的另一关系是“延伸部分”，如果Use Case有一个失败恢复的步骤是复杂的，通常有三、四步，说是一个Use Case去扩展另一个Use Case。比如：当没有可用库存时，“Issue Raincheck”可能扩展Use Case“下定单”。 

Use Cases应用当中的复杂性和危险 

主要行为者（Actor）和Use Case之间没有连结 

一些情况下，从Use Case中取值的行为者（Actor）和积极参与这个Use Case的行为者（Actor）之间没有清晰的连结。如：财务主管能成为“发票确认”的行为者（Actor），但他未必是创建发票的人。这不是什么问题，这个Use Case仍然是正确的，它正说明行为者取值和设计的系统的范围外的Use Case发生的初始化之间的关系。主要行为者是有用的，因为这个人扮演的角色是当你说明Use Case时需要跟他说的人。 

情节步骤不需要连续 

情节中步骤顺序的情况是没问题的，这里有一些机制去突出可能的并行步骤。在UML中活动图是首选的机制，通过非正式地看Use Case的情节你可以注意到可能的平行步骤；可以看Use Case内一些邻近的步骤；也可以有相同的行为者（Actor）对步骤负责。之前我们举过的例子里，确认数量和确认信用额可能是平行的。有时候在Use Case的说明文档中标记这些可能的平行步骤是有用的。 

Use Cases的大小 

当开始做Use Cases的时候有个很显然的危险就是它要么有很多步骤要么就很少步骤。如果在Use Case中有超过15个步骤，它可能包含一些实现明细。如果它只有非常少的步骤则检查它的目标是否是达到一个没有很多分支的活动的单一线索。 

较少的人类行为者（Actor） 

如果Use Case有较少的人类行为者，而大多数行为者是其它系统，通常的做法是修改这个Use Case。寻找系统必须做出反映或公认的事件胜过会见这些行为者。 

需求捕获和系统复杂性 

总而言之，这些情节捕获到系统复杂度的同时行为者：目标语句对容许大的系统以相对压缩的格式说明。Use Case的格式的作用是用户和开发者能标志出行为者，然后确认这些行为者工作职责对应（或不对应）的目标，代替一个大的很难读的功能规格说明书。 

仅仅这样，用户和开发者就有足够的兴趣进而研究那些情节的细节。 

系统不仅仅有应得的功能性需求 

一些Use Cases并没有捕获所有的客观需求，仅仅是捕获了系统怎么用的那些功能性需求。然而还有许多方面的需求需要去捕获的。其中有的非功能性需求使用关联以至于也能隶属于个别的Use Case，如性能需求和系统容量的需求。另外的一些不是关联的而是要单独地去捕获，它们是以下的需求： 

l 系统范围 

l 系统用户的目标 

l 用户界面原型 

l 一般规则 

l 约束 

l 算法 

运行时期和建立时期的需求比较 

一个重要的因数要记住，就是系统的赞助者是大过用户团体的。系统中有许多的风险承担者，Use Cases仅仅捕获其中一些风险承担者的需要，具体说，Use Cases仅仅捕获系统运行时期的需求而忽略做为系统开发组织的风险承担者的需求，开发组织最有兴趣的是对建立时期需求的描述。 

运行时期需求包括：系统范围、用户组织对产品的期望和目标、Use Cases、其它非功能性需求。 

建立时期需求包括：减少开发成本、较少的变更处理、现存组件的重用。 

建立时期的需求可以部分的由Use Cases把握。但许多方面是需要由开发组织的处理的。 

l 项目范围和目标：项目必须提交什么。（和系统范围的区别是它提交的是所有项目的东西） 

l 增长性和变更请求：这些可以在捕获为常规Use Cases格式中的“Change Cases” 

l 开发负责人的约束：包括标准、习惯、工具、品质度量标准、品质保证原则、及品质保证的习惯。 

Use Cases的适用性 

Use Cases首先用于需要响应客观事件的系统。它们能用于提供了一个有很容易理解的目标的清楚的行为者的环境。当结果不可定义或不清晰时不能用Use Cases。意思是如果目标成功或目标失败不能有一个明确的定义，那么Use Cases不能用来捕获需求。 

然而说到这，现在大部分对象方法都使用Use Cases。因为Use Cases被证明是捕获需求的非常有效的机制。 

总结 

Use Cases以一种可读的、可驳倒的格式捕获需求。Use Cases是系统客观必需机能的可驳倒的描述。 

可驳倒的意思是当你说明Use Cases时期望从用户和开发者处获得关于Use Cases品质的反馈。 

Use Cases并没有从一开始就就明确的定义，它主要的开发顺序如下： 

1、 指出行为者（Actor） 

2、 指出行为者的目标 

3、 指出每一行为者：目标语句对的成功或失败的意思 

4、 指出每一Use Case的主要的成功的情节 

5、 在细化阶段，指出失败的条件及可恢复/不可恢复的情节 

只有做到了第四步才能决定哪一些的东西在Use Case中逐步开发出来。 

总而言之，Use Cases是非常有效的需求捕获技术，它能使需求变得容易回顾，并且避免在需求中有实现细节的偏好出现。