用例图是从用户的角度出发，描述系统功能的。在软件开发过程中，开发人员首先获知用户的需求，然后设计用例模型，在分析并设计系统来实现这些用例。在系统完成后，还要根据用例图来对系统进行验证。
用例图主要介绍了一下部分：构成，描述和注意事项
用例在需求分析阶段产生，那么，用例设计时地第一个问题就是这个软件的范围是什么，确定范围后，再去找出都有谁参与，都干些什么事。然后根据这些话出来用例图。
首先是用例的构成：
用例图包括用例、角色两个部分。角色之间又有一些关系。这就是用例图需要表现的东西。
用例图的参与者。它可以是一个人，也可以是电脑部件，或者是其他系统。他们拥有系统中的角色，通过对应的角色可以使用相应的权限。但他却不属于系统，而是处在正在建模的系统的外部。
用例图的参与者的确定有以下原则：
1. 谁是主要客户
2. 谁用系统完成工作
3. 谁维护管理系统
4. 系统的硬件设置
5. 系统需要与那些其他系统交互
6. 系统从何处获取信息
系统的参与者确定后，根据参与者使用系统的次数确定谁是主要参与者，谁是次要参与者。（不是根据权限哦）
确定了系统的参与者后，需要考虑的是这些参与者都做一些什么样的工作。也就是说这些对象都具有什么方法。它有两种表示方法：一种是一个椭圆，把用例的名称写在椭圆内部，另一种表示方式是把用例的名称写在椭圆的外部，但是通常是吧用例的名称写在椭圆的外部。
首先，参与者要与用例进行通话，这就是他们的关联关系；接下来就是用例和用例之间的关系了：
1.扩展：假如说张三同学去图书馆借一本书，那么，就会有一个借书的时间长度的限制，如果过期没有还书，图书馆的管理老师就会请他去喝茶。在这个事件中，张三的“过期没有还书”的信息作为条件触发了“老师请张三去喝茶”的事件。
这就是用例的扩展，用例“老师请张三去喝茶”是用例还书是否超过规定时间的扩展用例。他们之间是依赖的关系。
2.包含：张三同学去借书时，他需要先看看有没有这本书，然后才确定能不能借书。
张三同学的“借书”用例中，包含有“验证是否该书以借出”的用例。这就是包含关系。他们之间也是依赖关系。
3.泛化：张三同学去还书，发现还书处增加了电子还书的功能。老师可以手动输入张三的借书证号码，也可以通过扫描仪器来扫描张三的借书证而得到借书证号。
张三的还书中，登记借书借书证号的用例分成了手动输入和电子录入两种，这两种用例被称为子用例而登记借书证号是父用例。子用例继承父用例，这就是泛化关系。
用例构成说完了，接下来就是用例的描述了。
如何描述用例图呢？
还是老规矩，先来一张图：
用例也有标识，那就是用例的名称。张三每天给小丽打三个电话。
在这个事件中，“打电话”用例需要先拨号，然后接通。这就是事物的流程，也就是事件流；在电话接通之前，会验证张三拨打的电话号码是否正确可以播出，这就是前置条件；电话接通后，双方处于可以通话的状态这就是后置条件；张三一天给小丽打三次电话中的“三次”就是使用频率。
用例图使用的时候有一些注意事项：
用例的粒度，用例图是不固定的，粒度可以设置的很大，也可以设置的很小，具体如何设计，还是要看设计人员的考虑。不过一般是从粗粒度到越来越细的去设置，当然粒度不是越细越好，而是合适就好。
然后就是用例图的结构要合理。这包括用例内部的结构要合理和用例之间的结构设计要合理。