一个架构定义结构

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

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

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

    图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在这种含义下，一个架构是一个系统的抽象，可以帮助架构师管理复杂性。

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