可变性本身可采取许多不同形式,其中任何一种形式都可能是适用的,并且在某些情况下,给定的情境中存在多种形式。可变性的常见种类如下:
-
因类型而异的可变性 - 例如:在法律合同的示例中,可变性基于用来表示概念“代表方”的类型层次结构,这是很常见的形式,通过使用 UML 方便地描述为类图(如主要描述中所示)。
-
因角色而异的可变性 -
在此情况下,元素的类型通常是非实质的(或者至少重要性是其次的),它充当的角色才具有价值。通常可在模式开发中发现此类型的可变性,其中的模式适用的可能对象集合过于宽泛,因此只能按照所提供的元素所充当的角色来定义模式参数。
-
从属于实施的可变性 -
在此情况下,所提供的元素对于执行某一行为是必需的,因此该元素需要实施给定的接口(或者正式程度更高的协议)才能成为适用元素。在此类情形下,通常公共元素的容器描述接口,具有接口类型的模板参数,或者需要接口。
示例
下图说明了“因角色而异的可变性”概念,其中有一个新的协作“销售”,它指示了作为合同代表方的卖方和买方之间的关系。如果使用 UML,则可以创建“协作发生”,它将角色“买方”和“卖方”绑定到实际的模型元素。
或者,让我们查看使用 escrow 服务的销售过程。我们将 escrow 服务所需的能力捕获为一个接口,它带有一组与期望 escrow 服务履行的职责相对应的操作。这样我们就创建了一个模板协作,可在其中使用 escrow
接口作为模板参数的类型。现在可以通过提供实现 IEscrowService 接口的类或组件,对模板进行实例化。
最后,我们只需使用一个组件(或类)来包含公共元素,并通过 UML 2.0 <<use>> 关系使该组件(或类)要求 IEscrowService
接口,如下图所示。该方法在设计级别当然具有价值,因为它还是基于组件的开发(甚至是 Java 之类的语言)中的常用编程方法。
技术的选择通常将取决于情境(包括如下注意事项):
-
要表示的可变性的种类(如前所见)。
-
该元素是否为分析、设计或实施模型的一部分。
-
模型中的项目干系人的技能和经验。
|