第02章 用例图

1、第2章 用例图 2.1 用例图的概念2.2 用例图建模技术2.6 实例图书馆管理系统中的 用例图用例图用例图 人们在进行软件开发时，无论是采用面向对象方法还是传统方法，首先要做的就是了解需求。由于用例图是从用户角度来描述系统功能的，所以在进行需求分析时，使用用例图可以更好描述系统应具备什么功能。用例图由开发人员与用户经过多次商讨而共同完成，软件建模的其他部分都是从用例图开始的。这些图以每一个参与系统开发的人员都可以理解的方式列举系统的业务需求。 本章将首先介绍系统、参与者和用例等一些基本概念及表示方法，然后再讨论泛化用例与参与者，以及用例之间的关系。最后介绍如何对用例进行描述以及如何绘制用例图

2、。 系统系统 系统是用例图一个重要组成部分。系统是用于执行某一项功能的，它不单指一个软件系统。但说本书的目的而言，我们感兴趣的是计算机软件，系统是为用户执行某类功能的一个或多个软件构件。系统的边界用来说明用例图应用的范围。例如，一台自动售货机应提供售货、供货、提取消售款等功能，这引功能在自动售货机之内的区载起作用，自动售货机之外的情况则不考虑。准确定义系统的边界并不总是很容易的，因为有些情况下，严格地划分哪些任务是由系统完成，而哪些是由人工或其他系统完成是很困难的。另外，系统最初的规模应有多大也应该考虑。一般的作法是，先识别出系统的基本功能，然后以此为基础定义一个稳定的、精确定义的系统架构，以

3、后再不断地扩充系统功能，逐步完善系统。这样做可以避免由于系统太大，需求分析不易明确，从而导致辞浪费大量的开发时间。2.1.1 概述 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。 用例图最常用来描述系统以及子系统。 2.1.1 概述 用例图包含6个元素：参与者（Actor）用例（Use Case）关联关系（Association）包含关系（Include）扩展关系（Extend） 泛化关系（Generalization） 2.1.2 参与者参与者是系统外的一个实体，参与者通过向系统输入或者系统要求参与者提供某种信息来进行交互。在确定系统的用例时，首要问题就是

4、识别参与者。 参与者的概念 参与者用于表示使用系统的对象。参与者可以是一个人、一个计算机系统、另一个子系统或另外一种对象。例如，一个计算网络系统的参与者可以包括操作员、系统管理员、数据库管理员和普通的用户，也可以有非人类参与者，如网络打印机。参与者的特征是其作为外部用户与系统发生交互。在系统的实际运作中，一个实际用户可能对应系统的多个参与者。同样，不同的多个用户也可以只对应于一个参与者，从而代表同一个参与者的不同实例。2.1.2 参与者 系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统输入某些事件来触发系统的执行。 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或

5、多个用例。 2.1.2 参与者参与者的种类：系统用户与所建造的系统交互的其他系统 一些可以运行的进程 确定参与者 如何寻找系统的参与者 对参与者建模的过程中需要注意的问题参与者间的关系 在用例图中，使用泛化关系来描述多个参与者之间的公共行为。 参与者间的泛化关系示例：2.1.3 用例用例是一组连续的操作，在用户使用系统来完成某个过程时出现，它是外部可见的系统功能单元。通过将这些不同的功能单元进行组合，就构成了对系统总体需求的描述。 用例的概念用例的概念 用例是用户期望系统具备的功能，它定义了系统的行为特征，如果没有这些特征，系统就不能被成功地使用。例如，程序开发人员使用开发系统来开发软件，则开

6、发系统应具备编译功能以满足程序开发人员的需求。 用例的目标是要定义系统（包括一个子系统或整个系统）的一个行为，但并不显示系统的内部结构。每个用例说明一个系统提供给它的使用者的一种服务，即一种对外部可见的使用系统的特定方式。它以用户的观点描述用户和系统间交互的完整顺序，以及由系统执行的响应。这里的交互只包括系统与参与者之间的通讯，而其内部行为和实现是隐藏的。一个系统的全部用例分割和覆盖它的行为，每个用例代表一部分量化了的、有深刻意义的和对用户可用的功能性。注意这里的用户包括人、计算机和其他对象。2.1.3 用例 外部可见的系统功能单元。 在不揭示系统内部构造的前提下定义连贯的行为。 不是需求或功

7、能的规格说明，但是也展示和体现其所描述的过程中的需求情况。 2.1.3 用例用例的名称：简单名 路径名识别用例 识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。 如何识别用例。用例与事件流 1. 简要说明 2. 前提条件 3. 事件流（主事件流、其他事件流、错误流 ） 4. 事后条件2.1.4 用例间的关系关系 用例与参与者之间的连线称为关系，关系也称为关联或通信关联。它表示参与者与用例之间的通信。这种通信是双向的，即参与者可以与用例通信，用例也可以与参与者通信。图表示了一个用例图中的关系。2.1.4用例之间的关系用例之间的关系 用例描述系统满足需求的方式。当细化

8、描述用例操作步骤时，就可以发现有些用例以几种不同的模式或特列在运行，而有些用例在整个执行期间会出现多重流程。如果将用例中重要的可选性操作流程从用例中分隔出来，以形成一个新的用例，这对整个系统的好处是显而易见的。当分离可重复使用的用例后，用例之间就存在着某种特殊关系。包含和扩展在是两个用例紧密相关时，关联用例的两种方法。包含关系用于表示用例为执行其功能时需要从其他用例引入功能。类似，扩展关系则表示用例的功能可以通过其他用例的功能得到扩充。 2.1.4 用例间的关系 1 关联关系 2 包含关系 3 扩展关系 4 泛化关系关联关系 表示参与者用例之间进行通信。 不同的参与者可以访问相同的用例。 包含

9、关系 在对系统进地分析时，通常会发现有些功能在不同的环境下都可以被使用。在编写代码时，我们希望编写可重用的构件，这些构件包括诸如可以从其他代码中调用或参考的类库、子过程以及函数。在用例图中UML支持同样的做法。用例之间的包含关系在UML中的标记符如图214所示。注意图中虚线箭头是指向被包含用例的。 扩展关系扩展用例被定义为基础用例的增量扩展。基础用例提供扩展点以添加新的行为。扩展用例提供插入片段以插入到基础用例的扩展点上。 扩展关系是一种依赖关系,它指定了一个用例可以增强另一个用例的功能。扩展关系与包含关系一样，只是将单词include替换成了表示扩展关系的单词extend。扩展关系如图所示。

10、泛化 泛化是一种表示UML中项目的继承关系的技术。泛化可以应用于参与者和用例来表示其子项从父项继承的功能，而且泛化还表示了父项的每个子项都有略微不同的功能功或目的以确保自己的惟一性。泛化关系 父用例也可以被特别列举为一个或多个子用例。 子用例表示父用例的特殊形式。 子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为。泛化用例泛化用例 相对于参与者而言，用例泛化更易理解。用例泛化是指一个用例（一般为子用例）和另一个用例（父用例）之间的关系，其中的父用例描述了子用例与其他用例共享的特性，而这些用例是有着同一父用例的。 泛化将特化用例和一般的用例联系起来。即子用例是父用例的特化，子

11、用例除具有父用例的特性外，他还可以有自己的另外特性。父用例可以被特化成一个或多个子用例，然后用这些子用例来代表父用例的更多明确的形式。图27演示一个泛化身份验证用例。24泛化参与者泛化参与者与用例一样，也可以对参与者进行泛化。泛化后的参与者也在系统中扮演较为具体的角色。如图212所示，假设图书管理系统中，管理员分为对系统进行维护的管理员和完成借书、还书等日常操作的图书管理员。参与者Manager描述了参与者Librarian和Administrator所扮演的一般角色。如果不考虑与系统交互时的职责，可以使用一般角色的参与者Manager。如果强调管理员的职责，那么用例须使用精确的参与者。即子类

12、Librarian和Administrator。25描述用例描述用例 用例图描述了参与者和系统特征之间的关系，但是它缺乏描述系统行为的细节。所以一般情况下，还会以书面文档的形式对用例进行描述，每个用例应具有一个用例描述。在UML中对用例的描述并没有硬性规定，但一般情况下用例描述应包括以下几个方面：名称名称无疑应该表明用户的意图或用例的用途，如上面示例中的“借阅图书”、“归还图书”。标识符可选惟一标识符一个用例，如UC200601。这样就可在项目的其他元素（如类模型）中用它来引用这个用例。参与者可选与此用例相关的参与者列表。尽管这则信息包含在用例本身当中，但在没有用例图时，它有助于增加对该用例的

13、理解。状态可选指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查。频率（参与者使用此用例的频率）前置条件262.2 用例图建模技术 2.2.1 对语境建模 2.2.2 对需求建模用例建模用例建模 为了加深对前面所介绍知识的理解，本节将通过一个实际的系统用例图来说明用例图的创建过程。在本节所采用的实例为一个图书馆的图书管理系统。绘制用例图一般要经过以下几个步骤： 确定系统涉及的总体信息 确定系统的参与者 确定系统的用例 构造用例模型2.2.1 对语境建模识别系统外部的参与者。将类似参与者组织成泛化的结构层次。在需要加深理解的地方，为每个参与者提供一个构造型。将参与者放入到

14、用例图中，并说明参与者与用例之间的通信路径。2.2.2 对需求建模 识别系统的外部参与者来建立系统的语境。考虑每一个参与者期望的行为或需要系统提供的行为。把这些公共的行为命名为用例。确定提供者用例和扩展用例。对这些用例、参与者和它们之间的关系建模。用注释修饰用例。2.3 实例图书馆管理系统的用例图 2.3.1 确定系统涉及的总体信息 2.3.2 确定系统的参与者 2.3.3 确定系统的用例 2.3.4 使用Rational Rose绘制用例图的步骤 2.3.5 图书馆管理系统的用例图2.3.1 确定系统涉及的总体信息 图书管理系统是对图书馆中的藏书以及借阅者进行统一管理的系统。系统的主要事务包

15、括，图书管理员的书籍借出处理、书籍归还处理和查看借阅者的借阅信息；还有系统管理员对系统的维护，包括对管理员的维护、书籍的维护、借阅者信息的维护等。在确定了系统的总体信息后就可以分析系统的参与者，并确定系统用例。2.3.1 确定系统涉及的总体信息读者：借书还书 书籍预定 2.3.1 确定系统涉及的总体信息图书馆管理员：书籍借出处理书籍归还处理 预定信息处理 2.3.1 确定系统涉及的总体信息系统管理员：增加书目删除或更新书目增加书籍减少书籍增加读者帐户信息删除或更新读者帐户信息书籍信息查询 读者信息查询 2.3.2 确定系统的参与者寻找系统的参与者与用例通常是由与潜在用户会见的系统建模人员完成的

16、。在某些情况下，该任务还包括与借阅者面对面的访谈，在访谈中可以提出问题，了解他们的需求。下面是一个针对图书管理系统的一个业务需求列表，它可以帮助我们创建用例图。 系统可供图书管理员使用来完成记录学生借阅图书信息。 系统允许用户浏览借阅信息。 系统准确记录了图书馆中的所有藏书。 系统需要允许图书管理员查询某学生的借阅信息。2.3.2 确定系统的参与者首先分析系统所涉及的问题领域和系统运行的主要任务：分析使用该系统主要功能部分的是哪些人。谁将需要该系统的支持以完成其工作。 系统的管理者与维护者。 2.3.2 确定系统的参与者图书馆管理系统的参与者：读者（借阅者）图书馆管理员 图书馆管理系统维护者

17、2.3.3 确定系统的用例 在识别出系统的参与者后，我们必须确定参与者所使用的用例，以使系统正常运行。用例是参与者与系统交互过程中需要系统完成的任务。识别用例最好的方法是从参与者的角度开始分析，这一过程可通过提出“要系统做什么？”这样的问题来完成。由于系统中存在两种类型的参与者，下面分别从这两种类型的参与者角度出发，列出了图书管理系统的基本用例。 图书管理员所涉及到的系统用例： 借阅图书 归还图书 查看借阅信息2.3.3 确定系统的用例 1. 借阅者请求服务的用例 2. 图书馆管理员处理借书、还书等的用例 3. 系统管理员进行系统维护的用例 1. 借阅者请求服务的用例登录系统 查询自己的借阅信息查询书籍信息预定书籍借阅书籍归还书籍2. 图书馆管理员处理借书、还书的用例处理书籍借阅处理书籍归还 删除预定信息3. 系统管理员进行系统维护的用例查询借阅者信息