1.3 Use Case模型与Use Case描述

作者: 高焕堂 出处:清华大学出版社 　2008-01-31 13:26　   砖    好    评论  条 　进入论坛

阅读提示：《Use Case 入门与实例》第一章主要是带领我们大家认识一下Use Case。本文主要说了Use Case模型与Use Case描述。

1.3  Use Case模型与Use Case描述

Use Case模型(即Use Case model)顾名思义是以Use Case为基本概念模块来抽象地描述一个系统。一个Use Case表达了用户对系统的一项需求，也就是系统的一项责任或功能(function)。在Use Case模型里，常将系统(System)表示成如图1-1所示的图形。

当系统的有关人员看到图1-1，就可知道这系统的需求了。

图1-1美中不足的是：并未表达出系统与外界环境间的关系，因而无法让人了解“为什么”系统必须提供这些Use Case？即无法确定这些需求的正确性。因此，有必要描述环境中与系统接触的部分，了解这些部分与系统接触的目的，再对应到系统内的Use Case所能支持的功能，才能确保系统的正确性与可用性。

图1-1  以包(package)代表系统

系统含有许多Use Case，而环境里的人或物(即系统的用户)在不同时刻，可能扮演不同角色(怀有不同的目的)来使用系统中的不同Use Case，以取得系统的不同服务。“角色”(role)代表一群对系统怀有相同兴趣或目的人或物。当这些人或物每次使用系统时，系统就执行一个特定的Use Case来为其服务，协助其达成目的。角色含有特定的目的，而其目的决定系统中的Use Case内涵，即决定系统应有的功能。

角色  →  目的  →  Use Cases

在电影中，我们称扮演某特定角色的人或物为“演员”(Actor)，于是，在Use Case模型也称扮演共同角色的用户为Actor。Actor 代表“一群”怀有共同目的的用户(所以Actor 是类)，也定义系统中的一些Use Cases。为了确保系统Use Case的正确性，在Use Case模型必须表达出Actor 与Use Case间的关系，才能让人们去了解与检验Use Case。
例如在图1-2中，当您扮演Actor 2时(怀有一个目的)，就可使用系统，此时系统就执行Use Case 3来协助您完成目的。同样地，当您扮演Actor 1时，就可使用Use Case 1或Use Case 2来达成您的目的。

并不是环境里的所有人或物都会使用到这系统，只有Actor 所代表的人或物会用到而已，所以在Use Case模型中只需描述Actor 就够了。同样地，Actor 也只会用到系统中的某些Use Case，所以在Use Case模型中只需描述系统中的Use Case就够了。所以，Use Case模型中的基本元素只有两个：Actor和Use Case。

图1-2  Actor与Use Case

而刚才说过的Use Case 描述就是用来描述Use Case的功能及其行为(behavior)，以便配合Actor 的行为而协助Actor 达成其目的。例如，您已找出Actor 及系统应有的Use Case，如图1-3所示。

图1-3  餐厅的Use Case

图1-3表示System将提供Use Case 1来协助Actor 1达成其目的，也提供Use Case 2来达成Actor 1的另一个目的；此外也提供Use Case 3 来替Actor 2达成目的。也就是说Use Case的应有责任是决定于Actor 所怀的目的。因此，在Use Case描述里宜描述Actor 的目的和Use Case的责任，让上述的Use Case模型更加清楚。

以上是针对Use Case的功能而言的。此外，在行为方面，Use Case必须在行为上配合Actor“使用”系统的过程，才能顺利达成Actor 的目的。也就是说Use Case的应用行为决定于Actor的使用过程。

因此，在Use Case描述里宜描述Actor 使用系统的途径，以及Use Case应有的配合行为。由于Use Case模型的目的在于分析系统的需求，将Use Case视为黑箱，所以在此Use Case描述里，只描述Use Case的外部行为，及其与Actor的交互而已，并不描述Use Case幕后的内部行为。如图1-3有3个Use Case，Use Case描述如下所示：

UC: 吃晚餐
｛ 
用户动作              系统响应  
点餐
上开胃菜
上主餐
请上点心
上点心
买单
结账
开收据
拿走收据
｝

这就表示出系统的应用功能和行为了，也就是掌握了系统的需求了。一个系统含有一群事物互助合作来进行各项活动(activity)，以达成系统的目标(objective or goal)。例如，一个饭店的目标是给予旅客舒适的食宿服务。它常需完成许多小任务(mission)，累积起来才能达成目的。同时也常需执行许多项活动，累积起来才能完成一个任务。那么支持某个任务的所需活动的集合，就称为饭店系统功能(System function)或流程(process)。

由于Use Case表达了用户使用系统的途径，在这使用过程中，系统则执行某个流程中的一连串活动。所以Use Case正好描述着程序，即成为流程的模型。当以Use Case来描述企业中的各流程时，就等于为系统创建了一个Use Case模型。即Use Case模型表达出用户对系统的期望(what we want the system to do)以及系统的功能和流程。这些都是系统的用户需求。

上述说明了Use Case模型表达用户观点下的系统功能需求。此外，Use Case又擅长于表达用户对系统行为的需求。所谓行为需求(behavior requirements)就是描述系统应该如何为用户提供服务。最常见的表达方式如：“饭店系统应该派车到机场接客人。”这说明了客人抵达机场时(是个事件)，饭店系统应该呈现出什么样的反应动作，这反应动作就是系统的行为。

根据Jacobson对Use Case的定义：一个Use Case就是一连串通过系统的事件(a specific flow of events through system)。其涵括系统对这些事件的反应，以及用户对事件的反应。即Use Case也描述了系统的外部行为(external behavior)。所以可借助Use Case来表达系统的行为需求。然而如何描述这些事件以及用户与系统间的交互情形呢？基本上，可用文档来描述，这就是刚才提过的“Use Case描述”了。例如：

UC: 饭店check-in
{
用户动作                          系统响应  
1. 当旅客抵达机场， 通知饭店
2. 饭店派人(车)赴机场接客人
3. 客人办理check-in手续
4. 饭店带领客人进房
}

此外，Wirfs-Brook也建议使用序列图(Sequence Diagram)来表示，如图1-4所示。

无论是Use Case描述还是序列图，都能更清楚地表达出系统的行为需求。每个Use Case都表达了系统行为需求的一部分，由于所有Use Case的总和等于是系统，因此，Use Case的总和就表达出整个系统的行为需求。在Use Case模型中，只表示出Use Case的外观行为，而把Use Case内的行为封装起来。到了Use Case的设计阶段，就可使用序列图来表达Use Case内部的行为(internal behavior)了，这是序列图主要用途之一。

图1-4  饭店check-in序列图

回书目   上一节   下一节