用例和用例图

h
18
主要内容
基本概念：Use case、Actor、
Scenario Use case间的关系 Use Case 分析技术 案例讲解
h
19
关系
• 参与者与用例之间
– 关联关系
• 用例与用例之间
– 包含关系 (include) – 扩展关系 (extend) – 泛化关系 (generalization)
• 主事件流： • 1、系统显示ID和密码窗口； • 2、顾客键入ID和密码，然后按OK键； • 3、系统验证顾客ID和密码，并显示个人信息窗口； • 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然
后按OK键； • 5、系统验证用户是否为老顾客； • 6、系统显示可以卖的商品列表； • 7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购
• 用例结束后的系统状态
• 其他需要描述的内容
用例描述原则：尽可能写的“充分”，而不是追求写的形 式化、完整或漂亮。
h
32
h
33
书写用例文档
——路径交互步骤的描述
只书写“可观测”的 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节
h
34
书写用例文档
买的数量。选购商品完毕后按Done按钮； • 8、系统通过库存系统验证要购买的商品是否有足够库存； • …….（后续描述省略）
问题：对用户界面的描述过于详细，对于需求文档来说， 详细的用户描述对获取需求并无帮助。
h
45
改进后的描述
• Use Case：Buy Something • 参与者：Customer • 主事件流： • 1、顾客使用ID和密码进入系统； • 2、系统验证顾客身份； • 3、顾客提供姓名、地址、电话号码； • 4、系统验证顾客是否为老顾客； • 5、顾客选择要购买的商品和数量； • 6、系统通过库存系统验证要购买的商品是否有足

第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) 什么叫事件流,作用是什么？

用例
用例(use case)是Ivar Jacobson发明的. 其它的中 文译名有: 用况、用案等. 定义1: 用例是对一个活动者(actor)使用系统的一项 功能时所进行的交互过程的一个文字描述序列. 定义2: 用例是系统、子系统或类和外部参与者交互 的动作序列的说明, 包括可选的动作序列和会出现 异常的动作序列. 用例是代表系统中各个项目相关人员之间就系统的 行为所达成的契约, 软件开发过程是用例驱动的.
实例1：图书馆管理系统中的用例图
1.确定系统涉及的总体信息 图书馆管理系统是对书籍的借阅及读者信息进行统 一管理的系统，具体包括读者的借书、还书，书籍 预订；图书馆管理员的书籍借出处理、书籍归还处 理、预订信息处理；还有系统管理员的系统维护， 包括增加书目、删除或更新书目、增加书籍、减少 书籍、增加读者账户信息、删除或更新读者账户信 息、书籍信息查询、读者信息查询等。
用例图的作用
用例图展示了用例之间以及用例与参与者之间是怎样相互联 系的。用例图对系统、子系统或类的行为进行了可视化，使 用户能够理解如何使用这些元素，并使开发者能够实现这些 元素。 用例图主要用来描述用户的功能需求。UML侧重从最终用户 的角度来理解软件系统的需求，强调谁在使用系统、系统可 以完成哪些功能。用例分析技术已经是一种公认有效的用户 需求获取、分析和描述技术
情况二：假如机票购买者通过呼叫中心，由人工座席 操作订票系统购买机票，那么谁是参与者？
情况三：如果机票购买者通过呼叫中心的自动语音预 定机票而不是通过人工座席，那么谁是参与者？
情况四：如果扩大系统边界，让呼叫中心成为机票预 定系统的一个子系统，并且假设机票购买者将可以 自主选择是通过人工座席还是自动语音登录网站预 订机票，那么谁是参与者？

第一页，编辑于星期二：十三点 五十六分。
第二页，编辑于星期二：十三点 五十六分。
第三页，编辑于星期二：十三点 五十六分。
第四页，编辑于星期二：十三点 五十六分。
第五页，编辑于星期二：十三点 五十六分。
第六页，编辑于星期二：十三点 五十六分。
第七页，编辑于星期二：十三点 五十六分。
第八页，编辑于星期二：十三点 五十六分。
第二十三页，编辑于星期二：十三点 五十六分。
第二十四页，编辑于星期二：十三点 五十六分。
第二十五页，编辑于星期二：十三点 五十六分。
第二十六页，编辑于星期二：十三点 五十六分。
第二十七页，编辑于星期二：十三点 五十六分。
第二十八页，编辑于星期二：十三点 五十六分。
第二十九页，编辑于星期二：十三点 五十六分。
第十六页，编辑于星期二：十三点 五十六分。
第十七页，编辑于星期二：十三点 五十六分。
第十八页，编辑于星期二：十三点 五十六分。
第十九页，编辑于星期二：十三点 五十六分。
第二十页，编辑于星期二：十三点 五十六分。
第二十一页，编辑于星期二：十三点 五十六分。
第二十二页，编辑于星期二：十三点 五十六分。
第三十页，编辑于星期二：十三点 五十六分。
第三十一页，编辑于星期二：十三点 五十六分。
第三十二页，编辑于星期二：十三点 五十六分。
第三十三页，编辑点 五十六分。
第九页，编辑于星期二：十三点 五十六分。
第十页，编辑于星期二：十三点 五十六分。
第十一页，编辑于星期二：十三点 五十六分。
第十二页，编辑于星期二：十三点 五十六分。
第十三页，编辑于星期二：十三点 五十六分。
第十四页，编辑于星期二：十三点 五十六分。

基于用例的需求分析过程
获取原始需求
开发一个可以理解的需求
识别参与者
识别用例
确定关系
55/ 55
思考
软 件
工 基于用例的需求分析过程可大致分几步？ 程 什么是系统边界
用例的概念 用例的关系 参与者的定义与关系
56/ 55
软 实验06
件 工
画出系统用例图
程 注意用例的粒度与关系
软 用例粒度-3
件 “四轮马车”
工 程
C(Create)
R(Read)
U(Update)
D(Delete)
所有业务最终会成为CRUD？
CRUD能为Actor提供价值？
CRUD掩盖业务，锐变成关系数据库的建模：
“系统就是数据的增删改查”
关心数据的存储和维护，反而忽略了用户的目的
36
用例的动态执行过程可以用U M L的交 互作用来说明，可以用状态图、顺序图、 协作图、活动图或非正式的文字描述来 表示
25/55
用例的命名
软
件 执行者视角：
工
程 （状语）动词+（定语+ ）宾语
顾客
购买商品 <<extend>> 信用卡支付
26/55
识别用例
软
件 工
识别用例
程 关键词：价值
12/ 55
用例与用例关系
软
件 工
用例图
程
参与者
用例
用例关系
13/ 55
软 用例图
件 工 程
获取需求、指导测试、 对过程中的其他工作流 起指导作用
14/ 55
参与者
软 件
工 参与者，Actor

UML用例图的建模(续)
Record grades Update grades Generate cards
Distribute report cards
View grades
UML用例图的建模(续)
2、区分用例优先次序
这项任务通常是由系统分析人员完成，他们对哪一项任务 最关键，哪一项任务最艰巨有最好的全局认识。他们还可以确 定出哪个用例可以为其他用例所重用。在上例中，可以提出以 下优先次序列表：
UML的用例图标
UML用例图组成(续)
3、用例图的关联 1)角色与用例的关联 角色与用例的关联表示角色与用例相关性。在UML中是使
用一条实线连接角色与用例，如下图所示。
UML用例图组成(续)
成绩管理
UML用例图组成(续)
2）角色与角色的关联
角色与角色的关联用来表示一般角色与特殊角色的泛化关 系。在UML图中，使用带空心三角箭头的实线表示。如下图所示：
用例图在各种开发活动中被广泛使用,但 它最经常用做描述系统以及子系统.
UML用例图的作用(续)
• 用例图的主要作用：
– 用来描述待开发系统的功能需求和系统使用场景 – 作为开发过程的基础，驱动各阶段的开发工作 – 用于验证与确认系统需求
画好用例图是由软件需求到最终实现的第一步.
第二章 用例和用例图
(4) 统计
①经理能够使用系统的统计功能，了解商品销售情况、库 存情况、供应商情况，以便进行合理的营销策略。 ②经理按市场情况适时变动商品价格。
案例----超市进销存系统用例图建模
2.建立超市进销存系统的用例图模型
在系统需求分析中需考虑：系统用例图模型需要哪些视 图，每个视图包含什么内容？视图中成员是否需构成包？

访客用例图
会员用例图
书店管理员用例图
3、用例描述 （1）细化用例描述----搭框架

用例名称：搜索图书 概述：用户根据关键字搜索图书 前置条件：无 事件流： 基本事件流 扩展事件流 后置条件: 无
3、用例描述 （2）细化用例描述----填＂血肉＂

事件流： •基本事件流 1 用户点击“搜索图书”，用例开始。 2 系统显示搜索图书商品界面，提示用户输入商品关键字。 3 用户输入图书关键字，选择提交。 4 系统访问数据库，根据关键字查询相关的图书商品信息， 并把查询出的图书信息显示搜索图书页面。 5 用例结束。 •扩展事件流 4a) 系统未查出所要商品相关信息，显示提示信息，用例 结束。 4b) 系统查出用户输入的关键字为空，显示提示信息并返 回基本事件流2。

编写用例描述应遵循以下几点：



使用简单的语法，主语明确，语义易于理解；在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制； 从第三者观察的角度指出参与者的动作，以及系统的响应； 显示参与者的意图而非动作 显示过程向前推移，每一步都有前进感；

构建结构良好的用例
为系统和部分系统中单个的、可标识的、合理的原子行为 命名。 将多个用例的公共的行为抽取出来放到一个被包含用例中。 对于变化部分，将其抽取出来，放到扩展用例中。 清晰的描述事件流。


扩展关系（Extend）
扩展关系表示基本用例在由扩展用例间接说明的一个位置 上隐式的合并了另一个用例（扩展用例）的行为。 基本用例不知道扩展用例的任何细节，没有扩展用例，基 本用例是完整的。只有在特定条件下，它的行为可以被扩 展用例的行为扩展，因此扩展关系处理事件流的异常或者 可选事件。

4.2.3 泛化关系
借阅者
.9 泛化关系
4.2.4 分组关系
在一些用例图中，用例的数目可能很多，这时就需要把 这些用例组织起来。这种情况在一个系统包含很多子系 统时就会出现。另一种可能就是，当你按顺序和用户会 谈，收集系统需求时，每个需求必须用一个单独的用例 来表达，这时就需要某种方式来对这些需求进行分类。
4.1.1 参与者
例如，在“图书管理系统”中，可以认为“读者”是 “学生读者”和“教师读者”的泛化，而“学生读者” 还可以具体化为“本科生读者”和“研究生读者”；同 样，“图书管理员”也是“采购员”、“ 编目员”及 “借阅人员”的泛化。图4.3表示出了参与者之间的泛 化关系。
4.1.1 参与者
“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
4.2.2 扩展关系
借阅者
<<include>>
还书
<<extend>>
查询图书 交罚款
图4.8 扩展关系
区别与联系：
联系：都是从现有的用例中抽取出公共的那部分信息
，作为一个单独的用例，然后通过不同的方法来重用这 个公共的用例，以减少模型维护的工作量。
因此，在“图书管理系统”中“借阅者”和“系统管理 员”都是参与者。
4.1.1 参与者
【例4-1】客户给销售员发来传真订货， 销售员下班前 将当日订货单汇总输入系统。谁是系统的参与者？
分析：根据参与者的定义可知，此系统的参与者是销售 员。
4.1.1 参与者
【例4-2】在需求分析中常见的权限控制问题，一般的 用户只可以使用一些常规的操作，如查询等，而管理员 除了常规操作之外还需要进行一些系统管理工作，如一 些关键数据的增加、删除、修改等，操作员既可以进行 常规操作又可以进行一些配置操作。

取款 用例旳动态事件流
a 经过读卡机，储户插入ATM卡
b ATM系统从卡上读取银行ID、帐号、并验证帐号。 c 储户键入密码，系统检验密码。 d 储户按确认键，输入取款金额。 e ATM把帐号和取款金额传递给银行系统，取回帐户余额。 f ATM输出现金，并显示帐户余额。 d ATM统计事务到日志文件。

参加者
1. 参加者旳概念 参加者（actor）是外部需要与系统交互旳事物。
也被称为活动者。 2.参加者旳三种类型
①. 人：客户，读者，库管员 ②. 设备：计算机，磁盘，读卡机等 ③. 外部系统：上层系统等
参加者旳表达
参加者能够表达为下面三种形式。
参加者之间旳关系
参加者之间能够有泛化关系。
用例之间旳关系(1)
用例之间能够具有下列几种关系：
➢ 泛化关系 ➢ 包括关系 ➢ 扩展关系
参加者与用例之间旳关系
关联关系 参加者与用例之间是关联关系，表达参加者与用
例之间具有使用，交互信息旳关联。
用例之间旳关系(3)
泛化关系 参加者与参加者之间，用例与用例之间存在一般与 特殊旳关系。
用例之间旳关系(4)
包括关系 两个用例之间，一种用例(基本用例)旳行为包括了 另外一种用例(包括用例)旳行为。 包括关系用依赖关系旳<<include>>构造型来表 达。
某学校网上选课系统旳用例分析(1)
管理员经过系统管理界面进入系统，建立本学期 要开设旳多种课程，将课程信息保存到数据库中， 并能够对课程进行改动和删除。 学生经过客户机浏览器进入系统，选择课程：能够 查询课程，选择课程，支付课程费用。
某学校网上选课系统旳用例分析(2)
●找出系统外部参加者，拟定系统边界和范围。

前置条件
后置条件
一个条件列表, 这些条件必须在访问用例前得到满足
一个条件列表, 这些条件必须在用例完成之后得到满足
基本操作流程 描述用例中各项工作都顺利进行时用例的工作方式
可选操作流程 描述变异工作方式、出现异常或发生错误的情况下的路径
20 面向对象分析与设计 & UML
3.6 用例的描述
用例的描述格式(续表)
14 面向对象分析与设计 & UML
3.4.4 几种关系的比较
关系类型 关联 泛化 包含 扩展 说明 actor与use case之间 actor之间或use case之间 use case之间 use case之间 表示符号
15
面向对象分析与设计 & UML
3.5 用例图
用例图(use case diagram)是显示一组用例、参与者以及 它们之间的关系的图.
26
面向对象分析与设计 & UML
3.8 常见问题分析
(1) 用例的粒度问题
对于一个目标系统进行用例分析后得到的用 例数目有多少比较合适?
27
面向对象分析与设计 & UML
3.8 常见问题分析
(2) 用例的分解/合并 系统中相似的功能, 是合并为一个用例还是 分解为几个用例?
方法1 一中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况. 其它译名: 情景、场景、情节、剧本. 每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
例：在“订货”用例中包括几个相关脚本： • 订货顺利进行的脚本; • 相关货源不足时的脚本; • 购货者的信用卡被拒绝时的脚本; • ……

如何绘制用例图 1、用例分析技术步骤（不固定，可根据需要调整）：
⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ 找出系统外部的参与者和外部系统，确定系统的边界和范围。 确定每一个参与者所期望的系统行为 把这些系统行为命名为用例 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分 编制每一个用例的脚本 绘制用例图 区分基本事件流和异常情况的事件流，如有需要可以把表示异常 情况的事件流作为单独的用例来处理 ⑻ 细化用例图，解决用例间的重复与冲突。
用例之间的关系 4、参与者与用例之间的关系：关联关系Association
关联关系描述参与者与用例之间的关系，在UML中它是 两个或多个类元之间的关系，它描述了类元的实例间的 联系。(类元，一种建模元素，常见类元包括类、参与者 、构件、数据类型、接口、结点、子系统以及用例等， 其中类是最常见的类元) 关联关系表示参与者和用例之间的通信。在UML中，关 联关系用直线或箭头表示。如果参与者启动了用例，箭 头指向用例；如果参与者利用了用例提供的服务,箭头指 向参与者。如果二者是互动的，则是直线。 例：汽车租赁系统用例图(部分)。显示的是“客户”参与者以 及与他交互的3个用例，“预定”、“取车”、“还车” 。
FEAT01.新增书籍信息 FEAT03.书籍信息按计算机类、非计算机类分别建档 FEAT04.录入新书时能够自动按规则生成书号 FEAT05.计算机类与非计算机类书籍采用不同的书号规则 FEAT06.录入新书时如果重名将自动提示 FEAT02.修改已有的书籍信息 FEAT07.按书名、作者、类别、出版社等关键字组合查询书籍 FEAT08.列出所有书籍信息 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 FEAT09.记录外借情况 FEAT10.外借状态能够自动反应在书籍信息中 FEAT11.按人、按书查询外借情况 FEAT12.列出所有的外借情况 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 FEAT13.按特定时间段统计购买金额、册数 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行

扩展关系
扩展点是一个条件，决定扩展是否会被使用， 扩展点定义了一个扩展用例一直在监视的条 件，一旦条件满足，扩展用例就将自己加入 到执行用例中。比如基用例向系统报告一个 错误，该错误这是某个扩展用例监视的条件， 在收到这个条件后，扩展用例就插入执行， 对错误进行处理，执行完毕后，基用例被允 许从中断的地方继续执行。
用例图
用例图是基于用例的方法的一部分，基 于用例的方法还包括对用例的文本描述 和用例脚本。文本描述用来强调用例的 需求细节，脚本则用来说明用例执行中 的选项、测试需求以及为后续的开发提 供较高层次的测试计划。
参与者（1）
参与者是某种类型的用户，用户指使用系 统的人，或者是其他的的系统、设备。 参与者的图形表示见教材P24页图3.4所示。
用例和用例图
教学目的
熟悉用例的概念，掌握用例图的作用； 掌握用例之间的关系； 学会使用用例对软件系统需求建模； 掌握用例描述； 掌握Rose下用例建模。
用例建模概述
用例图从用户的角度来描述系统功能，并 指出各功能的操作者，其基本组成成份是系 统、参与者和用例。 用例从外部用户的角度来描述系统应该实现 什么样的功能。 参与者是与系统进行交互的外部实体，系统 是实现各种用例的“黑盒”。
establish credit
监督员
用例图
用例图包含三个元素，它们是：参与者、用例、关 系。 参与者：参与系统成功操作的某些人、系统、设 备甚是是企业所扮演的角色。 用例：标志系统的某个关键行为。每个用例都表 达了系统必须达到的目标或必须产生的结果。 关系：标志参与者和用例之间的交互称为关联。 每个关联成为在用例描述中加以解释的对话，而每 个用例描述又提供了一组脚本，它们有助于开发测 试用例。用例之间有包含、扩展和泛化关系。