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

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

步骤
从业务用例确定候选服务

在较传统的基于组件和面向对象的解决方案开发中,倾向于有一组跨多个抽象级别的转换,并且自上而下将详细级别从用例添加到系统设计中。 在如指南:从业务模型到系统中展示的那样(该指南展示了如何从业务用例转为系统用例,我们仍然必须据此开发一个实际的设计模型),将业务用例用作起点的情况下尤其如此。

幸运的是,我们还可以在定义如何从业务用例模型派生出服务模型时,将指南提供的并行添加到系统用例中(如上所示)。 通常而言,此方法用于为工件:业务分析模型中的工件:业务工作者中定义的每个操作创建候选服务。此处与任务:业务流程分析截然不同,在业务流程分析中,流程模型中的单个任务被确定为候选服务。

文本内容中所述的图。

业务分析模型和服务模型之间的这个更直接的连接不仅使服务能够支持业务需要,还减少了业务需要和解决方案的表达之间的转换,从而使我们能够更有效地对业务用例或分析模型中的更改作出回应。 另一个重要方面是业务用例模型还包含驱动业务的业务目标,因此现今在服务和目标之间实现协调将容易得多。 例如,现在可以列出任何服务规范所要实现的所有业务目标。 对于任何业务目标,按照从服务到服务规范的连接,我们都可以列出负责实现该目标的 IT 组织中已实际部署的服务。

优化候选服务规范

某些情况下,业务用例实现中定义的一组操作可能更准确地反映与单一服务相关的各方之间的对话(相对于一组完全不同的服务);在这种情况下,操作可能被聚集到一个单一服务规范(如下所示)。 此方法的缺点是必须更详细地分析和了解用例实现,以及用例实现中工作者的角色,以便将此确定为需求。

至于提到的“对话”,通常的意思是服务的实际完成需要各方之间的多次交互,例如,如果对服务“安排顺序”进行检验,我们实际上可能会发现这是包含确认、装运声明、否定(例如,如果商品不可用)在内的一组复杂的交互,可能如下图中所示。


 

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