任务:对子系统依赖关系建模
此任务通过特定于 SOA 解决方案的详细信息(特别是从业务分析模型确定子系统时)扩展了传统的 RUP 子系统设计。一旦进行从业务领域到 IT 域的转换,就要将业务领域所定义的已确定功能区域映射到子系统(即:它们的 IT 对等对象)。
用途

为了将业务模型与其 IT 对等对象相关联,需要执行下列操作:

关系
主要描述

一开始,我们确定并记录子系统之间的依赖关系,这些子系统对应于任务:功能区域分析期间已确定的功能区域。通常一个功能区域将对应于一个子系统,这是一个简化的假设,已证实对于许多(即使并非大多数)情况都正确。如果决定将一个功能区域映射到多个子系统,同样会是可行而有效的;然而,这通常意味着领域分解不够深入,功能区域的详细程度不够。

步骤
描述子系统依赖关系
目的 记录子系统所依赖的接口。 

当一个子系统所含的元素使用另一子系统所包含元素的某个行为时,封闭的子系统之间就建立了依赖关系。为了提高重用性并降低维护依赖关系,我们希望根据对子系统的特定接口的依赖关系来表示这一点,而不是根据对子系统本身或者对子系统中所包含元素的依赖关系来表示。

这样做的原因有两方面:

  • 我们希望模型元素(包括子系统)能互相替换,前提是它们提供相同的行为。我们根据接口来指定所要求的行为,因此一个模型元素对另一个模型元素的任何行为要求都应根据接口来表示。
  • 我们希望设计人员完全有自由设计子系统的内部行为,前提是它提供正确的外部行为。如果一个子系统中的模型元素引用另一个子系统中的模型元素,设计人员就不能再随意删除该模型元素,或者将该模型元素的行为重新分配给其他元素。结果,系统就变得更加脆弱。

创建依赖关系时,请确保子系统所包含的模型元素与其他子系统所包含的模型元素之间没有任何直接依赖关系或关联。还要确保各子系统和各接口之间没有循环的依赖关系;一个子系统不能既实现某一接口而又依赖于该接口。

如下所示,可以直接绘制出子系统之间以及子系统和包之间的依赖关系。 如果这样显示依赖关系,则说明一个子系统(例如“发票管理”)直接依赖于另一个子系统(“支付调度管理”)。


附带文本中描述的图。

使用直接依赖关系的子系统分层示例

当有可能将一个子系统替换为另一个子系统时(它们有相同的接口),依赖关系可以绘制到该子系统实现的一个接口,而不是绘制到子系统本身。这就允许使用任何实现相同接口的其他模型元素(子系统或类)。使用接口依赖关系,则允许使用可替代的设计元素来设计灵活的框架。


附带文本中描述的图。

使用接口依赖关系的子系统分层示例

 

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