第2章
软件架构的概念
虽然软件架构已经在软件工程领域中有着广泛的应用，但迄今为止还没有一个被大家所公认的定义。但从目前存在的100多个软件架构定义来看，大体上可以分成决策派定义、组成派定义和其他定义三大类。本章简要介绍这些定义，并简要讨论这些定义的优势和不足。
2.1 引言
软件架构的定义似乎从此概念一出现就存在比较大的争论。研究人员一般认为：软件架构就是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，比如，在面向对象领域中，组件就是具体某个类或者对象，而组件之间的连接通常用接口来实现。与建筑师设定建筑项目的设计原则和目标作为绘图员画图的基础一样，一个软件架构师或者系统架构师把对软件架构的陈述作为满足不同客户需求的实际系统设计方案的基础。业界人士虽然也认同研究人员对软件架构概念的描述，但鉴于现实系统，特别是遇到的现实问题，很多时候很难用某个软件架构定义来进行系统、全面、准确的刻画，解决遇到的问题时也很难达到满意的程度，导致业界人士面对五花八门的软件架构定义时经常感到困惑，甚至刻意回避一些学术界认为比较好的做法。
在国内很多软件企业中，从事软件架构工作的人缺少系统的专业训练，虽然很多人是从编程人员、工程师的队伍中发展起来的，具有良好的软件系统开发经验和解决实际问题的能力，但是缺少很好的问题抽象能力，所以他（她）们谈论的软件架构往往与真正的架构师、研究人员心目中的软件架构不一样，他（她）们非常注重细节问题，而这些细节问题往往使得软件架构师，特别是研究人员比较困惑。而在研究人员的心目中，软件架构只是软件系统的一个比较高层次的抽象，也可以说是软件系统的骨架，这个骨架可支撑软件系统稳定、可靠、安全和高质量地运行。如果某一天这个骨架出现问题，软件系统就可能变得不稳定、不可靠、不安全，甚至不能有效运行了。所以，研究人员花费大量的人力、物力和财力研究软件架构如何建模、描述、验证和确认等，也研究出了大量的软件架构建模方法、软件架构描述语言（ADL），以及各种软件架构度量、评估、分析、测试、验证的方法和工具。但是这些成果对业界人士来说，很多都是纸上谈兵、难以落地，研究人员在业界很难找到认同感。究其原因，很多研究人员并没有多少工程实践经验，甚至没有从工程实践出发来提炼问题，所以给出的软件架构定义太过学术化，在此基础上上获得的研究成果势必与实际需求存在比较大的差异，也很难在工程实践中推广使用。
综上，由于学术界和工业界的联系不紧密，甚至脱节，导致它们对软件架构的认识不一致，从而使得软件架构至今很难有一个统一的定义，甚至是一个近似统一的定义。本章首先选择一些典型的软件架构定义进行阐述，然后在此基础上结合笔者的理解，对软件架构的定义给出一个框架性描述。
正如Martin Fowler所言：软件业的人乐于做这样的事情—找一些词汇，并将它们引申到大量微妙而又互相矛盾的含义中。其中最大的受害者就是“架构”这个词，很多人都试图给它下定义，而这些定义本身却很难统一。软件架构的定义驳杂多端，其中影响较大的定义派别是组成派和决策派：前者关注软件本身，将软件架构看作组件和交互的集合；后者关注软件架构中的实体（人），将软件架构视为一系列重要设计决策的集合。软件架构兴起初期，研究者对于软件架构的定义大都倾向组成派的观点，但随着软件架构的应用和发展，组成派观点的一些缺陷逐渐显露出来，由于软件开发者只注重软件本身，特别是组件本身，开发过程中经常会出现违背原始设计的现象，导致软件成品不能完全满足需求，软件架构形成之后的评价和演化也面临困难。在这样的条件下，决策派的观点引起了重视，即以人的决策为描述对象，从设计决策的角度来指导软件开发。然而决策派观点也有其不足之处，即对设计决策的优化程度要求很高，修改代价大。
2.2 组成派的主要定义
组成派定义的主要依据是软件架构主要反映系统由哪些部分组成，以及这些部分是如何组成的，强调软件系统的整体结构和配置。这里介绍几种有代表性的组成派定义。
1992年Dewayne和Alexander给出了软件架构最早的定义之一[1]，他们认为软件是由架构元素（element）、架构形式（form）和架构原理（rationale）组成的集合，也就是，软件架构={元素，组成，原理}，其中元素是指具有一定形式的结构化元素，包括处理元素（processing element）、数据元素（data element）和连接元素（connecting element）。处理元素负责对数据进行加工，数据元素是被加工的信息，连接元素把架构的不同部分组合连接起来。架构组成由加权的属性（weighted property）和关系（weighted relationship）构成，其中加权是指下列两种情况之一：①属性或关系的重要性；②在多个候选项之间选择的必要性，因为某些候选项相比其他的可能更受青睐。属性用来约束架构元素的选择，关系用来约束架构元素的放置（placement）。架构原理是软件架构的基础理论部分，用于指导在定义架构时面临的多种选择。架构原理指导如何准确捕获架构风格、架构元素和架构形式的选择动机。在构建软件架构时，架构原理解释了基本的哲学和美学思想，对架构师有很好的启发作用。
1993年David和Mary定义的软件架构包括组件（component）、连接件（connector）和约束（constraint）三大要素[2]，认为软件架构是软件设计过程的层次之一，该层次超越计算过程中的算法设计和数据结构设计。组件可以是一组代码，也可以是独立的程序；连接件可以是过程调用、管道和消息等，用于表示组件之间的相互关系；约束一般为组件连接时的条件。
1994年Jones认为软件架构是组件以及组件之间交互规则的集合[3]。
1994年波音公司（The Boeing Company）和DSG（Defense and Space Group）给出了一个CFRP模型[4]：软件系统由一组元素（element）构成。这组元素分成处理元素和数据元素。每个元素有一个接口（interface），一组元素的互连（connection）构成系统的拓扑结构。元素互连的语义包括静态互连语义（如数据元素的互连）、描述动态连接的信息转换协议（如过程调用、管道等）。
1995年Hayes认为软件架构是一个抽象的系统规范，主要包括由其行为和接口来描述的功能组件以及组件之间的相互连接关系[5]。
1995年David和Dewayne认为软件架构即一个程序或系统各组件的结构、它们之间的相互关系以及进行设计的原则和随时间演化的指导方针等[6]。该定义与系统的整体结构定义没有太大的区别，更加抽象，就是一种哲学思想而已。
1995年Cristina等人认为一个软件架构包括软件系统的组件、互联和约束的集合，系统需求说明的集合，以及说明组件的基本原理等[7]。
1997年Bass等人认为一个程序或计算机系统的软件架构包括软件组件、软件组件外部的可见特性及其相互关系[8]。其中，软件组件外部的可见特性是指软件组件提供的服务、性能、错误处理、共享资源使用等。
2003年Fowler在《Patterns of Enterprise Application Architecture》中对软件架构的定义如下[9]：在较高的层次上将系统分解，其中的决策稳定不变，同一系统的架构可以多种多样，架构上的主要内容会影响整个系统的生命周期，架构归结为所有重要之物。
2004年张友生在《软件体系结构》一书中将软件架构定义为[10]：为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件架构不仅指定了系统的组织结构和拓扑结构，而且显示了系统需求和构成系统的元素之间的对应关系，并提供了一些设计决策的基本原理。
2011年ISO/IEC/IEEE标准中[11]定义软件架构为某一系统的基本组织结构，其内容包括软件组件、组件间的联系、组件与其环境间的联系，以及指导上述内容设计与演化的原理。
2.3 决策派的主要定义
决策派定义的主要依据是软件架构设计是软件设计的一部分，软件设计实际上是开发人员意志和决策在软件开发过程中的体现，软件架构更是高层领导和架构师意志和决策的体现，强调的是设计决策，所以更加注重架构风格和模式的选择。这里介绍几种代表性的决策派定义。
1999年Booch等人认为软件架构是一系列重要决策的集合[12]，这些决策与以下内容有关：软件系统的组织；选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；如何组合这些元素，使它们逐渐合成为更大的子系统；用于指导这个系统组织的架构风格。
2005年Jansen等人认为软件架构是架构层次上所有设计决策的集合体[13]，这些设计决策与以下内容有关：架构改造的影响、原理、设计准则、设计约束以及附加需求。架构改造指的是对软件架构进行增加、删除和移动等操作，原理即说明为什么要对软件架构进行这样的修改，设计准则说明在设计中哪些操作可以做，设计约束则说明设计中哪些操作不可以做，附加需求是指做出一个设计决策后可能会产生的一些新需求。
2006年Kruchten等人[14]将软件架构简单地定义为“设计决策+设计”，这里的设计指的是设计决策的推理过程。
2.4 其他定义
业界还存在一些软件架构的其他定义，它们从独特的角度诠释了软件架构。
一些资深软件架构师根据他们的从业经历，也给出了软件架构的描述性定义[15]。比较有代表性的如下：Vivek Khare认为软件架构是设计和构建软件应用的科学和艺术，这些软件应用满足生命周期中用户的各种需求；Aakash Ahmad则认为软件架构是包含设计、演化、组件配置和组件互连关系的高层抽象结构；Andreas Rausch认为软件架构是一个针对软件改变的框架[15]；而Muthu Rajagopal则认为软件架构是能够有效组合在一起的软件和硬件组件的集合，这些组件组合后能满足预期需求。
2.5 参考定义框架
以上讨论的各种软件架构定义之所以同时存在，是因为人们还很难利用某个架构定义框架来统一它们。根本原因在于：软件架构与软件系统的应用领域有很大的关联，不同应用领域的软件架构师在强调软件架构共性的同时也热衷于强调个性化。所以出现有些架构定义难以理解，有些架构定义太过简单抽象的情况。例如，Jones的定义相对比较抽象，也比较片面，没有明确指出如何进行软件系统的整体配置，以及软件与外部环境的交互机制，而波音公司和DSG的定义又比较复杂，难以理解等。但是，不同应用领域的软件架构也是有共性的，特别是不同应用领域的相同类型的软件系统（如人事管理系统、考勤系统等）。站在一个更高的抽象程度，软件架构应该有统一的定义，或者存在某个参考定义框架。例如，Dewayne和Alexander的定义提倡的处理元素、数据元素和连接元素的思想，以及架构组成思想、架构原理思想，为后续的各种软件架构定义奠定了很好的基础，而且在很多其他定义中得到保持。David和Mary的定义给出了软件架构定义的3C（Component、Connector和Constraint）模型，明确了软件架构的核心组成内容，现在很多人都称之为软件架构的核心模型。
笔者基于国内外普遍认可的看法推荐如下参考定义框架[16]，如图2-1所示。也就是说，软件架构一般由五种元素构成，即组件（component）、连接件（connector）、配置（configuration）、端口（port）和角色（role）。
组件：具有某种功能的可重用的软件模块单元，表示了系统中主要的计算单元和数据存储。组件有两种，即组合组件和原子组件。组合组件由其他组合组件和原子组件连接而成。
连接件：表示了组件之间的交互，简单的连接件有管道（pipe）、过程调用（procedure-call）、事件广播（event broadcast）等。复杂的连接件有客户端–服务器（client-server）通信协议、数据库和应用之间的SQL连接等。
配置：表示了组件和连接件的拓扑逻辑和约束。
端口：组件作为一个封装的实体，只能通过接口与外部交互，组件的接口由一组端口组成，每个端口表示了组件和外部环境的交汇点。通过不同的端口类型，一个组件可以提供多重接口。端口可以很简单，如过程调用；也可以很复杂，如通信协议。
角色：连接件作为建模软件架构的主要实体，同样也有接口，连接件的接口由一组角色组成，连接件的每个角色定义了该连接件表示的交互的参与者。二元连接件有两个角色，如RPC的角色为caller 和callee，管道的角色是reading 和writing，消息传递的角色是sender 和receiver等。有的连接件有多于两个的角色，如事件广播有一个事件发布者角色和任意多个事件接收者角色。
2.6 本章小结
本章主要介绍了软件架构的两个代表性定义派别：组成派和决策派。其中组成派定义关注的是软件架构的组成部分有哪些，以及这些部分是如何组成的，强调软件系统的整体结构和配置；决策派定义强调的是设计决策，认为设计实际上是开发人员意志和决策在软件开发过程中的体现，软件架构更是高层领导和架构师意志和决策的体现，所以更加注重架构风格和模式的选择。
思考题
2.1 软件架构组成派定义和决策派定义的本质区别是什么？
2.2 软件架构的本质是什么？软件架构这些定义之间有无共同点？若有，则共同点是什么？若无，则原因是什么？
2.3 软件架构与软件系统所处的应用领域有关，谈谈你对这个问题的理解。
参考文献
[ 1 ] D E Perry, A L Wolf. Foundations for the Study of Software Architecture[J]. ACM SIGSOFT Software Engineering Notes, 1992, 17(4): 40-52.
[ 2 ] D Garlan, M Shaw. An introduction to software architecture[M]. Advances in software engineering and knowledge engineering, 1993: 1-39.
[ 3 ] A K Jones. The Maturing of Software Architecture[C]. Proceedings of the Software Engineering Symposium. Software Engineering Institute, Pittsburgh, 1994.
[ 4 ] R E Creps, M A Simos. STARS conceptual framework for reuse processes[R]. STARS Program Technical Report, 1994.
[ 5 ] B Hayes-Roth, K Pfleger, P Lalanda, et al. A domain-specific software architecture for adaptive intelligent systems[J]. IEEE Transactions on Software Engineering, 1995, 21(4): 288-301.
[ 6 ] D Garlan, D Perry. Introduction to the Special Issue on Software Architecture[C]. IEEE PRESS, 1995.
[ 7 ] C Gacek, A Abd-Allah, B Clark, et al. On the Definition of Software System Architecture[C]. Proceedings of the First International Workshop on Architectures for Software Systems, 1995: 85-94.
[ 8 ] L Bass, P Clements, R Kazman. Software Architecture in Practice[R]. DAPNIA, 1998.
[ 9 ] M Fowler. Patterns of enterprise application architecture[M]. Addison-Wesley Professional, 2003.
[10] 张友生. 软件体系结构[M]. 北京：清华大学出版社, 2004.
[11] ISO/IEC/IEEE 42010[R/OL].http://en.wikipedia.org/wiki/ISO/IEC_42010.
[12] G Booch, J Rumbaugh, I Jacobson. The Unified Modeling Language User Guide [M]. 2nd ed. Addison Wesley, 1999.
[13] A Jansen, J Bosch. Software Architecture as a Set of Architectural Design Decisions[C]. Proceedings of the 5th Working IEEE/IFIP Conference on Software Architeture. IEEE, 2005: 109-120.
[14] P Kruchten, P Lago, H V Vliet. Building up and reasoning about architectural knowledge[C]. Proceedings of the International Conference on the Quality of Software Architectures. Springer, Berlin, Heidelberg, 2006: 43-58.
[15] Community Software Architecture Definitions[EB/OL].http://www.sei.cmu.edu/architecture/start/community.cfm, 2018.
[16] 付燕. 软件体系结构实用教程[M]. 西安：西安电子科技大学出版社, 2009.
