快餐pos系统管理信息系统课程设计26组-MIS课程设计实验报告.doc

管理信息系统课程设计管理信息系统课程设计 快餐pos系统项目组编号26专业班级12信管 2 班项目组成员巴怀桔201230560201杨剑达201230560227黄培鑫201230560207凌鸿201230560216文档编制日期2015.7.2指导教师 邓成剑2MIS课程设计开发文档课程设计成绩评分表（1） 个人表现20%角色项目经理分析员架构师程序员测试员姓名杨剑达黄培鑫凌鸿杨剑达巴怀桔评分（2） 文档评分40%指标权重评价评分A（优秀）B（良好）C（一般）结构20分包含开发主要阶段，结构合理，前后连贯，结构合理包含开发主要阶段，前后较连贯，结构较合理缺少部分阶段文档，前后缺乏关联，结构较混乱内容40分内容涉及开发各阶段重要工作；详略得当；模型文字配合；囊括系统主要功能；与项目结合紧密内容涉及开发各阶段大部分重要工作；详略基本得当；重要模型未辅以文字说明；涉及系统基本功能；与项目结合较紧密；缺少分析与设计重要工作；内容较少；绘制了基本模型；忽略系统重要功能；有较多项目无关内容质量40分语言精炼；模型选用合理；模型绘制规范清晰；模型关联性强语言较精炼，模型选用基本合理；模型绘制较规范清晰，模型之间有关联拼凑文字；没有建模或模型不规范；模型之间缺乏关联（3） 程序评分 40%指标权重评价评分A（优秀）B（良好）C（一般）架构10分使用了常见JavaEE框架, 选用了UI框架选用个别框架；采用DAO及MVC模式 未使用框架；单纯JSP页面；分层不合理 基础数据30分实现了所有基础数据管理；包含了必要字段；选用合适组件；有格式校验实现了主要的基础数据管理；选用了较合适的组件；部分格式校验实现部分基础数据管理，只选择文本框，未做格式校验业务功能30分实现完整的业务流程；读取基础数据；选用合适组件；实现1对n或n对m；流程活动间有逻辑关联实现较完整的业务流程；读取大部分基础数据；基本实现1对n或n对m；流程活动间有一定关联实现了单个活动；较少读取基础数据；较多使用文本框录入数据；活动之间缺乏逻辑关联权限10分使用安全框架实现自定义权限按角色分配权限简单权限查询10分实现了多条件组合查询功能，查询结果能进一步操作实现多条件组合查询实现单条件简单查询报表10分使用报表工具，实现分类汇总统计报表使用报表工具，实现简单数据统计报表未使用报表工具，实现列表并能汇总统计25目 录软件开发文档版本更新记录11引言21.1项目设想21.2 开发计划21.3 技术路线22 需求分析22.1业务建模22.2需求规格说明32.3 补充性规格说明32.4 系统顺序图与操作契约33 架构设计33.1功能结构设计33.2 软件架构设计44 详细设计44.1用例实现设计44.1.1 销售开单44.1.2 收银44.1.3 退货44.2输入输出设计44.2.1 表单设计54.2.2 报表设计54.3 数据库设计54.4权限设计65 系统实现65.1 功能实现65.2 系统测试65.2.1 单元测试65.2.2 用例测试65.3 系统部署76 项目总结7软件开发文档版本更新记录ContentDateDescriptionAuthor1引言1.1项目设想A. 系统展望在餐饮界内中，过去拼价格、拼菜品、比档次、比服务等竞争手段已不稀奇。在现今网络经济时代，许多餐饮企业逐渐依靠灵敏的电子信息工具，不断提高市场应变能力。餐饮企业需要使用pos管理系统来适应当今高节奏的生活方式，为管理一体化提供技术手段，这是今后餐饮管理软件信息化的一个重要标志。也可以为顾客，服务人员，管理者，收费人员等提供方便，如：预订、接待、点菜、菜品上传、厨房分单打印、条码划菜、收银、经理查询等方面；提高为顾客服务质量、缓解餐厅拥挤的状况、提高厨房部的供餐服务质量、也提高了服务人员的效率和质量。主要应用如下：1)顾客点餐，系统根据食物的价格和数量提供订单并生成单据供结算费用；2)厨房根据顾客的订单，准备所需食物。3)服务人员根据顾客的订单，适时提供相应食物。4)顾户和收银员确认订单无误，结账并打印小票。5）常客可升级为会员，给予优惠折扣和高质服务等。6）经理可以随时查看业务，作出好的管理决策。本套系统适应所有酒吧、茶餐厅、夜总会、咖啡厅、会所、娱乐城、火锅店、酒楼、酒店、宾馆、中餐、西餐、快餐、排档等各种餐饮业用户。B.系统特性：1） 餐馆内部信息化：点菜员只要输入菜品编码或拼音字头简码，就能在手持POS机里迅速调出菜品数据，系统自动识别后在厨房打印机分单打印出来，厨师根据菜单很快就能了解到顾客的需要。2）及时反映需求：餐馆的老板可以通过电子化系统查询营业收入统计、员工业绩统计、人均消费额、翻台率等；此外，还可以用图形或者表格的形式进行各种数据分析，例如财务状况分析、营销决策分析、营业收入分析等3）数字化精确管理：如一个炒菜需要用多少料、装成多大一盘、用多少时间做出来、成本和利润是多少，全是模糊的概念。然而当这些都数字化之后，一切就变得比较明晰了。4）形象得到提升：顾客来到高端大气上档次的酒楼，会觉得管理，服务，待遇等都不一样，会提升酒楼的知名度等，吸引更多的客源。更加有如下功能：（1）管理桌账功能（3）自动分类打折功能（4）服务员功能（5）转账功能（6）分账功能（7）厨房打印机8）票据打印机（9）结账受理各种银行卡、会员卡，现金支付(10)为商户开通网上订餐功能1.2 开发计划A. 团队成员项目经理（杨剑达）：计划、组织、领导、控制整个项目，也负责监督整个项目的实施，把握整个项目的进度，对项目实施过程中出现的问题进行处理。分析员（黄培鑫）：代表整个项目组，同时也可以代表客户方的意见，项目组内所有与客户需求相关的事情必需得到他的认可。对项目做出正确的需求分析，同时也是是项目组中的首席执行官，涉及项目的所有方面，推动项目进度。架构师（凌鸿）： 软件架构师负责理解和管理非功能性系统需求，比如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等。审查客户和市场人员所提出的需求，确认开发团队所提出的设计；组织开发团队成员和开发过程的定义；协助分析师。测试员（巴怀桔）：1.独立编写测试计划；独立编写测试用例；协调测试团队内部的工作以及与开发团队之间的工作；.完成“执行测试”的工作；.掌握较深层次的测试方法、测试技术和较复杂的业务流程；负责测试过程工具的研究、推广与维护，负责测试数据库维护工作。B. 项目进度。过程时间目标工作内容提交资料初始阶段第2周分组定题布置任务，确定分组；确定题目，制定计划。提交MIS课程设计任务书提交分组计划细化迭代13-4周搭建框架确定核心架构实现基础数据增删改查程序；编写文档1.1, 1.2, 3.2细化迭代25-6周设计实现业务用例实现销售开单用例程序；编写文档2.1-2.4；编写4.1.1编写4.2.1细化迭代37-8周设计实现业务用例实现收银用例程序；完善文档2.1-2.4，编写4.1.2细化迭代49-10设计实现业务用例实现退货用例程序；完善文档2.1-2.4，编写4.1.3编写3.1里程碑总结。优秀成果展示。细化迭代511-12周设计实现权限基于所选技术实现系统权限功能程序；编写文档4.4编写文档4.3细化迭代613-14周设计实现报表实现数据报表功能程序；编写文档4.2.2交付16周提交成果编程人员实验室演示程序；提交文档打印稿。完成文档5,6最终版程序，文档定稿C. 风险控制1，不胜任的项目经理，担任项目经理职位的人不具备领导和管理项目的背景、技能、经验和个人品质。2.项目需求在不断的发生变化，项目的雏形不符合，导致小组分工出现不能很好对接的现象。3.项目中没有良好的沟通，这些问题的产生是由于信息的不对称、准确性，或者时间性的缺乏，以及粗略的数据收集和记录，或者未能将信息分配给那些需要信息的人。控制措施：（a）项目经理要面对矛盾，反省自己。勇于提出深层的、探索性的问题，为了项目的最大利益而进行有效的辩论。（b）整个小组要不断地改变程序，是的软件可以适应需求的变化，增加系统的糅合性。（c）项目经理要及时注意到项目的人力、行为方面。他建立一个项目团队，帮助团队成员理解项目目标，要不断激励项目团队成员朝着目标一起工作。1.3 技术路线1、MVC模式MVC模式就是边界、控制、处理三者相结合而形成的一种设计模式，其中涉及到的设计类包括边界类（V）、控制类（C）、实体类（M）。在利用MVC模式来设计软件系统时，对于每一个的用例都能够找到三个这样的类，2、中介者模式中介者封装了对象之间的交互，当多个对象分别于另外的多个对象之间进行自由的交互式，可能导致他们之间的耦合度变得更加的高，但是对于一个系统来说往往希望高内聚、低耦合。所以就设计一个中介者来代替一些对象与另外的对象进行交互。3、外观模式外观模式为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。其结构形式如下：外观模式往往在本系统设计的较为零散时，为了方便系统的扩展或者使用维护而增加了统一的接口以此来减少系统的复杂性。4课程设计工具（1）模工具软件可选用RationalRose、MicrosoftVisio等；（2）项目管理软件可选择MicrosoftProject等；（3）程序开发语言可选用VC+、JAVA或VB等；（4）数据库管理系统可选用ORACLE、SQLSERVER或ACCESS等2 需求分析2.1业务建模A.业务流程建模涉众有：收银员、顾客、服务员、酒店、经理、支付授权服务、税务代理机构；业务规则：一、餐前准备工作、按规定着装；检查自己仪容仪表是否符合规范；做好岗位清洁工作；、认真、仔细查看上一班交接内容；处理未完成的事项；、将昨日午市和晚市结账单、收银报表交财务部；、检查收银台各种设备是否正常，有无异常情况及时上报：电脑、打印机、点钞机、POS机、备用金的工作交接：一楼备用金1000元，茶楼备用金1000元，备足发票、结账单以及其他物品。二、营业操作流程1.接单、录单工作：a.接单员在收单服务员开出的点菜单或酒水单后，仔细查看上面填写内容，如有不清楚或不正确时，客气请服务员更改。b.所有单据正确之后，进行电脑对单，看是否有误遗漏；c收银员收到服务员买单通知后，确认台号、所点的菜品、酒水饮料之后，打印结账单；d打完结账单后，将结账单副联交服务人员进行买单；e收到结账单后，对消费桌进行相应结账处理，收款后马上消台；2.客人联台处理：a收到由楼面部确认后的联台信息，让通知人员在收银点菜单上写明联台号并签名；b在卡头登记日期，班次及联台桌号，熟记连台桌号；c收到连台信息的楼层通知其他楼层；d其他楼层收到信息后以相同方式记录在卡头上；e将连台信息置于醒目位置；f收到买单信息后，由服务员将结账单交接传递到买单楼层，收银员电话确认结账有无传到买单楼层，若买单客人拒买连台单，找楼面主管级以上管理人员协调处理；g买单后款项及结账单，由收银员保存存根；3.结账工作：a.现金结账；接到服务员或客人现金后，快速清点现钞、验钞，准确找补零钱，若有质疑，与楼面主管联系，客气地请客人调换；结账后由值台服务员在结账单上签字确认实收金额及付发票金额，盖“现金”章B信用卡结账与POS机的操作；C客户签单：（折扣优惠以协议为准）4.服务员报签单客户信息；按签单客户协议打折；打印结账单，请客人签名；核对签字模式；结账单上盖“签单”章，留存；注：收银员必须熟记签单客户资料（单位、折扣、签单人以及签单模式）；d.临时挂账（需经理级以上人员担保签字）e消费卷结账；B.领域建模。使用UML类图构建领域模型。2.2需求规格说明A.系统用例图。绘制整个系统的UML用例图。B.用例详述文本对所有业务活动用例采用详述风格（包括前置条件、后置条件、主事件流，扩展、业务规则等）进行描述。用例:（1）客人进店开手牌参与者:管理员目的:给客户开手牌，安排座位概述:有辛苦人进店后，管理员要看一下系统还有没有手牌，如果有的话给客户开手牌，手牌的种类有客户自己选择，然后安排客户就座。前置条件:系统运行正常后置条件:给出处理结果，发出手牌或者告知没有空位特定要求:待请求发出后，系统必须在两秒内作出反应主事件流参与者操作1.管理员发出查询请求2.管理员给客户展示后让客户选择满意的餐桌。管理员开出手牌系统作出响应3.显示空余的桌子和已经有人的桌子，4.根据手牌开出这桌客人的预消费列表，并指定专属服务员，5.记录服务员与相应的手牌6.要求入库候选事件流第一行：如果没有手牌，系统要给管理员提出警告。用例:（2）客户点菜参与者:客户，服务员目的:服务员记录客户的点菜菜单概述:客户选择自己喜欢的菜品，服务员记录菜品，菜单一式两份手写和复印。复印那份给管理 员，手写那份粘在手牌上。并传给厨房备菜上菜，并随时准备加菜或者减菜用例:（3）管理员记录菜单参与者:管理员目的:记录相应桌子上的菜单概述:管理员根据服务员拿过来的复印式菜单输入相应手牌上的菜品，前置条件:相应手牌已经开出，并且已经列出点菜列表后置条件:记录菜单，入库留存事件流参与者操作1.管理员输入客户所点菜品系统响应2.根据输入列出所点菜品列表并入库保存候选事件流用例:（4）客户加减菜参与者:管理员目的:给客户加减菜，满足客户需求并入库保存概述:客人要求加减菜时，系统要记录相应手牌的加减菜品以备最后结算作为依据类型:基本前置条件:客户首次所点菜单已经列出并且已经保存后置条件:记录客户加减菜后的菜单入库并且保存事件流参与者操作1.输入客户加减菜菜单系统响应2.记录修改后的列表3.删除原先的列表并入库保存更改后的列表用例:（5）结账参与者:管理员目的:根据客户消费记录进行结算概述:管理员调出相应手牌的消费记录并且计算金额，进行收账，收账后要求系统及时入库并且保存前置条件:客户消费情况已经入库并保存后置条件:给出消费列表和项目事件流参与者操作1.管理员发出结算请求系统响应2.显示相应手牌的消费记录，并且自动累加计算3.显示消费小票，并送入打印机打印出小票4.备份小票和相应的服务员，资料入库并保存，设置权限，非管理员无权打开参阅2.3补充性规则说明补充性规格说明补货并确定其他类型的需求，如可靠性（如10000人并发访问）、可用性（如1米外轻松看到文本）、接口（如支持钱箱、支持网银支付接口）等。也可以包括其他跨越多个用例的功能性需求如报表、安全性、日志和错误处理、数据备份、数据导入导出等。1.功能性1.1满足多个顾客的并发执行。1该系统应支持多达1000名顾客在任意特定时间使用中央数据库，并支持多达500名顾客在任何时候访问本地服务器。1.2当顾客预定饭菜时，系统必须判断该食品是否还有剩余，若该食品已无库存，需提醒顾客，并通知采购部门进行采购。2可用性2.1前台顾客界面采用美观，方便浏览的布局，色彩温和，餐饮主题突出，模块分布清晰。2.2后台管理界面各管理模块采用下拉菜单式设计，简洁大方，层次清晰，便于操作2,3顾客界面视窗与WINDOWS系统兼容。3.可靠性保证系统在配置完成以后24小时都可用，平均无故障时间应超过300小时。系统要求对数据库的访问，存取速度要快，特别是对食品目录的访问的反应时间要在8秒内4数据备份对数据库初始数据的设置，系统维护与升级。对数据进行分析，并根据顾客点菜情况适当修改菜单。权限设置，数据备份。5.安全性系统要求有较高的安全性，由于在管理订单时，顾客的信息都在网络上传输，所以必须提供额外的安全性措施。6接口设计6.1用户接口在这一接口里创建对象以访问数据库而不是使用直接函数调用，用户可设置和取得对象属性或调用方法。程序代码变得更清晰，开发和维护更为简单。Microsoft使用多种对象接口来访问数据库管理系统，比如SQLServer的数据：(1)数据访问对象(DAO)。(2)远程数据对象(RDO)。(3)OLEDB。(4)ActiveXDataObjects。6.2外部接口所有本组讨论的接口以标准形式写出，支持VisualBasic程序的调用。SQLServer对VisualBasic编程人员提供两种调用级接口：(1)DB-Library。(2)开放式数据库连接(ODBC)。DB-Library是Microsoft开发的提供到SQLServer的函数调用的API，因此，DB-Library是使用第三部分数据转换和集成数据服务、业务服务、表达服务。2.4 系统顺序图与操作契约系统顺序图（SSD）针对用例的一个特定场景，阐述从参与者到系统的跨越系统边界的事件制品，便于设计阶段为类分配职责。操作契约(Contract of Operation)定义了重要系统事件对领域模型内对象状态的变化。A. 系统顺序图。使用UML顺序图，选择1个业务活动用例绘制系统顺序图。B. 操作契约。选择系统顺序图中复杂的系统事件编写操作契约。如有需要，使用UML状态图对某些关键对象（如订单）状态转换进行建模分析。3 架构设计3.1功能结构设计3.2 软件架构设计A. 软件分层。（1）表现层(PresentationLayer)：显示信息，处理用户的请求，提供与用户交互的界面。有GUI（图形用户界面）和web页面是表述层的两个典型的例子。（2）领域/逻辑层(DomainLogicLayer)：逻辑，实际的业务活动，系统中真正的核心，实现各种业务逻辑。（3）数据访问层(DataAccessLayer)：与数据库、消息系统等的通信，负责存放和管理应用的持久性业务数据。B. 命名规范。本规范的条目分为两个级别:规则 - R建议 - SS-最好为名词R-命名类和接口时，需要将所有单词的首字母大写。R-接口的命名不采用首字母为 I 或加上 IF 后缀的命名方式 。例 如 ：IBookDao 、 BookDaoIF 等 。R-抽象类必须使用 Abstract 作为类名的前缀，而接口建议使用 Interface 作为 接口名后缀。R-异常类应该使用 Exception 做为 名称 后缀。R-如果是运行一次就抛弃的类，以 ing 结尾，比如RenderingR-类名尽量短，但是最好不要缩写，如果缩写，必须为特别常用的类，比如 org.nutz.dao.Cnd因为调用者书写你的类名太长，他(她)的IDE会自动替他(她)换行，他会觉得有点不爽R-不要和 Java 的标准库中的类名冲突，比如 Class, Object, String 等如果冲突，就表示你极其藐视 Java 标准库中的那个的设计调用者需要花更多的时间和代码来明确他使用的是你的类, 而不是标准库中的那个S-以下情况可以允许写奇怪类名 名称简短，让人一眼不知道什么意思，用了以后一眼就能知道什么意思类特别常用类非常特殊，难以归类私有类或内部类不推荐其他人调用的 公有、保护、默认类起个奇怪的名字，就是不想让你关心这个类的代码R-缺省接口实现应该使用 Default 名称 前缀 。例 如 ： DefaultEntityMaker。也可以采用 Impl 作为后缀，表示这个实现为此接口的最优实现或者唯一实现C. 架构相关设计模式。DAO模式和MVC模式4 详细设计4.1用例实现设计对关键的系统用例实现构建设计模型。可结合需求修改子项的用例名称。4.1.1 销售开单说明业务功能/用例实现设计，扩展和细化类，分析对象之间动态关系。该节重点描述为实现用例涉及的类、消息传递（即对象调用请求消息）。A. 设计类图。绘制UML类图，为用例实现的参与类(VOPC)分配职责，定义类的重要方法，描述类之间的静态结构关系。B. 交互图。使用UML顺序图或UML通信图描述对象之间的消息传递，描述类之间动态行为关系。 4.1.2 收银设计类图顺序图4.1.3 退货设计类图顺序图4.2输入输出设计 4.2.1 表单设计以录入订单等典型功能为例，设计输入表单及交互方式。重点描述业务表单及分录项的样式及其交互。如1张订单（表单）包含n个产品（分录项），那表单和分录项如何展现(即样式设计)，1个订单和多个产品如何录入、保存(交互设计)，如何实现数据格式校验。4.2.2、报表设计4.3数据库设计4.4权限设计对软件权限进行设计，需详细说明权限粒度、自定义程度及其相应的实现技术方案。权限设计比较复杂时，可使用UML类图/顺序图/通信图进行建模并辅以文字说明。提示：权限设计可使用Spring Security, Apache Shiro等安全框架来实现基于角色的访问控制(RBAC)。项目如果使用，需要在此处详细说明如何使用。本节限2页码篇幅。RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。RBAC权限模型的扩展模型的完整设计图如下：该图为系统权限功能用例图：5 系统实现5.1 功能实现对系统主要功能进行截图展示并辅以必要的文字予以说明。选择展示1个基础数据列表界面，1个分配权限界面，1个业务流程界面（1个活动1张图），1个查询界面，1个报表界面。该图为菜单管理界面该图为菜单分类管理该图为销售订单管理开单界面该图为退菜界面下两图为报表界面5.2 系统测试5.2.1 单元测试5.2.2 用例测试选择系统12个关键用例，简要说明用例测试数据及结