当提到架构的时候并不缺少架构的定义。甚至有一些网站还维护了这些定义集。本文中用到的定义来自于IEEE 1471 2000,软件密集系统架构描述的IEEE操作规程建议(IEEE 1471 2000)。这个定义遵循(关键特性着重显示):
架构是体现在它的组件中的一个系统的基本组织、它们彼此的关系、与环境的关系及指导它的设计和发展的原则。(IEEE 1471 2000)
这个标准也详细说明了与这个定义相关的下列术语:
系统是组织起来完成某一特定功能或一组功能的组件集。系统这个术语包括了单独的应用程序、传统意义上的系统、子系统、系统之系统、产品线、产品组、整个企业及感兴趣的其他集合。系统用于完成它的环境中的一个或多个任务。(IEEE 1471 2000)
环境或上下文决定了对这个系统的开发、运作、政策以及会对系统造成其他影响的环境和设置。(IEEE 1471 2000)
任务是由一个或多个利益相关者通过系统达到一些目标的系统的一个用途或操作。(IEEE 1471 2000)
系统利益相关者是对系统感兴趣的或与系统有关系的一个单独的团队或组织(或组织的一部分)。(IEEE 1471 2000)
正如您所见,在这个定义中用到了组件这个术语。然而,大多数的架构定义都没有定义组件这个术语,IEEE 1471也不例外,故意让它比较含糊,因为这个术语在行业中存在很多解释。一个组件可能是逻辑上的或物理上的、独立于技术的或针对特定技术的、粗粒度的或细粒度的。在本书中,我们使用统一建模语言(UML,Unified Modeling Language)规范中的组件的定义:
组件代表一个系统模块化的一部分,它封装了自身的内容,在环境中它的表现是可替换的。一个组件根据供给接口和需求接口定义自己的行为。同样地,一个组件也属于某一个类型,其一致性由这些供给接口和需求接口(包括它们的静态语义和动态语义)来定义。因此,一个组件可以由另一个组件替换,只要这两个组件类型一致。(UML 2.2 2009)
架构、架构师和架构设计探讨架构的另一些定义以便能够观察这些定义之间的相似性,这是值得的。请看下面的这些定义,其中的一些关键特性已经突出显示了。
架构是关于下面这些内容的重要的决策集合:软件系统的组织、构件的选择及系统用于组装在一起的接口、这些构件之间相互协作的行为、把这些构件合成到日益变大的子系统、指导这个组织的架构风格——所有这些构件和它们的接口、它们的协作、它们的组合。(Kruchten 2000)
一个程序或计算系统的软件架构是一个或多个系统结构:它由软件要素、这些要素的外部可视属性和它们之间的关系组成。(Bass 2003)
一个系统或一个系统集的软件架构由所有关于组成这些系统的软件结构和这些结构之间交互的重要的设计决策组成。这些设计决策支持系统取得成功所需要的特性。这些决策为系统开发、支持和维护提供一个理论基础。(McGovern 2004)
您可以看到,虽然这些定义有所不同,但是,它们有很大的相似性。大部分定义都指出一个架构应该既关注结构又包括行为,应该关注重要的因素,遵循一种架构风格,受其利益相关者和环境的影响,基于基本逻辑使决策具体化。接下来的章节将讨论这些主题及其他内容。