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

用例和用例图

  • 格式：pptx
  • 大小：1.05 MB
  • 文档页数：43

下载文档原格式

  / 43

合集下载

UML用例和用例图

UML用例和用例图

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侧重从最终用户 的角度来理解软件系统的需求，强调谁在使用系统、系统可 以完成哪些功能。用例分析技术已经是一种公认有效的用户 需求获取、分析和描述技术
情况二：假如机票购买者通过呼叫中心，由人工座席 操作订票系统购买机票，那么谁是参与者？
情况三：如果机票购买者通过呼叫中心的自动语音预 定机票而不是通过人工座席，那么谁是参与者？
情况四：如果扩大系统边界，让呼叫中心成为机票预 定系统的一个子系统，并且假设机票购买者将可以 自主选择是通过人工座席还是自动语音登录网站预 订机票，那么谁是参与者？

用例和用例图

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

第05讲用例分析与用例图

第05讲用例分析与用例图

基于用例的需求分析过程
获取原始需求
开发一个可以理解的需求
识别参与者
识别用例
确定关系
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章用例和用例图


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-用例及用例图

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

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

用例图


存款
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 用例分析
识别参与者
已有的上下文关系图（表示系统范围）及其他相关模型：它 们描述了系统与外部系统的边界，从这些图中可以寻找出与 系统有交互关系的外部实体。 项目相关人员分析：对项目的相关人员进行分析，就能够决 定出哪些人将会与系统进行交互。 书面的规格说明和其它项目文档（如会谈备忘录等） 需求研讨会和联合应用开发会议的记录：这些会议的参与者 通常是很重要的，因为他们在组织中所代表的角色就是可能 与系统发生交互的参与者。 当前过程和系统的培训指南及用户手册：这些东西中经常会 有潜在参与者。
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 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机器处于正常准备状态