对软件体系结构和模式的初步认识

 

一. 软件体系结构（架构）

软件体系结构的定义

通常，软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在发展期，对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同理解。比如，ANSI/IEEE 610.12-1990软件工程标准词汇对于体系结构定义是“体系架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计与演化的原理(principle)”；而Garlan & Shaw模型的基本思想是：软件体系结构={构件(component),连接件(connector)，约束(constrain)}。
对于软件项目的开发来说，一个清晰的软件体系结构是首要的。传统的软件开发过程可以划分为从概念到实现的若干个阶段，包括问题定义、需求分析、软件设计、软件实现及软件测试等。软件体系结构的建立就位于需求分析之后，软件设计之前。在建立软件体系结构时系统设计师主要从结构的角度对整个系统进行分析，选择恰当的构件（Component）、构件间的相互作用以及它们的约束，最后形成一个系统框架（Framework）以满足用户的需求，为软件设计奠定基础。
软件体系结构风格
软件体系结构设计的一个核心问题是能否使用重复的体系结构模式，即能否达到结构级的软件重用。也就是说，能否在不同的软件体系中，使用同一体系结构。基于这个目的，学者们开始研究和实践软件体系结构的风格问题。
软件体系结构风格（Software Architecture Style）是描述某一特定应用领域系统组织方式的惯用模式。它反映了领域中众多系统所有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证明的解决方案也可以可靠地用于解决新的问题。体系结构风格的不变部分使不同的系统可以共享一个实现代码。只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统结构。
Garlan和Shaw对通用体系结构风格进行如下分类：
（1）数据流风格：批处理序列、管道/过滤器等；
（2）调用/返回风格：主程序/子程序、面向对象风格、层次结构等。
（3）独立构件风格：进程通讯、事件系统等；
（4）虚拟机风格：解释器、基于规则的系统等；
（5）仓库风格：数据库系统、超文本系统、黑板系统等。
近年来，出现了许多新的体系结构风格，例如客户/服务器（Client /Server）结构、浏览器/服务器（Browser/Server）结构、正交（Orthogonal）结构、三层C/S结构等。
软件体系结构的建模研究
研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。根据建模的侧重点的不同，可以将软件体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。其中，最常用的是结构模型和动态模型。
研究热点
当前，体系结构仍是一个非常新的研究领域，其概念还相当模糊。但软件体系结构作为软件工程领域中的一个组成部分，已经取得了长足的发展，受到大多数软件系统设计和研究人员的重视。
软件体系结构目前较活跃的研究方向包括：（1）软件体系结构形式基础的研究；（2）针对软件体系结构描述中特有的问题研究新的专门的高级语言；（3）建立用于度量和评价软件体系结构的模型和方法；（4）建立面向专门领域的软件体系结构范型库。（5）把软件体系结构从目前的直觉和经验状态过渡到理论。
二．模式
模式（Pattern）的概念最早由建筑大师Christopher Alexander于二十世纪七十年代提出，应用于建筑领域，八十年代中期由Ward Cunningham和Kent Beck将其思想引入到软件领域，Christopher Alexander将模式分为三个部分：
(1)周境（Context，也可以称着上下文）,指模式在何种状况下发生作用；
(2)动机（System of Forces）,意指问题或预期的目标；
(3)解决方案（Solution）,指平衡各动机或解决所阐述问题的一个构造或配置（Configuration）。
他提出，模式是表示周境、动机、解决方案三个方面关系的一个规则，每个模式描述了一个在某种周境下不断重复发生的问题，以及该问题解决方案的核心所在，模式即是一个事物（thing）又是一个过程(process)，不仅描述该事物本身，而且提出了通过怎样的过程来产生该事物。这一定义已被软件界广为接受。
软件模式的应用对软件开发产生了重大的作用，主要表现在：
（1）软件模式是人们在长期的设计软件、管理组织软件开发等实践中大量经验的提炼和抽象，是复用软件设计方法、过程管理经验的有力工具。模式类似于拳击中的组合拳，它提供了一系列软件开发中的思维套路。如，通过模式的使用，有利于在复杂的系统中产生简洁、精巧的设计。
(2)软件模式为我们提供了一套简洁通用的设计、管理、组织方面的词汇，同时模式也为我们提供了一个描述抽象事物的规范标准，可大大促进软件开发过程中人与人之间的交流，而软件开发中的交流是至关重要的，“软件项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接收它的人”。
三．架构和模式的关系
架构(Architecture)和模式(Pattern)在当前的软件开发中经常地被提及，这两个术语非常容易混淆，而且学术界也没有一个非常统一的定义。
架构和模式应该是一个属于相互涵盖的过程，但是总体来说Architecture更加关注的是所谓的High-Level Design,而模式关注的重点在于通过经验提取的“准则或指导方案”在设计中的应用，因此在不同层面考虑问题的时候就形成了不同问题域上的Pattern。模式的目标是，把共通问题中的不变部分和变化部分分离出来。不变的部分，就构成了模式，因此，模式是一个经验提取的“准则”，并且在一次一次的实践中得到验证，在不同的层次有不同的模式，小到语言实现(如Singleton)大到架构。在不同的层面上，模式提供不同层面的指导。根据处理问题的粒度不同，从高到低，模式分为3个层次：
（1）架构模式(Architectural Pattern)、设计模式(Design Pattern)、实现模式(Implementation Pattern).架构模式是模式中的最高层次，描述软件系统里的基本的结构组织或纲要，通常提供一组事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。比如，用户和文件系统安全策略模型，N-层结构，组件对象服务等，我们熟知的MVC结构也属于架构模式的层次。一个架构模式常常可以分解成很多个设计模式的联合使用。
（2）设计模式是模式中的第二层次，用来处理程序设计中反复出现的问题。例如，《设计模式--可复用面向对象软件的基础》一书中总结的23个基本设计模式——Factory Pattern, Observer Pattern等。
（3）实现模式是最低也是最具体的层次，处理具体到编程语言的问题。比如，类名，变量名，函数名的命名规则；异常处理的规则等等。
相对于系统分析或者设计模式来说，体系结构从更高的层面去考虑问题，所以关注的问题就体现在“不变”因素上，比如系统部署中，更加关心应用程序的分层分级设计，而在这个基础之上提出的部署方案，才是架构考虑的重点。体系结构关心应用程序模式，更加体现在通过技术去解决这些业务差异带来的影响，关心是否是分布式应用程序，关心系统分层是如何设计，也关心性能和安全，因此在这样的情况之下，会考虑集群，负载平衡，故障迁移等等一系列技术。
总之，希望通过定义的方式来区分架构和模式是不太可能的，因为本来就是交互交叉和提供服务的，它实际上是架构模式，而不是设计模式。在大部份情况下，表现为下面几个设计模式之一：Strategy模式、Mediator模式、Composite模式、Observer模式。对于熟悉架构设计的系统架构师而言，似乎可以用如下来解释架构和模式之间的关系：架构是Hight-Level Design,着眼于不同业务中共性的解决方案，而模式是General Principle(通用原理)。

总结
以上是我对软件体系结构和模式的一些初步映像。真理和创新来源于实践，所以我将在以后的学习和工作中逐步加深对以上概念的认识！