1. 概述

　　用例图（Use Case Diagram）描述“用户、需求、系统功能单元”之间的关系，是参与者所能观察和使用到的系统功能模型图。

　　用例图用于需求分析阶段

　　用例图包含6个基本元素：参与者（Actor）、用例（Use Case）、泛化关系（Generalization）、扩展关系（Extend）、包含关系（Include）和关联关系（Association）。

2、用例（Use Case）

　　用例是外部可见的系统功能部分，用例的主要作用是在不揭示系统内部构造的前提下定义了连贯的行为。

2.1>、初识用例

　　用例包含了所必需的全部行为，即执行用例的主线次序、标准行为的不同变形、一般行为下的所有异常情况及其预期的反应。从用户角度来看，用例包含的行为可能是异常情况，但从系统角度来看，则是必须被描述和处理的附加情况。用例不是系统需求或功能的规格说明，而是系统所描述过程中的需求情况。

　　在UML中，用例用一个椭圆表示，并且每个用例都必须有一个名字，该名字不能与其他的用例重名。

　　

　　在UML中，每个用例的执行都独立于其他用例。每个用例都表示一个纵向的功能模块，这些模块在执行时会与其他用例混合执行。

　　用例的动态执行过程可以用UML中的状态图、协作图、时序图来描述，也可以用非正式的文字来描述。

2.2>、确定用例

　　确定用例最好的方法是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。

　　确定系统用例要明确以下问题：

　　（1）特定参与者希望系统提供什么功能？

　　（2）当系统改变状态时，是否通知参与者？

　　（3）是否存在影响系统的外部事件？

　　（4）哪个参与者通知系统这些事件？

　　（5）系统是否存储、检索信息？如果需要，则由哪些参与者出发？

2.3>、事件流

　　事件流描述的是一个系统“做什么”，而不是“怎么做”。事件流包括简要说明、前置条件、主事件流和其他事件流、后置条件。

　　（1）简要说明。每个用例都应该有一个说明，描述用例的作用。说明应该包括执行用例的不同类型用户和通过用例所达到的效果。

　　（2）前置条件。即用例的必须满足的条件。前置条件是另一个用例已经执行或用户具体有运行当前用例的权限。并不是每个用例都有前置条件。

　　（3）主事件流和其他事件流。用例的具体细节在主事件流和其他事件流中描述。事件流是从用户角度描述执行用例的具体步骤，关注系统“做什么”，而不是“怎么做”。主事件流和其他事件流包括：用例的开始、用例的交互、用例的正常流程、用例的事件流变体、用例的错误流、其他事件的变体和错误流、用例的结束。

　　（4）后置条件。该项是用例执行完后必须为真的条件。并不是每个用例都有后置条件。

3、参与者（Actor）

　　参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统中输入或请求系统输入某些事件来触发系统的执行。

3.1>、初识参与者

　　每个参与者可以参与一个或多个用例，他通过交换信息与用例发生交互，而和参与者的内部实现没有关系。

　　

　　参与者一般分为三类：系统用户、其他系统、可运行的进程。

　　（1）系统用户。该类参与者是最直接的，需要使用系统的用户。

　　（2）其他系统。在当前项目范围之外，需要建立与其他系统的接口。这类位于项目边界之外的系统也是参与者。

　　（3）一些可运行的进程。如时间，当经过一定时间段后，发生系统中的某个事件时，时间成为参与者。

3.2>、识别参与者

　　获取用例之前，首先要确定系统的参与者。参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物，并且一个人可以扮演多个角色。

　　参与者的识别方法：

　　（1）系统主要功能的使用者；

　　（2）系统所服务的对象及要完成的工作；

　　（3）系统的维护、管理人员；

　　（4）系统所需要的硬件设备；

　　（5）与该系统交互的其他系统；

　　（6）对本系统产生的结果感兴趣的人或其他系统。

3.3>、参与者与参与者之间的关系

　　参与者不是具体的人或物，而是类，所以多个参与者之间关系是类与类之间的关系。在用例图中，使用泛化关系来描述多个参与者之间的公共行为。

　　

　　　　　　　　　　参与者之间的泛化关系

3.4 用例与用例之间的关系

　　用例之间的关系包括：包含关系、泛化关系、关联关系、扩展关系，应用这些关系的目的是为了从系统中抽取公共行为及其变体。

3.4.1 包含关系

　　包含关系：一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身的一部分。在这种情况下，新用例不是初始用例的一个特殊例子，并且不能被初始用例所代替。

　　在UML中，包含关系用虚线箭头加<<include>>来表示，箭头指向被包含的用例。

　　

　　包含关系把几个用例的公共步骤分离成一个单独的被包含用例。

　　示例：

　　

3.4.2 泛化关系

　　用例泛化：一个用例可以被特别列举为一个或多个子用例。当父用例能够被使用时，任何子用例也可以被使用。

　　在UML中，用例泛化用一个三角箭头从子用例指向父用例。

　　

　　在用例泛化中，子用例表示父用例的特殊形式。子用例可以从父用例继承属性与行为，还可以添加、改变继承的行为。

　　示例：

　　

3.4.3 关联关系

　　关联关系描述参与者与用例之间的关系，用于表示类的关系的关联元素的实例。

　　关联关系表示参与者与用例之间的通信，不同的参与者可以访问同一个用例。

　　

3.4.4 扩展关系

　　扩展关系是一个用例被定义为基础用例的增量扩展，通过扩展关系把新的行为插入到已有用例中。扩展关系中，扩展用例是基础用例的一个相对独立并且可选的用例。

　　在UML中，扩展关系用虚线箭头加<<extend>>表示，箭头指向基础用例，即被扩展的用例。

　　

　　示例：读者在归还图书馆借书时，若超过应归还日期，则需要超期罚款；若未超过归还日期，则不需要超期罚款。

　　

4、UML语境建模技术

　　在UML中，利用用例图对系统语境进行建模，强调的是系统的外部参与者。具体建模方法如下：

　　（1）识别系统外部的参与者；

　　（2）在需要加深理解的地方，为每个参与者提供一个构造型；

　　（3）将参与者放入到用例图中，并说明参与者与用例之间的通信路径；

　　（4）将类似参与者组织成泛化的结构层次。

5、UML需求建模技术

　　软件需求是根据用户对产品的功能的期望，提出产品外部功能的描述。需求分析师的工作是获取系统的需求，归纳系统所要实现的功能，使最终的软件产品最大限度贴近用户的要求。需求分析师一般只考虑系统要做什么，而尽可能不去考虑怎么做。

　　对系统建模可以参考如下方法：

　　（1）识别系统外部的参与者，从而建立系统的语境；

　　（2）考虑每一个参与者期望的行为或需要系统提供的行为；

　　（3）把公共行为命名为用例；

　　（4）确定供其他用例使用的用例和扩展其他用例的用例；

　　（5）在用例图中对用例、参与者和它们之间关系建模；

　　（6）用描述非功能需求的注释修饰用例图。