高新企业为了生存，因此他们所依靠的软件必须能提供其所需的功能；所需的高质量；所承诺的可用性，和可接受的价格。这篇文章的主题就是关于可以影响这些属性的软件架构。

我所关注的是“强软件系统”，在 IEEE 中定义如下：

一个软件集成系统就是软件对于设计，构建，配置和整个系统的发展具有深入影响的系统 [ 来自 IEEE 1471 ， " 架构的定义 " 部分 ]

在本文中，“架构”与“软件架构”是相同的含义。虽然这篇文章关注于软件集成系统，但是应该注意，软件集成系统仍然需要硬件来运行，并且诸如可靠性和性能等品质是通过软硬件的结合实现的。所以解决方案中的硬件部分不能被忽略。文中后面将更详细的讨论这部分内容。

定义的架构

我们对于“架构”的定义没有缺陷。甚至存在支持定义集的网站。 ¹ 文中的定义来自 IEEE 标准 1472000 ， IEEE 对强软件系统的架构描述的推荐实践，参见 IEEE 1471 。 ² 定义如下，其中重要部分用粗体字表示。

架构是在组件，彼此间和与环境间的关系，引导设计发展原则中体现的系统的基本结构。 [IEEE 1471]

这些标准还定义了以下相关概念：

系统 是为实现某个（些）特殊作用的组件的集合。专用系统包括个人应用，传统概念上的系统，子系统，系统中的系统，产品线，产品系列，整个企业和其他利益集团。一个系统是为了实现一个或多个任务而存在。 [IEEE 1471]

环境 决定了开发，操作，策略和其他影响系统的设置和条件。 [IEEE 1471]

任务 是指系统为了实现对对象设置的使用或操作。 [IEEE 1471]

涉众 是对于系统有利益关系或关注的个人，团队或组织。 [IEEE 1471]

正如我们所见，“组件”贯穿于这些定义。正如有意留下一个模糊的概念来解释，大部分架构定义没有提到“组件”， IEEE 1471 也不例外。组件也许是逻辑上的或物理存在的，技术上独立的或特定的，规模大的或规模小的。由于文章的原因，我使用了 UML 2.0 规范的组件定义；并且我相当宽松的使用这个概念来包含各种所遇到的架构成分，包括了对象，技术组件（例如 Enterprise JavaBean ），服务，程序模块，遗留系统，包应用程序等。这些是 UML 2.0 中对“组件”的定义：

[ 组件 ] 是包括内容的系统模型部分，且它的显示是可替换的。组件定义了所需接口的行为。例如，组件类似类型 (type) ，它与所需接口行为一致。（包括静态和动态语义） ³

这里的定义包括了多种不同的概念，文中后面将有更详细的介绍。虽然工业界对于“架构”的概念没有普遍的共识，但是有必要考虑一些其他的定义使得他们可以被遵照。参照一下下面的定义，重点处我已经用粗体表示。

架构 是对软件系统组织，结构部分和系统包含接口的选择，集合部分的特定行为，较大子系统部分的构成和架构风格的重大决定的设置。 [Kruchten]⁴

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

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

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

虽然在某些方面定义有些区别，但我们可以看到大部分是相同的。例如，大部分定义都指出一个架构关注于结构和行为，仅关注于重要决定，可以与架构风格一致，受涉众和环境的影响，体现基于原因的决定。所有这些方面，都在下面提到。

一个架构定义结构

如果你要求人们为你描述“架构”，十分之九的人都会参照结构来解释。这在关于构建或其他土木工程结构（例如桥梁）中非常常见。虽然这些条目中的其他属性（例如行为，目的适当性和美学观念）也存在，但是结构的属性是最熟悉的和最经常被提到的。

我们对你会让某人来描述一下他所工作的软件系统架构一点也不会感到奇怪，他们将会给你展示一份系统结构方面的图表——无论这些内容是否是架构层，组件，或是分布结点。事实上，结构是架构的基础属性。架构会以各种形式展示他们自己，且大部分架构的定义是非常模糊的。一个结构组件可能是一个子系统，进程，库，数据库，计算结点，馈赠系统，按需产品等等。

许多架构的定义不但承认了他们自己的结构元素，而且还有结构元素的组成，关系（任何连接部分都需支持这样的关系），接口。这些部件都以不同方式被提供。例如，连接段可以是套接字，同步的或异步的，与某个协议相关等。

图 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 间通信所反映的依赖关系一样。

一个架构关注于重要元素

当一个架构定义了结构和行为，它不会在意所有的结构和行为的定义。它只在意那些被认为是重要的元素。重要的元素是那些有持久影响的，例如结构部分的主要部分，与核心行为相关的元素，和对诸如可靠性和可测量性等重要品质相关的元素。总的来说，架构不关心这些元素的细节。架构的重要性还可以以经济的重要性来表达，因为某些元素的主要驱动者是创建的成本和变更的成本。

由于架构仅关注于重要元素，它给我们提供了在考虑中的系统的一个特殊透视图——与架构最相关的透视图。 ⁸ 在这种含义下，一个架构是一个系统的抽象，可以帮助架构师管理复杂性。

我们仅仅应注意重要元素的设置不是静态的。作为一个需要被提炼，确定风险，可执行的软件构建和经验总结的结果，重要元素的设置可能会改变。但是，面对改变的架构的稳定性是好的架构，好的可执行架构进程，好的架构师的标志。如果架构需要根据变化不断做出调整，那么这不是一个好的标志。但是，如果架构相对稳定，那么相反的也对。

一个架构可以平衡涉众需求

架构是为了实现涉众的需要而创造的。但是，一般来说不可能满足所有的需求。例如，涉众可能会问特定的时间框的功能，但是这两方面（功能和时间框）是互斥的。或者为了满足时间表而减少范围或者所有的功能可以扩展时间框实现。类似的，不同的涉众之间可能有相互冲突的需求，所以应满足适当的平衡性。所以作折中是构建进程的主要方面，且妥协是架构的重要属性。

仅仅提供一个任务的例子，考虑如下涉众群各自的所需：

l         最终用户关心直觉，正确的行为，性能，可靠性，可用性，有效性和安全性。

l         系统管理员关注直觉行为，管理和辅助监测。

l         业务人员关注有竞争力的特性，市场的时效性，对于其他产品的定位和开销。

l         客户关注开销，稳定性和计划性。

l         开发者关注清晰的需求和简单而一致的设计方法。

l         项目经理关注追踪项目，计划，资源的生产使用和预算的可预见性。

l         维护人员关注易理解性，一致性，和文档化的设计方法，与易修改性。

正如表中可看到的，对于架构师的另一个挑战是涉众群不仅仅关注系统所提供的需求功能。他们所关注的在实际中是不起作用的，因为在系统中他们不发生作用。（例如，关于成本和计划的关注）但是这些关注体现了系统质量或局限。非功能需求经常是架构师所关注的最重要的需求。

一个架构基于基本原理体现决策

一个架构的重要部分不仅仅是最终结果，架构本身，而是他为什么是如此的原因。因此，确信你已把使用这个架构和原因文档化就非常重要了。

这个信息与许多涉众都有关系，尤其是那些维护系统的人。这些信息对需要参考设计理由的架构师来说非常有价值，因为他们可以省去不必要的步骤。例如，当需要重复架构和架构师重新审视所做的决定时，这些信息非常有用。

一个架构可以符合一个架构样式

大部分的架构来源于有相似关注的共享系统。这些相似性可被描述成某种特殊模式的架构风格，虽然经常是复杂和组合模式（由许多模式共同作用）。一种架构风格展示一个经验法典，并且有利于架构师重复使用类似经验。架构风格的例子包括分布式的风格，管道和过滤器风格，数据中心风格，基于规则的风格等。一个系统可以包含多于一个架构风格。 Shaw 和 Garlan 的描述如下：

[ 架构风格 ] 按照结构组织的模式定义了系统。更具体的，架构风格定义了组件和连接型的语法，和连接的方法。 ⁹

在 UML 中的定义 :

[ 模式 ] 是对于普遍问题的普遍解决方案。 ¹⁰

除了重复经验，由于一种风格以文档的形式保存了使用它的理由和它的结构与行为，所以架构风格的应用使类似架构师的工作变得容易起来。

一个架构被其环境所影响

系统贮存于环境中，且环境影响架构。这就是有时所提到的“环境中的架构”。基本上，环境决定了系统运行的范围，这些又决定了架构。影响架构的环境的因素包含架构所支持的商务环境，系统涉众群，内部技术限制（例如需要符合组织标准），和外部技术限制（例如对外部系统的接口或遵守外部规则的标准）。

相反的，如在 Bass, Clements, 和 Kazman 所描述的， ¹¹ 架构可能还影响它的环境。不但是从技术前景的架构创新改变了环境 -- 例如它可能对拥有组织的可重复使用价值有贡献——架构的创新可能在技术方面改变环境。

当提到软件集成系统，有一个必须被提到的关于环境的特殊部分。为了软件的有用性，它必须执行。为了执行，软件运行在硬件之上。所以最终系统是软硬件的结合，与诸如可靠性和性能等完美结合的实现。软件不能在单独的硬件条件下实现这些功能。

IEEE 标准 12207-1995 ， IEEE 信息技术标准 －－ 软件生命周期过程，定义了与之前 IEEE1471 不同的系统（关注于软件集成系统），但与在系统工程方面定义的相同：

[ 系统 ] 是包含了一个或多个进程，硬件，软件，工具与可以满足需求的人的集合。 [IEEE 12207]¹²

Systems Engineering (RUP SE) 的 Rational Unified Process 配置包含一个类似的定义。

[ 系统 ] 是提供为企业执行商业目的或任务的服务资源。系统组件包括硬件，软件，数据和工作人员 ¹³ 。

在系统工程方面，根据软件，硬件和人的使用定义事务。例如，如果性能为重，那么可能决定某一个系统元素的硬件实现，而不是软件或人。另一个例子是为了给客户提供可用系统，所以要给客户提供接口。更复杂的情况需要通过软硬件和人的结合实现系统功能。

我们非常有趣的注意到系统工程特别关注于对待软件和硬件，因此避免把硬件和软件相比作为第二级，或是执行软件的载体，或是反过来。

一个架构影响团队结构

架构定义了一组连贯的相关元素。例如，顺序进程系统架构可能已定义了一组次序入口，计数管理，客户管理，实现，外部系统集成，持续性和安全性。

每一组都会要求不同的技术。因此，一旦被定义好，统一软件开发小组结构就非常有意义了。但是，情况经常是最初的小组结构影响了构架，而不是相反情况。因为结果通常都是一个不太理想的架构。“康威规律” 规定“如果你有 4 个编译小组，那你会有 4 路编译器”。 实际上，我们经常会无意识地创建架构，以反映创建架构的组织。

但是，完全从实际出发，事实上这种有点理想的观点经常是不实际的，因为当前小组结构和技术都有实际可能的限制，并且架构师必须考虑在内。

一个架构呈现在每一个系统中

每个系统都有一个架构，即使这个架构没有被文档化，或者如果系统非常简单且包含单一元素。对架构文档化很有价值。文档化的架构比没有的考虑的更周全——因此也更有效，所以根据架构的进程可以更细致的考虑。

相反地，如果架构没有文档化，那么很困难来证明满足了诸如可维护性，最佳适应性等的需求。似乎大部分现今存在的无文档的架构都有些随意性而不是目的性。

一个架构拥有一个特定的范围

有许许多多种架构，最著名的是与建筑和其他工程相关的。甚至在软件工程领域，我们经常会遇到不同形式的架构。例如，除了软件构架的概念，我们会遇到诸如企业架构，系统架构，组织架构，信息架构，硬件架构，应用架构，基础设施架构等。你会见到其他类型的，每种类型都定义了一个架构的具体范围。

不幸的是，产业界没有相互形式间的协定，所以导致了对同一形式的不同意思。但是，从图 3 中可以推断出这些形式的范围。当你们在考虑和讨论下面这张图的时候，你肯定会发现很多你不同意的元素或是在你们的组织中不同的使用方法。但是重要的是——这些形式的确存在，却没有一致的观点。

图 3 ：不同领域的范围

图 3 展示的元素有：

l         软件架构——这篇文章主要的关注点。

l         硬件架构——包括 CPU, 内存，硬盘，周边设备例如打印机，与连接这些元素的部分。

l         组织架构——是一些关于商业进程，组织结构，规则和职责，与组织核心能力的部分。

l         信息架构——包含组织好的信息结构。

l         软件架构，硬件架构，组织架构和信息架构是全部系统架构的子结构。

l         企业架构，与系统架构很相似，包括硬件，软件，人员等。但是，企业架构与商业有很强的联系，因为它专注于商业对象的联系，专注于商业敏捷性和组织效率。企业架构可能穿插于公司间。

正像人们期盼的那样，有相应形式的架构师（例如软硬件架构师等）和架构（例如，软硬件架构等）。

总结

这篇文章关注于定义软件架构的核心特性。但是，仍然有很多未被解答的问题。什么是软件架构师的角色？架构师最重要的活动是什么？从“建立架构”中能得到什么好处？这些问题将在后续文章中被解答。

注释

¹ 软件工程研究所（ SEI ）架构 Web 站点 －－ 架构定义，提供了一个好的例子。参见 http://www.sei.cmu.edu/architecture/definitions.html

² IEEE Computer Society ，强软件系统的架构描述的 IEEE 推荐实践： IEEE 标准 1472000 ， 2000 。

³ 对象管理组织， UML 2.0 结构规格说明：文档号 03-09-15 。 2003 年九月。

⁴ Philippe Kruchten ， Rational 统一过程：介绍，第三版。 Addison-Wesley Professional 2003 。

⁵ Len Bass ， Paul Clements 和 Rick Kazman ，软件架构实践，第二版。 Addison Wesley 2003 。

⁶ 对象管理组织， OMG 统一建模语言规格 1.5 版，文档号 03-03-01 。 2003 年三月。

⁷ James McGovern 等，企业架构的实践指南。 Prentice Hall 2004

⁸ 一个在本系列的后续文章中所涵盖的角色。

⁹ Mary Shaw 和 David Garlan ，软件架构 -- 关于一个正在形成的学科的观察。 Prentice Hall 1996 ，

¹⁰ Grady Booch ， James Rumbaugh 和 Ivar Jacobson ，统一建模语言用户指南。 Addison Wesley 1999 。

¹¹ Bass 等，前面引用的书。

¹² IEEE Computer Society ， IEEE 信息技术标准 －－软件生命周期过程。 IEEE 标准 12207-1995 。

¹³ Murray Cantor ，“系统工程的 Rational 统一过程”。 The Rational Edge ， 2003 年八月。 http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/aug03/f_rupse_mc.pdf