第1章 解析软件架构概念
不积跬步，无以至千里。——《荀子·劝学篇》
什么是架构？如果你问五个不同的人，可能会得到五种不同的答案。
——Ivar Jacobson，《AOSD中文版》
很多人都试图给“架构”下定义，而这些定义本身却很难统一。
——Martin Fowler，《企业应用架构模式》
不积跬步，无以至千里。作为本书的第1章，我们首先讨论软件架构的概念。为了给读者带来实感，我们将结合流行的MVC架构以及一个名为PM Tool的项目管理系统的案例故事进行讲解。
值得说明的是，人们对“Architecture”有着不同的中文叫法，比如架构、构架和体系结构等。本书将一以贯之地采用“架构”的叫法；当然，当引用原文或提及书名时将保留原来的叫法。
1.1 软件架构概念的分类
地锅鸡的做法一个词（比如“电脑”），可能并不代表一件单独的东西，而是代表了一类事物。这个一般性的表述就是我们通常所说的“概念”。
拿破仑难过美人关
也许读者期待一个干净利落的软件架构概念，但这有点儿难。对此，Martin Fowler给出的评价是，“软件业的人乐于做这样的事——找一些词汇，并将它们引申到大量微妙而又相互矛盾的含义中。一个最大的受害者就是‘架构’这个词。……很多人都试图给‘架构’下定义，而这些定义本身却很难统一。”
的确如此。由于软件架构的概念有太多的版本，这已经对软件架构师的工作，乃至整个软件开发活动造成了不少麻烦。
第1章 解析软件架构概念
4
y造成交流上的误解。此君说的软件架构，和彼君理解的软件架构未必是一回事；
y造成实践上的障碍。软件架构设计领域和其他任何复杂领域一样，即使对基本概念和思想有了清晰的认识，依然未必能够保证实践畅通无阻。更何况是在架构概念本身还
处于“微妙的相互矛盾”之中的情况下呢？
y造成分工合作中的不一致。架构设计究竟要覆盖哪些范围？架构设计应进行到什么程度？对这两个问题认识上的不一致当然也和架构概念混乱有关。一方面，开发者对架
构的明确程度期望甚高；另一方面，架构师的架构设计方案却是高来高去；这就造成
了大量设计空白，最终往往靠临时拍脑袋或临时商量来决定，于是软件质量下降、协
闪耀造句
作开发混乱就在所难免了；
y造成其他概念乘虚而入。我们的大脑中“驻扎”了很多概念，“软件架构”一词如此流行，以至于每个软件人员的大脑中都有它的一席之地。但由于软件架构的概念本身
没有一个具有压倒性优势的定义充当“旗手”，致使许多人大脑中贴着“软件架构”
标签的位置已经被其他概念占据了——典型的片面认识包括架构就是结构、架构就是
基础设施（infrastructure）、架构就是框架（Framework），等等。
本书认为，鉴于软件架构概念的混乱，应该采取分类的办法。这是因为，通过分类可以在包容细节差
异的基础上明确共性，达到“概念总体上的清晰”。笔者的经验证明，这种务实的做法是有利于实践的。
下面，我们将软件架构概念分为两大流派：组成派和决策派。
1.1.1 组成派
Mary Shaw在《软件体系结构：一门初露端倪学科的展望》中，为“软件架构”给出了非常简明的定义：
软件系统的架构将系统描述为计算组件及组件之间的交互（The architecture of a
software system defines that system in terms of computational components and interactions
迪丽热巴高清壁纸among tho components.）。
必须说明，上述定义中的“组件”是广泛意义上的元素之意，并不是指和CORBA、DCOM、EJB等相关的专有的组件概念。“计算组件”也是泛指，其实计算组件可以进一步细分为处理组件、数据组件、连接组件等。总之，“组件”可以指子系统、框架（Framework）、模块、类等不同粒度的软件单元，它们可以担负不同的计算职责。
挪威在哪里
上述定义是“组成派”软件架构概念的典型代表，有如下两个显著特点：
（1）关注架构实践中的客体——软件，以软件本身为描述对象；
力耕
（2）分析了软件的组成，即软件由承担不同计算任务的组件组成，这些组件通过相互交互完成更高层次的计算。
1.2 软件架构概念大观 5
1.1.2 决策派
下面来看看RUP（Rational Unified Process，Rational统一过程）中的软件架构定义。
软件架构包含了关于以下问题的重要决策：
y软件系统的组织；
y选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；
y如何组合这些元素，使它们逐渐合成为更大的子系统；
y用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合。
软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性
能、弹性、重用、可理解性、经济和技术的限制及权衡，以及美学等。
上述定义看似冗长，但其核心思想非常明确：软件架构是在一些重要方面所作出的决策的集合。
该定义是“决策派”软件架构概念的典型代表，有如下两个显著特点：
（1）关注架构实践中的主体——人，以人的决策为描述对象；
（2）归纳了架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能需求的决策。
1.2 软件架构概念大观
如前所述，将软件架构概念分类的好处是：包容细节差异、明确本质共性、促成概念总体上的清晰。下面我们再列举几个著名的软件架构定义，以期达到下列目的：
（1）体会和证明众多软件架构概念都是围绕“组成”和“决策”两个视角展开的；
（2）开阔视野，说不定和你合作的同事所接受的软件架构概念就是其中的一种。
具体而言，下面的定义1和定义2属于架构概念的“决策派”，而定义3、4、5、6、7属于架构概念的“组成派”。值得说明的是，定义7是来自SEI的Bass等人的相对比较新的定义，它将架构的多视图“本性”体现到了架构的定义当中，本书认为这种做法非常值得肯定。在第4章中，我们将专门讨论软件架构视图这一主题。
1.2.1 Booch、Rumbaugh和Jacobson的定义
架构是一系列重要决策的集合，这些决策与以下内容有关：软件的组织，构成系统的结构元
第1章 解析软件架构概念
6
素及其接口的选择，这些元素在相互协作中明确表现出的行为，这些结构元素和行为元素进一步组合所构成的更大规模的子系统，以及指导这一组织——包括这些元素及其接口、它们的协作和它们的组合——架构风格。
1.2.2 Woods的观点
Eoin Woods是这样认为的：软件架构是一系列设计决策，如果作了不正确的决策，你的项目可能最终会被取消（Software architecture is the t of design decisions which, if made incorrectly, may cau your project to be cancelled.）。
1.2.3 Garlan和Shaw的定义
Garlan和Shaw认为：架构包括组件（Component）、连接件（Connector）和约束（Constrain）三大要素。组件可以是一组代码（例如程序模块），也可以是独立的程序（例如数据库服务器）。连接件可以是过程调用、管道和消息等，用于表示组件之间的相互关系。“约束”一般为组件连接时的条件。
1.2.4 Perry和Wolf的定义
Perry和Wolf提出：软件架构是一组具有特定形式的架构元素，这些元素分为三类：负责完成数据加工的处理元素（Processing Elements）、作为被加工信息的数据元素（Data Elements）及用于把架构的不同部分组合在一起的连接元素（Connecting Elements）。
1.2.5 Boehm的定义
Barry Boehm和他的学生提出：软件架构包括系统组件、连接件和约束的集合，反应不同涉众需求的集合，以及原理（Rationale）的集合。其中的原理，用于说明由组件、连接件和约束所定义的系统在实现时，是如何满足不同涉众需求的。
1.2.6 IEEE的定义
IEEE 610.12-1990软件工程标准词汇中是这样定义架构的：架构是以组件、组件之间的关系、组件与环境之间的关系为内容的某一系统的基本组织结构，以及指导上述内容设计与演化的原理（Principle）。
反骨1.2.7 Bass的定义
SEI（Software Engineering Institute, SEI，美国卡内基梅隆大学软件研究所）的Bass等人给架构的定义是：某个软件或计算机系统的软件架构是该系统的一个或多个结构，每个结构均由软
1.3 软件架构关注分割与交互 7
件元素、这些元素的外部可见属性、这些元素之间的关系组成（The software architecture of a progra
m or computing system is the structure or structures of the system, which compri software elements, the externally visible properties of tho elements, and the relationships among them.）。
1.3 软件架构关注分割与交互
本节结合流行的MVC架构，说明软件架构是如何将系统分为不同部分，以及各部分之间如何交互的。
“软件系统的架构将系统描述为计算组件及组件之间的交互”，Shaw的这个定义从“软件组成”角度解析了软件架构的要素：组件及组件之间的交互。通过UML类图，我们可以将这个关系表达得更加清晰，参见图1-1。如图所示，组件和组件之间有交互关系，图中的“交互”采用了关联类的语法。
图1-1 软件架构的要素：组件及组件之间的交互
Shaw的架构定义高度抽象地将软件架构概括为“组件＋交互”，下面以大家熟悉的MVC架构为例进行说明（如图1-2所示）。
禁毒安全知识
图1-2 MVC架构作为“组件＋交互”的例子
采用MVC架构的软件包含了这样3种组件：Model、View、Controller。
同时，为了达到一定的目的，这3种组件必须通过交互来协作，比如：View创建Controller 后，Controller根据用户交互调用Model的相应服务，而Model会将自身的改变通知View，View
则会读取Model的信息以更新自身。
通过此例可以看出，“组件＋交互”可以将MVC等“具体架构设计决策”高屋建瓴地抽象
地表达出来。
