服装连锁店POS收费系统管理信息系统课程设计24组--MIS课程设计报告.doc

管理信息系统课程设计管理信息系统课程设计服装连锁店POS收费系统项目组编号24专业班级12信管2班项目组成员徐望龙201230560225岳晓琳201230560228钟霞萍201230560230庄祥鹏201230560231文档编制日期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分使用报表工具，实现分类汇总统计报表使用报表工具，实现简单数据统计报表未使用报表工具，实现列表并能汇总统计31目 录软件开发文档版本更新记录11引言21.1项目设想21.2 开发计划31.3 技术路线42.1业务建模42.2需求规格说明72.3 补充性规格说明122.4 系统顺序图与操作契约143 架构设计173.1功能结构设计173.2 软件架构设计174 详细设计194.1用例实现设计194.1.1 销售开单和收银194.1.2收银194.1.3 退货204.2输入输出设计214.2.1 表单设计214.2.2 报表设计214.3 数据库设计224.4权限设计245 系统实现255.1 功能实现255.2 系统测试285.2.1 单元测试285.2.2 用例测试295.3 系统部署306 项目总结30软件开发文档版本更新记录ContentDateDescriptionAuthor细化迭代14月1日搭建框架（1.1、1.2 、3.2） 钟霞萍、庄祥鹏细化迭代24月16日实现开单用例（2.2、2.3、4.2中的UC1）钟霞萍、庄祥鹏细化迭代34月30日实现收银用例（2.2、2.3、4.2中的UC2、4.3）钟霞萍、庄祥鹏细化迭代45月14日实现退货用例（2.2、2.3、4.2中的UC3、4.3）钟霞萍、庄祥鹏细化迭代55月28日实现权限（4.1、4.4）钟霞萍、庄祥鹏细化迭代66月11日实现报表(4.2.2、5.1、5.2、6)钟霞萍、庄祥鹏项目整合总结6月30日文档汇总、修改、整理（all）钟霞萍、庄祥鹏1引言1.1项目设想A. 系统展望：服装连锁店POS收费系统，是一个用于记录销售和处理支付的计算机系统，系统包括硬件（计算机和条形码扫描仪等）和软件。主要应用场景有：（1）客户携带商品到收银台，收银员将商品逐一输入系统，系统计算应付金额（包括折扣计算）。输入完成后客户付款，收银员确认收款并找零，系统打印购物小票。（2）客户携带购物小票和商品办理退货业务，店员根据退货规则系统完成操作。（3）店员查询商品库存。（4）店员录入会员信息。（5）经理使用系统制作销售报表。（6）经理对店员的增删、信息编辑和权限设置。针对的用户有：客户（普通客户、会员），店员，经理系统范围: Pos应用基本目标：经理可对系统进行管理，经理和店员可对产品和客户的基础数据进行管理，可进行商品销售管理、查询和制作报表。B. 系统特性：1. 系统管理（1）系统使用人员的增删改查；（2）系统使用人员的权限设置；2. 基础数据（1）产品类别的增删改查；（2）产品信息的增删改查；（3）客户信息的增删改查；3. 销售管理（1） 生成销售订单：录入（/ 删除）商品条目、计算支付金额；（2 ）录入销售订单：收银、系统录入订单数据、修改库存、打印小票；（3） 退货：选择订单、选择商品、生成退货单、退款、系统录入退货单数据、修改库存；4. 查询（1）按商品型号或名称查找某商品的信息及库存数；（2）按客户和销售时间查询订单；5. 统计报表（1） 统计每日/月/季销售总金额 (数字报表)；（2）按“产品类别”统计“起止时间”内销售数量和金额（数字报表）；1.2 开发计划A. 团队成员项目经理庄祥鹏：项目进度控制分析员钟霞萍：完成分析文档（项目设想、需求分析、分析设计权限&报表等）；架构师庄祥鹏：架构设计、功能实现程序员徐望龙：功能实现测试员岳晓琳：测试工作，参与文档撰写。B. 项目进度项目进度安排：第2周确定题目并制定计划，从第3周开始每两周一个细化迭代，其中单周周三分析员和测试员讨论并确定本周的需求分析，生成文档；单周周四至双周周二，架构师和程序员讨论并实现功能；双周周三测试员测试功能并反馈结果给架构师程序员修改，周四提交代码。第15周交付。控制措施：互相督促，每次迭代计划比最迟交付时间提前一天，项目经理按时验收各成员工作成果。C. 风险控制项目风险主要有：市场风险：项目最终形成的产品能否满足市场的需求，成为适销对路、满足用户需求的的产品。生产风险：在项目生产阶段，技术知识、选用模型和实现方法的风险完工风险：项目能否在预计时间内完成的风险。控制措施：（1）在项目风险潜在阶段，预先采取措施对项目进程和后果进行适当控制和管理，规避风险的发生。例如：还有一天到预定完成时刻，但完成度很低时，需要督促、赶工。（2）在项目风险发生阶段，立刻积极地解决风险引发的问题，降低风险。例如周五仍未完成本次迭代，周六为检查时间，则拼命赶工、甚至通宵。（3）在项目风险后果阶段，消减风险后果。例如最后阶段，设计的附加功能无法完成或如预期运行，更改降低实现的方法的难度，甚至去除该功能。1.3 技术路线采用MVC模式划分各层，每一层所担任的职责都划分清楚，并尽量采用高内聚，低耦合的原则。后台：考虑到对语言的熟练程度和项目所需的时间，本项目使用JavaEE经典的三大框架Spring3.2.4+Hibernate4.2.6+Struts2.3，运用全注解从而减少配置文件，同时使用Maven仓库进行包的控制前端：使用JQuery easyui 框架2，方便对数据进行展示。使用Struts，Spring和hibernate实现MVC模式和DAO设计模式，从下到上分别为（1） 数据库：存储数据，考虑到系统的要求以及数据量，选用了灵活的数据库MYSQL。 （2） VO层：每一个实体类映射一张数据库表，对实体类的操作相当于对数据库中表的操作。（3）DAO层：实现对VO层实体类的基本操作，提供接口和实现类， 创建基本的CRUD实体操作泛型接口和泛型接口实现类，实现基本的数据操作；创建复杂的泛型接口和泛型实现类，实现一些较复杂的操作，如分页显示，复杂的查询功能。对于个别需要较复杂的单独操作的VO，单独为其创建接口和实现类，接口继承第二步中的泛型接口，实现类继承第二部中的泛型接口实现类。（4）Service层：在DAO层之上，实现逻辑处理，并提供接口和实现类共Action层使用，Service的设计和DAO层类似，也是创建基本的基于基本DAO类的CRUD实体操作泛型接口和泛型类。一些较复杂的操作可另外定义单独的接口和实现类继承基本的泛型接口和实现类。（5）Action层：实现跳转和数据传输。（6）View层：页面展示。 其中从VO到View，使用全注解，并利用Spring自动装载，实现解耦和资源管理。2.1业务建模A. 业务流程建模。销售业务活动图（含收银）:退货业务活动图:涉众：客户、店员业务规则：ID规则可变性来源规则1购买者折扣规则。如：员工：15%折扣额；会员级顾客：10%折扣额；高每个零售商有不同规则零售商政策规则2销售（交易级）折扣规则，适用于税前总额，例：全场购满300减30；高每个零售商有不同规则零售商政策规则3销售（商品级）折扣规则，适用于税前总额，例：新品不打折；换季商品20-30%折扣额；高每个零售商有不同规则零售商政策使用到的单据：收款票据，内容包括：店名，店铺地址，开单时间，店员号，商品名，商品单价，商品折扣，商品规格，商品数量，应收金额，实收金额，找零金额等 B. 领域建模。2.2需求规格说明A. 系统用例图B. 用例详述文本。用例UC1：开单范围：POS应用级别：用户目标主要参与者：收银员涉众及其关注点：-收银员：希望能够精准、快速的输入货品信息。希望能够快速的选择折扣权限。-顾客：希望得到快速的服务。希望便捷、清晰地看到所输入的商品项目和价格。前置条件：收银员必须经过确认和认证成功保证：建立新的销售单，准确输入商品信息，准确计算税金，准确计算商品总价。主成功场景：1、顾客携带所购商品到收银台通过POS机付款。2、收银员开始一次新的销售交易。3、收银员输入商品条码。4、系统逐条记录出售的商品，并显示该商品的描述、价格和累计额。收银员重复34步，直到输入结束。5、收银员选择客户可享受的折扣。6、系统显示总价。扩展：*a.店长在任意时刻要求进行超控操作：1. 系统进入店长授权模式2. 店长执行某一店长模式的操作。如，回复其他登录者中断的销售交易，取消销售交易等。3. 系统回复到收银员授权模式。*b.系统在任意时刻失败：1. 收银员重启系统，登录，请求恢复上次状态。2. 系统重建上次状态2a.系统在恢复过程中检测到异常：1. 系统向收银员提示错误，记录此错误，并进入一个初始状态。2. 收银员开始一次新的销售交易。1a.客户或店长需要恢复一个中断的销售交易。1. 收银员执行恢复操作，并且输入ID以提取对应的销售记录。2. 系统显示被恢复的销售交易状态及其小计。2a.未发现对应的销售记录。1、 系统向收银员提示错误2、 收银员可能会开始一个新销售交易，并重新输入所有商品。3. 收银员继续该次销售交易。3a.无效商品ID：1、 系统提示错误并拒绝输入该ID。2、 收银员响应该错误。2a.商品ID可读（例如通用产品代码）：1. 收银员手工输入商品ID。2. 系统显示商品项目的描述和价格。2a.无效商品ID：系统提示错误。收银员尝试其他方法。2b.系统内不存在该商品ID，但是该商品附有价签：1、 收银员请求店长执行超控操作。2、 店长执行相应的超控操作。3、 收银员选择手工输入价格，输入价签上的价格，并且请求对该价目进行标准计税。2c.收银员通过执行寻找产品帮助以获取正确的商品ID及其价格。2d.收银员可向其他员工询问商品ID或价格，然后手工输入ID或价格。3b.当有多个商品项目属于同一类别的时候（如2件相同的上衣），不必记录每个商品项目的唯一标识：1、 收银员可以输入类别的标识和商品的数量。3-6a.顾客要求收银员从所购商品中去掉一项：1、 收银员输入商品ID并将其删除。2、 系统删除该项目并显示更新后的累计额。3-6b.顾客要求收银员取消销售交易1、 收银员在系统中取消销售交易。3-6c.收银员延迟销售交易1、 系统记录销售交易信息，使其能够在任何POS登录中恢复操作。2、 系统显示用来恢复销售交易的“延迟票据”，其中包含商品项目和销售交易ID。5a.系统检测到与外部税务计算系统服务的通信障碍：1、 系统在POS机节点上重启此服务，并继续操作。1a.系统检测到该服务无法重启。1、 系统提示错误。2、 收银员手工计算和输入税金，或者取消该销售交易。5b.顾客符合打折条件：1、 顾客是会员：1、 输入顾客会员卡号。2、 系统按照打折规则显示折扣总计。2、顾客符合当季打折要求。1. 收银员选择折扣种类。2. 系统按照打折规则显示折扣总计。特殊需求：l 使用大尺寸平面显示器触摸屏UI。文本信息课件距离为1米。l 在访问远程服务失败的情况下具有比较强的恢复功能。l 支持文本显示的语言国际化。技术与数据变元表：*a.店长超控需要刷卡（由读卡器读取超控卡）或在键盘上输入授权码。3a.商品ID可以用条码扫描器或键盘输入。3b.商品ID可以使用UPC、EAN、JAN或SKU等任何一种编码方式。5a.顾客的会员号可用刷卡读取或在键盘上输入。发生频率：可能会不断地发生。用例UC2：收银范例：POS应用级别：用户目标主要参与者：收银员涉众及其关注点：-收银员：希望能准确快速的收款。-顾客：希望能准确快速的付款，希望得到购买凭证，以便退货。-希望确保记录了支付授权服务的支付票据。希望能自动、快速的更新账务和库存信息。-政府税收代理：希望能从每笔交易中抽取税金。-支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。前置条件：收银员必须经过确认和认证。成功保证：生成票据。记录支付授权的批准。主成功场景：1、 收银员告知顾客总额，并请顾客付款。2、 顾客付款，系统处理支付。3、 系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理）和库存系统（更新库存）。4、 系统打印票据。5、 顾客携带商品和票据离开。扩展：1a.顾客要求现金付款，但所携带的现金不足:1、 顾客要求使用其他支付方式。1a.顾客要求取消此次销售交易，收银员在系统上取消该销售交易。2a.现金支付：1、 收银员输入收取的现金额。2、 系统显示找零金额，并弹出现金抽屉。3、 收银员放入收取的现金，并给顾客找零。4、 系统记录该现金支付。2b.信用卡支付：1、 顾客输入信用卡账户信息。2、 系统显示其支付信息以备验证。3、 收银员确认。4、 系统向外部支付授权服务系统发送支付授权请求，并请求批准该支付。4a.系统检测到与外部系统协作时的故障：1、 系统向收银员提示错误。2、 收银员请求顾客更换支付方式。5、 系统收到批准支付的应答并提示收银员，同时弹出现金抽屉，放入签名后的信用卡支付票据。5a.系统收到拒绝支付的应答：1、 系统向收银员提示支付被拒绝。2、 收银员请求顾客更换支付方式。 5b.应答超时。1、 系统提示收银员应答超时。2、 收银员重试，或者请求顾客更换支付方式。6、 系统记录信用卡支付信息，其中包括支付批准。7、 系统显示信用卡支付的签名输入机制。8、 收银员请求顾客签署信用卡支付。将签名后的信用卡支付票据放入现金抽屉并关闭抽屉。2c.收银员取消支付步骤：1、 系统回到“商品输入”模式。4a.打印票据。1、 如果系统能够检测到错误，给出提示。2、 收银员更换纸张。3、 收银员请求打印其他票据。特殊需求：l 90%的信用卡授权响应时间小于30秒。技术与数据变元表：2a.信用卡账户信息应用读卡器输入。用例UC3：退货范例：POS应用级别：用户目标主要参与者：收银员涉众及其关注点：-收银员：希望有准确、快速的完成退款，不会发生退款错误的情况。-顾客：希望能退货并取回相应退款，井获得快速的服务。-公司：希望能够准确地记录交易，满足顾客要求。希望确保记录了退货情况和支付授权服务的支付票据。-经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。-支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。前置条件：收银员必须通过确认和认证，购物小票经过确认，货品也检查无误。后置条件：存储退货信息。准确计算退货总额。更新财务和库存信息。更改销售量。生成相应退票票据和记录支付授权。主成功场景：1.顾客携带退货物品和购物当次小票到收银台退货，提出退货要求。2.收银员接受顾客提供的商品和购物票据，并进行核查。4.核查后录入销售单号，并选择退货商品。5.系统显示退货总额，收银员提交退货申请。6.系统接受退货申请，修改库存和登记订单。7.收银员收回商品并根据退货单向顾客返还相应的现金，并打印退货单。扩展：*a.经理在任意时刻要求进行超控操作： 1.系统进入经理授权模式。 2.经理或收银员执行某一经理模式的操作。 3.系统恢复到收银员授权模式。*b .系统在任意时刻失败：为了支持恢复处理，要保证所有交易的敏感状态和事件都能够从场景的任何一步中完全恢复。3a.核查不通过：1.退货商品已过退货期。2.购物票据里的商品与实际要求退货的商品不符，拒绝顾客退货要求。3.商品受到售后损坏，不符合退货要求。4a.退货信息录入错误，经理向系统取消退货操作，并重新进行退货操作：6a.打印退货单。1.如果系统能够检测到错误，给出提示。2.收银员更换纸张。3.收银员请求打印其他票据。2.3 补充性规格说明功能性1、日志和错误处理在持久性存储中记录所有错误。2、可插拔规则在几个用例的不同场景点执行任意一组规则，以支持对系统功能的定制。3、安全性任何使用都需要经过用户认证。可用性1、店员能够看到POS屏幕显示器的显示：在1米外能够轻松的看到显示器上的文本。避免使用一般色盲人群难以辨认的颜色。2、快捷、准确的销售交易处理及其重要，因为购买者希望快速结束支付过程，否则会给他们的购买体验带来负面影响。3、店员的视线通常停留在顾客或商品，而不是计算机显示器上，因此，提示和告警应该通过声音传递而不仅仅是通过图像传递。可靠性1、可恢复性如果在使用外部服务（支付授权、账务系统等）时出现错误，为了完成销售交易，需要尝试才用本地方案（如存储和转发）加以解决。2、性能购买者希望非常快速的完成销售处理过程，因此，外部的支付授权是瓶颈之一，我们的目标是：90%的情况下，能够在1分钟之内完成授权。3、数据备份系统支持定时或实时的对数据进行备份，避免数据的破坏或者丢失，如处理销售交易过程中，系统出现闪退或者奔溃情况下导致的数据丢失或者需要重新录入。可支持性1、可适应性不同客户在处理销售时有其特有的业务规则和处理需求。因此，在场景中的几个预定之处（如开始新的销售交易时，增加新的商品时），需要能够启用可插拔的业务规则。2、可配置性系统具备一定的可配置能力以适应该店对其POS系统的不同的网络配置需求。实现约束使用的程序设计语言为java，其具备易于开发，能够提高远期的移植和可支持性能力。购买构件税金计算器，必须支持用于不同国家的可插拔计算器。免费开源构件尽可能的使用免费的java 技术开源构件，如：Maveneasyuisshjqueryjeecg接口1、重要硬件和接口显示屏（显示POS系统）。条形码激光扫描仪（通常附加在一种特殊键盘上，扫描输入在软件中视为键盘输入）。票据打印机信用卡、借记卡读卡器2、软件接口由于存在众多外部协作系统，如税金计算器，账务，库存等，我们需要采用不同的接口，接入不同的系统。所关注领域内的信息1、信用卡和借记卡支付处理当支付授权服务批准了信用卡或借记卡支付后，将由支付授权服务而不是买方来负责对卖方的支付。因此，对于每笔支付，卖方都需要将授权服务的未付金额记录于其应收账户下。通常，授权服务在每晚执行电子转账操作，将卖方当天的应收总额转入其账户下，同时对每笔交易扣除（少量的）服务费。2、销售税对税金计算采用税金计算器计算。3、商品标识：UPC、EAN、SKU、条形码和条形码读取装置UPC、EAN、SKU是常用的三种商品销售标识系统2.4 系统顺序图与操作契约A. 系统顺序图（开单收银）B. 操作契约。契约CO1：makeNewSale操作：makeNewSale()交叉引用：用例：开单前置条件：无后置条件：创建了Sale的实例s（创建实例） s被关联到Register（形成关联） s的属性被初始化（修改属性）契约CO2：enterItem操作：enterItem (itemID:ItemID,quantity:integer)交叉引用：用例：开单前置条件：正在进行中的销售后置条件：创建了SalesLineItem的实例sli（创建实例） sli被关联到当前Sale（形成关联） sli.quantity的赋值为quantity（修改属性） 基于itemID的匹配，sli被关联到productDescription（形成关联）契约CO3：enterSale操作：enterSale( )交叉引用：用例：收银前置条件：正在进行中的销售后置条件：Sales.isComplete被置为真（修改属性）。契约CO4：enterItem操作：makePayment(amount:Money)交叉引用：用例：开银前置条件：正在进行中的销售后置条件：创建了Payment的实例p（创建实例） p.amountTendered被赋值为amount p被关联到当前Sale（形成关联） 当前的sale被关联到Store（形成关联）(将其加入到完成销售的历史日志中)契约CO5：isExitEntity（）交叉引用：用例：退货前置条件：正在进行中的销售后置条件：saleOrderService.isExitEntity值修改为正契约CO6：loadEntityByKey交叉引用：用例：退货前置条件：正在进行中的销售后置条件：创建了SaleOrder的实例saleOrder与SaleOrderItem实例集合List。 SaleOrderItem被关联到SaleOrder。契约CO7：saleReturn交叉引用：用例：退货前置条件：正在进行中的退货处理后置条件：更新了订单saleOrder.total属性，更新了saleOrderItem集合中item.price和item.quantity属性,创建了新的saleReturnItem3 架构设计3.1功能结构设计系统功能结构图：服装店POS收费系统系统管理数据管理销售管理其他功能系统用户的增删改查系统用户的权限设置基础数据的增删改查开单收银退货统计报表查询3.2 软件架构设计软件架构文档(SAD)描述了软件类的宏观组织结构。A. 软件分层。使用UML包图描述软件的层次划分。用文字简要说明每个包的具体作用；B. 命名规范（1）DAO层的设计： 创建基本的CRUD实体操作泛型接口和泛型接口实现类，实现基本的数据操作；创建复杂的泛型接口和泛型实现类，实现一些较复杂的操作，如分页显示，复杂的查询功能。对于个别需要较复杂的单独操作的VO，单独为其创建接口和实现类，接口继承第二步中的泛型接口，实现类继承第二部中的泛型接口实现类。（2）Service层的设计： Service的设计和DAO层类似，也是创建基本的基于基本DAO类的CRUD实体操作泛型接口和泛型类。一些较复杂的操作可另外定义单独的接口和实现类继承基本的泛型接口和实现类，（3）命名规范： 使用驼峰法，英文命名，做到尽量简洁明了，一目了然。 VO层的命名，实体类的命名，如产品和产品类别，分别为Product.java和ProductCategory.java，且注明数据库中表的命名，一个单词（如Product）的直接为product；两个或两个单词以上的（ProductCategory）的，中间使用下划线（_）间隔，即product_category。 DAO层的命名，接口为XxxDao.java，实现类为XxxDaoImpl.java。例如Product.java，接口命名为ProductDao.java，实现类命名为ProductDaoImpl.java。 Service层的命名，接口为XxxService.java，实现类为XxxServiceImpl.java。例如接口为ProductService.java的实现类为ProductServiceImpl.java。 Action层的命名，action类命名为XxxAction.java，其中action的名字则为xxxAction（小写字母开头，驼峰法） View层的命名，分模块划分为不同的包，小写字母开头，驼峰法，相同类型的界面开头字母相同，如用户的登录界面和注册界面，分别命名为userLogin.jsp和userRegister.jsp。C. 架构相关设计模式。 使用Struts，Spring和hibernate实现MVC模式和DAO设计模式，从下到上分别为数据库：存储数据。VO层：每一个实体类映射一张数据库表，对实体类的操作相当于对数据库中表的操作。DAO层：实现对VO层实体类的基本操作，提供接口和实现类。Service层：在DAO层之上，实现逻辑处理，并提供接口和实现类共Action层使用。Action层：实现跳转和数据传输。View层：页面展示。其中从VO到View，使用全注解，并利用Spring自动装载，实现解耦和资源管理。4 详细设计4.1用例实现设计4.1.1 销售开单和收银A. 设计类图。B. 交互图 4.1.2收银A. 设计类图B. 交互图4.1.3 退货A. 设计类图B. 交互图4.2输入输出设计 4.2.1 表单设计以录入订单等典型功能为例，设计输入表单及交互方式。重点描述业务表单及分录项的样式及其交互。如1张订单（表单）包含n个产品（分录项），那表单和分录项如何展现(即样式设计)，1个订单和多个产品如何录入、保存(交互设计)，如何实现数据格式校验。绘制或截取1张JSP页面/Swing窗口设计效果表达样式设计，示意图结合文字说明交互设计和格式校验方案。提示：web项目中使用JQuery EasyUI等UI框架可更简单实现上述目标。如果项目使用UI框架，需在此处详细说明实现方案。4.2.2 报表设计报表设计，考虑到需要显示的数据并不复杂，主要为每一年各个月份的数据统计和产品的分类金额统计，所以使用了前端框架JQuery easyUI，结合数据抽取原则从数据库抽取数据，并进行运算，最后通过Json字符串传输到前端显示。以年份销售报表为例，输入年份，点击确认，即可从数据库中抽取出数据，并显示到dataGrid中，包括各年总额和列表中所有的销售额相加。类别销售报表中，通过从数据库中抽取出类别表，显示到Select中，然后点击查询，即可得到各类别的销售额。4.3 数据库设计E-R模型：User_iduserusernameUsernoPasswordRole_idCustomerCustomer_idaddressnamephonee-mailCustomer_noproductproduct_idaccoundcodedescriptionnameproductProduct_categorySale_returnProduct_stockSale_ordercustomerresourcesroleuserResource_typeRole_resourcesSale_order_listSale_return_list数据库表：4.4权限设计权限设计中，5 系统实现5.1 功能实现1、基础数据列表：客户基础数据列表2、开单：每次开始一次新的销售，系统会自动生成一个订单号。逐条录入商品条目，并逐行显示到datagrid中。然后选择客户。所有商品输入结束后点击提交订单，在数据库中创建此订单，把所有数据存进数据库。3、收银：根据商品数量和单价，商品总价格和金额总计自动计算：当顾客所支付的金额或者收银员所输入的顾客支付金额小于金额总计时，系统无法提交订单，并向收银员提示错误。若顾客所支付现金大于金额总计，则自动计算找零，收银员找零给顾客。点击提交订单后，后台返回订单提交是否成功，若订单提交成功，则系统按照规则给本订单一个订单号，并在订单编号栏显示订单编号。4、退货：在开始页面，点击退货，输入订单号，点击查找，出现该订单详细商品列表。点击选中需要退货的行，单击退货按钮，弹出处理框，业务员进行确认。操作成功后回到主页面，退货商品的数量和价格被设置为0，数据库中相应的订单价格也被改变，即成功退货。如需继续退货，则继续选择其它行进行退货，退货单号码仍为同一个。5、产品查询界面：6、年销售额报表5.2 系统测试5.2.1 单元测试（1）选择添加商品类别的测试进行单元测试，测试代码如下。public static void main(String args) ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext( new String applicationContext.xml);ProductCategoryDao pcd = (ProductCategoryDao) ctx.getBean(productCategoryDao);ProductCategorytype = new ProductCategory();type.setProductCategory(裤子);pcd.addProductType(type);、结果数据库中，出现一行数据（2）商品类别的删除，测试代码：ProductCategory type = pcd.deleteEntityById(3); 测试结果：成功删除了一个商品类别（3）商品类别的修改