尚择精文XXUML食堂售饭系统.docx
基于UML的外卖订餐系统需求分析
面向对象的分析和设计说明书( 2018 -- 2019 学年第二学期)题目：基于UML的外卖订餐系统需求分析日期：2019 年5 月3日1. 系统概述2．系统分析建模外卖订单系统是服务于餐馆外卖活动的一个简单的信息系统，开发该系统主要希望实现扩大本餐馆宣传、缩短顾客订餐时间、减少订餐错误、便于订单统计分析等，最终达到扩大餐馆影响力、提高餐馆外卖业务效率、实现一定程度的决策支持的目的。
该系统按照功能主要分为三类角色，分别是顾客，商家，送餐员。
顾客角色主要可执行的操作有顾客用户操作（包括登录和注册），检索操作（包括检索餐品或商家等），订单操作（包括编辑订单和提交订单），评价操作（包括评价餐品和餐厅）。
商家角色主要可执行的操作有商家用户操作（包括登录和注册），餐厅管理（包括菜单编辑、编辑餐厅信息等），订单管理（包括查看和更新订单），评论管理（包括查看评论和回复评论）。
送餐员角色主要可执行的操作有送餐员用户操作（包括登录和注册），订单操作（包括配送订单、订单查询、确认接单等），通知操作（通知顾客或商家）。
2.1用例图【三类顾客顶层用例图】图1三类顾客顶层用例图本系统预计实现的核心功能有：（1）顾客角色——顾客操作查询餐品：按照餐品种类或名称查询后选择某一餐厅查询餐厅：按照餐厅名查询后选择某一餐厅餐厅列表：餐厅列表包括了该餐厅的基本信息，包括餐厅名称、餐厅位置、餐厅距离、餐厅销量、人均消费。
订单管理：记录顾客当前正在进行的订单以及历史订单。
顾客可以删除历史订单，也能及时查看当前正在进行订单的状态和信息。
购物车界面：相当于临时订单界面，用于显示当前订单中已选餐品的信息（包括餐品的名称、数量、总价）和订单支付状态。
确认购物车信息无误后，顾客提交订单并支付。
提交订单后，购物车中不再显示该订单的信息。
（2）商家角色——商家操作确认接单功能：商家在收到用户提交的订单后，确认接单并通知该订单的顾客已接单。
商家确认接单后，将当前订单信息发送给附近区域的送餐员，等待送餐员接单。
上海食堂售饭系统
XX食堂售饭系统ID联脱一体消费智能管理系统目录概述:一、投资分析二、系统组成与结构图三、授权发卡系统3．1 售饭机键盘简介：3．2消费机设置：技术参数服务器的技术指标及参数四、系统管理软件介绍ID消费软件菜单系统运行环境要求：五、系统功能特点六、工程布线要求：七、系统配置八、售后服务概述:本系统是XX火悦电脑XX“一卡通”的一部分，它是以计算机管理为核心、以非接触式ID卡为信息载体、以售饭机为消费终端的全新智能收费管理系统，现已广泛应用于企业、机关、学校等的公共消费场所。
消费者只需持一X经过授权的ID卡，感应读卡，即可完成各种消费的支付过程；而系统在后台强大的软环境和完善的硬件基础上完成信息加工处理工作，统一进行ID卡的发行、授权、取消、挂失、充值等工作，并可查询、统计、清算、报表、打印各类消费信息及其它相关业务信息。
一、投资分析由非接触式ID卡食堂售饭管理系统所引起的“收费革命”，必将为企业带来如下效益：▼消费方式快捷、方便，极大地提高了工作效率，优化了服务质量。
▼消除了现金交易的繁琐和误差，并有效地防止了各种徇私舞弊的行为。
▼加强了卫生管理。
▼收费和统计的全面自动化，方便了财务管理，亦可堵塞其它管理漏洞。
▼降低维护成本，减少管理费用。
▼预收费和卡押金，加速了资金回笼。
二、系统组成与结构图ID联脱一体消费智能管理系统主要由管理计算机（必须含有两个串口，本系统要用到两个，可外加一个串口卡。
）、联脱一体消费机、联脱一体服务器、非接触式ID 卡、授权发卡系统、系统管理软件及其它外围设备等组成。
其结构图如下：发卡器联脱一体服务器┉┉┉┉┉┉三、授权发卡系统授权发卡系统主要进行发行、授权、取消、挂失各级ID 卡的工作及进行读写设备的授权设置工作，它主要由发卡机、发卡软件和一系列卡片组成。
消费卡，经过授权后可在售饭机上进行消费，可不断充值。
售饭机介绍3．1 售饭机键盘简介：（0—9）数字键：用于输入消费金额。
食堂售饭系统需求规格说明书 精品
需求规格说明书项目名称：食堂售饭管理系统1引言1.1编写目的本文档主要是对获取的用户需求，综合考虑组织目标、现状、技术条件、投资能力等因素，从系统目标、结构、功能、性能、风险等方面对食堂售饭管理进行深入细致地分析，剔除相互矛盾、不一致、有歧义或者不必要的需求，最终确定出合理、正确、可行的系统需求，尽可能地满足用户要求，避免开发人员和用户之间的误解。
本文档将详细、准确地反映最终确定的系统需求内容，简要地反映需求分析的过程以及相关问题；既是对需求分析工作的总结，又将作为后续开发阶段系统分析、设计、实现和测试的工作纲领。
1.2背景本次系统开发不是从头做起，而是在食堂原有的系统上进行完善和扩充，食堂原有的系统已经能够完成通过一卡通进行消费，并且此套系统在收费方面已经比较完善，我们的任务是完成额外的进货和库存，员工管理，收益汇总及分析，同时还要考虑通过数据挖据和人工智能的方式优化食堂的进存货安排，菜品配置及窗口设置等等一系列的问题，提高食堂的原料利用率，食品质量及单位时间内的客流量，达到节约成本，提高口碑，加快出售的目的。
A.待开发的软件系统的名称：食堂售饭管理系统B.项目的任务提出者：XX学校食堂C.项目开发者：哈尔滨工程大学计算机科学与技术专业110614班第4小组D.本文档的读者范围包括：a．需求提供方具体责任人b．开发方项目负责人、系统分析设计人员1.3定义A.非营业开支：除采购款、销售款外，食堂维持正常运营所需开支B.报损：库存损坏商品上报C.报溢：库存非正常（顾客遗失等原因）增加商品上报1.4参考资料A.《系统设计与分析》哈尔滨工程大学邢薇主编B.软件设计文档国家标准－需求规格说明书（GB856T——88）》2任务概述2.1目标食堂管理系统将结合原有的收费系统，同时完成员工管理，采购，库存、进行决策分析等，智能化食堂售饭管理。
☞软件的主要的改进部分涉及的员工数不是太多，大多是中高层人员，一般员工不需培训仍然可以使用该系统，对于相关的部分需要另配专业人员，如数据分析和智能设备管理。
基于UML的餐厅点餐系统设计
个性化服务：系统可以根据客户的用餐历史、口味偏好等信息，为客户提供 个性化服务，如自动推荐菜品、提醒客户上次点的菜等。
菜品管理：管理员可以在系统中添加、编辑和删除菜品信息，包括菜品图片、 名称、价格、口味等。
账单管理：系统可以自动计算账单金额，包括菜品金额、服务费等，方便服 务员和收银员操作。
参考内容
随着科技的不断发展，餐厅行业也在逐步走向数字化和智能化。为了提高顾 客体验和提升餐厅运营效率，餐厅自助点餐管理系统应运而生。本次演示将介绍 餐厅自助点餐管理系统的背景、架构、功能模块、实现方法以及系统优化等方面 的内容。
一、背景介绍
餐厅自助点餐管理系统是在互联网技术和移动支付的普及下逐渐发展起来的。 过去，顾客需要在餐厅内排队等待点餐，支付手段也相对单一。随着移动支付的 兴起，顾客对于便捷、快速的服务需求也越来越高。因此，餐厅自助点餐管理系 统成为了市场上的热门选择。
1、架构设计
系统采用B/S架构，由客户端、 服务器和数据库组成。
客户端主要负责用户的交互，包括点餐、查看菜单、下单等功能。 服务器负责处理客户端的请求，与数据库进行交互，实现业务逻辑。
数据库负责存储系统数据，包括用户信息、菜单信息、订单信息等。
2、功能设计
快速点餐：客户可以通过客户端输入菜品编号或名称进行点餐，同时系统可 以推荐相关菜品或根据客户口味偏好自动推荐。
fied Modeling Language，统一建模语言）的餐厅点餐系统，可以提高点 餐效率和服务质量，同时提升客户的用餐体验。
需求分析
基于UML的餐厅点餐系统需要满足以下需求：
1、快速点餐：系统应该能够快速处理客户的点餐请求，减少等待时间，提 高点餐速度。
2、个性化服务：系统应该能够根据客户的口味、偏好等信息，推荐适合的 菜品，提供个性化服务。
食堂售饭系统分析与设计UMLword文档
食堂售饭系统分析与设计目录1. 需求分析与描述 (2)1.1 需求分析 (2)1.2 用例分析 (2)1.3 用例模型图 (4)1.4 用例事件流描述 (5)2.领域模型分析 (8)3.工作流程分析 (9)1. 需求分析与描述1.1 需求分析●持卡人：办理新饭卡，给饭卡充值，注销饭卡，挂失/撤销挂失饭卡，补办新卡，退还饭卡，使用饭卡消费，查看个人消费的明细。
●管理部门：通过计算机系统具体实现持卡人需求中的项目。
●食堂工作人员：通过自动售饭机输入饭菜的金额，通过计算机系统对当天的营业情况进行汇总统计。
1.2 用例分析1)系统的边界对于系统边界，系统首先会包含需求分析中所需要软件实现的各项功能，此外还须确定食堂售饭系统是否包括管理部门和食堂工作人员。
就食堂售饭系统而言，其主要功能是让用户（即持卡人）享受服务（即用饭卡使购买饭菜的过程绕过了付款及找零的环节，提高了服务效率），而管理部门和食堂工作人员的作用都是为了使用户免于对系统的直接操作而设置的，因而此两者应归为食堂售饭系统的内部，相当于用户和具体的计算机软硬件系统之间的接口。
2)系统的执行者持卡人需要通过食堂售饭系统来使用其所持有饭卡买饭，因而是整个系统的执行者；管理部门根据持卡人的需求操作计算机系统从而实现与饭卡相关信息的管理，相当于其中饭卡信息管理子系统的使用者，是位于食堂售饭系统内部的执行者；食堂工作人员同样通过操作计算机系统来实现购买饭菜过程中的扣费功能以及对营业情况进行的汇总统计的功能，相当于其中消费处理与统计子系统的使用者，也是位于食堂售饭系统内部的执行者。
这样得到了系统中的执行者：●持卡人●管理部门●食堂工作人员3)系统的用例根据用户需求及执行者的分析，得到系统的用例如下：●办理新饭卡●饭卡充值●注销饭卡●挂失/撤销挂失饭卡●补办饭卡●退还饭卡●查看个人消费的明细●扣除饭卡费用（对应于持卡人使用饭卡消费）●汇总统计1.3 用例模型图根据前面的分析，可以得到系统的用例模型图，如上图所示。
基于UML的餐馆订餐系统分析与设计(doc 7页)
基于UML的餐馆订餐系统分析与设计(doc 7页)基于UML的餐馆订餐系统的分析与设计软件工程0701 张正娟摘要：为了方便餐馆人员能够按照客户需求分配餐桌，并能有条理的记录订菜单，减少因管理无序与客户产生不必要的冲突，需要实施开发设计一个适用于餐馆的订餐系统，本文应用面向对象的分析技术，基于UML对餐馆订餐系统进行了分析与建模实践。
关键字：UML，餐馆订餐系统，StarUMLAnalysis and Design of Restaurant Booking System based on UML Abstract: In order to better understand system, modeling is necessary. In software development process, the UML is usually used as a standard method to model related products. In this paper, authors use object-oriented technology to analysis and model the restaurant booking system of primary and secondary school based on UML.Key words: UML,restaurant booking system,StarUML1. 引言当前社会对信息系统的需求日益增长，需求变化也越来越大，软件开发的技术发展方向已经从“提升被开发系统的执行效率”转变为“提升开能。
2. 需求分析2.1基本要求本系统的基本需求是餐馆在营业时记录预约、更新预约单信息、分配餐桌以及接待未预约的顾客的能力，还添加了会员业务，为会员提供提前点菜的服务。
主要的功能有下订单、修改订单、取消订单以及在顾客未按时到达时及时提醒顾客；同时还能记录未预约的顾客（Walk-In）；维护订单和未预约记录，如记录到达、离开，以便及时更新餐桌的状态；附加的功能有管理会员信息，为会员提供提前点菜的服务。
UML餐馆系统：业务建模
第4章餐馆系统：业务建模接下来的四章将考虑一个简单的案例，并给出一个从需求获取到实现的完整开发过程。
我们将考虑一次单独的迭代，它通过统一过程标识的主要工作流之中的四个：即需求、分析、设计和实现，用例子说明UML表示法在软件开发中的使用。
由于本案例研究的意图在于强调开发的产品而不是过程，所以不会详细考虑由统一过程定义的这些工作流的结构，而在真正需要的地方将在介绍UML表示法的同时，简略介绍开发中涉及的活动。
4.1 非正式的需求要开发的系统的意图是，通过改进为顾客预定和分配餐台的过程，支持一家餐馆的日常经营。
这家餐馆当前采用一个手工预约系统，使用的是保存在一个大文件夹中的手写预约单。
图4.1是当前的预约单的一个例子，预约单中的每一行对应餐馆中一张特定的餐台。
预约是对特定的一个餐台登记的，每个预约中记录有“餐具”的数目，或者预期进餐者的数目，这样就能够分配一个大小适当的餐台。
这家餐馆在晚间供应三次餐点，称为“简餐”、“正餐”和“夜点”时段。
但如同预约单所表明的，这些时段无须严格遵守，可以预约跨多个时段的时间。
最后，每个预约中要记录联系人的姓名和电话。
图4.1 手工预约单为了记录各种事情，要在预约单上加一个注文。
当一行用餐者到来并在他们的餐台就座时，就划掉相应的预约登记。
如果他们就座的不是他们预约的餐台，就画一个箭头从最初预约的餐台指向新的餐台。
如果顾客打电话取消预约，并不能从表中真正地擦除，而是做一个预约已经取消的注文。
其他的信息，比如到什么时间餐台必须空出来，也可以写在预约单上。
如果有空闲的餐台，用餐者当然也可以不提前预约就进餐馆用餐，这被称为“未预约的顾客（walk-in）”，并在预约单中作为预约登记以表示餐台的占用，但不记录顾客的姓名或电话。
4.1.1 对计算机化系统的需要这家餐馆的管理人员已经确认了很多与手工系统相关的问题。
手工系统速度慢，而且，预约登记单很快就变得难以理解。
这可能导致经营上的问题，例如，实际上有空餐台而由于这个预约单不是很明显，会妨碍顾客进行预约。
uml建模 订餐系统
UML统一建模语言 UML统一建模语言
二、创建系统用例模型
接待员用例能够通 过该系统进行如下活动： （1）记录订餐信息。 接待员将客人的订餐要 求输入到系统中予以保 存。 （2）订餐定时提醒。 （3）取消订餐记录。 接待员在客人的预定的 客人因临时原因取消订 订餐时间之前给客人一 餐，接待员将系统中原 个提醒，同时再次加以 来的订餐信息予以取消。 确认。
4、领班记录订餐客人到店的序列 领班记录订餐客人到店的序列 图和交互图
UML统一建模语言 UML统一建模语言
三、创建系统动态模型
领班记录订餐客人离店的基 本工作流程如下： （1）订餐客人用餐完毕后离 店。 （2）领班登录系统进入操作 界面Form，输入订单号，系统到 数据库对象DataBase查询此订单 是否存在。如果不存在，返回提 示信息。 （3）如果订单存在，则返回 订单信息并显示在操作界面。 （4）领班提交客人离店的时 间，订单对象Order修改订餐记 录中的订餐状态，同时更新数据 库中订单的信息。 （5）返回订餐状态修改成功 的提示信息。
14、 14、领班记录订餐客人到店 活动图
UML统一建模语言 UML统一建模语言
三、创建系统动态模型
领班记录订餐客人离店的活动 图，先创建了二个泳道，分别是领 班对象和系统对象。具体的活动过 程如下： （1）领班在界面输入到店客人 的订单号。 （2）系统判断订单是否存在， 如果不存在，返回订单不存在的信 息。 （3）如果订单存在，领班输入 订餐客人离店的时间，对订单的状 态进行修改。并同时更新数据库的 数据。 （4）最后向界面返回修改成功 的信息。
13、 13、接待员定时提醒预订活动 图
UML统一建模语言 UML统一建模语言
三、创建系统动态模型
UML案例-食堂系统
搜索卡号()
整理课件
• 售饭——搜索该人的卡号，类图
数据库系统
系统
串口记录
饭卡
饭卡记录
整理课件
• 售饭——扣除金额
售饭机
接收金额()
串口
接收金额()
[大于20元]输入密码
系统
串口记录
接受金额() 金额 [小于20元]扣除金额()
饭卡
接受密码()
接受密码()
接受密码() 密码 查询密码()
[密码不正确]显示原金额() 显示余额()
读卡机
窗体
串口
系统
饭卡
整理课件
• 存钱——设计类图
串口
读卡机
系统
饭卡记录
窗体
饭卡 整理课件
数据库系统
• 存钱——设计类图 添加“串口记录类”
串口
读卡机
系统
串口记录 饭卡记录
窗体
饭卡
数据库系统
整理课件
5.3 售饭
读卡号
搜索该人记录
生成饭卡 扣除金额
更新数据库
整理课件
• 售饭——获取卡号——添加“串口记录”类
• 食堂售饭系统 • 1 找出执行者 • 1.1 列出所有的执行者 • 管理部门：处理饭卡的发放、挂失、注销 • 持卡人：申请新卡、追加存款、使用饭卡买饭、挂失、
注销 • 饭卡：保存饭卡信息（持卡人姓名、单位、密码、金额
等） • 售饭机：判断卡中金额是否充足、减去工作人员输入的
饭菜金额 • 师傅：输入所选饭菜的金额 • 计算机系统：统计食堂当天的营业额、打印当天的“分
插卡 用户
售饭机
系统
串口
串口记录
接收卡号()
食堂售饭系统管理方案
感应式智能卡食堂售饭管理系统方案一、概述现代信息识别技术的发展是现代科技发展中最活跃的一部分,自从条码识别技术诞生以来,先后出现了磁条读写技术、接触式IC卡读写技术、光电卡读写技术，每一种新技术的诞生都是社会需求和科技进步的成果，都会给人民生活带来极大便利，但他们又都存在或多或少的局限性，如存储量少、使用寿命短、受食堂环境影响而读写困难等。
80年代末世界上出现了感应式智能卡读写技术，经历了近十年的不断发展和完善，日趋成熟，并广泛应用到工业、商业和人民生活之中。
非接触感应技术基于电磁感应原理，无需物理接触即可完成信息读写，读写所需瞬间能量由读写器提供，使用这种非接触IC卡可实现一卡多用的功能，它与传统的卡证技术相比，采用非接触IC卡技术能很好实现校园内部统一化、安全化、科学化的管理方式，其具有如下优点：●使用寿命长、维护成本低：非接触IC卡与读写器无需机械接触即可完成信息读写，避免了接触式读写而产生的卡损伤和读写机的故障，从而大大地提高了卡和读写设备的使用寿命。
正常使用可以保证非接触IC卡的使用寿命，使用寿命在10年以上。
●使用方便：非接触IC卡的读写非常简单，不需固定方向和位置，便于持卡人的使用。
●安全可靠：每次卡读写过程符合ISO/IEC14443标准的三次DES加密；每张卡片在出厂时都写有不可更改的唯一编号，并可为第一用户设定卡与读写设备相对应的唯一的密钥，卡和读写设备均无法复制，确保系统的安全性和可靠性。
●高抗干扰性：非接触式中具有防冲突机制，在多张卡片进入读写器的工作范围时防止卡片之间出现数据干扰，允许多张卡同时操作。
●一卡多用：卡片可实现一卡多用的需要。
同一张卡片经个人化处理后，既可作为学生证、借书证等等，也可作为校园咖啡厅和其它消费用的电子钱包，等诸多功能。
●性能价格比最优：由于上述的性能特点，采用非接触IC卡实现一卡通管理，是一种性能价格比最优的解决方案。
二、食堂售饭工作特点和系统设计原则2.1 食堂售饭运作具体特点●现场操作和金额计算比较繁琐。
售饭管理系统
售饭管理系统食堂售饭管理系统最早使用于校园，微机食堂售饭管理系统的研制成功和投入使用开启了伙食管理的革命，它不仅堵塞了伙食管理中长期存在的、难以根除的漏洞，而且作为一种电脑自动结算系统,替代了传统的餐券结算方式，从根本上解决了餐券流通过程中的伪造、丢失、病菌交叉感染等一系列难以根除的弊端，节省了餐券在印刷、发放、兑换、回笼、清点、保管、复核等环节上的大量人力、物力、财力，该系统的全面推广和应用为后勤管理工作向自动化、科学化方向发展开辟了广阔的前景。
现在的消费管理系统已经远远超出了售饭系统的概念，已经延伸到学校超市、小卖部、医务室、洗衣店以及其他场馆的收费管理。
系统具有以下特点：1、从企业管理角度出发：杜决了餐券、现金流通过程中的丢失、假钞、破钞，节省了餐券、现金的兑换、回笼、清点、保管等环节上的人力、物力、财力，提高管理层次。
2、从企业投资角度出发：该系统可扩展为企业一卡通，实现食堂售饭、考勤门禁、、节水控制消费等企业内消费、管理使用一张卡全部完成的功能，避免重复投资。
3、从饮食卫生的角度出发：避免了一手找零钱，一手打饭菜的现象，减少了餐券、现金流通环节病菌交叉感染的机率。
4、从食堂管理角度出发：堵塞资金漏洞；节省人力，物力；便于消费统计；加快售饭速度，提高效率。
6、从帐务的角度出发：持卡人在校消费能清楚查询任何时间在任一网点的消费明细，保证消费安全；限额消费密码保护完善资金安全管理。
一、消费系统网络结构二、系统组成1、计算机房在食堂适当地点设置机房，机房内设置消费系统工作站，工作站配有发卡器，就餐卡消费管理系统工作站用于接待就餐卡持卡人的卡片业务，如查询、挂失、解挂、换卡、查询（如独立使用还具有开户、撤户、补助）等操作，同时也负责监控管理各商业网点的POS机和营业控制、统计。
系统采用WINDOWS作为操作系统平台，其上运行的就餐卡消费管理系统软件XF-V2.0负责对校园卡的消费业务进行管理。
就餐卡系统工作站上连接CAN 总线通讯网卡，引出若干条干线到本区内的各商业网点，形成校园卡消费POS机群的骨干网。
食堂售饭系统PPT课件
该系统具备菜品管理、订餐管理、结 算管理、数据统计分析等功能，旨在 提高食堂运营效率，提升就餐体验。
发展历程及现状
发展历程
食堂售饭系统经历了从手工记录 到电子化管理的转变，随着技术 的不断进步，逐渐实现了智能化 、网络化的升级。
现状
目前，许多高校、企事业单位的 食堂已普遍采用售饭系统，实现 了售饭流程的自动化和数字化管 理，提高了管理效率。
为大型活动如会议、展览等提供餐饮保障 服务，实现快速、高效的餐饮服务。
05
食堂售饭系统安装与调试
设备安装及配置
设备清单检查
确保所有硬件设备齐全，包括读 卡器、消费机、通讯转换器等。
设备安装
根据设备规格和食堂布局，合理安 装硬件设备，确保设备稳定可靠。
设备配置
对硬件设备进行初始化配置，包括 网络设置、时间设置等。
市场需求分析
高效运营需求
食堂需要提高售饭效率，减少 排队等待时间，提升就餐体验
。பைடு நூலகம்
数据分析需求
食堂管理者需要通过对售饭数据的 统计分析，了解就餐者的消费习惯 和口味偏好，以便优化菜品结构。
食品安全需求
保障食品安全是食堂的重要职责， 售饭系统应具备对食品采购、加工、 销售等环节的监控功能。
技术创新需求
数据分析与优化
通过对食堂销售数据的分析，可优化菜品结 构，提高食堂运营效率。
企业员工餐厅应用
员工福利管理
食堂售饭系统可作为员工福利的一部 分，实现餐补、优惠券等福利的发放 和管理。
快速结算
支持多种支付方式，实现快速结算， 提高员工就餐效率。
菜品评价反馈
员工可对菜品进行评价和反馈，帮助 餐厅改进菜品质量和服务水平。
UML食堂售饭系统
UML食堂售饭系统目录一、用户需求 ............................ 错误!未定义书签。
二、需求分析与描述 ...................... 错误!未定义书签。
1、系统边界........................ 错误!未定义书签。
2、执行者及用例分析................ 错误!未定义书签。
3、用例图 04、用例描述 0三、领域模型分析 (3)1、概念类及相关属性与方法 (3)2、类间关联 (3)3、领域模型图 (4)四、工作流程分析 (4)1、活动分析 (4)2、顺序图 (10)五、设计类图 (15)3、用例图4、用例描述（1）分类汇总统计●前置条件：角色为食堂工作人员●后置条件：打印分类报表●基本流：1)食堂工作人员登录到本系统2)输入统计要求，统计每天或者指定时间段内分机的营业明细与统计或者分类汇总表3)根据要求，打印机执行相关任务●备选流：无（2）扣除消费金额●前置条件：角色为食堂工作人员●后置条件：扣除消费金额，更新饭卡余额●基本流：1)食堂工作人员根据持卡人的点餐输入相应金额2)自动售饭机判断饭卡中余额是否足够3)若足够，则用余额减去输入的金额●备选流：若余额不足，提示持卡人充值（3）办理新饭卡●前置条件：申请者从未申请过饭卡●后置条件：给申请者发放新饭卡●基本流：1)申请者提交办卡申请，出示证明2)餐饮管理部门查看、保存办卡人信息3)收取相应押金和余额，制作新卡4)向申请者发放新卡●备选流：无（4）饭卡充值●前置条件：饭卡处于正常激活状态，未被挂失与注销●后置条件：增加饭卡余额●基本流：1)餐饮管理部门收取充卡金额2)持卡人将饭卡放到充值机上3)工作人员将相应金额充入饭卡中●备选流：无（5）注销饭卡●前置条件：是本人持卡申请注销●后置条件：注销饭卡，即再也不能使用●基本流：1)持卡人提出注销申请2)餐饮管理部门审核相关信息和要求3)注销饭卡信息，即永久性停止饭卡的使用●备选流：若不是本人持卡，或者持卡证明不足，则不能审核通过（6）挂失/撤销挂失●前置条件：本人持有效证件挂失或撤销挂失●后置条件：挂失成功则停止该卡的使用或者取消挂失成功●基本流：1)持卡人申请挂失或者申请撤销挂失2)餐饮管理部门核对相关信息，确认挂失/撤销挂失●备选流：若持卡人信息与饭卡信息不符合，则不能执行相关操作（7）补办饭卡●前置条件：饭卡遗失或损坏●后置条件：发放新卡●基本流：1)申请者申请补办饭卡并出示相关证件2)餐饮管理部门查看相关证件信息，核对是否本人3)若是本人，则注销旧卡4)申请者缴纳押金和存款，餐饮管理部门制作新卡并发放●备选流：若不是本人，则不能执行相关操作（8）退卡●前置条件：持卡人是本人●后置条件：退换押金和余额●基本流：1)持卡人申请退卡2)餐饮管理部门审核相关信息3)若是本人，清除卡内信息，退换押金和余额●备选流：若不是本人，不能执行相关操作（9）查看个人消费明细●前置条件：持卡人是本人或者是餐饮管理部门●后置条件：显示相关消费明细●基本流：1)持卡人申请查看个人消费明细2)餐饮管理部门核对相关信息3)计算机系统显示持卡人的消费明细●备选流：若不是本人，不能执行相关操作（10）查看持卡人信息明细●前置条件：持卡人是本人●后置条件：显示持卡人办卡信息●基本流：1)持卡人申请查看办卡信息2)餐饮管理部门核对是否本人3)计算机系统显示持卡人的办卡信息明细4)若是餐饮管理部门，显示办卡人信息备选流：若既不是本人也不是餐饮管理部门，则不能查看办卡人信息三、领域模型分析1、概念类及相关属性与方法（1）持卡人属性：姓名、所在单位、办卡时间、密码、身份证号方法：查看个人消费明细、查看办卡信息、查看余额（2）餐饮管理部员工属性：姓名、工号、密码方法：办理新饭卡、补办饭卡、查看信息、更改挂失状态（3）食堂员工属性：姓名、工号、密码方法：输入金额、输入分类汇总要求（4）饭卡属性：卡号、密码、持卡人身份证号、余额、押金、是否挂失、是否注销（5）自动售饭机属性：机器编号方法：扣除金额（6）计算机系统方法：办理新饭卡、饭卡充值、注销饭卡、更改挂失状态、补办饭卡、退卡、查看个人消费明细、查看持卡人信息明细、分类汇总统计2、类间关联持卡人和饭卡是一对一的关联关系，而饭卡和自动售饭机、自动售饭机和食堂员工、计算机系统和餐饮管理部员工、计算机系统和持卡人、计算机系统和饭卡、计算机系统和食堂员工、餐饮管理部员工和持卡人、餐饮管理部员工和饭卡之间均是多对多的关联关系。
食堂售饭系统需求规格说明书 精品
需求规格说明书项目名称：食堂售饭管理系统1引言1.1编写目的本文档主要是对获取的用户需求，综合考虑组织目标、现状、技术条件、投资能力等因素，从系统目标、结构、功能、性能、风险等方面对食堂售饭管理进行深入细致地分析，剔除相互矛盾、不一致、有歧义或者不必要的需求，最终确定出合理、正确、可行的系统需求，尽可能地满足用户要求，避免开发人员和用户之间的误解。
本文档将详细、准确地反映最终确定的系统需求内容，简要地反映需求分析的过程以及相关问题；既是对需求分析工作的总结，又将作为后续开发阶段系统分析、设计、实现和测试的工作纲领。
1.2背景本次系统开发不是从头做起，而是在食堂原有的系统上进行完善和扩充，食堂原有的系统已经能够完成通过一卡通进行消费，并且此套系统在收费方面已经比较完善，我们的任务是完成额外的进货和库存，员工管理，收益汇总及分析，同时还要考虑通过数据挖据和人工智能的方式优化食堂的进存货安排，菜品配置及窗口设置等等一系列的问题，提高食堂的原料利用率，食品质量及单位时间内的客流量，达到节约成本，提高口碑，加快出售的目的。
A.待开发的软件系统的名称：食堂售饭管理系统B.项目的任务提出者：XX学校食堂C.项目开发者：哈尔滨工程大学计算机科学与技术专业110614班第4小组D.本文档的读者范围包括：a．需求提供方具体责任人b．开发方项目负责人、系统分析设计人员1.3定义A.非营业开支：除采购款、销售款外，食堂维持正常运营所需开支B.报损：库存损坏商品上报C.报溢：库存非正常（顾客遗失等原因）增加商品上报1.4参考资料A.《系统设计与分析》哈尔滨工程大学邢薇主编B.软件设计文档国家标准－需求规格说明书（GB856T——88）》2任务概述2.1目标食堂管理系统将结合原有的收费系统，同时完成员工管理，采购，库存、进行决策分析等，智能化食堂售饭管理。
☞软件的主要的改进部分涉及的员工数不是太多，大多是中高层人员，一般员工不需培训仍然可以使用该系统，对于相关的部分需要另配专业人员，如数据分析和智能设备管理。
食堂售饭系统标准方案
目录第一节、概述第二节、非接触IC卡消费管理系统说明1．系统组成说明2．系统设备说明3．系统功能说明4.售饭上位管理软件第三节、系统配置与报价第四节、施工周期第五节、工程组织与服务附：部分工程业绩第一节概述本方案中所采用的设备均为ROAD系列产品，该设备符合国家及行业相关标准，其核心电路全部选用原装进口产品；我们的系统选用的PHILIPS公司原产的MIFARE I型非接触式IC卡，该卡具有32位的全世界唯一序列号，具有严密的逻辑运算和逻辑加密功能，以及高达8Kbit的存储容量，分为16个扇区支持多种应用，每个扇区有自己的一组密码，可自定义每个扇区的访问条件，在读写速度、读写安全性、系统的扩展性等方面远优于磁卡、ID卡。
第二节非接触IC卡收费管理系统说明我公司的这种计算机管理“收费管理系统”，既能实现对消费过程的有效监督，又能通过科学、严格的管理提高工作效率。
1、系统组成说明整个管理系统由中央处理部分、网络传输部分、前端设备部构成。
中央处理部分：1、授权卡的发放、存款、挂失、注销、卡片回收2、各终端的管理，终端数据的采集3、采集上的数据的整理、统计、查询、打印硬件部分：●586以上计算机（最小配置：CPU133MHz/内存16M/1G/VGA显示器16位支持800×600 ）●票据打印机●非接触IC卡发卡器（RD-M920）软件部分：●操作系统：Windows2000以上中文操作系统●非接触IC卡收费系统网络传输部分：主要完成数据的传输任务，主机命令的下载，终端数据的采集。
组件如下：●RS-485网络通讯卡●CAT 5数据线前端设备部分：收费数据的处理及储存.组件如下：●电源（AC 220V）●非接触IC卡消费机(RD-M760/RD-M780)2、终端设备说明●M780收费终端机读写卡类型：符合MIFARE标准卡操作距离：25mm--50mm工作频率：13.56MHZ读写时间：小于0.3秒存储容量：256KB,存储8千条消费记录；可扩展至2万条内部数据保存时间:10年通讯方式：RS485/232可选；可扩展TCP/IP通讯方式通讯距离：≤1.2公里（RS485方式下）工作电压：220V/50HZ,功耗小于3瓦环境温度：-10度--50度体积：320mm×175mm×135mm重量：1200克产品特性：读写时间短，方便进行快速消费灵活的消费方式:单价、定值、编号三种方式切换可通过上位软件进行收费限次、消费限额以及密码消费设置，所有卡片的缺省密码为:0000，可根据客户的需求更改消费密码，当卡消费金额大于设定的最大消费额时，客户仅需在提示音后输入密码再刷卡。
食堂售饭系统
• 下次将记录保存到文件时,是对文件进行覆 盖.
记录式文件
• 记录式文件的写操作,即 以对象为单位进行 写操作.P291
• 必须将写入文件的类实java.io.Serializable 接口, 以告知java每次操作读写多少字节
• 记录式文件不能通过普通的文本编辑器查 看内容,须用程序实现对内容的查看.
java.sql.Timestamp(utilDate.getTime());
– System.out.println("util Date : " + utilDate); – System.out.println("sql Date : "+sqlDate); – System.out.println("sql Time : "+ sqlTime); – System.out.println("sql TimeStamp "+sqlTimeStamp);
谢谢!!!
可以显示的位数 • int z = consumeSB.length();//consumeSB为用户
输入的消费金额位数
• for (int i = 0; i < j && i < z; i++) {
• consumeArrList.get(i).setIcon(
• new ImageIcon("res/dig" + consumeSB.charAt(z - i - 1)
• Java.util.Date d = new java.util.Date(); • preparedstatement.setDate(1,java.sql.Dat
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
目录
一、用户需求 (2)
二、需求分析与描述 (2)
1、系统边界 (2)
2、执行者及用例分析 (2)
3、用例图 (3)
4、用例描述 (3)
三、领域模型分析 (6)
1、概念类及相关属性与方法 (6)
2、类间关联 (6)
3、领域模型图 (7)
四、工作流程分析 (7)
1、活动分析 (7)
2、顺序图 (12)
五、设计类图 (17)
一、用户需求
1、餐饮管理部门
发放饭卡，满足持卡人的需求。
2、食堂工作人员
在自动售饭机上输入饭菜金额，汇总统计食堂当天营业情况，打印“分类报表”，定期分类汇总和结算。
3、持卡人
申请办理新卡，给饭卡充值，用饭卡买饭，注销饭卡，挂失饭卡，撤销挂失，补办新卡，退卡。
二、需求分析与描述
1、系统边界
系统包括各个用户的功能需求，而数据库服务器、其他硬件设施、网络服务应属于系统外部。
而持卡人通过餐饮管理部门达到办卡、充卡、挂失/撤销挂失、
补办饭卡、注销饭卡、退卡等目的，通过食堂工作人员来消费，扣除饭卡金额，所以餐饮管理部门、食堂工作人员都是系统内部的执行者，持卡人是系统外部的执行者。
2、执行者及用例分析
根据以上分析，可知系统有三个执行者：持卡人、食堂工作人员、餐饮管理部门。
而与之相关的用例则有：办理新饭卡、饭卡充值、注销饭卡、挂失/撤销挂失、补办饭卡、退卡、查看个人消费明细、查看持卡人信息明细、分类汇总统计、扣除消费金额。
3、用例图
4、用例描述
（1）分类汇总统计
●前置条件：角色为食堂工作人员
●后置条件：打印分类报表
●基本流：
1)食堂工作人员登录到本系统
2)输入统计要求，统计每天或者指定时间段内分机的营业明细与统计
或者分类汇总表
3)根据要求，打印机执行相关任务
●备选流：无
（2）扣除消费金额
●前置条件：角色为食堂工作人员
●后置条件：扣除消费金额，更新饭卡余额
●基本流：
1)食堂工作人员根据持卡人的点餐输入相应金额
2)自动售饭机判断饭卡中余额是否足够
3)若足够，则用余额减去输入的金额
●备选流：若余额不足，提示持卡人充值
（3）办理新饭卡
●前置条件：申请者从未申请过饭卡
●后置条件：给申请者发放新饭卡
●基本流：
1)申请者提交办卡申请，出示证明
2)餐饮管理部门查看、保存办卡人信息
3)收取相应押金和余额，制作新卡
4)向申请者发放新卡
●备选流：无
（4）饭卡充值
●前置条件：饭卡处于正常激活状态，未被挂失与注销
●后置条件：增加饭卡余额
●基本流：
1)餐饮管理部门收取充卡金额
2)持卡人将饭卡放到充值机上
3)工作人员将相应金额充入饭卡中
●备选流：无
（5）注销饭卡
●前置条件：是本人持卡申请注销
●后置条件：注销饭卡，即再也不能使用
●基本流：
1)持卡人提出注销申请
2)餐饮管理部门审核相关信息和要求
3)注销饭卡信息，即永久性停止饭卡的使用
●备选流：若不是本人持卡，或者持卡证明不足，则不能审核通过（6）挂失/撤销挂失
●前置条件：本人持有效证件挂失或撤销挂失
●后置条件：挂失成功则停止该卡的使用或者取消挂失成功
●基本流：
1)持卡人申请挂失或者申请撤销挂失
2)餐饮管理部门核对相关信息，确认挂失/撤销挂失
●备选流：若持卡人信息与饭卡信息不符合，则不能执行相关操作（7）补办饭卡
●前置条件：饭卡遗失或损坏
●后置条件：发放新卡
●基本流：
1)申请者申请补办饭卡并出示相关证件
2)餐饮管理部门查看相关证件信息，核对是否本人
3)若是本人，则注销旧卡
4)申请者缴纳押金和存款，餐饮管理部门制作新卡并发放
●备选流：若不是本人，则不能执行相关操作
（8）退卡
●前置条件：持卡人是本人
●后置条件：退换押金和余额
●基本流：
1)持卡人申请退卡
2)餐饮管理部门审核相关信息
3)若是本人，清除卡内信息，退换押金和余额
●备选流：若不是本人，不能执行相关操作
（9）查看个人消费明细
●前置条件：持卡人是本人或者是餐饮管理部门
●后置条件：显示相关消费明细
●基本流：
1)持卡人申请查看个人消费明细
2)餐饮管理部门核对相关信息
3)计算机系统显示持卡人的消费明细
●备选流：若不是本人，不能执行相关操作
（10）查看持卡人信息明细
●前置条件：持卡人是本人
●后置条件：显示持卡人办卡信息
●基本流：
1)持卡人申请查看办卡信息
2)餐饮管理部门核对是否本人
3)计算机系统显示持卡人的办卡信息明细
4)若是餐饮管理部门，显示办卡人信息
●备选流：若既不是本人也不是餐饮管理部门，则不能查看办卡人信息
三、领域模型分析
1、概念类及相关属性与方法
（1）持卡人
属性：姓名、所在单位、办卡时间、密码、身份证号
方法：查看个人消费明细、查看办卡信息、查看余额
（2）餐饮管理部员工
属性：姓名、工号、密码
方法：办理新饭卡、补办饭卡、查看信息、更改挂失状态
（3）食堂员工
属性：姓名、工号、密码
方法：输入金额、输入分类汇总要求
（4）饭卡
属性：卡号、密码、持卡人身份证号、余额、押金、是否挂失、是否注销（5）自动售饭机
属性：机器编号
方法：扣除金额
（6）计算机系统
方法：办理新饭卡、饭卡充值、注销饭卡、更改挂失状态、补办饭卡、退卡、查看个人消费明细、查看持卡人信息明细、分类汇总统计
2、类间关联
持卡人和饭卡是一对一的关联关系，而饭卡和自动售饭机、自动售饭机和食堂员工、计算机系统和餐饮管理部员工、计算机系统和持卡人、计算机系统和饭卡、计算机系统和食堂员工、餐饮管理部员工和持卡人、餐饮管理部员工和饭卡之间均是多对多的关联关系。
3、领域模型图
四、工作流程分析
1、活动分析
（1）分类汇总统计
（2）扣除消费金额
（3）办理新饭卡
（4）饭卡充值
（5）注销饭卡
（6）挂失/撤销挂失
（7）补办饭卡
（8）退卡
（9）查看个人消费明细
（10）查看持卡人信息明细
与查看个人消费明细相似。
2、顺序图
（1）分类汇总统计
（2）扣除消费金额
（3）办理新饭卡
（4）饭卡充值
（5）注销饭卡
（6）挂失/撤销挂失
（7）补办饭卡
（8）退卡
（9）查看个人消费明细
（10）查看持卡人信息明细
与查看个人消费明细相似
五、设计类图
1、类图
2、说明
通过前面的分析，数据库接口可有办卡人、饭卡、饭卡余额等；而计算机系统可细化为消费、查询、办卡、充值、注销、挂失、补办、退卡等8个子系统；用户又分新用户和持卡人两种，新用户即刚刚申请办卡尚未拿到饭卡的人，每一个持卡人曾经都是新用户，每一个新用户后来都是持卡人；只有新用户才能办卡，持卡人只能补办饭卡。