软件体系结构知识点复习Word文档格式.docx
- 文档编号:1153236
- 上传时间:2023-04-30
- 格式:DOCX
- 页数:33
- 大小:326.59KB
软件体系结构知识点复习Word文档格式.docx
《软件体系结构知识点复习Word文档格式.docx》由会员分享,可在线阅读,更多相关《软件体系结构知识点复习Word文档格式.docx(33页珍藏版)》请在冰点文库上搜索。
3.构架的反影响力
・构架会影响开发组织的结构
・构架会影响开发组织的目标
・构架会影响客户对下一个系统的要求
・构建系统的过程丰富了整个开发团队的经验,从而将影响设计师对后继系统的设计
・一些系统会影响并实际改变软件工程的环境,也就是系统开发人员学习或实践的技术环境。
4.构架的商业周期
软件构架是技术、商业和社会等诸多因素作用的结果,而软件构架的存在反过来又会影响技术、商业和社会环境,从而影响未来的软件构架。
我们把这种相互影响的周期--从环境到软件构架又返回到环境--称作软件构架商业周期。
三、架构模式、参考模型、参考架构
1、架构模式是对元素和关系类型以及一组对其使用方式的限制的描述。
2、参考模型是一种考虑数据流的功能划分。
3、参考架构是映射到软件元素(它们相互协作,共同实现在参考模型中定义的功能)及元素之间数据流上的参考模型。
4、软件架构、架构模式、参考模型、参考架构之间的关系
5、软件架构的重要性
(1)、架构是涉众进行交流的手段。
绝大多数系统涉众都借助软件体系结构来进行彼此理解、协商、达成共识或者相互沟通。
(2)、架构是早期设计决策的体现。
构架设计是在所开发系统的最早时间点,明确对系统实现的约束条件、决定开发组织的组织结构、影响质量属性的实现等。
是系统最早期设计决策的体现,它们对软件系统的后续开发、部署和维护具有相当重要的影响。
(3)、架构是可传递、可重用的模型。
软件构架是关于系统构造以及系统各个元素工作机制的相对较小、却又能够突出反映问题的模型。
这种模型可以在多个系统之间传递,特别是可以应用到具有相似质量属性和功能需求的系统中,并能够促进大规模软件的系统级复用。
四、架构的结构
架构定义中指出系统由多种结构构成的,下面列出一些常见的结构。
软件结构
关系
适用环境
模块结构
分解
是一个子模块;
与之共享秘密
资源分配、项目结构化和规划;
信息隐藏、封装;
配置控制
使用
模块之间的调用
设计子集;
设计扩展
分层
只允许相邻两层之间调用模块、使用服务、提供服务等
增量式开发;
在“虚拟机”可移植性之上实现系统
类
特化:
由类创建对象或子类继承基类
泛化:
从许多对象中抽取共同特征和行为,构成类
在面向对象的设计系统中,从一个公共的模版中产生快速的、相近的实现
组件-连接器结构
客户机-服务器
与之通信;
依赖于
分布式操作;
关注点分离;
性能分析;
负载平衡
进程
与之并发运行、可能会与之并发运行;
排除;
优先于等
调度分析;
性能分析
并发
在相同的逻辑线程上运行
确定存在资源争用,线程可以交叉、连接、被创建或被杀死的位置
共享数据
产生数据;
使用数据
性能;
数据完整性;
可修改性
分配结构
部署
分配给;
移植到
性能、可用性、安全性分析
实现
存储在
配置控制、集成、测试活动
工作分配
分配到
项目管理、最佳利用专业技术、管理通用性
五、软件体系结构几种建模方法
1.结构模型
这是一个最直观、最普遍的建模方法。
这种方法以体系结构的构件、连接件和其他概念来刻画结构,并力图通过结构来反映系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质等。
研究结构模型的核心是体系结构描述语言。
2.框架模型
框架模型与结构模型类似,但它不太侧重描述结构的细节而更侧重于整体的结构。
框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
3.功能模型
功能模型认为体系结构是由一组功能构件按层次组成,下层向上层提供服务。
功能模型可以看作是一种特殊的框架模型。
4.动态模型
动态模型是对结构或框架模型的补充,研究系统的“大颗粒”的行为性质。
例如,描述系统的重新配置或演化。
动态可以指系统总体结构的配置、建立或拆除通信通道或计算的过程。
5.过程模型
过程模型研究构造系统的步骤和过程。
六“4+1”模型
示意图:
含义:
“4+1”视图模型从5个不同的视角-逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。
每一个视图只关心系统的一个侧面,5个视图结合在一起才能反映系统的软件体系结构的全部内容。
1.逻辑视图
逻辑视图主要支持系统的功能需求,即系统提供给最终用户的服务。
在逻辑视图中,系统分解成一系列的功能抽象,这些抽象主要来自问题领域。
这种分解不但可以用来进行功能分析,而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。
在面向对象技术中,通过抽象、封装和继承,可以用对象模型来代表逻辑视图,用类图来描述逻辑视图。
逻辑视图中使用的风格为面向对象的风格,逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。
2.开发视图
开发视图也称模块视图,主要侧重于软件模块的组织和管理。
开发视图要考虑软件内部的需求,如软件开发的容易性、软件的重用和软件的通用性,要充分考虑由于具体开发工具的不同而带来的局限性。
开发视图通过系统输入输出关系的模型图和子系统图来描述。
在开发视图中,最好采用4-6层子系统,而且每个子系统仅仅能与同层或更低层的子系统通讯,这样可以使每个层次的接口既完备又精练,避免了各个模块之间很复杂的依赖关系。
设计时要充分考虑,对于各个层次,层次越低,通用性越强,这样,可以保证应用程序的需求发生改变时,所做的改动最小。
开发视图所用的风格通常是层次结构风格。
3.进程视图
进程视图侧重于系统的运行特性,主要关注一些非功能性的需求。
进程视图强调并发性、分布性、系统集成性和容错能力,以及从逻辑视图中的主要抽象如何适合进程结构。
它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。
进程视图可以描述成多层抽象,每个级别分别关注不同的方面。
在最高层抽象中,进程结构可以看作是构成一个执行单元的一组任务。
它可看成一系列独立的,通过逻辑网络相互通信的程序。
它们是分布的,通过总线或局域网、广域网等硬件
资源连接起来。
4.物理视图
物理视图主要考虑如何把软件映射到硬件上,它通常要考虑到系统性能、规模、可靠性等。
解决系统拓扑结构、系统安装、通讯等问题。
当软件运行于不同的节点上时,各视图中的构件都直接或间接地对应于系统的不同节点上。
因此,从软件到节点的映射要有较高的灵活性,当环境改变时,对系统其他视图的影响最小。
大型系统的物理视图可能会变得十分混乱,因此可以与进程视图的映射一道,以多种形式出现,也可单独出现。
5.场景
场景可以看作是那些重要系统活动的抽象,它使四个视图有机联系起来,从某种意义上说场景是最重要的需求抽象。
在开发体系结构时,它可以帮助设计者找到体系结构的构件和它们之间的作用关系。
同时,也可以用场景来分析一个特定的视图,或描述不同视图构件间是如何相互作用的场景可以用文本表示,也可以用图形表示。
七、软件体系结构风格定义、含义
1.定义与含义:
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
体系结构风格定义了一个系统家族,即定义一个词汇表和一组约束。
词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。
体系结构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。
2.经典的体系结构风格的分类
数据流风格:
批处理序列;
管道/过滤器。
调用/返回风格:
主程序/子程序;
面向对象风格;
层次结构。
独立构件风格:
进程通讯;
事件系统。
虚拟机风格:
解释器;
基于规则的系统。
仓库风格:
数据库系统;
超文本系统;
黑板系统。
3.几种体系结构风格
(1)管道/过滤器
每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流。
这个过程通常通过对输入流的变换及增量计算来完成,所以在输入被完全消费之前,输出便产生了。
这里的构件被称为过滤器,这种风格的连接件就象是数据流传输的管道,将一个过滤器的输出传到另一过滤器的输入。
组成:
构件(过滤器)和连接件(管道)
优点:
・使得软构件具有良好的隐蔽性和高内聚、低耦合的特点;
・允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成;
・支持软件重用。
只要提供适合在两个过滤器之间传送的数据,任何两个过滤器都可被连接起来;
・系统维护和增强系统性能简单。
新的过滤器可以添加到现有系统中来;
旧的可以被改进的过滤器替换掉;
・允许对一些如吞吐量、死锁等属性的分析;
・支持并行执行。
每个过滤器是作为一个单独的任务完成,因此可与其它任务并行执行。
缺点:
・通常导致进程成为批处理的结构。
・不适合处理交互的应用。
・因为在数据传输上没有通用的标准,每个过滤器都增加了解析和合成数据的工作,这样就导致了系统性能下降,并增加了编写过滤器的复杂性。
例子:
Unix,DOS中的重定向:
(dir|sort),perl脚本语言,编译器
(2)数据抽象和面向对象组织
这种风格建立在数据抽象和面向对象的基础上,数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。
这种风格的构件是对象,或者说是抽象数据类型的实例。
对象是一种被称作管理者的构件,因为它负责保持资源的完整性。
对象是通过函数和过程的调用来交互的。
构件(对象)
结构:
对象抽象数据类型过程调用
・因为对象对其它对象隐藏它的表示,所以可以改变一个对象的表示,而不影响其它的对象;
・设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。
缺点:
・为了使一个对象和另一个对象通过过程调用等进行交互,必须知道对象的标识。
只要一个对象的标识改变了,就必须修改所有其他明确调用它的对象;
・必须修改所有显式调用它的其它对象,并消除由此带来的一些副作用。
例如,如果A使用了对象B,C也使用了对象B,那么,C对B的使用所造成的对A的影响可能是料想不到的。
(3)基于事件的隐式调用
构件不直接调用一个过程,而是触发或广播一个或多个事件。
系统中的其它构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程,这样,一个事件的触发就导致了另一模块中的过程的调用。
这种风格的构件是一些模块,模块既可以是一些过程,又可以是一些事件的集合。
过程可以用通用的方式调用,也可以在系统事件中注册一些过程,当发生这些事件时,过程被调用。
这种风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。
这样不能假定构件的处理顺序,甚至不知道哪些过程会被调用,因此,许多隐式调用的系统也包含显式调用作为构件交互的补充形式。
构件(一些模块,模块既可以是一些过程,又可以是一些事件的集合)
・为软件重用提供了强大的支持。
当需要将一个构件加入现存系统中时,只需将它注册到系统的事件中。
・为改进系统带来了方便。
当用一个构件代替另一个构件时,不会影响到其它构件的接口。
・构件放弃了对系统计算的控制。
一个构件触发一个事件时,不能确定其它构件是否会响应它。
而且即使它知道事件注册了哪些构件的构成,它也不能保证这些过程被调用的顺序。
・数据交换效率的问题。
有时数据可被一个事件传递,但另一些情况下,基于事件的系统必须依靠一个共享的仓库进行交互。
在这些情况下,全局性能和资源管理便成了问题。
・既然过程的语义必须依赖于被触发事件的上下文约束,关于正确性的推理存在问题。
(4)分层系统
层次系统组织成一个层次结构,每一层为上层服务,并作为下层客户。
在一些层次系统中,除了一些精心挑选的输出函数外,内部的层只对相邻的层可见。
这样的系统中构件在一些层实现了虚拟机(在另一些层次系统中层是部分不透明的)。
连接件通过决定层间如何交互的协议来定义,拓扑约束包括对相邻层间交互的约束。
这种风格支持基于可增加抽象层的设计。
允许将一个复杂问题分解成一个增量步骤序列的实现。
由于每一层最多只影响两层,同时只要给相邻层提供相同的接口,允许每层用不同的方法实现,同样为软件重用提供了强大的支持。
构件,连接件
・优点:
・支持基于抽象程度递增的系统设计,使设计者可以把一个复杂系统按递增的步骤进行分解;
・支持功能增强,因为每一层至多和相邻的上下层交互,因此功能的改变最多影响相邻的上下层;
・支持重用。
只要提供的服务接口定义不变,同一层的不同实现可以交换使用。
这样,就可以定义一组标准的接口,而允许各种不同的实现方法。
・并不是每个系统都可以很容易地划分为分层的模式,甚至即使一个系统的逻辑结构是层次化的,出于对系统性能的考虑,系统设计师不得不把一些低级或高级的功能综合起来;
・很难找到一个合适的、正确的层次抽象方法。
(5)仓库系统及知识库
有两种不同的构件:
中央数据结构说明当前状态,独立构件在中央数据存贮上执行。
控制原则的选取产生两个主要的子类。
若输入流中某类时间触发进程执行的选择,则仓库是一传统型数据库;
另一方面,若中央数据结构的当前状态触发进程执行的选择,则仓库是一黑板系统。
构件(中央数据结构,独立构件)
例子:
黑板系统的传统应用是信号处理领域,如语音和模式识别。
另一个应用是松耦合代理数据共享存取。
视频会议系统中有一个共享的白板可以用来交流。
(6)C2风格
通过连接件绑定在一起的按照一组规则运作的并行构件网络。
C2风格中的系统组织规则如下:
・系统中的构件和连接件都有一个顶部和一个底部;
・构件的顶部应连接到某连接件的底部,构件的底部则应连接到某连接件的顶部,而构件与构件之间的直接连接是不允许的;
・一个连接件可以和任意数目的其它构件和连接件连接;
・当两个连接件进行直接连接时,必须由其中一个的底部到另一个的顶部。
构件、连接件
特点:
・系统中的构件可实现应用需求,并能将任意复杂度的功能封装在一起;
・所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的;
・构件相对独立,构件之间依赖性较少。
系统中不存在某些构件将在同一地址空间内执行,或某些构件共享特定控制线程之类的相关性假设。
(7)C/S
C/S软件体系结构是基于资源不对等,且为实现共享而提出来的,是20世纪90年代成熟起来的技术,C/S体系结构定义了工作站如何与服务器相连,以实现数据和应用分布到多个处理机上。
C/S体系结构有三个主要组成部分:
数据库服务器、客户应用程序和网络。
数据库服务器、客户应用程序和网络
优点:
・模型思想简单,易于人们理解和接受。
・灵活、易维护与扩充:
系统的客户应用程序和服务器构件分别运行在不同的计算机上,系统中每台服务器都可以适合各构件的要求,这对于硬件和软件的变化显示出极大的适应性和灵活性,而且易于对系统进行扩充和缩小。
・资源可以进行合理配臵:
在C/S体系结构中,系统中的功能构件充分隔离,客户应用程序的开发集中于数据的显示和分析,而数据库服务器的开发则集中于数据的管理,不必在每一个新的应用程序中都要对一个DBMS进行编码。
将大的应用处理任务分布到许多通过网络连接的低成本计算机上,以节约大量费用。
・开发成本较高
・客户端程序设计复杂
(8)B/S
浏览器/服务器(B/S)风格就是三层应用结构的一种实现方式,其具体结构为:
浏览器/Web服务器/数据库服务器。
B/S体系结构主要是利用不断成熟的WWW浏览器技术,结合浏览器的多种脚本语言,用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能,并节约了开发成本。
从某种程度上来说,B/S结构是一种全新的软件体系结构。
浏览器/Web服务器/数据库服务器
・基于B/S体系结构的软件,系统安装、修改和维护全在服务器端解决。
用户在使用系统时,仅仅需要一个浏览器就可运行全部的模块,真正达到了“零客户端”的功能,很容易在运行时自动升级。
・B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。
・没有集成有效的数据库处理功能,对数据处理功能不强。
・安全性难以控制。
・采用B/S体系结构的应用系统,在数据查询等响应速度上,要远远地低于C/S体系结构。
・B/S体系结构的数据提交一般以页面为单位,数据的动态交互性不强,不利于在线事务处理(OLTP)应用
为什么要使用B/S与C/S混合体系结构:
・B/S与C/S混合是一种典型的异构体系结构。
・传统的C/S体系结构并非一无是处,而新兴的B/S结构也并非十全十美。
C/S结构和B/S结构还将长期共存。
(9)CORBA体系结构
CORBA是由对象管理组织OMG制定的一个工业标准,主要目标是提供一种机制,使得对象可以透明的发出请求和获得应答,从而建立起一个异质的分布式应用环境。
1991年,OMG基于面向对象技术,给出了对象请求代理为中心的对象管理结构。
CORBA技术规范
接口定义语言(IDL)
接口池(IR)
动态调用接口(DII)
对象适配器(OA)
特点
◎引入中间件作为事务代理,完成客户机向服务对象方(Server)提出的业务请求。
◎实现客户与服务对象的完全分开,客户不需要了解服务对象的实现过程以及具体位置。
◎提供软总线机制,使得在任何环境下、采用任何语言开发的软件只要符合接口规范的定义,均能够集成到分布式系统中。
◎采用面向对象的软件实现方法开发应用系统,实现对象内部细节的完整封装,保留对象方法的对外接口定义。
(10)正交软件体系结构
正交软件体系结构由组织层和线索的构件构成。
层是由一组具有相同抽象级别的构件构成。
每条线索完成系统中相对独立的一部分功能,由完成不同层次功能的构件组成。
每条线索的实现与其他线索的实现无关或关联很少。
特征
◎系结构由不同功能的n(n>
1)个线索(子系统)组成;
◎系统具有m(m>
1)个不同抽象级别的层;
◎线索之间是相互独立的(正交的);
◎同一层的构件不能相互调用;
◎系统有一个公共驱动层(一般为最高层)和公共数据结构(一般为最低层)。
◎结构清晰,易于理解。
线索功能相互独立,不进行互相调用,结构简单、清晰。
构件的位置就能说明它的抽象级别和担负功能。
◎易修改,可维护性强。
线索之间相互独立,对一个线索的修改不会影响到其他线索。
系统功能的增加或减少,只需相应的增删线索构件族,而不影响整个正交体系结构。
◎可移植性强,重用粒度大。
正交结构可以为一个领域内的所有应用程序所共享,这些软件有着相同或类似的层次和线索,可以实现体系结构级的重用。
(11)基于层次消息总线的体系结构(HierarchyMessageBus,HMB)
◎基于HMB的风格,支持构件的分布和并发,构件之间通过消息总线进行通信。
◎消息总线是系统的连接件,负责消息的分派,传递和过滤以及处理结果的返回。
◎各个构件挂在消息总线上,向总线登记感兴趣的消息类型;
◎构件根据需要发出消息,由消息总线负责把该消息分派到系统中所有对此消息感兴趣的构件;
◎构件收到消息后,根据自身状态对消息进行响应,并通过总线返回处理的结果。
◎消息是构件间唯一的通信方式
◎复杂构件可分解为比较低层的子构件,这些构件通过局部消息总线进行连接,这种复杂的构件成为复合构件。
(12)为什么要使用异构风格
不同的结构有不同的处理能力的强项和弱点,一个系统的体系结构应该根据实际需要进行选择,以解决实际问题。
关于软件包、框架、通信以及其他一些体系结构上的问题,目前存在多种标准。
即使在某段时间内某一种标准占统治地位,但变动最终是绝对的。
一些遗留下来的代码,它们仍有效用,但是却与新系统有某种程度上的不协调。
然而在许多场合,将技术与经济综合进行考虑时,总是决定不再重写它们。
八、软件体系结构的描述的几种方法
(1)图形表达工具
矩形框和有向线段组合而成。
矩形框代表抽象构件,框内标注的文字为抽象构件的名称。
有向线段代表辅助各构件进行通讯、控制或关联的连接件。
简洁、易懂、使用广泛。
缺点:
图形在术语和表达语义上存在着一些不规范和不精确,不同系统和不同文档之间有着不一致甚至矛盾。
(2)模块内连接语言MIL(ModuleInterconnectionLanguage)
将一种或几种传统程序设计语言的模块连接起来的语言
程序设计语言和模块内连接语言具有严格的语义基础,因此能支持对较大的软件单元进行描述。
诸如定义/使用和扇入/扇出等操作。
例如,Ada语言采用use实现包的重用,Pascal语言采用过程(函数)模块的交互等。
MIL方式对模块化的程序设计和分段编译等程序设计与开发技术确实发挥了很大的作用。
但是由于这些语言处理和描述的软件设计开发层次过于依赖程序设计语言,因此限制了它们处理和描述比程序设计语言元素更为抽象的高层次软件体系结构元素的能力。
(3)基于软构件的系统描述语言
基于软构件的系统描述语言将软件系统描述成一种是由许多以特定形式相互作用的特殊软件实体构造组成的组织或系统。
是一种以构件为单位的软件系统描述方法。
可以用来在一个较高的抽象层次上对系统的体系结构建模。
如Darwin最初用作设计和构造复杂分布式系统的配臵说明语言,因具有动态特性,也可用来描述动态体系结构。
但是他们所面向和针对的系统元素仍然是一些层次较低的以程序设计为基础的通信协作软件实体单元,而且这些语言所描述和表达的系统一般而言
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 体系结构 知识点 复习