软件体系结构ppt课件

软件体系结构,刘兴 计算机学院软件工程系,1,软件体系结构内容,1概述 2软件体系结构风格 3案例研究 4软件体系结构的分析与评估（略） 5流行的软件体系结构 6设计模式与软件架构 7企业架构师和设计师、企业软件架构简介,2,1概述,我们要学的这个是什么玩意？ 我们为什么要学这个玩意？ 我们将来会怎么干？ 其他人是怎么玩的？,3,1概述,它是一种简单的、清楚的、完善的方式形成的 软件工程师需要一种更好的视角来理解软件，并试图找到一种新的方法来构建更复杂的大型软件系统 SA (software architecture) 一个简单程序到复杂系统软件的距离是十年,4,1概述需求开发的主要困难,5,1概述软件危机的原因,软件规模越来越大 随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确、有时还会产生误解。 软件项目开发人员不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。,6,1概述软件危机的原因,软件复杂度越来越高 软件不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。软件产品的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。 所谓“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前。,7,1.1what is SA ？,这种全局结构的设计和规划问题包括 全局组织结构；全局控制结构；通信和同步以及数据存取协议；规定设计元素的功能；设计元素的组合；物理分布；规模和性能；演化的维度；设计方案的选择等。 1随着软件系统的规模和复杂性不断增加，系统的全局结构的设计和规划变得比算法的选择以及数据结构的设计更加重要。 2人们普遍认为，为系统设计一个合适的体系结构是系统取得长远的成功的关键因素。 3非形式化的。,8,1.1what is SA ？,形式化还是非形式化 ： 首先，软件工程师在长期的实践中已经拥有了一套共享的，语义丰富的词典，它由软件系统的习惯用语，模式，软件系统组织结构风格组成。 通过识别一个管道过滤器体系结构风格的实例，一个软件工程师传达了这样的事实：这个系统的主要功能就是进行数据流的转换，系统的主要功能由各种独立实体的过滤器分别来实现，系统的响应时间和吞吐量能用一种直接的方式计算出来。,9,1.1what is SA ？,e.g. 每个Filter都有输入端和输出端，例如一个MPEG-1解码Filter它的输入是MPEG编码的流数据，它的输出端是一解码过的流数据。DirectShow正是通过将不同的Filter连接在一起完成特定的功能的，我们将这些Filter的连接叫做Filter Graph，如下图A给出是播放AVI的Filter Graph： 图A 播放AVI文件的Graph Filter图 上图中每个模块分别代表了不同的Filter，媒体文件Filter从硬盘读取AVI文件，AVI分离 Filter将文件分离为音频流和视频流，AVI解码Filter对视频流进行解码并送往Video表现Filter，由后者将各帧在显示器上显示，默认的DirectSound设备用DirectSound将音频流输出。,10,1.1what is SA ？,其次，体系结构的描述的作用好像一个框架，系统属性在这个框架下进行扩充，并且，它在考察一个系统实现其整体需求的能力中扮演了非常重要的作用。 （软件体系结构是非常抽象的，可以理解更大范围的，系统级的关注点，比如吞吐量，通信模式，执行控制结构，可伸缩性，以及系统演化的扩展方式，提供一个自然的框架。）,11,1.1what is SA ？,软件系统的体系结构定义系统由计算构件和构件之间的相互作用组成。构件可以是客户机和服务器、数据库、过滤器或者是在一个分层系统中的层。构件之间的相互作用在这个设计层次上可以是简单和相似的，比如过程调用，共享变量的访问。但是它们也可以是复杂和语义丰富的。比如客户机服务器协议（clientserver protocols）数据库存取协议（database-accessing protocols）,异步事件多点传送（asynchronous event multicast）和管道数据流（piped streams）,12,1.1what is SA ？,软件设计层次 体系结构级：系统性能与构件之间的整体联系。这个级别的构成元素是模块，模块通过各种方式互连，通过操作算子将子系统组装成一个系统。 代码级：这个级别的设计问题包括算法和数据结构；其构成元素是编程语言原语。 执行级：这个级别的设计问题包含存储器的映射、数据格式配置、堆栈和寄存器的分配。,13,软件各级抽象,高级程序设计语言,数据结构与算法,软件结构研究的开始,抽象数据类型,程序族,软件体系结构,汇编语言、宏替换、高级语言编译器、数据类型,程序数据结构算法,软件划分与构造、方便系统的开发与维护,数据类型抽象、封装、信息隐藏、多态性,程序族在信息隐藏和软件结构设计上具有相同的模式（设计模式抽象）,软件体系结构使系统在体系结构级达到重用,14,1.1定义,Dewayne Perry和A1exander Wo1f 软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。 处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组合连接起来。 这一定义注重区分处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基本上得到保持。,15,1.1定义,Mary Shaw和David Garlan 软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。 体系结构问题包括总体组织和全局控制、通讯协议、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。 软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通讯、同步与数据存取的协议，设计构件功能定义，物理分布与合成，设计方案的选择、评估与实现等。,16,Kruchten 软件体系结构有四个角度，它们从不同方面对系统进行描述：概念角度描述系统的主要构件及它们之间的关系；模块角度包含功能分解与层次结构；运行角度描述了一个系统的动态结构；代码角度描述了各种代码和库函数在开发环境中的组织。,17,Hayes Roth 软件体系结构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。,18,David Garlan 和 Dewne Perry 软件体系结构是一个程序系统各构件的结构、它们之间的相互关系以及进行设计的原则和随时间演化的指导方针。,19,Barry Boehm 软件体系结构包括一个软件和系统构件，互联及约束的集合；一个系统需求说明的集合；一个基本原理用以说明这一构件，互联和约束能够满足系统需求。,20,Bass，Ctements 和 Kazman 软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。其中，“软件外部的可见特性”是指软件构件提供的服务、性能、特性、错误处理、共享资源使用等。,21,1.2软件体系结构研究的内容和范畴,被解决的：模块接口语言，特定领域的软件体系结构，软件的重用，软件组织结构模式的规范化编纂，体系结构描述语言，体系结构设计形式化的支持和体系机构设计环境。 四个研究领域： 1.新的体系机构描述语言来解决体系机构描述问题。 2.体系结构领域知识的总结性研究。这个领域关心的是工程师通过软件实践总结而来的各种体系机构原则和模式的分类和阐释。 3.针对特定的领域的框架的研究。 4.软件体系结构形式化支持的研究。,22,1.2软件体系结构研究的内容和范畴,风格、设计模式、框架 1.体系结构风格（architecture styles） 体系结构风格独立于实际问题，强调了软件系统中通用的组织结构。比如管道线，分层系统，客户机服务器等等。,23,1.2软件体系结构研究的内容和范畴,风格、设计模式、框架 2.设计模式 设计模式是软件问题高效和成熟的设计模板，模板包含了固有问题的解决方案。设计模式可以看成规范了的小粒度的结构成分，并且独立于编程语言或编程范例。设计模式的应用对软件系统的基础结构没有什么影响，但可能对子系统的组织结构有较大影响。每个模式处理系统设计或实现一种特殊的重复出现的问题。它为解决抽象部分和实现部分独立变化的问题提供了一种通用结构。因此，设计模式更强调直接复用的程序结构。,24,1.2软件体系结构研究的内容和范畴,风格、设计模式、框架 3.应用框架（application framework） 应用框架是整个或部分系统的可重用设计，表现为一组抽象构件的集合以及构件实例间交互的方法。可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程。,25,1.2软件体系结构研究的内容和范畴,体系结构风格、设计模式和应用框架的概念是从不同的目的和出发点讨论软件体系结构，它们之间的概念经常互相借鉴和引用。,26,1.3体系结构设计原则,抽象 分而治之 封装和信息隐藏 模块化 高内聚和低耦合 关注点分离 策略和实现的分离 接口和实现的分离,27,1.3体系结构设计原则,体系结构是指软件系统的基本和主体的形态，也就是软件系统中“最本质”的东西。一个软件系统的体系结构设计得好不好，可以用“合适性、结构稳定性、可扩展性、可复用性”这些特征量来评估。,28,1.3体系结构设计原则,合适性：即体系结构是否适合于软件的“功能性需求”和“非功能性需求”。,设计师可以充分发挥主观能动性，根据需求的特征，通过推理和归纳的方法设计出合适的体系结构。经验不丰富的设计师往往把注意力集中在“功能性需求”而疏忽了“非功能性需求”，殊不知后者恰恰是最能体现设计水平的地方。 高水平的设计师高就高在“设计出恰好满足客户需求的软件，并且使开发方和客户方获取最大的利益，而不是不惜代价设计出最先进的软件。（以设计住宅为例） 对于软件系统而言，能够满足需求的设计方案可能有很多种，究竟该选哪一种？此时商业目标是决策依据，即选择能够为开发方和客户方带来最大利益的那个设计方案。大部分软件开发人员天生有使用新技术的倾向，而这种倾向对开发商业产品而言可能是不利的，切记切记,29,结构稳定性,当前中国有几句流行的至理名言：“稳定压倒一切”、“发展是硬道理”。发展的前提条件是稳定，社会如此，开发软件产品也是如此。 体系结构一旦设计完成，应当在一定的时间内保持稳定不变，只有这样才能使后续工作顺利开展。如果体系结构经常变动，那么建筑在体系结构之上的用户界面、数据库、模块、数据结构等等也跟着经常变动，用“树倒猢狲散”来比喻很恰当，这将导致项目发生混乱。 高水平的设计师应当能够分析需求文档，判断出哪些需求是稳定不变的，哪些需求是可能变动的。于是根据那些稳定不变的需求设计体系结构，而根据那些可变的需求设计软件的“可扩展性”。,30,可扩展性是指软件扩展新功能的容易程度。可扩展性越好，表示软件适应“变化”的能力越强。可扩展性越来越重要，这是由现代软件的商业模式决定的： 社会的商业越发达，需求变化就越快。 现代软件产品通常采用“增量开发模式”，开发商不断地推出软件产品的新版本，从而不断地获取增值利润。 稳定性和可扩展性之间存在辨证的关系：如果系统不可扩展的话，那么就没有发展前途，所以不能只关心稳定性而忽视可扩展性；而软件系统“可扩展”的前提条件是“保持结构稳定”，否则软件难以按计划开发出来，稳定性是使系统能够持续发展的基础。所以稳定性和可扩展性都是体系结构设计的要素。 如果每次变化都导致体系结构发生大的变动，那简直就是“伤筋动骨”，这样的体系结构无疑是败笔之作。（例如房屋装修）,31,复用就是指“重复利用已经存在的东西”。被复用的对象可以是有形的物体，也可以是无形的知识财富。复用不是人类懒惰的表现而是智慧的表现。因为人类总是在继承了前人的成果，不断加以利用、改进或创新后才会进步。 复用的有利于提高产品的质量、提高生产率和降低成本。由经验可知，通常在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具有高质量），而大量成熟的工作可以通过复用来快速实现（即具有高生产率）。勤劳并且聪明的人们应该把大部分的时间用在小比例的创新工作上，而把小部分的时间用在大比例的成熟工作中，这样才能把工作做得又快又好。,32,复用的意义很容易理解，人们也乐意复用以前的成果，但是前提条件是该成果具有比较好的可复用性。可复用性是指成果被复用的容易程度。 可复用性是设计出来的，而不是偶然碰到的。要使体系结构具有良好的可复用性，设计师应当分析应用域的共性问题，然后设计出一种通用的体系结构模式，这样的体系结构才可以被复用。,33,问题回答,架构师与设计师 企业软件架构 作业1：分组 大作业 作业2：准备,http:/en.wikipedia.org/wiki/Key_Word_in_Context,34,软件体系结构内容,1概述 2软件体系结构风格 3案例研究 4共享信息系统 5软件体系结构描述 6软件体系结构的分析与评估 7特定领域的软件体系结构 8流行的软件体系结构,35,2体系结构风格,惯用模式 我们的目的是展示软件体系结构丰富的选择空间，以及在这个基础上对风格选择的一些权衡。,36,2.1体系结构风格,数据流系统 虚拟机 批处理序列 解释器 管道和过滤器 基于规则系统 调用和返回系统 数据中心系统（知识库） 主程序和子程序 数据库 面向对象系统 超文本系统 多级分层 黑板 独立构件 通讯进程 事件系统,37,2.1体系结构风格,设计符号集即构件和连接件的类型是什么？ 被认可的结构模式是什么？ 根本的计算模型是什么？ 最基本的特点是什么？ 使用这种风格的通用例子有哪些？ 使用这种风格有什么优点和缺点 通用的规格说明是什么？,38,2.1体系结构风格,7种通用的风格 管道和过滤器、对象、隐式调用、层、知识库、解释器和过程调用。,39,构件对输入流进行内部转换和增量计算，在输入数据流全部处理之前，输出就已经开始了。 重要特点是每个filter必须是一个独立实体。特别是filter之间无需共享状态。,40,2.2管道过滤器（pipes &filters,典型的例子： Unix的shell中编写的程序通过提供的符号表示要连接的构件和提供运行时机制实现管道。 传统的编译器 ：词法分析、句法分析、词义分析、代码生成阶段 信号处理领域 并行计算 功能编程 分布式系统,41,2.2管道过滤器（pipes &filters,管道过滤器的优点： 设计者可以将整个系统的输入和输出特性理解为各个过滤器功能的简单合成。 支持功能模块的重用：只要相互传输的数据格式达成一致，就可以连接在一起。 系统容易维护和扩展：新的过滤器可以加进来，旧的可以被替换 支持某些特定的分析，如吞吐量和死锁检测 具有天然的并发特性，可以独立运行，也可以和其他过滤器并发执行。,42,2.2管道过滤器（pipes &filters,管道过滤器模式的缺点： 过滤器独立性强，处理过程成批处理，不适合交互性强的应用 维持两个相对独立但有不存在某种关系的数据流之间的通讯可能很困难。 根据实际应用的要求，设计者也需要在数据传输时被迫使用底层公共命名。增加过滤器本身的复杂性。,43,2.3数据抽象和面向对象组织结构,对象通过函数和过程调用来实现交互。这种模式有两个重要的方面： 对象维护自身表示的完整性（通常是通过保持其表示上的一些不变式来实现的） 这种表示对其他对象是隐藏的。,44,2.3数据抽象和面向对象组织结构,面向对象系统有很多众所周知的优点。由于对象的对客户隐藏了实现的细节，所以可以在不影响其客户的情况下改变对象实现。另外，由于把操作的数据和一组存取例程绑定在一起，使得设计者能够把问题分解成交互作用的代理集合。,45,2.3数据抽象和面向对象组织结构,最大的缺点：当一个对象和其他对象交互（过程调用），它必须知道其他对象的标识。而在过滤器系统中，过滤器是不需要知道其他过滤器的存在。每当一个对象的标识改变的时候，必须修改那些显式调用它的对象。在模块化语言中，当一个模块改变后需要修改每一个引用了这个模块的“导入”列表。,46,2.4事件驱动，隐式调用,隐式调用，响应集成，选择性广播。这种模式起源于基于角色的系统，约束满足性检查，后台程序和包交换网络。 思想是，不直接调用一个过程，而是发布或广播一个或多个事件。系统中的其他构件通过注册与一个事件关联起来的过程，来表示对某一个事件感兴趣。当这个事件发生时，系统本身会调用所有注册了这个事件的过程。这样一个事件的激发会导致其他模块中过程的隐式调用。,47,2.4事件驱动，隐式调用,QT的signal与slot,Object1 Signal1 signal2,Object2 Slot1 slot2,Object4 Slot1 Slot2 Slot3,Object3 Signal1,Connect(object1,singal1,object2,slot1),Connect(object1,singal1,object2,slot2),Connect(object1,singal2,object4,slot1),Connect(object3,singal1,object4,slot3),48,2.4事件驱动，隐式调用,主要特点： 事件发布者不知道哪些构件会受到事件的影响，这样，构件不能对事件的处理顺序，或者事件发生后的处理结果做任何假设。 许多隐式调用系统也包含显示调用（正常的过程调用）以此作为构件交互的补充形式。,49,2.4事件驱动，隐式调用,例子： 编程环境中工具集成 数据库管理系统中的一致性约束 用户界面中数据表示与管理数据的应用程序的分离 语法导向的增量语义检查,50,2.4事件驱动，隐式调用,优点： 它提供了对重用非常好的支持。通过注册一个系统事件，任何一个构件可以很容易的引入到系统中来。 能简化系统的演化。在不改变系统中其他构件接口的情况下，构件可以非常容易的被其他构件取代。,51,2.4事件驱动，隐式调用,缺点： 构件放弃了自身对系统的计算的控制。当一个构件发布一个事件，它不能保证保证其他构件会对其作出响应。即使它能够肯定该事件会被其他构件响应，它也不能依赖事件被处理的先后顺序。 在数据交换方面，有时数据通过事件传递，但在某些情况下，事件系统必须依赖一个共享缓冲区，这样整体的性能和资源的管理可能成为关键性问题。(ip) 正确性验证也可能是问题，因为发布事件的过程的具体含义与事件激发的上下文有关。,52,2.5分层系统（LAYERED SYSTEMS）,一个分层系统是按照层次结构组织的，每一层向它的上层提供服务，同时它又是下层的客户。在某些分层系统中，内层只对其相邻的层和某些用于输出的函数是可见的，对其他外部的层是隐藏的。在这些系统中，构件在某些层中实现虚拟机。,53,2.5分层系统（LAYERED SYSTEMS）,应用系统层,用户,基本功能层,内核层,过程调用,过程调用,54,2.5分层系统（LAYERED SYSTEMS）,例子： 最著名的例子是分层通信协议 数据库系统 操作系统,55,2.5分层系统（LAYERED SYSTEMS）,性质特点： 它支持逐级抽象的系统设计 它支持扩展，每层最多和上下两层交互 它支持重用 。这使得定义标准层接口成为可能，在此接口上可建立不同实现。（OSI的ISO模型和X WINDOW SYSTEM）,56,2.5分层系统（LAYERED SYSTEMS）,缺点： 并不是所有的系统都容易用这种模式来构建。从性能的考虑，也需要将逻辑上高层次的功能与相对低层次的实现结合起来。 很难定义一个合适的抽象层次可能会非常困难。,57,2.6知识库（REPOSITORIES）,由两种截然不同的功能构件：一个是中央数据结构构件，代表系统当前状态，另一个是一些相对独立的构件的集合，这些构件对中央数据存储进行操作。 控制方式的选择将知识库分成了两种主要的子类。输入流中事务触发系统相应的进程执行，是传统的数据库型知识库。由中心数据结构的当前状态触发系统相应的进程执行，这种称为黑板知识库,58,2.6知识库（REPOSITORIES）黑板体系结构,黑板（共享数据）,KS1,KS8,KS7,KS6,KS5,KS4,KS3,KS2,Knowledge source,直接存取,计算,59,2.6知识库（REPOSITORIES）黑板体系结构,黑板系统传统上应用在复杂信号处理解释上，比如语音和模式识别。 通过松散连接代理共享数据 集成编程环境 编译器（以共享信息为基础）,60,2.7解释器（INTERPRETERS）,通常有一个虚拟机。一个解释器包括正在被解释执行的伪码和解释引擎本身。包含四个部分：完成解释工作的解释引擎，一个包含将被解释的伪码的存储区，一个纪录解释引擎当前工作状态的数据结构，以及一个纪录源代码被解释执行的进度的数据结构。,61,2.7解释器（INTERPRETERS）,被解释的程序 （伪码）,数据 （程序状态）,解释引擎,内部解释器状态,选择的指令和数据,输入,输出,62,2.8过程控制,过程控制环路。这种模式在软件开发团队中并没有受到广泛的认可，不象面向对象或功能设计那样以出现的某类构件为特征，控制环路设计的特点是不仅具有某类构件，还具有在构件间必须保持的特殊关系。,63,2.9异构体系结构,大多数系统都是由很多风格组合而成的 一种是使用层次结构 一种是允许单一的构件使用复合的连接件。 第三种组合方法是，用完全不同的体系结构风格来阐述体系结构的一个角度。,64,2.10其他常见的体系结构,分布式处理（比如心跳算法） 主程序/子程序组织结构 特定领域的软件体系结构（参考模型） 状态转换系统（State Transition System）,65,软件体系结构内容,1概述 2软件体系结构风格 3案例研究 4共享信息系统 5软件体系结构描述 6软件体系结构的分析与评估 7特定领域的软件体系结构 8流行的软件体系结构,66,3.0案例分析上下文关键字,Key Word in Context From Wikipedia, the free encyclopedia Jump to: navigation, search KWIC is an acronym for Key Word In Context, the most common format for concordance lines. The term KWIC was first coined by Hans Peter Luhn. 1 A KWIC index is formed by sorting and aligning the words within an article title to allow each word (except the stop words) in titles to be searchable alphabetically in the index. It was a useful indexing method for technical manuals before computerized full text search became common. For example, the title statement of this article and the Wikipedia slogan would appear as follows in a KWIC index. A KWIC index usually uses a wide layout to allow the display of maximum in context information (not shown in the following example).,http:/en.wikipedia.org/wiki/Key_Word_in_Context,http:/www.cs.cmu.edu/ModProb/KWIC.html,67,3.0案例分析上下文关键字,68,3.0案例分析上下文关键字 需求分析,处理算法的变更 比如输入设备可以每读入一行就执行一次移动，也可以读完所有行再执行行移动，或者在需要以字母表的顺序排列行集合时才执行行移动。 数据表示的变更 比如，行，单词和字母可以用各种各样的方式存储。类似的，循环移动情况也可以被显示的或者隐式存储（使用索引和偏移量）,69,3.0案例分析上下文关键字 需求分析,系统功能的扩充 比如，修改系统使其能够排除以某些干扰单词（a，an）开头的循环移动。把系统变成交互式的，允许用户从初始列表中（或者从循环移动的列表中）删除某些行。 性能：空间和时间。 重用：作为可重用的实体，构件重用的程度。,70,3.0案例分析上下文关键字 解决方案1,使用共享数据的主程序/子程序 根据四个基本功能将问题分解为：输入、移动、按字母表排序、输出。所有计算构件作为子程序协同工作，并且由一个主程序顺序地调用这些子程序。构件通过共享存储区（核心存储区）交换数据。 因为是顺序访问，使得计算构件和共享数据之间基于一个不受约束的读写协议的通信成为可能。,71,3.0案例分析上下文关键字 解决方案1,输入,循环移动,按字母表排序,输出,字符,索引,按字母表索引,输入媒介,输出媒介,主控制,使用共享数据的主程序/子程序,72,3.0案例分析上下文关键字 解决方案1,优点：不同的计算功能被划分到不同的模块中 缺点：数据存储格式的变化会影响到所有模块。整体处理算法的变更和系统功能扩充的问题也很难调和。不支持重用。,73,3.0案例分析上下文关键字 解决方案2,抽象数据类型 数据不在共享，每个模块提供一个接口，该接口允许其他构件通过调用接口中的过程来访问数据。,74,3.0案例分析上下文关键字 解决方案2,主控制,输入,输出,输入媒介,输出媒介,字符,设置字符,字符,单词,循环移动,设置字符,字符,单词,设置,按字母次序移动,字母,第I个,抽象数据类型,75,3.0案例分析上下文关键字 解决方案2,优点：将系统逻辑上分成了几个处理模块。然而，当设计变更时，这种方案比第一种具有一定优势。特别是，在一个独立的模块中算法和数据表示的改变不会影响其他模块。另外，为重用提供了更好的支持。 缺点：并不能很好地适合于功能扩展的情况。主要问题是，向系统中加入一个新的功能时，实现者要么平衡其简介性和完整性而修改现存模块，要么添加新的模块而导致性能下降。,76,3.0案例分析上下文关键字 解决方案3,输入,循环移动,按字母表排序,输出,输入媒介,输出媒介,主控制,使用共享数据隐式调用,行,插入,删除,第一个,行,删除,第一个,插入,77,3.0案例分析上下文关键字 解决方案3,采用共享数据的构件集成方式。 两个主要不同。 数据访问接口更加抽象 数据被修改时，计算被隐式地调用。,78,3.0案例分析上下文关键字 解决方案3,优点：容易支持系统功能扩展，通过注册，添加的模块很容易和系统整合，当发生数据交换事件时，这些添加的模块就会被调用。因为数据被抽象访问，所以这种解决方案也将计算和数据表示分开。也支持重用。 难以控制隐式调用模块的处理顺序。数据驱动，会占用更大的空间。,79,3.0案例分析上下文关键字 解决方案,管道过滤器,输入媒介,输入,循环移动,按字母表顺序排序,输出,输出媒介,80,3.0案例分析上下文关键字 解决方案,特性：首先，它能够维持处理的自然流动。第二，它支持重用，因为每个过滤器可以独立处理。通过在处理序列中的合适位置插入过滤器，新的功能很容易加入系统中。第三，既然每个过滤器和其他过滤器在逻辑上是独立的，那么每个过滤器也很容易替换或修改。,81,3.0案例分析上下文关键字 解决方案,缺点： 首先，不可能通过修改使其支持交互。比如，删除一行可能需要一些持久性共享存储区，但是这样就违反了这种方案的基本原则。第二，这种方案空间使用的效率非常低。因为每个过滤器必须复制所有的数据到它的输出端口。,82,3.0案例分析上下文关键字 方案比较,共享数据方案对整体处理算法、数据表示的变更以及重用的支持比较弱。另一方面，由于对数据的直接共享，获得了相对好的性能。另外，相对比较容易加入新的处理构件。 抽象数据类型方案在保证性能的情况下，允许数据表示变更并且支持重用。但是由于构件的交互依赖于模块本身，所以改变整体处理算法或者加入新的功能可能要对现有的系统作很大的修改。 隐式调用方案对于添加新的功能的支持非常好。然而，由于共享数据自身的一些问题，该方案对于数据表示和重用的支持非常弱。它可能引起额外的执行开销。管道过滤器方案允许在文本处理流中放置新的过滤器。因此它支持处理算法的改变、功能的变化和重用。 管道过滤器允许在文本处理流中放置新的过滤器，因此它支持处理算法的改变，功能的变化和重用。数据表示的选择过分依赖于管道中传输的数据类型的假定。而且对管道中的数据进行编码和解码需要额外的开销。,83,3.0案例分析上下文关键字 方案比较,共享数据,抽象数据类型,隐式调用,管道过滤器,算法变更,数据表示变更,功能变更,性能,重用,84,3.案例分析仪器仪表,为Tektronix公司开发一种可重用的体系结构 需求：对电信号进行取样，并且在屏幕上显示电信号的图像，完成大量的测量，提供兆字节的内存，支持工作站和其他仪器的接口，完善的界面，菜单和触摸屏、内置的HELP,85,3.案例分析仪器仪表,需求： 几乎没有在不同的示波器上可重用的软件组织结构。 性能问题越来越严重。不能被快速配置。 （也碰到过：网络测试仪表、两个不同的平台）,86,3.案例分析仪器仪表,面向对象模型（参考文档）,示波器对象,波形,最大最小波形,X-Y波形,叠加波形,87,3.案例分析仪器仪表,但是没有一个整体模型解释怎么结合这些对象类型。这会导致功能划分的混乱。比如量度是否应该与被测量的或者被外部表示的数据类型相关联？用户界面应该和哪些对象交互？,88,3.案例分析仪器仪表,分层模型 第二阶段尝试了解决这些问题。,硬件,数字化,可视化,用户接口,操作,89,3.案例分析仪器仪表,在应用领域是错误的。 主要问题是层次间强加的抽象边界和各种功能交互的需要是相互冲突的。 用户需要跟各层打交道，比如在信号处理层中设置衰减，在采集层中选择采集模式和参数，或者在波形处理层中制作导出波形。,90,3.案例分析仪器仪表,管道过滤器模型,耦合,采集,To-xy,裁减,信号,触发子系统,测量,测量值,91,3.案例分析仪器仪表,没有在功能划分中将各个功能孤立起来，模型允许各个构件灵活混合和替换。 问题：没有清晰说明用户怎么与其交互。如果用户仅仅是等待结果，那么比分层还要糟糕。 改进。？,92,3.案例分析仪器仪表,改进后的FILTER,耦合,采集,To-xy,裁减,信号,触发子系统,测量,测量值,耦合度,种类速率,转换,大小,93,3.案例分析仪器仪表,专用化模型 显著问题：计算模型的性能非常差。特别是波形数据占用了很大的内存容量。每个过滤器的处理速率是不同的。 解决方法：一些FILTER不用复制数据，一些允许慢速过滤器在数据还没有处理完时忽略新来的数据。,94,3.案例分析仪器仪表,小结： 在工业设计体系结构中，必须将“纯”的体系结构风格改造成专用的风格来满足特定领域的需要。,95,3.2案例分析移动机器人,简介：移动机器人用来操纵有人驾驶或部分地有人驾驶的交通工具。 这类系统在诸如空间探索、有害垃圾处理、深水探索等领域得到了新的应用。,96,3.2案例分析移动机器人,软件功能： 采集从传感器发送来的输入信号， 操纵车轮和其他可移动零件的运动， 规划未来的移动路线。 使任务变复杂： 障碍物可能会阻挡机器人的移动路线； 传感器的输入信号可能非常弱； 机器人的电力使用完； 机器的局限性会限制移动的精确性； 机器人可能会处理有毒的材料； 不可预知的事件要求它具有快速响应。,97,3.2案例分析移动机器人,设计考虑因素：对体系结构的几个基本需求 需求：必须能够协调有准备的行为和反应行为。（完成规定动作） 需求：必须能够处理不确定性。机器人能够应对不完整的或不可靠的信息。 需求：能应对固有的危险。考虑容错度、安全性和性能，这个体系结构必须能够保持完整性。（电力下降、有毒气体） 需求：设计者灵活性。需要经常实验和重新配置。任务的改变要定期的修改。 当然有环境问题。不同的使用环境是不同的要求。,98,3.2案例分析移动机器人,考察四种设计： Lozano的控制环路 Elfes的分层组织结构 Simmons的任务控制体系结构 Shafer的黑板组织结构应用,99,3.2案例分析移动机器人,方案控制环路 开始是开环的。（不需要检查结果）因此需要改进成闭环的。,机器人的活动组件,传动装置,传感器,控制器,外界环境,动作,反馈,100,3.2案例分析移动机器人,控制环路对需求的满足： 需求：结构简单，机器人与外界的交互非常清晰。然而在不可预知的环境中这种简单性也是它的缺陷。对于复杂的任务，控制环路并没有给出将软件分解成几个协作构件的方法。,101,3.2案例分析移动机器人,需求：对于不确定性，控制环路偏爱使用下述方法来解决。通过迭代来降低未知性。试探和错误处理程序通过动作和响应来消除每次循环中的可能性。（没有使用基本循环集成这些操作的框架，也没有提供委托独立实体进行操作的框架）,102,3.2案例分析移动机器人,需求：这种闭环范例提供对容错度和安全性的支持。因为它的结构简单，使得复制操作更加容易，并能减少系统中错误发生的几率。,103,3.2案例分析移动机器人,需求：主要构件（监视器、传感器、发动机）是彼此分开的，并能够被独立地替换。微小的修改必须在模块中进行。,104,3.2案例分析移动机器人,方案分层体系结构,监督,全局技术,控制,导航,现实世界建模,传感器集成分析,传感器解释分析,机器人控制,外界环境,这种定义也影响了Dolphin声纳和导航系统的设计，并在Terregator Neptune移动机器人上,驻留机器人控制程序（发动机，关节等）,处理外界的输入（分析单个，集成分析）,维持机器人的外界模型,负责调度和安排机器人行动。处理问题和重新安排,用户界面和全局监控,105,3.2案例分析移动机器人,分层 需求：通过定义更多的执行委托任务的构件,Elfes的模型避开了一些控制环路方案面临的问题。因为这个模型专用于自动控制的机器人，所以它揭示了针对这种机器人所必须解决的问题。（如传感器集成）另外它定义了抽象层来指导设计。,106,3.2案例分析移动机器人,需求：虽然这种模型很好的组织了用来协调机器人操作的构件，但是这种分层体系结构并不适合现行的数据和控制流模式。因为，分层模型要求请求和服务必须在相邻的两层进行。 现实中，比如需要快速响应的数据应该直接从传感器送到位于7层的问题处理代理那里。并且相应的命令也应该跳过好几层及时到达发动机。,107,3.2案例分析移动机器人,另一问题：不能区分实际存在两个抽象层次。 数据层： 原始的传感器输入（第1层） 解释后和集成后的结果（第2层和第3 层）、最终的外界模型（第4层） 控制层： 包括发动机控制（第1层）、导航（第5层）、调度（第6层）、安排（第7层）、用户层控制（第8层）。,108,3.2案例分析移动机器人,需求：抽象层的存在满足了处理不确定性的需要：通过在较高层加入可以用到的知识，使得在最低层中的不确定的事物在较高层中会变得确定。比如外界模型中的上下文能够提供某些线索来消除相对矛盾的传感器数据中的歧义。,109,3.2案例分析移动机器人,需求3： 抽象机制满足了容错度和被动的安全性（你什么也不做）的要求。可以从不同角度分析数据和命令。将多个检查和平衡操作合并到系统中是可能的。就象已经提到的，性能和主动安全性需要缩短通讯路径。,110,3.2案例分析移动机器人,需求4： 层次间的依赖性使得构件的替换和添加更加困难。另外，层次间复杂的关系使得解读每一次变化都会令人头疼。,111,3.2案例分析移动机器人,方案：隐式调用 内嵌于任务控制体系结构（Task-Control Architecture）,task,task,task,task,task,异常,消息,分支的消息,窃听,112,3.2案例分析移动机器人,方案：隐式调用 内嵌于任务控制体系结构（Task-Control Architecture） 任务树,采集岩石,到位置,取石子,举起岩石,左移,前移,113,3.2案例分析移动机器人,TCA的三种功能： 异常（exception） 窃听（wiretapping） 例如一个安全性检查的构件能够根据这种特点验证输出的移动命令。 监控器（Monitor） 如果数据满足某一标准，监控器就可以读取信息，然后去执行某些操作。比如监控器检测到电量低于一个给定值，就会调用负责充电的动作。这个特点提供了一个处理容错度问题的简便方法。放置一个代理来监控系统。,114,3.2案例分析移动机器人,隐式调用 需求：一方面是任务树，另一方是异常、窃听、监控器，这些为动作和响应提供了清晰的划分。可以进行并发处理。多个任务是相互独立的。,115,3.2案例分析移动机器人,隐式调用 需求2：TCA解决不确定性是不够清晰的。如果存在不可估计的情况，会创建一个试验性的任务树，如果任务树中基本假设被证明是错误的，那么异常处理程序会不断的修改它直到正确为止。,116,3.2案例分析移动机器人,隐式调用 需求3 TCA异常、窃听、监控器特点使其考虑了性能、安全性、容错度这些问题。 当为同一个信号注册多个处理者时，通过冗余来实现容错。,117,3.2案例分析移动机器人,隐式调用 需求4 使用隐式调用使得增量开发和构件的替换更为直接。在不影响现有构件的情况下，很容易在中心服务器注册新的处理者、异常、窃听器或监控器。,118,3.2案例分析移动机器人,方案：黑板体系结构,lookout,caption,Map navigator,pilot,黑板,感知子系统,Caption：总监视器 MN：高层路线规划程序 Lookout：为获取路标而监控环境的模块 Pilot：底层的路线规划程序和发动机控制器 感知子系统：这个模块接收来自多个传感器的原始输入并将它们整合成一致的解释,119,3.2案例分析移动机器人,黑板体系结构 需求：构件（感知子系统中的模块）通过黑板系统的共享知识库来进行通信。每个模块只对某种信息感兴趣。数据库可以立刻向这些模块发送它们需要的信息，或者在这些模块向数据库插入这些信息后，再向这些模块发送它们需要的信息。,120,3.2案例分析移动机器人,黑板 需求2：黑板也是一种解决矛盾和不确定性情况的方式。,121,3.2案例分析移动机器人,黑板 需求3：通过数据库进行通信和通过TCA中心消息服务器进行通信的方式非常相似。,122,3.2案例分析移动机器人,黑板： 需求4 和TCA一样，黑板体系结构风格支持并发以及发送者和接受者分离，这样有利于维护。 总之，基于数据库内容的隐式调用机制、黑板体系结构具有模拟任务协作的能力，满足了以灵活的方式处理协调和解决不确定性的需求。,123,3.2案例分析移动机器人,循环控制,分层,隐式调用,黑板,任务协调,处理不确定性,故障容忍,安全,性能,适应性,+,124,3.3定速巡航控制,目的：怎么将控制环路范例应用到一个简单的问题中，这个问题传统上使用面向对象的方法进行处理。 控制环路体系结构的使用，有利于阐明体系结构对于问题解决所起的重要作用。,125,3.3定速巡航控制,巡航控制系统,系统开关,引擎开关,车轮脉冲,加速度,刹车,增减速,恢复速度,时钟,油门,126,3.3定速巡航控制,车轮,当前车速,时钟,期望速度,油门,司机,刹车,发动机,加速器,面向对象的方法,127,3.3定速巡航控制,控制环路方法,引擎,油门设定,期望速度,活跃闲置肘,车轮转动,控制器,128,3.3定速巡航控制,激活状态机,非活动加速,活动,非活动减速,非活动零,关闭,加速度设定点,加速度设定点,恢复,刹车,系统开,引擎开,所有状态,除关闭外的所有状态,系统关闭,引擎关,129,4软件架构的评估,130,5流行的软件体系结构,需求： 提供一种手段，使应用软件可以预先编好的，功能明确的产品部件定制而成，并可用不同版本的部件实现应用的扩展和更新。 利用模块化的方法，将复杂的难以维护的系统分解为互相独立、协同工作的部件，并努力使这些部件可反复重用。 突破时间、空间及不同硬件设备的限制，利用客户和软件之间统一的接口实现跨平台的互操作。,131,5流行的软件体系结构,CORBA 规范 Sun的java平台 Microsoft的.NET平台,132,5流行的软件体系结构,这两种体系结构提供的技术服务， 例如：事务的完整性、消息传递和目录服务、安全、异常处理、远程访问，以及许多其他服务，它们使开发人员能够将注意力集中在构件的功能上，而无需关注工作需要的所有底层技术基础。,133,5.1基于CORBA的分布式构件技术,OMG OMA :三种对象 CORBA服务 CORBA设备 应用对象,134,5.1基于CORBA的分布式构件技术,对象请求代理（Object Request Broker）,CORBA 服务,应用对象,CORBA 服务,CORBA 服务,垂直CORBA设备 facility,水平CORBA设备,OMA对象管理体系结构,135,5.1基于CORBA的分布式构件技术,Corba规范包括：ORB,IDL(接口定义语言),存根(STUB)和框架（SKELETON)、对象适配器、动态调用接口。,136,5.1基于CORBA的分布式构件技术,CORBA 体系结构,接口库,客户端程序,对象请求中间件核心（ORB CORE）,实现库,对象适配器,客户stub,动态调用,ORB接口,对象实现（server）,动态服务,静态服务,137,5.1基于CORBA的分布式构件技术,一个从客户程序发送到对象实现的请求,客户端程序,请求,Object Request Broker,IDL STUB,IDL STUB,对象实现,138,5.2基于JAVA的分布式构件技术,客户端应用程序,动态HTML页面,动态HTML页面,客户层,JSP页面,EJB,JSP页面,EJB,WEB层,业务层,EIS层,数据库,数据库,数据库,139,5.3基于.NET平台的分布式构件技术,VB C+ C# PERL,WEB 服务 用户界面 ,数据和XML(ADO.NET),类库（CLASS LIBRARY）,通用语言运行时（Common Language Runtime）,Visual studio .net,140,5.4面向服务的体系结构,服务注册,服务消费者,服务提供者,服务注册,服务,服务描述,绑定与调用,发布,发现,141,5.4面向服务的体系结构,实现的核心技术 1)XML 2)SOAP 3)WSDL 4)UDDI(Universal Description Discovery and Integration),142,