面向对象分析与设计课程设计报告-饭卡管理系统.doc

中南民族大学计算机科学学院课程设计报告课 程 面向对象分析与设计题 目 饭卡管理系统年 级 2009专 业 软件工程 学 生 学 号 指导教师 2012年4月2 日饭卡管理系统姓名：刘宇翔学号：09065075计算机科学学院软件工程教研室2012年3月2文档修订历史日期版本教师评论描述Ok! Good!Ok! Good!目 录1 概述- 1 -1.1 系统简述- 1 -1.2 软件设计目标- 1 -1.3 参考资料- 2 -1.4 修订版本记录- 2 -2 术语表- 3 -3 用例- 3 -4 设计概述- 7 -4.1 简述- 7 -4.2 系统结构设计- 7 -4.3 系统界面- 8 -4.4 约束和假定- 10 -5 对象模型- 10 -5.1 类定义- 10 -5.2 类关联描述- 11 -5.3 对象模型图- 11 -6 对象数据字典描述- 12 -6.1 饭卡管理系统中的对象- 12 -7 动态模型- 13 -7.1 场景（Scenarios）- 14 -7.2事件定义（Events）- 15 -7.3 状态图- 17 -8 功能模型- 19 -8.1 确定输入输出与事件关系- 19 -8.2 功能模型图- 19 -9 数据库定义- 21 -10 部署图- 22 - 23 -1 概述1.1 系统简述在当代高校中，学生众多，消费频繁，如果仅靠现金和饭票消费，将给学校各个消费点的员工带来压力，找钱压力，统计压力，记账压力等等，十分的麻烦，出于这些压力，饭卡管理系统将会缓解和消除以上种种压力。给后勤管理带来福音。某学校食堂分别由教工食堂、学生一食堂、学生二食堂、三食堂 四食堂等等组成。食堂采用刷卡消费，校园内食堂全部由内部承包、独立核算，不可付现金只可刷卡。校园食堂统一由后勤科管理，需通过消费系统实现一卡通。运行环境硬件环境：服务器端/客户端：处理器：Intel PentiumIII或者更高内存： 1024M硬盘空间：80G软件环境：服务器端/客户端：操作系统：Windows 98/ME/2000/XP/Vista/NT或UNIX,LINUX网络协议：TCP/IP、HTTP浏览器：IE 6.0或者以上1.2 软件设计目标食堂就餐卡系统是用现代信息技术和自动控制技术的计算机网络系统。它的使用对于加强校园后勤服务的信息化建设，提高服务质量、管理水平和经济效益有重要的作用。系统中每个消费者都有一张卡，在管理中心注册缴费，卡内记着消费者的身份、余额。使用时将卡插入窗口机则显示卡上金额，服务员按窗口机上数字键，窗口机自动计算并显示消费额及余额。管理中心监视每一笔消费，可打印出消费情况的相关统计数据。应可以满足以下的几点要求 系统信息管理：建立营业组档案、卡用户档案、收款机档案； 卡的管理：开户、挂失解挂、注销、补卡、充值、设置超额消费密码等； 营业汇总：自动汇总交易数据，实现金额结算，生成相应报表； 查询：对每一次消费情况进行实时记录，可查询卡内余额或消费记录； 系统维护：数据备份、数据恢复、端口设置、管理员信息并设置密码和权限； 统计报表：饭卡发行、各窗口机就餐数据、明细报表；从非功能性的需求上分析，本系统是面向学校饭卡管理而开发的，由于系统的界面清晰、美观，操作简单、方便，所以操作人员只需要具备一定的电脑操作技能即可。管理员（维护人员）不需要任何数据库专业技能知识。本系统可以极大的提高工作效率，预期使用频度较高。1.3 参考资料1 Alan Zeichick , Modeling Usage Low; Developers Confused About UML 2.0, MDA,20042 ITU Recommendation Z.100, Specification and Description Language(SDL)；20033 麻志毅.面向对象分析与设计.机械工业出版社.2008；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,科学出版社1.4 修订版本记录列出本文档修改的历史纪录。必须指明修改的内容、日期以及修改人。2 术语表对本文档中所使用的各种术语进行说明。如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。管理员1、登陆：管理员在执行所有操作前，必须凭用户名密码登陆系统。2、增加用户：管理员在系统中操作办理新卡，给新卡进行入网、编号、输入持卡人信息、超额消费密码等。3、取消用户：持卡人离校或者毕业，用户管理员给持卡人的饭卡按卡号注销，并消除用户信息。4、挂失：当持卡人的饭卡丢失或损坏，管理员给持卡人挂失饭卡使原先饭卡失效后，在给持卡人补办新卡。5、充值：当持卡人饭卡余额不足并交钱申请充值时，管理员则给饭卡增加与持卡人申请的数目相等的余额叠加在原有余额上。6、生成报表：到月底或者年底，管理员可以选择让系统生成各种报表，显示在屏幕上。7、查询：查询饭卡余额与消费记录。系统维护员1、登陆：输入密码登陆系统界面。2、系统维护：数据备份、数据恢复、端口设置、管理员信息并设置密码和权限；学生1、刷卡：持有饭卡的学生在刷卡机上插卡消费。2、查询余额：持有饭卡的学生在刷卡机上插卡查询余额。3 用例此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。用例中请将事件进行标注。用例1登陆参与者管理员前置条件成功打开系统后置条件进入相应权限的页面，可执行相应权限的操作工作流1.【管理员】输入登录信息2.【系统】检验登录信息，若合法，则跳转到相应权限页面；否则，输出警告用例2增加用户参与者管理员前置条件登陆系统进入操作界面后置条件添加了相应用户保存工作流1.【管理员】输入用户信息，学号工号、院系等。2.【系统】保存、更新、给予相应饭卡卡号及显示用户信息。用例3取消用户参与者管理员前置条件登陆系统进入相应操作界面后置条件删除相应用户工作流1.【管理员】选择相应用户进行删除操作。2.【系统】保存、更新、注销相应饭卡卡号。用例4挂失参与者管理员前置条件登陆系统进入相应操作界面后置条件冻结相应卡号饭卡刷卡功能。旧卡消磁。工作流1.【管理员】输入挂失卡卡号进行挂失操作。2.【系统】保存、更新、冻结相应卡号饭卡刷卡功能。用例5补办参与者管理员前置条件登陆系统进入相应操作界面后置条件办理新卡，分配原先卡号并解冻刷卡功能。工作流1.【管理员】输入用户信息，办理新卡操作。2.【系统】保存、更新、解冻相应卡号刷卡功能。用例6充值参与者管理员前置条件登陆系统进入相应操作界面后置条件相应的金额成功叠加到饭卡原有余额上工作流1.【管理员】给相应卡号叠加相应金额2.【系统】修改余额、保存和显示剩余金额。用例7查询参与者管理员前置条件登陆系统进入相应操作界面后置条件显示相应卡号饭卡余额与消费记录工作流1.【管理员】查询操作2.【系统】显示相应卡号饭卡余额与消费记录用例8生成报表参与者管理员前置条件登陆系统进入相应操作界面后置条件生成报表并显示在屏幕上，打印报表工作流1.【管理员】选择生成报表操作2.【系统】生成报表信息显示在屏幕上并打印报表用例9系统维护参与者系统维护员前置条件登陆系统进入相应操作界面后置条件数据备份、数据恢复、端口设置、管理员信息并设置密码和权限工作流1.【系统维护员】维护操作2.【系统】相应的维护操作用例10刷卡参与者学生前置条件持有饭卡，饭卡余额大于消费金额后置条件扣除相应的余额工作流1.【学生】将饭卡插入刷卡机消费2.【系统】扣除相应余额，存入数据库用例11查询余额参与者学生前置条件持有饭卡后置条件显示余额工作流1.【学生】在刷卡机中插入饭卡2.【系统】通过刷卡机显示相应余额4 设计概述4.1 简述本系统采用面向对象分析、设计方法，基于对象而不再基于结构。系统采用三层B/S结构风格，包括数据库服务器、应用服务器以及Web浏览器。作图过程中采用的时UML（统一建模语言）进行作图。4.2 系统结构设计系统顶层方框图如下：4.2.1 顶层系统结构4.3 系统界面登陆界面：管理员操作界面：系统维护员操作界面：4.4 约束和假定该系统须在6个月之内完成，预算投入8万人民币。提供熟练的队员五个左右。开发此系统的语言最好能使用跨平台语言进行开发。当30名管理员同时登录系统时，系统应该正常运行。系统响应时间应该在人所能接受的等待时间范围内。界面友好，易于操作，安全性好。5 对象模型5.1 类定义管理员系统维护员饭卡学生5.2 类关联描述类关联关联关系意义1饭卡与管理员n：m全校有多个管理员，一个管理员可以管理多张饭卡2系统维护员与管理员1：n全校只有一个系统维护员管理多个管理员。3系统维护员与饭卡1：n全校只有一个系统维护员，一个系统管理员管理多张饭卡的数据还原与备份4学生与饭卡1：1一个学生只有一张饭卡5.3 对象模型图6 对象数据字典描述6.1 饭卡管理系统中的对象6.1.1 对象：饭卡用途：刷卡消费约束：一个学生只有一张饭卡。持久性：长久存于数据库中 属性描述：1. 属性：卡号类型：long型描述：主键，唯一标识饭卡。约束：每张饭卡只有一个互不相同的卡号。2. 属性：学生学号类型：long型描述：一张饭卡卡号对应一个学生学号约束：每张饭卡只记录一个学生的信息。 方法描述：1. 方法：Addcard_cardID(long num) 或者在系统提供的SQL编程接口中输入SQL语句 /输入学号，进行饭卡ID分配。返回类型：long型参数：num返回值：cardIDPre-Condition：该学号未被绑定卡号，该卡号未被分配。Post-Condition：给饭卡分配卡号，并绑定学号信息。读取/修改的属性：读取学号，产生卡号。调用的方法：程序中嵌入SQL语句处理逻辑：根据获得的学号和卡号，在数据库中查询学号属性，当不存在相同学号时新建该学号数据，并绑定相应卡号，保存。测试例：CASE输入期望结果CASE 1输入合法且已存在的学号给出警告信息CASE 2输入合法但不存在的学号新建相应学号数据，并绑定分配的卡号7 动态模型管理员操作顺序图如下： 7.1 场景（Scenarios）7.1.1场景：登录描述：管理员、系统维护员打开饭卡管理系统页面，输入登录权限、帐号、密码，系统验证完全无误后，系统自动跳转到相应权限的操作页面。动作1：用户输入登陆权限、帐号、密码。动作2：等待系统进行验证。7.1.2场景：增加用户 描述：管理员在饭卡管理系统管理员界面进行增加用户操作，输入用户信息，系统分配卡号，保存。动作1：在管理员界面进行增加用户操作。动作2：输入新用户信息，进行饭卡卡号分配。动作3：进行保存操作。7.1.3场景：取消用户描述：管理员在饭卡管理系统管理员界面进行取消用户操作，查询要取消的用户，进行数据库删除操作。动作1：在管理员界面选择取消用户操作。动作2：输入要取消的用户地信息，在数据库中查询到用户。动作3：删除用户操作。7.1.4场景：挂失描述：管理员在饭卡管理系统管理员界面进行饭卡账户冻结操作，输入饭卡卡号，进行账户冻结。动作1：在管理员界面选择挂失操作。动作2：输入挂失饭卡卡号，查询饭卡信息。动作3：冻结饭卡账户。7.1.5场景：生成报表描述：管理员在饭卡管理系统管理员界面进行生成报表操作，输入生成报表的月份，选择统计报表并生成报表。动作1：在管理员界面选择生成报表操作。动作2：输入要生成报表的月份动作3：选择统计并生成统计后的报表。7.2事件定义（Events）文字定义事件画出事件跟踪图画出事件流图学生管理员饭卡管理系统的事件跟踪： 饭卡管理系统的事件流图如下：定义事件：查询成功事件下面为查询的顺序图：定义事件：更新事件更新事件顺序图：7.3 状态图7.2.1 状态图1：管理员状态：饭卡信息状态：8 功能模型8.1 确定输入输出与事件关系查询事务与输入输出的关系：8.2 功能模型图功能模型图有很多，请分开表示8.2.1 饭卡管理系统查询的功能模型图：8.2.2饭卡管理系统顶层数据流图：数据字典：数据项：（1）饭卡信息=学号+卡号+余额+消费记录（2）消费记录报表=卡号+学号+消费记录总汇（3）饭卡信息表=饭卡信息+消费记录报表加工条目：加工名：饭卡管理系统编号：无输入：饭卡信息、消费记录报表输出：饭卡信息表、消费记录报表9 数据库定义饭卡：列名 说明 数据类型 约束说明 CardId卡号 long,长度为10 主键 Sno 学号 long,长度为10 非空值 Sname姓名 string,长度为10只能是英文字母组成，5-10位，非空值Ccode 密码long，长度为10非空值 Cmoney余额double，长度为20非空值学生表：列名 说明 数据类型 约束说明 Sname 姓名string,长度为1