UML食堂售饭系统.docx
- 文档编号:12710696
- 上传时间:2023-04-21
- 格式:DOCX
- 页数:18
- 大小:151.71KB
UML食堂售饭系统.docx
《UML食堂售饭系统.docx》由会员分享,可在线阅读,更多相关《UML食堂售饭系统.docx(18页珍藏版)》请在冰豆网上搜索。
UML食堂售饭系统
UML食堂售饭系统
一、用户需求1
二、需求分析与描述1
1、系统边界1
2、执行者及用例分析1
3、用例图2
4、用例描述2
三、领域模型分析5
1、概念类及相关属性与方法5
2、类间关联5
3、领域模型图6
四、工作流程分析6
1、活动分析6
2、顺序图12
五、设计类图17
、用户需求
1、餐饮管理部门
发放饭卡,满足持卡人的需求。
2、食堂工作人员
在自动售饭机上输入饭菜金额,汇总统计食堂当天营业情况,打印“分类报表”,定期分类汇总和结算。
3、持卡人
申请办理新卡,给饭卡充值,用饭卡买饭,注销饭卡,挂失饭卡,撤销挂失,补办新卡,退卡。
二、需求分析与描述
1、系统边界
系统包括各个用户的功能需求,而数据库服务器、其他硬件设施、网络服务应属于系统外部。
而持卡人通过餐饮管理部门达到办卡、充卡、挂失/撤销挂失、补办饭卡、注销饭卡、退卡等目的,通过食堂工作人员来消费,扣除饭卡金额,所以餐饮管理部门、食堂工作人员都是系统内部的执行者,持卡人是系统外部的执行者。
2、执行者及用例分析
根据以上分析,可知系统有三个执行者:
持卡人、食堂工作人员、餐饮管理部门。
而与Z相关的用例则有:
办理新饭卡、饭卡充值、注销饭卡、挂失/撤销挂失、补办饭卡、退卡、查看个人消费明细、查看持卡人信息明细、分类汇总统计、扣除消费金额。
1/20
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、领域模型图
持卡人
-所在单位
-密码
-身份证号
-办卡时间
十査看个人消费明细()十査看办卡信息()
十査看余额()
-端2
-端3
计算机系统
饭卡
-密码
-持卡人身份证号
-余额
-押金
-是否挂失
-是否注销
自动售饭机
-机器编号
■扣除金额()
-端7
-端18
也端17
餐饮管理部员工
-I.'}
-密码
+办理新饭卡0
+补办饭卡()
+査看信息0
+更改挂失状态0
+退卡()
-端13-端14
+办理新饭卡()
+充值()
+注销饭卡()
+更改挂失状态()
+补办饭卡()
+退卡()
+査看个人消费明细0
+査看持卡人信息0
+分类汇总统计()
-端9-端10
名号码
姓工密
---
食堂员工
十输入金额()十输入分类汇总要求(〉
工作流程分析
1、活动分析
(1)分类汇总统计
(2)扣除消费金额
(3)办理新饭卡
(4)饭卡充值
(5)注销饭卡
(6)挂失/撤销挂失
(7)补办饭卡
(8)退卡
(9)査看个人消费明细
(10)査看持卡人信息明细与査看个人消费明细相似。
2、顺序图
(1)分类汇总统计
(2)扣除消费金额
倉常坍匸
am饭机
计%机系统
故据用服务器
点餐
(3)办理新饭卡
(4)饭卡充值
充値机
充侑系统
数据库服务器
存软与存歉单
插入饭卡
饭氏信息
充值成功
输入存歉金额
増加饭卡余额i
(5)注销饭卡
持卡人餐饮部员工注销系统数抑:
廉服务器
申请注綃饭卡
1
1
1
输入申请者和饭卡信息
、
1
1
1
1
1
1
1
1
1
1
1
含找申请者和饭卡信息;
1确认注销
'!
7
1
1
注销饭卡
1
■
1
1
1
1
>
1
1
1
1
1
1
1
1
注销成功
1
1
1—
1
U••
aa1
(6)挂失/撤销挂失
数抑库服务器
餐饮沛员匸
挂失系统
(7)补办饭卡
(8)退卡
持卡人
数抑库服务器
餐饮沛员匸
退卡系统
II丄-1I
(9)査看个人消费明细
ulff——
(10)査看持卡人信息明细
与查看个人消费明细相似
五、设计类图
1、类图
2、说明
通过前面的分析,数据库接口可有办卡人、饭卡、饭卡余额等;而计算机系统可细化为消费、査询、办卡、充值、注销、挂失、补办、退卡等8个子系统;用户又分新用户和持卡人两种,新用户即刚刚申请办卡尚未拿到饭卡的人,每一个持卡人曾经都是新用户,每一个新用户后来都是持卡人;只有新用户才能办卡,持卡人只能补办饭卡。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- UML 食堂 系统
![提示](https://static.bdocx.com/images/bang_tan.gif)