软件架构与软件模式（部分内容） [转帖]
20 views
Skip to first unread message
Leo
May 4, 2008, 3:10:01 AM5/4/08
to 中国架构师联盟
一、什么是架构
软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在发展期，
对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同
理解，以下是一些主流的标准观点。
ANSI/IEEE 610.12-1990软件工程标准词汇对于体系结构定义是：“体系架构是以构件、构
件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计
与演化的原理(principle)”。
Mary Shaw和David Garlan认为软件体系结构是软件设计过程中，超越计算中的算法设计和数据结构设计的一个层次。体系结构问题包
括各个方面的组织和全局控制结构，通信协 议、同
步，数据存储，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案之间进
行选择。Garlan & Shaw模型[1]的基本思想是：软件体系结构={构件(component) ，连接件
(connector)，约束(constrain)}．其中构件可以是一组代码，如程序的 模块；也可以是一个独立
的程序，如数据库服务器。连接件可以是过程调用、管道、远程过程调用(RPC)等，用于表示构
件之间的相互作用。约束一般为对象连 接时的规则，或指明构件连接的形式和条件，例如，上
层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性
约束；什么条 件下此种连接无效等。关于架构的定义还有很多其他观点，比如Bass定义、
Booch & Rumbaugh &Jacobson定义、Perry & Wolf模型[7]、Boehm模型等等，虽然各种定义关
键架构的角度不同，研究对象也略有侧重，但其核心的内容都是软件系统的结构，其中以Garlan & Shaw模型为代表，强调了体系结构的基本要素是
构件、连接件及其约束（或者连接语义），这
些定义大部分是从构造的角度来甚至软件体系结构，而IEEE的定义不仅强调了系统的基本组成，
同时强调了体系结构的环境即和外界的交互。
二、什么是模式
模式（Pattern）的概念最早由建筑大师Christopher Alexander于二十世纪七十年代提出，应用于建筑领域，八十年代中期由
Ward Cunningham和Kent Beck将其思想引入到软件领域，
Christopher Alexander将模式分为三个部分：首先是周境（Context，也可以称着上下文），指模
式在何种状况下发生作用；其二是动机（System of Forces）,意指问题或预期的目标；其三是解
决方案（Solution）,指平衡各动机或解决所阐述问题的一个构造或配置 （Configuration）。他提
出，模式是表示周境、动机、解决方案三个方面关系的一个规则，每个模式描述了一个在某种周
境下不断重复发生的问题，以及该问题解决方案的核心所在，模式即是一个事物（thing）又是一
个过程(process)，不仅描述该事物本身，而且提出了通过怎样的过程来产生该事物。这一定义已
被软件界广为接受。软件模式的应用对软件开发产生了重大的作用，主要表现在：
* 软件模式是人们在长期的设计软件、管理组织软件开发等实践中大量经验的提炼和抽象，
是复用软件设计方法、过程管理经验的有力工具。模式类似于拳击中的组合拳，它提供了一系列
软件开发中的思维套路。如，通过模式的使用，有利于在复杂的系统中产生简洁、精巧的设计。
* 软件模式为我们提供了一套简洁通用的设计、管理、组织方面的词汇，同时模式也为我们
提供了一个描述抽象事物的规范标准，可大大促进软件开发过程中人与人之间的交流，而软件开
发中的交流是至关重要的，"软件项目失败的原因最终都可追溯到信息没有及时准确地传递到应该
接收它的人"。
三、架构和模式的关系
因为架构(Architecture)和模式(Pattern)在当前的软件开发中经常地被提及，可是很多人容易
混淆这两个术语，而对此，学术界也没有一个非常统一的定义。
架构和模式应该是一个属于相互涵盖的过程，但是总体来说Architecture更加关注的是所谓的
High-Level Design，而模式关注的重点在于通过经验提取的“准则或指导方案”在设计中的应
用，因此在不同层面考虑问题的时候就形成了不同问题域上的 Pattern。模式的目标是，把共通
问题中的不变部分和变化部分分离出来。不变的部分，就构成了模式， 因此，模式是一个经验
提取的“准则”，并且在一次一次的实践中得到验证，在不同的层次有不同的模式，小到语言实
现(如Singleton)大到架构。在不同的层面上，模式提供不同层面的指导。根据处理问题的粒度不
同，从高到低，模式分为3个层次：架构模式（Architectural Pattern）、设计模式（Design Pattern）、实现模式
（Implementation Pattern）。架构模式是模式中的最高层次，描述软件系
统里的基本的结构组织或纲要，通常提供一组事先定义好的子系统，指定它们的责任，并给出把
它们组织在一起的法则和指南。比如，用户和文件系统安全策略模型，N-层结构，组件对象服务
等，我们熟知的MVC结构也属于架构模式的层次。一个架构模式常常可以分解成很多个设计模式
的联合使用。设计模式是模式中的第二层次，用来处理程序设计中反复出现的问题。例如，
[GOF95][2]总结的23个基本设计模式——Factory Pattern, Observer Pattern等等。实现模式是最
低也是最具体的层次，处理具体到编程语言的问题。比如，类名，变量名，函数名的命名规则；
异常处理的规则等等。相对于系统分析或者设计模式来说，体系结构从更高的层面去考虑问题，
所以关注的问题就体现在“不变”因素上，比如系统部署中，更加关心应用程序的分层分级设
计，而在这个基础之上提出的部署方案，才是架构考虑的重点。体系结构关心应用程序模式，更
加体现在通过技术去解决这些业务差异带来的影响，关心是否是分布式应用程序，关心系统分层是如何设计，也关心性能和安全，因此在这样的情况之下，会考虑
集群，负载平衡，故障迁移等等一系列技术。希望通过定义的方式来区分架构和模式是不太可能的，因为本来就是交互交叉和
提供服务的，它实际上是架构模式，而不是设计模式。在大部份情况下， 表现为下面几个设计
模式之一：Strategy模式、Mediator模式、Composite模式、Observer模式。对于熟悉架构设计的
系统架构师而言，似乎可以用如下来解释架构和模式之间的关系：架构是Hight-Level Design，着
眼于不同业务中共性的解决方案，而模式是General Principle(通用原理)。
四、企业解决方案的构建模式
企业级业务解决方案是公司实现其业务的赌注，它们通常极其复杂，而且性能必须不负众
望。它们不仅必须具有高可用性和伸缩性以应对不可预知的使 用，而且还必须具有适应性和预
见性以适应快速变化的业务要求。最佳解决方案是那些由一组更小的、简单的、能够可靠且有效
地解决简单问题的机制组成的解决方案。在构建更大、更复杂的系统过程中，将这些简单的机制
组合在一起，从而形成更大的系统。对这些简单机制的认识来之不易。它通常存在于有经验的开
发人员和体系结构设计者的头脑中，并且是他们潜意识中自然带到项目中的重要知识。
模式对于开发人员和体系结构设计者非常有用，因为它们：
* 记录能够正常工作的简单机制。
* 为开发人员和体系结构设计者提供通用的词汇和分类法。
* 允许以模式组合的方式简明扼要地描述方案。
* 允许重复使用体系结构、设计和实现决策。
五、模式可以记录简单机制
模式描述给定上下文中反复出现的问题，并基于一组指导性影响因素来建议解决方案。解决
方案通常是一种简单的机制，是为了解决模式中所标示出的问题而一起工作的两个或多个类、对
象、服务、进程、线程、组件或节点之间的协作。
您正在构建一个报价应用程序，其中有一个类负责管理系统中的所有报价。很重要的一点
是，所有报价都应与该类的一个（而且只与一个）实例进行交互。如何构造您的设计，以便从该
应用程序中只能访问该类的一个实例？
解决该问题最简单的方案就是创建一个具有私用构造函数的QuoteManager类，以便任何其
他类都不能实例化它。此类包含QuoteManager的一个静态实例，并使用名为GetInstance()的静
态方法返回。此代码大体如下所示：
public class QuoteManager
{
//注意：仅适用于单线程应用程序
private static QuoteManager _Instance = null;
private QuoteManager() {}
public static QuoteManager GetInstance()
{
if (_Instance==null)
{
_Instance = new QuoteManager ();
}
return _Instance;
}
//... QuoteManager提供的函数
}
您可能已经像其他许多开发人员那样通过类似的方式解决过类似的问题。实际上，注意反复出现
的问题并寻求解决方案的模式作者已经屡次发现了这种实现，提取出了通用解决方案并将这种问
题-解决方案对称为Singleton模式[GOF95]。
... ...
----------------------------------------------------------------------------------------------------------------------------------------
发帖说明：这里整合了部分内容，完整内容参见文件“软件架构与软件模式.doc ”
软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在发展期，
对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同
理解，以下是一些主流的标准观点。
ANSI/IEEE 610.12-1990软件工程标准词汇对于体系结构定义是：“体系架构是以构件、构
件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计
与演化的原理(principle)”。
Mary Shaw和David Garlan认为软件体系结构是软件设计过程中，超越计算中的算法设计和数据结构设计的一个层次。体系结构问题包
括各个方面的组织和全局控制结构，通信协 议、同
步，数据存储，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案之间进
行选择。Garlan & Shaw模型[1]的基本思想是：软件体系结构={构件(component) ，连接件
(connector)，约束(constrain)}．其中构件可以是一组代码，如程序的 模块；也可以是一个独立
的程序，如数据库服务器。连接件可以是过程调用、管道、远程过程调用(RPC)等，用于表示构
件之间的相互作用。约束一般为对象连 接时的规则，或指明构件连接的形式和条件，例如，上
层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性
约束；什么条 件下此种连接无效等。关于架构的定义还有很多其他观点，比如Bass定义、
Booch & Rumbaugh &Jacobson定义、Perry & Wolf模型[7]、Boehm模型等等，虽然各种定义关
键架构的角度不同，研究对象也略有侧重，但其核心的内容都是软件系统的结构，其中以Garlan & Shaw模型为代表，强调了体系结构的基本要素是
构件、连接件及其约束（或者连接语义），这
些定义大部分是从构造的角度来甚至软件体系结构，而IEEE的定义不仅强调了系统的基本组成，
同时强调了体系结构的环境即和外界的交互。
二、什么是模式
模式（Pattern）的概念最早由建筑大师Christopher Alexander于二十世纪七十年代提出，应用于建筑领域，八十年代中期由
Ward Cunningham和Kent Beck将其思想引入到软件领域，
Christopher Alexander将模式分为三个部分：首先是周境（Context，也可以称着上下文），指模
式在何种状况下发生作用；其二是动机（System of Forces）,意指问题或预期的目标；其三是解
决方案（Solution）,指平衡各动机或解决所阐述问题的一个构造或配置 （Configuration）。他提
出，模式是表示周境、动机、解决方案三个方面关系的一个规则，每个模式描述了一个在某种周
境下不断重复发生的问题，以及该问题解决方案的核心所在，模式即是一个事物（thing）又是一
个过程(process)，不仅描述该事物本身，而且提出了通过怎样的过程来产生该事物。这一定义已
被软件界广为接受。软件模式的应用对软件开发产生了重大的作用，主要表现在：
* 软件模式是人们在长期的设计软件、管理组织软件开发等实践中大量经验的提炼和抽象，
是复用软件设计方法、过程管理经验的有力工具。模式类似于拳击中的组合拳，它提供了一系列
软件开发中的思维套路。如，通过模式的使用，有利于在复杂的系统中产生简洁、精巧的设计。
* 软件模式为我们提供了一套简洁通用的设计、管理、组织方面的词汇，同时模式也为我们
提供了一个描述抽象事物的规范标准，可大大促进软件开发过程中人与人之间的交流，而软件开
发中的交流是至关重要的，"软件项目失败的原因最终都可追溯到信息没有及时准确地传递到应该
接收它的人"。
三、架构和模式的关系
因为架构(Architecture)和模式(Pattern)在当前的软件开发中经常地被提及，可是很多人容易
混淆这两个术语，而对此，学术界也没有一个非常统一的定义。
架构和模式应该是一个属于相互涵盖的过程，但是总体来说Architecture更加关注的是所谓的
High-Level Design，而模式关注的重点在于通过经验提取的“准则或指导方案”在设计中的应
用，因此在不同层面考虑问题的时候就形成了不同问题域上的 Pattern。模式的目标是，把共通
问题中的不变部分和变化部分分离出来。不变的部分，就构成了模式， 因此，模式是一个经验
提取的“准则”，并且在一次一次的实践中得到验证，在不同的层次有不同的模式，小到语言实
现(如Singleton)大到架构。在不同的层面上，模式提供不同层面的指导。根据处理问题的粒度不
同，从高到低，模式分为3个层次：架构模式（Architectural Pattern）、设计模式（Design Pattern）、实现模式
（Implementation Pattern）。架构模式是模式中的最高层次，描述软件系
统里的基本的结构组织或纲要，通常提供一组事先定义好的子系统，指定它们的责任，并给出把
它们组织在一起的法则和指南。比如，用户和文件系统安全策略模型，N-层结构，组件对象服务
等，我们熟知的MVC结构也属于架构模式的层次。一个架构模式常常可以分解成很多个设计模式
的联合使用。设计模式是模式中的第二层次，用来处理程序设计中反复出现的问题。例如，
[GOF95][2]总结的23个基本设计模式——Factory Pattern, Observer Pattern等等。实现模式是最
低也是最具体的层次，处理具体到编程语言的问题。比如，类名，变量名，函数名的命名规则；
异常处理的规则等等。相对于系统分析或者设计模式来说，体系结构从更高的层面去考虑问题，
所以关注的问题就体现在“不变”因素上，比如系统部署中，更加关心应用程序的分层分级设
计，而在这个基础之上提出的部署方案，才是架构考虑的重点。体系结构关心应用程序模式，更
加体现在通过技术去解决这些业务差异带来的影响，关心是否是分布式应用程序，关心系统分层是如何设计，也关心性能和安全，因此在这样的情况之下，会考虑
集群，负载平衡，故障迁移等等一系列技术。希望通过定义的方式来区分架构和模式是不太可能的，因为本来就是交互交叉和
提供服务的，它实际上是架构模式，而不是设计模式。在大部份情况下， 表现为下面几个设计
模式之一：Strategy模式、Mediator模式、Composite模式、Observer模式。对于熟悉架构设计的
系统架构师而言，似乎可以用如下来解释架构和模式之间的关系：架构是Hight-Level Design，着
眼于不同业务中共性的解决方案，而模式是General Principle(通用原理)。
四、企业解决方案的构建模式
企业级业务解决方案是公司实现其业务的赌注，它们通常极其复杂，而且性能必须不负众
望。它们不仅必须具有高可用性和伸缩性以应对不可预知的使 用，而且还必须具有适应性和预
见性以适应快速变化的业务要求。最佳解决方案是那些由一组更小的、简单的、能够可靠且有效
地解决简单问题的机制组成的解决方案。在构建更大、更复杂的系统过程中，将这些简单的机制
组合在一起，从而形成更大的系统。对这些简单机制的认识来之不易。它通常存在于有经验的开
发人员和体系结构设计者的头脑中，并且是他们潜意识中自然带到项目中的重要知识。
模式对于开发人员和体系结构设计者非常有用，因为它们：
* 记录能够正常工作的简单机制。
* 为开发人员和体系结构设计者提供通用的词汇和分类法。
* 允许以模式组合的方式简明扼要地描述方案。
* 允许重复使用体系结构、设计和实现决策。
五、模式可以记录简单机制
模式描述给定上下文中反复出现的问题，并基于一组指导性影响因素来建议解决方案。解决
方案通常是一种简单的机制，是为了解决模式中所标示出的问题而一起工作的两个或多个类、对
象、服务、进程、线程、组件或节点之间的协作。
您正在构建一个报价应用程序，其中有一个类负责管理系统中的所有报价。很重要的一点
是，所有报价都应与该类的一个（而且只与一个）实例进行交互。如何构造您的设计，以便从该
应用程序中只能访问该类的一个实例？
解决该问题最简单的方案就是创建一个具有私用构造函数的QuoteManager类，以便任何其
他类都不能实例化它。此类包含QuoteManager的一个静态实例，并使用名为GetInstance()的静
态方法返回。此代码大体如下所示：
public class QuoteManager
{
//注意：仅适用于单线程应用程序
private static QuoteManager _Instance = null;
private QuoteManager() {}
public static QuoteManager GetInstance()
{
if (_Instance==null)
{
_Instance = new QuoteManager ();
}
return _Instance;
}
//... QuoteManager提供的函数
}
您可能已经像其他许多开发人员那样通过类似的方式解决过类似的问题。实际上，注意反复出现
的问题并寻求解决方案的模式作者已经屡次发现了这种实现，提取出了通用解决方案并将这种问
题-解决方案对称为Singleton模式[GOF95]。
... ...
----------------------------------------------------------------------------------------------------------------------------------------
发帖说明：这里整合了部分内容，完整内容参见文件“软件架构与软件模式.doc ”
Reply all
Reply to author
Forward
0 new messages