课程设计一直在画用例图，但从未经过深入思考，用例图是什么？用例图解决了什么问题？什么时候要画用例图？画用例图的逻辑究竟是什么？经过系统学习之后记录一下，同时也希望自己能学以致用，用于实际的产品工作当中。
用例图是什么？
用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。简单来说就是用来表示参与者（包含用户，外部系统），系统，功能之间的相互关系图。基础模型如下：
用例图解决了什么问题？
按我目前的理解，用例图主要解决了以下三个个问题：
1. 把用户，业务（系统），功能抽象化，更好的帮助我们清楚系统是什么？有哪些用户？系统有哪些功能？
2. 拆解需求，把用户目标拆解成一个个业务目标乃至一个个功能。
3. 帮助我们清楚功能权限的设计，权限分为功能权限和数据权限，用例图主要体现出每类用户下的角色的功能权限，越是角色复杂的系统越需要理清楚权限问题，例如后台管理系统。
什么时候要画用例图？
进行需求分析和设计时。可以梳理在某一个较复杂的系统中，角色和功能的对应关系，高度抽象出这几者之间的关系。
用例图怎么画？
我以淘宝购物系统为例。不完整也可能有错误，希望得到前辈们的指点，感谢！
第一步：先画出参与者和系统
第二步：画出用户下可能存在的角色
第三步：思考用例粒度，就是用例细化程度。那么究竟需要多大的粒度，我们应该根据每个系统的具体情况，因时因宜地来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。此处按我粗浅的理解写了几个用例，由于系统是整个购物系统，所以用例粒度较大。
在科伯恩的《编写有效用例》中，提出了几个角度去判断用例的粒度
从用例本身思考
CRUD类型用例，CRUD是指创建、检索、更新和删除，添加用户、修改用户和删除用户就是典型的CRUD类型用例。
从用户角度思考
同样在科伯恩的书里，用户目标用例标为蓝色，海平面（对等于雅各布森用例的系统用例），在多数情况下，用户目标用例需要一次2到20分钟的处理。概要层次（白色、云朵，风筝）的用例通常需要执行几个小时到几个月，甚至几年。这层次的用例对照到雅各布森用例体系，相当于业务用例。
从用例包含的业务流程思考
科伯恩推荐用例的主要场景的步骤在3到8、9步。
同时细化时要注意：
1）不要将粒度细化得过小，不要将用例细化为单个操作，比如说点击确认，因为它们联合起来才能体现出业务价值；
2）不要将同一业务目标细化为不同用例；
第四步：确定每个用例之间的关系
参与者用例之间，用例和用例之间主要存在四种关系，分别是关联，泛化，包含，扩展。
1）关联：表示参与者与用例之间的通信，任何一方都可发送或接受消息。
2）泛化：一个用例可以被特别列举为一个或多个子用例，类似通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
3）包含：用来把一个较复杂用例所表示的功能分解成较小的步骤；基础用例可以看到包含用例，并依赖于包含用例的执行结果。但是二者不能访问对方的属性。
4）扩展：指用例功能的延伸，把新行为插入到已有用例，相当于为基础用例提供一个附加功能。
到此，用例图就完成了，剩下的就是回溯复查是否有错误信息了。
总结：用例图可用于需求分析和设计。画用例图时要注意用例的粒度大小，各个要素之间的关联，泛化，包含，拓展四种关系。
参考链接：
