|
第一章 研究发现与建议 13
1.1 业务界定 13
1.1.1 移动支付的定义 13
1.1.2 移动支付的分类 14
1.1.3 移动支付的实现方式 15
1.2 研究发现 18
1.3 发展建议 18
1.3.1 移动运营商 18
1.3.2 金融服务机构 19
1.3.3 第三方平台提供商 19
第二章 移动支付业务发展环境PEST分析 20
2.1 政策环境 20
2.1.1 目前政策监管现状 20
2.1.2 政策的变化及对市场的影响 20
2.1.3 国外政策监管启示 21
2.2 金融（经济）环境 22
2.2.1 金融结构体系 22
2.2.2 金融行业竞争趋势 24
2.2.3 移动支付对金融机构的机会 26
2.3 社会环境 27
2.3.1 消费者理财观念及支付方式的转变 27
2.3.2 支付方式的转变为移动支付带来的机会 28
2.3.3 社会信用体系的评估与健全 28
2.3.4 信用体系的健全为移动支付带来的机会 29
2.4 技术环境 29
2.4.1 移动支付的技术实现形式 29
2.4.2 移动支付的技术走势 32
2.5 移动支付PEST模型模拟 33
第三章 移动支付业务运营模式分析 34
3.1 移动梦网模式（移动运营商独立运营） 34
3.1.1 模式运作方式 34
3.1.2 模式业务范围 35
3.1.3 模式利益分配 35
3.1.4 模式运作特点 36
3.2 交通银行模式（金融机构独立运营） 36
3.2.1 模式运作方式 36
3.2.2 模式业务范围 37
3.2.3 模式利益分配 38
3.2.4 模式运作特点 38
3.3 联动优势模式（运营商和银行联合运营） 39
3.3.1 模式运作方式 39
3.3.2 模式业务范围 39
3.3.3 模式利益分配 40
3.3.4 模式运作特点 41
3.4 上海捷银模式（第三方平台商独立运营） 41
3.4.1 模式运作方式 41
3.4.2 模式业务范围 42
3.4.3 模式利益分配 42
3.4.4 模式运作特点 43
3.5 四种运营模式比较分析 43
第四章 移动支付业务内容模式分析 45
4.1 模式一：小额支付 45
4.1.1 业务应用方向 45
4.1.2 关键成功因子（CSF）分析 46
4.1.3 业务成熟度及其前景 46
4.2 模式二：手机银行 46
4.2.1 业务应用方向 46
4.2.2 关键成功因子（CSF）分析 47
4.2.3 业务成熟度及其前景 49
4.3 模式三：手机信用卡 51
4.3.1 业务应用方向 51
4.3.2 关键成功因子（CSF）分析 51
4.3.3 业务成熟度及其前景 52
4.5 模式四：现场支付 52
4.5.1 业务应用方向 52
4.5.2 关键成功因子（CSF）分析 53
4.5.3 业务成熟度及其前景 53
第五章 移动支付业务产业链分析 55
5.1 移动支付业务链模型 55
5.2 移动运营商 55
5.3 金融服务机构 56
5.4 第三方平台提供商 56
5.5 加盟商家 57
5.6 最终用户 57
第六章 移动运营商移动支付业务发展分析 58
6.1 中国移动 58
6.1.1 发展现状 58
6.1.2 业务范围 59
6.1.3 运营模式 59
6.1.4 合作金融机构 59
6.1.5 盈利模式 60
6.2 中国联通 60
6.2.1 发展现状 60
6.2.2 业务范围 61
6.2.3 运营模式 61
6.2.4 合作金融机构 61
6.2.5 盈利模式 61
第七章 第三方运营商移动支付业务发展分析 63
7.1 上海捷银 63
7.1.1 公司介绍 63
7.1.2 业务范围 64
7.1.3 运营模式 64
7.1.4 合作金融机构 65
7.1.5 合作商家 65
7.1.6 盈利模式 65
7.2 掌上通 65
7.2.1 公司介绍 65
7.2.2 业务范围 66
7.2.3 运营模式 66
7.2.4 合作金融机构 67
7.2.5 合作商家 67
7.2.6 盈利模式 69
7.3 北京通融通 70
7.3.1 公司介绍 70
7.3.2 业务范围 70
7.3.3 运营模式 71
7.3.4 合作金融机构 71
7.3.5 合作商家 72
7.3.6 盈利模式 72
第八章 金融机构移动支付业务发展进程 73
8.1 工商银行 73
8.1.1 实现方式 73
8.1.2 开通地区 73
8.1.3 业务范围 74
8.1.4 用户使用条件 74
8.2 建设银行 75
8.2.1 实现方式 75
8.2.2 开通地区 76
8.2.3 业务范围 76
8.2.4 用户使用条件 76
8.3 中国银行 76
8.3.1 实现方式 76
8.3.2 开通地区 77
8.3.3 业务范围 77
8.3.4 用户使用条件 77
8.4 交通银行 77
8.4.1 实现方式 77
8.4.2 开通地区 78
8.4.3 业务范围 78
8.4.4 用户使用条件 79
8.5 招商银行 79
8.5.1 实现方式 79
8.5.2 开通地区 79
8.5.3 业务范围 80
8.5.4 用户使用条件 80
8.6 民生银行 81
8.6.1 实现方式 81
8.6.2 开通地区 81
8.6.3 业务范围 81
8.6.4 用户使用条件 81
第九章 国外移动支付业务案例分析 83
9.1 paybox 83
9.1.1 运营模式 83
9.1.2 交易流程 83
9.1.3 PayBox的特点 84
9.2 i-mode Felica 84
9.2.1 业务介绍 84
9.2.2 业务范围 85
9.2.3 合作伙伴 87
9.2.4 业务发展 88
9.3 MONETA 88
9.3.1 业务介绍 88
9.3.2 业务范围 89
9.3.3 业务发展 93
9.4 K-merce 93
9.4.1 业务介绍 93
9.4.2 业务范围 94
9.4.3 业务发展 94
第十章 移动支付业务发展建议 95
10.1 移动运营商 95
10.2 金融服务机构 97
10.3 第三方平台提供商 98
图表目录
图1-1： 移动支付流程 9
图1-2：移动支付的建立过程及构架 10
图1-3：移动支付业务系统组成图 13
图2-1：中小银行近几年信息化建设的重点方向 21
图2-2：国际银行不同方式的交易成本 22
图2-3：手机用户选择移动支付业务原因 24
图2-4：移动支付PEST模型 29
图3-1：运营商为主体的移动支付系统结构 31
图3-2：金融机构独立运营的移动支付系统结构 33
图3-3：第三方支付平台独立运营的系统结构 38
图5-1：移动支付产业链 51
图8-1：交通银行手机银行实现方式 74
图9-1：i-mode Felica手机购物实例 82
图9-2：i-mode Felica手机电子票务实例 82
图9-3：i-mode Felica手机作钥匙实例 83
图9-4：i-mode Felica手机在线购物实例 83
图9-5：i-mode Felica合作伙伴 84
图10-1：用户为使用移动支付的原因 92
表1-1：手机接入移动支付平台的技术方式 11
表1-2：手机跟商家直接支付的技术方式 12
表3-1：四种模式的对比分析 39
表4-1：国内各银行的手机银行服务状况 45
表7-1：上海捷银发展历程 59
表10-1：消费者对信用卡的认知调查结果 91?
清单 1. 典型的一文不值的 Javadoc
/**
* Represents a command history
*/
public class CommandHistory {
/**
* Get the command history for a given user
*/
public static CommandHistory getCommandHistory(String user) {
. . .
}
} |
什么是好的文档
那么好的文档包括哪些内容呢？
上面描述的组织技术（在类描述中引用相关类或工厂类，也包括了包概述和代码样本）是形成优秀文档的好开端。它有助于新用户使用 Javadoc 了解新工具。
但体系结构的概述只完成了任务的一半。另一半则是详细地解释方法做什么和不做什么、在什么条件下运行以及它们如何处理错误条件。大多数 Javadoc 都没有完全提供所需的信息，即便是那些充分描述了方法在期望情况下的行为的 Javadoc 也是如此，这些缺少的信息包括：
· 方法如何处理错误条件或不合要求的输入
· 如何将错误条件传回给调用者
· 可能会抛出哪个特定异常的子类
· 哪些值对于输入是有效的
· 类不变条件、方法前置条件或方法后置条件
· 副作用
· 在方法之间是否有重要联接
· 类如何处理多个线程同时访问一个实例的情况。
Javadoc 约定提供了 @param 标记，它让我们除了能够对参数的名称和类型编制文档之外，还可以对其意义编制文档。然而，并不是所有的方法都能很好地接受参数的任何值。例如，虽然可以合法地向任何获取对象参数的方法传递空值（null）而不违反类型检查规则，但并不是所有的方法都能在传入空值时正常工作。Javadoc 应该显式地描述有效的参数范围，如果它希望某个参数非 null，那么它应该这样描述，而如果它期望参数值在某个范围内，例如某种长度的字符串或大于 0 的整数，那么它也应该那样描述。并非所有方法都仔细检查其参数的有效性；不进行有效性检查也没有编制关于可接受的输入范围的文档，这二者的结合为灾难埋下了隐患。
返回代码
Javadoc 使得描述返回值的意义变得很容易，但正如方法参数一样，@return 标记应该包括对可能返回的值范围的详细描述。对于对象取值的返回类型而言，它会返回空值吗？对于整数取值的返回类型而言，结果会限制在一个已知值或非负值的集合上吗？任何返回代码都有特殊意义吗，例如从 java.io.InputStream.read() 返回 -1 表示文件结束符？返回代码会被用来表示例如如果无法找到表项则返回空值那样的错误条件吗？
异常
标准 doclet 复制方法的 throws 子句，但 Javadoc @throws 标记应该更为具体。例如，NoSuchFileException 是 IOException 的子类，但 java.io 中的大多数方法却只被声明为抛出 IOException。然而，方法可能独立于其它 IOException 而抛出 NoSuchFileException，这是调用者要了解的很有用的事实 — 它应该被包括在 Javadoc 中。还应该指出抛出各种异常类的实际错误条件，以便调用者知道在给定异常被抛出时该采取什么纠正措施。应该用 @throws 标记对方法可能抛出的每个经检查的或未经检查的异常编制文档，并对引发抛出异常的条件编制文档。
前置条件、后置条件和不变条件
当然，您应该对方法对对象状态的影响编制文档。但您可能需要编制得更详细一些，描述方法的前置条件、后置条件和类不变条件。前置条件是在调用方法前对对象状态的约束；例如，调用 Iterator.next() 的前置条件是 hasMore() 为真。后置条件是方法调用完成后对对象状态的约束，例如在调用 add() 之后 List 不能为空。不变条件是对对象状态的一种约束，它保证该状态始终为真，例如 Collection.size() == Collection.toArray().length()。
诸如 jContract 之类的按契约设计（Design-by-contract）工具允许您使用特殊注释指定前置条件、后置条件和类不变条件，这类工具然后生成额外代码来强制这些约束。无论您是否使用工具来强制这些期望条件，对这些约束编制文档可以让用户知道要安全地使用类，他们可以做些什么。
副作用
有时候，方法除了改变对象状态之外还会有其它副作用，例如改变相关对象、JVM 或底层计算平台的状态。例如，所有执行 I/O 的方法都有副作用。有些副作用是无害的，例如保留类处理的请求的记数。另外一些副作用则会对程序性能和正确性产生重大影响，例如修改传递给方法的对象的状态，或存储对该对象的引用的副本。诸如修改相关对象的状态或存储对作为方法参数传递的对象的引用之类的副作用应该编制文档。
方法联接
方法联接意味着类中的两个方法相互依赖，并且都对对方的行为做了假定。发生方法联接的一种常见情形是：方法在内部使用同一个类的 toString 方法，并假定 toString 将以特别的方法格式化对象状态。如果该类已经子类化并且 toString 方法被重写了，那么这种情形可能引起问题；另一个方法会突然不能正常工作，除非它也被重写。如果您的方法依赖于其它方法的实现行为，那么需要对那些依赖性编制文档。而且，如果类已子类化，那么可以以一致的方式重写两种方法以便使子类仍能正常工作。
线程安全
应该编制文档的最重要的行为之一是线程安全，而对它几乎从未编制文档。这个类是线程安全的吗？如果不是，那么是否可以通过用同步封装调用来使其线程安全吗？这些同步必须同特定管程相关联，还是任何一直使用的管程都可以使用呢？方法获得了对于类外部是可见的对象的锁吗？
线程安全实际上不是二进制属性；线程安全有几种可标识的等级。对线程安全编制文档，或者甚至确定线程安全的等级并非总是很容易。但未能进行这一工作将导致严重的问题；在并发应用程序中使用非线程安全类可能引起零星的故障，这些故障常常直到部署时才出现（那时暴露应用程序以便装入）。而且将额外锁定封装在已经是线程安全的类周围会影响性能，甚至引起死锁。
Josh Bloch 在他的 Effective Java Programming Language Guide（参阅参考资料）一书中对类的线程安全等级编制文档提供了有用的分类法。可以按照线程安全递减顺序将类归到下列某一组：不可变、线程安全、有条件的线程安全、线程兼容和线程对立。
这种分类是一个极佳的框架，用于在并发访问情况下传递关于类行为的重要信息。不管您是否使用这一分类法都没关系，但您应该标识您的类意图显示的线程安全等级。我还建议：如果方法获得对一个对象的锁定，而该对象对于类自身的代码外部是可见的，那么您也应该就此编制文档，即使这只是一个“实现细节”，以便协助做出全局锁定顺序（global-lock-order）决策并防止死锁。
结束语
对类的行为编制文档远远不只是对每个方法做什么给出一行描述。有效的 Javadoc 应该包括对下列内容的描述：
· 类如何相互关联
· 方法如何影响对象的状态
· 方法如何将出错条件通知它们的调用者以及它们可能通知什么错误
· 类如何处理多线程应用程序中的使用
· 方法的参数作用域及其返回值的范围
另外，糟糕的文档（或甚至更糟糕，没有文档）会导致优秀的代码不可用或不可重用。通过在文档上花一些额外时间，您将为您的用户（可能是您自己）避免无数的挫折。
关于作者
Brian Goetz 是一名软件顾问，在过去的 15 年里，他一直是一名专业软件开发人员。他是 Quiotix 的首席顾问，Quiotix 是一家位于加尼福利亚州洛萨图斯（Los Altos）市的软件开发与咨询公司。在流行的业界出版物中查阅 Brian 已出版和即将出版的文章。请通过 brian@quiotix.com 和 Brian 联系。
『引自 IBM DW中国』
（责任编辑：Sunny）
| 
2007年02月05日
