第1章　软件架构概述

最初，软件架构（Software Architecture，又称软件体系结构）是用来刻画软件系统整体抽象结构的一种手段，软件架构设计是软件开发过程中的一个重要环节，但随着研究的深入和应用的推广，软件架构逐渐成为软件工程学科的重要分支方向，在基础理论、技术方法和工程实践等方面形成了自己独特的理念和完整的体系。作为软件架构的背景知识，本章简要介绍软件架构产生的背景、主要思想、特征和发展轨迹。

1.1　软件架构产生的背景

众所周知，20世纪60年代中期开始爆发大规模的软件危机，软件危机的突出表现就是软件生产不仅效率低，而且质量差。究其原因，主要是因为软件开发的理论方法不够系统、技术手段相对滞后，主要的软件生产都是手工作坊式的。为了解决软件危机，北大西洋公约组织（NATO）分别于1968年和1969年连续召开两次著名的软件会议，后人称之为NATO会议。NATO会议提出了软件工程的概念，发展了软件工程的理论和方法，形成了软件工程专业的教育、培养和训练体系，为软件产业的发展指明了方向。
但是随着软件规模的进一步扩大和软件复杂性的不断提高，新一轮的软件危机再次出现。1995年，Standish Group研究机构以美国境内8000个软件工程项目作为调查样本进行调查，其结果显示，有84％的软件项目无法按时按需完成，超过30％的项目夭折，工程项目耗费平均超出预算189％。软件工程遇到了前所未有的困难[1]。
通过避免软件开发中重复劳动的方式提升软件开发效率、保障软件质量，软件重用与组件化成为解决此次危机的行之有效的方案。随着组件化软件开发方式的发展，如何在设计阶段对软件系统进行抽象，获取系统蓝图以支持系统开发中的决策成为迫切而现实的问题。分析问题的根源和产生的原因，以下现象应该获得关注：
1）软件复杂、易变，其行为特性难以预见，软件开发过程中需求和设计之间缺乏有效的转换，导致软件开发过程困难和不可控。
2）随着软件系统规模越来越大、越来越复杂，整个系统的结构和规格说明显得越来越重要。
3）对于大规模的复杂软件系统，相较于对计算算法和数据结构的选择，总体的系统结构设计和规格说明已经变得明显重要得多。
4）对软件系统结构的深入研究将会成为提高软件生产率和解决软件维护问题的最有希望的新途径。
在这种情况下，软件架构应运而生。
20世纪90年代，研究人员展开了关于软件架构的基础研究，主要集中于架构风格（模式）、架构描述语言、架构文档和形式化方法。众多研究机构在促进软件架构成为一门学科的过程中发挥了举足轻重的作用。例如，卡内基–梅隆大学的Mary Shaw和David Garlan的专著推广了软件架构的概念，即组件、连接件和风格的集合。加州大学欧文分校针对架构风格、架构描述语言和动态架构也开展了深入的研究。
软件架构在高层次上对软件进行描述，便于软件开发过程中各个视角（如用户、业务和系统）的统一，能够及早发现开发中的问题并支持各种解决方案的评估和预测[2]。
软件架构的意义贯穿软件生命周期的各个阶段：需求分析阶段需要使用软件架构的理念对规约进行完善，继而支持由需求模型向架构模型的转化；通过验证的架构设计借助形式化或多角度具象描述，成为进一步细化设计的基础；在程序的开发和维护阶段，架构能够帮助开发和维护人员理解软件、尽早地发现和修复问题。因此良好的架构是软件得以顺利实现过程中至关重要的因素。

1.2　软件架构的主要思想和特征

1.2.1　软件架构的主要思想

软件架构是一个软件系统的设计图，并不仅限于软件系统的总体结构，还包含一些质量属性以及功能与结构之间的映射关系，即设计决策[3]。软件架构的两个主要焦点是系统的总体结构以及需求和实现之间的对应。软件架构的主要思想是将注意力集中在系统总体结构的组织上，实现的手段是运用抽象方法来屏蔽错综复杂的模块间连接，使人们的认知提升并保持在整体结构的组件交互层次，并进一步将交互从计算中分离出来，建立“组件+连接件+配置”的软件系统高层结构组织方式。

1.2.2　软件架构的特征

（1）注重可重用性
重用是软件开发中避免重复劳动的解决方案，其出发点是应用系统的开发不再采用一切“从零开始”的模式，而是充分利用已有系统开发中积累的知识和经验[4]。通过重用不仅可以提高软件开发效率，而且因为可以避免重新开发引入新的错误，从而可提高当前软件的质量。软件架构中的组件就是重用思想的重要体现，此外有关软件架构风格的研究还提供了架构级别的重用。
（2）利益相关者较多
软件系统通常有多个利益相关者，每个利益相关者都会因为利益关系而对系统有一定的需求，软件系统需要满足每个利益相关者的需求[3]。架构设计工作就是要平衡这些需求并将它们反映到系统中。
（3）关注点分离
关注点分离是计算科学和软件工程在长期实践中确立的一项方法论原则[5]，此原则在业界更多的时候以“分而治之”（divide-and-conquer）的形式出现，即将整体看成为部分的组合体并对各部分分别加以处理[6]。模块化（modularization）是其中最有代表性的具体设计原则之一。软件架构的关注点就是指在软件架构设计中对利益相关者的利益来说比较关键或重要的方面。已有的架构方法采用分离关注点的办法来简化复杂性，以此来驱动设计，这种分离被称作“架构视角”。
（4）质量驱动
软件系统的设计已经从传统的功能性需求及数据流驱动逐渐向质量驱动转变，利益相关者的关注点往往体现在质量属性的需求上，如可靠性、可扩展性需求等[3]。质量属性需求是影响软件系统复杂度的关键因素，软件架构是处理质量属性需求和控制复杂性的主要手段，质量属性是软件架构中最为重要的关注点。
（5）提倡概念完整性
软件架构的设计决策是一个持续的过程，每个决策都要在其前面设计决策的基础上进行，既要符合前面设计决策所规定的设计规则和约束，又要解决本身的特定问题和关注点[3]。因此，每个设计决策的上下文环境、规则、约束都是不同的。但是有一个至高的设计规则是所有的设计决策都必须遵守的，即概念完整性。Frederick Brooks首先在软件系统设计中明确提出了概念完整性规则：“我认为概念完整性是系统设计中最重要的考虑因素。一个为了反映一组设计思想而省略不规则特性及改进的系统，要好过一个包含很多虽然好但独立、不协调的设计思想的系统。”[7]简单地说，概念完整性是要求用相似的方法做相似的事情。
（6）循环风格
与建筑架构类似，软件架构也提出了标准的方法来处理反复出现的问题。这些方法的命名被看作不同层次的抽象，常见的如架构风格、架构策略、参考结构、架构模式等[3]。

1.3　软件架构的发展阶段

软件架构自概念诞生之初便得到了广泛关注，至今已经历了一系列发展阶段。整体上来看，软件架构的发展可以分为如下几个阶段。

1.3.1　基础研究阶段（1968—1994）

术语“软件架构”在1968年的北大西洋公约组织会议上第一次出现，但并没有得到明确定义。直到20世纪80年代，“架构”一词在大部分情况下被用于表示计算机系统的物理结构，偶尔被用于表示计算机指令集的特定体系。从20世纪80年代起，为应对大型软件开发中存在的危机，对软件结构进行描述的方法开始在大型软件开发过程中广泛使用，并在实践中积累了大量经验，经研究者总结归纳，逐渐形成了以描述软件高层次结构为目的的理论体系，实质上形成了软件架构研究领域的雏形。在这一阶段，随着软件规模增大，开发者已经开始尝试模块化的实践，为后续软件架构理论的发展奠定了基础。
具体来说，模块化指的是一种软件开发方法，即把一个待开发的软件分解成若干小的简单的部分，称为模块。每一个模块都独立地开发、测试，最后再组装出整个软件。这种开发方法是对待复杂事物的“分而治之”的一般原则在软件开发领域的具体体现。
在软件中，模块是执行一个特殊任务或实现一个特殊的抽象数据类型的一组例程和数据结构，通常由接口和实现两部分组成。接口使得模块内部的具体实现被隐藏，使得能够面向接口开发而不是面向具体应用开发，体现了良好的封装性，易于独立的开发、修改和测试。
模块化开发方法涉及的主要问题是模块设计的规则，即系统如何分解成模块。在把系统分解成模块时，应该遵循以下规则：①最高模块内聚。也就是在一个模块内部的元素最大限度地关联。只实现一种功能的模块是最高内聚的，具有三种以上功能的模块则是低内聚的。②最低耦合。也就是不同模块之间的关系尽可能弱，以利于软件的升级和扩展。
③模块大小适度。粒度过大会造成模块内部维护困难，而粒度过小又会导致模块间的耦合增加。④模块调用链的深度（嵌套层次）不可过多。⑤接口干净，信息隐蔽。⑥尽可能地复用已有模块。
一般来说，模块的粒度小于服务组件的粒度。服务组件可以在应用之间复用。由于服务的调用通常是基于分布式协议（比如SOAP、HTTP、RMI/IIOP）的，且通常是远程调用，因此出于分布式请求性能的考虑一般粒度比较大。而当只想复用服务中特定的行为时，复制代码或者暴露新的服务接口都不是很好的选择，这时基于模块则可以得到一种更为优雅的解决方案。由于模块比服务粒度更小，而且又是一种部署单元，因此可以将这种特定的行为实现为模块，这样不仅支持复用，同时为组装应用带来了更大的灵活性。
随着全球化的发展趋势和全球化市场竞争压力的增加，一方面企业需要提高业务灵活性和创新能力；另一方面随着IT环境复杂度和历史遗留系统的增加，企业面临新的挑战。模块化的思想恰恰能够帮助企业从根本上解决这一问题，它一方面通过抽象、封装、分解、层次化等基本的科学方法，对各种软件组件和软件应用进行打包，提高对企业现有资产的重用水平和能力；另一方面，基于模块化思想，业界提出了面向服务架构（Service-Oriented Architecture，SOA）思想，它提供一组基于标准的方法和技术，通过有效整合和重用现有应用系统和各种资源实现服务组件化，并基于服务组件实现各种新业务应用的快速组装，帮助企业更好地应对业务的灵活性要求。它通过有效平衡业务的灵活性和IT的复杂度，为开发者提供了新的视角，有效拉近了IT和业务的距离。

1.3.2　概念体系和核心技术形成阶段（1991—2000）

基于工程实践经验，研究者对软件开发中所采用的结构描述方法进行了反思，软件架构概念作为一个独立的研究领域出现是在20世纪90年代，Winston W. Royce 与 Walker Royce 在1991年的一篇文章中首次对软件架构进行了定义[8]。1992年D.E.Perry与A.L.Wolf对软件架构进行了阐述，创造性地提出了著名的“{elements, forms, rationale} = software architecture”公式[9]，使之成为后续软件架构概念发展的基础。与此同时，大量关于软件架构的研究陆续展开并卓有成效，其中最著名的是卡内基–梅隆大学软件工程研究所（CMU/SEI）进行的研究。1996年CMU/SEI的Mary Shaw和David Garlan出版了《Software Architecture: Perspectives on an Emerging Discipline》[10]，其对软件架构概念的内涵与外延进行了详尽阐述，这对软件架构概念的形成起到了至关重要的作用。
从1995年起，软件架构研究领域开始进入快速发展阶段，来自于工业界与学术界的研究成果大量出现。在这一阶段中，研究关注点主要集中于对前一阶段研究成果进行整合与完善，使得软件架构作为一个技术领域日渐成熟。在此阶段中，对软件架构概念的探讨越加深入，Booch、Rumbaugh和Jacobson从另一个角度对软件架构的概念进行了全新的诠
释[11]，认为架构是一系列重要决策的集合。此阶段还提出了第一个由软件工程研究机构提出的软件架构实践方法体系—SAAM[12]；企业界也提出并完善了多视角软件架构表示方法以及针对软件架构的特定设计模式[13–14]。Siemens、Nokia、Philips、Nortel、Lockheed Martin、IBM，以及其他一些大型软件开发组织开始关注软件架构，并联手进行了软件产品线架构的重用性调查。Rechtin 与 Mark Maier在1998年出版的《The Art of Systems Architecting》一书中很好地阐述了系统与软件的关系[15]。
2000年，IEEE 1471—2000的“软件密集型系统架构描述的推荐实践”发布[16]，第一次定义了软件架构的形式化标准。这标志着软件架构理论体系已基本建立，并已具备普及应用的基础。
这一阶段最重要的成果之一就是软件组件化技术，通过沿用20世纪的工业组件概念，提升了软件重用能力和质量。
软件技术发展在几十年里经历了面向机器、面向过程、面向对象、面向组件的发展历程，每个阶段较于前一个阶段在关注点和思维层次上都有一定的升华，并解决了某类问题，对当时的软件发展起到了重要作用。
首先，业务组件之间相对独立，并且具有可组装性和可插拔性。每个组件的运行仅依赖于平台或者容器，组件与组件之间不存在直接的耦合关系。同时，组件与组件之间又并非绝对的独立。组件经过组装后可以与其他组件进行业务上的交互。
组件化开发并不等同于模块化开发。模块化开发只是在逻辑上做了切分，物理上（开发出的系统代码）通常并没有真正意义上的隔离。组件化也不等同于应用集成，应用集成是将一些基于不同平台或不同方案的应用软件和系统有机地集成到一个无缝的、并列的、易于访问的单一系统中，以建立一个统一的综合应用。组件化应比模块化更独立，但比应用集成结合得更加紧密。

1.3.3　理论体系完善与发展阶段（1996年至今）

随着基于组件软件架构理论的建立，与之相关的一些研究方向逐渐成为软件工程领域的研究热点，主要包括：软件架构的描述与表示；软件架构分析、设计与测试；软件架构发现、演化与重用；基于软件架构的开发方法；软件架构风格等。
1998年，P. Bengtsson和J. Bosch在ICSR（International Conference on Software Reuse）上发表了《Scenario-based Software Architecture Reengineering》[17]，展开软件架构的“再工程”。P. Oreizy、N. Medvidovic和R. N. Taylor在ICSE会议上发表了《Architecture-based Runtime Software Evolution》[18]，开创了动态软件架构的研究。

1.3.4　普及应用阶段（1999年至今）

在软件架构发展历程中1999年是一个关键年份，这一年召开了第一届IFIP软件架构会议[19]，并成立了IFIP工作组2.10与全球软件架构师协会，许多企业开始将软件架构相关理论投入实践，为了使架构描述能够在实践中得到更广泛的应用，Open Group 提出了ADML[20]，它是一种基于XML的架构描述语言，支持广泛的架构模型共享。由于企业对重用以及产品族的形成有着更多考虑，因此软件产品线成为软件架构的一个重要分支，吸引了大量大型企业的关注。2000年，IEEE 1471—2000的发布[16]为软件架构的普及应用制定了标准化规范，为软件架构的后续发展奠定了基础，该标准随后分别于2007年与2011年得到扩充与修改。2003年，L. Bass、P. Clements和 R. Kazman出版了《Software Architecture in Practice》一书[21]，引起巨大反响，书中总结了软件架构研究领域的最新成果，并介绍了如何在实践中应用这些理论成果。
纵观软件架构的发展历程，其完成了由实践上升到理论，再由理论反馈指导实践的过程，理论与实践均处于健康发展中，已经形成良性的发展循环。

1.4　软件架构研究和应用现状

当前，软件架构尚处于迅速发展之中，至今尚无统一的定义，但软件架构作为软件工程领域中的一个组成部分，已经取得了长足的发展，成为软件工程领域的研究热点，作为一门学科受到越来越多软件系统设计和研究人员的重视。目前软件架构的相关研究主要集中在以下两个方面。

1.4.1　软件架构理论和方法研究

（1）软件架构描述与构造表示
ADL是一种规范化架构描述，提供了具体的语法与刻画架构的概念框架，是支持架构描述和推理的形式化语言。目前已经提出了许多软件架构描述语言。国外比较典型的有基于组件和消息的软件架构描述语言C2 SADL[22]，分布、并发类型的架构描述语言Wright[23]，架构互换语言ACME[24]，基于组件和连接的架构描述语言UniCon[25]，基于事件的架构描述语言Rapide[26]，以及其他比较有影响力的Darwin、MetaH、Aesop、Weaves、SADL、xADL等架构描述语言[36]。国内提出的ADL有基于框架和角色模型的软件架构规约FRADL[27]、多智能体系统架构描述语言A-ADL[28]、基于主动连接件的架构描述语言Tracer[29]、基于XML的软件架构描述语言ABC/ADL[30]、功耗-体系结构描述语言XP-ADL[31]、基于层次消息总线的软件架构描述语言JB/SADL[32]、基于时序逻辑的可视化架构描述语言XYZ/ADL[33–34]、基于高阶多型π演算的动态架构语言D-ADL[35]等。
架构表示是指按照一定的描述方法，用架构描述语言对架构进行说明的结果，并将描述架构的过程称为架构构造。目前常见的架构描述方法包括形式化的架构描述方法、Kruchten的“4+1”架构模型、使用UML的架构描述方法以及IEEE的软件架构描述规范等[36]。
形式化方法是指在严格的数学基础（逻辑、代数、自动机、图论等）之上的方法。该方法按所采用的技术可以分为五类：基于模型的方法、代数方法、过程代数方法、基于逻辑的方法以及基于网格的方法。目前被广泛使用的形式化方法Z规约语言，是一种以状态机为模型的形式规约语言，可以把架构描述的基本语法元素（组件、连接件以及对应的配置）形式化。
Kruchten的“4+1”架构模型从5个不同的视角（包括逻辑视角、过程视角、物理视角、开发视角和场景视角）来描述软件架构。每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统软件架构的全部内容，比较细致地描述了需求和架构之间的关系[37]。类似的还有Siemens的四视角模型，其由Siemens公司研究所开发，从概念、执行、模块和代码架构四个视角分离不同的工程关注点，从而降低架构设计任务的复杂性[38]。
统一建模语言（Unified Modeling Language，UML）是一种通过可视化方法对系统进行描述、实施和说明的标准语言。UML不属于ADL，它更关心使用性，更多地适用于应用软件系统设计，对系统的可构建性建模能力较弱，不具备ADL可构造的组件–连接器框架特征。Medvovonic总结了用UML描述架构的3种途径：不改变UML用法而直接对架构建模；利用UML支持的扩充机制扩展UML的元模型以实现对架构建模概念的支持；对UML进行扩充，增加架构建模元素[36]。
IEEE于1995年成立了架构工作组（AWG），起草了架构描述框架标准[39]，即IEEE 1471—2000，该标准建立了架构描述的框架，定义了架构描述的内容，并提供了关键概念和术语的基本原理、与其他标准之间的关系和用法的例子，用于处理软件密集系统架构的创建、分析和支持，以及用架构描述术语记录这些架构。
此外，Rational起草了可重用的软件资产规格说明，并专门讨论了架构描述的规格说明，提出了一套易于重用的架构描述规范[40]。该规范是基于RUP（Rational United Process）开发的，采用UML模型来描述软件架构；认为架构描述的关键是定义视点、视图以及各种建模元素之间的映射关系。
（2）软件架构分析、设计与测试
架构分析的内容可分为结构分析、功能分析和非功能分析。软件架构分析的目的是在系统被实际构造之前预测其质量属性。目前存在的方法有基于场景的架构分析方法SAAM[41]及其3个扩展，其中一个是基于复杂场景的SAAMCS[42]，另两个是对可重用性扩展的ESAAMI[43]和SAAMER[44]；架构折中分析方法ATAM[45]；基于场景的架构再工程SBAR[46]；架构层次的软件可维护性预测ALPSM[47]；软件架构评估模型SAEM[48]等。
软件架构设计指生成一个满足用户需求的软件架构的过程[49]。主要的设计方法有从工件描述中提取架构描述的工件驱动（artifact-driven）方法、从用例导出架构抽象的用例驱动（use-case-driven）方法、从模式导出架构抽象的模式驱动（pattern-driven）方法、从领域模型导出架构抽象的域驱动（domain-driven）方法，以及从设计过程中获得架构质量属性需求的属性驱动设计（attribute-driven design）方法等。
软件架构测试着重于仿真系统模型、解决架构层的主要问题。由于测试的抽象层次不同、架构测试策略可以分为单元、子系统、集成、验收测试等阶段的测试策略。在架构集成测试阶段提出了多种技术，其中包括Debra等人提出的一组针对架构的测试覆盖准则，如组件覆盖准则等[50]；基于霍尔公理的组件设计正确性验证技术[51]；基于CHAM（CHemical Abstract Machine）的架构动态语义验证技术等[52]。
（3）软件架构发现、演化与复用
软件架构发现解决如何从已经存在的系统中提取软件架构的问题，属于逆向工程。Waters等人提出了一种迭代式架构发现过程，即由不同的人员对系统进行描述，然后对这些描述进行分类并融合，发现并解除冲突，将架构新属性加入已有的架构模型中，并重复该过程直至架构描述充分[53]。
软件架构的演化即由于系统需求、技术、环境、分布等因素的变化而最终导致软件架构的变动。软件系统在运行时刻的架构变化称为架构动态性，而将架构的静态修改称为架构扩展。架构扩展与架构动态性都是架构适应性和演化性的研究范畴。Darwin和C2直接支持结构动态性，CHAM、Wright、Rapide支持语义动态性。在C2中定义有专门支持架构修改的描述语言AML，而Darwin对架构的修改则采用相应的脚本语言，CHAM通过多值演算实现系统架构的变换，Wright通过顺序通信进程CSP描述组件的交互语义[36]。
软件架构复用属于设计重用，比代码重用更抽象。架构模式就是架构复用的一个研究成果。
（4）基于软件架构的开发模型
软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架，给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为三种类型:①以软件需求完全确定为前提的瀑布模型。②在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型等。③以形式化开发方法为基础的变换模型。为了更好地支持软件开发，Bass等人提出了基于架构的软件开发过程[21]。
（5）软件架构风格与模式
人们在软件开发实践中总结出了许多软件架构风格。架构风格（架构模式）是针对给定场景中经常出现的问题提供的一般性可重用方案，它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。
David Garlan和Mary Shaw等人总结出若干被广泛接受的架构风格，并将其分成五种主要的类型[54]：
1）数据流风格：批处理序列；管道–过滤器。
2）调用/返回风格：主程序/子程序；面向对象；层次化结构。
3）独立组件风格：进程通信；事件系统。
4）虚拟机风格：解释器；基于规则的系统。
5）仓库风格：数据库系统；超文本系统；黑板系统。
之后仍有扩充，如出现了C2风格、GenVoca风格、REST风格等。此外，针对不同的系统类型又提出若干种架构风格，如分布式系统、交互式系统和适应性系统的架构风格等[55]。
（6）软件产品线架构
软件产品线表示着一组具有公共的系统需求集的软件系统，它们都是根据基本的用户需求对标准的产品线架构进行定制，将可重用组件与系统独有的部分集成而得到的[48]。在这种开发生产中，基于同一个软件架构，可以创建具有不同功能的多个系统。在软件产品族之间共享架构和一组可重用的组件，可以降低开发和维护成本。由美国国防部支持的两个典型项目—关于基于特定领域软件架构的软件开发方法的研究项目（DSSA）与关于过程驱动、特定领域和基于重用的软件开发方法的研究项目（STARS），分别从软件架构和软件重用两个方面推动了软件产品线的研究和发展。
软件产品线架构的发展是依托着特定领域软件架构（Domain Specific Software Architecture，DSSA）的研究深入而进行的[43]。尽管业界对 DSSA尚无统一的定义，但各种观点中DSSA都必须具备以下4个特征：①一个严格定义的问题域/解域；②具有普遍性，使其可以用于领域中某个特定应用的开发；③对整个领域的适度抽象；④具备该领域固定的、典型的在开发过程中可复用的元素。目前已有一些较好的DSSA应用，如IBM/Aerospace/ MIT/UCI开发的适用于航空电子领域的软件架构，北京大学杨芙清院士牵头实现的支持组件复用的青鸟Ⅲ型系统等[49]。
（7）软件架构支持工具
在软件架构支持工具中，支持架构分析的工具包含支持静态分析的工具、支持类型检查的工具、支持架构层次依赖分析的工具、支持架构动态特性仿真的工具、支持架构性能仿真的工具等；然而支持架构设计的工具还很不成熟，相关研究成果较少，难以进行实用化比较。著名的软件架构支持工具包括卡内基–梅隆大学研发的Acme，其以Acme架构语言为基础，提供了Acme工具开发人员库（Acmelib），用于表示和操作Acme的设计，并提供了一个具有图形化用户界面的软件架构开发环境AcmeStudio；支持C2架构风格的ArchStudio3、UniCon、Aesop等架构支持环境；支持主动连接件的Tracer工具等[49]。

1.4.2　软件架构的应用研究

（1）软件架构风格的应用
软件架构风格是在实践中被多次应用，综合若干设计思想得出的，具有已经被熟知的特性，并且可以实现有效复用，在实际设计和开发中具有指导性作用。不同的架构风格具有各自的优缺点和应用场景。例如管道-过滤器风格适用于将系统分成几个独立的处理步骤；主程序/子程序和面向对象的架构风格可用来对组件内部进行设计；虚拟机风格经常用于构造解释器或专家系统；C/S和B/S风格适合于数据和处理分布在一定范围、通过网络连接构成的系统；平台/插件风格适用于具有插件扩展功能的应用程序；MVC风格被广泛地应用于用户交互程序的设计；SOA风格应用在企业集成等方面；JB/HMB风格的典型应用是青鸟软件生产线；C2风格适用于GUI软件开发，用以构建灵活和可扩展的应用系统，等等。
现代大型软件很少采用单一架构风格进行设计和开发，而是混合多种风格。了解“纯”的架构风格有助于在设计时选择更为合理的架构并对各种架构进行有效组合，同时，理解背离此种风格所带来的结果和影响对保障软件的可靠性、可扩展性、可维护性等也有所帮助。
（2）软件架构在开发过程中的应用
软件架构是软件生命周期中的重要产物，它影响软件开发的各个阶段[36,56]。
需求阶段：把SA的概念引入需求分析阶段，有助于保证需求规约和系统设计之间的可追踪性和一致性。该阶段主要是根据需求来决定系统的功能，在此阶段，设计者应对目标对象和环境进行细致深入的调查，收集目标对象的基本信息，从中找出有用信息，这是一个抽象思维、逻辑推理的过程，结果是软件规格说明。
从需求模型向软件架构模型的转换：该阶段主要关注两个问题，一是如何根据需求模型构建SA模型，二是如何保证模型转换的可追踪性。这两个问题的解决方案因所采用的需求模型的不同而各异。在需求阶段研究SA，有助于将SA的概念贯穿整个软件生命周期，从而保证软件开发过程的概念完整性，有利于各阶段参与者的交流，也易于维护各阶段的可追踪性。
设计阶段：设计阶段是SA研究关注得最早和最多的阶段，这一阶段的SA研究主要包括SA模型的描述、SA模型的设计与分析方法，以及对SA设计经验的总结与复用等。该阶段需要细化至对系统进行模块化并选定描述各个部件间的详细接口、算法和数据类型，对上支持建立架构阶段形成的框架，对下提供实现基础。
实现阶段：将设计阶段设计的算法及数据类型用程序设计语言进行表示，满足设计、架构和需求分析要求，从而得到满足设计需求的目标系统。软件架构在系统开发的全过程中起着基础作用，是设计的起点和依据，同时也是装配和维护的指南。
维护阶段：为了保证软件具有良好的维护性，在软件架构中针对维护性目标进行分析时，需要对一些有关维护性的属性（如可扩展性、可替换性等）进行规定，当架构经过一定的开发过程实现和形成软件系统时，这些属性也相应地反映了软件的维护性。
（3）常见软件产品的架构
1）人人网采用JavaEE技术作为主要的业务解决方案，基本按照通用的JavaEE模型进行架构设计：①Web层基于REST风格和MVC风格，为用户提供基于Web的访问接口，人人网采用的是自己开发的Web框架Rose，该框架基于Spring Framework，类似RoR框架，增强了对Controller编码部分的默认约定和REST风格URL的支持；②业务层封装业务逻辑，为Web层提供业务接口，操作由数据访问层提供的数据。人人网开发了自己的SOA框架XOA以支持业务层抽象，该框架结合Rose框架，以REST风格对业务进行分类、消息格式封装和路由。XOA支持远程调用，并可以通过简单添加服务器的方式进行横向扩展。③数据访问层提供对数据库访问的封装。人人网使用Java语言开发了自己的Object-Relation Mapping 框架JADE（Java Database Engine），并支持数据库的水平横向切分。④数据持久层实现数据的持久存储，人人网主要采用MySQL数据库，并且开发了自己的海量存储系统Nuclear。
2）金蝶EAS（Enterprise Application Suite）是金蝶国际软件集团推出的新一代企业应用套件。金蝶EAS构建于金蝶自主研发的业务操作系统—金蝶BOS（Business Operating System）之上，提供了集成的集团财务管理、集团人力资源管理、集团采购管理、集团分销管理、供应链管理、协同平台等50多个应用模块，并为企业提供行业及个性化解决方案、移动商务解决方案，实现企业间的业务协作和电子商务的应用集成。基于金蝶BOS构建的金蝶EAS系统在架构模型上遵循SOA架构体系，由四部分构成：①信息门户。将企业不同角色的相关人员通过Internet紧密地结合在一起协同工作，并能有效整合第三方系统。
②业务流程。涉及可灵活配置的流程引擎。其中业务流程和工作流都是可视的，企业可以随时查阅每一项业务的流程规则、路线、处理状态及参与者，用户的操作也变得更加简单和直观。③业务服务。提供统一的接口标准，使所有业务都作为功能插件连接在业务流程上，这些服务可以根据用户的需要来决定是否使用甚至更换。④基础平台。将包含各种底层存储、计算和传输的技术细节通过封装进行屏蔽，有效降低系统集成、应用部署的复杂度。
3）Lucene作为一个优秀的全文检索引擎，其系统架构具有强烈的面向对象特征。首先其定义了一个与平台无关的索引文件格式，其次通过抽象将系统的核心组成部分设计为抽象类，具体的平台实现部分设计为抽象类的实现，此外与具体平台相关的部分比如文件存储也封装为类，经过层层的面向对象式的处理，最终实现一个低耦合高效率、容易二次开发的检索引擎系统。Lucene的一大优势在于其开源。这样我们对于Lucene的架构分析可以直接从它的包以及云代码入手。
4）OpenStack实际上是由众多服务组合而成的，服务之间的关联或多或少，而且具有一定的层次关系，每个服务就像积木块一样，可以根据实际需要进行取舍并组合搭建，因此良好的运营架构整合能力是应用OpenStack的前提。实际上，OpenStack既是一个社区，也是一个项目和一个开源软件，它提供了一个部署云的操作平台或工具集。其宗旨在于帮助组织为虚拟计算或存储服务的云，为公有云、私有云，也为大云、小云提供可扩展的、灵活的云计算。
5）12306网站或系统采用的是两地三中心混合云架构。12306的后端架构由阿里巴巴的技术团队提供支持，从阿里自己的业务上来看，这套架构可以承载“双十一”和“双十二”这样的大型抢购活动。这种软件架构需要很好地支撑并发业务，支持高可靠、高性能业务的需求。该系统的架构设计应该能够面对系统数据、用户数增长10倍以上的情况，并且能够提供一个稳定的响应时间，不能出现剧烈的波动等。
6）大数据时代，移动互联、社交网络、数据分析、云服务等应用的迅速普及，对数据中心提出革命性需求，存储基础架构已经成为IT核心之一。数据的价值日益突显，数据已经成为不可或缺的资产。作为数据的载体和驱动力量，存储系统成为大数据基础架构中最为关键的核心。数据驱动的软件架构（Data-Driven Software Architecture，DDSA）目前在各行各业得到研究开发和推广应用。

1.5　本章小结

作为本书的第1章，本章简要介绍了软件架构产生的背景，以及软件架构的核心思想、典型特征和发展轨迹。

思考题

1.1　结合生活中遇到的各种架构（如桥梁架构、房屋架构等），阐述软件架构的理论意义和工程意义。
1.2　根据你的经验判断：软件架构的现有理论研究成果与工程实践还存在哪些差距？
1.3　你熟悉的软件架构都是什么样子的？用简洁的语言描述其存在的问题。

参考文献

[ 1 ]　维基百科[EB/OL].http://zh.wikipedia.org/wiki/.
[ 2 ]　Chapter 1: What is Software Architecture? [EB/OL].http://msdn.microsoft.com/en-us/lib ary/ee658098.aspx, 2009.
[ 3 ]　Software architecture[EB/OL].http://en.wikipedia.org/wiki/Software_architecture.
[ 4 ]　梅宏, 李克勤.软件复用与软件构件技术[J].电子学报, 1999, 27(2): 51-68.
[ 5 ]　D L Parnas. On the criteria to be used in decomposing systems into modules[J]. Communications of the ACM, 1972, 15(12): 1053-1058.
[ 6 ]　E W Dijkstra.On the cruelty of really teaching computing science[J].Communications of the ACM, 1989, 32(12): 1398-1404.
[ 7 ]　F P Brooks. The mythical man-month[M]. Addison-Wesley, 1975.
[ 8 ]　W Royce, W Royce.Software architecture: Integrating process and technology[J].TRW Quest, 1991, 14(1): 2-15.
[ 9 ]　D E Perry, A L Wolf.Foundations for the study of software architecture[J].ACM SIGSOFT Software Engineering Notes, 1992, 17(4): 40-52.
[10]　M Shaw, D Garlan.Software Architecture: Perspectives on an Emerging Discipline[J].Prentice-Hall, 1996, 24(1):129-132(4).
[11]　G Booch, J Rumbaugh, I Jacobson.The unified modeling language user guide[M].Pearson Education India, 1999.
[12]　R Kazman, L Bass, G Abowd, et al.SAAM: A method for analyzing the properties of software architectures[C]. Proceedings of 16th International Conference on Software Engineering. IEEE, 1994: 81-90.
[13]　P Kruchten.The 4+1 view model of architecture[J].Software, IEEE, 1995, 12(6): 42-50.
[14]　D Soni, R Nord, C Hofmeister.Software architecture in industrial applications[C].Proceedings of the 17th International Conference on Software Engineering.IEEE, 1995: 196-196.
[15]　M Maier, E Rechtin. The art of systems architecting[M]. CRC Press, 2000.
[16]　R Hilliard.IEEE-std-1471—2000 recommended practice for architectural description of software-intensive systems[S/OL]. http://standards.ieee.org.
[17]　P O Bengtsson, J Bosch.Scenario-based software architecture reengineering[C].Proceedings of the 5th International Conference on Software Reuse. IEEE, 1998: 308-317.
[18]　P Oreizy, N Medvidovic , R N Taylor.Architecture-based runtime software evolution[C].Proceedings of the 20th International Conference on Software Engineering.IEEE Computer Society, 1998: 177-186.
[19]　Software Architecture—1st IFIP Conf. Software Architecture (WICSA 1) [C].Kluwer Academic Publishers, 1999.
[20]　J Spencer.Architecture Description Markup Language (ADML): creating an open market for IT Architecture tools[R]. Open Group White Paper, 2000.
[21]　L. Bass, P. Clements, R. Kazman Software architecture in practice[M]. Addison Wesley, 2003.
[22]　N Medvidovic, D Rosenblum, R Taylor.A language and environment for architecture-based software development and evolution[C].Proceedings of the 1999 International Conference on Software Engineering, 1999: 44-53.
[23]　R Allen, D Garlan.A formal basis for architectural connection[J].ACM Transactions on Software Engineering and Methodology (TOSEM), 1997, 6(3): 213-249.
[24]　D Garlan, R T Monroe, D Wile.Acme: Architectural description of component-based systems[J].Foundations of component-based systems, 2000（68）: 47-68.
[25]　M Shaw, R DeLine, D V Klein, et al.Abstractions for software architecture and tools to support them[J].IEEE Transactions on Software Engineering, 1995, 21(4): 314-335.
[26]　D C Luckham, J J Kenney, L M Augustin, et al.Specification and analysis of system architecture using Rapide[J].IEEE Transactions on Software Engineering, 1995, 21(4): 336-354.
[27]　马铁, 张皋晨, 陈伟, 等.基于框架和角色模型的软件体系结构规约[J].软件学报, 2000 (8): 1078-1086.
[28]　马俊涛, 傅韶勇, 刘积仁.A-ADL: 一种多智能体系统体系结构描述语言[J].软件学报, 2000, 11(10): 1382-1389.
[29]　张家晨,冯铁,陈伟,等.基于主动连接的软件体系结构及其描述方法[J].软件学报, 2000, 11(8): 1047-1052.
[30]　H Mei, F Chen, Q Wang, et al.ABC/ADL: An ADL supporting component composition [M]//Formal Methods and Software Engineering.Springer Berlin Heidelberg, 2002: 38-47.
[31]　熊悦, 李曦, 周学海, 等.功耗–体系结构描述语言XP-ADL及其设计环境[J].小型微型计算机系统, 2003, 24(8): 1470-1473.
[32]　张世琨, 王立福, 常欣, 等.基于层次消息总线的软件体系结构描述语言[J].电子学报, 2001, 29(5): 581-584.
[33]　X Y Zhu, Z S Tang.A temporal logic-based software architecture description language XYZ/ADL[J].Journal of Software, 2003, 14(4): 713-720.
[34]　骆华俊, 唐稚松, 郑建丹.可视化体系结构描述语言 XYZ/ADL[J].软件学报, 2000, 11(8): 1024-1029.
[35]　李长云, 李赣生, 何频捷.一种形式化的动态体系结构描述语言[J].软件学报, 2006, 17(6): 1349-1359.
[36]　孙昌爱, 金茂忠, 刘超.软件体系结构研究综述[J].软件学报, 2002, 13(7): 1228-1237.
[37]　P B Kruchten.The 4+1 view model of architecture[J].IEEE Software, 1995, 12(6): 42-50.
[38]　C Hofmeister, P Kruchten, R L Nord, et al.A general model of software architecture design derived from five industrial approaches[J].Journal of Systems and Software, 2007, 80(1): 106-126.
[39]　IEEE ARG.IEEE 1471—2000 Recommended Practice for Architectural Description[S].2000.
[40]　IBM Knowledge Center [EB/OL].https://www.ibm.com/support/knowledgecenter/.
[41]　R Kazman, L Bass, M Webb, et al.SAAM: A method for analyzing the properties of software architectures[C].Proceedings of the 16th international conference on Software engineering. IEEE Computer Society Press, 1994: 81-90.
[42]　N Lassing, D Rijsenbrij, H van Vliet.On software architecture analysis of flexibility, Complexity of changes: Size isn't everything[C].Proceedings of the Second Nordic Software Architecture Workshop NOSA.1999: 1103-1581.
[43]　G Molter.Integrating SAAM in domain-centric and reuse-based development processes[C].Proceedings of the 2nd Nordic Workshop on Software Architecture, Ronneby.1999: 1-10.
[44]　C H Lung, S Bot, K Kalaichelvan, et al.An approach to software architecture analysis for evolution and reusability[C].Proceedings of the 1997 conference of the Centre for Advanced Studies on Collaborative research.IBM Press, 1997: 15.
[45]　R Kazman, M Klein, M Barbacci, et al.The architecture tradeoff analysis method[C].Proceedings of the 4th IEEE International Conference on Engineering of Complex Computer Systems, 1998( ICECCS'98).IEEE, 1998: 68-78.
[46]　P O Bengtsson, J Bosch.Scenario-based software architecture reengineering[C].Proceedings of the 5th International Conference on Software Reuse.IEEE, 1998: 308-317.
[47]　P Bengtsson, J Bosch.Architecture level prediction of software maintenance[C].Proceedings of the 3rd European Conference on Software Maintenance and Reengineering, IEEE, 1999: 139-147.
[48]　J C Due?as, W L de Oliveira, A Juan.A software architecture evaluation model[M]//Development and Evolution of Software Architectures for Product Families.Springer Berlin Heidelberg, 1998: 148-157.
[49]　王映辉.软件构件与体系结构: 原理, 方法与技术[M].北京：机械工业出版社, 2009.
[50]　D J Richardson, A L Wolf.Software testing at the architectural level[C].Proceedings of the second international software architecture workshop (ISAW-2) and international workshop on multiple perspectives in software development (Viewpoints' 96) on SIGSOFT'96 workshops. ACM, 1996: 68-71.
[51]　云晓春, 方滨兴.基于构件设计的正确性验证[J].小型微型计算机系统, 1999, 20(5): 330-334.
[52]　P Inverardi, A Wolf, D Yankelevich.Behavioral type checking of architectural components based on assumptions[R].Technical Report CU-CS-861-98, University of Colorado, Department of Computer Science, 1998.
[53]　R Waters, G D Abowd.Architectural synthesis: Integrating multiple architectural perspectives[C].Proceedings of the 6th Working Conference on Reverse Engineering.IEEE, 1999: 2-12.
[54]　M Shaw, D Garlan.Software Architecture[M].Tsinghua University Press/Prentice Hall, 1997.
[55]　梅宏, 申峻嵘.软件体系结构研究进展[J].软件学报, 2006, 17(6): 1257-1275.
[56]　任雪莲.软件体系结构在软件开发过程中的实践研究[J].才智, 2009(1): 131.

带你读《软件架构理论与实践》之一：软件架构概述

第1章　软件架构概述

1.1　软件架构产生的背景