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

1、umluml 面向对象分析课程面向对象分析课程实践项目报告实践项目报告项目名称：食堂饭卡管理系统模型项目名称：食堂饭卡管理系统模型项目组成员：学号：班级：指导教师：08 年11 月15日目目 录录1需求分析 .11.1需求概述.11.2需求分析.31.3需求模型（用例图） .4静态模型 .72.1类图.72.2对象图 .82.3包图.10动态模型 .123.1时序图 .123.2状态图 .143.3协作图 .163.4活动图 .18项目组成员分工说明.21总结 .22参考资料 .2223456统一建模语言 uml 是业务和软件应用建模的标准语言，适用于各种软件开发方法、软件生命周期的各个阶段、

2、各种应用领域以及各种开发工具。设计系统时，首先是描述需求；其次根据需求建立系统的静态模型，以构造系统的结构；第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的，包括用例图、类图、对象图、组件图和配置图等五个图形。其中第三步中所建立的模型包括状态图、活动图、顺序图和合作图等四个图形,是 uml 的动态建模机制1 1 需求分析需求分析1.11.1 需求概述需求概述南京工业职业技术学院食堂分别由教工食堂、学生一食堂、学生二食堂、三食堂 四食堂 等等组成。其中教工食堂采用计次消费，学生食堂采用刷卡消费，校园内食堂全部由内部承包、独立核算，不可付现金只可刷卡。校园食堂统一由后勤科管理，

3、共需管理 10000 余人用餐，需通过消费系统实现一卡通。根据对该大学四个食堂及管理中心现场勘察情况以及对客户需求的详细调查，总结分析如下：一、 该大学共有食堂5 个，消费点46 个，其中；教工食堂5 个消费点，一食堂二食堂三食堂四食堂各20 个消费点，师生园饭庄5 个消费点；二、 在后勤科设立食堂管理中心，主要负责对全校持卡人进行消费刷卡、发卡充值、 销卡等操作。 每月根据食堂消费情况打印出总报表及各食堂报表等；三、 仅学校教职员工在此消费， 每人每餐标准定额补给。 教职工分早餐、中餐、晚餐及夜宵四种。四、 学生一食堂、二食堂等食堂采用金额式消费，仅供本校学生在此消费，学生分早餐、中餐、晚餐

4、三种。五、 校园饭庄由于个人承包，教职员工及学生均可在此消费。不分早中晚餐和宵夜。每月终了，管理中心核算其营业收入。六、 消费卡片标记持卡人相片、姓名、院名、系名、学号等信息；食堂饭卡应能实现以下功能食堂饭卡应能实现以下功能支持定额扣费和自选扣费、记次消费三种模式；支持学校补贴包和个人充值两个独立钱包；补贴钱包支持覆盖上月余额或累加上月余额两种模式选择；支持软件订餐和硬件订餐功能；不同餐别票价设置，比如：早餐1 元、午餐4 元、晚餐4 元、宵夜2 元；可以限定一餐（或一天）的最高消费额，超额拒绝消费；不同卡类的设置，可以设定同一餐不同的卡扣不同的金额，如果：午餐员工卡扣 4 元， 教师卡扣3

5、元可以限制一餐只能消费一次或者消费第二次扣不同的金额。 ic 卡使用有效期限定，离校学生或离职教工无法使用；支持联网、脱机使用 实时监控交易数据支持硬件查询消费金额和人次；自动生成各种报表（充值报表、发卡报表、退卡报表、消费报表、经营汇总表、平衡报表，可以按年、月、周、日、时段查询及打印报表等）；支持挂失、黑名单下载、黑名单拒绝消费功能2828282821.2需求分析：需求分析：食堂就餐卡系统是用现代信息技术和自动控制技术的计算机网络系统。它的使用对于加强校园后勤服务的信息化建设，提高服务质量、管理水平和经济效益有重要的作用。系统中每个消费者都有一张卡，在管理中心注册缴费，卡内记着消费者的身份

6、、余额。注册缴费，卡内记着消费者的身份、余额。使用时将卡插入窗口机则显示卡使用时将卡插入窗口机则显示卡 上金额，服务员按窗口机上数字键，窗口机自动计算并显示消费额及余额。管理中心监视每一笔消费，可打印出消费情况的相关统计数据。应可以满足以下的几点要求282828283 系统信息管理：建立营业组档案、卡用户档案、收款机档案； 卡的管理：开户、更改、发卡、挂失解挂、注销、补卡、充值、统计等； 日常操作：数据采集、终端设置、挂失名单、上传交易、上传充值等； 营业汇总：自动汇总交易数据，实现金额结算，生成相应报表； 查询：对每一次消费情况进行实时记录，可查询卡内余额或消费记录； 系统维护：数据备份、数

7、据恢复、端口设置、管理员信息并设置密码和权限； 统计报表：就餐卡发行、各窗口机就餐数据、黑名单等汇总、明细报表；1.3 需求模型（用例图）282828284用例图的分析：分析阶段的一个主要工作是对用户的需求进行分析， 找出系统的用例，如下图是网络购物系统的用例图：当然这并不是唯一的用例图，每个设计者对用例的划分粒度， 参与者的选择， 用例优先级的分配等有不同的方案。在用例的分析中， 对于用例还有一个很重要的工作就是要有用例的描述，这样会让用户能更加明白你的系统的用途。在食堂管理系统中，使用者插卡进行消费，对于用例的描述有不同的格式，但是基本的内容应该都是差不多的。都是能尽量的把系统的所有功能描

8、述清楚，让用户最大化的理解和能使用系统的功能。 用例图被称为参与者和外部用户所能观察到的系统功能的模型图。下图之一是本系统的用例图。282828285挂失(from use case view)充值(from use case view)查询消费记录(from use case view)查询余额(from use case view)取消用户(from use case view)students(from use case view)administrator(from use case view)刷卡(from use case view)增加用户(from use case view)

9、waiter(from use case v.)退出系统用户登录(from use case view)(from use case view)消磁(from use case view)食堂管理系统用例图由三个二元关联类的事项组成，即消费者与系统服务器之间的卡的管理事项，储值卡与收款机之间的消费事项，以及系统服务器与服务员的结算事项。整个系统参与者是消费者、管理员和服务员， 第一幅用来解释用例里设计的流程， 。其中 administer 与服务器是属于一个整体的，这里仅有administer 来表示服务器2828282862 2静态模型类图的分析：静态模型类图的分析：画类图和理解类图时都应采

10、用三画类图和理解类图时都应采用三个层次的观点。这些观点也适用于其它模型。三个层次的观点不是个层次的观点。这些观点也适用于其它模型。三个层次的观点不是umluml的组成部分，的组成部分， 但对建造模型或评价模型都非常有用，但对建造模型或评价模型都非常有用， 且都可应且都可应用于用于 uml.uml. （1 1）概念层描述应用域中的概念，是对现实世界的直接）概念层描述应用域中的概念，是对现实世界的直接描述，与实现它们的类有关但与实现方案和实现语言无关。（描述，与实现它们的类有关但与实现方案和实现语言无关。（ 2 2）说）说明层描述软件的接口，明层描述软件的接口， 而不是软件的实现。而不是软件的实现

11、。 一个类型描述一个接口，一个类型描述一个接口，但可能有多种实现。（但可能有多种实现。（ 3 3）实现层从实现的角度定义类及其实现，揭）实现层从实现的角度定义类及其实现，揭示了软件实现体的构成情况。下面是食堂管理系统的类图示了软件实现体的构成情况。下面是食堂管理系统的类图282828287食堂系统管理类图对象图学生类；发送姓名 获取卡号和查询时要输入卡号服务员类包含学生的动作并显示卡号 传递消息和退出管理员类登陆 增加减用户加值 挂失注销用户 查询消费信息等等282828288食堂管理系统对象简图students 内记着消费者的身份、余额。使用时将卡插入窗口机（收款机）则显示卡上金额，服务员按

12、窗口机上数字键，窗口机自动计算并显示消费额及余额。管理中心（数据服务器）监视每一笔消费并可容易可打印出消费情况的相关统计数据。2828282892.12.1 包图包图包图用来补充说明事件所用 1gui 包是图像用户界面的包图：含有+lenders windowsreturnwindows等等 图形元素sever package1 事件包！如工作人员键入数据 收款机损坏数据键入数值有误 等等！从而进行相应的处理！card client 处理卡的相应事件！如当卡内余额不足时 给出相应提示2828282810gui 包是图像用户界面的包图：含有+lenders windowsreturnwindow

13、s等等 图形元素sever package1 事件包！如工作人员键入数据 收款机损坏数据键入数值有误 等等！从而进行相应的处理！card client 处理卡的相应事件！如当卡内余额不足时 给出相应提示28282828113 3 动态模型动态模型3.13.1 时序图时序图如下面两图，学生把卡贴到显示器（即收款机）上，注意！ ！ ！此时其他卡在放到收款机无效，除非收款机一取消前一用户！收款机读取该卡额相关信心！并发送到服务器中！读取数据库中的相关数据！符合则返回到收款机收款员键入数字！收款机负责发送！服务器查看数据是否合法，有其合法性确定确定按钮是否有效 再有其按确定按钮！数据等待处理完成后保存

14、，并是收款机返回初始状态2828282812学生消费时序图食堂系统管理域时序图2828282813食堂打卡管理系统时序图28282828143.23.2 状态图状态图食堂打卡状态图卡被收款机读取后 收款机将自动将数据发送到服务器，有服务器分析判断该户是否存在，卡是否有效，从而决定是否继续下一步操作的有效型管理员状态图图282828281528282828163.33.3 协作图协作图系统管理员协作图管理员输入姓名登陆进入操作界面选择操作界面选择操作事项操作完毕数据库自动保存完成后返回主界面28282828173.43.4 活动图活动图食堂管理员活动图管理员进入系统后根据需要选择相应需求 为学生

15、完成相关服务！管理员登陆需要用户验证选择操作界面进行各项操作如上图操作完毕系统自动保存返回该主界面2828282818gong工作人员活动图工作人员根据学生消费数量键入数字 有收款机发送到服务器，有服务器接受保存后，注销该卡信息，是收款机回复初始状态2828282819食堂系统活动图学生插卡读卡机机收款机自动读取信息并验证验证完毕服务员方可进行各项操作活动如上图28282828204 4 项目组成员分工说明项目组成员分工说明需求分析类图协作图需求概述 包图活动图需求模型 时序图 状态图对象图2828282821总结总结: :从整个食堂饭卡管理系统的设计过程可以看出，从整个食堂饭卡管理系统的设计

16、过程可以看出，umluml 作为面作为面向对象建摸领域的工业标准，在软件系统的设计过程中有着巨大的优向对象建摸领域的工业标准，在软件系统的设计过程中有着巨大的优势。它的各个模型可以帮助我们更好地理解业务流程，建立更可靠、更势。它的各个模型可以帮助我们更好地理解业务流程，建立更可靠、更完善的系统模型。从而使用户和开发人员对问题的描述达到相同的理完善的系统模型。从而使用户和开发人员对问题的描述达到相同的理解，以减少语义差异，保障分析的正确性从使用解，以减少语义差异，保障分析的正确性从使用umluml建模的整个过程建模的整个过程来讲，可分成概念级建模、逻辑级建模、物理级建模三个阶段。概念级来讲，可分

17、成概念级建模、逻辑级建模、物理级建模三个阶段。概念级建模用于需求分析阶段，建模用于需求分析阶段，主要采取用例图、对象图、活动图来表示；逻辑级建模用于分析和初步主要采取用例图、对象图、活动图来表示；逻辑级建模用于分析和初步设计阶段，主要用类图、序例图、状态图设计阶段，主要用类图、序例图、状态图活动图活动图 状态图状态图 来表示；来表示； 第第三阶段由于水平有限三阶段由于水平有限 咱无法给出咱无法给出2828282822所以本食堂饭卡管理系统只是简单地给出前两个阶段对应的相应图例。所以本食堂饭卡管理系统只是简单地给出前两个阶段对应的相应图例。在概念级建模阶段，设计人员在概念级建模阶段，设计人员 必

18、须清楚了解用户的需求！以及系统要必须清楚了解用户的需求！以及系统要实现的功能！原则是不增加不必要的功能，也不缺少必要的功能实现的功能！原则是不增加不必要的功能，也不缺少必要的功能例如加值例如加值 挂失挂失 黑户黑户或是支持补贴或是支持补贴 或是更先进的银行卡！能与银行或是更先进的银行卡！能与银行卡绑定！、卡绑定！、6 6 参考资料参考资料1alan zeichick , modeling usage low; developers confused about uml 2.0,mda,20042itu recommendation z.100, specification and description language(sdl)；20033uml 和模式应用面向对象分析和设计导论，cra