第三章 用例图

“供货”用例
• 考虑“供货”用例。供货人发起这个用例是由于某个时间 间隔到期所引起的。供货代表打开销售机拉出销售机前面 的架子，在架子上补满各种品牌的饮料。销售员还要在机 器中加零钱。然后他放好销售机的前端架子，并锁好机器。 这个用例的前置条件是一个时间间隔的流逝，后置条 件是供货人在机器中放置了新的待售饮料。
有时也会有分组的关系，分组是一组用例的简单组织方式。
1.泛化
用例的泛化是指一个父用例可被特化形成多个子用例， 而父用例和子用例之间的关系就是泛化关系。 • 在用例的泛化关系中，子用例继承了父用例所有的结构、 行为和关系。 子用例还可添加、覆盖、改变继承的行为 • 在UML中，用例的泛化关系是从子用例指向父用例的三 角箭头来表示。 • 当发现系统中有两个或多个用例在行为、结构和目的方 面存在共性时，就可用泛化关系。 这时，可用一个新的用例来描述这些共有部分，这个新 的用例就是父用例。 •
通过回答一些问题，可以帮助建模者发现角色： 使用系统主要功能的人是谁（即主要角色）？ 需要借助于系统完成日常工作的人是谁？ 谁来维护、管理系统（次要角色），保证系统正常工作？ 系统控制的硬件设备有哪些？ 系统需要与哪些其它系统交互？ 对系统产生的结果感兴趣的人或事是哪些？
3百度文库1.2 用例
“缺货”的场景
• 另一种“缺货”的场景。“指定品牌的饮料售完”消息 显示在机器上，直到对这台机器补充为止。在这种情况下， 用户不再输入钱了。销售机的客户可能更喜欢第一种场景： 如果顾客已经投了钱，应该让顾客做另外一种选择而不是 要机器退钱。
“付款数不正确”的 场景
• 紧接着让我们来看看“付款数不正确”的这个场景。顾客 按照通常的方式发起了这个用例，并进行了一个选择。假 设这是机器中备有选择的饮料。如果机器中刚好存有适合 的零钱，那么机器就会退还零钱并交付饮料。如果机器中 没有保存零钱，它将退还钱，并显示一条消息提示用户投 入适当的零钱。 前置条件和前面场景一样，后置条件是顾客得到一罐 饮料和找回零钱或者按原款归还钱。
例： 飞机订票系统中，预订飞机票有两种方式，一种是通过 电话预订，另一种是通过网上预订。
2. 扩展
有时我们可通过对已有用例增加一些额外的步骤来建立 新的用例。 • 在“供货”这个用例中，在给机器补充新饮料的时候， 供货代表注意到有些品牌的饮料销售的好，有些品牌的饮 料销售不好。在这种情况下，他不是简单的把所有品牌的 饮料补充给机器，而是把一些销售情况下不太好的饮料取 出来，用销售情况好的饮料来代替它们。同时供货代表还 要在机器前修改饮料品种的指示牌。 • 如果我们把上述的步骤加入到“供货”用例，我们将得 到一个新的用例，不妨称它为“根据销售情况供货”。这 个新用例是对原用例的扩展，这种技术叫做扩展用例。 •
•
（1）用例“买饮料”
• 这个用例的参与者是买饮料的顾客。顾客将钱插入销售 机触发了这个用例的场景被执行，然后用户进行选择。如 果一切顺利，销售机内至少还存储有一罐被选择的饮料， 则销售机会自动弹出这种饮料给顾客。 上面的“买饮料”场景是唯一可描述的场景么？。显然， 我们立即会想到还有其他的场景。顾客所要购买的饮料销 售机中可能没有。顾客投入的钱数不是刚好等于购买饮料 所需要的钱。应该如何设计饮料销售机来处理这些场景呢？
•
• 参与者可以分为两种类型： （1）主要参与者和次要参与者。 主要参与者指的是执行系统主要功能的参与者，次要参 与者指的是使用系统次要功能的参与者。 标识出主要参与者有利于找出系统的核心功能。 （2）发起参与者和参加参与者 发起参与者发起用例的执行过程，一个用例只有一个 发起参与者，可以有若干个参与者。 在用例中标识出发起参与者是一个有用的做法。
3.1.3 关系
• 用例图之间的关系分为3种： 用例和用例之间的关系； 参与者和参与者之间的关系；
用例和参与者之间的关系。
一、用例之间的关系
一般情况下，能够在用例之间抽象出包含、扩展和泛 化这3种关系。 • • • 包含——即在一个用例中重用另一个用例在步骤； 扩展——允许通过对已有用例增加步骤创建一个新的用 例； 泛化——指一个用例继承了另一个用例。
• 用例具有3个明显的特征： （1）用例表明的是一个类，而不是某个具体的实例 （2）用例必须由某一个参与者触发激活后才能执行，即 每个用例至少应该涉及一个参与者 （3）用例是一个完整的描述
“回顾”饮料销售机
• 在前面的分析中，我们获得了系统中有3个用例，分别是 “Buy soda（买饮料）”、“Restock（供货）”、 “Collect（收款）”。 • 参与者有Customer（顾客）、Supplier’s Representative （供货代表）和Collector（收款人）。
• 参与者是用例的启动者，参与者处于用例的外部并且 能够初始化一个用例，但它并不是所描述系统的一部分， 它可能是人或其他外界系统。 参与者是指存在于系统外部并直接与系统进行交互的人、 系统、子系统或类的外部实体的抽象。 每个参与者都可以参与一个或多个用例，每个用例也可 以有一个或多个参与者。
•
•
特别注意：参与者并不仅仅是指一个人，它代表的是 一个集合。也就是说，参与者（角色）是一个群体概念， 代表的是一类能使用某个功能的人或事，不能将角色的名 字表示成角色的某个实例（如，张三）。 参与者是启动用例的前提条件，先发送消息给用例，初 始化用例后，用例开始执行，在执行过程中，该用例也可 能向一个或多个角色发送消息
用例图主要用于描述系统的行为及各种功能之间的关系， 是描述参与者（Actor）与用例以及用例与用例之间关系 的图。 • 用例图从用户和外部系统的角度，分析和考察系统的行 为，并通过参与者与系统之间的交互关系描述系统对外提 供的功能特性，用例图用于描述系统与外部系统及用户之 间的交互。 • UML的用例图由参与者、用例及它们之间的关系组成， 它的表达方式为： 用例图 = 参与者 + 用例 + 关系 Use Case Diagram = Actor + Use Case + Relationship •
跟踪场景中的步骤
• 每个用例就是一组场景的集合，而每个场景又是一个 步骤序列。而这些步骤在上图中并没有表现出来。通常也 不用附加注释来说明这些用例。因为如果对每个用例都附 加注释进行说明，则布图就很混乱。那么如何并在哪里记 录和跟踪这些场景中的步骤呢？
• 用例图通常是供客户和开发组参考的一部分。每个用例中 的场景在文档中要描述下列内容： 发起用例的参与者 用例的假设条件 用例中的前置条件 场景中的步骤 场景完成后的后置条件 从用例中获益的参与者 要说明一个场景中的步骤，还可以使用UML活动图对 场景进行描述。
“取钱”用例
• 还有一个“取钱”用例，同样也是因为一段时间的流逝， 收款人发起了这个用例。它的前期工作步骤与”供货“一 样，也是打开销售机前端架子。收款人从机器中取出钱， 然后按照”供货“步骤，放回架子锁好机器。 这个用例的前置条件也是时间间隔的流逝，后置条件 是收款人收到了钱。
3.1.1 参与者
通过询问下列问题就可发现用例： 角色需要从系统中获得哪种功能？角色需要做什么？ 角色需要读取、产生、删除、修改或存储系统中的某 种信息吗？ 系统中发生的事件需要通知角色吗？或者角色需要通 知系统某件事吗？这些事件（功能）能干些什么？ 如果用系统的新功能处理角色的日常工作是简单化， 还提高了工作效率？ 系统当前的这种实线方法要解决的问题是什么？
•
假设正在对一台饮料机建模，这台饮料销售机允许顾 客选择买一罐饮料或是买一杯饮料。在这种情况下， “Buy Soda”就是一个父用例，“Buy a can of soda”和 “Buy a cup of Soda”就是子用例。用例之间的泛化关系 建模与类之间泛化关系建模方法相同，用一条带空心三角 形箭头的实线从子用例指向父用例。
3.1 用例图的构成
• 用例图可以用于描述系统的功能性需求和系统功能 的使用环境。 • 用例图可视化地描述了系统外部的使用者（抽象为 参与者）和使用者使用系统时系统为这些使用者提 供的一系列服务（抽象为用例），并清晰地描述了：
参与者和参与者之间的泛化关系； 用例和用例之间的包含关系、泛化关系、扩展关系； 用例和参与者之间的关联关系
•
理想情况下，顾客看到这条消息后会立即选择其它品牌 的饮料。销售机也必须提供给顾客取回原来的钱的选项。 这表示，销售机应给顾客两种选择：让顾客选择另一种饮 料并且给顾客提供这种饮料（如果这种饮料还有存货的话） 或者让顾客选择退钱。 该场景的前置条件是顾客感到口渴，后置条件是顾客 得到一罐饮料或者顾客投入的钱被退回。
•
一个基础用例可以拥有一个或多个扩展用例，这些扩 展用例可以一起使用。 在UML中，扩展关系通过带箭头的虚线段加 <<extend>>来表示，箭头指向基础用例。
• 用例是参与者可感受到的系统服务或功能单元。它定义 了系统如何被参与者使用，描述了参与者为了使用系统所 提供的某一完整功能而与系统发生的对话。
用例是站在用户的角度上（从系统的外部）来描述系统 的功能。 当系统有很多参与者时，用例是捕获系统需求 最好的选择。 • 所有用例都应有名称，建议使用动名词为用例命名。 • 用例名可以包括任意数目的字母、数字和除冒号以外的 大多数标点符号，用例的名字是一个能准确描述功能的动 词短语或动词词组。 •
•
没有所需饮料的场景
• 先看看没有所需的饮料这个场景，它是用例“买饮料” 的另一场景。可以把这个场景看成是用例执行时的一条可 选路径。用例是由顾客在销售机中插入钱币所发起的。然 后客户进行一个选择，销售机中至少要有一罐选择的饮料， 如果没有，销售机就给顾客提示一个信息，告诉顾客没有 这种品牌的饮料。
在一定条件下，把新的行为加入到已有的用例中，获 得的新用例称为扩展用例（Extension），原有的用例称 为基础用例（Base），从扩展用例到基础用例的关系就 是扩展关系。 • 扩展是两个用例之间的关系，它使得每个用例可以通过 扩展用例向基础用例中添加额外的行为来扩展基础用例的 功能。 • 用例的扩展机制允许从一个基础用例开始开发一个复杂 的系统，并且能够在不改变基础用例的前提下向基础用例 中扩展更多的行为。 •
• 要用在用例图上显示某个用例： 使用人形符号绘制一个参与者； 绘制一个椭圆表示用例，将用例的名称放在椭 圆的中心或椭圆下面的中间位置； 使用带箭头或不带箭头的线段来描述参与者和 用例之间的关系。
举例：饮料销售机
• 假设你现在正着手设计一台饮料销售机。为了获得用户 的观点，你会见了许多可能的用户以了解这些用户将如何 与这台机器交互。 饮料销售机的主要功能是允许一个顾客购买一罐饮料， 很可能用户立刻就能告诉你一些有关的场景（换句话说就 是用例），你可以给这组场景加上一个标签“买饮料”。 下面我们来考察这个用例中每一种可能的场景。
•
另一种可能是机器的储备零钱一旦用光，就会在机器 上显示一条小子告诉用户需要投入适当的零钱。直到对这 台机器补充零钱为止，这条消息才会消失。
（2）其他用例
• 已经从用户的观点考察了饮料销售机。除了这些用户外， 当然还有其他人加入。供货人负责为销售机提供饮料，收 款人（可能与供货人是同一个人）负责定期收集销售机中 的钱。这说明至少需要建立两个用例：“供货”和“取 钱”，这些用例细节可以通过与供货人和收款人交谈来获 得。
第三章 用例图
本章导读
• 知道参与者、用例和关系的概念 • 了解用例的粒度和规约 • 掌握参与者和用例的确定关系
思考学习以下内容
• • • 什么是用例？ 创建、包含和扩展用例等的思想 如何开始一个用例分析？
•
•
如何表示一个用例模型？
如何可视化用例之间的关系？
• 用户对系统的使用方式决定了系统如何设计和构造。用例 是能够帮助分析员和用户确定系统使用情况的UML组件。 一组用例就是从用户的角度出发对如何使用系统的描述。 • 可以认为用例是系统的一组使用场景。 • 用例图的主要要素是参与者、用例和关联。