​ 由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。

用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化地了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。

用例图可以用来描述系统的功能性需求。用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。而且，用例方法是完全从外部来定义系统功能的，它把需求和设计完全分离开来。

参与者是指存在于系统外部并直接与系统进行交互的人、系统或类的外部实体的抽象。参与者是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。

参与者是用户相对系统而言所扮演的角色

参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。

其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者；

硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者；

时钟：系统需要定时触发时，时钟就是参与者。

用例是参与者可以感受到的系统服务或功能单元。它定义了系统是如何被参与者使用的，描述了参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

用例必须由某一个参与者触发激活后才能执行，即每个用例至少应该设计一个参与者。如果存在没有参与者的用例，就可以考虑将这个用例并入其他用例之中。

真实项目中如何发现用例？

请遵循如下思维习惯：

调研需求时最先弄清楚有多少部门，多少岗位（参与者），然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？（参与者目标），这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？（用例）

​ 用来定义系统的界限，系统的用例都置于其中，参与者则置于边界之外。通过这个系统边界可以很清晰地标识出了系统的范围。

系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。系统边界以外的同系统相关联的其他部分称之为系统环境。

参与者用例之间是关联关系，表示了参与者与用例间的通信．用一条实线箭头表示。

包含关系是指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。箭头由基用例指向包含用例。

在一定条件下，把新的行为加入到已有的用例中，获得的新用例成为扩展用例，原有的用例称为基用例。箭头方向是从扩展用例指向基用例。

如果用户想要既能够直接导出报表，同时还能够直接打印报表。而且用户在查看报表之后，同样也可疑导出报表和打印报表。