UML介绍（2）—— 用例图（use case diagram)
用例图（use case diagram)属于行为式图形（Behavior diagrams），强调系统模型中触发的事件。
用例图使用参与者和用例对系统的功能进行建模。用例是系统需要执行的一组动作，服务和功能。用例图只是描述预期会触发的事件（用例），并不展示具体实现（用例）的方法。它仅总结了参与者和系统之间的一些关系。
用例建模的关键概念是帮助我们从最终用户的角度设计系统。用例图很简单，通常在设计的早期使用。
用例图的元素包括：1.参与者（actor） 2.用例（use case) 3.系统边界（boundary of system）4.关系（communication link)
1.参与者（actor）
- 参与者是与系统进行交互的角色，即参与者会触发用例
- 参与者通常是以名词命名
- 参与者与用户的概念相似，但是用户可以扮演多种参与者。比如学校图书馆，学生可能既是借书人也是图书管理员。
- 参与者负责对系统输入和输出
2.用例（use case)
- 用例是系统需要执行的一组动作，服务和功能
- 用例通常以动词 +名词命名，例如借书、取钱等
- 每个参与者必须连接到一个用例，但某些用例可能没有连接参与者。
3.系统边界（boundary of system）
- 系统边界即系统和系统之间的边界
4.关系（communication link)
参与者和用例之间通过实线连接。表示参与者和用例之间的交互
用例之间的关系包括 1.包含（include）2.扩展（extend） 3.泛化（generalization)
1. 包含（include）
2. 扩展 (extend)
3. 泛化 (generalization)
下面介绍用例规范（Specification）。
参考
https://blog.****.net/happyunbound/article/details/8119691
https://blog.****.net/ZZh1301051836/article/details/71514575
1. 前置条件（Pre-Conditions)
把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件（说明在用例触发之前什么必须为真）
<1> 用例开始之前，某些条件必须为真。但是它们不是启动用例的触发器。
<2> 该用例本身不会去检查该条件，调用者检查。
<3> 通常前置条件说明，在该用例运行之前，另一个用例必须运行。典型的前置条件可以是“用户已登陆”。
2.基本流（Action steps)
即顺利操作该系统的流程，异常事件不包括在内。
2.1 通常使用主动句
2.2 以系统或参与者为主语
2.3 不要涉及界面细节
3. 扩展点（Extension Points)
即触发到特殊用例的情况说明。只有当密码连续三次错误后才会出发报警的用例。
4. 备选流（exceptions)
顾名思义，就是指如果事件没有按照理想的情况进行，那么可能发生的意外的事件。
5. 后置条件（Post-Conditions)
对于后置条件理解还不是很清楚。
(1) 对于有多个事件流的用例，则应该有多个后置条件（用例执行后什么必须为真）
(2) 用例执行结果“必须”为真的条件，也称为“附加条件”，非必需。若某用例不是必须为真，则没有后置条件。
基本用例模板
|
用例名称： |
ATM取款 |
|
描述： |
客户持银行卡（本行或其他行）从ATM提取现金 |
|
参与者: |
客户和银行主机 |
|
前置条件： |
无 |
|
基本流： |
1.客户插入银行卡。
2.ATM从银行卡读入卡号（含银行标识和账号），验证卡的有效性。
3.客户输入密码。
4.ATM验证帐号和密码。
5.ATM显示包括取款在内的服务功能，客户选择“取款”。
6.客户输入取款额。
7.ATM向银行主机发出卡号、密码、账号和取款额。
8.银行主机核实账户余额足够否，足够则执行扣款，并向ATM机返回取款成功信息。
9.ATM打印并吐出凭条。
10.ATM清点并吐出现金。
|
|
备选流： |
4a. 累计3次密码错误： ATM吞卡，[用例失败] 4b. 无此帐号： ATM吞卡，[用例失败] 5a. ATM无现金： ATM不显示“取款”功能，客户可选择其他服务， [用例失败] |
|
扩展点： |
无 |
|
非功能需求： |
ATM响应客户时间不超过15秒 |
|
后置条件： |
无 |