UML系列文章（29）体系结构建模---模式和框架

本章内容：

• 模式和框架
• 对设计模式建模
• 对体系结构模式建模
• 使模式可应用

所有结构良好的系统都充满了模式。模式为给定语境中的共同问题提供了一个好的解决方案。机制是应用于类群体的设计模式，框架通常是为领域中的应用系统提供可扩展模板的体系结构模式。

用模式来详细说明形成系统体系结构的机制和框架。通过清楚地标识模式的槽、标签、刻度盘，可以使模式易于使用。

1. 入门

想一想把一堆木头组装起来建造房子的种种方式真有点让人惊异。在A地的专业建筑师手中，这堆木头变成A地格调的房子；在B地的建筑师手中，同样一堆木头，却变成了B地格调的房子。

从外在看，两种房子代表了截然不同的建筑风格。每个建筑师都从自己的经验出发，选择自己认为最适合客户的风格，然后按客户的愿望和建筑地点与地方法规的限制来调整其风格。

从内部看，每个建筑师都必须在设计房子时解决一些共同的问题。解决桁架支撑屋顶的问题就有许多已被证实有效的方法，也有许多经过验证的方法可以用来设计如何在承重墙上开窗户和门。每个建筑师都要选择合适的机制解决这些公共问题，然后根据总体建筑风格和地方性建筑限制去调整这些机制。

建立一个软件密集型系统也是这样。每当以高于代码行的眼光看问题时，会发现一些能够决定以何种方式来组织类或者其他抽象的通用机制。例如，在事件驱动的系统中，使用责任链设计模式是一种组织事件处理程序的通用方法。把眼光放得比这些机制再高一些，会发现一些形成整个系统体系结构的通用框架。例如，在信息系统中，使用三层体系结构是清晰地隔离系统的用户界面、它的永久信息和它的业务对象及规则三者之间关注点的通用处理方法。

    在UML中，通常要对设计模式（也叫机制）建模，将它们表示为协作。类似地、通常将体系结构模式建模为框架，将它们表示为衍型化的包。

2. 术语和概念

    模式（pattern）是对给定语境中共同问题的通用解决方案。机制（mechanism）是应用于一组类的设计模式。框架（framework）是为领域中的应用系统提供可扩充模板的体系结构模式。

2.1 模式和体系结构

    不管是在建筑一个新系统，还是对一个已有的系统进行演化，都不需要真正从头开始。经验和习惯会引导你使用通用的方法去解决常见的问题。例如，如果正在建立一个用户密集型系统，一种经过考验的组织抽象的方法是使用模型-视图-控制器模式，用这种模式将对象和它们的表示（视图）以及协调二者同步工作的代理（控制器）清楚地分离开来。与此类似，如果是在建立一个破解密码的系统，一种经过考验的组织系统的方法是使用黑板体系结构，它很适合以机会主义的方式来解决处理的问题。

    上面两个都是模式的例子。在结构良好的系统中，可以在不同抽象层次上发现很多模式。设计模式描述了类群体的结构和行为，而体系结构模式描述了整个系统的结构和行为。

    因为模式是开发人员的词汇表中的重要部分，所以UML引入了模式的概念。在系统模型中显式地采用模式，可以使系统更易于理解，更易于演化，也更易于维护。例如，如果有人给你一堆陌生的源码并要求扩充其功能，你要费尽力气视图去理解它们如何在一起配合工作的。相反，若果给你同样的源码，并告诉你“这些类之间是采用发布-订阅模式”，你将很快地找到理解其如何工作的正确途径。对于整个系统也是这样。告诉你“这个系统是用一组管道和过滤器组织的”， 就解释了关于系统体系结构的许多细节。否则，如果只从孤立地类开始去理解，那就困难得多了。

    模式有助于可视化、详述、构造和文档化软件密集型系统的制品。可以选择一组合适的模式，并将它们应用到特定领域的抽象中以进行系统的正向工程；也可以通过寻找系统中所包含的模式进行逆向工程，尽管它还不是一个完善的过程。更好的是，当提交一个系统时，可以说明其中采用的模式，这样当某些人将来需要对系统进行复用和调整时，这些模式就清楚地呈现出来。

    在实际应用中，有两种模式经常被用到，即设计模式和框架，UML提供了对这两类模式建模的方法。当对这两类模式建模时，会发现它们在一个较大的包的语境中通常是独立存在的，只是通过依赖关系与系统的其他部分相联系。

2.2 机制

    机制只是应用于类群体的设计模式的一个别名。比如对一个知道如何响应一组事件的类进行调整，使之能在不替换原来类的前提下响应另一组稍有不同的事件。解决这个问题的一般采用适配器模式（adaptor），它是将一种将一个接口转换为另一个接口的结构设计模式。

建模时，这些机制有两种显示方式

1）如上图所示，一个机制仅仅是为一组共同工作来完成一些共同而有意义的行为的抽象指定一个名称。因为它只是对类的群体命名，所以可将它建模为简单的协作。

2）如下图所示，

 

    一个机制是给一组共同工作来完成共同而有意义的行为的抽象指定一个模板的名称。可以将这种机制建模为参数化协作，它在UML中的画法与模板相似。展开协作，可以看到它的结构方面和行为方面。压缩协作，可以看到模式是如何将协作的模板部件和系统中存在的抽象绑定在一起而应用于系统的。将机制建模为参数化协作时，要标识一些选项，如槽、标签、按钮和刻度盘等，利用这些选项通过模板的参数来调整模式。 

2.3 框架

    框架是为一个领域中的应用系统提供可扩展模板的体系结构模式。例如，在实时系统中一种常见的体系结构模式是循环执行模式，它将时间划分为一些帧和子帧，期间的处理要在严格地期限内发生。

    在UML中，把框架建模为衍型化的包。展开包，可以看到存在于系统体系结构的各个视图的机制。例如，不仅可以看到参数化协作，也可以看到用况（用来解释如何应用框架）以及简单协作（提供一组可以在其上构造的抽象---如通过子类）。

 

3. 常用建模技术

3.1 对设计模式建模

 

 

 

3.2 对体系结构模式建模

     使用模式的另一种情况是对体系结构模式建模。当为这样一个框架建模时，实际上是在对预计要在某些语境中复用和调整的系统整体体系结构的基础结构建模。

    框架被表示成一个衍型化的包。作为包，框架提供了一组元素。这些元素包括（但不限于）类、接口、用况、构件、结点、协作、甚至可以是其他框架。事实上，可以把共同工作来为一个领域中应用系统提供可扩充模板的所有抽象放在一个框架中。

对体系结构模式建模时，要遵循如下策略：

• 从已被证明有效的现存体系结构中获取框架
• 将框架建模为衍型化的包，其中包括对描述框架的各种视图是充分而又必要的所有元素。
• 显示对于调整以设计模式和协作的形式存在的框架所必要的插件、接口和参数。多少情况下，这意味着要使模式得1用户清楚哪些类必须被扩展、哪些操作必须被实现以及哪些信号必须被处理。

下图是黑板体系结构模式。

 

4. 提示和技巧

    当用UML对模式建模时，它们工作在从个体类到整个系统外形的很多抽象层次上。机制和框架是最令人感兴趣的两种模式。

一个结构良好的模式，应满足如下的要求：

• 以通用的方式来解决普遍的问题。
• 包括结构和行为两方面。
• 显露要进行调整以运用与某种语境的槽、标签、按钮和刻度盘。
• 是原子的，即不容易再分成更小的模式。
• 倾向于直接引用对系统中的个体抽象。

当用UML绘制一个模式时，要遵循如下策略：

• 显露在语境中必须调整的模式的元素。
• 提供使用和调整模式的用况。