什么是软件架构？ - ┣◇网站建设&Web语言 - ╋艺镇╋

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

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

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

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

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

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

软件架构——这篇文章主要的关注点。
硬件架构——包括CPU, 内存，硬盘，周边设备例如打印机，与连接这些元素的部分。
组织架构——是一些关于商业进程，组织结构，规则和职责，与组织核心能力的部分。
信息架构——包含组织好的信息结构。
软件架构，硬件架构，组织架构和信息架构是全部系统架构的子结构。
企业架构，与系统架构很相似，包括硬件，软件，人员等。但是，企业架构与商业有很强的联系，因为它专注于商业对象的联系，专注于商业敏捷性和组织效率。企业架构可能穿插于公司间。

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

现在我们已浏览过这些定义了，但还有很多未回答的问题。企业架构与系统架构间有什么不同？一个企业是一个系统？信息架构与数据集成软件应用中的数据架构是一样的？不幸的是，没有对这些问题的一致的答案。

对现在来说，你会意识到这些不同，但是产业界不存在对这些内容的一致定义。因此，对你的建议只是选择那些与你的组成相似的形式并且合适的定义他们。至少你会获得某些一致性，并减少错误传达的可能。

总结

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

感谢

这篇文章的内容来源于一本即将出版的新书，暂时叫做“软件架构建立过程”。最后，我衷心的感谢对内容提出宝贵意见的人们，他们是Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Holger Heuss，Kelli Houston，Luan Doan-Minh，Philippe Kruchten，Nick Rozanski，Dave Williams，和Eoin Woods。

注释

¹ 软件工程研究所（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 等，前面引用的书。