第2章　软件架构的概念

虽然软件架构已经在软件工程领域中有着广泛的应用，但迄今为止还没有一个被大家所公认的定义。但从目前存在的100多个软件架构定义来看，大体上可以分成决策派定义、组成派定义和其他定义三大类。本章简要介绍这些定义，并简要讨论这些定义的优势和不足。

2.1　引言

软件架构的定义似乎从此概念一出现就存在比较大的争论。研究人员一般认为：软件架构就是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，比如，在面向对象领域中，组件就是具体某个类或者对象，而组件之间的连接通常用接口来实现。与建筑师设定建筑项目的设计原则和目标作为绘图员画图的基础一样，一个软件架构师或者系统架构师把对软件架构的陈述作为满足不同客户需求的实际系统设计方案的基础。业界人士虽然也认同研究人员对软件架构概念的描述，但鉴于现实系统，特别是遇到的现实问题，很多时候很难用某个软件架构定义来进行系统、全面、准确的刻画，解决遇到的问题时也很难达到满意的程度，导致业界人士面对五花八门的软件架构定义时经常感到困惑，甚至刻意回避一些学术界认为比较好的做法。

在国内很多软件企业中，从事软件架构工作的人缺少系统的专业训练，虽然很多人是从编程人员、工程师的队伍中发展起来的，具有良好的软件系统开发经验和解决实际问题的能力，但是缺少很好的问题抽象能力，所以他（她）们谈论的软件架构往往与真正的架构师、研究人员心目中的软件架构不一样，他（她）们非常注重细节问题，而这些细节问题往往使得软件架构师，特别是研究人员比较困惑。而在研究人员的心目中，软件架构只是软件系统的一个比较高层次的抽象，也可以说是软件系统的骨架，这个骨架可支撑软件系统稳定、可靠、安全和高质量地运行。如果某一天这个骨架出现问题，软件系统就可能变得不稳定、不可靠、不安全，甚至不能有效运行了。所以，研究人员花费大量的人力、物力和财力研究软件架构如何建模、描述、验证和确认等，也研究出了大量的软件架构建模方法、软件架构描述语言（ADL），以及各种软件架构度量、评估、分析、测试、验证的方法和工具。但是这些成果对业界人士来说，很多都是纸上谈兵、难以落地，研究人员在业界很难找到认同感。究其原因，很多研究人员并没有多少工程实践经验，甚至没有从工程实践出发来提炼问题，所以给出的软件架构定义太过学术化，在此基础上上获得的研究成果势必与实际需求存在比较大的差异，也很难在工程实践中推广使用。

综上，由于学术界和工业界的联系不紧密，甚至脱节，导致它们对软件架构的认识不一致，从而使得软件架构至今很难有一个统一的定义，甚至是一个近似统一的定义。本章首先选择一些典型的软件架构定义进行阐述，然后在此基础上结合笔者的理解，对软件架构的定义给出一个框架性描述。

正如Martin Fowler所言：软件业的人乐于做这样的事情—找一些词汇，并将它们引申到大量微妙而又互相矛盾的含义中。其中最大的受害者就是“架构”这个词，很多人都试图给它下定义，而这些定义本身却很难统一。软件架构的定义驳杂多端，其中影响较大的定义派别是组成派和决策派：前者关注软件本身，将软件架构看作组件和交互的集合；后者关注软件架构中的实体（人），将软件架构视为一系列重要设计决策的集合。软件架构兴起初期，研究者对于软件架构的定义大都倾向组成派的观点，但随着软件架构的应用和发展，组成派观点的一些缺陷逐渐显露出来，由于软件开发者只注重软件本身，特别是组件本身，开发过程中经常会出现违背原始设计的现象，导致软件成品不能完全满足需求，软件架构形成之后的评价和演化也面临困难。在这样的条件下，决策派的观点引起了重视，即以人的决策为描述对象，从设计决策的角度来指导软件开发。然而决策派观点也有其不足之处，即对设计决策的优化程度要求很高，修改代价大。