软件架构设计 · 架构的身世与三个定义

阿明，从这集起我们进入全书分量最重的一章——第 9 章，软件架构设计。原文开篇打了个好比方：像学写文章一样，在学会字、词、句之后，就应上升到段落，就应追求文章的布局谋篇，这就是架构。通俗地讲，软件架构设计就是软件系统的布局谋篇。软件设计人员学习架构知识，旨在站在较高的层面上整体地解决好软件的设计、复用、质量和维护等方面的实际问题。

原文四万七千多字，全书之最，我们拆成十六集慢慢啃。先划范围：软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。今天先讲架构的身世和它的定义，都是选择题的直接取材点。

软件架构是软件抽象发展到一定阶段的产物，从编程角度能清晰看到这条线，它是标准的年代配对题。20 世纪 60 年代是子程序的年代：出现了原始的软件架构，即子程序，并以程序间的调用为连接关系。70 年代是模块化的年代：出现了数据流分析、实体—关系图也就是 E-R 图、信息隐藏等工具和方法，软件的抽象层次发展到了模块级。

80 年代是面向对象的年代：基于模块化的编程语言进一步发展成面向对象的语言，继承性地增加了一种新元素之间的连接关系。90 年代是框架的年代：标准的基于对象的架构以框架的形式出现了，如电子数据表、文档、图形图像、音频剪辑等可互换的黑箱对象，可以相互嵌入。当前，也就是最近十年来：中间件和 IT 架构作为标准平台出现，用可购买可复用的元素来构建系统，同时基于架构的开发方法和理论不断成熟。

顺序对了。考题最爱干两件事：把「框架」安到八十年代，或者问「程序间调用是哪个年代的连接关系」——答六十年代。八十年代对应的新连接关系是继承，这两个别混。接下来是重头戏，软件架构的定义。软件架构仍在不断发展中，还没有形成一个统一的、公认的定义，原文举出几个较权威的定义。

三个，都要看，各抓特征。定义 1：软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。

定义 2：软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成。

定义 3：软件架构是指一个系统的基础组织，它具体体现在：系统的构件，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。

挂的是 IEEE1471-2000，问「下列哪个定义出自 IEEE1471-2000」就选它。三个定义的关系原文也交代了：前两个定义都是按「元素—结构—架构」这一抽象层次来描述的，它们的基本意义相同，其中定义 1 较通俗，因此本章采用这一定义。

定义 1 里还有两个词要抠准：软件元素，是指比「构件」更一般的抽象；元素的「外部可见属性」，是指其他元素对该元素所做的假设，如它所提供的服务、性能特征等。

会，拿「构件」和「元素」玩偷换是常见手法。接着是定义的六点说明，这是判断题富矿，我逐条给你。第一，架构是对系统的抽象，它通过描述元素、元素的外部可见属性及元素之间的关系来反映这种抽象，因此仅与内部具体实现有关的细节是不属于架构的，定义强调的是「外部可见」属性。

第二，架构由多个结构组成，结构是从功能角度来描述元素之间的关系的，具体的结构传达了架构某方面的信息，但是个别结构一般不能代表大型软件架构。第三，任何软件都存在架构，但不一定有对该架构的具体表述文档，也就是说架构可以独立于架构的描述而存在，如文档已过时，则该文档不能反映架构。

对，架构和文档是两回事。第四，元素及其行为的集合构成架构的内容，体现系统由哪些元素组成、各有哪些功能、如何连接与互动；它在两个方面进行抽象：在静态方面，关注系统的大粒度也就是宏观总体结构，比如分层；在动态方面，关注系统内关键行为的共同特征。

第五，架构具有「基础」性：它通常涉及解决各类关键的重复问题的通用方案，也就是复用性，以及系统设计中影响深远、架构敏感的各项重要决策——一旦贯彻，更改的代价昂贵。第六，架构隐含有「决策」，即架构是由架构设计师根据关键的功能和非功能性需求，也就是质量属性及项目相关的约束，进行设计与决策的结果。

原文正是这么说的，而且补了两句：为避免架构设计师考虑不周，重大决策应经过评审；架构设计师自身的水平是一种约束，不断学习和积累经验才是摆脱这种约束走向自由王国的必经之路。这里还夹着一个辨析：设计软件架构时也必须考虑硬件特性和网络特性，因此软件架构与系统架构二者间的区别其实不大；但在大多情况下，架构设计师在软件方面的选择性较之硬件方面自由度大得多，所以使用「软件架构」这一术语，也表明了一个观点——架构设计师通常将架构的重点放在软件部分。

对，将软件架构置于商业背景中进行观察，可以发现软件架构对企业非常重要，分正反两个方向记。一方面，影响架构的因素：软件系统的项目干系人，包括客户、用户、项目经理、程序员、测试人员、市场人员等，对软件系统有不同的要求；开发组织即项目组有不同的人员知识结构；还有架构设计师的素质与经验、当前的技术环境等。这些因素通过功能性需求、非功能性需求、约束条件及相互冲突的要求，影响架构设计师的决策，从而影响架构。

能，这就是反作用。举例：影响开发组织的结构——架构描述了系统的大粒度宏观总体结构，因此可以按架构进行分工，将项目组分为几个工作组，使开发有序；还影响开发组织的目标——成功的架构为开发组织提供了新的商机，这归功于系统的示范性、架构的可复用性及团队开发经验的提升；同时，成功的系统将影响客户对下一个系统的要求。这种反馈机制，原文给它起了名字，叫架构的商业周期。

必背。本集清单：演化史五段配对——六十年代子程序且连接关系是调用、七十年代模块化、八十年代面向对象且新连接关系是继承、九十年代框架、当前中间件；三个定义，定义 1 是结构与元素外部可见属性、本章采用它、元素比构件更一般，定义 2 是高级抽象加模式加约束，定义 3 出自 IEEE1471-2000 讲构件、关系和指导设计演化的原则；六点说明里三句判断题——仅与内部实现有关的细节不属于架构、任何软件都有架构但未必有文档、个别结构不能代表大型软件架构；最后是架构的商业周期：干系人和技术环境通过需求与约束影响架构，架构反过来影响组织结构与目标。

下一集讲软件架构的重要性——它在技术上到底重要在哪四个方面，以及基于架构的开发把整个过程划成哪六个子过程，那六个名字是简答级的考点，一个都不能少。