什么是用例图？　　

　　UML用例图，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，UML用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

　　用什么画用例图？

　　本文和大家重点讨论一下用processon画UML图基本操作，画UML图有好多种工具，processon只是其中一种，processon的动作非常轻快而且是在线画图工具.很多人都在用。

　　我们要做的第一步就是注册processon，然后新建一个UML用例图模板。

　　现在，先让我们一起了解一下基础知识。

　　用例图三要素　

　　1，参与者-系统使用人员　　2，用例-系统功能　　3，关系-参与者和参与者之间的联系，用例和用例之间的联系。

　　其中重要并且需要理解的内容就是关系了，让我们先来看参与者和参与者之间的联系（主要就是泛化）

 　　参与者之间的泛化关系

         例如，一个网上订购系统，可以有网上客户、电话客户、直接客户等。可以看出，他们有共同的行为特征，这就是可以用到面向对象的抽象，抽象出更为一般的化的参与者——客户。通过泛化来描述多个参与者之间的共同行为，不同的参与者以独特的方式来使用系统。

　　　　 泛化就类似于Java中的继承关系。子类具有父类的所有行为，并且在其基础上添加自己的行为。

　　用例与用例之间的关系

　　1、泛化关系

　　用例与用例之间也存在着泛化关系，通常用于表示同一业务目的（父用例）的不同技术实现（各个子用例）。

　　例如某购物系统为用户提供不同的支付方式，那么”支付”这个复杂用例就可以用泛化关系表示。

　　TIPS：子类名 = XX(用于具体描述）+父类名。

　　2、包含关系

　　在包含关系中，基本用例吸收了被包含用例的行为，如果没有后者它将是不完整的。

　　包含关系的划分有两个好处：一是被包含用例被抽取出来，基本用例得以简化；二是可以抽象出公共事件流，实现代码复用。

　　有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包　　含这些细颗粒的用例。

　　3、扩展关系

　　扩展用例的事件流在一定条件下按照扩展点插入到基础用例的事件流中，即根据一定的条件来判断是否要插入到基础用例的事件流中，并且扩展点可以用多个

　　对于一个扩展用例，可以在基用例上有几个扩展点。

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

　　包含关系与扩展关系(转）

　　共同点：扩展用例与包含用例都是基用例的一部分

                基本用例不执行，扩展用例与包含用例都不会执行

                扩展用例可以扩展多个基本用例，包含用例可以被多个基本用例包含

　　区别：

            扩展关系中基本用例的基本流执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行。

            包含关系中基本用例的基本流执行时，包含用例一定会执行。

　　总结

　　用例图的难点主要在于用例与用例之间三种关系的使用。

　　用例是功能模块，是用来体现服务的。我们把服务从两个维度分为两大类:

　　1.直接服务/间接服务 　　与　　2.有条件服务/无条件服务

　　那么拓展属于有条件服务，只有在拓展的父类产生一定的条件才会提供服务。

　　那么泛化和包含属于无条件服务，泛化是直接服务，包含是间接服务。

　　再土一点，举个例子：

　　按功能名字划分的话：泛化----------子类名 = XX(用于具体描述）+父类名。例：移动支付 = 移动 + 支付。PC支付 = PC + 支付。

　　　　　　　　　　　　包含----------被包含（X1/X2/X3） = 包含（XX） 例：密码维护/账户维护/头像维护 = 维护。

UML用例图--入门