概要设计说明书
本阶段的主要任务是在用户的需求分析阶段的基础上,对机房收费系统做概要设计,为在需求分析阶段得到的目标系统的物理模型确定一个合理的软件系统的体系结构。包括合理地划分组成系统的模块、模块间的调用关系及模块间的接口,并且为软件系统提供所用的数据结构或者数据库结构。同时为下一阶段的详细设计做参考。
本文档的读者是项目设计和项目编码人员。
A.待开发软件名称:机房收费系统
B.项目提出者:米新江教授
开发者:吴士龙
用户:廊坊师范学院全体教职工和学生
实现该软件的计算中心或计算机网络:廊坊师范学院局域网
C.该软件系统同其他机构的基本的相互来往关系:由廊坊师范学院信息技术提高班做技术支持。
注册 |
消费金额 |
充值 |
值班 |
退卡 |
Login |
Consume |
Recharge |
On work |
Cancel |
结账 |
基本数据 |
购卡 |
上机 |
下机 |
Statement |
Basic_date |
Buycard |
Login |
logout |
[1]《软件工程事务》刘学俊李继芳 刘汉中编著 浙江大学出版社
[2]概要设计说明书(GB8567——88)
A.主要输入:基本数据设定、添加用户、注册信息、充值信息、上下机信息以及退卡信息都会输入到数据库中保存
B.主要输出:查询信息及日结账信息、周结账信息,还可以打印
硬件支持:
a.server要求内存256以上,cpu 2.0GHz以上
b.Clinet内存128以上,cpu奔腾III以上,最大可支持20台分机同时连接到主机上
软件支持:
a.操作系统:windows xp以上操作系统
b.数据库管理系统:sql server
主要模块功能块的流程图如下:
2.4结构
如图所示:
2.5功能需求与程序的关系
|
一般用户 |
操作员 |
管理员 |
学生信息管理 |
√ |
√ |
√ |
用户信息管理 |
|
|
√ |
收支账目管理 |
|
√ |
√ |
系统信息管理 |
|
|
√ |
学生上下机需要刷卡。
功能模块与相应数据表之间的关系尚未详细确立,机数据库的详细设计部分,将在下一个环节详细设计中提到。
命令 |
语法 |
信息正确 |
信息错误 |
提交 |
IF&ELSE |
实现命令 |
系统提示,返回当前界面 |
修改 |
点击 |
清空输入的数据 |
无 |
取消 |
点击 |
返回当前界面 |
无 |
软件 硬件 |
键盘 |
鼠标 |
打印机 |
主模块 |
连接 |
连接 |
|
管理模块 |
连接 |
连接 |
连接 |
A.一般用户:主要是查看学生余额、学生上机记录、学生充值记录、学生上机状态查询、修改密码等模块,都涉及到数据库的调用
B.操作员:学生上机情况查询、余额退还查询、注册、充值、退卡、收取金额的模块
C.管理员:主要基本数据设定、添加删除用户、值班教师情况查询、结账、日结账单和周结账单
该系统的主要输入设备是键盘和刷卡器,输出主要是显示器输出和打印机输出
响应时间:0.5s内
更新处理时间:0.5s内
数据的更换和传送时间:1s内
5系统数据结构设计
无
5.1逻辑结构设计要点
机房收费系统共建立了10个表,具体如下:
1)基本数据设定(BasicData_Info)
描述 |
字段名 |
数据类型 |
长度 |
半小时费用 |
HalfCharge |
Char |
10 |
递增时间 |
IncreaseTime |
Char |
10 |
最少上机时间 |
LeastTime |
Char |
10 |
上机准备时间 |
ReadyTime |
Char |
10 |
卡内最少余额 |
LeastCash |
Char |
10 |
日期 |
Date |
Char |
10 |
时间 |
Time |
Char |
10 |
2)退卡信息(CancelCard_Info)
描述 |
字段名 |
数据类型 |
长度 |
学号 |
StudentNo |
Char |
10 |
卡号 |
CardNo |
Char |
10 |
退卡金额 |
CancelCash |
numeric |
(18,1) |
日期 |
Date |
Char |
10 |
时间 |
Time |
Char |
10 |
用户名 |
UserID |
Char |
10 |
状态 |
Status |
Char |
10 |
3)日结账单(CheckDay_Info)
描述 |
字段名 |
数据类型 |
长度 |
余额 |
RemainCash |
numeric |
(18,0) |
充值金额 |
RechargeCash |
numeric |
(18,0) |
消费金额 |
ConsumeCash |
numeric |
(18,0) |
退卡金额 |
CancelCash |
numeric |
(18,0) |
所有金额 |
AllCash |
numeric |
(18,0) |
日期 |
Date |
Char |
10 |
时间 |
Time |
Char |
10 |
4)周结账单(CheckWeek_Info)
描述 |
字段名 |
数据类型 |
长度 |
余额 |
RemainCash |
numeric |
(18,0) |
充值金额 |
RechargeCash |
numeric |
(18,0) |
消费金额 |
ConsumeCash |
numeric |
(18,0) |
退卡金额 |
CancelCash |
numeric |
(18,0) |
所有金额 |
AllCash |
numeric |
(18,0) |
日期 |
Date |
Char |
10 |
时间 |
Time |
Char |
10 |
5)上机信息(Online_Info)
描述 |
字段名 |
数据类型 |
长度 |
卡号 |
CardNo |
Char |
10 |
卡的类型 |
CardType |
Char |
10 |
学号 |
StudentNo |
Char |
10 |
学生姓名 |
StudentName |
Char |
10 |
系别 |
Department |
Char |
10 |
性别 |
Sex |
Char |
10 |
上机日期 |
OnDate |
Char |
10 |
上机时间 |
OnTime |
Char |
10 |
电脑 |
Computer |
Char |
10 |
6)充值记录(Recharge_Info)
描述 |
字段名 |
数据类型 |
长度 |
学号 |
StudentNo |
Char |
10 |
卡号 |
CardNo |
Char |
10 |
充值金额 |
AddMoney |
Numeric |
10 |
日期 |
Date |
Char |
(19,4) |
时间 |
Time |
Char |
10 |
用户名 |
UserID |
Char |
10 |
状态 |
Status |
Char |
10 |
7)学生信息(Student_Info)
描述 |
字段名 |
数据类型 |
长度 |
学号 |
StudentNo |
Char |
10 |
卡号 |
CardNo |
Char |
10 |
学生姓名 |
StudentName |
Char |
10 |
系别 |
Department |
Char |
10 |
性别 |
Sex |
Char |
10 |
年级 |
Grade |
Char |
10 |
班级 |
Class |
Char |
10 |
金额 |
Cash |
Numeric |
(10,3) |
备注 |
Explain |
Varchar |
50 |
用户名 |
UserID |
Char |
10 |
状态 |
Status |
Char |
10 |
是否结账 |
IsCheck |
Char |
10 |
日期 |
Date |
Char |
10 |
时间 |
Time |
Char |
10 |
8)用户信息(User_Info)
描述 |
字段名 |
数据类型 |
长度 |
账号 |
UserID |
Char |
10 |
密码 |
PWD |
Char |
10 |
级别 |
Level |
Char |
8 |
用户名 |
UserName |
Char |
10 |
9)值班信息(WorkLog_Info)
描述 |
字段名 |
数据类型 |
长度 |
用户名 |
UserID |
Char |
10 |
级别 |
Level |
Char |
10 |
登录日期 |
LoginDate |
Char |
10 |
登录时间 |
LogoutTime |
Char |
10 |
注销日期 |
LogoutDate |
Char |
10 |
注销时间 |
LogoutTime |
Char |
10 |
电脑名 |
Computer |
Char |
10 |
状态 |
Status |
Char |
10 |
5.2物理结构设计要点
给出本系统内所使用的每个数据结构中的每个数据项存储要求,访问方法、存取单位、存取的物理关系(索引、设备、存储区域)、设计考虑和保密条件。
由客户端输入的信息存入服务端的数据库中,访问方式根据操作人员而定。
5.3数据结构与程序的关系
说明各个数据结构与访问这些数据结构的形式:
系统的数据结构由标准数据库语言SQL实现,如INSERT语句、DELETE语句、UPDATE语句。
在用户使用错误的数据或访问没有权限的数据以及在用户操作非法时,系统会给出相应的警告提示。
由于数据在数据库中已经有备份,故在系统出错后可以依靠数据库的回复功能,并且依靠日志文件使系统再启动,就算系统崩溃用户数据也不会丢失或遭到破坏。但有可能占用更多的数据存储空间,权衡措施由用户自己来决定。
由于系统较小没有外加维护模块,因为维护工作比较简单,仅靠数据库的一些基本维护足以。