用例和用例图
合集下载
UML用例和用例图
![UML用例和用例图](https://img.taocdn.com/s3/m/ac9c70c04b35eefdc9d33336.png)
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、系统通过库存系统验证要购买的商品是否有足
用例及用例图案例
![用例及用例图案例](https://img.taocdn.com/s3/m/e9c6224ca6c30c2258019e22.png)
第3章
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统(或工作内容) – 帮助业务过程重建工程工作 – 帮助员工(小组内成员)充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例:客房预订 ●参与者:柜台工作人员 ●说明:
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例:预订变更 ●参与者:柜台工作人员 ●说明:
A2:有冲突。
⑧系统添加新课程,并提示添加成功。
⑨系统回到管理主界面,显示所有课程,用例结束。
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) 什么叫事件流,作用是什么?
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统(或工作内容) – 帮助业务过程重建工程工作 – 帮助员工(小组内成员)充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例:客房预订 ●参与者:柜台工作人员 ●说明:
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例:预订变更 ●参与者:柜台工作人员 ●说明:
A2:有冲突。
⑧系统添加新课程,并提示添加成功。
⑨系统回到管理主界面,显示所有课程,用例结束。
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) 什么叫事件流,作用是什么?
用例和用例图
![用例和用例图](https://img.taocdn.com/s3/m/c97d66ae0029bd64783e2cbe.png)
用例
用例(use case)是Ivar Jacobson发明的. 其它的中 文译名有: 用况、用案等. 定义1: 用例是对一个活动者(actor)使用系统的一项 功能时所进行的交互过程的一个文字描述序列. 定义2: 用例是系统、子系统或类和外部参与者交互 的动作序列的说明, 包括可选的动作序列和会出现 异常的动作序列. 用例是代表系统中各个项目相关人员之间就系统的 行为所达成的契约, 软件开发过程是用例驱动的.
实例1:图书馆管理系统中的用例图
1.确定系统涉及的总体信息 图书馆管理系统是对书籍的借阅及读者信息进行统 一管理的系统,具体包括读者的借书、还书,书籍 预订;图书馆管理员的书籍借出处理、书籍归还处 理、预订信息处理;还有系统管理员的系统维护, 包括增加书目、删除或更新书目、增加书籍、减少 书籍、增加读者账户信息、删除或更新读者账户信 息、书籍信息查询、读者信息查询等。
用例图的作用
用例图展示了用例之间以及用例与参与者之间是怎样相互联 系的。用例图对系统、子系统或类的行为进行了可视化,使 用户能够理解如何使用这些元素,并使开发者能够实现这些 元素。 用例图主要用来描述用户的功能需求。UML侧重从最终用户 的角度来理解软件系统的需求,强调谁在使用系统、系统可 以完成哪些功能。用例分析技术已经是一种公认有效的用户 需求获取、分析和描述技术
情况二:假如机票购买者通过呼叫中心,由人工座席 操作订票系统购买机票,那么谁是参与者?
情况三:如果机票购买者通过呼叫中心的自动语音预 定机票而不是通过人工座席,那么谁是参与者?
情况四:如果扩大系统边界,让呼叫中心成为机票预 定系统的一个子系统,并且假设机票购买者将可以 自主选择是通过人工座席还是自动语音登录网站预 订机票,那么谁是参与者?
用例和用例图
![用例和用例图](https://img.taocdn.com/s3/m/70675ef2cc1755270622088a.png)
第一页,编辑于星期二:十三点 五十六分。
第二页,编辑于星期二:十三点 五十六分。
第三页,编辑于星期二:十三点 五十六分。
第四页,编辑于星期二:十三点 五十六分。
第五页,编辑于星期二:十三点 五十六分。
第六页,编辑于星期二:十三点 五十六分。
第七页,编辑于星期二:十三点 五十六分。
第八页,编辑于星期二:十三点 五十六分。
第二十三页,编辑于星期二:十三点 五十六分。
第二十四页,编辑于星期二:十三点 五十六分。
第二十五页,编辑于星期二:十三点 五十六分。
第二十六页,编辑于星期二:十三点 五十六分。
第二十七页,编辑于星期二:十三点 五十六分。
第二十八页,编辑于星期二:十三点 五十六分。
第二十九页,编辑于星期二:十三点 五十六分。
第十六页,编辑于星期二:十三点 五十六分。
第十七页,编辑于星期二:十三点 五十六分。
第十八页,编辑于星期二:十三点 五十六分。
第十九页,编辑于星期二:十三点 五十六分。
第二十页,编辑于星期二:十三点 五十六分。
第二十一页,编辑于星期二:十三点 五十六分。
第二十二页,编辑于星期二:十三点 五十六分。
第三十页,编辑于星期二:十三点 五十六分。
第三十一页,编辑于星期二:十三点 五十六分。
第三十二页,编辑于星期二:十三点 五十六分。
第三十三页,编辑点 五十六分。
第九页,编辑于星期二:十三点 五十六分。
第十页,编辑于星期二:十三点 五十六分。
第十一页,编辑于星期二:十三点 五十六分。
第十二页,编辑于星期二:十三点 五十六分。
第十三页,编辑于星期二:十三点 五十六分。
第十四页,编辑于星期二:十三点 五十六分。
第二页,编辑于星期二:十三点 五十六分。
第三页,编辑于星期二:十三点 五十六分。
第四页,编辑于星期二:十三点 五十六分。
第五页,编辑于星期二:十三点 五十六分。
第六页,编辑于星期二:十三点 五十六分。
第七页,编辑于星期二:十三点 五十六分。
第八页,编辑于星期二:十三点 五十六分。
第二十三页,编辑于星期二:十三点 五十六分。
第二十四页,编辑于星期二:十三点 五十六分。
第二十五页,编辑于星期二:十三点 五十六分。
第二十六页,编辑于星期二:十三点 五十六分。
第二十七页,编辑于星期二:十三点 五十六分。
第二十八页,编辑于星期二:十三点 五十六分。
第二十九页,编辑于星期二:十三点 五十六分。
第十六页,编辑于星期二:十三点 五十六分。
第十七页,编辑于星期二:十三点 五十六分。
第十八页,编辑于星期二:十三点 五十六分。
第十九页,编辑于星期二:十三点 五十六分。
第二十页,编辑于星期二:十三点 五十六分。
第二十一页,编辑于星期二:十三点 五十六分。
第二十二页,编辑于星期二:十三点 五十六分。
第三十页,编辑于星期二:十三点 五十六分。
第三十一页,编辑于星期二:十三点 五十六分。
第三十二页,编辑于星期二:十三点 五十六分。
第三十三页,编辑点 五十六分。
第九页,编辑于星期二:十三点 五十六分。
第十页,编辑于星期二:十三点 五十六分。
第十一页,编辑于星期二:十三点 五十六分。
第十二页,编辑于星期二:十三点 五十六分。
第十三页,编辑于星期二:十三点 五十六分。
第十四页,编辑于星期二:十三点 五十六分。
第05讲用例分析与用例图
![第05讲用例分析与用例图](https://img.taocdn.com/s3/m/6c2fcc1fcfc789eb172dc860.png)
基于用例的需求分析过程
获取原始需求
开发一个可以理解的需求
识别参与者
识别用例
确定关系
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
用例和用例图统一建模语言
![用例和用例图统一建模语言](https://img.taocdn.com/s3/m/d775694653d380eb6294dd88d0d233d4b14e3f22.png)
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.建立超市进销存系统的用例图模型
在系统需求分析中需考虑:系统用例图模型需要哪些视 图,每个视图包含什么内容?视图中成员是否需构成包?
用例和用例图
![用例和用例图](https://img.taocdn.com/s3/m/162c175ce518964bcf847cda.png)
访客用例图
会员用例图
书店管理员用例图
3、用例描述 (1)细化用例描述----搭框架
用例名称:搜索图书 概述:用户根据关键字搜索图书 前置条件:无 事件流: 基本事件流 扩展事件流 后置条件: 无
3、用例描述 (2)细化用例描述----填"血肉"
事件流: •基本事件流 1 用户点击“搜索图书”,用例开始。 2 系统显示搜索图书商品界面,提示用户输入商品关键字。 3 用户输入图书关键字,选择提交。 4 系统访问数据库,根据关键字查询相关的图书商品信息, 并把查询出的图书信息显示搜索图书页面。 5 用例结束。 •扩展事件流 4a) 系统未查出所要商品相关信息,显示提示信息,用例 结束。 4b) 系统查出用户输入的关键字为空,显示提示信息并返 回基本事件流2。
编写用例描述应遵循以下几点:
使用简单的语法,主语明确,语义易于理解;在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制; 从第三者观察的角度指出参与者的动作,以及系统的响应; 显示参与者的意图而非动作 显示过程向前推移,每一步都有前进感;
构建结构良好的用例
为系统和部分系统中单个的、可标识的、合理的原子行为 命名。 将多个用例的公共的行为抽取出来放到一个被包含用例中。 对于变化部分,将其抽取出来,放到扩展用例中。 清晰的描述事件流。
扩展关系(Extend)
扩展关系表示基本用例在由扩展用例间接说明的一个位置 上隐式的合并了另一个用例(扩展用例)的行为。 基本用例不知道扩展用例的任何细节,没有扩展用例,基 本用例是完整的。只有在特定条件下,它的行为可以被扩 展用例的行为扩展,因此扩展关系处理事件流的异常或者 可选事件。
软件工程课件之第4章用例和用例图
![软件工程课件之第4章用例和用例图](https://img.taocdn.com/s3/m/02e1ce2453ea551810a6f524ccbff121dc36c57b.png)
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】在需求分析中常见的权限控制问题,一般的 用户只可以使用一些常规的操作,如查询等,而管理员 除了常规操作之外还需要进行一些系统管理工作,如一 些关键数据的增加、删除、修改等,操作员既可以进行 常规操作又可以进行一些配置操作。
第5讲2-用例及用例图
![第5讲2-用例及用例图](https://img.taocdn.com/s3/m/15f4b11f326c1eb91a37f111f18583d049640fb5.png)
取款 用例旳动态事件流
a 经过读卡机,储户插入ATM卡
b ATM系统从卡上读取银行ID、帐号、并验证帐号。 c 储户键入密码,系统检验密码。 d 储户按确认键,输入取款金额。 e ATM把帐号和取款金额传递给银行系统,取回帐户余额。 f ATM输出现金,并显示帐户余额。 d ATM统计事务到日志文件。
参加者
1. 参加者旳概念 参加者(actor)是外部需要与系统交互旳事物。
也被称为活动者。 2.参加者旳三种类型
①. 人:客户,读者,库管员 ②. 设备:计算机,磁盘,读卡机等 ③. 外部系统:上层系统等
参加者旳表达
参加者能够表达为下面三种形式。
参加者之间旳关系
参加者之间能够有泛化关系。
用例之间旳关系(1)
用例之间能够具有下列几种关系:
➢ 泛化关系 ➢ 包括关系 ➢ 扩展关系
参加者与用例之间旳关系
关联关系 参加者与用例之间是关联关系,表达参加者与用
例之间具有使用,交互信息旳关联。
用例之间旳关系(3)
泛化关系 参加者与参加者之间,用例与用例之间存在一般与 特殊旳关系。
用例之间旳关系(4)
包括关系 两个用例之间,一种用例(基本用例)旳行为包括了 另外一种用例(包括用例)旳行为。 包括关系用依赖关系旳<<include>>构造型来表 达。
某学校网上选课系统旳用例分析(1)
管理员经过系统管理界面进入系统,建立本学期 要开设旳多种课程,将课程信息保存到数据库中, 并能够对课程进行改动和删除。 学生经过客户机浏览器进入系统,选择课程:能够 查询课程,选择课程,支付课程费用。
某学校网上选课系统旳用例分析(2)
●找出系统外部参加者,拟定系统边界和范围。
a 经过读卡机,储户插入ATM卡
b ATM系统从卡上读取银行ID、帐号、并验证帐号。 c 储户键入密码,系统检验密码。 d 储户按确认键,输入取款金额。 e ATM把帐号和取款金额传递给银行系统,取回帐户余额。 f ATM输出现金,并显示帐户余额。 d ATM统计事务到日志文件。
参加者
1. 参加者旳概念 参加者(actor)是外部需要与系统交互旳事物。
也被称为活动者。 2.参加者旳三种类型
①. 人:客户,读者,库管员 ②. 设备:计算机,磁盘,读卡机等 ③. 外部系统:上层系统等
参加者旳表达
参加者能够表达为下面三种形式。
参加者之间旳关系
参加者之间能够有泛化关系。
用例之间旳关系(1)
用例之间能够具有下列几种关系:
➢ 泛化关系 ➢ 包括关系 ➢ 扩展关系
参加者与用例之间旳关系
关联关系 参加者与用例之间是关联关系,表达参加者与用
例之间具有使用,交互信息旳关联。
用例之间旳关系(3)
泛化关系 参加者与参加者之间,用例与用例之间存在一般与 特殊旳关系。
用例之间旳关系(4)
包括关系 两个用例之间,一种用例(基本用例)旳行为包括了 另外一种用例(包括用例)旳行为。 包括关系用依赖关系旳<<include>>构造型来表 达。
某学校网上选课系统旳用例分析(1)
管理员经过系统管理界面进入系统,建立本学期 要开设旳多种课程,将课程信息保存到数据库中, 并能够对课程进行改动和删除。 学生经过客户机浏览器进入系统,选择课程:能够 查询课程,选择课程,支付课程费用。
某学校网上选课系统旳用例分析(2)
●找出系统外部参加者,拟定系统边界和范围。
用例图
![用例图](https://img.taocdn.com/s3/m/e11bf240336c1eb91a375d6f.png)
存款
4
3.1.1 用例
怎样确定用例的粒度?
用例的粒度(用例的大小)可大可小,一般一个系 统宜控制在20个用例左右。 用例是系统级的、抽象的描述,不是细化的(是做 什么,非怎样做) 对复杂的系统可以划分为若干子系统处理。
学籍 处理
退学处分
3.1.1 用例
怎样获取用例?
参与者希望系统执行什么任务? 参与者在系统中访问哪些信息(创建、存储、修 改、删除等)? 需要将外界的哪些信息提供给系统? 需要将系统的哪个事件告诉参与者? 如何维护系统?
3.1.3 关系
包含include
一个用例过于复杂,可以分解成小用例,构成包含 依赖(三个被包含的用例合起来实现完整的事件 流,不能单独调用);
3.1.3 关系
扩展extend
一个用例(在某些扩展点上)扩展另一个用例的功 能 ,构成新用例; 扩展用例依赖于被扩展依赖(基本用例),只是部 分片断组成,不是完整的独立用例,无法单独执 行;
用例图
本章内容
组成 用例图 用例描述 用例分析 业务用例图 实例
2
3.1 组成
用例(Use Case) 参与者(角色,Actor) 关系(Relationship)
3
3.1.1 用例
Use Case:
系统、子系统或类与外部的参与者(actor)交互的 动作序列的说明,包括各种序列及出错序列。 用例分析可以认为是对系统功能的分解。
3.4 用例分析
识别参与者
已有的上下文关系图(表示系统范围)及其他相关模型:它 们描述了系统与外部系统的边界,从这些图中可以寻找出与 系统有交互关系的外部实体。 项目相关人员分析:对项目的相关人员进行分析,就能够决 定出哪些人将会与系统进行交互。 书面的规格说明和其它项目文档(如会谈备忘录等) 需求研讨会和联合应用开发会议的记录:这些会议的参与者 通常是很重要的,因为他们在组织中所代表的角色就是可能 与系统发生交互的参与者。 当前过程和系统的培训指南及用户手册:这些东西中经常会 有潜在参与者。
第03章 用例和用例图
![第03章 用例和用例图](https://img.taocdn.com/s3/m/e914b7c24028915f804dc22b.png)
前置条件
后置条件
一个条件列表, 这些条件必须在访问用例前得到满足
一个条件列表, 这些条件必须在用例完成之后得到满足
基本操作流程 描述用例中各项工作都顺利进行时用例的工作方式
可选操作流程 描述变异工作方式、出现异常或发生错误的情况下的路径
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 一中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况. 其它译名: 情景、场景、情节、剧本. 每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
例:在“订货”用例中包括几个相关脚本: • 订货顺利进行的脚本; • 相关货源不足时的脚本; • 购货者的信用卡被拒绝时的脚本; • ……
用例和用例图
![用例和用例图](https://img.taocdn.com/s3/m/eebebbb769dc5022aaea004e.png)
如何绘制用例图 1、用例分析技术步骤(不固定,可根据需要调整):
⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ 找出系统外部的参与者和外部系统,确定系统的边界和范围。 确定每一个参与者所期望的系统行为 把这些系统行为命名为用例 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分 编制每一个用例的脚本 绘制用例图 区分基本事件流和异常情况的事件流,如有需要可以把表示异常 情况的事件流作为单独的用例来处理 ⑻ 细化用例图,解决用例间的重复与冲突。
用例之间的关系 4、参与者与用例之间的关系:关联关系Association
关联关系描述参与者与用例之间的关系,在UML中它是 两个或多个类元之间的关系,它描述了类元的实例间的 联系。(类元,一种建模元素,常见类元包括类、参与者 、构件、数据类型、接口、结点、子系统以及用例等, 其中类是最常见的类元) 关联关系表示参与者和用例之间的通信。在UML中,关 联关系用直线或箭头表示。如果参与者启动了用例,箭 头指向用例;如果参与者利用了用例提供的服务,箭头指 向参与者。如果二者是互动的,则是直线。 例:汽车租赁系统用例图(部分)。显示的是“客户”参与者以 及与他交互的3个用例,“预定”、“取车”、“还车” 。
FEAT01.新增书籍信息 FEAT03.书籍信息按计算机类、非计算机类分别建档 FEAT04.录入新书时能够自动按规则生成书号 FEAT05.计算机类与非计算机类书籍采用不同的书号规则 FEAT06.录入新书时如果重名将自动提示 FEAT02.修改已有的书籍信息 FEAT07.按书名、作者、类别、出版社等关键字组合查询书籍 FEAT08.列出所有书籍信息 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 FEAT09.记录外借情况 FEAT10.外借状态能够自动反应在书籍信息中 FEAT11.按人、按书查询外借情况 FEAT12.列出所有的外借情况 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 FEAT13.按特定时间段统计购买金额、册数 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行
用例和用例图
![用例和用例图](https://img.taocdn.com/s3/m/0a0e3406a300a6c30c229f85.png)
扩展关系
扩展点是一个条件,决定扩展是否会被使用, 扩展点定义了一个扩展用例一直在监视的条 件,一旦条件满足,扩展用例就将自己加入 到执行用例中。比如基用例向系统报告一个 错误,该错误这是某个扩展用例监视的条件, 在收到这个条件后,扩展用例就插入执行, 对错误进行处理,执行完毕后,基用例被允 许从中断的地方继续执行。
用例图
用例图是基于用例的方法的一部分,基 于用例的方法还包括对用例的文本描述 和用例脚本。文本描述用来强调用例的 需求细节,脚本则用来说明用例执行中 的选项、测试需求以及为后续的开发提 供较高层次的测试计划。
参与者(1)
参与者是某种类型的用户,用户指使用系 统的人,或者是其他的的系统、设备。 参与者的图形表示见教材P24页图3.4所示。
用例和用例图
教学目的
熟悉用例的概念,掌握用例图的作用; 掌握用例之间的关系; 学会使用用例对软件系统需求建模; 掌握用例描述; 掌握Rose下用例建模。
用例建模概述
用例图从用户的角度来描述系统功能,并 指出各功能的操作者,其基本组成成份是系 统、参与者和用例。 用例从外部用户的角度来描述系统应该实现 什么样的功能。 参与者是与系统进行交互的外部实体,系统 是实现各种用例的“黑盒”。
establish credit
监督员
用例图
用例图包含三个元素,它们是:参与者、用例、关 系。 参与者:参与系统成功操作的某些人、系统、设 备甚是是企业所扮演的角色。 用例:标志系统的某个关键行为。每个用例都表 达了系统必须达到的目标或必须产生的结果。 关系:标志参与者和用例之间的交互称为关联。 每个关联成为在用例描述中加以解释的对话,而每 个用例描述又提供了一组脚本,它们有助于开发测 试用例。用例之间有包含、扩展和泛化关系。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
录单员
录入保单
ATM用户
取款
录单员已经登录
ATM用户已登录
注意:必须是系统在用例开始前能检测到的
2020/5/8
17
2020/5/8
2 常见问题分析
Use case: Withdraw cash Actor: customer 主事件流: (1)储户插入ATM卡,并输入密码 (2)储户按“取款”按钮,并输
2 常见问题分析
购物查询用例 • 会员从下拉框中选择要查询的商品类
别后,又在在相应文本框中输入查询 条件,然后点击“确定”按钮 • 系统以列表的显示查询结果
不要涉及界面细节
2020/5/8
例子---ATM取款用例描述
❖ 用例编号:001 ❖ 用例名:ATM取款 ❖ 用例描述:储户使用信用卡在ATM机上取款 ❖ 参与者角色:储户 ❖ 前置条件:ATM机器处于正常准备状态 ❖ 后置条件:若成功,则储户取出钱,帐户上扣除钱;若失败,储户没有取 到钱,帐户上钱数不变。
2020/5/8
12
方案一:
由于选课和查看学分都需要登录,故专门设立一个 “登录”用例。若登录成功,则可以进行选课,也可 以进行查看学分。
研究生
<<include>>
选课
登录 <<include>> 查看学分
2020/5/8
13
方案二:
让所有的相关用例都包含登录用例。
研究生
选课
<<include>>
<<include>> 登录
查看学分
这个方法中的“登录”用例仅描述有 关登录的信息,研究生执行系统的每 项功能都要先登录。 其缺点为,对研究生要进行多次验证。
2020/5/8
14
方案三:
使用扩展,设计系统登录。
<<extend>> 选课
研究生
登录 <<extend>> 查看学分
该方法与方法一相比,对“登录”用例 的描述要清楚一些。在增加新用例 时,仅在登录用例中添加扩展点即可
设定查询条件
选择零件
医生
诊断 开处方
• 价值结果由系统生成
5
2 常见问题分析
• 用户的观点而非系统的观点 • 不要把步骤当用例
处理订票
用户
输入密码
旅行者
显示今日航班
<<include>> 验密码
用户
取款 <<include>>
扣除帐号金额
2020/5/8
6
2 常见问题分析
• 用例的粒度—— CRUD泛滥
❖ 基本路径 1, 储户插卡; 2. ATM机提示输入用户口令; 3.储户输入口令; 4.ATM机口令验证通过,提示用户选择功能 5.储户选择取款;
2020/5/8
6. ATM提示储户输入钱数;
7.储户输入钱数;
8.ATM机进行钱数有效性检查,提示操作成功,吐
出钱和卡;
9.储户取走钱和卡;
10.ATM机屏幕恢复为初始状态。
入取款数目 (3)储户取走现金/ATM卡/收据 (4)储户离开
只描述了actor的行为
2 常见问题分析
Use case: Withdraw cash Actor: customer 主事件流: • ATM系统获得ATM卡和密码,在SQL中查询到匹配
的信息后,显示主界面 • 如果信息不匹配,系统提示错误 • 储户按“取款”按钮,并输入取款数目 • 设置交易类型为“取款” • ATM系统获得取款金额 • 输出现金、收据和ATM卡 • 现金/ATM卡/收据被储户取走 2020/5/8 • 系统复位
➢甚至很多种基本数据的管 理都可以用一个用例表示
管理员 管理员
管理用户 配置参数
2020/5/8
8
2 常见问题分析
• 用例的粒度—— 1个业务用例,多个系统用例
患者
<<include>>
看病
<<include>>
< < i n c l u d e > >< < i n c l u d e > >
挂号
分诊
开处方
收费
2020/5/8
9
2 常见问题分析
2020/5/8
10
请举例说明包含、泛化、扩展的区别
• 扩展:分离扩展路径 • 包含:提取公共步骤,便于复用 • 泛化:同一业务目的的不同技术实现
2020/5/8
11
2 常见问题分析
很多软件系统在一开始都需要登录,若用户 登录成功,则可进入系统。 如下以一个研究生学籍管理系统为例,描述 四种登录方法。 为了简化起见,假设此处仅描述登录、选课 和查看学分这3项功能。
3
1、用例模型
• 用例模型的目的是各方达成共识,明确系统 的基本功能,为后阶段的工作打下基础。
–确定系统应具备哪些功能; –为系统的功能提供清晰一致的描用例图和用例规约两部分组成
2020/5/8
2 常见问题分析
• 用例是有意义的目标
会员
2020/5/8
主要内容
上讲回顾 1 用例模型 2 常见问题分析 3 补充规约 4 讨论---课程注册系统示例 5 小结
2020/5/8
1
上讲回顾
✓UML的全称? ✓你对UML的理解? ✓UML由什么构成? ✓UML基本构造块中的关系有哪几种? ✓UML的图有哪几种?
2020/5/8
2
1、用例模型
2020/5/8
❖ 扩展路径
4a. ATM机验证用户口令不通过
4a1. ATM机给出提示信息,并吐出信用卡;
4a2. 储户取出卡;
4a3. ATM机屏幕恢复为初始状态.
8a. ATM验证用户输入钱数超过3000
8a1. ATM机给出提示信息,并吐出信用卡;
8a2. 储户取出卡;
2020/5/8
8a3. ATM机屏幕恢复为初始状态. 。。。。
用例编号:用例名
执行者
前置条件
后置条件
用例文档
涉众利益 基本路径
+ 补充约束 =
修改用户 删除用户
管理员
增加用户 查询用户
用有色眼镜看, 所有业务最终 都会成为CRUD 多问:为什么 要CRUD?光 CRUD能为执行 者提供价值吗?
2020/5/8
7
2 常见问题分析
• 用例的粒度—— CRUD泛滥
➢如果CRUD不涉及复杂的交 互,一个用例“管理××” 即可
➢不管是C、R、U、D,都是 为了完成“管理”的目标
2020/5/8
15
方案四:
登录用例完全独立于其它用例。
选课
研究生
登录
查看学分
若使用该方法,必须要在“选课”用例和“查 看学分”用例中指定前置条件:只有在登录成 功后才能执行自己。
2020/5/8
16
2 常见问题分析
业务代表已把保单交给录单员 ATM用户的账户里有足够的金额 ATM机器处于正常准备状态