任务:创建组件类图
本任务指定了实现设计子系统的服务组件的详细信息。
用途

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

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

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

步骤
模型组件内部结构

在此活动中,重点是创建至少一个显示每个服务组件的功能组件与技术组件之间关系的类图。 标准的 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.

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