教职工食堂订餐系统的需求和总体设计后台子系统.docx
- 文档编号:9189383
- 上传时间:2023-02-03
- 格式:DOCX
- 页数:16
- 大小:241.22KB
教职工食堂订餐系统的需求和总体设计后台子系统.docx
《教职工食堂订餐系统的需求和总体设计后台子系统.docx》由会员分享,可在线阅读,更多相关《教职工食堂订餐系统的需求和总体设计后台子系统.docx(16页珍藏版)》请在冰豆网上搜索。
教职工食堂订餐系统的需求和总体设计后台子系统
教职工食堂订餐系统需求和总体设计——后台子系统
目录
1.系统需求分析2
1.1.系统总体业务流程2
1.2.系统功能需求4
1.2.1.审查注册用户4
1.2.2.菜谱信息录入4
1.2.3.今日菜单发布4
1.2.4.今日订单管理5
1.2.5.结帐与教职工信用度管理5
1.2.6.留言版管理5
1.3.系统其他需求5
2.系统总体设计6
2.1.系统设计原则6
2.2.系统总体架构7
2.3.系统功能模块设计9
2.4.数据库设计10
2.4.1.数据库概念结构设计10
2.4.2.数据库逻辑结构设计11
2.5.开发运行平台选择13
1.系统需求分析
1.1.系统总体业务流程
图1教职工食堂订餐系统总体流程图
从图1来看,系统主要分为两大部分:
系统后台部分(后台子系统)、系统前台部分(前台子系统)。
第一部分为教职工订餐系统的后台子系统部分。
食堂管理员成功登陆后,查看等待审查的注册教职工信息——包括教职工号、姓名、性别、单位、办公室地址、电话号码、密码,食堂管理人员可能通过打电话方式确认教职工信息是否真实。
若所添信息真实,那该教职工就通过审查,该教职工就算正式注册成功了,教职工的注册信息就上传到教职工信息表,成为教职工信息表的一条记录,同时删除在待审查注册信息表里该教职工用户的注册信息;否则该教职工就注册失败;食堂管理员还负责录入菜谱和饮料信息,通过录入菜谱的名字、类型、描述、图片、价格的形式,生成菜谱信息表,以便日后的修改、删除;管理员必须要负责发布今天供应的菜谱和饮料信息,让教职工可以查询到今天供应的菜和饮料,以便教职工用户可以订到喜欢的菜式;在这之后管理员可以查看今日的订单看那些教职工订了餐和和他今天的订餐记录,根据订单的内容和订餐时间的不同把订单制成订餐表打印出来然后发送到厨房(厨师按订单包装快餐)和送餐人员(送餐人员按订单把快餐送到相应的地点);当送餐人员在送餐返回后,将从教职工那里收到的钱交给食堂管理人员,食堂管理人员将钱入帐之后,将该教职工的信用度加一分。
如果送餐人员无法将快餐送到教职工的手中,由于是教职工的原因造成的(可能订餐的送餐地点不对),则扣该教职工的信用度2分,如果一个教职工的信用度低于0分,则管理员就不让他在网上订餐;管理员可以查看留言版内容并对教职工的留言给予回复,还可以删除留言内容。
第二部分为教职工订餐系统后台部分。
教职工填写本人的姓名,性别,单位,办公室地址,电话号码,密码信息,然后提交给系统生成待审查信息表,等待食堂管理员审查;教职工在审查通过后就可以以用户身份登陆系统,之后教职工可以查看今日的菜谱,觉得合适的话就可以直接点击菜谱图片进行订餐或者进入订餐界面进行订餐,完成订餐后就可以提交订单,生成订单信息表,订单信息包括菜的名称、数量、订餐时间(必须是当日)、送餐时间(必须是当日)、送餐地点(如果没有,则默认是该教职工的办公室地址)、联系电话,在提交订单后假如教职工觉得不合适可以对订单进行修改甚至取消订单,离送餐时间大于30分钟的时间段内教职工可以取消订餐而不扣信用度。
离送餐时间小于30分钟的时间段内教职工也可以取消订餐,但是要扣除该教职工的1分信用度;教职工还可以进入留言版通过写下自己的留言的方式向食堂管理员提议和意见和对其他教职工的留言进行回复。
1.2.系统功能需求
1.2.1.审查注册用户
1)食堂管理人员登陆到本系统后,可以看到哪些教职工的注册信息需要审查,要审查的信息包括教职工的名称、教职工的性别、教职工的电话号码、教职工的住址、教职工的办公部门,资格审查的目的是只允许本高校的教职工可以使用本系统。
2)食堂管理员通过打电话等方式核查教职工的注册信息是否真实。
假如教职工提供的信息是真实的就把该职工的注册信息提交到用户信息表并将审查结果保存到数据库。
并且系统默认在该教职工的信用度属性了加上4分。
这样该教职工就算通过审查了,同时删除在待审查注册信息表里该教职工用户的注册信息;否则该教职工审查不通过,就删除他的注册信息不让他登录。
1.2.2.菜谱信息录入
食堂管理员负责录入本食堂的菜谱,菜谱信息包括菜的名称,菜的描述,菜的图片,菜价格。
饮料信息包括饮料名称,饮料的描述,饮料的图片,饮料价格,其中菜谱和饮料名称必须是中文,食物的描述和图片可以为空,食物价格精确到小数点后两位,然后食堂管理员把录入的菜的信息和饮料信息保存到数据库(菜谱信息表)。
添加菜谱信息完成后食堂管理员可以浏览已添加的菜和饮料信息,可以对不满意的菜或饮料的数据进行修改,例如修改菜谱名字、描述、更新或重新上传图片、更改价格甚至可以直接把菜或饮料从数据库里删除。
1.2.3.今日菜单发布
1)食堂管理员可以首先浏览菜谱信息表里的那些已经发布的菜谱与饮料信息,因为每天的要发布的菜单一般来说都不会有很大的变动,所以可以把过去发布了的菜单保存到数据库了而不必要每次都重新发布菜单一次。
只有当要发布某些特别的菜或饮料(比如说季节上的时令菜式)时,才需要重新发布菜单和饮料假如觉得以前已发布的菜单合适的话就不需要发布菜单更新浏览器公布的菜和饮料,直接就让教职工用户在原来的菜单上进行订餐。
2)假如食堂管理员觉得已发布的菜单不满意,比如说有些菜或饮料现在已经没有或过时了的话,就要更新今日菜单发布的菜或饮料的信息,取消某些已发布的食物和饮料,让它们的状态从发布转为未发布,然后浏览菜谱信息表里的菜和饮料寻找合适的菜谱,然后把合适的的菜或饮料发布到浏览器,让教职工用户进行选择和订餐,之后教职工可以重新查看已发布的菜单信息。
1.2.4.今日订单管理
在教职工用户提交了自己的订单后,食堂管理员可以以单个用户为单位查看每个有订餐的教职工用户所有的订单信息,包括订单号、食物的名称、食物的数量、食物的单价、送餐地点和送餐的时间,然后根据送餐时间的先后顺序分别把它们打印出来,然后发送到厨房(厨师按订单包装快餐)和送餐人员(送餐人员按订单把快餐送到相应的地点)。
1.2.5.结帐与教职工信用度管理
食堂管理员就查看教职工用户的帐单(订单)作核对和查看当前教职工用户的信用度,核对正确后就给教职工结帐并且给该教职工的信用度增加一分同时注销该教职工用户的订单信息;如果送餐人员无法将快餐送到教职工的手中,由于是教职工的原因造成的(可能订餐的送餐地点不对),则扣该教职工的信用度2分同时注销该教职工用户的订单。
当该教职工的信用度少于或等于0分时,食堂管理员就注销该教职工的帐号让他下次无法登陆订餐系统进行订餐。
1.2.6.留言版管理
食堂管理员还可以进入教职工留言版查看所有教职工用户的留言信息,包括留言ID、留言人的IP地址、用户名、留言内容、其他用户的回复内容、回复时间、该教职工用户的E-Mail、教职工用户的留言时间,对于教职工反映的问题和意见可以给予回复,对于那些已经作出回复的留言并已过了较长时间的留言可以给予删除。
1.3.系统其他需求
(一)精度需求
1在执行数据增加的时候,不允许出现因为程序的原因导致增加操作失败,也不允许发生重复增加的数据。
2在执行数据删除操作的时候,不允许因为程序的原因发生多删除数据、删除失败的情况。
3数据的修改也要求保持对应的准确性。
4对汉字字符进行操作时无论上传数据还是获取数据时都不能出现或变成乱码。
(二)时间特性要求
1在单用户执行增加修改和删除操作的时候,在运行环境规定的条件下,单次操作的响应时间要求在3秒钟之内。
2返回100行数据以内的数据查询,单次操作的响应时间要求在3秒之内。
3多人操作时候,时间的相应要求同上。
(三)故障处理要求
1在操作成员输入一些不合理的数据的时候,能够进行一些合理的提示信息,不能因为输入错误而导致系统的错误,或者程序停止运行。
2程序运行时,对服务器和网络通信故障能够识别并提示,当故障排除后,程序恢复正常运行。
3数据库要求有灾难备份机制,以防止数据的全部丢失。
(四)安全需求
1数据库安全:
数据库级备份和恢复。
数据库级用户进行角色和权限授权。
使得在异常情况发生时,系统可以得以快速恢复,避免数据的丢失或将其影响降到最低限度。
同样,要保证存储过程中数据不被非法访问和篡改。
2应用系统的安全:
通过对用户的身份鉴别,并实施相应的访问控制策略后,使用户只能完成得到系统授权的数据访问功能操作。
用户只有经授权后才可以更新程序,避免因错误程序更新而影响系统的正常运行。
2.系统总体设计
2.1.系统设计原则
1)问题界定
问题的界定,对于软件开发来说是至关重要的。
因为任何一个软件都是为了更好的解决某些问题而开发的,只有准确地对问题进行界定,才能明确地把握软件系统的功能,以及系统的扩展方向。
2)功能分解,逐步求精
分解一直被认为是分析大而复杂设计问题的有力工具,分解的一个突出的优点是降低设计问题的复杂性。
采用逐步求精,就是在确保全局的正确性之后,再分别对每一局部进行考虑,每个局部又将是一个问题或任务。
采用逐步求精的优点是:
便于构造程序。
由这种方法产生的程序,其结构清晰、易读、易写、易理解、易调试、易维护[2]。
3)模块独立化
通过模块独立化,可以有效的实现信息隐蔽,提高内聚,降低耦合;这对测试及后期维护中需做变更时提供了极大的优点。
4)适应性和可扩展性原则
系统需要具备一定的适应能力,特别是Web应用要能适应于多种运行环境,来应对未来变化的环境和需求。
可扩展性主要体现在系统易于扩展,例如可以采用分布式设计、系统结构模块化设计,系统架构可以根据网络环境和用户的访问量而适时调整,从某种程度上说,这也是系统的适应性。
5)可靠性原则
系统应该是可靠的,在出现异常的时候应该有人性化的异常信息方便用户理解原因,或采取适当的应对方案,在设计业务量比较大的时候可采用先进的嵌入式技术来保证业务的流畅运行。
2.2.系统总体架构
通过系统的总体需求分析,得出系统要求的数据安全性能是不太严格的,系统的使用范围可分为食堂管理员和大量的教职工用户,其中食堂管理员都是非计算机技术专业人员,因此要求系统可操作简单,系统使用简便,客户端基本不需要什么维护或维护简单,成本低;对于教职工用户来说,系统使用方便,可扩展性高,不需要专门的网络设备,界面生动友好,系统响应速度快。
鉴于此,经过认真考虑之后,决定系统采用当代最流行的B/S结构和MVC模式来实现。
B/S结构:
(Browser/Server,浏览器/服务器模式)是WEB兴起后的一种网络结构模式,WEB浏览器是客户端最主要的应用软件。
这种模式统一了客户端,将系统功能实现的核心部分集中到服务器上,简化了系统的开发、维护和使用。
B/S最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。
只要有一台能上网的电脑就能使用,客户端零维护。
系统的扩展非常容易。
系统的结构如图2所示:
图2系统总体结构构图
用户界面层:
负责处理用户的输入和向用户输出,同时对用户的输入进行合法性验证。
业务逻辑层:
这一层是上下两层的纽带,它建立实际的数据库连接,根据用户的请求生成检索语句或更新数据库。
利用JSP技术把结果构造为HTML发送到客户端。
数据层:
负责数据的存储、维护和检索。
MVC模式是"Model-View-Controller"的缩写,中文翻译为"模式-视图-控制器"。
MVC应用程序总是由这三个部分组成。
MVC模式的组件类型和功能如图3[2]所示:
图3[2]MVC模式功能结构图
Model数据层[2]:
应用系统的数据存放。
View表示层[2]:
Model中的存储数据的可视化表示
Control控制层[2]:
接受用户的输入,通知Model发生事件
2.3.系统功能模块设计
依照的系统功能需求,根据参与角色的不同和权限的不同,各个功能进行分解,得到如下模块图:
图4。
图4后台子系统功能模块图
1).在审查用户注册信息中,食堂管理员在B/S系统中审查教职工提交的注册用户信息。
2).在录入菜谱管理中,食堂管理员向数据库录入菜和饮料信息。
3).在发布今日菜单中,食堂管理员发布今日供应给教职工用户订餐的菜和饮料。
4).在订单管理过程中,食堂管理员打印教职工用户订餐的订单一式两份,一份发送到厨房的厨师,一份发送给送餐人员。
5).在教职工用户付钱结帐后,食堂送餐人员把钱交到食堂管理员手上,食堂管理员核对无误后,就给改订餐用户结帐并修改用户的信用度,同时销毁订单信息。
6).食堂管理员进入留言版查看教职工用户的留言必要时给予回复并清理过期的留言。
2.4.数据库设计
2.4.1.数据库概念结构设计
经过上述系统功能分析和需求总结,由此得到教职工食堂订餐系统的设计与实现——后台子系统主要实体的E-R图,如图5所示
如图5后台子系统数据库E-R图
食堂管理员实体的主要属性:
管理员ID,用户姓名,管理员密码,真实姓名,电话号码.
教职工注册信息的主要属性:
用户ID,用户姓名,用户性别,用户密码,用户电话号码,用户住址,用户办公地点,用户信用度.
教职工用户信息的主要属性:
用户ID,用户姓名,用户性别,用户密码,用户电话号码,用户住址,用户办公地点,用户信用度.
菜谱信息的主要属性:
菜单ID,菜单名字,菜单类型,菜单描述,菜单图片,菜单价格,发布标志.
订单信息的主要属性:
订单ID,订单标识ID,菜的名字,菜的价格,菜的数量,订餐人姓名,送餐地点,订餐时间.
留言版实体的主要属性:
留言ID,留言人的IP地址,留言人的E-Mail地址,留言时间,留言内容,留言回复,回复时间,回复人姓名。
2.4.2.数据库逻辑结构设计
由于教职工食堂订餐系统的后台子系统只涉及5、6个表,所以把这5、6个表都一一列出来。
表1:
教职工注册审查信息表(教职工用户信息表)
字段名称
中文描述
数据类型
非空
缺省值
备注
userId
教职工注册编号
int
Y
userName
教职工用户名
Varchar(20)
Y
userSex
教职工性别
Varchar(8)
Y
userPwd
教职工密码
Varchar(16)
Y
userTel
教职工电话
Char(11)
Y
userAd
教职工住址
Varchar(50)
Y
userDepartment
教职工办公部门
varchar
Y
Feedback
教职工信用度
Int
Y
4
注册成功后自动赋予用户4分信用度
约束
ConstrainttempList_Pkprimarykey(userId)
表2:
食堂管理员信息表
字段名称
中文描述
数据类型
非空
缺省值
备注
id
食堂管理员编号
int
Y
userName
用户姓名
Varchar(50)
Y
userPwd
用户密码
Varchar(50)
Y
truthName
管理员真实姓名
Varchar(50)
phoneNum
管理员电话号码
Varchar(50)
Y
约束
Constraintadmins_Pkprimarykey(id)
表3:
菜谱信息表
字段名称
中文描述
数据类型
非空
缺省值
备注
menuId
菜谱编号
int
Y
menuName
菜谱名称
Varchar(20)
Y
menuType
菜谱类型
Varchar(20)
Y
menuDescribe
菜谱描述
Varchar(50)
menuPicture
菜谱图片
Varchar(50)
menuPrice
菜谱价格
Varchar(50)
Y
istoday
是否今日发布
Int
Y
0
0:
未发布1:
已发布
约束
ConstraintMenu_Pkprimarykey(menuId)
表4:
教职工用户订单信息表
字段名称
中文描述
数据类型
非空
缺省值
备注
Id
订单流水编号
int
Y
orderId
订单标识编号
int
Y
真正的订单号
goodName
菜的名称
Varchar(50)
Y
goodPrice
菜的价格
Varchar(50)
Y
goodNum
菜的数量
int
Y
userName
订餐人姓名
Varchar(50)
Y
RoomAddress
送餐地点
Varchar(50)
Y
orderTime
订餐时间
Varchar(50)
Y
约束
Constraintorders_Pkprimarykey(Id)
表5:
留言版信息表
字段名称
中文描述
数据类型
非空
缺省值
备注
id
留言编号
int
Y
ip
用户IP地址
Varchar(50)
用户网上邮箱
Varchar(50)
[Time]
教职工留言时间
Varchar(50)
content
留言内容
Varchar(50)
Y
restores
回复留言内容
Varchar(50)
restore_time
回复时间
Varchar(50)
xm
回复人姓名
Varchar(50)
ts
审核教师的ID
Varchar(50)
约束
Constraintmessages_Pkprimarykey(id)
2.5.开发运行平台选择
开发环境:
硬件:
CPU:
AMDAthlon(tm)850
内存:
256M
操作系统:
MicrosoftWindowsXPProfessional+SP2
服务器:
Tomcat5.0.0
开发工具:
EclipseV3.1+MyEclipse5.1.1
数据库管理系统:
SQLServer2000
其它的工具:
Dreamweaver8.0
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 教职工 食堂 系统 需求 总体 设计 后台 子系统