最近团队在做在一个项目，设计到一些用例图的绘制。因为以前没有深入研究，所以这几天浏览了一些资料，对这方面的知识总结了一下，与大家一起分享(LXF)。

对于用例图，首先我们要了解什么是用例图？

用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。

当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称作用例。用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。

简而言之，就是站在用户的角度，把用户要做的场景以图的方式表现出来。

用例图包含的元素：UML用例图包含六个元素，分别是：执行者(Actor)、用例(UseCase)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。但是有些UML的绘图工具多提供了一种直接关联关系(DirectedAssociation)。

1.执行者(Actor)

表示与应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。

每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。

    参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。

    第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。

    第二类参与者是其它的系统。这类位于程序边界之外的系统也是参与者。

    第三类参与者是一些可以运行的进程，如时间。当经过一定的时间触发系统中的某个事件时，时间就成了参与者。

    2.用例(Use Case)

用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。

在模型中，每个用例的执行都独立与其它用例，尽管在执行一个用例时由于用例之间共享对象的原因可能会在用例之间产生隐含的依赖关系。每个用例都表示一个纵向的功能块，这个功能块的执行会和其它用例的执行混合在一起。

     用例的动态执行过程可以用UML的交互来说明，可用用状态图、时序图、协作图或非正式的文字描述来表示。用例功能的执行通过系统中类之间的协作来实现。一个类可以参与多个协作，因此也参与了多个用例。

     在系统层，用例表示整个系统对外部用户可见的行为。一个用例就像外部用户可以使用的系统操作。但是，它不又与操作不同，用例可以在执行过程中持续接受参与者的输入消息。用例也可以被像子系统和独立类这样的系统小单元所应用。一个内部用例表示了系统的一部分对其它部分呈现出的行为。

3. 子系统(Subsystem)

用来展示系统的一部分功能，这部分功能联系紧密。

4. 关系

用例图中涉及的关系有：关联、泛化、包含、扩展。

a. 关联(Association)

表示参与者与用例之间的通信，任何一方都可发送或接受消息。

关联关系表示参与者与用例之间的通信。不同的参与者可以访问相同的用例，一般说来它们和该用例的交互是不一样的，如果一样的话，说明它们的角色可能是相同的。如果两中交互的目的也相同，说明它们的角色是相同的，就可以将它们合并。

b. 泛化(Inheritance)

就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

c. 包含(Include)

包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。

包含关系使一个用例的功能可以在另一个用例中使用，如下所述。

  （1）如果两个以上用例有大量一致的功能，则可以将这个功能分解到另外一个用例中。其它用例可以和这两个用例建立包含关系。

  （2）一个用例的功能太多时，可以用包含关系建模两个小用例。

要使用包含关系，就必须在客户用例中说明提供者用例行为别包含的详细位置。这一点同功能调用有点类似。事实上，它们在某种程度上具有相似的语义。

d. 扩展(Extend)

扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。

扩展关系是把新的行为插入到已有的用例中的方法。同一个基础用例的几个扩展用例可以在一起应用。基础用例的扩展增加了原有的语义，此时基础用例而不是扩展用例被作为例子使用

e. 依赖(Dependency)

　以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。

包含(include)、扩展(extend)、泛化(Inheritance) 的区别：

条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；

直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。

对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。

对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；

用例建模技术：

一．对语境建模

对于一个系统，会有一些事物存在于其内部，而一些事物存在于其外部。存在于系统内部的事物的任务是完成系统外部事物所期望的系统行为，存在于系统外部并与其进行交互的事物构成了系统的语境，即系统存在的环境。在UML建模中，用例图对系统的语境进行建模，强调的是系统的外部参与者。对系统语境建模应当遵循以下的方法：

（1） 用以下几组事物来识别系统外部的参与者：需要从系统中得到帮助以完成其任务的组；执行系统功能时所必须的组；与外部硬件或其它软件系统进行交互的组；为了管理和维护而执行某些辅助功能的组。

（2）将类似的参与者组织成泛化/特殊化的结构层次。

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

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

二．对需求建模

需求就是根据用户对产品功能的期望，提出产品外部功能的描述。需要分析所要做的工作是获取系统的需求，归纳系统所要实现的功能，使最终的软件产品最大限度的贴近用户的要求。对系统需求建模可以参考以下的方法。

（1）识别系统外部的参与者来建立系统的语境。

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

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

（4） 解公共行为，放入到新的用例中以供其它的用例使用：分解异常行为，放入新用例中以延伸为主要的控制流。简而言之，就是确定提供者用例和扩展用例。

（5）         在用例视图中对用例、参与者和它们之间的关系进行建模。

本文转自HDDevTeam 51CTO博客，原文链接：http://blog.51cto.com/hddev/1253982，如需转载请自行联系原作者