软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在发展期，对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同理解，以下是一些主流的标准观点。

组成派

Mary Shaw在《软件体系结构：一门初露端倪学科的展望》中为“软件架构”给出了非常简明的定义：软件系统的架构将系统描述为计算机组件及组件之间的交互（The architecture of a software system defines that system in terms of computational components and interactions among those components.）。

上述定义有如下两个显著特点：

（1）关注架构是实践中的客体——软件，以软件本身为描述对象；

（2）分析了软件的组成，即软件由承担不同计算任务的组件组成，这些组件通过相互交互完成更高层次的计算。

决策派

RUP（Rational Unified Process，统一过程）中的软件架构定义：

软件架构包含了关于一下问题的重要决策：

（1）软件系统的组织；

（2）选择组成系统的结构元素和他们之间的接口，以及当这些元素相互协作是所体现的行为；

（3）如何组合这些元素，使他们逐渐合成为更大的子系统；

（4）用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和合作。

软件架构不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡，以及美学等。

上述定义有如下两个显著特点：

（1）关注架构实践中的主体——人，以人的决策为描述对象；

（2）归纳了架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能性需求的决策。

软件架构模式是高度抽象的、适用于许多类似系统的、预先定义好的一种特殊的软件架构。

架构模式的经典分类

架构模式的现代分类

由于经典模式比较久远，下面对现代模式简要阐述一下。

分层：从不同的层次来观察系统，处理不同层次问题的对象被封装到不同的层中，最大的优点是将整体问题局部化，把可能的变化分别封装在不同的层中。第N层只能被第N-1层调用或者被位于上一层的任意一层调用。

图1 典型的分层架构

管道—过滤器：用数据流的观点来观察系统。整个系统由一些管道和过滤器组成，需要处理的数据同管道传送给每一个过滤器，每个过滤器就是一个处理步骤。每个过滤器可以单独修改,功能单一,并且它们之间的顺序可以进行配置。但数据通过了所有的过滤器后，就完成了所有的处理操作，得到了最终的处理结果。这种架构的缺点是交互性差，原因在于它没有“边界对象”——它是控制对象和实体对象的间插排列成的一条流水线。

一个典型的管道/过滤器体系结构的例子是以Unix shell编写的程序。Unix既提供一种符号，以连接各组成部分(Unix的进程)，又提供某种进程运行时机制以实现管道。另一个著名的例子是传统的编译器。传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段（包括词法分析、语法分析、语义分析和代码生成）的输出是另一个阶段的输入。

图2 编译器架构

黑板：应用中的多种不同数据处理逻辑相互影响和协同来完成数据分析处理。就好像多位不同的专家在同一黑板上交流思想，每个专家都可以获得别的专家写在黑板上的信息，同时也可以用自己的分析去更新黑板上的信息，从而影响其它专家。

在实际应用中常见的实现模式有：

A 利用数据库： 利用数据库充当黑板，不同的应用共享数据库中信息，并且可以更新数据信息。这也是最常见的实现方式。

特点：

1 便于实现信息的查询，筛选和统计，这方面关系数据库提供了SQL 92的强大支持。

2 不能用于较高实时性要求的环境，这种实现是工作在“拉模式”下的，并且高频率的访问数据库会导致严重的系统性能问题。

B 利用发布—订阅模式：这种实现方式通常采用消息队列作为黑板，队列工作在主题模式（Topic），专家作为队列的订阅者，同时可以向队列发送消息，消息会被发送至所有订阅者。以上过程实现了专家间的信息交流。

特点：

1 可以有效应用于实时性要求较高的系统，这种实现工作在“推模式”下。

2 难于实现信息的统计分析，不像实现方式一那样可以通过SQL支持，这些工作必须开发者自己完成。

代理者 ：现今未找到详细说明，笔者日后到英文网站查找后再更新。

MVC ：采用该模式的软件会包含这样三种组件：Model、View、Controller。

图3 基于J2EE平台的MVC

PAC ： 现今未找到详细说明，笔者日后到英文网站查找后再更新。

微内核 ：微内核模式能适用于需求经常变更的系统，它把最小化的基本服务内核从扩展服务和客户特殊服务中分离出来。微内核服务与这些扩展的接口和协调它们之间的合作。（The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.）

优点：

1.可扩展性。微内核所有附加功能均能通过开发新的附加服务的形式进行扩充。而且，它提供了封装底层功能的更易用的虚拟机，附加服务的开发可以在较高层次上开始。

2.可移植性。附加功能只依赖于微内核，它们没有移植性的开销。只需修改微内核的一直线管部分即可。

3.延长软件系统的生命周期。微内核架构可以接纳一些当前不可预见的新技术，以及商业层面的新功能的挑战。

缺点：

1.设计和实现的复杂性。微内核提供的能力必须少而精，但又必须完备，否则就不能提供逍遥的完整“机制” 。

2.微内核架构往往比同类情况下的其他设计性能低，要解决此问题得依靠良好的策略。

微内核适用于开发难度大、预期生存周期长、成本高的软件系统，通过改架构可以很好的解决这三个问题：

1.微内核将底层差异进行封装，构建了一个抽象度更高的虚拟机，降低了其他服务开发的难度。

2.生存周期长，需要应对的变化越多。微内核架构屏蔽了下层变化，为上层服务提供了更稳定的抽象服务，理喻大规模扩展的需要。

3同股沟开放性可以缓解成本高的问题。将微内核实现的基础服务开房，可以吸引大批开发者增强你的产品。.

以下给出一个微内核的示例，它来自于CMU- Carnegie-Mellon大学开发的Hydra操作系统。（Below is illustrative example of Mickrokernel architecture from Hydra Operating System. Which is developed by CMU- Carnegie-Mellon University.）

图4

微软下一代实验性操作系统在搜索方面（Singularity）引入了微内核的概念（Microsoft’s next generation experimental operating system in research code name ‘Singularity’ has adopting concept of ‘Microkernel’ ）。下面给出示例图

图5

基于元模型：基于元模型的架构和微内核架构一样，都是以适应变化、支持长生命周期为主要目标的架构模式，它包含两个层：基本层和元层，如下图所示。

图6

基本层定义应用，元层通过元对象Meta A调用对象A，接触了应用对对象A的依赖。元层包含一组“元对象”，这些元对象组成的模型叫做“元模型”，元模型是对基本层中“一切”的抽象。元模型提供了软件本身的结构和行为的“自描述”。一般而言，元模型中的元对象应分别从三个方面刻画基本层：结构、行为、状态。

由于本人知识有限，此文也只是对常用架构模式的浅层次归纳，更多内容在以后的学习过程中笔者会不定时更新，希望这些对大家有帮助，同时也欢迎大家留言探讨，指正不足之处。