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

管理信息系统课程设计管理信息系统课程设计便利店POS系统项目组编号22专业班级12信管 2 班项目组成员黄佳莹201230560206黄晓萍201230560208杨畅达201230560226钟淑娜201230560229文档编制日期2015.6指导教师 邓成剑2MIS课程设计开发文档课程设计成绩评分表（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分使用报表工具，实现分类汇总统计报表使用报表工具，实现简单数据统计报表未使用报表工具，实现列表并能汇总统计35目 录软件开发文档版本更新记录11引言21.1项目设想21.2 开发计划31.3 技术路线42 需求分析52.1业务建模52.2需求规格说明72.3 补充性规格说明72.4 系统顺序图与操作契约193 架构设计213.1功能结构设计213.2 软件架构设计214 详细设计224.1用例实现设计224.1.1 销售开单224.1.2 收银234.1.3 退货244.2输入输出设计254.2.1 表单设计254.2.2 报表设计264.3 数据库设计274.4权限设计275 系统实现275.1 功能实现275.2 系统测试325.2.1 单元测试325.2.2 用例测试335.3 系统部署336 项目总结34文档版本更新记录ContentDateDescriptionAuthor细化迭代一2015-4-02项目设想、开发计划及软件架构设计黄佳莹、杨畅达细化迭代二2015-4-16开单用例模型、补充性规格说明及输入设计黄佳莹、杨畅达细化迭代三2015-4-30收银用例模型、补充性规格说明及相关数据库黄佳莹、杨畅达细化迭代四2015-5-16退货用例模型、补充性规格说明及相关数据库黄佳莹、杨畅达细化迭代五2015-5-29用例实现设计黄佳莹、杨畅达细化迭代六2015-6-13报表设计、功能实现、系统测试及部署杨畅达、黄晓萍项目总结2015-7-01整理文档、总结项目黄佳莹、杨畅达1引言1.1项目设想A. 系统展望。应用场景：本产品主要应用在便利店中的日常销售中，用于监控商品流通。当顾客在便利店购买商品后并进行结账时，收银员只要拿着pos系统的扫描枪对准商品的条形码，即可将商品的编码，价格，购买数量等等信息扫描出来，将顾客所要购买的商品一一扫描完后，此时在pc机上即可显示商品的信息及总共需付账款，客户在付款时，可以选择现金支付，可以选择刷卡支付（pos系统提供密码输入设备，顾客输入银行卡密码也可以实现支付），在支付完成后打印出相关票据给客户。产品用户：主要为便利店收银员、pos系统管理员、便利店店长。系统范围：包括前台软件系统和后台软件系统。前台软件系统（主要为基本收银作业）的主要目的在于管理前台收银系统的各项作业：客户购买明细资料、交易查询作业、查账及结账作业，以避免人为疏忽或错误。其具有的功能如下：（1）销售；（2）付款；（3）即时纠错；（4）退货功能；（5）交班结算。后台软件系统主要包括基本资料管理、库存商品管理、销售系统分析管理及采购进货管理。其具有的功能如下：（1）实现入库管理；（2）商品销售管理；（3）单证票证管理；（4）完善分析功能。基本目标：条形码销售、退货、换货、折扣、取消交易、更改价格、搁置发票等。系统运行稳定，权限设定，保密性强，速度快捷。B. 系统特性。POS机具有直接、及时入账的实时处理能力，即在销售时，商品的各种信息数据处理是在交易的瞬间完成的，销售事务的处理通过POS完成。POS系统通过条码识读设备快速识读商品外包上的条码标识，传输相应的商品信息数据，然后由计算机完成结算，并自动生成账单，简化了收银手续，大大提高了结算速度，从而为顾客提供优质的服务。便利店实施了POS系统后，每售出一件商品，POS系统数据库中就相应地减少该商品的库存记录，从而降低了商品盘点的复杂度，节约了大量人力物力，而及时提供的商品存储信息又可以为经营决策者对商品品种的调运和调整提供可靠的依据，极大地提高了便利店经营质量和管理效率。 1.2 开发计划A. 团队成员。黄佳莹（项目经理、分析员）：制定项目计划，分配任务，监督团队进度；分析业务功能，进行业务建模，描述用例并设计用例实现，撰写相关文档。杨畅达（架构师）：设计软件的体系结构和数据模型，系统功能实现。钟淑娜（程序员）：协助架构师设计项目架构并完善系统功能，绘制相应图表。黄晓萍（测试员）：对系统功能进行测试，找出系统中的错漏，编写测试报告并及时反馈给其他团队成员，协助撰写文档。B. 项目进度。过程时间目标工作内容初始阶段第2周分组定题布置任务，确定分组；确定题目，制定计划。细化迭代13-4周搭建框架确定核心架构实现基础数据增删改查细化迭代25-6周设计实现业务用例实现销售开单用例细化迭代37-8周设计实现业务用例实现收银用例细化迭代49-10设计实现业务用例实现退货用例细化迭代511-12周设计实现权限基于所选技术实现系统权限功能细化迭代613-14周设计实现报表实现数据报表功能交付15周提交成果编程人员实验室演示程序；提交文档打印稿。C. 风险控制。（1）技术风险：可能由于软件开发水平有限，有些系统功能可能无法实现。措施：对于程序员在开发过程中遇到未接触过的技术，可以上网找资料或请教别人边做边学。（2）进度风险：未能在规定的时间内完成任务。措施：由于各种原因，可能出现未能在规定时间内完成任务，那么项目经理应该合理安排团队成员的各自任务并规定任务完成的最后期限，在任务执行期间，经常向团队成员了解任务完成情况及碰到的问题等，协助和督促其按质按量完成任务。（3）团队沟通合作：团队成员沟通不良，合作。措施：新组的团队会经历一个动荡期，可能会出现沟通不良等情况，项目经理要协调团队各成员，并组织团队一起合作，加强沟通，同时各团队成员应加强团队意识，积极融入团队（4）质量风险：开发的产品未能达到任务所要求的质量。措施：在执行任务前，开发团队应仔细了解好所开发的产品所要达到的质量，开发完成后应由测试人员对产品进行测试，如压力测试等等，并将问题反馈给程序员，程序员再根据反馈进行调试，最终达到所要求的质量。（5）性能风险：评价一个系统的性能有很多方面，比如吞吐量、响应时间、并发用户数等等。开发系统时往往可能只注重系统的功能，却没有考虑系统的性能，如并发用户数、系统响应时间等等，但是这些却也是同样重要的，这些将影响用户体验，也是评价一个系统的好坏的指标。措施：在测试时，除测试系统功能外，也要对系统进行性能测试，如负载测试、强度测试、容量测试等。负载测试（LoadTesting）譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等。强度测试（StressTesting）：压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等容量测试（VolumeTesting）：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。根据测试结果，进一步提高系统性能。 1.3 技术路线开发语言：Java，JavaScript计算模式：B/S前端框架：easyUI（版本号：1.3.5）后端框架：spring（版本号：3.2.4.RELEASE）、hibernate（版本号：4.2.6.Final）、struts（版本号：）数据库管理系统：mysql（版本号：5.6.17）前端使用easyUI，因为easyUI适合用来开发curd类型的应用；后端使用spring、hibernate、struts是因为这些框架成熟，用的人多，文档齐全，社区成熟，遇到问题时能快速解决。2 需求分析2.1业务建模A. 业务流程建模。销售活动图（含收银）：退货活动图： B. 领域建模。2.2需求规格说明A. 系统用例图。B. 用例详述文本。UC1：开单与收银范围：便利店POS应用级别：用户目标主要参与者：收银员、顾客涉众及其关注点： 收银员：希望能够准确、快速地输入商品信息，并准确向顾客收取应付金额。 顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望有购买凭证，以作为购买清单和作为退货的凭据。 公司：希望准确地记录交易，满足顾客要求。希望能够自动、快速地更新账务和库存信息。希望系统足够健壮和容错性，当系统出现一些小问题时，也可以完成开单。经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。前置条件：收银员必须经过确认和认证。成功保证（或后置条件）：存储销售信息。准确计算税金。更新账务和库存信息。记录提成。生成票据。记录支付授权的批准。主成功场景：1、顾客携带所购商品或服务到收银台通过POS机付款。2、收银员开始一次新的开单记录。3、收银员输入商品条码。4、系统逐条记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。收银员重复34步，知道输入结束。5、系统显示总额和所计算的税金。6、收银员告知顾客总额，并请顾客付款。7、顾客付款，系统处理支付。8、系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。9、系统打印票据。10、顾客携带商品和票据离开（如果有）。扩展：*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可读（例如，数字型的UPC）： 1、收银员手动输入商品ID。 2、系统显示商品项目的描述和价格。 2a、无效商品ID：系统提示错误。收银员尝试其他方式。 2b、系统内不存在该商品ID，但是该商品附有价签： 1、收银员请求经理执行超控操作。 2、经理执行相应的超控操作。 3、收银员选择手工输入价格，输入价签上的价格，并请求对该价目进行标准计税。（因为没有产品信息，计税引擎无法确定如何计税。） 2c、收银员通过执行寻找产品帮助以获取正确的商品ID及其价格。 2d、另外，收银员可以向其他员工询问商品ID或价格，然后手工输入ID或价格（参见以上内容）。3b、当有多个商品项目属于同一类别的时候（如5瓶可乐），不必记录每个商品项目的唯一标识： 1、收银员可以输入类别的标识和商品的数量。3c、需要手工输入类别和价格（例如，花卉或纸牌及其价格）： 1、收银员手工输入特定的类别代码及其价格。3-5a、顾客要求收银员从所购商品中去掉一项：所去除商品的价格必须小于收银员权限，否则需要经理执行超控操作。 1、收银员输入商品ID并将其删除。 2、系统删除该项目并显示更新后的累计额。 2a、商品价格超过了收银员权限： 1、系统提示错误，并建议经理超控。 2、收银员请求经理超控，完成超控后，重做该操作。3-5b、顾客要求收银员取消销售交易： 1、收银员在系统中取消销售交易。3-5c、收银员延迟销售交易： 1、系统记录销售交易信息，使其能够在任何POS登录中恢复操作。 2、系统显示用来恢复销售交易的“延迟票据”，其中包含商品项目和销售交易ID。4a、系统定义的商品价格不是顾客预期的价格（顾客对此产生抱怨并要求减价）： 1、收银员请求经理批准。 2、经理执行超控操作。 3、收银员手工输入超控后的价格。 4、系统显示新价格。5a、系统检测到与外部税务计算系统服务的通信故障： 1、系统在POS机节点上重启次服务，并继续操作。 1a、系统检测到该服务无法重启。 1、系统提示错误。 2、收银员手工计算和输入税金，或者取消该销售交易。5b、顾客声称他们符合打折条件（例如，是雇员或重要顾客）： 1、收银员提出打折请求。 2、收银员输入顾客ID。 3、系统按照打折规则显示折扣总计。5c、顾客要求兑现账户积分，用于此次销售交易： 1、收银员提交积分请求。 2、收银员输入顾客ID。 3、系统应用积分直到价格为0，同时扣除结余积分。6a、顾客要求现金付款，但所携带现金不足： 1、顾客要求使用其他支付方式。 1a、顾客要求取消此次销售交易，收银员在系统上取消该销售交易。7a、现金支付： 1、收银员输入收取的现金额。 2、系统显示找零金额，并弹出现金抽屉。 3、收银员放入收取的现金，并给顾客找零。 4、系统记录改现金支付。7b、信用卡支付： 1、顾客输入信用卡账户信息。 2、系统显示其支付信息以备验证。 3、收银员确认。 3a、收银员取消付款步骤。 1、系统回复到“商品输入”模式。 4、系统向外部支付授权服务系统发送支付授权请求，并请求批准该支付。 4a、系统检测到与外部系统协作时的故障： 1、系统向收银员提示错误。 2、收银员请求顾客更换支付方式。 5、系统受到批准支付的应答并提示收银员，同时弹出现金抽屉（以便放入签名后的信用卡支付票据）。 5a、系统受到拒绝支付的应答： 1、系统向收银员提示支付被拒绝。 2、收银员请求顾客更换支付方式。 5b、应答超时。 1、系统提示收银员应答超时。 2、收银员重试，或者请求顾客更换支付方式。 6、系统记录信用卡支付信息，其中包括支付批准。 7、系统显示信用卡支付的签名输入机制。 8、收银员请求顾客签署信用卡支付。顾客输入签名。 9、如果在纸质票据上签名，则收银员将改票据放入现金抽屉并关闭抽屉。7c、收银员取消支付步骤： 1、系统回到“商品输入”模式。7d、顾客出示优惠券： 1、在处理支付之前，收银员记录每张优惠券，系统扣除相应金额。系统记录已使用的优惠券以备账务处理之用。 1a、输入的优惠券不适用于所购商品： 1、系统向收银员提示错误。9a、存在产品回扣： 1、系统对每个具有回扣的商品给出回扣表单和票据。9b、顾客索要赠品票据（不显示价格）： 1、收银员请求赠品票据，系统给出赠品票据。9c、打印票据。 1、如果系统能够检测到错误，给出提示。 2、收银员更换纸张。 3、收银员请求打印其他票据。特殊需求：使用大尺寸平面显示器触摸屏UI。文本信息可见距离为1米。90%的信用卡授权响应时间小于30秒。由于某些原因，我们希望在访问远程服务失败的情况下具有比较强的恢复能力。支持文本显示的语言国际化。在步骤3和步骤7中能够加入可插拔的业务规则。技术与数据变元表：*a.经理超控需要在键盘上输入授权码。3a.商品ID可以用条码扫描枪或键盘输入。3b.商品ID可以使用UPC、EAN、JAN或SKU等任何一种编码方式。7a.信用卡账户信息可以用读卡器或键盘输入。7b.记录在纸质票据上的信用卡支付签名。发生频率：可能会不断地发生。未解决问题：税法如何变化？研究远程服务的恢复问题。针对不同的业务需求怎样进行定制？收银员是否必须在从系统注销后带走他们的现金抽屉？顾客是否可以直接使用读卡器，还是必须由收银员完成？UC2：退货范围：便利店POS应用级别：用户目标主要参与者：收银员、顾客涉众及其关注点：收银员：希望能够准确、快速地帮助顾客退换商品。顾客：希望以最小代价完成退货活动并得到快速服务。希望便捷、清晰地看到所退换货品的商品项目和价格。希望有退货凭证。公司：希望准确地记录交易，满足顾客要求。希望能够自动、快速地更新账务和库存信息。希望系统足够健壮和容错性，当系统出现一些小问题时，也可以完成收银。经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。前置条件：收银员必须经过确认和认证。成功保证（或后置条件）：存储退货信息。准确计算税金。更新账务和库存信息。记录提成。生成票据。记录支付授权的批准。主成功场景：1、顾客携带要退换的货品到服务台出提出退货要求，服务台值班员根据顾客提供的购物小票等购物凭证，检查顾客所退商品是否符合商品退货原则。2、服务台值班员确定处理方式，并填写顾客退货申请单，办理退货手续并将手续完备的退货申请单交收银员处理。3、收银员输入顾客退回商品的条码。4、系统逐条记录顾客退回的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。收银员重复34步，直到输入结束。5、系统显示总额和所计算的税金。6、收银员打印退货凭证，值班员在凭证上签名后交给收银员，并进行收、付退换货款处理（收银员退给顾客货款)。7、系统记录完整的退货信息，并将退货和支付信息发送到外部的账务系统（进行账务处理）和库存系统（更新库存）。8、顾客携带商品和退货凭证离开（如果有）。扩展：*a、经理在任意时刻要求进行超控操作： 1、系统进入经理授权模式、 2、经理或收银员执行某一经理模式的操作。 3、系统回复到收银员授权模式。*b、系统在任意时刻失败： 为了支持恢复和更正账务处理，要保证所有交易的敏感状态和事件都能够从场景的任何一步中完全恢复。 1、收银员重启系统，登录，请求恢复上次状态。 2、系统重建上次状态。 2a、系统在恢复过程中检测到异常： 1、系统向收银员提示错误，记录次错误，并进入一个初始状态。 2、收银员开始一次新的退货交易。1a、客户或经理需要恢复一个中断的退货交易。 1、收银员执行恢复操作，并且输入ID以提取相应的退货交易。 2、系统显示被恢复的退货交易状态及其小计。 2a、未发现对应的退货交易。 1、系统向收银员提示错误。 2、收银员可能会开始一个新退货交易，并重新输入所有商品。 3、收银员继续该次退货交易（可能要输入更多的商品或处理支付）。1a、服务台值班员不能确认该商品是否符合退换货原则，可通知商品部门主管到服务台协助判断。1b、顾客无电脑小票或发票但能提供其他证明（如：公司标价签、公司商品条码、发票复印件等）的，退换货须经前台经理或以上人员审核，在退换申请单上签字同意后，交服务台受理。服务台审核后退换货申请单后，办理退换货手续。3a、无效商品ID（在系统中未发现）： 1、系统提示错误并拒绝输入该ID。 2、收银员响应该错误。 2a、商品ID可读（例如，数字型的UPC）： 1、收银员手动输入商品ID。 2、系统显示商品项目的描述和价格。 2a、无效商品ID：系统提示错误。收银员尝试其他方式。 2b、系统内不存在该商品ID，但是该商品附有价签： 1、收银员请求经理执行超控操作。 2、经理执行相应的超控操作。 3、收银员选择手工输入价格，输入价签上的价格，并请求对该价目进行标准计税。（因为没有产品信息，计税引擎无法确定如何计税。） 2c、收银员通过执行寻找产品帮助以获取正确的商品ID及其价格。 2d、另外，收银员可以向其他员工询问商品ID或价格，然后手工输入ID或价格（参见以上内容）。3b、当有多个商品项目属于同一类别的时候（如5瓶可乐），不必记录每个商品项目的唯一标识： 1、收银员可以输入类别的标识和商品的数量。3c、需要手工输入类别和价格（例如，花卉或纸牌及其价格）： 1、收银员手工输入特定的类别代码及其价格。3-5a、顾客要求收银员取消退货交易： 1、收银员在系统中取消退货交易。3-5b、收银员延迟退货交易： 1、系统记录退货交易信息，使其能够在任何POS登录中恢复操作。 2、系统显示用来恢复退货交易的“延迟票据”，其中包含商品项目和退货交易ID。3-5c、顾客要求退换新的商品： 1、收银员验证顾客电脑小票上需换商品与顾客挑选的新商品是否是同条码商品。 1a、如顾客挑选的新商品与需换商品条码相符，收银员在顾客电脑小票的所换商品上注明“已换新”和更新日期并签字，将电脑小票和商品交给顾客。 1b、如顾客挑选的新商品与需换商品条码不符： 1、收银员可建议顾客对新换商品先行买单，之后顾客可凭新购商品的电脑小票及原需换商品的电脑小票，到服务台对原需商品办理退货手续，转至步骤1。 2、如顾客不同意对新换商品先行买单，收银员应要求顾客将商品留存收银台，并将新商品条码抄于小票背面并签字，请顾客到服务台办理收、付差价手续。 6a、付款： 1、在发生商品退货情况下，收银员应遵循以下办理退款手续： 1a、现金购物退货： 1、由收银员直接支付现金给顾客。 1b、退货凭证购物退货： 1、50元以内（含50元）由收银员支付现金给顾客。 2、50元以上由收银员向经理请示，转至步骤*a。 1c、银行卡购物退货： 1、退货金额在相关金融机构规定限额（1000元）以内的（含限定金额），由外部支付授权服务系统确认已到账后通知收银员直接支付现金给顾客。 2、超出限额（1000元）的，由收银员向经理请示，转至步骤*a。特殊需求：与用例“开单与收银”相同技术与数据变元表：与用例“开单与收银”相同2.3 补充性规格说明UC1：开单与收银1、功能性日志和错误处理在持久性存储中记录所有错误。可插拨规则在几个用例的不同场景点执行任意一组规则，以支持对系统功能的定制。安全性任何使用都需要经过用户认证。国际化支持文本显示的语言国际化，以便于处理与外国顾客的交易。正确性系统能正确结算顾客应付的金额，不能算少或算多2、可用性顾客能够看到POS大屏幕显示器的显示。因此：应该在1米外轻松看到文本。避免使用一般色盲人群难以辨认的颜色。快捷、无错的销售交易处理极为重要，因为购买者希望快速离开，否则会给他们的购买体验（和对销售员的评价）带来负面影响。收银员的视线通常停留在顾客或商品，而不是计算机显示器上。因此，提示和警告应该通过声音传递而不仅仅是通过图像传递。3、可靠性可恢复性如果在使用外部服务时出现错误，为了完成销售交易，需要尝试采用本地方案（如存储和转发）加以解决。性能购买者希望非常快速地完成销售处理过程。目标是在90%情况下，能够在1分钟之内完成授权。4、可支持性可适应性不同客户在处理销售时有其特有的业务规则和处理需求。因此，在场景中的几个预订之处（例如，当添加新的商品时），需要能够启用可插拨的业务规则。可配置性不同的客户对其POS系统有不同的网络配置需求，例如，采用两层或多层物理结构等。此外，他们还要求具备修改配置的能力，以便适应其变更业务和性能的需求。因此，系统应该具备一定的可配置能力以适应这些需求。对此需要进一步分析，以发现哪些地方需要灵活性和灵活性的程度，以及实现这种灵活性所需的工作。5.健壮性系统对于规范要求以外的输入情况的处理能力强。当用户对系统的操作不规范时，系统能够识别这些操作，并且能有效合理的处理。6、接口重要硬件和接口（1）触摸屏（操作系统将此视为普通监视器，且触摸动作也视为鼠标事件）。（2）条形码激光扫描仪（通常附加在一种特殊键盘上，扫描输入在软件中视为键盘输入）。（3）票据打印机。软件接口由于存在众多外部协作系统（税金计算器等），我们需要采用不同的接口，接入不停的系统。7、法律问题法律规定，在销售交易中必须遵从所以税务规则。同时，这些规则可以频繁变更。8、注领域内的信息定价产品有原始价格和可选的常设低标价之分。产品标示的价格（折扣前）是常设低标价。由于账务和税务的原因，即使有常设低标价，也需要维护原始价格。信用卡支付处理当支付授权服务批准了信用卡支付后，将由支付授权服务而不是买方来负责对卖方的支付。因此，对于每笔支付，卖方都需要将授权服务的未付金额记录于其应收账户下。通常，授权服务在每晚执行电子转账操作，将卖方当天的应收总额转入其账户下，同时对每笔交易扣除（少量的）服务费。UC2：退货与前面UC1和UC2的补充性规格说明相同，另增加下面的补充性说明1、可用性销售经理能尽快找到退货商品。快捷、无错的退货处理极为重要，因为购买者希望快速离开，否则会给他们的购买体验（和对经理的评价）带来负面影响。2、所关注领域内的信息当退货完成后，退货商品金额可以根据客户要求退还现金或经过第三方退款。2.4 系统顺序图与操作契约A. 系统顺序图。B. 操作契约。契约CO1：makeNewSale操作： makeNewSale()交叉引用： 用例：处理销售前置条件：无后置条件：创建了Sale的实例s（创建实例）。 s被关联到Register（形成关联）。 s的属性被初始化（修改属性）。契约CO2：enterItem操作： enterItem(id:Id,quantity:int)交叉引用： 用例：处理销售前置条件：正在进行中的销售后置条件：创建了SaleOrder的实例saleOrder（创建实例）。 saleOrder被关联到当前Sale（形成关联）。 saleOrder.quantity赋值为quantity（修改属性）。 基于id的匹配，saleOrder被关联到description（形成关联）。契约CO3：endSale操作： endSale()交叉引用： 用例：处理销售前置条件：正在进行中的销售后置条件：Sale.isComplete被置为真（修改属性）。契约CO4：makePayment操作： makePayment(amount: Money)交叉引用： 用例：处理销售前置条件：正在进行中的销售后置条件：创建了Payment的 实例p（创建实例）。 p.amountTendered被赋值为amount（修改属性）。 p被关联到当前的Sale（形成关联）。 当前的Sale被关联到Store（形成关联）（将其加入到完成销售的历史日志中）。3 架构设计3.1功能结构设计3.2 软件架构设计A. 软件分层。（1）Action层。处理用户的请求，并将结果返回给用户。（2）Service层。将Action层对Service层的调用转化为对DAO层的调用。（3）DAO层。对数据库进行操作。B. 命名规范。局部变量的命名：命名最前面加“_”;接口的实现在后面加“Impl”；类名的命名：骆驼命名法，每个单词首字母大写；方法名的命名：小骆驼命名法，第一个字母小写，其余每个单词首字母大写； Service层后面加“Service”，Dao层后面加“Dao”，Action层后面加“Action”。C. 架构相关设计模式。 MVC即model，view，controller。前端页面（view）的请求发给Action层（controller）处理，为了防止Action层直接操作数据库，Service层（model）将Action层传来的请求传给Dao层，Dao层操作数据库。4 详细设计4.1用例实现设计4.1.1 销售开单和收银A. 设计类图。B. 交互图。4.1.2 收银A. 设计类图。B. 交互图。4.1.3 退货A. 设计类图。B. 交互图。4.2输入输出设计 4.2.1 表单设计本来打算把界面做成下面这样子： 但由于工作量太大，只能把界面做成这样子：输入设计为：输入客户编号，商品编号和数量，便得出总的价钱。当收银员输入的商品数量超过该商品的库存时，弹出提示框提示出错；当输入客户编号或商品编号不存在时，弹出提示框提示出错。4.2.2 报表设计月销售报表：产品类销售报表：报表前端使用easyui的datagrid实现，后台使用sql查询数据并返回结果，使用json传输数据。4.3 数据库设计该项目的E-R图如上，可以看出该项目最重要的表是saleorder表，其中saleorder与payment为(1:1)，saleorder与customer为（1:1），saleorder与saleorderitem为（1：n），saleorderitem与product为（1:1），product与producttype为（n:1），退货表salereturn与saleorder为（1:1），salereturn与salereturnitem为（1：n），salereturnitem与saleorderitem为（1:1）。4.4权限设计 由于能力有限，所以该功能尚未实