UML食堂售饭系统.docx

UML食堂售饭系统.docx

《UML食堂售饭系统.docx》由会员分享，可在线阅读，更多相关《UML食堂售饭系统.docx（16页珍藏版）》请在冰豆网上搜索。

UML食堂售饭系统

一、用户需求

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个子系统；用户又分新用户和持卡人两种，新用户即刚刚申请办卡尚未拿到饭卡的人，每一个持卡人曾经都是新用户，每一个新用户后来都是持卡人；只有新用户才能办卡，持卡人只能补办饭卡。