【UML】— 用例图

一.元素：

1.角色、用例（功能描述）、关系（泛化、依赖、关联、实现）

2.元素含义：

Actor	1. 可以是人、事、物 2. 分析角色考虑的因素：直接使用系统的人、维护人员、外设（人、打印机）、相连的系统 3.  参与用例的实现过程 3.       图符：
用例	1.       名称：要体现系统的功能 2.       图符：
关系	1.  4种关系： 关联—>     分为：双向和单向，参与者与用例之间的关系常为关联关系 依赖- - - -> 使用关系，如一个类使用另一个类的方法 泛化一个用例被特举出多个用例使用 2.  其它关系： 包含《include》一个用例的行为包含另外一个用例的行为 扩展《extend》（接口扩展）一个用例被定义为基础用例的增量扩展，扩展用例为 基用例添加新的行为

关系图说明：

关联：

依赖：

泛化：

包含：

扩展：

二.作用：描述用户的需求（强调功能、功能的执行者、正在使用的系统）

三.用例注意点

1.清楚地定义系统的边界（即判断哪些功能属于该系统）

2.防止用例过多（粒度）

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

4.描述正规程度

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

6.避免执行者和用例之间的关系太复杂（若过复杂，则添加新的执行者）

7.用例大小恰当

8.用例描述混乱

四：主要属性

事件流	1.用例执行时角色与系统的交互过程； 2.分为基本流（用例中常规和预期路径的描述）和备选流（受影响后执行其它的路径）
前置条件	（执行的前提条件）什么条件下开始执行一个事件流
后置条件	用例结束后系统的状态

五：粒度

       在绘制一个系统的用例图时，到底画多少用例，多少用例比较合适那，往往在绘制一个系统的用例图时一层用例是不够的，往往需要画好几层，那么问题就来了，我这个用例到底画到第一层中，还是第二层中那，这时有一个判断标准——粒度，用例越多，粒度越大，一般用例在10——50个为宜。

        不同阶段使用的粒度不同：

                 1.业务建模阶段：一个用例能描述一个完整的事件流

                 2.用例分析阶段：一个用例能描述计算机与用户人员能完成一次成功的交互过程

                 3.用例的开发量的时间在一周左右为宜

六：范围

分为：概述级、用户目标级、子功能级

        两个用例同时用到同一个用例，表示这两个用例包含同样的关系，复用一个关系

七：产生阶段及使用用户

主要产生于系统分析阶段，用户描述用户的需求（功能），产生于需求分析报告中

使用人群：用户、系统开发、设计、测试人员、项目负责人

八：图例（以机房收费系统为例）

分析该系统的用户需求：本系统有3个角色，分别是管理员，操作员和一般用户，