软件工程 教学课件 PPT 作者 郑人杰 马素霞 麻志毅 第11章 软件体系结构

《软件工程 教学课件 PPT 作者 郑人杰 马素霞 麻志毅 第11章 软件体系结构》由会员分享，可在线阅读，更多相关《软件工程 教学课件 PPT 作者 郑人杰 马素霞 麻志毅 第11章 软件体系结构（78页珍藏版）》请在金锄头文库上搜索。

1、第4部分 软件生存期模型与软件体系结构,第11章 软件体系结构,11.1 软件体系结构的基本概念,什么是体系结构 目前还没有一个公认的关于软件体系结构的定义，许多专家 学者从不同角度对软件体系结构进行了描述。Bass、 Clements和Kazman给出了如下定义：“一个程序或计算机 系统的软件体系结构是指系统的一个或者多个结构。结构中 包括软件的构件、构件的外部可见属性以及它们之间的相互 关系。外部可见属性则是指软件构件提供的服务、性能、使 用特性、错误处理、共享资源使用等。” 这一定义强调在任一体系结构表述中“软件构件”的角色。,Dewayne Perry和A1exander Wo1f曾这

2、样定义：“软件 体系结构是具有一定形式的结构化元素，即构件的集合，包 括处理构件、数据构件和连接构件。处理构件负责对数据进 行加工，数据构件是被加工的信息，连接构件把体系结构的 不同部分组合连接起来。” 这一定义注重区分处理构件、数据构件和连接构件。 虽然软件体系结构的定义在变化，但其意图是清晰的。 体系结构设计是一系列决策和基本原理的集合，这些决策的 目标在于开发高效的软件体系结构。在体系结构设计中所强 调的基本原理是系统的可理解性、可维护性和可扩展性。,11.1 软件体系结构的基本概念,1模式 软件设计模式是从软件设计过程中总结出来的，是针对 特定问题的解决方案。建筑师C.Alexande

3、r对模式给出的 经典定义是：每个模式都描述了一个在我们的环境中不断 出现的问题及该问题解决方案的核心。在软件系统中，可 以将模式划分为以下3类。 （1）体系结构模式（architectural pattern）：表达了软 件系统的基本结构组织形式或者结构方案，包含了一组预 定义的子系统，规定了这些子系统的责任，同时还提供了 用于组织和管理这些子系统的规则和向导。典型的体系结 构模式如OSI参考模型。,11.1 软件体系结构的基本概念,体系结构模式、风格和框架的概念,（2）设计模式（design pattern）：为软件系统的子系 统、构件或者构件之间的关系提供一个精炼之后的解决方 案，描述了在

4、特定环境下，用于解决通用软件设计问题的 构件以及这些构件相互通信时的各种结构。有代表性的设 计模式是Erich Gamma及其同事提出的23种设计模式。 （3）惯用法（idiom）：是与编程语言相关的低级模式， 描述如何实现构件的某些功能，或者利用编程语言的特性 来实现构件内部要素之间的通信功能。,11.1 软件体系结构的基本概念,2风格 风格是带有一种倾向性的模式。同一个问题可以有不同 的解决问题的方案或模式，但我们根据经验，通常会强烈 倾向于采用特定的模式，这就是风格。 每种风格描述一种系统范畴，该范畴包括： （1）一组构件（如数据库、计算模块）完成系统需要的某 种功能； （2）一组连接件

5、，它们能使构件间实现“通信”、“合作”和 “协调”； （3）约束，定义构件如何集成为一个系统； （4）语义模型，它能使设计者通过分析系统的构成成分的 性质来理解系统的整体性质。,11.1 软件体系结构的基本概念,体系结构风格定义了一个系统家族，即一个体系结构定 义一个词汇表和一组约束。词汇表中包含一些构件和连接 件类型，而这组约束指出系统是如何将这些构件和连接件 组合起来的。体系结构风格反映了领域中众多系统所共有 的结构和语义特性，并指导如何将各个模块和子系统有效 地组织成一个完整的系统。 对体系结构风格的研究和实践为大粒度的软件复用提供 了可能。,11.1 软件测试的基本概念,11.1 软件

6、测试的基本概念,3框架 随着应用的发展和完善，某些带有整体性的应用模式被 逐渐固定下来，形成特定的框架，包括基本构成元素和关 系。框架是特定应用领域问题的体系结构模式，框架定义 了基本构成单元和关系后，开发者就可以集中精力解决业 务逻辑问题。 在组织形式上，框架是一个待实例化的完整系统，定义 了软件系统的元素和关系，创建了基本的模块，定义了涉 及功能更改和扩充的插件位置。典型的框架例子有MFC框 架和Struts框架。,体系结构的重要作用体现在以下三个方面 ： （1）体系结构的表示有助于风险承担者（项目干系 人）进行交流。 （2）体系结构突出了早期设计决策。 （3）软件体系结构是可传递和可复用

7、的模型。,11.1 软件测试的基本概念,体系结构的重要作用,当输入数据经过一系列的计算和操作构件的变换形成输出 数据时，可以应用这种体系结构。管道/过滤器、批处理序 列都属于数据流风格。 管道/过滤器结构如下图所示。,11.2 典型的体系结构风格,数据流风格,管道/过滤器结构,从上图可看出，管道/过滤器结构拥有一组被称为过滤器（filter）的构件，这些构件通过管道（pipe）连接，管道将数据从一个构件传送到下一个构件。每个过滤器独立于其上游和下游的构件而工作，过滤器的设计要针对某种形式的数据输入，并且产生某种特定形式的数据输出。 如果数据流退化成为单线的变换，则称为批处理序列（batch s

8、equential）。这种结构接收一批数据，然后应用一系列连续的构件（过滤器）变换它。,11.2 典型的体系结构风格,管道/过滤器风格具有以下优点： （1）使得软构件具有良好的隐蔽性和高内聚、低耦合的特 点。 （2）允许设计者将整个系统的输入/输出行为看成是多个过 滤器的行为的简单合成。 （3）支持软件复用。只要提供适合在两个过滤器之间传送 的数据，任何两个过滤器都可被连接起来。 （4）系统维护和增强系统性能简单。新的过滤器可以添加 到现有系统中来；旧的可以被改进的过滤器替换掉。 （5）允许对一些如吞吐量、死锁等属性的分析。 （6）支持并行执行。每个过滤器是作为一个单独的任务完 成，因此可与其

9、他任务并行执行。,11.2 典型的体系结构风格,管道/过滤器风格主要缺点如下： （1）通常导致进程成为批处理的结构。这是因为虽然过滤 器可增量式地处理数据，但它们是独立的，所以设计者必须 将每个过滤器看成一个完整的从输入到输出的转换。 （2）不适合处理交互的应用。当需要增量地显示改变时， 这个问题尤为严重。 （3）因为在数据传输上没有通用的标准，每个过滤器都增 加了解析和合成数据的工作，这样就导致了系统性能下降， 并增加了编写过滤器的复杂性。,11.2 典型的体系结构风格,在此类体系结构中，存在以下3种子风格。 1主程序/子程序体系结构 这种传统的程序结构将功能分解为一个控制层次，其 中“主”

10、程序调用一组程序构件，这些程序构件又去调用别 的程序构件，如下图所示。这种结构总体上为树状结 构，可以在底层存在公共模块。,11.2 典型的体系结构风格,调用返回风格,主程序/子程序体系结构的优点如下: （1）可以使用自顶向下，逐步分解的方法得到体系结构 图，典型的拓扑结构为树状结构。基于定义使用关系对子 程序进行分解，使用过程调用作为程序之间的交互机制。 （2）采用程序设计语言支持的单线程控制。 其主要缺点如下: （3）子程序的正确性难于判断。需要运用层次推理来判断 子程序的正确性，因为子程序的正确性取决于它调用的子程 序的正确性。 （4）子系统的结构不清晰。通常可以将多个子程序合成为 模块

11、。,11.2 典型的体系结构风格,2面向对象风格 系统的构件封装了数据和必须应用到该数据上的操 作，构件间通过消息传递进行通信与合作。与主程序/子程 序的体系结构相比，面向对象风格中的对象交互会复杂一 些。面向对象风格与网络应用的需求在分布性、自治性、 协作性、演化性等方面具有内在的一致性。 面向对象风格具有以下优点: （1）因为对象对其他对象隐藏它的表示，所以可以改变一 个对象的表示，而不影响其他对象。 （2）设计者可将一些数据存取操作的问题分解成一些交互 的代理程序的集合。,11.2 典型的体系结构风格,其缺点如下: （1）为了使一个对象和另一个对象通过过程调用等进行 交互，必须知道对象的

12、标识。只要一个对象的标识 改变了，就必须修改所有其他明确调用它的对象。 （2）必须修改所有显式调用它的其他对象，并消除由此 带来的一些副作用。例如，如果A使用了对象B，C 也使用了对象B，那么，C对B的使用所造成的对A 的影响可能是料想不到的。,11.2 典型的体系结构风格,3层次结构 层次结构的基本结构如下图所示。在这种体系结构中，整 个系统被组织成一个分层结构，每一层为上层提供服务，并 作为下一层的客户。,11.2 典型的体系结构风格,这种风格支持基于可增加抽象层的设计。允许将复杂问 题分解成一个增量步骤序列的实现。由于每一层最多只影响 两层，同时只要给相邻层提供相同的接口，允许每层用不同

13、 的方法实现，同样为软件复用提供了强大的支持。 层次结构具有以下优点: （1）支持基于抽象程度递增的系统设计，使设计者可以把 一个复杂系统按递增的步骤进行分解。 （2）支持功能增强，因为每一层至多和相邻的上下层交 互，因此，功能的改变最多影响相邻的内外层。,11.2 典型的体系结构风格,（3）支持复用。只要提供的服务接口定义不变，同一层的 不同实现可以交换使用。这样，就可以定义一组标准 的接口，从而允许各种不同的实现方法。 其缺点如下: （1）并不是每个系统都可以很容易地划分为分层的模式， 甚至即使一个系统的逻辑结构是层次化的，出于对系 统性能的考虑，系统设计师不得不把一些低级或高级 的功能综

14、合起来。 （2）很难找到一个合适的、正确的层次抽象方法。,11.2 典型的体系结构风格,数据库系统、超文本系统 和黑板系统都属于仓库风 格。在这种风格中，数据 仓库（如文件或数据库） 位于这种体系结构的中心， 其他构件会经常访问该数 据仓库，并对仓库中的数 据进行增加、修改或删除 操作。右图为一个典型的 仓库风格的体系结构。,11.2 典型的体系结构风格,仓库风格,上图中,可把中心存储库变换成“黑板”，黑板构件负责协 调信息在客户间的传递，当用户感兴趣的数据发生变化时， 它将通知客户软件。黑板系统的组成如下图所示。黑板系统 的传统应用是信号处理领域，如语音和模式识别。另一应用 是松耦合代理数据

15、共享存取。,11.2 典型的体系结构风格,以上所讲的体系结构模型是通用的模型，除了这些通用的 模型以外，对于特定的应用还需要特定的体系结构模型。这 些体系结构模型称为领域相关的体系结构。有两种领域相关 的体系结构模型：类属模型（generic model）和参考模型 （reference model）。,11.3 特定领域的软件体系结构,类属模型,类属模型是从许多实际系统中抽象出来的一般模型，它封装了这些系统的主要特征。例如，许多图书馆开发了自己的图书馆馆藏/流通系统，若把它们的共同功能抽取出来并创建一个让所有图书馆都认可的系统体系结构模型，这就是类属模型。类属模型的一个最著名的例子是编译器模

16、型，由这个模型已开发出了数以千计的编译器。,参考模型源于对应用领域的研究，它描述了一个理想化的包含 了系统应具有的所有特征的软件体系结构。它是更抽象且是描述 一大类系统的模型，并且也是对设计者有关某类系统的一般结构 的指导，如Rockwell和Gera所提出的软件工厂参考模型。 以上两种不同类型的模型之间并不存在严格的区别，也可以将 类属模型视为参考模型。区别之一是类属模型可以直接在设计中 复用，而参考模型一般是用于领域概念间的交流和对可能的体系 结构做出比较。另外，类属模型通常是经过“自下而上”地对已有 系统的抽象，而参考模型是“由上到下”地产生的。它们都是抽象 系统表示法。,11.3 特定领域的软件体系结构,参考模型,分布式系统的一个最简单的模型是多处理器系统，系统由 许多进程组成，这些进程可以在不同的处理器上并行运行， 可以极大地提高系统的性能。 由于大型实时系统对响应时间要求较高，这种模型在大型 实时系统中比较常见。大型实时系统需要实时采集信息，并 利用采集到的信息进行决策，然后发送信号给执行机构。虽 然，信息采集、决策制定和执行控制这些进程