UML——Use Case Diagram（用例图）

用例图主要用来描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示这些元素之间的各种关系，如泛化、关联和依赖。它展示了一个外部用户能够观察到的系统功能模型图。

【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。

一、用例图所包含的的元素

1. 参与者(Actor)——与应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。

　　　　　　　　　　　　　　　　

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

　　　　　　　　　　　　 

3. 子系统(Subsystem)——用来展示系统的一部分功能，这部分功能联系紧密。

　　　　

二、用例图所包含的的关系

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

　　如下表所示：

　　a. 关联(Association)

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

　　【箭头指向】：无箭头，将参与者与用例相连接，指向消息接收方

　　

　　b. 泛化(Inheritance)

　　就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

　　【箭头指向】：指向父用例

　　c. 包含(Include)

　　包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

　　例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那添加、修改以及删除都要在用例详述中描述，过于复杂；如果分成添加用例、修改用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

　　【箭头指向】：指向分解出来的功能用例

　　d. 扩展(Extend)

　　扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

对于一个扩展用例，可以在基用例上有几个扩展点。

　　【箭头指向】：指向基础用例

　　e. 依赖(Dependency)

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

　　【箭头指向】：指向被依赖项

　　5. 项目(Artifact)

　　用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。

　　用依赖关系把某个用例依赖到项目上：

　　然后把项目->属性的Hyperlink设置到你的文档上；

　　这样当你在用例图上双击项目时，就会打开相关联的文档。

　　6. 注释(Comment)

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

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

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

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

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

　　●泛化侧重表示子用例间的互斥性；

　　●包含侧重表示被包含用例对Actor提供服务的间接性；

　　●扩展侧重表示扩展用例的触发不定性；

　　另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。

三、几个用例图示例

****************************************************************************

　　以下为某在线购物系统的用例图，对系统做出做了整体的描绘。

　　(1)系统整体用例图

    

(商品用例图)

    
   
   
   （购买信息用例）
  
   

    (用户资料用例)

用例图主要用来描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示这些元素之间的各种关系，如泛化、关联和依赖。它展示了一个外部用户能够观察到的系统功能模型图。【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。
用例图中包含6个元素，分别是执行者（Actor），用例（Use Case），关联关系（Association），包含关系(Include)，扩展关系(Extend)以及泛化关系(Generalization)。
角色（Actor）：即使用本系统的有哪些角色，不同的角色使用的系统功能部分是不同的，在用例图中用小人表示。
其中，角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。1分析得到角色的原则，也可以看做是我们在获得角色时，需要思考的内容：
  1）有哪些直接使用系统的人
  2）涉及到哪些维护人员
  3）使用哪些外设
  4）相连的其他系统
  5）还有哪些人和事物对这个系统产生的结果感兴趣。123456789用例（Use Case）：即系统具有的功能，在用例图中用椭圆圈表示，圈里用文字描述该用例，一般为动宾短语。
其中，某个用例不一定是只属于一个角色的，有些用例是同时属于多个角色的，即被多个角色“共享”。1关系：用例图中涉及的关系有：关联、泛化、包含、扩展。
关联（Association）：表示参与者与用例之间的通信，任何一方都可发送或接受消息。【箭头指向】：无箭头，将参与者与用例相连接，指向消息接收方
泛化（Inheritance）：就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。【箭头指向】：指向父用例
包含（Include）：指用例可以简单地包含其他用例具有的行为，并把它包含的用例行为作为自身行为的一部分。包含关系代表着基础用例会用到被包含用例，将被包含用例的时间流插入到基础用例的时间流中。【箭头指向】：指向分解出来的功能用例。在处理包含关系时，具体的做法就是把几个用例的公共部分单独地抽象成一个新的用例。主要有以下两种情况需要用到包含关系。多个用例用到同一段的行为，则可以把这段共同行为单独地抽象成一个用例，然后让其他用例来包含这一用例。当某一个用例功能过多，事件流过于复杂时，也可以把某一段事件流抽象成一个被包含的用例，以达到简化描述的目的。
在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例【箭头指向】：指向基础用例扩展关系和包含关系的不同在扩展关系中，基础用例提供了一个或者多个插入点，扩展用例为这些插入点提供了需要插入的行为。而在包含关系中，插入点只有一个。在扩展关系中，基础用例的执行并不一定会涉及到扩展用例，扩展用例只有在满足一定条件下才会被执行。而在包含关系中，当基础用例执行外后，被包含用例时一定要被执行的。即使没有扩展用例，扩展关系中的基础用例本身也是完整的。而包含关系，基础用例在没有被包含用例的情况下是不完整存在
子系统(Subsystem)：用来展示系统的一部分功能，这部分功能联系紧密。

简单旅馆订房示例，如有错误请指出：

附：UML用例UseCase的几个理解误区参见UML用例UseCase的几个理解误区

误区1：用例就是功能点　　这是一个很大的误区，也是技术人员容易犯的一个错误。功能点是站在软件开发的角度来说的，而用例是站在用户的角度来说的。获取用例是领域专家干的活，而最后的功能实现是技术专家干的活，不同的角色。所以获取用例的关键就是要站在用户角度看问题。　　怎么获得用例？首先确定位于系统边界之外的主角是谁？他的期望和目的是什么？这个期望和回报要求在系统之内。所以，用例是帮助确定系统边界的一个好方法。用例也是获取需求的一个方法。　　

误区2：用例和步骤混淆　　举例来说，用户输入密码，要有密码错误提示，并且三次错误自动锁定用户，最后登录成功。“输入密码”是一个步骤，不是用例。整个过程是一个用例：“用户登录”。中间步骤和场景可以有很多。比如输入密码是一个步骤；“要有密码错误提示”这是一个业务需求，不是用例；“并且三次错误自动锁定用户”这是一个业务需求，也不是用例。　　用例的特征：有目的，有用户期望，有回报预期。当结果不可定义或不清晰时不能用Use Cases，意思是如果目标成功或目标失败不能有一个明确的定义，那就不是一个用例。举例来说，用户输入密码，这是不是一个用例？用户输入密码的目的是什么？是为了输入密码吗？不是的，是为了登录系统，所以，用户登录是一个用例。　　

误区3：用例的粒度不明　　用例的粒度大小要看情况，因地制宜，因时制宜。　　因地制宜：一般系统用例10-50个为宜。比较小型系统可以粒度更小一些。　　因时制宜：在业务建模阶段，在概念建模阶段，在系统建模阶段都是不同的。在系统建模阶段，用例的粒度是以每个用例能够描述操作者与计算机的一次完整的交互为宜。根据项目的不同阶段，不断缩小边界可以获得更小的粒度用例。一个大的用例还可以include一个小的用例，比如网上下订单是一个用例，修改订单是一个子用例，因为除了用户，管理员可以修改订单，这个子用例有意义。　　

误区4：用例和场景混淆　　一个用例的执行是要有前因和后果的（前提是什么，结果会怎么样）；比如，煮饭和炒菜是用例，他们各自都有步骤，各自有好几个场景。比如煮饭，我可以用电饭锅煮，也可以蒸饭，煮饭前要先淘米，等等，这些都是一个用例的不同场景，但用户的最终目的都是一样的。不要把用例和场景混淆。　　

误区5：软件工程是不是用例驱动？　　软件工程是不是用例驱动？需求是重要的，用例是构造需求的好方法。但如果你同时要考虑开发的所有因素包括重用，架构，花费，时间，你就无法仅仅从一个方面来驱动你的项目。好的软件工程是被一系列重要因素所驱动的，而且因素也因不同的公司和项目有着不同的重要程度。这些因素包括： 技术上对于设计的考虑，用户需求，重用，可更改性，系统性能，标准化，日程的安排以及其他的商务驱动。每个项目都有着自己不同的考虑。对于每一种情况，可以精确的说项目被域模型和用例共同驱动。　　

误区6：用例直接推导出设计　　不要从用例直接推论出设计。如果这样做，“用例开发”仅仅成为了功能分解的一个借口。用例止于系统接口的边界！用例应该描述参与者使用系统时所遵循的次序，但用例决不说明系统内部采用什么步骤来响应参与者的刺激。　　用例是帮助确定系统边界的一个好方法。用例也是获取需求的一个方法。用例也是产生测试用例的好方法。但是，从系统边界、需求、到详细设计还有很长的路要走。比如说，类图，事实上类图和用例图没有对应关系。换句话来说，用例是需求分析时的产物，类（边界类外）的设计期的产物。

原文链接：https://blog.csdn.net/zhaokx3/article/details/68958218