目录
1、机制
2、框架
3、常用建模技术
3.1、对设计模式建模
3.2、对体系结构模式建模
用模式来详述形成系统体系结构的机制和框架。通过清晰地标识模式的槽、标签、按钮和刻度盘
在UML中，
对设计模式（也叫做机制）建模，将它们表示为协作。
将体系结构模式建模为框架，将它们表示为衍型化的包。
模式 （pattern）是对给定语境中共同问题的通用解决方案。
机制（mechanism）是应用于类群体的设计模式。
框架 （framework）是为领域中的应用系统提供可扩充模板的体系结构模式。
例如，如果正在建立一个用户密集型系统，一种经过考验的组织抽象的方法是使用模型——视图——控制器模式，用这种模式将对象（模型）和它们的表示（视图）以及协调二者同步工作的代理（控制器）清楚地分离开来。与此类似，如果是在建立一个破解密码的系统，一种经过考验的组织系统的方法是使用黑板体系结构，它很适合以机会主义的方式来解决难处理的问题。
1、机制
机制只是应用于类群体的设计模式的一个别名。
1）第一种方式：一个机制仅仅是为一组共同工作来完成一些共同而有意义的行为的抽象指定一个名称。因为它只是对类的群体命名，所以可将它建模为简单的协作。展开这个协作，可以看到它的结构方面（通常用类图表示）和行为方面（通常用交互图表示）。像这样的协作将交叉引用系统中的个体抽象；一个给定的类可能成为多个协作的成员。
2）第二种方式：一个机制是给一组共同工作来完成公共而有意义的行为的抽象指定一个模板的名称。可以将这种机制建模为参数化协作，它在UML中的画法与模板类的画法相似。展开协作，可以看到它的结构方面和行为方面。
压缩协作，可以看到模式是如何将协作的模板部件和系统中存在的抽象绑定在一起而应用于系统的。将机制建模为参数化协作时，要标识一些选项，如槽、标签、按钮和刻度盘等，利用这些选项通过模板的参数来调整模式。像这样的协作可以绑定到不同的抽象集而在系统中反复出现。在这个例子中，模式的Subject 和Observer类分别与具体类CallQueue和SliderBar绑定。
2、框架
框架是为一个领域中的应用系统提供可扩充模板的体系结构模式。
例如，在实时系统中一种常见的体系结构模式是循环执行模式，它将时间划分为一些帧和子帧，其间的处理要在严格的期限内发生。
框架比机制的规模大。
在UML中，把框架建模为衍型化的包。展开包，看到存在于系统体系结构的各个视图中的机制。
下图描述了一个名为CyclicExecutive的框架。此框架有一个包含一组事件类的协作（CommonEvents）和一个以循环的方式处理这些事件的机制（EventHandler）。在这个框架上进行构造的客户（如Pacemaker），可以通过建立子类而使用CommonEvents中的抽象，并且也能应用EventHandler机制的实例。
3、常用建模技术
3.1、对设计模式建模
从外部看，设计模式被表示成一个参数化协作。作为协作，模式提供了一组抽象，其结构和行为共同工作，以完成一些有用的功能。协作的参数命名了该模式的用户必须绑定的元素。这使得设计模式成为一个模板，通过提供与模板参数相匹配的元素来将它用于特定的语境。
从内部看，设计模式只是一个协作，用它的结构部分和行为部分表示。通常可以用一组类图（结构方面）和一组交互图（行为方面）对这种协作的内部建模。协作的参数命名了其中一些结构元素，当设计模式被绑定到具体语境中时，就被来自该语境的抽象实例化。
下图表示命令模式“将请求封装成对象，从而可以用不同的请求（队列或日志请求）将客户参数化，并支持可以取消的操作”。
在每种情况下必须
把参数 AbstractCommand 绑定到同一个抽象超类。
在不同的绑定中，把参数 ConcreteCommand 绑定到不同的特殊类；
把参数 Receiver 绑定到该命令作用于其上的类。
类Command可以由模式创建，但是把它作为一个允许创建多个命令层次的参数。
下图表示该设计模式的类图。使用被命名为模式参数的类。
下图表示命令模式的顺序图
3.2、对体系结构模式建模
框架实际上就是对体系结构的描述，尽管它是不完整的而且可能是参数化的。
下图给出了Blackboard（黑板）体系结构模式的规约，这个模式“解决了那些从原始数据转换为高层数据结构时没有可行的确定性的解决方案的问题”。
这个体系结构的核心是Blackboard（黑板）设计模式，它规定了KnowledgeSources（知识源）、Blackboard（黑板）和Controller（控制器）如何协作。
这个框架中还包含设计模式Reasoning engine（推理引擎），它描述了每个KnowledgeSource如何被驱动。
最后，这个框架还显示了一个用况，即Apply newknowledge sources（应用新知识源），它解释客户如何去调整框架本身。
