其中一个案例需求：异常流量

引出的问题

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

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

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

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

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

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

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

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

第2种写法的样例例如以下：

用例名称：填写请购单

简要说明

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

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

事件流

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

基本流

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

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

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

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

新增：系统详细运行见“备选流 新增”

改动：系统详细运行见“备选流 改动”

删除：系统详细运行见“备选流 删除”

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

 备选流

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

　　　　请购单信息：新增、改动、删除。

新增

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

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

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

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

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

改动

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

（二）系统弹出“改动请购单”模式窗体。并显示当前请购单信息。

（三）改动对应数据后。选择“保存”提交，系统验证数据有效性。如验证不成功则依据错误提示又一次输入，验证成功后保存数据并关闭“改动请购单”模式窗体同一时候刷新请购单信息列表；

若继续改动，则反复㈠㈡㈢步骤。

删除

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

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

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

”；

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

特殊需求

　　无

前置条件

　　员工登录系统。

后置条件

　　无

---样例结束----

第2种写法中。在备选流中说明了基本功能。用例篇幅已经变长。假设备选流中出现异常。备选流将显得更加臃肿。

因此第2种写法比較少见。

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

异常流是什么？

Bernd Lohmeyer提出来例如以下分类规则

（见 http://www.lohmy.de/2013/03/06/writing-use-cases-exception-or-alternate-flow/  ）

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

l 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，删除请购单

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

用例属性	说明
名称	新增请购单
简要说明	员工在线填写图书请购单，内容包含：图书名称、出版社、作者、单位价格等。填好后提交给图书管理员审核。
前置条件	员工已经登录
启动点	员工在“填写请购单”信息区选择“新增”，提交“新增”请求，系统弹出“新增请购单”空白模式窗体
基本流	1. 员工填写各项请购单信息。包含图书名称、出版社、作者、单位价格、数量、订购原因、备注，员工请购单信息输入完成后，选择“保存”提交 2. 系统验证数据有效性，有效性规则见X.Y 3. 系统验证假设通过，记录此请购单 4. 系统返回“保存”成功信息
异常流	3b假设验证不成功。给出详细字段的错误提示信息，让用户修正输入数据
后置条件	提交给图书管理员审核
特殊需求	请购单输入信息界面在一个屏幕内
扩展点	无

异常流的优点

依据以上分析，能够看到。异常流实质上是一种备选流，对比原RUP备选流说明的话，定义例如以下：异常流是与基本流正常行为相关的异常行为。

异常流不是基本流的“绕行道”，有些异常流将返回到基本流。有些将结束用例的运行。

异常流替代备选流基本的优点：

1，基本功能所有在基本流中表达

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

3，基本流+异常流的组合能够覆盖全部事件流场景

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

版权声明：本文博主原创文章，博客，未经同意不得转载。