联系之前写的软工文档和看的UML视频，我们知道软件设计的第一步就是对用户需求进行分析，从用户的角度对软件进行设计，而接下来要说的用例图便是可以展现给用户的图。

一、目的：

  用来表示系统有哪些功能，描述用户需求，从用户的角度让用户明确系统内部和系统外部（也就是角色）是如何交互的，并指出系统各个功能的执行者。

二、组成：

  功能的描述——角色（Actor），用例（Use Case），关系（依赖，泛化，关联）和系统边界。

1、角色：

  可为人，可为物。人：事件的主动发起方，被动接收方，直接使用系统的人，设计到的维护人员，可能对系统感兴趣的人等；

                               物：外设（打印机，传真机）等；

2、用例：

  简而言之是参与者想要系统做的事情

3、关系：

三、用例图的形成。

1、在制作过程中要把系统看做一个黑盒子。

在画图时，只看系统功能而不看系统是如何设计的。而且用例图的画法没有标准答案，完全是创作者根据喜好和个人的经验来确定关系和粒度大小。

2、确定粒度大小，将其逐渐细化。

概述级是粗粒度，如管理员；用户目标级，如结账；子功能级，如卡内余额计算。

3、确定包含关系。

业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。如一些重复用到的东西，要抽象出来，如管理员，操作员和一般用户在操作区都要进行身份确认，所以把身份确认抽象出来（子功能），各个用户可以复用，用Include标明，不用再单独提取关系。

四、注意事项

1>应该清晰的定义系统边界

2>防止用例过多

3>从执行者的角度来命名用例

4>用例描述正规程度

5>避免执行者的名字不一致

6>避免执行者和用例的关系太复杂

7>用例的粒度

8>用例描述清晰

9>区分用例分解和功能分解

10>避免客户不能理解用例的情况发生

11>在不适合用用例图的场合可以以文档的形式进行描述。

五、画好的用例图

六、小结：

   画用例图没有正确的答案，在以后滚动学习的过程中对软件，用例图会有新的理解，这只是1.0版。