
1.1目的
随着微电子技术、计算机技术和网络通信技术的发展,嵌入式系统已广泛应用在各个领域,包括消费电子、汽车电子、网络通信、工业设备、航空航天和国防军事等。
伴随着计算机技术在各行各业日益广泛和深入的应用,网络的概念早已深入人心。网络在各行各业的发展战略中占据了重要的位置,成为不可分割的部分。随着Internet的蓬勃发展,ATM网上银行取款作为电子商务的一种形式正以方便、快捷的优势,逐步成为新兴的经营模式和理念,人们已经不再满足于排队等待业务,而是渴望着能够充分享受网络所带来的更加多的便利。ATM银行取款系统正适应了当今社会快节奏地生活,使顾客足不出户便可以方便快捷轻松地实物银行所能办理的各种业务,大大节约了时间,实物银行所需的人力,物力,财力等。
本平台旨在利用现在比较广泛的JSP+SQL SERVER2000数据库的架构实现的,进行系统分析,为将来进一步的实施打下一个坚实的技术基础。从而实现信息化,规范化,系统化,网络化的平台,具有较好的适应性和推广性。此系统ATM银行取款管理。它是友好的操作界面,供用户查询、存款、取款转账使用,其中包括:查询管理、取款管理、存款管理、查询余额等。可以摆脱传统银行业务在时间、地点以及在人多时需要排队等待浪费时间的现象,它是全天制的,随时随地,只要有互联网就可以实现传统银行的所以业务,提高了办事效率,方便了广大用户。
1.2 文档约定
本软件需求规格说明书讲遵循IEEE 830标准改写并扩充的模板编写,实际的改写与扩充将根据项目的需求,模板中的某一特定部分可能不适用于此项目,约定的做法是在原处保留标题,并注明该项不适用。
1.3 预期的读者和阅读建议
本软件需求规格说明所针对的读者有:设计人员、项目经理、用户、测试文档的编写人员。本文档是开发人员与用户之间进行交流,澄清了模糊概念之后写成的。本文档确定了待开发软件的功能、性能、数据、界面等要求,并确定了系统的逻辑模型。为不熟悉嵌入式开发业务的开发人员进行系统开发提供了依据,也为测试文档的编写人员提供了参考。
1.4 产品的范围
本ATM系统并不是针对某一个具体银行设计而开发的,他适用于目前市面上 的大多数银行,目前,信用卡用户越来越多,如果还是全部都通过柜台去办理业务,一旦某个时间段顾客过多,那么银行工作人员的工作量将会大量增加,并且,客户会非常浪费时间,柜台办理业务的缺点是,一旦客户多了的时候,很难保证工作人员的质量,难免会为银行和客户带来一定的损失。另外工作效率也太低。此系统的投入使用,将改变银行的一些管理与操作模式 ,加快客户办理的效率,减轻工作人员的工作强度,极大程度上提升了工作人员的工作效率,缩短了客户 的等待时间。
1.5参考文献
[1] 邵贝贝.μC/OS-Ⅱ—源码公开的实时嵌入式操作系统.北京:中国电力版2002
[2] 郑宗汉.实时系统软件基础.北京:清华大学出版社,2003
[3] 陈智育,温彦军,陈琪编著.VxWorks程序开发实践.北京:人民邮电出版社,2004
[4] 罗蕾.嵌入式实时操作系统及应用开发.北京:北京航空航天出版社,2007
[5]于渊.自己动手写操作系统.北京:电子工业出版社,2005
[6] LPC2138 芯片手册
综合描述
2.1产品的前景
当今的嵌入式操作系统领域呈现百家争鸣的状态。据最近的调查数据显示,嵌入式操作系统有数十种之多的。这种多样性存在是必然的,是由嵌入式系统的定制性所决定的,是针对各个领域和行业的不同需求的应对。也就是说,各个嵌入式操作系统都有自己的应用领域,针对不同的应用没有绝对的优劣之分,不会出现一种操作系统垄断的局面。自主开发嵌入式操作系统绝对不是多余的,也是是对这种多样性的自然顺应,应该可拥有自己的用武之地。
本软件作品作为嵌入式实时操作系统系统,采用各种算法和策略,始终保证系统行为的可预测性(Predictability)。可预测性是指在系统运行的任何时刻,在任何情况下,实时操作系统的资源调配策略都能为争夺资源(包括CPU、内存等)的多个实时任务合理地分配资源,使每个实时任务的实时性要求都能得到满足。与通用操作系统不同,实时操作系统注重的不是系统的平均表现,而是要求每个实时任务在最坏情况下都要满足其实时性要求,也就是说实时操作系统注重的是个体表现,更准确地讲是个体最坏情况的表现。
2.2 产品的功能
本系统功能管理如下:
2.2.1功能概述
ATM系统按照实际需要,应主要由用户密码修改功能、用户转账功能、用户提取现金功能、用户存款功能、用户查询余额功能、系统维护功能、银行工作人员更新账户信息等功能。
2.2.2用户密码修改功能
这里的用户密码修改功能,有用户到银行柜台机中通过用户界面完成。用户通过先插入磁卡,输入现在密码,带后台系统验证为合法用户之后,用户可以重置用户密码,选择退卡操作用户取走信用卡。再输入新密码,带后台验证无误之后,后台服务应接受用户修改信息,并写入数据库中。
2.2.3用户转账功能
用户转账功能也是由用户到柜台机通过用户界面完成向其他账号转账完成,用户通过先插入磁卡,有后台服务器验证账号的合法性,如合法,再输入带转账账号,确认所有人信息,然后在输入要从当前账号转入多少金额,然后确认信息,用户可以选择是否打印凭条业务,选择退卡操作,用户取走信用卡,当用户完成之一操作之后,后台系统需要对账号信息进行修改,并写入数据库。
2.2.4用户提取现金功能
用户提取现金功能也是由用户通过柜台机用户界面提取现金完成的,用户通过先插入磁卡,输入密码,带后台服务系统验证账号的合法性之后, 选择取现业务,在输入要取出的金额。确认金额,然后用户可以从出钞口取走现金,之后用户可以选择打印凭条业务,选额退卡操作,用户取走信用卡,当用户完成之一操作之后,后台服务系统应及时更新用户信息,并写入数据库。
2.2.5用户存款功能
用户存款功能通过用户在柜台机出钞口完成,用户通过先插入磁卡,在输入密码,有后台服务系统验证账号的合法性之后,选择存款业务,把要存入的金额放入出钞口,然后确认,用户取走别识别的假钞,之后用户可以选择继续存款,也可以选择打印凭条业务。选择退卡操作,用户取走信用卡,当用户完成这一操作是,后台服务系统应及时更新用户账号信息,并写入数据库。
2.2.6用户查询余额功能
用户查询余额功能也是由用户通过柜台机用户界面完成的,用户通过先插入磁卡,在输入密码,在后台服务系统验证合法账号,选择查询余额业务,之后用户可以根据需求在选择需要的服务。
2.2.7系统维护功能
系统维护公告是当柜员机出现故障时,银行用户提示柜员机暂时不可用,并及时对柜员机进行修理。
2.2.8银行工作人员更新账户信息功能.
银行工作人员更新账户信息功能是当用户完成某一个操作时,银行工作人员需要更新用户的信息(在前面的介绍中已有)。
2.3用户类和特征
| 用户 | 特征 | 
| 信用卡用户 | 信用卡用户可以通过柜员机,输入信用卡密码来修改自己的信用卡密码,进行转账,查询余额,并提取现金,存款等,用户卡用户为合法用户对信用等级有一定的要求 | 
| 后台服务系统 | 后台服务系统负责账户的日常维护工作,即对用户的信息进行及时的更新。 | 
| 维护人员 | 负责此系统的日常维护工作,可以请专门人员进行负责,也可以有银行的工作人员来兼任。 | 
(1)适用于Windows系列中的多个操作系统,如Windows XP、 Windows 2003、Windows 2000、Windows 98等;
(2)为以后增加支持的数据库留下接口,方便以后的系统扩展。
(3)编译程序:Sun JDK1.5或更高版本操作系统:Windows XP、Windows 2003、Windows 2000、Windows 98
(4)开发语言:Java 编译程序:Sun JDK1.5 开发工具:Dreamweaver 8.0 数据库:SQL Server 2000
(5)操作系统:windows XP
(6)系统基于才/S架构进行开发,所有管理和维护工作均集中在服务器端,客户机只需安装有IE浏览器即可,要求IE浏览器版本不低于5.5。
(7)CPU:1GHz以上。 RAM:256M以上。 存储容量:剩余存储容量大于100M
2.5 设计和实现的
2.6 假设和依赖
不足之处:
本系统在开发过程中,若出现技术故障或疑难问题无法解决,软件开发过程中出现偏差,会延误工程进度,导致工程无法预期完工,若用户需求陈述中出现问题,部分描述含糊不清,则会影响工程的完整性和继承性。在管理上如果管理者没有预见性,对出现的问题无法提出切实可行的解决方案,则会影响工程的顺利推进,导致工程无法按期完工。
已具备的条件:
1、小组成员交流比较方便,而且共同写作,积极进取。
2、实现系统所需的资料准备得较齐全。
尚需补充的条件:
1、提高开发人员的编程能力和对软件工程思想的认识;
2、尽快掌握JAVA和SQL的使用方法以及相互的连接。
外部接口需求
3.1用户界面
本软件用户界面要求简洁、友好,采用用户熟悉的Windows窗口菜单操作,且菜单操作简单易懂,菜单命令可用快捷键激活,输入输出时间应使用户不感到明显的时间延迟。
3.2 硬件接口
本系统在c/s模式下运行,其具体方案如下,每台ATM机配备两台服务器,双机备份,前台pc当做终端来用,通过终端服务器与主服务器相连,pc工作站直接挂在以太网上,整个网络采用的是TCP/IP协议,由于此系统要求的性能与可靠性较高,所以前台的pc机配置较高。
1.服务器:
配有双CPU的主板,器CPU不得低于P42.0G。
最小内存不低于512MB,建议使用1G。
硬盘最小容量不低于160G。
100M网卡PCI
2.PC 机:
CPU不低于P41.8G。
最小内存不低于128MB,建议使用256MB。
硬盘最小容量不小于40G。
100M网卡PCI。
3.打印机:
建议使用EPSON针打印系列。
3.3 软件接口
服务器程序可使用JDBC提供的对SQL SERVER的接口,进行对数据库的所有访问。服务器程序上可使用SQL SERVER的对数据库的备份命令,以做到对数据的保存。
3.4 通信接口
通信接口方面,各模块之间采用函数调用、参数传递、返回值的方式进行信息传递。具体参数的结构将在数据结构设计的内容中说明。接口传递的信息将是以数据结构封装了的数据,以参数传递或返回值的形式在各模块间传输。网络间采用TCP/IP协议进行通信。
系统特征
4.1说明和优先级
| 特性: | 优先级: | 
| 1.客户余额的查询: | 中 | 
| 2.客户转账操作: | 中 | 
| 3.客户的基本信息制定: | 高 | 
| 4.客户密码的修改: | 中 | 
| 5.存取款操作 | 中 | 
| 6.系统维护操作 | 高 | 
4.2.1信用卡用户登录:
| 执行这行为: | 系统响应 | 
| 1.插入磁卡,输入自己密码 | 2.验证此用户是否合法 | 
| 3.如果是合法用户就显示相应操作页面,若不合法提示用户重新输入 | |
| 4.用户重新输入自己密码 | 5.再次验证是否是合法用户 | 
| 6.重新执行3 | |
| 7.用户重新确认自己磁卡密码 | 8.若是合法用户显示相应的图形用户界面,否则锁定磁卡,既此磁卡需要到相应的银行解锁才行 | 
| 执行者行为 | 系统响应 | 
| 1.点击查看基本余额信息 | 2.显示该用户余额信息 | 
| 3.点击修改密码 | 4.请求用户输入新密码 | 
| 5.输入新密码 | 6.验证新密码是否合法 | 
| 7.请求用户确认新密码 | |
| 8.再次输入新密码 | 9.验证两次密码是否一致 | 
| 10.如果不一致转而执行8,如果一致则修改用户密码并提示“密码修改成功” | 
| 执行者行为 | 系统响应 | 
| 1.点击选择取款义务 | 2.请求用户输入取款金额 | 
| 3.输入取款金额 | 4.验证金额的合法性,若合法后台给出相应的金额给前台,若不合法则提示输入正确的金额 | 
| 5.重新输入金额 | 6.重新验证金额的合法性,若不合法转而执行5,若合法则后台给出相应的金额给出钞机 | 
| 执行者行为 | 系统响应 | 
| 1.点击选择转账业务 | 2.要求用户输入带转入的账号 | 
| 3.输入带转入的账号 | 4.系统验证账号的合法性,若合法则系统给出相应的操作,若不合法,则提示用户重新输入带转入的账号 | 
| 5.重新输入带转入的账号 | 6.验证账号的合法性,若不合法转而执行5,若合法则服务器给出相应的操作 | 
| 执行者行为 | 系统响应 | 
| 1.点击选择存款业务 | 2.请求用户将钱整理后平整放入出钞口 | 
| 3.将钱放入出钞口 | 4.验证钱是否为假钞,若为真,则系统将钱存入该账号,并修改数据库,若为假,则将钱退还用户,并提示此为假钞。 | 
4.3.1用户密码修改
正常情况下的脚本
1.系统请求用户输入密码,用户输入密码“123456”
2.系统核对改密码正确
3.系统请求用户输入新密码,用户输入密码“4567”
4.系统确定改密码有效
5.系统请求用户确认改密码,用户在此输入密码“4567”
| 6.系统核对两次密码相同,在数据库中更新用户密码为新密码 | 
1.系统请求用户输入新密码,用户输入“1234”
| 2.系统提示非法,密码长度应为6位,请求用户重新输入 | 
| 1.系统请求用户输入新密码,用户输入“234567” 2.系统确定密码有效 3.系统请求用户确认新密啊,用户输入“234566” 4.系统显示“两次输入的密码不一致”请用户重新输入 | 
正常情况下脚本
1.系统请求用户输入待转账账号,用户输入“62222222222222”
| 2.系统核对该账号有效, | 
| 1.系统请求用户确认账号信息是否正确,用户在界面点击确定确认 | 
| 1.系统请求用户输入代转入的金额,用户输入“10000” 2.系统确认有效 | 
| 1.系统提示转账成功 | 
1.系统请求用户输入待转账账号,用户输入“6222222222222”
| 2.系统提示账号非法长度为19位,请求用户重新输入 | 
| 1.系统请求用户输入带转入账号,用户输入“62222222222222” 2.系统显示账号合法 | 
| 1.系统请求用户输入代转入的金额,用户输入“100000” 2.系统提示账号余额不足 | 
| 1.请求用户输入带转入金额,用户输入“150” 2.系统提示金额只能为100的倍数 | 
正常情况下的脚本
1.系统请求用户输入取款金额,用户输入“1500”
| 2.系统核对金额是否合法 | 
| 1.系统提示取款成功 | 
1.系统提示用户输入取款金额,用户输入“3000”
| 2.系统显示金额不合法,金额应在100-2500之间 | 
| 1.系统提示用户重新输入取款金额,用户输入“1550” 2.系统提示金额只能为100的倍数,请求用户重新输入 | 
| 1.系统提示用户重新输入取款金额,用户输入“1500.25” 2.系统提示金额只能为整数,请求用户重新输入 | 
5.1性能需求
精度:
数据采集率:必须在90%以上
动态信息及时率:必须在95%以上
静态信息全面率:必须在95%以上
信息准确率:必须在98%以上
时间特性:
响应时间:存款响应时间<==100秒,取款响应时间<==60秒,转账响应时间<==100秒,查询余额响应时间<==30秒,其他业务响应时间<==30。
5.2 安全设施需求
如果本系统在运行时出现死机现象,那么本系统必须在1分钟之内终止掉,同时提示维护人员进行及时维护。
每月都必须在固定时间对柜员机进行维护,以确保硬件和计算机运行请款的正确性,并要求工作人员在一定的时间内对柜员机中放入一定数量的金钱。
5.3 安全性需求
系统中所有涉及敏感信息如登录口令等,服务器端应设置严格安全访问控 制策略,从而保证系统安全性和操作责任的可追溯性。
5.4 软件质量属性
5.4.1有效性
本系统应该能一次运行至少一个月,同时在运行期间其有效性要达到98%。
5.4.2效率
本系统不管是在高峰使用时期还是在低峰使用时期都要保持高效率。
5.4.3完整性
所有用户必须在验证账户信息合法后才能进入系统执行下一步操作,只有银行的系统维护员才有权限查看系统的历史记录,操作日志,只有制定的人员才能对系统的硬件和软件进行维护。
5.4.4健壮性
当输入密码位数不对或者格式不对时,系统应该出相应的操作,并给出简单实例,当用户输入错误信息时,系统立即报错,并发出修改踢死信息,当用户一天之内有三次输入错误,本系统通知后台管理系统锁定该账户。
5.4.5可用性
新的用户在进行简单的实验后,就可以正确的执行所有的操作。
5.4.6可维护性
在整个系统开发中,必须有完整的准确的文档资料,正常情况下,各个柜员机的维护人员应该可以再极端的时间内完成对系统的维护工作,在系统编码时,函数的调用不能超过三层深度,并且每个模块中代码与注释的比例不得低于1:3,注释中应当包含编写人,编写时间,软件功能模块的描述,函数的作用。
5.4.7可重用性
本系统涉及的基础数据处理模块可考虑作为新的组件库,为后续项目做准备。
5.4.8可测试性
模块之间不要出现相互调用的情况,同时每个模块设计或者源代码中逻辑分支最好在(7+-2)之间。
5.5 业务规则
1. 只有持有系统维护人员权限的用户才能执行系统的维护工作。
2.只有合法用户才能执行转账业务
3.只有合法用户才能执行存款业务
4.只有合法用户才能执行取现业务
| 5.只有合法用户才能执行查看余额业务 | 
详细内容见《ATM系统使用说明》
附录A 词汇表
名字:用户信息表
描述:存储用户的相关信息
定义:用户信息表=开户账号+身份证号+电话+家庭住址
组织:按关键字排列
| 注释:包括所有账号信息 | 
| 名字:信用卡信息表 描述:存储用户信用卡的相关信息 定义:用户信息表=卡号+密码+余额+开户信息 组织:按关键字排列 注释:包括所有用户信息 | 
| 名字:交易信息表 描述:说明用户进行交易的基本内容 定义:交易信息表=卡号+交易日期+交易类型+交易金额 组织:按关键字排列 注释:包括所有用户信息 | 
| 名字:交易类型 描述:说明用户进行什么交易 定义:交易类型=[取款|转账] 组织:按关键字排列 注释:包括所有用户信息 | 
| 名字:金额信息 描述:每个用户索取的金额是卡里的余额 定义:金额信息=[取款金额|余额] | 
| 名字:交易时间 描述:每个用户进行交易的具体时间 定义:交易时间=日期 注释:采用4-2-2格式 | 
| 名字:交易金额 描述:用于判定用户交易的金额 定义:交易金额=[100的倍数|100-3000] 注释:只能满足上述条件 | 
| 名字:联系电话 描述:用户的联系方式 | 
| 名字:家庭住址 描述:用户的住址 定义:只能是字符串 | 
| 名字:开户名 描述:用户姓名 定义:开户名=姓名 注释:名字只能为2-4个汉字 | 
| 名字:身份证号 描述:唯一标识个人身份的关键域 定义:15-17位数字 | 
| 名字:卡号 描述:唯一描述一个用户的关键域 定义:19位数字 | 
| 名字:密码 描述:用于对用户的一种加密技术 定义:密码只能为6位数字 | 
| 名字:取款金额 描述:说明用户取款的具体金额 注释:同交易金额 | 
| 名字:余额 描述:说明用户账号里的钱 定义:余额=0{数字} 注释:账号余额最少为0 | 
1.系统E-R图
2.ATM机系统数据流图
3.用户操作数据流图
4.ATM机子系统取款功能流程图
5.管理员系统流程图
6.管理员查询系统功能机数据流程图
7.用户与后台管理系统用例图:
