用例图包含六个元素，分别是：参与者(Actor)、用例(UseCase)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者由参与用例时所担当的角色来表示。在UML中，参与者用名字写在下面的人形图标表示。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类：参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
第二类：参与者是其它的系统。这类位于程序边界之外的系统也是参与者。
在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者。
（1）谁将使用该系统的主要功能。
（2）谁将需要该系统的支持以完成其工作。
（3）谁将需要维护、管理该系统，以及保持该系统处于工作状态。
（4）系统需要处理哪些硬件设备。
（5）与该系统那个交互的是什么系统。
（6）谁或什么系统对本系统产生的结果感兴趣。
在对参与者建模的过程中，开发人员必须要牢记以下几点。
（1）参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。
（2）参与者可以直接或间接的与系统交互，或使用系统提供的服务以完成某件事务。
（3）参与者表示人和事物与系统发生交户时所扮演的角色，而不是特定的人或者特定的事物。
（4）每个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似“新参与者”的名字。
（5）每一个参与者要必须有简短的描述，从业务角度描述参与者是什么。
（6）一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。
（7）和类一样，参与者可以具有表示参与者的属性和可以接受的事件，但使用的不频繁。
因为参与者是类，所以多个参与者之间可以具有与类相同的关系。在用例视图中，使用了泛化关系来描述多个参与者之间的公共行为。如果系统中存在几个参与者，它们既扮演自身的角色，同时也扮演更具一般化的角色，那么就用泛化关系来描述它们。这种情况往往发生在一般角色的行为在参与者超类中描述的场合。特殊化的参与者继承了该超类的行为，然后在某些方面扩展了此行为。参与者之间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类。这与UML中类之间的返还关系符号相同。
简介：
用例图对整个系统建模过程非常重要，在绘制系统用例图前，还有许多工作要做。系统分析者必须分析系统的参与者和用例，他们分别描述了“谁来做”和“做什么”这两个问题。
识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。用例建模的过程是一个迭代和逐步精华的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。
在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。
（1）特定参与者希望系统提供什么功能。
（2）系统是否存储和检索信息，如果是，由哪个参与者触发。
（3）当系统改变状态时，是否通知参与者。
（4）是否存在影响系统的外部事件。
（5）哪个参与者通知系统这些事件。
用例分析处于系统的需求分析阶段，这个阶段应该尽量避免考虑系统实现的细节问题。但是要实际建立系统，则需要更加具体的细节，这些细节写在事件流文件中。事件流的目的是为用例的逻辑流程建立文档，这个文档详细描述系统用户的工作和系统本身的工作。
虽说事件流很详细，但其仍然是独立于实现的方法的。换句话说，事件流描述的是一个系统“做什么”而不是“怎么做”。事件流通常包括：简要说明、前提条件、主事件流、其它事件流和事后事件流。
（2）前提条件。用例的前提条件列出用例之间必须满足的条件。例如，前提条件是另一个用例已经执行或用户具有运行当前用例的权限。但并不是所有用例都有前提条件。
（4）事后条件。事后条件是用例执行完毕后必须为真的条件。例如，可以在用例完成之后设置一个标识，这种信息就是事后条件。与前提条件一样，事后条件可以增加用例次序方面的信息，如果要求一个用例执行完后必须执行另一个用，那么就可以在事后条件中说明这一点。当然，并不是每个用例中都有事后条件。
用例除了与参与者发生关系外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和其变体。
关联关系描述参与者与用例之间的关系，它是用于表示类的挂系的关联元类的实例。在UML中，关联关系用箭头来表示。
关联关系表示参与者与用例之间的通信。不同的参与者可以访问相同的用例，一般说来它们和该用例的交互是不一样的，如果一样的话，说明它们的角色可能是相同的。如果两中交互的目的也相同，说明它们的角色是相同的，就可以将它们合并。
虽然每个用例的实例都是独立的，但是一个用例可以用其它的更简单的用例来描述。这有点像通过继承父类并增加附加描述来定义一个类。一个用例可以简单地包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。在这种情况下，新用例不是初始用例的一个特殊例子，并且不能被初始用例所代替。在UML中，包含关系表示为虚线箭头交<
包含关系把几个用例的公共步骤分离成一个单独的被包含用例。被包含用例称作提供者用例，包含用例称作客户用例，提供者用例提供功能给客户使用。用例间的包含关系允许包含提供者用例的行为到客户用例的事件中。
包含关系使一个用例的功能可以在另一个用例中使用，如下所述。
（1）如果两个以上用例有大量一致的功能，则可以将这个功能分解到另外一个用例中。其它用例可以和这两个用例建立包含关系。
（2）一个用例的功能太多时，可以用包含关系建模两个小用例。
要使用包含关系，就必须在客户用例中说明提供者用例行为别包含的详细位置。这一点同功能调用有点类似。事实上，它们在某种程度上具有相似的语义。
一个用例也可以被定义为基础用例的增量扩展，这被称作扩展关系，扩展关系是把新的行为插入到已有的用例中的方法。同一个基础用例的几个扩展用例可以在一起应用。基础用例的扩展增加了原有的语义，此时基础用例而不是扩展用例被作为例子使用。在UML中，扩展关系表示为虚线箭头加<
基础用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供了一组插入片片段，这些片段能够被插入到基础用例的扩展点上。基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。事实上，基础用例即使没有扩展用例也是完整的，这点与包含关系有所不同。一个用例可能有多个扩展点，每个扩展点可以出现多次。但是一般情况下，基础用例的执行不和涉及到扩展用例，只有特定的条件发生，扩展用例才被执行。扩展关系为处理异常或构建灵活的系统框架提供了一种有效的方法。
一个用例可以被特别列举为一个或多个用例，这被称为用例泛化。当父用例能够被使用时，任何子用例也可以被使用。在UML中用例泛化与其它泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。
在用例泛化中，子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加、覆盖或改变继承的行为。如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。
用例建模技术
对于一个系统，会有一些事物存在于其内部，而一些事物存在于其外部。存在于系统内部的事物的任务是完成系统外部事物所期望的系统行为，存在于系统外部并与其进行交互的事物构成了系统的语境，即系统存在的环境。在UML建模中，用例图对系统的语境进行建模，强调的是系统的外部参与者。对系统语境建模应当遵循以下的方法：
（1）用以下几组事物来识别系统外部的参与者：需要从系统中得到帮助以完成其任务的组；执行系统功能时所必须的组；与外部硬件或其它软件系统进行交互的组；为了管理和维护而执行某些辅助功能的组。
（2）将类似的参与者组织成泛化/特殊化的结构层次。
（3）在需要加深理解的地方，为每个参与者提供一个构造型。
（4）将参与者放入到用例图中，并说明参与者与用例之间的通信路径。
需求就是根据用户对产品功能的期望，提出产品外部功能的描述。需要分析所要做的工作是获取系统的需求，归纳系统所要实现的功能，使最终的软件产品最大限度的贴近用户的要求。对系统需求建模可以参考以下的方法。
（1）识别系统外部的参与者来建立系统的语境。
（2）考虑每一个参与者期望的行为或需要系统提供的行为。
（3）把公共的行为命名为用例
（4）分解公共行为，放入到新的用例中以供其它的用例使用：分解异常行为，放入新用例中以延伸为主要的控制流。简而言之，就是确定提供者用例和扩展用例。
（5）在用例视图中对用例、参与者和它们之间的关系进行建模。
用例建模实例
许多人在用例中混淆了扩展关系。顾名思义，它扩展了基本用例并为系统增加了更多功能。使用<
例子：用例“注册学生信息”和“充值”与用例“用户登陆”之间的关系就是包含关系。b和a本质不一样，就是做b之前一定要做a，那a和b就是包含。