任务:组件规范(SOA)
本任务指定了实现设计子系统的服务组件的详细信息。
用途

详细阐述一个或多个工具:设计子系统(已在任务:子系统设计(SOA)过程中描述)并提供详细的工件:服务组件设计。

关系
角色主要: 其他: 辅助:
输入必需: 可选: 外部:
输出
主要描述

基于 SOA 的解决方案中所使用的服务是通过工件:服务组件实现的,它们属于满足特定业务功能的子系统。 每个服务组件都有责任确保它将实现的服务的 QoS。 作为企业级的资产,每个服务组件都具有与自身关联的筹资、管理和维护方面的资格。基础结构管理必须到位以确保服务组件的可用性、负载均衡、安全性、性能,版本控制以及整体运行状况,它们将负责实施一组服务的功能并确保其服务质量。 功能组件和技术组件可以在多个服务组件中使用。

步骤
模型组件接口

组件(尤其是服务组件)不应直接提供操作,而应该使用接口来描述一组操作,然后再提供/实现此接口。在 RUP 中对此进行了概述,请参阅任务:子系统设计(SOA)任务:确定设计元素

示例

在“租车”示例中,我们已经确定了保留服务组件的需求(通过子系统分析)。 为了确保设计的可复用性和灵活性,我们还可以创建一个对应的保留接口,或使用服务规范(通过任务:服务规范)来描述至服务组件的接口。 组件将实现(以 UML 术语)每个提供的接口,并使用 UML 使用关系来表示它与其他组件的依赖关系(如下图中所示)。

请注意,为了清楚起见,我们已省略了接口本身的详细信息。

模型组件属性
在此步骤中,我们将定义每个服务组件的详细信息,包括属性、服务、策略以及规则。 记录服务组件规范的模板将包含以下属性:
  1. 属性
  2. 规则
  3. 变化
  4. 对 <其他组件> 的依赖
  5. 功能组件和技术组件的组合
  6. 提供的服务
  7. 所需的服务
模型组件事件和消息
在此活动中,我们将确定组件必须检测且一旦触发必须响应的事件。 还将指定入局和出局的组件消息。对于由对数据的更改而驱动的服务,必须采用数据中心视图,且必须确定和评估不处在基于服务的解决方案范围内的业务流程,以便生成事件并为面向服务的解决方案中的使用者服务提供数据。 例如,一个新的客户机可能由某个 ISV 软件包内的多个业务流程添加。在任何情况下,可能都不会为取决于特定业务流程环境的客户机捕获相同的数据。 需通过供应商服务发现新客户机的使用者服务必须能够处理新客户机服务的调用,不论该调用是哪个业务流程生成的。
模型组件内部结构

在此活动中,重点是创建至少一个显示每个服务组件的功能组件与技术组件之间关系的类图。 标准的 UML 建模适用于此阶段。 在模式的使用方面,最好以可扩展且开放更改的方式来构造结果对象图。如果期望进行大幅度的更改,建议在此阶段执行可变性分析

如先前的任务中所述,在对更改进行设计,或预计由于将来的业务更改而会对 IT 系统的设计和结构产生重大影响时,明智的做法是采用可变性分析技术。这些技术使用设计模式重构共同点并将变化外部化。可将早期发现的共同点和变化作为起点,然后通过使用公共设计模式(例如策略、状态[i]、规则对象 [ii] 和类型对象等)加以扩充。

在详细设计过程中进行的分析确定了共同点并重点构建可拔插变化,并包含了六大原则,这些原则有助于从较少的软件系统变化方面分离出变化,并隔离和封装这些变化:

  1. 将领域中不断变化的方面与不变的方面区分开来,并对变化的方面进行建模:对不断增加的变化进行确定、区分、封装和外部化。
  2. 为每个变化点创建类型层次结构。
  3. 向每种变化类型指定规则类型。
  4. 实施三个级别的抽象;使用聚集继承元方式。
  5. 从高于对象的复用级别开始,并在每个复用级别构建资产;在变化点周围构建小框架。通常而言,每个框架的类不应超过 7+-2 个。
  6. 每个复用元素都具有自己的行为。将行为外部化为可读取到应用程序中的可配置数据以允许软配线。

[i] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addision-Wesley 1994.

[ii] Arsanjani, A., Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules, Washington University Technical Report number:  wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000.

模型组件流

在此活动中,我们将确定服务组件中的内部控制流。这可以表示为序列或活动图。

ISV 考虑事项:将根据 ISV 软件包来确定包组件中的组件内部流是否显现和/或可配置。 如果 ISV 组件内的对象显现且可配置,则可以对它们进行调整和定制,以便更好地满足解决方案。 但是,必须意识到这样做所牵涉的潜在持续维护问题。 在许多情况下,既不可能,也无必要确定 ISV 软件包内的组件内部流。 在此例中,ISV 组件应视为“黑匣”,即只显现和实现记述的服务。

属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息