第3章用例及用例图-案例学习资料
第3章 用例图
为了保证系统正常运行,谁将对系统进行维护管理
(副参与者)? 谁将完成系统数据的录入、导出及修改等工作(主 动参与者)? 谁或什么系统对系统产生的结果感兴趣(被动参与 外部系统进行交互? 在预定的时间,是否有事件自动触发? 系统从何处获取信息?
(2)参与者不一定是人,也可以是一个外部系统, 该系统与本系统相互作用。代表的是一种角色。 (3)在系统的实际运作中,多个不同的用户可能 只对应于一个参与者;同时一个实际用户也可 能对应系统的多个参与者。
例如: 在“房地产开发经营管理系统”中,
所有的购房者作为一个集合,在“房屋销售子 系统”中作为购房合同的签约方出现,多个个 体在系统中担任一个参与者;同时,某个独立 的购房者在“物业管理子系统”中又作为房屋 的业主出现,同一个人在系统中担任了两类参 与者。
主参与者和副参与者
主参与者使用系统的主要功能,是使用系统较 频繁、业务量较大的用户。 副参与者处理系统的辅助功能,它与用例进行 交互的主要目的是为了给其他的参与者提供某些服 务。如管理数据库、通信、系统备份以及其他管理
等系统维护工作。
主动参与者和被动参与者
主动参与者是系统的启动者,负责启动一个或多
借阅图书用例的描述
用例名称 标识符 用例描述 参与者 状态 BorrowBook UC0001 图书管理员代理借阅者办理借阅手续 图书管理员 通过审查
前置条件
后置条件 假设 基本操作流程
图书管理员登录进入系统
如果这个用例成功,在系统中建立并存储借阅记录 图书管理员已经成功地登录到系统 1. 2. 3. 4. 5. 管理员输入借书证信息 系统验证借阅证的有效性 图书管理员输入图书信息 添加新的借阅记录 显示借书后的借阅信息
第3章(用例图)
从分析系统的参与者开始,考虑每个参与者是怎样使用系统。
①参与者希望系统提供什么功能; ②系统是否存储和检索信息; ③当系统改变状态时,是否通知参与者; ④是否存在影响系统的外部事件,是哪个参与者通知系
统这些外部事件。
用例
识别用例 例1:Email客户端(如:outlook express),A在北京发邮件给深 圳的B,系统提醒B”你有新邮件”,B收邮件。
参与者的表示方法
参与者
如何发现系统的参与者 ①谁使用系统? ②谁安装系统、维护系统? ③谁启动系统、关闭系统? ④谁从系统中获取信息,谁提供信息给系统? ⑤在系统交互中,谁扮演了什么角色? ⑥系统会与哪些其他系统相关联?
参与者
如何发现系统的参与者 例1:客户给销售员发来传真订货, 销售员下班前将当日订货单汇总 输入系统。
用例
用例的粒度 用例所包含的系统服务或功能单元的多少。
用例
用例规约 对每一个用例的详细描述信息,以便于其他人对整个系统有一
个更加详细地了解。
用例规约的内容
(1)简要说明 (2)前置条件 (3)基本事件流 (4)其他事件流 (5)异常事件流 (6)后置条件
前置条件 扩展事件流 基本事件流
后置条件
用例
事件流
例:将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。 提款─基本事件流
基本流步骤1:用户插入信用卡 基本流步骤2:输入密码 基本流步骤3:输入提款金额 基本流步骤4:提取现金 基本流步骤5:退出系统,取回信用卡
用例
事件流
例:将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。
问题:谁是系统的Actor?
答案: 销售员
参与者
2012-2013 第二学期 11本 UML 第三章 用例和用例图
代表两个用例之间的关系, 其中一个用例(基本用例base use case)的行为包含另 一个用例(包含用例inclusion use case)的行为的关系。 例子一:
确 认
取
款
转
账
查询余额
17
§3.4.2 包含关系(续)
例子二:从基本用例指向包含用例。 基本用例:ATM System 包含用例:Identify Customer ; Validate Account
11
§3.3 脚本(scenario)
脚本又称为情景、场景、情节、剧本等 在UML中,脚本贯穿用例的一条单一路径。 脚本的定义:脚本是用例的实例(instance)。 脚本与用例之间是对象与类的关系。 例如:针对‘取钱’的用例,脚本就会有 1、正常完成取钱的脚本。 2、账户拒绝、取不出钱的处理脚本。 3、取出钱不对后的处理脚本。 但是有1、2、3、…构成了一个用例。 脚本的描述:一个脚本是用具体的文字加以描述的。
用例驱动的方法论。 用例是各种交互的动作序列之间的说明与描述。 用例的描述、表示与命名方法、规律。 用例描述的是系统功能性的需求。 理解用例之间相互关系(泛化、包含、扩展)。 脚本是用例的实例。 参与者在系统中的含义。参与者之间同样有泛化关系。 用例描述是用例的主要部分。 用例描述无统一的标准。 用例分析结果与分析人员的水平与领域知识相关
由以上例子看出: 其用例描述并无一个固定的模式可循,各自有理解和侧重, 关键是要多加练习。
25
§3.7 寻找用例的方法
用例分析可遵循的步骤:
1、找出系统外部的参与者和外部系统,确定系统的边界; 2、确定每一个参与者所期望的系统行为; 3、命名这些系统行为为用例; 4、使用泛化\包含\扩展关系处理系统行为的公共或变更部分; 5、编制每一个用例的脚本; 6、绘制用例图; 7、区分主事件流和异常事件流,单独处理异常事件流用例; 8、细化用例图,去掉重复与冲突;
第三讲用例图
3.3 用例图的概念
• 1. 用例图
• 用例图是描述用例、参与 者及其关系的图。与所有 UML的其它图一样,用例 图可以包括注释、约束。 图3-1是棋牌管理系统对应 的用例图。 • 图中的元素包括:参与者、 用例、一个方框和一些表 示关系的连接线,所有的 用例都位于方框之内,该 方框称为“系统边界”。 方框内是棋牌管理系统的 多个用例,方框外是外部 参与者。
第3章 用例图
目录
3.1 需求技术
3.2 RUP开发过程
3.3 用例图的概念 3.4 用例图的表示 3.5 参与者之间的关系
目录
3.6 用例之间的关系
3.7 参与者与用例之间的关系
3.8 阅读用例图 3.9 用例图应用 3.10 建模要点
第3章 用例图
• 用例图是外部参与者所能观察到的系统功能的模型图,该 图呈现了一些参与者和一些用例,以及它们之间的关系, 主要用于对系统、子系统或类的功能行为进行建模。
3.3.2 标识用例间的关系
• 2.包含关系 • 在UML中,包含关系用构造型《include》表示,它是指基用例(base use case)在它内部的某一个位置上显式地合并了另一个用例的行为。 • (1) 包含用例的表示 • 包含是指一个用例被另一个用例使用,被使用的用例就是包含用例, 使用包含用例的是基用例。 • 图3-7说明:查询、提款、转帐三个是基用例,它们都包含打印回执用 例.基用例执行时必须执行包含用例,否则,基用例是不完整的,包 含用例不是孤立存在的,它仅作为基用例的一部分出现.图中,包含 关系的箭头是从基用例指向包含用例. • 只有当某个事件流片断在多个用例中出现时,才将这个事件流片段抽 取出来,放在一个单独的用例中,把这个用例用作包含用例。
用例和用例图
技巧 实地观察
访谈
描述
• 直接观察个人工作旳情况,以发觉现存旳实践方式和
问题
• 从个人处搜集特定信息
特定群体 调查
对一组人员进行调查,以便了解工作态度和共同看法
• 问卷调查 搜集详细数据和统计意义上比较主要旳数据
• • 顾客指 导
让最终顾客告诉你,他们是怎样操作系统旳
• 原型制作 模拟一种无法直接测试旳系统
人、外部系统、外部因素等
12
3.2.2 辨认参加者:参加者要点
• 参加者指在系统中所扮演旳角色。即在拟定参加者时,
应主要考虑他旳角色,而不是这个角色旳实例。
• 某些组织中可能有诸多营销人员,但他们均起着同
一种作用,扮演着相同旳角色。
• 一种顾客也能够扮演多…种角色:一种高级营销人员
既能够是贸易经理,也能够是一般旳营销人员。
小一点旳蓝色大理石
5
3.2.1 获取原始需求:如此脆弱
客户/顾客旳要 求/想法/期望
验收
分析和设计
没价值旳 软件需求
补文档
软件产品 编码和测试
软件设计
6
3.2.1 获取原始需求:也需要开发
客户/顾客旳要 求/想法/期望
软件产品
开发
验收
编码和测试
有价值旳 软件需求
分析和设计
软件设计
7
3.2.1 获取原始需求:技巧
第三章 用例和用例图
1
3.1 概述
• 用例图着重从系统外部执行者旳角度来描述系统需要提
供哪些功能,执行者能够是人或外部系统。
2
3.1 概述
用例图旳构成元素
• 图中旳元素涉及:参加者、用例、某些表达关系旳连接
3章:用例图习题
3章:用例图习题第3章用例图习题一、简答题1. 什么叫参与者,参与者有哪些基本特性?答:参与者也被称为活动者,是与系统发生交互的外部实体。
参与者的特性有:1)参与者位于系统的外部,不属于系统的内容;2)参与者与系统发生交互关系,交互关系主要有:使用系统,启动系统,获取系统信息或给系统提供信息;3)参与者和系统之间存在交互信息的接口,系统提供接口让参与者使用系统,或者系统通过参与者的接口与参与者进行交互。
2. 用例有哪些特性?答:概括起来,用例有以下特性:1)用例描述用户对系统的期望,被用于软件需求建模,一个用例对应于软件能够为参与者提供的一项服务。
2)用例反映参与者与系统一次完整的交互过程。
这个交互过程总是要耗费一段时间,并1执行一定的流程。
流程的执行是参与者与系统的一段互动过程,在这个过程中有输入到系统的信息,以及系统反馈给参与者的信息。
3)用例的执行过程是系统为参与者的一次服务过程,这个服务就体现为系统提供给参与者的功能。
一个用例执行的完成,需要有确定的评价结果,这个结果表现为系统提供给参与者的一项完整的功能。
4)用例是软件设计和测试的依据。
3. 用例之间有哪几种关系?答:泛化关系,包含关系,扩展关系。
4. 用例叙述应该包括哪些基本内容?答:包括:用例编号,用例名,参与者,前置条件,事件流,后置条件。
二、填空题1. 用例图的要素包括(参与者)、用例和(关系)。
2.参与者的英名名称是(actor),参与者2也被称为(活动者)。
3.参与者的类型可以是(人)、设备、(外部系统)和时间。
4.用例的英名名称是(usecase),也被称为(用案)和(用况)。
5.用例之间的关系有(泛化)、包含和(扩展)。
6.执行用例之前系统所处的状态被称为(前置条件),(事件流)被称为用例执行的流程。
三、选择题1.下面不属于用例图作用的是(C)A:展现软件的功能 B:展现软件使用者和软件功能的关系C:展现软件的特性 D:展现软件功能相互之间的关系2.下面(B)不属于用例图的要素A:参与者 B:包含3C:用例 D:关系3.下面对参与者说法不正确的是(A)A:是系统的一个实体 B:也叫活动者C:在系统外部 D:与系统发生交互4.下面(D)不属于参与者类型()A:人 B:设备C:外部系统 D:交互对象5.下面对用例说法不正确的是(C)A:usecase B:用况C:使用情况 D:用案6.下面不属于用例特点的是(B)A:用例描述用户可见的软件功能4B:用例反映功能的不同抽象层次C:用例反映参与者与系统一次完整的交互过程D:用例是软件设计和测试的依据7.下面不属于用例之间关系的是(A)A:关联 B:泛化C:包含 D:扩展四、练习题1.根据你的理解,把下面的用例图补充完整。
T3_用例及用例图
2)非正式:需求分析早期使用,可覆盖不同的场景
3)详述:详细编写所有步骤及各种变化。
二、用例图
1.用例图的作用
1)用例图用来描述软件需求模型中的系统功能,通过一组用例可以描述软件系统能够给用户提供的功能。
2)用例图可以作为整个系统开发过程中的开发依据,指导和驱动其他模型。
2.关联关系:参与者与用例之间是关联关系,表示参与者与用例之间具有使用,交互信息的关联。
3.泛化关系:参与者与参与者之间,用例与用例之间存在一般与特殊的关系。
4.包含关系:
1)两个用例之间,一个用例(基本用例)的行为包含了另外一个用例(包含用例)的行为。
2)包含关系Βιβλιοθήκη 依赖关系的<<include>>构造型来表示。
周次
第3周,第1次课;总第2次课
章节名称
第三章:用例及用例图
授课方式
课堂讲授(√);上机实验();
实际操作( );课程设计();
教学时数
2
授课方法
和手段
课堂讲授
教学目的
与要求
目的和要求:
1.理解什么是用例及用例图
2.用例的特点
3.用例的构成
4.用例的编写
5.用例的关系
6.如何发现用例
7.案例演示
教学基本内容纲要
5.扩展关系“
1)扩展关系表示基本用例在扩展点要增加新的行为或功能,以扩展到新用例。
2)扩展关系用依赖关系的<<extend>>构造型来表示。
七、如何发现用例
1.发现用例的简单描述:
1)选择系统边界
2)确定主要参与者
3)确定每个主要参与者的目标
第3章 用例图
案例分析--用例图
实例:“杂志流通”
在杂志的内容被一个雇员分析之前,每个杂志 首先由图书馆登记;分析员认为有意义的文章 被汇总输入到系统中;随后,杂志在雇员中传 阅。在此过程中,要求生成流通通知。该通知 被附到杂志上,并且包含现在正在阅读杂志的 雇员的名字。最后,在最后一名读者把杂志返 回到图书馆时,它由图书馆来存档。
3.1 参与者
从上面的问答得到系统中初步的类和对象:
GUI(图形用户界面):识别用户的命令,接收 用户的输入,显示程序的结果。
Recorder(记录员):记录中奖信息。 Chooser(抽奖者):抽出中奖号码。 Printing(打印对象):打印中奖信息。 Searching(查询对象):为奖票持有者查询中
3.2 用例
问:抽奖主持人用这个系 抽奖程序初步的用例图
统做什么事情?兑奖人员
抽奖程序
如何用这个系统帮助兑奖
?
抽出中奖号码
答:抽奖主持人用这个系统 活动主持人 抽出中奖号码,兑奖人员用
活动主持人
这个系统打印本次活动所有
打印中奖记录
的中奖记录。再对照记录兑 兑奖者
兑奖者
奖。
查询中奖情况
奖票持有者
奖票持有者
用例图的构成4要素:
参与者 用例 系统边界 关联
用例图的基本概念
3.1 参与者
1. 参与者(Actor)的概念
参与者是指存在于被定义系统外部并与该系统发生 交互的人或其他系统,他们代表的是系统的使用者 或使用环境。
在确定系统的用例时,首要问题就是识别参与者 (是一个类!!!!!!不是对象)。
如何识别用例?
参与者要向系统请求什么功能? 每个参与者的特定任务是什么? 参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗? 是否任何一个参与者都要向系统通知有关突发性的、外部的改变?
《软件工程》第3章用例图及其应用
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一,它能 够帮助开发团队更好地理解用户需求,明确系统 的功能范围。
2
通过用例图,开发团队可以对系统的交互方式进 行模拟和验证,从而发现潜在的问题和缺陷,提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中,保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率,确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例,可以找出未被测 试到的功能和业务流程,从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率,降低 漏测的风险。
02
针对每个测试场景,细化出具体的测试用例,包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求,从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程,为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系, 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物,它描 述了用户期望的系统功能和行为。
02 在系统设计完成后,可以通过与原始用例图进行 对比,验证设计是否满足原始需求。
03 如果设计不符合原始需求,则需要重新调整设计, 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
第3章用例及用例图课件
总结 用例的特点
① 用例用于描述系统的功能,这个功能是外部 使用者看到的系统功能,不反映功能的实现方 式。 ② 用例描述用户提出的一些可见需求,对应一 个具体的用户目标。 ③ 用例反映系统与用户的一次交互过程,应该 具有交互的信息的传递。 ④ 用例是对系统功能的描述,属于需求建模。
13
4. 怎样确定用例的粒度
35
3.5 用例描述
• 用例名称
– 应该与用例图相符,并写上其相应的编号
• 简要说明
– 对该用例对参与者所传递的价值结果进行描述,应 注意语言简要,使用用户能够阅读的自然语言
• 前置条件
– 是执行用例之前必须存在的系统状态,这部分内容 如果在现在不容易确定可以在后面再细化
• 后置条件
– 用例执行完毕系统可能处于的一组状态,这部分内 容如果在现在不容易确定可以在后面再细化
9、UML是通过什么方法来对语言进 行扩展的?
6
教学进程
第3章
用例及用例图
3.1 用例 3.2 参与者 3.3 用例之间的关系 3.4 用例图 3.5 用例描述 3.6 用例分析
7
3.1 用例
1. 用例的概念 用例(use case): 系统、子系统或类与外部的参与者
交互的动作序列的说明,包括各种序列及出错序列。简 单的说,表示参与者与系统的一次交互过程。 用例分析可以认为是对系统功能的分解。 2.用例的表示
UML除了可以用于软件建模之外,
还可以用于(
)建模。
3
教学进程
?问题:
4、填空 UML的基本语言要素包括( )、
( ) 和 ( )。
4
教学进程
?问题:
5、UML建模元素之间可以有哪几种 关系?
第三章用例图
方法2:每个use case 画一个交互图。
32
Create, Retrieve, Update, Delete 类型用例的处理:
– 采用CRUD四个用例还是一个用例? – 从用户需求的角度考虑而不是从数据 处理的角度考虑。
第3章 用例图
东北大学信息科学与工程学院
E-Mail: yanglei@
杨雷
1/336
学习目标
1、掌握用例模型包括内容 2、熟练掌握用例图 3、熟练掌握用例图中的关系 4、掌握用例描述 5、掌握用例图建模技术
2
主要内容 3.1 用例模型概述 3.2 用例图 3.3 用例图中的关系
– 可观测:用例止于系统边界 – 结果值:用例是目标向导的 – 系统执行:结果值是由系统生成的 – 由参与者观测:业务语言,用户观点 – 一组用例实例:用例的粒度
22
可观测
描述交互,而不是内在的系统活动
23
用例是目标导向的
系统的存在是因为:参与者有一些需要使用它 来满足的目标。用例是用来描述系统的目标
10
Use Case的定义
在一个workshop(专题讨论会)上,14位主要的 OO专家对Use Case有14个定义。 定义1:use case是对一个活动者(actor)使用 系统的一项功能时所进行的交互过程的一个文 字描述序列 (见[2])。 定义2:用例是系统、子系统或类和外部的参与 者(actor)交互的动作序列的说明,包括可选的 动作序列和会出现异常的动作序列. (见[3])
ቤተ መጻሕፍቲ ባይዱ12
用例基本思想
问题的提出:在系统尚未存在时,如何描绘用户需 要一个什么样的系统?如何规范地定义用户需求? 考虑问题的思路:把系统看作一个黑箱,看它对外 部的客观世界发挥什么作用,描述它外部可见的行 为。
第3章用例和用例图
□ 包含关系 表示的是用例之间的“has a”关系
3.4.4 用例的泛化、包含、扩展关系
□ 在扩展关系中,基本用例一定是一个well formed的用例,即是可以独立存在的用例。 一个基本用例执行时,可以执行,也可以不 执行扩展部分。
□ 在包含关系中,基本用例可能是、也可能 不是well formed。在执行基本用例时,一定 会执行包含用例(inclusion use case)部分。
3.1 用例
□ 使用用例进行需求分析的特点:
① 从使用者的角度描述系统中的信息 站在系统外部看系统 ② 描述了用户提出的一些可见需求 对应一个具体的用户目标 ③ 对系统行为的动态描述 属于UML的动态建模部分
3.1 用例
UML建模: ① 静态建模 ② 动态建模 ◇ 静态建模:类图、对象图、构件图和 部署图 ◇ 动态建模:用例图、顺序图、协作图、 状态图和活动图。
3.4.3 扩展关系
□ 包含用例和扩展用例
Buy Merchandise Customer
<<include>> <<extend>>
Browse Web Site
Add Order to Warehouse System
3.4.4 用例的泛化、包含、扩展关系
□ 泛化关系和扩展关系 表示的是用例之间的“is a”关系 泛化关系 扩展关系 比泛化关系多了扩展点
Trader
<<extend>>
Capture Deal
SalesPerson
Limits Exceeded
3.6 用例的描述
□ UML初学者 缺少用例的描述或用例的描述不完整 □ 用例是一个“文字描述序列” □ 用例是“动作序列的说明” □ 用例的描述才是用例的主要部分 是后续的交互图分析和类图分析必不可少 的部分。
第3章用例和用例图
3.1 用例
用例(use case)是Ivar Jacobson发明的. 其它的中文译 名有: 用况、用案等. 它是站在用户的角度看待系统、 定义系统 ;使用用户能够看懂的语言来表述
定义1: 用例是对一个活动者(actor,角色,参与者)使用 系统的一项功能时所进行的交互过程的一个文字描述序 列. 定义2: 用例是系统、子系统或类和外部参与者交互的动 作序列的说明, 包括可选的动作序列和会出现异常的动 作序列. 用例是代表系统中各个项目相关人员之间就系统的行为 所达成的契约, 软件开发过程是用例驱动的.
18
面向对象分析与设计 & UML
3.4.1 泛化关系
泛化关系代表一般与特殊的关系, 与继承类似. 在泛化关系中, 子用例继承了父用例的行为和含义, 子 用例也可以增加新的行为和含义或覆盖父用例中的行 为和含义.
右图的例子演示了 泛化关系
19
面向对象分析与设计 & UML
3.4.1 泛化关系
•
可以用来表示参与者与参与者之间,用例与用例之间的 特殊/一般化关系
33
面向对象分析与设计 & UML
3.6 用例的描述
用例描述一般包括的内容:
用例的目标 用例是怎么启动的 参与者与用例之间的消息如何传送 用例中除了主路径外, 其它路径是什么 用例结束后系统的状态 其它需要描述的内容
描述用例时的原则是尽可能写得“充分”, 而不是形式 化、完整或漂亮.
柜员机系统中,银行后台系统就是一个参与者; 2)硬件设备:如果系统需要与硬件设备交互时,如在 开发IC卡门禁系统时,IC卡读写器就是一个参与者; 3)时钟:当系统需要定时触发时,时钟就是参与者
第03章 用例和用例图
前置条件
后置条件
一个条件列表, 这些条件必须在访问用例前得到满足
一个条件列表, 这些条件必须在用例完成之后得到满足
基本操作流程 描述用例中各项工作都顺利进行时用例的工作方式
可选操作流程 描述变异工作方式、出现异常或发生错误的情况下的路径
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 一中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况. 其它译名: 情景、场景、情节、剧本. 每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
例:在“订货”用例中包括几个相关脚本: • 订货顺利进行的脚本; • 相关货源不足时的脚本; • 购货者的信用卡被拒绝时的脚本; • ……
第3章(用例图)
用例
事件流
将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。 (ATM)系统中的 例:将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。 提款─ 提款─基本事件流
基本流步骤1:用户插入信用卡 基本流步骤1 基本流步骤2 基本流步骤2:输入密码 基本流步骤3 基本流步骤3:输入提款金额 基本流步骤4 基本流步骤4:提取现金 基本流步骤5 退出系统, 基本流步骤5:退出系统,取回信用卡
用例规约模板
用例编号 用例名称 用例概述 范围 主参与者 次要参与者 项目相关人 利益说明 [为用例制定一个唯一的编号,通常格式为UCxx] 为用例制定一个唯一的编号,通常格式为UCxx] [应为一个动词短语,让读者一目了然地知道用例的目标] 应为一个动词短语,让读者一目了然地知道用例的目标] [用例的目标,一个概要性的描述] 用例的目标,一个概要性的描述] [用例的设计范围] 用例的设计范围] [该用例的主Actor,在此列出名称,并简要的描述它] 该用例的主Actor,在此列出名称,并简要的描述它] Actor [该用例的次要Actor,在此列出名称,并简要的描述它] 该用例的次要Actor,在此列出名称,并简要的描述它] Actor 项目相关人 [项目相关人员名称] 项目相关人员名称] …… 前置条件 后置条件 成功保证 基本事件流 1 2 扩展事件流 1a 1b 子事件流 规则与约束 [从该用例获取的利益] 从该用例获取的利益] …… 利益
[即启动该用例所应该满足的条件。] 即启动该用例所应该满足的条件。 [即该用例完成之后,将执行什么动作。] 即该用例完成之后,将执行什么动作。 [描述当前目标完成后,环境变化情况。] 描述当前目标完成后,环境变化情况。 步骤 活动 [在这里写出触发事件到目标完成以及清除的步骤。] 在这里写出触发事件到目标完成以及清除的步骤。 ……(其中可以包含子事件流,以子事件流编号来表示) ……(其中可以包含子事件流,以子事件流编号来表示) 其中可以包含子事件流 [1a表示是对1的扩展,其中应说明条件和活动] [1a表示是对1的扩展,其中应说明条件和活动] 表示是对 ……(其中可以包含子事件流,以子事件流编号来表示) ……(其中可以包含子事件流,以子事件流编号来表示) 其中可以包含子事件流
第3章 用例和用例图-2
3.4.3 扩展关系
在一定条件下,把新的行为加入到已有的 用例中,获得的新用例叫扩展用例,原有 的用例叫基本用例。 扩展用例的规则限制
基本用例必须声明若干“扩展点”(extension point),而扩展用例只能在这些扩展点上增加新的 行为和含义。
<<extend>>
扩展用例
基本用例
<<include>>
参与者、用例间的关系类型
□ 下表是参与者、用例之间关系的总结
3.4 UML中几个概念的区别和联系
□ 关系:模型元素之间的语义联系,包括关联、 泛化、依赖 □ 关联:两个或多个类元(参与者、类、用例、组件等) 之间的关系。描述了类元的实例之间的联系 □ 泛化:特殊和一般的关系 □ 依赖:例如包含关系和扩展关系 目标元素: 被依赖的元素 改变 源 元素: 依赖元素 相应的改变
练习
3.4 用例间的关系
□ 用例之间的关系包括:
① 泛化关系(generalization) ② 包含关系(include) ③ 扩展关系(extend)
3.4.1 泛化关系
□ 泛化(generalization)代表一般与特殊的 关系。 ■ 在泛化关系中,子用例继承了父用例的行 为和含义,子用例也可以增加新的行为和含 义或覆盖父用例中的行为和含义。
父用例
子用例
3.4.1 泛化关系
Validate User
订票
电话订票
网上订票
Retinal Scan
Check Password
□ 什么时候使用泛化关系?
当发现系统中有两个或者多个用例在行为、结构、目 的方面存在共性时就可以使用泛化关系。可以用新的 用例(通常是抽象的)来描述共有部分,这个新用例 就是父用例。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
● ① 找出系统外部参与者,确定系统边界和范围。
17
● ② 确定各参与者所期望的系统行为。
柜台人员 客房预订 预订变更 入住登记 退房结帐 选择课程 信息查询
18
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
19
● ④ 确定各用例之间的关系(泛化,包含,扩展)。
13
● ⑥ 编制用例说明。
● 用例:增加课程
●参与者:管理员
●操作流:
① 管理员选择进入管理界面,用例开始。
② 系统提示输入管理员密码。
③ 管理员输入密码。
④ 系统检验密码。
A1:密码出错。
⑤ 进入管理界面,系统显示当前所建立的全部课程信息。
⑥ 管理员选择增加课程,管理员输入新课程信息。
⑦系统验证是否与已有课程冲突。
2
3.7 业务用例图
4
3.8 实例
• 案例1:
– 有一个爱书之人,家里各类书籍已过千册,平时又 时常有朋友外借,因此需要一个图书管理系统。该 系统应该能够将书籍的基本信息按计算机类、非计 算机类分别建档,实现按书名、作者、类别、出版 社等关键字的组合查询功能。在使用系统录入新书 籍时系统会自动按规则生成书号,以修改信息,但 不能够删除记录。该系统还应该能够对书籍的外借 情况进行记录,可对外借情况列出打印。另外,还 希望能够对书籍的购买金额、册数按特定时限进行 统计。
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例:客房预订 ●参与者:柜台工作人员 ●说明:
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例:预订变更 ●参与者:柜台工作人员 ●说明:
A2:有冲突。
⑧系统添加新课程,并提示添加成功。
⑨系统回到管理主界面,显示所有课程,用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图,解决用例之间的冲突和重复。
15
案例3:
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的 功能。
END
27
5
案例1: • 用例图
6
案例1: • 优化
7
案例2:
某学校网上选课系统的用例分析
管理员通过系统管理界面进入系统,建立本学 期要开设的各种课程,将课程信息保存到系统中, 并可以对课程进行改动和删除。 学生通过客户机浏览器进入系统,选择课程:可 以查询课程,选择课程,支付课程费用。
8
● ① 找出系统外部参与者,确定系统边界和范围。
第3章 用例和用例图
● 3.4 用例图 3.4.1 用例图的作 3.4.2 用例图的形式
● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
● —— 重要知识点
26
本章作业
(1) 什么叫用例? (2) 用例图在软件建模中的作用是什么? (3) 用例之间存在那几种关系? (4) 包含关系和扩展关系有什么区别? (5) 参与者可以是那几种形式? (6) 什么叫事件流,作用是什么?
24
● ⑥ 编制用例说明。
● 用例:退房结帐 ●参与者:柜台工作人员 ●说明:
① 工作人员启动退房结帐功能。 ② 输入旅客标志信息。 ③ 系统显示旅客入住信息。 ④ 显示入住天数,费用。 ⑤ 接收费用。 ⑥ 打印发票。 ⑦ 入住登记结束。
25
● 小结
3.1 用例
3.2 参与者
3.3 用例之间的关系 4.3.1 关联关系 4.3.2 泛化关系 4.3.3 包含关系 4.3.4 扩展关系
① 工作人员启动预订功能。 ② 输入预订人标志信息。 ③ 系统显示该预订人的客房预订信息。 ④ 预订变更。 ⑤ 预订变更成功。
23
● ⑥ 编制用例说明。
● 用例:入住登记 ●参与者:柜台工作人员 ●说明:
① 工作人员启动入住登记功能。 ② 根据旅客要求查询客房空闲信息。 ③ 如果不满足旅客入住要求,则退出。 ④ 接收旅客信息。 ⑤ 给旅客分配房间床位。 ⑥ 接收押金。 ⑦ 打印入住单 ⑧ 入住登记结束。
9
● ② 确定各参与者所期望的系统行为。
管理员: 增加课程 修改课程 删除课程
学生: 查询课程 选择课程 网上付费
10
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
11
● ④ 确定各用例之间的关系(泛化,包含,扩展)。
12
● ⑤ 绘制用例图。
第3章
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统(或工作内容) – 帮助业务过程重建工程工作 – 帮助员工(小组内成员)充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足