《用例建模与分析》PPT课件

5. 用例
用例描述一系列动作，系统执行这些动作，以产生某个特定参与者能 够观察到的结果。即用例是参与者与系统之间对话的抽象，描述可能的 交互，而不深入某个场景的详细细节。
在UML中，使用带有描述参与者目标标签的椭圆形表示用例。使用直线
表示通信链接，将用例连接到一个或多个参与者。如在与ATM系统的交
互过程中，客户目标之一是从账户中取款，其用例可表示如下。
《include》关系用于两个或多个用例中，以共享事件流中某些公共部分。 然后将该公共部分分组并提取出来，形成一个包含用例，在两个或多个用 例中共享。 2. 《extend》关系
如果两个用例相似，但一个用例比另一个用例所做的事稍多一些，则可 以使用《extend》关系。例如，可以使用一个用例来捕获典型情况（基本 用例），然后使用扩展来描述各种变化，使基本用例可以有条件地调用某 个用例。即扩展用例向基本用例中添加了一些额外的行为。如取款有一个 可能的行为，就是需要处理超额取款。
中得到。如下面的例子所示。
5
3 GIS软件工程—用例建模与分析
报税表可以由纳税人（直接参与者）直接提交，也可以通过Internet或邮 寄进行，若是后面一种情况，就需要数据录入员将报税表单中的数据录 入系统，数据录入员可视为次要参与者，因为他们帮助报税人处理报税 表单。
4. 参与者与角色
在用例建模中，参与者的精确含义应该是一组角色，个人或其它外部 系统都能扮演这些角色。同一个人可以在不同的时间扮演不同的角色， 具有相同职务头衔的职员，可以扮演不同的角色以适应业务需求的需要。
12
3 GIS软件工程—用例建模与分析
3.6.2 用例建模的UML表示法小结
现将用例建模的UML表示法小结如下：
用例：系统执行的一系列事务， 通过这些事务，系统产生某个特 定用户可度量的结果。
用例名
参与者：用户在与这些用户交互 时所扮演的一组角色。
系统边界：物理系统与该物理系统进行 交互的参与者之间的边界
2
3 GIS软件工程—用例建模与分析
用例必须从用户的角度描述所期望的系统行为，完整的用例集合确定了 系统的范围，包含了系统的所有行为。用例应作为需求定义单元或仅仅作 为一个用户目标。
3.4 用例建模技术
用例建模是一个从外部视角来描述目标系统行为的过程。用于描述系统 将要做什么，而不是如何做，主要帮助设计师关注系统需求，而不是系统 实现。用例图能够使系统设计师从用户的视角发现目标系统需求，是设计 师与用户进行沟通的有效工具。
❖完全位于系统外部，并驱动系统需求； ❖使用系统，以实现某个可观测的用户目标。 次要参与者是监督、操作和管理该系统的用户或者实体。扮演支撑角 色，以帮助主要参与者实现他们的目标，次要参与者特征包括： ❖次要参与者经常更多地出现在系统的内部而不是外部；
❖次要参与者经常指定很多系统需求，这些需求不能直接从需求陈述
基于这些需求，共有4个可观测到的服务可作为用例：预定、 取消预定、检入和检出。其用例模型如下图所示。
10
3 GIS软件工程—用例建模与分析
客户 团客 散客
Hotel Information System 预定房间 取消预定 检入房间 检出房间
处理房间预 定的职员
接待职员
11
3 GIS软件工程—用例建模与分析
1. 定义需求过程中的一般问题
软件需求规范中确定需求一般只是简单基于自然语言的说明性语句，开 发者总是使用规范中提供的经典场景来试图理解系统需求的含义以及期待 系统如何运转，软件需求规范的编写方式非常低效。而用例是可以将场景 捕获过程形式化的有用技术。
2. 用于需求获取的用例建模
用例（Use Case）是系统执行的一系列事件（操作），通过提供这些事件， 可以为特定参与者产生可度量的结果。参与者（Actor）是与系统进行交互 的某个人或者事物所扮演的角色。因此，用例是由一系列动作组成，用户 必须进行这些动作，以完成一些有用的工作并实现目标。用例反映了在实 现参与者目标的过程中，系统可能发生的所有事件。
6. 系统边界
定义了开发中的系统范围，在UML中用矩形表示边界，所有用例都必须
放在边界以内。参与者放在系统边界以外，所有用例共同组成了系统的总
需求。
7
3 GIS软件工程—用例建模与分析
3.5 用例建模示例
1. ATM系统 ATM通过计算机化银行网络进行账户交易，银行网络包含一台中心 计算机，它连接着所有的ATM机和单个银行拥有的银行计算机，每 台银行计算机用来处理由其客户请求的交易。 在这个例子中，客户Customer是ATM系统的一组参与者。他们操 作ATM存款、取款或者检查账户余额等。可以将这些可观察的服务 作为用来。
6
3 GIS软件工程—用例建模与分析
取款
参与者、用例和通信链接
好的用例应该满足的条件：
❖描述系统执行的一系列事务，这些被执行的事务可为特定参与者产生可 度量的结果。
❖从用户角度描述期望的系统行为。
❖使得系统分析使能够从高层次业务观点来理解系统，并为之建模。
❖表示系统提供给外部实体的接口，以及参与者与系统之间的相互关系。
3 GIS软件工程—用例建模与分析
3.1 概述
用例建模是用来捕获系统场景的形式化过程，是识别和定义 任何类型软件系统需求的重要方法。本章将重点讲述如何利用用 例建模，有效获取软件系统需求。
3.2 本章的重点
陈述用例模型的组件 描述用例模型如何辅助解决常见的需求定义问题 开发用例 为用例编写文档 将用例建模贯穿到项目生命周期中
用例模型（Use Case Model）是一幅图或一组图，还可能包含额外的资料， 用于表达所提交的软件系统要完成的工作。用例图由3部分组成：
参与者 用例以及用例之间的通信 额外文档 另外，用例图还包含系统边界。 1. 参与者 参与者是需要与系统交互信息的一切外部实体。主要包括以下几类： 3
3 GIS软件工程—用例建模与分析
3 GIS软件工程—用例建模与分析
ATM System
取款
《extend》
超额取款
《include》
存款
《inቤተ መጻሕፍቲ ባይዱlude》 账户登录
查询余额 《include》 显示《extend》和《include》关系的用例图
只有在定义了所有 用例之后，才能识别 和提取不同用例中相 似的行为，以形成抽 象用例。设计师要比 用户更加关注抽象用 例的提取。
参与者名称 系统名称
13
3 GIS软件工程—用例建模与分析
关联：参与者在某个用例中的 参与，如参与者的某个实例与 用例的某个实例进行通信 泛化：一般用例与较特定用例 之间的分类关系，箭头指向一 般用例。 扩展：扩展用例与其基本用例之 间的关系，指定如何将扩展用例 的行为插入到基本用例所定义的 行为中去，箭头指向基本用例。 包含：基本用例和包含用例之间 的关系，指定为包含用例定义的 行为如何插入到基本用例的行为 中去。箭头指向包含用例。
8
3 GIS软件工程—用例建模与分析
客户
联系
ATM Banking System 取款 存款
查询余额
系统名称 用例
系统边界
ATM系统用例模型
9
3 GIS软件工程—用例建模与分析
2. 酒店信息系统
考虑简单的酒店信息系统，有两类客户，即团客和散客。前 者是旅游承办商提前预定，后者是旅客直接与酒店进行预定。 两类客户都可以利用Internet或电话预定、取消、检入和检出 房间。
17
3 GIS软件工程—用例建模与分析
PayBill
Credit Card Bill
泛化关系
Utility Bill
4. 基本用例与抽象用例
一旦识别出系统的一组用例，就可以找到公共行为，通过提取这些用 例的公共行为，就可以形成一个基本用例（具体用例）和抽象用例。前 者基本上就是主用例，它可以直接由某个参与者实例化。它本身可实现 可观测的用户目标。后则只能由基本用例实例化，因为它只包含在两个 或多个用例之间共享部分的公共行为，即从用户角度看，它不是一个完 整的用户目标。如前面讲过的账号登录用例，就是一个抽象用例，它不 能完成一个完整的用户目标。
3.6 用例分析技术
3.6.1 进行用例分析
在用例分析过程中，通常可以访问客户和系统的典型用户。描述系 统的用例是一个实用且非常重要的练习，它有助于识别冗余或不清晰 的功能，用例分析有助于解决一些潜在的沟通问题。
在以下领域中需要使用用例分析： ❖发现新功能（需求）。在分析系统和深化设计的过程中，新的用例 常常可以帮助产生新的需求。 ❖与客户沟通。 ❖产生测试案例。用例的场景结合还可以提供一个测试套件，并作为 形成用户界面的起点。场景是捕获某个用例的某此特定执行。即用例 是泛化描述或者是一系列事务的模板，而场景是用例的一个具体实例。
取款
《include》
账户登录
存款
《include》
15
3 GIS软件工程—用例建模与分析
在UML中，支持3种用于用例的关系类型：《include》、《extend》和泛化。 UML构造型是书写在书名号（《》）中的标签，表示某些超出UML基本定 义的语义概念。使用UML构造型，可扩展UML语义，以便支持特定的设计 方法或设计师需求。 1. 《include》关系
2.表示参与者
参与者一般用人形简笔画来表示，即便参与者不是人类时，仍然使用这
种表示法。在UML中，可以用带有构造形的类图来表示参与者，将构造
形放在位于图标上半部分类名的上方，如下图所示。
4
3 GIS软件工程—用例建模与分析
《Actor》 Customer
3. 参与者类型
参与者可以分为主要参与者和次要参与者。所谓主要参与者是指主要 用户或系统设计时主要面向的实体。主要参与者应具备的关键特征包括：
取款
超额取款
基本用例中的扩展点
参与者可能直接调用基本用例，而抽象用例只能由基本用例实例化。 抽象用例的实例化必须返回到调用用例（基本用例），返回位置就是进 行调用的那个地方。抽象用例由从其他用例中提取出来的部分组成，抽 象用例类似于子程序调用，而基本用例就像是主程序。基本用例用于实19 现某个用户目标的全部行为，抽象用例实现基本用例的部分行为。
1
3 GIS软件工程—用例建模与分析
3.3 需求获取
需求是描述系统应该具备的功能，以及为满足此功能需要具备的条件。 需求用来描述系统应该做什么，而不是如何构建系统。可以直接从用户那 里获取需求，也可以在合同、标准、规范或其它正式使用的文档中来获得 需求。需求获取是定义系统的过程，包括对问题空间的清晰理解，然后定 义解决问题的应用或系统。
❖人；
❖计算机硬件或设备；
❖外部系统。
参与者代表了用户可以扮演的角色，不是某个特定的用户，而是可以扮 演某个角色的一组用户。一个人可能是某个参与者的实例，多个人也可 能扮演某个参与者的同一角色。
识别用例的通用方法是与将要直接操作该系统的用户交谈，该过程有 助于设计满足用户需求的系统。而系统的其它涉众可能在关键的开发阶 段漏掉，导致系统可能不满足所有涉众需求。在同一个软件系统中，不 同涉众的需求可能存在冲突，开发小组的通行做法是召集所有涉众，以 确定所有需求，同时解决存在矛盾的需求。
18
3 GIS软件工程—用例建模与分析
用例可能还展现多个场景，普通场景以及可能的几个其他场景。基本用 例可以用来表示普通场景，而抽象用例则可以用来描述其他场景。
下图给出了一个ATM系统的用例模型，取款是一个基本用例，是用户成 功登录系统的普通场景，指定交易类型，并输入取款的有效金额。而处理 超额属于抽象用例，因为用户的银行账户中可能有足够的钱供其取出。
《extend》
《include》
14
3 GIS软件工程—用例建模与分析
3.6.3 使用关系组织用例
在开发用例模型的过程中，可能会发现有些用例之间包含相同的行 为。在有些情况下，除了一些额外的行为之外，有些用例很相似。在 上面讲过的ATM系统中，取款、存款和查询余额都要先进行账户登录， 因此可以将用户登录作为单独的用例，其它用例可以共享这个用例。 在UML中，账户登录与取款和存款这两个用例之间的关系可以用 《include》来表示。
16
3 GIS软件工程—用例建模与分析
取款
《extend》
超额取款
3. 泛化关系 子用例可以继承父用例中的行为、关系和通信连接。即可以将子用例放
置在父用例出现的地方，子用例与父用例之间的关系是泛化关系。例如， 假设ATM可以用于支付账单，则它有两个子用例。一为Pay Credit Bill，其 一为Pay Utility Bill。