详细的网吧管理系统实训报告.docx
《详细的网吧管理系统实训报告.docx》由会员分享，可在线阅读，更多相关《详细的网吧管理系统实训报告.docx（16页珍藏版）》请在冰豆网上搜索。
详细的网吧管理系统实训报告
管理信息系统实训告
课题:
网吧管理系统
班级：
信管二班
姓名：
李瑞玲
学号：
100301219
1.系统开发背景
随着网吧的不断普及和消费者需求的不断增加，使得网吧的管理需要更加系统更加科学的改进，尤其是对于一些大型的网吧。
满足消费者的需求，是网吧管理改进的直接动因。
在最开始的时候，网吧只是一个单纯的提供上网的场所，而现在消费者在上网的同时还有其他的需要，例如需要饮料，零食或者在网吧直接用餐。
这些服务项目的增加使得网吧在管理上需要进行改进和调整。
科学的系统和以消费者为主的管理，会让消费者有愉悦的消费体验，还有助于网吧在消费这心中塑造良好的形象。
网吧的管理包括缴费管理，服务管理，设备的维修管理等。
它的这些项目虽说简单，但是在处理的过程中如果用更好的方法和流程来完成，会产生更好的效果。
这样做的目的就是给消费者提供了一个高效，舒适的上网环境。
2.可行性分析
2.1可行性概述
可行性分析也称为可行性研究，是在系统调查的基础上，针对新系统的开发是否具备必要性和可能性，对新系统的开发从技术、经济、社会的房买你进行分析和研究，以避免投资失误，保证新系统的开发成功。
可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。
2.2可行性研究
（1）法律可行性
该系统在网吧等类似场所使用，进行管理监控用户的基本操作，其中不会添加获取用户密码等受法律保护的信息的操作，且该系统不保存用户上机的具体操作，只会保留用户上网日期和时间等数据，以便用户日后核对，或者供其他一些有权限的人或部门
（2）经济可行性
由于该系统的实现初衷是为了锻炼，以熟悉软件开发的全过程，不涉及经济的投入（有也会很少），所以将不会有经济上的风险。
因此，在这一方面是可行的。
（3）运行可行性
由于网吧管理系统是相对独立的系统，除了与操作系统交互外，与其他软件的关系不大，所以发生冲突的概率较低。
万一发生不能协调工作，为了本系统的安全，将对外来系统做一定限制，严重的将采取禁用策略。
（4）技术可行性
采用JAVA语言和SQL数据库实现，采用Powerdesigner建模。
从技术上来说是可以实现的。
3.系统需求分析
3.1系统功能设计
本系统包含两个子系统，其中网吧的客户用的是客户端子系统，而网管所使用的则是服务端子系统。
每个子系统包换了若干子功能模块，每个子功能模块完成相应的处理操作功能。
（图3.3.1）系统总功能框图
3.2系统组织结构图
（图3.2.1）组织结构图
经理是网吧最高的管理者，负责网吧的战略决策。
网吧的具体事项的实施者是主管，负责所有决策的具体实施。
主管有两名一位主管前台服务，后勤。
另一位负责财务和电脑的维修采购任务。
用户分析
用户角色
权限
经理
行政人员，对系统中管理员进行管理，对不同人员赋予不同的权限
主管
对系统信息进行操作，权限由超级管理员赋予
服务台
能够提供各种花费服务，和服务员一样的功能
（表3.2.1）
3.3系统业务流程图
3.3.1缴费业务
缴费管理流程图
3.2.2服务业务说明
服务管理流程图
3.2.3维修业务说明
维修采购流程图
3.2.4人事管理业务流程图说明
人事管理流程图
3.3系统数据流调查和分析
3.3.1数据流程图
0层数据流层图
一层数据流程图
二层数据流程图
三层管理数据流程图
四层数据流程图
3.3.2数据字典
1、数据流的描述
数据流的编号
数据流名称
简述
数据流来源
数据流去向
数据流组成
F1
身份证菜单
提供顾客的身份信息，顾客所点的商品菜单
S
P0
顾客的身份信息，菜单信息
F2
上网记录
为符合条件的顾客提供上网账号和上网时间
P0
S
顾客登录时间，下机时间，上网总时间及总费用
F3
账单
顾客所购买商品的凭证
P0
S
顾客所消费的商品总费用
F4
缴费
支付所消费的账单
P0
S
缴费金额
F5
身份证及现金
提供顾客身份年龄信息供核查
S
P1
顾客的年龄，预交上网金额
F6
不合格身份证及现金
核查后不符合年龄要求的身份证和现金
P1
S
顾客的年龄，预交上网金额
F7
缴费信息
顾客缴纳的上网及所购商品的费用
P1
D1
上网及购买商品的具体金额
F8
消费清单
消费者购买的商品记录的凭证
P2
S
顾客购买的物品名、数量及费用
F9
菜单
消费者购买的商品
S
P2
所购商品的名称及数量
F10
人事数据
员工的基本信息
P3
D3
员工的姓名，权限，职位等信息
F11
维修采购单
维修和采购的信息
P4
D4
维修或购买的时间，内容，人员及费用
F12
符合要求的身份证件
顾客的信息
P3.3
S
顾客的年龄，姓名等
F13
缺货菜单
菜单上缺货的产品
P2.1
S
顾客菜单上缺货的产品名称数量等
F14
菜单数据
库中现有的商品信息
P2.1
D3
顾客菜单中现有的商品名称，价格，数量等
F15
维修单
前台根据实际情况提出的维修申请
S1
P3.1
需要维修的电脑编号，时间等
F16
能够维修的计划单
维修后能继续使用的计划单
P3.1
P3.2
编号，报修修时间，出现的问题
F17
采购计划单
更换无法修好的电脑
P3.1
P3.3
被更换电脑的编号，计划购买日期
F18
维修数据
维修的内容
P3.2
D4
维修内容，维修人员，维修时间，维修情况等信息
F19
采购数据
采购的内容
P3.3
D4
采购的费用，电脑型号，采购日期
F20
维修清单
维修内容的
P3.3
S
维修内容，维修人员，维修时间，维修情况等信息
F21
采购清单
采购的内容
P3.3
S
采购的人员，时间
F22
信息变更清单
员工的信息修改的信息
P4.1
P4.2
员工的名字，口令，权限等信息
F23
缴费额
顾客缴费
S
P2.2
交付的金额，时间，项目等
F24
收费数据
收费基本信息
P2.2
D2
缴费的金额，缴费时间，缴费项目，收费人员等信息
2、处理逻辑的描述
标号
处理逻辑名称
输入数据流
处理
输出数据流
P1.1
登记处理
F5
顾客出示身份证及现金后如果年龄符合要求，前台则办理上网手续
F12
D1
P2.1
菜单处理
F9
前台按顾客菜单拿取商品并送给顾客，如果缺货则告知顾客
F14
P2.2
收费处理
F23
当前台工作人员将商品送给顾客时，顾客当面付款
F24
P2.3
收费核算
D3
计算顾客所选商品的价格，生成账单
F18
P3.1
检查处理
F15
维修人员检查机器后决定是否能机会够修好
F16f17
P3.2
维修处理
F16
维修机器
F18
P3.3
采购处理
F17
采购新电脑更换无法维修的电脑
F19
P4.1
信息审核
D5
员工提出申请后，经理对员工提出的信息及要求进行正确性和可行性的分析，以保证信息正确可行
F22
P4.2
信息变更
F22
据审核后的信息变更清单，对员工的基本信息按要求操作
F10
3、数据存储的描述
数据存储编号
数据存储名称
简述
数据存储组成
关键字
相关处理
D1
缴费信息
收费所有的基本信息
缴费时间，金额，人员
单据编号
制作报表
D2
商品台账
商品的出售账目
时间，总金额，名称
账目日期
制作报表
D3
菜单信息
顾客所选商品的信息
名称，单价
菜单编号
记录
D4
报修和采购信息
维修和采购的基本信息
保修或采购的时间，费用，人员
报修或采购编号
制作报表
D5
人事信息
所有员工的信息
姓名，权限，职位
员工编号
登记
4、外部实体的描述
外部实体编号
外部实体名称
简述
输入数据流
输出数据流
S
顾客
上网消费者
收到的回复
提出要处理的事情
S1
前台
网吧日常管理部门
收到的回复
提出要处理的事情
4.数据库分析
4.1数据库设计
1概念结构设计
概念结构设计的任务是在需求分析阶段产生的需求说明书的基础上，按照特定的方法把它们抽象为一个不依赖于任何具体机器的数据模型，即概念模型。
概念模型使设计者的注意力能够从复杂的实现细节中解脱出来，而只集中在最重要的信息的组织结构和处理模式上。
概念模型具有以下的特点：
（1）概念模型是对现实世界的抽象和概括，它真实、充分地反映了现实世界中事物和事物之间的联系，能满足用户对数据的处理要求。
（2）由于概念模型简洁、明晰、独立于计算机，很容易理解，因此可以用概念模型和不熟悉计算机的用户交换意见，使用户能积极参与数据库的设计工作，保证设计工作顺利进行。
（3）概念模型易于更新，当应用环境和应用要求改变时，容易对概念模型修改和扩充。
（4）概念模型很容易向关系、网状、层次等各种数据模型转换。
描述概念模型的有力工具是E-R图。
E-R模型是一个面向问题的概念模型，即用简单的图形方式（E-R图）描述现实世界中的数据。
这种描述不涉及数据在数据库中表示和存取方法，非常接近人的思维方式。
后来又提出了扩展实体联系模型（ExtendEntity-RelationshipModel），简称为“EER模型”。
EER模型目前已经成为一种使用广泛的概念模型，为面向对象的数据库设计提供了有效的工具。
2逻辑结构设计
概念结构设计所得的E-R模型是对用户需求的一种抽象的表达形式，它独立于任何一种具体的数据模型，因而也不能为任何一个具体的DBMS所支持。
为了能够建立起最终的物理系统，还需要将概念结构进一步转化为某一DBMS所支持的数据模型，然后根据逻辑设计的准则、数据的语义约束、规范化理论等对数据模型进行适当的调整和优化，形成合理的全局逻辑结构，并设计出用户子模式。
数据库逻辑结构的设计分为两个步骤：
首先将概念设计所得的E-R图转换为关系模型；然后对关系模型进行优化。
3物理结构设计
在表当中，关键字（即编号）都采用自动编号的数据类型；日期都采用日期型的数据类型；凡是关于数据量的都采用数据型的数据类型；其他数据均采用文本型的数据类型。
当表之间有关系时通过添加外键来处理。
当表与其他表有关系时，便给该表建立一张视图，通过外键将两张表联系起来，通过数据筛选，把自己想要的信息提取出来，形成一张新的表。
其数据库中表的设计具体如下：
表4-1用户表
列名
数据类型
允许空
字段说明
帐号
Char（10）
否
主键
密码
Char（10）
否
登录密码
余额
Money
是
用户余额
上机费用
Money
否
每分钟费用
注册日期
Datetime
是
注册日期
表4-2管理员表
列名
数据类型
允许空
字段说明
帐号
Char（10）
否
主键
密码
Char（10）
是
登陆密码
姓名
Varchar（50）
是
管理员姓名
年龄
Varchar（50）
是
管理员年龄
性别
Char（10）
是
管理员性别
表4-3消费表
列名
数据类型
允许空
字段说明
登陆帐号
Char（10）
否
主键
登陆时间
Datetime
是
登陆时间
下机时间
Datetime
是
下机时间
计算机名
Varchar（50）
是
计算机名
花费
money
是
花费
5.详细设计
IPO编号（模块号）：
C.2.4.5
HIPO编号：
C.2.0.0
数据库设计文件编号：
C.3.2.2
编码文件号：
C.2.3
模块名称：
密码校验
设计者：
╳╳╳
使用单位：
╳╳╳
编程要求：
asp.Net
输入部分：
（I）
处理部分（P）
输出部分（O）
●上级模块传入用户输入密码
●从数据库中读取密码
●下级模块传来对比正确进入标志
●下级模块传来对比错误重输标志
输入次数计数器=0
Dowhile输入次数计数器<3
If输入密码≠库中密码
输入次数计数器=输入次数计数器+1；
输出重输密码标志；
Else
输出进入系统标志；
退出循环；
Endif
Enddo
If输入次数计数器=3
退出系统；
Endif
●进入标志
●重输入标志
5.系统测试
5.1系统测试目标
系统测试的目标是想以最少的时间和人力发现系统中潜在的各种错误和缺陷。
如果成功的实现了测试，就能够发现系统中的错误，并及时的更改过来。
测试的另一个收获是它能够证明此次设计的系统功能和性能与需求说明相符。
5.2测试方法
本次测试主要采用手工黑盒测试方法，根据基础用例整理测试，并补充完成第三方测试用例，执行全部可执行测试用例，跟据测试要求验证是否达到测试目的中所列内容。
测试流程
步骤
动作
负责人
测试提交物
要求
1
测试准备
赵静
基础用例
描述需求
马子云
测试需求
整理需求
2
测试计划
李泉
测试方案
经过评审
3
环境测试部署
张申申
发布日志，测试入口URL
日志按时提交，环境可用.
4
测试设计
何燕
测试用例
5
测试实施
李泉
用例执行情况
6
测试报告
何燕
测试报告
经过评审
5.3测试要求
测试阶段
测试方法
测试要求
第一阶段
各模块的功能验证
1.检查操作按钮功能
2.检查操作按钮的用途与说明
3.检查必填项设定
4.数据查询正确性
5.界面检查
6.异常输入检查
7.其它
1.检查各按钮操作功能是否准确。
2.不同模块中同一用途的按钮名称或说明文字是否相同。
3.系统是否能给出相应的限制
4.满足查询要求
5.检查界面的整体风格是否一致及表格布局、用户提示、菜单及对话框等
6.验证系统对于异常数据是否给出正确判断
第二阶段
系统稳定性
1.统计正常操作下，产生的错误率。
2.统计任意操作下，产生的错误率。
记录多见错误信息。
3.安全性测试（如登录模块）
4.压力测试
1.正常操作下，不应产生错误。
2.任意操作下，越少越好
升级会员 