指南:可变性分析
可变性分析创建的模型可将领域模型中不断变化的方面与较稳定的方面区分开来。这将实现所预期类型的更改及其相应规则的具体化,并允许将来以无干扰的方式将更改引入现有设计。
关系
主要描述

简介

服务设计人员必须意识到,在制订工件:服务规范时,必须权衡两个具有竞争性的因素。

  • 专门化;需要确保服务按要求执行任务,实现在活动:现有资产分析期间确定的功能。
  • 一般化;需要确保服务尽可能可复用,因为未来需求不要求对现有服务进行重大的重新设计。

为实现此目标,设计人员可以使用通常称为“共性和可变性”分析的技术。一段时间以来,人们已了解并记录了这些技术,它们主要应用于模式构造 [Coplien, Gabriel] 和软件产品线工程 [GBS, JGBS01, JB02, MRR04, Parnas, SBM01] 方面。在这些方面,设计人员也应权衡模式中的这些因素 - 必须将可变性捕获为模式参数,以实现模式在不同情境中的适用性。

在模式文献中,[Coplien] 将共性描述为“抽象的本质”,可变性为“生活的调味品”,而 [Gabriel] 则更具体地描述了共性和抽象之间的关系 - 好的抽象需要捕获解决方案间的共性方面,同时指定各个元素的可变性

编程中的抽象是确定具有系统差异的公共模式的过程;抽象代表公共模式并提供一种方法来指定要使用的差异。

通过使用相似的术语,[Parnas] 基于集合的公共属性和各个成员的特殊属性,定义了系列程序(今天我们倾向于按软件产品线来描述):

我们将在值得从集合研究程序的情况下考虑组成系列的一组程序,方法是:首先研究集合的公共属性,然后确定系列中各个成员的特殊属性

捕获可变性

我们在构建很多系统时都几乎对并入新需求引起的更改没有任何远见。共性和可变性分析带来了弹性设计,该设计对更改的适应性要好得多。这一点是通过以下方式实现的:避免通过具体化过程对领域中预期会发生更改的方面进行硬编码或硬设计:将领域中更迅速变化的功能和结构方面与更稳定而不变的方面区分开来。此技术使系统设计能够在不受干扰性更改的情况下,由于新需求的出现而演进和发展。分析期间,按类型层次结构对共性和可变性进行建模。可变性的每一点均已确定和具体化。例如,可以将诸如 组织客户个人客户的差异实例建模为客户类型的两个实现,然后可按需求扩展这些实现。具体化的类型(例如,客户类型)与客户规则相关联,这些规则适用于所有客户,并且允许通过每种客户类型所适用的特定规则类型进行改进和扩展。

分析中第一步是从功能(静态)和流程(动态)透视图中确定对类型的依赖关系。确定依赖于实体类型(功能)的流程类型对设计重构是一个很好的启发:

  • 确定功能和流程的公共元素(例如,“预订”业务流程)。
  • 将不断变化的方面与较少变化的方面区分开来。确定与功能和流程相关的主要类型,这些类型预期将发生变化或依赖于其他类型(预订类型将因客户类型而异 - 如果客户类型发生变化,那么预订类型也会因此发生变化)。
  • 对于已知实例,将差异具体化,并创建类型层次结构(频率类型是期望或定期,代表方是组织或个人)。

可变性的这些特点将对构建弹性自适应系统起关键作用。通过将可变性特点具体化,可以对它们进行修改,而不影响设计的其余部分。因此,变更的连锁反应将由可变性特点进行限制和约束。显示此层次结构的 UML 类图为详细设计(并最终为实施)提供路线图。

因此,共性和可变性设计的基本原理是:

  1. 将领域中不断变化的方面与不变的方面区分开
  2. 使接口与实施相分离
  3. 将变化具体化。如果领域中某个元素不断变化,那么可能有必要将该元素具体化为类(或复用的更高层)。
  4. 在每个复用级别上构建资产。复用级别是:基类、继承层次结构、聚集层次结构、集群、框架、组件、模式和一般体系结构。
  5. 除了对用于服务能力运行时查询的复用元素进行反应性和适应性自我描述所需的元数据外,每个复用元素也都有自己的行为规则。

参考资料

[Arsanjani]    A. Arsanjani。Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules。Washington University 技术报告编号:wucs-00-29,学报“Pattern Languages of Program Design”,2000 年。

[Coplien]    J. O. Coplien。Multi-Paradigm Design for C++。Addison-Wesley Professional,1998 年,第一版。

[Gabriel]    R. P. Gabriel。Patterns of Software: Tales from the Software Community。Oxford University Press,1998 年。

[GBS]    J. van Gurp、J. Bosch 和 M. Svahnberg。Managing Variability in Software Product Lineshttp://citeseer.ist.psu.edu/568368.html

[GHJV]    E. Gamma、R. Helm、R. Johnson 和 J. Vlissides。Design Patterns。Addision-Wesley,1994 年。

[JGBS01]    J. van Gurp、J. Bosch 和 M. Svahnberg。On the notion of variability in software product lines。学报“2nd Working IEEE / IFIP Conference on Software Architecture (WICSA)”第 45--54 页。 IEEE Computer Society,2001 年。http://citeseer.ist.psu.edu/vangurp01notion.html

[JB02]    M. Jaring、J. Bosch:Representing Variability in Software Product Lines: A Case Study,加州圣地亚哥 Second Product Line Conference(SPLC-2),2002 年 8 月 19 日 - 22 日。http://citeseer.ist.psu.edu/jaring02representing.html

[MRR04]    Jurgen Meister、Ralf Reussner 和 Martin Rohde。Managing Product Line Variability by Patternshttp://se.informatik.uni-oldenburg.de/pubdb_files/pdf/ManagingProductLineVariabilityByPatterns-Final.pdf

[Parnas]    D. L. Parnas。On the Design and Development of Program Families。IEEE Transactions on Software Engineering, SE-2(1):1--9, 1976.

[SBM01]    A. Stephenson、D. Buttle 和 J. McDermid。Extending Commonality Analysis for Embedded Control System Families。2001 年 Computer Science 第 1951 卷中的讲稿。http://citeseer.ist.psu.edu/stephenson51extending.html

[SGB01]    M. Svahnberg、J. van Gurp 和 J. Bosch:A Taxonomy of Variability Realization Techniques,2001 年 6 月提交。http://citeseer.ist.psu.edu/svahnberg01taxonomy.html