任务:执行面向差异的设计
此任务适用于许多分析和设计元素,剔除此类元素中的可变性因素并计入共性因素将得到健壮性和灵活性更好的结果。
用途

分析所提供的模型元素,并确定这些元素中有哪些是公共于不同的应用程序的,并将这些公共元素与因应用程序而异的那些元素区分开来。通过确定这些因应用程序而异的元素,我们就能够显式地对各种可变性建模,并为模型元素的客户记录它们。

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

此任务可应用于任何分析或设计模型,只要模型中的元素可从此处所述的技术中获益。这些技术是从产品线工程和模式开发的经验中衍生的:产品线工程中的公共元素将产品线中的产品联合在一起,可变性将产品彼此区分开;模式开发中的公共元素是模式的结构,可变性用于定义模式参数。

该方法首先确定公共于所有应用程序的设计元素,然后确定因每个应用程序而异的元素,最后记录可变性(此处不同领域使用不同的方法)。

示例

在下面的类图中,我们将看到法律合同中的各个元素,可以确定这是双方或多方之间的合同。确定公共元素时,我们可以看到:核心元素是合同本身的结构以及与各方之间的不同关系。

然而,法律合同可以是不同的人员、组织或政府和机构之间的合同,因此我们注意到“代表方”是一个因类型而异的可变元素。记录这一点时,我们为“代表方”定义了类型层次结构,并将“代表方”指定为抽象类,这样在实际设计中必须使用具体类型。

步骤
确定公共元素和可变元素

确定设计中不因情境而异的元素通常是通过迭代方式得到最好执行的。通过一组场景创建实例图,并在比较不同场景的实例图时记录哪些元素在所有情况下都是相同的。可使用的场景越多,那么显然可用的数据点也越多,因此能够对早期结果和假设进行验证。

描述模型中的公共元素时,通常有必要提供某种形式的封装元素,以将这些元素与设计中的其余元素区分开。可选的封装技术显然依赖于上下文,但有可能:

  • 引入一个程序包来拥有这些元素,这只更改元素的所有权,而不会更改这些元素之间或程序包外元素之间的关系 - 这最常应用于分析模型。
  • 引入一个组件来拥有这些元素,这不仅更改所有权,而且还引入了正式的封装,因此可选择定义一个接口以将相关元素显现给外部。
  • 引入 UML 2.0 协作,使得能够将公共元素定义为协作组合结构的一部分,并将可变元素定义为角色;随后将会作出从可变元素角色到具体元素的绑定。这是通过 UML 定义设计模式的常用方法。请注意:协作不拥有元素本身,只有与元素相对应的角色才拥有元素。
  • 引入模板类,其中模板对应于可变元素的类型,这是支持类属编程的 Ada、C++、Eiffel 以及当前的 Java 等语言的常用方法。
  • 您只需选择使用一种直观的提示。例如,常见的情况是使用一个图(如主要描述中所示)并对公共元素和可变元素填上不同颜色。

示例

在法律合同的示例中,我们选择引入一个组件来拥有这些元素,如下图所示。

记录可变性形式

可变性本身可采取许多不同形式,其中任何一种形式都可能是适用的,并且在某些情况下,给定的情境中存在多种形式。可变性的常见种类如下:

  • 因类型而异的可变性 - 例如:在法律合同的示例中,可变性基于用来表示概念“代表方”的类型层次结构,这是很常见的形式,通过使用 UML 方便地描述为类图(如主要描述中所示)。
  • 因角色而异的可变性 - 在此情况下,元素的类型通常是非实质的(或者至少重要性是其次的),它充当的角色才具有价值。通常可在模式开发中发现此类型的可变性,其中的模式适用的可能对象集合过于宽泛,因此只能按照所提供的元素所充当的角色来定义模式参数。
  • 从属于实施的可变性 - 在此情况下,所提供的元素对于执行某一行为是必需的,因此该元素需要实施给定的接口(或者正式程度更高的协议)才能成为适用元素。在此类情形下,通常公共元素的容器描述接口,具有接口类型的模板参数,或者需要接口。

示例

下图说明了“因角色而异的可变性”概念,其中有一个新的协作“销售”,它指示了作为合同代表方的卖方和买方之间的关系。如果使用 UML,则可以创建“协作发生”,它将角色“买方”和“卖方”绑定到实际的模型元素。

或者,让我们查看使用 escrow 服务的销售过程。我们将 escrow 服务所需的能力捕获为一个接口,它带有一组与期望 escrow 服务履行的职责相对应的操作。这样我们就创建了一个模板协作,可在其中使用 escrow 接口作为模板参数的类型。现在可以通过提供实现 IEscrowService 接口的类或组件,对模板进行实例化。

最后,我们只需使用一个组件(或类)来包含公共元素,并通过 UML 2.0 <<use>> 关系使该组件(或类)要求 IEscrowService 接口,如下图所示。该方法在设计级别当然具有价值,因为它还是基于组件的开发(甚至是 Java 之类的语言)中的常用编程方法。

技术的选择通常将取决于情境(包括如下注意事项):

  • 要表示的可变性的种类(如前所见)。
  • 该元素是否为分析、设计或实施模型的一部分。
  • 模型中的项目干系人的技能和经验。

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