软件体系结构第5章.ppt
- 文档编号:2573704
- 上传时间:2022-11-02
- 格式:PPT
- 页数:63
- 大小:2.89MB
软件体系结构第5章.ppt
《软件体系结构第5章.ppt》由会员分享,可在线阅读,更多相关《软件体系结构第5章.ppt(63页珍藏版)》请在冰豆网上搜索。
清华大学出版社,1,第5章软件体系结构风格,清华大学出版社,2,内容提要,5.1软件体系结构风格概述5.2软件体系结构基本风格解析5.2.1管道-过滤器5.2.2数据抽象与面向对象风格5.2.3基于事件的隐式调用风格5.2.4分层系统风格5.2.5仓库风格和黑板风格5.2.6模型-视图-控制器(MVC)风格5.2.7解释器风格5.2.8C2风格5.3案例研究5.3.1案例1:
上下文关键字5.3.2案例2:
仪器软件5.3.3平台层PaaS和应用程序层SaaS,清华大学出版社,3,5.4客户/服务器风格5.5三层C/S结构风格5.5.1三层C/S结构的优点5.5.2实例:
某石油管理局劳动管理信息系统5.6B/S风格5.7C/S与B/S混合结构风格5.8正交软件体系结构风格5.8.1正交软件体系结构的概念5.8.2正交软件体系结构的优点5.8.3正交软件体系结构的实例5.9基于层次消息总线的体系结构风格5.9.1构件模型5.9.2构件接口5.9.3消息总线5.9.4构件静态结构5.9.5构件动态行为5.9.6运行时刻的系统演化,清华大学出版社,4,5.10异构结构风格5.10.1使用异构结构的原因5.10.2异构体系结构的实例5.10.3异构组合匹配问题5.11小结,5.1软件体系结构风格概述,软件体系结构风格,是描述某一特定应用领域中系统组织方式的惯用模式。
体系结构风格定义一个系统家族,即一个体系结构定义一个词汇表和一组约束。
词汇表中包含了一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。
体系结构风格,反映了领域中众多系统所共有的结构和语义特征,并指导如何将各个模块和子系统有效地组织成一个完整的系统。
按这种方式理解,软件体系结构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
5.2软件体系结构基本风格解析,5.2.1管道-过滤器,适用于对有序数据进行一系列已经定义的相互计算的应用程序。
管道过滤器模式下,每个功能模块都有一组输入和输出。
功能模块从输入集合读入数据流,并在输出集合产生输出数据流,即功能模块对输入数据流进行增量计算得到输出数据流。
管道过滤器模式下,功能模块称作过滤器(filter);功能模块间的连接可以看作输入、输出数据流之间的通路,所以称作管道(pipe)。
图5-1管道过滤器风格的体系结构,清华大学出版社,8,采用管道-过滤器模式建立的系统主要有以下几个优点:
(1)由于每个构件的行为不受其他构件的影响,因此,整个系统的行为比较易于理解。
设计者可以将系统抽象成一个“黑匣子”,其输入是系统中第一个过滤器的输入管道,输出是系统中最后一个过滤器的输出管道,而其内部各功能模块的具体实现对用户完全透明。
(2)支持功能模块的复用。
任意两个过滤器只要在相互的输入、输出管道格式上达成一致,就可以连接在一起。
过滤器A和过滤器B只要对管道C中传输的数据格式达成一致就可以实现互连,其中过滤器A并不关心过滤器B如何处理管道C的内容,而过滤器B也不知道管道C的内容究竟是如何产生的,即在管道过滤器模式中,过滤器之间仅需很少的信息交换就可以完成互连。
清华大学出版社,9,(3)具有较强的可维护性与可扩展性。
可维护性体现在系统过滤器部件的更新或升级。
由于技术改进等原因,过滤器A的实现发生了改变,采用新技术开发的过滤器D具有和A完全相同的输入、输出管道接口,这时可以直接将A替换为D,而无须对系统中的其他过滤器或管道进行任何修改。
图5-2管道-过滤器支持功能模块复用,图5-3管道-过滤器的可扩展性,清华大学出版社,11,(4)支持特殊的分析:
如吞吐量计算和死锁检测等。
利用管道-过滤器模式图,可以很容易地得到系统的资源使用与请求状态图,然后,根据操作系统原理等相关理论中的死锁检测方法就可以分析出系统目前所处的状态,是否存在死锁可能及如何消除死锁等问题。
(5)支持并发执行。
基于管道-过滤器模式的系统存在很多并行的过滤器,这样的系统在实际运行时,可以将存在并发可能的多个过滤器看作多个并发的任务并行执行,从而大大提高了系统的整体效率,加快了处理速度。
当然,在调度并行任务的时候,必须有相应的并行算法作基础,否则,可能导致系统功能的混乱。
清华大学出版社,12,5.2.2数据抽象与面向对象风格,图5-4数据抽象与面向对象风格的体系结构,面向对象的系统有许多优点,并早已为人所知:
(1)因为对象对其他对象隐藏它的表示,所以可以改变一个对象的表示,而不影响其他的对象。
(2)设计者可将一些数据存取操作的问题,分解成一些交互的代理程序的集合。
但是,面向对象的系统也存在着某些问题。
(1)为了使一个对象和另一个对象通过过程调用等进行交互,必须知道对象的标识,只要一个对象的标识改变了,就必须修改所有其他明确调用它的对象。
(2)必须修改所有显式调用它的其他对象,并消除由此带来的一些副作用。
例如,如果A使用了对象B,C也使用了对象B,那么C对B的使用所造成的对A的影响,可能是预想不到的。
清华大学出版社,14,5.2.3基于事件的隐式调用风格,基于事件的隐式调用风格的思想是构件不直接调用一个过程,而是触发或广播一个或多个事件。
系统中的其他构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程,这样,一个事件的触发就导致了另一模块中的过程的调用。
清华大学出版社,15,隐式调用系统的主要优点有以下两点:
为软件重用提供了强大的支持。
当需要将一个构件加入现存系统时,只需将它注册到系统的事件中。
为改进系统带来了方便。
当用一个构件代替另一个构件时,不会影响到其他构件的接口。
清华大学出版社,16,隐式调用系统的主要缺点有以下几方面:
构件放弃了对系统计算的控制。
一个构件触发一个事件时不能确定其他构件是否会响应它。
而且即使它知道事件注册了哪些构件的过程,它也不能保证这些过程被调用的顺序。
数据交换的问题。
有时数据可被一个事件传递,但在另一些情况下,基于事件的系统必须依靠一个共享的仓库进行交互。
在这些情况下,全局性能和资源管理便成了问题。
既然过程的语义必须依赖于被触发事件的上下文约束,关于正确性的推理就存在问题。
清华大学出版社,17,5.2.4分层系统风格,一个分层风格的系统按照层次结构组织,每一层向它的上层提供服务,同时又是它的下层客户;在某些系统中,除了邻接的层,一个内部层次对于其他外部层次是隐藏的,对体系结构的约束包括把系统内的交互限制在邻接层次之间。
交互只在相邻的层间发生;同时,这些交互按照一定协议进行。
连接件可以用层次间的交互协议来定义。
每个独立层都要防止较高层直接访问较低层。
每一层次是由不同的部件构成的实体集合。
层内的部件可以交互。
相邻层的部件可直接从上向下调用,还可以设计统一的层调用接口对层进行保护。
图5-5分层模型,清华大学出版社,19,5.2.5仓库风格和黑板风格,仓库风格的体系结构由两个构件组成:
一个中央数据结构,它表示当前状态;一个独立构件的集合,它对中央数据结构进行操作。
对于系统中数据和状态的控制方法有两种:
一个传统的方法是,由输入事务选择进行何种处理,并把执行结果作为当前状态存储到中央数据结构中,这时,仓库是一个传统的数据库体系结构;另一种方法是,由中央数据结构的当前状态决定进行何种处理。
这时,仓库是一个黑板体系结构。
即黑板体系结构是仓库体系结构的特殊化。
清华大学出版社,20,
(1)适应的设计问题
(2)解决方案,“黑板”模式类似于这样一个情形,即让专家们坐在真实黑板前并一起工作来解决一个问题。
每个专家独立评估解法的当前状态,并可在任何时间到黑板上添加、更改或删除信息。
人们往往要决定接下来谁去访问黑板。
在黑板模式中,如果可用的组件超过一个,仲裁者(moderator)组件决定程序执行的顺序。
图5-6黑板风格的体系结构,清华大学出版社,22,从图5-6中不难看出,一个标准的黑板型仓库模式系统通常包括3个组成部分:
(1)知识源:
(2)中央数据单元:
(3)控制单元:
清华大学出版社,23,黑板风格的体系结构的优点有:
便于多客户共享大量数据,它们不用关心数据是何时出现的、谁提供的、怎样提供的。
既便于添加新的作为知识源代理的应用程序,也便于扩展共享的黑板数据结构。
可重用的知识源。
知识源是某类任务的独立专家。
黑板体系结构有助于使它们可重用。
重用的先决条件是知识源和所基于的黑板系统理解相同的协议和数据,或者在这方面相当接近而不排斥协议或数据的自适应程序。
支持容错性和健壮性。
在黑板体系结构中,所有的结果都只是假设。
只有那些被数据和其他假设强烈支持的才能生存。
这提供了对噪声数据和不确定结论的容忍。
清华大学出版社,24,黑板风格的体系结构的缺点有:
不同的知识源代理对于共享数据结构要达成一致,而且,这也造成对黑板数据结构的修改较为困难。
需要一定的同步锁机制保证数据结构的完整性和一致性,增大了系统复杂度。
测试困难。
由于黑板系统的计算没有依据一个确定的算法,所以其结果常常不可再现。
此外,错误假设也是求解过程的一部分。
不能保证有好的求解方案。
一个黑板系统往往只能正确解决所给任务的某一百分比。
难以建立一个好的控制策略。
控制策略不能以一种直接方式设计,而需要一种试验的方法。
清华大学出版社,25,低效。
黑板系统在拒绝错误假设中要承受多余的计算开销。
但是,如果没有确定的算法存在,那么与根本不存在的系统相比,低效总比没有强。
开发成本高。
绝大多数黑板系统要花几年时间来进化。
我们把这归因于病态结构问题。
5.2.6模型-视图-控制器(MVC)风格,1.MVC模式,MVC由TrygveReenskaug提出,首先被应用在SmallTalk-80环境中,是许多交互和界面系统的构成基础。
MVC结构是为那些需要为同样的数据提供多个视图的应用程序而设计的,它很好地实现了数据层与表示层的分离。
作为一种开发模型,MVC通常用于分布式应用系统的设计和分析中,以及用于确定系统各部分间的组织关系。
对于界面设计可变性的需求,MVC(ModelViewController)把交互系统的组成分解成模型、视图、控制器三种部件。
清华大学出版社,27,2.MVC中的模型、视图和控制类MVC中的模型、视图和控制类如图5-7所示。
(1)模型类
(2)视图类(3)控制类,清华大学出版社,28,(a),(b),(c),清华大学出版社,29,3.MVC的实现实现基于MVC的应用需要完成以下工作,如图5-8所示:
图5-8MVC的实现,清华大学出版社,30,
(1)分析应用问题,对系统进行分离
(2)设计和实现每个视图(3)设计和实现每个控制器(4)使用可安装和卸载的控制器,5.2.7解释器风格,解释器风格通常被用于建立一种虚拟机以弥合程序的语义与作为计算引擎的硬件的间隙。
由于解释器实际上创建了一个软件虚拟出来的机器,所以这种风格又常常被称为虚拟机风格。
(例如:
程序设计语言的编译器,比如Java、Smalltalk等;基于规则的系统,比如专家系统领域的Prolog等;脚本语言,比如Awk、Perl等。
),清华大学出版社,32,图5-9解释器风格的体系结构,清华大学出版社,33,解释器风格的优点如下:
有助于应用程序的可移植性与程序设计语言的跨平台能力;可以对未实现的硬件进行仿真。
解释器风格的缺点,是额外的间接层次带来的系统性能的下降。
5.2.8C2风格,C2体系结构风格可以概括为通过连接件绑定在一起的、按照一组规则运作的并行构件网络。
图5-10C2风格的体系结构,清华大学出版社,35,C2风格,是最常用的一种软件体系结构风格。
从C2风格的组织规则和结构图中可以得出,C2风格具有以下特点:
系统中的构件可实现应用需求,并能将任意复杂度的功能封装在一起。
所有构件之间的通信是通过以连接件为中介的异步消息交换机制来实现的。
构件相对独立,构件之间依赖性较少。
系统中不存在某些构件将在同一地址空间内执行,或某些构件共享特定控制线程之类的相关性假设。
清华大学出版社,36,5.3案
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 体系结构