atm取款机内部结构图(2篇)
1.atm取款机内部结构图 篇一
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系统协作图
从图上我们可以看出协作图的角色和顺序图的对象是一一对应的,而协作图上的各对象上的协作关系和顺序图上的消息传递是一一对应的。
2.atm取款机内部结构图 篇二
1.项目背景及基本描述
ATM自动取款机系统作为银行信息化管理的一部分,已经相当普及了。相比传统的手工操作,大大提高了银行的工作效率,同时降低人力、财力、物力的浪费,使得取款,转账等一些银行的日常业务形成一种规范有序的流程,减少信息交流的烦琐过程及其带来的开销,实现银行管理的规范化、自动化。
2.用户分析
使用该系统的用户包括两类:管理员和客户。
管理员 :系统的超级用户,其对系统的操作包括开户、销户、修改密码。此类用户对计算机有一定的深入了解,对数据库的操作也有一定的基础,其亦可能是此类软件较熟悉的用户,这类用户有能力进行一些复杂的操作,比较数据备份,备份路径等。由于数据库保存着所有客户信息情况,在设计时对这类操作应尽量增加确认操作,以对话框的形式询问是否进行操作。
客户:系统的普通用户,其对系统的操作包括取款、存款、查询余额、转账、修改密码等。此类用户的计算机水平一般较低,系统对其操作的要求不应过高,比如菜单项就放在较为突出的地方,方便其操作,尽可能减少输入的数据与次数,避免因操作过多而出现的失误,同时相应菜单应设置带提示性的图标,提交后应弹出提示信息。
3.系统功能需求
ATM自动取款机系统相关的主要对象有:
用户:使用ATM自动取款机进行现金交易。进行取款、查询余额、设置密码、转账等操作。ATM系统:对用户的需求进行接收,通过与数据库的交互,根据对用户应用服务的响应,更新数据库中用户的信息。
银行数据库:对用户的所有信息进行存储更新。因此,可以把系统具体功能描述如下:
管理员:开户,销户,修改密码。
客户:取款,存款,查询余额,转账,修改密码。主要功能:
取款:用户按照系统输入要求输入取款金额即可取出相应金额的现金。查询余额:用户可以查看账户所剩现金余额。
修改密码:如果用户想要修改当前密码,通过系统可以设置新密码。
转账:用户可以通过该功能将自己账户上的金额转到其他账户
4.界面需求 4.1界面风格
用户界面统一设计,保证界面文字、颜色、图案等的一致性;符合美学标准。整洁、美观、错落有致。4.1.1文字
字体使用适当,一般两到三种为谊;使用清晰易读的文字。4.1.2 颜色
颜色使用适当;选择使用户长期使用不易疲劳的颜色,如灰色。遵循对比原则,深色背景使用浅色文字;浅色背景使用深色文字。4.1.3图案
图案的一致性、使用的恰当性、形象性、见图知意、大小合理。4.1.4界面布局
合理的界面布局,保证习惯,平衡,屏幕不能拥挤,屏幕总体覆盖度最好不要超过40%;而组合框中覆盖度不要超过62%(Mayhew 1992年试验结果)。
有效组合,在逻辑上关联的项目在屏幕上应当加以组合,以显示其关联性。反之任何项目之间毫不相关的项目应当分隔开。在项目集合间用间隔对其进行分组/或用方框也同样可做到这一点。
保持习惯,屏幕组织自上而下、自左而右。4.1.5区域排列
区域排列合理,排列整齐;一般的标签右对齐,编辑框左对齐。4.1.6数据对齐方式
数据对齐要恰当,字符左对齐,数字右对齐。
4.2 操作方式
操作方式遵循Microsoft标准。在没有鼠标的情况下应该保证用户可以方便使用软件;回车键具备Tab健功能;方向健功能可以使用;用直观,标准的快捷建;界面间切换方便;对用户不能访问的功能统一采用灰掉而不是移走;使用非破坏性的缺省按钮,对于保存、删除之类的按钮不用缺省按钮;在操作焦点处排列功能按钮;菜单/工具条设计合理,弹出菜单不应该是唯一功能;主要功能应放于工具条;菜单层次少于4层。
4.3交互信息
提示信息的一致性,措词适当;用清晰简单无二意的文字表述功能。
当程序运行时间较长时,用进度条给于提示。用状态栏提示当前操作。
4.4 输入
控制输入量,在输入时只输入基本信息,非基本信息应在系统中通过基本信息计算生成。
输入设计中应采用多种输入校验和有效性验证技术,尽量采用下拉选择框,让用户选择;减少输入错误。
避免额外步骤,在输入设计中应尽量避免不必要的输入步骤,当步骤不能省略时应仔细验证现有步骤是否完备、高效。
简化输入过程,不能因为校验而是输入复杂化。便于填写、便于归档、保证精度。
4.5 输出
对输出数据要保证精度。
输出尽可能采用多种形式,如声音、图像,各种图形 报表尽可能的满足用户的各种需要,最好能实现报表制定义。
5.小组成员
组长:**(23号)
组员:***(29号)***(51号)****(59号)
6.工作分配
***(23号):写开题报告及后期报告 **(23号):软件功能策划及后期工作 **(29号):界面设计 **(51号):界面设计 ***(59号):界面设计
7.项目进度计划安排
第3周~第4周:写需求分析报告 第4周~第5周:设计方案
第5周~第9周:设计