上　篇

基础理论篇

基础理论篇涵盖了第1～6章的内容，重点介绍软件架构的基本理论和方法，内容包括软件架构的发展历史、软件架构的概念和建模方法、软件架构风格和模式、软件架构描述语言，以及软件架构与敏捷开发之间的关系等。其中：

第1章　软件架构概述：简述了软件架构的意义以及软件架构发展历史。

第2章　软件架构的概念：概述了软件架构的主要定义派别以及它们之间的不同。

第3章　软件架构模型：介绍了软件架构建模的几种主流方法，如可视化建模、形式化建模等。

第4章　软件架构的风格与模式：详细讨论了多种主流的软件架构风格和模式，如管道–过滤器风格、黑板系统风格、正交架构风格等。

第5章　软件架构描述语言：概述了一些主流软件架构描述语言，如ACME、Wright等。

第6章　软件架构与敏捷开发：简单讨论了软件架构与敏捷开发的关系。

第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]。

软件架构的意义贯穿软件生命周期的各个阶段：需求分析阶段需要使用软件架构的理念对规约进行完善，继而支持由需求模型向架构模型的转化；通过验证的架构设计借助形式化或多角度具象描述，成为进一步细化设计的基础；在程序的开发和维护阶段，架构能够帮助开发和维护人员理解软件、尽早地发现和修复问题。因此良好的架构是软件得以顺利实现过程中至关重要的因素。