UML用例图

UML用例图在开发方案设计的时候可以用来查漏补缺，一个需求发到头上，开发需要去思考设计开发方案，但是如果没有整理好所有的用例，就有可能在后续发现后导致返工，因此学会或者开发初期针对需求画一个UML用例图可以理清设计思路（说的这么厉害，笔者之前写开发方案也没有画过UML用例图。。不过那是得益于测试同学的测试用例写的很完善），正如内心OS的，所以这里记录一下UML图应该如何画，也不一定对

一个UML用例图，包含三个（参与者、用例、关系），再次声明，这个分享是笔者自己的初见理解，不一定对，后续发现问题，动态更新（叠甲，过）。

第一个是参与者，这里可以理解成对象，这里举一个例子，比如一个设置快捷键的需求，那么参与者可以有用户（用户可以设置快捷键）、开发人员（比如你的需求是设置一个快捷键机制，开发人员可以基于此二次开发或者新增自己的快捷键设置）、管理者（可以理解成最终实现整套快捷键机制的对象）；

第二个是用例，这里笔者是这样理解的，用例从不同的参与者分离出去，比如用户的角色可以做以下的事情，例如：
查看快捷键列表 - 用户可以查看所有可用的快捷键及其当前绑定。
编辑快捷键绑定 - 用户可以更改现有快捷键的键位组合。
添加新快捷键 - 用户可以为新操作创建快捷键绑定。
删除快捷键 - 用户可以删除不再需要的快捷键绑定。
保存设置 - 用户保存所做的快捷键更改。
恢复默认设置 - 用户可以恢复快捷键的默认绑定。

第三个是关系，这里有点抽象，下面举几种常用的
关联关系（association）：单独一个用一个箭头来表示，箭头方向为启动者指向用例，用例指向支持者

包含关系（include）：箭头指向的用例是发起箭头用例的行为之一，表现为一个箭头上面写上<< include >>
例如多种用例都包含一种行为，可以把公共行为抽离出来为一个用例，然后包含这种行为的用例就可以用上包含关系指向该公共用例
（比如上方的编辑、添加、删除快捷键的操作，之后都会涉及到保存设置的操作，就可以将保存设置设置为公共用例，然后在用户编辑、添加、删除等操作后，include保存设置）

拓展关系（extend）：箭头指向用例为发起箭头用例的拓展功能，表现为一个箭头上面写上<< extend >>
把新的行为加入到已有的用例中，新的用例则为扩展用例，原有的用例为基础用例，两者的关系为扩展关系
(比如上面快捷键相关，我这边也没想到例子，难绷）

泛化关系（generalization）：箭头指向用例为发起箭头用例的特例之一，表现为一个空间投的实线，为一个父用例可以被特化为多个子用例，之间的关系则为泛化关系，期间会继承父用例的所有结构、行为、关系。子用例也可以添加、覆盖、改变继承的行为

https://zhuanlan.zhihu.com/p/646716117
图来自这里，这篇文章写的很好，每次看到类似的好文都会想着，wc，别人都写这么好了，我还写个毛线啊，直接看别人的不就行了，后来想想，算了，敲字也是熟悉的过程，把别人的理解成我的，这也是一种学（xie）习（du）。

介绍完基本概念后，就开始创建一个UML用例图了，第一步，我们可以思考有哪些参与者会用到这里，比如快捷键，我这里想的是用户、开发者、管理者；也可以看看他人写的几种问题
“谁将使用该系统的主要功能
谁将需要该系统的支持以完成其工作
谁将需要维护、管理该系统，以及保持该系统处于工作状态
系统需要处理哪些硬件设备
与该系统交互的是什么系统
谁或什么系统对本系统产生的结果感兴趣”
这样可以很清晰地得到使用者，这样好全面地分析需求。

然后可以从参与者出发，每个参与者会如何用，再来看看别人提出的问题
“特定参与者希望系统提供什么功能
系统是否存储和检索信息。如果是，那么由哪一个参与者触发
是否存在影响系统的外部事件
哪个参与者通知系统这些事件
当系统改变状态时，是否通知参与者”

然后通过三层级去更细的划分出用例

图也来自上述的链接文章https://zhuanlan.zhihu.com/p/646716117