银行用例及用例图
02-用例和用例图
3.4.4 几种关系的比较
关系类型
说明
表示符号
关联
actor与use case之间
泛化
actor之间或use case之间
包含
use case之间
扩展
use case之间
用例图
用例图(use case diagram)是显示一组用例、角色以及它 们之间的关系的图.
在UML中, 一个用例模型若干个用例图描述.
角色
由于Actor实际上是一个特殊类, 因此它们之间可以 存在一定的关系,如：
脚本/场景
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况.
其它译名: 情景、情节、剧本.
每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
实例分析：语音邮箱系统----用例脚本
用例3: 登录系统 1. 邮箱用户完成邮箱号输入操作. 2. 邮箱用户键入密码并后跟#键.(默认号码与邮箱号相同) 3. 语音邮件系统播放邮箱菜单: 按1键接收信息. 按2键更改密码. 按3键更改问候语.
实例分析：语音邮箱系统----用例脚本
用例4: 接收信息 1. 邮箱用户完成登录操作. 2. 邮箱用户选择 “接收信息”菜单选项. 3. 语音邮件系统播放信息菜单: 按1收听当前信息; 按2存储当前信息; 按3删除当前信息; 按4返回邮箱菜单. 4. 邮箱用户选择“收听当前信息”菜单选项. 5. 语音邮件系统播放当前新信息,若无新信息,播放当前已有信 息.(注意: 只播放,不删除) 6. 语音邮件系统播放信息菜单. 7. 用户选择”删除当前信息”,则信息被永久删除. 8. 继续执行第3步.
uml银行用例图解析
用例描述：开户用例图中，由管理员发起开户事务，储户提供账户信息、身份信息，管理员验证账户合法性和身份真实性后输入账户信息，储户设置密码，过程中涉及验证合法性（账户号正确、身份真实等）、添加账户信息等。
储户可以打印凭证。
ii. 销户MM用例描述：销户用例图中，主动销户由管理员发起销户事务，储户提供账户信息、身份信息, 输入密码，管理员验证密码正确身份真实性后输入账户信息，并验证账户余额，若有余额则返还给储户完成销户，若无余额直接完成销户。
过程中涉及验证合法性（密码正确、身份真实等）、处理余额、删除账户信息等。
储户可以打印凭证。
被动销户则需要进行销户判断（挂失子系统），若判断可以销户，则处理余额，完成销户。
iii. 冻结«ejdend»'、、O用例描述：冻结用例图中，主动冻结由管理员发起冻结事务，储户提供账户信息、身份信息,管理员验证密码正确身份真实性后输入账户信息，完成冻结。
过程中涉及验证正确性（密码正确、身份真实等）、修改账户状态信息等。
储户可以打印凭证。
被动冻结则需要进行冻结判断，若输 入密码大于三次，账户冻结。
iv. 挂失X用例描述：挂失用例图中，管理员需要用户输入账户信息，可以触发挂失事务，其中挂失事务包括生成挂失信息，获取余额信息以及销户触发判断，判断是否挂失一定时间，自动触发销户。
V.存款用例描述：存款用例图中，管理员需要用户输入账户信息，或者打印存款信息才可以触发存款事务，其中存款事务包括修改余额信息以及生成存款信息两个功能。
vi. 取款用例描述：取款用例图中，管理员需要用户输入账户信息，以及账户密码，经过余额验证才可以触发取款事务，其中取款事务包括修改余额信息以及生成取款信息打印凭证两个功能。
vii. 转账偲改余额用例描述：转账用例图中，由管理员发起转账事务，输入转账信息，其次储户通过验证账户密码可以完成转账，过程中涉及计算手续费、验证合法性（如余额足够、账户号正确等）、修改账户余额、生成转账信息等。
ATM系统UML 7种图
UML建模语言7种图(以银行ATM系统为例)分类：JAVA2010-04-21 20:40 2911人阅读评论(0) 收藏举报uml语言活动作业优化1 用例图：描述了系统提供的一个功能单元。
以一种可视化的方式理解系统的功能需求，"角色"与系统内用例之间的关系。
本例中，参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
2 类图：显示系统的静态结构。
逻辑类、实现类，实现类就是程序员处理的实体。
类在类图上使用包含三个部分的矩形来描述，如图2所示。
最上面的部分显示类的名称，中间部分包含类的属性，最下面的部分包含类的操作（或者说"方法"）。
本例中许多单个的帐户组成了帐户库，帐户具有帐户类型、帐户号、余额三个属性。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮助自己整理思路，充实及优化自己的设计。
3 序列图：显示具体用例（或者是用例的一部分）的详细流程。
它几乎是自描述的，并且显示了流程中中不同对象之间的调用关系，同时还可以很详细地显示对不同对象的不同调用。
序列图有两个维度：垂直维度以发生的时间顺序显示消息/调用的序列；水平维度显示消息被发送到的对象实例。
本例以时间为顺序描述了顾客在ATM机上取款时信息的流动情况，顺序图着重于对象间消息传递的时间顺序。
4 状态图：表示某个类所处的不同状态和该类的状态转换信息。
包括5个基本元素：初始起点，它使用实心圆来绘制；状态之间的转换，它使用具有开箭头的线段来绘制；状态，它使用圆角矩形来绘制；判断点，它使用空心圆来绘制；以及一个或者多个终止点，它们使用内部包含实心圆的圆来绘制。
本例描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。
银行用例
一：处理存款用例1：用例名：存款2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：存储存款信息，更新信息，生成票据8：主事件流：（1）：客户领取排队号码牌（2）：填取存款单（3）：带卡或存折，则排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统（5）：银行职员扫描银行卡信息到存款界面（6）：客户输入密码进行银行卡认证（7）：客户向银行职员递交所存现金（8）：银行职员确认存款信息并向客户确认（9）：银行系统保存存款信息（10）：生成存款信息并打印，客户签字确认9：备用事件流（1）：客户所带证件不齐全（2）：客户忘记密码二：处理取款用例1：用例名：取款2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：存储存款信息，更新信息，生成票据8：主事件流（1）：客户领取排队号码牌（2）：填取取款单（3）：带卡或存折，则排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统（5）：银行职员扫描银行卡信息到存款界面（6）：客户输入密码进行银行卡认证（7）：银行职员向客户确认取款金额（8）：银行职员提取现金给客户（9）：保存信息并打印，客户签字确认9：备用事件流（10）：客户所带证件不齐全（11）：客户忘记密码三：处理贷款用例1：用例名：贷款2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：贷款人（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：存储存款信息，更新信息，生成票据8：主事件流（1）：贷款人向银行提出借款申请（2）：银行对贷款人的信用等级进行评估（3）：银行对贷款人的合法性、安全性、盈利性进行调查（4）：银行按审贷分离、分级审批的贷款管理制度进行贷款审批（5）：银行与贷款人签订贷款合同（6）：银行职员登录到贷款界面（7）：银行职员录入贷款人信息（8）：保存贷款信息（9）：银行按贷款合同规定按期发放贷款（10）：银行对贷款人执行贷款合同情况及贷款人经营情况进行追踪和检查（11）9:备用事件流（12）：未达到贷款条件（13）：相关手续不齐全四：处理银行卡开户用例1：用例名：银行卡开户2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：在账户库中增加了一个新账户，得到一张新存折8：银行卡开户主事件流（1）：客户领取排队号码牌（2）：填取开户申请单（3）：排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统中的开户界面（5）：输入客户信息（姓名、地址、身份证号）（6）：银行职员取出一张新的银行卡并进行激活（7）：客户输入密码（8）：客户再次输入密码进行确认（9）：如果两次输入密码不一致，则返回第七步（10：银行系统保存客户信息（11）：银行职员向客户交还银行卡9:备用事件流（1）：相关手续不齐全五：处理存折开户用例1：用例名：存折开户2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：在账户库中增加了一个新账户，得到一张新存折8：银行卡开户主事件流（1）：客户领取排队号码牌（2）：填取开户申请单（3）：排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统中的开户界面（5）：输入客户信息（姓名、地址、身份证号）（6）：从账户管理系统获取新的账户（7）：客户输入密码（8）：客户再次输入密码进行确认（9）；如果两次输入密码不一致，则返回第七步（9）：在账户库中添加新账户（10）：打印存折（10）：银行职员向客户交还银行卡9:备用事件流（1）：相关手续不齐全六：处理用户挂失用例1：用例名：用户挂失2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：该银行卡暂时不能使用，但是账户信息依旧保存8：主事件流：（1）：客户领取排队号码牌（2）：填取挂失单（3）：排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统（5）：银行职员打开用户挂失界面（6）：银行职员选择要挂失的银行卡（7）：银行职员对客户进行身份验证（8）：银行职员向客户确认确认要挂失的银行卡（9）：银行系统保存挂失信息9：备用事件流（1）：客户所带证件不齐全（2）：手机号码变更过（3）：挂失所在地与开户所在地不同七：处理用户注销用例1：用例名：用户注销2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：该银行卡失效并且删除银行卡信息8：主事件流：（3）：客户领取排队号码牌（4）：填取注销单（3）：排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统（5）：银行职员打开用户注销界面（6）：银行职员选择要注销的银行账户（7）：系统检索并显示该用户详细资料（8）：系统管理员确认删除（9）：系统删除该用户信息9：备用事件流（1）：客户所带证件不齐全（2）：注销所在地与开户所在地不同八：处理用户修改密码用例1：用例名：用户修改密码2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：用户修改原来密码，账户信息不变8：主事件流：（1）：客户领取排队号码牌（2）：填取密码修改单（3）：排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统（5）：银行职员打开用户密码修改界面（6）：银行职员选择要修改的银行账户（7）：对客户进行身份验证（8）：客户输入原密码（9）：客户输入新密码（10）：客户确认新密码（11）：系统保存该用户的新信息，替换旧信息9：备用事件流（1）：客户所带证件不齐全（2）：忘记原密码。
ATM用例图 用例规约 时序图
ATM吞卡，[用例失败]
扩展点：
[待定]
非功能需求：
ATM响应客户时间不超过15秒
业务规则：
7b单日取款不得超过5000元
6c每次取款不得超过2000元
取款顺序图
基本流
备选流
密码错备选流
[用例结束]
备选流：
3-7，10a.客户取消服务：
ATM记录服务取消，打印凭条，吐出凭条和银行卡，[用例失败]
3,6,11a.客户未及时输入超过30秒：
ATM吞卡，[用例失败]
2a.卡无效：
ATM吞卡，[用例失败]
2b.读卡器或卡被损坏：
ATM吞卡，[用例失败]
4a.密码错：
4a1.客户重新输入密码
6.输入取款额：客户输入数量为50元的倍数的取款额。
7.ATM向银行主机通知卡号、密码、账号和取款额，获得含有最新余额的取款成功确认信息。
8.ATM打印并吐出凭条。
9.ATM清点并吐出现金，记录取款成功。
10.ATM询问客户是否继续服务。
11.客户选择否，ATM吐出银行卡，结束用例，否则回到步骤5。
系统用例规约：ATM取款
用例名称：
ATM取款
描述：
客户持银行卡（本行或其他行）从ATM提取现金
actors:
客户和银行主机
前置条件：
无
基本流：
1.客户插入银行卡。
2.ATM从银行卡读入卡号（含银行标识和账号），验证卡的有效性。
3.客户输入密码。
4.ATM验证帐号和密码。
5.ATM显示包括取款在内的服务功能，客户选择“取款”。
UML业务建模实例分析四例
UML业务建模实例分析在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。
我们在日常生活中也经常和ATM打交道。
本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
图5.1 自动取款机（ATM）系统用例图银行储户在ATM机上完成取款、存款及其他业务。
图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。
帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。
六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。
getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。
getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。
getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
ATM用例图_用例规约_时序图[]
![ATM用例图_用例规约_时序图[]](https://img.taocdn.com/s3/m/e841b606e45c3b3567ec8b7f.png)
ATM用例图_用例规约_时序图[]————————————————————————————————作者：————————————————————————————————日期：ATM 系统用例图存款取款查询转账客户银行主机改密码用例包括：1） 存款：客户持银行卡（本行或其他行）从ATM 存放现金 2） 取款：客户持银行卡（本行或其他行）从ATM 提取现金3） 查询：客户持银行卡（本行或其他行）在ATM 上查询卡的帐户信息 4） 转账：客户持银行卡（本行）在ATM 上进行同行转账5） 改密码：客户持银行卡（本行或其他行）在ATM 修改卡的密码系统用例规约：ATM取款用例名称：ATM取款描述：客户持银行卡（本行或其他行）从ATM提取现金actors: 客户和银行主机前置条件：无基本流： 1.客户插入银行卡。
2.ATM从银行卡读入卡号（含银行标识和账号），验证卡的有效性。
3.客户输入密码。
4.ATM验证帐号和密码。
5.ATM显示包括取款在内的服务功能，客户选择“取款”。
6.输入取款额：客户输入数量为50元的倍数的取款额。
7.ATM向银行主机通知卡号、密码、账号和取款额，获得含有最新余额的取款成功确认信息。
8.ATM打印并吐出凭条。
9.ATM清点并吐出现金，记录取款成功。
10.ATM询问客户是否继续服务。
11.客户选择否，ATM吐出银行卡，结束用例，否则回到步骤5。
[用例结束]备选流：3-7，10a. 客户取消服务：ATM记录服务取消，打印凭条，吐出凭条和银行卡，[用例失败] 3,6,11a. 客户未及时输入超过30秒：ATM吞卡，[用例失败]2a. 卡无效：ATM吞卡，[用例失败]2b. 读卡器或卡被损坏：ATM吞卡，[用例失败]4a. 密码错：4a1. 客户重新输入密码a.累计3次密码错误：ATM吞卡，[用例失败]4b. 无此帐号：ATM吞卡，[用例失败]5a. ATM无现金：ATM不显示“取款”功能，客户可选择其他服务，[用例失败] 6a. 取款额超过ATM现金余额：ATM要求客户重新输入取款额。
ATM(自动取款机)的用例图
ATM（自动取款机）的用例图、类图、顺序图、状态图、活动图及协作图1 用例图参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
2 类图图2所示的银行系统类图和图5是类似的，只是将工作人员换成了ATM。
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。
帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。
六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。
getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。
getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。
getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM 机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。
同样对于一个真正的银行系统，这个类图过于简单。
比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。
UML银行系统
银行系统
学号：
姓名：
专业：
银行职员用例图
客户用例图
系统类图
银行职员登录系统序列图
银行职员登录系统协作图
客户存款序列图
客户存款协作图
客户取款序列图
客户取款协作图
客户本行转账序列图
客户本行转账协作图
客户跨行转账序列图
客户跨行转账协作图
客户开立新账户序列图
客户开立新账户协作图
客户删除账户的序列图
客户删除账户的协作图
客户修改账户信息序列图
客户修改账户信息协作图
账户状态图
银行职员登录系统活动图
客户存款活动图
客户取款活动图
客户转账活动图
创建账户的活动图
客户修改账户活动图
基本业务构件图
系统部署图。
案例1--银行储蓄账户管理系统用例
输入客户信息 ［选择重新输入］ 选择重新输入］ ［不一致］ 不一致］ 显示 错误信息 显示 冻结信息
● · ·
8/260
描 述 取 款 用 例 的 活 动 图
［一致］ 一致］ 冻结］ ［冻结］ ［未冻结］ 未冻结］ 输入并校验密码
［选择结束］ 选择结束］
输入取款金额 ［余额＜取款额］ 余额＜取款额］ 取款额］ ［余额≥取款额］ 余额 取款额 打印取款单 ［客户不确认］ 客户不确认］ ［客户确认］ 客户确认］ 建立取款记录 更新账户信息 打印存折
6/8
取款用例描述 用例名称：取款 参与的执行者：银行职员（客户代理） 前置条件：一合法的银行职员(客户代理)已登录到该系统 事件流： 基本路径： 1.当选择取款功能时用例开始 2.当输入客户信息（姓名、账号等）后 a）如果客户信息与账户不一致，显示错误信息，可以 重新输入或结束用例 b）如果该账户被冻结（如因挂失而冻结），显示冻结 信息并结束用例 3.输入并校验密码
4/260
开户 存款 取款 银行职员 用户代理） （用户代理） 注销 转账 银行内转账 银行职员 管理人员） （管理人员） 账户管 理 报表生 成 系统管理员
《包含》 包含》 《包含》 包含》 《包含》 包含》
客户 校验密码
银行间转账 其它银行 账户管理系统
银行储蓄账户管理系统
5/8
开户用例描述 用例名称：开户 参与的执行者：银行职员（客户代理），客户 前置条件：一合法的银行职员（客户代理）已登录到该系统 事件流： 1.当选择开户功能时用例开始 2.输入客户信息（姓名、地址、身份证号等） 3.从账户管理系统获取新的账号 4.请客户输入密码 5.请客户再次输入密码 6.如果两次密码不一致则回到第4步，否则继续 7.在账户库中添加新账户 8.打印存折，用例结束 后置条件：在账户库中增加了一个新账户，得到一张新存折
银行用例及用例图
4.4 用例图
1. 用例图的作用
用例图用来描述软件需求模型中的系统功能, 通过一组用例可以描述软件系统能够给用户提 供的功能.
用例图可以作为整个系统开发过程中的开发依 据,指导和驱动其他模型.
2. 用例图的形式
取款用例描述实例
● 用例：取款 ●参与者：储户 ●操作流：
① 通过读卡机,储户插入ATM卡 ② ATM系统从卡上读取银行ID、帐号、并验证帐号. ③ 储户键入密码,系统检验密码. ④储户按确认键,输入取款金额. ⑤ATM把帐号和取款金额传递给银行系统,取回确认信息 和帐户余额. ⑥ ATM输出现金,并显示帐户余额. ⑦ATM记录事务到日志文件.
① 管理员选择进入管理界面,用例开始. ② 系统提示输入管理员密码. ③ 管理员输入密码. ④ 系统检验密码.
A1：密码出错. ⑤ 进入管理界面,系统显示当前所建立的全部课程信息. ⑥ 管理员选择增加课程,管理员输入新课程信息. ⑦系统验证是否与已有课程冲突.
Ａ２：有冲突. ⑧系统填写新课程,并提示填写成功. ⑨系统回到管理主界面,显示所有课程,用例结束.
用例及用例图
张鲲
用例及用例图
4.1 用例 4.2 参与者 4.3 用例之间的关系 4.4 用例图 4.5 发现用例
4.1 用例
1. 用例的概念 用例use case: 表示参与者与系统的一次交互过程.
2.用例的表示 用例用椭圆表示
3. 用例的特点 ① 用例用于描述系统的功能,这个功能是外部
使用者看到的系统功能,不反映功能的实现方式.
● ⑥ 编制用例说明.
● 用例：退房结帐 ●参与者：柜台工作人员 ●说明：
① 工作人员启动退房结帐功能. ② 输入旅客标志信息. ③ 系统显示旅客入住信息. ④ 显示入住天数,费用. ⑤ 接收费用. ⑥ 打印发票. ⑦ 入住登记结束.
uml银行用例图
一、面向对象分析1. 建立用例模型i. 开户用例描述：开户用例图中，由管理员发起开户事务，储户提供账户信息、身份信息，管理员验证账户合法性和身份真实性后输入账户信息，储户设置密码，过程中涉及验证合法性（账户号正确、身份真实等）、添加账户信息等。
储户可以打印凭证。
ii. 销户用例描述：销户用例图中，主动销户由管理员发起销户事务，储户提供账户信息、身份信息，输入密码，管理员验证密码正确身份真实性后输入账户信息，并验证账户余额，若有余额则返还给储户完成销户，若无余额直接完成销户。
过程中涉及验证合法性（密码正确、身份真实等）、处理余额、删除账户信息等。
储户可以打印凭证。
被动销户则需要进行销户判断（挂失子系统），若判断可以销户，则处理余额，完成销户。
iii. 冻结用例描述：冻结用例图中，主动冻结由管理员发起冻结事务，储户提供账户信息、身份信息，管理员验证密码正确身份真实性后输入账户信息，完成冻结。
过程中涉及验证正确性（密码正确、身份真实等）、修改账户状态信息等。
储户可以打印凭证。
被动冻结则需要进行冻结判断，若输入密码大于三次，账户冻结。
iv. 挂失用例描述：挂失用例图中，管理员需要用户输入账户信息，可以触发挂失事务，其中挂失事务包括生成挂失信息，获取余额信息以及销户触发判断，判断是否挂失一定时间，自动触发销户。
v. 存款用例描述：存款用例图中，管理员需要用户输入账户信息，或者打印存款信息才可以触发存款事务，其中存款事务包括修改余额信息以及生成存款信息两个功能。
vi. 取款用例描述：取款用例图中，管理员需要用户输入账户信息，以及账户密码，经过余额验证才可以触发取款事务，其中取款事务包括修改余额信息以及生成取款信息打印凭证两个功能。
vii. 转账用例描述：转账用例图中，由管理员发起转账事务，输入转账信息，其次储户通过验证账户密码可以完成转账，过程中涉及计算手续费、验证合法性（如余额足够、账户号正确等）、修改账户余额、生成转账信息等。
银行系统用例图
实验一：Rose工具的使用
一、实验目的：
熟悉和掌握Rose工具的基本使用.。
二、实验内容：
可视化建模
Rose：优秀的可视化建模工具
Rational Rose工具简介
Rose应用程序界面
Rose模型
Rose视图
三、实验用设备仪器及材料：
PC Rose工具
四、实验方法及步骤：
1、操作模型元素
a)创建一个模型元素
i.利用快捷菜单创建模型元素
1.右单击新模型元素所属的父元素（可以是视图、模型图、包等），从快捷
菜单中选择New
2.在New下拉菜单栏中选择相应的模型元素选项
ii.运用拖放功能
1.注意源位置的标识
“from …”
B)删除模型元素
从浏览器中删除一个模型元素，将把该模型元素从模型中永久删除，同时还将删除该元素的关系
可以一次删除多个模型元素
按下Ctrl或者Shift键选取要删除的多个模型元素
C)命名模型元素
直接在浏览器中输入模型元素的名称
注意多元素同名的命名错误
五、实验结果分析
打开Rose工具，右单击新模型元素所属的父元素视图，从快捷菜单中选择New，在New 下拉菜单栏中选择main模型元素选项,自定义工具箱，添加要用到的工具，构建视图。
UML案例--银行系统
（2）银行职员将相关信息输入后提 交，系统判断账户是否存在且有效，账 户中的金额是否大于转账金额。
（3）如果账户有效并存在同时金额 足够，建立交易记录，同时修改账户金 额，保存交易记录。
（4）判断转入账户是否属于同一银 行。如是同一银行，系统先确认转入账 户是否存在并有效。如有效更新账户相 关信息，建立转账记录，保存转账记录。 （5）如果转入和转出账户不是同一银
UML统一建模语言
三、创建系统动态模型
1、银行职员登录银行系统的序列图 和交互图
银行职员登录银行系统 用例的工作流程：
（1）银行职员想通过系 统进行某一项操作。
（2）银行职员启动系统， 在登录页面LoginFrame输入 自己的用户名和密码并提交。
（3）系统验证银行职员 的用户名和密码是否正确， 如正确创建系统主界面。
UML统一建模语言
二、创建系统用例模型
银行职员用例能够通过 该系统进行如下活动：
（1）登录银行系统。银 行职员在登录系统时，必须 通过系统的身份验证才能进 入银行系统主界面进行下一 步的操作。
（2）对客户的账户进行 管理，包括为客户创建新的 账户、修改账户信息和删除 账户。
UML统一建模语言
二、创建系统用例模型
（4）银行职员修改账户信 息后，提交给账户界面。
（5）账户界面发送消息更 新数据库中客户的信息，同时 更新账户信息。
8、客户修改账户信息序列图和协作图
UML统一建模语言
三、创建系统动态模型 9、银行账户状态图
在银行系统中，有明确状态转换的类是账户。账户包含以下 三种状态：被创建的新账户、被修改后账户、睡眠账户和被删除 的账户。它们之间的转化规则是：
ATM用例描述及用例分析
问题描述：•银行有很多ATM机分布在城市的各个地方，并通过广域网与中心服务器相连；•每台ATM机都有读卡器、出钞机、键盘、显示器和收据打印机；•顾客可以通过ATM机从自已的银行帐户中取现金、查询余额、转帐；•顾客把ATM卡扦入读卡器就启动一个事务.在卡背面磁条中保存有ATM卡号、启用日期和截止日期，读卡器识别出卡后，系统将确认ATM卡是否过期;然后用户输入个人密码并和系统保存的个人密码匹配比较以检验是否正确或因挂失而禁用。
输入密码时最多可以尝试三次,连续三次输入关败， ATM卡将被没收，若ATM卡已挂失,也会被没收；•如果用户输入个人密码通过确认，ATM将提示客户可做取款、查询余额、转帐选择。
在开始取款前，系统要检查客户帐户是否有足够的钱，是否超过每天最高取款限额、出钞机是否有足够的现金；如果此事务可行,出钞机将按客户的要求的数额出钞、打印收据并退还ATM卡;任何时侯客户都可能取消事务，事务一旦终止，卡就被退出；客户记录、帐户记录都将保存在服务器中。
•为了给ATM机的出钞机装入现金以及进行日常维护，操作员可以启动或关闭ATM机。
UML ATM机结构类图UML表达的问题域的概念静态模型—实体类UML表达的 ATM机用例图《软件需求规格说明书》用例描述验证客户路经活动图UML表达的验证客户用例交互顺序图验证客户用例交互矩阵—类封装顺序图作用:1．作为交互分析的工具和方法；2．识别出用例中的类；3．分析交互的时间顺序;4．分析交互消息；5．进行类操作（消息）封装,与类的职责进行验证；《软件需求规格说明书》用例描述UML表达的取款用例交互顺序图ATM状态图实体类封装验证矩阵用例描述检查点检查标准：1．用例粒度是否符合用户的价值观点?2．是否按4W+DO模式书写用例描述?什么人(Who)在什么时间（When)和地点（Where)因为何种原因(Why）依据什么信息实体做(Do）什么事情以及做事情的条件、约束、规则、算法和结果；3．备选动作序列是否符合业务需求?4．用例描述其余属性是否一致和完整？11/ 11。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
总结 用例的特点
① 用例用于描述系统的功能，这个功能是外部 使用者看到的系统功能，不反映功能的实现方 式。 ② 用例描述用户提出的一些可见需求，对应一 个具体的用户目标。 ③ 用例反映系统与用户的一次交互过程，应该 具有交互的信息的传递。 ④ 用例是对系统功能的描述，属于需求建模。
4.2 参与者
4.5 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ● ④ 确定各用例之间的关系(泛化，包含，扩展)。
4.5 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ● ⑤ 绘制用例图。
管理员： 增加课程 修改课程 删除课程
学生： 查询课程 选择课程 网上付费
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
● ④ 确定各用例之间的关系(泛化，包含，扩展)。
● ⑤ 绘制用例图。
● ⑥ 编制用例说明。
● 用例：增加课程 ●参与者：管理员 ●操作流：
4.5 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ⑤ 绘制用例图。 ● ⑥ 编制用例说明。
4.5 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ⑤ 绘制用例图。 ⑥ 编制用例说明。 ● ⑦ 对异常流程确定单独用例。
4.5 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ⑤ 绘制用例图。 ⑥ 编制用例说明。 ⑦ 对异常流程确定单独用例。 ● ⑧ 优化用例图，解决用例之间的冲突和重复。
4.5 发现用例
发现用例的一般方法：
● ① 找出系统外部参与者，确定系统边界和范围。
4.5 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ● ② 确定各参与者所期望的系统行为。
4.5 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
4.3 用例之间的关系
用例之间可以具有以下几种关系： ①. 关联关系 ②. 泛化关系 ③. 包含关系 ④. 扩展关系
1. 关联关系
参与者与用例之间是关联关系，表示参与者与 用例之间具有使用，交互信息的关联。
2. 泛化关系
参与者与参与者之间，用例与用例之间存在一 般与特殊的关系。
3. 包含关系
用例图用来描述软件需求模型中的系统功能， 通过一组用例可以描述软件系统能够给用户提 供的功能。
用例图可以作为整个系统开发过程中的开发依 据，指导和驱动其他模型。
2. 用例图的形式
取款用例描述实例
●ห้องสมุดไป่ตู้用例：取款 ●参与者：储户 ●操作流：
① 通过读卡机，储户插入ATM卡 ② ATM系统从卡上读取银行ID、帐号、并验证帐号。 ③ 储户键入密码，系统检验密码。 ④储户按确认键，输入取款金额。 ⑤ATM把帐号和取款金额传递给银行系统，取回确认信 息和帐户余额。 ⑥ ATM输出现金，并显示帐户余额。 ⑦ATM记录事务到日志文件。
1. 参与者的概念 参与者（actor）是外部需要与系统交互的事
物。也被称为活动者。 2.参与者的三种类型
①. 人：客户，读者，库管员 ②. 设备：计算机，磁盘，读卡机等 ③. 外部系统：上层系统等
3. 参与者的表示 参与者可以表示为下面三种形式。
4. 参与者之间的关系 参与者之间可以有泛化关系。
案例1：
某学校网上选课系统的用例分析
管理员通过系统管理界面进入系统，建立本学 期要开设的各种课程，将课程信息保存到系统中， 并可以对课程进行改动和删除。 学生通过客户机浏览器进入系统，选择课程：可 以查询课程，选择课程，支付课程费用。
● ① 找出系统外部参与者，确定系统边界和范围。
● ② 确定各参与者所期望的系统行为。
取款
3. 用例的特点 ④ 用例是对系统功能的描述，属于需求建模。
取款 用例的动态事件流
a 通过读卡机，储户插入ATM卡
b ATM系统从卡上读取银行ID、帐号、并验证帐号。 c 储户键入密码，系统检验密码。 d 储户按确认键，输入取款金额。 e ATM把帐号和取款金额传递给银行系统，取回帐户余额。 f ATM输出现金，并显示帐户余额。 d ATM记录事务到日志文件。
用例及用例图
张鲲
用例及用例图
4.1 用例 4.2 参与者 4.3 用例之间的关系 4.4 用例图 4.5 发现用例
4.1 用例
1. 用例的概念 用例(use case): 表示参与者与系统的一次交互过程。
2.用例的表示 用例用椭圆表示
3. 用例的特点
① 用例用于描述系统的功能，这个功能是外
部使用者看到的系统功能，不反映功能的实现
两个用例之间，一个用例(基本用例)的行为包 含了另外一个用例(包含用例)的行为。 包含关系用依赖关系的<<include>>构造型 来表示。
4. 扩展关系
扩展关系表示基本用例在扩展点要增加新的行 为或功能，以扩展到新用例。
扩展关系用依赖关系的<<extend>>构造型来 表示。
4.4 用例图
1. 用例图的作用
方式。
储蓄系统
√ 开户 √ 存款 √ 取款 √ 转帐
3. 用例的特点 ② 用例描述用户提出的一些可见需求，对应一 个具体的用户目标。
储蓄系统
√ 开户 √ 存款 √ 取款 √ 转帐
× 数据上传
3. 用例的特点
③ 用例反映系统与用户的一次交互过程，应 该具有交互的信息的传递。
帐户，密码，金额数 确认信息，帐户余额