Object-Oriented Analysis and Design Using UML 翻译与学习 （四）

 Creating Use Case Scenarios and Forms 创建用例场景和用例表单（表格）

 

目标

完成这一章你能够：

1、为用例定义和记录场景。

2、创建一个表单，去概述存在于主要流程和次要流程中的场景。

3、描述如何应用被包含和继承的用例。

4、定义和记录用例的非功能性需求，商业规则，风险和优先级。

5、定义补充说明文档的目的

 

记录用例场景

一个用例场景是一个是在的用例的例子。

一个用例场景应该：

1、尽可能具体

2、从不包含条件状态

3、以相同的方式开始，但会有不同的输出结果

4、不需要说明太多用户界面细节

5、展示成功和不成功的输出结果（在不同的用例场景中）

6、用例驱动不少其他OOAD工作流

 

选择用例场景

理想的情况下，可以有多个用例场景，但是会花很多时间。因此，你可以用一下标准选择合适的用例：

1、用例包含了与演员复杂的交互

2、用例包含了许多了很可能失败点，例如与内部系统和数据库的交互

 

有两种类型场景

1、主（高兴）场景记录成功的结果

2、副（悲伤）场景记录失败的事件

 

写一个用例场景

一个用例是一个故事：

1、描述用户如何使用系统和系统如何反应演员的行为

2、有开头，中间和结尾

 

主用例场景：例子

开头：

用例开始于预订经理收到一个在旅馆预订房间的请求。

 

中间:

预订经理填入到达日期，离开日期和需要的每个房间的类型。预订经理提交填写的详情。

系统查找符合预订期间的空房和占有需要的空房间的房间号和类型。

系统回应存在说明的房间，并且返回暂时的房间预订号，然后将这个预订标记为“稍等”。

预订经理接受提供的房间。

 

更加中间：

预订经理选择客户以前住过的连锁旅馆，填入编号和顾客名。

系统找到并返回符合的顾客信息及住址详情。

预订经理选择其中一个顾客作为合法顾客。系统把用户分配到订单。

预订经理检查订金支付。检查成功。

 

结尾：

系把订金支付分配给订单，并且把预订的状态改为“确认”。系统返回预订ID和预订详情。

 

副用例场景：例子

开始：

用例开始于预订经理收到一个在旅馆预订房间的请求。

 

中间：

预订经理填入到达日期，离开日期和需要的每个房间的类型。预订经理提交填写的详情。

系统响应，在日期范围内没有任何类型的空房间。

 

结尾：

用例结束。

 

补充说明

一些你收集的工程信息不能与用例一起存放，因为这些信息需要被几个用例共享。

 

可以放在补充说明中的附加信息，一般包含：

1、非功能性需求

2、工程风险

3、工程限制

4、术语词汇

 

非功能性需求

非功能性需求定义系统的定性的特质。

对一个动物来说，NFRs描述动物内部特征的力量，速度，敏捷。

任何状语都可以成为NFR

 

非功能需求：例子

NFR1：系统支持200网页程序的模拟用户。

NFR2：完成预定的活动的步骤，占用用户的平均完成时间一定不能超过10分钟。

NFR3：预定记录的容量可以一个月增长2600条。

 

//2016年9月23日0:20:46

 

术语词汇

术语词汇定义了要在工程中使用的，商业的，IT的词汇。

在旅馆系统中如，预订，日期范围。

 

用例表单的描述

用例表单是一个工具，它记录每一个用例的详细分析和用例的场景。

一般需要填入的名词有：用例名称、描述、演员、优先级、风险、触发条件等。

 

总结

1、用例场景提供了对用例的一个实例的活动的详细描述描述。

2、用例场景应该提供多的不同场景，以至于用例范围内的活动都被记录下来。

3、用例场景提供了用例的详情。这个详细的分析记录在用例表单。

4、用例的活动被放到用例表单的“事件流程表单”中。不寻常的场景被定义到“可选流程单”中。

 

 

 

//2016年9月24日14:41:16
//联系我，邮箱：bourne_w@sina.com

交个朋友吧