软件体系结构1

软件体系结构,软件体系结构的基本概念典型的软件体系结构风格基于网络的软件体系结构,模式分类,低层模式：惯用法(idiom)中层模式：设计模式(designpattern)高层模式：体系结构模式(architecturepattern),惯用法,惯用法的特点：是与具体语言密切相关的编程经验的总结描述如何使用给定的语言特征来实现构件的特定方面及其关系代表最底层的模式惯用法更关注设计的实现可能是一种特定设计模式的具体实现,设计模式,基本概念,什么是体系结构目前还没有一个公认的关于软件体系结构的定义，许多专家学者从不同角度对软件体系结构进行了描述。Bass、Clements和Kazman给出了如下定义：“一个程序或计算机系统的软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件、构件的外部可见属性以及它们之间的相互关系。外部可见属性则是指软件构件提供的服务、性能、使用特性、错误处理、共享资源使用等。”这一定义强调在任一体系结构表述中“软件构件”的角色。,DewaynePerry和A1exanderWo1f曾这样定义：“软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组合连接起来。”,基本概念,基本概念,框架随着应用的发展和完善，某些带有整体性的应用模式被逐渐固定下来，形成特定的框架，包括基本构成元素和关系。框架是特定应用领域问题的体系结构模式，框架定义了基本构成单元和关系后，开发者就可以集中精力解决业务逻辑问题。在组织形式上，框架是一个待实例化的完整系统，定义了软件系统的元素和关系，创建了基本的模块，定义了涉及功能更改和扩充的插件位置。典型的框架例子有MFC框架和Struts框架。,体系结构的重要作用体现在以下三个方面：（1）体系结构的表示有助于风险承担者（项目干系人）进行交流。（2）体系结构突出了早期设计决策。（3）软件体系结构是可传递和可复用的模型。,基本概念,体系结构的重要作用,体系结构风格,传统的体系结构数据流风格(Dataflow)：批处理序列、管道过滤器风格(Pipe-and-Filter)调用/返回风格：主程序/子程序、面向对象风格(ADT)、层次系统(LayeredSystems)事件系统风格：进程通信、事件系统仓库风格：数据库系统、超文本系统、黑板系统MVC软件体系结构,体系结构风格,基于网络的体系结构客户端（服务器）/服务器体系结构：一层/两层/三层结构、JavaEEP2P软件体系结构网格计算体系结构SOA与WebServices云计算体系结构,当输入数据经过一系列的计算和操作构件的变换形成输出数据时，可以应用这种体系结构。管道/过滤器、批处理序列都属于数据流风格。管道/过滤器结构如下图所示：,数据流风格,数据流风格,管道/过滤器结构,Linux系统中的命令序列,堆叠的数据过程（图像处理）,从上图可看出，管道/过滤器结构拥有一组被称为过滤器（filter）的构件，这些构件通过管道（pipe）连接，管道将数据从一个构件传送到下一个构件。每个过滤器独立于其上游和下游的构件而工作，过滤器的设计要针对某种形式的数据输入，并且产生某种特定形式的数据输出。如果数据流退化成为单线的变换，则称为批处理序列（batchsequential）。这种结构接收一批数据，然后应用一系列连续的构件（过滤器）变换它。,数据流风格,管道/过滤器风格具有以下优点：（1）使得软构件具有良好的隐蔽性和高内聚、低耦合的特点。（2）允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成。（3）支持软件复用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来。（4）系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉。（5）允许对一些如吞吐量、死锁等属性的分析。（6）支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行执行。,数据流风格,管道/过滤器风格主要缺点如下：（1）通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。（2）不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重。（3）因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。,数据流风格,在此类体系结构中，存在以下3种子风格。主程序/子程序体系结构（C语言？）这种传统的程序结构将功能分解为一个控制层次，其中“主”程序调用一组程序构件，这些程序构件又去调用别的程序构件，如下图所示。这种结构总体上为树状结构，可以在底层存在公共模块。,调用返回风格,调用返回风格（常见，发挥主要作用）,主程序/子程序体系结构的优点如下:（1）可以使用自顶向下，逐步分解的方法得到体系结构图，典型的拓扑结构为树状结构。基于定义使用关系对子程序进行分解，使用过程调用作为程序之间的交互机制。（2）采用程序设计语言支持的单线程控制。其主要缺点如下:（1）子程序的正确性难于判断。需要运用层次推理来判断子程序的正确性，因为子程序的正确性取决于它调用的子程序的正确性。（2）子系统的结构不清晰。通常可以将多个子程序合成为模块。,调用返回风格,面向对象的调用返回风格系统的构件(类/对象)封装了数据和必须应用到该数据上的操作，构件间通过消息传递进行通信与合作。与主程序/子程序的体系结构相比，面向对象风格中的对象交互会复杂一些。面向对象风格与网络应用的需求在分布性、自治性、协作性、演化性等方面具有内在的一致性。面向对象风格具有以下优点:（1）因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他对象。（2）设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。,调用返回风格,其缺点如下:（1）为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。（2）必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。,调用返回风格,层次结构层次结构的基本结构如下图所示。在这种体系结构中，整个系统被组织成一个分层结构，每一层为上层提供服务，并作为下一层的客户。,调用返回风格,各类网络协议栈,层级之间的调用-返回避免复杂性,这种风格支持基于可增加抽象层的设计。允许将复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。,调用返回风格,调用返回风格,调用返回风格,分层系统实例：ISO/OSI网络的分层模型,调用返回风格,分层系统实例：计算机操作系统(OS)的层次结构,层次结构具有以下优点:（1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解。（2）支持功能增强，因为每一层至多和相邻的上下层交互，因此，功能的改变最多影响相邻的内外层。（3）支持复用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，从而允许各种不同的实现方法。,调用返回风格,其缺点如下:（1）并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来。（2）很难找到一个合适的、正确的层次抽象方法。,调用返回风格,数据流与调用-返回,事件系统风格,事件系统风格（独立构件）GUI编程Windows操作系统中Hook机制Jquery中的回调,事件系统风格,事件系统风格,事件系统风格,典型的体系结构风格,事件系统风格,事件系统风格,为何称为“独立构件”风格？,这种风格的主要特点是：事件的触发者并不知道哪些构件会被这些事件影响，相互保持独立。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用；各个构件之间彼此之间无连接关系，各自独立存在，通过对事件的发布和注册实现关联；,事件系统风格,遇到断点，编辑器将源代码滚动到断点处，变量监测器则更新当前变量值并显示出来。如何完成?,事件系统风格,事件系统的基本构成与工作原理,事件系统风格,EventSource:debugger(调试器)EventHandler:editorandvariablemonitor(编辑器与变量监视器)EventManager:IDE(集成开发环境)编辑器与变量监视器向调试器注册，接收“断点事件”；一旦遇到断点，调试器发布事件，从而触发“编辑器”与“变量监测器”；编辑器将源代码滚动到断点处，变量监测器则更新当前变量值并显示出来。,其他的例子？Windows本身就是事件驱动的,事件系统风格,事件分发的策略,事件系统风格,无独立的事件派遣模块,通过“观察者模式”实现模块向事件发送模块注册某些消息当某一模块发出某一事件时，它自动将这些事件发布给那些曾经向自己注册过此事件的模块,有独立的事件派遣模块,广播式(Allbroadcasting)：派遣模块将事件广播到所有的模块，但只有感兴趣的模块才去取事件并触发自身的行为；选择广播式(Selectedbroadcasting)：派遣模块将事件送到那些已经注册了的模块中。,事件系统风格,我对此事件感兴趣，触发我的行为,我对此事件不感兴趣，不触发我的行为,我们都得到了事件,广播式事件派遣,事件系统风格,选择广播式事件派遣,我没预定!我得不到事件消息,WIN32EventHandling,ApplicationscalltheOSAPI(应用程序调用操作系统的API注册自身及事件处理方法)OScreateseventstonotifytheapplications(操作系统根据应用系统的行为，创建事件并通知其他已注册的应用程序)userinputoccurred(mouse,keyboard)messagesfromthenetworkarrived,.time-outhappened,.applicationopened,systemwillbeshutdown,.,WIN32EventHandling,用户产生的事件或其他应用程序发出的消息,依据应用程序队列和消息确定向哪个应用程序发送,依据消息和对象控制序列找到对应该消息的对象程序执行之,1,3,4,2,5,6,7,数据库系统、超文本系统和黑板系统都属于仓库风格。在这种风格中，数据仓库（如文件或数据库）位于这种体系结构的中心，其他构件会经常访问该数据仓库，并对仓库中的数据进行增加、修改或删除操作。右图为一个典型的仓库风格的体系结构。,仓库风格,仓库风格,仓库风格,仓库风格实例注册表,仓库风格,仓库风格实例注册表,仓库风格,仓库风格实例剪贴板,仓库风格,仓库风格实例剪贴板,仓库风格,仓库风格的连接件,黑板构件负责协调信息在客户间的传递，当用户感兴趣的数据发生变化时，它将通知客户软件。黑板系统的组成如下图所示：,仓库风格,黑板结构,模型：包含核心功能和数据（核心业务逻辑）视图：向用户显示信息控制器：处理用户输入,MVC风格,MVC（Model-View-Controller）的组成,MVC风格,将人机交互从核心功能中分离出来(M)模型对用户来说是透明的，用户只需要观察视图(V)用户与模型的交互通过控制器提供的安全方法来实现(C),MVC的目的,具有灵活人-机界面的交互式应用程序可以灵活选择不同的信息显示方式可以灵活选择用户的输入方式针对不同的用户角色，提供不同的用户界面不同用户具有不同权限，操作的方式也有所不同,MVC的应用领域,封装了内核功能和数据业务逻辑（软件的核心）数据以及访问它们的函数（视图组件使用）执行特定应用程序处理的过程（控制器代表用户调用）模型对于用户来说是不可见的(M与V独立)模型独立于特定输出表示或者输入方式(M与C独立)用户只能通过控制器操作模型(C是M与V之间的桥梁),MVC风格,模型（Model）,向用户显示信息不同的视图使用不同的方法呈现信息每个视图组件都有一个更新函数，这个函数被模型变更通知激活这个函数被激活（此时模型已经改变）后，将使得视图重新和模型一致在初始化阶段，视图向模型登记请求变更通知（表）从模型获得数据通过状态查询函数实现例如：定时刷新,MVC风格,视图（View）,每个视图有一个相关的控制器组件(一一对应)控制器组件接受事件，并翻译成输入事件如何发送到控制器由用户界面平台决定事件被翻译成为对模型或者视图的请求如果控制器的行为依赖于模型的状态，那么控制器也需要向模型登记请求变更通知例如：用户点击按钮，按钮的事件响应函数将采取相应的措施处理用户要求用户仅仅通过控制器与系统交互,MVC风格,控制器（Controller）,一个模型可对应多个视图如果用户通过一个视图的控制器改变了模型中的数据，那么依赖于该数据的其他视图也应该反映出这样的变化一旦模型的数据发生了变化，模型需要通知所有相关的视图做出相应的变化工作原理：模型维护了一个表所有视图还有一些控制器在这个表中登记了对变更通知的需求模型状态的改变将触发变更-传播机制，每个在表中登记的视图和控制器都会收到变更通知,MVC风格,变更-传播机制,观察者模式？,事件架构？,MVC是一种体系结构通过各类技术的组合来实现通过各类框架实现（struts等）最终实现：前台页面设计与核心业务逻辑分离。,MVC风格,MVC的实现,体系结构风格,基于网络的体系结构客户端（浏览器）/服务器体系结构：一层/两层/三层结构、JavaEESOA与WebServices云计算体系结构,1965-1985：以大型机为核心的集中式处理模式；1986-1990：以PC/文件服务器为核心的文件共享计算模式；1990-1996：以C/S结构为主流的分布式计算模式；1996-：以Web为核心、B/S结构为主流的分布式计算模式；2000-：以各类移动设备为核心的普适计算模式；2005-：以Grid、P2P、Web2.0等为核心的分布式计算模式；,客户端/服务器体系结构,计算模式经历了以下六代：,一个应用系统被分为两个逻辑上分离的部分，每一部分充当不同的角色、完成不同的功能，多台计算机共同完成统一的任务。客户机(前端，front-end)：业务逻辑、与服务器通讯的接口；服务器(后端：back-end)：与客户机通讯的接口、业务逻辑、数据管理。一般的：客户机为完成特定的工作向服务器发出请求；服务器处理客户机的请求并返回结果。,客户端/服务器体系结构,客户机/服务器(Client-ServerArchitecture),两层C/S三层C/S多层C/S,客户端/服务器体系结构,C/S结构发展历程,客户界面,数据库服务器,客户界面,数据库服务器,业务逻辑服务器,客户界面,数据库服务器,业务逻辑服务器,Web服务器,客户端/服务器体系结构,两层C/S,客户端/服务器体系结构,两层C/S,Client,Server,客户端/服务器体系结构,两层C/S,基本构件：数据库服务器：存放数据的数据库、负责数据处理的业务逻辑；客户机应用程序：GUI：用户界面业务逻辑：利用客户机上的应用程序对数据进行处理；连接件：经由网络的调用-返回机制或隐式调用机制。客户机服务器：客户机向服务器发送请求，并接收返回结果。,客户端/服务器体系结构,两层C/S,业务逻辑的划分比重：在客户端多一些还是在服务器端多一些？(胖客户端：客户端执行大部分的数据处理操作)(瘦客户端：客户端具有很少或没有业务逻辑),客户端/服务器体系结构,两层C/S应用,两层C/S架构通常被用在那些管理与操作不太复杂的非实时的信息处理系统适合于轻量级事务客户机对服务器的请求少，数据传输量少当业务逻辑较少变化以及用户数少于100时，两层C/S架构的性能较好,客户端/服务器体系结构,三层C/S,在客户端与数据库服务器之间增加了一个中间层中间层可能为：事务处理监控服务器、消息服务器、应用服务器中间层负责消息排队、业务逻辑执行、数据传输等功能,客户端/服务器体系结构,三层C/S应用,客户端/服务器体系结构,三层C/S,表示层:用户接口部分，担负着用户与应用之间的对话功能；检查用户的输入，显示应用的输出；通常使用GUI；在变更时，只需要改写显示控制和数据检查程序，而不影响其他层；不包含或包含一部分业务逻辑。,客户端/服务器体系结构,三层C/S,表示层:用户接口部分，担负着用户与应用之间的对话功能；检查用户的输入，显示应用的输出；通常使用GUI；在变更时，只需要改写显示控制和数据检查程序，而不影响其他层；不包含或包含一部分业务逻辑。,客户端/服务器体系结构,三层C/S,功能层:应用系统的主体，包括大部分业务处理逻辑(通常以业务构件的形式存在，如JavaBean/EJB/COM等)；从表示层获取用户的输入数据并加以处理；处理过程中需要从数据层获取数据或向数据层更新数据；处理结果返回给表示层。,客户端/服务器体系结构,三层C/S,数据层:DMBS；接受功能层的数据查询请求，执行请求，并将查询结果返回给功能层；从功能层接受数据存取请求，并将数据写入数据库；请求的执行结果也要返回给功能层。,客户端/服务器体系结构,三层C/S结构的物理结构,两层C/S已经将数据层分离出来三层C/S则要将表示层与功能层分离开来，形成独立的程序，并使二者之间的接口简洁明了。问题：这三个层次在物理上是如何分布的？,客户端/服务器体系结构,基于集群(Cluster)的C/S物理分布,事实上，功能层通常不是只驻留在同一台服务器上，数据层也是如此；如果功能层(或数据层)分布在多台服务器上，那么就形成了基于集群(Cluster)的C/S物理分布模式。,客户端/服务器体系结构,三层C/S结构的优点,在用户数目较多的情况下，三层C/S结构将极大改善性能与灵活性(通常可支持数百并发用户，通过集群可达数万并发用户)；允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性允许更灵活有效地选用相应的平台和硬件系统，并且这些平台和各个组成部分可以具有良好的可升级性和开放性。,客户端/服务器体系结构,浏览器/服务器(Browser/ServerArchitecture),浏览器/服务器(B/S)是三层C/S风格的一种实现方式。表现层：浏览器逻辑层：Web服务器应用服务器数据层：数据库服务器,客户端/服务器体系结构,浏览器/服务器(Browser/ServerArchitecture),J2EE平台典型B/S结构的实现方式,客户端/服务器体系结构,B/S架构的优点,基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决，系统维护成本低：客户端无任何业务逻辑，用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。良好的灵活性和可扩展性：对于环境和应用条件经常变动的情况，只要对业务逻辑层实施相应的改变，就能够达到目的。三层模式成为真正意义上的“瘦客户端”，从而具备了很高的稳定性、延展性和执行效率。三层模式可以将服务集中在一起管理，统一服务于客户端，从而具备了良好的容错能力和负载平衡能力。,客户端/服务器体系结构,B/S架构的优点,基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决，系统维护成本低：客户端无任何业务逻辑，用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真