本文主要结合实际使用，介绍UML用例图的画法以及用例的说明方式。希望对你有所启发。
一、概述
用例图是编写需求说明时经常用到的需求表达方式，用于向开发、测试同事说明需求中用户与系统功能单元之间的关系。但是很多刚接触用例的新人，在准备用例说明时并不清楚参与者与用例之间应该如何表达，网上教程五花八门，但感觉部分用例图不够规范，因此对用例图及用例说明梳理总结。
考虑到用例图的作图规范，使用Visio的UML用例组件，对用例中的各种关系进行说明。
二、用例图
用例图的结构主要分为三个部分：参与者、用例、参与者与用例之间的关系，具体说明如下：
2.1 参与者
顾名思义，代表系统外部与系统发生交互的人或事物；需要注意，人指的是参与者与系统发生交互时的角色，不代指具体的人。
事物指的是某一个应用程序或者特殊进程；例如微信登录，通过跳转微信确认登录信息，微信对系统产生输入时，可以把微信作为参与者；而设定时间，强制退出账号时，时间这一特殊进程对系统产生输入，因此时间也可以作为参与者。
2.2 用例
2.2.1 用例的说明
用例是系统外部可见的一个功能单元，是某一个参与者在系统中做某件事从开始到结束的一系列活动的集合，以及结束时应该返回的可观测、有意义的结果，其中还包含可能的各种分支情况；具体用例在用例属性中说明。
2.2.2 用例的特征
用例都是动宾结构；例如：登录账号
用例是相互独立的
用例由参与者启动
有可观测的执行结果
2.3 关系说明
角色与用例之间的关系主要包括关联、归纳（泛化）、包含、拓展和依赖。
2.3.1 关联关系
展示形式：以一条直线相连
举例说明：用户登录系统
2.3.2 归纳（泛化）关系
展示形式：用箭头表示，箭头从子参与者（子用例）指向父参与者（基础用例），一般父参与者（基础用例）相对子参与者（子用例）更为抽象
举例说明：VIP会员和普通用户，归纳为用户；账号登录与微信登录，也可归纳为登录系统。
图2 用户之间、用例之间的归纳关系
2.3.3 包含关系
展示形式：用带有“包含”的箭头表示，箭头从基础用例指向包含用例
举例说明：用户在账号登录过程中，包括输入账号、输入密码、确认登录等操作
图3 用例与用例之间的包含关系
2.3.4 拓展关系
关系说明：表示用例与用例之间的关系；用于拓展用例对基础用例的增强；拓展用例是在特定条件出现时，才会被执行的用例
展示形式：用带有“拓展”的箭头表示，由拓展用例指向基础用例
举例说明：用户在登录过程中忘记了密码
图4 用例与用例之间的拓展关系
2.3.5 依赖关系
关系说明：表示用例与用例之间的关系；一个用例在活动执行过程中，要依赖另一个用例的执行
展现形式：以一条直线相连
举例说明：用户要登录系统后，才能查看首页信息
补充说明：A用例依赖B用例，A用例或使用B用例执行后的返回结果，或使用B用例执行部分功能。依赖关系类似于包含关系，都是在用例执行过程中，调用其它用例来完成部分任务。
图5 用例与用例之间的依赖关系
2.3.6 注释
对于部分有特殊条件支撑的用例，也可以添加注释加以说明，例如VIP用户与普通用户登录系统后，可查看的菜单、数据甚至对系统的操作都是不一样的，此时可以在对应用例上加以注释，以强调此用例的特殊需求。
图6 对用例进行注释
2.3.7 子系统
关系说明：用于强调某部分用例的强关联性，例如门户包含系统登录、首页信息展示等。
图7 子系统与用例之间的关系
2.3.8 各关系的对比
为了对包含、拓展和归纳（泛化）关系更好的区分，以图7为例说明各种关系之间的差别：
1）用例的使用条件
包含用例与归纳（泛化）的子用例，都没有限定的使用条件；例如用户登录系统时，直接选择输入账号密码登录系统，或者通过微信登录系统；而忘记密码是在用户账号登录时遗忘密码才会发生的用例，是有特定条件下才会发生的用例。
2）直接、间接提供服务
归纳（泛化）的子用例与拓展用例为参与者直接提供服务，例如用户登录系统时，会直接选择账号登录或微信登录，而账号登录或微信登录直接为参与者提供登录服务；而包含关系的用例，为参与者提供间接服务，例如账号登录时，需要输入账号、输入密码等，这些用例直接鼓舞于账号登录这个用例，间接为参与者提供登录服务。
3）其余说明
延伸用例与基础用例相互独立，两者之间不包含对方用例的内容。
归纳（泛化）的子用例包含基础用例所有内容、基础用例与其他用例的关系以及基础用例与参与者之间的关系；例如账号登录是登录系统的子用例，但账号登录包含了登录系统的内容、登录系统与展示首页的关系以及登录系统与参与者的关系。
三、用例描述
完成了用例图，实际上工作只完成了一半，更重要的是对每个用例进行具体的说明；包括说明用例之间的关系、参与者身份角色以及用例从开始至结束过程中的条件及分支情况等；具体用例说明形式可参考下表：
用例的描述针对不同业务系统，描述的重点可能会存在差异，因此用例描述的重点在于清晰表达用例需求，不必拘泥于表达形式。
最后
不管用例图与表格画得多么酷炫，最终目的也是为了团队同事可以用最短的时间及精力完成对需求的理解。因此扎实的文档能力是产品的基础要求，希望这份总结能给到对用例说明无从下手的童鞋一点帮助。
如有错误，希望各位指正；共勉！
