便利店pos系统管理信息系统课程设计21组MIS课程设计实验报告.docx

1、便利店pos系统管理信息系统课程设计21组MIS课程设计实验报告管理信息系统课程设计便利店pos系统项目组编号21专业班级12信管 2班项目组成员范文辉201230560205陈梦娜201230560203吴文浩201230560223林宇航201230760316文档编制日期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分使用报表工具，实现分类汇总统计报表使用报表工具，实现简单数据统计报表未使用报表工具，实现列表并能汇总统计软件开发文档版本更新记录ContentDateDescriptionAuthor便利店pos机-细化迭代12015/4项目设想，开发计划林宇航细化迭代二需求规格说明和补充性规格说明2015/4/18用例图，用例文本，补充性规格说明林宇航软件架构设计2015/4/19软件架构设计陈梦娜1引言1.1项目设想A.系统展望应用场景：一般便利店的销售收银系统。用户：收银员，顾客，经理。系统范围：便利店

5、，士多店基本目标：主要是实现便利店货物的收费、支付和找钱功能，还有货物管理，销售管理和客户管理等。B.系统特性货物管理：对货物的录入，删除，库存和促销打折的管理。客户管理：客户积分计算和享有的折扣优惠。员工管理：员工的登录和拥有对货物打折的权限。销售管理：实现收银支付促销的功能。统计管理：统计历史时间货物的销售状况。1.2 开发计划A.团队成员项目经理（范文辉）：统筹整个项目的工作，控制项目的进度。分析员（范文辉）：分析需求，确定产品应用范围、功能和最终实现的目标。架构师（陈梦娜）：搭建项目的构架，编写部分代码，实现系统功能。程序员（吴文浩）：编写代码，实现系统功能。测试员（林宇航）：测试系统

6、的运行效果，功能实现程度，写测试报告。B.项目进度1进度安排：3-4周搭建框架，确定核心架构，实现基础数据增删改查。5-6周设计实现业务用例，实现销售开单用例。7-8周设计实现业务用例，实现收银用例。9-10 设计实现业务用例，实现退货用例。11-12周设计实现权限，基于所选技术实现系统权限功能。13-14周设计实现报表，实现数据报表功能。2控制措施：任务分工，把具体工作分配给每个人，项目经理及时提醒个人根据进度安排按时完成各项内容。成员内有效沟通，尽量以比较高的效率完成项目。C.风险控制1经验欠缺，成员开发经验不足，可能使项目质量难以保证。只有通过不断地实践，修改来提高项目的质 量。2 .项

7、目开发过程涉及的专业知识较多，给项目开发带来一定的困难。开发过程中不断地学习知识。3.系统性能不稳定，可能出现bug。成员使用相同的开发环境，搭建良好的配置开发环境。1.3 技术路线 对本项目用到的技术工具和作用进行简要说明。包括开发语言和工具、计算模式(单机应用，C/S，B/S)、框架，类库、数据库管理系统等，附上版本号，可简要描述选择依据。开发语言：java，JavaScript，html框架：play framework （版本号：2.2.1） ，flat ui，ajax数据库：mysql 2 需求分析2.1业务建模A. 业务流程建模。使用UML活动图分析目标系统所支持的业务流程。使用文

8、字对流程中每个活动的涉众、业务规则、使用到的单据进行必要的说明。 B. 领域建模。使用UML类图构建领域模型。2.2需求规格说明系统用例图。B. 用例详述文本。用例1：处理销售级别：用户目标主要参与者：收银员涉众及其关注点：收银员：希望能够快速、准确地输入，而且没有支付错误，没有找钱错误。顾客：希望快速地完成购买活动，并且能够享受到可以清晰地看到商品列表、价格、优惠以及总价，还有能够得到购买凭证。经理：能够管理商品，管理用户，实现查询，修改，添加，删除的操作，还有实现超控操作，更正收银员的不当操作。前置条件：收银员必须经过确认和认证后置条件：存储销售信息，生成记录和票据，计算总额和税金，更新账

9、务和库存。主成功场景：1顾客携带所购的商品到收银台通过pos机付款。2收银员开始一次新的销售。3收银员输入一位顾客购买的商品。4系统逐条记录商品，并显示该商品的描述、价格和累计金额。银员重复3-4步，直到输入所有的商品。5系统显示总金额和优惠信息。6顾客付款，系统处理支付，并打印票据。7系统更新销售信息和财务信息。扩展：*a.经理在任意时刻要求进行超控操作：1.系统进入经理授权模式（登录经理账号）。2.经理实现经理模式操作，例如：改变商品优惠信息，给顾客打折，处理销售交易等。3.系统恢复到收银员模式。*b.系统在任意时刻失败：为了支持恢复和更正账务处理，要保证交易能够从任何一步恢复1.收银员重

10、启系统，登录，恢复上一次状态。2.系统重建上次状态。 2a.系统在恢复过程中检测到异常：1.系统向收银员提示错误，记录此错误，并进入一个人初始状态。2.收银员开始一个新的销售交易。1a.顾客或经理需要恢复一个中断的销售交易。1收银员执行恢复操作，并输入交易ID提取对应的销售交易。2系统显示被恢复的销售交易状态及其小计。2a.未发现对应的销售交易。1系统向收银员提示错误。2收银员可能会开始一个新销售交易，并重新输入所有商品。3收银员继续该次销售交易。2-4a顾客告诉收银员其获得的优惠折扣。 1收银员核实后输入折扣信息。 2系统根据折扣信息计算总金额。3a无效商品ID（在系统中未发现）： 1系统提

11、示错误并拒绝输入该ID。 2收银员响应该错误。 2a商品ID可读 1收银员手工输入商品ID。 2系统显示商品项目的描述和价格。 2b系统内不存在该商品的ID，但是该商品附有价签： 1收银员请求经理执行超控操作。 2经理执行超控操作（添加该商品）。 3收银员再收入该商品。3b当有多个商品项目属于同一类别： 1收银员可以输入类别的标识和商品的数量。3-5a顾客要求收银员从所购商品中去掉一项或几项： 1收银员将列表中对应的商品删除。 2系统删除对应的项目后显示更新的总金额。3-5b顾客要求取消交易： 1收银员在系统中取消交易。6a现金支付： 1收银员输入收取的现金额 2系统显示找零金额。 3收银员收

12、取现金，并给顾客找零。6b打印票据 1系统提示错误。 2收银员更换纸张。 3收银员或打印其它票据。特殊需求：文本信息即字体可见距离要为1米。记录某位收银员一次登录收取的金额。收银员能被授权给某位顾客优惠。发生频率：可能会不断发生未决问题：针对不同的业务需要怎样进行定制。顾客是否可以要求第三方支付。应用的领域规则ID规则可变性来源规则1所有商品有经理录入并决定价格和优惠折扣。不同便利店优惠折扣不同。便利店政策规则2所有商品折扣不能大于20%，顾客消费200-500折扣为5%，500以上10%，节日另决定。不同便利店优惠折扣不同。便利店政策用例2名称：收银范围：便利店POS机应用主要参与者：收银员

13、前置条件：收银员必须经过登陆和认证身份后置条件：存储销售交易信息，确定每个订单号对应一笔交易。准确计算销售总价和折扣，并同时更新库存信息，生成票据。主成功场景：1.收银员把顾客所要购买的商品信息都录入到pos机应用，进行结账操作。2.系统显示应付总额，收银员告知顾客所要支付金额。3.顾客付款，系统进行处理支付，收银员找零。4.系统记录完整销售交易记录，同时更新库存信息5.系统打印票据6.顾客带着商品和票据离开扩展：*a.经理在任意时刻要求进行超控操作：1.系统进入经理授权模式（登录经理账号）。2.经理实现经理模式操作，例如：改变商品优惠信息，给顾客打折，处理销售交易等。3.系统恢复到收银员模式

14、。*b.系统在任意时刻失败：为了支持恢复和更正账务处理，要保证交易能够从任何一步恢复2-3a.顾客发现现金不足,无法付款:1.顾客要求取消本次销售交易,收银员在系统上取消该销售交易2.顾客要求使用其他方式支付2a.顾客使用信用卡支付：1.顾客输入信用卡密码。2.系统显示支付信息以验证。3.收银员确认。4.系统向外部的支付授权服务系统发送请求5.支付授权服务系统批准该支付，系统收到回答并提示收银员3b.系统崩溃,1.无法开始处理支付消息,收银员重启系统服务,继续操作1a.重启服务失败,收银员向经理请求超控操作,重新开始一次销售交易2.系统处理支付事件时出现故障,无法计算(显示)找零金额2a.收银

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

16、在打折的同时扣除结余积分)5a.打印票据时出现问题 1.系统检测出错误,给出提示 2.收银员更换纸张 3.收银员请求打印其他票据用例3名称：退货范围：便利店pos机应用主要参与者：收银员，顾客前置条件：收银员必须登陆到系统并通过认证，该顾客须持有票据，票据的订单号对应一个销售交易信息。后置条件：该退回的商品不能继续销售，应返还给供应商；把该销售交易信息设置为失败交易，同时生成新的销售交易信息取代旧的销售信息。主成功场景：1.顾客带票据及需要退货的商品到收银台。2.收银员查询票据，系统显示对应的销售交易信息。3.顾客选择重新更换或退款,收银员根据顾客选择进行操作。4.系统处理完成，打印新的票据。

17、5.顾客离开。扩展：*a.经理在任意时刻要求进行超控操作：1.系统进入经理授权模式（登录经理账号）。2.经理实现经理模式操作，例如：改变商品优惠信息，给顾客打折，处理销售交易等。3.系统恢复到收银员模式。*b.系统在任意时刻失败：为了支持恢复和更正账务处理，要保证交易能够从任何一步恢复2.系统中没有对应票据的销售交易信息1.收银员告知顾客，并取消这次退货操作3a.顾客选择更换商品，对应商品库存为01，收银员告知顾客，询问顾客是否选择退款操作。2，收银员根据系统提供信息，退还金额给顾客。3b.系统崩溃,1.无法开始处理支付消息,收银员重启系统服务,继续操作1a.重启服务失败,收银员向经理请求超控

18、操作,重新开始一次销售交易2.系统处理支付事件时出现故障,无法计算(显示)找零金额2a.收银员重启系统服务,继续操作1.重启失败,收银员手工计算找零金额3c.pos机无法自动弹出现金抽屉1.收银员手工开启现金抽屉,若无法手工开启,则请求经理执行超控操作3d.现金抽屉里零钱不足,无法给顾客找零1.收银员询问顾客是否有零钱支付或者是否使用其他方式付款2.收银员从其他现金抽屉里取出零钱,给顾客找零2a.所有现金抽屉均没有足够的零钱,收银员通知经理,经理及时补充零钱4a.打印票据时出现问题 1.系统检测出错误,给出提示 2.收银员更换纸张 3.收银员请求打印其他票据2.3 补充性规格说明功能性1销售交

19、易中断处理保存数据，交易中断后能恢复上一次交易。2安全性在开始使用系统之前要进行登录。3统计性能够将数据导出并且实现统计画图操作。可用性1顾客应该能轻松看到显示器上的信息。2显示器字体颜色避免使用色盲人群不能辨认的颜色。可靠性1避免系统时常出现问题导致顾客等待时间长。接口1条形码激光扫描仪2票据打印机2.4 系统顺序图与操作契约A. 系统顺序图。选择：销售过程B. 操作契约。选择系统顺序图中复杂的系统事件编写操作契约。契约enterItem操作：enterItem（）交叉引用：用例：处理销售前置条件：无后置条件：创建了Bill的实例bill（创建实例）bill被关联到user和customer

20、（形成关联）bill的其他属性被初始化（修改属性）3 架构设计3.1功能结构设计使用树形功能层次图画出系统的功能结构图。3.2 软件架构设计软件分层。1、UML包图：2、描述：本次课程设计采用play框架(半路弃用ssh，架构师表示真的不想坑害队友=)，为什么要使用play; 前端采用amaze ui,戳这里是amaze uiview: 用户视图层，使用play默认scala template渲染模板，同时使用国产前端框架amaze uicotroller: 控制器model: 模型router: 路由，负责请求方法跳转命名规范。(1)各层包及类命名规范 ：总体原则：包名所有字母小写，类名采用

21、“驼峰标识”，由于paly遵循默认大于设置的设计思想，所以对各种类和方法的命名已有规定，此处遵循play命名规范；(2)其它命名规范 ：1.变量命名：变量名首字母必须小写，如果该变量名有多个单词组成，后面的单词首字母大写， 单词与单词之间不要使用_做连接，变量名访问控制必须为私有，可以对其增加setter与getter方法；2.常量命名：所有字母大写，如果有多个单词组成，单词与单词之间以”_“隔开。而且该变量必须是公共、静态、final类型；3.方法命名：首字母必须小写，如果该变量名有多个单词组成，后面的单词首字母大写，单词与单词之间不要使用_做连接。单词不要使用名词 ；(3)前端规范：按照约

22、定的文件摆放位置，命名规范遵循前端命名规范，和后台通过ajax进行交互；(4)类Restful接口设计规范 ：1.响应请求规范：请求：GET:使用url传参，如：?a=1&b=2；POST:使用Json传参，从request.body中获取此Json，如：a:1,b:2 ；响应：返回值格式为json，分为成功返回（ok_json）和失败返回（fail_json）：ok_json示例：data:user_id:1,error:,retmsg:1 ；fail_json示例：data:,error:nopointerevent,retmsg:02.接口规范：如/customer/add；架构相关设计

23、模式。1、关于DAO模式：Play实体采用ActiveRecord模式，将Struts中的dao与pojo合并，ActiveRecord也属于ORM层，由Rails最早提出，遵循标准的ORM模型：表映射到记录，记录映射到对象，字段映射到对象属性。配合遵循的命名和配置惯例，能够很大程度的快速实现模型的操作，而且简洁易懂。Play也提倡使用ActiveRecord模式进行快速开发，其主要思想是：每一个数据库表对应创建一个类，类的每一个对象实例对应于数据库中表的一行记录；通常表的每个字段在类中都有相应的Field；ActiveRecord同时负责把自己持久化，在ActiveRecord中封装了对数据

24、库的访问，即CURD；ActiveRecord是一种领域模型(DomainModel)，封装了部分业务逻辑；2、关于MVC模式：如包图所示,同时采用play注解。4 详细设计4.1用例实现设计对关键的系统用例实现构建设计模型。可结合需求修改子项的用例名称。4.1.1 销售开单A. 设计类图。B. 交互图。4.1.2 收银设计类图：交互图：4.1.3 退货设计类图：交互图：4.2输入输出设计 4.2.1 表单设计输入订单数据提交订单打印订单4.2.2 报表设计显示全年的订单根据分类查询销售情况4.3 数据库设计构建E-R模型，设计数据库表； 部分表详细create table bill_item

25、 ( bill_item_id bigint auto_increment not null, product_id bigint not null, bill_id bigint not null, bill_item_sum integer, bill_item_sum_price varchar(255), bill_item_createtime datetime(6), bill_item_status integer, constraint pk_bill_item primary key (bill_item_id);create table category ( categor

26、y_id bigint auto_increment not null, category_name varchar(255), category_des varchar(255), category_createtime datetime(6), constraint uq_category_category_name unique (category_name), constraint pk_category primary key (category_id);create table customer ( customer_id bigint auto_increment not nul

27、l, name varchar(255), sex varchar(255), address varchar(255), birthday datetime(6), isvip tinyint(1) default 0, phone varchar(255), createtime datetime(6), constraint pk_customer primary key (customer_id);create table myorder ( id bigint auto_increment not null, order_create_time datetime(6), order_

28、status integer, constraint pk_myorder primary key (id);4.4权限设计权限粒度：用户粒度，它可以精细到角色或具体的用户，有系统管理员讲某一资源访问权限授权给角色后用户，从而实现对数据库的操作。这里的角色可以理解为实际工作中的岗位、职位等。操作对象粒度。对数据库的增删改查，是由具体的模块实现的。对于新用户，一般只有赋予查询权限。系统管理员可以根据实际情况赋予对应的权限。比如角色为店长，系统管理员可以赋予给他，对商品表的增删改查的权限。自定义程度：当角色为客户，只能对商品表进行查询权限。当角色为员工，对商品表查询权限，对自身的与员工信息修改的权限、当角色为店长，基本上每张表都能进行增删改查，但对同等级的店长的信息则不能修改。当角色为系统管理员，具有数据库全部的权限，同时可以赋予给其他用户的某种操作权限。实现技术方案：添加监视器，当一个用户进入到某个模块时候，系统通过监视器，读取到该用户的权限，若该用户含有对该模块操作的权限，则显示可以操作的界面和对应的可选操作；若该用户没有对该模块操作的权限，则禁止访问。例如：用户的角色为客户，当该角色想进入到商品的模块，则系统显示可以操作的界面，但可选操作只有查询。而当用户想进入到员工管理模块，由于该用户的角色为客户