淘宝购物支付平台系统的设计与实现设计报告(编辑修改稿)

淘宝购物支付平台系统的设计与实现设计报告(编辑修改稿)内容摘要：

信息和银行卡信息。 西安交通大学项目设计报告 26 （ 5） 提现功能数据流程图 用户填写提现表单，由系统审核，并更新用户表和银行卡表信息 （ 6） 转账功能数据流程图 用户填写转账表单，由系统审核，并更新用户表信息。 西安交通大学项目设计报告 27 数据流程图简单清楚的描述了数据流向，但其中某些部分的表述不够清晰，抽象难懂，因此就需要数据字典加以配合来解释其中相应内容。 数据字典（ Data Dictionary, DD）是关于数据流程图中未能具体说明部分的数据清单。 其主要包括的内容有数据项、数据结构、数据流、数据存储、处理过程等的详细解释。 数据字典的描述使得数据流程图更加完整。 数据项 数据项，又被称为数据元素，是数据流程图中具有独立逻辑含义的最小单元，无法再分割的数据单位。 本系统中的数据项包括： 代号 名称 含义 A01 username 用户名 A02 password 登录密码 A03 dingdanhao 订单号 A04 dingdanjine 订单金额 A05 shoukuanfang 收款方 A06 zhifufang 支付方 A07 zhifupassword 支付密码 A08 bangdingyinhangkahao 绑定银行卡号 A09 yinhangkahao 银行卡卡号 A10 yinhangkapassword 银行卡密码 A11 zhuanzhangjine 转账金额 A12 zhifubaoyuee 支付宝余额 A13 chongzhijine 充值金额 A14 shengyujine 银行卡余额 西安交通大学项目设计报告 28 A15 tixianjine 提现金额 A16 time 订单完成时间 数据流 数据流表示数据的来源和去向。 根据数据流程图，系统中的数据流包括： 代号 名称 数据来源 数据去向 F1 待处理的提交信息 用户 淘宝支付平台系统 F2 已处理的信息 淘宝支付平台系统 用户 F3 登录信息 登录信息填写 信息审核 F4 审核未通过信息 信息审核 用户 F5 登录审核通过信息 登录信息审核 用户 F6 支付信息 支付信息填写 信息审核 F7 审核通过信息 信息审核 相关用户信息修改 F8 相关用户修改信息 相关用户信息修改 用户表 F9 确认收获信息 确认收货 相关用户信息修改 F10 支付成功信息 用户表 用户 F11 相关银行卡修改信息 相关用户信息修改 银行卡表 F12 充值信息 充值信息填写 充值信息审核 F13 充值成功信息 用户表 用户 F14 提现信息 提现信息填写 提现信息审核 F15 提现成功信息 用户表 用户 F16 转账信息 转账信息填写 转账信息审核 F17 转账成功信息 用户表 用户 处理逻辑 系统中的处理逻辑包括： 西安交通大学项目设计报告 29 代号 处理逻辑 P1 登录 P2 付款 P3 提现 P4 充值 P5 转账 P6 填写登录信息 P7 审核登录信息 P8 填写支付信息 P9 审核支付信息 P10 相关用户信息修改 P11 用户确认收货 P12 填写充值信息 P13 审核充值信息 P14 填写提现信息 P15 审核提现信息 P16 转账信息填写 P17 审核转账信息 数据存储 系统中的数据存储在三个表中，这三个表分别是： （ 1） D1： 用户表 ， 储存用户相关信息。 数据存储构成：用户名、登录密码、支付密码、支付宝余额、银行卡号、头像 关键字 ： 用户名 （ 2） D2： 订单表 ， 储存订单相关信息。 西安交通大学项目设计报告 30 数据存储构成： 订单号、订单金额、订单状态、支付方、收款方、时间、商品名称、商品图片 关键字 ： 订单号 （ 3） D3： 银行卡表 ， 储存银行卡相关信息。 数据存储构成： 银行卡号 ， 银行卡密码 ， 银行卡余额。 关键字 ： 银行卡号。 关于表中字段的具体有效性约束等详细信息，请参考数据库设计中相关内容。 第三章 系统总体设计 功能模块 结构 图 在系统分析的基础上，我们可以得出系统的整体功能模块图。 本系统分为前台系统和后台系统两部分。 前台系统主要面对用户，实现管理功能和交易功能。 管理功能包括充值、提现、转账、修改密码等，交易功能包括取消订单、付款、浏览订单信息、确认收货、申请退款等，其中付款功能又细分为支付宝支付、网银支付、快捷支付、货到付款、他人代付等方式。 后台系统主要面向第三方支付平台和管理员。 第三方平台功能包括暂存货款、放款、退款等，管理员功能包括修改用户信息、修改订单信息等。 西安交通大学项目设计报告 31 系统的功能模块结构图如下： 假设功能模块结构图 由于时间有限，我们在认真研究整体功能模块图的基础上，认真分析其中最核心的业务，精简后确定了本系统的实际功能需求假设。 前台功能中，管理功能包括充值、提现、转账，交易功能包括付款、浏览订单信息、确认收货。 其中付款包括支付宝余额支付、网银支付、快捷支付三种方式；浏览订单信息不再专门设计查询功能，而是待用户登录后直接在个人界面中显示相关订单信息；确认收货功能在订单界面添加相关按钮。 后台功能中，只保留第三方平台的功能，包括货款暂存和放款。 西安交通大学项目设计报告 32 付款后，货款暂存在第三方账户上，用户确认收货后，第三方账户放款，货款才能转 移至收款方账户。 系统的假设功能模块结构图如下： 概念结构设计 用户需求分析采用方法和工具抽象出了现实世界的需求，概念模型则可以将这种需求转变为信息世界的实体和联系。 概念模型最常用的表示方法是实体 —联系方法，即通过 ER（ EntityRelationship）来描述现实中的实体与联系之间的关系。 在本系统中主要涉及 3 个实体，分别是订单，用户，银行卡。 这西安交通大学项目设计报告 33 些实体之间的关系是：一个用户拥有多个订单，用户与订单是 1 对 m的联系，一个用户拥有多张银行卡，用户与银行卡是 1 对 n 的联系： 系统的 ER 图如下： 逻辑结构设计： 逻辑结构设计是将概念结构设计中得到的结构转化为数据模型，以便支持数据库的设计，本系统中是将其转化为关系数据模型。 由于ER 途中只存在 1： n 的关系，因此逻辑结构设计的结果得到的关系跟实体的数量相同。 其结果如下： （ 1）用户（用户名，登录密码，支付密码，支付宝余额，银行卡号，头像） （ 2）银行卡（银行卡号，银行卡密码，银行卡余额） （ 3）订单（订单号，订单金额，订单状态，支付方，收款方，西安交通大学项目设计报告 34 时间，商品名称，商品图片） 根据上面分析的关系模型，我们设计出了主要的表： （ 1） 用户表： 字段名称 字段类型 约束条件 默认值 用户名 文本 数字和字母 登录密码 文本 同时含有且只含有数字和字母 支付密码 文本 同时含有且只含有数字和字母 支付宝余额 数字 大于 0 0 银行卡号 文本 19 位数字 头像 文本 （ 2） 银行卡表 ： 字段名称 字段类型 约束条件 默认值 银行卡号 * 文本 19 位数字 银行卡密码 文本 同时含有且只含有数字和字母 银行卡余额 数字 大于 0 0 （ 3） 订单表 ： 字段名称 字段类型 约束条件 默认值 订单号 * 文本 12 位整数 订单金额 货币 大于 0 订单状态 数字 0、 2 0 支付方 文本 数字和字母 收款方 文本 数字和字母 时间 日期 /时间 商品名称 文本 商品图片 文本 西安交通大学项目设计报告 35 第四章 系统详细设计与实现 以 WIN7 为例，进行系统的初步配置。 步骤如下： （ 1） 打开管理工具 （ 2） 打开 Inter 信息服务 西安交通大学项目设计报告 36 （ 3） 添加虚拟目录 本系统使用 Access 数据库，数据库 默认 路径为 ： C:\Users\Administrator\Desktop\ 新 建 文 件 夹(2)\。 接口 采用 OLEDB 接口 ， 其中 OLEDB 是 微软 的战略性的通向不同的数据源的低级应用程序接口。 数据库链接代码如下： % set conn=() dbpath=() Provider=。 Data Source=amp。 dbpathamp。 % 西安交通大学项目设计报告 37 （界面截图 +子程序流程图 +代码） 登录界面 程序流程设计 界面设计 代码设计 （ 1）从网页中获取信息 set rs=() 西安交通大学项目设计报告 38 username=(username) password=(password) （ 2）与数据库连接，判断信息 sql=select * from 用户 where(用户名 =39。 +username+39。 and 登录密码=39。 +password+39。 ) sql,conn,1,1 if = 0 then (验证 )=1 (登录 .asp) else (username)=(username) (验证 )=2 (主页 .asp) end if （ 3）根据信息判断，做出反应 u=(验证 ) if u= then u=0 end if if u=1 then font color=red 用户名或密码错误 ,请重新输入 /font end if 错误提示 西安交通大学项目设计报告 39 信息正确，进入主界面 付款界面 程序流程设计 界面设计。