概要设计说明书
1引言
1.1编写目的
本阶段的主要任务是在用户的需求分析阶段的基础上,对大米时代订餐系统做概要设计,为在需求分析阶段得到的目标系统的物理模型确定一个合理的软件系统的体系结构。包括合理地划分组成系统的模块、模块间的调用关系及模块间的接口,并且为软件系统提供所用的数据结构或者数据库结构。同时为下一阶段的详细设计做参考。
本文档的读者是项目设计和项目编码人员。
1.2背景
A.待开发软件名称:大米时代订餐系统
B.项目提出者:米新江教授
开发者:王啸、杨倩、郑晓东、焦玉丽
用户:志晟集团全体员工、大米时代全体、五楼食堂
实现该软件的计算中心或计算机网络:志晟集团公司局域网
C.该软件系统同其他机构的基本的相互来往关系:由大米时代订餐系统项目开发组做技术支持。
1.3定义
大米时代订餐系统:完成员工的订餐和自动刷卡消费的系统。
1.4参考资料
[1]《软件工程事务》刘学俊李继芳 刘汉中 编著 浙江大学出版社
[2]概要设计说明书(GB8567——88)
2总体设计
2.1需求规定
输入:一般为系统人员键盘输入,部分为外部文件导入。
输出:一般为屏幕输出,打印输出,还有Excel输出。
处理的性能要求:
1.数据管理能力要求:能满足当前使用规模的数据处理要求,至少需要1-2G的数据库,备份库的空间大小不限。
2.故障处理要求:①读卡器连接问题,刷卡消费时必须连接读卡器。②服务器硬件故障,应有备件或备机替换③数据服务器硬件故障,数据无法访问,应有备件或备机替换
2.2运行环境
本系统分为PC端和手机端,其中两个系统都需要有.NETFramework4.5的支持,需要有一台主机作为系统的服务器进行数据存储和公共访问使用。
系统需求:本系统需要的操作系统必须是Windows版本的xp-sp3以上的系统,需要局域网络支持。
设备:数据库服务器:至强E-3210以上,内存2G以上,硬盘9G,100M网卡
手机端:ISO、Android,支持微信使用
PC端:奔腾四,内存1G以上,硬盘1G,100M/10M网卡
2.3基本设计概念和处理流程
基本设计:
处理流程:
PC端:
手机端: 2.4结构2.4.1 包图+类图包图
包图说明:本系统基于3层架构,分为界面层(UI)、逻辑层(BLL)、数据处理层(DAL)、实体层(ENTITY),3层都要引用实体层,因为需要通过实体层来传递参数,数据处理层需要引用一个SQLHelper的助手类
UI类图
UI层分为5个类,根据窗体而建立,这5个类分别是:厨师类、前台类、订单类、财务类、类、界面显示类
B层类图
DAL层类图
D层:根据实体建立的D层 11个类,分别为: 食物类,订单类,用户类,添加记录类,卡表类,补贴记录类,数据库类,查看订单类,财务管理类,字典类SqlHelper
SQLHelper是对数据操作处理层(DAL)相同代码的一个封装,在助手类中封装了四种不同类型操作的方法
实体类图2.5功能器求与程序的关系 本条用一张如下的矩阵图说明各项功能需求的实现同各块程序的分配关系:
PC端
| Windows窗体 | 数据库 | 通讯加密 |
用户登录 | √ | √ | √ |
退出登录 | √ | √ | √ |
批量配置菜单 | √ | | |
详细菜谱 | √ | √ | |
食堂反馈 | √ | √ | |
当前员工订单 | √ | √ | |
食物排行 | √ | √ | |
未取餐统计 | √ | √ | |
订单明细 | √ | √ | |
未取餐订单 | √ | √ | |
历史订单 | √ | √ | |
今日订单 | √ | √ | |
临时收费记录 | √ | √ | |
新卡录入 | √ | √ | |
注册管理 | √ | √ | |
金额录入 | √ | √ | |
充值管理 | √ | √ | |
退卡管理 | √ | √ | |
挂失管理 | √ | √ | |
换卡管理 | √ | √ | |
账单查询 | √ | √ | |
账单汇总 | √ | √ | |
收费更正 | √ | √ | |
会馆菜单 | √ | √ | |
会馆订餐 | √ | √ | |
会馆订单 | √ | √ | |
修改密码 | √ | √ | |
分配权限 | √ | √ | |
设置 | √ | √ | |
手机端:
| 手机页面 | 数据库 | 通讯加密 |
用户登录 | √ | √ | √ |
本周订单 | √ | √ | |
订单记录 | √ | √ | |
充值记录 | √ | √ | |
食堂反馈 | √ | √ | |
修改密码 | √ | √ | |
退出系统 | √ | √ | |
2.6人工处理过程
管理员与员工需要输入卡号和密码,登陆上机,初始密码默认为1。
2.7尚未解决的问题
暂无
3接口设计
3.1用户接口
1、系统管理人员与员工的用户名为饭卡编号或编号后三位,初始密码为1。若用户输入密码错误,系统将会给出密码错误提示。
2、在使用系统过程中,用户进行查询操作时,需要选择查询的日期,然后会进一步进行功能选择。
3、而系统管理人员进行操作时,需要输入要查看员工的饭卡卡号,然后会进一步进行功能选择。
4、其余均为可视化界面,用户可以根据系统提示使用鼠标、键盘、触摸屏等外部构件进行功能选择及输入。
3.2外部接口
1、USB接口,连接鼠标,数字键盘,读卡器等设备。
2、系统通过访问服务器实现各种操作,与系统交互。
3.3内部接口
系统用户分为员工及管理人员,通过访问权限进行区分。
系统内部又分为前台管理、财务管理、厨师管理、员工系统、管理员系统等五个模块,各部分通过用户进行功能选择时的界面进行相互联系。通过面向对象语言设计类,在public类中实现调用;类间实现严格封装。
4运行设计
4.1运行模块组合
本项目分为若干专题模块,主要是以一个窗口为模块,一般一个窗口完成一个特定的功能,主窗口主要通过打开另一个子窗口来实现模块之间不同功能的连接和组合。个模块之间相互独立,程序的可移植性好。各模块之间主要以传递数据项的引用来实现模块之间的合作和数据共享。
4.2运行控制
1. 运行控制将严格按照各模块间的函数调用关系来实现。
2. 员工订餐时,应先进行新卡录入,录入成功后可以使用;
3. 员工修改密码时需要输入原密码;
4. 员工查询订单记录可以按照日期查询;
4.3运行时间
1. 响应时间:0.5s内
2. 更新处理时间:0.5s内
3. 数据的更换和传送时间:1s内
5系统数据结构设计
5.1逻辑结构设计要点
给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。
5.2物理结构设计要点
给出本系统内所使用的每个数据结构中的每个数据项的存储要求,访问方法、存取单位、存取的物理关系(索引、设备、存储区域)、设计考虑和保密条件。
数据的存储结构:采用二维关系表存储表结构,各表之间通过主键外键关联。
数据存取的威力关系:为表建立索引、视图。不涉及修改数据库的操作。
数据的存取路径:主要采用物理名称存取,有特殊要求可以采用物理名。
数据的存放位置:讲本系统的所有表存放在一个数据库汇总,并对数据库实时进行维护和更新。
数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户进行权衡,选择一个优化方案作为数据库物理结构。此外考虑到安全性,可以对数据库设置角色并将不同的人员添加到不同的角色中去。
5.3数据结构与程序的关系
说明各个数据结构与访问这些数据结构的形式:
数据结构与程序是软件的重要组成部分,程序的正确执行依赖于合理的数据结构。
6系统出错处理设计
6.1出错信息
1、用户登录账号不存在,或者已被注销:用户输入了错误的账号或者此账号已经不使用
2、密码输入错误:初始密码默认为1,后期可以修改密码
3、员工不能订餐:如果员工饭卡余额少于所选订单的金额,不允许订餐
4、结束日期不能超过起始日期:员工在查询订单记录和查询消费记录时候
5、文本框不能为空:在规定的窗体中必须输入卡号才能查询结果
6、刷卡自动消费需要连接读卡器;
7、财务管理需要连接读卡器:对饭卡进行操作的时候,需要使用其饭卡的物理卡号;
6.2补救措施
说明故障出现后可能采取的变通措施,包括:
a. 后备技术说明准备采用的后备技术,当原始系统数据万一丢失时启用的副本的建立和启动的技术,例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术;
b. 降效技术说明准备采用的后备技术,使用另一个效率稍低的系统或方法来求得所需结果的某些部分,例如一个自动系统的降效技术可以是手工操作和数据的人工记录;
c. 恢复及再启动技术说明将使用的恢复再启动技术,使软件从故障点恢复执行或使软件从头开始重新运行的方法。
1、 对于员工登录不存在,交给三楼财务部门查明原因
2、 对于员工密码不正确,在确定是本人的情况下,帮助员工找到密码
3、 对于员工不能订餐, 帮助员工充值金额。
4、 刷卡自动不成功,检查是否读卡器没有正确连接。重新插拔连接。
6.3系统维护设计
软件的维护主要包括数据库的维护和软件功能的维护。
定期为数据库数据进行备份,维护管理数据库死锁问题和维护数据库内数据的一致性等。
对于数据库的维护,本软件已经提供了数据库的备份和恢复的功能,可以方便的实现数据库的维护管理。
对于软件功能方面的维护,由于我们采用的是模块化的设计方法,每个模块(窗口)之间相互独立性较高,这样对软件的维护带来了很大的方便,对于单独功能的修改只需修改一个窗口就行了。而对于功能的添加,只要再添加菜单项的内容即可,将根据客户的要求和反映,定期的对软件进行维护修改。