用例图——如何描述用例
一 用例图
1 用例间的关系
包含、扩展、泛化。
三者都属于依赖关系。
2 箭头方向
(1) 包含关系，基用例依赖它所包含的用例，箭头指向包含用例。
(2) 扩展关系：扩展用例依赖基用例，它由基用例触发出来的，箭头指向基用例。
(3) 泛化关系：儿子依赖父亲，箭头指向父亲。
3 三者的区别
●泛化侧重表示子用例间的互斥性（子用例不可同时发生）；它必定发生，如审批泛化出工资调整审批、请假审批。
●包含侧重表示提供间接性的服务；它必定发生，如发送邮件包含在修改密码中，又包含在其他通知业务中。
●扩展侧重表示选择性的触发；基用例必定发生，但扩展用例某些情况下才发生。如查询某个表，扩展出导出这个表的EXCEL。
二 用例文档
参考网站：
(1) 关于用例、前置条件等的理解——蓝叶菱的专栏——CSDN
(2) 2016用例描述模板
(4)uml用例图——电脑玩物
内容较多，欲详细了解请直接到原网址学习。此处只列举小编容易出错的地方，以作学习笔记之用。
1 用例模板
用例名：用例名为用例提供了一个唯一标示。它要用动/宾格式书写，并且要充分，达到最终用户能够明白用例中描述的是什么。
前置条件：
把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件（说明在用例触发之前什么必须为真）
<1> 用例开始之前，某些条件必须为真。但是它们不是启动用例的触发器。
<2> 该用例本身不会去检查该条件，调用者检查。
已登陆”。
触发器：开始此用例的事件。
户打给餐馆一个预约电话”。而在另一种情况下，触发器可能是此用例中的第一个系统事件。
主流程：主流程一定是你希望的流程，你认为用户最顺利操作你的产品的流程，那么它就是主流程。很多Pd在写UC的时候。主流程无比复杂，里面加入无数的判断，就是因为这一点上没有明确。我自己的感觉是，往往一个UC，主流程可能很短，而分支流程会比主流程多，而且复杂。
注意：不要涉及界面细节（下面是反例）
后置条件：
(1) 对于有多个事件流的用例，则应该有多个后置条件（用例执行后什么必须为真）
(2) 用例执行结果“必须”为真的条件，也称为“附加条件”，非必需。若某用例不是必须为真，则没有后置条件。
其实对于上述两点，小编也仍存在一定的疑惑。所以，按照个人将后置条件理解为，正确处理完主流程后系统所处的状态。（可参照“参考网站2 2016用例描述模板”中的举例，如图1）
图1
{
前后置条件补充：
}