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

《教职工食堂订餐系统的需求和总体设计》由会员分享，可在线阅读，更多相关《教职工食堂订餐系统的需求和总体设计（13页珍藏版）》请在金锄头文库上搜索。

1、教职工食堂订餐系统需求和总体设计后台子系统目录1.系统需求分析21.1. 系统总体业务流程21.2. 系统功能需求41.2.1.审查注册用户41.2.2. 菜谱信息录入41.2.3. 今日菜单发布41.2.4. 今日订单管理51.2.5. 结帐与教职工信用度管理51.2.6. 留言版管理51.3. 系统其他需求52.系统总体设计62.1.系统设计原则62.2.系统总体架构72.3. 系统功能模块设计92.4. 数据库设计102.4.1.数据库概念结构设计102.4.2.数据库逻辑结构设计112.5. 开发运行平台选择131. 系统需求分析1.1. 系统总体业务流程息信册注户用查审图1教职工食堂

2、订餐系统总体流程图从图1来看，系统主要分为两大部分：系统后台部分（后台子系统）、系统 前台部分（前台子系统）。第一部分为教职工订餐系统的后台子系统部分。食堂管理员成功登陆后，查 看等待审查的注册教职工信息包括教职工号、姓名、性别、单位、办公室地 址、电话号码、密码，食堂管理人员可能通过打电话方式确认教职工信息是否真 实。若所添信息真实，那该教职工就通过审查，该教职工就算正式注册成功了， 教职工的注册信息就上传到教职工信息表，成为教职工信息表的一条记录，同时 删除在待审查注册信息表里该教职工用户的注册信息；否则该教职工就注册失 败；食堂管理员还负责录入菜谱和饮料信息，通过录入菜谱的名字、类型、描

3、述、 图片、价格的形式，生成菜谱信息表，以便日后的修改、删除；管理员必须要负 责发布今天供应的菜谱和饮料信息，让教职工可以查询到今天供应的菜和饮料， 以便教职工用户可以订到喜欢的菜式；在这之后管理员可以查看今日的订单看那 些教职工订了餐和和他今天的订餐记录，根据订单的内容和订餐时间的不同把订 单制成订餐表打印出来然后发送到厨房（厨师按订单包装快餐）和送餐人员（送 餐人员按订单把快餐送到相应的地点）；当送餐人员在送餐返回后，将从教职工 那里收到的钱交给食堂管理人员，食堂管理人员将钱入帐之后，将该教职工的信 用度加一分。如果送餐人员无法将快餐送到教职工的手中，由于是教职工的原因 造成的（可能订餐的

4、送餐地点不对），则扣该教职工的信用度2 分，如果一个教 职工的信用度低于 0 分，则管理员就不让他在网上订餐；管理员可以查看留言版 内容并对教职工的留言给予回复，还可以删除留言内容。第二部分为教职工订餐系统后台部分。教职工填写本人的姓名，性别，单位， 办公室地址，电话号码，密码信息，然后提交给系统生成待审查信息表，等待食 堂管理员审查；教职工在审查通过后就可以以用户身份登陆系统，之后教职工可 以查看今日的菜谱，觉得合适的话就可以直接点击菜谱图片进行订餐或者进入订 餐界面进行订餐，完成订餐后就可以提交订单，生成订单信息表，订单信息包括 菜的名称、数量、订餐时间（必须是当日）、送餐时间（必须是当日

5、）、送餐地点 （如果没有，则默认是该教职工的办公室地址）、联系电话，在提交订单后假如 教职工觉得不合适可以对订单进行修改甚至取消订单，离送餐时间大于 30 分钟 的时间段内教职工可以取消订餐而不扣信用度。离送餐时间小于 30 分钟的时间 段内教职工也可以取消订餐，但是要扣除该教职工的 1 分信用度；教职工还可以 进入留言版通过写下自己的留言的方式向食堂管理员提议和意见和对其他教职 工的留言进行回复。1.2. 系统功能需求1.2.1.审查注册用户1） 食堂管理人员登陆到本系统后，可以看到哪些教职工的注册信息 需要审查，要审查的信息包括教职工的名称、教职工的性别、教职工的电 话号码、教职工的住址、

6、教职工的办公部门，资格审查的目的是只允许本 高校的教职工可以使用本系统。2） 食堂管理员通过打电话等方式核查教职工的注册信息是否真实。 假如教职工提供的信息是真实的就把该职工的注册信息提交到用户信息 表并将审查结果保存到数据库。并且系统默认在该教职工的信用度属性了 加上 4 分。这样该教职工就算通过审查了，同时删除在待审查注册信息表 里该教职工用户的注册信息；否则该教职工审查不通过，就删除他的注册 信息不让他登录。1.2.2. 菜谱信息录入食堂管理员负责录入本食堂的菜谱，菜谱信息包括菜的名称，菜的 描述，菜的图片，菜价格。饮料信息包括饮料名称，饮料的描述，饮料 的图片，饮料价格，其中菜谱和饮料

7、名称必须是中文，食物的描述和图 片可以为空，食物价格精确到小数点后两位，然后食堂管理员把录入的 菜的信息和饮料信息保存到数据库（菜谱信息表）。添加菜谱信息完成后 食堂管理员可以浏览已添加的菜和饮料信息，可以对不满意的菜或饮料 的数据进行修改，例如修改菜谱名字、描述、更新或重新上传图片、更 改价格甚至可以直接把菜或饮料从数据库里删除。1.2.3. 今日菜单发布1）食堂管理员可以首先浏览菜谱信息表里的那些已经发布的菜谱与 饮料信息，因为每天的要发布的菜单一般来说都不会有很大的变动，所以 可以把过去发布了的菜单保存到数据库了而不必要每次都重新发布菜单 一次。只有当要发布某些特别的菜或饮料（比如说季节

8、上的时令菜式）时， 才需要重新发布菜单和饮料假如觉得以前已发布的菜单合适的话就不需 要发布菜单更新浏览器公布的菜和饮料，直接就让教职工用户在原来的菜 单上进行订餐。2）假如食堂管理员觉得已发布的菜单不满意，比如说有些菜或饮料 现在已经没有或过时了的话，就要更新今日菜单发布的菜或饮料的信息， 取消某些已发布的食物和饮料，让它们的状态从发布转为未发布，然后浏 览菜谱信息表里的菜和饮料寻找合适的菜谱，然后把合适的的菜或饮料发 布到浏览器，让教职工用户进行选择和订餐，之后教职工可以重新查看已 发布的菜单信息。1.2.4. 今日订单管理在教职工用户提交了自己的订单后，食堂管理员可以以单个用户为单 位查看

9、每个有订餐的教职工用户所有的订单信息，包括订单号、食物的名 称、食物的数量、食物的单价、送餐地点和送餐的时间，然后根据送餐时 间的先后顺序分别把它们打印出来，然后发送到厨房（厨师按订单包装快 餐）和送餐人员（送餐人员按订单把快餐送到相应的地点）。1.2.5. 结帐与教职工信用度管理食堂管理员就查看教职工用户的帐单（订单）作核对和查看当前教职工 用户的信用度，核对正确后就给教职工结帐并且给该教职工的信用度增加一 分同时注销该教职工用户的订单信息；如果送餐人员无法将快餐送到教职工 的手中，由于是教职工的原因造成的（可能订餐的送餐地点不对），则扣该 教职工的信用度 2 分同时注销该教职工用户的订单。

10、当该教职工的信用度少 于或等于 0 分时，食堂管理员就注销该教职工的帐号让他下次无法登陆订餐 系统进行订餐。1.2.6. 留言版管理食堂管理员还可以进入教职工留言版查看所有教职工用户的留言信息，包括 留言ID、留言人的IP地址、用户名、留言内容、其他用户的回复内容、 回复时间、该教职工用户的E-Mail、教职工用户的留言时间，对于教职 工反映的问题和意见可以给予回复，对于那些已经作出回复的留言并已过 了较长时间的留言可以给予删除。1.3. 系统其他需求（一）精度需求1 在执行数据增加的时候，不允许出现因为程序的原因导致增加操作失败， 也不允许发生重复增加的数据。2 在执行数据删除操作的时候，不

11、允许因为程序的原因发生多删除数据、 删除失败的情况。3 数据的修改也要求保持对应的准确性。4 对汉字字符进行操作时无论上传数据还是获取数据时都不能出现或变成 乱码。（二）时间特性要求1 在单用户执行增加修改和删除操作的时候，在运行环境规定的条件下， 单次操作的响应时间要求在 3 秒钟之内。2 返回 100 行数据以内的数据查询，单次操作的响应时间要求在 3 秒之内。3 多人操作时候，时间的相应要求同上。（三）故障处理要求1 在操作成员输入一些不合理的数据的时候，能够进行一些合理的提示信 息，不能因为输入错误而导致系统的错误，或者程序停止运行。2 程序运行时，对服务器和网络通信故障能够识别并提示

12、，当故障排除后， 程序恢复正常运行。3 数据库要求有灾难备份机制，以防止数据的全部丢失。（四）安全需求1 数据库安全：数据库级备份和恢复。数据库级用户进行角色和权限授权。 使得在异常情况发生时，系统可以得以快速恢复，避免数据的丢失或将其 影响降到最低限度。同样，要保证存储过程中数据不被非法访问和篡改。2 应用系统的安全：通过对用户的身份鉴别，并实施相应的访问控制策略 后，使用户只能完成得到系统授权的数据访问功能操作。用户只有经授权 后才可以更新程序，避免因错误程序更新而影响系统的正常运行。2. 系统总体设计2.1. 系统设计原则1） 问题界定问题的界定，对于软件开发来说是至关重要的。因为任何一

13、个软件 都是为了更好的解决某些问题而开发的，只有准确地对问题进行界 定，才能明确地把握软件系统的功能，以及系统的扩展方向。2) 功能分解，逐步求精 分解一直被认为是分析大而复杂设计问题的有力工具 ,分解的一个 突出的优点是降低设计问题的复杂性。采用逐步求精，就是在确保 全局的正确性之后，再分别对每一局部进行考虑，每个局部又将是 一个问题或任务。采用逐步求精的优点是：便于构造程序。由这种 方法产生的程序，其结构清晰、易读、易写、易理解、易调试、易 维护2。3) 模块独立化 通过模块独立化，可以有效的实现信息隐蔽，提高内聚，降低耦合； 这对测试及后期维护中需做变更时提供了极大的优点。4) 适应性和

14、可扩展性原则 系统需要具备一定的适应能力，特别是 Web 应用要能适应于多种运 行环境，来应对未来变化的环境和需求。可扩展性主要体现在系统 易于扩展，例如可以采用分布式设计、系统结构模块化设计，系统 架构可以根据网络环境和用户的访问量而适时调整，从某种程度上 说，这也是系统的适应性。5) 可靠性原则 系统应该是可靠的，在出现异常的时候应该有人性化的异常信息方 便用户理解原因，或采取适当的应对方案，在设计业务量比较大的 时候可采用先进的嵌入式技术来保证业务的流畅运行。2.2. 系统总体架构通过系统的总体需求分析，得出系统要求的数据安全性能是不太严格的，系 统的使用范围可分为食堂管理员和大量的教职

15、工用户，其中食堂管理员都是非计 算机技术专业人员，因此要求系统可操作简单，系统使用简便，客户端基本不需 要什么维护或维护简单，成本低；对于教职工用户来说，系统使用方便，可扩展 性高，不需要专门的网络设备，界面生动友好，系统响应速度快。鉴于此，经过认真考虑之后，决定系统采用当代最流行的B/S结构和MVC模 式来实现。B/S结构：(Browser/Server，浏览器/服务器模式)是WEB兴起后的 一种网络结构模式，WEB浏览器是客户端最主要的应用软件。这种模式统一了客 户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和 使用。 B/S 最大的优点就是可以在任何地方进行操作而不

16、用安装任何专门的软 件。只要有一台能上网的电脑就能使用，客户端零维护。系统的扩展非常容易。 系统的结构如图 2 所示：Web 浏览器Web 服务器数据库服务器图 2 系统总体结构构图用户界面层：负责处理用户的输入和向用户输出，同时对用户的输入进行合 法性验证。业务逻辑层：这一层是上下两层的纽带，它建立实际的数据库连接，根据用 户的请求生成检索语句或更新数据库。利用 JSP 技术把结果构造为 HTML 发送到 客户端。数据层：负责数据的存储、维护和检索。MVC模式是Model-View-Controller的缩写，中文翻译为模式-视图-控制 器。MVC应用程序总是由这三个部分组成。MVC模式的组件