用例图：

       用例图是从用户的角度去描述软件产品的需求，分析产品所需的功能和动态行为，是实现软件需求到最终实现的第一步，在UML中用例图用于对系统、子系统或类的行为的可视化，以便是系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。画用例图，要注意功能和它的执行者。

用例图的基本元素：

（一）、用例：用例是对系统的用户需求的描述，用例表达了系统的功能和所提供的服务。

              如何识别用例：

             识别用例最好的办法就是从分析系统的参与者开始，考虑每个参与者是怎样使用系统。并且，用力建模的过                程就是迭代和逐步精化的过程。

（二）、参与者：参与者通过向系统输入或请求系统输入某些事件来触发系统的执行，可以是人，也可以是一个外部               系统。

             如何寻找参与者：

            1、谁使用该系统

            2、谁维护该系统

            3、与该系统交互的是什么系统

            4、谁从系统中获取信息

            5、谁提供信息给系统

           要点：

          1、参与者对于系统而言总是外部的

          2、参与者直接同系统交互，可以帮助定义系统边界

          3、每个参与者需要一个名字

          4、每个参与者必须有间断的描述

（三）、关系：

         用例和参与者之间的关系：依赖、泛化、关联

         用例与用例之间的关系：泛化、包含、扩展

         包含关系：一个用例可以包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。

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

         扩展关系：扩展关系就是把新行为插入到已有用例的方法。为处理异常或构建灵活系统框架提供了一种有效的           方法。

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

画用例图的要点：

（1）、找到用例和参与者

（2）、描述它们之间的关系

（3）、用例规格说明文件，对用例进行详细的说明

            简要说明、事件流、特殊需求、前置条件、后置条件、扩展点、相关数据、问题说明

总结：

       明白用例图是做什么的，然后谁做，找到之间的关系，对用例进行说明。

UML——用例图