《软件工程》第6章体系结构设计

    体系结构设计关注理解一个软件系统应当如何组织，以及设计该系统的整体结构。体系结构设计是设计和需求工程之间的关键性衔接环节，因为它会确定组成一个系统的主要结构构件以及它们之间的关系。体系结构设计过程的输出是一个体系结构模型，该模型描述系统如何被组织为一组相互通信的构件。

    在敏捷过程中，得到广泛认同的一点是，一个敏捷开发过程的早期阶段应该关注设计一个整体的系统体系结构。体系结构的增量开发通常都不会成功。根据变化重构构件通常相对容易。然而，重构体系结构却很昂贵，因为可能需要修改大部分系统构件以使它们能够适应体系结构的变化。

    在实践中，需求工程过程和体系结构设计过程之间存在显著的重叠。理想情况下，系统规格说明不应当包含任何设计信息。然而，这个设想是不现实的；因此，作为需求工程过程的一部分，要提出一个抽象的系统体系结构，其中将一组组的系统功能或特征与大规模的构件或子系统关联起来。

    可以在两个抽象层次上设计软件体系结构，分别称为小体系结构和大体系结构。

    1.小体系结构关注单个程序的体系结构。在这个层次上，我们关注单个的程序是如何被分解为构件的。

    2.大体系结构关注包括其他系统、程序和程序构件的复杂企业系统体系结构。这些企业系统可以分布在不同的计算机上，这些计算机可以由不同的公司拥有和管理。

    软件体系结构很重要，因为它会影响一个系统的性能、健壮性、分布性和可维护性。明确地设计并描述软件体系结构有以下3个好处：

    1.利益相关者交流。体系结构是一种可以作为许多不同利益相关者讨论的焦点的系统的高层表示。

    2.系统分析。在系统开发早期阶段明确系统的体系结构要求进行一些分析。

    3.大范围复用。体系结构模型是关于系统如何组织以及构件如何互操作的一个紧凑、可管理的描述。

    系统体系结构经常使用简单的框图进行非正式的建模。可以使用UML的构造型和构件图进行绘制，其中每一个方框表示一个构件。方框中的方框表示该构件被分解子构件。箭头表示数据和控制信号按照箭头的方向从一个构件传到另一个构件。

    程序的体系结构模型有如下两种不同的使用方式：

    1.作为一种鼓励对系统设计进行讨论的方式。一个系统的高层体系结构视图对于与系统利益相关者进行交流以及项目计划都很有用，利益相关者可以接受这种表示并理解系统的抽象视图。体系结构模型识别出了要开发的关键构件，从而使管理者可以开始分配人员规划这些系统的开发。

    2.作为一种文档化已经设计好的体系结构的方式。目的是产生一个显示系统中不同的构件、它们的接口以及连接关系的完整的系统模型，这样一种详细的体系结构描述使得对系统的理解和演化可以更容易。

    对于很多项目，框图是唯一的体系结构描述。理想情况下，如果要详细描述一个系统的体系结构，最好能使用一种更严格的软件体系结构描述的方法。显然，一个更加详细和完整的描述意味着对体系结构构件之间关系误解的可能性会降低，然而其相应的成本就会大大增加，在实践中无法判断待开发的系统使用严格定义体系结构的方法是否合算。

§6.1体系结构设计决策

    体系结构设计是一个创造性的过程，在这个过程中你会设计一个满足系统功能性和非功能性需求的系统组织结构。具体的体系结构设计过程取决于所开发的系统的类型、系统架构师的背景和经验，以及系统的特定需求，因此也并不存在公式化、形式化的体系结构设计过程。

    在体系结构设计过程中，系统架构师必须做出一系列深刻影响系统及其开发过程的结构决策：

    1.是否存在一个通用的应用体系结构可以用作所设计的系统的模板？

    2.系统将如何分布到各个硬件核或处理器上？

    3.可以使用什么体系结构模式或风格？

    4.用来组织系统的基本方法是什么？

    5.用什么样的策略来控制系统中的构件的运行？

    6.系统中的结构构件将如何分解为子构件？

    7.什么样的体系结构组织是实现系统的非功能性需求的最佳选择？

    8.系统的体系结构应当如何文档化？

    虽然每个软件系统都是独特的，但是同一个应用领域中的系统经常具有相似的、反映领域的基本概念的体系结构。当设计一个系统体系结构时，你必须确定你的系统和更广阔的应用类型有什么共性，确定来自这些应用体系结构中的知识有多少可以复用。

    对于嵌入式系统以及针对个人电脑和移动设备设计的应用，不需要为系统设计一个分布式体系结构。然而，大多数大型系统是分布式系统，其中系统软件分布在许多不同的计算机上。

    一个软件系统的体系结构可以基于特定的体系结构模式或风格。体系结构模式捕捉了一个在不同的软件系统中使用的体系结构的本质特性。在进行体系结构设计时，应当了解通用的模式、这些模式的适用场合、它们的优势和弱点。

    由于非功能性系统特性和软件体系结构的密切关系，体系结构风格和结构的选择应当根据系统的非功能性需求来确定。

   1.性能。如果性能是一个关键性需求，那么体系结构设计应当将关键性操作局部化到少量的构件中，尽量让这些构件部署在同一台计算机上而不要分布在网络上。

   2.信息安全。如果信息安全是一个关键性需求，那么应该使用一种层次化的体系结构组织，把最关键的资产放在最内层进行保护，并对这些层应用高级的信息安全确认。

   3.安全性。如果安全性是一个关键性需求，那么体系结构设计应该让安全性相关的操作集中在单个构件或少量构件中。

   4.可用性。如果可用性是一个关键性需求，那么体系结构设计应该包含冗余的构件以便在不停止系统的情况下可以更换或更新构件。

   5.可维护性。如果可维护性是一个关键性需求，那么系统体系结构设计应当使用容易改变的细粒度、自包含的构件。

   显然，上面这些体系结构之间存在潜在的冲突，在具体的系统体系结构设计时就必须要进行权衡折中：有时可以通过在系统的不同部分使用不同的体系结构模式或风格来实现权衡。

    评价一个体系结构很难，因为真正的体系结构评判标准是，系统在使用时能够在多大程度上满足它的功能性和非功能性需求。

§6.2体系结构视图

   此外，体系结构模型也可以用于设计的文档化，这样，体系结构可以作为更加详细的系统设计以及实现的基础。在单个图中表示出与一个系统的体系结构相关的所有信息是不可能的，因为一个图形化模型只能显示一个系统视图或视角。通常来说，需要从多个不同的视图来呈现软件体系结构。

    1.逻辑视图。这个视图将系统中的关键抽象显示为对象或对象类。

    2.进程视图。这个视图显示系统在运行时如何通过相互交互的进程来构成。

    3.开发视图。这个视图显示软件如何面向开发任务进行分解；也就是说，该视图显示了软件如何分解为由单个开发者或开发团队实现的构件。

    4.物理视图。这个视图显示系统硬件以及软件构件如何分布在系统中的处理器上。

    在实践中，一个系统体系结构的概念视图几乎总是在设计过程中开发。这些概念视图用于向利益相关者解释系统体系结构以及告知体系结构设计决策。在设计过程中，其他一些视图也可以在讨论系统的不同方面的时候进行开发，但是一般都不需要从所有的视角出发开发一个完整的描述。

    当使用UML描述一个软件系统的体系结构时，通常都是以一种非正式的方式进行应用的。而另有一些人提出，应使用更加专业化的体系结构描述语言（Architectural Description Language, ADL）来描述系统体系结构。体系结构描述语言的基本元素是构件和连接器，并且包含面向结构良好的体系结构的规则和指南。然而，由于体系结构描述语言是专家语言，领域和应用专家感觉很难理解和使用体系结构描述语言。

    与之对比的是敏捷方法的使用者，他们认为详细的设计文档通常都是没有用的，即开发这种文档是浪费时间。

§6.3体系结构模式

    将模式作为一种表示、分享、复用软件系统相关知识的思想已经在软件工程中的一系列领域中得到了采用。

    体系结构模式是在20世纪90年代提出的，最初被称为“体系结构风格”。可以将体系结构模式理解为对好的实践的一种风格化、抽象化的描述，这些实践已经在不同的系统和环境中进行了尝试和测试。因此，一个体系结构模式应当描述一种已经在此前的系统中得到成功应用的系统的组织。它应当包含何时适合以及何时不适合使用该模式，还应包含关于该模式的优缺点的详细描述等信息。

【例】模型—视图—控制器（MVC）模式

名称	MVC（模型—视图—控制器）
描述	将呈现和交互从系统数据中分离出来。系统被组织为3个相互交互的逻辑构件。模型（Model）构件管理系统数据以及相关的对这些数据的操作。视图（View）构件定义并管理数据呈现给用户的方式。控制器（Controller）构件管理用户界面（例如按键、鼠标点击等）并将这些交互传递给视图和模型。
例子	显示了一个使用MVC模式进行组织的基于Web的应用系统的体系结构
何时使用	当存在多种查看数据以及数据交互的方式时使用。也可在未来关于数据的交互和呈现的需求未知时使用
优点	允许数据独立于它的呈现方式进行变更，反之亦然。支持以不同的方式呈现同样的数据，在某一呈现方式中进行的修改可以在所有呈现方式中显示
缺点	当数据模型和交互比较简单时，可能包含额外的代码以及代码复杂性

这是该体系结构模式的“型”

    上表和上图所示是模型—视图—控制器的体系结构模式。该模式是许多基于Web的系统中交互管理的基础，并且得到了大多数语言框架的支持。这种风格化的描述包括一个模式名称、一段简要描述、一个图形化模型，以及一个使用了这种模式的系统的例子。（见下图）其中还应当包含关于该模式应该在何种情况下使用以及模式的优缺点的信息。

这是该体系结构模式的“值”

    6.3.1分层体系结构

    分离和独立性的思想是体系结构设计的基础，因为这可以使变更被局部化。分层体系结构模式是另一种实现分离和独立性的方式。系统功能被组织为多个分离的层次，每个层次只依赖于紧邻的下一层所提供的设施和服务。

    这一分层的方法支持系统的增量开发。一个层次开发好之后，该层次所提供的一些服务可以提供给用户。该体系结构也是可变化和可前移的。如果接口不变，那么一个功能进行了扩展的新层可以在不影响系统的其他部分的情况下取代一个已有的层。而且，当一个层次的接口发生变化或者增加了新的设施时，只有相邻的层次受到影响。由于分层的系统将机器的依赖局部化了，这使提供一个应用系统的多平台实现变得更容易了。只需将与机器有依赖关系的层重新实现，便可以适应不同的操作系统或数据库的设施。

分层体系结构

名称	多层体系结构
描述	将系统组织为多个层次，每个层次与一些相关的功能相联系。每个层次向其上的一层提供服务，因此那些最低层次表示很可能在整个系统中使用的核心服务
例子	一个数字化学习系统的分层模型支持学校中所有科目的学习
何时使用	当在已有系统之上构建新的设施时使用；当开发涉及多个团队，每个团队负责一个层次上的功能时使用；当存在多个层次上的信息安全需求时使用
优点	只要接口保持不变，允许对整个层进行替换。可以在每个层次上提供冗余设施以增加系统的可依赖性
缺点	在实践中，将各层之间干净地分离经常很难做到，较高层次上的层可能不得不与较低层次上的层直接交互，而不是通过紧邻着的下一层。性能可能是一个问题，因为当一个服务请求在各个层次上进行处理时需要经过多层的解析

    6.3.2知识库体系结构

    知识库模式，则描述了一组相互交互的构件如何共享数据。大多数使用大量数据的系统都是围绕一个共享数据库或知识库组成的。因此，这个模型适合于数据由一个构件生成同时由另一个构件使用的应用。

知识库模式

名称	知识库
描述	一个系统中的所有数据在所有系统构件都能访问的中心知识库中进行管理。构件相互之间并不直接交互，仅通过知识库进行交互
例子	下图是一个集成开发环境（IDE）的例子，其中构件使用系统设计信息的知识库。每个软件工具生成的信息都会提供给其他工具使用
何时使用	当系统生成大量需要长时间保存的信息时应当使用这个模式。还可以在数据驱动的系统中使用，这类系统中的知识库中增加新数据时会触发一个动作或工具
优点	构件可以保持独立，它们不需要知道其他构件的存在；一个构件进行的修改可以被传播到所有构件；所有数据都可以一致地进行管理（例如同时进行备份），因为这些数据都位于一个地方
缺点	知识库可能存在单点失效问题，因此知识库中的问题会影响整个系统；通过知识库组织所有的通信可能效率不高；将知识库分布到多台计算机上可能比较困难

面向集成开发环境（IDE）的知识库体系结构

    围绕一个知识库组织工具是一个共享大量数据的有效方法。不需要显式地从一个构件向另一个构件传输数据。然而，构件必须围绕一个达成共识的知识库数据模型运转。这其中不可避免地要对每个工具的特定需要进行权衡，而且如果一个新构件与数据模型不相符，那么就可能很难甚至无法集成了。在实践中，可能很难将知识库分布到多台不同的机器上。虽然有可能实现一个逻辑上的集中知识库的分布式部署，这其中会涉及维护数据的多份拷贝。保证这些拷贝的一致性以及及时更新给系统增加了更多的额外负担。

    6.3.3客户-服务器体系结构

    知识库模式关注系统的静态结构，没有显示系统的运行时组织。【例】客户-服务器模式，描述了一种常用的分布式系统运行时的组织方式。一个遵循客户-服务器模式的系统被组织为一组服务和相关联的服务器，以及访问并使用服务的客户端。该模型的主要构件包括以下这些：

    1.一组向其他构件提供服务的服务器。服务器的例子包括：提供打印服务的打印服务器，提供文件管理服务的文件服务器，提供编程语言编译服务的编译服务器。服务器是软件构件，多个服务器可能运行在同一台计算机上。

    2.一组调用服务器提供的服务的客户端。通常会有一个客户端程序的多个实例并行运行在多台计算机上。

    3.一个允许客户端访问这些服务的网络。客户-服务器系统通常实现为分布式系统，使用互联网协议连接。

客户-服务器模式

名称	客户-服务器
描述	在客户-服务器体系结构中，系统被呈现为一组服务，其中每个服务都由一个独立的服务器提供。客户端是这些服务的用户，通过访问服务器来利用这些服务
例子	下图是一个组织成客户-服务器系统的电影和视频/DVD库的例子
何时使用	当一个共享数据库中的数据必须从一系列不同的位置进行访问时使用。因为服务器可以复制，因此也可以在一个系统的负载多变的情况下使用
优点	这种模型的主要优点是服务器可以分布在网络上。通用的功能（例如一个打印服务）可以向所有客户端开放使用，不需要由所有服务实现
缺点	每个服务都存在单点失效问题，因此容易受到拒绝服务攻击或服务器失效的影响；性能可能不可预测，因为这取决于网络以及系统；如果服务器属于不同的组织，那么还可能会出现管理问题

    客户-服务器体系结构通常被认为是分布式系统体系结构，但是运行在不同的服务器上的独立服务的逻辑模型可以被实现在单台计算机上。这里的一个重要优势仍然是分离和独立性。服务和服务器可以在不影响系统的其他部分的情况下被修改。

    客户端可能必须知道可用的服务器以及它们所提供的服务的名称。然而，服务器不需要知道客户端的身份或者有多少客户端正在访问它们的服务。客户端通过使用请求-应答协议的远程过程调用访问一个服务器提供的服务，其中客户端向一个服务器发出请求，并且一直等待直到收到来自服务器的应答。

    下图是一个基于客户-服务器模型的系统的例子，这是一个提供电影和照片库的多用户、基于Web的系统。

一个电影库的客户—服务器体系结构

    客户-服务器模型最重要的优势在于它是一个分布式体系结构。带有很多分布式处理器的网络化系统可以获得有效的使用。很容易增加一个新的服务器并将其与系统的剩余部分相集成，或者在不影响系统其他部分的情况下透明地升级服务器。

    6.3.4管道和过滤器体系结构

    这是一个通用体系结构的模型，其中功能性的变换处理输入并产生输出。数据从一个构件流动到另一个构件，在流经这个序列时进行变换。每个处理步骤被实现为一个变换。输入数据流经这些变换直到被转换为输出。这些变换可以串行或并行执行。每个变换可以一项项地处理数据，也可以在单个批次中一次性处理。

管道和过滤器模式

名称	管道和过滤器
描述	系统中的数据处理通过组织，每个处理构件（过滤器）可以分离开来并执行一种数据转换。数据从一个构件流动（就像在管道中一样）到另一个构件进行处理
例子	下图是一个用于处理发货单的管道和过滤器系统的例子
何时使用	在数据处理应用（无论是批处理还是基于事务）中得到了广泛应用，这类应用中输入在多个分离的阶段中进行处理，并最终生成相关的输出
优点	容易理解并且支持变换的复用；这种工作流风格与许多业务过程的结构相匹配；通过增加变换来进行演化是非常直观的；可以被实现为一个顺序系统或一个并发系统
缺点	针对数据转换的格式必须在相互通信的多个变换之间达成一致；每个变换必须解析它的输入，并将输出转换成所约定的形式，增加了系统的负担，同时可能意味着无法复用使用不兼容的数据结构的体系结构构件

一个管道和过滤器体系结构的例子

    【例】一个管道和过滤器体系结构的例子

    管道和过滤器最适合于用户交互很少的批处理系统和嵌入式系统。交互式系统很难使用管道和过滤器模型实现，因为管道和过滤器模型需要处理数据流。虽然简单的文本输入和输出可以用这种方式建模，但是对于图形化的用户界面、更复杂的输入/输出格式以及基于事件的控制策略，很难将这些实现为一种符合管道和过滤器模型的顺序流。

§6.4应用体系结构

    应用系统的目的是满足一个企业或者一个组织的需要。所有的企业都有很多共性：它们都需要雇人、开发货单、保存账户等。同属一个行业的企业使用通用的行业特定的应用。因此，与通用的企业功能一样，所有的电话公司都需要系统来连接呼叫和计费、管理他们的网络、向客户发出账单。因此，这些企业使用的应用系统同样有很多共性。

    这些共性促使人们去开发描述特定类型软件系统的结构合组织的软件体系结构。应用体系结构封装了一类系统的主要特性。应用体系结构可以在开发系统时重新实现，应用体系结构复用是隐式的。这一点在广泛使用的企业资源规划（Enterprise Resource Planning, ERP）系统以及可配置的成品应用系统中可以看到。这些系统有一个标准的体系结构以及相关的构件。这些构件可以通过配置和适应性调整来创建一个特定的企业应用。

    一个软件设计者可以通过以下这些不同的方式使用应用体系结构模型：

    1.作为体系结构设计过程的起点。如果你不熟悉你正在开发的应用类型，你可以将你的初始设计建立在一个通用的应用体系结构基础上。

    2.作为一个设计检查表。如果你已经为一个应用系统开发了一个体系结构设计，那么你可以将它与通用的应用体系结构相比较，检查你的设计是否与通用体系结构相一致。

    3.作为组织开发团队工作的一种方式。应用体系结构识别出了系统体系结构中稳定的结构特征，而且这些结构单元很多时候可以并行开发。

    4.作为评价构件复用的一种方式。如果你有一些可复用的构件，可以将它们与通用结构相比较，以确定应用体系结构中是否有与之相当的构件。

    5.作为谈论应用时的一种词汇表。如果你正在讨论一个特定的应用或者试图比较不同的应用，那么你可以使用通用体系结构中所识别的概念来讨论这些应用。

    存在许多类型的应用系统，有时候它们可能看上去很不一样。然而，表面上不一样的应用可能有很多共性，因此可以共享一个抽象应用体系结构。

【例】

    1.事务处理应用。事务处理应用是以数据库为中心的应用，处理用户的信息请求并且更新数据库中的信息。

    2.语言处理系统。语言处理系统中用户的意图用形式化语言来表达。

    6.4.1事务处理系统

    事务处理系统被设计用于处理用户获取数据库中信息的请求或者更新数据库的请求。从技术上看，一个数据库事务包含一个操作序列并且该序列作为整体处理。一个事物中的所有操作必须在数据库修改被持久化之前完成。这保证了一个事务中失败的操作不会导致数据库中的不一致。

    从用户的角度看，一个事务是任何满足一个目标的内聚的操作序列。如果用户事务不需要对数据库进行修改，那么不一定要将其作为一个技术上的数据库事务。

    事务处理系统通常是交互式系统，其中发出的异步的服务请求。下图描述了事务处理应用的概念体系结构。首先，用户通过一个输入/输出处理构件向系统发出请求。该请求由一些应用特定的逻辑进行处理。一个事务被创建并传递给事务管理器（通常嵌入在数据库管理系统中）。事务管理器在保证事务被正确完成后，再通知应用处理已完成。

事务处理应用的结构

    可将事务处理系统组织为含有负责输入、处理、输出的系统构件的“管道和过滤器”体系结构。

    6.4.2信息系统

    所有包含与一个共享数据库交互的系统都可以认为是基于事务的信息系统。一个信息系统允许对一个很大的信息库的受控访问。信息系统几乎都是基于Web的系统，其中用户界面在一个Web浏览器中实现。

    下图展示了一个非常通用的信息系统模型。系统使用层次化的方法进行建模，其中最顶层支持用户界面，最底层是系统数据库。用户通信层处理来自用户界面的所有输入和输出，信息检索包括特定应用的数据库访问和更新逻辑。这个模型中的各个层可以直接映射到一个分布式基于互联网的系统中的服务器上。

分层的信息系统体系结构

    可以通过识别支持用户通信以及信息检索和访问的构件，向这个模型的每一层都增加了一些细节。信息和资源管理系统有时候也是事务处理系统。这些系统中的服务器通常反映了上图所示的4层通用模型。这些系统经常实现为带有多层客户端/服务器体系结构的分布式系统。

    1.Web服务器负责所有的用户通信，并带有使用Web浏览器实现的用户界面。

    2.应用服务器负责实现特定应用逻辑以及信息存储和检索请求。

    3.数据库服务器将信息移动到数据库，从数据库中获取数据，同时处理事务管理

    使用多个服务器可以实现高吞吐量，使每分钟处理完成千上万的事务成为可能。随着请求量的增长，每个层次都可以增加服务器以应对所需要的额外处理能力。

    6.4.3语言处理系统

    语言处理系统将一种语言翻译为该语言的另一种表示方式，对于编程语言还可以执行所产生的代码。编译器将一种编程语言翻译为机器代码。其他语言处理系统可以将XML数据描述为数据库查询命令或者另一种XML表示形式。自然语言处理系统可以将一种自然语言翻译为另一种语言。

    一个面向编程语言的语言处理系统体系结构如下图所示。源语言指令定义了要执行的程序，一个翻译器将这些转换为面向抽象机器的指令。这些指令接着被另一个构件解析，该构件取出执行指令并且使用来自环境的数据执行这些指令。该过程的输出是解析输入数据中的指令的结果。

    对于许多编译器，解析器是处理机器指令的系统硬件，而抽象机器是真实的处理器。然而，对于动态类型语言，解析器是一个软件构件。

    作为更通用的编程环境的一部分的编程语言编译器具有一个通用体系结构，其中包括以下这些构件：

    1.一个词法分析器，读入输入语言标记符号，并将其砖混为一种内部形式。

    2.一个符号表，包含与所翻译的文本中使用的实体（变量、类名、对象名等）名称相关的信息。

    3.一个语法分析器，检查所翻译的语言的语法。它使用该语言所定义的语法，并且构造一个语法树。

    4.语法树，这是所编译的程序的一种内部表示结构。

    5.语义分析器，使用来自语法树的信息以及符号表来检查输入语言文本的语义正确性。

    6.代码生成器，遍历语法树并且生成抽象的机器代码。

    还可以包含其他对语法树进行分析和转换以提高效率并从所生成的机器代码中消除冗余的构件。在其他类型的语言处理系统中，还有一些附加的构件，例如字典。系统的输出是对输入文本的翻译。

    【例】下图描述了一个语言处理系统如何作为一个集成的编程支持工具集的一部分。

    其他体系结构模式也可以用于语言处理系统。编译器的实现可以将知识库模型和管道过滤器模型结合起来使用。在一个编译器体系结构中，符号表是一个共享数据的知识库。词法、语法和语义分析阶段以顺序化的方式进行组织，并且通过共享的符号表进行通信。

    这一语言编译的管道和过滤模型在批处理环境中很有效，其中程序的编译和执行都不需要与用户交互。然而，当一个编辑器与其他语言处理工具相集成时，该模型就没那么有效了。在这种情况下，更好的办法是围绕一个知识库来组织系统。