OOA实例支付宝4.8

Thanks☺
29
` 表示对象之间行为关系的图 ` 一个顺序图通常只描绘一组对象一项功能 ` 当功能所涉及的对象行为关系比较复杂时用 ` 强调时序关系
` 顺序图举例
◦ 支付宝充值 ◦ 买家购买商品
` 状态机图描述了一个对象（或其他实体）在其生命 期内所经历的各种状态、状态间的转移、发生转移 的动因、条件以及转移中所执行的活动。
系统通知卖家发货； 买家确认收货；
系统将钱转至卖家支付宝帐户，并通知买卖双方交易结束。
客户.为自己的支付宝帐户充值 客户填写相关充值信息；
系统新建交易订单并链接至网上银行； 客户在网上银行填写自己的帐号密码等；
系统显示银行返回的交易结果。
` 是一种描述系统行为的图 ` 把系统的一项行为表示成一个可以由计算机、人或者其
卖家
买家
卖家
第三方支付平台
1.下订单 8.反馈订单处理信息
优点
•减少搭建银行网关代价
•解决交易安全和信用问 题
网络消费者
网上商店
3.选择网上银行
2.发送支付数据
7.反馈支付结 果
6.反馈交易结 果
第三方支付平台 4.登录银行网 关
5.输入金融账号信息完成支付
其他功能
•网上商店查询订单支付 信息 •消费者查询支付记录 •平台自身的业务管理 •。。。
20
` 需求分析完成后，便可以进行面向对象分析了 ` 基本思路
◦ 发现对象、定义对象类
x 定义属性和操作（可能推迟到OOD）
◦ 定义对象之间的关系
x 一般-特殊关系 x 整体-部分关系 x 关联 x 依赖
23
` 策略与启发
◦ 考虑问题域
x 人员，组织，物品，设备，抽象事物，文件，结构
◦ 考虑系统边界
柳毅
liuyi07@sei.pku.edu.cn 2009-04-08
` 讲什么
◦ 需求分析及OOA的整个过程 ◦ 分析思路 ◦ 需要考虑哪些方面
` 不讲什么
◦ 各建模元素的细节信息
x 如类的属性、操作等
着重讲过程、思路，暂时不考虑完备性
Baidu Nhomakorabea
` 系统介绍
◦ 背景、功能概述
` 需求分析
◦ 用况图、活动图
9
•系统边界以内的成分是需要实现的成分 •系统边界的范围指明了系统开发的责任
接收系统
服务的人 员
买家
普通用户 卖家
工作人员
为系统直 接提供服 务的人员
设备？
外系统 （与系统 交换信
息）
商户系统
` 对每一类参与者，分析它们与系统交互是为了完成 哪些功能
` 针对每一项功能定义一个用况
` 登录
` 个人信息管理
确认付款 买家
卖家
x 满足上述所述运行机制
x 交易双方至少各有一个支付宝账号
x 买家先付款到PKUmini支付平台
PKUmini支付平台
x 待买家确认付款后，支付平台才将钱真正转给卖家
` 按前面所述机制进行运作 ` 提供用户管理功能
◦ 买家、卖家
` 用户可对支付宝进行充值
◦ 即将用户银行卡中的钱转至支付公司的帐户
` 一般来说，仅对行为受状态影响情况复杂的对象建 立状态机图。
` 举例：买卖交易的状态
` 对模型的细节进行详细解释和说明 ` 图形文档不够详细、精确
` 类规约
◦ 类的总体说明、属性说明、操作说明、。。
` 对用况图的规约
◦ 对每个用况进行文字描述
` 对其他模型图的规约
Continue ——OOD
◦ 与银行网关接口、与商户系统接口
` 考虑系统责任
◦ 检查疏漏的对象
25
` 一般-特殊（泛化）——分类关系 ` 整体-部分（聚合、组合）——构成关系 ` 关联——静态联系 ` 消息——动态联系
` 一部分关系可能在发现对象的时候直接定义出来了， 还有一些可能需要在对象发现后再去识别
28
注：依赖关系的问题、类图中的消息
` 允许用户对支付宝进行管理； ` 能与商户系统进行交互，以接受和反馈相关的交易信息；
` 能与银行网关进行交互，以实现用户的充值和提现等操 作请求；
` 允许支付公司业务管理员查询交易的相关情况 ` 。。。
` 对用户需求进行分析，旨在产生一份明确、规范 的需求定义
` 基本思路
◦ 确定系统边界 ◦ 发现参与者 ◦ 定义用况
注:公司内部的业务管理等不是本次分析的重点， 故此处只是简要提及，以后不再详细论述
` 合并相同的用况
◦ 系统登录
` 描述参与者之间的继承关系 ` 用况的粒度问题
17
需求分析到此为止吗？ 或者说需求分析中只有用况图吗？
买家.购买商品 买家确定购买商品；
系统新建交易，并等待买家付款； 买家付款（即将自己支付宝帐户的钱转至支付宝公司账户）；
` OOA
◦ 类图、顺序图、状态机图
` 小结&讨论
` 网上商店的大量涌现
◦ 淘宝、eBay、…
` 在线支付的安全和信用问题
◦ 网上银行?、货到付款?、…
` 第三方支付平台
◦ 支付宝（淘宝网）、安付通（eBay）、买卖通、… ◦ 专营第三方支付平台的公司
x 网银在线、YeePay、支付@网等
买家
支付
◦ 查看个人信息 ◦ 修改个人信息
` 支付宝管理
◦ 充值 ◦ 提现 ◦ 查询
` “普通用户” ` 新建交易 ` 付款 ` 交易查询 ` 确认收货 ` 申请退款 ` 请求关闭交易
` “普通用户” ` 申请实名认证 ` 收款 ` 修改交易信息 ` 查看交易状态 ` 关闭交易 ` 退款处理
` 登录 ` 用户管理 ` 公司业务管理 ` 。。。
` 用户可以进行提现操作
◦ 即将自己在支付公司的款项转至自己的银行帐户
` 买家可以进行付款操作
◦ 即购物时通过支付平台将自己在支付公司帐户上的款项转至卖 家在支付公司的帐户
` 卖家能够进行收款服务 ` 卖家必须申请实名认证
` 用户能对交易进行管理。
◦ 包括买家、卖家 ◦ 记录交易的信息，允许用户进行查询、修改等； ◦ 买家可以申请退款 ◦ 卖家可关闭交易
银行支付网关 注：上图是最长路径，实际交易中有可能不用每次都登录银行网关（3，4，5，6）
` PKUSEI公司：在线支付业务（平台）
◦ PKUmini支付宝 ◦ 在网上银行和商家之间建立起安全连接，实现消费者与银
行以及商家之间的在线货币支付、资金清算、查询统计等 业务
◦ 本分析主要针对在线货币支付业务
x 人员，设备，外系统
◦ 考虑系统责任
24
` 问题域
◦ 人员
x 买家、卖家、系统管理员、业务管理人员
◦ 抽象事物
x 支付宝账户、支付平台-银行交易信息、买家-卖家交易信息、 客户充值/提现交易信息
◦ 结构
x 一般-特殊结构：普通用户、工作人员 x 整体-部分结构：实名认证资料（卖家）
` 考虑系统边界
` 建模结果是唯一的吗？如何评价建模结果的好坏？
` OO方法与敏捷开发、极限编程
◦ OOA、OOD的目的是降低开发复杂度，如果系统比较小， 那么OOA和OOD反而有可能增加复杂度
x “hello world”也用OOA和OOD？
` OO方法与结构化方法
◦ OO方法是放之四海皆准的吗？ ◦ OOA和OOD的方法不是教条的，应当灵活应用
他执行者执行的活动 ` 通过给出活动中的各个动作及动作间的转移关系来描述
系统的行为
` 活动图可能出现在建模的各个阶段，用以辅助说明某个 流程或行为
◦ 描述对象的操作流程（OOD） ◦ 描述系统的局部行为（OOA、OOD） ◦ 描述系统外部可见的行为（需求） ◦ 描述系统的业务逻辑（需求）——更进一步认识系统的需求