软件设计ZhouSu第6章体系结构的模式与结构.ppt

软件体系结构与设计,浙江大学城市学院 周苏 教授 QQ：81505050,第6章 体系结构的模式与结构,第6章 体系结构的模式与结构,软件工程中的设计 设计过程 关注点分离 关于设计的概念 设计模型,在工程领域中，基于模式和设计风格的开发方式使用得非常普遍。一个设计良好的通用模式是工程领域中技术成熟的标志之一。,第6章 体系结构的模式与结构,软件体系结构是有关软件系统如何组织的描述。系统的性质，比如性能、信息安全性和可用性，都受到所使用体系结构的影响。软件工程师可以在给定的体系结构类型中使用许多种不同的体系结构风格和模式，每个模式描述了一个系统类别，它包含：一组完成系统所需功能的构件；一组使构件间通信、协调及合作的连接件；定义如何集成构件以构成系统的约束条件；使设计者能够理解系统整体特性的语义模型。,第6章 体系结构的模式与结构,6.1 体系结构视图,在单个体系结构模型中不可能提出所有与系统体系结构相关的信息，因为每一种模型只能显示系统的一种角度和视图。通常体系结构可能会从许多不同的视角和视图被文档化，我们需要提供系统体系结构的多重视图。,6.1 体系结构视图,4种基础的体系结构视图是： 1）逻辑视图。显示了系统中对象和对象类的一些主要抽象。通过逻辑视图，可以将系统需求和实体关联起来。 2）进程视图。显示了在运行时系统是如何组织为一组交互的进程。这种视图对非功能系统特征的判断非常有效，比如性能和可用性。 3）开发视图。显示了软件是如何为了开发而被分解的，即将软件分解成可以由单独的开发人员或开发团队实现的组件。这种视图主要用于软件的管理者和程序员。 4）物理视图。显示了系统硬件和系统中软件组件是如何分布在处理器上的。这种视图对系统工程师规划系统部署非常有用。,6.1 体系结构视图,在使用类似视图的基础上还要添加概念视图。概念视图是系统的抽象视图，它可以作为把高层次需求分解为详细描述的基础，来帮助工程师在可复用的组件、表现产品线而不是单独的系统等方面做出决策。图6-1所描述的打包机器人的体系结构就是概念性系统视图的一个例子。该图显示了一个打包机器人系统体系结构的抽象模型，描述了所要开发的子系统。,图6-1 打包机器人控制系统的体系结构,6.1 体系结构视图,这个机器人系统能够对不同类型的对象进行打包，它使用一个视觉子系统来拾取传送带上的对象，识别对象类型并选择正确的打包方式，然后从传送带上移下对象、打包，最后将其送到另一个传送带上。体系结构模型描述了这些组件以及它们之间的关联。,6.1 体系结构视图,实际上，在设计过程中通常都会形成概念视图，它对体系结构的决策很有帮助。概念视图给出系统的本质内容供不同的信息持有者之间交流。在设计过程中，当讨论系统的不同方面时也可能会形成一些其他的视图，但是包含各个角度的完全描述是没有必要的。 关于软件体系结构是否应该使用UML来描述有不同的看法。设计UML是为了描述面向对象系统，在体系结构设计阶段，我们常常要以更高层次的抽象化来描述系统。当需要详细地文档化一个体系结构或使用模型驱动开发的时候，UML是非常有价值的。,6.1 体系结构视图,还可以使用专门的体系结构描述语言（ADL）来描述系统体系结构。ADL语言的基本要素是组件和连接器，这类语言包含了形成规范化体系结构所应该使用的规则和指南。不过，由于它的专业性，领域和应用专家很难理解和使用ADL。ADL语言是为特定领域设计的（例如，汽车系统），或许可以作为模型驱动开发的基础。尽管如此，像UML这种非正式的模型和符号系统是文档化系统体系结构最普遍使用的方法。,6.1 体系结构视图,大多数系统是不值得开发一个详细的体系结构描述的。应当开发出这种视图，它有益于沟通而不在乎体系结构文档是否完整。不过，例外的情况是，当正在开发关键性系统，当需要做一个详细的系统可依赖性分析时，或许需要使外部的管理者确定我们的系统符合他们的规则而且可能会需要完整的体系结构文档。,6.2 体系结构类型,尽管体系结构设计的基本原则适用于所有类型（也称为应用领域）的体系结构，但对于需要构建的结构，体系结构类型经常规定特定的体系结构方法。在体系结构设计环境中，“类型”隐含了在整个软件领域中的一个特定类别。在每种类别中，会有很多的子类别。例如，在建筑物类型中，会有房子、单元楼、公寓、办公楼、工厂厂房、仓库等一般风格。在每种一般风格中，也会运用更多的具体风格，即结构。每种风格的结构可以用一组可预测模式进行描述。,6.2 体系结构类型,例如，可以有以下几种软件系统的体系结构类型： 人工智能模拟或扩大人类认知、运动或其他有机体过程的系统。 商业和非盈利的工商企业营运必要的系统。 通信用于数据传输和数据管理、数据的用户连接或者数据展示的基础设施的系统。 内容创作用来创建或管理文字或多媒体人造物品的系统。 设备与物理世界交互的系统，可以为个人提供某种有意义的服务。 娱乐与运动管理公众事件或者提供大众娱乐体验的系统。,6.2 体系结构类型,金融为转账和理财以及其他安全事务提供基础设施的系统。 游戏为个人或群体提供娱乐体验的系统。 行政管理支持各级政治实体的管理和运作方式的系统。 工业模拟或控制物理过程的系统。 法律支持法律的系统。 医疗诊断或治疗，或者有助于医学研究的系统。 军事用于商议、通信、指挥、控制和信息的系统，也有用于进攻和防卫武器的系统。 操作系统位于硬件之上提供基本软件服务的系统。 平台位于操作系统之上提供高级服务的系统。,6.2 体系结构类型,科学用于科学研究和应用的系统。 工具用来开发其他系统的系统。 运输控制水上、地面、空中或者太空交通工具的系统。 实用程序与其他软件交互作用的系统，可以提供某些有意义的服务。,6.2 体系结构类型,从体系结构设计的立场看，每一种类型表述了一个特有问题。考虑一个游戏系统的软件体系结构，游戏系统有时被称作沉浸式交互应用（immersive interactive application) ，它需要密集型算法的计算方法、成熟的计算机图形图像技术、流媒体数据源、通过常规或非常规输入进行的实时的交互操作以及许多其他专业知识。,6.2 体系结构类型,例如，一种可应用于游戏环境的immersipresence软件体系结构描述如下： immersipresence软件体系结构（Software Architecture for Immersipresence, SAI）是一种新的体系结构模型，用于设计、分析和实现执行一般数据流的分布式、异步并行处理的应用系统。SAI的目标是为算法的分布式实施和容易地将其集成到复杂系统提供通用框架底层可扩展数据模型和混合（共享存储和信息传递）分布式异步并行处理模型允许自然和有效地处理一般数据流，并可以使用已有的库或本地代码。类型模块化使得分布式代码开发、测试和重用以及快速系统设计与集成、维护和演化更加便利。,6.2 体系结构类型,可见，游戏系统类型可以用专门设计的强调游戏系统关注点的体系结构风格来描述。 表6-1描述了MVC（模型-视图-控制器）模式。在许多基于Web的系统中，这种模式是交互管理的基础。这种格式化的模式描述包括模式的名字，一个简短的描述（伴有一个相关的图形模型），以及一个这种模式适用的系统类型的例子（可能也伴有一个图形模型）。此外，还应该包括这种模式的应用时机和优缺点。,表6-1 MVC（模型-视图-控制器）模式,6.2 体系结构类型,图6-2和图6-3显示了与MVC模式相关的体系结构的图形模型，它们从不同的角度展现体系结构图6-2是概念视图，而图6-3则给出了当该模式用于基于Web系统交互管理时的一个可能的体系结构。,图6-2 MVC模式的组成,图6-3 采用MVC模式的Web应用体系结构,6.3 体系结构的风格与模式,作为一种表示、共享和复用软件系统知识的方法模式的思想，已经得到广泛的应用，例如面向对象设计模式、机构设计模式、可用性模式、交互模式、配置管理模式等。体系结构模式在20世纪90年代以“体系结构风格”的名字提出来。,6.3.1 风格与模式,体系结构风格（Architecture styles）强调组织模式，是描述特定系统组织方式的惯用范例。组织模式即静态表述的样例，惯用范例则是反映众多系统共有的结构和语义。通常，体系结构风格独立于实际问题，强调了软件系统中通用的组织结构，比如管道线，分层系统，客户机-服务器等等，体系结构风格以这些组织结构定义了一类系统族。,6.3.1 风格与模式,体系结构模式是复用和通用系统体系结构知识的一种方法。可以把体系结构模式看作是对好的实践所做的格式化的抽象描述，它们已经在不同的系统和环境中多次尝试和测试过。所以，体系结构模式应当描述一种系统构成，这种构成在以往的系统中是很成功的。体系结构模式还应该包括：这种模式什么时候适用，什么时候不适用，以及这种模式的优点和缺点等。,6.3.1 风格与模式,软件体系结构设计的特点之一，是使用系统组织惯用模式（idiomatic patterns）。随着系统设计人员对详细的组织原则和某类软件结构价值的认识不断加深，这些惯用模式（或称体系结构模式）被逐渐总结出来。通过熟悉一些体系结构风格，可以了解软件体系结构丰富的选择空间以及在这个基础上对风格选择的一些权衡。,6.3.1 风格与模式,体系结构的术语一般与特定的设计方法和符号相关，比如面向对象和数据流组织结构。某些体系结构模式和一些特殊类型的系统相关，比如编译器的传统组织结构，国际标准化组织的公共系统连接参考模型和面向对象设计通用模式。,6.3.1 风格与模式,从更详细的层面上，为了分清不同模式间的差异，需要有一个公共的框架以便对这些模式进行比较。我们将采用的框架是把某个特定系统的体系结构看成计算构件集，或者简单地说，由构件再加上描述构件间交互的连接件组成。构件如客户机、服务器、过滤器、层、数据库等，连接件如过程调用、事件广播、数据库协议和管道等。,6.3.1 风格与模式,因此，一个体系结构风格根据结构组织模式定义了一个系统族。更明确地说，一个体系结构风格定义了构件和连接件类型的符号集，以及规定它们怎样组合起来的约束集合。对于很多风格来说，也可能存在一个或多个语义模型，其中规定了怎样从系统的各部分属性来确定系统的总体属性。,6.3.1 风格与模式,利用这个框架，我们可以通过回答下面的问题以确定体系结构风格，即： 设计符号集，即构件和连接件的类型是什么？ 被认可的结构模式是什么？ 根本的计算模型是什么？ 最基本的特点是什么？ 使用这种风格的通用例子有哪些？ 使用这种风格有什么优点和缺点？ 通用的规格说明是什么？,6.3.1 风格与模式,例如，当建筑师用“小高层”来描述某座房子时，大多数人将能够获得对房子的整体画面，对建筑主平面图可能像什么样子也会有所了解。建筑师使用体系结构风格作为描述手段，将该房子和其他风格（例如，公寓、别墅等）的房子区分开来。但更重要的是，体系结构风格也是建筑的样板。必须进一步规定房子的细节，具体说明它的最终尺寸，进一步给出定制的特征，确定建筑材料等。实际上是建筑风格“小高层”指导了建筑师的工作。,6.3.1 风格与模式,为基于计算机的系统构造的软件也展示了众多体系结构风格中的一种。每种风格描述一种系统类别，包括： l）完成系统需要的某种功能的一组构件（例如，数据库、计算模块）； 2）能使构件间实现“通信、合作和协调”的一组连接件； 3）定义构件如何集成为系统的约束； 4）语义模型，能使设计者通过分析系统组成成分的已知属性来理解系统的整体性质。,6.3.1 风格与模式,一种体系结构风格就是施加在整个系统设计上的一种变换，目的是为系统的所有构件建立一个结构。在对已有体系结构再工程时，一种体系结构风格的强制采用会导致软件结构的根本性改变，包括对构件功能的再分配。,6.3.1 风格与模式,与体系结构风格一样，体系结构模式也对体系结构设计施加一种变换。然而，体系结构模式与体系结构风格在许多基本方面存在不同： l）模式涉及的范围要小一些，它更多集中在体系结构的某一方面而不是体系结构的整体； 2）模式在体系结构上施加规则，描述了软件是如何在基础设施层次（例如，并发）上处理某些功能性方面的问题。 3）体系结构模式倾向于在体系结构环境中处理特定的行为问题（例如，实时应用系统如何处理同步和中断）。 模式可以与体系结构风格结合起来建立整个系统结构的外形。,6.3.2 基本体系结构,本质上软件体系结构表示了一种结构，在该结构中，某个实体集（经常称作构件）通过一组已定义的关系（经常称作连接件）进行连接。无论是构件还是连接件，它们都与一组特性相关，这组特性使设计者能够区别所使用的构件和连接件的类型。,6.3.2 基本体系结构,5种典型的基本体系结构（构件、连接件和特性）是： 功能结构：构件表示功能或处理实体，连接件表示接口，它提供“使用”构件或“传递数据到”构件的功能。特性描述构件的特征和接口的组织。 实现结构：“构件可以是包、类、对象、过程函数方法等所有在不同抽象层上打包的功能”。连接件包括传递数据和控制、共享数据、“使用”以及“是一个实例”等能力。特性关注于结构实现时的质量特征（例如，可维护性、可重用性）。 并发结构：构件表示“并发单元”，这些“并发单元”被组织为并行任务或线程。“关系（连接件）包括同步于、优先级高于、发送数据到、运行必须有、运行不能有。与结构相关的特性包括优先级、抢先占有以及执行时间”。,6.3.2 基本体系结构,物理结构：物理结构类似于设计开发中的部署模型，构件是物理硬件，软件驻留在硬件、上。连接件是硬件构件之间的接口，特性用来描述容量、带宽、性能和其他属性。 开发结构：该结构定义构件、工作产品以及软件工程过程中所需的其他信息源。连接件表示工作产品之间的关系，特性标识每项的特征。 每一种结构表示体系结构的不同视图，显示出进行建模和构建时对软件团队的有用信息。,6.3.3 组织和求精,由于设计过程经常会留下许多种可供选择的体系结构方案，因此建立一组用于评估所导出的体系结构设计的设计标准是非常重要的。下面的问题有助于更深入地了解体系结构风格： 控制。在体系结构中如何管理控制？是否存在清楚的控制层次？如果存在，构件在控制层次中有什么作用？构件如何在系统中传递控制？构件间如何共享控制？控制的拓扑结构（即控制呈现的几何形状）如何？控制是否同步或者构件操作是否异步？,6.3.3 组织和求精,数据。构件间如何进行数据通信？数据流是否是连续地传递给系统，或数据对象是否是零散地传递给系统？数据传递的模式是什么（即，数据是从一个构件传递到另一个构件，还是数据被系统中的构件全局共享）？是否存在数据构件（如黑板或中心存储库）？如果存在，它们的作用是什么？功能构件如何和数据构件交互？数据构件是被动的还是主动的（即数据构件是否主动地和系统的其他构件交互）？数据和控制如何在系统中交互？ 这些问题有助于设计者对设计质量进行早期评估，也为更详细地分析体系结构奠定了基础。,6.4 典型的体系结构模式,尽管在过去的几十年中人们已经创建了众多的计算机系统，但其中绝大多数都可以归为少数几种体系结构风格之一。应用较多的体系结构模式有：MVC（模型-视图-控制器）、批处理序列、管道-过滤器（数据流）、调用和返回、主程序和子程序、面向对象系统、多级分层、客户机-服务器、独立构件、通信进程、事件系统、虚拟机、解释器、基于规则系统、数据中心系统（知识库、黑板、容器）、数据库、超文本系统、过程控制。,6.4 典型的体系结构模式,这些体系结构风格也仅仅是可用风格中的一小部分。一旦需求工程揭示了待构建系统的特征和约束，就可以选择最适合这些特征和约束的体系结构风格和（或）风格的组合。在很多情况下，会有多种模式是适合的，需要对可选的体系结构风格进行设计和评估。,6.4.1 管道-过滤器,管道-过滤器（Pipes and Filters）体系结构模式（见表6-2和图6-4）是一个系统运行时组织的模型，在这个模型中，函数转换处理输入并产生输出。数据从一个处理单元流到另一个处理单元，每经过一个单元就做一次变换。输入数据流经过这些变换直到转换为输出。这些转换可能顺序地或并行地执行，数据加工可以是一项一项地处理，也可以成批处理。,表6-2 管道-过滤器模式,图6-4 管道-过滤器模式（数据流体系结构）,图6-5 管道-过滤器模式的一个实例,6.4.1 管道-过滤器,“管道-过滤器”的名字最早出自Unix系统，Unix系统在链接进程时可能会用到“管道”，通过提供符号表示要连接的构件和提供运行时机制来实现管道，这些管道能从一个进程到另一个进程传递文本流。遵照这个模型，系统可以组合Unix命令、使用管道和Unix shell控制工具来实现。“过滤器”这个词很形象地描述了数据从输入到输出这样一个过程。,6.4.1 管道-过滤器,管道-过滤器模式又称数据流体系结构。当输入数据经过一系列的计算构件和操作构件的变换形成输出数据时，可以应用这种体系结构。管道-过滤器模式拥有一组称为过滤器（Filter）的构件，每个构件都有一组输入集和输出集。这些构件从输入源读入数据流，通过管道（Pipe）连接，管道将数据从一个构件传送到下一个构件，并在输出池产生输出数据流。,6.4.1 管道-过滤器,构件对输入流进行内部转换和增量计算，因此在输入数据流被全部处理之前，输出就已经开始了。每个过滤器独立于其上游和下游的构件而工作，要针对某种形式的数据输入产生某种特定形式的数据输出（到下一个过滤器）。然而，过滤器没有必要了解与之相邻的过滤器的工作。 管道-过滤器的通用结构如管线（Pipelines），限制系统的拓扑结构只能是过滤器的线性序列；有界管道（Bounded Pipes）限制了在管道中能容纳的数据量；类型定义管道（Typed Pipes）要求明确定义在两个过滤器间传输的数据类型。,6.4.1 管道-过滤器,另一个著名的管线系统例子是传统编译器，在这个管线系统中包括词法分析、句法分析、语义分析、代码生成阶段。 自从计算机被用于自动数据处理以来，数据流模型的多种形式就被广泛使用。当系统中每个过滤器作为一个单一实体处理输入数据，即对数据的转换是顺序进行时，就成了一个退化的管线结构，这时管道-过滤器模式就变成了批处理模型。,6.4.1 管道-过滤器,管道-过滤器系统有很多优点。首先，设计者可以将整个系统的输入、输出特性理解为各个过滤器功能的简单合成。第二，支持功能模块的重用：任意两个过滤器只要相互间所传输的数据格式上达成一致，就可以连接在一起。第三，系统容易维护和扩展：新的过滤器容易加入到系统中，旧的过滤器也可被改进的过滤器替换。第四，支持某些特定的分析，如吞吐量和死锁检测。最后，它具有天然的并发特性，每一个过滤器既可以独立的运行，也可以和其他过滤器并发执行。,6.4.1 管道-过滤器,但是管道-过滤器模式也有缺点。首先，这种系统往往导致处理过程的成批操作。虽然系统中的过滤器对数据采取增量的方式，但过滤器的独立性很强，这样设计者必须考虑每个过滤器完成从输入到输出的完整转换。此外，由于过滤器的传输特性，管道-过滤器模式通常不适合于交互性很强的应用。尤其是在系统需要逐步显示数据流变化的过程时，问题会变得更加难以解决，因为增量显示和过滤器的输出数据差距太大。,6.4.1 管道-过滤器,第二，维持两个相对独立但又存在某种关系的数据流之间的通信可能很困难。 第三，根据实际应用的要求，设计者也需要在数据传输时被迫使用底层公共命名，导致过滤器必须对输入、输出管道中的数据进行解析或反解析的额外工作。这样，降低了系统的效率，同时增加了编写过滤器本身的复杂性。,6.4.2 分层系统,分离性和独立性的概念是体系结构设计的基础，因为分离性和独立性使得变更得到局部化。分层体系结构模式是实现分离性和独立性的一个方式，表6-3和图6-6显示了这种模式。这里，一个分层系统（Layered Systems）按照层次结构组织，系统的功能被划分成几个独立的层次，每一层只依赖紧接的下一层所提供的服务和设施。定义的一系列不同层次各自完成其自身的操作，这些操作逐渐接近机器的指令集。在外层，构件完成建立用户界面的操作；在内层，构件完成建立操作系统接口的操作；中间层提供各种实用工具服务和应用软件功能。,表6-3 分层体系结构模式,图6-6 分层系统（分层体系结构）,6.4.2 分层系统,每一层向它的上层提供服务，同时它又是下层的客户。在某些分层系统中，内层只对其相邻的层和某些用于输出的函数是可见的，对其他外部的层是隐藏的。在这些系统中，构件在某些层中实现虚拟机。（在其他分层系统中，层次可能只是部分透明的。）连接件通过协议来定义，而协议规定了层次之间交互的方式，还限制了相邻层间的交互。,6.4.2 分层系统,这种体系结构模式最著名的例子就是分层通信协议。在这个应用中，在某种抽象程度上，每一层向其他层提供通讯基础。较低层定义较低层的交互，最底层通常通过硬件连接来定义。其他的应用领域包括数据库系统和操作系统。,6.4.2 分层系统,分层的方法支持系统的增量式开发。如一个层被开发完，该层提供的服务就可以被用户使用了。这个体系结构还是可改变的和可移植的。如果一层的接口被保留下来，这个层就能被另外的一个对等层替换。当一层的接口改变或增加了新设施的时候，只有毗邻的层受影响。因为分层系统的抽象机依赖的是内层中的抽象机，因此，转换到其他机器上实现是比较容易的，此时只有内部与具体机器相关的层需要重新实现以适应不同的操作系统或数据库。,6.4.2 分层系统,图6-7是一个分为4层的体系结构的例子。最底层包括了系统支持软件，比较典型的是数据库和操作系统支持。再上一层是应用程序层，包括与应用功能相关的组件、可以被其他应用组件利用的实用工具组件等。第三层与用户界面管理相关，并提供用户的身份验证和授权。最上层提供用户界面设施。当然，分层的数量是随意的。图6-7中的任何一层都可以分为两层或更多层。,图6-7 通用分层体系结构,6.4.2 分层系统,图6-8是分层体系结构模式应用于一个叫做LIBSYS的图书馆系统的示例，能够控制对一组大学图书馆中版权资料的电子访问。这个系统有5层，最底层是各个图书馆中独立的数据库。,图6-8 LIBSYS系统的体系结构,6.4.2 分层系统,分层系统有许多理想的性质。首先，它支持基于逐级抽象的系统设计。这就允许设计者将一个复杂的问题分解成一系列递增的步骤。第二，它支持扩展。和管线模式相比，由于分层系统每一层最多和上下两层交互，对于任意一层的功能的改变最多只影响其他两层。第三，它支持重用。像抽象数据类型一样，假如能够保证为相邻的层提供一致的接口，它允许系统中同一层的不同实现相互交换使用。这使得定义标准层接口成为可能，在此接口上可建立不同实现。（最好的例子是ISO的OSI模型和X Window System协议。）,6.4.2 分层系统,但是分层系统也有缺点，并不是所有的系统都容易用这种模式来构建。而且即使一个系统能够从逻辑上被构建成层次结构，出于对性能的考虑，也需要将逻辑上高层次的功能和相对低层次的实现结合起来。另外，定义一个合适的抽象层次可能会非常困难。特别是对于标准化的层次模型来说，尤其如此。比如，实际的通信协议体就很难映射到OSI框架中，因为其中许多协议跨多个层。,6.4.3 知识库（容器）,知识库（Repositories）模式又称容器（Repository）模式（见表6-4），是以数据为中心的体系结构。,表6-4 容器模式,图6-9 以数据为中心的体系结构,6.4.3 知识库（容器）,数据存储（如文件或数据库）驻留在这种体系结构的中心，其他构件会经常访问该数据存储，并对存储中的数据进行更新、增加、删除或者修改。图6-9描述了一种典型的以数据为中心的体系结构风格，其中，客户软件访问中心存储库。在某些情况下，数据存储库是被动的，也就是说，客户软件独立于数据的任何变化或其他客户软件的动作而访问数据。该方法的一个变种是将中心存储库变换成“黑板”，当客户感兴趣的数据发生变化时，它将通知客户软件。,6.4.3 知识库（容器）,大多数使用大量数据的系统都是围绕共享数据库或容器来组织的。因此，这个模型适合于数据是由一个组件产生而由其他组件使用的倩形。这种类型的系统例子包括指挥和控制系统、管理信息系统、CAD系统和软件的交互开发环境等。 图6-10说明了一个可能会用到容器的情形。该图显示了一个包含不同工具来支持模型驱动开发的IDE系统。在这个例子中，容器或许就是一个能跟踪软件变更并允许回滚到先前版本的版本控制环境。,图6-10 IDE系统的容器体系结构,6.4.3 知识库（容器）,把所有适合使用容器的工具组织起来是共享大量数据的一种高效方式。这就不需要显式地把数据从一个组件传送到另一个组件。然而，组件一定要围绕一个约定好了的容器数据模型运行。这不可避免地要在每个工具的特定需求之间做出妥协。若一个新组件的数据模型与该模型有冲突，那么要想将它集成到该系统中来就可能很困难。实际上，将容器分布到多台机器上可能是困难的。虽然从逻辑上讲将集中式容器分布到不同的机器上是可能的，但这样做会引起数据冗余和不一致性的问题。,6.4.3 知识库（容器）,如图6-10中所示，容器是被动的，对它的控制是组件的职责。另外一种方法源于人工智能，即使用所谓的“黑板”模型，当有特别的数据可用时，就会主动通报组件。在容器数据的结构组织得不是很好的时候，这个方法比较合适。到底激活哪个工具要视对数据的分析结果而定。,6.4.3 知识库（容器）,以数据为中心的体系结构促进了可集成性，也就是说，现有的构件可以被修改，而且新的客户构件可以加入到体系结构之中，而无需考虑其他的客户（因为客户构件是独立运作的）。另外，数据可以在客户间通过“黑板”机制传送（即黑板构件负责协调信息在客户间的传递），客户构件独立地执行过程。,6.4.3 知识库（容器）,通常知识库模式中有两个截然不同的功能构件：一个是中央数据结构构件，代表系统当前状态；另一个是一些相对独立的构件的集合，这些构件对中央数据存储进行操作。在不同的系统中，知识库和外部构件集合之间的交互方式存在很大的差异。 控制方式的选择将知识库风格分成了两种主要的子类。如果由输入流中事务触发系统相应的进程执行，这是传统的数据库型知识库。另一方面，如果由中心数据结构的当前状态触发系统相应的进程执行，称为黑板知识库。黑板体系结构的示意图如图6-11所示。,图6-11 黑板体系结构,6.4.3 知识库（容器）,黑板模型通常由三个部分组成： l）知识源：分离的，独立的，依赖于应用的知识包。知识源仅通过黑板进行交互。 2）黑板数据结构：问题求解状态数据，被组织成依赖于应用的层次结构。知识源不断修改黑板中的数据，直到问题得解。 3）控制器：完全由黑板的状态驱动。一旦黑板的状态使某个知识源可用，知识源就会适时地响应。 图6-11并没有显式地表示出控制构件，因为知识源的调用是通过黑板的状态激活的。因此实际的控制器或者它的实现可以在知识源中，也可以在黑板中，独立的模块中或者在它们的组合中。,6.4.3 知识库（容器）,黑板系统通常用在复杂信号处理解释上，比如语音和模式识别，也被用在其他的系统中，比如通过松散连接代理共享数据。,6.4.4 客户机-服务器,容器模式与系统的静态结构有关，但是不能展现出它的运行组织。表6-5描述了客户机-服务器模式。,表6-5 客户机-服务器模式,图6-12 电影资料库的客户机-服务器体系结构,6.4.4 客户机-服务器,一个采用客户机-服务器模式的系统是由一个服务集合和相关的服务器以及访问和使用这些服务的客户机组织起来的。这个模型的主要组成部分是： （1）一组给其他组件提供服务的服务器。包括：打印服务器，提供打印服务；文件服务器，提供文档管理服务；编译服务器，负责对程序的编译服务。 （2）一组向服务器请求服务的客户机。一个客户机程序通常有多个实例，可以在不同的计算机上并发执行。 （3）一个连接客户机和服务器的网络。绝大多数客户机-服务器系统实现为分布式系统，通过互联网的协议连接在一起。,6.4.4 客户机-服务器,客户机-服务器体系结构经常被认为是分布式系统体系结构，但是运行在分散服务器上的独立服务的逻辑模型可以在单个计算机上实现。此外，更重要的好处是分离性和独立性。服务和服务器可以改变而不会影响系统其他部分。,6.4.4 客户机-服务器,客户机必须知道可用的服务器的名字及它们所提供的服务。反之，服务器没有必要知道客户机的身份以及到底有多少客户机在访问它们的服务。客户机通过远程过程调用来获取服务器提供的服务，远程过程调用使用一个请求-回答协议，比如在WWW上使用的http协议。本质上，客户机向服务器提出请求，然后等待直到它收到回答为止。,6.4.4 客户机-服务器,图6-12所示是一个基于Web的提供电影和图片库的多用户系统。在这个系统中，有管理和放映不同类型媒体的多个服务器。视频信号需要快速、同步地传输，但分辨率相对较低。它们是以压缩的形式存储的，所以视频服务器需要对于各种不同的格式处理视频压缩和解压缩。静态图片必须保持高分辨率，所以将它们单独放在一个服务器上是比较妥当的。,6.4.4 客户机-服务器,要求目录能够支持各种查询，能与包含电影和视频片段的Web信息系统链接，并能与支持发售图片、电影和视频片段的电子商务系统保持链接。客户机程序只是对访问这些服务提供一个集成的用户界面（用Web浏览器构造）。,6.4.5 数据抽象和面向对象组织,在基于数据抽象和面向对象组织结构（Data Abstraction and Object-Oriented Organization）模式中，数据表示和相关的基本操作封装在抽象数据类型或对象中。这种模式的构件是对象（封装了数据和必须用于控制该数据的操作），或者也可称为抽象数据类型的实例，构件间通过信息传递进行通信与合作。这种模式有两个重要的方面： 对象维护自身表示的完整性（通常是通过保持其表示上的一些不变式来实现的）， 这种表示对其他对象是隐藏的。,6.4.5 数据抽象和面向对象组织,在这种描述中并没有提及继承。虽然对于系统中对象类型的定义，继承是一个非常重要的概念，但是它不具备直接的体系结构功能。特别是，因为它并没有定义系统中构件的交互关系，我们认为继承关系不是一种连接件。在体系结构范畴中，属性的继承并不只限制在对象中，也包括连接件，甚至体系结构风格。 抽象数据类型的使用，以及面向对象系统的使用己经非常普遍。一些系统允许“对象”是并发的任务；还有一些系统允许对象拥有多个接口。,6.4.5 数据抽象和面向对象组织,面向对象系统有很多众所周知的优点。由于对象对客户隐藏了实现的细节，所以可以在不影响其客户的情况下改变对象的实现。另外，由于把操作的数据和一组存取例程绑定在一起，使得设计者能够把问题分解成交互作用的代理集合。,6.4.5 数据抽象和面向对象组织,但是，面向对象系统最大的缺点是，当一个对象和其他对象交互（过程调用），它必须知道其他对象的标识。与此相反，例如，在管道-过滤器系统中，过滤器之间交互不需要知道系统中其他过滤器的存在。在面向对象系统中，每当一个对象的标识改变的时候，必须修改那些显式调用它的对象。在模块化语言中，当一个模块改变后需要修改每一个引用了这个模块的“导入”列表。这样做同样会有副作用：对象A使用了对象B，对象C也使用了对象B，则对象C对对象B的影响可能产生对对象A不可预料的副作用，反之亦然。,6.4.6实践驱动与隐式调用,在一个系统中，比如面向对象系统，构件接口提供了过程和函数的集合，典型的情况是，构件通过显式地调用这些例程来与其他构件交互。然而，还有另一种可供选择的集成技术，称为隐式调用（Implicit Invocation，或称响应集成、选择性广播等），这种模式起源于基于角色的系统、约束满足性检查、后台程序和包交换网络。,6.4.6实践驱动与隐式调用,隐式调用的思想是，不直接调用一个过程，而是发布或广播一个或多个事件。系统中的其他构件通过注册与一个事件关联起来的过程，来表示对某一个事件感兴趣。当这个事件发生时，系统本身会调用所有注册了这个事件的过程。这样一个事件的激发会导致其他模块中过程的隐式调用。比如在Field系统中，诸如编辑器和变量监视器等工具会注册调试器的中断点事件。,6.4.6实践驱动与隐式调用,当一个调试器停止在一个中断点上，它会发布一个事件，这个事件会使系统自动地调用那些已注册工具的相应过程。这些过程会使编辑器滚动到相应的代码行，或者重新显示被监视的变量的值。在这个方案中，调试器仅仅发布一个事件，但是它既不需要知道其他工具或动作是否和这个事件相关联，也不需要知道这个事件发布后它们将要做什么。,6.4.6实践驱动与隐式调用,从体系结构的角度说，隐式调用模式中的构件是模块，其接口不仅提供过程的集合（像抽象数据类型），也提供事件的集合。过程可能以一般的方式被调用，但构件可以将过程注册到与其相关联的系统事件中，这样，当事件发生时，过程会被间接调用。这种模式主要特点是事件发布者不知道哪些构件会受到事件的影响。因此，构件不能对事件的处理顺序，或者事件发生后的处理结果做任何假设。正因为这个原因，许多隐式调用系统也包括显式调用（比如，正常的过程调用），以此作为构件交互的补充。,6.4.6实践驱动与隐式调用,使用隐式调用机制的例子很多，比如，编程环境中的工具集成，数据库管理系统中的一致性约束，用户界面中数据表示与管理数据的应用程序的分离，语法导向的增量语义检查。 隐式调用对重用提供了很好的支持。通过注册一个系统事件，任何一个构件都可以很容易地引入到系统中来。第二个优点是隐式调用能够简化系统的演化。在不改变系统中其他构件接口的情况下，构件可以非常容易的被其他构件取代。,6.4.6实践驱动与隐式调用,隐式调用的主要缺点是构件放弃了自身对系统计算的控制。当一个构件发布一个事件，它不能保证其他构件会对其做出响应。即使它能够肯定该事件会被其他构件响应，它也不能依赖事件被处理的先后顺序。另一个问题涉及到数据交换。有时数据通过事件传递，但在某些情况下，事件系统必须依赖一个共享缓冲区，以便于数据的交换。这样，整体的性能和资源的管理可能成为关键性问题。最后，正确性验证也可能是个问题，因为发布事件的过程的具体含义与事件激发的上下文有关。这和传统的过程调用验证不同，当对调用功能行为进行验证时，传统的过程调用只需考虑过程前和过程后的条件。,6.4.7 解释器,一个解释器包括正在被解释执行的伪码和解释引擎本身。其中，伪码由需要被解释的源代码和解释引擎分析所得到的中间代码组成。而解释引擎包括语法、解释器的定义和解释器当前执行状态。这样一个解释器通常包括四个部分：完成解释工作的解释引擎，一个包含将被解释的伪码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构（见图6-13）。,图6-13 解释器,6.4.7 解释器,解释器模式通常用来构建虚拟机，以弥合程序语义所期望的与硬件提供的计算引擎之间的差距。例如，我们有时说一门编程语言提供了一个“Pascal虚拟机”。,6.4.8 过程控制,基于过程控制环路是另一个体系结构模式，这种模式在软件开发中并没有得到广泛认可；这种模式不像面向对象或功能设计那样以出现的某类构件为特征，控制环路的设计特点是不仅具有某类构件，还具有在构件间必须保持的特殊关系。,6.4.8 过程控制,持续的过程通过对输入和中间产物进行某些操作，将输入的材料转化成某些具有特殊属性的产物。系统状态（材料、设备设置等）可测属性的值称为过程变量，用来测量输出材料的过程变量称为过程被控变量。输入材料、中间产物和操作的属性通过过程变量来获得。尤其是，为了对过程做出调整，被控变量要与控制系统的某些属性联系起来，这些属性能够被控制系统改变（过程变量不能和程序变量混淆）。,6.4.8 过程控制,过程控制中的一些有用的定义包括： 过程变量：可测的过程属性：一些具体的过程变量需要被区分开来； 被控变量：一种过程变量，系统通过控制它的值来达到控制目标； 输入变量：一种过程变量，用来测量过程的输入。 操纵变量：一种过程变量，它的值能被控制器改变。 设定点：被控变量的期望值。 开环系统：在这种系统中，过程变量的相关信息不用于调整系统。,6.4.8 过程控制, 闭环系统：在这种系统中，通过过程变量中的信息调整过程变量，补偿过程变量和操作环境的变化。 反馈控制系统：被控变量是可测量的，并且使用测量的结果操作一个或更多的过程变量。 前馈控制系统：一些被控变量是可测量的，并且预期的干扰会被直接补偿，不需要等待被控变量的变化值被计算出来。 过程控制系统的目标是将过程输出的指定属性维持在一个（充分接近的）特定的参考值即设定点。如果输入是没有干扰的，过程是定义完整的，操作是完全可重复的，那么过程完全可以在没有监控的情况下自动运行。这样的一个过程称为开环系统（Open-loop System）。,6.4.8 过程控制,在实际过程控制中，开环系统的假设很少有效。通常，通过监测诸如温度、压力和流速这类属性，计算它们的值，再通过改变设备（比如气阀，加热器，冷却器）的设置，来控制过程。这样的系统称为闭环系统（Closed-loop System）。家庭自动调温器就是一个常见的例子：自动调温器中的气体温度被测量出，根据设定的期望温度（即设定点），控制炉子的开关。,6.4.9 主程序/子程序组织,传统的主程序/子程序组织结构模式将功能分解为一个控制层次，其中“主”程序调用一组程序构件，这些程序构件又去调用其他构件。图6-14描述了该类型的体系结构。很多系统的主要组织结构反映了所使用的编程语言的特点。对于一个没有模块化支持的语言，系统通常会被组织成一个主程序和一系列子程序的集合。主程序担当子程序的驱动器，为子程序提供一个控制环路，使子程序以某种次序顺序执行。主程序/子程序体系结构的构件分布在网络中的多台计算机上，则构成远程过程调用体系结构。,图6-14 主程序/子程序体系结构,6.4.9 主程序/子程序组织,此外，特定领域的软件体系结构（Domain-specific Software Architectures）是指为特定领域开发“参考”模型。这种体系结构提供一种被剪裁成应用程序族的组织结构，比如航空电子技术，命令和控制，汽车驾驶系统。将体系结构具体应用到某一特定领域中，能够增加结构的描述能力。在很多案例中，可执行系统就是从体系结构描述本身自动或半自动生成的。 状态转换系统（State Transition System）是指很多响应系统的通用组织结构。这些系统被定义成状态集合和指定的转换集合，转换将系统从一个状态转换到另一个状态。,6.5 应用框架,应用框架（Application Framework）是整个或部分系统的可重用设计，表现为一组抽象构件的集合以及构件实例间交互的方法。可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文（Context）关系。在很多情况下，框架通常以构件库的形式出现，但构件库只是框架的一个重要部分。,6.5 应用框架,框架的关键还在于框架内对象间的交互模式和控制流模式。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；框架可以用代码表示，也能直接执行或复用，而对模式而言只有实例才能用代码表示；设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应用领域，但同一模式却可适用于各种不同的应用。体系结构风格描述了软件系统的整体组织结构，它独立于实际问题。而设计模式和应用框架更加面向具体问题。,6.5 应用框架,体系结构风格、设计模式和应用框架的概念是基于不同的目的和出发点来讨论软件体系结构，它们之间的概念经常互相借鉴和引用。事实上，大多数系统都是由很多风格组合而成的。 一种组合方式是使用层次结构。一个系统构件被组织成某种体系结构风格，但它的内部结构可能是另一种完全不同的风格。连接件通常也能从层次上分解。比如，一个管道连接件内部运行起来好像是一个先进先出的队列，通过插入和移出操作访问。,6.5 应用框架,第二种组合风格的方式是允许单一构件使用复合的连接件。比如，一个构件可能通过它的接口访问知识库，但通过管道与系统中其他构件进行交互，又通过其他接口接受控制信息。（事实上，Unix管道-过滤器就是以这种方式组织的；文件系统充当知识库的角色，初始化转换器充当控制器的角色。）另一个例子是“active database”。这是一个知识库，它通过隐式调用来激活外部的构件。在这种组织结构中，外部构件通过注册与数据库建立联系，数据库通过这种联系自动地调用合适的工具。,6.5 应用框架,第三种组合方法是用完全不同的体系结构风格来阐述体系结构描述的一个角度。,6.6 应用体系结构,商业和机构的所有业务几乎都具有共性需要雇佣人员、开出发票、记账等。除了一般的业务功能之外，所有的电话公司都需要系统去连通线路、管理它们的网络、向客户开单据等。因此，这些业务所使用的应用系统也有很多共同点。这些共性导致了用来描述特殊类型软件系统的结构和组成的软件体系结构的发展。,6.6.1 体系结构的应用方式,应用体系结构封装了一类系统的基本特征。例如，在实时系统中就有不同系统类型的通用的体系结构模型，像数据采集系统或监控系统。尽管这些系统实例在细节上有所不同，但是当开发同一类型的新系统时，我们是可以复用通用体系结构架构的。应用系统体系结构的一般模型能帮助我们理解应用的运作，比较相同类型的应用，验证应用系统设计的有效性并能达到对大粒度组件的复用。,6.6.1 体系结构的应用方式,当开发新的系统时应用体系结构往往要重新实现，但是对大多数商务系统，应用的复用有可能不需要重新实现。例如出自SAP和Oracle公司的企业资源规划（ERP）系统以及为特殊应用所提供的垂直软件包（COTS），在这些系统中，我们可以发现存在一个通用的配置，通过调整它们来产生专门的业务应用。作为一个例子，供应链管理系统可以调整以面向不同类型的供应商、商品以及合同管理。,6.6.1 体系结构的应用方式,软件设计人员可以以多种方式来使用这些应用体系结构模型： 1）作为体系结构设计过程的一个起点。如果不熟悉正在开发的应用类型，可以将初始设计建立在一般体系结构基础上。当然，这些都必须针对被开发的专门系统进行特殊处理，但不管怎样，它们都是设计的一个很好的开始。 2）作为设计检查列表。如果已经为一个应用系统完成了系统体系结构设计，可以将它与一般应用体系结构进行比较，来检查自己的设计和一般体系结构是否一致。,6.6.1 体系结构的应用方式,3）作为对开发团队工作的组织方式。应用体系结构寻找系统体系结构的稳定的结构特征，而且，在很多情况下，是可能并行地开发这些的。可以分派任务给团队成员，在同一个体系结构框架下实现不同的组件。 4）作为评估组件以便复用的手段。如果拥有组件，就可以复用它。在希望复用时