几种常用软件架构设计指南软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

软件架构是一个系统的草图。

软件架构描述的对象是直接构成系统的抽象组件。

各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。

在面向对象领域中，组件之间的连接通常用接口来实现。

软件体系结构的定义虽然软件体系结构已经在软件工程领域中有着广泛的应用，但迄今为止还没有一个被大家所公认的定义。

许多专家学者从不同角度和不同侧面对软件体系结构进行了刻画，较为典型的定义有：Dewayne Perry和A1ex Wo1f曾这样定义：软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。

处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组组合连接起来。

这一定义注重区分处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基本上得到保持。

Mary Shaw和David Garlan认为软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。

体系结构问题包括总体组织和全局控制、通讯协议、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。

软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通讯、同步与数据存取的协议，设计构件功能定义，物理分布与合成，设计方案的选择、评估与实现等Kruchten指出，软件体系结构有四个角度，它们从不同方面对系统进行描述：概念角度描述系统的主要构件及它们之间的关系；模块角度包含功能分解与层次结构；运行角度描述了一个系统的动态结构；代码角度描述了各种代码和库函数在开发环境中的组织。

Hayes Roth则认为软件体系结构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。

David Garlan和Dewne Perry于1995年在IEEE软件工程学报上又采用如下的定义：软件体系结构是一个程序／系统各构件的结构、它们之间的相互关系以及进行设计的原则和随时间进化的指导方针。

Barry Boehm和他的学生提出，一个软件体系结构包括一个软件和系统构件，互联及约束的集合；一个系统需求说明的集合；一个基本原理用以说明这一构件，互联和约束能够满足系统需求。

1997年，Bass，Ctements和Kazman在《使用软件体系结构》一书中给出如下的定义：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。

其中，"软件外部的可见特性"是指软件构件提供的服务、性能、特性、错误处理、共享资源使用等。

软件体系结构建模研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。

根据建模的侧重点的不同，可以将软件体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。

在这5个模型中，最常用的是结构模型和动态模型。

结构模型这是一个最直观、最普遍的建模方法。

这种方法以体系结构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。

研究结构模型的核心是体系结构描述语言。

框架模型框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。

框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

动态模型动态模型是对结构或框架模型的补充，研究系统的"大颗粒"的行为性质。

例如，描述系统的重新配置或演化。

动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。

这类系统常是激励型的。

过程模型过程模型研究构造系统的步骤和过程。

因而结构是遵循某些过程脚本的结果。

功能模型该模型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。

它可以看作是一种特殊的框架模型。

这5种模型各有所长，也许将5种模型有机地统一在一起，形成一个完整的模型来刻画软件体系结构更合适。

例如，Kruchten在1995年提出了一个"4+1"的视角模型。

"4+1"模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软件体系结构。

每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件体系结构的全部内容。

图1 “4+1”视图模型逻辑架构逻辑架构主要支持功能性需求――即在为用户提供服务方面系统所应该提供的功能。

系统分解为一系列的关键抽象，（大多数）来自于问题域，表现为对象或对象类的形式。

它们采用抽象、封装和继承的原理。

分解并不仅仅是为了功能分析，而且用来识别遍布系统各个部分的通用机制和设计元素。

我们使用Rational/Booch 方法来表示逻辑架构，借助于类图和类模板的手段。

类图用来显示一个类的集合和它们的逻辑关系：关联、使用、组合、继承等等。

相似的类可以划分成类集合。

类模板关注于单个类，它们强调主要的类操作，并且识别关键的对象特征。

如果需要定义对象的内部行为，则使用状态转换图或状态图来完成。

公共机制或服务可以在类功能（class utilities）中定义。

对于数据驱动程度高的应用程序，可以使用其他形式的逻辑视图，例如E-R 图，来代替面向对象的方法（OO approach）。

图2 逻辑视图表示符号开发架构开发架构关注软件开发环境下实际模块的组织。

软件打包成小的程序块（程序库或子系统），它们可以由一位或几位开发人员来开发。

子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。

系统的开发架构用模块和子系统图来表达，显示了"输出"和"输入"关系。

完整的开发架构只有当所有软件元素被识别后才能加以描述。

但是，可以列出控制开发架构的规则：分块、分组和可见性。

图3 开发视图的标识符号进程架构进程架构考虑一些非功能性的需求，如性能和可用性。

它解决并发性、分布性、系统完整性、容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合在一起－即在哪个控制线程上，对象的操作被实际执行。

进程架构可以在几种层次的抽象上进行描述，每个层次针对不同的问题。

在最高的层次上，进程架构可以视为一组独立执行的通信程序（叫作"processes"）的逻辑网络，它们分布在整个一组硬件资源上，这些资源通过LAN 或者WAN 连接起来。

多个逻辑网络可能同时并存，共享相同的物理资源。

例如，独立的逻辑网络可能用于支持离线系统与在线系统的分离，或者支持软件的模拟版本和测试版本的共存。

图4 进程视图的标识符号物理架构物理架构主要关注系统非功能性的需求，如可用性、可靠性（容错性），性能（吞吐量）和可伸缩性。

软件在计算机网络或处理节点上运行，被识别的各种元素（网络、过程、任务和对象），需要被映射至不同的节点；我们希望使用不同的物理配置：一些用于开发和测试，另外一些则用于不同地点和不同客户的部署。

因此软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。

图5 物理视图的标识符号场景架构四种视图的元素通过数量比较少的一组重要场景（更常见的是用例）进行无缝协同工作，我们为场景描述相应的脚本（对象之间和过程之间的交互序列）。

在某种意义上场景是最重要的需求抽象，它们的设计使用对象场景图和对象交互图来表示。

该视图是其他视图的冗余（因此"＋1"），但它起到了两个作用：●作为一项驱动因素来发现架构设计过程中的架构元素。

●作为架构设计结束后的一项验证和说明功能，既以视图的角度来说明又作为架构原型测试的出发点。

场景表示法与组件逻辑视图非常相似（请对照图2），但它使用过程视图的连接符来表示对象之间的交互（请对照图4），注意对象实例使用实线来表达。

管道过滤器风格软件架构在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。

这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。

因此，这里的构件被称为过滤器，这种风格的连接件就象是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。

此风格特别重要的过滤器必须是独立的实体，它不能与其它的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。

一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。

图6 管道过滤器体系结构图7 数字通信系统粗略模型管道/过滤器风格的软件体系结构具有许多很好的特点：➢使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；➢允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；➢支持软件重用。

重要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；➢系统维护和增强系统性能简单。

新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；➢允许对一些如吞吐量、死锁等属性的分析；➢支持并行执行。

每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。

但是，这样的系统也存在着若干不利因素。

➢通常导致进程成为批处理的结构。

这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。

➢不适合处理交互的应用。

当需要增量地显示改变时，这个问题尤为严重。

➢因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

层次风格软件架构层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。

在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。

这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）。

连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。

这种风格支持基于可增加抽象层的设计。

这样，允许将一个复杂问题分解成一个增量步骤序列的实现。

由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持。

图8是层次系统风格的示意图。

层次系统最广泛的应用是分层通信协议。

在这一应用领域中，每一层提供一个抽象的功能，作为上层通信的基础。

较低的层次定义低层的交互，最低层通常只定义硬件物理连接。

图8 层次系统体系结构层次系统有许多可取的属性：➢支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；➢支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层；➢支持重用。