目录
用例图的基本概念
含义：由参与者、用例以及他们之间的关系构成的用于描述系统功能的动态视图成为用例图。其中用例和参与者之间的对应关系又叫做通讯关联，他表示参与者使用了系统中的哪些用例。用例图是从软件需求分析到最终实现的第一步，他显示了系统的用户和用户希望提供的功能，有利于用户和软件开发人员之间的沟通。
作用：用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。
用例图的构成要素
画好用例图的前提是，必须详细了解用例图的四个组成元素：参与者、用例、系统边界、关联。
参与者：参与者是指存在于系统外部并直接与系统交互的人、系统、子系统或类的外部实体的抽象。每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者，在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面。需要注意的是，参与者虽然可以代表人或事物，但参与者并不是指人或事物本身，而是表示人或事物当时所扮演的巨额色色。参与者还可以划分为主要参与者和次要参与者。主要参与者是指执行系统主要功能的参与者，次要参与者指的是使用系统次要功能的参与者。标出主要参与者有利于找出系统的核心功能，往往也是用户最关心的功能。
参与者之间的关系:由于参与者实质上也是类，所以他拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。泛化关系是指把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。泛化关系表示的是参与者之间的一般或特殊关系，在UML图中，使用带空心三角形的实线表示泛化关系。
系统边界：在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与系统之间的界限。通常所说的系统可以认为是由一系列相互作用的元素形成的具有特定功能的有机整体。系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此，系统与系统之间需要使用系统边界进行区分，一般把系统边界以外的同系统关联的其他部分称之为系统环境。
用例的重要元素
识别用例：任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。当找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者是如何使用系统的，需要系统提供什么样的服务。
用例的细度：用例的细度指的是用例所包含的系统服务或功能单元的多少。用例的细度越大，用例包含的功能越多，反之包含的功能越少。
用例的规约：
简要说明：是对用例作用和目的的简要描述；
事件流：包括基本流和备选流。基本流描述的是用例的基本流程，是指用例正常运行时的场景。备选流描述的是用例执行过程中可能发生的异常和偶尔发生的情况。基本流和备选流合起来应该能够覆盖一个用例所有可能发生的场景。
用例场景：同一个用例在实际执行过程中会有很多不同的情况发生，称之为用例场景，也可以说用例场景是用例的实例。
特殊需求：指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。设计约束可以包括开发工具、操作系统及环境、兼容性等。
前置条件：是指执行用例之前系统必须所处的状态。
后置条件：是指用例执行完毕后系统可能处于的一组状态。
用例之间的各种重要关系
包含、扩展、泛化。。。