教职工食堂订餐系统的需求和总体设计

教职工食堂订餐系统需求和总体设计——前台子系统

目录

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)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。