1适用性
设计模式应该适用于任何一种系统，包括SOA，单独的桌面系统，实时控制系统，金融或是工程系统等。在实际设计过程中，当开始偏离模式时，设计模式应有助于开发人员进行往返设计。尽管设计模式是用类似于传统UML格式绘图来描述［8］，但它应该独立于特定的编程语言，框架，软件环境等。下面，将开始研究母线模式的特点。某一组件可能有一个来自于上一代版本系统中的祖先，它可能有单个后代或没有显示的派生出下一代。这种关系的具体实现方法并没有在母线模式中给出。例如，可以通过职责链模式或是拦截过滤来实现。某一特定的组件可能有两个或是两个以上的后代，也可能是在没有任何祖先的情况下作为新一代而产生。这种关系使得该设计模式变得更加有趣，但它并不会破坏母线模式。
2结构
这一部分将介绍母线模式的结构成分，图1通过典型方式描述了该设计模式的结构:(1)Client:客户是一个具体的系统或是组件，用来进行具体的实现操作，具体表现为提交某种请求，消息，或是方法调用等等。(2)Thetwogenerations:两代组件(纵向虚线分开)表示这种类似的关系可能会延续到很多代。(3)ThetwolineagesofParts:这两部分出现在每一代中，有类似关系的Part数量可能是任意多。在给定的一代中，一个Part可能有也可能没有直接的祖先。可能会有任意多此类的模块存在。一个“血统”包括一个Part模块以及该模块的所有祖先。(4)Part:一个Part是至少包含一个接口的类或是模块。接口用于完成具体的应用需求处理，其内部结构并没有限制。(5)Builder:在该设计模式中，Builder要比生成器模式更为一般化。它表示一种对象创建模式，并可能包含原型模式，装饰者模式，部分构造函数，工厂模式，适配器模式等等。可以通过桥接模式，代理模式或是其他的设计模式来实现。(6)Predecessor:祖先构件概念的引入帮助说明了职责链模式和过滤器链模式。一个重要的原则是组件不能引用它所派生对象，否则将会违反一代只能知道本身和它的父辈原则。(7)Resource:它本身就是一个Part。它像其他的部件一样可能因不同代而异，具体是实现方法也可能需要重新设计。
3参与者
应用母线模式构造的系统的主要参与者有:客户端可能有某种“代亲和力”，即对特定的一代兼容性有兴趣。或者可能有想要获得最新信息的意图。生产线的子系统在有无代亲和力的情况下都有可能被调用。当一个子系统受到代更新的影响时，就可以应用母线模式。
4初步研究
4.1可维护性问题的研究
下面列出应用设计模式中所遇到的典型问题，并讨论了初步的解决方案:(1)整个模块的复制和修改:当需要实现新的数值和方法时，开发人员可能会拷贝整个模块而不仅仅改变相关的属性和方法。在每一代，大量非常类似的代码会成为代码库的一部分。相应的结果是，出现很多版本的代码，并且无法决定目前正在使用的版本。(2)新一代直接替换旧一代:尽管一个或多个旧版本需要维持其目前的形式，开发人员试图有条件地改变逻辑块让模块做些不同操作。这会使代码变得难以控制。(3)改变数据库以满足新的需求:考虑在一种具有多代的特定模式下，数据库管理员(DBA)将主要的精力用于为新数据提供支持，而开发者则需要在老地方字段定义业务逻辑引用。(4)逻辑无序扩张:决策逻辑的增长趋向于出现在多个地方，而不是比较集中化。这在某种程度上降低了设计的可理解性，使得其他人难以维护和扩展。(5)修正了一处，破坏了另一处:为了适应新的需求，一个模块在更新的时候可能会被损坏，并且软件测试可能无法发现出现该问题。第一个问题的出现是由于不好的设计和可靠性差所导致的，这与可靠性度量标准相一致。为了适应新的需求或是去除已经不再需要的特性所做的操作将会导致失败几率的增长。但很显然，如果只是为了编码的便利而去复用以前版本的代码，失败的几率将会成倍增加。第二个问题会导致可靠性降低，当新的模块直接替换本来是作为祖先的模块时将会产生相同的效果。这不仅仅会增加新设计中失败的几率，还可能会导致上一代模块功能受损并无法检测。拷贝整个模块和替换旧的模块在一定程度上不兼容。首先，试图为新的一代保持干净的基线，这将会使维护的负担成倍增加。另一方面，如果不做任何拷贝，只是对代码库进行简单的修改，将会冒代码库被污染的风险。母线设计模式试图解决这种明显的冲突。拥有“血缘”的Part概念的提出可以使得设计得到优化，在特定的一代设计成员关系时，没有应用到新功能的部分将不再被拷贝。该部件可能需要相当精细的设计。粒度往往决定了整个大的模块是否需要被复制。对于粒度问题，母线模式允许分支［9］。图2中显示派生出两个Builder组件以满足新一代的新需求。PartB可以由两种路径的任一种来构造，但其具体的设计是不变的。这种分歧使得祖先对象一直停留在原地。也许未来的某些时刻，不再需要时可以将之直接从系统中移除。正确的部件构建者的加载不应该使用特设的编码策略，例如:给名称附加一个字母或数字等。这一方案解决了目前讨论的两个候选问题。旧的不再是被简单的覆盖，拷贝操作可能发生在构造新对象时，但也只局限于必须修改的部分。
4.2解决方案可靠性研究
母线模式提出了一种在一开始就创建一个高度可维护性设计的前景。或者，它可以用来辅助设计，让其变得更容易维护。这要求开发人员具有丰富的经验来确保有效性。在具体设计的过程中，相对于有效产出，失败机会显著增加。通过前面问题的论述可见一斑。因此需要一种简单的度量标准［10］，来衡量正在开发的系统的可维护性和可靠性［11］。母线模式在可靠性方面的实施措施并不是用来衡量该领域最终产品的性能。虽然这是软件可靠性通常的定义。文中给出了一种新的度量标准，用来衡量软件设计和维护的可靠性。它可以测试设计的特性，并可以用来预测系统开发、测试、维护状态的优劣。这种度量标准侧重于可能派遣错误的实现的数量，而不考虑具体的实现细节。将通过检验代码库和设计发现的有效派遣操作数量定义为v，并将失败机会的数量定义为f，将理想的可靠性度量标准定义为:R=v/f(1)这个简单的度量准则，能满足相关文献中的所有可靠性指标标准［12］。预测有效性:衡量标准(1)只侧重于设计符合规范的好坏程度。前提有效性:公式(1)的前提是知道v和f的值。软件测试可以被用来确定v的值，代码扫描将会给出f的值。适用性:该设计模式不依赖于某种编程语言或是系统类型。简单性:它很容易为人们所理解。可测试性:这种度量标准是基于可测试的基础上提出的，用来评估的元素是可以计数的。
5结束语
文中提出了一种设计模式，以解决跨应用程序中的并发代设计和软件维护问题。它适用于组件会按照代步骤进行演化的系统设计，系统组件需要同时支持多代和有代意识，以便客户可以选择具有代亲和力的选项。初步的研究表明，该设计模式提供了一些用于解决维护困难的初步方案。今后的工作将侧重于该设计模式在实际应用中的相关经验积累。
作者：赵冉 张代远 单位：南京邮电大学 计算机学院 江苏省无线传感网高技术研究重点实验室 南京邮电大学 计算机技术研究所
