小区超市pos机系统管理信息系统课程设计27组MIS课程设计实验报告Word文档下载推荐.docx
《小区超市pos机系统管理信息系统课程设计27组MIS课程设计实验报告Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《小区超市pos机系统管理信息系统课程设计27组MIS课程设计实验报告Word文档下载推荐.docx（21页珍藏版）》请在冰豆网上搜索。
绘制了基本模型；
忽略系统重要功能；
有较多项目无关内容
质量
语言精炼；
模型选用合理；
模型绘制规范清晰；
模型关联性强
语言较精炼，模型选用基本合理；
模型绘制较规范清晰，模型之间有关联
拼凑文字；
没有建模或模型不规范；
模型之间缺乏关联
（3）程序评分40%
架构
10分
使用了常见JavaEE框架,选用了UI框架
选用个别框架；
采用DAO及MVC模式
未使用框架；
单纯JSP页面；
分层不合理
基础
数据
30分
实现了所有基础数据管理；
包含了必要字段；
选用合适组件；
有格式校验
实现了主要的基础数据管理；
选用了较合适的组件；
部分格式校验
实现部分基础数据管理，只选择文本框，未做格式校验
业务
功能
实现完整的业务流程；
读取基础数据；
实现1对n或n对m；
流程活动间有逻辑关联
实现较完整的业务流程；
读取大部分基础数据；
基本实现1对n或n对m；
流程活动间有一定关联
实现了单个活动；
较少读取基础数据；
较多使用文本框录入数据；
活动之间缺乏逻辑关联
权限
使用安全框架实现自定义权限
按角色分配权限
简单权限
查询
实现了多条件组合查询功能，查询结果能进一步操作
实现多条件组合查询
实现单条件简单查询
报表
使用报表工具，实现分类汇总统计报表
使用报表工具，实现简单数据统计报表
未使用报表工具，实现列表并能汇总统计
软件开发文档版本更新记录
Content
Date
Description
Author
细化迭代1
2015年4月
确定核心架构实现基础数据增删改查
细化迭代2
实现销售开单用例
细化迭代3
2015年5月
实现收银用例
细化迭代4
实现退货用例
细化迭代5
2015年6月
基于所选技术实现系统权限功能
细化迭代6
实现数据报表功能
1引言
1.1项目设想
A.系统展望。
产品应用场景：
小区超市的信息管理系统
用户：
收银员、经理、普通顾客、会员顾客、维护人员、售货员
系统范围：
小区超市
基本目标：
系统能被简单地使用，使操作员短时间能够熟练，从而达到存储销售信息、准确计算销售额、更新售价和库存信息、记录销售量、生成票据和记录支付授权的批准的目标。
B.系统特性。
用高阶、简洁的语句对系统预期功能和性能加以概述。
1.系统管理
（1）会员顾客：
会员顾客增删改查。
（2）普通顾客：
普通顾客增删改查。
（3）权限：
对顾客的类型进行授权。
2.基础数据
（1）产品类别：
产品类别增删改。
（2）产品：
产品增删改查。
（3）顾客：
普通顾客和会员顾客增删改查。
3.销售管理
（1）开单：
生成销售订单——录入商品条目。
（2）收银：
生成支付单——修改库存——打印小票。
（2）退货：
选择订单——选择商品——生成退货单——退款。
4.查询
（1）按名称查找某商品，并能查看它的库存数。
（2）按顾客&
销售时间查询订单。
5.统计报表
（1）统计超市（时间分为年、季度、月）销售总金额（数字报表）。
（2）按“产品类别”统计“起止时间”内销售金额，有小计和总计（数字报表）。
1.2开发计划
A.团队成员。
架构师、项目经理
B.项目进度。
过程
时间
目标
工作内容
提交资料
控制措施
初始
阶段
第2周
分组定题
布置任务，确定分组；
确定题目，制定计划。
提交MIS课程设计任务书
提交分组计划
确定项目的方向，进行项目的需求分析。
3-4周
搭建框架
确定核心架构
实现基础数据增删改查
程序；
编写文档1.1,1.2,3.2
小组成员加强沟通，明确各成员的任务的工作时间。
5-6周
设计实现业务用例
编写文档2.1-2.4；
编写4.1.1
编写4.2.1
7-8周
完善文档2.1-2.4，
编写4.1.2
9-10
编写4.1.3
编写3.1
11-12周
设计实现权限
编写文档4.4
编写文档4.3
13-14周
设计实现报表
编写文档4.2.2
小组成员加强沟通，项目经理监督。
交付
17周
提交成果
编程人员实验室演示程序；
提交文档打印稿。
完成文档5,6
最终版程序
文档定稿
C.风险控制。
即使项目经过了详细的计划并进行跟进，但没有控制好项目中的风险，项目仍然会超出进度的预计，从而导致项目团队内部的不和谐和项目的失败，所以风险控制能力则是项目经理重要的技能之一。
因而在参考老师布置的项目进度计划和考虑我们小组的实际情况下，我们认识我们会面临的项目风险进度有：
1、技术风险：
在开发的过程中，基于开发者的技术水平有限，会遇到技术上的瓶颈，这时需要花费时间去学习技术。
2、团队内部风险：
在项目开发过程中，每个成员的时间分配不明确，从而导致项目进度有所延误。
3、业务风险：
对项目的需求不明确，项目的实际情况与开发者所设想的有差异。
基于上述风险，项目经理可以通过预先采取措施的方法对项目风险的进程和后果进行适当的控制与管理，因而会采取以下风险控制措施：
1、程序员在配合架构师的前提下，事先通过老师的博客和视频教程学习新的技术
2、团队内部加强沟通，明确安排组员的工作时间，避免因个人原因而导致总个团队的进度受到延误。
3、加强对项目需求分析的理解，若开发者对项目需求仍然有不清楚的地方及时与团队和老师沟通解决。
1.3技术路线
本项目采用的主要开发工具为：
Eclipse、mysql5.5，
涉及开发语言有：
Java，HTML，sql，jpql
主要框架：
maven+springdata+springmvc
项目模式：
C/S
版本号：
0.0.1
2需求分析
2.1业务建模
A.业务流程建模。
涉众：
顾客，收银员、经理
业务规则
规则1
购买者折扣规则。
示例：
员工：
20%折扣额。
会员：
10%折扣额
高
每个零售商有不同规则
零售商政策
规则2
商品折扣规格。
洗发水买二送一
花生油九五折出售
高。
每个零售商有不同规则，每周或每月都可能改变
规则3
信用卡手续费规则
很低。
根据银行的政策来收取部分手续费
信用授权的公司政策
规则4
信用卡付款的方式所需的签名
使用者签名是必需的
使用到的单据：
1、收款票据：
超市名，工号，单号，商品名，商品单价，商品数量，商品金额，商品折扣，应收金额，实收金额，开单时间，咨询电话，超市地址等。
2、信用卡票据：
客户号，工号，卡号，日期/时间，应收金额，折扣金额，实收金，超市名，咨询电话，超市地址等。
B.领域建模。
2.2需求规格说明
A.系统用例图。
B.用例详述文本。
用例UC1：
开单
范围：
超市POS机应用
级别：
顾客目标
主要参与者：
收银员
涉众及其关注点：
-收银员：
希望有准确、快速的输入方式。
-顾客：
希望买到商品，井获得快速的服务。
-公司：
希望能够准确地记录交易，满足顾客要求。
-经理：
希望能够快速执行超控操作，并易于更正收银员的不当操作。
前置条件：
收银员必须通过确认和认证。
后置条件：
存储销售信息。
准确计算销售额。
更新售价和库存信息。
记录销售量。
主事件流：
1.顾客携带所购商品到收银台通过POS机付款。
2.收银员开始一次新的销售交易。
3.收银员扫描顾客所购商品的商品条形码来处理商品信息。
4.系统逐条记录出售的商品，并显示该商品的描述，价格和累计额。
价格通过一组价格规则来计算。
收银员重复3～4步，直到输入结束。
5.系统显示总额和计算折扣。
6.收银员告知顾客总额，并请顾客付款。
扩展
*a.经理在任意时刻要求进行超控操作：
1.系统进入经理授权模式。
2.经理或收银员执行某一经理模式的操作。
3.系统恢复到收银员授权模式。
*b.系统在任意时刻失败：
为了支持恢复处理，要保证所有交易的敏感状态和事件都能够从场景的任何一步中完全恢复。
1.收银员重启系统，登录，请求恢复上次状态。
2.系统重建上次状态。
2a.系统在恢复过程中检测到异常：
1.系统向收银员提示错误，记录此错误，并进入一个初始状态。
2.收银员开始一次新的销售交易。
3a.无效商品ID：
1.系统提示错误并拒绝输入该ID。
2.收银员响应该错误收。
2a.商品ID可读。
1.银员手工输入商品ID。
2.系统显示商品项目的描述和价格。
2a.无效商品ID：
系统提示错误，收银员尝试其他方式。
3b.当有多个同一类别的商品时，不必记录每个商品的唯一标识：
1.收银员输入商品类别的标识和商品数量。
3-6a.顾客要求收银员去掉某个原先想买的商品:
1.收银员录入要去掉商品的条码与数量。
2.系统更新当前的总销售金额。
3-6b.顾客要求收银员取消这次销售:
1.收银员取消这次销售交易。
3-6c.顾客要求收银员暂停本次销售:
1.系统将销售记录下来，而且之后可以在任何POS终端中取回这比销售交易的记录。
5a.收银员询问顾客是否享受会员优惠
1.顾客享受会员优惠，系统按照打折规则进行交易。
2.顾客不享受会员优惠，系统按照商品原价进行交易。
用例UC2：
收银
希望不会发生付款错误的情况。
希望获得精准的服务，同时希望付款方式多元化。
希望确保记录了支付授权服务的支付票据。
-支付授权服务：
希望接收到格式和协议正确的数字授权请求。
希望准确计算对商店的应付款。
生成票据和记录支付授权。
1.收银员告知顾客总额，并请顾客付款。
2.顾客付款，系统处理付款。
3.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。
4.系统打印购物票据。
5.顾客携带商品和票据离开。
3a.现金支付：
1.收银员输入收取的现金额。
2.系统显示找零金额，并弹出现金抽屉。
3.收银员放入收取的现金，并给顾客找零。
4.系统记录该现金支付。
3b.信用卡支付：
1.顾客输入信用卡账户信息。
2.系统显示其支付信息以备验证。
3.收银员确认。
4.系统向外部支付授权服务系统发送支付授权请求，并请求批准该支付。
4a.系统检测到与外部系统协作时的故障：
1.系统向收银员提示错误。
2.收银员请求顾客更换支付方式。
5.系统收到批准支付的应答并提示收银员，同时弹出现金抽屉（以便放入签名后的信用卡支付票据）。
5a.系统收到拒绝支付的应答：
1.系统向收银员提示支付被。
6.系统记录信用卡支付信息，其中包括支付批准。
7.系统显示信用卡支付的签名机制。
8.收银员请求顾客签署信用卡支付，顾客输入签名。
9.如果在纸质票据上签名，则收银员将该票据放入现金抽屉并关闭抽屉。
4a.打印票据。
1.如果系统能够检测到错误，给出提示。
2.收银员更换纸张。
3.收银员请求打印其他票据。
用例UC3：
退货
希望有准确、快速的输入方式，不会发生付款错误的情况。
希望购买后能保证退货。
1.顾客提出退货要求。
2.收银员接受顾客提供的商品和购物票据，并向经理汇报情况。
3.经理根据购物票据对商品进行核查。
4.经理录入退货信息。
5.系统生成退货单。
6.经理根据退货单向顾客返还相应的现金，并打印退货单。
3a.核查不通过：
1.购物票据里的商品与实际要求退货的商品不符，经理拒绝顾客退货要求，并返还商品。
2.商品受到售后损坏，不符合退货要求。
4a.退货信息录入错误，经理向系统取消退货操作，并重新进行退货操作：
6a.打印退货单。
1.如果系统能够检测到错误，给出提示。
2.收银员更换纸张。
3.收银员请求打印其他票据。
特殊需求：
l大型、平面显示器，触摸式使用界面，在30厘米外能看清上面的字。
l能在30秒内相应90%的信用授权。
l由于某种原因造成与外部系统（如库存系统）连接出现故障时，希望系统的复原能力比较强。
l显示的文字应是国际化语言文字。
l能在步骤3-7之间客户华增加企业的业务规则。
技术与数据变元表：
*a.店长超控需要刷卡（由读卡器读取超控卡）或在键盘上输入授权码。
3a.（如果有条码的话）用键盘或条码扫描器输入商品识别码。
3b.商品识别码可以是UPC、EAN、JAN、SKU中的任何一种。
5a.顾客的会员号可用刷卡读取或在键盘上输入。
发生频率：
可能会连续不断地发生。
2.3补充性规格说明
简介
本文档中描述的是在POS系统需求中除用例以外的所有其他需求。
功能性
（这功能有可能是存在于或涉及多个用例中的常见功能）
1.系统记录错误的处理方法：
要求记录所有系统错误到可永久保存的储存介质中。
2.系统可嵌入商业规则：
从而在某个特定事件发生时，可以使用某企业自己的商业规则。
3.安全性：
要求系统所有的使用行为必须是得到授权的。
可用性
考虑到人的因素，由于顾客希望能看到POS系统显示的内容，所以需要使用大型显示器，以便于顾客在30厘米以外也能看到文字。
同时，显示时应该避免使用色盲无法辨别的颜色。
另外，为了能及时提醒收银员，不仅要显示文字还需要能够提供声音发出的提示或警告。
可靠性
1.可恢复性：
当系统中断无法和外部系统通信时，利用本地临时解决的可能性。
2.性能：
希望90％以上的交易能在一分钟内完成。
可支持性
1.可适应性：
系统要能根据不同情况，设定相应的商业规则，从而在不同情况下提供不同的服务。
2.可配置性：
用户够根据自身情况选择系统不同的配置方式，如瘦客户机或胖客户机，两层式系统或多层式系统等。
实现约束
采用Java技术的解决方案。
采用Java技术一般被认为除了易于开发外，还能够提高远期的移植和可支持性能力。
购买构件
•税金计算器。
必须支持用于不同国家的可插拔计算器。
免费开源构件
一般而言，在该项目中我们尽可能地使用免费的Java技术开源构件。
如：
•ssh
•easyui
•maven
•......
接口
1.重要硬件和接口
•触摸屏（触摸动作视为鼠标事件）
•条形码激光扫描仪（通常附加在一种特殊键盘上，扫描输入在软件中视为键盘输入）。
•票据打印机
•信用卡读卡器
2.软件接口
由于存在外部协作系统，我们需要采用不同的接口，接入不同的系统。
所关注领域内的信息
1.定价
除了定价规则之外，还需要注意，产品有原始价格和可选的常设低标价之分。
产品标示的价格（折扣前）是常设低标价。
由于财务和税务的原因，即使有常设低标价，也需要维护原始价格。
2信用卡支付处理
当支付授权服务批准了信用卡支付后，将有支付授权服务来负责对卖方的支付。
3.销售税：
对税金计算采用第三方软件（税金计算器）计算。
4.商品标识：
UPC、EAN、SKU、条形码和条形码读取装置。
2.4系统顺序图与操作契约
A.处理销售系统顺序图。
B.操作契约。
契约CO1：
makeNewSale
操作：
makeNewSale（）
交叉引用：
用例：
处理销售
无
创建了Sale的实例s（创建实例）
s被关联到Register（形成关联）
s的属性被初始化（修改属性）
契约CO2:
enterItem
正在进行中的销售
创建了SalesLineItem的实例sli（创建实例）
sli被关联到当前Sale（形成关联）
sli.quantity赋值为quantity（修改属性）
基于itemID的匹配，sli被关联到ProductDescription（形成关联）
契约CO3:
enterSale
Sale.isComplete被置为真（修改属性）。
契约CO4:
makePayment
makePayment（amount:
Money）
创建了Payment的实例p（创建实例）
p.amountTendered被赋值为amount（修改属性）
p被关联到当前Sale（形成关联）
当前的Sale被关联到Store（形成关联）
3架构设计
3.1功能结构设计
3.2软件架构设计
A.软件分层。
件主要以mvc模式分层，主要分为beans包、common包、controller包、model包、repository包、service包、util包。
说明如下：
beans包：
将与controller涉及的实体属性的不相符的信息转化为对应的对象
controller包：
也撑action包，接收前端的信息并处理业务
model包：
数据库表对应的实体类
repository包：
dao层，执行数据库表的写改删查任务
service包：
接收controller的业务信息，处理业务
utile包：
一些工具类
B.命名规范。
1.变量的命名由小写的前缀加上首字母大写的英文单词组成
2.常量全部使用大写，用能表达含义的英文单词表示，中间用“_”连接
3.循环变量一般采用i、j、k、m、n表示。
4.方法的命名采用动宾结构，能够表达函数实现的功能
5.setter和getter方法在命名时加上前缀set和get，变量名首字母变大写
C.架构相关设计模式。
4详细设计
4.1用例实现设计
4.1.1销售开单
A.类图。
B.顺序图。
4.1.2收银
A.类图。
B.顺序图。
4.1.3退货
4.2输入输出设计
4.2.1表单设计
4.2.2报表设计
4.3数据库设计
E-R模型
数据库表
4.4权限设计
权限粒度:
增、删、改、查、浏览5个操作，通过“用户权限”这样就知道某个用户是否有某张表的操作权限,同样的角色也是这样控制
5系统实现
5.1功能实现
（1）增
（2）删
（3）改
（4）查
5.2系统测试
5.2.1单元测试
5.2.2用例测试
开单测试
（1）测试失败
（2）测试成功
5.3系统部署
代码配置：
1.本地要有一个maven库，存放常用jar包
2.需安装jdk1.7或以上
3.数据库为mysql5.1或以上
项目代码部署步骤：
1.以mavenproject形式导入到Eclipse
2.导入数据库文件到mysql数据库
3.将项目的配置文件application.properties中的信息该为自己数据库信息
6项目总结
我们最初对pos机简直是一窍不通，认为只要大家都肯下功夫，都努力做，就可以了。
所以一开始时我们商量怎么做，然后大家一起做，但其实等大家商量好后，实际其过程真可谓一波三折。
所以总结起来，本次设计过程的失体现在两个方面：
第一，技术水平有限，编程上基本上是以程序员为主力军，所以这也给了程序员一定的重担，在学习新的技术的同时又要赶进度，所以出现了在迭代阶段，往往只有文档而代码还没有完成的情况；
第二，就是时间把控不好，彼此间都相互依赖对方，要等对方完成了对应的任务才开始自己的任务，就成了一个人在那做，但是其他人在旁边看，这样极大的降低了团队的工作效率。
我们意识到这个问题后，仔细的分
升级会员 