任务:数据模型分析
本任务根据服务和分区确定面向服务的解决方案的设计元素,并记录那些服务的初始规范。
用途
  • 根据服务和分区确定面向服务的解决方案的设计元素。
  • 记录服务的初始规范。
  • 确定服务之间的初始依赖关系和通信。
关系
角色主要: 其他: 辅助:
输入必需: 可选: 外部:
输出
主要描述

本任务使用业务流程模型作为输入并确定包含在项目服务组合中的一组候选服务。 这些候选服务可能仍需要进一步改进,但此处包含的步骤提供了生成一组初始服务规范的有效方法。

步骤
从数据模型确定候选服务

对于大多数业务驱动的 IT 组织而言,了解和管理形式以复杂的工件:业务实体形式表示的数据是分析和设计解决方案的关键。 因此,许多解决方案将包含用于数据管理的服务,且服务的确定更侧重于工件:数据模型工件:业务分析模型。在为面向服务的解决方案重新设计应用程序时,必须根据现有的应用程序开发数据模型,这些应用程序应当是可用于确定可视为自主服务的相关子集。

如果创建企业范围的领域模型是具有很大价值的活动,该领域模型通常是对较完整逻辑数据模型的更高程度抽象(请参阅工件:数据模型),因此可能需要更有规则地进行维护。该领域模型表达了工件:业务实体方面的几个关键概念,并且可认为它代表了由业务组件或业务服务所管理的关键工件类型(请参阅概念:组件业务建模)。因此,将领域模型在逻辑上归为一组连续的依赖实体可以作为服务确定的起点 - 即将服务视为实体的所有者。 例如,请考虑以下领域模型片段。

我们可以看见该领域模型确定了一组业务实体,而这些实体分属两大业务能力:帐户和客户管理。虽然帐户和组织之间的确存在很重要的关系,但是这两种工件类型通常是分开处理的,而且倾向于以帐户或组织级别执行操作。随后我们按如下所示将领域模型的相关部分分配给 RUP 工件:业务系统(CBM 中的业务组件)。

虽然上图清楚地显示了相关工件类型的所有权的情况,但我们仍需进一步确定业务系统向组织提供的服务,具体到此示例中,就是为管理已确定工件类型而提供的服务。 因此,在提供的示例中,我们将实体“帐户”确定为“帐户管理”业务系统拥有的主工件,而将“客户”确定为“客户管理”系统拥有的主工件。 由此我们提供了一项能够对这些实体进行访问和更新的服务,如下图所示。

此外,这些服务规范只代表候选服务(请参阅工件:服务规范的状态属性)且正因为这样,需要使用它们提供的操作(具体而言就是允许更新实体的操作)的详细信息进行优化。

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