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

《UML面向对象分析》课程实践项目报告项目名称：食堂饭卡管理系统模型项目组成员：学号：班级：指导教师：08年11月15日目录1需求分析....................................................错误!未定义书签。需求概述..............................................错误!未定义书签。需求分析..............................................................3需求模型（用例图）....................................错误!未定义书签。2静态模型....................................................错误!未定义书签。类图...............................................................7对象图................................................错误!未定义书签。包图..................................................错误!未定义书签。3动态模型....................................................错误!未定义书签。时序图................................................错误!未定义书签。状态图................................................错误!未定义书签。协作图................................................错误!未定义书签。活动图................................................错误!未定义书签。4项目组成员分工说明..........................................错误!未定义书签。5总结.......................................................错误!未定义书签。6参考资料...................................................................22统一建模语言UML是业务和软件应用建模的标准语言，适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具。设计系统时，首先是描述需求；其次根据需求建立系统的静态模型，以构造系统的结构；第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的，包括用例图、类图、对象图、组件图和配置图等五个图形。其中第三步中所建立的模型包括状态图、活动图、顺序图和合作图等四个图形,是UML的动态建模机制1需求分析1.1需求概述南京工业职业技术学院食堂分别由教工食堂、学生一食堂、学生二食堂、三食堂四食堂等等组成。其中教工食堂采用计次消费，学生食堂采用刷卡消费，校园内食堂全部由内部承包、独立核算，不可付现金只可刷卡。校园食堂统一由后勤科管理，共需管理10000余人用餐，需通过消费系统实现一卡通。根据对该大学四个食堂及管理中心现场勘察情况以及对客户需求的详细调查，总结分析如下：一、该大学共有食堂5个，消费点46个，其中；教工食堂5个消费点，一食堂二食堂三食堂四食堂各20个消费点，师生园饭庄5个消费点；二、在后勤科设立食堂管理中心，主要负责对全校持卡人进行消费刷卡、发卡充值、销卡等操作。每月根据食堂消费情况打印出总报表及各食堂报表等；三、仅学校教职员工在此消费，每人每餐标准定额补给。教职工分早餐、中餐、晚餐及夜宵四种。四、学生一食堂、二食堂等食堂采用金额式消费，仅供本校学生在此消费，学生分早餐、中餐、晚餐三种。五、校园饭庄由于个人承包，教职员工及学生均可在此消费。不分早中晚餐和宵夜。每月终了，管理中心核算其营业收入。六、消费卡片标记持卡人相片、姓名、院名、系名、学号等信息；食堂饭卡应能实现以下功能支持定额扣费和自选扣费、记次消费三种模式；支持学校补贴包和个人充值两个独立钱包；补贴钱包支持覆盖上月余额或累加上月余额两种模式选择；支持软件订餐和硬件订餐功能；不同餐别票价设置，比如：早餐1元、午餐4元、晚餐4元、宵夜2元；可以限定一餐（或一天）的最高消费额，超额拒绝消费；不同卡类的设置，可以设定同一餐不同的卡扣不同的金额，如果：午餐员工卡扣4元，教师卡扣3元可以限制一餐只能消费一次或者消费第二次扣不同的金额。IC卡使用有效期限定，离校学生或离职教工无法使用；支持联网、脱机使用实时监控交易数据支持硬件查询消费金额和人次；自动生成各种报表（充值报表、发卡报表、退卡报表、消费报表、经营汇总表、平衡报表，可以按年、月、周、日、时段查询及打印报表等）；支持挂失、黑名单下载、黑名单拒绝消费功能需求分析：食堂就餐卡系统是用现代信息技术和自动控制技术的计算机网络系统。它的使用对于加强校园后勤服务的信息化建设，提高服务质量、管理水平和经济效益有重要的作用。系统中每个消费者都有一张卡，在管理中心注册缴费，卡内记着消费者的身份、余额。使用时将卡插入窗口机则显示卡上金额，服务员按窗口机上数字键，窗口机自动计算并显示消费额及余额。管理中心监视每一笔消费，可打印出消费情况的相关统计数据。应可以满足以下的几点要求⑴系统信息管理：建立营业组档案、卡用户档案、收款机档案；⑵卡的管理：开户、更改、发卡、挂失解挂、注销、补卡、充值、统计等；⑶日常操作：数据采集、终端设置、挂失名单、上传交易、上传充值等；⑷营业汇总：自动汇总交易数据，实现金额结算，生成相应报表；⑸查询：对每一次消费情况进行实时记录，可查询卡内余额或消费记录；⑹系统维护：数据备份、数据恢复、端口设置、管理员信息并设置密码和权限；⑺统计报表：就餐卡发行、各窗口机就餐数据、黑名单等汇总、明细报表；需求模型（用例图）用例图的分析：分析阶段的一个主要工作是对用户的需求进行分析，找出系统的用例，如下图是网络购物系统的用例图：当然这并不是唯一的用例图，每个设计者对用例的划分粒度，参与者的选择，用例优先级的分配等有不同的方案。在用例的分析中，对于用例还有一个很重要的工作就是要有用例的描述，这样会让用户能更加明白你的系统的用途。在食堂管理系统中，使用者插卡进行消费，对于用例的描述有不同的格式，但是基本的内容应该都是差不多的。都是能尽量的把系统的所有功能描述清楚，让用户最大化的理解和能使用系统的功能。用例图被称为参与者和外部用户所能观察到的系统功能的模型图。下图之一是本系统的用例图。消磁(fromUseCaseView)waiter(fromUseCaseView)...)students(fromUseCaseView)administrator(fromUseCaseView)用户登录(fromUseCaseView)退出系统(fromUseCaseView)充值(fromUseCaseView)挂失(fromUseCaseView)增加用户(fromUseCaseView)取消用户(fromUseCaseView)查询消费记录(fromUseCaseView)刷卡(fromUseCaseView)查询余额(fromUseCaseView)食堂管理系统用例图由三个二元关联类的事项组成，即消费者与系统服务器之间的卡的管理事项，储值卡与收款机之间的消费事项，以及系统服务器与服务员的结算事项。整个系统参与者是消费者、管理员和服务员，第一幅用来解释用例里设计的流程，。其中administer与服务器是属于一个整体的，这里仅有administer来表示服务器2静态模型类图的分析：画类图和理解类图时都应采用三个层次的观点。这些观点也适用于其它模型。三个层次的观点不是UML的组成部分，但对建造模型或评价模型都非常有用，且都可应用于UML.（1）概念层描述应用域中的概念，是对现实世界的直接描述，与实现它们的类有关但与实现方案和实现语言无关。（2）说明层描述软件的接口，而不是软件的实现。一个类型描述一个接口，但可能有多种实现。（3）实现层从实现的角度定义类及其实现，揭示了软件实现体的构成情况。下面是食堂管理系统的类图食堂系统管理类图对象图学生类；发送姓名获取卡号和查询时要输入卡号服务员类包含学生的动作并显示卡号传递消息和退出管理员类登陆增加减用户加值挂失注销用户查询消费信息等等食堂管理系统对象简图Students内记着消费者的身份、余额。使用时将卡插入窗口机（收款机）则显示卡上金额，服务员按窗口机上数字键，窗口机自动计算并显示消费额及余额。管理中心（数据服务器）监视每一笔消费并可容易可打印出消费情况的相关统计数据。2.1包图包图用来补充说明事件所用1GUI包是图像用户界面的包图：含有+lendersWINDOWSreturnWINDOWS等等图形元素SEVERPACKAGE1事件包！如工作人员键入数据收款机损坏数据键入数值有误等等！从而进行相应的处理！CARDCLIENT处理卡的相应事件！如当卡内余额不足时给出相应提示GUI包是图像用户界面的包图：含有+lendersWINDOWSreturnWINDOWS等等图形元素SEVERPACKAGE1事件包！如工作人员键入数据收款机损坏数据键入数值有误等等！从而进行相应的处理！CARDCLIENT处理卡的相应事件！如当卡内余额不足时给出相应提示3动态模型时序图如下面两图，学生把卡贴到显示器（即收款机）上，注意！！！此时其他卡在放到收款机无效，除非收款机一取消前一用户！收款机读取该卡额相关信心！并发送到服务器中！读取数据库中的相关数据！符合则返回到收款机收款员键入数字！收款机负责发送！服务器查看数据是否合法，有其合法性确定确定按钮是否有效再有其按确定按钮！数据等待处理完成后保存，并是收款机返回初始状态学生消费时序图食堂系统管理域时序图食堂打卡管理系统时序图状态图食堂打卡状态图卡被收款机读取后收款机将自动将数据发送到服务器，有服务器分析判断该户是否存在，卡是否有效，从而决定是否继续下一步操作的有效型管理员状态图图协作图系统管理员协作图管理员输入姓名登陆进入操作界面选择操作界面选择操作事项操作完毕数据库自动保存完成后返回主界面活动图食堂管理员活动图管理员进入系统后根据需要选择相应需求为学生完成相关服务！管理员登陆需要用户验证选择操作界面进行各项操作如上图操作完毕系统自动保存返回该主界面gong工作人员活动图工作人员根据学生消费数量键入数字有收款机发送到服务器，有服务器接受保存后，注销该卡信息，是收款机回复初始状态食堂系统活动图学生插卡读卡机机收款机自动读取信息并验证验证完毕服务员方可进行各项操作活动如上图4项目组成员分工说明需求分析类图协作图需求概述包图活动图需求模型时序图状态图对象图总结:从整个食堂饭卡管理系统的设计过程可以看出，UML作为面向对象建摸领域的工业标准，在软件系统的设计过程中有着巨大的优势。它的各个模型可以帮助我们更好地理解业务流程，建立更可靠、更完善的系统模型。从而使用户和开发人员对问题的描述达到相同的理解，以减少语义差异，保障分析的正确性从使用UML建模的整个过程来讲，可分成概念级建模、逻辑级建模、物理级建模三个阶段。概念级建模用于需求分析阶段，主要采取用例图、对象图、活动图来表示；逻辑级建模用于分析和初步设计阶段，主要用类图、序例图、状态图活动图状态图来表示；第三阶段由于水平有限咱无法给出所以本食堂饭卡管理系统只是简单地给出前两个阶段对应的相应图例。在概念级建模阶段，设计人员必须清楚了解用户的需求！以及系统要实现的功能！原则是不增加不必要的功能，也不缺少必要的功能例如加值挂失黑户或是支持补贴或是更先进的银行卡！能与银行卡绑定！、6参考资料[1]AlanZeic