需求用例分析之一：异常流

问题的引出

备选流，又称备选事件流，英文是Alternative Flow。在RUP和UML中，备选流的解释如下：备选事件流包括与正常行为相关的可选或异常特征的行为，同时也包括正常行为的各种变形。您可以将备选事件流看作是基本事件流的“绕行道”，有些备选事件流将返回到基本事件流，而有些将结束此用例的执行。

分析RUP对于备选流的定义，可以看到备选流可以分成两类：

1，不同做法但仍然达成用例目标；

2，异常情况，无法达成用例目标。

在实际用例分析中，由于备选流可能存在两种情况，导致备选流存在2种主要写法：

1．在备选流中说明基本流以外的异常情况的处理，可能仍然回到基本流，也可能导致用例结束。

在备选流中说明基本流以外的其它正常和异常情况的处理，覆盖了其它功能。

第1种写法的例子比较常见，下文将出现，这里不再赘述。

第2种写法的例子如下：

用例名称：填写请购单

1.简要说明

员工在线填写图书请购单，内容包括：图书名称、出版社、作者、价格、订购人（系统自动识别）、订购部门、订购日期等，填好后提交给图书管理员审核。

填写请购单的主角是员工。

2.事件流

员工选择“填写请购单”，用例开始。

3.基本流

员工选择“填写请购单”，提交“填写请购单”请求；

显示“填写请购单”窗口并列表显示请购单信息（已填写未提交、已提交审核未通过）， 两种状态的请购单信息通过选择分别列出，审核未通过的原因只能查看不能修改；

请购单信息包括：请购单编码（系统自动生成）、订购部门、订购人、订购日期、订购原因、备注，和图书明细包括：图书名称、出版社、作者、单价、数量等，图书明细包括：新增，修改，删除；

请购单信息输入操作见备选流；

新增：系统具体执行见“备选流 新增”

修改：系统具体执行见“备选流 修改”

删除：系统具体执行见“备选流 删除”

选择“提交”，系统把选中的请购单提交给图书管理员审核，此用例结束。

4.备选流

填写请购单基本流中抽取出三个备选流：

请购单信息：新增、修改、删除；

1）新增

（一）员工在“填写请购单”信息区选择“新增”，提交“新增”请求；

（二）系统弹出“新增请购单”空白模式窗口；

（三）请购单信息包括：图书名称、出版社、作者、单价、数量等；

（四）请购单信息输入完毕后，选择“保存”提交，系统验证数据有效性，如验证不成功，针对所提示错误信息修正输入数据，验证成功关闭“新增请购单”窗口；

若继续新增请购单，则重复㈠㈡㈢㈣步骤。

2）修改

（一）员工在“填写请购单”信息区列表选中要修改的请购单，提交“修改”请求；

（二）系统弹出“修改请购单”模式窗口，并显示当前请购单信息；

（三）修改相应数据后，选择“保存”提交，系统验证数据有效性，如验证不成功则根据错误提示重新输入，验证成功后保存数据并关闭“修改请购单”模式窗口同时刷新请购单信息列表；

若继续修改，则重复㈠㈡㈢步骤。

3）删除

（一）员工在“填写请购单”信息区列表选中要删除的请购单，提交“删除”请求；

（二）若选中的请购单属于审核未通过，系统提示“不能删除审核未通过的请购单”；

（三）删除后刷新请购单列表信息同时系统提示“编号为XXX的请购单已删除！”；

若继续删除，则重复㈠㈡㈢步骤。

5.特殊需求

无

6.前置条件

员工登录系统。

7.后置条件

无

---例子结束----

第2种写法中，在备选流中说明了基本功能，用例篇幅已经变长，如果备选流中出现异常，备选流将显得更加臃肿。因此第2种写法比较少见。

为了解决备选流的不同情况，人们识别率异常流来解决上述问题。

异常流是什么？

Bernd Lohmeyer提出来如下分类规则（见 http://www.lohmy.de/2013/03/06/writing-use-cases-exception-or-alternate-flow/ ）

1.Result negative: An Exception is anything that leads to NOT achieving the use case’s goal. 负面结果：异常，任何导致不能达成用例目标的事情

2.Result positive: An Alternate Flow is a step or a sequence of steps that achieves the use case’s goal following different steps than described in the main success scenario. But the goal is achieved finally. 正面结果：备选流，一步或多个步骤序列达成了用例目标，但与主成功场景不一样的步骤。最终目标是达成的。

见如下例子：

简单说：异常流是基本流的异常情况，不能达成用例目标。

用异常流替代备选流

苍狼敏捷需求用例分析方法对于备选流的做法是采用第1种做法，但用异常流替代备选流，从名称上排除第2种做法，满足用例目的的可选流程在基本流中表达，如果导致基本流篇幅过长，那么就分拆用例。

对照到上述“填写请购单”的例子，苍狼敏捷需求用例分析方法至少分拆成如下多个用例：

1，新增请购单

2，修改请购单

3，删除请购单

其中新增请购单的用例规约

异常流的好处

根据以上分析，可以看到，异常流实质上是一种备选流，对照原RUP备选流说明的话，定义如下：异常流是与基本流正常行为相关的异常行为。
异常流不是基本流的“绕行道”，有些异常流将返回到基本流，有些将结束用例的执行。

异常流替代备选流主要的好处：

1，基本功能全部在基本流中表达

2，异常流从名称上清晰的明确了其定位：基本流的异常情况

3，基本流+异常流的组合可以覆盖所有事件流场景

4，用例的颗粒度将受到基本流篇幅的限制，有助于更精细的管理，有便于在敏捷开发环境下使用。

需求用例分析之二：级别设置

在《编写有效用例》（阿莱斯特-科伯恩著，以下用科伯恩用例来指代）一书中，赋予了用例不同的级别，科伯恩形象的设定了如下级别：海平面、云朵、风筝、蛤等等。

科伯恩建议用例级别分为多个个目标层次：概要、用户目标、子功能，书写需求用例时，只能选择其一，下面对其具体说明：

1.概要：包括多个用户目标，它有“显示相关目标的生命周期顺序”和“为低层用例提供一个目录表”的功能，概要用例通常需要执行几个小时、几天、几个星期、几个月、甚至几年。

2.用户目标：它是主执行者努力使工作得以完成的目标，或是用户使用系统的目标，通常情况下指系统为用户提供的界面操作。

3.子功能：指那些在实现用户目标时可能会被用到的目标，一般是指系统内部执行，而用户看不到界面的用例。

在雅各布森用例分析方法（UML统一建模语言、RUP瑞理统一过程之父Ivar Jacobson伊瓦·雅各布森在OOSE、RUP和UML中阐述的用例分析方法）中，充分利用了UML中包来组织子系统、模块和用例。雅各布森用例方法与UML、RUP三者之间有着天然的紧密联系，除了可以用RUP的格式文本描述用例外，还推荐适当地选择利用UML用例图、活动图、包图和状态图等等图示从各个角度来描述和组织用例，可谓手段充足、武器齐备。

级别与静态展现

两者其实没有本质区别，雅各布森用例分析方法更加注重在RUP和UML下协同发挥作用。从现在工具的情况来看，用包来包含用例是UML的标准做法，毕竟以用例来包含用例显得有些怪异，目前没有看到有工具支持用例包含用例。从静态而言，包解决了多级别用例的问题。

级别与动态变化

但是这里其实还有一个时间动态的问题：即是海平面级用例一般而言是早于云朵风筝级用例出现的，而蛤级用例是最后出现的。在RUP中强调迭代演进来处理包和用例分解重组等等，事实上最后将淹没曾经出现的海平面级用例，这对于追溯用户最初的需求而言是不利的。当然RUP配套有业务用例分析，业务用例将收集用户起初的业务需要，但这显得过于累赘。但实际采用中，很少见到严格按照RUP先分析业务用例，再分析用例，往往的直接分析用例。

改良的级别设置方法

所以在雅各布森用例分析方法中采用原始需求列表来替代业务用例分析，是既能追溯最初的需求，又能节约大量业务用例分析的工作量，这样就能从时间动态和结构静态两方面融合了两种方法的优势。

对应在科伯恩用例分析方法，相当于将首批海平面级用例（用户直接表达的目标）专册收集后续跟踪，而利用包来替代云朵和风筝,后来的海平面（经分析后的海平面）级用例仍然是实质性的用例。

改良的级别处理方式能融合两大流派在这方面的各自考虑，综合发挥优势，规避劣势。