JAVA毕业课程设计网吧管理系统.docx

JAVA毕业课程设计网吧管理系统.docx

《JAVA毕业课程设计网吧管理系统.docx》由会员分享，可在线阅读，更多相关《JAVA毕业课程设计网吧管理系统.docx（29页珍藏版）》请在冰豆网上搜索。

JAVA毕业课程设计网吧管理系统

Java课程设计指导书（学生版初稿）

第一章网吧计费管理系统

目标

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展望

第一章网吧计费管理系统

学习目标：

能使用Java集成开发环境,运用Swing设计图形界面，运用JDBC访问数据库，掌握事件处理编程，了解简单两层CS项目的开发及简单面向对象程序的设计过程，发展基本的团队协作开发能力。

学习寄语：

虽然本项目并不是一个商业项目，其产品也不能用来赚钱，但从中你可以学到实际开发中的许多经验和技巧，获得一种“学有所用”、“学有所得”的成就感，同时赢得老师和同学（同事）对你的格外尊重。

在此项目的学习中，你不但是个学生，还是一个职业人，将与同事一起尽全力完成你所要做的工作，并再次验证“天道酬勤”的真理。

我们的信念是：

“不抛弃，不放弃”。

你的改变和收获是老师真诚的期待。

1.1背景介绍

1.1.1业务背景

“海之星”网吧，是一个小型网吧，以前是人工记帐，现需要开发一个简单的网吧计费管理系统。

原人工管理的主要过程如下：

客户在门口服务台，出示上机卡，若是新客户则先发新卡；管理员先查询是否有空机器，若有则根据上机卡号查到该卡对应的记录（账簿），若有余额（〉5元），则分配一个空闲的机器号给客户，客户根据机器号对号入座，管理员记下客户卡号、上机机器号、上机时间。

客户下机要到门口的服务台，请求下机，管理员根据当前时间、上机时间及费率计算出本次上机费用，并记录，同时将费用从卡余额中扣除，若费用不够则需充值。

原手工系统主要有如下缺点：

1手工记帐，管理员工作量大，且易出错；2超时超费使用不能及时发现。

因此需要开发一个简易计费管理软件，取代人工记帐方式，由软件统一管理记录上下机、计费、上机卡、机器情况，提供简单统计功能，超时超费提醒功能等。

1.1.2技术背景

本系统要求使用java技术开发，使用数据库（如ACCESS，SQLServer）保存数据，集成开发环境可使用支持可视化GUI界面设计的主流工具（如eclipse\antbean\jbuilder）。

开发者应有java程序设计语言、SWING基本GUI组件、文件使用、JDBC存取数据库、使用一种集成开发工具的基本知识和技能。

系统采用两层CS体系结构，C端负责通过GUI与管理员交互、处理业务逻辑及存取数据库，S端主要是数据库系统。

系统分析设计主要采用面向对象的分析设计方法。

友情提示：

对项目有了一个最基本的认识后，是不是立即准备大干一场？

是否要问一问值不值得干？

能不能干？

商业项目一般可以从经济性、技术性、法律社会等方面进行可行性分析，但本项目作为一个学习型项目显然无利可图、技术也欠缺（事实上技术正是要学习的东西）、好在项目是合法的。

那是否继续？

当然！

因为本项目的目标不是在合法的前提下获取最大利润，而是习得知识和技能，只要你愿意，就可以继续进一步了解“网吧计费管理系统”，Let’sgo!

1.2需求分析

1.2.1功能需求分析

系统需求分析的主要任务是从用户角度考察系统应具有哪些功能及非功能性需求，对于网吧计费管理系统，用户主要是指系统管理员，系统的主要功能是：

登录、上机、下机、卡管理（发卡、删卡、充值、查询）、机器管理（添加机器、删除机器、查询状态、修改状态），统计功能（日、月费用统计），口令管理（添加用户、删除用户、修改口令），参数设置（时段费率），使用帮助。

主要使用流程是：

管理员登录，根据客户请求上机，根据客户请求下机。

主要功能的用例（usecase）描述如下：

一上机

1管理员输入空闲机器号，上网人输入口令、卡号，请求上机。

2系统验证卡号，检查卡中余额，卡状态

3系统获取当前系统时间作为上机开始时间

4系统修改该机器的使用标志为“在用”，卡标志为“在用”。

5系统记录上机信息（卡号、机器号、上机时间）

6系统提示上机成功

若1中无空闲机器又请求上机的，系统提示“没用空闲机器”，

2中卡验证未通过，提示“无此卡号”，余额不足，提示“余额不足”，卡状态为“在用”，则提示“不能一卡多用”。

二下机

1管理员选择被使用的机器号，请求下机

2系统获取系统当前时间作为下机时间；

3系统计算费用；

4系统显示应缴费用

5系统记录下机时间和此次费用；

6系统从卡中扣费，修改卡状态为“空闲”；

7系统修改该机器的状态为“空闲”；

8系统显示本次上机记录信息，提示下机成功

三登录

1管理员输入用户名和密码，请求进入系统

2系统验证用户名和密码

3系统显示主界面

若一次验证不通过，则提示再输入一次，仍不通过则系统退出。

四卡维护

卡有三种状态：

停用、空闲、在用。

发新卡：

1管理员输入卡号（保证卡号唯一）

2管理员输入卡初始金额

3上网人输入用户名、口令

4管理员请求添加新卡

5系统保存卡号、金额、用户名和密码，状态为“空闲”

6系统提示添卡成功，显示卡号及金额，以便核对。

7管理员将系统生成的有卡号、用户名的纸卡给上网人。

充值：

1管理员输入卡号

2系统显示该卡信息（卡号、用户名、余额、状态）

3管理员核对后，输入充值金额

4系统计算并保存该卡总金额

5系统显示充值后的卡信息（卡号、用户名、余额、状态）。

查询卡信息：

1管理员输入卡号或请求察看所有卡信息

2系统查询卡信息（卡号、用户名、余额）并显示

删除卡：

1管理员输入卡号

2系统查询卡余额及状态

3若余额已结清且状态为“空闲”，则将该卡信息删除

4系统提示删除成功

若有余额或“在用”则不能删除

五机器维护

机器有三种状态：

停用、空闲、在用。

添加机器：

1管理员输入机器号，请求添加

2系统验证机器号是否重复

3系统添加机器记录信息（机器号、状态为“空闲”）

4系统提示添加成功

删除机器：

1管理员输入机器号，请求删除

2系统删除相应机器信息

3系统提示删除成功

查询机器状态：

1管理员输入机器号或请求察看所有机器信息

2系统查询并显示机器信息（机器号和状态）并显示

六管理员口令管理

添加用户

1管理员输入用户名、密码和确认密码，请求添加

2系统验证用户是否是新用户，两次输入的密码是否相同

3系统添加用户、密码信息

4系统提示添加成功

删除用户

1管理员输入用户名、密码

2系统验证用户名、密码是否正确

3系统删除用户名、密码记录

4系统提示删除成功

修改密码

1管理员输入用户名、密码，请求修改密码

2系统验证用户名、密码是否正确

3管理员输入新密码、及确认密码

4系统保存新密码

5系统提示修改成功

七统计管理

1管理员输入起始时间（年、月、日），结束时间,请求按日、月、年汇总

2系统查询上网记录，计算、统计出时间段的总费用、人次、总上机时间等信息。

3系统显示上述信息

八参数管理

时段费率设置：

0系统显示当前设置

1管理员设置时间段（时、分）及对应的费率，请求保存

2系统保存设置

3系统提示保存成功

超时报警定时器间隔设置

九超时超费报警

1设置定时器为周期触发方式，触发间隔由参数获得，默认为30分钟

2定时器到时，系统查询当前正在上机的记录，计算其上机时间及费用，计算其卡中余额是否低于最低费用。

3系统提示已超费卡号、机器号，及超的费用

本系统除了功能性需求，还有易用性、可靠性、安全性等要求，可以在实现上述功能性需求的基础上，进一步实现完善非功能性要求。

友情提示：

本文使用“用例”法分析功能性需求，属于面向对象分析（OOA）法，其实质就是从用户角度，通过观察、与用户交谈等方式，记录下用户希望如何使用系统，系统相应需要实现哪些功能。

分析用户需求一般由系统分析人员完成，其核心能力是熟练掌握业务领域的知识和沟通的技巧，需求分析的最大难点在于需求的可变性，最令开发人员气馁的莫过于辛苦设计实现了一个功能，用户突然说不需要这个功能了，另一个常见的问题是隐蔽性的需求（行业惯例、日常规则）常被用户和分析人员忽略。

不同的需求对于客户而言重要性是不同的，一般需要对需求划分优先级，优先级高的优先设计实现。

你能否从上述一到九大用例描述中找出哪些用例是高优先级的？

1.2.2业务对象分析

根据上面的主要用例描述，可以分析出系统的主要业务对象，它是设计阶段核心类图的基础（不一定一一对应），这些对象必须实际存在，其行为和属性应与问题领域相关：

1上网卡：

主要维护上网卡的相关信息。

卡号、密码、余额、卡用户名、卡状态（在用、空闲、停用）

2机器：

主要维护上网吧计算机的相关信息。

机器号、使用标志（在用、停用、空闲）、备注

3费用记录：

记录每次上机的信息。

记录编号、卡号、机器号、开始上机时间，下机时间、费用

4费率记录：

起始时间、终止时间，费率

5管理员：

利用1—4完成各种业务操作。

1.2.3验收测试要求

用户要求开发产品，产品开发完成后，需要交付用户验收，验收要求常常是合同中的重要组成部分，这是一个必经的环节，主要思路是按照用户使用的过程测试系统，越频繁使用的功能越要多测试。

本系统功能性需求验收测试的基本要求如下：

前置条件：

1除口令表有初始用户名和密码外，各库表为空。

2程序安装配置正确，能正常启动运行。

一初始化数据

1启动程序，进入“卡维护”，选“发新卡”，输入一条数据记录，退出，进入“信息浏览”，查看记录是否已被正确加入；退出“信息浏览”，再进入“发新卡”，连续发3张卡，其中有张卡余额为0；再进入“信息浏览”，查看记录是否已被正确加入。

2同理按1，添加机器。

3进入“费率维护”，设置费率。

二功能测试

1上下机测试。

进入“上机”，观察上机界面，有无可用机器，按说明操作上机，连续上机3次，第一次正确输入，第二次输入不存在的卡号，第三次输入错误口令；进入“下机”界面，看有无正确的上机，连续下机两次。

观察输出信息界面，看内容是否正确（金额、卡号，时间，费用）。

已下机器是否已被同步从上机下拉表中清除。

再进入“上机”，比对可选空闲机器是否正确，输入已上机用户的卡号，观察结果；输入卡金额不足的卡号，观察结果；不输入任何值，直接按确认的结果。

2统计测试，进入“统计”功能，按日，月，年查询统计，与库中实际数据比对，不同日、月、年分别查2次

3进入“卡维护”，进入“卡充值“，输入余额不足卡号，给卡充值，进入“信息浏览”，查看卡充值是否正确，并以此卡号上机；再进入“卡维护”的“信息浏览”，查看记录；然后选“删除卡”，连续删2张卡，应不能删除在线卡，并能标识出卡余额，以便清帐；进入“信息浏览”，查看记录是否已被正确删除。

正在上机的不能被删除。

选“修改密码”，输入正确的用户名、口令，修改成新口令；进入“信息浏览”，查看口令是否已更改；进入“上机”，以新口令上机。

4同3测试“机器维护”中的删除机器功能，应不能删除在线机器

5测试“费率维护”，退出程序，重启动，进入“费率维护”，修改费率，上下机，观察费用计算结果。

6测试超时报警功能：

发一张新卡，初始额刚达到最低标准，以此卡上机，为缩短超时等待时间，可设置定时器间隔为1分钟，等待2分钟，看系统是否能正确报警。

7测试帮助功能。

按照帮助说明使用系统，验证帮助说明的正确性。

友情提示：

测试是保证程序质量的基本手段，一般可分为单元测试、集成测试、系统测试、验收测试，其中验收测试一般由用户在真实的运行环境下测试系统，是用户确认系统符合要求的关键环节，你开发的系统必须通过上述最基本的验收测试。

并不是整个系统完成后才可以进行上述测试，完成相应模块后就可以有针对性地测试，验收测试的内容经过分解后是单元测试、集成测试、系统测试的基本依据，测试工作并不是从编码时才开始的，在需求分析阶段就已展开（如根据用例提出验收测试要求）。

有的IT公司内部的质量部门在产品正式交付用户前，也会做类似的测试，以保证用户验收时一次通过。

1.3系统设计

1.3.1总体设计

一系统体系结构

一般要确定系统的体系结构，主要模块，系统运行环境（如操作系统、数据库），开发平台及语言。

本系统主要运行在windows系列平台上，数据库使用ACCESS,使用eclipse开发系统。

采用两层CS体系结构。

系统体系结构图如下图所示：

图1系统体系结构

客户端分3层，图形界面层（采用java的SWING设计）负责与用户交互，业务逻辑层则根据用户的请求执行各种功能（如上、下机等），数据访问层主要根据业务逻辑层的请求通过JDBCSQL存取数据库。

数据库使用ACCESS，可根据情况使用其他数据库（如SQLServer）,客户端基本不做修改，仅有的少量修改也只在数据访问层。

客户端与服务端在物理上可以运行在一台机器上，也可以分别运行在不同机器上。

二系统功能模块及主要类

系统的主要功能模块如图2所示：

图2系统模块图

可据此设计菜单，划分模块。

系统主要类图如下：

图3

总类图的画法基本遵循视图层、业务逻辑层、数据模型及数据库访问层的自上而下的顺序，其中视图层中的视图因为较多未画出，主要的业务逻辑控制类是BusinessManager，用户的上下机请求，通过界面的事件机制，在事件处理程序中会调用BusinessManager中的方法，然后再调用xDAO类方法，在xDAO类中一般先通过DBConnection获取连接，再通过JDBCSQL访问数据库。

Card\Computer\Record\Manager类是“值对象”，主要是存放相应的属性，方法也是setX\getX类方法，“值对象”常作为参数在各种方法中传递。

三经验共享

1客户端基本采用三层结构（视图View、控制Controller、模型Mode），层与层间耦合性较小，提高了整体的可扩展性、可重用及抗变动能力。

缺点是要求预先设计好，对设计水平要求高，不过一旦形成模式，养成习惯，能“照葫芦画瓢”，也是提高设计水平的捷径。

2使用xDAO类将业务逻辑和数据库访问隔离，只要xDAO对上提供的接口不变，以后数据库存取代码发生改变也不会影响上层代码（如业务逻辑层）。

接口中的参数主要是“值对象”,这样即使Card\Computer\Record\Manager类中的属性发生改变，由于“值对象”的封装，对接口的影响也不大，缺点是如果“值对象”本身很大，而又只用到其中很少的属性，则对性能和内存浪费较大。

与此对应，比较一般的设计是在事件处理代码中就实现业务逻辑（如验证、计算、上下机）、

获取数据库连接并通过JDBC访问数据库，这样做的好处是实现较容易、符合一般过程性思维（常用于初始的或原型系统的开发中），缺点是代码一旦需要修改，则改动较多、且容易出错，代码重用性差。

3使用DBConnection类统一完成连接的获取和释放，好处是连接部分代码可重复使用，如果连接参数（如连到不同的数据库）改动，只需更改DBConnection类中的相关参数属性（当然更好的做法是将这些连接参数放在配置文件中，这样可以只修改配置文件，无需修改程序），另外还可以为了提高性能扩展成“连接池”，同时对使用它的xDAO类没有影响。

友情提示：

如果你不能理解上述描述，也不必担心，按照你的直觉去开发系统，如果你一帆风顺，那么你肯定是这方面的天才，如果遇到各种问题，上述的文字可供参考，同学之间可以互相交流，老师也乐意为你效劳，勤思、善问、实干是快速提高水平的不二法门。

1.3.2详细设计

详细设计主要是关注模块一级的设计，一般有界面，核心算法及处理流程，数据库表（表、属性及表间关系）的设计。

由于模块较多，下面选择几个典型模块分析设计，其中“经验共享”，揭示难点的同时，也介绍了相应的解决方法及设计经验。

1.3.2.1数据库设计

数据库设计主要是根据分析和概要设计中发现的对象和类，确定哪些对象需要持久保存，然后将对象属性及对象间关系转化成关系表。

经过分析Card、Computer、Record、Manger需要保存在数据库中，将Config参数配置信息保存在文件中。

其中Card、Computer、Record的关系如下图所示：

图持久对象属性及关系图

一条Record记录必有对应的一个Card及一台Computer，对于未用机器及卡，则没有对应的记录。

将其转换为关系表时，关键是在Record中设置CARDID,COMPUTERID作为外键指向Card和Computer。

共设计出四张表：

1.CARD表

名称

编码

数据类型

卡号

ID（主键）

VARCHAR（20）

用户名

USERNAME（非空）

VARCHAR（20）

密码

PASSWORD（非空）

VARCHAR（15）

卡状态

STATUS（非空）

INTEGER

余额

BALANCE（非空）

DOUBLE

2PUTER表

名称

编码

数据类型

机器号

ID（主键）

VARCHAR（10）

状态

STATUS（非空）

INTEGER

备注

NOTES

VARCHAR（200）

3.RECORD表

名称

编码

数据类型

记录号

ID（主键）

VARCHAR（20）

卡号

CARDID（非空）

VARCHAR（20）

机器号

COMPUTERID（非空）

VARCHAR（10）

上机时间

BEGINTIME（非空）

DATE

下机时间

ENDTIME

DATE

上机费用

FEE

DOUBLE

4.Manager表

名称

编码

数据类型

用户名

USERNAME（非空）

VARCHAR（20）

口令

PASSWORD（非空）

VARCHAR（20）

经验共享：

数据库设计一般相对独立，采用的主要方法是将对象模型转化为数据库关系模型，也可以采用传统的设计出E-R图，再定关系表的方法。

即使是简单数据库的设计若从实用角度出发也需要考虑多方面的问题。

首先基本的是确定有哪几张表，表间关系，然后是表中的字段，比较麻烦的是确定字段的约束（主键、非空等），字段数据类型，范式的调整等，因为此时会考虑到存储空间、性能、易编程、数据质量等方面的因素。

如定义“用户名”字段要有多大，就需要在存储空间节省和适应性间权衡，定义的较小，遇到长名字的情况，程序不能适应；定义的过大，对于大多数情况可能又会浪费存储空间，一般宁愿定义的大些，以空间换取适应性。

再比如确定哪些字段为“非空”，从编程角度看必须保证“非空”字段有值，这会增加验证“非空”字段程序的代码量，对用户的约束也加强，有些值要求用户必须输入，如口令就不能为空。

但若允许字段可以为“空”，如机器状态字段，则机器的当前状态就可能难以确定，影响数据质量。

一个基本的方向是“约束”多，则编程的代码量会变大，性能会下降，但数据的质量会得到提高。

在Record表中“下机时间”和“上机费用”没有定义为“非空”，是因为上机时这两项不能确定，只能填写部分上机记录信息。

一般数据库表结构的变动对于程序的影响较大，在程序设计上可通过xDAO类尽量消减变动的影响，在实现阶段应避免对数据库结构大的改动。

1.3.2.2上机模块设计

一界面设计

界面设计主要是根据功能要求构建界面，界面中的每个元素均应有其作用，以支持功能的实现，界面设计还要考虑到界面风格的一致、符合一般window应用GUI的规范。

设计应简洁实用，避免在细节上（如字体、颜色）耗费时间。

上机模块参考界面如图4所示：

图4参考界面

二上机流程

1初始化

（1）显示界面

（2）获取空闲机器

（3）将空闲机器号加入下拉列表

2上机处理过程：

（1）验证机器号、卡号、密码是否为空

（2）根据卡号、密码获取卡对象

（3）若卡对象为空则说明卡号或密码错，给出提示“卡号或密码错”，要求重输

（4）判断卡状态，若卡正在使用则给出提示“不能一卡多用”

（5）计算卡中余额，若低于设定值，则提示“余额不足”

（6）修改卡状态为在用，修改机器状态为在用，获取上机时间，将上机时间、机器号、卡号保存到记录对象，再通过RecordDAO在库中添加一条新上网记录。

（7）提示上网成功

三经验共享

1上机处理中的第6步要在一个完整的“事务”中完成，对卡、记录、机器数据的更改添加要保证要么全部更改成功，要么都不更改，以保证数据的一致性。

2费用计算是按时段计算的，需要考虑跨时段费用如何计算，另外为了降低复杂性，可规定时段只能为三段，时间精确到分，费用精确到角。

3记录ID如何保证唯一且自动增长。

基本有两种：

一是编程控制，插入新记录前获取当前最大记录号,通过selectmax（id）fromrecord，加1后，将ID及其它信息写入，若有多用户访问该表，则上述过程要放在一个“事务”中。

二是利用关系数据库提供的“自增字段”特性，将ID设置成“自增字段”，由数据库负责每添加一条记录就将ID加1。

1.3.2.3下机模块设计

一界面设计

下机模块主要根据用户请求（报出卡号机器号），管理员根据卡号机器号执行下机操作，参考界面如图5所示，大的文本空白文本框用于显示下机记录信息。

当然还有其它的设计方式，如显示当前上机的所有记录信息，选中其中一条执行下机操作。

图5下机模块界面

二下机流程

1管理员输入机器号或卡号，请求下机

2系统获取机器号，据机器号获取相应记录对象，要处理机器号错误的情况

3系统根据记录对象获取该记录对应的卡对象

4系统计算费用，并比较卡对象余额，若不够则提示“余额不足”，并显示余额

5系统从卡中扣费，修改卡状态为“空闲”；系统修改该机器的状态为“空闲”；系统更新记录信息（下机时间、费用）。

6系统显示本次上网完整的记录（Record）信息及卡余额，并提示下机成功

注：

下机处理4中修改三表的操作应作为一个“事务”完成。

1.3.2.4发新卡模块设计

一界面设计

发卡需要输入卡号、用户名、密码、金额，参考界面如下图所示。

界面设计布局应简洁一致，从用户友好性出发，提供了输入提示，增加了“确认密码”，以提醒用户记住密码，输入的密码用*号显示以提高安全性。

虽然有了提示但在代码中仍需对输入进行验证，如金额不能为负值，以避免误输及恶意输入。

当然从口令强度考虑，要求密码只输入数字和字母又是不妥的，相反可提示用户输入特殊字符及输入的最小字符数。

所以此界面虽简单，但已涉及到界面的视觉风格、用户友好性、安全性考虑。

图发卡界面

二发卡流程

1系统从界面获取所有信息，依次判断是否为空

2判断金额是否大于0

3判断密码和确认密码是否一致，

4判断密码和用户名是否在最小及最大长度之间

5判断卡号是否有效（唯一）

6生成Card对象，请求CardDao向Card表中添加一条新记录。

7提示卡添加成功，并显示卡号和金额

三经验共享

1输入数据的验证是难点，验证输入数据是保证程序可靠性的重要措施，例如：

若不限制用户或口令长度在相应数据库表字段设定的范围内，一旦将超长的用户名写入数据库则会产生数据被截断