UML建模之用例图学习笔记

什么是用例图

用例图是指由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的静态视图。

用例图是用例（Use Case）分析手段或工具。用例分析是捕获应用需求的有效手段，也是 UML 中进行功能需求分析的主要方法。它用参与者和用例定义所建系统的功能需求和范围。用例是站在系统使用者的角度描述系统可以处理的各种用例（通常，一个系统功能至少要用一个用例描述）。它描述的系统内部对象和运行情况。而参与者是系统使用者，描述了与系统相关的外部对象。

用例图有哪些构成成分

一、参与者（Actor）

参与者是与所建系统交互的人或物。用例描述的是系统内部的所有功能，参与者描述的是系统范围外的一切。参与者在 UML 中用下图表示。

参与者主要包括三大类：系统用户、时间、与系统交互的其他系统。

第一类参与者是实际的人或物，是最常用的参与者。比如，在一个销售系统中，销售员就是一个参与者，该系统是由销售员来实现下订单功能的。

第二类参与者是时间。当经过一定时间会触发系统中的某个事件时，时间就成了参与者。比如，某商场的销售系统里，每到下午四点实行打折，此时时间不在我们的控制之内，但是它又实实在在触发系统中的事件，因此时间也是一个参与者。

第三类参与者是另一个系统。比如，在某个航空订票系统中，该系统可能需要与外部应用程序进行交互，如验证信用卡以便来购买飞机票。此时，外部程序就是一个参与者。

二、用例（Use Case）

用例可以理解为系统提供的功能块，它形象地表示了人们如何使用系统。如何来确定用例主要就是来确定系统向外部提供哪些功能。用例在 UML 中用下图表示。

用例是通过分析需求规格说明书，来进一步帮助用户了解系统。

三、关系（Relationship）

在用例图中参与者与参与者、参与者与用例、用例与用例之间均有关系。这些关系有的相同有的不同。下面仅重点介绍用例与用例之间的关系。

（一）关联关系（Association）

关联是参与者与其参与执行的用例之间的通信路径。如下图中，参与者与用例之间的带箭头的连接实线就是关联。

（二）包括关系（Include）

包括关系表示一个案例的功能可以被重复地在另一个或多个案例中实现。

• 目的：提取用例中公共的场景部分
• 关系约束：基本用例包含部分用例，部分用例无条件执行
• 执行方式：包含用例的行为插入到基本用例中的一个位置。当遵循基本用例说明的用例实例到达基本用例中定义了包含关系的位置，它就将无条件执行包含用例，执行完包含用例后，用例实例就将在基本用例中它先前停止的地方重新开始。

上图是对包括关系进行的抽象图形表示，其中椭圆表示基本用例，椭圆中的实线表示用例实例。
下面通过武松打虎实例对包括关系进行分析。

上图一共包含了两个用例，一个是武松回家，一个是当差的办事，仔细发现两个用例的事件流中有一些地方是相同的，比如“来到三碗不过岗”、“叫酒”、“喝两口”和“过岗”。但是根据包括关系定义，推敲这四个事件，发现武松回家用例中过岗之前有打虎事件，而当差的办事用例中没有，包括关系定义的包括用例是能共用的用例，而如果将过岗纳入包括用例则违反了包括关系的规则。所以仅有“来到三碗不过岗”、“叫酒”、“喝两口”能组成一个公用用例。

所以根据以上分析可以画出该用例图

（三）扩展关系（Extend）

扩展关系表示一个案例是对另一个案例的扩充或者特例。

• 目的：
  
  • 表明用例某一部分是可选（或可能可选）的系统行为。将模型中的可选行为和必选行为分开。
  • 表明只在特定条件（有时是例外条件）下才执行分流，如触发报警。
• 关系约束：
  
  • 扩展用例在扩展点插入基本用例。
  • 扩展用例不会孤立存在
• 执行方式：当执行基本用例的用例实例达到基本用例中定义扩展点的位置时，如果条件发生，则执行扩展用例。执行完后返回。

上图是扩展关系的抽象图形表示。可以看出与包含关系不同的是，扩展关系是可选的系统行为，而包含是无条件执行的系统行为。下面还是利用武松打虎的实例对扩展关系进行分析。

上图是武松回家用例和武松打虎用例，可以看出只有武松回家用例中遇到老虎事件触发时才有武松打虎用例，所以从这一点反推，如果武松没有遇到老虎，则武松打虎用例也不会发生。所以武松打虎是武松回家用例的扩展用例。下面给出完整的用例图。

（四）泛化关系（Generalization）

泛化关系表示了一般与特殊之间的关系，跟面向对象语言 Java 中的继承关系十分相似。

• 目的：当几个用例有共同的场景内容或场景结构的时候，可以使用泛化关系提炼共性避免类似用例的重复描述
• 关系约束：
  
  • 子用例依赖于父用例的结构。
  • 子用例和父用例范围一致
• 执行方式：执行子用例的用例实例将遵循父用例的事件流的结构和内容，同时插入附加行为或修改在子用例事件流中定义的行为

上图是泛化关系的抽象图形表示，下面还是在武松打虎基础上对泛化关系进行分析。

上图除了武松打虎用例，又引入了两个用例，一个是李逵打虎，一个是悟空打虎。对这三个用例进行提炼，最终可以总结出该三个用例的相似之处，“打虎原因”、“打虎工具”和“打虎结果”。

问题：泛化与包括都是提炼共同或相似的地方，这两种关系有什么不同呢？

答：包括关系是对连续的事件进行提炼，以达到复用用例的功能，这种包括用例是不会被分割的。而泛化则是在结构上（大部分在结构上，也有在场景中）对事件进行结构上的提炼，提炼的地方可以不用连续，以此来达到对结构进行总结，将内容抽象，最终形成抽象用例。

具体抽象过程见下面两张图片的介绍。

上图是对抽象实例进行复制描述和场景实例化，从这里可以看出泛化关系与继承关系十分相似。

上图是对实例进一步进行抽象，最终可以被其他赋值进行泛化，即特殊化。比如，对打虎原因、打虎工具和打虎结果进行分别赋值为“牟利”、“猎枪”和“空手而归”。则可以体现出子用例对父用例的泛化或继承关系。

四、总结

用例图最终是要给用户看的，也就是说用例图的设计不必过度分析系统的细节，主要将系统的主要功能模块进行总结分析即可。

• 用例的关系来自于对用例场景内容结构的分析
• 不要过分沉迷用例之间的关系
• 包含，扩展关系是面向执行具体场景的
• 泛化关系是面向结构定义的，也可以包含执行具体场景