第一章 网吧计费管理系统
学习目标:能使用 Java 集成开发环境,运用 Swing 设计图形界面,运用 JDBC 访
问数据库,掌握事件处理编程,了解简单两层 C/S 项目的开发及简单面向对象程
序的设计过程,发展基本的团队协作开发能力。
学习寄语:虽然本项目并不是一个商业项目,其产品也不能用来赚钱,但从中你
可以学到实际开发中的许多经验和技巧,获得一种“学有所用”、“学有所得”的
成就感,同时赢得老师和同学(同事)对你的格外尊重。在此项目的学习中,你
不但是个学生,还是一个职业人,将与同事一起尽全力完成你所要做的工作,并
再次验证“天道酬勤”的真理。我们的信念是:“不抛弃,不放弃”。你的改变和
收获是老师真诚的期待。
1.1 背景介绍
1.1.1 业务背景
“海之星”网吧,是一个小型网吧,以前是人工记帐,现需要开发一个简单的
网吧计费管理系统。原人工管理的主要过程如下:客户在门口服务台,出示上机
卡,若是新客户则先发新卡;管理员先查询是否有空机器,若有则根据上机卡号
查到该卡对应的记录(账簿),若有余额(〉5 元),则分配一个空闲的机器号给
客户,客户根据机器号对号入座,管理员记下客户卡号、上机机器号、上机时间。
客户下机要到门口的服务台,请求下机,管理员根据当前时间、上机时间及费率
计算出本次上机费用,并记录,同时将费用从卡余额中扣除,若费用不够则需充
值。原手工系统主要有如下缺点:1 手工记帐,管理员工作量大,且易出错;2 超
时超费使用不能及时发现。因此需要开发一个简易计费管理软件,取代人工记帐
方式,由软件统一管理记录上下机、计费、上机卡、机器情况,提供简单统计功
能,超时超费提醒功能等。
1.1.2 技术背景
本系统要求使用 java 技术开发,使用数据库(如 ACCESS,SQLServer)保存
数据,集成开发环境可使用支持可视化 GUI 界面设计的主流工具(如 eclipse\ant
bean\jbuilder)。开发者应有 java 程序设计语言、SWING 基本 GUI 组件、文件
使用、JDBC 存取数据库、使用一种集成开发工具的基本知识和技能。系统采用
两层 C/S 体系结构,C 端负责通过 GUI 与管理员交互、处理业务逻辑及存取数据
库,S 端主要是数据库系统。系统分析设计主要采用面向对象的分析设计方法。
友情提示:对项目有了一个最基本的认识后,是不是立即准备大干一场?是否要
问一问值不值得干?能不能干?商业项目一般可以从经济性、技术性、法律社会
等方面进行可行性分析,但本项目作为一个学习型项目显然无利可图、技术也欠
缺(事实上技术正是要学习的东西)、好在项目是合法的。那是否继续?当然!
因为本项目的目标不是在合法的前提下获取最大利润,而是习得知识和技能,只
要你愿意,就可以继续进一步了解“网吧计费管理系统”,Let’s
go!
1.2 需求分析
1.2.1 功能需求分析
系统需求分析的主要任务是从用户角度考察系统应具有哪些功能及非功能
性需求,对于网吧计费管理系统,用户主要是指系统管理员,系统的主要功能是:
登录、上机、下机、卡管理(发卡、删卡、充值、查询)、机器管理(添加机器、
删除机器、查询状态、修改状态),统计功能(日、月费用统计),口令管理(添
加用户、删除用户、修改口令),参数设置(时段费率),使用帮助。主要使用流
程是:管理员登录,根据客户请求上机,根据客户请求下机。主要功能的用例(use
case)描述如下:
一 上机
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 开发系统。采用两层 C/S 体系结构。系统体系结构图如下
图所示:
图形界面
SWING
业务逻辑
数据访问(JDBC)
客户端
SQL
服务端
数据库
ACCESS
图 1 系统体系结构
客户端分 3 层,图形界面层(采用 java 的 SWING 设计)负责与用户交互,业务
逻辑层则根据用户的请求执行各种功能(如上、下机等),数据访问层主要根据业
务逻辑层的请求通过 JDBC/SQL 存取数据库。数据库使用 ACCESS,可根据情况使
用其他数据库(如 SQL Server),客户端基本不做修改,仅有的少量修改也只在
数据访问层。客户端与服务端在物理上可以运行在一台机器上,也可以分别运行
在不同机器上。
二 系统功能模块及主要类
系 统 的 主 要 功 能 模 块 如 图 2 所 示 :
主模块
登
录
上
机
下
机
帮
助
统
计
卡
维
护
机
器
维
护
参
数
维
护
口
令
维
护
发
卡
充
值
查
询
删
除
卡
查
询
添
加
机
器
删
除
机
器
图 2 系统模块图
添
加
用
户
更
改
口
令
删
除
用
户