《JAVA课程设计网吧管理系统.docx》由会员分享,可在线阅读,更多相关《JAVA课程设计网吧管理系统.docx(37页珍藏版)》请在三一办公上搜索。
1、Java课程设计指导书(学生版初稿)第一章1234网吧计费管理系统1.1背景介绍1.1.1业务背景1.1.2技术背景1.2需求分析1.2.1功能需求分析1.2.2业务对象分析1.2.3验收测试要求1.3系统设计1.3. 1总体设计1.3.2详细设计1.4系统实现1.5小结1.6展望第一章1234网吧计费管理系统1.1背景介绍1.1.1业务背景1234网吧,是一个小型网吧,以前是人工记帐,现需要开发一 个简单的网吧计费管理系统。原人工管理的主要过程如下:客户在门 口服务台,出示上机卡,若是新客户则先发新卡;管理员先查询是否 有空机器,若有则根据上机卡号查到该卡对应的记录(账簿),若有 余额(余额
2、5元),则分配一个空闲的机器号给客户,客户根据机器 号对号入座,管理员记下客户卡号、上机机器号、上机时间。客户下 机要到门口的服务台,请求下机,管理员根据当前时间、上机时间及 费率计算出本次上机费用,并记录,同时将费用从卡余额中扣除,若 费用不够则需充值。原手工系统主要有如下缺点:1手工记帐,管理 员工作量大,且易出错;2超时超费使用不能及时发现。因此需要开 发一个简易计费管理软件,取代人工记帐方式,由软件统一管理记录 上下机、计费、上机卡、机器情况,提供简单统计功能,超时超费提 醒功能等。1.1.2技术背景本系统要求使用java技术开发,使用数据库(如MySQL)保存数 据,集成开发环境可使
3、用支持可视化GUI界面设计的主流工具(如 eclipse)。开发者应有java程序设计语言、文件使用、JDBC存取数 据库、使用一种集成开发工具的基本知识和技能。系统采用两层C/S 体系结构,C端负责通过GUI与管理员交互、处理业务逻辑及存取数 据库,S端主要是数据库系统。系统分析设计主要采用面向对象的分 析设计方法。1.2需求分析1.2.1功能需求分析系统需求分析的主要任务是从用户角度考察系统应具有哪些功 能及非功能性需求,对于网吧计费管理系统,用户主要是指系统管理 员,系统的主要功能是:登录、上机、下机、身份证管理(刷身份证、 删身份证、充值、查询)、机器管理(添加机器、删除机器、查询状
4、态、修改状态),统计功能(日、月费用统计),口令管理(添加用户、 删除用户、修改口令),参数设置(时段费率),使用帮助。主要使用 流程是:管理员登录,根据客户请求上机,根据客户请求下机。主要 功能的用例(use case)描述如下:一. 上机1管理员输入空闲机器号,上网人输入口令、卡号,请求上机。2系统验证卡号,检查卡中余额,卡状态3系统获取当前系统时间作为上机开始时间4系统修改该机器的使用标志为“在用”,卡标志为“在用”。5系统记录上机信息(卡号、机器号、上机时间)6系统提示上机成功若1中无空闲机器又请求上机的,系统提示“没用空闲机器”,2中卡验证未通过,提示“无此卡号”,余额不足,提示“余
5、额不 足”,卡状态为“在用”,则提示“不能一卡多用”。二. 下机1管理员选择被使用的机器号,请求下机2系统获取系统当前时间作为下机时间;3系统计算费用;4系统显示应缴费用5系统记录下机时间和此次费用;6系统从卡中扣费,修改卡状态为“空闲”;7系统修改该机器的状态为“空闲”;8系统显示本次上机记录信息,提示下机成功三. 登录1管理员输入用户名和密码,请求进入系统2系统验证用户名和密码3系统显示主界面若一次验证不通过,则提示再输入一次,仍不通过则系统退出。四. 卡维护卡有三种状态:停用、空闲、在用。发新卡:1管理员输入卡号(保证卡号唯一)2管理员输入卡初始金额3上网人输入用户名、口令4管理员请求添
6、加新卡5系统保存卡号、金额、用户名和密码,状态为“空闲”6系统提示添卡成功,显示卡号及金额,以便核对。7管理员将系统生成的有卡号、用户名的纸卡给上网人。充值:1管理员输入卡号2系统显示该卡信息(卡号、用户名、余额、状态)3管理员核对后,输入充值金额4系统计算并保存该卡总金额5系统显示充值后的卡信息(卡号、用户名、余额、状态)。查询卡信息:1管理员输入卡号或请求察看所有卡信息2系统查询卡信息(卡号、用户名、余额)并显示删除卡:1管理员输入卡号2系统查询卡余额及状态3若余额已结清且状态为“空闲”,则将该卡信息删除4系统提示删除成功若有余额或“在用”则不能删除机器有三种状态:停用、空闲、在用。添加机
7、器:1管理员输入机器号,请求添加2系统验证机器号是否重复3系统添加机器记录信息(机器号、状态为“空闲”)4系统提示添加成功删除机器:1管理员输入机器号,请求删除2系统删除相应机器信息3 系统提示删除成功查询机器状态:1管理员输入机器号或请求察看所有机器信息2系统查询并显示机器信息(机器号和状态)并显示六. 管理员口令管理添加用户1管理员输入用户名、密码和确认密码,请求添加2系统验证用户是否是新用户,两次输入的密码是否相同3系统添加用户、密码信息4系统提示添加成功删除用户1 管理员输入用户名、密码2系统验证用户名、密码是否正确3系统删除用户名、密码记录4系统提示删除成功修改密码1管理员输入用户名
8、、密码,请求修改密码2系统验证用户名、密码是否正确3管理员输入新密码、及确认密码4系统保存新密码5系统提示修改成功七. 统计管理1管理员输入起始时间(年、月、日),结束时间,请求按日、 月、年汇总2系统查询上网记录,计算、统计出时间段的总费用、人次、总上机时间等信息。3系统显示上述信息八. 参数管理时段费率设置:0系统显示当前设置1管理员设置时间段(时、分)及对应的费率,请求保存2系统保存设置3系统提示保存成功超时报警定时器间隔设置九. 超时超费报警1设置定时器为周期触发方式,触发间隔由参数获得,默认为30分钟2定时器到时,系统查询当前正在上机的记录,计算其上机 时间及费用,计算其卡中余额是否
9、低于最低费用。3系统提示已超费卡号、机器号,及超的费用本系统除了功能性需求,还有易用性、可靠性、安全性等要求, 可以在实现上述功能性需求的基础上,进一步实现完善非功能性要 求。1.2.2业务对象分析根据上面的主要用例描述,可以分析出系统的主要业务对象,它 是设计阶段核心类图的基础(不一定一一对应),这些对象必须实际 存在,其行为和属性应与问题领域相关:1上网卡:主要维护上网卡的相关信息。卡号、密码、余额、卡用户名、卡状态(在用、空闲、停用)2机器:主要维护上网吧计算机的相关信息。机器号、使用标志(在 用、停用、空闲)、备注3费用记录:记录每次上机的信息。记录编号、卡号、机器号、开 始上机时间,
10、下机时间、费用4费率记录:起始时间、终止时间,费率5管理员:利用14完成各种业务操作。1.2.3验收测试要求用户要求开发产品,产品开发完成后,需要交付用户验收,验 收要求常常是合同中的重要组成部分,这是一个必经的环节,主要思 路是按照用户使用的过程测试系统,越频繁使用的功能越要多测试。 本系统功能性需求验收测试的基本要求如下: 前置条件:1除口令表有初始用户名和密码外,各库表为空。2程序安装配置正确,能正常启动运行。一. 初始化数据1启动程序,进入“卡维护”,选“发新卡”,输入一条数据记录,退 出,进入“信息浏览”,查看记录是否已被正确加入;退出“信息浏 览”,再进入“发新卡”,连续发3张卡,
11、其中有张卡余额为0;再进 入“信息浏览”,查看记录是否已被正确加入。2同理按1,添加机器。3进入“费率维护”,设置费率。二. 功能测试1上下机测试。进入“上机”,观察上机界面,有无可用机器,按说 明操作上机,连续上机3次,第一次正确输入,第二次输入不存在的 卡号,第三次输入错误口令;进入“下机”界面,看有无正确的上机, 连续下机两次。观察输出信息界面,看内容是否正确(金额、卡号, 时间,费用)。已下机器是否已被同步从上机下拉表中清除。再进入 “上机”,比对可选空闲机器是否正确,输入已上机用户的卡号,观 察结果;输入卡金额不足的卡号,观察结果;不输入任何值,直接按 确认的结果。2统计测试,进入“
12、统计”功能,按日,月,年查询统计,与库中实 际数据比对,不同日、月、年分别查2次3进入“卡维护”,进入“卡充值“,输入余额不足卡号,给卡充值, 进入“信息浏览”,查看卡充值是否正确,并以此卡号上机;再进入“卡维护”的“信息浏览”,查看记录;然后选“删除卡”,连续删2 张卡,应不能删除在线卡,并能标识出卡余额,以便清帐;进入“信 息浏览”,查看记录是否已被正确删除。正在上机的不能被删除。选“修改密码”,输入正确的用户名、口令,修改成新口令;进入“信 息浏览”,查看口令是否已更改;进入“上机”,以新口令上机。4同3测试“机器维护”中的删除机器功能,应不能删除在线机器5测试“费率维护”,退出程序,重
13、启动,进入“费率维护”修改费 率,上下机,观察费用计算结果。6测试超时报警功能:发一张新卡,初始额刚达到最低标准,以此卡 上机,为缩短超时等待时间,可设置定时器间隔为1分钟,等待2分 钟,看系统是否能正确报警。7测试帮助功能。按照帮助说明使用系统,验证帮助说明的正确性。1.3系统设计1.3.1总体设计一.系统体系结构SQL一般要确定系统的体系结构,主要模块,系统运行环境(如操作 系统、数据库),开发平台及语言。本系统主要运行在windows系列 平台上,数据库使用ACCESS,使用eclipse开发系统。采用两层C/S 体系结构。系统体系结构图如下图所示:服务端客户端图1系统体系结构客户端分3
14、层,图形界面层(采用java的SWING设计)负责与用户 交互,业务逻辑层则根据用户的请求执行各种功能(如上、下机等), 数据访问层主要根据业务逻辑层的请求通过JDBC/SQL存取数据库。 数据库使用ACCESS,可根据情况使用其他数据库(如SQLServer), 客户端基本不做修改,仅有的少量修改也只在数据访问层。客户端与 服务端在物理上可以运行在一台机器上,也可以分别运行在不同机器 上。.系统功能模块及主要类系统的主要功能模块如图2 所示:系统模块图图2可据此设计菜单,划分模块。系 统 主 要 类 图如下CnRg6 ckhsklrljnrec: Rwordiri Eomputer: Ccm
15、pulEf) ydk!6 doCh&OJ:(irirec: Rword): icoid6 c=lF&e():出诚n FE-mVE; String4 g=fP=irarnelsrO SiringMeagerRecord0 id : 9:rrg paEEvgd s 5lrhg bialiciri:e: fb*Cardmputer id : StringQ EtilUE : IN:ci rule: 5h-ng statiE; irt username SiringwiiseI H : StririgII c csrdd : Siringci campderti: Sbing;:甲lennc begn
16、li : Dalec endime : W 桓际! Float;j F;。:十廿* usern-sme: Slrrm p 必Ed: SlrriGFWUE 曾ManaqefDAOCirJDAQCoHirierDM)C queryCardjnid : Slrirg): Card C updahCardjncard): udd addCardjn card): ijcid C ddCardjnid: Sring): uoid QiiEUJid(riQrd : Card) : toolen Qi期新Mefingrd : Card): IxnlenqueryCtflipJ:Gf(iri d: Sirin
17、g : ConpjberQupd”电匚HYipis1:in carrpdter : Gcxrpjlr) w丽 -=iddCDmpd:in DDrmpiier: Corpuler): radQ ddCtxnFdtertri ti: String): vixlgeHdleCcxYipiE) : MgLidQilJEe(in c cm pda-: CbmpulBr): bcnleETi::4uEe::-::-DBCMMnHtiDiiG CamsumeDitspihylnFo0 recCTd s RKOtd0 card s CardRecDrd&AOQ querRecardin d: Shing) R
18、ecord尊 upd女Reccirdl:iri r&c : kecard) : void尊 aiddRjecordfin rec : torrpler): vodQ checkJrB|in record: RecDrdjnccnpier : ompiier): void6 checkOiJDBIin record Recordjn cjrd : Cad): mdA getCnUE8fl.8Cfd: PmijLisIQ getCheckCuIRjecordO:匚exyicuyi心目曲InFo CflT;EI:. CLfi5S! Sirin: D.TA50UkZ: String信 qebniier
19、i:ion:l;匚口nriedioi9 thseCawdiixidntcm : Oonnedipri:wckl总类图的画法基本遵循视图层、业务逻辑层、数据模型及数据库 访问层的自上而下的顺序,其中视图层中的视图因为较多未画出,主 要的业务逻辑控制类是BusinessManager,用户的上下机请求,通过 界面的事件机制,在事件处理程序中会调用BusinessManager中的方 法,然后再调用xDAO类方法,在xDAO类中一般先通过DBConnection 获取连接,再通过 JDBC/SQL 访问数据库。 CardComputerRecordManager类是值对象”,主要是存放相应的 属性,
20、方法也是setXgetX类方法,“值对象”常作为参数在各种方 法中传递。三.经验共享1客户端基本采用三层结构(视图View、控制Controller、模型 Mode),层与层间耦合性较小,提高了整体的可扩展性、可重用及抗 变动能力。缺点是要求预先设计好,对设计水平要求高,不过一旦形 成模式,养成习惯,能“照葫芦画瓢”,也是提高设计水平的捷径。2使用xDAO类将业务逻辑和数据库访问隔离,只要xDAO对上提供的 接口不变,以后数据库存取代码发生改变也不会影响上层代码(如业 务逻辑层)。接口中的参数主要是“值对象”,这样即使 CardComputerRecordManager类中的属性发生改变,由于
21、值对 象”的封装,对接口的影响也不大,缺点是如果“值对象”本身很大, 而又只用到其中很少的属性,则对性能和内存浪费较大。与此对应, 比较一般的设计是在事件处理代码中就实现业务逻辑(如验证、计算、 上下机)、获取数据库连接并通过JDBC访问数据库,这样做的好处是实现较容 易、符合一般过程性思维(常用于初始的或原型系统的开发中),缺 点是代码一旦需要修改,则改动较多、且容易出错,代码重用性差。3使用DBConnection类统一完成连接的获取和释放,好处是连接部 分代码可重复使用,如果连接参数(如连到不同的数据库)改动,只 需更改DBConnection类中的相关参数属性(当然更好的做法是将这 些
22、连接参数放在配置文件中,这样可以只修改配置文件,无需修改程 序),另外还可以为了提高性能扩展成“连接池”,同时对使用它的 xDAO类没有影响。1.3.2详细设计详细设计主要是关注模块一级的设计,一般有界面,核心算法及 处理流程,数据库表(表、属性及表间关系)的设计。由于模块较多, 下面选择几个典型模块分析设计,其中“经验共享”,揭示难点的同 时,也介绍了相应的解决方法及设计经验。1.3.2.1数据库设计数据库设计主要是根据分析和概要设计中发现的对象和类,确定 哪些对象需要持久保存,然后将对象属性及对象间关系转化成关系 表。经过分析Card、Computer、Record、Manger需要保存在
23、数据库 中,将Config参数配置信息保存在文件中。其中Card、Computer、 Record的关系如下图所示:图持久对象属性及关系图一条Record记录必有对应的一个Card及一台Computer,对于未用 机器及卡,则没有对应的记录。将其转换为关系表时,关键是在Record 中设置CARDID,COMPUTERID作为外键指向Card和Computer。共设计 出四张表:1. CARD 表名称编码数据类型卡号ID (主键)VARCHAR(20)用户名USERNAME (非空)VARCHAR(20)密码PASSWORD (非空)VARCHAR(15)卡状态STATUS (非空)INTEG
24、ER余额BALANCE (非空)DOUBLE2. COMPUTER 表名称编码数据类型机器号ID (主键)VARCHAR (10)状态STATUS (非空)INTEGER备注NOTESVARCHAR( 200)3. RECORD 表名称编码数据类型记录号ID (主键)VARCHAR(20)卡号CARDID (非空)VARCHAR(20)机器号COMPUTERID (非空)VARCHAR(10)上机时间BEGINTIME (非空)DATE下机时间ENDTIMEDATE上机费用FEEDOUBLE4. Manager 表名称编码数据类型用户名USERNAME (非空)VARCHAR(20)口令PAS
25、SWORD (非空)VARCHAR(20)经验共享:数据库设计一般相对独立,采用的主要方法是将对象模型 转化为数据库关系模型,也可以采用传统的设计出E-R图,再定关系 表的方法。即使是简单数据库的设计若从实用角度出发也需要考虑多方面的问题。首先基本的是确定有哪几张表,表间关系,然后是表中 的字段,比较麻烦的是确定字段的约束(主键、非空等),字段数据 类型,范式的调整等,因为此时会考虑到存储空间、性能、易编程、 数据质量等方面的因素。如定义“用户名”字段要有多大,就需要在存储空间节省和适应 性间权衡,定义的较小,遇到长名字的情况,程序不能适应;定义的 过大,对于大多数情况可能又会浪费存储空间,一
26、般宁愿定义的大些, 以空间换取适应性。再比如确定哪些字段为“非空”,从编程角度看必须保证“非空” 字段有值,这会增加验证“非空”字段程序的代码量,对用户的约束 也加强,有些值要求用户必须输入,如口令就不能为空。但若允许字 段可以为“空”,如机器状态字段,则机器的当前状态就可能难以确 定,影响数据质量。一个基本的方向是“约束”多,则编程的代码量 会变大,性能会下降,但数据的质量会得到提高。在Record表中“下 机时间”和“上机费用”没有定义为“非空”,是因为上机时这 两项不能确定,只能填写部分上机记录信息。一般数据库表结构的变动对于程序的影响较大,在程序设计上可 通过xDAO类尽量消减变动的影
27、响,在实现阶段应避免对数据库结构 大的改动。1.3.2.2上机模块设计界面设计主要是根据功能要求构建界面,界面中的每个元素均应 有其作用,以支持功能的实现,界面设计还要考虑到界面风格的一致、 符合一般window应用GUI的规范。设计应简洁实用,避免在细节上(如字体、颜色)耗费时间。上机模块参考界面如图4所示:图4参考界面二上机流程1初始化(1)显示界面(2)获取空闲机器(3)将空闲机器号加入下拉列表2上机处理过程:(1)验证机器号、卡号、密码是否为空(2)根据卡号、密码获取卡对象(3)若卡对象为空则说明卡号或密码错,给出提示“卡号或密码错”,要求重输(4)判断卡状态,若卡正在使用则给出提示“
28、不能一卡多用”(5)计算卡中余额,若低于设定值,则提示“余额不足”(6)修改卡状态为在用,修改机器状态为在用,获取上机时间,将上机时间、机器号、卡号保存到记录对象,再通过 RecordDAO在库中添加一条新上网记录。(7)提示上网成功三经验共享1上机处理中的第6步要在一个完整的“事务”中完成,对卡、记录、 机器数据的更改添加要保证要么全部更改成功,要么都不更改,以保 证数据的一致性。2费用计算是按时段计算的,需要考虑跨时段费用如何计算,另外为 了降低复杂性,可规定时段只能为三段,时间精确到分,费用精确到 角。3记录ID如何保证唯一且自动增长。基本有两种:一是编程控制, 插入新记录前获取当前最大
29、记录号,通过select max(id) fromrecord,加1后,将ID及其它信息写入,若有多用户访问该表,则 上述过程要放在一个“事务”中。二是利用关系数据库提供的“自增 字段”特性,将ID设置成“自增字段”,由数据库负责每添加一条记 录就将ID加1。1.3.2.3下机模块设计下机模块主要根据用户请求(报出卡号/机器号),管理员根据卡 号/机器号执行下机操作,参考界面如图5所示,大的文本空白文本 框用于显示下机记录信息。当然还有其它的设计方式,如显示当前上 机的所有记录信息,选中其中一条执行下机操作。图5下机模块界面二下机流程1管理员输入机器号或卡号,请求下机2系统获取机器号,据机器号
30、获取相应记录对象,要处理机器号错 误的情况3系统根据记录对象获取该记录对应的卡对象4系统计算费用,并比较卡对象余额,若不够则提示“余额不足” 并显示余额5系统从卡中扣费,修改卡状态为“空闲”系统修改该机器的状 态为“空闲”;系统更新记录信息(下机时间、费用)。6系统显示本次上网完整的记录(Record)信息及卡余额,并提示 下机成功注:下机处理4中修改三表的操作应作为一个“事务”完成。1.3.2.4发新卡模块设计一界面设计发卡需要输入卡号、用户名、密码、金额,参考界面如下图所示。界面设计布局应简洁一致,从用户友好性出发,提供了输入提示,增 加了 “确认密码”,以提醒用户记住密码,输入的密码辱号
31、显示以提 高安全性。虽然有了提示但在代码中仍需对输入进行验证,如金额不 能为负值,以避免误输及恶意输入。当然从口令强度考虑,要求密码 只输入数字和字母又是不妥的,相反可提示用户输入特殊字符及输入 的最小字符数。所以此界面虽简单,但已涉及到界面的视觉风格、用 户 友 好 性、 安 全 性 考 虑。图发卡界面二发卡流程1系统从界面获取所有信息,依次判断是否为空2判断金额是否大于03判断密码和确认密码是否一致,4判断密码和用户名是否在最小及最大长度之间5判断卡号是否有效(唯一)6生成Card对象,请求CardDao向Card表中添加一条新记录。7提示卡添加成功,并显示卡号和金额三经验共享1输入数据的
32、验证是难点,验证输入数据是保证程序可靠性的重要措 施,例如:若不限制用户或口令长度在相应数据库表字段设定的范围 内,一旦将超长的用户名写入数据库则会产生数据被截断或数据库异常,而这完全可以在用户输入时予以控制。验证输入数据的难点之一 在于在验证的代码量和限制大多数常见错误间取得平衡,过多地验证 代码无疑会增加编码量和难度,但没有验证或很少验证又使程序可靠 性太差而难以实用。但也有一些常规经验可循,如是否限定字符数据 的长度,验证是否为空、数字数据是否在范围内等,有些输入控件提 供了限定输入长度等功能,应该充分利用以减少编码量。一般验证可遵循如下策略:输入前提示如何输入,输入后验证, 验证不通过
33、则再提示(如通过对话框)。输入验证的时机:可以在输 入一项后立即验证该项输入是否合法,也可以全部输完后再逐项验 证,某项若验证不通过,除给出提示,从用户友好性角度,还可以将 焦点定位到出错项(缺点是代码复杂性增加)。验证通过后的数据在 程序内部传递时,一般无需重复验证。2卡号的获取。最基本的方式由管理员手工编号并保证卡号的唯一 性,但卡一旦多了,这会成为管理员的负担,因此,可以由系统自动 编号,如规定卡号从1依次递增编号,这样卡号就无需输入。可在每 次增加新卡时,从卡表中获取最大ID,加1后作为新增卡的卡号。也可以获取当前时间转化成字符串作为ID,一般时间不会重复,可 保证ID唯一,优点是生成
34、ID无需访问数据库,还可以代表发卡时间。1.2.3.5删除卡模块设计*界面设计删除卡参考界面如下图所示:图删除卡界面二删除卡流程1管理员输入卡号2系统根据卡号,请求CardDAO查询有无该卡3若返回的卡对象存在,则执行下一步,否则提示“卡号错误”, 要求重输。4系统从Card查询卡状态5若为“在用”,则提示“不能删除在用卡”6查询余额,若有则对话框提示“请结清余额”7若余额已结清且状态为“空闲”,则将该卡信息删除8系统提示删除成功三经验共享1如何删除卡:一种是真删,卡记录信息从数据库中永久删除,采 用delete from where语句,此时还要注意,由于Record中有指向Card表的外键
35、,删除涉及到“级连删除”这一概念,即在Record中 包含该卡号的记录是否要一起删除。一般不允许“级连删除”,因为 Record中记录是统计费用的基本依据,删除后会使统计数据失真。 还有一种是假删,即标注卡状态信息为“停用”,只需用update语句 更改其状态即可,这样做好处是:一是可以完整保留已发卡信息,二 是易于重新恢复已删卡。坏处是:若有大量卡(数以十万计)长期不 用,会占用数据库空间,影响访问卡表的性能。2 一般数据库中数据删除后难以恢复,同时难以避免因为意外导致 的数据损坏,因此重要数据的保存备份必不可少,本系统没有要求做 数据备份功能,因为数据库管理工具一般会提供相应功能,只是要求
36、 用户会使用数据库管理工具,所以从方便用户使用考虑,程序本身提 供备份(手动或定期自动备份)功能也是必要的。1.4系统实现系统实现主要运用集成开发环境、Java、数据库工具根据设计制 做出实际的界面,编写代码,生成数据库表,进行测试,这也是初级 程序员所要完成的主要任务,在此列出部分典型代码,仅供参考。1.4.1数据库访问对数据库的基本操作是:增、删、改、查,数据库连接的建立、关闭,其中的难点是访问数据库的异常处理和参数化SQL,现举例如下:1获取连接的代码:private static final String DRIVER_CLASS =sun.jdbc.odbc.JdbcOdbcDriv
37、er; /定义驱动类private static final String DATASOURCE =jdbc:odbc:NetBarDataSource; /定义 ODBC 数据源public static Connection getConnction() Connection dbConnection = null;try Class.forName(DRIVER_CLASS);dbConnection=DriverManager.getConnection(DATASOURCE); catch (Exception e) e.printStackTrace();return dbConn
38、ection;该 代 码 针 对 JdbcOdbcDriver 驱 动,ODBC 源名为NetBarDataSource,未支持口令验证。2查询代码:下面是根据用户名和口令验证卡是否有效的代码,需要注意的是 查询参数值需要加单引号:/* judge card is valid or not.* param card Card* return boolean*/public boolean isValid( Card card) boolean isValid = false;Connection dbConnection = null;PreparedStatement pStatement
39、= null;ResultSet res = null;try dbConnection = ConnectionManager.getConnction();/构建查询SQL语句String strSql = select * from card where id= + card.getId()+ and password = + card.getPassword() + ;if (dbConnection != null) System.out.println(dbConnection != null);/查询操作pStatement = dbConnection.prepareState
40、ment(strSql);res = pStatement.executeQuery();/执行 SQL 语句,并返回 结果if (res.next() /若res有记录说明卡存在isValid = true; catch (SQLException sqlE) sqlE.printStackTrace(); finally ConnectionManager.closeResultSet(res);/关闭结果集ConnectionManager.closeStatement(pStatement);ConnectionManager.closeConnection(dbConnection)
41、; /关 闭连接return isValid;3更新代码下面是更新机器状态的代码,其中SQL语句中,“id = (?) ”是动态参数,具体值设置在 pStatement.setString(1, computer.getId() /* record the computer have used.* param computer Computer*/public void updateOnUse( Computer computer) Connection dbConnection = null;PreparedStatement pStatement = null;try String str
42、Sql =update computer set Status =1 where id =(?); ; pStatement = dbConnection.prepareStatement(strSql); pStatement.setString(1, computer.getId(); /设置机器号id参数pStatement.executeUpdate(); catch (SQLException sqlE) sqlE.printStackTrace(); finally ConnectionManager.closeStatement(pStatement);ConnectionMan
43、ager.closeConnection(dbConnection);1.4.2下机模块在BusinessManager类中有一 doCheckOut ()方法是实现下机 过程的关键。/* do check out business.* param rec Record,已有机器号值* return ComsumeDisplayInfo含有上机记录、对应卡记录*/public static ComsumeDisplayInfo doCheckOut( Record rec) RecordDAO dao = new RecordDAO();/获取包含了下机记录及对应卡信息的ComsumeDisp
44、layInfoComsumeDisplayInforesult=dao.getStopCompouterRelationlnfo(rec);Record record = result.getRecord();Card card = result.getCard();/计算本次上机的费用int fee = calFee(record.getBeginTime(), record.getEndTime();record.setFee(fee);/计算余额int balance = card.getBalance() - fee;card.setId(record.getCardId();card
45、.setBalance(balance);/将数据写入数据库RecordDAO dao2 = new RecordDAO();dao2.doCheckOutDB(record, card);/返回含有上机记录、CARD记录的ComsumeDisplayInfo,供界面显 示下机结果result.setRecord(record);result.setCard(card);return result;1.4.3上机模块处理请求上机的部分代码如下,主要有界面数据(机器号、密码、 卡用户号)验证代码;卡有效性、余额可用性验证。/* deal business about click confirm button.* param e ActionEvent*/void confirmButton_actionPerformed(ActionEvent e) String cardId=;String passwordtemp = ;String computerld =;获取机器号,并去掉空格cardId = cardIdTextField.getText().trim();/获取密码for(int i=0;ipasswordFiled.getPassword().length;i+)passwordtemp += pa
链接地址:https://www.31ppt.com/p-4885659.html