主题：什么是软件架构？

本文来自于 Rational Edge：这篇关于软件架构的较新规则的介绍，是一个关于“架构”的四篇系列文章的的第一篇。作者以定义规则的关键术语开始，继续探索设计出色的架构对于架构所部署的环境所起的作用。

我们毫不怀疑世界正变得越来越依靠软件。软件是诸如无处不在的手机，和复杂的空中控制系统的核心元素。事实上，如果没有软件，例如eBay 和 Amazon等我们理所当然认为是创新的企业将不可能存在。甚至那些金融业，零售业和公共部门等传统行业也相当的依赖于软件。在当今的时代，某种程度上，我们很难发现一个企业完全与软件不相关。
高新企业为了生存，因此他们所依靠的软件必须能提供其所需的功能；所需的高质量；所承诺的可用性，和可接受的价格。
这篇文章的主题就是关于可以影响这些属性的软件架构。我所关注的是“强软件系统”，在IEEE中定义如下：
一个软件集成系统就是软件对于设计，构建，配置和整个系统的发展具有深入影响的系统[来自 IEEE 1471，"架构的定义" 部分]
在本文中，“架构”与“软件架构”是相同的含义。虽然这篇文章关注于软件集成系统，但是应该注意，软件集成系统仍然需要硬件来运行，并且诸如可靠性和性能等品质是通过软硬件的结合实现的。所以解决方案中的硬件部分不能被忽略。文中后面将更详细的讨论这部分内容。
定义的架构
我们对于“架构”的定义没有缺陷。甚至存在支持定义集的网站。

1

 文中的定义来自IEEE标准 1472000，IEEE对强软件系统的架构描述的推荐实践，参见IEEE 1471。

2

 定义如下，其中重要部分用粗体字表示。
架构是在组件，彼此间和与环境间的关系，引导设计发展原则中体现的系统的基本结构。[IEEE 1471]
这些标准还定义了以下相关概念：
系统是为实现某个（些）特殊作用的组件的集合。专用系统包括个人应用，传统概念上的系统，子系统，系统中的系统，产品线，产品系列，整个企业和其他利益集团。一个系统是为了实现一个或多个任务而存在。[IEEE 1471]
环境决定了开发，操作，策略和其他影响系统的设置和条件。[IEEE 1471]
任务是指系统为了实现对对象设置的使用或操作。[IEEE 1471]
涉众是对于系统有利益关系或关注的个人，团队或组织。[IEEE 1471]
正如我们所见，“组件”贯穿于这些定义。正如有意留下一个模糊的概念来解释，大部分架构定义没有提到“组件”，IEEE 1471也不例外。组件也许是逻辑上的或物理存在的，技术上独立的或特定的，规模大的或规模小的。由于文章的原因，我使用了UML 2.0规范的组件定义；并且我相当宽松的使用这个概念来包含各种所遇到的架构成分，包括了对象，技术组件（例如Enterprise JavaBean），服务，程序模块，遗留系统，包应用程序等。这些是 UML 2.0中对“组件”的定义：
[组件]是包括内容的系统模型部分，且它的显示是可替换的。组件定义了所需接口的行为。例如，组件类似类型(type)，它与所需接口行为一致。（包括静态和动态语义）

3

这里的定义包括了多种不同的概念，文中后面将有更详细的介绍。虽然工业界对于“架构”的概念没有普遍的共识，但是有必要考虑一些其他的定义使得他们可以被遵照。参照一下下面的定义，重点处我已经用粗体表示。
架构是对软件系统组织，结构部分和系统包含接口的选择，集合部分的特定行为，较大子系统部分的构成和架构风格的重大决定的设置。[Kruchten]

4


系统或计算系统的软件架构是包含软件部分，外部可见特性部分，和他们之间的关系的系统的结构。[Bass et al.]

5


[架构]是系统的组织结构和相关行为。架构可被重复分解为通过接口，互联部分的关系和结合部相互作用的部分。通过接口相互作用的部分包括类，组件和子系统。[UML 1.5]

6


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

7


虽然在某些方面定义有些区别，但我们可以看到大部分是相同的。例如，大部分定义都指出一个架构关注于结构和行为，仅关注于重要决定，可以与架构风格一致，受涉众和环境的影响，体现基于原因的决定。所有这些方面，都在下面提到。
一个架构定义结构
如果你要求人们为你描述“架构”，十分之九的人都会参照结构来解释。这在关于构建或其他土木工程结构（例如桥梁）中非常常见。虽然这些条目中的其他属性（例如行为，目的适当性和美学观念）也存在，但是结构的属性是最熟悉的和最经常被提到的。
我们对你会让某人来描述一下他所工作的软件系统架构一点也不会感到奇怪，他们将会给你展示一份系统结构方面的图表——无论这些内容是否是架构层，组件，或是分布结点。事实上，结构是架构的基础属性。架构会以各种形式展示他们自己，且大部分架构的定义是非常模糊的。一个结构组件可能是一个子系统，进程，库，数据库，计算结点，馈赠系统，按需产品等等。
许多架构的定义不但承认了他们自己的结构元素，而且还有结构元素的组成，关系（任何连接部分都需支持这样的关系），接口。这些部件都以不同方式被提供。例如，连接段可以是套接字，同步的或异步的，与某个协议相关等。
图1提供了结构元素的例子。这幅图显示了包含展示顺序进程系统的结构部分的UML类图。我们看到有三个类——OrderEntry，CustomerManagement，和AccountManagement。OrderEntry类与CustomerManagement和AccountManagement类相连。

 
图1：UML类图显示了结构元素
一个架构定义行为
与定义结构元素一样，架构定义了这些结构元素的相互作用。这些作用可以实现所期望的系统行为。图2展示了允许系统支持在顺序进程系统中的次序定义的UML顺序图。在这里我们能看到五个交互作用。第一，Sales Clerk使用OrderEntry类创建了一个顺序。OrderEntry使得客户得到使用CustomerManagement类的细节。然后OrderEntry使用 AccountManagement类创建一个次序，用次序条目构建顺序。

 
图2：UML是序列图显示了行为元素
图2与图1相连，因为我们能从图2中的关于交互作用的定义得到图1中的相关内容。例如，OrderEntry事例在被执行中要依靠CustomerManagement事例，正如在图2中所示的一样。这种依赖就如OrderEntry和CustomerManagement间通信所反映的依赖关系一样。
一个架构关注于重要元素
当一个架构定义了结构和行为，它不会在意所有的结构和行为的定义。它只在意那些被认为是重要的元素。重要的元素是那些有持久影响的，例如结构部分的主要部分，与核心行为相关的元素，和对诸如可靠性和可测量性等重要品质相关的元素。总的来说，架构不关心这些元素的细节。架构的重要性还可以以经济的重要性来表达，因为某些元素的主要驱动者是创建的成本和变更的成本。
由于架构仅关注于重要元素，它给我们提供了在考虑中的系统的一个特殊透视图——与架构最相关的透视图。

8

在这种含义下，一个架构是一个系统的抽象，可以帮助架构师管理复杂性。
我们仅仅应注意重要元素的设置不是静态的。作为一个需要被提炼，确定风险，可执行的软件构建和经验总结的结果，重要元素的设置可能会改变。但是，面对改变的架构的稳定性是好的架构，好的可执行架构进程，好的架构师的标志。如果架构需要根据变化不断作出调整，那么这不是一个好的标志。但是，如果架构相对稳定，那么相反的也对。
一个架构可以平衡涉众需求
架构是为了实现涉众的需要而创造的。但是，一般来说不可能满足所有的需求。例如，涉众可能会问特定的时间框的功能，但是这两方面（功能和时间框）是互斥的。或者为了满足时间表而减少范围或者所有的功能可以扩展时间框实现。类似的，不同的涉众之间可能有相互冲突的需求，所以应满足适当的平衡性。所以作折中是构建进程的主要方面，且妥协是架构的重要属性。
仅仅提供一个任务的例子，考虑如下涉众群各自的所需：
最终用户关心直觉，正确的行为，性能，可靠性，可用性，有效性和安全性。
系统管理员关注直觉行为，管理和辅助监测。
业务人员关注有竞争力的特性，市场的时效性，对于其他产品的定位和开销。
客户关注开销，稳定性和计划性。
开发者关注清晰的需求和简单而一致的设计方法。
项目经理关注追踪项目，计划，资源的生产使用和预算的可预见性。
维护人员关注易理解性，一致性，和文档化的设计方法，与易修改性。