249.软件体系结构起源和发展

 

1.软件体系结构的定义

　　软件体系结构尚处在发展期，对于其定义，目前学术界还没有造成统一意见，不一样学者有不一样的见解。如下介绍并分析几个具备表明性的定义。

 

　　定义1  IEEE610. 12—1990软件工程标准词汇中的定义

　　体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即

　　软件体系结构={构件，链接件，环境，原理}

 

　　定义2  Booch&Rumbaugh&Jacobson的定义

　　体系结构是一系列重要决策的集合，这些决策与如下内容相关：软件的组织、构成系统的结构元素及其接口的选择，这些元素在相互协做中明确表现出的行为、这些结构元素和行为元素进一步组合构成的更大规模的子系统，和引导这一组织(包括这些元素及其接口、它们的协做、它们的组合)的体系结构风格，即

　　　软件体系结构={组织，元素，子系统，风格}

 

　　定义3  Bass的定义

　　程序或计算系统的软件体系结构是系统的一个或多个结构，包括软件构件、构件的外部可视属性和构件之间的关系。这个定义有如下含义：首先，体系结构定义了构件，描述了构件间如何交互，这意味着体系结构略去了那些仅与某构件自身有关的信息。同时，这个定义明确指出系统能够包含多个结构，但没有其中的哪个能够被称为是体系结构。这个定义还意味着每个软件系统都有一个体系结构，由于每一个软件系统都是由若干构件及其之间的关系构成的。此外，只要一个构件的行为能够被其余构件观察或辨明，这个构件就是体系结构的一部分。 

　　这里的外部可视属性，是指其余构件认为该构件所具有的特征，如所提供的服务、具备的性能特色、错误处理机制、共享资源的用法等。须要注意的是，此定义中，特地未指明什么是构件，什么是关系。构件既能够是对象，也能够是进程，还能够是函数库或是数据库。

 

　　定义4  Shaw的定义

　　在第一届软件系统体系结构国际研讨会上，Mary Shaw对于当时术语使用的混乱状况予以了澄清：不一样学者的软件体系结构定义之间并不相互抵触，在回答什么是软件体系结构这样的问题时，也并无根本的冲突。实际上，它们表明了软件体系结构研究者对于体系结构研究重点的一系列不一样见解。在会上，Shaw对当时的各类观点作了以下的分类。

(1) 结构模型：结构模型认为，软件体系结构由构件、构件之间的链接和一些其余方面组成。这些方面包括以下几类：

　　· 配置，风格；

　　· 约束，语义；

　　· 分析，属性；

　　· 原理，需求。

 

(2) 框架模型：框架模型的观点与结构模型类似，但其重点在于整个系统的连贯结构(这种结构一般是惟一的)，这与重视其组成刚好相反。框架模型常以某种特定领域或某类问题为目标。

 

(3) 动态模型：动态模型强调系统的行为质量。“动态”能够有多种含义。它能够是指整个系统配置的变化，也能够是指禁止预先激活了的通讯或交互，还能够是指计算中表现出的动态特性，如改变数据的值。

 

(4) 过程模型：过程模型关注系统结构的构建及其步骤和过程。在这一观点下，体系结构是所进行的一系列过程的结果。

 

 

　　定义5  Garlan&Shaw的模型

　　　软件体系结构={构件，链接件，约束}

　　(1) 构件(Component)能够是一组代码，如程序的模块，也能够是一个独立的程序，如数据库服务器。构件是相关对象的集合，运行后实现某计算逻辑。它们或是结构相关或是逻辑相关。构件相对独立，仅经过接口与外部相互做用，可做为独立单元嵌入到不一样应用系统中。构件的定制和规范化对于实现构件的重用有重要意义。



　　(2) 链接件(Connector)能够是过程调用、管道、远程过程调用等，用于表示构件之间的相互做用，它把不一样的构件链接起来构成体系结构的一部分。链接件也是一组对象。它通常表现为框架式对象或转换式对象(调用远程构件资源)，例如“桩”、“代理”对象等。

　　(3) 约束(Constrain)通常为对象链接时的规则，或指明构件链接的姿态和条件。例如，上层构件可要求下层构件的服务，反之不行；两个对象不得以递归方式发送消息；代码复制迁移的一致性约束；在什么条件下此种链接无效等。主要针对链接件的一些约束规则。

 

 

　　定义6  Perry&Wolf的模型

　　软件体系结构是一组具备特定形式的体系结构元素(Elements)。这组元素分为3类：负责完成数据加工的处理元素(Processing Elements)、被加工的数据元素(Data Elements)和用于把体系结构的不一样部分组合链接到一块儿的链接元素(Connecting Elements)。软件体系结构形式由专有特性和关系组成。专有特性用于限制软件体系结构元素的选择，关系用于限制软件体系结构元素组合的拓扑结构。在多个体系结构方案中选择合适的体系结构方案每每基于一组准则，即

　　　软件体系结构={元素，形式，准则}

 

 

　　定义7  Garlan&Perry的定义

　　1995年，David Garlan和Dewne Perry在IEEE软件工程学报上所作的特约评论中提出：软件体系结构是一个程序或系统各构件的结构、它们的相互关系以及进行设计的原则和指导方针，这些原则和方针随时间变化而变化。

 

　　定义8  Boehm的模型

　　软件体系结构包括系统构件、链接件、约束的集合，反映不一样人员需求的集合，以及准则的集合。其中，这些准则可以说明由构件、链接件和约束所定义的系统在实现时是如何知足系统不一样人员需求的，即

　　　软件体系结构={构件，链接件，约束，不一样人员的需求，准则}

　　比较上述体系结构定义，能够发现：尽管各类定义都从不一样的角度关注软件体系结构，研究对象各有侧重，但其核心内容都是软件的系统结构，而且都蕴含构件、构件之间的关系、构件和链接件之间的关系等实体。

 

　　定义9 国内

　　根据国内广泛承认的见解，能够将体系结构定义为构件、链接件和约束。软件体系结构指可预制和可重构的软件框架结构。构件是可预制和可重用的软件部件，是组成体系结构的基本计算单元或数据存储单元；链接件也是可预制和可重用的构件部件，是构件之间的链接单元；构件和链接件之间的关系用约束来描述。这样就能够把软件体系结构写成：

　　　体系结构(Architecture)=构件(Components)+链接件(Connectors)+约束(Constraints)

　　除了构件、链接件和约束这3个最基本的组成元素，软件体系结构还包括端口(Port)和角色(Role)两种元素。构件做为一个封装的实体，仅经过其接口与外部环境交互，而构件的接口由一组端口组成，每一个端口表示了构件和外部环境的交互点。链接件做为建模软件体系结构的主要实体，一样也有接口。链接件的接口由一组角色组成，链接的每一个角色定义了该链接表示的交互的参与者。图2-1形式化地描述了软件体系结构的基本概念。

 

 图2-1  软件体系结构的基本概念

 

 

　　其中：

　　软件体系结构∷= 软件体系模型 | 体系结构风格

　　软件体系模型∷= { 构件，链接件，约束 }

　　构件∷= { 端口1，端口2，…，端口ｎ }

　　链接件∷= { 角色１，角色２，…，角色m  }

　　约束∷= { (端口i，角色j)，… }

　　体系结构风格∷= { 管道-过滤器，层次系统，客户/服务器，…，解释器 }

 

　　下面，咱们对构件、链接件、约束这3个基本概念做进一步的解释。

 

　　1．构件

　　通常认为，构件是指具备必定功能、可明确辨识的软件单位，而且具有如下特色：语义完整、语法正确、有可重用价值。这就意味着，在结构上，构件是语义描述、通讯接口和实现代码的复合体。更具体地说，能够把构件视为用于实现某种计算逻辑的相关对象的集合，这些对象或是结构相关或是逻辑相关。在体系结构中，构件能够有不一样的粒度。一个构件能够小到只有一个过程，也能够大到包含一个应用程序。它能够包括函数、例程、对象、二进制对象、类库、数据包等。

　　构件内部包含了多种属性，如端口、类型、语义、约束、演化、非功能属性等。端口是构件与外部世界交互的一组接口。构件端口说明了构件提供哪些服务(消息、操做、变量)。它定义了构件可以提交的计算委托及其用途上的约束。构件类型是实现构件重用的手段。构件类型保证了构件自身可以在体系结构的描述中屡次实例化。

　　从抽象程度来看，构件是对一组类的组合进行封装，并表明完成一个或多个功能的特定服务，也为用户提供了多个接口。构件之间是相对独立的。构件隐藏其具体实现，只经过接口提供服务。若是不用指定的接口与之通讯，则外界不会对它的运行形成任何影响。所以，构件能够做为独立单元被应用于不一样的体系结构和软件系统中，实现构件的重用。构件的使用与它的开发也是独立的。

 

　　2.链接件

　　链接件是用来创建构件间的交互以及支配这些交互规则的体系结构构造模块。构件之间的交互包括消息或信号量的传递，功能或方法调用，数据的传送和转换，构件之间的同步关系、依赖关系等。在最简单的状况下，构件之间能够直接完成交互，这时体系结构中的链接件就退化为直接链接。在比较复杂的状况下，构件间交互的处理和维持都须要链接件来实现。常见的链接件有管道(在管道-过滤器结构中)、通讯协议或通讯机制(在客户/服务器结构中)等。

　　链接件的接口由它与所链接构件之间的一组交互点构成，这些交互点称作角色。角色表明了所链接构件的做用和地位，并体现了链接所具备的方向性。所以，角色存在主动和被动、请求和响应之分。

　　体系结构级的通讯须要有复杂协议来表达，为了抽象这些协议并使之可以重用，能够将链接件构造为类型。

　　链接件的主要特性有可扩展性、互操做性、动态链接性和请求响应特性。链接件的可扩展性是链接件容许动态改变被关联构件的集合和交互关系的性质。互操做性指的是被链接的构件经过链接件对其余构件进行直接或间接操做的能力。动态链接性是对链接的动态约束，即链接件对于不一样的所链接构件实施不一样的动态处理方法的能力。请求响应特性包括响应的并发性和时序性。在并行和并发系统中，多个构件有可能并行或并发地提出交互请求，这就要求链接件可以正确协调这些交互请求之间的逻辑关系和时序关系。

　　对于构件而言，链接件是构件的黏合剂，是构件交互的实现。链接件和构件的区别主要在于它们在体系结构中承担着不一样的做用。链接件也是一组对象。它把不一样的构件链接起来，造成体系结构的一部分，通常表现为框架式对象或转换式对象(调用远程构件资源)。

 

　　3．约束(配置)

　　体系结构的约束描述了体系结构配置和拓扑的要求，肯定了体系结构的构件与链接件的链接关系。它是基于规则和参数配置的。体系结构约束提供限制以肯定构件是否正确链接、接口是否匹配、链接件构成的通讯是否正确，并说明实现所要求行为的组合语义。

　　体系结构每每用于大型的、生存期长的软件系统的描述。为了更好地在一个较高的抽象层上理解系统的分析和设计，同时为了方便系统开发者、使用者等多种有关人员之间的交流，须要简单的、可理解的语法来配置结构化(拓扑的)信息。理想的状况是从约束说明中澄清系统结构，即不需研究构件与链接件就能使构件系统的各类参与者理解系统。

 

 

 

 

 

 2.软件体系结构的研究意义

　　软件体系结构是软件系统的高级抽象，每每体现了系统开发中最先作出的决策。它体现了根本性的系统设计思路，对系统起着最为深远的影响。体系结构在明确了系统的各个组成部分的同时，也限定了各部分间的交互方式。这将进一步影响到开发资源的配置和开发团队的组织等其余方方面面的开发活动，并影响着最终的软件产品质量。 

　　在大型软件系统中，软件体系结构是决定系统可否顺利实现的关键因素之一，不当的体系结构会给整个系统带来灾难性的后果。

 

　　良好的体系结构对于软件系统的重要意义在软件生命周期中的各个阶段都有体现，这主要有以下4个方面。

　　1．对系统分析的意义

　　在系统分析阶段，软件体系结构发挥着巨大做用。

　　一方面，借助于软件体系结构进行描述，能够使问题得以进一步抽象，使整个系统更易于被系统分析设计人员把握，更清晰地认识系统，完善对系统的理解。除此以外，体系结构对于系统分析带来的优点还体如今，它为系统分析设计人员提供了新的思路。好比，在更高层次上进行系统一致性检查、使用成熟的软件体系结构风格等。

　　另外一方面，它可以帮助软件系统的各有关权益方(客户、用户、项目管理人员、设计开发人员以及测试人员等)造成统一认识，互相交流。交流是软件开发的重要组成部分。在软件开发活动中，各有关权益方承担着不一样角色，关注同一软件系统不一样的侧面，这要求他们要从不一样的角度交流对共同面对的软件系统的认识。 

　　例如，用户关心系统是否知足可用性及可靠性需求；客户关心此结构可否定期按预算实现；管理人员担忧在经费支出和进度条件下，按此体系结构可否使开发组成员在必定程度上独立开发，并有条不紊地有序地交互；开发人员关心达到所有目的的策略。体系结构表明了系统的公共的高层次的抽象，是你们都关心的一个重要因素。它做为项目参与人员共同使用的语言，还具备很强的描述能力，起到了难以替代的沟通做用。系统的大部分有关人员(即便不是所有)能把它做为创建互相理解的基础，经过体系结构的概念、术语和规范，设计者与用户之间、设计者之间等各方面相关人员能够更好地彼此理解。

 

　　2.对软件开发的意义

　　软件体系结构表明了系统早期的设计决策。与开发、设计、编码或运行服务及维护阶段相比，早期设计决策的处理难度最大，对系统的生命期的影响也最大。同时，软件体系结构也难于改变，会对整个系统开发活动形成深远影响。

　　软件体系结构是系统实现的基本约束，即系统的后继开发工做要遵循体系结构所描述的设计决策。每一个构件或链接件必须知足体系结构规格说明中指定的功能、语义和接口，而且按体系结构配置中所规定的方式完成交互。这样，构件或链接件的开发人员在体系结构给定的约束下进行工做，他们既不关心其余构件或链接件的开发，也不会对其产生影响。而体系结构设计者也没必要设计算法或精通编程语言。

　　软件体系结构决定了开发和维护项目的组织活动。软件体系结构也会反映到开发工做的分解，以及项目的人员组织。项目组成员还要使用构件的接口规格说明相互交流。即便到了维护期，项目维护人员的组织形式也经常要依据特定的软件体系结构成分来安排。此外，对于项目组新成员，能够用软件体系结构做为培训基础或高层次的系统概述，使他们迅速、准确地认识系统和本身的任务，快速进入开发角色。

　　软件体系结构对于软件质量控制有重要意义。软件质量特性可分为两类：第一类是能够经过运行软件并观察其效果来度量的特性，如功能、性能、安全性及可靠性等；第二类是指那些没法经过观察系统来度量，只能经过观察开发活动或维护活动来考察的特性，包括各类可维护性问题，如可适应性、可移植性、可重用性等(例如，可重用性依赖于系统中的构件与其余构件的联系状况)。软件体系结构在很大程度上肯定了系统是否能达到其需求的质量特性。 

　　使用软件体系结构的一些评估技术(如SAAM)，对软件体系结构加以分析，可以对软件的某些质量特性加以预测。但同时，也必须认识到，好的软件体系结构是成功的必要条件，但不是充分条件。仅重视软件体系结构并不能保证系统所要求的功能和质量——低劣的设计及实现都会损害整个体系结构。

 

　　3．对软件重用的意义

　　重用是提升软件开发效率、保证软件质量的重要手段。软件开发经历了从机器语言、汇编语言、结构化程序设计语言、面向对象程序设计语言、形式化(非形式化)规格说明语言(如体系结构描述语言)的发展过程，愈来愈适合开发人员的思惟活动模型，代码重用的级别也在不断地提高。体系结构技术的研究，使软件重用从代码重用发展到设计重用和过程重用，实现多层次的软件重用。

　　构件的重用是体系结构良好的软件系统最基本的一点。面向体系结构的开发方法经常注意构件的组合与装配，而不必定把编程做为主要活动。有效地利用标准构件，或是识别并重用系统内部的构件，或是购买第三方构件，只要这些构件与当前体系结构相容，都能减小开发中的重复劳动和系统中的重复代码。体系结构起了组织产品的构件、接口及运行的做用。这里要着重指出的是标准构件的应用。应用标准构件库的关键在于要可以从总体上对库中构件进行把握。一旦作到了这点，就能够快速、灵活地在构件库中选择出合适的构件应用到系统中去；反之，构件的选取就只能经过反复地浏览来寻找，这实际上影响到了体系结构所带来的优点，形成了没必要要的资源浪费。

　　体系结构良好的软件系统中，不只构件库可以重用，还能够在更高层次上实现软件子系统乃至软件系统框架的重用。软件体系结构级的重用意味着体系结构的决策能在具备类似需求的多个系统中发生影响，这比代码级的重用要有更大的好处。经过对体系结构的抽象能够使设计者可以对一些实践证实有效的体系结构构件进行重用，从而提升设计效率和可靠性。在设计过程当中咱们经常会发现，对一个体系结构构件稍加抽象，就能够将它应用到其余设计中去，这样会大大下降设计的复杂度。 

　　例如，咱们在某个设计中采用了管道-过滤器风格，当咱们将系统映射到Unix系统中时，咱们就会发现Unix系统已经为咱们提供了功能丰富的管道-过滤器功能，这样咱们就能够充分利用Unix系统提供的这些构件来简化咱们的设计和开发。当前，针对特定领域的体系结构，人们开展了许多研究和实践工做。这在某种意义上也是一种重用。软件重用的层次越高，所带来的收益也就越大。某些状况下，重用的设计方案自己也许不是最适合该系统的，可是从总体上权衡，经过重用带来的成本节约和质量提供可以让重用变得很是值得。

　　软件体系结构有利于造成完整的软件生产线。1976年Parnas提出了发展软件族的软件生产线。软件族的软件生产线成功的关键问题是设计决策的次序问题，要求对于最容易发生变更的决策应当尽可能放在最迟做出。事实上，软件族的软件生产线表明了早期决策的总和，将影响软件族的软件生产线的全体成员。能够说，体系结构在必定程度上限制了设计选择的范围或内容。要认识到这种决策对于每个部分来讲不必定是最优，但其优势通常能够补偿失去的特定领域优化的损失。

 

 

　　4．对系统演化的意义

　　对软件系统的演化过程当中，维护人员须要不断地进行调整、修改、增长新的功能或构件等工做。一般状况下，软件系统的开发成本中，有80%是在初次投入使用以后产生的。所以，解决好系统演化阶段的开发问题具备重要意义。

　　软件体系结构决定着系统构件的划分和交互方式。一方面，在设计系统的体系结构之初，就应当充分考虑到未来可能的系统演化；另外一方面，在进行系统演化阶段的开发时，因为体系结构充分地刻画了当前系统，清晰地描述了构件及其相互关系和整个系统的框架，因此应当充分利用。

　　以现有体系结构为基础，把握须要进行的系统变更，在系统范围内综合考虑，有助于肯定系统维护的最优方案，更好地控制软件质量和维护成本。软件为主的系统老是存在着“利用软件做为增长或修改系统整体功能的工具”的倾向。重要的是要决定什么时候进行改动，肯定哪一种改动风险最小，评估改动的后果，仲裁改动的顺序及优先级。全部这些都须要深刻地洞察系统各部分的关系、相互依存关系、性能及行为特性。而在软件体系结构这一级进行讨论，就能提供这种观察力，更重要的是软件体系结构能够把可能发生的变更分为3类：局部的、非局部的和体系结构级的。 

　　局部的是指只要修改单个构件自己；非局部的是指要修改几个构件，但不影响基础体系结构的变更；而体系结构级是指会影响各部分的相互关系，甚至要改动整个系统。显然，局部改动应是最常常发生的，也是最容易进行的。软件体系结构承担了“保证最常常发生的变更是最容易进行的”这一重任。

 

 

3.软件体系结构的发展历程

　　软件工程做为一门独立的学科，其发展已逾30年。不管从应用规模仍是从技术水平看，计算机软件产业所经历的发展都是迅猛的。这体如今诸多方面。首先，软件系统的应用领域从实验室渗透到了人类社会的各个角落。最初的软件是以穿孔纸带或卡片的形式出如今实验室和机房中用于科学计算的；而在今天的人类社会中，各类软件系统运行在从手持设备(如手机)到大型机(如进行天气预报的服务器)的各类规模和用途的信息处理设备上。其次，软件系统的规模也迅速增加。 

　　从微机不断跃增的内存配置就能够明显看出这一点。1981年，IBM公司推出的第一台PC机的配置是16 KB的内存；2003年，主流PC机的内存配置是256 MB；2008年，主流PC机的内存配置是2 GB。此外，随着计算机产业的发展，软件成本也在增加。20世纪50年代，软件成本在整个计算机系统成本中所占的比例为10%～20%。到20世纪60年代中期，软件成本在计算机系统中所占的比例已经增加到50%左右。相反，计算机硬件价格随着技术进步和生产规模扩大却在不断降低。软件成本在计算机系统中所占的比例愈来愈大。 

　　下面是一组来自美国空军计算机系统的数据：1955年，软件费用约占总费用的18%，1970年达到60%，1975年达到72%，1980年达到80%，1985年达到85%左右。

　　在软件应用规模和应用领域迅速扩大的同时，软件开发技术也在发生着根本性的变革。软件规模的迅速增加使得软件开发成为了一项过去不可思议的系统工程。根据微软公司公布的数据， Windows 2000开发过程当中测试用代码行数超过1000万行，测试兼容性的应用软件数量约1000种，应用软件测试中所使用的脚本程序约6500种，每个月备份的数据约88 TB，每晚模拟打印数量约25万页，每周刻录CD约12 000盘。

　　在此过程当中，软件体系结构也经历了与之相对应的一系列变革，由最初的模糊概念发展成为一门日益成熟的技术。下面咱们分阶段进行讨论。

 

 

3.1  “无体系结构”设计阶段

　　1946年，随着具备里程碑意义的ENIAC机的问世，软件行业开始在美国和欧洲的实验室出现。1955～1965年间，运算速度愈来愈快、价格愈来愈低的新计算机不断涌现。这期间的软件多数应用于学术界，或者是政府、军队及私人公司。可是，因为当时的计算机硬件向着专用方向发展，科学与商业领域使用彻底不一样的机器硬件。不断地针对不一样计算机编写软件让软件工做人员目不暇接，反复地开发相同或相似的软件使得软件研究者开始着手处理软件的移植问题，即设法使一种机器的汇编语言程序可以自动移植到另外一台机器上去。但研究人员很快发现这难以实现，大量复杂代码仍必须由程序员进行改写。

　　在这样的背景下，高级语言应运而生。FORTRAN语言诞生于20世纪50年代中期，是最先发布的高级语言；50年代后期，COBOL语言出现；60年代早期，ALGOL语言出现。而在当时，高级语言不能被程序编制人员所接受，他们认为真正的程序员应使用汇编语言。

　　总的说来，20世纪70年代之前，尤为是在以ALGOL 68为表明的高级语言出现之前，软件开发基本上都是用汇编程序设计。尽管此阶段软件工做者开始逐渐造成模块编程的方法，但软件投入的资金和人力没法预测，软件完工的时间没法肯定，软件的可靠性没法控制等问题开始表露出来，软件危机今后阶段开始出现。一个著名的例子是1962年7月美国飞往金星的火箭控制系统中的指令，“DO 5 I=1, 3”误写成“DO 5 I=1.3”，致使火箭偏离轨道，被迫炸毁。

　　由于此阶段系统规模较小，不多明确考虑软件体系结构，因此通常不存在软件系统的建模工做。

 

 

 3.2  萌芽阶段

　　在1968年NATO会议上，“软件工程”的概念首次被提出。自此，围绕软件项目，开展了有关开发模型、方法以及支持工具的研究。其主要成果有：提出了瀑布模型，开发了一些结构化程序设计语言(例如PASCAL语言、Ada语言)，结构化软件开发技术，而且围绕项目管理提出了费用估算、文档复审等方法和工具。

 　　结构化软件开发技术在20世纪70年代中后期出现，以PASCAL、COBOL等程序设计语言和关系数据库管理系统为标志，以强调数据结构、程序模块化结构为特征，采用自顶向下逐步求精的设计方法和单入口单出口的控制结构。随着结构化开发技术的出现与普遍应用，软件开发中出现了以数据流设计和控制流设计为主要任务的概要设计和详细设计。伴随着结构化软件技术而出现的软件工程方法(包括CASE工具)，使软件工做的范围从只考虑程序的编写扩展到从定义、编码、测试到使用、维护等活动的整个软件生命周期。

　　 总的说来，在此阶段，软件体系结构已是系统开发中的一个明确概念。结构化程序中，由语句构成模块，模块的汇集和嵌套又构成层层调用的高层结构。这种程序(表达)结构和(计算的)逻辑结构的一致性造成告终构化程序的体系结构。

　　结构化程序设计时代程序规模不算大，同时，采用结构化程序设计方法进行自顶向下逐步求精的设计，并注意模块的耦合性，就能够获得相对良好的结构。所以，体系结构问题并非当时软件开发中的主要问题，也就没有开展深刻的研究工做。

 

 

 3.3  初级阶段

　　20世纪80年代初，面向对象开发技术逐渐兴起。随着面向对象技术成为研究的热点，出现了几十种支持软件开发的面向对象方法。其中，Booch、Coad/Yourdon、OMT和Jacobson的方法在面向对象软件开发界获得了普遍的承认。

　　面向对象开发技术以对象做为最基本的元素，将软件系统当作是离散的对象的集合。一个对象既包括数据，也包括行为。 

 　　面向对象方法都支持3种基本的活动：识别对象和类，描述对象和类之间的关系，以及经过描述每一个类的功能定义对象的行为。对象技术的优势在于，它能让分析者、设计者及用户更清楚地表达概念，相互交流；同时，它做为描述、分析和创建软件文档的一种手段，大大提升了软件的易读性、可维护性、可重用性；使得从软件分析到软件设计的过渡很是天然，所以可显著下降软件开发成本。另外，面向对象技术中的继承、封装、多态性等机制，直接为软件重用提供了进一步的支持。在面向对象开发方法阶段，因为对象是对数据及其操做的封装，于是数据流设计与控制流设计统一为对象建模。 

 　　同时，面向对象方法还提出了一些其余的结构视图。如OMT方法提出了功能视图、对象视图和动态视图，Booch方法提出了类视图、对象视图、状态迁移图、交互做用图、模块图、进程图，UML则从功能模型、静态模型、动态模型、配置模型等方面描述应用系统的结构。

 　　从1994年开始，Booch、Rumbaugh和Jacobson三人通过共同努力，推出了统一建模语言UML(Unified Modeling Language)。它结合了Booch、OMT和Jacobson方法的优势，统一了符号体系，并从其余的方法和工程实践中吸取了许多通过实际检验的经验和技术。对象管理组织OMG于1997年11月正式采纳UML1.1做为建模语言规范，而后成立任务组不断修订。尽管UML取得了巨大成功，但仍然有一些批评意见。工业界的批评主要是，它的庞大和复杂使得多数用户难以实际应用或只能应用少量概念。学术界的批评则主要针对它在理论上的缺陷和错误，包括语言体系结构、语法、语义等方面的问题。

 　　随着抽象数据类型和面向对象技术的出现，体系结构研究逐渐获得重视。这是由如下因素决定的：对象的封装减低了模块间的耦合，为构件层次上的软件重用提供了可能；此外，类库的构造、分布式应用系统的设计等规模大、复杂性高的系统，也须要对体系结构进行研究。

 

3.4  高级阶段

　　20世纪90年代后，软件开发技术进入了基于构件的软件开发阶段。软件开发的目标是软件具有很强的自适应性、互操做性、可扩展性和可重用性，软件开发强调采用构件化技术和体系结构技术。

　　软件构件技术与面向对象技术有着重要的不一样。面向对象技术中的软件重用主要是源代码形式的重用，这要求设计者在重用软件时必须理解其设计思路和编程风格。软件构件技术则实现了对软件的最终形式——可执行二进制码的重用。这样，构件的实现是彻底与实现语言无关的。任何一种过程化语言，从Ada到C到Java到C#，都可用来开发构件，而且任何一种程序设计语言均可以直接或稍做修改后使用构件技术。一个软件可被切分红一些构件，这些构件能够单独开发、单独编译，甚至单独调试与测试。当完成了全部构件的开发，再对它们加以组合，就获得了完整的软件系统。在投入使用后，不一样的构件还能够在不影响系统的其余部分的状况下，分别进行维护和升级。

　　此阶段中，软件体系结构逐渐成为软件工程的重要研究领域，并最终做为一门学科获得了业界的广泛认同。在基于构件和体系结构的软件开发方法下，程序开发模式也相应地发生了根本变化。软件开发再也不是“算法+数据结构”，而是“构件开发+基于体系结构的构件组装”。软件体系结构做为开发文档和中间产品，开始出如今软件过程当中。有研究人员认为，“将来的年代将是研究软件体系结构的时代”。

 

3.5 综合　　

　　从软件技术的发展过程能够看出，在各个时期，软件体系结构的问题实际上老是存在的，可是它是随着软件系统的规模和复杂性的日益膨胀才逐渐表露、被人们发现和研究的。从最初的“无体系结构”设计到今天的基于体系结构的软件开发，软件体系结构技术大体经历了如下4个阶段：

• 　　(1) “无体系结构”设计阶段：开发主要采用汇编语言，规模通常较小。
• 　　(2) 萌芽阶段：主要采用结构化的开发技术。
• 　　(3) 初级阶段：主要采用面向对象的开发技术，从多种角度对系统建模(如UML)。
• 　　(4) 高级阶段：该阶段以Kruchten提出的“4+1”模型为标志。软件开发的中心是描述系统的高层抽象结构模型，相比之下，传统的软件结构更关心具体的建模细节。

　　软件体系结构技术仍存在诸多问题，如概念定义尚不统1、描述规范不能一致等。有研究人员认为在软件开发实践中软件体系结构尚不能发挥重要做用，软件体系结构技术仍有待研究、发展和完善。
　

 

4.软件体系结构的研究现状及发展方向

4.1 软件体系结构的研究现状

　　软件体系结构做为软件工程研究领域的一部分，已经取得了长足的发展，受到大多数软件系统设计和研究人员的重视。但当前，体系结构还是一个处在不断发展中的新研究领域，许多定义还不够统一，概括现有体系结构的研究活动，主要的讨论和研究大体集中在如下几个方面。　　

1．软件体系结构描述研究

　　构建软件体系结构的目的之一就是创建一个可供各类人员交流的平台，而且要具有系统架构级的可重用性。所以如何恰当、准确地对软件体系结构进行描述是相当重要的。这种描述应当可以为各类人员提供不一样的视图以知足其不一样的要求；同时，当要构建新的应用或对应用进行系统级更改时，这种描述应该可以快速提供可重用的系统架构视图或系统模块视图。这方面的研究包括软件体系结构描述语言、使用“4+1” 模型描述软件体系结构、使用UML描述软件体系结构等方面的研究。

　　1) 软件体系结构描述语言
　　现有的一些软件体系结构描述方法采用非形式化的方法，体系结构设计常常难以理解，难以对体系结构进行形式化分析和模拟，缺少相应的支持工具帮助设计师完成设计工做。为了解决这个问题，用于描述和推理的形式化语言得以发展，这些语言就叫作体系结构描述语言(Architecture Description Language，ADL)，ADL寻求增长软件体系结构设计的可理解性和重用性。
　　ADL是这样一种语言，系统设计师能够利用它所提供的特性进行软件系统概念体系结构建模。ADL提供了具体的语法与刻画体系结构的概念框架。它使得系统开发者可以很好地描述他们设计的体系结构，以便与他人交流，可以用提供的工具对许多实例进行分析。
　　研究人员已经设计出了若干种ADL，典型的有Aesop、MetaH、C二、Rapide、SADL、UniCon和Wright等，尽管它们都描述软件体系结构，却有不一样的特色：Aesop支持体系结构风格的应用；MetaH为设计者提供了关于实时电子控制软件系统的设计指导；C2支持基于消息传递风格的用户界面系统的描述；Rapide支持体系结构设计的模拟并提供了分析模拟结果的工具；SADL提供了关于体系结构加细的形式化基础；UniCon支持异构的构件和链接件类型，并提供了关于体系结构的高层编译器；Wright支持体系结构构件之间交互的说明和分析。
　　这些ADL及它们的支持工具、描述方法和形式各不相同，强调了体系结构不一样的侧面，对体系结构的研究和应用起到了重要的做用，但也有负面的影响。每一种ADL都以独立的形式存在，描述语法不一样且互不兼容。同时又有许多共同的特征，这使设计人员很难选择一种合适的ADL；大部分ADL都是领域相关的，不利于对不一样领域的体系结构进行分析；一些ADL在某些方面大同小异，有不少冗余的部分。
　　针对这些不足，已出现一些交换语言，其目标是提供一个公共形式把各类语言综合起来，以此来综合不一样的体系结构描述。ACME就是其中较有影响的一个，它的目标是抽取诸多ADL中与具体ADL无关的信息做为交换的依据，同时，容许并入相关信息做为保留的辅助信息。另一个研究热点是开发基于XML的体系结构描述语言。XML是可扩展标记语言，它简单并易于实现，所以被工业界普遍使用。若能用XML来表示软件体系结构，必能极大推进软件体系结构领域的研究成果在软件产业界的应用。因为XML在体系结构描述上的许多优势，研究者们已经开发出了不一样的基于XML的体系结构描述语言，如XADL1.0、XBA、XCOBA等。

　　2) 使用“4+1” 模型描述软件体系结构
　　按照必定的描述方法，用体系结构描述语言对体系结构进行说明的结果称为体系结构的表示，而将描述体系结构的过程称为体系结构构造。在体系结构描述方面，Kruchten提出的“4+1”模型是当前软件体系结构描述的一个经典范例，该模型由逻辑视图、开发视图、过程视图和物理视图组成，并经过场景将这4个视图有机地结合起来，比较细致地描述了需求和体系结构之间的关系。
　　“4+1”模型实际上使得有不一样需求的人员可以获得他们对于软件体系结构想要了解的东西。系统工程师先从物理视图，而后从过程视图靠近体系结构。最终使用者、客户、数据专家从逻辑视图看体系结构；项目经理、软件配置人员从开发视图看体系结构。

　　3) 使用UML描述软件体系结构
　　Booch从UML的角度给出了一种由设计视图、过程视图、实现视图和部署视图，再加上一个用例视图构成的体系结构描述模型。Medividovic则总结了用UML描述体系结构的三种途径：不改变UML用法而直接对体系结构建模；利用UML支持的扩充机制扩展UML的元模型对体系结构建模概念的支持；对UML进行扩充，增长体系结构建模元素。本书第3章介绍了不改变UML用法而直接对体系结构建模的方法。UML的静态建模机制包括用例图、类图、对象图、包、构件图和部署图。UML的动态建模机制包括顺序图、协做图、状态图和活动图。能够使用UML对构件交互模式进行静态建模和动态建模。

　　2.软件体系结构设计研究

　　软件体系结构设计研究包括体系结构风格研究、体系结构设计原理、设计模式和设计方法研究。
　　1) 体系结构风格研究
　　体系结构设计研究的重点内容之一就是体系结构风格的研究。人们在开发不一样系统时，会逐渐发现一类系统的体系结构上有许多共性，因而抽取出这些共性构成一些富有表明性和被普遍接受的体系结构风格。因此说体系结构风格是用来刻画具备类似结构和语义性质的一类系统族的。它定义一组构件、链接件的类型以及它们之间应该如何链接的约束。
　　通常来讲，一个系统不必定只具备一种风格，在不一样层次或抽象级别上，可具备多种风格。虽然系统组织方式能够是无穷的，但若是能用少许的风格类型表达出较多的系统组织方式，不只能够缩短系统分析设计的时间，还能大大提升大规模软件重用的机会。
　　Garlan和Shaw给出了对通用体系结构风格的分类：数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。

　　2) 体系结构设计原理
　　参照软件工程、结构化程序设计和面向对象程序设计原理，结合软件体系结构设计自己的特色，能够总结出软件体系结构设计过程当中用到的原理主要有如下几个：抽象、封装、信息隐藏、模块化、注意点分离、耦合和内聚、接口和实现分离、分而治之、层次化等。

　　3) 体系结构设计模式
　　设计模式的概念最先是由美国的一位叫作Christopher Alexander的建筑理论家提出来的，他试图找到一种结构化、可重用的方法，以在图纸上捕捉到建筑物的基本要素。后来被做为总结软件设计，特别是面向对象设计的实践和经验而提出。在几十年的软件设计研究和实践中，设计人员和程序员积累了大量的实际经验，发现并提出了大量在众多应用中广泛存在的软件结构和结构关系，模式被用于软件体系结构设计中。利用设计模式能够方便地重用成功的设计和结构。把已经证明的技术表示为设计模式，使它们更加容易被新系统的开发者所接受。设计模式帮助设计师选择可以使系统重用的设计方案，避免选择危害到可重用性的方案。

　　4) 体系结构设计方法
　　生成一个知足软件需求的体系结构的过程即为体系结构设计。体系结构设计过程的本质在于：将系统分解成相应的组成成分(如构件、链接件)，并将这些成分从新组装成一个系统。经常使用的体系结构设计方法有4类，分别为制品驱动(artifact-driven)的方法，用例驱动(use-case-driven)的方法，模式驱动(pattern-driven)的方法和领域驱动(domain-driven)的方法。每种方法在过程的顺序上、在概念的特定内容上有所不一样，但最后都生成对体系结构的描述。

　　3．基于体系结构的软件开发方法

　　本质上，软件体系结构是对软件需求的一种抽象解决方案。在引入了体系结构的软件开发中，应用系统的构造过程变为“问题定义→软件需求→软件体系结构→软件设计→软件实现”，能够认为软件体系结构架起了软件需求与软件设计之间的一座桥梁。而在由软件体系结构到实现的过程当中，借助必定的中间件技术与软件总线技术，软件体系结构易于映射成相应的实现。Bass等人提出了一种基于体系结构的软件开发过程，该过程包括6个步骤：导出体系结构需求；设计体系结构；文档化体系结构；分析体系结构；实现体系结构；维护体系结构。对此在本书第5章中会进行介绍。
　　软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的所有工做和任务的结构框架，给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大体可分为3种类型：
　　(1) 以软件需求彻底肯定为前提的瀑布模型。
　　(2) 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型等。
　　(3) 以形式化开发方法为基础的变换模型。
　　全部开发方法都是要解决需求与实现之间的差距。可是，这3种类型的软件开发模型都存在这样或那样的缺陷，不能很好地支持基于软件体系结构的开发过程。所以，研究人员在发展基于体系结构的软件开发模型方面作了必定的工做。
　　在基于构件和基于体系结构的软件开发逐渐成为主流的开发方法的状况下，已经出现了基于构件的软件工程。可是，对体系结构的描述、表示、设计和分析以及验证等内容的研究还相对不足，随着需求复杂化及其演化，切实可行的体系结构设计规则与方法将更为重要。

　　4．软件体系结构评估

　　软件体系结构的设计是整个软件开发过程当中关键的一步。对于当今世界上庞大而复杂的系统来讲，没有一个合适的体系结构而要有一个成功的软件设计几乎是不可想象的。不一样类型的系统须要不一样的体系结构，甚至一个系统的不一样子系统也须要不一样的体系结构。体系结构的选择是一个软件系统设计成败的关键。
　　可是，怎样才能知道为软件系统所选用的体系结构是否恰当？如何确保按照所选用的体系结构能顺利地开发出成功的软件产品呢？要回答这些问题，须要使用专门的方法对软件体系结构进行分析和评估。
　　经常使用的软件体系结构评估方法有软件体系结构分析方法(Software Architecture Analysis Method，SAAM)和体系结构权衡分析方法(Architecture Tradeoff Analysis Method，ATAM)。它们都是基于场景的软件体系结构评估方法，这类评估方法分析软件体系结构对场景也就是对系统的使用或修改活动的支持程度，从而判断该体系结构对这一场景所表明的质量需求的知足程度。例如，用一系列对软件的修改来反映易修改性方面的需求，用一系列攻击性操做来表明安全性方面的需求等。SAAM本质上是一个寻找受场景影响的体系结构元素的方法，而ATAM创建在SAAM基础上，关注对风险、非风险、敏感点和权衡点的识别。

　　5．特定领域的体系结构框架

　　特定领域的应用一般具备类似的特征，若是可以充分挖掘系统所在领域的共同特征，提炼出领域的通常需求，抽象出领域模型，概括总结出这类系统的软件开发方法，就可以指导领域内其余系统的开发，提升软件质量和开发效率、节省软件开发成本。正是基于这种考虑，人们在软件的理论研究和工程实践中，逐渐造成一种称之为特定领域的软件体系结构(Domain Specific Software Architecture，DSSA)的理论与工程方法，它对软件设计与开发过程具备必定参考和指导意义，已经成为软件体系结构研究的一个重要方向。
　　Rick Hayers-Roth和Will Tracz分别对DSSA给出了不一样的定义，前者侧重于DSSA的特征，强调系统由构件组成，适用于特定领域，有利于开发成功应用程序的标准结构；后者侧重于DSSA的组成要素，指出DSSA应该包括领域模型、参考需求、参考体系结构、相应的支持环境或设施、实例化、细化或评估的方法与过程。两种DSSA定义都强调了参考体系结构的重要性。
　　特定领域的体系结构是将体系结构理论应用到具体领域的过程，常见的例子有：
　　(1) 用户界面工具和框架。能够为开发者提供可重用框架以及像菜单、对话框等可重用构件的集合。
　　(2) 编译器的标准分解。体系结构的重用能使语言编译系统的开发变得很是简单。
　　(3) 标准化的通讯协议。经过在不一样层次的抽象上提供服务，可实现跨平台的交互。

　　6．软件体系结构支持工具

　　几乎每种体系结构都有相应的支持工具，如UniCon、Aesop等体系结构支持环境，C2的支持环境ArchStudio，Acme的支持环境AcmeStudio，支持主动链接件的Tracer工具等。另外，还出现了不少支持体系结构的分析工具，如支持静态分析的工具、支持类型检查的工具、支持体系结构层次依赖分析的工具、支持体系结构动态特性仿真工具、体系结构性能仿真工具等。但与其余成熟的软件工程环境相比，体系结构设计的支持工具还很不成熟，难以实用化。本书经过两个较为著名的软件体系结构集成开发环境ArchStudio4和AcmeStudio，介绍软件体系结构集成开发环境的具体功能。

 

 

 

4.2 软件体系结构的发展方向　　

1．各类软件体系结构语言之间的信息互换　　

　　现有的各类软件体系结构描述语言大可能是与领域相关的，因此不利于对不一样领域体系结构的说明。但这些针对不一样领域的软件体系结构描述语言在某些方面又大同小异，形成资源的冗余。其实，大多数软件体系结构描述语言具备一系列共同概念。如何用一种公共形式把各类语言综合起来，使得可以交换各类体系结构描述信息，将是从此软件体系结构研究和实践的重点之一。

2.设计工具和环境

　　软件体系结构设计做为软件工程的一部分，它的计算机辅助实现手段是至关重要的。应当开发出一些软件工具来实现体系结构的描述和分析，开发阶段转换工具能够实现阶段成果的自动转换，例如，把需求规格说明自动转换为构件等。目前关于这方面的研究成果不多，特别是能够应用到实际项目开发中的工具和环境就更少。

3．体系结构再工程问题

　　如今软件系统的规模变得愈来愈大，结构也愈来愈复杂，同时从头开始构建的大系统数量在急剧地减小，于是不少遗留系统正在被逐步地利用。从遗留系统软件代码和系统中抽取结构信息，通过描述、统1、抽象、通常化与实例化等处理，可总结出系统的体系结构。

 

5 本 章 小 结

　　本章首先介绍了软件体系结构的各类定义和基本概念，它们是本章的重点。考虑到定义的通常适用性和被普遍接受的程度，咱们所提到的软件体系结构，都以定义5中的软件体系结构概念为基础。构件、链接件和约束(配置)等概念是软件体系结构最基本的元素。
　　接下来介绍了软件体系结构研究的意义，良好的体系结构对于软件系统的重要意义在软件生命周期中的各个阶段都有体现。
　　软件体系结构发展到如今共经历了4个发展阶段：“无体系结构”设计阶段、萌芽阶段、初级阶段和高级阶段，对每一阶段进行了简单介绍。概括现有软件体系结构的研究活动，介绍了软件体系结构研究现状和发展方向。当前的体系结构研究主要集中在软件体系结构描述研究、设计研究、分析与评估、支持工具，基于体系结构的开发方法、特定领域的体系结构框架等方面。
　　软件体系结构技术目前仍存在诸多问题，如概念定义尚不统1、描述规范不能一致等。有研究人员认为在软件开发实践中软件体系结构尚不能发挥重要做用，软件体系结构技术仍有待研究、发展和完善。

　　1．为何要研究软件体系结构？
　　1.根据软件体系结构的定义，你认为软件体系结构的模型应该由哪些部分组成？
　　3．软件体系结构的概念和建筑中的体系结构的概念相相似，两者有什么共同之处？这种类比对于咱们认识和研究软件体系结构有何帮助？
　　4．结合本身曾参与开发的软件项目，思考构件、链接件和约束的概念，并用本身的语言描述构件、链接件和约束的特色，进一步论述构件、链接件和约束分别对于软件体系结构的重要意义。
　　5．查阅相关文献，比较各类软件体系结构定义，进一步讨论它们的联系和区别。