软件架构综述论文

软件架构综述

一、软件架构的定义

1、软件架构的概念

软件架构（software architecture）是一个系统的草图,是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构描述的对象是直接构成系统的抽象组件。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

在“软件构架简介”一书中，David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”

2、与软件体系结构概念的细微区别

目前，没有文献表明软件体系结构与软件架构的差别。如果你强调方法论，应使用软件体系结构。强调软件开发实践，应使用软件架构。构架不仅是结构，IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。在 Rational Unified ProcESs 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

软件系统的架构是一个软件系统从整体到部分的最高层次的划分。其有两个要素：元件划分和设计决定。详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（TASk-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

3、研究的背景

在经历60年代的软件危机之后,使人们开始重视软件工程的研究。来自不同应用领域的软件专家总结了大量的有价值的知识. 当初,人们把软件设计的重点放在数据结构和算法的选择上，如Knuth提出了数据结构+算法=程序. 但是随着软件系统规模越来越大、越来越复杂，使软件系统的架构越来越重要。软件危机的程度日益加剧，现有的软件工程方法对此显得力不从心。对于大规模的复杂软件系统来说，软件体系架构比起对程序的算法和数据结构的选择已经变得明显重要得多。在此种背景下，人们认识到软件体系架构的重要性，并认为对软件体系架构系统、深入的研究将会成为提高软件生产效率和解决软件危机的最有希望的途径

二、架构的目标

正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：

〃可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

〃安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

〃可扩展性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

〃可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

〃可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展

〃可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费

〃客户体验（Customer Experience）。软件系统必须易于使用。

〃市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

三、架构的种类

根据我们关注的角度不同，可以将架构分成三种：

〃逻辑架构：软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。

〃物理架构：软件元件是怎样放到硬件上的。

〃系统架构：系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。

四、架构的风格

软件体系结构风格（有时候也叫架构模式）是描述某一特定应用领域中系统组织方式的惯用模式，是为一个系统提供的一系列抽象框架。它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。架构风格通过为经常发生的问题提供解决方案，来提高设计重用和改善程序结构。按这种方式理解，软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。

通用软件体系结构风格总结为以下几类：

1.数据流风格：批处理序列；管道过滤器。

2.调用返回风格：主程序子程序；面向对象风格；层次结构。

3.独立构件风格：进程通讯；事件系统。

4.虚拟机风格：解释器；基于规则的系统。

5.仓库风格：数据库系统；超文本系统；黑板系统。

几种主要的和经典的体系结构风格：

1.C2风格。C2风格是最常用的一种软件体系结构风格，该体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。

2.数据抽象和面向对象风格。目前软件界已普遍转向使用面向对象系统，抽象数据类

型概念对软件系统有着重要作用。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程

的调用来交互的。

3.基于事件的隐式调用风格。基于事件的隐式调用风格的思想是构件不直接调用一个

过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中

的触发就导致了另一模块中的过程的调用。

4.管道/过滤器风格。在管道/过滤器风格的软件体系结构中，每个构件都有一组输入

和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过

对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，

这里的构件被称为过滤器，这种风格的连接件就象是数据流传输的管道，将一个过滤器的

输出传到另一过滤器的输入。

5.批处理风格。批处理风格的每一步处理都是独立的，并且每一步是顺序执行的，只

有当前一步处理完后，后一步处理才能开始，数据传送在步与步之间作为一个整体。批处

理的典型应用是经典数据处理和程序开发。

6.仓库风格。在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立

构件在中央数据存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化。

五、关于架构的一些思考

1、EAI与SOA之比较

EAI是将基于异构平台下的业务应用系统集成在一起的一种技术。EAI通过中间件作为粘合剂来连接企业内外各种业务相关的异构系统、应用以及数据源，从而满足企业内部应用系统之间信息共享的需要。

SOA(面向服务的体系结构)将企业中各个系统应用程序的不同功能单元抽象为服务，通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务能够通过统一和通用的方式进行交互。SOA架构由服务总线、服务目录、门户、流程管理等几个核心组件构成的。这些核心组件协同工作共同支撑服务的部署、运行与管理监控。

从以下的几个方面对EAI与SOA进行比较：

1. 集成的本质

EAI的集成方式从本质而言是基于消息的集成，因此EAI的各组成部件，如适配器与hub，都带有消息转换与消息路由的功能，在EAI的运作过程中，单个应用系统只关心其与EAI 连接部分消息的输入与输出，不关心具体的业务处理，业务处理都是在应用系统内部完成的。

SOA的集成方式，其本质是对业务功能服务化后根据业务流程进行编排，是真正意义上的基于功能服务的集成。当然在基于SOA的集成中同样包含了基于消息集成的功能。

因此基于SOA的集成方式比EAI的集成方式适用范围更广。

2. 集成对象的颗粒度

SOA和EAI从不同的视角切入去看待企业已有的信息资源，并基于此对企业已有的资源进行梳理、分类和集成。

EAI从应用系统的层面去看待企业已有信息资源，企业的每一个应用系统被看作一个集成单元，EAI工作的目标就是，通过为这些已有的应用系统提供一种中间沟通方式，让这些应用软件之间可以进行数据的共享与交换，从而盘活这一个个独立的“信息孤岛”。

SOA从提供服务、使用服务的角度去看待企业已有的信息资源。在这种方式下，同样的一种资源既可能是服务提供者，也同样可以是服务使用者；在这种方式下，一个应用模块可能只提供一种服务，因此被封装成一个服务，也可能由于提供了多种服务，而需要进一步划分。

显然，SOA方式集成处理的颗粒度比EAI要小，因此SOA方式比EAI方式更具有灵活性。3. 标准化

SOA在实现企业信息化集成的同时，也将实现企业级服务的高度可重用作为目标，因此，在SOA架构中任何一种接口、通讯、协议都是遵循相应的国际标准，如：标准描述语言（WSDL）、发现协议（UDDI)和消息协议(SOAP)等。

EAI则大多使用基于具体实施EAI企业中制定的私有标准。基于私有标准的优点是可