1.1 什么是架构

计算机科学和程序设计的飞速发展，使得软件设计应用在从航空航天到日常生活的方方面面。个人开发一段小程序的做法早就过时，大范围协作的工程化时代随即到来。随着大范围协作带来的效率问题和软件复杂度的爆炸式增长，管理和技术方面的各种不确定性也爆发性增加，导致软件开发的质量无法得到有效保证，开发周期和成本无法得到有效控制。人们一直在寻求这些问题的解决方法。然而Fred Brooks在1975年出版的软件工程圣经《人月神话》中写道，没有（能解决所有问题的）银弹（There is no silver bullet）。自此，人们发展了项目研发过程管理来控制管理活动的不确定性，同时发展了软件架构设计方法来控制技术方面的不确定性，进而在实践中不断地总结和改进，用于有效指导软件的开发过程，最大程度地保障软件的质量、开发周期和成本。

自软件工程产生以来，架构设计和过程管理一直是软件领域DNA的双螺旋。前者从科学技术领域出发来解决软件创造中的工程技术问题，后者从人类的管理活动出发发展了软件工程的组织管理方式。两者都是为了解决大规模软件开发过程中的各种问题而出现的。

架构的定义

架构（Architecture）一词源于建筑领域，其本身就是建筑的意思，也有体系结构的意思。维基百科英文版里对Architecture的解释是：规划、设计和建造建筑物的过程及产物。鉴于软件工程与建筑工程一样是一项系统的工程性工作，在引入计算机领域后，软件架构就成为描述软件规划设计技术的专有名词。特别地，软件架构师一词在英文里和建筑师也是同一个词（Architect）。

1972年图灵奖获得者、荷兰计算机科学家Edsger Wybe Dijkstra（就是大名鼎鼎的Dijkstra最短路径算法的发明者）早在二十世纪六十年代就已经涉及软件架构这个概念了。到了二十世纪九十年代，Rational Software Corporation和Microsoft、卡内基梅隆大学和加州大学埃尔文分校在这个领域做了很多研究和实践，提出了软件架构中的很多概念。

维基百科里对软件架构的定义：

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构师定义和设计软件的模块化、模块之间的交互、用户界面风格、对外接口方法、创新的设计特性，以及高层事物的对象操作、逻辑和流程。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或对象。在面向对象领域中，组件之间的连接通常用接口来实现。

Kruchten认为：

架构是对软件系统组织、结构部分和系统包含接口的选择，满足功能和性能需求的一系列架构元素的集合。软件架构设计与软件高层次结构的实现能够抽象、分解、组合等。

Bass等人认为：

系统或计算系统的软件架构是包含软件部分、外部可见特性部分，以及它们之间关系的系统结构。

McGovern则认为：

软件架构或系统由组成系统的结构的相互作用和软件结构的重要设计决定组成。设计决定应成功实现所期望支持的质量。设计决定为系统开发、支持和维护提供概念上的基础。

比较公认的软件架构定义是在2000年的ANSI/IEEE 1471标准《软件增强系统的体系结构描述推荐实施规程（Recommended Practice for Architectural Description for Software-Intensive Systems Description）》、2011年的ISO/IEC/IEEE 42010标准《系统和软件工程——架构描述（Systems and software engineering — Architecture description）》中定义的。

（1）架构过程：在系统整个生命周期中构思、定义、表达、记录、交流，验证合适实现，维护和改进架构的过程，也就是设计过程。

（2）架构：一个系统体现在其环境中的元素、关系的基本概念或属性，以及其设计和进化原则。

（3）架构描述：表达一个架构的工作产出物（通常指的是各种架构图和设计文档）。

（4）架构视图：通过系统的某些关注点的视角，表达一个系统的工作产出物（例如部署视图、开发视图等）。

（5）系统：包含一个或多个进程，硬件、软件、工具与可以满足需求的人的集合。

（6）环境：决定开发、操作、策略和其他影响系统的设置和条件。

在UML中，架构被认为是系统的组织结构和相关行为。一个系统的架构可看作通过接口互联部分的关系，以及它们之间的相互作用。通过接口相互作用的部分包括类、组件和子系统。这样就可以通过UML的各种架构图来描述这些对象和关系，从而清楚表达一个系统的架构。

总结：软件架构是一个用于指导系统实现的草图。这个草图越详细，对系统实现的指导意义就越重要，且贯穿于软件的整个生命周期。在建筑领域，大楼尚未建造前，就已经存在于建筑师的脑海里。同样地，开始编写第一行代码之前，系统就已经存在于软件架构师的心里。那么怎样把架构草图表达出来呢？我们一般都是采用架构图和设计文档的形式。如果我们进一步追问，使用哪些方面的架构图和设计文档就能把架构草图表达清楚呢？草图里包含哪些具体的要素和对象呢？围绕着不同的具体操作手段，就产生了不同的架构方法论，本章后续的内容会逐步介绍。