销售终端系统 v1.docVIP

商场支付系统的uml设计与分析 系统概述 该项目一个用于商品零售的支付系统，支持多种付款方式以及实时结算清算的高性能现代化支付系统。系统充分利用了网络技术和安全加密技术，对数据库的支持也使得所有交易数据能被安全高效的存储。由于系统的开发过程基于.net框架，uml能很好的与.net的面向对象设计语言结合大大提高软件开发的效率，缩短开发周期，提高软件质量。 需求分析 2.1 顾客 所有的具有独立结算和网络化的商品销售网点和超市 2.2 目标 系统的目标是提高结算的自动化水平，为业务过程提供更快捷的、更好的和更经济的服务： 为顾客快速结帐 进行快速准确的销售统计分析 仓储控制自动化 2.3 系统功能 2.3.1 基本功能 标号 功能 分类 R1.1 记录在线的（当前的）销售-卖出商品 明显的 R1.2 计算当前的销售总额，包括税和优惠折算 明显的 R1.3 从条形码中获得被购买的商品信息 明显的 R1.4 记录完整的销售信息 隐藏的 R1.5 当一次销售被提交系统以后，削减相应库存 隐藏的 R1.6 提供一个持久化存储机制 隐藏的 R1.7 显示记录下来的商品说明，商品价格 明显的 2.3.2 处理支付的功能 标号 功能 分类 R2.1 处理现金支付，记录付款额，计算应还款额 明显的 R2.2 处理信用卡支付，从读卡机中读入信用卡信息，连接信用卡授权服务机构来为顾客的信用卡支付提供授权服务 明显的 R2.3 处理支票支付，人工录入个人信息并为支付服务，连接支票授权服务机构来为顾客的支票支付提供授权服务 明显的 R2.4 将信用卡支付的款项记录到应收系统中去 隐藏的 2.4基本用例图 模型中的活动者代表外部与系统交互的单元，包括顾客、出纳员、授权服务机构、支票授权机构、商场管理员；业务用例框图是对系统需求的描述，表达了系统的功能和所提供的服务 详细分析和设计 3.1静态模型设计 静态逻辑模型描述实例化（类成员关系）、关联、聚集（整体/部分）、和一般化（继承）等关系。这被称为对象模型。一般化关系表示属性和方法的继承关系。定义对象模型的图形符号体系通常是从用于数据建模的实体关系图导出的。对设计十分重要的约束，如基数（一对一、一对多、多对多），也在对象模型中表示 3.1.1 对象和关系图 3.1.1类图 3.2 动态交互模型设计 类和对象的识别包括找出问题空间中关键的抽象和产生动态行为的重要机制。开发人员可以通过研究问题域的术语发现关键的抽象。语义的识别主要是建立前一阶段识别出的类和对象的含义。开发人员确定类的行为（即方法）和类及对象之间的互相作用（即行为的规范描述）。该阶段利用状态转移图描述对象的状态的模型，利用时态图（系统中的时态约束）和对象图（对象之间的互相作用）描述行为模型 3.2.1 状态图 状态图适合描述一个对象穿越多个Use Case的行为。类的状态图表示类的对象可以呈现的状态和这个对象从一种状态到另一种状态的转换。 通过对buyItems用况的状态图分析，可以帮助理解类之间的状态转换关系 3.2.2 序列图 序列图：序列图是一种对象交互图，着重强调了时间序列，而不是静态对象的关系，通过序列图可以清楚地看到“谁在什么时间对谁说了写什么”。通常类和对象的操作方法都是一段程序的处理过程，这个过程通常是有一个时间序列流程，通过对操作的序列图，可以清楚的得到整个过程中各个对象之间的交互信息 以下是信用卡支付交易的操作序列图，它说明了各个对象之间的交互信息 3.2.3 协作图 协作图和序列图相似，两种图所表达的是同一种信息，可以将序列图转换为协作图，反之也然。但两者是有区别的，序列图强调的是交互的时间序列，协作图强调的是交互的语境和参与交互的对象的整体组织。下图描述的是一个支付过程中的消息传递。 支付交易协作图（6） 3.2.4 活动图 活动图：用于描述业务过程和类的操作，类似与旧流程图，是对业务处理工作流建模，在活动图中可以增加角色的可视化的维数，下图是增加了顾客、出纳、post，和auther四个角色的系统活动图，反映了在业务处理过程中，每个角色执行的过程。 系统活动图(8) 构件和部署 4.1程序组织和构建图 以下是程序的主要组件之间的关系图，程序的界面主要由menu.dll第三方控件实现，数据库访问通过ODBC连接oralce数据库系统 4.2 系统部署和实施图 系统结构以客户端-服务器端-数据库 三层模式分布，通过商场之间的网络专线以及其他金融机构之间的网络专线通信。