uml报告,食堂饭卡管理系统

uml报告,食堂饭卡管理系统 UML面向对象分析》课程 《 实践项目报告 项目名称:食堂饭卡管理系统模型 项目组成员: 学 号: 班 级: 指导 教师: 08年 11 月 15 日 目 录 1 需求分析 .......................................................... 1 1.1 需求概述 ..................................................... 1 1.2 需求分析 ..................................................... 3 1.3 需求模型,用例图, ........................................... 3 2 静态模型 .......................................................... 5 2.1 类图 ...................................................... 7 2.2 对象图 ....................................................... 6 2.3 包图 ......................................................... 8 3 动态模型 ......................................................... 11 3.1 时序图 ...................................................... 11 3.2 状态图 ...................................................... 13 3.3 协作图 ...................................................... 15 3.4 活动图 ...................................................... 17 4 项目组成员分工说明 ............................................... 20 5 总结 ............................................................. 21 6 参考资料 ......................................................... 22 统一建模语言UML是业务和软件应用建模的标准语言～适用于各种软件开发方法、软件生 命周期的各个阶段、各种应用领域以及各种开发工具。 设计系统时～首先是描述需求,其次根据需求建立系统的静态模型～以构造系统的结构, 第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的～包括用例 图、类图、对象图、组件图和配置图等五个图形。其中第三步中所建立的模型包括状态图、 活动图、顺序图和合作图等四个图形,是UML的动态建模机制 1需求分析 需求概述 1.1 南京工业职业技术学院食堂分别由教工食堂、学生一食堂、学生二食堂、三食堂 四食 等等组成。其中教工食堂采用计次消费～学生食堂采用刷卡消费～校园内食堂全部堂 由内部承包、独立核算～不可付现金只可刷卡。校园食堂统一由后勤科管理～共需管 理10000余人用餐～需通过消费系统实现一卡通。 根据对该大学四个食堂及管理中心现场勘察情况以及对客户需求的详细调查～总结分 析如下: 一、 该大学共有食堂5个～消费点46个～其中,教工食堂5个消费点～一食堂二食 堂三食堂四食堂各20个消费点～师生园饭庄5个消费点, 二、 在后勤科设立食堂管理中心～主要负责对全校持卡人进行消费刷卡、发卡充值、 销卡等操作。每月根据食堂消费情况打印出总报表及各食堂报表等, 三、 仅学校教职员工在此消费～每人每餐标准定额补给。教职工分早餐、中餐、晚 餐及夜宵四种。 四、 学生一食堂、二食堂等食堂采用金额式消费～仅供本校学生在此消费～学生分早 餐、中餐、晚餐三种。 五、 校园饭庄由于个人承包～教职员工及学生均可在此消费。不分早中晚餐和宵夜。 每月终了～管理中心核算其营业收入。 六、 消费卡片标记持卡人相片、姓名、院名、系名、学号等信息, 食堂饭卡应能实现以下功能 支持定额扣费和自选扣费、记次消费三种模式, 支持学校补贴包和个人充值两个独立钱包, 补贴钱包支持覆盖上月余额或累加上月余额两种模式选择, 支持软件订餐和硬件订餐功能, 不同餐别票价设置～比如:早餐1元、午餐4元、晚餐4元、宵夜2元, 可以限定一餐,或一天,的最高消费额～超额拒绝消费, 不同卡类的设置～可以设定同一餐不同的卡扣不同的金额～如果:午餐员工卡扣4元～教 师卡扣3元可以限制一餐只能消费一次或者消费第二次扣不同的金额。 IC卡使用有效期限 定～离校学生或离职教工无法使用, 支持联网、脱机使用 实时监控交易数据支持硬件查询消费金额和人次, 自动生成各种报表,充值报表、发卡报表、退卡报表、消费报表、经营汇总 表、平衡报表～可以按年、月、周、日、时段查询及打印报表等,, 支持挂失、黑名单下载、黑名单拒绝消费功能 262626262 1.2需求分析:食堂就餐卡系统是用现代信息技术和自动控制技术的计算机网络系统。它的 使用对于加强校园后勤服务的信息化建设～提高服务质量、管理水平和经济效益有重要的 作用。系统中每个消费者都有一张卡～在管理中心注册缴费～卡内记着消费者的身份、余 额。使用时将卡插入窗口机则显示卡上金额～服务员按窗口机上数字键～窗口机自动计算 并显示消费额及余额。管理中心监视每一笔消费～可打印出消费情况的相关统计数据。 应可以满足以下的几点要求 ? 系统信息管理:建立营业组档案、卡用户档案、收款机档案, ? 卡的管理:开户、更改、挂失解挂、注销、补卡、充值等, ?营业汇总:自动汇总交易数据～实现金额结算～生成相应报表, ? 查询:对每一次消费情况进行实时记录～可查询卡内余额或消费记录, ? 系统维护:数据备份、数据恢复、端口设置、管理员信息并设置密码和权限, ? 统计报表:饭卡发行、各窗口机就餐数据、黑名单等汇总、明细报表, 1.3需求模型(用例图) 262626263 挂失充值查询消费记录(from Use Case View)(from Use Case View)(from Use Case View) 查询余额 (from Use Case View) 取消用户 (from Use Case View) studentsadministrator(from Use Case View)(from Use Case View) 刷卡增加用户(from Use Case View)(from Use Case View) waiter退出系统(from Use Case View)...)(from Use Case View)用户登录消磁(from Use Case View)(from Use Case View) 食堂管理系统用例图 由三个二元关联类的事项组成～即消费者与系统服务器之间的卡的管理事项～储值卡与收 款机之间的消费事项～以及系统服务器与服务员的结算事项。整个系统参与者是消费者、 管理员和服务员～第一幅用来解释用例里设计的流程～。其中administer 与服务器是属于 一个整体的～这里仅有administer 来表示服务器 262626264 2 静态模型类图的分析:画类图和理解类图时都应采用三个层次的观点。这些观点也适用于其它模型。三个层次的观点不是UML的组成部分～但对建造模型或评价模型都非常有用～且都可应用于UML.,1,概念层描述应用域中的概念～是对现实世界的直接描述～与实现它们的类有关但与实现方案和实现语言无关。,2,说明层描述软件的接口～而不是软件的实现。一个类型描述一个接口～但可能有多种实现。,3,实现层从实现的角度定义类及其实现～揭示了软件实现体的构成情况。下面是食堂管理系统的类图 262626265 食堂系统管理类图 对象图 学生类,发送姓名 获取卡号 和查询时要输入卡号 服务员类 包含学生的动作 并显示卡号 传递消息 和退出 管理员类 登陆 增加减用户 加值 挂失 注销用户 查询消费信息等等 262626266 食堂管理系统对象简图 Students内记着消费者的身份、余额。使用时将卡插入窗口机,收款机,则显示卡上金额～服务员按窗口机上数字键～窗口机自动计算并显示消费额及余额。管理中心,数据服务器,监视每一笔消费并可容易可打印出消费情况的相关统计数据。 262626267 2.1 包图 包图用来补充说明事件所用1 UI包是图像用户界面的包图:含有+lenders WINDOWS returnWINDOWS 等等 图G 形元素 SEVER PACKAGE1 事件包:如工作人员键入数据 收款机损坏 数据键入数值有误 等等:从而进行相应的处理: CARD CLIENT 处理卡的相应事件:如当卡内余额不足时 给出相应提示 262626268 262626269 GUI包是图像用户界面的包图:含有+lenders WINDOWS returnWINDOWS 等等 图形元素 SEVER PACKAGE1 事件包:如工作人员键入数据 收款机损坏 数据键入数值有误 等等:从而进行相应的处理: 给出相应提示 CARD CLIENT 处理卡的相应事件:如当卡内余额不足时 2626262610 3动态模型 3.1时序图 如下面两图～学生把卡贴到显示器,即收款机,上～注意:::此时其他卡在放到收款机无效～除非收款机一取消前一用户:收款机读取该卡额相关信心:并发送到服务器中:读取数据库中的相关数据:符合则返回到收款机收款员键入数字:收款机负责发送:服务器查看数据是否合法～有其合法性确定确定按钮是否有效 再有其按确定按钮:数据等待处理完成后保存～并是收款机返回初始状态 2626262611 学生消费时序图 食堂系统管理域时序图 2626262612 食堂打卡管理系统时序图 3.2状态图 2626262613 食堂打卡状态图 卡被收款机读取后 收款机将自动将数据发送到服务器～有服务器分析判断该户是 否存在～卡是否有效～从而决定是否继续下一步操作的有效型 管理员状态图图 2626262614 3.3协作图 2626262615 系统管理员协作图 管理员输入姓名 登陆 进入操作界面 选择操作界面 选择操作事项 操作完毕数据库自动保存 完成后返回主界面 2626262616 3.4活动图 食堂管理员活动图 管理员进入系统后根据需要选择相应需求 为学生完成相关服务: 管理员登陆 需要用户验证 选择操作界面 进行各项操作如上图 操作完毕系统自动保存 返回该主界面 2626262617 gong 工作人员活动图 工作人员根据学生消费数量键入数字 有收款机发送到服务器～有服务器接受保存 后～注销该卡信息～是收款机回复初始状态 2626262618 食堂系统活动图 学生插卡 读卡机机收款机自动读取信息并验证 验证完毕服务员方可进行各项操作 活动如上图 2626262619 4项目组成员分工说明 需求分析 类图 协作图 需求概述 包图 活动图 需求模型 时序图 状态图 对象图 2626262620 总结:从整个食堂饭卡管理系统的设计过程可以看出～UML作为面向对象建摸领域的工业标准～在软件系统的设计过程中有着巨大的优势。它的各个模型可以帮助我们更好地理解业务流程～建立更可靠、更完善的系统模型。从而使用户和开发人员对问题的描述达到相同的理解～以减少语义差异～保障分析的正确性从使用UML建模的整个过程来讲～可分成概念级建模、逻辑级建模、物理级建模三个阶段。概念级建模用于需求分析阶段～ 主要采取用例图、对象图、活动图来表示,逻辑级建模用于分析和初步设计阶段～主要用类图、序例图、状态图 活动图 状态图 来表示, 第三阶段由于水平有限 咱无法给出 所以本食堂饭卡管理系统只是简单地给出前两个阶段对应的相应图例。在概念级建模阶段～设计人员 必须清楚了解用户的需求:以及系统要实现的功能:原则是不增加不必要的功能～也不缺少必要的功能 2626262621 例如加值 挂失 黑户 或是支持补贴 或是更先进的银行卡:能与银行卡绑定:、 6参考资料 [1] Alan Zeichick , Modeling Usage Low; Developers Confused About UML 2.0, MDA,2004 [2] ITU Recommendation Z.100, Specification and Description Language(SDL),2003 [3] UML和模式应用——面向对象分析和设计导论～Craig Larman等～姚淑珍～ 李虎译～机械工业出版社～2002 [4] UML ASL Reference Guide ASL Language Level 2.5,Ian Wilkie, Adrian King, Mike Clarke, Chas Weaver and Chris Rastrick, [5] Stephen J. Mellor, Marc J. Balcer,Executable UML :A Foundation for Model-Driven Architecture, ,2003,科学出版社 组件图 2626262622 配置图 2626262623 2626262624