用例图

很多软件项目失败最常见的原因，都集中在“项目关键干系人”之间沟通不佳或缺少沟通。当开发机构和业务提出者之

间缺乏联盟时，就更加关键。业务人员可能知道他们有某个问题需要解决，但是开发组长却只收到了关于业务需求的

一般描述和一些具体的需求。

UML建模语言中，“用例图”既可以让开发组织能够理解业务的目标，也可以不会很麻烦业务人员。用例图展示待建系

统的上下文范围以及它提供的功能。它们描述了谁与系统交互，外部世界希望系统做些什么。

基本概念：执行者

执行者是与系统交互的实体，可以是人或其他系统。执行者位于他们使用的系统之外。用棍状小人表示。如下图所

示：

当然，在考虑执行者时，考虑最多的还是思考执行者所扮演的角色。角色不同，那么他对应的表示就不同。

基本概念：用例

用例代表了执行者希望系统为他们做什么。用例在UML“用例图”中，我们用一些椭圆表示。用例不仅仅是系统可以提

供的功能，从“执行者的观点”来看，用例必须是一个“完整”的活动流程，它为执行者提供了“价值”。用例是通过某部分

功能来使用系统的一种具体的方式……因此，用例是相关事务的一个具体序列，执行者和系统以对话的方式来执行这

些事务……从用户的观点来看，每个用例都是系统中的一个完整序列的事件。

如下图所示：

“管理花园”、“修改农作物百科书”

基本概念：用例图

将执行者与用例利用基本的关联连接起来，就构成了一张用例图。在“用例图”中，这种关联使用实线来表示。用例图

中的关联表明是哪个用户发起的哪个用例。如在下图：

用例图中的关联表明哪个用户发起哪个用例。例如上图中，只有执行者Gardener才可以维护储水箱，但是所有的执行

者都可以查看报告。

1、确定用例细节

确定用例提供的功能细节，或者指定完整序列的事件时，较好的办法就是使用其他的UML模型（如活动图）和文本规

格说明。在UML用例图中，用例规格说明有许多不同的形式。但大多数都包含以下信息：

用例的名称、

关于它的目的的一段简短描述

乐观流程（即一切正常，用例中发生的事件流）

一个或多个更实际的流程（即事情如果没有按照愿望发生时的流程）

2、用例规格说明示例

举例说明，如“维护保养车辆”用例的例子。

用例规格说明

用例名称：维护保养车辆”

用例目的：本用例提供了维护车辆的保养功能。本用例让执行者维护车辆的保养，维护。

乐观流程：

1、执行者检查车辆的当前状态。

2、执行者决定对车辆进行保养（清洗，更换机油……）。

3、执行者决定对车辆损坏的地方进行维护（补漆，更换零件……）。

4、保养完成、维护完成

5、执行者对下一台车辆进行维护与保养

实际流程：

条件触发对的可选流程如下：

条件1：1、水不够，不足以完成洗车的操作。

提示：提醒执行者水不够，不能达到洗车所需的水量，并显示可用的原料。提醒执行者选择终止保养或重新设置加注

水量。

选择：如果选择终止保养，执行“乐观流程”的第5步。

   如果选择重新设置加注水量，完成加水后，执行“乐观流程”的第2步。

条件2：……

当然其他有用的信息也可以被加入到规格说明中，但是要表述清楚，如进入条件（在执行这个用例之前什么条件必须

为真）、退出条件（在执行这个用例之后什么条件必须为真）、限制条件、假定等。

例外，就是用例规格说明不应该太长……它应该只有几页。如果规格说明非常长，要么就是你用例做的事太多，要么

就是你设计的用例实际上是多个用例，一切根据自己的具体情况去做。

高级概念：《include》和《extend》关系

有两种主要用于组织用例模型的关系……《include》和《extend》：

1、《include》关系

例如，这张图表明，Update Crop Encyclopedia用例包含了View Reports用例。这意味着在执行Update Crop

 Encyclopedia时，View Reports必须被执行。如果没有View Reports,  Update Crop Encyclopedia就不能被看作是完

整的。

当一个被包含的用例执行的时候，它在用例规格说明中就体现为一个包含点。包含点指明了在外层用例的什么位置执

行被包含的用例。

2、《extend》关系

《extend》关系，在用例图中，一般表示某些活动可以作为用例的一部分执行，但是并不一定要运行它，用例也能成

功的这种情况。如上图中，当执行者Gardener执行Manage Garden用例时，他可能想看下某些报告，那么他就会执

行View Reports用例。但是在执行Manage Garden时，View Reports并不是必需的，Manage Garden本身就是完整

的。所以我们《extend》表明View Reports用例扩展了Manage Garden用例。

当一个扩展的用例被执行时，它在用例规格说明中就体现为一个扩展点。扩展点指明了在外层用例的什么位置执行扩

展的用例。

当不知道在用例中到底需要采用哪个关系时，可以借用下面的表格来区分：

高级概念：泛化

泛化这个概念除了可以在类图中体现以外，也可以在用例中来进行展示，用例也可以有一些共同的行为，其他用例

（子用例）可以通过添加步骤或精华其他方面来修改这些共同的行为。如：下图中的购买门票的用例

Purchase Ticket包含了购买任何门票所需的基本步骤，而子用例针对具体的门票的种类对Purchase Ticket进行了特

化。