当前位置：文档之家 › 第3章 用例和用例图

第3章 用例和用例图

  • 格式：ppt
  • 大小：1.27 MB
  • 文档页数：63

下载文档原格式

  / 63

合集下载

第3章 用例图及其应用

第3章 用例图及其应用

1 基本概念
1.2 用例
– 定义
对一组动作序列的描述,系统通过执行这一组动作序 列为参与者产生一个可观察的结果
– 用例特征
说明了系统具有的一种行为模式 说明了一个参与者与系统执行的一个相关的事务序列 提供了一种获取系统需求的方法 提供了一种与最终的用户和领域专家进行沟通的方法 提供了一种测试系统的方法
– 2)包含关系 )
是一种构造型关系,它将一个基用例连接到一个包含用 例 UML1.1中为使用关系,在1.3中改为包含关系 包含关系在一个用例中重用另一个用例中的步骤 包含关系用带箭头的虚线表示,沿线上加一个用双尖括 号括起来的"include"
2 关系及其应用
2.4 关系的扩展
使用包含关系的三种情况: a.如果有多个用例,并且这些用例包含大量类似 的行为,应该考虑将这些类似的行为通过包含关 系包含到用例中 b.对两个或多个互相独立的用例建模时做了重复 的工作,可以通过包含关系包含这些重复的工作 c.如果某个行为可能会引入冗余,或者,当行为 发生变化时可能导致不一致性,这时,应该对这 种行为进行孤立建模并将它包含到用例中
3 参与者规范及应用
3.1 参与者规范
– Rose在实现中对参与者和类使用相同的规 范窗口,包括如下一些标签:
General Detail Operations Attributes Relations Components Nested Files
3 参与者规范及应用
3.1 参与者规范
– General标签
Name Stereotype Documentation
3 参与者规范及应用
3.1 参与者规范
– Detail标签
Multiplicity (参与者基数)

第3章 用例图

第3章 用例图

为了保证系统正常运行，谁将对系统进行维护管理

（副参与者）？ 谁将完成系统数据的录入、导出及修改等工作（主 动参与者）？ 谁或什么系统对系统产生的结果感兴趣（被动参与 外部系统进行交互？ 在预定的时间，是否有事件自动触发？ 系统从何处获取信息？
（2）参与者不一定是人，也可以是一个外部系统， 该系统与本系统相互作用。代表的是一种角色。 （3）在系统的实际运作中，多个不同的用户可能 只对应于一个参与者；同时一个实际用户也可 能对应系统的多个参与者。
例如： 在“房地产开发经营管理系统”中，
所有的购房者作为一个集合，在“房屋销售子 系统”中作为购房合同的签约方出现，多个个 体在系统中担任一个参与者；同时，某个独立 的购房者在“物业管理子系统”中又作为房屋 的业主出现，同一个人在系统中担任了两类参 与者。
主参与者和副参与者
主参与者使用系统的主要功能，是使用系统较 频繁、业务量较大的用户。 副参与者处理系统的辅助功能，它与用例进行 交互的主要目的是为了给其他的参与者提供某些服 务。如管理数据库、通信、系统备份以及其他管理
等系统维护工作。
主动参与者和被动参与者
主动参与者是系统的启动者，负责启动一个或多
借阅图书用例的描述
用例名称 标识符 用例描述 参与者 状态 BorrowBook UC0001 图书管理员代理借阅者办理借阅手续 图书管理员 通过审查
前置条件
后置条件 假设 基本操作流程
图书管理员登录进入系统
如果这个用例成功，在系统中建立并存储借阅记录 图书管理员已经成功地登录到系统 1. 2. 3. 4. 5. 管理员输入借书证信息 系统验证借阅证的有效性 图书管理员输入图书信息 添加新的借阅记录 显示借书后的借阅信息

第03章 用例和用例图

第03章 用例和用例图

5
用例的特点 ① 用例用于描述系统的功能，这个功能是外 部使用者看到的系统功能，不反映功能的实现 方式。
储蓄系统
开户 存款
√
√ √ √
取款
转帐
6
用例的特点
② 用例描述用户提出的一些可见需求，对应 一个具体的用户目标。
储蓄系统 √ √ √ 开户 存款 取款 转帐
√
×
数据上传
7
用例的特点 ③ 用例反映系统与用户的一次交互过程，应 该具有交互的信息的传递。
泛化关系代表一般与特殊的关系, 与继承类似.
在泛化关系中, 子用例继承了父用例的行为和含义, 子用例也可以增加新的行为和含义或覆盖父用例中 的行为和含义.
20
3.4.2 泛化关系
21
3.4.3 包含关系
包含关系是指一个用例(基本用例)的行为包含了另一 个用例(包含用例)的行为.
包含关系是依赖关系的版型, 但其含义更多.
3.6 用例的描述
用例阐述：写用例规约

用例规约：更进一步的精度
用例文档的核心，作为用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值

用例图是骨架，而用例规约则是其内在的血肉
43
3.6 用例的描述
谁来写用例文档 ?



最完美：业务人员接受训练，写出优美的 用例文档 最现实：业务人员提供素材，开发人员写 用例文档 最糟糕：业务人员不管，完全由开发人员 杜撰
3
3.7 寻找用例的方法
3.8 用例的常见问题
15
3.3 脚本
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用来显示用例中的某种特殊情况. 其它译名: 情景、场景、情节、剧本.

用例及用例图案例

用例及用例图案例
第3章
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统（或工作内容） – 帮助业务过程重建工程工作 – 帮助员工（小组内成员）充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例：预订变更 ●参与者：柜台工作人员 ●说明：
Ａ２：有冲突。
⑧系统添加新课程，并提示添加成功。
⑨系统回到管理主界面，显示所有课程，用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图，解决用例之间的冲突和重复。
15
案例3：
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的 功能。
第3章 用例和用例图
● 3.4 用例图 3.4.1 用例图的作用 3.4.2 用例图的形式
● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
● —— 重要知识点
26
本章作业
(1) 什么叫用例？ (2) 用例图在软件建模中的作用是什么？ (3) 用例之间存在那几种关系？ (4) 包含关系和扩展关系有什么区别? (5) 参与者可以是那几种形式？ (6) 什么叫事件流,作用是什么？

uml仓库管理系统课程设计

uml仓库管理系统课程设计

uml仓库 管理系统课程设计一、课程目标知识目标：1. 学生能理解UML的基本概念，掌握UML图的使用方法。

2. 学生能掌握仓库管理系统的功能需求、业务流程和数据流程。

3. 学生能运用UML图描述仓库管理系统的静态结构和动态行为。

技能目标：1. 学生能运用UML工具绘制类图、用例图、序列图等，对仓库管理系统进行建模。

2. 学生能通过小组合作，分析和解决实际项目问题，提高团队协作能力。

3. 学生能运用所学知识，对仓库管理系统进行优化和改进。

情感态度价值观目标：1. 学生通过课程学习，培养对软件工程和系统分析的兴趣，提高学习积极性。

2. 学生能够认识到UML图在软件开发中的重要性，增强对软件工程规范的认识。

3. 学生在课程实践中，培养认真负责、严谨细致的工作态度，提高沟通协作能力。

课程性质：本课程为实践性较强的课程设计，旨在让学生运用所学知识，结合实际项目，进行UML建模和系统分析。

学生特点：学生处于高年级阶段，已具备一定的编程基础和软件工程知识，具备独立思考和解决问题的能力。

教学要求：教师需引导学生运用UML工具进行系统建模，注重培养学生的实际操作能力和团队协作精神，提高学生对实际项目的分析和解决能力。

通过课程目标的实现，为学生的未来职业发展奠定基础。

二、教学内容1. UML基本知识回顾：包括UML的基本概念、类图、用例图、序列图等。

教材章节：第一章 UML基本概念；第二章 类图与对象图；第三章 用例图与序列图。

2. 仓库管理系统需求分析：学习如何进行系统功能需求、业务流程和数据流程分析。

教材章节：第四章 系统分析与设计；第六章 数据流程图。

3. UML建模实践：a. 运用UML工具绘制类图、用例图、序列图等。

b. 根据仓库管理系统需求，进行系统建模。

教材章节：第二章 类图与对象图；第三章 用例图与序列图；第五章 UML工具使用。

4. 仓库管理系统优化与改进：结合实际情况，对系统进行优化和改进。

教材章节：第七章 系统优化与改进。

第三讲 用例图

第三讲 用例图

用例描述——事件流
1、事件流
事件流描述了一个用例在执行时参与者 与系统之间的交互过程。 其中预期会成功的路线称为基本流，剩 下其他路线称为备选流。
基本流
• 基本流是对用例中常规和预期路径的描 述。
• 执行者通过这个路径来执行用例可以得 到一个有价值的结果。
用例描述——事件流
• 例如，银行自动取款机(ATM)系统中的 “提款”用例可以用事件流表述如下：
•提款─基本事件流 1. 用户插入信用卡 2. 输入密码 3. 输入提款金额 4. 提取现金 5. 退出系统，取回信用卡
备选流
在用例的执行过程中，不一定都按常规 和预期的路径进行。 由于受到其他一些因素的影响，这时可 能执行了其他的路径，这种路径叫做备 选流。
备选流
•提款─备选事件流：
1.a ：如果用户插入无效信用卡，系统显示错误并 退出信用卡，用例结束。
• 用例分析技术是一种用户需求获取、分 析和描述技术。
• 用例图主要用于需求分析阶段。 • 用例图描述了待开发系统的功能需求。 • 用例图从用户的角度来理解系统，不关
心系统的内部结构。 • 用例图是后继各阶段开发工作的基础。
用例图
• 用例图是显示一组用例、参与者以及它们之间 关系的图。
– 用例图从用户的角度而不是开发者的角度来描 述对软件产品的需求，分析产品所需的功能和 动态行为
用例或关联参与者？
用例之间的关系
泛化关系 包含关系 扩展关系
用例之间的关系
泛化：同一业务目的的不同技术 实现。 包含：表示一个用例使用了另一 个用例的行为或功能。通过包含 用例提取公共交互，提高复用。 扩展：描述某个用例的特殊情况。 “冻结”基用例以保持稳定。
*通过关系提高用例复用

第三章 用例和用例图PPT课件


精选课件
9
3.2.2 识别参与者(actor)
对于一个大系统，难以列出所有用例的清单。此时，应先 列出所有的参与者，然后在对每个参与者列出他所需的所 有用例。即提供了一种获取用例的系统化过程。
“参与者”（活动者、执行…者）是指在系统之外，透过系 统边界与系统进行有意义交互的任何事物。
精选课件
10
3.2 识别参与者
精选课件
14
思考：识别参与者？
• 寻呼台系统：用户如果预定了天气预报，系统每天定
时给他发天气消息；如果当天气温高于35度，还要提 醒用户注意防暑；
在这个叙述里，谁是寻呼台系统的Actor？ 用户？气温？时间？
时间作为参与者，一种习惯用法，用于激活那些系统定 期的、自动执行的用例
精选课件
15
3.2.2 识别参与者：参与者与系统边界
精选课件
40
3.2.4 用例之间的关系
Generalization 泛化关系中，子用例继承父用例的行为和含义，子用例也 可以增加新的行为和含义或覆盖父用例中的行为和含义
<<include>> Include
一个用例（称作基本用例）的行为包含了另一个用例（称 作包含用例）的行为
<<extend>> Extend 扩展关系比泛化关系用更多的规则限制，基础用例提供扩 展点，扩展用例只能在这些扩展点上增加新的行为。
精选课件
19
识别参与者：棋牌馆管理系统
目标：构建一个棋牌馆管理系统 问题描述： 客户通过Internet预订座位，检查座位详情，如果没有空闲 的座位或满意的座位，可以选择进入等候队列。 总台服务员在客户到棋牌馆时，根据客户的预订信息，安排 客户座位。 当客户要离开棋牌馆时，客户到总台服务员办理结账，可以 采用两种方式，一种是现金结账，另一种是银行卡结账，而 银行卡结账将通过与银联POS系统交互来完成。

实验报告1--用例和用例图

中北大学软件学院实验报告
专业：软件工程
方向：软件开发与测试
课程名称： UML
班级：
学号：
姓名：
辅导教师：井超
2017年3月制
4.用例图如下所示
1).系统参与者
系统角色
2).图书管理
图书管理用例图3).图书借阅和还书用例图
图书的借阅和归还用例4).图书管理系统的整体用例图
图书管理系统的整体用例图
5.实验结论及心得
通过本次实验，我掌握了在课堂上学习的用例图等。

加深了对书本知识的认识和记忆。

在实验中我学会了去如何操作ro se工具图。

通过ro se工具图，可以去清晰的去展示一个关系等。

使用非常方便。

【精品】3章用例图习题

【关键字】精品第3章用例图习题一、简答题1. 什么叫参与者，参与者有哪些基本特性？答：参与者也被称为活动者，是与系统发生交互的外部实体。

参与者的特性有：1）参与者位于系统的外部，不属于系统的内容；2）参与者与系统发生交互关系，交互关系主要有：使用系统，启动系统，获取系统信息或给系统提供信息；3）参与者和系统之间存在交互信息的接口，系统提供接口让参与者使用系统，或者系统通过参与者的接口与参与者进行交互。

2. 用例有哪些特性？答：概括起来，用例有以下特性：1）用例描述用户对系统的期望，被用于软件需求建模，一个用例对应于软件能够为参与者提供的一项服务。

2）用例反映参与者与系统一次完整的交互过程。

这个交互过程总是要耗费一段时间，并执行一定的流程。

流程的执行是参与者与系统的一段互动过程，在这个过程中有输入到系统的信息，以及系统反馈给参与者的信息。

3）用例的执行过程是系统为参与者的一次服务过程，这个服务就体现为系统提供给参与者的功能。

一个用例执行的完成，需要有确定的评价结果，这个结果表现为系统提供给参与者的一项完整的功能。

4）用例是软件设计和测试的依据。

3. 用例之间有哪几种关系？答：泛化关系，包含关系，扩展关系。

4. 用例叙述应该包括哪些基本内容？答：包括：用例编号，用例名，参与者，前置条件，事件流，后置条件。

二、填空题1. 用例图的要素包括（参与者）、用例和（关系）。

2．参与者的英名名称是（actor），参与者也被称为（活动者）。

3．参与者的类型可以是（人）、设备、（外部系统）和时间。

4．用例的英名名称是（usecase），也被称为（用案）和（用况）。

5．用例之间的关系有（泛化）、包含和（扩展）。

6．执行用例之前系统所处的状态被称为（前置条件），（事件流）被称为用例执行的流程。

三、选择题1．下面不属于用例图作用的是（C ）A：展现软件的功能B：展现软件使用者和软件功能的关系C：展现软件的特性D：展现软件功能相互之间的关系2．下面（B ）不属于用例图的要素A：参与者B：包含C：用例D：关系3．下面对参与者说法不正确的是（A ）A：是系统的一个实体B：也叫活动者C：在系统外部D：与系统发生交互4．下面（D ）不属于参与者类型（）A：人B：设备C：外部系统D：交互对象5．下面对用例说法不正确的是（C ）A：usecase B：用况C：使用情况D：用案6．下面不属于用例特点的是（B ）A：用例描述用户可见的软件功能B：用例反映功能的不同抽象层次C：用例反映参与者与系统一次完整的交互过程D：用例是软件设计和测试的依据7．下面不属于用例之间关系的是（A ）A：关联B：泛化C：包含D：扩展四、练习题1．根据你的理解，把下面的用例图补充完整。

第3章 用例图


案例分析--用例图
实例：“杂志流通”
在杂志的内容被一个雇员分析之前，每个杂志 首先由图书馆登记；分析员认为有意义的文章 被汇总输入到系统中；随后，杂志在雇员中传 阅。在此过程中，要求生成流通通知。该通知 被附到杂志上，并且包含现在正在阅读杂志的 雇员的名字。最后，在最后一名读者把杂志返 回到图书馆时，它由图书馆来存档。
3.1 参与者
从上面的问答得到系统中初步的类和对象：
GUI（图形用户界面）：识别用户的命令，接收 用户的输入，显示程序的结果。
Recorder（记录员）：记录中奖信息。 Chooser（抽奖者）：抽出中奖号码。 Printing（打印对象）：打印中奖信息。 Searching（查询对象）：为奖票持有者查询中
3.2 用例
问：抽奖主持人用这个系 抽奖程序初步的用例图
统做什么事情？兑奖人员
抽奖程序
如何用这个系统帮助兑奖
？
抽出中奖号码
答：抽奖主持人用这个系统 活动主持人 抽出中奖号码，兑奖人员用
活动主持人
这个系统打印本次活动所有
打印中奖记录
的中奖记录。再对照记录兑 兑奖者
兑奖者
奖。
查询中奖情况
奖票持有者
奖票持有者
用例图的构成4要素：
参与者 用例 系统边界 关联
用例图的基本概念
3.1 参与者
1. 参与者(Actor)的概念
参与者是指存在于被定义系统外部并与该系统发生 交互的人或其他系统，他们代表的是系统的使用者 或使用环境。
在确定系统的用例时，首要问题就是识别参与者 （是一个类！！！！！！不是对象）。
如何识别用例？
参与者要向系统请求什么功能？ 每个参与者的特定任务是什么？ 参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗？ 是否任何一个参与者都要向系统通知有关突发性的、外部的改变？
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

– 包含（Include）
– 扩展（Extend）
处理订单
处理急单
应用这些是 为了抽取出 系统的公共 行为和变种。
查询订单
验证用户
验证密码 扫描指纹
泛化（Generalization）关系
• 一般和特殊的关系（继承关系）
处理订单
处理急单
查询订单
验证用户
验证密码 扫描指纹
包含（Include）关系
Use Case
3.3 脚本（场景）Scenario
• 脚本（场景）：用户与系统之间的一个交 互过程，即为实现这次交互所要经历的一 系列步骤
– 例：假设有一个基于Web的在线购物站点，我 们可以给出这样一个购物场景：
• 主场景：顾客浏览了货单并将感兴趣的物品添加到 购物筐中。如决定购买，则说明要购买的物品，提 供信用卡信息并确认购物清单。系统将检查信用卡 的合法性并确认销售结果。给客户发出确认电子邮 件
3.5 用例图
• 是显示一组用例、参与者以及它们之间 关系的图
• 一个用例模型由若干个用例图描述
用例图中的图符
用例
执行者 系统
《包含》
泛化
《扩展》
注释体
关联
注释连接
用例图中的模型元素
系统、执行者和用例
系统：一个提供“用例”所需要的功能的“黑 盒 子”。系统的外部特性由系统的功能来定 义；整个系统的功能用一组用例来描述。
一个用例（基用例，基本用例）可以包含其他用例（包 含用例）具有的行为，并把它所包含的用例行为作为 自身用例的一部分，这被称为包含关系。 UML中，包含关系表示为虚线箭头加版型《include》 箭头从基本用例指向包含用例。
包含（Include）关系
• 一个用例（基本用例）的行为包含了另一个用例（包含用 例）的行为
• 备选场景；信用卡失效
用例Use Cases
• 用例：一组场景，用以共同描述用户的 某个特定的目标。
• 例：
– 用例：购买商品
用例：购买商品
– 主场景：
1. 顾客浏览货单并选择要买的商品 2. 顾客来付款 3. 顾客填写采购信息（地址、隔天或3天送货） 4. 系统显示价目信息 5. 顾客填写信用卡信息 6. 系统检查信用卡的合法性 7. 系统确认销售 8. 系统给客户发出确认电子邮件
候选场景
– 候选场景：信用卡失效
• 系统检查信用卡失败。允许客户重新执行第5步
– 候选场景：固定客户
• 3a. 系统显示当前购物信息、价格信息、信用卡 的最后四位数字
• 3b. r)
• 指系统以外的、需要使用系统或与系统交互的东西 • 可以是人、设备或外部系统。
包含与扩展关系的区别
包含：源用例没有目的用例就不能工作。 扩展：源用例即使没有目的用例也能工作得很好。
参与者与用例之间的关系
关联关系Association
关联关系描述参与者与用例之间的关系， 关联关系表示参与者和 用例之间的通信。在UML中，关联关系用直线或箭头表示。 如果参与者启动了用例，箭头指向用例；如果参与者利用了用例提 供的服务,箭头指向参与者。如果二者是互动的，则是直线。
• 是依赖关系的版型
从包含用例 指向被包含
的用例
处理订单
处理急单
查询订单
验证用户
验证密码 扫描指纹
扩展（Extend）关系
• 基本用例必须声明若干扩展点，而扩展用例只能在这些扩 展点上增加新的行为和含义
• 被扩展的用例是可选的 • 是依赖关系的版型
从扩展用例 指向被扩展
的用例
处理订单
处理急单
查询订单
执行者的获取
执行者主要是业务的客户，而不是操作员。通过 用户回答问题可以帮助我们识别执行者。以下问 题可供参考：
谁使用系统的主要功能(主要使用者)？谁需要 系统支持他们的日常工作？
谁来维护、管理系统使其能正常工作(辅助使用 者)？
系统需要控制哪些硬件？系统需要与其他哪些 系统交互？
对系统产生的结果感兴趣的是哪些人或哪些事 物？
• 确定需求：
– 软件开发中的一个致命的问题 – 为此，各有关方面需要大量的交流，以增进
对需求的了解。 – 然而，对各方所关心的事情的描述却都是粗
糙的（非形式化）、口头的或是一些杂乱的 草稿，没有文档
• 怎样描述用户所关心的事情？
– 用例是对（用户）所关心的事情的描述。
用例（Use Case）
•用例是一个叙述型的文档 ，用来描述一个参与者 （Actor）使用系统完成某个事件时的事情发生顺序。 用例是系统的使用过程。更确切的说，用例不是需求 或者功能的规格说明，但用例也展示和体现出了其所 描述的过程中的需求情况。 •图形上用例用一个椭圆来表示，用例的名字可以书 写在椭圆的内部或下方。
扩展：当一个用例是另一个一般化用例的特例 时，用扩展关系。因此，当描述一般行为的变化 时，采用扩展关系。
要说明扩展点
用例图中的模型元素(续2)
注释体和注释连接
文档属性：必要时，要 对用例图中的各个成分 进行文字说明，称之为 用例图的文档属性。文 档属性用注释体和注释 连接表达，其中：
注释体用于对UML实体进行文字描述。
对执行者的描述
执行者是类，因而可用执行者的类名及其属性 和行为来描述。
有必要时增加注解，对使用者情况和要求等加 以说明。
执行者之间的关系与其他类之间的关系相同。 在用例图中，只有泛化关系用来描述某些执行 者之间的公共行为。
3.7.3 找出用例
首先获取简单的、常规的用例作为基本用例
当一个用例与另一个用例相似，但比另一个用例做 的动作要多，采用扩展关系：
对用例模型关心的人员
客户：他关心如何使用系统的功能；充当模型中 的哪一个角色；如何调整模型可以更好地适应他 们的愿望。
开发人员：他需要理解系统的功能，以作为今后 工作的基础和依据；在系统集成测试期间，可以 使用这些用例测试系统。
其他人员：销售人员，技术支持人员，文档编写 人员等也关心用例图。
3.1 用例
一个执行者代表一个角色，执行一个类；因此一个执行者的 名字不应使用该执行者的某个具体实例的名字。
一个人在系统中的角色可以被限定为一个角色；但也可以担 任不同的角色，充当不同类的执行者。
执行者与系统和用例之间的关系
执行者与系统之间的交流是通过收发消息。 一个简单用例总是由一个执行者通过发消息的方 法(刺激)创建；一个复合用例总是由一个或若干 个执行者通过发消息的方法(刺激)创建。 当执行一个(简单的或复合的)用例时，它会发一 些消息给一个或多个执行者。
顾客
用例描述：购买商品
– 主场景：
1. 顾客浏览货单并选择要买的商品 2. 顾客来付款 3. 顾客填写采购信息（地址、隔天或3天送货） 4. 系统显示价目信息 5. 顾客填写信用卡信息 6. 系统检查信用卡的合法性 7. 系统确认销售 8. 系统给客户发出确认电子邮件
候选场景
– 候选场景：信用卡失效
注释连接将注释体与要描述的实体相连，说明 该注释体是针对该实体所进行的描述。
3.6 用例的描述
• 用例的具体说明
– 用例的目标 – 用例是怎样启动的 – 参与者和用例之间的消息是如何传送的 – 主要路径和其他路径 – 用例结束后的系统状态 – 其他
• 用例模板P30 表3.2
建立用例模型
购买商品
《Actor》 LoanOffcer
《Actor》 LoanOffcer
Icon形式
Label形式 Decoration形式
参与者泛化
• 参与者之间的继承关系
顾客
会员
非会员
3.4 用例间关系
• 用例除了与其参与者发生关联外，还可以参与系统中
的多个关系，这些关系包括：
– 泛化（Generalization）
对用例中的每一步，问一下“这儿可能出现什么异 常情况”以及“是否需要采取不同的解决方法”； 将所有出现变动的部分列出，作为给定用例的扩展。
一旦获取了系统的执行者，就可对每个执行者提出 一些问题，然后从执行者对这些问题的答案中获取 用例。
建立用例模型
3.8 例：餐馆预约系统
• 记录一个新的预约信息（记录预约） • 取消一个预约信息（取消预约） • 记录一位顾客的到来（记录到达） • 将一位顾客从一张餐桌移到另一张餐桌
第3章 用例和用例图
用例、参与者、脚本、用例间关系 用例模型(用例图)的建造
用例分析的目的
描述和决定系统的功能需求，帮助客户和软件开 发人员形成一致意见。
给出系统应该做什么且与内容一致的可视化描 述，使之成为在开发全过程中研讨系统需求和进 行系统设计的依据。
在软件测试阶段作为系统测试的基础。
建立系统实现的各个对象类和系统操作与功能需 求之间的可追踪关系。
用例图举例
练习
答案：1、2、3、4
如图所示，下面那个语句是正确的？ （多选） 1. X3可以使用UC4与系统交互。 2. X1可以使用UC1和UC4与系统交互 3. X3、X1与X2不同 4. UC3是没有步骤的抽象用例
练习
答案：1、4
如图所示，下面那个语句是正确的？（多选） 1. UC5是UC4的补充部分 2. UC4是UC5的可选部分 3. UC1是没有用的 4. UC2是UC4的可选部分 5. UC4是UC2的补充部分
包含：由用例A连向用例B，表示用例A中使用了 用例B中的行为或功能。
扩展：由用例 A连向用例 B，表示用例B描述了 一项基本需求，而用例A则描述了该基本需求的 特殊情况，即一种扩展。
包含与扩展关系的选择
下列规则可用来判断应采用包含关系或扩展关系：
包含：当一个通用的用例可以成为几个特殊的用 例的组成部分时用包含关系。因此，当在两个或 更多的用例中出现重复描述而又想避免这种重复 时，采用包含关系。