用例图的含义是由3358www.Sina.com/和参与者（Actor）、用例（Use Case）组成的用于描述系统功能的动态视图称为用例图。
其中，使用者与参加者的对应关系也称为它们之间的关系。
用例图用例图是需求分析的产物，它的主要作用是说明参与者和用例之间的关系，使开发人员能够直观地理解系统的功能。 通过使用用例图，系统用户、系统分析人员、系统设计师、领域专家可以通过可视化的方式讨论问题，减少大量的交流障碍，便于对问题的共识。
用例图的构成要素用例图的构成要素为通讯关联（Communication Association），参与者（角色）
参与者——是与APP应用或系统交互的用户、组织或外部系统。 用小人表示。
用例(Use Case ) ——用例是一种外部可见的系统功能，用于描述系统提供的服务。 用椭圆表示。
系统边界——系统边界是系统和系统的边界。 用方形框的系统名称表示。
-元素之间的关系
用例图的关系是用例、系统边界、元素之间的关系
关系型说明是，关系扩展用例之间的关系参与者(Actor )存在于系统外部，与系统直接交互的http://www.sinw.sinsing，包括表示符号相关参与者和用例之间关系的泛化参与者之间或者用例之间的关系每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。
参与者之间的关系与类具有相同的关系描述，因为参与者实质上也是类。 也就是说，参与者和参与者之间主要称为关联、泛化、包含、扩展或“继承”关系。
泛化关系是指提取某个参加者的共同行为并作为共同行为来表达，作为超类来描述。 泛化关系表示参与者之间的一般或特殊关系，在UML图中使用人、系统、子系统表示泛化关系，使用类的外部实体
系统边界系统边界可以指的是泛化关系通用的系统，其为由一系列相互作用的元素形成的具有特定功能的整体有机实体。 系统是相对的，一个系统本身可能是另一个更大系统的组成部分。 因此，必须使用系统边界来区分系统和系统之间。
系统边界在用例图中标记为带空心三角箭头的实现，同时系统命名，参与者在边界的箭头指向超类参与者。，用例在边界的系统与系统之间的界限
用例(Use Case )是参与者(角色)可以看到的系统服务或功能单元。 定义系统被参与者使用的方式，并描述参与者为了使用系统提供的完整功能而与系统之间发生的对话。
用例的最大优点是从用户的角度(从系统外部)描述系统的功能。 它将系统视为黑盒子，不关心系统内部如何完成它提供的功能，整个系统表现出外部用户可见的行为。
方框
用例必须在单个参与者开始激活后才能运行。 这意味着每个用例必须至少包含一个参与者。 如果您有一个没有参与者的用例，请考虑将该用例合并到其他用例中。 用例表明它是类而不是特定的实例。 用例展示了其代表性功能的各个方面，包括在用例执行过程中可能出现的各种情况。 用例是完整的说明。外面
用例粒度是指用例中包含的系统服务或功能单元的数量。 用例粒度越大，用例包含的功能就越多，相反，包含的功能就越少。
粗粒度细粒度里面
用例图只是从总体上大致说明了系统提供的各种服务，对系统有一般的认识。 但是，在每个用例中，都需要详细地描述信息，以便别人对整个系统有更详细的理解。 这些信息包含在**用例约定**中。
简要说明(Brief Description ) )
简要说明是用例的作用和目的的简要说明。 事件流(Flow Event )
事件流包括基本流和备用流。 基本流程描述了用例的基本流程，是指用例“成功”运行时的场景。 在执行备用流中描述的用例时可能发生的异常和偶尔发生的情况。 用例方案(Use-Case Scenario )
当同一用例实际运行时，会出现各种情况，称为用例场景。 用例场景也可以说是用例的实例。 用例场景包括成功的用例场景和失败的场景。 特殊需要(Sepcial Requirement ) )
特殊要求是用例的非功能性要求和设计限制。 特定需求(如可靠性、性能、可用性和可扩展性)通常是不起作用的。 前置条件(Pre-Condition ) )
前置条件是指执行用例之间的系统必须放置的状态。 例如，前提是要求用户具有访问权限，或者用例必须已经运行。 职位条件(Post-
Condition）后置条件是指用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。 用例之间的重要关系 1. 包含
包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。
在UML中，包含关系是通过带箭头的虚线段 + << include >>字样来表示的，箭头由基础用例（Base）指向被包含的用例（Inclusion）。
主要由以下两种情况需要用到包含关系：
添加和修改会员信息后需要预览会员信息，用以检查添加和修改操作是否正确完成。
包含关系的两个优点：
提高了用例模型的可维护性，当需要对公共需求进行修改时，只需要修改一个用例而不必修改所有与其有关的用例。不但可以避免在多个用例中重复的描述同一段行为，还可以避免在多个用例中对同一段行为描述不一致的现象。 2. 扩展在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例（Extension）。原有的用例叫做基础用例（Base），从扩展用例到基础用例的关系就是扩展关系。
一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。需要注意的时：在扩展关系中是基础用例而不是扩展用例被当做例子使用。
在UML图中，扩展关系是通过带箭头的虚线段 + << extend >> 字样来表示的，箭头指向基础用例。
扩展关系与包含关系的不同点如下：
基础用例是“身份验证”，扩展用例是”修改密码“。在一般情况下，只需要执行”身份验证“用例即可。但是如果登录用户想要修改密码，这时就不能执行用例的常规动作。如果取修改”身份验证“用例，势必增加系统的复杂性，这时就可以在基础用例”身份验证“中增加插入点，这样用户向修改密码时，就执行扩展用例”修改密码“。
3. 泛化用例的泛化是指一个父用例可以被特化成多个子用例，而父用例和子用例之间的关系就是泛化关系。
在用例的泛化关系中，子用例继承了父用例所有的结果、行为和关系，子用例是父用例的一种特殊形式。此外，子用例还可以添加、覆盖、改变继承的行为。
在UML中，用例的泛化关系是通过一个三角箭头从子用例指向父用例来表示的。
泛化关系的使用场景：
当系统中有两个或者多个用例存在行为、结构和目的方面存在共性时，就可以使用泛化关系。这时，可以用一个新的（通常也是抽象的）用例来描述这些共有部分，这个新的用例就是父用例。
银行有两种存款方式，一种时柜台存款，一种时ATM存款。在上图中，银行柜台存款和ATM存款都是存款的一种特殊方式，因此“存款”为父用例，“银行柜台存款”和“ATM存款”为子用例。
泛化关系和包含关系的区别:
在用例的泛化关系中，所有的子用例都有相似的目的和结构，注意它们是整体上的相似。而用例的包含关系中，基础用例在目的上可以完全不同，但是它们都有一段相似的行为，它们的相似是部分的相似不是整体的相似。用例的泛化关系类似于面向对象中的继承，它把多个子用例中的共性抽象成一个父用例，子用例在继承父用例的基础上可以进行修改。但是子用例和子用例之间又是相互独立的，任何一个子用例的执行都不受其他子用例的影响。而用例的包含关系是把多个基础用例中的共性抽象为一个被包含用例，可以说被包含用例就是基础用例中的一部分，基础用例的执行必然引起被包含用例的执行。 用例图实例销售员用例图
仓库管理员用例图
采购员用例图
会计用例图
系统管理元用例图