教职工食堂订餐系统需求和总体设计——前台子系统目录1 系统需求分析 (2)1.1系统总体业务流程 (2)1.2系统功能需求 (3)1.3系统其它需求 (5)2 前台子系统的总体设计 (6)2.1MVC设计方法介绍 (6)2.2系统整体架构 (8)2.3前台子系统功能模块设计 (9)2.4前台子系统总体页面设计 (9)2.5数据库设计 (10)2.5.1数据库概念结构设计 (10)2.5.2数据库逻辑结构设计 (11)2.6开发运行平台选择与分析 (14)1系统需求分析1.1 系统总体业务流程图1 教职工订餐系统客户端流程图从图1来看，前台子系统主要分为五大模块：查询今日菜单模块、留言板模块、购物车模块、注册登录模块、用户中心模块。
图2 教职工订餐系统管理端流程图从图2来看，后台子系统主要分为七个模块：审查注册员工资格、菜单管理、今日菜单管理、推荐菜管理、信用度管理、订单打印和账单打印。
1.2 系统功能需求这里只对订餐系统的前台子系统五个模块即查询今日菜单模块、留言板模块、购物车模块、注册登录模块、用户中心模块和后台子系统部分的审查注册员工资格模块进行分析,其具体如下：1.2.1 查询今日菜单1)任何用户登录网站即可以直接查询今日菜单,但是登录之后才能购买各种食物。
2)饮料订购快速窗口,直接查看饮料信息.3)炒菜订购快速窗口,直接查看炒菜信息序号功能列表功能明细1 查询今日菜单查看今日菜单全部,点击单个食物可以查看详细信息2 饮料速订查看今日菜单后,可以只查看饮料信息3 炒菜速订查看今日菜单后,可以只查看炒菜信息1.2.2 留言板1)任何人登录网站都能查看,回复全部留言和签写新留言。
2)管理员登陆时可以删除留言。
1.2.3 购物车模块1)将选中的食物放入购物车。
2)浏览购物车。
3)取消购物车中的某一件食物。
4)继续购买。
5)清空购物车。
6)订餐。
表3 购物车模块功能表1.2.4 注册登录1)新用户注册,填写正确的注册信息,等待管理员审查。
2)通过审查的用户登录。
1.2.5 用户中心1)用户信息修改。
2)用户密码修改。
3)订单管理。
4)用户注销。
表5 用户中心模块功能表1.2.6 管理员审查注册员工资格1)查看待审查注册员工信息。
2)通过该员工注册。
3)放弃该注册员工。
1.3 系统其它需求1.3.1系统扩展性要求系统的运行将为以后的学生食堂在网上运行提供宝贵的经验,所以,对于系统功能的扩充要求比较高,系统后期的升级才能顺利方便,这就要求在建立系统的构架和设计系统时,一定要注意系统的可扩展性,而且现在很多项目开发是分期进行的。
暂时准备的扩展有一些比较高级的功能,比如系统向用户提供收藏夹模块功能,用户可以把喜欢吃的食物收藏起来,下次购买时可以直接生成订单,还有网上充值和结账模块,使订餐的全程除了送餐外,全部实现在网上,达到真正的网络化。
1.3.2时间特性要求1)在用户执行添加删除食物,取消订单等操作的时候，在运行环境规定的条件下，单次操作的响应时间要求在3秒钟之内。
2)系统同时上线人数不超过数据库承受能力时,相应速度不应超过3秒。
1.3.3 错误处理要求1)在用户输入一些不合理的数据的时候，能够进行合理的提示信息,并且正确处理跳转逻辑，不能因为输入错误而导致系统的错误，或者程序停止运行。
2)程序运行时，对服务器和网络通信故障能够识别并提示，当故障排除后，程序恢复正常运行。
3)数据库要求有备份机制，以防止数据在意外情况下丢失。
1.3.4 安全需求数据库安全：数据库级备份和恢复。
数据库级用户进行角色和权限授权。
使得在异常情况发生时，系统可以得以快速恢复，避免数据的丢失或将其影响降到最低限度。
同样，要保证存储过程中数据不被非法访问和篡改。
应用系统的安全：通过对用户的身份鉴别，并实施相应的访问控制策略后，系统之分普通教职工用户和管理员,特殊操作如更改或删除数据库的操作必须受到严格的权限限制,以保证系统的正常运行。
2前台子系统的总体设计2.1 MVC设计方法介绍图3MVC组件类型的关系和功能[8]MVC英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。
视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。
随着应用的复杂性和规模性，界面的处理也变得具有挑战性。
一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。
业务流程的处理交予模型(Model)处理。
比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。
模型(Model)：就是业务流程/状态的处理以及业务规则的制定。
业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。
业务模型的设计可以说是MVC最主要的核心。
目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。
它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。
对一个开发者来说，就可以专注于业务模型的设计。
MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。
抽象与具体不能隔得太远，也不能太近。
MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。
我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。
这点对编程的开发人员非常重要。
业务模型还有一个很重要的模型那就是数据模型。
数据模型主要指实体对象的数据保存（持续化）。
比如将一张订单保存到数据库，从数据库获取订单。
我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。
控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。
划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。
控制层并不做任何的数据处理。
例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。
因此，一个模型可能对应多个视图，一个视图可能对应多个模型。
图4 MVC的分工与协作模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。
如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。
因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。
这实际上是一种模型的变化-传播机制。
模型、视图、控制器三者之间的关系和各自的主要功能，如图3所示。
2.2 系统整体架构通过对系统的需求分析，确定了整个系统为一个WEB系统，采用的是MVC模式进行网站的开发,在这个系统中使用的Web Server是Tomcat 6.0,DBMS(数据库管理软件)是SQL Server 2000,并且使用Microsoft提供的JDBC驱动程序。
基于MVC 模式的WEB项目的优点在上一节中已经介绍过了，在知道了Jsp、Servlet、Javabean分别在MVC模式中的角色和功能后，这里对网站的整体构架做一个详细描述，工作流程为：a) Web客户机向Web服务器发出请求；b) Web服务器把这一请求转送给控制器Servlet；c) Servlet对JavaBean进行必要的操作；d)控制器把处理结果转发给JSP视图；e) JSP视图对模型进行格式化以备显示，并把HTML结果回送给Web服务器；f) Web服务器再把信息回送给Web客户机。
图5：系统构架图2.3 前台子系统功能模块设计前台子系统的功能模块图如下：图6：前台子系统功能模块图1)登录注册：教职工用户注册为系统用户，登录使用该系统；2)查询今日菜单：任何用户都可以查询今日菜单，点击按钮则显示今日菜单；3)购物车：用来临时保存登录用户所购买的物品，用户可以对购物车内的物品进行添加删除清空等操作，确认购买后，可以提交订单；4)用户中心：用户登录后可以修改自己的注册信息，密码，查看自己的订单状态和信息，并且可以退出系统；5)留言板：任何用户均可查看留言，并且允许签写新留言和回复留言，用于普通用户和其他用户交流、与管理员的交互和管理员用户进行答疑等，管理员用户可以删除任何留言。
2.4 前台子系统总体页面设计1).页面框架开发一个网站,好的界面风格和页面框架是非常重要的,特别是对电子商务网站如本食堂订餐系统更需要有好的”门面”。
本系统采用的是比较传统的框架,如图7所示。
图7 页面框架可以看到,页面包含三个部分,最上面是菜单部分,下面的左边部分是一个固定页面,右边部分包好了根据不同的页面显示的内容,所有页面都直接套用该框架。
2).页面风格对于本系统来说,网站的美观是用户订餐的一种胃口的保证,是吸引顾客的重要因素之一,所以一般需要在页面里面制作专业的图片和动画,本系统中的头部和左边都有一个精美而且实用的FLASH动画,分别为top.swf和menu.swf,增加了页面的美感。
同时在页面的整体风格上,定义了两个统一的式样单style.css和web.css。
2.5 数据库设计2.5.1数据库概念结构设计前台子系统以及管理员审查模块的ER图如下：图8 前台子系统部分模块E-R图教职工实体的主要属性：教职工号，用户名，密码，性别，联系电话，办公室地址，单位,信用度。
待审查教职工名单实体的主要属性：教职工号，用户名，密码，性别，联系电话，办公室地址，单位。
管理员实体的属性：编号，用户名，密码,真实姓名,电话。
菜谱实体的属性：食物编号，食物名，类型，描述，图片，价格，是否为今日菜。
购物车实体的属性: 食物名,食物数量,总价格,订餐人,送餐时间,送餐地址。
订单实体的属性: 订单号,食物名,单个食物价格,食物数量,订餐用户,送餐时间,送餐地址。
留言的属性：留言编号，IP，留言者邮箱，留言时间，留言内容，回复内容，回复时间，昵称。
2.5.2数据库逻辑结构设计以下仅对重要的表进行列举和分析。
表7：教职工信息表 userInfo说明:用户使用userName和userPwd进行登录, userTel将作为管理员与用户取得联系的重要方式,其他信息用于管理员进行身份审核时对照只用,信用度每个人初始为4,以后根据规则,信用度将会调整,当信用度小于1时,该用户将被取消订餐功能。