食堂售饭系统分析与设计UMLword文档
基于UML的外卖订餐系统需求分析
面向对象的分析和设计说明书( 2018 -- 2019 学年第二学期)题目：基于UML的外卖订餐系统需求分析日期：2019 年5 月3日1. 系统概述2．系统分析建模外卖订单系统是服务于餐馆外卖活动的一个简单的信息系统，开发该系统主要希望实现扩大本餐馆宣传、缩短顾客订餐时间、减少订餐错误、便于订单统计分析等，最终达到扩大餐馆影响力、提高餐馆外卖业务效率、实现一定程度的决策支持的目的。
该系统按照功能主要分为三类角色，分别是顾客，商家，送餐员。
顾客角色主要可执行的操作有顾客用户操作（包括登录和注册），检索操作（包括检索餐品或商家等），订单操作（包括编辑订单和提交订单），评价操作（包括评价餐品和餐厅）。
商家角色主要可执行的操作有商家用户操作（包括登录和注册），餐厅管理（包括菜单编辑、编辑餐厅信息等），订单管理（包括查看和更新订单），评论管理（包括查看评论和回复评论）。
送餐员角色主要可执行的操作有送餐员用户操作（包括登录和注册），订单操作（包括配送订单、订单查询、确认接单等），通知操作（通知顾客或商家）。
2.1用例图【三类顾客顶层用例图】图1三类顾客顶层用例图本系统预计实现的核心功能有：（1）顾客角色——顾客操作查询餐品：按照餐品种类或名称查询后选择某一餐厅查询餐厅：按照餐厅名查询后选择某一餐厅餐厅列表：餐厅列表包括了该餐厅的基本信息，包括餐厅名称、餐厅位置、餐厅距离、餐厅销量、人均消费。
订单管理：记录顾客当前正在进行的订单以及历史订单。
顾客可以删除历史订单，也能及时查看当前正在进行订单的状态和信息。
购物车界面：相当于临时订单界面，用于显示当前订单中已选餐品的信息（包括餐品的名称、数量、总价）和订单支付状态。
确认购物车信息无误后，顾客提交订单并支付。
提交订单后，购物车中不再显示该订单的信息。
（2）商家角色——商家操作确认接单功能：商家在收到用户提交的订单后，确认接单并通知该订单的顾客已接单。
商家确认接单后，将当前订单信息发送给附近区域的送餐员，等待送餐员接单。
uml 餐馆管理信息系统
用例 建模
参与者与涉众的关系
用例 建模
涉众也称干系人,是与要建设的这个 系统有利益相关的一切人和事,涉众 的利益要求会影响系统的建设。 涉众不等于用户。 涉众建议并界定了系统必须要做的 工作。用例应该满足包含所有涉众 关注点的事物。
前置条件和后置条件
前置和后置条件表示用例开始状态 和结束会发生什么
用例建模 领域建模 系统顺序图 系统契约 对象交互图 设计类图
用例建模
用例 建模
用例视图应该包含一组定义了该系统 完整功能的用例，或者至少定义了当 前迭代所规定功能的用例 用例视图应该是客户、最终用户、领 域专家、测试人员和任何其他涉及系 统的人员，不需要详细了解系统结构 和实现就容易理解的
餐馆预约系统的初始用例图
“预约日期可以选择” “顾客姓名可以选择” “可以用条码扫描器或键盘输入商品 id”
领域建模（ 领域建模（概念模型）
建立一个领域模型 领域模型——添加关联 领域模型——添加属性
领域 建模
简介
领域 建模
领域模型：显示最重要的业务概 念和它们之间的关系的类图 领域模型用关联和泛化显示了这 些概念之间的关系。领域模型通 领域模型通 常不包含操作
用例 建模
在大型平板显示器上的触摸屏界面。 在大型平板显示器上的触摸屏界面。文本信 息要能够在1 息要能够在1米之外看清 90%的信用卡授权机构的响应应该在30秒收到 的信用卡授权机构的响应应该在30 90%的信用卡授权机构的响应应该在30秒收到 ……
技术和数据的变化列表
用例 建模
技术和数据的变化列表：系统通常 有一些技术上的变化是关于“应该 怎么做”，而不是“应该做什么”， 需要在用例中将这种变化记录下来。
用例 建模
基于UML的餐馆订餐系统分析与设计doc 7页.doc
基于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. 引言当前社会对信息系统的需求日益增长，需求变化也越来越大，软件开发的技术发展方向已经从“提升被开发系统的执行效率”转变为“提升开发效率”。
面向对象（OO）技术降低了解决方法域与问题域的差别，提供了良好的复用机制，能够更加有效提高软件开发效率，完全顺应了软件开发技术的发展方向。
UML（Unified Modeling Language）是基于面向对象技术的标准建模语言，它融合了Booch、OMT、OOSE方法中的基本概念，运用UML的目的可以捕捉系统的功能需求、分析，提取所开发系统领域的类以及描述它们之间合作概况，在完成系统的OOA(Object-Oriented Analysis：面向对象分析)在此基础上，对系统进行OOD(Object-Oriented Design：面向对象设计)。
基于UML的餐厅点餐系统设计
个性化服务：系统可以根据客户的用餐历史、口味偏好等信息，为客户提供 个性化服务，如自动推荐菜品、提醒客户上次点的菜等。
菜品管理：管理员可以在系统中添加、编辑和删除菜品信息，包括菜品图片、 名称、价格、口味等。
账单管理：系统可以自动计算账单金额，包括菜品金额、服务费等，方便服 务员和收银员操作。
参考内容
随着科技的不断发展，餐厅行业也在逐步走向数字化和智能化。为了提高顾 客体验和提升餐厅运营效率，餐厅自助点餐管理系统应运而生。本次演示将介绍 餐厅自助点餐管理系统的背景、架构、功能模块、实现方法以及系统优化等方面 的内容。
一、背景介绍
餐厅自助点餐管理系统是在互联网技术和移动支付的普及下逐渐发展起来的。 过去，顾客需要在餐厅内排队等待点餐，支付手段也相对单一。随着移动支付的 兴起，顾客对于便捷、快速的服务需求也越来越高。因此，餐厅自助点餐管理系 统成为了市场上的热门选择。
1、架构设计
系统采用B/S架构，由客户端、 服务器和数据库组成。
客户端主要负责用户的交互，包括点餐、查看菜单、下单等功能。 服务器负责处理客户端的请求，与数据库进行交互，实现业务逻辑。
数据库负责存储系统数据，包括用户信息、菜单信息、订单信息等。
2、功能设计
快速点餐：客户可以通过客户端输入菜品编号或名称进行点餐，同时系统可 以推荐相关菜品或根据客户口味偏好自动推荐。
fied Modeling Language，统一建模语言）的餐厅点餐系统，可以提高点 餐效率和服务质量，同时提升客户的用餐体验。
需求分析
基于UML的餐厅点餐系统需要满足以下需求：
1、快速点餐：系统应该能够快速处理客户的点餐请求，减少等待时间，提 高点餐速度。
2、个性化服务：系统应该能够根据客户的口味、偏好等信息，推荐适合的 菜品，提供个性化服务。
餐馆订餐系统的UML设计文档-系统设计说明书 - 副本
1 引言1.1 编写目的本详细设计说明书是基于系统概要设计说明书，经过项目组成员讨论后，将系统的各个功能模块细化，将总的用例图的功能细化到每个序列图中。
并且为后续的编码工作提供依据,也是系统测试用例编写和后期维护的主要参考资料。
1.3 名词解释系统中所有以“JE_”开头的类和变量均为“Just Enjoy”——我们小组名称的缩写，也用以和系统或者其他人开发的变量和函数相区别。
SQLServer 2000: Microsoft公司的关系型数据库。
JDK 1.4: 版本为号1.4的JAVA虚拟机。
E-R图：关系实体图，用于表示数据库的设计。
2 软件结构概述2.1 模块划分本系统根据需求分析可以划分为三大模块，他们是订餐管理模块、餐馆管理模块和会员管理模块。
其中餐馆管理主要简化为了餐桌管理。
餐馆管理模块和会员管理模块分别提供增加、修改、删除的管理功能，而最为核心的订餐管理模块提供记录订单、修改订单(换桌、换时间等)、取消订单、定时提醒和查询空桌等功能。
2.2 模块功能详细设计以UML序列图的方式列举各个用例模块的功能和实现过程。
2.2.1 CancelBooking取消订单功能，使用户可以取消已经下过的订单。
序列图如下图2-1所示：图2-1 取消订单序列图2.2.2 DeleteMember删除会员功能，使餐馆可以注销某些用户。
序列图如下图2-2所示：图2-2 删除会员序列图2.2.3 DisplayBooking显示订单功能，根据用户设定的时间显示的餐桌的信息。
其序列图如图2-3所示：图2-3 显示订单序列图2.2.4DisplayMember显示会员信息功能，显示选定的会员信息，以供管理员查看并作为修改的依据。
其序列图如图2-4示：图2-42.2.5ModifyBooking修改订单的功能为用户提供修改预约的机会，比如更换时间、换桌等。
修改订单的序列图如图2-5所示：图2-52.2.6ModifyMember修改会员信息提供给管理员以修改会员信息的功能，比图联系方式、用户姓名、信誉度等。
(完整word版)校园网上订餐系统需求分析说明书(word文档良心出品)
校园网上订餐系统之需求分析说明书项目人员：李文斌王维康业铿目录1.引言 (4)1.1 编写目的 (4)1.2 定义 (4)1.3 参考资料 (4)2.项目概述 (4)2.1 项目背景 (4)2.2 项目目标 (4)2.3 构件图 (4)2.4 上下文关系图 (5)2.5 类图 (6)2.6 项目适用范围 (7)3 项目需求分析3.1 性能需求分析 (7)3.2 系统用例图 (8)3.3系统体系结构 (9)4 项目详细设计4.1 系统模块详细设计 (9)4.2 登录模块详细设计 (10)4.3 顾客模块详细设计 (10)4.4 管理员模块详细设计 (11)5 项目技术方案 (13)5.1方案概述 (13)5.2 编程环境 (14)5.3 数据库的实现 (14)6．项目报表 (14)6.1 项目活动图 (14)6.2 系统报表 (16)7．可行性分析 (16)7.1 技术可行性分析 (16)7.2 运行可行性分析 (16)7.3 经济可行性分析 (17)1. 引言1.1编写目的此立项报告旨在确定本项目的基本目标、主要内容，设计实现的流程、工作负荷、费用开支、人员结构、设备情况、局限性，运行设计的项目时间总体规划、进度分段标准、阶段考核方法，以及项目验收方式、提交的内容清单、后续工作情况。
1.2定义本产品是为校园餐厅专门开发的一套订餐管理系统，旨在合理化安排餐厅的工作，提高餐厅的管理效率，同时方便学生就餐。
1.3参考资料《软件系统分析与设计》《软件需求工程》2. 项目概述2.1项目背景学生到食堂用餐，在和排队上浪费很多时间，并且去晚了经常会吃不到想吃的食物；学生对食堂的满意度不高，有许多的学生会选择去学校周边的饭店用餐。
因此，食堂更无法准确预测学生需求，经常会出现有些食物因为没有卖出去只好倒掉，而学生需要的一些食物却已卖完的现象。
2.2 项目目标开发网上报餐系统节省学生的时间和精力，避免食堂食物的浪费，同时让每位就餐员工都吃到满意的食物，提高服务质量以及员工对餐厅的满意度。
基于UML的外卖订餐系统需求分析
基于UML的外卖订餐系统需求分析目录1. 系统概况 (3)2. 系统需求 (4)2.1. 功能性需求 (4)2.2. 非功能性需求 (4)3. 系统开发时间管理 (5)4. 系统开发可行性分析 (5)4.1. 技术的可行性： (6)4.2. 经济的可行性： (6)4.3. 操作的可行性： (6)5. 系统开发项目人员安排 (6)6. 基于UML的系统分析 (7)6.1. 用户用例图 (7)6.2. 系统主要用例 (11)7 总结 (29)图表目录表格 1 项目人员安排表 (7)表格 2 顾客管理账户用例描述 (11)表格 3 找回密码用例描述 (12)表格 4 顾客订餐用例描述 (15)表格 5 送货员送餐用例描述 (16)表格 6 顾客查看历史订单用例描述 (16)表格 7 主管查看历史订单用例描述 (17)表格 8 菜品评论与主管查看用例描述 (21)表格 9 主管管理菜品描述 (24)表格 10 系统管理员用例描述 (26)图 1 外卖订餐系统结构图1 3图 2 外卖订餐系统结构图2 4 图 3 系统开发甘特图 5 图 4 外卖订餐系统用户用例图8 图 5 顾客用例图9 图 6 主管用例图10 图 7 送餐员用例图10 图 8 系统员用例图11 图 9 账户管理活动图13 图 10 顾客注册顺序图14 图 11 顾客登录管理账户顺序14 图 12 顾客订餐活动图18 图 13 送餐员送餐活动图19 图 14 主管查看历史订单活动图20 图 15 顾客订餐顺序图20 图 16 送餐员送餐顺序图21 图 17 顾客评论活动图22 图 18 主管查看评论活动图23 图 19 顾客评论顺序图23 图 20 主管管理菜品活动图25 图 21 主管管理菜品顺序图26 图 22 系统管理员活动图28 图 23 系统管理员顺序图291.系统概况外卖订单系统是服务于餐馆外卖活动的一个简单的信息系统，开发该系统主要希望实现扩大本餐馆宣传、缩短顾客订餐时间、减少订餐错误、便于订单统计分析等，最终达到扩大餐馆影响力、提高餐馆外卖业务效率、实现一定程度的决策支持的目的。
UML案例-食堂系统
搜索卡号()
整理课件
• 售饭——搜索该人的卡号，类图
数据库系统
系统
串口记录
饭卡
饭卡记录
整理课件
• 售饭——扣除金额
售饭机
接收金额()
串口
接收金额()
[大于20元]输入密码
系统
串口记录
接受金额() 金额 [小于20元]扣除金额()
饭卡
接受密码()
接受密码()
接受密码() 密码 查询密码()
[密码不正确]显示原金额() 显示余额()
读卡机
窗体
串口
系统
饭卡
整理课件
• 存钱——设计类图
串口
读卡机
系统
饭卡记录
窗体
饭卡 整理课件
数据库系统
• 存钱——设计类图 添加“串口记录类”
串口
读卡机
系统
串口记录 饭卡记录
窗体
饭卡
数据库系统
整理课件
5.3 售饭
读卡号
搜索该人记录
生成饭卡 扣除金额
更新数据库
整理课件
• 售饭——获取卡号——添加“串口记录”类
• 食堂售饭系统 • 1 找出执行者 • 1.1 列出所有的执行者 • 管理部门：处理饭卡的发放、挂失、注销 • 持卡人：申请新卡、追加存款、使用饭卡买饭、挂失、
注销 • 饭卡：保存饭卡信息（持卡人姓名、单位、密码、金额
等） • 售饭机：判断卡中金额是否充足、减去工作人员输入的
饭菜金额 • 师傅：输入所选饭菜的金额 • 计算机系统：统计食堂当天的营业额、打印当天的“分
插卡 用户
售饭机
系统
串口
串口记录
接收卡号()
食堂售饭系统方案设计
目录一．系统说明 21．概述 22．非接触式IC卡特点23．非接触式IC卡“一卡通”系统 24．“一卡通”系统结构 3二．国信证券食堂就餐系统 41．自助餐式管理系统 42．POS式食堂外卖系统7 3．系统的扩展及兼容性9 4．设备清单及报价9三．工程实施与售后服务111.施工人员组成112.工程执行流程图113.工程安装调试计划114.工程验收检测计划125.人员培训计划与技术支持126.售后服务12四．附录131.公司简介132.XX公司优势133.PK产品系列134.主要技术指标145.主要工程业绩14一．系统说明1．概述随着社会信息化时代的到来，社会的管理与资金的流通也将进入信息化，革命的产物――变量信息及移动信息。
深圳市XX电子有限公司应社会发展的要求，在XX非接触式IC卡读卡技术专利（专利号：ZL952XXXXX）基础上开发、生产出门禁、考勤；餐饮、购物消费；巡更、停车场收费等“一卡通”综合管理系统。
这一系统的推出给社会、企业的管理带来了极大的方便，并引起极大的反响。
作为深圳市的高新技术企业――XX公司有责任和义务把所拥有的专利技术产品在全国范围推广应用，为进一步提高我国的企、事业单位现代化管理水平做出应有的贡献。
2．非接触式IC卡特点从信息卡的发展来看有磁卡、光电卡、TM卡（碰碰卡）、接触式IC卡。
但使用这些卡片均在不同程度上存在共同的问题。
例如：这些都有插卡或接触点，容易塞入异物，被恶意破坏；长期使用后灰尘、油污积累在读写头易发生故障；磨擦式卡的操作会造成卡片和读写头磨损，容易发生故障。
非接触式IC卡（又称感应IC卡），完全克服了上述卡缺点，向零缺陷迈进了一大步。
具有以下主要特点：无源、免接触、免操作、使用寿命长。
防水、防尘、防静电干扰，适应各种恶劣环境。
感应距离远，普通门禁可达10－50cm，停车场可达50－160cm。
安全可靠、误读或不读卡的机率几乎为零，成百上千亿的密码，无法破译。
西南交通大学食堂网上订餐系统 UML 分析建模
食堂的网上自动订餐系统
专业：软件工程
班级：软件一班
姓名：某某某
学号：
目录
食堂的网上自动订餐系统 0
画图工具： (2)
一、用例图 (2)
1、注册登陆用例图 (2)
2、系统管理员用例图 (3)
3、订餐系统整体用例图 (4)
二、活动图 (5)
1、用户注册活动图 (5)
2、用户登陆活动图 (6)
3、管理员对用户进行增删改操作活动图 (7)
4、管理员查询用户活动图 (8)
5、订餐系统活动图 (9)
三、顺序图 (10)
1、系统管理员的顺序图 (10)
2、会员的顺序图 (10)
四、类图 (11)
画图工具：
IBM Rational Rose Professional J Edition 2003版。
一、用例图
1、注册、登陆用例图
顾客
送餐人员
厨师
2、系统管理员用例图
异常安全退出
3、订餐系统整体用例图
查询信息
二、活动图
1、用户注册活动图
2、用户登陆活动图
注：由于其他用户登陆时的活动图类似，我就没有一一列举了。
为了减少篇幅。
3、管理员对用户进行增删改操作活动图
注：由于增删改和查询的活动图不一样，所以需要把查询分开画，而增删改操作类似，所以可以合并在一起画。
4、管理员查询用户活动图
5、订餐系统活动图
截图：
注：因为截图是有一些被缩小的字看不清，但是用截图会看不到泳道，所以复制了如下的这张图。
三、顺序图
1、系统管理员的顺序图
2、会员的顺序图
10
四、类图
11。
(完整word版)uml网上订餐系统
实用文档《UML建模语言》课程设计报告题目：订餐管理系统数学与计算机科学（软件）学院软件工程专业2011级实验时间：2013－2014学年第一学期任课教师：***目录1背景介绍： (3)2、系统分析 (3)2.1 获取需求 (3)2.1.1在大学城订餐系统中主要有以下涉众： (3)2.1.2边界 (4)2.1.3业务用例 (7)2.1.4活动图 (10)2.1.5用例规约 (11)2.2需求分析 (14)2.2.1财务管理 (14)2.2.2信息管理 (16)2.2.3店面管理 (19)2.2.4订餐 (22)2.2.5 订单管理 (24)3 系统设计 (26)3.1整个系统结构： (26)3.2组件图和设计类图 (27)3.2.1店面管理用例的设计类图 (27)3.2.2财务管理用例的设计类图 (28)3.2.3信息管理用例的设计类图 (31)3.2.4订餐管理用例的设计类图 (34)3.2.5订单管理的设计类图 (35)3.3数据库设计 (37)3.4系统部署图 (40)4总结 (41)1背景介绍：当今社会，计算机技术尤其是网络技术飞速发展，给我们的生活带来的极大的方便。
经过我们小组成员在生活中细致观察，发现整个大学城的学生对平常订餐需求很大，但他们订餐的方式都是比较原始的电话订餐。
而各个餐饮店也是各自为战，自己接电话，记录订单需求，自己配送。
这样效率很低，利润薄，而且信息不流畅。
基于这个现状。
我们决定提供一个平台---网上订餐系统。
在网上给申请的商家一个虚拟店面，可以在上面挂上该商家的名称，饭菜的图片和价格等，让订餐者可以方便的订餐，可以对商家进行评价等。
而商家后期只负责煮菜。
物流有我们系统运营者负责，然后直接赚取差价。
还要定期对商家进行卫生安全评估，以及根据用户的评价来生产评价档案。
并以此为依据来决定商家的去留等。
2、系统分析2.1 获取需求非功能性需求1.界面操作简单功能性需求2.1.1在大学城订餐系统中主要有以下涉众：订餐者：订餐商家：提供餐饮配送人员：取餐送餐店面管理员：核实并更新商家信息，管理商家界面显示订单管理员：管理订单信息管理员：订餐者信息管理，商家联系信息管理收银员：收取送餐人员金额会计员：统计每日收支财务经理：总财务核算和收入支出相关法律法规:应遵循的行业规范和标准业主：网站建设成本，建设周期，建成后的收益参与者（用户）：用户名称使用系统方式订餐者通过系统订餐配送人员通过系统获取订餐者订餐信息店面管理员代理商家使用系统实时更新核实并更新商家信息，管理商家界面显示订单管理员管理订单信息管理员订餐者信息管理，商家联系信息管理收银员收取送餐人员金额财务经理通过计算机系统系统进行财务核算收入支出，2.1.2边界对于该系统，我们以业务功能为依据进行边界的划分，划分出五个边界：订餐边界、商家餐饮管理边界、信息管理边界、订单管理边界、财务管理边界。
大学生网上订餐系统--UML建模(Word最新版)
高校生网上订餐系统--UML建模通过整理的高校生网上订餐系统--UML建模相关文档，渴望对大家有所扶植，感谢观看！题目：高校生网上订餐系统书目1背景介绍：3 2需求分析3 3系统用例模型4 3.1订餐者用例图4 3.2商家用例图43.3店铺管理员用例图53.4订单管理员用例图53.5系统管理员用例图6 4系统静态模型7 5系统动态模型8 5.系统时序图85.1.1订餐者订餐85.1.2商家管理店铺95.1.3店铺管理管理员管理店铺105.1.4店铺管理员建立客户评价档案115.1.5店铺管理员建立商家监察档案125.1.6订单管理员管理订单135.1.7系统管理员管理商家信息145.1.8系统管理员管理订餐者信息155.1.9系统管理员维护系统165.2系统活动图175.3系统状态图17 6系统部署模型186.1系统构件图18 6.2系统部署图18 7总结19高校生网上订餐系统--UML建模1背景介绍随着网络技术的飞速发展，人们的生活也越来越追求便利化。
经过视察，发觉整个高校城的学生对平常订餐需求很大，但他们订餐的方式都是比较原始的电话订餐。
而各个餐饮店也是各自为战，自己接电话，记录订单需求，自己配送。
这样做效率很低，利润薄，而且信息不流畅。
所以我确定为高校生供应一个平台---网上订餐系统。
在网上给申请的商家一个虚拟店面，可以在上面挂上该商家的名称，饭菜的图片和价格等信息，让订餐者可以便利地订餐，还可以对商家的餐饮进行评价，由系统生成评价档案以供其他人参考等，而商家后期只负责做饭菜并支配人配送。
此外，须要定期对商家进行卫生平安监察，生成商家监察档案，并以此为依据来确定商家的去留等。
2 需求分析高校生网上订餐系统主要有以下几方面需求：1）订餐者订餐者首先须要注册一个账号用于系统登录，登录后可以查看店铺信息，并选中某一店铺后进入其餐饮信息界面，最终选中所需餐饮，下订单。
当然用餐后还可以对此餐饮进行评价。
uml报告-食堂饭卡管理系统
《UML面向对象分析》课程实践项目报告项目名称：食堂饭卡管理系统模型项目组成员：学号：班级：指导教师：08年 11 月 15 日目录1 需求分析.................................................... 错误!未定义书签。
需求概述.............................................. 错误!未定义书签。
需求分析 (3)需求模型（用例图）.................................... 错误!未定义书签。
2 静态模型.................................................... 错误!未定义书签。
类图 (7)对象图................................................ 错误!未定义书签。
包图.................................................. 错误!未定义书签。
3 动态模型.................................................... 错误!未定义书签。
时序图................................................ 错误!未定义书签。
状态图................................................ 错误!未定义书签。
协作图................................................ 错误!未定义书签。
活动图................................................ 错误!未定义书签。
4 项目组成员分工说明.......................................... 错误!未定义书签。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
食堂售饭系统分析与设计
目录
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 用例模型图
根据前面的分析，可以得到系统的用例模型图，如上图所示。
对其中3个执行者和8个用例的简单描述如下：
执行者：
●持卡人：饭卡的持有者，通过食堂工作人员的操作直接使用饭卡进行消
费，并通过管理部门对其饭卡进行管理。
●管理部门：负责根据持卡人的需求操作计算机系统，从而实现办新卡、
充值、注销、挂失/撤销挂失，补卡、退卡、查看消费明细等功能。
●食堂工作人员：负责根据饭菜的金额操作自动售饭机实现扣费功能，没
隔一段时间对营业情况进行汇总统计并打印出相关文档。
用例：
●办理新饭卡：管理部门人员负责在用户申请新卡时替用户办理新饭卡。
●饭卡充值：管理部门人员负责根据持卡人所给的金额向饭卡中追加存款
金额。
●注销饭卡：管理部门人员负责在持卡人补办新卡或退卡时注销其原有饭
卡。
●挂失/撤销挂失饭卡：管理部门人员负责在持卡人因饭卡遗失申请挂失时
进行挂失饭卡操作，在其找回饭卡时撤销对饭卡的挂失。
●补办饭卡：管理部门人员负责在持卡人确认饭卡丢失或者损坏时替其补
办饭卡，更改饭卡版本号，并实现只能使用最新版本号的饭卡。
●退还饭卡：管理部门人员负责在持卡人申请退卡时清除卡内信息，退还
剩余金额和押金。
●查看个人消费的明细：管理部门人员负责在持卡人申请查看其消费明细
时执行次操作。
●扣除饭卡费用：食堂工作人员负责在持卡人持卡消费时根据饭菜的价格
对饭卡进行扣费操作。
●汇总统计：食堂工作人员负责在每天营业结束后对营业情况进行汇总统
计并打印相关报表。
1.4 用例事件流描述
1.办理新饭卡
●基本流
1.用户申请办理新饭卡
2.管理部门收取其押金和存款，记录持卡人相关信息
3.管理部门创建新饭卡的相关信息
4.用户领取新饭卡
●备选流
无
2.饭卡充值
●基本流
1.持卡人申请对饭卡充值
2.管理部门向持卡人收取现金
3.管理部门根据持卡人要求向饭卡中充值
●备选流
3.a 如果收取现金金额大于充值额度，管理部门向持卡人找零
3.注销饭卡
●基本流
1.持卡人申请注销饭卡
2.管理部门注销饭卡
●备选流
无
4.挂失/撤销挂失饭卡
●基本流
1.持卡人申请挂失/撤销挂失饭卡
2.管理部门执行相应操作
●备选流
无
5.补办新卡
●基本流
1.持卡人申请补办新卡
2.管理部门注销持卡人原有饭卡，读出余额，清除卡内信息
3.管理部门创建新饭卡的相关信息
4.管理部门更新持卡人的相关信息
5.持卡人领取新饭卡
●备选流
无
6.退还饭卡
●基本流
1.持卡人申请退还饭卡
2.管理部门收回饭卡
3.管理部门将押金退还持卡人并清除卡内信息
●备选流
2.a 如果卡内有剩余金额，管理部门想持卡人退还相应金额
7.查看个人消费的明细
●基本流
1.持卡人申请查看个人消费的明细
2.管理部门让持卡人输入饭卡密码
3.持卡人查看其消费的明细
●备选流
2.a 如果饭卡密码错误，给出提示，结束
8.扣除饭卡费用（对应于持卡人使用饭卡消费）
●基本流
1.持卡人购买饭菜，将饭卡放到自动售饭机上
2.食堂工作人员在自动售饭机上输入饭菜的金额
3.自动售饭机查询饭卡余额
4.卡内金额扣除
●备选流
3.a 如果卡中金额不够用，给出提示，结束
4.a 如果卡内金额低于底线，给出提示，结束
9.汇总统计
●基本流
1.食堂工作人员按需求对营业情况进行汇总统计
2.打印相关报表
●备选流
无
2.领域模型分析
3.工作流程分析
办理新卡
饭卡充值
挂失/撤销挂失饭卡
补办饭卡
查看个人信息明细
注销饭卡
退还饭卡
扣除金额
汇总统计
（注：素材和资料部分来自网络，供参考。
请预览后才下载，期待你的好评与关注！）。