软件体系结构的兴起和发展
20世纪60年代的软件危机使得人们开始重视软件工程的研究。起初，人们把软件设计的重点放在数据结构（data structure）和算法（algorithmic）的选择上，随着软件系统规模越来越大、越 来越复杂，整个系统的结构和规格说明显得越来越重要。随着软件危机的程度日益加剧，现有的软 件工程方法对此显得力不从心。对于大规模的复杂软件系统来说，对总体的系统结构设计和规格说 明比起对计算的算法和数据结构的选择已经变得明显重要得多。在此种背景下，人们认识到软件体系结构（software architecture）的重要性，并认为对软件体系结构的系统、深入的研究将会成为 提高软件生产率和解决软件维护问题的新的最有希望的途径。
自从软件系统首次被分成许多模块，模块之间有相互作用，组合起来有整体的属性，就具有了 体系结构。优秀的开发者常常会使用一些体系结构模式（architecture pattern）作为软件系统结构 设计策略，但他们并没有规范地、明确地表达出来，这样就无法将他们的知识与别人交流。软件体 系结构是设计抽象的进一步发展，满足了更好地理解软件系统，更方便地开发更大、更复杂的软件 系统的需要。
事实上，软件总是有体系结构的，不存在没有体系结构的软件。体系结构一词在英文里就是 “建筑”的意思。把软件比作一座楼房，从整体上讲，是因为它有基础、主体和装饰，即操作系统 之上的基础设施软件、实现计算逻辑的主体应用程序、方便使用的用户界面程序。从细节上来看每一个程序也是有结构的。早期的结构化程序就是以语句组成模块，模块的聚集和嵌套形成层层调用的程序结构，也就是体系结构。结构化程序的程序（表达）结构和（计算的）逻辑结构的一致性及 自顶向下开发方法自然而然地形成了体系结构。由于结构化程序设计时代程序规模不大，通过强调 结构化程序设计方法学，自顶向下、逐步求精，并注意模块的耦合性就可以得到相对良好的结构， 所以，并未特别研究软件体系结构。
可以作个简单的比喻，结构化程序设计时代是以砖、瓦、灰、沙、石、预制梁、柱、屋面板盖 平房和小楼，而面向对象时代以整面墙、整间房、一层楼梯的预制件来盖高楼大厦。构件怎样搭配 才合理？体系结构怎样构造容易？重要构件有了更改后，如何保证整栋高楼不倒？每种应用领域 （医院、工厂、旅馆等）需要什么构件？有哪些实用、美观、强度、造价合理的构件骨架使建造出 来的建筑（即体系结构）更能满足用户的需求？如同土木工程进入到现代建筑学一样，软件也从传 统的软件工程进入到现代面向对象的软件工程，研究整个软件系统的体系结构，寻求建构最快、成 本最低、质量最好的构造过程。
软件体系结构虽脱胎于软件工程，但其形成同时借鉴了计算机体系结构和网络体系结构中很多 宝贵的思想和方法，最近几年软件体系结构研究已完全独立于软件工程的研究，成为计算机科学的 一个最新的研究方向和独立学科分支。软件体系结构研究的主要内容涉及软件体系结构描述、软件 体系结构风格、软件体系结构评价和软件体系结构的形式化方法等。解决好软件的重用、质量和维 护问题，是研究软件体系结构的根本目的。
软件体系结构的定义
虽然软件体系结构已经在软件工程领域中有着广泛的应用，但迄今为止还没有一个被大家所公认的定义。许多专家学者从不同角度和不同侧面对软件体系结构进行了刻画，较为典型的定义有以 下几个。
（1）Dewayne Perry和A1exander Wo1f曾这样定义：软件体系结构是具有一定形式的结构化 元素（element），即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进 行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组组合连接起来。这一定义注 重区分处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基本上得到保持。 （2）Mary Shaw和David Garlan认为软件体系结构是软件设计过程中的一个层次，这一层次 超越计算过程中的算法设计和数据结构设计。体系结构问题包括总体组织和全局控制、通讯协议 （protocol）、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各 设计方案间进行选择等。软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面 的一些问题，如全局组织和全局控制结构、关于通讯、同步与数据存取的协议，设计构件功能定 义，物理分布与合成，设计方案的选择、评估（evaluation）与实现等。
（3）Kruchten指出，软件体系结构有四个角度，它们从不同方面对系统进行描述：概念 （concept）角度描述系统的主要构件及它们之间的关系；模块角度包含功能分解与层次结构；运行 角度描述了一个系统的动态结构；代码角度描述了各种代码和库函数在开发环境中的组织。
（4）Hayes Roth则认为软件体系结构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。
（5）David Garlan和Dewne Perry于1995年在IEEE（Institute of Electrical and Electronics Engineers，国际电气和电子工程师协会）软件工程学报上又采用如下的定义：软件体系结构是一个 程序/系统各构件的结构、它们之间的相互关系以及进行设计的原则和随时间演化（evolution）的 指导方针。
（6）Barry Boehm和他的学生提出，一个软件体系结构包括一个软件和系统构件，互联及约束 的集合；一个系统需求说明的集合；一个基本原理用以说明这一构件，互联和约束能够满足系统需 求。
（7）1997年，Bass，Ctements和Kazman在《使用软件体系结构》一书中给出如下的定义： 一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其 相互关系。其中，“软件外部的可见特性”是指软件构件提供的服务、性能、特性、错误处理、共 享资源使用等。
总之，软件体系结构的研究正在发展，软件体系结构的定义也必然随之完善。
可以使用软件体系结构的下列定义： 软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描 述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件体系结构不仅指定 了系统的组织（organization）结构和拓扑（topology）结构，并且显示了系统需求和构成系统的 元素之间的对应关系，提供了一些设计决策的基本原理。
软件体系结构的意义
以现代建筑为例，不管建多高的楼盘，都是先用钢筋和水泥搭起框架（在建筑业中称之为“框剪结构”），在此结构中再用各种砖头砌墙。这样的楼房，在建好后，业主在装修时可以敲掉任何 一堵非承重墙，也可以在任何地方加一堵新墙，都不会影响到整栋楼的质量。
如果把软件系统看作是一栋楼，则软件体系结构就是这栋楼的框剪结构。换句话说，软件体系 结构是整个软件系统的骨架，在软件开发中起着非常重要的作用。
1、体系结构是风险承担者进行交流的手段
软件体系结构代表了系统的公共的高层次的抽象。这样，系统的大部分有关人员（即使不是全 部）能把它作为建立一个互相理解的基础，形成统一认识，互相交流。
因为软件系统的各个风险承担者（客户、用户、项目管理人员、设计开发人员以及测试人员 等）关心着系统的各个不同方面，而这些方面都受体系结构的影响，所以体系结构可能是大家都关 心的一个重要因素（即使是从不同愿望出发）。例如，用户关心系统是否满足可用性和可靠性需 求；客户关心的是系统能否在规定时间内完成，并且开支在预算范围内。管理人员担心在经费支出 和进度条件下，按此体系结构能否使开发组成员在一定程度上独立开发，各部分的交互是否遵循统 一的规范，开发进度是否可控；开发人员关心的是如何才能实现体系结构的各项目标。
总之，体系结构提供了一种共同语言来表达各种关注和协商，进而对大型复杂系统能进行理智的管理。这对项目最终的质量和使用有极大的影响。
2、体系结构是早期设计决策的体现
软件体系结构体现了系统的最早的一组设计决策（decision），这些早期的约束比起以后的开 发、设计、编码或运行服务及维护阶段的工作重要得多，对系统生命周期（life cycle）的影响也大 得多。早期决策的正确性最难以保证，而且这些决策也最难以改变，影响范围也最大。
（1）软件体系结构明确了对系统实现的约束条件
所谓“实现”就是要用实体来显示出一个软件体系结构，即要符合体系结构所描述的结构性设 计决策，分割成规定的构件，按规定方式互相交互。如果系统实现严格遵循体系结构设计中所做出 的关于系统结构的决策，则系统实现将能够体现出体系结构的特色。也就是说，在具体实现时必须 按照体系结构的设计，将系统分成若干个组成部分，各部分必须按照预定的方式进行交互，而且每 个部分也必须具有体系结构中所规定的外部特征。 这些约束是在系统级或项目范围内作出的，每个构件上工作的实现者是看不见的。这样一来， 可以分离着重点，软件体系结构的设计者不必是算法设计者或精通编程语言，只需重点考虑系统的 总体权衡（tradeoff）问题；而构件的开发人员在体系结构给定的约束下进行开发。
（2）软件体系结构决定了开发和维护组织的组织结构
体系结构不仅规定了所开发软件的系统结构，还影响着项目开发组织的结构。开发一个大型系 统时，常见的任务划分方法是系统的任务划分结构，即将系统的不同部分交由不同的小组去开发完 成。体系结构中包含了对系统的最高层次的分解，因而一般被作为任务划分结构的基础。 任务划分结构又规定了计划、调度及预算的单位，决定了组内交流的渠道、配置控制和文件系 统的组织、集成（integration）与测试计划和过程，甚至对电子公告牌的组织、开发小组出去野餐 的次数这样的琐碎细节也提出了要求。各开发小组按照体系结构中对各主要构件接口的规定进行交 流。一旦进入维护阶段，维护活动也会反映出软件的结构，常由不同的小组分别负责对各具体部分 的维护。
（3）软件体系结构制约着系统的质量属性
一个大型系统能否具有所期望的质量属性，主要是由确定体系结构的时间决定的。小的软件系 统可以通过编程或调试措施来达到质量属性的要求，而随着软件系统规模的扩大，这种技巧也将越 来越无法满足要求。这是因为，在大型软件系统中，质量属性更多地是由系统结构和功能划分来实 现的，而不再主要依靠所选用的算法或数据结构。 系统的质量属性可以分为两类：第一类是可以通过运行软件并观察其效果来度量的，如功能、 性能、安全性及可靠性等；第二类是指那些无法通过观察系统来度量，只能通过观察开发活动或维 护活动来考察的特性，包括各种可维护性问题，如可适应性、可移植性、可重用性等（例如，可重 用性依赖于系统中的构件与其他构件的联系情况）。必须认识到：软件体系结构并不能单独保证系 统所要求的功能与质量。低劣的下游设计及实现都会破坏一个体系结构的构架。好的软件体系结构 是必要条件，但不是成功的充分条件。
（4）通过研究软件体系结构可能预测软件的质量
能否在系统开发或使用之前就确知在体系结构上做了哪些合理的决策（例如，系统是否将表现 出所期望的质量属性？），答案是否定的。从理论上来说，用某种方法选择体系结构和随机选择一 个体系结构没有什么两样。然而，可以使用对体系结构的评价来预测系统未来的质量属性。一些体系结构评估技术可使设计师全面地对按某软件体系结构开发出来的软件产品的质量及 缺陷做出比较准确的预测。
（5）软件体系结构使推理和控制更改更简单
按照经典软件工程理论，软件维护阶段所花费的成本占整个软件生命周期中的60%-80%。根据 这一论断，许多（即使不是全部）程序员或设计师从来没有进行过新系统的开发，而仅仅是在已有 代码的基础上工作。 在整个软件生命周期内，每个体系结构都将更改划分为三类：局部的、非局部的和体系结构级 的变更。局部变更是最经常发生的，也是最容易进行的，只需修改某一个构件就可以实现。非局部 变更的实现则需对多个构件进行修改，但并不改动体系结构。体系结构级的变更是指会影响各部分 的相互关系，甚至要改动整个系统。所以，一个优秀的体系结构应该能使更改简单易行。 重要的是要确定何时必须更改，确定哪种更改方式的风险最小，评估更改的效果，以及合理安 排所提出的更改的实施顺序和优先级等。所有这些都需要深入地洞察系统的各部分的关系、相互依 赖关系、性能及行为特性。
（6）软件体系结构有助于循序渐进的原型设计
一旦确定了体系结构，就可以对其进行分析，并将其按可执行模型来构造原型（prototype）。 从两个方面有助于开发活动的顺利进行，一是可以在软件生命周期的早期阶段明确潜在的系统性能 问题，二是在软件生命周期的早期阶段就能得到一个可执行的系统。这两个方面都将减少项目开发 的潜在风险。如果所用的体系结构是若干相关体系结构中的一个，则构建原型框架的代价就可以分 摊到多个系统上。
（7）软件体系结构可以作为培训的基础
在对项目组新成员介绍所开发的系统时，可以首先介绍系统的体系结构，以及对构件之间如何 交互从而实现系统需求的高层次的描述，让项目新成员很快进入角色。
3、软件体系结构是可传递和可重用的模型
软件体系结构体现了一个相对来说比较小又可理解的模型。
软件体系结构级的重用意味着体系结构的决策能在具有相似需求的多个系统中发生影响，这比 代码级的重用要有更大的好处。通过对体系结构的抽象可以使设计师能够对一些经过实践证明是非 常有效的体系结构构件进行重用，从而提高设计的效率和可靠性。在设计过程中，设计师常常会发 现，对一个体系结构中的构件稍加抽象，就可以将它应用到其他设计中去，这样会大大降低设计的 复杂度。例如，在某个设计中采用了管道与过滤器（pipe-filter）体系结构风格（见3.1.1节），当 将系统映射到Unix系统中时，就会发现Unix系统已经为用户提供了功能丰富的管道与过滤器功能， 这样，用户就可以充分利用Unix系统提供的这些构件来简化设计和开发。 鉴于体系结构的重要性，Perry将软件体系结构视为软件开发中第一类重要的设计对象，Barry Boehm也明确指出：“在没有设计出体系结构及其规则时，那么整个项目不能继续下去，而且体系 结构应该看作是软件开发中可交付的中间产品”。由此可见，体系结构在软件开发中为不同的人员 提供了共同交流的语言，体现并尝试了系统早期的设计决策，并作为系统设计的抽象，为实现框架 和构件的共享和重用、基于体系结构的软件开发提供了有力的支持。
软件体系结构的发展史
软件系统的规模在迅速增大的同时，软件开发方法也经历了一系列的变革。在此过程中，软件体系结构也由最初模糊的概念发展到一个渐趋成熟的理论和技术。
20世纪70年代以前，尤其是在以ALGOL 68为代表的高级语言出现以前，软件开发基本上都是 汇编程序设计，此阶段系统规模较小，很少明确考虑系统结构，一般不存在系统建模工作。70年代 中后期，由于结构化开发方法的出现与广泛应用，软件开发中出现了概要设计与详细设计，而且主 要任务是数据流设计与控制流设计，因此，此时软件结构已作为一个明确的概念出现在系统的开发 中。
20世纪80年代初到90年代中期，是面向对象开发方法兴起与成熟阶段。由于对象是数据与基于 数据之上操作的封装，因而在面向对象开发方法下，数据流设计与控制流设计则统一为对象建模， 同时，面向对象方法还提出了一些其他的结构视图。例如，OMT（Object Modeling Technology，对象建模技术）方法提出了功能视图、对象视图与动态视图（包括状态图和事件追踪 图）；Booch方法提出了类视图、对象视图、状态迁移图、交互作用图、模块图、进程图；统一建 模语言（Unified Modeling Language，UML）则从功能模型（用例视图）、静态模型（包括类 图、对象图、构件图、包图、组合结构图）、动态模型（通信图、顺序图、定时图、状态图、活动 图、交互概览图）、配置模型（制品图、配置图）描述应用系统的结构。
20世纪90年代以后则是基于构件的软件开发阶段，该阶段以过程为中心，强调软件开发采用构 件化技术和体系结构技术，要求开发出的软件具备很强的自适应性、互操作性、可扩展性和可重用 性。此阶段中，软件体系结构已经作为一个明确的文档和中间产品存在于软件开发过程中，同时， 软件体系结构作为一门学科逐渐得到人们的重视，并成为软件工程领域的研究热点。
纵观软件体系结构技术的发展过程，从最初的“无结构”设计到现行的基于体系结构的软件开 发，可以认为经历了4个阶段：
（1）无体系结构设计阶段。以汇编语言进行小规模应用程序开发为特征。
（2）萌芽阶段。出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征。
（3）初期阶段。出现了从不同侧面描述系统的结构模型，以UML为典型代表。
（4）高级阶段。以描述系统的高层抽象结构为中心，不关心具体的建模细节，划分了体系结构 模型与传统软件结构的界限，该阶段以Kruchten提出的“4+1”模型为标志。
软件体系结构的应用现状
目前，软件体系结构领域研究非常活跃，例如，南加州大学专门成立了软件体系结构研究组，曼彻斯特大学专门成立了软件体系结构研究所。同时，业界许多著名企业的研究中心也将软件体系 结构作为重要的研究内容。
归纳现有体系结构的研究活动，主要包括如下几个方面。
1、软件体系结构描述语言
在提高软件工程师对软件系统的描述和理解能力中，虽然软件体系结构描述起着重要作用，但 这些抽象的描述通常是非形式化的和随意的。体系结构设计经常难以理解，难以适于进行形式化分析和模拟，缺乏相应的支持工具帮助设计师完成设计工作。为了解决这个问题，用于描述和推理的形式化语言得以发展，这些语言就叫做体系结构描述语言（Architecture Description Language， ADL），ADL寻求增加软件体系结构设计的可理解性和重用性。
ADL是这样一种语言，系统设计师可以利用它所提供的特性进行软件系统概念体系结构建模。 ADL提供了具体的语法与刻画体系结构的概念框架。ADL使得系统开发者能够很好地描述他们设计 的体系结构，以便与他人交流，能够用提供的工具对许多实例进行分析。
这种描述语言的目的就是提供一种规范化的体系结构描述，从而使得体系结构的自动化分析变 得可能。研究人员已经提出了若干适用于特定领域的ADL，典型的有C2、Wright、Aesop、 Unicon、Rapide、SADL、MetaH、Weaves等。Shaw和Garlan指出，一个好的ADL的框架应具备 如下几个方面的特点，即组装性、抽象性、重用性、可配置性、异构性、可分析性等。在此基础 上，Medividovic提出了一种ADL的分类和比较框架，详细分析了多种典型的ADL的优点与不足，对 当前ADL研究做了比较全面的总结，并为将来的ADL的开发提供了很有价值的参考建议。
在ADL研究方面，国内的一些学者也相应提出了几种比较有特色的ADL，如北京大学杨芙清院 士等人提出的JB/SADL、中科院软件所唐稚松院士等人提出的XYX/ADL、吉林大学金淳兆教授等人 提出的FRADL和Tracer、东北大学刘积仁教授等人提出的A-ADL、北京邮电大学艾波教授等人提出 的XYZ/SAE等。
2、体系结构描述构造与表示
按照一定的描述方法，用体系结构描述语言对体系结构进行说明的结果则称为体系结构的表 示，而将描述体系结构的过程称为体系结构构造。在体系结构描述方面，Kruchten提出的“4+1” 模型是当前软件体系结构描述的一个经典范例，该模型由逻辑视图、开发视图、过程视图和物理视 图组成，并通过场景将这4个视图有机地结合起来，比较细致地描述了需求和体系结构之间的关系 。
而Booch从UML的角度给出了一种由设计视图、过程视图、实现视图和部署视图，再加上一个 用例视图构成的体系结构描述模型。Medividovic则总结了用UML描述体系结构的三种途径：不改 变UML用法而直接对体系结构建模；利用UML支持的扩充机制扩展UML的元模型实现对体系结构建 模概念的支持；对UML进行扩充，增加体系结构建模元素。我国电子科技大学的于卫等人研究了其 中的第二种方案，其主要思路是提炼5个软件体系结构的核心部件，利用UML扩充机制中的一种，给 出了相应的OCL（Object Constraint Language，对象约束语言）约束规则的描述，并且给出了描 述这些元素之间的关系的模型。
IEEE于1995年成立了体系结构工作组，综合了体系结构描述研究成果，并参考业界的体系结构 描述的实践，起草了体系结构描述框架标准IEEE P1471。
Rational从资产重用的角度提出了体系结构描述的规格说明框架（architecture description specification），该建议草案已经提交给OMG，可望成为体系结构描述的规范。IEEE P1471和 Rational 的ADS，都提出了体系结构视点（viewpoint）的概念，并从多个视点描述体系结构的框 架。但问题在于：一个体系结构应该从哪几个视点进行考虑？每个视点由哪些视构成？各种视点应 当使用哪种体系结构描述语言，以及采用哪些体系结构建模和分析技术等问题都未解决。
综上所述，虽然UML作为一个工业化标准的可视化建模语言，支持多角度、多层次、多方面的 建模需求，支持扩展，并有强大的工具支持，确实是一种可选的体系结构描述语言，但是根据 Medividovic给出的体系结构语言的框架，UML不属于体系结构描述语言的范畴。事实上，判断一种语言是否适合用作体系结构描述语言的关键在于，它能否表达体系结构描述语言应该表达的概念与抽象，如果需要转化，其复杂性如何？
3、体系结构分析、设计与验证
体系结构是对系统的高层抽象，并只对感兴趣的属性进行建模。由于体系结构是在软件开发过程之初产生的，因此设计好的体系结构可以减少和避免软件错误的产生和维护阶段的高昂代价。体 系结构是系统集成的蓝本、系统验收的依据，体系结构本身需要分析与测试，以确定这样的体系结 构是否满足需求。体系结构分析的内容可分为结构分析、功能分析和非功能分析。而在进行非功能 分析时，可以采用定量分析方法与推断的分析方法。在非功能分析的途径上，则可以采用单个体系 结构分析与体系结构比较的分析方法。Kazman等人提出了一种非功能分析的体系结构分析方法，并运用场景技术，提出了基于场景的体系结构分析方法，而Barbacci等人提出了多质量 属性情况下的体系结构质量模型、分析与权衡方法。
生成一个满足软件需求的体系结构的过程即为体系结构设计。体系结构设计过程的本质在于： 将系统分解成相应的组成成分（如构件、连接件），并将这些成分重新组装成一个系统。具体说 来，体系结构设计有两大类方法：过程驱动方法和问题列表驱动方法。
前者包括：
（1）面向对象方法，与OOA/OOD相似，但更侧重接口与交互。
（2）“4+1”模型方法。
（3）基于场景的迭代方法。
应该说，基于过程驱动的体系结构设计方法适用范围广，易于裁减，具备动态特点，通用性与 实践性强。而问题列表驱动法的基本思想是枚举设计空间，并考虑设计维的相关性，以此来选择体 系结构的风格（style）。显然，该方法适用于特定领域，是静态的，并可以实现量化体系结构设计 空间。如Allen博士的论文专门研究了用户界面类的量化设计空间，提出了19个功能维，26个结构 维，622条设计规则。
体系结构设计研究的重点内容之一就是体系结构风格或模式，体系结构模式在本质上反映了一 些特定的元素、按照特定的方式组成一个特定的结构，该结构应有利于上下文环境（context）下的 特定问题的解决。体系结构模式分为两个大类：固定术语和参考模型。已知的固定术语类的体系结 构模型包括管道过滤器、客户/服务器、面向对象、黑板、分层、对等模式（基于事件调用方法，隐 式调用，基于推理模式）、状态转换、一些派生的固定术语类的体系结构模式，包括Gen Voca，C2 和REST等；而参考模型则相对较多，常常与特定领域相关，如编译器的顺序参考模型和并行参考模 型、信息系统的参考模型、航空模拟环境系统的参考模型等等。国内学者在这方面也做了不少有益 的工作，如北京大学杨芙清院士等人提出的JB/HBM风格。
体系结构测试着重于仿真系统模型，解决体系结构层的主要问题。由于测试的抽象层次不同， 体系结构测试策略可以分为单元/子系统/集成/验收测试等阶段的测试策略。在体系结构集成测试阶 段，Debra等人提出了一组针对体系结构的测试覆盖标准，Paola Inveradi提出了一种基于CHAM的 体系结构语义验证技术。 应该说，体系结构分析、设计和验证已经取得了很丰富的研究成果。但是这些方法存在着一个 普遍缺点：可操作性差，难于实用化，因此并没有取得很好的实践效果。
4、体系结构发现、演化与重用
体系结构发现解决如何从已经存在的系统中提取软件的体系结构，属于逆向工程范畴。Waters 等人提出了一种迭代（iteration）式体系结构发现过程，即由不同的人员对系统进行描述，然后对 这些描述进行分类并融合，发现并解除冲突，将体系结构新属性加入到已有的体系结构模型中，并 重复该过程直至体系结构描述充分。
由于系统需求、技术、环境、分布等因素的变化而最终导致软件体系结构的变动，称之为软件体系结构演化。软件系统在运行时刻的体系结构变化称为体系结构的动态性，而将体系结构的静态 修改称为体系结构扩展。体系结构扩展与体系结构动态性都是体系结构适应性和演化性的研究范 畴。可以用多值代数或图重写理论来解释软件体系结构的演化。Esteban等人通过研究系统的动态可 配置特性，提出了电信软件体系结构动态修改的方案。体系结构的动态性分为有约束的和无约束的 以及结构动态性和语义动态性。Darwin和C2都直接支持结构动态性，而 CHAM，Wright和Rapide 支持语义动态性。在C2中定义有专门支持体系结构修改的描述语言AML，而Darwin对体系结构的修 改则采用相应的脚本语言，CHAM是通过多值演算实现系统体系结构的变换，Wright通过顺序通信 进程CSP描述构件的交互语义。
体系结构重用属于设计重用，比代码重用更抽象。一般认为易于重用的标准包括：领域易于理 解，变化相对较慢，内部有构件标准，与已存在的基础设施兼容，在大规模系统开发时体现规模效 应。由于软件体系结构是系统的高层抽象，反映了系统的主要组成元素及其交互关系，因而较算法 更稳定，更适合于重用。鉴于软件体系结构是应大系统开发和软件产品线（software product line）技术而出现的，在其二者之间，作者认为：产品线中的体系结构重用将更有现实意义，并具有 更大的相似性。体系结构模式就是体系结构重用研究的一个成果，而体系结构参考模型则是特定域 软件体系结构的重用的成熟的象征。Katwijk等人采用扩展数据流技术EDFG实现了系统与构件的构 造过程，得出了相应的体系结构是易于重用的结论。
总之，重用技术作为软件工程领域倡导的有效技术之一，在基于构件与体系结构的软件开发时 代，软件体系结构重用将是一个重要的主题。
5、基于体系结构的软件开发方法
本质上，软件体系结构是对软件需求的一种抽象解决方案。在引入了体系结构的软件开发之 后，应用系统的构造过程变为“问题定义→软件需求→软件体系结构→软件设计→软件实现”，可 以认为软件体系结构架起了软件需求与软件设计之间的一座桥梁。而在由软件体系结构到实现的过 程中，借助一定的中间件（middleware）技术与软件总线（bus）技术，软件体系结构将易于映射 成相应的实现。Bass等人提出了一种基于体系结构的软件开发过程。国内学者在这方面也做了不少 的工作，如清华大学车敦仁教授等人提出了基于体系结构的应用平台及框架仓库技术，北京邮电大 学艾波教授等人提出了基于体系结构的开发模型中软件体系结构的生命周期模型，北京航空航天大 学陶伟博士等人提出了一种以6个体系结构视图为中心的软件开发方式。
软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结 构框架，给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为三种类型:
（1）以软件需求完全确定为前提的瀑布模型。
（2）在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，例如，螺旋模型、增量 模型、敏捷方法、统一过程等。
（3）以形式化开发方法为基础的变换模型。
所有开发方法都是要解决需求与实现之间的差距。但是，这三种类型的软件开发模型都存在这 样或那样的缺陷，不能很好地支持基于软件体系结构的开发过程。因此，研究人员在发展基于体系 结构的软件开发模型方面做了一定的工作。 在基于构件和基于体系结构的软件开发逐渐成为主流的开发方法的情况下，已经出现了基于构 件的软件工程。但是，对体系结构的描述、表示、设计和分析以及验证等内容的研究还相对不足， 随着需求复杂化及其演化，切实可行的体系结构设计规则与方法将更为重要。
6、特定领域的体系结构框架
鉴于特定领域的应用具有相似的特征，因而经过严格设计，并将直觉的成分减少到最少程度， 可以有效地实现重用，并可借鉴领域中已经成熟的体系结构。Rick Hayers-Roth和Will Tracz分别对 特定领域的体系结构（Domain Specific Software Architecture，DSSA）给出了不同的定义，前 者侧重于DSSA的特征，强调系统由构件组成，适用于特定领域，有利于开发成功应用程序的标准结 构；后者侧重于DSSA的组成要素，指出DSSA应该包括领域模型、参考需求、参考体系结构、相应 的支持环境或设施、实例化、细化或评估的方法与过程。两种DSSA定义都强调了参考体系结构的重 要性。
特定领域的体系结构是将体系结构理论应用到具体领域的过程，常见的DSSA有： CASE体系结 构、CAD软件的参考模型、信息系统的参考体系结构、网络体系结构DSSA、机场信息系统的体系结 构和信息处理DSSA等。国内学者提出的DSSA有：北京邮电大学周莹新博士提出的电信软件的体系 结构，北京航空航天大学金茂忠教授等人提出的测试环境的体系结构等。
软件体系结构充当一个理解系统构件和它们之间关系的框架，特别是那些始终跨越时间和实现 的属性。这个理解对于现在系统的分析和未来系统的综合很有必要。在分析和支持下，体系结构抓 住领域知识和实际的一致，促进设计的评估和构件的实施，减少仿真和构造原型。在综合的支持 下，体系结构提供了建立系列产品的基础，以可预测的方式利用领域知识构造和维护模块、子系统 和系统。 本书的3.10节将详细讨论DSSA相关技术。
7、软件体系结构支持工具
几乎每种体系结构都有相应的支持工具，如Unicon，Aesop等体系结构支持环境，C2的支持环 境ArchStudio，支持主动连接件的Tracer工具等。另外，支持体系结构分析的工具，如支持静态分 析的工具、支持类型检查的工具、支持体系结构层次依赖分析的工具、支持体系结构动态特性仿真 工具、体系结构性能仿真工具等。但与其他成熟的软件工程环境相比，体系结构设计的支持工具还 很不成熟，难以实用化。
8、软件产品线体系结构
软件体系结构的开发是大型软件系统开发的关键环节。体系结构在软件产品线的开发中具有至 关重要的作用，在这种开发生产中，基于同一个软件体系结构，可以创建具有不同功能的多个系 统。在软件产品族之间共享体系结构和一组可重用的构件，可以降低开发和维护成本。 一个产品线代表着一组具有公共的系统需求集的软件系统，它们都是根据基本的用户需求对标 准的产品线构架进行定制，将可重用构件与系统独有的部分集成而得到的。采用软件生产线模式进 行软件开发，将产生巨型软件企业。但目前开发的软件产品族大部分是处于同一领域的。 软件产品线是一个十分适合专业的软件开发组织的软件开发方法，能有效地提高软件生产率和 质量、缩短开发时间、降低总开发成本。软件体系结构有利于形成完整的软件产品线。
9、建立评价软件体系结构的方法
软件体系结构的设计是整个软件开发过程中关键的一步。对于当今世界上庞大而复杂的系统来 说，没有一个合适的体系结构而要有一个成功的软件设计几乎是不可想象的。不同类型的系统需要 不同的体系结构，甚至一个系统的不同子系统也需要不同的体系结构。体系结构的选择往往会成为 一个系统设计成败的关键。
但是，怎样才能知道为软件系统所选用的体系结构是恰当的呢？如何确保按照所选用的体系结
构能顺利地开发出成功的软件产品呢？要回答这些问题并不容易，因为它受到很多因素的影响，需 要专门的方法来对其进行评估。目前，常用的软件体系结构评估方法主要有以下三个。
（1）体系结构权衡分析方法（Architecture Tradeoff Analysis Method，ATAM）。
（2）软件体系结构分析方法（Software Architecture Analysis Method，SAAM）。
（3）中间设计的积极评审（Active Reviews for Intermediate Design，ARID）。
