一、用例模型
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.系统提示出错