1.实验项目概述

1.1.项目简介

我们小组的项目是南风银行ATM系统，作为软件工程课程的实验项目，我们通过课程实验八个课程的学习、小组集成项目的开发工作，历时八周，基本实现了由计算机控制的持卡人自我服务型ATM系统。作为自助系统，其可以提供最基本的银行服务，即用户的登录、查存取转交易、改密、管理员登录进行开户销户等。我在整个项目中负责用户的登录改密以及管理员登录进行开户销户的功能，同时我们小组的成员还有**…，他们负责的功能就不在此一一赘述。我们的系统目前已测试完成，功能基本完善。

1.2.项目OBS

我们整个项目组的组织分解结构分为设计组、开发组、以及测试组，给每个人都分配了详细的任务，“组织分解结构”OBS如图2-1所示。

图 1-1项目组织分解结构图

1.3.项目WBS

本项目的“工作分解结构”WBS如图3-1所示。

图 1-2项目工作分解结构图

1.4.项目初始

项目小组正式成立后，我们经过商讨将南风银行ATM系统确定为我们的实验项目，在项目的初始阶段，我们小组对这个项目做了较为详细的解析，将各个功能模块进行拆分，由此我们做了相应的分工，我作为组员负责ATM自动柜员机系统用户管理相关功能的实现，同时作为小组长负责项目的整合工作。我们在初始阶段还一同制定了软件项目计划报告，为之后的项目进程做好准备。

1.5.项目实施

项目的实施阶段大概为：分析——设计——实现——测试四大模块，我们又将分析过程细分为了系统分析及需求分析，将设计过程分为概要设计及详细设计，大概过程如下图所示，我们小组根据计划内容进行项目的开发进程推进。

图 1-3项目过程图

1.6.项目结项

在项目进程进行到实施计划的最后一步系统测试之后，我们整个项目的基本功能就大概完成了，虽然过程中稍有曲折，但是最终每个人都基本完成了自己的任务部分，之后我作为组长将我们各自完成的功能整合在一起。系统整合好之后我们小组在一起进行最后的系统测试，将系统继续完善，系统实现的展示及源码将在后文中给出。大致测试过程如下图所示：

图 1-4项目测试图

2.软件项目计划总结

2.1.项目进度

将项目结项的成果与计划书做比较，我们的项目自评定完成度大概为百分之90。系统目前已测试完成，功能基本完善，可进行结项。

2.2.项目成本

根据我们项目的系统用例利于用例点UCP法估算项目成本，如图所示。
此处计算的是我们整个项目的成本，我在其中对我所负责的功能进行了标注处理，即红色用例。

图2-1 用例模型图

图2-2 项目成本估算图(一)
默认：UCP:84 Hours:1680 Cost:67200

图2-3 项目成本估算图(二）
据调查本市计算机工程师均工资约为75元/小时；
配置相关TCF技术影响因子及ECF环境影响因子；
可得ATM系统软件成本约为17.6万元。
其中最为主要的成本是技术成本。

2.3.项目质量

就目前看来我认为我们这个项目的质量大概算是中等偏上水平，设计较为良好，采用了MVC框架，系统开发过程较为清晰，编码较为规范，团队配合情况良好。

2.4.项目风险

（一）需求风险：项目在确定需求时会面临一些不确定性，当我们的项目早期容忍了这些不确定性，并且在项目进程中这些问题得不到解决，就会对项目的成功造成威胁。关于需求相关的风险因素有：对产品缺少认同、在做需求中客户参与度不够、缺少有效的需求变化管理过程等。
（二）技术风险：软件技术的发展和经验丰富员工的缺乏意味着项目团队可能会因为技术原因影响项目的成功，关于技术方面的风险因素有：项目成员缺乏培训、项目成员对方法工具和技术理解不足、团队应用领域经验不足。

2.5.过程模型

本项目的软件开发过程模型如图所示。

图2-4 软件开发过程模型图

2.6.项目成果

我们的项目基本完成了ATM系统的业务功能。我在此处展示个人负责功能截图，源码部分及其余详情见下文。
我的个人任务是普通用户登录改密与管理员登录开户销户功能，所以我在此只展示普通用户登录改密及管理员登录开户功能的实现截图。
登录界面：

图2-5 登录界面图

图2-6 登录成功界面图
用户主界面：

图2-7 主界面图
改密界面：

图2-8 改密界面图
修改成功界面：

图2-9 改密成功界面图
管理员登录：

图2-10管理员登录图
管理员主界面：

图2-11 管理员主界面图
开户界面：

图2-12 开户界面图
开户成功界面：

图2-13 开户成功界面图

3.软件需求分析总结

3.1.需求模型

根据ATM自动柜员机相关设计需求进行需求建模，主要有功能性需求和非功能性需求两大部分，功能性需求中又分为系统需求、用户需求、业务需求等，业务需求又可详细分为查存取转等功能需求。我在项目中主要负责用户管理即普通用户登录改密与管理员登录开户销户，所以我在此处只展示了用户管理的详细需求模型部分。

图 3-3 用户需求模型图

3.2.需求管理

EA导出根据需求建模生成的需求报告，并修改报告内容得到最终的需求管理报告。

图3-4 用户管理需求管理图

3.3.用例模型

根据需求模型进行用例建模：
根据我在项目中对所负责的功能进行了用例建模。

图3-5用例模型图

3.4.鲁棒分析

根据用例模型绘制分析模型的鲁棒图，如下图所示：

图3-6 ATM分析模型鲁棒图
ATM自动柜员机业务所涉及的视图类有操作面板、凭据打印装置、信息接收装置、ATM系统、退卡装置等；
ATM自动柜员机业务所涉及的控制类有ATM柜员机、会话、事务等；
ATM自动柜员机业务所涉及的模型类银行账户、账户金额、用户密码数据、账单、ATM柜员机日志等。

3.5.分析类图

ATM分析类图主要是从领域获取实体类、系统初步设计鲁棒分析的边界类、控制类等，确定类对象，以及对象间的关系和权属。如下图所示：

图3-7分析模型类图
此处我放了系统分析前期阶段，根据总体设计获取默认类以及设计和编码阶段的类图，在前期我们将各个类根据其之间的关系关联起来，进行初步分析建模，确定初步结构。详细类图在下文中给出。

4.软件系统设计总结

4.1.设计原则

系统总体设计应当根据系统工程的设计思想，使开发的系统满足科学化、合理化、经济化的总体要求。一般遵循以下几项基本原则：
( 1) 完备性
完备性主要是指系统的功能齐全、完备，能够满足用户的需要，系统要具备数据采集、管理、处理、查询、编辑、显示、分析及输出等功能。
( 2) 系统性
空间数据和属性数据必须能够有机地结合为一体，各种参数可以互相进行传输。
( 3) 可靠性
系统的可靠性包括两个方面，一是系统运行的安全性，系统必须保证能够长期安全可靠稳定的运行; 二是运用 GIS 软件进行开发采集数据精度的可靠性和符号内容的完整性。
( 4) 实用性
系统数据组织灵活，可以满足不同应用分析的需求。系统真正做到能够解决用户所关心的问题，为生产实践、科研教学服务。

4.2.分层结构

我们的项目体系结构为CS三层结构。即客户层、服务层、数据层。服务端分别将分析模型的鲁棒图中的边界类、控制类分别视为客户层、服务层。总体结构如下图所示：

图4-1项目体系结构图

4.3.数据建模

采用类图表示概念，修改为表和列后，仍然为类图，表示其逻辑；最后通过生成DDL，结合DBMS得到最终的数据库脚本或数据库实例。
经过调研和分析，系统支持MySQL存储实体数据，确认ATM、用户、磁卡、账号、交易5个实体，其关系实体类图如下图所示：

图4-2概念模型图
概念模型可确定概念或实体类名称、实体关系、主键等。采用抽象描述，如用户，姓名为字符串类型，用户可以拥有多个账户及多张磁卡等等。进而利用概念模型生成逻辑模型，最终生成数据模型，如下图所示：

图4-3物理模型图
数据建模的目的一是由物理模型生成得到DDL，再建库导入形成可用数据库系统；二是直接创建数据库系统。现在我们既要保存DDL，又要配置环境，支持数据库操作。

图4-4数据库系统图
最后完善开发数据库，创建测试数据库，根据需求设计若干测试用例入库。

图4-5 数据库用例图

4.4.界面建模

识别界面类及其组件，数据跟踪界面元素。界面类应该建立与界面相应的Java语言的边界类，其中包含必要的界面组件。
识别GUI登录界面类及其组件、数据映射。

图4-6 界面映射图
根据界面和数据表，完成二者映射，可以编辑和修改原来的界面和数据模型确保一致性。

图4-7 界面类映射图

4.5.设计类图

图4-8 设计类图（一）

图4-9设计类图（二）

4.5.1.设计类图的行为建模：活动图

对改密类图进行行为建模，绘制活动图，如下图所示，并正向工程生成覆盖原生成代码：

图4-10 ATM行为建模改密活动图

4.5.2.设计类图的行为建模：顺序图

对取款类图进行行为建模，绘制顺序图，如下图所示，并正向工程生成覆盖原生成代码：

图4-11 ATM行为建模取款顺序图

4.6.模块建模

①登录模块：

图4-1登录模块时序图
②用户管理模块（此处绘制的是密码修改行为及个人信息、账单查询打印行为的时序图）。

图5-1用户管理模块时序图

4.7.设计评估

我在项目设计过程中尽可能的使每个类的成员方法完成少的事件，减少类内部对其他类的调用，内聚度较高，耦合度较低。

5.软件系统编码总结

5.1.双向工程

正向工程：只有类图才能生成代码，代码包含类的属性和操作的定义骨架（没有定义体），行为模型生成类的操作即其定义。

图5-1 正向工程图（一）

图5-2 正向工程图（二）
逆向工程。引用依赖包，参考源码设计。逆向得到模型，由模型理解源码的逻辑和设计思路。

图5-3 逆向工程图（一）

图5-4 逆向工程图（二）

5.2.编码风格

项目的编程在随着软件规模增大的同时，复杂性也有了增加，我们逐渐发现在系统的总体架构中需要经常阅读程序，特别是在软件测试阶段和维护阶段，阅读程序是软件开发和维护过程中的一个重要组成部分，且读程序的时间比写程序的时间还要多。此时，程序实际上需加强可读性，这样，我们确定了一些编码风格。
(1)每一个函数都必须有注释，即使函数短到可能只有几行。
(2)每个函数定义结束之后以及每个文件结束之后都要加一个或若干个空行。
(3)在一个函数体内，变量定义与函数语句之间要加空行。
(4)逻揖上密切相关的语句之间不加空行，其它地方应加空行分隔。
(5)复杂的函数中，在分支语句，循环语句结束之后需要适当的注释，方便区分各分支或循环体。
(6)修改别人代码的时候不要轻易删除别人的代码，应该用适当的注释方式。
(7)用缩行显示程序结构，使排版整齐，缩进量统一使用4个字符（不使用TAB缩进）。
(8)在函数体的开始、结构/联合的定义、枚举的定义以及循环、判断等语句中的代码都要采用缩行。
(9)同层次的代码在同层次的缩进层上。
(10)代码行最大长度宜控制在80 个字符以内，较长的语句、表达式等要分成多行书写。
(11)长表达式要在低优先级操作符处划分新行，操作符放在新行之首（以便突出操作符）。
(12)如果函数中的参数较长，则要进行适当的划分。
(13)用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。
(14)如果代码行中的运算符比较多，用括号确定表达式的操作顺序，避免使用默认的优先级。
(15)不要编写太复杂的复合表达式。
(16)尽量避免含有否定运算的条件表达式。
(17)参数的书写要完整，不要贪图省事只写参数的类型而省略参数名字。
(18)不要编写太复杂的复合表达式。
(19)构造函数的初始化列表：如果类存在继承关系，派生类必须在其初始化表里调用基类的构造函数
(20)关于编程习惯：在编写程序前至少有明确思路（数据结构和算法），而不是坐在电脑前边输边想，东拼西凑。
(21)一个类中相同的代码，最好是提炼成一个独立的方法，方便调用。不同类中重复的代码，提炼成一个新的类

5.3.实现模型

我个人在小组中的任务是用户管理，即开户、改密业务和登录操作的实现，以下是我个人任务功能实现的具体类图和包图。

图5-5 个人任务类图

图5-6个人任务包图
由模型可生成所有源码，并可编译执行。

图5-7 项目源码图

图5-8 项目源码展示图

5.4.组件模型

ATM中包含所有源码，形成组件。

图5-9 组件模型图

5.5.部署模型

图5-10 部署模型图

6.软件系统测试总结

6.1.软件测试基础

首先在EA中生成JUnit测试模型

图6-1 JUnt测试图
选择包或类，点击“Transform”转换，生成相应的代码。

图3-2 JUnt test包图
单元测试规范：
①可衡量：单测的编写应该是可以用具体的指标衡量的单测通过率要求100%，行覆盖率要求50%以上。老代码有逻辑变更时，单测也应该做相应的变更（并实施测试称为递归测试）。新业务提测前，必须保证老单测的通过率也保持100%。
②独立性：单测应该是独立且相互隔离的。一个单测只测试一个方法。单测不应该依赖于别的单测。单测如果涉及到数据变更，必须进行回滚。单测应该测试目标方法本身的逻辑，对于被测试的方法内部调用的非私有方法应进行mock（模仿），推荐使用Mockito进行mock。
③规范性：单测的编写需要符合一定规范对实现类进行测试而非接口。单测应该是无状态的。

6.1.1.软件测试的黑白盒技术

软件分为两部分，一部分是数据，另一部分是程序。数据包括键盘输入，鼠标单击，磁盘文件，打印输出等；程序是指可执行的流程，转换，逻辑和运算。而我们测试最常用的一个方法也是按同样的方式划分进行测试。
软件测试常用的方法有黑盒测试，白盒测试，静态测试，动态测试。。
黑盒测试：又称功能性测试或行为测试，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试。它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
白盒测试：又称透明盒测试或结构测试或逻辑驱动测试，是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作，即可以看到盒子里面。
静态测试：是指测试不运行的部分，只是检测和审核。
动态测试：是指通常意义上的测试，使用和运行软件。

6.1.2.软件测试的单集系验测试分类

我们的项目结构分为Dao层、Service层、Gui层三个层次，且我们项目的业务功能主要有登录、查询、存款、取款、转账、改密、开户，所以我们小组分别对这些单个的功能进行了拆分单测。
我在项目中负责登录、改密，则我的测试进行将对改密功能的三个层次展开。

6.2.需求测试模型

早在软件项目计划时我们就已经大概确定了系统各个功能的需求模型，项目完工我们需要再次对之前确立及完善的需求模型进行系统性能测试，即登录需求、存款需求、取款需求、转账需求、用户管理需求等。我在此展示我所负责的部分，即登录需求和用户管理需求的测试模型。如下图所示：
用户管理需求性能测试：

图6-1 用户管理性能测试模型图

登录需求性能测试：

图6-2 登录性能测试模型图

测试结果截图：

图6-3 登录性能测试截图（一）

图6-4 登录性能测试截图（二）

图6-5 登录性能测试截图

6.3.用例测试模型

集成测试之后我们对系统的部分用例进行了功能测试，即对系统用例中的开户、登录、查余、存款、取款、转账、改密功能进行系统功能测试，大概参考单测与集测对这些用例进行详细测试我在此处仅展示我自己所负责部分功能的性能测试。
功测模型图及管理图如下图所示：

图6-6 系统功能测试模型图

测试结果截图：

图6-7 改密性能测试截图

6.4.类测试模型

我们项目的业务功能主要有查询、存款、取款、转账、改密、开户。所以我们小组分别对这些单个的功能进行了拆分单测。我负责改密，所以在此展示改密功能实现的三个类图测试。
如下图所示：

图6-8 改密单测模型图

测试结果截图：

图6-9 改密测试截图（一）

图6-10 改密性能测试截图（二）

当我们的单测完成之后，就要考虑部分单个的功能集合在一起的效果，单个模块没有问题，但会不会对另一个模块造成影响？或者说各个子模块合起来，能否达到父功能的要求。所以我将开户与登录功能集合在一起进行集成测试。
开户与登录功能集成测试：
开户——登录——退出，如此反复测试。集测类模型图如下图所示：

图6-11 开户与登录集成测试模型图

测试结果截图：

图6-12 开户测试截图（一）

图6-13 开户测试截图（二）

图6-14 开户测试截图（三）

6.5.测试管理

图6-15 改密单测管理图

图6-16 开户与登录集成测试管理图

图6-17 总测试管理图

6.6.测试报告

密码修改功能单测（负责人：–）
密码修改功能单测共进行7次，成功6次，失败1次，失败的原因是修改密码位数超过六位数。
开户与登录功能集成测试（负责人：–）
开户——登录——退出，如此反复测试。
该集测共进行7次，均成功。
用例功能测试（负责人：–）
每一个用例都进行了3次测试，共计21次，20次成功，1次失败，为登录用例中的空密码错误。
登录需求、改密需求、销户需求NPS性能测试（负责人：—）
每项功能约测试5-7次，共计18次，均成功。
验收测试（负责人：–）
类比于性能测试模型对我所负责功能的所有需求进行验收测试，共计24次，均成功。

7.收获与展望

掌握项目词汇，总结项目的领域知识；总结EA对软件开发全生命周期的支持；总结个人软件过程和团队软件过程中的收获与体会。

7.1.项目词汇

略

7.2.项目效益

本项目属于课程设计项目，项目的学术效益突出，经济效益与社会效益也较为可观。
经济效益:
南风银行一台ATM机初始投入资金约为100000元，安装费用1000元，每年维修费用2000元，最长使用寿命10年，预计每天使用次数40次左右，平均使用时间80分钟。相当于每天花费50元左右雇佣员工工作一小时。
据调查，银行一名普通柜员年薪25k加上年底奖金30k左右共50k左右。每月平均4200元，日均服务笔数为200——300，其中存储业务约占10%,每天实际处理业务时间6小时左右。平均每天花费200元雇佣员工工作6小时。
所以可知该系统经济效益可观。
社会效益：
南风银行ATM自动柜员机在银行业务流程当中起着承上启下的作用，其重要性不言而喻，不仅能为银行节省大量财力人力，还为广大用户带来便捷。

7.3.软件、项目、EA建模三个全生命周期

软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。
生命周期的每一个周期都有确定的任务，并产生一定规格的文档（资料），提交给下一个周期作为继续工作的依据。按照软件的生命周期，软件的开发不再只单单强调“编码”，而是概括了软件开发的全过程。软件工程要求每一周期工作的开始只能必须是建立在前一个周期结果“正确”前提上的延续；因此，每一周期都是按“活动-结果-审核-再活动-直至结果正确”循环往复进展的。同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期（软件生命周期）。把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。可以将软件生命周期概括为软件计划与可行性研究阶段（问题定义、可行性研究）、需求分析阶段、软件设计阶段（概要设计和详细设计）、软件编码阶段、软件测试阶段和软件运行与维护阶段。
软件计划与可行性研究阶段（问题定义、可行性研究）：此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
需求分析阶段：在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，也是在整个软件开发过程中不断变化和深入的阶段，能够为整个软件开发项目的成功打下良好的基础。
软件设计阶段（概要设计和详细设计）：主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件编码阶段：是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
软件测试阶段：在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。
软件运行和维护阶段：是软件生命周期中持续时间最长的阶段，包括纠错性维护和改进性维护两个方面。
项目生命周期是一个项目从概念到完成所经过的所有阶段。所有项目都可分成若干阶段，且所有项目无论大小，都有一个类似的生命周期结构。其最简单的形式主要由四个主要阶段构成：概念阶段、开发或定义阶段、执行（实施或开发）阶段和结束（试运行或结束）阶段。阶段数量取决于项目复杂程度和所处行业，每个阶段还可再分解成更小的阶段。

7.4.个人软件过程PSP收获

本次实验开发完整的ATM自动柜员机系统,从理论到实践，对Java技术的应用方面以及面向对象的知识都有了进一步的学习和研究。通过这次实验开发，我更加熟悉了开发和编程应用的知识与技巧，同时锻炼了开发和编程应用的能力。此外，通过对MySql的操作，进一步巩固了我对数据库方面知识的理解，提高了我编写SQL语句的能力。总之，通过这次实验开发，提高了我的自学能力和独立解决问题的能力，也锻炼了我编写软件各种文档的能力，在校期间所学的理论知识在此次实验开发中得到很好的实践，为今后的实际工作打下坚实的基础。

7.5.个人软件过程PSP体会

通过这次的实验开发，我深刻体会到，一个系统或者说一个项目从开发到可运行，仅靠一个人是远远不够或者说异常艰难的，团队的的力量才是无穷大的，合作开发才是永远的主流。

7.6.个人软件过程PSP问题

一是EA软件使用的问题，EA功能很强大，所以操作起来并不是那么容易，在整个实验开发过程中，EA软件的使用经常会碰到问题，不过还好老师的视频教学很多也很全，绝大多数问题都能在老师的视频里找出解决办法。
二是对软件开发及面向对象相关知识的了解应用不足，特别是换了开发环境之后刚开始不太能理解，之后慢慢了解认识面向对象的真面目才转过来观念。

7.7.团队软件过程TSP收获

好的合作确实会使整个项目开发效率更高，但是若是小组内成员配合不好就会得到截然相反的结果，一开始我们小组也配合不太好，各自写的代码模型什么的很难组合到一块去，之后我们每次项目进程推进之前我们都会进行详细的交流，并制定相应简单的编码规定，讨论彼此对项目的的想法，集思广益才能更加踏实的的一步步走下去。
我们小组的组员们都很积极，并且都很乐于交流，基本上每次实验我们都进行的较为顺利。

7.8.团队软件过程TSP体会

还是那句话，团结就是力量，开发永远不是一个人的事，团队是你走下去的基石。

7.9.团队软件过程TSP问题

同TSP收获

8.附录

8.1.词汇表

略

8.2.项目效果截图

我的个人任务是密码修改与开户，所以我在此只展示普通用户登录改密及管理员登录开户功能的实现截图。
登录界面：

用户主界面：

改密界面：

管理员登录：

管理员主界面：

查询账户界面：

开户界面：

8.3.项目所有文件清单

8.4.项目EA的模型文件

8.5.项目源码文件

8.6.项目安装文件

Build配置图：

Debug配置：

Run配置图：

《软件工程》实验个人报告，南风银行ATM自动柜员机开发总结报告；滁州学院课程相关推荐

写一个简单的自动取款机c语言程序,C语言编程模仿银行ATM自动取款机功能
编程模仿银行ATM自动取款机功能,要求能实现以下功能: 1. 输入储户基本信息(既开户功能,开户成功需要打印储户基本信息): 2. 开户成功后打印欢迎界面,比如"开户成功,欢迎使用**银行自 ...
python银行ATM自动取款机
python银行ATM自动取款机银行自动取款机 main.py(主程序) admin.py atm.py user.py card.py 总结银行自动取款机 main.py(主程序) main.p ...
各银行ATM(自动柜员机) 取款费用+信用卡收费标准+网上银行收费标准
各银行ATM(自动柜员机) 取款费用+信用卡收费标准+网上银行收费标准 ATM收费标准 update:2009年05月18日银行同行同城取款同城跨行取款 ...
银行ATM自动取款机模拟程序C语言——课程设计实习
绪论 ATM即自动取款机的意识,ATM是最普遍的自助银行设备,可以提供最基本的银行服务之一,即出钞交易,有些全功能的产品还可以提供信封存款业务.在ATM自动取款机上也可以进行账户查询和改密的业务.作为 ...
python项目分析报告_实战 | Python自动生成PPT分析报告
原标题:实战 | Python自动生成PPT分析报告在数据分析里面有一句话是说,80%的时间要用于数据清洗和整理,而我觉得理想的状态应该是把更多的把时间花在数据背后的洞察当中.去年11月在简书占了个 ...
基于HTML模拟系统自动报告生成技术的研究与开发[开题报告]
开题报告一.课题题目基于 HTML 模拟系统自动报告生成技术的研究与开发二.课题内容及任务要求本课题的主要目的是自动生成HTML格式的分析报告文档: 1. 对华铸CAE数据可以自动获取 2 ...
python自动生成ppt报告_实战 | Python自动生成PPT分析报告
importreportasrpt# 文件I/Odata=rpt.read_data(filename)code=rpt.read_code(filename)rpt.save_data(data,f ...
《软件工程》实验个人报告，实验三：软件系统设计1；滁州学院课程
1.项目体系结构我们的项目体系结构为CS三层结构.即客户层.业务层.数据层.服务端分别将分析模型的鲁棒图中的边界类.控制类.实体类分别视为客户层.业务层.数据层.设计各层之间的接口.总体结构如下图所 ...
基于java的银行ATM系统设计(含源文件)
欢迎添加微信互相交流学习哦! 项目源码:https://gitee.com/oklongmm/biye 目录 1 系统分析 1 1.1 设计背景 1 1.2 需求分析 1 1.2. ...

《软件工程》实验个人报告，南风银行ATM自动柜员机 开发总结报告； 滁州学院课程