2 设计用例图的案例

合集下载

uml综合案例:医院预约挂号系统

uml综合案例:医院预约挂号系统
描述 普通游客,没有访问该系统的账号和密码 通过管理员审核后的合法用户 对本系统进行日常维护和后台管理人员 使用该系统的医院各科室分诊台的护士 使用该系统的医院挂号处的工作人员 为该系统提供支付接口的外部系统 习惯用法,启动需要系统自动执行的用例
表 2. 医院预约挂号系统用例说明
描述 完成在系统的注册业务 查询医院、相关科室、各科室的医生等各类信 息 登录系统 注册用户可通过该用例完成预约挂号业务 打印出已经预约挂号的预约单 打印出已经预约挂号并支付费用的挂号单
备选事件流
A-* 用户在提交该预约前,随时都可能中止本次预约 1. 系统显示中止确认的消息; 2. 用户可以结束该用例,也可以选择继续。
A-1 当用户已经有成功预约且还没看病的预约记录时 1. 系统显示用户已有的预约记录; 针对每个预约记录,系统提供三个扩展点:打印预约单、打印挂号费、支付挂号费
A-2 无法查询到所要的出诊信息 1. 系统显示没有可用的出诊信息; 2. 注册用户可以重新输入查询条件进行查询,也可以结束该用例。
2. 参考答案
作业答案部分仅供参考,学生的作业可能会多种多样,具体按照第三部分的典型错误扣 分,用例图:
1
未注册用户 注册用户
实名注册
生成出诊信息
时间
打印预约单
查询医院信<<息extend>>
处理逾期未取消的预约
<<extend>> 打印挂号单
<<extend>>
预约挂号
支付挂号费
支付系统
取消预约
系统管理员
登录 审核注册信息
挂号处 核查预约单
<<include>>

两个案例背后的分析与思考——利用用例图表达架构观点之六

两个案例背后的分析与思考——利用用例图表达架构观点之六

件事:架构并非是 虚无飘渺、无所适从 的。例如进 ( 订购 ) ( ,销 销货 出货 ) ,存 或者 X o .它们都有机会来使用 C U Bx P。
的虚像。 一流的软件架构师. 很能懂得如 ( 库存) 系统.一般小型的套件( cae P kg ) a
这些都是显而易见的道理 .从以上
某主板设计师时 , 我会 研究 C U P 的规格 .
再举个例 子 .当你是 主板 开发厂商 知道该如何与之沟通 . 但却不会打开 . 事 时. 你会不会 “ 打开 CU 研究其 内部 实上也无从知道 C U的内部结构。不需 P P
仍有一致性与调和 的观点 。对架构要能 的结构 呢 绝 大部分设计 师会 回答说 不 要打开 .就会 ” 封装 C U.因为封装 . P 所 以只能通过 “ 口” 接 沟通 “ 有所不 为“ 就表示因为 “ 封装—了C U. 以我没有 P 所
住整体 .才能 了解系统设计与开发 时的 站在C U P 设计者的角度 , 我只要提供 ” 接 向与其假 设前提。
74 瑶 序 员
维普资讯
进销存系统需要几个数据库?
以用例 图在说 明架构设计 时 .每一
个 用套件 所界定范围的系统系指软件 应
类型产品的比较就会偏重 在系统的外观 解你 自己的角色 .或者知 道你现 在是用
所 以. 到底什么是 ” 架构”呢7其实 方面:系统所提供功能的多寡 、 完整性与 什 么角度在 看待系统 的设计 。当我 是某
架构。 .非常之难解释 若真要一言 使用者的图形 接 E (U)等。 _词 l GI 以蔽之 . 那么可 以说 .“ 构 架 是一种 整 体观 .需要 保持从 各 角度 看待架 构时 .
用系统 但用例 图却几乎不会 涉及 到数

用例及用例图案例

用例及用例图案例
第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) 什么叫事件流,作用是什么?

uml综合案例:员工考勤系统

uml综合案例:员工考勤系统

《UML2面向对象分析与设计》综合案例:员工考勤系统作业评分实施细则一、第四章作业(用例图和用例文档)1. 评分档次用例图和用例文档分别按照满分10分计算,以此作为评分标准,基本的评分准则如下:●一档(10分):图形(文本)条理清楚,无任何明显错误●二档(8-9分):图形/文本清楚,存在个别错误●三档(6-7分):图形/文本一般,存在一定的错误●四档(5分):图形/文本条理不清,存在致命错误或错误数过多一般情况下按错别个数扣分,每个错误按严重程度扣0.5、1、2分,最终成绩向上取整;同类错误不重复扣分。

2. 参考答案作业答案部分仅供参考,学生的作业可能会多种多样,具体按照第三部分的典型错误扣分,用例图:用例文档:员工(含小时工和普通员工)相关用例无前置条件员工已正确登录到该系统后置条件无(将在下次迭代中确定)涉众利益员工:准确地维护自己的考勤信息公司:要求员工的信息准确基本路径1—添加新的考勤1.1、用例起始于用户需要记录新的考勤信息1.2、系统显示当前日期和时间,并提醒用户该时间即为用户的上班时间1.3、用户确认该信息1.4、系统记录当前日期和时间,并将其作为用户考勤信息的上班时间2—提交考勤信息2.1、任何时刻用户都可以提交自己的考勤信息2.2、系统查询用户上班时的考勤记录(E-1)2.3、系统记录当前的日期和时间,作为用户考勤信息的下班时间2.4、系统显示用户今天完整的考勤信息2.5、用户确认提交考勤信息2.6、系统保存考勤信息,并将考勤信息的状态改为“已提交”(D-1)备选路径E-1 如果系统没有找到用户上班时的考勤信息,则用例终止;用户可以通过项目经理为其添加上班的考勤信息数据需求A-1 考勤信息主要包括:用户名、日期、上班时间、下班时间、状态D-1 考勤信息的状态有:“新考勤”(只有上班时间,没有下班时间的考勤信息)、“已提交”(有完整的上下班时间,但还没有进行工资结算的考勤)、“已完成”(已结算工资的考勤)业务规则B-1 作为用户考勤信息的上下班时间由系统自动获取,不允许用户编辑B-2 状态为“已提交”的考勤信息不允许普通用户进行任何操作;非功能需求无设计约束无待解决问题无参与者时间、项目管理数据库(外部系统)相关用例无前置条件无后置条件无(将在下次迭代中确定)涉众利益员工:…(包括临时工、普通员工、销售人员)公司:…基本路径—计算普通员工和销售人员工资1.用例起始于系统时间到达每月末晚上,需要计算普通员工和销售人员工资(E-1);2.系统查询所有的普通员工和销售人员的个人信息(D-1);3.对于每一个员工(普通员工、销售人员):3.1.根据员工的类别获得其考勤信息或订单信息(E-2);3.1.1.如果是普通员工,则获得本月的考勤信息(D-2);3.1.2.如果是销售人员,则获得本月的销售信息(D-3);3.2.系统从项目管理数据库中获得员工的工资级别信息(E-3);3.3.系统根据员工的考勤信息(或销售信息)和工资级别信息计算该员工的工资,保存;4.计算完成后,系统产生一个提醒信息,以便于项目经理确认备选路径E-1—计算临时工工资1. 用例起始于系统时间达到每个周末的晚上,需要计算临时工工资2. 系统查询所有临时工的个人信息3. 对于每一个临时工:3.1. 获得员工的考勤信息3.2 从项目管理数据库中获得员工的工资级别信息;3.3 系统根据员工的考勤信息和工资级别信息计算该员工的工资,保存;4. 计算完成后,系统产生一个提醒信息,以便于项目经理确认E-2 如果找不到该员工的考勤信息或订单信息,则记录相关日志,并转回3计算下一个员工E-3 如果无法获得员工工资级别信息,则记录相关日志,并转回3计算下一个员工数据需求D-1. 员工信息=员工编号+员工姓名D-2 考勤信息参见“登记考勤”用例D-3 订单信息参见“登记订单”用例业务规则暂不明确非功能需求暂不明确设计约束3. 典型错误情况3.1 用例图部分3.1.1 参与者本系统中包含的参与者有:小时工、普通员工、销售人员、项目经理、项目管理数据库、时间,其中由于小时工和普通员工有关考勤的处理细节完全相同,因此为了便于简化和复用,可将他们统一合并为员工(不合并也可以,不算错误),但不能和销售人员合并,因为销售人员没有考勤信息,而是登记订单信息,需要明确区分。

用例图, 类图

用例图, 类图

Get Upload Files
Receive Data
Manage Log
Breake Connection
Time
18/336
1.用例图 (19/29)

20/336
21/336
22/336
1.用例图 (22/29)
23/336
24/336
1.用例图 (25/29)
智能电梯系统
25/336
1.用例图 (26/29)
Deal with Auditing Data
Auditing break connection
break connection
Server 17/336
1.用例图 (18/29)
• 学生课程注册系统例子
– 每个学生都可以增删改查自己的课程注册表 – 每个教师都可以查询课程花名册 – 学校管理人员可以维护全部课程,可以登记
Dat aObjec t
38/336
2.顺序图 (8/19)
40/336
2.顺序图 (9/19) 2.顺序图 (11/19)
41/336
: Actor
FormObject
1: Open form
ControlObject
DataObject
2: Enter information
3: Save informat ion
is displayed
4. Select a file
12/336
1.用例图 (12/29)
• 例子: 远程通讯
– 背景 – 任务
• 远程审核 • 远程客户端
Client
13/336
logon Request Data Receive Data

第二讲用例图.ppt

第二讲用例图.ppt
持有借阅卡的借阅者可以借阅书刊归还书刊查询书刊信息预定书刊并取消预定但借阅归还书刊操作都是通过图书管理员进行的图书管理员充当借阅者的代理与系统交在借阅书刊时需要输入所借阅的书刊名借阅者名等信息完成后提交所填表格系统验证借阅者是否有效若有效则查询数据库中是否存在借阅书刊若存在则借阅者可借出该书刊并在系统中存储借阅记录
通过回答以下的几个问题识别用例:
特定参与者希望系统提供什么功能。 系统是否存储和检索信息,如果是,由哪个参与者触
发。 当系统发生改变时,是否通知参与者。 是否存在影响系统的外部事件。
哪个参与者通知系统这些事件。
还有两个针对整个系统的问题:(1)系统需要何种输入输 出?输入从何处来?输出到何处去?(2)当前运行系统 的主要问题一?个用这例两至个少问要题与一并个不参意与味者着关联没!有参与者也可以 有用例,只是获取用例时还不知道参与者是什么。
(2)为系统的功能提供清晰一致的描述,以便为后续的开 发工作打下良好的交流基础,方便开发人员传递需求的 功能。
(3)为系统验证工作打下基础。通过验证最终实现的系 统能够执行的功能是否与最初需求的功能相一致,保证 系统的实用性。
(4)从需求的功能(用例)出发,提供跟踪进入系统中 具体实现的类和方法,检查其是否正确的能力。
S-1:添加所选课程
系统提示含有课程名和课程代码的域,学生输入希望选修的 课程名和课程代码(E-3),系统显示信息表示该课程可以选 修(E-4),并建立该课程与该学生的连接(E-5)。用例重新 开始。
S-2:删除所选课程
系统提示含有课程名和课程代码的域,学生输入希望取消的 课程名和课程代码,系统删除该课程与该学生的连接(E-6)。 用例重新开始。
4.用例
(1)用例的概念

UML中的用例图实践案例

UML中的用例图实践案例

UML中的用例图实践案例UML(统一建模语言)是一种用于软件开发的标准化建模语言,它提供了一套丰富的图形符号和概念,用于描述和设计软件系统的各个方面。

其中,用例图是UML中最为常用和重要的一种图形表示方法,它用于描述系统的功能需求和用户与系统之间的交互关系。

本文将通过一个实践案例,介绍用例图在软件开发中的具体应用。

假设我们要开发一个在线购物系统,该系统包括用户注册、浏览商品、添加购物车、下单、支付等功能。

首先,我们需要明确系统的角色和用例。

在这个案例中,系统的角色包括用户、管理员和支付网关。

用户可以注册账号、浏览商品、添加购物车、下单和支付;管理员可以管理商品信息;支付网关负责处理支付请求。

接下来,我们可以使用用例图来表示这些角色和用例之间的关系。

首先,我们可以在用例图中用椭圆形表示各个用例。

在本案例中,我们可以用椭圆形表示注册账号、浏览商品、添加购物车、下单和支付等用例。

然后,我们可以用矩形表示各个角色,即用户、管理员和支付网关。

接着,我们可以使用实线箭头来表示角色与用例之间的关系。

例如,用户可以注册账号,我们可以在用户和注册账号之间画一条实线箭头来表示这种关系。

除了角色和用例之间的关系,用例图还可以表示用例之间的关系。

在本案例中,用户可以浏览商品、添加购物车、下单和支付,这些用例之间存在一定的先后顺序。

我们可以使用虚线箭头来表示这种顺序关系。

例如,用户可以先浏览商品,然后将商品添加到购物车,最后下单和支付。

我们可以在浏览商品和添加购物车之间画一条虚线箭头,表示用户在浏览商品后可以将商品添加到购物车。

此外,用例图还可以表示用例之间的包含和扩展关系。

在本案例中,用户下单时可能需要选择配送地址,我们可以将选择配送地址作为一个包含关系,用一个带有加号的实线箭头表示。

另外,用户下单时还可以选择使用优惠券,这可以作为一个扩展关系,用一个带有箭头和加号的虚线箭头表示。

通过用例图,我们可以清晰地描述系统的功能需求和用户与系统之间的交互关系。

(完整word版)UML综合案例

(完整word版)UML综合案例

UML在ATM自动取款机中的应用(一)Uml 基础知识Uml 概述UML (Unified Modeling Language)是软件界第一个统一的建模语言,该方法结合了Booch , OMT ,和OOSE 方法的优点,统一了符号体系,并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术.它是一种标准的表示,已成为国际软件界广泛承认的标准。

是一种基于面向对象的可视化的通用(General )建模语言。

为不同领域的用户提供了统一的交流标准 — UML 图。

UML 应用领域很广泛,可用于软件开发建模的各个阶段,商业建模(Business Modeling ), 也可用于其它类型的系统。

UML 是一种定义良好,易于表达,功能强大且普遍实用的建模语言,不是一种方法,它独立于过程。

利用它建模时,可遵循任何类型的建模过程。

建模过程:UML 的主要构成向对象分析与设计的一种UML 是一种标准化的图形建模语言,它是面向对象分析与设计的一种标准表示.由:● 视图(views ), ● 图(Diagrams ),● 模型元素(Model elements ) ● 通用机制(general mechanism )等几个部分构成。

视图(views)一个系统应从不同的角度进行描述,从一个角度观察到的系统称为一个视图(view)。

视图由多个图(Diagrams)构成,它不是一个图表(Graph),而是在某一个抽象层上,对系统的抽象表示。

如果要为系统建立一个完整的模型图,需定义一定数量的视图,每个视图表示系统的一个特殊的方面。

另外,视图还把建模语言和系统开发时选择的方法或过程连接起来。

图(Diagrams)UML语言定义了五种类型9种不同的图,把它们有机结合起来就可以描述系统的所有视图。

用例图(Use case diagram)从用户角度描述系统功能,并指出各功能的操作者。

静态图(Static diagram),表示系统的静态结构.包括类图、对象图、包图。

用例图说明实例

用例图说明实例

业务规则
4.至少选择一本,至多选择三本
涉及的业务实体
Be_费用记录 Be_图书 Be_借书篮 Be_借阅定单 Be_借阅证
上表是用例规约内容。过程描述中的章节号标明每一个可能的活动。例如,4 代表“用户可 单选或多选书本,并确认借阅。计算机显示确认借阅图书清单”这个活动,而 4.1.1 代表第 4 步的第一个可选分枝的第一步,4.1.2.1.1 代表第 4 步的第一个可选分枝的第二步中的第 一个可选分分枝的第一步。
用例名称
bu_借阅图书
用例描述
借阅人通过此用例向系统查询并提交借书请求
执行者
借阅人
前置条件 后置条件 主过程描述
分支过程描述
异常过程描述
1. 借阅人借阅证件在有效期内 2. 借阅人没有逾期未归还的图书 1. 创建借书定单 2. 更新借阅人借阅记录 1 用户用借阅证提供的帐号登录系统,计算机显示我的图书馆 界面 2.用户选择查询图书,计算机显示查询界面 3.用户按书名、作者、出版社查询,计算机显示查询结果 4.用户可单选或多选书本,并 确认借阅。计算 机显示确认借阅 图书清单。 5.用户选择确认借阅,计算机显示借阅定单及费用 6 用户选择提交定单,计算机显示提交结果和定单号 7.计算机执行后置条件。用例结束 2.1.1 用户选择查看原有定单,计算机执行 4; 4.1.1 用户可单选或多选书本,放入借书篮,计算机显示借书 篮现有内容 4.1.2.1.1 用户选择继续借书,计算机执行 2; 4.1.2.2.1 用户选择提交借书篮,计算机执行 4 4.2.1 用户选择放弃,计算机执行 2; 6.1.1 用户选择保存定单,计算机保存并执行 1; 6.2.1 用户选择放弃,计算机执行 1; 1.1.1 借阅证已过期,拒绝登录,用例结束 1.2.1 借阅人有逾期未归还书本,启动 bu_归还图书用例 5.1.1 用户余额不足,计算机显示余额和所需金额 5.1.2.1.1 用户选择续费,启动 bu_交纳借阅费用例 5.1.2.2.1 用户选择放弃,计算机执行 1

案例二:网上购物系统UML课程设计RationalRose建模(综合)

案例二:网上购物系统UML课程设计RationalRose建模(综合)

后置条件:
如果用例成功,客户将收到发票。
用例:
Inform Warehouse about Order
简述:
在客户定单输入到系统之后,销售人员发送电子请求给仓库,附上所订购的配置的细节。
参与者:
Salesman Warehouse
前提条件:
验证和接收客户付款成功。
Salesman选择系统提供的订购清单中该客户的订购信息,并点击Refer(或相似命名的)功能键来将订购信息提交给Warehouse时,该用例开始。
3.客户可以选择在线订购计算机,或者也可以要求销售人员在定单真正发出之前与自己联系,解释定单的细节、协商价格等。
4.要发出定单,客户必须填写在线表格关于运送和发票地址以及付款细节(信用卡或支票)。
5.在客户定单输入到系统之后,销售人员发送电子请求给仓库,附上所订购的配置的细节。
6.事务的细节,包括定单号和客户账号,要e-mail给客户,使得客户可以在线查看定单的状态。
参与者:
Customer
前提条件:
Customer点击一个因特网浏览器进入计算机制造厂商的定单输入Web页面,该页面显示已配置计算机及其价格的详细情况。
当Customer在定单信息已经显示在屏幕上时选择Continue(或相似命名的)功能键来确定订购所配置的计算机时,该用例开始。
主流:
系统请求Customer输入购买细节,包括销售人员的名字(如果知道的话)、运送信息(客户的名字和地址)、发票细节(如果与运送地址不同的话)、付款方法(信用卡或支票)以及任何其他注释。
SelfConfigurationWindow类调用此方
法从Component类中得到计算机自选部件的
详细信息。

uml综合案例:医院预约挂号系统

uml综合案例:医院预约挂号系统
二、第五章作业(用例分析)
1. 评分档次
一档(10 分): 图形(文本)条理清楚,无任何错误 二档(8-9 分): 图形/文本清楚,存在个别错误
5
三档(6-7 分): 图形/文本一般,存在一定的错误 四档(5 分): 图形/文本条理不清,存在致命错误或错误数过多 一般情况下按错别个数扣分,每个错误按严重程度扣 0.5、1、2 分,最终成绩向上取整; 同类错误不重复扣分。
支付挂号费控制类 添加出诊信息控制 类
处理逾期未取消预约 核查预约单和挂号单
控制类
控制类
7
医院
科室
医生
出诊信息
出诊规则
用户
注册用户
支付
预约
预约挂号(基本路径)顺序图
: 注册用户 : 预约挂号界面类
: 预约挂号控制类
//查询出诊信息
//查询出诊信息
: 出诊信息
//生成可用的出诊信息 出诊信息 显示可用的出诊信息
目前的问题陈述中,还有很多细节问题没有阐述清楚,需要进一步考虑(这也是我们做 需求过程中普遍存在的问题,需求需要不断地细化)。当考虑的细节不同时,系统的参与者 和用例也不一样,主要包括以下几个方面的问题:
(1)系统需要根据用户是否去看病,维护用户的信用等级,那如何知道用户去看病? (2)护士核查预约单和挂号单,以及挂号处核查预约单和打印挂号单需要先登陆“挂 号系统”,在系统中核实及打印吗?还是只需要凭用户手中纸制的“预约单”和“挂号单” 即可完成以上工作? (3)根据实际情况,每个医院都会有自己的“管理系统”,管理科室,医院情况,以及 挂号、付费情况,如果是这样,那么医院自己的系统也将会和“医院挂号系统”有接口数据 同步的问题? (4)“对于那些在网上预约成功,却不去看病也不按时取消的用户,系统会进行警告: 已收取的费用不再退回。”,问题是这个警告是什么时候发出?是在用户预约成功后,提示“预 约不去,不退费”这样的字样吗?还是在用户没有按时就诊这个事件发生后,将来再次登录 系统的时候警告? 用例部分,从参与者的角度查找用例,根据针对上面问题的理解不同,部分用例可能会 有区别。主要考虑包括以下几个方面的用例: (1)未注册用户:实名注册和查询(实名注册用例必须要有); (2)注册用户:预约挂号、取消预约(两个最核心的用例,不能缺少);其他打印(预 约单、挂号单),支付挂号费等可以作为单独的用例存在,也可以作为预约挂号的一部分(子 用例)存在; (3)系统管理员:审核注册信息、维护出诊信息(应该有这两个业务相关的用例,但 可以考虑有不同级别的管理员来执行该用例); (4)时间:生成出诊信息、处理逾期未取消的预约(应该有时间相关的用例); (5)分诊台护士的核查用例,挂号处的取消预约和打印挂号单用例,这部分作为可选, 根据不同的业务考虑会由不同的用例。

用例图活动图案例

用例图活动图案例

1、设计一个饮料自动售货机系统,其主要功能是向顾客出售饮料,同时供应商需要向其中放置饮料,收银员需要向其中放置零钱和收回营业收入。

画出该系统的用例图。

2、仔细分析下面对某公司“会见顾客”业务流程的描述,画出带泳道的活动图。

(1)公司业务员打电话给客户,确定一个会面。

(2)如果会面地点在公司内,公司技术人员需要为会面准备一间会议室,同时,咨询顾问需要为准备一份陈述报告。

(3)如果会面地点在公司外,则只需咨询顾问需要为准备一份陈述报告。

(4)咨询顾问与顾客在约定的时间和地点见面。

(5)业务员随后为他们准备好会议用纸。

(6)如果会面得到了一个解决方案,则咨询顾问根据解决方案编写一个报告,并将报告发给顾客。

3 所谓基金定投指的是投资者在每个月固定的时间(如每月10日)以固定的金额(如1000
元)投资到指定的开放式基金中,类似于银行的零存整取方式。

具体实现过程如下:定投约定的日期一到,系统首先检查客户设定的扣款账户余额,确认余额是否足够支付交易款项,如果足够,则扣交易款项,更新客户基金账户中基金的份额,交易成功,并且把交易扣款失败次数归零。

否则检查累计失败次数,如果累计失败次数超过三次,则停止扣款,并且更改交易情况为“停止扣款”。

请采用活动图模型对这个业务进行建模。

用例图设计实例:

用例图设计实例:

实验二:建立动态模型一旦定义了一个工程的用例,就可以用它们来指导对系统的进一步开发。

用例的实现描述了相互影响的对象的集合,这些对象将支持用例所要求的功能。

给出系统用例的实现,是从外部视图转到内部结构的第一步。

在UML中,用例的实现用交互图来指定和说明。

交互图通过显示对象之间的关系和对象之间处理的消息来对系统的动态特性建模。

有两种交互图:序列图和协作图。

1、创建交互图的步骤交互图一步一步地显示用例的实现流程。

它包括流中需要什么对象、对象之间发送什么、什么角色启动流、消息按什么顺序发送等。

系统要求实现的所有不同情形都在交互图中记录。

通过从用例建模得到的用例文档说明、词汇表和用例图来创建交互图。

2、实例本节主要以选课系统中的选课用例(Select Course)为例,来学习序列图的设计与实现。

2.1 分析为了使问题更简单一些,不考虑学生的登陆。

假设学生已经成功登陆系统,选课的事件流如下:(1)学生进入选课主界面。

(2)学生点击选课。

(3)系统显示所有课程信息。

(4)学生选择课程。

(5)系统验证课程是否可选。

A1:课程不可选(6)系统提示课程选择成功,提示学生交费。

(7)用例结束。

A1:课程不可选(1)系统提示课程不可选及原因。

(2)学生重新选课。

(3)重新验证直至成功。

(4)转选课事件流第6步。

首先,查找Select Course用例的对象。

从事件流中发现涉及以下对象:(1)界面。

(2)课程。

(3)对于业务层的操作,也应该有对象进行处理。

(4)事件流中设计的角色有:学生、数据库。

然后,分析对象、角色之间交互的消息。

本用例主要有以下交互:(1)学生通过界面发送选课命令。

(2)界面向控制对象请求课程信息。

(3)控制对象向数据库发送查询数据消息。

(4)控制对象暂存数据库的查询结果。

(5)界面对象从控制对象中取得所有的课程信息。

(6)在界面上显示所有的课程信息。

(7)界面对象发送命令要求控制对象删除课程信息。

2 设计用例图的案例

2 设计用例图的案例
软件工程导论
孙旭光
灾害信息工程系
功能模型

在面向对象方法学中,可以使用UML提供的用例 图进行需求分析和建立功能模型。
也把用用例图建立起来的系统模型称为用例模型。
使用用例模型代替传统的功能说明,能更好地获取
用户需求,它所回答的问题是“系统应该为每个用
户做什么”。
用例模型描述的是外部行为者所理解的系统功能。

建立用例模型:银行账户管理系统需求陈述如下:
用例名称:开户 一个客户可以在多个银行中开设账户,一个客户也 参与者:银行职员(客户代理)、客户
前臵条件:一个合法的银行职员(客户代理)已登录到该系统 可在同一银行中开设多个不同的账户。客户可以通 事件流: 过银行职员进行开户、存款、取款、转账、注销账 1. 当选择开户功能时用例开始 2. 输入客户信息(姓名、地址、身份证号等) 户等活动。其中转账指客户将自己的某个账户上的 3. 从账户管理系统获取新的账号 钱转入同一银行的不同账户(称为银行内转账)或 4. 请客户输入密码 5. 请客户再次输入密码 转入不同银行的账户(称为银行间转账)。系统管 6. 如果两次密码不一致则回到第4步,否则继续 理员负责系统的账户管理及业务报表的生成。 7. 在账户库中添加新账户

注意寻找参与者时不要只考虑使用计算机的人!
用例图—参与者

参与者间的关系
用例图—系统边界

系统边界是指系统与系统之间的界限。
系统与环境之间存在边界,子系统与
其他子系统之间存在边界,子系统与 整体系统之间也存在边界。 用例图中的系统边界用来表示正在建 模系统的边界,边界内表示系统的组 成部分,边界外表示系统的外部。
8. 打印存折,用例结束 后臵条件:在账户库中增加一个新账户,得到一张新存折

用例图实例讲解

用例图实例讲解
承的行为。
用例图建模技术
对语境建模 对需求建模
对语境建模
① 识别系统外部的参与者。 ② 将类似参与者组织成泛化的结构层次。 ③ 在需要加深理解的地方,为每个参与者提供一个构造型。 ④ 将参与者放入到用例图中,并说明参与者与用例之间的
通信路径。
对需求建模
① 识别系统的外部参与者来建立系统的语境。 ② 考虑每一个参与者期望的行为或需要系统提供的
用例图实例讲解
概述
用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户 需要为系统提供的服务。
用例图最常用来描述: ① 参与者(Actor) ② 用例(Use Case) ③ 关联关系(Association) ④ 包含关系(Include) ⑤ 扩展关系(Extend) ⑥ 泛化关系(Generalization)
参与者
参与者的种类: ① 系统用户 ② 与所建造的系统交互的其他系统 ③ 一些可以运行的进程
参与者间的关系
参与者间的泛化关系示例: 在用例图中,使用泛化关系来描
述多个参与者之间的公共行为。
用例
外部可见的系统功能单元。 在不揭示系统内部构造的前提下定义连贯的行为。 不是需求或功能的规格说明,但是也展示和体现其所描述
包含关系
客户用例可以简单地包含提供者用例具有的行为,并把它所包含的用 例行为作为自身行为的一部分。
扩展关系
扩展用例被定义为基础用例的增量扩展。 基础用例提供扩展点以添加新的行为。 扩展用例提供插入片段以插入到基础用例的扩展点上。
泛化关系
父用例也可以被特别列举为一个或多个子用例。 子用例表示父用例的特殊形式。 子用例从父用例处继承行为和属性,还可以添加行为或覆盖、改变继

苏州科技学院UML建模技术案例

苏州科技学院UML建模技术案例
(from Actor)
Credit System
(from Actor)
Flight Coordinator
(from Actor)
62
Airline
案例1:航空售票系统
Purchase Ticket Check credit Change Reservation
Credit System
(from Actor)
58
识别思路:
• • • • • • • • • 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务
操作员,管理员 操作员,管理员 操作员,管理员
领料员,退料员,操作员,管理员,供应商
谁负责维护、管理并保持系统正常运行案 管理员 系统需要应付那些硬件设备 生产系统, 供应商系统 系统需要和那些外部系统交互 操作员,管理员,领料员,退料员 谁对系统运行产生的结果感兴趣 时间、气温等内部外部条件 时间
(from Actor)
Flight Coordinator
(from Actor)
57
Airline
案例2:库存管理系统
某汽车制造厂需要一套库存管理系统, 该系统实现的业务:生产工人根据生 产计划领取物料,库存操作员根据生 产系统的派单准备,交付给领料工人, 余料即时归还库房。库房管理人员定 期盘点库存,通知供应商供货,对长 期积存的货物,申请退货。
75
76
练习: 建模航班状态图 创建一个状态图来描述航班如何从提出申请、制定航班计划、 售票、起飞、飞行、到着陆的状态过程。 练习步骤; 1)标识出要建模的实体。 2)标识出实体的状态。
77
航班计划 批准航班计划 航班申请
entry/ 发 布 航 班 信 息 do/ 检 查 当 前 日 期

系统分析设计实验02用例图及其应用ppt课件

系统分析设计实验02用例图及其应用ppt课件
2021/4/17
4 用例规范及应用
Diagrams标签 • 用例所拥有的模型图 的信息,其中第一列 (没有标题)显示模 型图的图标,第二列 (Title)显示图的名称
2021/4/17
4 用例规范及应用
– Relations标签 • 用例与其他用例 或参与者之间存 在的所有关联关 系
2021/4/17
2021/4/17
Purchase Ticket
1 基本概念-用例
• 每个用例执行都独立于其他用例,即使它 们之间存在隐含的依赖关系。
• 动态执行过程可以使用UML的交互说明。 • 在系统层,用例表示整个系统对外部用户
可见的行为。
2021/4/17
1 基本概念-用例识别
• 参与者要向系统请求什么功能? • 每个参与者的特定任务是什么? • 参与者需要读取、创建、撤消、修改、或存储系统的
2021/4/17
对需求建模
• 通过识别外部参与者建立系统语境 • 考虑每一个参与者期望的行为或需要系统
提供的行为 • 把公共行为命名为用例 • 确定提供者用例和扩展用例
– 分解公共行为,作为新用例 – 分解异常行为,作为新用例的扩展
• 在用例图中对用例、参与者和它们之间的 关系进行建模
2021/4/17
2021/4/17
1 基本概念-用例
– 用例特征 • 说明了系统具有的一种行为模式
• 说明了一个参与者与系统执行的一个相关的事务 序列
• 提供了一种获取系统需求的方法
• 提供了一种与最终的用户和领域专家进行沟通的 方法
• 提供了一种测试系统的方法 – 图形表示
• 用椭圆形表示,用例的名字显示在图标的下面
2021/4/17

用例图实例

用例图实例
3、当病症信号异常时,系统自动更新病历并打印病情 报告。
4、值班护士可以查看病情报告并进行打印。 5、医生可以查看病情报告,要求打印病情报告,也可 以查看或要求打印病历。 6、系统定期自动更新病历。
首页 上页 下页 末页 退出
需求分析
三、用UML的静态建模机制定义并描述系统的静态结构 (一)建立系统的用例图
nn显示病情报告显示病情报告在显示器上显示病情oo打印病情报告打印病情报告在打印机打印病情报告用例细化用例细化给出细化的用例图给出细化的用例图病人模数转化数据格式化值班护士报警信号采集比较信号标准病症信号库医生信号数据组合采样频率改变提供标准病症信号生成病历查看病历更新病历打印病历显示病情报告打印病情报告分解信号extenduseuseuseuseuseuseuseuse细化的用例图细化的用例图
要求根据现场情景,对医院病房监护系统进行需 求分析, 建立系统的Use case model。
情景教学
医院病房监护系统
监视病情
产生 病情报告
经过初步的需求分析,得到系统功能要求:
1、请监视对病系员统的需病求症(进血行压分、析体!温、脉搏等)
2、定时更新病历 3、病员出现异常情况时报警。 4、随机地产生某一病员的病情报告。
1、中央监护
分解为: a 分解信号 将从病症监护器传送来的组合病症信号分解为系 统可以处理的信号。
b 比较信号 将病人的病症信号与标准信号比较 。
c 报警 信号。
如果病症信号发生异常(即高于峰值),发出报警
d 数据格式化 将处理后的数据格式化以便写入病历库 。
2、病症监护
分解为:e 信号采集 采集病人的病症信号。
显示病情报告
打印病情报告
《 Extend 》
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

确定用例:

学生信息管理的用例 班级信息管理的用例
成绩管理的用例
网上选课的用例 账号管理的用例

注意:《include》应用的两 种场合:

1、多个用例都用到某个同 样的功能,将这个功能抽取 出来,单独编写,供其他用 例调用。
好处:避免了重复编写相同 的功能。


2、当某个功能包含若干个子功能时,使用《include》展 示子功能。 需要注意的是要区别是使用《include》合适还是使用“泛 化”合适。
使用Rose画图并不画系统边界,采用 Visio画图,用方框表示系统边界。 系统边界不一样,它的参与者就会发 生很大变化。搞清系统边界才能更好 地确定系统的参与者和用例。

系统 参与者 用例
用例图—用例
用例和参与者之间也有关系,这种关系属于关联关
系,是双向的一对一关系,表明了哪个参与者与用 例通信。
系统开发出来后,使用系统主要功能的是谁? 谁需要借助系统来完成日常工作? 系统需要从哪些人或其他系统中获取数据? 系统会为哪些人或其他系统提供数据? 系统会与哪些其他系统交互? 系统是由谁来维护和管理的,以保证系统处于工作状 态? 系统控制的硬件设备有哪些? 谁对本系统产生的结果感兴趣?

同一个系统由于用例的粒度不同,不同人会产生不同 的用例模型。
用例图—用例
用例的识别

参与者希望系统提供什Fra bibliotek功能?参与者是否会读取、创建、修改、删除、存储系统的 某种信息?如果是,参与者又是如何完成这些操作的?

参与者是否会将外部的某些事件通知给系统? 系统中发生的事件是否通知参与者? 是否存在影响系统的外部事件?

注意:
在用例图中,只能展示系统大的功能模块,对功能
的细节部分无法展示,如“每个学生可以选择不超 过4门课程,同时指定2门候选课程以备主选课程未 选上。每门课程最多不能超过10人,最少不能低于 3人,低于3人选课的课程将被取消”这样的细节可 以在用例图中为某个用例添加上“注释”。
建立用例模型案例2
参与者是用户相对系统而言所扮演的角色。 每个参与者可以参与一个或多个用例,每个用例也
可以有一个或多个参与者。
参与者不仅可以由人承担,还可以是其他系统、硬
件设备,甚至是时钟。

参与者虽然可以代表人或事物,但参与者不是指人或 事物本身,而是表示人或事物当时所扮演的角色。
用例图—参与者
参与者的确定:
确定用例:

与教师有关的用例

选择课程--选择所教的课程,并获得学生名册
登记成绩--在学期结束时,提交学生的课程成绩。

与学生有关的用例

注册课程--在学期开始进行选课注册,允许在一段时间内 更改或删除,课程目录系统提供当前学期的所有可选课程 列表
查看成绩单--学生可以查看以前学期的电子成绩单。
8. 打印存折,用例结束 后臵条件:在账户库中增加一个新账户,得到一张新存折
作 业

教材230页第10题。
作 业

教材230页第10题。
仓库管理员通过放在仓库
中的终端把零件入库/出 库事务报告给订货系统, 系统接收到事务信息后应 该处理事务;
采购员需要使用订货系统
提供的产生报表功能,以 获取订货报表。

者,箭头所指方 参与者——与系统交互的人或物。是向系统输入或系
统输出的对象。用一个小人图形表示。 是对话的被动接 受者。 用例——系统的一个功能。用椭圆表示。 用例和参与者之间的关系——用带箭头的线段来描述。
用例图—参与者

参与者(Actor)是指存在于系统外部并直接与系
统进行交互的实体。


与注册管理员有关的用例

维护课程信息--在系统中增加、修改和删除课程信息;
维护学生信息--在系统中增加、修改和删除学生信息; 维护教师信息--在系统中增加、修改和删除教师信息。
关闭注册--删除少于3人的课程,并由付费系统通知学生缴费。

与安全性要求有关的用例

登录--使用此系统的人员需要进行登录,以验证其身份和权限。

注意寻找参与者时不要只考虑使用计算机的人!
用例图—参与者

参与者间的关系
用例图—系统边界

系统边界是指系统与系统之间的界限。
系统与环境之间存在边界,子系统与
其他子系统之间存在边界,子系统与 整体系统之间也存在边界。 用例图中的系统边界用来表示正在建 模系统的边界,边界内表示系统的组 成部分,边界外表示系统的外部。

建立用例模型:银行账户管理系统需求陈述如下:
用例名称:开户 一个客户可以在多个银行中开设账户,一个客户也 参与者:银行职员(客户代理)、客户
前臵条件:一个合法的银行职员(客户代理)已登录到该系统 可在同一银行中开设多个不同的账户。客户可以通 事件流: 过银行职员进行开户、存款、取款、转账、注销账 1. 当选择开户功能时用例开始 2. 输入客户信息(姓名、地址、身份证号等) 户等活动。其中转账指客户将自己的某个账户上的 3. 从账户管理系统获取新的账号 钱转入同一银行的不同账户(称为银行内转账)或 4. 请客户输入密码 5. 请客户再次输入密码 转入不同银行的账户(称为银行间转账)。系统管 6. 如果两次密码不一致则回到第4步,否则继续 理员负责系统的账户管理及业务报表的生成。 7. 在账户库中添加新账户
用例图

用例图源于Jacobson的OOSE方法,它通过用例来 捕获系统的需求,再结合参与者进行系统功能需求 的分析和设计。
用例图由参与者、用例、系统边界和关联组成。
用例和参与者之间的对应关系称为通信关联 箭头表示在这一 (Communication Association)。 关系中哪一方是 使用用例图来描述系统,主要弄清楚三方面内容: 对话的主动发起
建立用例模型两种思路

1、找到每个Actor在系统中的功能,然后将所有 Actor的功能合并为一张用例图。 ——见案例1 2、将一个大系统划分为几个子系统,为每个子系 统分别建立用例图。 ——见案例2

建立用例模型案例1

详细用例建模过程举例:学生注册管理系统
识别参与者:

教师、学生、注册管理员、收费系统
软件工程导论
孙旭光
灾害信息工程系
功能模型

在面向对象方法学中,可以使用UML提供的用例 图进行需求分析和建立功能模型。
也把用用例图建立起来的系统模型称为用例模型。
使用用例模型代替传统的功能说明,能更好地获取
用户需求,它所回答的问题是“系统应该为每个用
户做什么”。
用例模型描述的是外部行为者所理解的系统功能。

总结

根据系统陈述建立模型过程中,很重要的一点 是要分析陈述中哪些是无用的信息,哪些是有用 的信息,哪些是可以合并的信息。
建立用例模型

练习:银行账户管理系统需求陈述如下:
一个客户可以在多个银行中开设账户,一个客户也
可在同一银行中开设多个不同的账户。客户可以通 过银行职员进行开户、存款、取款、转账、注销账 户等活动。其中转账指客户将自己的某个账户上的 钱转入同一银行的不同账户(称为银行内转账)或 转入不同银行的账户(称为银行间转账)。系统管 理员负责系统的账户管理及业务报表的生成。

详细用例建模过程举例:学生信息管理系统
识别参与者:

学生、教师、校领导、系统管理员
登录 登录 查询学生基本信息 找回密码登录 登录 录入学生基本信息 录入成绩 找回密码 找回密码 修改学生基本信息 创建新账号 修改成绩 查询课程信息 查看班级基本信息 删除学生基本信息 设臵账号 保存成绩 按课程编号查看 录入班级基本信息 找回密码 设臵账号基本信息 查询成绩 按课程名查看 修改班级基本信息 设臵账号权限 删除成绩 选择课程 删除班级基本信息 删除账号 删除已选课程 查看账号 维护课程信息
相关文档
最新文档