小区超市pos机系统管理信息系统课程设计27组MIS课程设计实验报告Word文档下载推荐.docx

1、绘制了基本模型；忽略系统重要功能；有较多项目无关内容质量语言精炼；模型选用合理；模型绘制规范清晰；模型关联性强语言较精炼，模型选用基本合理；模型绘制较规范清晰，模型之间有关联拼凑文字；没有建模或模型不规范；模型之间缺乏关联（3） 程序评分 40%架构10分使用了常见JavaEE框架, 选用了UI框架选用个别框架；采用DAO及MVC模式 未使用框架；单纯JSP页面；分层不合理 基础数据30分实现了所有基础数据管理；包含了必要字段；选用合适组件；有格式校验实现了主要的基础数据管理；选用了较合适的组件；部分格式校验实现部分基础数据管理，只选择文本框，未做格式校验业务功能实现完整的业务流程；读取基础数

2、据；实现1对n或n对m；流程活动间有逻辑关联实现较完整的业务流程；读取大部分基础数据；基本实现1对n或n对m；流程活动间有一定关联实现了单个活动；较少读取基础数据；较多使用文本框录入数据；活动之间缺乏逻辑关联权限使用安全框架实现自定义权限按角色分配权限简单权限查询实现了多条件组合查询功能，查询结果能进一步操作实现多条件组合查询实现单条件简单查询报表使用报表工具，实现分类汇总统计报表使用报表工具，实现简单数据统计报表未使用报表工具，实现列表并能汇总统计软件开发文档版本更新记录ContentDateDescriptionAuthor细化迭代12015年4月确定核心架构实现基础数据增删改查细化迭代2

3、实现销售开单用例细化迭代32015年5月实现收银用例细化迭代4实现退货用例细化迭代52015年6月基于所选技术实现系统权限功能细化迭代6实现数据报表功能1引言1.1项目设想A. 系统展望。产品应用场景：小区超市的信息管理系统用户：收银员、经理、普通顾客、会员顾客、维护人员、售货员系统范围：小区超市基本目标：系统能被简单地使用，使操作员短时间能够熟练，从而达到存储销售信息、准确计算销售额、更新售价和库存信息、记录销售量、生成票据和记录支付授权的批准的目标。B. 系统特性。用高阶、简洁的语句对系统预期功能和性能加以概述。1.系统管理（1） 会员顾客：会员顾客增删改查。（2） 普通顾客：普通顾客增删

4、改查。（3） 权限：对顾客的类型进行授权。2.基础数据（1） 产品类别：产品类别增删改。（2） 产品：产品增删改查。（3） 顾客：普通顾客和会员顾客增删改查。3.销售管理（1） 开单：生成销售订单录入商品条目。（2） 收银：生成支付单修改库存打印小票。（2） 退货：选择订单选择商品生成退货单退款。4.查询（1） 按名称查找某商品，并能查看它的库存数。（2） 按顾客& 销售时间查询订单。5.统计报表（1） 统计超市（时间分为年、季度、月）销售总金额 （数字报表）。（2） 按“产品类别”统计“起止时间”内销售金额，有小计和总计（数字报表）。1.2 开发计划A. 团队成员。架构师、项目经理B. 项目

5、进度。过程时间目标工作内容提交资料控制措施初始阶段第2周分组定题布置任务，确定分组；确定题目，制定计划。提交MIS课程设计任务书提交分组计划确定项目的方向，进行项目的需求分析。3-4周搭建框架确定核心架构实现基础数据增删改查程序；编写文档1.1, 1.2, 3.2小组成员加强沟通，明确各成员的任务的工作时间。5-6周设计实现业务用例编写文档2.1-2.4；编写4.1.1编写4.2.17-8周完善文档2.1-2.4，编写4.1.29-10编写4.1.3编写3.111-12周设计实现权限编写文档4.4编写文档4.313-14周设计实现报表编写文档4.2.2小组成员加强沟通，项目经理监督。交付17周

6、提交成果编程人员实验室演示程序；提交文档打印稿。完成文档5,6最终版程序文档定稿C. 风险控制。即使项目经过了详细的计划并进行跟进，但没有控制好项目中的风险，项目仍然会超出进度的预计，从而导致项目团队内部的不和谐和项目的失败，所以风险控制能力则是项目经理重要的技能之一。因而在参考老师布置的项目进度计划和考虑我们小组的实际情况下，我们认识我们会面临的项目风险进度有：1、技术风险：在开发的过程中，基于开发者的技术水平有限，会遇到技术上的瓶颈，这时需要花费时间去学习技术。2、团队内部风险：在项目开发过程中，每个成员的时间分配不明确，从而导致项目进度有所延误。3、业务风险：对项目的需求不明确，项目的实

7、际情况与开发者所设想的有差异。 基于上述风险，项目经理可以通过预先采取措施的方法对项目风险的进程和后果进行适当的控制与管理，因而会采取以下风险控制措施：1、程序员在配合架构师的前提下，事先通过老师的博客和视频教程学习新的技术2、团队内部加强沟通，明确安排组员的工作时间，避免因个人原因而导致总个团队的进度受到延误。3、加强对项目需求分析的理解，若开发者对项目需求仍然有不清楚的地方及时与团队和老师沟通解决。1.3 技术路线本项目采用的主要开发工具为：Eclipse、mysql5.5，涉及开发语言有：Java，HTML，sql，jpql主要框架：maven+spring data+spring mv

8、c项目模式：C/S版本号：0.0.12 需求分析2.1业务建模A. 业务流程建模。涉众：顾客，收银员、经理业务规则规则1购买者折扣规则。示例：员工：20%折扣额。会员：10%折扣额高每个零售商有不同规则零售商政策规则2商品折扣规格。洗发水买二送一花生油九五折出售高。每个零售商有不同规则，每周或每月都可能改变规则3信用卡手续费规则很低。根据银行的政策来收取部分手续费信用授权的公司政策规则4信用卡付款的方式所需的签名使用者签名是必需的使用到的单据：1、收款票据：超市名，工号，单号，商品名，商品单价，商品数量，商品金额，商品折扣，应收金额，实收金额，开单时间，咨询电话，超市地址等。2、信用卡票据：客

9、户号，工号，卡号，日期/时间，应收金额，折扣金额，实收金，超市名，咨询电话，超市地址等。 B. 领域建模。2.2需求规格说明A.系统用例图。B. 用例详述文本。用例UC1：开单范围：超市POS机应用级别：顾客目标主要参与者：收银员涉众及其关注点：-收银员：希望有准确、快速的输入方式。-顾客：希望买到商品，井获得快速的服务。-公司：希望能够准确地记录交易，满足顾客要求。-经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。前置条件：收银员必须通过确认和认证。后置条件：存储销售信息。准确计算销售额。更新售价和库存信息。记录销售量。主事件流：1.顾客携带所购商品到收银台通过POS机付款。2.

10、收银员开始一次新的销售交易。3.收银员扫描顾客所购商品的商品条形码来处理商品信息。4.系统逐条记录出售的商品，并显示该商品的描述，价格和累计额。价格通过一组价格规则来计算。收银员重复34步，直到输入结束。5.系统显示总额和计算折扣。6.收银员告知顾客总额，并请顾客付款。扩展*a.经理在任意时刻要求进行超控操作： 1.系统进入经理授权模式。 2.经理或收银员执行某一经理模式的操作。 3.系统恢复到收银员授权模式。*b .系统在任意时刻失败：为了支持恢复处理，要保证所有交易的敏感状态和事件都能够从场景的任何一步中完全恢复。1.收银员重启系统，登录，请求恢复上次状态。2.系统重建上次状态。 2a.系

11、统在恢复过程中检测到异常： 1.系统向收银员提示错误，记录此错误，并进入一个初始状态。 2.收银员开始一次新的销售交易。3a.无效商品ID：1.系统提示错误并拒绝输入该ID。2.收银员响应该错误收。2a.商品ID可读。1.银员手工输入商品ID。2.系统显示商品项目的描述和价格。2a.无效商品ID：系统提示错误，收银员尝试其他方式。3b.当有多个同一类别的商品时，不必记录每个商品的唯一标识：1.收银员输入商品类别的标识和商品数量。3-6a.顾客要求收银员去掉某个原先想买的商品:1.收银员录入要去掉商品的条码与数量。2.系统更新当前的总销售金额。3-6b.顾客要求收银员取消这次销售:1.收银员取消

12、这次销售交易。3-6c.顾客要求收银员暂停本次销售:1.系统将销售记录下来，而且之后可以在任何POS终端中取回这比销售交易的记录。5a.收银员询问顾客是否享受会员优惠1.顾客享受会员优惠，系统按照打折规则进行交易。2.顾客不享受会员优惠，系统按照商品原价进行交易。用例UC2：收银希望不会发生付款错误的情况。希望获得精准的服务，同时希望付款方式多元化。希望确保记录了支付授权服务的支付票据。-支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。生成票据和记录支付授权。1.收银员告知顾客总额，并请顾客付款。2.顾客付款，系统处理付款。3.系统记录完整的销售信息，并将销售

13、和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。4.系统打印购物票据。5.顾客携带商品和票据离开。3a.现金支付：1.收银员输入收取的现金额。2.系统显示找零金额，并弹出现金抽屉。3.收银员放入收取的现金，并给顾客找零。4.系统记录该现金支付。3b.信用卡支付：1.顾客输入信用卡账户信息。2.系统显示其支付信息以备验证。3.收银员确认。4.系统向外部支付授权服务系统发送支付授权请求，并请求批准该支付。4a.系统检测到与外部系统协作时的故障：1.系统向收银员提示错误。2.收银员请求顾客更换支付方式。5.系统收到批准支付的应答并提示收银员，同时弹出现金抽屉（以便放入签名

14、后的信用卡支付票据）。5a.系统收到拒绝支付的应答：1.系统向收银员提示支付被。6.系统记录信用卡支付信息，其中包括支付批准。7.系统显示信用卡支付的签名机制。8.收银员请求顾客签署信用卡支付，顾客输入签名。9.如果在纸质票据上签名，则收银员将该票据放入现金抽屉并关闭抽屉。4a.打印票据。1.如果系统能够检测到错误，给出提示。2.收银员更换纸张。3.收银员请求打印其他票据。用例UC3：退货希望有准确、快速的输入方式，不会发生付款错误的情况。希望购买后能保证退货。1.顾客提出退货要求。2.收银员接受顾客提供的商品和购物票据，并向经理汇报情况。3.经理根据购物票据对商品进行核查。4.经理录入退货信

15、息。5.系统生成退货单。6.经理根据退货单向顾客返还相应的现金，并打印退货单。3a.核查不通过： 1.购物票据里的商品与实际要求退货的商品不符，经理拒绝顾客退货要求，并返还商品。 2.商品受到售后损坏，不符合退货要求。4a.退货信息录入错误，经理向系统取消退货操作，并重新进行退货操作：6a.打印退货单。 1.如果系统能够检测到错误，给出提示。 2.收银员更换纸张。 3.收银员请求打印其他票据。特殊需求：l大型、平面显示器，触摸式使用界面，在30厘米外能看清上面的字。l能在30秒内相应90%的信用授权。l由于某种原因造成与外部系统（如库存系统）连接出现故障时，希望系统的复原能力比较强。l显示的文

16、字应是国际化语言文字。l能在步骤3-7之间客户华增加企业的业务规则。技术与数据变元表：*a.店长超控需要刷卡（由读卡器读取超控卡）或在键盘上输入授权码。3a.（如果有条码的话）用键盘或条码扫描器输入商品识别码。3b.商品识别码可以是UPC、EAN、JAN、SKU中的任何一种。5a.顾客的会员号可用刷卡读取或在键盘上输入。发生频率：可能会连续不断地发生。2.3 补充性规格说明简介 本文档中描述的是在POS系统需求中除用例以外的所有其他需求。 功能性（这功能有可能是存在于或涉及多个用例中的常见功能）1.系统记录错误的处理方法：要求记录所有系统错误到可永久保存的储存介质中。2.系统可嵌入商业规则：从

17、而在某个特定事件发生时，可以使用某企业自己的商业规则。3.安全性：要求系统所有的使用行为必须是得到授权的。可用性考虑到人的因素，由于顾客希望能看到POS系统显示的内容，所以需要使用大型显示器，以便于顾客在30厘米以外也能看到文字。同时，显示时应该避免使用色盲无法辨别的颜色。另外，为了能及时提醒收银员，不仅要显示文字还需要能够提供声音发出的提示或警告。可靠性1.可恢复性：当系统中断无法和外部系统通信时，利用本地临时解决的可能性。2.性能：希望90以上的交易能在一分钟内完成。可支持性1.可适应性：系统要能根据不同情况，设定相应的商业规则，从而在不同情况下提供不同的服务。2.可配置性：用户够根据自身

18、情况选择系统不同的配置方式，如瘦客户机或胖客户机，两层式系统或多层式系统等。实现约束采用Java技术的解决方案。采用Java技术一般被认为除了易于开发外，还能够提高远期的移植和可支持性能力。购买构件税金计算器。必须支持用于不同国家的可插拔计算器。免费开源构件一般而言，在该项目中我们尽可能地使用免费的Java技术开源构件。如：ssheasyuimaven.接口1.重要硬件和接口触摸屏（触摸动作视为鼠标事件）条形码激光扫描仪（通常附加在一种特殊键盘上，扫描输入在软件中视为键盘输入）。票据打印机信用卡读卡器2.软件接口由于存在外部协作系统，我们需要采用不同的接口，接入不同的系统。所关注领域内的信息1

19、.定价除了定价规则之外，还需要注意，产品有原始价格和可选的常设低标价之分。产品标示的价格（折扣前）是常设低标价。由于财务和税务的原因，即使有常设低标价，也需要维护原始价格。2信用卡支付处理当支付授权服务批准了信用卡支付后，将有支付授权服务来负责对卖方的支付。3.销售税：对税金计算采用第三方软件（税金计算器）计算。4.商品标识：UPC、EAN、SKU、条形码和条形码读取装置。2.4 系统顺序图与操作契约A. 处理销售系统顺序图。B. 操作契约。契约CO1：makeNewSale操作：makeNewSale（）交叉引用：用例：处理销售无创建了Sale的实例s（创建实例） s被关联到Register

20、（形成关联） s的属性被初始化（修改属性）契约CO2:enterItem正在进行中的销售创建了SalesLineItem的实例sli（创建实例） sli被关联到当前Sale（形成关联） sli.quantity赋值为quantity（修改属性） 基于itemID的匹配，sli被关联到ProductDescription（形成关联）契约CO3:enterSaleSale.isComplete被置为真（修改属性）。契约CO4:makePaymentmakePayment（amount:Money）创建了Payment的实例p（创建实例） p.amountTendered被赋值为amount（修改属

21、性） 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包：接收controlle

22、r的业务信息，处理业务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 数据库设计

23、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.以maven project形式导入到Eclipse2.导入数据库文件到mysql数据库3.将项目的配置文件application.pro

24、perties中的信息该为自己数据库信息6 项目总结我们最初对pos机简直是一窍不通，认为只要大家都肯下功夫，都努力做，就可以了。所以一开始时我们商量怎么做，然后大家一起做，但其实等大家商量好后，实际其过程真可谓一波三折。所以总结起来，本次设计过程的失体现在两个方面：第一，技术水平有限，编程上基本上是以程序员为主力军，所以这也给了程序员一定的重担，在学习新的技术的同时又要赶进度，所以出现了在迭代阶段，往往只有文档而代码还没有完成的情况；第二，就是时间把控不好，彼此间都相互依赖对方，要等对方完成了对应的任务才开始自己的任务，就成了一个人在那做，但是其他人在旁边看，这样极大的降低了团队的工作效率。我们意识到这个问题后，仔细的分