河北师范大学软件体系结构期末复习总结.docx
- 文档编号:24111880
- 上传时间:2023-05-24
- 格式:DOCX
- 页数:17
- 大小:141.79KB
河北师范大学软件体系结构期末复习总结.docx
《河北师范大学软件体系结构期末复习总结.docx》由会员分享,可在线阅读,更多相关《河北师范大学软件体系结构期末复习总结.docx(17页珍藏版)》请在冰豆网上搜索。
河北师范大学软件体系结构期末复习总结
软件体系结构复习
第一章概述
1.模式是一条由三部分组成的规则:
一个特定的环境,一个问题,一个解决方案。
2.设计模式基于惯用法;体系结构模式基于设计模式。
3.好的系统设计应该具备的3个性质:
可扩展性;灵活性;可插入性。
4.面对对象设计的原则:
单一职责原则:
高内聚性原则;避免相同的职责(功能)分散到不同的类中实现;避免一个类承担过多的职责——可以减少类之间的耦合;(类的设计主要工作是“发现职责”并“分离职责”;工厂模式,模板方法模式,命令模式,代理模式遵守该设计模式);单一职责原则的体系结构模式:
一个模块,子系统也应该仅有一个引起他变化的原因。
开闭原则:
Open:
模块的行为必须是开放的,支持扩展的,而不是僵化的;
Closed:
在对模块的功能进行扩展时,不应该影响或把规模的影响已有的程序模块;
绝大部分的设计模式都符合开闭原则;抽象化是开闭原则的关键——要求开发人员在不修改系统中现有的功能代码前提下,而实现对应用系统功能进行扩展。
依赖倒置原则:
将依赖关系倒置为依赖接口:
上层模块不应依赖于下层模块,它们共同依赖于一个抽象;父类不能依赖子类,他们都要依赖抽象类;抽象不能以来具体,具体应该依赖于抽象。
接口原则:
一个类对另外一个类的依赖应当是建立在最小的接口上;客户端不应该依赖那些它不需要的接口。
如何避免不良好的接口设计:
用多个专门的接口,而不使用单一的接口;一个接口就只代表一个角色;使用接口隔离原则拆分接口时,首先必须满足单一职责原则。
合成复用原则:
又称为组合/聚合复用原则;尽量使用对象组合,而不是继承来达到复用目的;一个新的对象里通过关联关系(包括组合关系和聚合关系)来使用一些已有的对象;新对象通过委派调用已有对象的方法达到复用其已有功能的目的;
继承复用:
(“白箱”复用)实现简单,易于扩展,没有足够的灵活性。
组合/聚合复用:
(“黑箱”复用)耦合度相对较低,选择性地调用成员对象的操作;可以在运行时动态进行。
5.好设计的原则:
单一职责原则要求在软件系统中,一个类只负责一个功能领域中的相应职责。
开闭原则要求一个软件实体应当对扩展开放,对修改关闭,即在不修改源代码的基础上拓展一个系统的行为。
里氏代换原则可以通俗表述为在软件中如果能够使用基类对象,那么一定能够使用其他子类对象。
依赖倒转原则要求抽象不应该依赖于细节,细节应该依赖于抽象;要针对接口编程,不要针对实现编程。
接口隔离原则要求客户端不应该依赖那些他不需要的接口,即将一些大的接口细化为一些小的接口供客户端使用。
合成复用原则要求复用时尽量适用对象组合,而不使用继承。
迪米特法则要求一个软件实体应当尽可能少的与其他实体发生相互作用。
第二章观察者模式
1.问题:
背景:
某对象发生变化,需其他的对象做出调整;应用程序的可维护性和重用性;互动关系不能体现成类之间的直接调用,对象之间的关系的解耦。
2.观察者模式:
又叫发布订阅模式;两个角色:
观察者和被观察对象;两者之间存在观察的逻辑关联;当被观察者发生改变的时候,观察者就会观察到这样的变化,并且做出相应的响应;观察不是直接调用;
实现观察者模式有很多形式,比较直观的一种是使用一种“注册——通知——撤销注册”的形式。
第三章适配器模式
1.问题:
想使用一个已经存在的类,但他的接口不符合要求;将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能在一起工作的那些类可以在一起工作。
2.适配器模式:
适配器模式中的有四种角色:
目标:
定义客户端使用的与特定领域相关的接口;
被适配者:
定义了一个已经存在的接口,这个接口需要匹配;
适配者:
对被适配者的接口与目标的接口进行匹配;
客户端:
与符合目标接口的对象协调。
3.适配器模式分类:
类的适配器模式(采用继承实现);对象适配器(采用对象组合方式实现)。
4.类适配器和对象适配器的比较:
类适配器采用“多继承”的实现方式,带来了不良的高耦合;对象适配器采用“对象组合”的方式,更符合松耦合精神;类适配器无法对象多个被适配器对象(合成复用原则)。
第四章策略模式
1.问题:
将每一个一系列的算法封装起来;而且使他们可以相互替换,而且可以相互替换——策略模式:
让算法独立于使用它的用户而独立变化。
2.策略模式中的三种角色:
抽象策略类:
定义所有支持的算法的公共接口;
具体策略类:
以抽象策略类接口实现某具体算法;
环境类:
维护一个对抽象策略对象。
可定义一个接口来让抽象接口类访问它的数据。
3.策略模式的优点:
策略模式提供了对“开闭原则”的完美支持,用户可以在不修改原有系统的基础上选择算法或者行为,也可以灵活地增加新的算法或行为;
策略模式提供了管理相关的算法族的办法;
策略模式提供了可以替换继承关系的办法;
使用策略模式可以避免使用多重条件转移;
缺点:
客户端必须知道所有的策略类,并自行决定使用哪一个策略类;策略模式将产生很多策略类。
5.策略模式适用环境
如果在一个系统里面有许多类,它们之间的区别仅在于它们的行为,那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。
一个系统需要动态地在几种算法中选择一种。
不希望客户端知道复杂的、不算法相关的数据结构,在具体策略类中封装算法和相关的数据结构,提高算法的保密性与安全性
第五章组合模式
1.问题:
对于树形结构,当容器对象(如文件夹)的某一个方法被调用时,将遍历整个树形结构,寻找也包含这个方法的成员对象并调用执行(递归)。
客户端希望一致地处理容器对象和叶子对象——组合模式:
描述了如何将容器对象和叶子对象进行递归组合,使得用户在使用时无须对他们进行区分,可以一致的对待容器对象和子对象。
2.组合模式:
又叫做“整体——部分模式”;它使树形结构的问题中,模糊了简单元素和复杂元素的概念,客户程序可以向处理简单元素一样对来处理复杂元素,从而使客户程序与复杂元素的内部结构解耦。
3.适配器模式下的三种角色:
抽象组件类:
组合中的对象声明接口,实现所有类共有接口的行为。
声明用于访问和管理抽象组件类的子部件的接口。
叶子节点:
叶节点对象,叶节点没有子节点。
由于叶节点不能增加分支和树叶,所以叶节点的Add和Remove没有实际意义。
有叶节点行为,用来存储叶节点集合。
组件集合类:
实现抽象组件类的相关操作,比如Add和Remove操作。
其中包含抽象组件类的容器,用来存储叶节点集合。
4.组合模式
优点:
组合模式不遵守单一责任原则换取透明性,让客户将组合和叶节点一视同仁;
在实现组合模式时,有很多设计上的折中。
要根据需求平衡透明性和安全性。
有时候系统需要遍历一个树枝构件的字构件很多次,这时候可以把遍历结果缓存起来;
组合模式的实现中,可以让子对象持有父对象的引用进行反向追溯。
缺点:
使用组合模式后,控制树枝的类型不太容易;用继承的方法来增加新的行为很困难。
6.组合模式的使用环境:
表示对象的部分—整体层次结构;用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象。
第六章装饰模式
1.问题:
背景:
动态的给一个对象添加一些功能;
类的关系爆炸:
类的数量成几何方式扩充;
应用程序的可维护性,可扩展性差。
2.Decorator模式:
——解决方案是利用子对象,委派
解决的问题:
动态的给一个对象添加一些额外的功能和职责;
实现观察者模式有很多形式,最常见的一种就是“实现装饰者类—定义被装饰者对象—使用被装饰者对象产生装饰者对象”。
3.扩展说明:
装饰者和被装饰者具有相同的类型;可以用多个装饰者装饰一个对象;由于装饰者和被装饰者具有相同的类型,我们可以用装饰后的对象代替原来的对象;装饰者在委派它装饰者的对象做某种处理时,可以添加上自己的行为;对象可以在任何时候被装饰,因我们能在运行时动态的装饰对象。
第七章状态模式-
1.问题:
背景:
某对象发生变化时,其所能做的操作也随之变化;
应用程序的可维护性和重用性差;代码的逻辑较复杂。
2.状态模式:
允许对象在其内部状态发生改变的时候改变它的行为。
角色:
环境类:
客户使用的对象类。
维护一个State子类的实例,这个实例定义当前的状态;
抽象状态类:
定义一个接口以封装与环境类的一个特定状态相关的行为。
具体状态类:
每一个子类实现一个与环境类的一个状态相关的行为。
3.扩展说明
状态模式可封装状态转换规则;
对于某个系统,可以方便的添加新的状态;
允许状态转换逻辑与状态对象合成一体;
状态模式必然会增加系统类和对象个数;
结构和实现相对比较复杂;
对开闭原则的支持不是很好,增加状态需要修改复杂状态转换的代码。
5.改进状态模式:
在状态类内部维护状态的切换规则;
6.状态切换规则:
1.一般情况下,如果状态转换的规则是一定的,一般不需要进行什么扩展规则,那么久适合在上下文中统一进行状态的维护;
2.如果状态的转换取决于前一个状态动态处理的结果,或者是依赖于外部数据,为了增强灵活性,这种情况下,一般是在状态处理类里面进行状态的维护。
7.状态模式的解决方案是利用包含状态类的子对象;如果状态之前具有前后关系,可在状态类内部进行状态的切换。
第八章命令模式
1.问题:
背景:
一个用户要对多个目标进行调用,而且目标对象的操作相似;
用户使用的复杂性加大,目标的执行效率会比较低;
增加目标的使用者的话,逻辑叫复杂;
互动关系不能体现成类之间的直接调用,对象之间的关系耦合度大。
2.命令模式:
——利用包含转发者进行命令的转发
让行为的发送者和执行者完全解耦;
当用户发出命令后,无需关注谁来执行命令,由转发者来进行命令的调配的转发;
将命令的发出者和命令的执行者完全隔离开;
3.角色
Command:
定义命令的接口,声明执行的方法。
ConcreteCommand:
命令接口实现对象,通常会持有接收者,并调用接收者的功能来完成命令要执行的操作。
Receiver:
接收者,真正执行命令的对象。
Invoker:
传递者,要求命令对象执行请求,通常会持有命令对象,可以持有很多的命令对象。
Client:
创建具体的命令对象,并且设置命令对象的接收者。
组装命令对象和接收者,因为真正使用命令的客户端是从Invoker来触发执行。
命令模式有很多种实现形式,比较常见的一种是“客户下达命令-----传达者接收,并传递给执行者----执行者接收到命令,执行命令”
第九章外观模式
1.问题:
背景:
用户希望使用一个比较复杂的子系统。
但是用户需要和子系统的复杂模块交互;
客户并不了解复杂的子系统内部的结构;
子系统结构变化,需要改变客户的使用方式;
2.外观模式(Facade):
为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用;
使客户尽量少的与子系统内部的组件打交道,尽量维护子系统的统一的接口;
使系统的用户和系统通过Façade类解耦。
当子系统改变时,只要保证façade类的接口不变,用户的使用方式无需改变。
外观模式的实现一般采用:
在子系统外部封装façade类的方式实现。
4.角色:
目标类:
子系统的合集;
外观类:
一个相对复杂的子系统类的外观类;
客户端类:
要使用子系统类中各个方法的用户类。
5.扩展说明:
外观模式为复杂子系统提供了一个简单接口,并不为子系统添加新的功能和行为。
外观模式实现子系统和客户之间的松耦合关系;
外观模式没有封装子系统类,只是提供了简单的接口。
如果应用需要,它并不限制客户使用子系统类,因此可以在系统易用性和通用性之间选择。
外观模式注重的是简化接口,它更多的时候是从架构层次去看整个系统,而并非单个类的层次。
6.外观模式结解决的问题是“如何简单的使用一套复杂的子系统”;外观模式的解决方案是利用对处理逻辑的封装产生外观类。
第十章代理模式—提供一种代理控制对一个对象的访问
1.背景:
找一个代理人来帮助解决问题;
2.代理模式:
为其他对象提供一种代理以控制对该对象的访问;
通过代理对象实现调用对象和被调用对象之间的解耦,当被调用者对象改变时,只要保证代理独享的接口不变,调用对象的使用方式无需改变;
代理模式的实现一般采用:
创建一个公开接口或抽象类,,被调用类和代理类同时实现该接口,代理类的方法调用被代理类的方法来实现,这样调用类直接调用代理类就间接调用了被调用类。
3.代理模式的应用:
远程代理:
为一个对象在不同的地址空间创建局部代表,这样类隐藏对象存在于不同地址空间;
虚拟代理:
需要创建开销很大的对象时,通过虚拟代理存放需要很长时间实例化的真实对象;
安全代理:
用来控制真实对象访问时的权限;
智能指引:
当调用真实对象时,代理会处理另外一些事情。
4.扩展说明
代理是将目标对象的复杂性进行封装,通过代理来完成调用,针对客户端调用的目标类型完成接口定义,并且目标对象要实现这个接口,代理类也要实现这个接口。
某些情况下,客户不想或者不能够直接引用一个对象,代理对象可以在客户和目标对象直接起到中介的作用。
客户端分辨不出代理主题对象与真实主题对象。
代理模式可以并不知道真正的被代理对象,而仅持有一个被代理对象的接口
5.代理模式和外观模式的区别:
外观模式也是屏蔽复杂性的,但是外观模式不会实现客户端调用的目标类型接口。
一般客户端调用外观模式的方法都是直接调用。
代理模式中对客户端目标对象类型抽象接口具体化了
外观模式是代理模式中一种特殊的子级模式(广泛的,非约束性).
第十一章桥接模式—将抽象部分和实现部分分离,使他们都可以独立的变化。
1.桥接模式:
在软件系统中,如何应对”多维度的变化”;将抽象部分与实现部分分离。
2.合成/聚合复用原则:
合成和聚合都是关联关系的特殊种类;
聚合表示一种弱的”拥有”关系,A对象可以包含B,但是B对象不是A对象的一部分;
合成表示一种强的拥有关系,体现了严格的整体和部分的关系,部分和整体的生命周期都是一样的。
3.扩展说明:
Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系,使得抽象和实现可以沿着各自的维度来变化。
所谓抽象和实现沿着各自维度的变化,即“子类化”它们,得到各个子类之后,便可以任意它们,从而获得不同平台上的不同型号。
第十二章迭代器模式
1.应用场景:
访问一个聚合对象的内容而无需要暴露它的内部表示;
支持对聚合对象的多种遍历;
为遍历不同的聚合结构提供一个统一的接口(即支持多态迭代)。
2.迭代器模式(Iterator)
又叫做游标模式;
提供一种方法访问一个容器对象中各个元素,而又不需暴露该对象的内部细节;迭代器模式为容器而生的;
3.迭代器模式的四种角色:
抽象集合:
一个接口,规定了具体集合需要实现的操作;
具体集合:
具体的集合按照一定的结构存储对象;具体集合应该有一个方法,该方法返回一个针对该集合的具体迭代器。
抽象迭代器:
一个接口,规定了遍历具体集合的方法,比如next()方法;
具体迭代器:
实现了迭代器接口的类实例。
4.扩展说明:
优点:
简单了遍历方式;可以提供很多遍历方式(正序遍历,倒序遍历);封装性良好。
缺点:
对于比较简单的遍历(像数组或者有序列表),使用迭代器方式遍历较为繁琐,大家可能都有感觉,像ArrayList,使用for循环和get方法来遍历集合。
5.小结:
迭代器模式是与集合共生共死的
大多数语言在实现容器的时候都给提供了迭代器,假如我们要实现一个这样的新的容器,当然也需要引入迭代器模式。
SoftwareArchitecture(SA)——软件体系结构
第十四章管道过滤器
1.软件体系结构==构件(各种基本的软件构造模块(函数,对象,模式等等))+连接件(将他们组合起来形成完整的软件系统)+约束。
2.软件体系结构风格分类:
经典SA风格:
分类典型风格
数据流风格批处理序列,管道和过滤器
调用/返回风格主程序/子程序,面向对象,层次结构
独立构件风格进程通信,事件系统
虚拟机风格解释器,基于规则系统
仓库风格数据库系统,黑板系统
其他常用SA风格
分类典型风格
通讯类SOA,MessageBus
部署类Client/Server,3-Tier,N-tier,Peerto-
peer(P2P),,CloudComputing
领域类Search-orientedarchitecture,Web2.0
交互类MVC,SeparatedPresentation
结构类Plugin,Sharednothingarchitecture
3.数据流风格:
数据从一个处理单元流入到另一个处理单元,每经过一个单元就做一次转换。
(数据流风格不是某个过程的数据流图,它描述的是系统体系结构级别的设计)。
4.数据流风格的基本构件:
基本构件:
数据处理;构件接口:
输入端口和输出端口。
连接件:
数据流
5.数据流风格的拓扑结构
任意拓扑结构的图:
一般来说,数据的流向是无序的;我们主要关注近似线性的数据流或在限度内的循环数据流。
6.三种典型的数据流风格:
管道/过滤器;批处理;过程控制。
7.管道—过滤器风格的直观结构:
8.管道—过滤器风格的基本构成:
构件:
过滤器,处理数据流:
一个过滤器封装了一个处理步骤;
数据源点的数据终止点可以看做是特殊的过滤器。
连接件:
管道,连接一个源和一个目的的过滤器—转发数据流。
连接器定义了数据流图,形成拓扑结构。
9.过滤器:
目的:
将源数据变换成目标数据;
过滤器对数据流的五种变换类型:
增加/丰富;删减/浓缩;转换;合并;分解
10.过滤器读取和处理数据流的方式:
递增的读取和消费数据流;在输入被完全消费之前,输出便产生了。
11.过滤器的一些基本特征:
无上下文信息;不保留状态;对其他过滤器无任何了解;可使用数据缓冲区临时保存数据流:
蓄水池。
12.管道:
作用:
在过滤器之间传送数据:
单向流;可能具有缓冲区;
不同的管道中流动的数据流,具有不同的数据格式;
原因:
数据在经过每一个过滤器时,被过滤器进行了操作;因而发生了变化。
13.数据流的分类:
推式:
前面的过滤器把新产生的数据推入管道;
拉式:
随后的过滤器从管道中拉出所需数据;
推拉式:
过滤器以循环的方式,从管道中拉出其输入数据,并将其处理产生的数据压入后续管道。
14.过滤器的分类:
主动过滤器:
具有pull/push类型的过滤器;
被动过滤器:
拉式策略;推式策略。
系统中至少有一个主动过滤器
15.过滤器状态转换图:
16.管道过滤器风格的典型应用:
Unix管道;DOS管道命令;
编译器;图像处理;信号处理;声音和图像处理。
17.管道过滤器风格的其他应用:
网络监听和流量控制;电话通信;网络安全;金融领域;工业生产;网页日志不点击流。
18.管道—过滤器的风格
优点:
使得系统中的构件具有良好的隐蔽性和高内聚、低耦合的特点;设计者可以将整个系统的输入、输出特性简单的理解为各个过滤器功能的合成;支持功能模块的复用;较强的可维护性和可扩展性;支持一些特定的分析,如吞吐量计算和死锁检测等;具有并发性。
缺点:
交互式处理能力弱;设计者也许不得不花费精力协调两个相对独立;但又存在某种关系的数据流之间的关系;过滤器具体实现的复杂性;往往导致系统处理过程的成批操作
19.批处理:
数据流风格的另外一种模型;数据是逐次输入、累积保存、成批处理的;输入大量的记录,处理后产生汇总性的输出;每个处理步骤是一个独立的程序;每一步必须在前一步结束后才能开始;数据必须是完整的,以整体的方式传递。
21.批处理风格基本构成
基本构件:
独立的应用程序
连接件:
某种类型的媒质
连接件定义了相应的数据流图,表达拓扑结构
每一步骤必须在前一步骤完全结束之后方能开始
20.批处理与管道-过滤器的比较
相似点:
把任务分解成为一系列固定顺序的计算单元
彼此间只通过数据传递交互
不同点:
BatchSequential:
整体传递数据;构件粒度较大;延迟高,实时性差;无并发;
Pipe:
增量;构件粒度较小;实时性;可并发
21.批处理体系结构
优点:
支持转换的复用,顺序的戒是并发的处理;很直观,许多人都能将它们的工作理解成输入和输出处理。
缺点:
需要一种适合于所有转换的通用格式;若要求转换是独立的且可复用的,需要定义一种对所有数据都通用的标准格式;可能无法集成那些不兼容数据格式的转换。
第十五章MVC架构
1.MVC的设计思想:
把一个应用的输入,处理,输出流程按照Model,View,Controller的方式进行分离。
2.MVC的不足:
View是可以直接访问Model的;View是依赖于Model的;有一些业务逻辑在View里实现。
3.表现层的演化——MVP:
ModelViewPresenter
模型与视图完全分离;
可以更搞笑的使用模型,因为所有的交互都发生在一个地方——Presenter内部;
我们可以将一个Presener用于多个视图,而不需要改变改变Presenter的逻辑,这个特性非常的有用,因为使徒的变化总是比模型的变化频繁;
如果我们把逻辑放在Presenter中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试).
4.MVC和MVP对比
.1.视图并不了解模型;2.展示器将忽略视图中使用的具体UI技术;3.视图可以被模拟,以便测试。
第十六章插件结构
1.使用插件的意义:
支持特性拓展;支持第三方开发;较低应用程序大小。
——插件不是简单的功能扩展。
2.插件技术:
在程序设计过程中,把应用程序分成两部分:
宿主程序,插件,契约。
3.插件系统实现步骤:
设计契约——设计插件——设计宿主程序
4.动态连接:
在链接时并没有将库函数中的函数连接到应用程序的可执行文件。
链接是在程序中运行时动态来执行的。
采用动态链接方式的库文件即为DLL(DynamicLinkableLibrary).
5.DLL到进程地址空间的映射:
要调用DLL中的函数,首先必须把DLL的文件映像映射到调用进程的地址空间中。
有两种方法可以实现这一映射:
装入时动态连接;运行时动态连接.
6.后续补充
什么是软件体系结构由哪三个部分组成构件、连接件、约束定义软件体系结构为软件系统提供了一个结构、属性和行为的高级抽象。
它不仅指定了系统的组织结构和拓扑结构并且显示了系统需求和构成系统的元素之间的对应关系提供了一些设计决策的基本原理
了解设计模式的区别。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 河北 师范大学 软件 体系结构 期末 复习 总结