第3章 用例图

合集下载

第3章 用例图及其应用

第3章  用例图及其应用

1 基本概念
1.2 用例
– 定义
对一组动作序列的描述,系统通过执行这一组动作序 列为参与者产生一个可观察的结果
– 用例特征
说明了系统具有的一种行为模式 说明了一个参与者与系统执行的一个相关的事务序列 提供了一种获取系统需求的方法 提供了一种与最终的用户和领域专家进行沟通的方法 提供了一种测试系统的方法
– General标签
Name Stereotype Documentation
3 参与者规范及应用
3.1 参与者规范
– Detail标签
Multiplicity (参与者基数)
基数 0..0 0..1 0..n 1..1 1..n n 含义 0 0或者1 0或者多 1 1或者多 许多
Abstract(抽象参与者)
3 参与者规范及应用
3.1 参与者规范
– Rose在实现中对参与者和类使用相同的规 范窗口,包括如下一些标签:
General Detail Operations Attributes Relations Components Nested Files
3 参与者规范及应用
3.1 参与者规范
2 关系及其应用
2.1 关联关系
– 表示
工具箱中:一个直角直线 模型图中:一条直线或者 一条带箭头的直线
– 关联命名
一个动词或者一个动词短 语,用于指明关系的类型 或者目的. 关联关系表示通信途径

第3章用例及用例图-案例学习资料

第3章用例及用例图-案例学习资料

A2:有冲突。
⑧系统添加新课程,并提示添加成功。
⑨系统回到管理主界面,显示所有课程,用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图,解决用例之间的冲突和重复。
15
案例3:
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的 功能。
5
案例1: • 用例图
6
案例1: • 优化
7
案例2:
某学校网上选课系统的用例分析
管理员通过系统管理界面进入系统,建立本学 期要开设的各种课程,将课程信息保存到系统中, 并可以对课程进行改动和删除。 学生通过客户机浏览器进入系统,选择课程:可 以查询课程,选择课程,支付课程费用。
8
● ① 找出系统外部参与者,确定系统边界和范围。
① 工作人员启动预订功能。 ② 输入预订人标志信息。 ③ 系统显示该预订人的客房预订信息。 ④ 预订变更。 ⑤ 预订变更成功。
23
● ⑥ 编制用例说明。
● 用例:入住登记 ●参与者:柜台工作人员 ●说明:
① 工作人员启动入住登记功能。 ② 根据旅客要求查询客房空闲信息。 ③ 如果不满足旅客入住要求,则退出。 ④ 接收旅客信息。 ⑤ 给旅客分配房间床位。 ⑥ 接收押金。 ⑦ 打印入住单 ⑧ 入住登记结束。
20

第3章用例及用例图案例PPT课件

第3章用例及用例图案例PPT课件
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统(或工作内容) – 帮助业务过程重建工程工作 – 帮助员工(小组内成员)充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
1
3.7 业务用例图
• 业务角色(Business Actor)
– 机构的主要产品等实体
• 物理工人(Phsical Worker)
– 机构内部人类参与者
2
3.7 业务用例图
3
3.8 实例
• 案例1:
– 有一个爱书之人,家里各类书籍已过千册,平时又 时常有朋友外借,因此需要一个图书管理系统。该 系统应该能够将书籍的基本信息按计算机类、非计 算机类分别建档,实现按书名、作者、类别、出版 社等关键字的组合查询功能。在使用系统录入新书 籍时系统会自动按规则生成书号,以修改信息,但 不能够删除记录。该系统还应该能够对书籍的外借 情况进行记录,可对外借情况列出打印。另外,还 希望能够对书籍的购买金额、册数按特定时限进行 统计。
23
● ⑥ 编制用例说明。
● 用例:退房结帐 ●参与者:柜台工作人员 ●说明:
① 工作人员启动退房结帐功能。 ② 输入旅客标志信息。 ③ 系统显示旅客入住信息。 ④ 显示入住天数,费用。 ⑤ 接收费用。 ⑥ 打印发票。 ⑦ 入住登记结束。

第三章 用例和用例图

第三章  用例和用例图

《Actor》 Actor1 Actor1
Actor 1
Icon形式 Label形式 Decoration形式
2014-7-16
饮料贩卖机中的参与者
在饮料自动贩卖机中,除了买饮料的顾客, 还有以下的参与者。 供应商向自动贩卖机添加饮料。 收银员从自动贩卖机收钱。
2014-7-16
每一 种参 与者 Customer 具有 自己 Supplier 的 use case Collector
2014-7-16
<<include>>
Identify Customer
ATM Session
<<include>> Validate Account
2014-7-16

扩展关系(extend)的基本含义与泛化关系 类似,但在扩展关系中,对扩展用例有更多 的规则限制,即基本用例必须声明若干“扩 展点”,而扩展用例只能在这些扩展点上增 加新的行为和含义
主事件流是正常情形,是用例中的最常用路径
其他事件流
从主事件流中分支出来的非常用路径
2014-7-16

用例描述易犯错误
只描述系统的行为,没有描述参与者的行为 只描述参与者的行为,没有描述系统的行为 在用例描述中就设定对用户界面的设计的要求
描述过于冗长
2014-7-16

2012-2013 第二学期 11本 UML 第三章 用例和用例图

2012-2013 第二学期 11本 UML 第三章 用例和用例图

基本用例
扩展用例1
扩展用例2
19
§3.4.3 扩展关系(续)

一个用例相对于包含和扩展关系来讲是变换的。 例如:网上买东西
对应于包含关系来讲是基本用例 对应于扩展关系来讲是扩展用例
Customer
Buy Merchandise
<<extend >>
<<include>>
Browse Web Site

12
§3.4 用例间关系
针对用例的描述要遵循的几个要点: 清楚地确定系统的边界。 用标准模板书写用例说明。 关注用例的真正目的。 不能将用例说明与用户接口设计相混淆。 实现使用例交互与用户接口之间的松散耦合。 不要在用例与用户接口之间建立通信。
13
§3.4 用例间关系(续)

用例之间关系有以下几种: 关系 所表示的功能 关联 参与者与用例之间通信 扩展 在基础用例上插入扩展部分 泛化 表示用例间的一般和特殊关系
由以上例子看出: 其用例描述并无一个固定的模式可循,各自有理解和侧重, 关键是要多加练习。
25
§3.7 寻找用例的方法

用例分析可遵循的步骤:
1、找出系统外部的参与者和外部系统,确定系统的边界; 2、确定每一个参与者所期望的系统行为; 3、命名这些系统行为为用例; 4、使用泛化\包含\扩展关系处理系统行为的公共或变更部分; 5、编制每一个用例的脚本; 6、绘制用例图; 7、区分主事件流和异常事件流,单独处理异常事件流用例; 8、细化用例图,去掉重复与冲突;

uml 基础教程 第三章-用例图

uml 基础教程 第三章-用例图

例:
飞机订票系统中,预订飞机票有两种方式,一种是通过 电话预订,另一种是通过网上预订。
继承关系,子用例和父用例相似,但表现出更特别的行为; 子用例将继承父用例的所有结构、行为和关系。子用例可 以使用父用例的一段行为,也可以重载它。父用例通常是 抽象的。
【箭头指向】:指向父用例
2. 扩展(Hale Waihona Puke Baiduxtend)
前置条件和前面场景一样,后置条件是顾客得到一罐 饮料和找回零钱或者按原款归还钱。
• 另一种可能是机器的储备零钱一旦用光,就会在机器 上显示一条小子告诉用户需要投入适当的零钱。直到对这 台机器补充零钱为止,这条消息才会消失。
(2)其他用例
• 已经从用户的观点考察了饮料销售机。除了这些用户外, 当然还有其他人加入。供货人负责为销售机提供饮料,收 款人(可能与供货人是同一个人)负责定期收集销售机中 的钱。这说明至少需要建立两个用例:“供货”和“取 钱”,这些用例细节可以通过与供货人和收款人交谈来获 得。
• 用例图通常是供客户和开发组参考的一部分。每个用例中 的场景在文档中要描述下列内容: 发起用例的参与者 用例的假设条件 用例中的前置条件 场景中的步骤 场景完成后的后置条件 从用例中获益的参与者 要说明一个场景中的步骤,还可以使用UML活动图对 场景进行描述。
通过询问下列问题就可发现用例: ➢ 角色需要从系统中获得哪种功能?角色需要做什么? ➢ 角色需要读取、产生、删除、修改或存储系统中的某 种信息吗? ➢ 系统中发生的事件需要通知角色吗?或者角色需要通 知系统某件事吗?这些事件(功能)能干些什么? ➢ 如果用系统的新功能处理角色的日常工作是简单化, 还提高了工作效率? ➢ 系统当前的这种实线方法要解决的问题是什么?

第三章 用例图

第三章 用例图

UML
- 20 -
UML中用例用椭圆表示, 使用动宾结构或主谓结构命 名.
例: 字处理程序中, “置正文为黑 体”和”创建索引”都可以是用 例.
UML
- 21 -
使用用例进行需求分析的特点:
1. 用例从使用系统的角度描述系统中的信息. 2. 用例描述用户提出的一些可见需求, 对应一个具体的用户目标. 3. 用例是对系统行为的描述, 属于UML的动态建模部分.
UML
-6-
从图中可以看出,所有的用例都放置在系统边界内,表明它属于一个系 统。参与者则放在系统边界的外面,表明角色并不属于系统。但是角色负 责直接(或间接)驱动与之关联的用例的执行。
UML
-7-
参与者有三大类:系统用户、与所建造的系统交互的其它系统和 一些可以运行的进程。 第一类参与者是真实的人,即用户,命名这类参与者时,应 当按照业务命名; 第二类参与者是其它的系统,这类位于程序边界之外的系统 也是参与者。 第三类参与者是一些可以运行的进程,如时间。当经过一定 的时间触发系统中的某个事件时,时间就成了参与者。
关联
《include》
包含
用例之间 的关系 扩展
《extend》
参与者之 间的关系
泛化
发出箭头的事物“is a”箭头指向的事物。泛化关系 是一般和特殊关系,发出箭头的一方代表特殊的一方 ,箭头指向的一方代表一般一方。特殊一方继承了一 般方的特性并增加了新的特性。

chapter03用例与用例图

chapter03用例与用例图

参与者
注意事项 -一个Actor可以执行一个或多个用例。通过向系统输入或 请求系统输入某些事件来触发系统的执行。 -一个用例也可以由多个Actor使用。 -Actor参与者不是系统的一部分,是系统外部的一个实体。 -由参与用例时所担当的角色来表示。 参与者的三种表示方法

参与者
① ② ③
用例
① ②

用例的表示和命名方法 椭圆 简单名、路径名 动宾结构或者主谓结构
用例

用例的粒度:
当有外部的参与者与之交互才 是用例,无外部参与者交互不 是用例。
用例
用例例子: 一个银行业务系统

浏览账户余额 列出交易内容 划拨资金 支付账款 登录 退出系统
用例
用例的特点 -用例从使用系统的角度描述系统中的信息. -用例描述用户提出的一些可见需求, 对应一个具 体的用户目标. -用例是对系统行为的描述, 属于UML的动态建模 部分. • 静态图:类图、对象图、构件图、部署图 • 动态图:用例图、顺序图、协ຫໍສະໝຸດ Baidu图、状态图、活 动图 • 争议
在识别参与者需要注意的



参与者对于系统而言总是外部的; 参与者直接同系统交互; 参与者表示人和事物同系统发生交互时所扮演的角色, 而不是特定的人和特定的事物; 一个人或事物在与系统发生交互时,同时或不同时扮演 多种角色; 每个参与者需要一个具有业务意义的简短名称; 每个参与者必须有简短描述,它从业务角度描述参与者 是什么。 像类一样,参与者可以具有分栏,表示参与者属性和它 可能接收的事件;

第3章 信息系统分析与设计 用例及用例图

第3章 信息系统分析与设计 用例及用例图
参与者与用例之间可以具有以下关系: ①.启动用例 有些用例可以由参与者启动,例如:
第26页,共87页。
3.4 参与者与用例之间的关系
②.获取用例提供的服务
参与者通过用例获取系统提供的服务,大部分 参与者与用例属于这种关系,例如:
第27页,共87页。
3.4 参与者与用例之间的关系 ③.为用例提供服务
有些参与者需要向用例提供服务,例如:
第28页,共87页。
3.4 参与者与用例之间的关系
④.给系统提供信息
有些需要给系统提供必要的信息,例如:
第29页,共87页。
3.4 参与者与用例之间的关系
⑤.从系统获取信息
有些参与者需要从系统获取必要的信息,例如:
第30页,共87页。
3.5 用例之间的关系
用例之间可以具有以下几种关系:
3.8 发现用例
发现用例的一般方法:
④ 系统检验密码;
有错:退出ATM卡; ⑤储户按确认键,输入取款金额;
⑥ ATM把帐号和取款金额传递给银行系统,取回确认信息和帐户余 额;
ATM输出现金,并显示帐户余额; ATM记录事务到日志文件;
⑦ 储户取出ATM卡。
第47页,共87页。
3.8 发现用例
发现用例的一般方法:
● ① 找出系统外部参与者,确定系统边界和范围。
第50页,共87页。

第3章 用例图

第3章 用例图
客户:为达到业务目标而投资项目或购买产品 用户:直接或间接使用产品 需求分析员:负责获取和编写需求 开发人员:根据需求文档设计、实现、维护软件 测试人员:检测产品的分析、设计、实现与预计的一致 文档编制人员:负责编写用户手册、用户培训资料和帮助系统 法律人员:保证产品的合法性和知识产权 生产人员:制造包含该软件的产品 其他人员:市场策划、营销、技术支持以及其他辅助人员
第3章 用例图
学习目标
理解用例模型的基本概念 掌握识别参与者、用例的方法 掌握用例模型中各种关系的分析 掌握用例描述(用例规约/用例约束)的分析与 编写 了解UML中用例建模的注意事项
补充:需求分析
关于项目涉众
我们称参与软件项目或受软件项目影响的人为项目干系 人,或称为项目涉众,主要包括:
统最让你满意的方面和最让你不满意的方面? J:请问你期望新系统的外貌是什么样的,新系统在哪些设
备上运行?
获取用户需求—从与用户交流开始需求分析
实例:开发一个“抽奖程序”
问:“谁将会使用这个系统?”
答:抽奖活动的主持人(Director)在抽奖过程中、兑奖工作 人员(Dispense)在分发奖品时都需要使用这个系统。
3.1 参与者
从上面的问答得到系统中初步的类和对象:
GUI(图形用户界面):识别用户的命令,接收 用户的输入,显示程序的结果。

《软件工程》第3章用例图及其应用

《软件工程》第3章用例图及其应用

用例图的绘制步骤
绘制用例图的步骤包括:确定系统的边界和参与者、识别系统的用例、绘制参与者和用例的图标、 添加关系和标注信息、进行审查和验证。
用例图的应用场景
用例图在软件工程中有广泛的应用场景,例如需求分析、系统设计、测试规 划等。通过用例图,开发人员和利益相关者能够共同理解系统功能和用户需 求,从而有效地进行软件开发。
《软件工程》第3章用例 图及其应用
用例图作为软件工程中重要的建模工具,能够帮助我们更好地理解系统需求 和功能。本章介绍用例图的概念、基本元素、符号表示方法以及应用场景。
用例图的概念和作用
用例图是一种描述系统功能和用户行为的图形化工具。它帮助开发人员和利 益相关者理解系统的需求,并作为沟通和验证的工具。用例图能够直观地展 示系统功能,帮助识别系统的边界和行为。
用例图在软件工程中的重要性
用例图在软件工程中起到了至关重要的作用。它不仅帮助开发人员了解系统 需求和功能,还能够引导需求分析和测试的工作,并作为可视化的沟通工具, 促进不同角色之间的合作交流。
结论
用例图作为软件工程中常用的建模工具,具有直观、易理解的特点。通过用例图,我们能够更好 地理解和沟通系统需求,提高系统开发的质量和效率。
用例图的基本元素
用例图包含参与者、用例和关系三个基本元素。参与者代表系统的外部角色, 用例代表系统的功能或服务,而关系则表示参与者和用例之间Βιβλιοθήκη Baidu交互和依赖 关系。

第3章 用例图

第3章 用例图

练习1
(1)学生需要登录“远程网络教学系统” 后才能正常使用该系统所有功能。如果忘记 密码,可以通过“找回密码”功能找回密码。 登录后学生可以浏览课件、查找课件、下载 课件、观看教学视频,请画出学生参与者的 用例图。
练习1
练习1
(2)教师登录“远程网络教学系统”后可 以上传课件、上传教学视频课件、发布教学 心得、修改教学心得。如果忘记密码,可以 通过“找回密码”功能找回密码。请画出教 师参与者的用例图。
第3章 用例图
主要内容
概述 参与者 用例 习题案例
概述
用例图的含义
由参与者(Actor)、 用例(Use Case)以 与它们之间的关系构成 的用于描述系统功能的 视图称为用例图。
概述
用例图的作用
用例图是需求分析中的产物,主要作用是描述 参与者和用例之间的关系,帮助开发人员可视 化的了解系统的功能。借助于用例图,系统用 户、系统分析人员、系统设计人员、领域专家 能够以可视化的方式对问题进行探讨,减少了 大量交流上的障碍,便于对问题达成共识。
用户 时间
发邮件 收邮件 提醒新邮件
用例
用例规约
对于每一个用例,我们还需要有详细的描述信 息,以便让别人对于整个系统有一个更加详细 的了解,这些信息包含在用例规约之中。
(1)简要说明 (3)用例场景 (5)前置条件
(2)事件流 (4)特殊需求 (6)后置条件

《软件工程》第3章用例图及其应用

《软件工程》第3章用例图及其应用
用例图的更新可以及时地反映到自 动化测试脚本中,保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率,确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例,可以找出未被测 试到的功能和业务流程,从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率,降低 漏测的风险。
通过模拟不同的场景和情况,可以发现潜在的问题和风险,并提前制定相 应的应对策略。
场景分析和模拟还可以用于测试阶段,帮助测试团队设计更全面的测试用 例,提高测试的质量和效率。
需求变更管理策略
在软件开发过程中,需求变更是不可避免的。 用例图可以帮助开发团队制定有效的需求变更 管理策略。
通过及时更新用例图来反映需求变更的内容和 影响范围,可以确保开发团队对变更后的需求 有清晰的认识和理解。
同时,用例图还可以作为变更请求的参考依据 和评估标准,有助于开发团队与客户、用户等 其他利益相关者就变更内容进行沟通和协商。
04 用例图在系统设计阶段作 用
指导架构设计决策
01
用例图描述了系统的功能和行为,为架构师提供了设计系统 结构的基础。
02
通过分析用例图中的参与者和用例,架构师可以确定系统的 主要组件和它们之间的交互方式。
缺陷跟踪与回归测试策略
01
02

第三章用例图

第三章用例图
– 可观测:用例止于系统边界 – 结果值:用例是目标向导的 – 系统执行:结果值是由系统生成的 – 由参与者观测:业务语言,用户观点 – 一组用例实例:用例的粒度
22
可观测
描述交互,而不是内在的系统活动
23
用例是目标导向的
系统的存在是因为:参与者有一些需要使用它 来满足的目标。用例是用来描述系统的目标
方法2:每个use case 画一个交互图。
32
Create, Retrieve, Update, Delete 类型用例的处理:
– 采用CRUD四个用例还是一个用例? – 从用户需求的角度考虑而不是从数据 处理的角度考虑。
– 可以参照需求大纲
15
Alistair Cockburn提出的供参考用的需求大纲: Chapter 1. Purpose and scope – 1a. What is the overall scope and goal? – 1b. Stakeholders (who cares?) – 1c. What is in scope, what is out of scope Chapter 2. Terms used / Glossary Chapter 3. The use cases – 3a. The primary actors and their general goals – 3b. The business use cases (operations concepts) – 3c. The system use cases Chapter 4. The technology to be used – 4a. What technology requirements are there for this system? – 4b. What systems will this system interface with, with what requirements?

第03章 用例和用例图

第03章 用例和用例图

频率[可选]
参与者访问此用例的频率, 如: 每日一次/每月一次等
例:用例“处理订单”的描述
21 面向对象分析与设计 & UML
3.6 用例的描述
描述用例时易出现的错误:
只描述系统的行为, 没有描述参与者的行为
只描述参与者的行为, 没有描述系统的行为 在用例描述中就设定了对用户界面的设计的要求 描述过于冗长
2
面向对象分析与设计 & UML
3.1 用例
UML中用例用椭圆表示, 使用动宾结构或主谓结构命名.
例: 字处理程序中, “置正文为黑体” 和”创建索引”都可以是用例.
例: 在一个银行业务系统中可能 有如右的用例

ຫໍສະໝຸດ Baidu
浏览账户余额 列出交易内容 划拨资金 ……
3
面向对象分析与设计 & UML
31
面向对象分析与设计 & UML
实例分析:语音邮箱系统
3. 初步找到的用例 呼叫者:保留信息 邮箱主人:接收信息、更改问候语、更改密码 4. 进一步寻找用例
邮箱主人:登录邮箱 呼叫者、邮箱主人:拨打邮箱号码
5. 分析用例之间的关系
24 面向对象分析与设计 & UML
3.7 寻找用例的方法
用例分析的基本步骤:
① 找出系统外部的参与者和外部系统, 确定系统边界和范围 ② 确定每一个参与者所期望的系统行为 ③ 把这些系统行为命名为用例 ④ 使用泛化、包含、扩展等关系处理系统行为的公共或变 更部分 ⑤ 编制每一个用例的脚本 ⑥ 绘制用例图 ⑦ 区分主要事件流和异常事件流, 如果需要, 可以把异常事 件流处理为单独的用例 ⑧ 细化用例图, 解决用例间重复与冲突的问题.

第3章用例和用例图

第3章用例和用例图

用例图(use case diagram)是显示一组用例、参与者以及它们之间的关 系的图.
在UML中, 一个用例模型由若干个用例图描述.
31 面向对象分析与设计 & UML
例: 金融贸易系统的用例图
32
面向对象分析与设计 & UML
3.6 用例的描述
用例描述是指对一个用例的功能进行的文字描述, 是 参与者与系统交互动作序列的说明. 用例描述才是用例的主要部分, 是后续的 交互图分析和类图分析必不可少的部分. 用例采用自然语言描述参与者与系统的交互行为,要 易于理解. 其读者是开发人员、用户、项目经理、测 试人员等.
Icon形式
Label形式
Decoration形式
15
面向对象分析与设计 & UML
3.2 参与者
由于Actor实际上是一个类, 因此它们之间可以存在 一定的关系,如:
16
面向对象分析与设计 & UML
3.3 脚本
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况. 它是用例的实例。 其它译名: 情景、场景、情节、剧本. 每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
33
面向对象分析与设计 & UML
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

(2)参与者不一定是人,也可以是一个外部系统, 该系统与本系统相互作用。代表的是一种角色。 (3)在系统的实际运作中,多个不同的用户可能 只对应于一个参与者;同时一个实际用户也可 能对应系统的多个参与者。
例如: 在“房地产开发经营管理系统”中,
所有的购房者作为一个集合,在“房屋销售子 系统”中作为购房合同的签约方出现,多个个 体在系统中担任一个参与者;同时,某个独立 的购房者在“物业管理子系统”中又作为房屋 的业主出现,同一个人在系统中担任了两类参 与者。
2.标识符[可选]:用来唯一标识一个用例,如 “UC0001”,这样就可以在项目的其他元素中用 它来引用这个用例。 3.参与者[可选]:与此用例相关的参与者列表。在 没有用例图时,它有助于增加对该用例的理解。
4.状态[可选]:用来指示该用例的状态,通常可 包括进行中、等待审查、通过审查或未通过审查 等状态。 5.频率:记录参与者使用该用例的频率。
AddBook
Libraian::LoanBook
3.3.2 确定用例
1、确定用例策略
确定用例最好的方法是从分析系统的参与者开始,
对于已经确定的参与者,通过考虑每个参与者是如
何使用系统的,以及系统对事件的响应来识别用例。
使用这种策略进行具体分析的过程中,可能会发现
新的参与者,这对完善整个系统的建模有很大Βιβλιοθήκη Baidu帮 助作用。

以用例作为建立需求模型的基本单位,一个用例 只针对一项系统功能,详细的描述系统边界以外 的参与者使用这项功能时与系统进行交互的情况, 这可以比较确切地定义系统的功能需求。 用例的概念的提出弥补了以往各种面向对象分析 方法在需求定义方面的不足,因此很快就被广泛 采纳。 UML的面向对象系统开发过程中在需求分析阶段 的需求模型由用例建模完成,以用例为驱动,因 此又称为用例模型。
的参与者。
超类参与者
特殊化的参与者
特殊化的参与者
例:假设在图书管理系统中,管理员分为对系统进
行维护的系统管理员和完成借书、还书等日常操作 的图书管理员。在这里,管理员参与者描述了图书
管理员和系统管理员所扮演的一般角色。
管理员
图书管理员
系统管理员
3.3 用例(Use Case)
3.3.1 用例的概念
3、参与者的分类
(1)人参与者和外部系统参与者 (2)主参与者和副参与者 (3)主动参与者和被动参与者
人参与者和外部系统参与者。
人参与者是系统的各类用户,用户通过与系统进行交
互来操纵系统,完成各种工作。 外部系统参与者是位于系统外部的其他软件系统或硬
件设备。
例如:计算机网络系统的参与者可以包括操作员系 统管理员、数据库管理员以及普通用户等人参与者,另 外也可以有外部系统参与者,如网络打印机。
借阅图书用例的描述
用例名称 标识符 用例描述 参与者 状态 BorrowBook UC0001 图书管理员代理借阅者办理借阅手续 图书管理员 通过审查
前置条件
后置条件 假设 基本操作流程
图书管理员登录进入系统
如果这个用例成功,在系统中建立并存储借阅记录 图书管理员已经成功地登录到系统 1. 2. 3. 4. 5. 管理员输入借书证信息 系统验证借阅证的有效性 图书管理员输入图书信息 添加新的借阅记录 显示借书后的借阅信息
3.2.3 参与者之间的关系
参与者是类,类之间的关联也适用于参与者, 多个参与者之间的关系就是类与类之间的关系。在 用例图中,使用泛化关系来描述多个参与者之间的 公共行为。如果系统中存在几个参与者,他们既扮 演自身的角色,同时也扮演更具一般化的角色,那 么就用泛化关系来描述他们。
泛化关系:用一个三角箭头来表示,其中箭头所 指向的角色为超类参与者,箭头尾端的角色为特殊化
回执性。用例执行完毕,向参与者提供可识别
的返回值。
完整性。用例表示一个完整的功能,必须是一
个完整的描述。
3、用例的表示 在UML语言中,用例用一个椭圆来表示,并 且每个用例必须有一个名字。 在用例命名时用例的名字一般用字符串来表 示,可分为简单名和路径名。其中,路径名引 入了包的概念,在用例名前加上该用例所属包 的名字,两个名字之间用两个冒号分开。
可选操作流程
该借阅者有超期的借阅信息,进行超期处理; 借阅者所借阅的图书超过了规定的数量,用例终止,拒绝借阅; 借阅证不合法,用例终止,图书管理员进行确认 王强,定义基本操作流程,2008年1月7日 丁一,定义可选操作流程,2008年1月10日
修改历史记录
3.3.4 用例间的关系
在用例模型中,用例与参与者之间、用例与用 例之间有一定的关系。 UML中用例之间的关系主要有4种:关联关系、 泛化关系、包含关系和扩展关系。
基本用例1
管理员
基本用例2
2、泛化关系
泛化关系表示两个用例之间存在用例泛化,其 中一个用例称为父用例,其派生的用例称为子用例, 子用例是父用例的特殊化形式。子用例除了具有父 用例的特性外,还可以有自己另外的特性。
父用例
子用例
用例间的泛化关系
3、包含关系
一个用例可以简单地包含其他用例具有的行为, 并把它所包含的用例行为作为自身行为的一部分, 这被称作包含关系。 包含关系是一种依赖关系。 包含关系把几个公共步骤抽取出来形成一个单独 的被包含用例,包含有公共步骤的用例称为基本 用例。 包含关系用虚线箭头加注<<include>>字样来表 示。
用例建模的过程是一个迭代并逐步细化的过程。
2、确定用例方法
参与者需要系统提供什么功能?即参与者需要系统
“做什么”?
参与者是否需要读取、产生、删除、修改或存储系
统中的某种信息?
当系统状态改变时,是否通知参与者? 是否存在影响系统的外部事件? 系统需要什么样的输入/输出信息?
3.3.3 描述用例



用例模型是表达系统外部事物(参与者)与系统 之间交互的可视化工具。

一个系统的用例模型由若干用例图组成,用例图 的主要成分有参与者(Actor)、用例(Use Case)以及用例间的各种关系。
用例图可以包含注释和约束,还可以包含包,用 于将模型中的元素组合成更大的模块。

用例1
参与者1 基用例1
1、描述用例作用
用例图通过图形符号描述了参与者和系统之间
的关系,但是它对于系统行为的细节描述比较 欠缺。
在一般情况下,需要以书面文档的形式对于用
例进行描述。
2、描述用例包含的内容
1.名称:能够明确的表明用户的意图或用例的用途, 切记不要使用诸如UseCase1、UseCase2之类的 名称,会使用例图的读者在阅读时无法读懂用例 图所描述的内容。
主参与者和副参与者
主参与者使用系统的主要功能,是使用系统较 频繁、业务量较大的用户。 副参与者处理系统的辅助功能,它与用例进行 交互的主要目的是为了给其他的参与者提供某些服 务。如管理数据库、通信、系统备份以及其他管理
等系统维护工作。
主动参与者和被动参与者
主动参与者是系统的启动者,负责启动一个或多
参与者(Actor)
3.2.2 确定参与者
1、说明
(1)进行用例图建模,首先要做的就是确定系统 的参与者。 (2)在确定参与者之前,一定要明确一点:参与 者对于系统而言,总是处于系统外部的,而不 是系统的组成部分。
2、识别参与者
谁将使用系统的主要功能(主参与者)? 谁将借助于系统来完成日常工作?
第3章 用例图
3.1 3.2 3.3 3.4 3.5 3.6 概述 参与者(Actor) 用例(Use Case) 用例间的关系 用例图建模 用例图建模实例
3.1 概述
在软件开发过程中,首先需要准确地描述客 户需求中的功能需求,即系统需要做什么,以便 进一步确定系统应建立哪些对象及所建立对象之 间的关系。用例建模是用于描述一个系统的功能 (即系统应该做什么)的建模技术。 建立用例模型的目的是为了寻找需求规约, 需要通过开发人员和客户之间进行多次的交互方 可完成。

<<include>>
基本用例
被包含用例
用例间的包含关系
<<include>>
BorrowBook
Librarian
ProcessOverTime
<<include>>
ReturnBook
图书管理系统用例图包含关系示例
4、扩展关系
扩展关系是一种依赖关系。它指定了一个用例可 以增强另一个用例的功能,通过基本用例添加动作来 扩展该用例。

面向对象的系统分析主要特点是把问题域中的事 物抽象为系统中的对象,最终建立一个用面向对 象概念表达的系统模型。 抽象必须有一个目标,对分析而言,这个目标就 是要满足用户需求。 Jacobson提出:针对系统对外提供的每一项功 能,详细地描述对这项功能的使用情况(use case,简称用例)。


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

(副参与者)? 谁将完成系统数据的录入、导出及修改等工作(主 动参与者)? 谁或什么系统对系统产生的结果感兴趣(被动参与 者)? 系统控制的硬件设备有哪些? 系统需要与哪些其他外部系统进行交互? 在预定的时间,是否有事件自动触发? 系统从何处获取信息?
<<extend>>
基本用例
扩展用例
<<include>>
BorrowBook Librarian ReturnBook
<<extend>>
<<include>>
ProcessOverTime
NotifyOverTime
3.4 用例图建模
1、用例图建模的步骤 在UML中,用例图建模的步骤主要包括: ① 识别和确定参与者。 ② 识别和确定用例。 ③ 描述用例。 ④ 定义用例之间的关系。 ⑤ 建立用例图,构造用例模型。 ⑥ 审核用例模型。
6.前置条件:前置条件以一个条件列表的形式进 行记录,用来描述执行用例之前系统所必须满 足的条件。这些条件必须在使用用例之前得到 满足。前置条件在使用之前,已经由用例进行 过测试。如果条件不满足,则用例不会被执行。
7.后置条件:后置条件将在用例成功完成以后得 到满足,它提供了系统的部分描述。即在前置 条件满足后,用例做了什么?以及用例结束时, 系统处于什么状态?
1、关联关系
关联关系是执行者与用例之间的联系。执行者 触发了用例之后,与用例进行信息交换,用例在完 成相应功能后,向执行者返回结果。关联用执行者
与用例之间的带箭头连线来表示。
1、关联关系
关联关系是执行者与用例之间的联系。执行者 触发了用例之后,与用例进行信息交换,用例在完 成相应功能后,向执行者返回结果。关联用执行者 与用例之间的带箭头连线来表示。
8.假设[可选]:假设描述的是系统在使用用例之前 必须满足的状态,这些条件并没有经过用例的检 测,用例只是假设它们为真。 9.基本操作流程:参与者在用例中所遵循的主要逻 辑路径。操作流程描述了用户和执行用例之间交 互的每一步。 10.可选操作流程:包括用例中很少使用的逻辑路径, 那些在变更工作方式、出现异常或发生错误的情 况下所遵循的路径。 11.修改历史记录[可选]:主要记录的是关于用例的 修改时间、修改原因和修改人的详细信息。
个用例,他们是为了完成某项事务而启动系统的,一 个主动参与者可以请求某种服务或者触发一个事件。 被动参与者从不启动用例,只是参与一个或多个 用例,他们响应系统的请求,为系统提供某种服务。
4、参与者的表示 在用例图中,参与者用一个简化的人体形状的 符号(稻草人)表示,在符号的下方注明了参与者 的名称。
<<include>>
参与者2 基用例2
<<include>>
被包含用例 用例2
参与者3
基用例3
<<extend>>
扩展用例
基本用例图
3.2 参与者(Actor)
3.2.1 参与者概念
1、概念 参与者是在系统之外与系统进行交互的任 何事物,可以是人或其他系统,他以某种方式 参与了系统内用例的执行。 2、特征 (1)参与者作为外部用户与系统发生交互,交 互的方式可以是参与者向系统发送消息,也可 以是从系统那里接收消息,或与系统之间交换 消息。
1、概念
用例(Use Case)是对参与者使用系统某项
功能时所进行的交互过程的描述,过程中包括 交互双方所执行的一系列动作。
用例描述了参与者与系统交互的完整过程。
2、用例特征
响应性。一个用例不会自动执行,总是由参与
者启动或由系统根据某些事件触发,参与者必 须直接或间接地指示系统去执行用例。
相关文档
最新文档