用Use Cases捕获需求
Pete McBreen，译：UMLChina.苏康胜（cancan28@163.net）
概述
开发者们经常通过一些典型的情节去理解系统并知晓系统如何工作，不幸的是他们虽然努力地去做了这些工作却很少以一种有效的方式去说明，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捕获需求来自www.itwen.comIT WEN计算机教程网
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之间如何关联的“大图”和获得系统上下文的大体描述来说是非常重要的。
Pete McBreen，译：UMLChina.苏康胜（cancan28@163.net）
概述
开发者们经常通过一些典型的情节去理解系统并知晓系统如何工作，不幸的是他们虽然努力地去做了这些工作却很少以一种有效的方式去说明，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之间如何关联的“大图”和获得系统上下文的大体描述来说是非常重要的。
