餐饮业pos销售管理系统管理信息系统课程设计23组MIS课程设计实验报告doc.docx

1、餐饮业pos销售管理系统管理信息系统课程设计23组MIS课程设计实验报告doc管理信息系统课程设计题目项目组编号23专业班级12信管 2 班项目组成员蔡超敏201230560202梁惠兰201230560213林耿佳201230560214卢少壮201230560217文档编制日期2015.6指导教师 邓成剑课程设计成绩评分表（1） 个人表现20%角色项目经理分析员架构师程序员测试员姓名蔡超敏林耿佳蔡超敏卢少壮梁惠兰评分（2） 文档评分40%指标权重评价评分A（优秀）B（良好）C（一般）结构20分包含开发主要阶段，结构合理，前后连贯，结构合理包含开发主要阶段，前后较连贯，结构较合理缺少部分阶段

2、文档，前后缺乏关联，结构较混乱内容40分内容涉及开发各阶段重要工作；详略得当；模型文字配合；囊括系统主要功能；与项目结合紧密内容涉及开发各阶段大部分重要工作；详略基本得当；重要模型未辅以文字说明；涉及系统基本功能；与项目结合较紧密；缺少分析与设计重要工作；内容较少；绘制了基本模型；忽略系统重要功能；有较多项目无关内容质量40分语言精炼；模型选用合理；模型绘制规范清晰；模型关联性强语言较精炼，模型选用基本合理；模型绘制较规范清晰，模型之间有关联拼凑文字；没有建模或模型不规范；模型之间缺乏关联（3） 程序评分 40%指标权重评价评分A（优秀）B（良好）C（一般）架构10分使用了常见JavaEE框架

3、, 选用了UI框架选用个别框架；采用DAO及MVC模式 未使用框架；单纯JSP页面；分层不合理 基础数据30分实现了所有基础数据管理；包含了必要字段；选用合适组件；有格式校验实现了主要的基础数据管理；选用了较合适的组件；部分格式校验实现部分基础数据管理，只选择文本框，未做格式校验业务功能30分实现完整的业务流程；读取基础数据；选用合适组件；实现1对n或n对m；流程活动间有逻辑关联实现较完整的业务流程；读取大部分基础数据；基本实现1对n或n对m；流程活动间有一定关联实现了单个活动；较少读取基础数据；较多使用文本框录入数据；活动之间缺乏逻辑关联权限10分使用安全框架实现自定义权限按角色分配权限简单

4、权限查询10分实现了多条件组合查询功能，查询结果能进一步操作实现多条件组合查询实现单条件简单查询报表10分使用报表工具，实现分类汇总统计报表使用报表工具，实现简单数据统计报表未使用报表工具，实现列表并能汇总统计1引言1.1项目设想A. 系统展望。任何企业、公司甚至小型商店等都想时刻掌握他们日常的经营情况，以此来分析制定战略，寻求更好的发展机会，餐饮业也不例外。我们小组经过一系列的讨论后，决定开发一个可应用于餐饮业的pos销售管理系统，主要用户为收银员、系统管理员（经理）、仓库主管、系统维护员等，不同角色有不同权限。开发这个项目，我们的基本目标是通过该pos机系统，营业人员可以随时掌握该餐厅（饭

5、店、快餐店）日常营业情况以及统计营业额、各种菜式受欢迎程度，顾客消费情况以及打印报表，从而可以为未来发展作出正确决策和规划。该pos机系统可支持前台收银、会员消费、销售管理、营业收入统计、打印小票等功能。B. 系统特性。员工及用户基本信息的设置与修改（员工需登录账户密码方可进入系统进行操作）；用户角色等级的修改管理；食物产品信息（包括编号，名称，金额等）的输入；食物样式/类别的增删改减；处理查询某种食物的销售情况；查询打印票据；统计报表，分析并打印出报表；特殊用户及员工资料的登记与修改。1.2 开发计划A. 团队成员。 项目经理：蔡超敏，负责整个项目的进度安排以及协调各方面工作，保证项目正常进

6、行 分析员：林耿佳，负责项目的需求分析，对系统各功能进行定义 架构师：蔡超敏，主要负责整个项目的架构搭建和代码编写 程序员： 卢少壮协助架构师完成项目代码的编写 测试员：梁惠兰对各个模块的代码进行测试，完成测试文档B. 项目进度。主要以老师给出的迭代周期以及任务为主，在每个迭代周期中合理安排工作，制定计划，分析需求，搭建框架，编写代码，测试代码，完成测试文档以及整个项目的文档撰写。并且留有一定控制时间。C. 风险控制。1. 项目需求分析难度较大，可能达不到预期的目标需求，在现阶段整个项目的构想都还在处于不确定阶段，所以我们需要经过小组不断沟通交流，保证对项目理解一致2. 项目成员工作混乱，导致

7、进度落后。项目经理要跟进成员工作情况，定时召开小组会议，进行每一阶段的工作报告以及总结不足之处3. 项目测试不严谨，导致提交演示时出现差错。测试员应保证与架构师充分沟通，了解代码的由来，同时项目经理应监督测试员进行有效的测试，完成测试文档。 1.3 技术路线使用（Struts2 + Spring3 + Hibernate4 ）全注解+ EasyUI1.32 需求分析2.1业务建模业务建模(Business Modeling)对领域内企业管理和业务对象进行建模。包括业务流程建模和领域建模。业务流程建模描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向。领域建模是从现实的问题域中找到最有代

8、表性的概念对象，抽象成分析类。A. 业务流程建模。销售收银活动图退货活动图涉众：顾客，收银员，pos机系统，授权服务 B. 领域建模。 使用UML类图构建领域模型。2.2需求规格说明需求规格说明书(Software Requirements Specification)描述了系统的功能需求。构建系统用例模型描述功能需求。A. 系统用例图。B. 用例详述文本。对所有业务活动用例采用详述风格（包括前置条件、后置条件、主事件流，扩展、业务规则等）进行描述。用例UC1：处理销售范围：FD POS应用主要参与者：收银员涉众极其关注点：收银员：希望能够准确、快速地输入顾客所点餐品编号，而且没有输入错误以及

9、其他意外。顾客：希望以最小代价完成点餐活动并得到快速服务。希望便捷、清晰看到所点餐品的项目和价格。餐饮店：希望准确地记录交易，满足顾客要求。希望有一定的容错性，即使在某些服务器构件不可用时，也能完成销售。希望能够自动、快速地更新账务信息和库存信息。经理：希望能够快速执行超控操作，并易于更正收银员的不当操作前置条件：收银员必须经过登录和验证。成功保证：存储销售信息。系统自动记录销售时间。系统显示总金额。主成功场景：1.顾客到前台点餐并通过POS机付款。2.收银员开始一次新的销售交易。3.收银员输入顾客所点餐品编号。4.系统逐条记录出售的餐品，并显示该餐品的描述、类别、价格以及数量。收银员重复34

10、步，直至输入结束。5.系统显示总金额.6.收银员告知顾客总金额，并等待付款.扩展：*a.经理在任意时刻要求进行超控操作：1.系统进行经理授权模式。2.经理或收银员执行某一经理模式的操作。例如取消销售交易。3.系统恢复到收银员授权模式。*b.系统在任意时刻失败1.收银员重启系统，登录，请求恢复上次状态。2.系统重建上次状态2a.系统在恢复过程中检测到异常1.系统向收银员提示错误，记录此错误，并进入初始状态。2.收银员重新开始一次新的销售交易。1a.顾客或经理需要恢复一个中断的销售交易。1.收银员执行恢复操作，并且输入订单号以获得相应的销售交易2.系统显示被恢复的销售交易状态以及合计。2a.未发现

11、相应的销售交易。1.系统向收银员提示错误。2.收银员重新开始一个新的销售交易，并重新输入所有商品。3.收银员继续该销售交易（可能是输入更多的餐品或者删除餐品）2-6a.顾客告诉收银员其手机号码，要求进行会员消费1.收银员输入该顾客的手机号码，进行核实2.系统显示会员打折规则并记录（在计算总金额时使用）3a.餐品ID在pos系统未发现（无效）1.系统提示错误并拒绝收银员输入餐品ID，收银员尝试使用其他方式。1a.系统内没有该餐品ID，但是菜单上有该餐品的价格1.收银员请求经理执行超控操作。2.经理执行相应的超控操作。3.收银员手动输入价格。3b.当一种餐品的数量多于一时，收银员可直接添加该餐品的

12、数量而不是记录每个餐品的唯一标识。3-6a.顾客要求收银员从所点餐品中去掉某一项1.收银员输入餐品ID并将其删除。2.系统删除该项目后并显示更新后的累计额3-6b.顾客由于特殊原因要求收银员取消销售交易。1.收银员在系统中取消本次销售交易。3-6c.顾客临时有事（例如等待朋友一起点餐），要求延迟销售交易。1.系统记录该销售交易信息，以便随时可以恢复操作。5a.系统出现故障，无法显示总金额。1.收银员进行重启系统服务，并继续操作。1a.重启服务失败1.收银员手工计算餐品总金额或使用其他方式计算总金额。6a.顾客要求使用现金（信用卡）支付，发现现金（信用卡余额）不足无法付款。1.顾客要求收银员取消

13、本次销售交易，收银员取消本次销售交易。2.顾客要求使用其他方式付款。6b.顾客要求添加一项餐品项目。1.收银员返回到第三步，重新输入顾客所添加的餐品编号ID。特殊需求：使用大尺寸平面显示器触摸屏UI。文本信息可见距离为1米。支持文本显示的国际化语言。收银员有权限可返回到上一步骤重新进行销售交易技术与数据变元素：*a.经理进行操控操作时需要进行登录验证。3a.餐品ID可用键盘输入。发生频率：可能会不断发生。未决问题：当餐饮店有特价商品或促销活动时，应如何重新定制系统餐品价格规则？用例UC2：收银范围：FD POS应用主要参与者：收银员前置条件：收银员必须经过登录和认证身份后置条件：存储销售交易信

14、息，确定一个订单号对应一笔销售交易。准确计算销售总价和折扣。更新账务和库存信息。生成票据主成功场景：1.顾客点餐完毕，收银员根据该销售订单进行结账操作2.系统显示应付总金额，收银员告知顾客并等待顾客付款3.顾客付款，系统处理支付4.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统和库存系统。5.系统打印票据6.顾客携带票据等待领取餐品就餐扩展:*a.经理在任意时刻要求进行超控操作：1.系统进行经理授权模式。2.经理或收银员执行某一经理模式的操作。例如取消处理支付。3.系统恢复到收银员授权模式。*b.系统在任意时刻失败1.收银员重启系统，登录，请求恢复上次状态。2.系统重建上次状态

15、2a.系统在恢复过程中检测到异常1.系统向收银员提示错误，记录此错误，并进入初始状态。2.收银员开始一次新的销售交易。2-3a.顾客发现现金不足,无法付款:1.顾客要求取消本次销售交易,收银员在系统上取消该销售交易2.顾客要求使用其他方式支付2a.顾客使用信用卡支付：1.顾客输入信用卡密码。2.系统显示支付信息以验证。3.收银员确认。4.系统向外部的支付授权服务系统发送请求5.支付授权服务系统批准该支付，系统收到回答并提示收银员3b.系统崩溃,1.无法开始处理支付消息,收银员重启系统服务,继续操作1a.重启服务失败,收银员向经理请求超控操作,重新开始一次销售交易2.系统处理支付事件时出现故障,

16、无法计算(显示)找零金额2a.收银员重启系统服务,继续操作1.重启失败,收银员手工计算找零金额3c.pos机无法自动弹出现金抽屉1.收银员手工开启现金抽屉,若无法手工开启,则请求经理执行超控操作3d.现金抽屉里零钱不足,无法给顾客找零1.收银员询问顾客是否有零钱支付或者是否使用其他方式付款2.收银员从其他现金抽屉里取出零钱,给顾客找零2a.所有现金抽屉均没有足够的零钱,收银员通知经理,经理及时补充零钱3e.顾客要求使用会员卡消费或声称他们符合某种优惠条件(例如,会员卡账户积分达到一定程度可以享受打折优惠)1.收银员向系统提示打折请求2.收银员输入顾客手机号码或会员卡ID确认身份3.系统按照打折

17、规则显示折扣总计(若为兑现积分,则在打折的同时扣除结余积分)5a.打印票据时出现问题 1.系统检测出错误,给出提示 2.收银员更换纸张 3.收银员请求打印其他票据用例UC3：退货范例： FDPOS应用主要参与者：收银员涉众及其关注点：收银员：希望能准确、快速的完成退款，并且不会发生退款错误的情况。顾客：希望能够退货并取回相应退款金额。餐饮店：希望能够准确地记录交易，希望确保记录了退货情况。经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。前置条件：收银员必须通过确认和认证，购物小票经过确认。后置条件：存储退货信息。准确计算退货总额。更新财务和库存信息。更改销售量。生成相应退票票据主成

18、功场景：1.顾客携带票据到收银台退货，提出退货要求。2.收银员接受顾客提供的点餐票据，进行核对信息。4.核查后录入销售单号，并选择退货商品。5.系统显示退货总额，收银员提交退货申请。6.系统接受退货申请，修改库存和登记订单。7.收银员根据退货单向顾客返还相应的现金，并打印退货单。扩展：*a.经理在任意时刻要求进行超控操作： 1.系统进入经理授权模式。 2.经理或收银员执行某一经理模式的操作。 3.系统恢复到收银员授权模式。*b .系统在任意时刻失败：为了支持恢复处理，要保证所有交易的敏感状态和事件都能够从场景的任何一步中完全恢复。3a.不允许退餐：1.票据里的餐品与顾客实际要求退货的餐品不符，

19、拒绝顾客退货要求。4a.退货信息录入错误，经理向系统取消退货操作，并重新进行退货操作：6a.打印退货单。1.如果系统能够检测到错误，给出提示。2.收银员更换纸张。3.收银员请求打印其他票据。业务规则：ID规则可变性来源规则1购买者折扣规则：会员价：10%折扣额员工价：15%折扣额一般顾客：无折扣高每个餐饮店有不同的规则餐饮业规则规则2会员卡积分规则：积分100以上：享受会员价后再打九折的优惠积分200以上：享受会员价后再打八折的优惠更高的积分同200及以上一样享受同等优惠，不设更高打折优惠高每个餐饮店有不同的规则餐饮业规则2.3 补充性规格说明 补充性规格说明补货并确定其他类型的需求，如可靠性

20、（如10000人并发访问）、可用性（如1米外轻松看到文本）、接口（如支持钱箱、支持网银支付接口）等。也可以包括其他跨越多个用例的功能性需求如报表、安全性、日志和错误处理、数据备份、数据导入导出等。可用性：在1米外轻松可看到文本可靠性：可允许多人同时访问该系统；需要体现出系统的稳定性以及反应速度。支持定时进行数据备份（防止系统崩溃时数据丢失）；功能性：日志与错误处理（在持久性存储中记录所有错误）安全性（使用系统必须经过用户认证）权限管理（不同用户有不同的使用管理权限）可插拔规则（在几个用例的不同场景点执行任意一组规则，以支持对系统功能的定制。）可对系统任意时刻数据进行查询；可导入导出系统数据以及

21、打印报表等可支持性：1.可适应性：不同客户在处理销售时有其特有的业务规则和处理需求。因此，在场景中的几个预定之处（如开始新的销售交易时，增加新的商品时），需要能够启用可插拔的业务规则。2.可配置性：系统可适应快餐店对其POS系统的不同的网络配置需求。实现约束：使用java程序设计语言接口：1.重要硬件和接口：触摸屏票据打印机信用卡读卡器2软件接口需要采用不同接口，接入不同系统（账务、库存等）所关注的领域内信息1.定价食物餐品的价格根据市场价格定价。2.编码可参考都城快餐店的编码来进行编码。2.4 系统顺序图与操作契约系统顺序图（SSD）针对用例的一个特定场景，阐述从参与者到系统的跨越系统边界的

22、事件制品，便于设计阶段为类分配职责。操作契约(Contract of Operation)定义了重要系统事件对领域模型内对象状态的变化。A. 系统顺序图。B. 操作契约。选择系统顺序图中复杂的系统事件编写操作契约。操作： enterItems(itemID：ItemID, quantity:integer)交叉引用： 用例：处理销售前置条件： 正在进行中的销售后置条件： 创建了SalesLineItem 的实例 sli （创建实例）。Sli.quantity被赋值为quantity（修改属性）。sli被关联到当前的Sale（形成关联）。基于itemID的匹配，sli被关联到ProductDes

23、cription（形成关联）3 架构设计3.1软件架构设计软件架构文档(SAD)描述了软件类的宏观组织结构。A. 软件分层。MVC三层模式：表示层：表示层向上对用户服务，向下接受来自业务逻辑层的服务。表示层为在应用过程之间传送的信息提供表示方法的服务，主要是用户与之交互的界面，pos的基础数据的增删该查。商品销售，销售退货，修改密码的界面：业务逻辑层：处于数据访问层与表示层中间，起到了数据交换中承上启下的作用，实现pos系统各种数据的处理。数据持久层：对数据持久化操作的应用层，封装并对外提供操作数据库的服务。实现DAO模式，多个XXDao继承同一个HIbernateDao基类，编写一个服务类X

24、XServeice间接对数据进行操作。B. 命名规范。说明各层接口设计及相关接口及实现类的命名规范；C. 架构相关设计模式。4 详细设计4.1用例实现设计类图：用例顺序图：4.2输入输出设计 本节包含两部分，输入设计和输出设计：输入设计包括输入完整性控制设计、数据输入方法、输入设备、输入表单设计等，本文档只需撰写输入表单设计；输出设计包括输出完整性控制、输出内容和形式、输出设备接口、报表格式设计等。 本文档只需撰写输出报表设计； 4.2.1 表单设计以录入订单等典型功能为例，设计输入表单及交互方式。重点描述业务表单及分录项的样式及其交互。如1张订单（表单）包含n个产品（分录项），那表单和分录项

25、如何展现(即样式设计)，1个订单和多个产品如何录入、保存(交互设计)，如何实现数据格式校验。绘制或截取1张JSP页面/Swing窗口设计效果表达样式设计，示意图结合文字说明交互设计和格式校验方案。提示：web项目中使用JQuery EasyUI等UI框架可更简单实现上述目标。如果项目使用UI框架，需在此处详细说明实现方案。4.2.2 报表设计使用了JFreeChart 图标如下：4.3数据库设计1、ER图UC1：销售开单用例 UC2：收银用例UC3：退货用例2、销售开单用例、收银用例以及退货用例数据库sql文件销售单saleorder- - Table structure for saleor

26、der- -DROP TABLE IF EXISTS saleorder;CREATE TABLE saleorder ( id int(11) NOT NULL AUTO_INCREMENT, saleorder_id varchar(255) NOT NULL, user_id varchar(255) NOT NULL, member_id varchar(255) NOT NULL, created_datetime datetime NOT NULL, state int(11) NOT NULL, table_plate int(11) DEFAULT NULL, descript

27、ion text, PRIMARY KEY (id), KEY detail_id (saleorder_id), KEY FDU (user_id), KEY FDM (member_id), CONSTRAINT saleorder_ibfk_1 FOREIGN KEY (member_id) REFERENCES member (member_id) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT saleorder_ibfk_2 FOREIGN KEY (user_id) REFERENCES user (user_id) ON

28、DELETE NO ACTION ON UPDATE NO ACTION) ENGINE=InnoDB DEFAULT CHARSET=utf8;销售明细表saleorderitem- - Table structure for saleorderitem- -DROP TABLE IF EXISTS saleorderitem;CREATE TABLE saleorderitem ( id int(11) NOT NULL AUTO_INCREMENT, saleorder_id varchar(255) NOT NULL, product_id varchar(255) NOT NULL, count int(11) NOT NULL, state int(11) NOT NULL, description text, PRIMARY KEY (id), KEY fdup (saleorder_id), KEY FDPD (product_id), CONSTRAINT saleorderitem_ibfk_1 FOREIGN KEY (product_id) REFERENCES product (product_id) ON DELET