面向服务的分析与设计原理

　　OO 分析是一种非常强大且广为赞誉的方法，同样，SOAD 应该尽可能多地利用 OO 分析技术。要将 OO 分析成功地应用于 SOA 项目，您就必须一次分析多个系统。用况模型必须继续扮演重要的角色。然而，SOAD 必须主要是 流程，而不是 用户驱动的。因此，SOAD 需要 BPM 和用况建模活动之间的强链接。

　　在 设计层，OO 的目标是能够进行快速而有效的设计、开发以及执行灵活且可扩展的应用程序。对象是软件构造，其行为就像它们建模的真实世界的实体。例如，顾客 (Customer) 将有名称和联系信息，并且还可能有一个或多个与之相关的帐户对象。从 OO 的角度看，每件事情都是对象。

　　OO的基本原则是：

• 　　封装：软件对象就是包含模拟真实世界的对象的物理属性(数据)和功能(行为)的离散包。例如，帐户对象保持收支平衡并且包含平衡中的借贷机制。
• 　　信息隐藏：结构良好的对象有简单的接口，并且不向外界显漏任何内部机制。真实世界信息隐藏的例子是，您不需要详细了解汽车的工作原理就能够驾驶它。
• 　　类和实例： 类是定义特定类型的软件对象具有什么类型的属性和行为的模板，而 实例是具有这些属性值的个别对象。创建类的新实例称为 实例化。利用生物学进行类比，人就是一个类。所有的人都具有一些属性，比如身高、体重、头发和眼睛颜色等等。我们中的每个人都是这个类 HumanBeing 的实例，具有一些特定的身高、体重以及其他的属性值。类是一直存在的，而实例具有有限的生命周期。
• 　　关联和继承：在 OO 中，表达类和对象之间的关联的能力是一个关键的概念;继承是关联的强形式，用于表达有关系：按照同样的方式，生物物种由这样的层次构成：界 (Kingdom)、门 (Phylum)、纲 (Class)、目 (Order)、科 (Family)、类 (Genus)、种 (Species)。我们常常发现软件对象的自然层次。例如，当您创建一个财务应用程序实体时，您可能需要构造像 经常帐户(CheckingAccount) 、 储蓄帐户(SavingsAccount) 和 贷款帐户(LoanAccount) 这样的对象。如果您看得更仔细一点(请参见 图 3)，您将发现这些类共享许多属性，比如都有收支平衡帐户、借方帐户和贷方帐户等等

　　图 3. UML 类继承示例

　　与其重复定义和管理这些属性的代码，不如创建一个通用的 帐户(Account) 类，该类具有现金收支平衡并且可以处理借贷事务。所有其他的类都是这个 帐户(Account) 对象的专门形式。例如， 贷款帐户(LoanAccount) 将在零和某个约定的最大值之间具有负平衡，而 储蓄帐户(SavingsAccount) 将具有负平衡，并且将展示增加利息的行为，等等。

　　消息传递：为了完成一些有用的工作，软件对象需要相互通信。它们通过相互发送消息来这样做。例如，假定我们想将 $1000 从经常帐户转到储蓄帐户，要达到此目的，可以将带有参数 $1000 的 借消息发送到 经常帐户(CheckingAccount) 实例，并且将相应的 贷消息发送到 储蓄帐户(SavingsAccount) 实例。当实例接收消息时，它执行相应的功能，称为 方法，它有与消息相同的名称。

　　多态：这个术语描述两个或两个以上的类接受相同的消息但是以不同的方式进行实现的情况。例如， 自由经常帐户(FreeCheckingAccount) 实例和 经常帐户(CheckingAccount) 实例将响应 借 ($100) 消息，但是 自由经常帐户(FreeCheckingAccount) 实例将正好 $1000 记入它的帐户平衡的借方，而 经常帐户(CheckingAccount) 实例将 $1000 加上交易费记入它的帐户平衡的借方。

　　OO 支持应用程序分析、设计和开发的完整生命周期：

　　OOAD试图找到最优的对象和最自然的类继承来实现它们。

　　OO 开发集中于应用程序的渐进式开发，每次实现一个业务场景或用况。像 IBM WebSphere Studio Application Developer 这样的工具有助于开发人员快速地构造和测试 OO 应用程序。

　　OO 运行时环境，例如由 Java 虚拟机提供的，提供应用程序服务(如垃圾收集(删除因使用它们的对象已经被丢弃而不再使用的资源))以及框架(如 J2EE)来为驻留在不同的服务器上的对象提供相互通信的机制。

　　目前与 SO 有关的 OO 设计实践的主要问题在于，它的粒度级别集中在类级，对于业务服务建模来说，这样的抽象级别太低了。诸如继承这样的强关联产生了相关方之间一定程度的 紧耦合(因而具有依赖性)。与此相反，SO 范式试图通过 松耦合来促进灵活性和敏捷性。目前，在 SOA 中还没有服务 实例的跨平台继承支持和一流的表示法来避免需要处理服务生命周期维护管理问题(如远程垃圾收集)。

　　这些考虑事项使 OO 难以与 SO 体系结构样式直接保持一致。然而，对于设计已定义的服务中的底层类和组件结构，OO 仍然是一种有价值的方法。此外，许多 OOAD 技术(例如类、责任、协作(CRC)卡)也可以用于服务建模(如果它们提升到更高层次的抽象的话)。在本文后面，我们将回过头来讨论这一点。

　　图 4展示了可见性层次和 OO、 面向组件和 SO 设计提供的重点之间的对应关系。它还展示了在 SOA 和 SOAD 背景中它们之间的相互关系。

　　图 4. 设计层次

　　至于表示法，统一建模语言(Unified Modeling Language，UML)——通过一些附加的定型(Stereotype)和概要加以增强——自然成为 SOAD 的重要基础。

　　在使用 Rational Unified Process (RUP)——被认为是支持迭代软件开发的分析与设计的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要价值。然而，RUP 以 OOAD 的原则为基础，因而使其不容易与 SOA 设计保持一致。从 RUP 的角度来看，系统的体系结构是其通过已定义接口交互的主要组件的体系结构。此外，这些组件还由逐渐减小到类级粒度的更小组件组成。相反，在 SOA 中，系统的体系结构通常包括满足普通 业务服务需要的无状态、全封装且自描述的服务组成，它更接近于映射到 BPM，如 图 5所示。

　　图 5. SOAD 服务定义层次

　　这些服务可能包括许多协作或编排服务。这并没有排除 RUP 采用的 OO 观点，而是在其上实现了另一个抽象层。这个超层的作用是封装作为正式的跨层接口结构中的 RUP 构件( 软件服务)设计的组件。