软件工程之用例模型总结

一、用例模型

1.用例概念

用例：使用系统时发现的功能性需求，不应过于复杂，简单的来说就是你希望系统能够有什么功能，能够增加系统的价值。

用例模型包括用例描述和用例图，我们主要把中心放在用例描述上。

用例模型包含参与者和场景，场景包括成功场景和失败场景。

因此用例模型中有多个场景；每个场景是一个用例。

用例必须注重为用户提供可观察的返回值，就是系统触发了一个用例之后能够给用户带来什么。

一般用例都是黑盒用例，即不考虑如何实现。

2.Use Case Description

每个用例都有一个描述。

怎样确定用例？

(1)确定一个功能；
(2)写一个用例；

(1)主要参与者：调用系统服务完成目标的人。

(2)次要参与者：为系统提供服务的人。

(3)写出每个项目相关人员的理想需求，从中分析功能。

(4)PreCondition:执行到这个用例之前必须为真的情况，比如必须已成功登录或通过验证。

(5)PostCondition:成功执行完此用例后的情况，比如登录用例的后置条件是成功登录（不考虑其他失败情况）。

(6)main flow：将最理想的步骤列出。

一般main flow步骤如下：

    (1)参与者发生动作。

    (2)系统验证。

    (3)返回结果。

(7)extension flow：扩展步骤,通常格式为：(1)系统检测到**有问题;

在main flow中的第一步扩展，则用1a,1b,1c;

3.如何确保正确的用例

EBP原则:一般用例都需要遵守这个规则，即确定主要用例。

用例中的主要用例是一些重复做但是有意义的事，比如收银员收钱，重复多次是有意义的，因为钱收得多了；但是像登录系统，这种做100次却没有意义的用例，不能被称为主要用例；

(1)EBP（基本业务过程）原则的用例写入；

(2)如果要写编辑A，删除A，添加A，可以合并成“管理A”；

4.用例图

每个用例描述都是一个用例，左边是主要参与者（希望系统为他提供服务）和次要参与者（提供给系统服务的人）；

 

在次要参与者中不能有数据库，因为在用户角度看是不知道系统有数据库的；

 

关系：

(1)泛化关系，在参与者和用例中都能泛化。

(2)包含关系：

 

表示A包含B；比如A是管理数据，B可以是添加数据、删除数据等；

(3)扩展关系：

表示D被C扩展，D包含新的功能，比如D是查询数据，C可以是打印数据，即用户可以查询但不打印数据，打印数据只是一个扩展功能。

用例描述模板

用例模型根据系统边界的确定，描述了系统的输入和输出，确定了系统外部的参与者，通过用例描述了系统的主要功能，描述了外部参与者与系统的交互，将系统作为一个黑盒，从用户角度描绘出系统需要提供的功能; 

Use Case：用例名称

Actor：参与者

Precondition：前置条件，即执行这个用例一定要满足的条件

Postcondition：后置条件，如果成功执行，则一定会变成的状态

Main flow：

1.用户开始一次会话

2.用户输入信息

3.系统验证并反馈

4.用户重复2，3步

Extensions：

3a：数据无效

    1.系统提示出错