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

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

《便利店pos系统管理信息系统课程设计21组MIS课程设计实验报告.docx》由会员分享，可在线阅读，更多相关《便利店pos系统管理信息系统课程设计21组MIS课程设计实验报告.docx（23页珍藏版）》请在冰点文库上搜索。

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

管理信息系统课程设计

便利店pos系统

项目组编号

21

专业班级

12信管2班

项目组成员

范文辉

201230560205

陈梦娜

201230560203

吴文浩

201230560223

林宇航

201230760316

文档编制日期

2015.6

指导教师

邓成剑

课程设计成绩评分表

（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分

使用报表工具，实现分类汇总统计报表

使用报表工具，实现简单数据统计报表

未使用报表工具，实现列表并能汇总统计

软件开发文档版本更新记录

Content

Date

Description

Author

便利店pos机-细化迭代1

2015/4

项目设想，开发计划

林宇航

细化迭代二—需求规格说明和补充性规格说明

2015/4/18

用例图，用例文本，补充性规格说明

林宇航

软件架构设计

2015/4/19

软件架构设计

陈梦娜

1引言

1.1项目设想

A. 系统展望

应用场景：

一般便利店的销售收银系统。

用户：

收银员，顾客，经理。

系统范围：

便利店，士多店

基本目标：

主要是实现便利店货物的收费、支付和找钱功能，还有货物管理，销售管理和客户管理等。

B. 系统特性

货物管理：

对货物的录入，删除，库存和促销打折的管理。

客户管理：

 客户积分计算和享有的折扣优惠。

员工管理：

员工的登录和拥有对货物打折的权限。

销售管理：

实现收银支付促销的功能。

统计管理：

统计历史时间货物的销售状况。

1.2开发计划

A. 团队成员

项目经理（范文辉）：

统筹整个项目的工作，控制项目的进度。

分析员（范文辉）：

分析需求，确定产品应用范围、功能和最终实现的目标。

架构师（陈梦娜）：

搭建项目的构架，编写部分代码，实现系统功能。

程序员（吴文浩）：

编写代码，实现系统功能。

测试员（林宇航）：

测试系统的运行效果，功能实现程度，写测试报告。

B. 项目进度

1 进度安排：

①3-4周      搭建框架，确定核心架构，实现基础数据增删改查。

②5-6周      设计实现业务用例，实现销售开单用例。

③7-8周      设计实现业务用例，实现收银用例。

④9-10    设计实现业务用例，实现退货用例。

⑤11-12周  设计实现权限，基于所选技术实现系统权限功能。

⑥13-14周  设计实现报表，实现数据报表功能。

2 控制措施：

任务分工，把具体工作分配给每个人，项目经理及时提醒个人根据进度安排按时完成各项内容。

成员内有效沟通，尽量以比较高的效率完成项目。

C. 风险控制

1．经验欠缺，成员开发经验不足，可能使项目质量难以保证。

只有通过不断地实践，修改来提高项目的质     量。

2. 项目开发过程涉及的专业知识较多，给项目开发带来一定的困难。

开发过程中不断地学习知识。

3. 系统性能不稳定，可能出现bug。

成员使用相同的开发环境，搭建良好的配置开发环境。

1.3技术路线

对本项目用到的技术工具和作用进行简要说明。

包括开发语言和工具、计算模式（单机应用，C/S，B/S）、框架，类库、数据库管理系统等，附上版本号，可简要描述选择依据。

开发语言：

java，JavaScript，html

框架：

playframework（版本号：

2.2.1），flatui，ajax

数据库：

mysql

2需求分析

2.1业务建模

A.业务流程建模。

◆使用UML活动图分析目标系统所支持的业务流程。

◆使用文字对流程中每个活动的涉众、业务规则、使用到的单据进行必要的说明。

B.领域建模。

◆使用UML类图构建领域模型。

2.2需求规格说明

系统用例图。

B.用例详述文本。

用例1：

处理销售

级别：

用户目标

主要参与者：

收银员

涉众及其关注点：

—收银员：

希望能够快速、准确地输入，而且没有支付错误，没有找钱错误。

—顾客：

希望快速地完成购买活动，并且能够享受到可以清晰地看到商品列表、价格、优惠以及总价，还有能够得到购买凭证。

—经理：

能够管理商品，管理用户，实现查询，修改，添加，删除的操作，还有实现超控操作，更正收银员的不当操作。

前置条件：

收银员必须经过确认和认证

后置条件：

存储销售信息，生成记录和票据，计算总额和税金，更新账务和库存。

主成功场景：

1顾客携带所购的商品到收银台通过pos机付款。

2收银员开始一次新的销售。

3收银员输入一位顾客购买的商品。

4系统逐条记录商品，并显示该商品的描述、价格和累计金额。

银员重复3-4步，直到输入所有的商品。

5系统显示总金额和优惠信息。

6顾客付款，系统处理支付，并打印票据。

7系统更新销售信息和财务信息。

扩展：

*a.经理在任意时刻要求进行超控操作：

1.系统进入经理授权模式（登录经理账号）。

2.经理实现经理模式操作，例如：

改变商品优惠信息，给顾客打折，处理销售交易等。

3.系统恢复到收银员模式。

*b.系统在任意时刻失败：

    为了支持恢复和更正账务处理，要保证交易能够从任何一步恢复

1.收银员重启系统，登录，恢复上一次状态。

2.系统重建上次状态。

   2a.系统在恢复过程中检测到异常：

1.系统向收银员提示错误，记录此错误，并进入一个人初始状态。

2.收银员开始一个新的销售交易。

1a.顾客或经理需要恢复一个中断的销售交易。

1收银员执行恢复操作，并输入交易ID提取对应的销售交易。

2系统显示被恢复的销售交易状态及其小计。

2a.未发现对应的销售交易。

1系统向收银员提示错误。

2收银员可能会开始一个新销售交易，并重新输入所有商品。

3收银员继续该次销售交易。

2-4a顾客告诉收银员其获得的优惠折扣。

 1收银员核实后输入折扣信息。

 2系统根据折扣信息计算总金额。

3a无效商品ID（在系统中未发现）：

 1系统提示错误并拒绝输入该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收银员收取现金，并给顾客找零。

6b打印票据

  1系统提示错误。

  2收银员更换纸张。

  3收银员或打印其它票据。

特殊需求：

●文本信息即字体可见距离要为1米。

●记录某位收银员一次登录收取的金额。

●收银员能被授权给某位顾客优惠。

发生频率：

可能会不断发生

未决问题：

●针对不同的业务需要怎样进行定制。

●顾客是否可以要求第三方支付。

应用的领域规则

ID

规则

可变性

来源

规则1

所有商品有经理录入并决定价格和优惠折扣。

不同便利店优惠折扣不同。

便利店政策

规则2

所有商品折扣不能大于20%，顾客消费200-500折扣为5%，500以上10%，节日另决定。

不同便利店优惠折扣不同。

便利店政策

用例2名称：

收银

范围：

便利店POS机应用

主要参与者：

收银员

前置条件：

收银员必须经过登陆和认证身份

后置条件：

存储销售交易信息，确定每个订单号对应一笔交易。

准确计算销售总价和折扣，并同时更新库存信息，生成票据。

主成功场景：

1.收银员把顾客所要购买的商品信息都录入到pos机应用，进行结账操作。

2.系统显示应付总额，收银员告知顾客所要支付金额。

3.顾客付款，系统进行处理支付，收银员找零。

4.系统记录完整销售交易记录，同时更新库存信息

5.系统打印票据

6.顾客带着商品和票据离开

扩展：

*a.经理在任意时刻要求进行超控操作：

1.系统进入经理授权模式（登录经理账号）。

2.经理实现经理模式操作，例如：

改变商品优惠信息，给顾客打折，处理销售交易等。

3.系统恢复到收银员模式。

*b.系统在任意时刻失败：

为了支持恢复和更正账务处理，要保证交易能够从任何一步恢复

2-3a.顾客发现现金不足,无法付款:

1.顾客要求取消本次销售交易,收银员在系统上取消该销售交易

2.顾客要求使用其他方式支付

2a.顾客使用信用卡支付：

1.顾客输入信用卡密码。

2.系统显示支付信息以验证。

3.收银员确认。

4.系统向外部的支付授权服务系统发送请求

5.支付授权服务系统批准该支付，系统收到回答并提示收银员

3b.系统崩溃,

1. 无法开始处理支付消息,收银员重启系统服务,继续操作

  1a.重启服务失败,,收银员向经理请求超控操作,重新开始一次销售交易

2.系统处理支付事件时出现故障,无法计算（显示）找零金额

2a.收银员重启系统服务,继续操作

    1.重启失败,收银员手工计算找零金额

3c.pos机无法自动弹出现金抽屉

  1.收银员手工开启现金抽屉,若无法手工开启,则请求经理执行超控操作

3d.现金抽屉里零钱不足,无法给顾客找零

1.收银员询问顾客是否有零钱支付或者是否使用其他方式付款

2.收银员从其他现金抽屉里取出零钱,给顾客找零

  2a.所有现金抽屉均没有足够的零钱,收银员通知经理,经理及时补充零钱

3e.顾客要求使用会员卡消费或声称他们符合某种优惠条件（例如,会员卡账户积分达到一定程度可以享受打折优惠）

1.收银员向系统提示打折请求

2.收银员输入顾客手机号码或会员卡ID确认身份

3.系统按照打折规则显示折扣总计（若为兑现积分,则在打折的同时扣除结余积分）

5a.打印票据时出现问题

  1.系统检测出错误,给出提示

  2.收银员更换纸张

  3.收银员请求打印其他票据

用例3名称：

退货

范围：

便利店pos机应用‘

主要参与者：

收银员，顾客

前置条件：

收银员必须登陆到系统并通过认证，该顾客须持有票据，票据的订单号对应一个销售交易信息。

后置条件：

该退回的商品不能继续销售，应返还给供应商；把该销售交易信息设置为失败交易，同时生成新的销售交易信息取代旧的销售信息。

主成功场景：

1.顾客带票据及需要退货的商品到收银台。

2.收银员查询票据，系统显示对应的销售交易信息。

3.顾客选择重新更换或退款,收银员根据顾客选择进行操作。

4.系统处理完成，打印新的票据。

5.顾客离开。

扩展：

*a.经理在任意时刻要求进行超控操作：

1.系统进入经理授权模式（登录经理账号）。

2.经理实现经理模式操作，例如：

改变商品优惠信息，给顾客打折，处理销售交易等。

3.系统恢复到收银员模式。

*b.系统在任意时刻失败：

为了支持恢复和更正账务处理，要保证交易能够从任何一步恢复

2.系统中没有对应票据的销售交易信息

1.收银员告知顾客，并取消这次退货操作

3a.顾客选择更换商品，对应商品库存为0

1，收银员告知顾客，询问顾客是否选择退款操作。

2，收银员根据系统提供信息，退还金额给顾客。

3b.系统崩溃,

1. 无法开始处理支付消息,收银员重启系统服务,继续操作

  1a.重启服务失败,,收银员向经理请求超控操作,重新开始一次销售交易

2.系统处理支付事件时出现故障,无法计算（显示）找零金额

2a.收银员重启系统服务,继续操作

1.重启失败,收银员手工计算找零金额

3c.pos机无法自动弹出现金抽屉

  1.收银员手工开启现金抽屉,若无法手工开启,则请求经理执行超控操作

3d.现金抽屉里零钱不足,无法给顾客找零

1.收银员询问顾客是否有零钱支付或者是否使用其他方式付款

2.收银员从其他现金抽屉里取出零钱,给顾客找零

  2a.所有现金抽屉均没有足够的零钱,收银员通知经理,经理及时补充零钱

4a.打印票据时出现问题

  1.系统检测出错误,给出提示

  2.收银员更换纸张

  3.收银员请求打印其他票据

2.3补充性规格说明

功能性

1销售交易中断处理

保存数据，交易中断后能恢复上一次交易。

2安全性

 在开始使用系统之前要进行登录。

3统计性

 能够将数据导出并且实现统计画图操作。

可用性

1顾客应该能轻松看到显示器上的信息。

2显示器字体颜色避免使用色盲人群不能辨认的颜色。

可靠性

1避免系统时常出现问题导致顾客等待时间长。

接口

1条形码激光扫描仪

2票据打印机

2.4系统顺序图与操作契约

A.系统顺序图。

选择：

销售过程

B.操作契约。

选择系统顺序图中复杂的系统事件编写操作契约。

契约enterItem

操作：

enterItem（）

交叉引用：

用例：

处理销售

前置条件：

无

后置条件：

●创建了Bill的实例bill（创建实例）

●bill被关联到user和customer（形成关联）

●bill的其他属性被初始化（修改属性）

3架构设计

3.1功能结构设计

使用树形功能层次图画出系统的功能结构图。

3.2软件架构设计

软件分层。

1、UML包图：

2、描述：

本次课程设计采用play框架（半路弃用ssh，架构师表示真的不想坑害队友==），为什么要使用play;前端采用amazeui, 戳这里是amazeui

view:

用户视图层，使用play默认scalatemplate渲染模板，同时使用国产前端框架amazeui

cotroller:

 控制器

model:

模型

router:

路由，负责请求方法跳转

命名规范。

（1） 各层包及类命名规范：

总体原则：

包名所有字母小写，类名采用 “驼峰标识”，由于paly遵循默认大于设置的设计思想，所以对各种类和方法的命名已有规定，此处遵循play命名规范；

（2） 其它命名规范：

1.变量命名：

变量名首字母必须小写，如果该变量名有多个单词组成，后面的单词首字母大写，单词与单词之间不要使用"_"做连接，变量名访问控制必须为私有， 可以对其增加 setter与getter方法；

2.常量命名：

所有字母大写，如果有多个单词组成，单词与单词之间以” _“隔开。

而且 该变量必须是公共、静态、final类型；

3.方法命名：

首字母必须小写，如果该变量名有多个单词组成，后面的单词首字母大写， 单词与单词之间不要使用"_"做连接。

单词不要使用名词；

（3） 前端规范：

按照约定的文件摆放位置，命名规范遵循前端命名规范，和后台通过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":

 "no pointer event","retmsg":

 "0"}

2.接口规范：

如/customer/add；

架构相关设计模式。

1、关于DAO模式：

Play实体采用ActiveRecord模式，将Struts中的dao与pojo合并，ActiveRecord也属于ORM层，由Rails最早提出，遵循标准的ORM模型：

表映射到记录，记录映射到对象，字段映射到对象属性。

配合遵循的命名和配置惯例，能够很大程度的快速实现模型的操作，而且简洁易懂。

Play也提倡使用ActiveRecord模式进行快速开发，其主要思想是：

每一个数据库表对应创建一个类，类的每一个对象实例对应于数据库中表的一行记录；通常表的每个字段在类中都有相应的Field；ActiveRecord同时负责把自己持久化，在ActiveRecord中封装了对数据库的访问，即CURD；

ActiveRecord是一种领域模型（Domain Model），封装了部分业务逻辑；

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模型，设计数据库表；

部分表详细

createtablebill_item（

bill_item_idbigintauto_incrementnotnull,

product_idbigintnotnull,

bill_idbigintnotnull,

bill_item_suminteger,

bill_item_sum_pricevarchar（255）,

bill_item_createtimedatetime（6）,

bill_item_statusinteger,

constraintpk_bill_itemprimarykey（bill_item_id））

;

createtablecategory（

category_idbigintauto_incrementnotnull,

category_namevarchar（255）,

category_desvarchar（255）,

category_createtimedatetime（6）,

constraintuq_category_category_nameunique（category_name）,

constraintpk_categoryprimarykey（category_id））

;

createtablecustomer（

customer_idbigintauto_incrementnotnull,

namevarchar（255）,

sexvarchar（255）,

addressvarchar（255）,

birthdaydatetime（6）,

isviptinyint

（1）default0,

phonevarchar（255）,

createtimedatetime（6）,

constraintpk_customerprimarykey（customer_id））

;

createtablemyorder（

idbigintauto_incrementnotnull,

order_create_timedatetime（6）,

order_statusinteger,

constraintpk_myorderprimarykey（id））

;

4.4权限设计

权限粒度：

用户粒度，它可以精细到角色或具体的用户，有系统管理员讲某一资源访问权限授权给角色后用户，从而实现对数据库的操作。

这里的角色可以理解为实际工作中的岗位、职位等。

操作对象粒度。

对数据库的增删改查，是由具体的模块实现的。

对于新用户，一般只有赋予查询权限。

系统管理员可以根据实际情况赋予对应的权限。

比如角色为店长，系统管理员可以赋予给他，对商品表的增删改查的权限。

自定义程度：

当角色为客户，只能对商品表进行查询权限。

当角色为员工，对商品表查询权限，对自身的与员工信息修改的权限、

当角色为店长，基本上每张表都能进行增删改查，但对同等级的店长的信息则不能修改。

当角色为系统管理员，具有数据库全部的权限，同时可以赋予给其他用户的某种操作权限。

实现技术方案：

添加监视器，当一个用户进入到某个模块时候，系统通过监视器，读取到该用户的权限，若该用户含有对该模块操作的权限，则显示可以操作的界面和对应的可选操作；若该用户没有对该模块操作的权限，则禁止访问。

例如：

用户的角色为客户，当该角色想进入到商品的模块，则系统显示可以操作的界面，但可选操作只有查询。

而当用户想进入到员工管理模块，由于该用户的角色为客户