UML图（一）—用例图（use case diagrams）

        用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。用于在需求分析阶段分析客户需求。

        用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。它将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。

一、USE CASE图主要的作用有三个

（1）获取需求；

（2）指导测试；

（3）还可在整个过程中的其它工作流起到指导作用。

二、角色之间的关系（泛化）

        泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

三、用例间的关系

1、包含：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

     Include，从表面英文意思来看，是包含的意思，也就是说是基用例的一部分，是不可缺少的。即：必须执行。

注意：用户让学生上机时知道 包含三项的存在

2、扩展：系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导出、打印和查询相对独立，而且为查询添加了新行为。

      Extend是扩展，也就是在原有基础上新增加的一个。即：可执行也可不执行。

注意：用户查询学充值记录时，并不知道有export excel项，导出excel是可独立存在的。

3、泛化：子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

4、扩展与泛化的区别

       泛化“继承”或“多态”。UML中的Use Case泛化过程是将不同UseCase之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子UseCase；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：

          ●泛化侧重表示子用例间的互斥性；

          ●包含侧重表示被包含用例对Actor提供服务的间接性；

          ●扩展侧重表示扩展用例的触发不定性；详述如下：

     既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：

         ⒈无条件发生：肯定发生的；

         ⒉有条件发生：未必发生，发生与否取决于系统状态；

          因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

         我的理解：

         包含：前用例的实现必须依靠后用例

         扩展：是功能的一个延伸，可有可无

         泛化：对前用例方法、属性的继承（把别人的变为自己的，自己就不用重新写）

四、机房收费系统用例图

一般用户

博文借鉴：http://blog.csdn.net/lbq613613/article/details/8035588

                 http://blog.csdn.net/caihaijiang/article/details/5903180

五、角色和执行者的确定

1、角色

哪些直接使用系统的人
系统的维护人员
使用哪些外设（打印机、传真机）
需和此系统相连的其他系统（例子：EMS），外部系统也需要确认为角色。

2、执行者

谁需要使用这些功能
需要系统支持日常的工作
谁来维护这些系统
系统需要操作哪些硬件呢？
这个系统需要和哪些系统交互呢？
有哪些人或事对我们系统产生的结果是感兴趣的