atm取款用例的顺序图

atm取款用例的顺序图（精选2篇）

atm取款用例的顺序图 第1篇

ATM（自动取款机）的用例图、类图、顺序图、状态图、活动图及协作图 用例图

参与者“银行储户”和ATM机。简化后的ATM机仅有取款、存款及其余功能。其余功能不做详细说明。

银行储户在ATM机上完成取款、存款及其他业务。类图

图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，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。

图2 银行系统类图 顺序图

图3描述了顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为仅是示例，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。

通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个“X”，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画“X”，表明这个对象在这时被销毁。

首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来…..因为这个顺序图较长，且很清晰，即便是初学者也很容易读懂，在此就不对本图做过多的解释。

图3 ATM取款顺序图状态图

图4描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。因为是简化了的例子，所以除了等待顾客插入磁卡的起始状态和结束服务的终止状态，顾客会处于输入密码、选择服务类型、存款及取款四种状态。

图4 ATM状态图

插入磁卡后进入输密码状态，当密码输入正确时进入选择服务类型状态，当输入密码不正确时，停留在原状态，但如果三次不正确，服务结束。进入选择服务类型后根据选择的不同，顾客可进入存款和取款状态。存、取款结束后，顾客既可以选择结束服务到最终状态，也可以选择继续服务回到选择服务类型状态。

通过状态图我们可以无歧义的了解各个活动角色是如何在不同状况下转换的，转换的条件是什么，是否会出现死锁现象，是否有条件没考虑周全，是否有状态无法达到。状态图可以帮助我们发现问题，并及时改正。活动图

图5参考了Randy Miller的《A Hands-On Introduction for Developers》一文，3图中的客户管理和事物管理对应于5图中的Bank，图3中的读卡机、显示、输入设备及点钞机对应于5图中的ATM Machina，银行储户就是Customer。初看活动图和顺序图表达的意义很接近。但我们可以注意到顺序图着重时间的顺序，而活动图侧重于各部分之间的相互制约，对于一些并行的活动能够有效的表示出来。例如5图中fork和join处，我们可以很清楚的看到一些并行活动的存在。

这个活动图以顾客插入卡为开始，以顾客取卡结束。我们可以看到活动图的重点虽然不在时间顺序，但我们同样可以得到时间的信息。

图5 ATM银行系统活动图 协作图

在第四章中我们知道协作图和顺序图是可以无信息损失的相互转换，只是它们的侧重点是不一样的。顺序图着重于对象间消息传递的时间顺序，协作图着重于表达对象之间的静态连接关系。图6将3图转换为协作图。

1．插入ATM卡

2．接受ATM卡

3．查询密码

4．显示输入密码请求

5．输入密码

6．密码传递

7．请求确认密码合法性

8．确认密码合法性

9．询问服务类别

10．显示输入服务服务类别请求

11．输入取款请求

12．取款请求 13．询问取款数额

14．显示输入数额请求

15．输入取款数额

16．传递取款数额

17．询问取款数额确认

18．显示确认数额请求

19．输入确认

20．传递确认信息

21．数额合法性确认请求

22．确认数额和法性

23．出钞请求

24．计算帐户余额

25．出钞

26．取钞

27．传递余额并询问是否还需要其他服务

28．显示帐户余额并提示选择下面的服务

图6 ATM系统协作图

从图上我们可以看出协作图的角色和顺序图的对象是一一对应的，而协作图上的各对象上的协作关系和顺序图上的消息传递是一一对应的。

atm取款用例的顺序图 第2篇

软件测试贯穿整个软件开发过程, 其目的在于降低软件的缺陷, 提高软件可靠性, 并满足客户的需求。软件测试可分为黑盒测试和白盒测试。黑盒测试认为任何程序可以看作从输入定义域取值映射到输出值域的函数, 它基于已描述的行为。白盒测试依靠程序, 它基于编程实现的行为。本文从黑盒测试方面来研究软件测试的技术和方法, 介绍运用因果图和判定表组合技术生成测试用例的方法, 并给出该方法在校园一卡通校车移动消费系统中的应用。

1 判定表测试技术 (DT)

判定表 (Decision Table) 是分析和表达多逻辑条件下执行不同操作情况的工具。它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确, 能够将复杂的问题按照各种可能的情况全部列举出来, 简明并避免遗漏。

1.1 判定表的组成

判定表通常由4个部分组成, 如图1所示。

条件桩:列出了问题的所有条件, 通常认为其次序无关紧要。

动作桩:列出了问题规定可能采取的操作, 这些操作的排列顺序没有约束。

条件项:列出针对条件的取值和在所有可能情况下的真假值。

具体项:列出在条件项的各种取值情况下应该采取的动作。

1.2 生成条件表的规则

(1) 规则:任何一个条件组合的特定取值及其要执行的相应操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。因此, 判定表中列出多少组条件取值, 也就有多少条规则, 即条件项和动作项会有多少列。

(2) 化简:就是把有两条或多条具有相同的动作、且其条件项之间存在着极为相似的关系规则合并。

1.3 判定表的建立步骤

(1) 确定规则的个数, 假如有n个条件, 每个条件有2个取值 (0, 1) , 则有2n种规则;

(2) 列出所有的条件项和动作项;

(3) 填入条件取值;

(4) 填入集体动作, 得到初始判定表;

(5) 简化, 合并相似规则 (相同动作) 。

2 因果图测试技术 (CEG)

因果图 (Cause-Effect Graph) 法利用图解法分析输入的各种情况设计测试用例, 它适合于检查各种程序输入条件的各种组合情况。在因果图中, 用Ci表示原因, Ei表示结果, 有4种符号分别表示了规格说明中4种因果关系, 如图2所示。

恒等:若原因出现, 则结果出现;若原因不出现, 则结果不出现。

非 (~) :若原因出现, 则结果不出现;若原因不出现, 则结果出现。

或 (∨) :若几个原因中有1个出现, 则结果出现;若几个原因都不出现, 则结果不出现。

与 (∧) :若几个原因都出现, 结果才出现;若其中有1个原因不出现, 则结果不出现。

3 因果图与判定表组合测试技术 (CEG-DT)

因果图描述程序中的输入/输出关系, 即因果关系, 而该关系的建立有各种组合情况, 这些组合情况如不能较好地组织, 容易遗漏测试用例。而判定表技术能将复杂的问题组合全部列举出来, 这可以较好解决因果图的设计缺陷, 从而使各种可能的测试用例均被设计到测试用例表中, 实现较好的测试。

因果图与判定表组合生成测试用例的基本步骤如下:

(1) 分析软件规格说明中的因果 (因为输入条件, 果为输出条件) ;

(2) 分析软件规格说明中的语义, 找出因果之间的对应关系, 并画出因果图;

(3) 标明约束条件;

(4) 将因果图转换成判定表;

(5) 为判定表中的每一列设计测试用例。

4 CEG-DT技术的应用

下面以本文作者开发的校园一卡通校车移动消费系统中的乘车刷卡消费程序为例, 说明该方法的应用。

用户在乘车刷卡消费时读卡器就绪后, 不断在感应区感应卡片, 当感应到卡片并读卡后, 则读取卡片标识, 是否为乘车注销卡, 或是否为开通乘车服务的卡片。如为注销卡, 则显示“注销卡”并发报警音;如为开通乘车服务的卡, 则读取卡余额;如卡余额不足, 则显示“余额不足”并发一声滴音;如卡余额足够, 则写卡扣款。

上述为软件规格说明书中的描述, 根据该描述, 分析可得出其原因和结果:

(1) 原因: (1) 感应到卡片; (2) 没有感应到卡片; (3) 卡标识为注销卡; (4) 卡标识为开通乘车服务卡; (5) 卡余额不足; (6) 卡余额足够。

(2) 结果:E11没有卡片, 继续感应;E12有卡片, 读卡标识;E23显示“注销卡”, 报警音;E24读卡余额;E35显示余额不足, 发滴音;E36写卡扣款。

根据原因和结果, 可以设计一个因果图, 如图3所示。

将因果图转换为判定表, 如表1所示, 每一列可作为确定测试用例的依据。

根据判定表, 由于有6种条件, 所有的组合情况应为26=64种, 但本例中可合并很多相似 (相同动作) 情况, 即 (1) (2) 只有一种为真, 当同时取假时表示读卡器为未就绪 (规则1) ; (3) (4) 只有当 (2) 为真时有效, 且只有一种为真, 同时取假时表示即非注销卡也非乘车卡 (规则3) ; (5) (6) 只有当 (2) 和 (4) 同为真时有效, 同时取假表示卡余额数据区损坏, 读不到数据 (规则5) 。

5 结束语

因果图法能较好地解决黑盒测试中的各种情况的因果关系, 但在输入条件的组合上却存在不足;判定表可以解决各种输入条件的组合关系, 但在解决各条件的内在关系时具有缺陷。将二者结合使用可以很好地生成测试用例解决, 使测试覆盖率最大化, 提高程序缺陷发现率, 从而提高软件质量可靠性。

本文讨论的校车移动消费系统中所采用的因果图与判定表组合技术较好地实现了项目中的黑盒测试, 达到了较为理想的效果。

参考文献

[1]Paul C.Jorgensen.Software testing A Craftsman's Approach[M].CRC Press LLC, 2000.

[2]佟伟光.软件测试[M].北京:人民邮电出版社, 2008.