软件体系结构复习纲要汇总.docx
- 文档编号:2150529
- 上传时间:2023-05-02
- 格式:DOCX
- 页数:23
- 大小:191.78KB
软件体系结构复习纲要汇总.docx
《软件体系结构复习纲要汇总.docx》由会员分享,可在线阅读,更多相关《软件体系结构复习纲要汇总.docx(23页珍藏版)》请在冰点文库上搜索。
软件体系结构复习纲要汇总
《软件体系结构》复习纲要
课程名称:
软件体系结构
考试时间:
120分钟
考核方式:
笔试、闭卷
题型:
选择、填空、简答、分析、综合应用
分数分配:
10、10、30、30、20
第一章知识要点(要求:
标记、理解、应用,题型分布:
选择、填空)
体系结构的定义,回答一个即可(一定要提到构件)
构件的内部属性,外部属性。
衡量模块好坏的指标(内聚耦合)
体系结构和体系结构的概述有什么区别。
反映系统的内在属性。
选择件是构件。
模块是模块化技术定义的,“元素”可以是任一种。
软件体系结构技术是指导开发新过程,提高软件开发效率。
体系结构的活动,可以贯穿整个软件开发过程。
将技术应用于软件的开发过程,在前期的分析设计用得比较多。
1、体系结构基础概念、定义、属性。
软件体系结构是系统的一个或多个结构,它包括:
软件的组成元素(构件),这些(构件)元素的外部可见特性,以及这些元素(构件)之间的相互关系。
基本术语
模型:
现实的简化抽象
建模技术:
形式化、半形式化、非形式化
定义1:
SA={构件、连接器、约束}
构件:
反映服务
连接器:
连接器定义了交互协议和策略,形成动态关系
与面向对象不同,并非静态的单元,是动态的单元
定义2:
SA是系统的顶级分解,分解的产物是系统的主要构件
说明:
与模块技术等价,仅有静态结构,与定义1相差甚远。
定义3:
SA={构件、连接器、约束、利益关系者、推理}
说明:
与定义1对比,增加了功能和其它质量。
定义的含义-1:
系统由一个或多个结构组成,其中任何一个结构并不能与体系结构等同。
定义的含义-2:
每个系统都有一个体系结构。
每个系统都是由元素和元素之间的关系组成。
最简单的例子,一个系统就是由一个元素和它自身的关系组成,每个系统都有体系结构,但并不意味着任何人都知晓该体系结构的存在。
如果你不明确的开发一个体系结构,你仍然拥有一个----只是不是你喜欢或期望的。
定义的含义-3:
软件体系结构是系统的抽象,体系结构定义了元素以及它们如何交互。
体系结构隐瞒了纯粹的属于局部的信息,元素的细节不属于体系结构。
元素外部可见的属性是指元素对其它元素来说
提供的服务
需要的服务
共享资源的使用等
只要某个构件的行为可从其它构件的角度观察到或者区别开,这样的行为就是体系结构的内容。
定义的含义-4:
定义中并没有明确说明什么是elements:
是一个对象?
一个实现单元?
一段进程?
一个函数库?
数据库?
商业构件?
以上都有可能,还可能是其它一些事物
各元素间的交互关系也可能有多种。
例如:
细划分,同步,调用,包含…
体系结构是一种高层设计:
正确。
体系结构是一种前期的设计活动。
体系结构是系统的总体结构:
它暗含了意思是系统只有一个结构。
而结构的多样性位于体系结构概念的核心。
体系结构是一个软件或系统的构件、构件之间的相互关系以及管理其设计和演变的原理和方针的结构:
不应包括原理和方针。
体系结构是构件和连接器:
不完全。
因为连接器是指系统运行时为传送控制和数据信息而采用的机制。
因此这种说法强调了运行时的体系结构。
2、模块化技术、抽象化技术、软件工程的基本概念
3、体系结构与描述
体系结构与体系结构描述不同。
体系结构:
一个系统的基础组织,体现在系统的构件、构件之间的关系、构件与环境的关系和指导系统设计和演化的准则。
体系结构描述:
一组对系统结构进行编档的产品。
体系结构不可见。
4、构件、连接件、约束的定义
构件的定义。
1.构件:
(Component)是软件系统的结构块单元,是软件功能设计和实现的承载体,因此,每个构件都承担着一定的功能并发挥着一定的作用,例如,中断程序、设备驱动程序、过程、各种功能库、文件等。
2.构件可以看做是模块、类、对象等一个相关功能的集合。
3.构件大都作为一个分状的实体,其内部结构和信息隐藏起来。
每个构件至少有一个接口。
接口是构件与外界发生交互的窗口。
与其他构件交互时,只需了解此构件对外的接口和提供的操作服务。
连接件的定义。
1.连接:
(Connect)是构件间建立和维护行为关联及信息传递的途径。
2.连接需要两方面的支持:
一是连接发生和维持的机制,这是实现连接的物质基础;二是连接能够正确地、无二义、无冲突地进行信息交换的保证,这就是连接进行有效信息交换的规则,称为连接的“协议”。
3.连接的本质是实现连接机制和信息交换协议,简称机制和协议。
4.连接器:
(Connector)当构件间联系关系复杂时,需要建立专门的连接构件以调度和协调构件间的关联关系,实现构件间联系的特殊构件称为连接器。
5.构件间的联系有:
消息和信号的传递,功能和方法的请求或调用,数据的传送和转换,构件间特定关系的协调和维持等,所有涉及构件间信息、行为、特性的联系和依赖。
约束。
约束的定义。
约束条件是系统属性或系统的一部分。
违反了约束条件,可能导致系统崩溃。
约束约定约束条件,边界,以及构件之间的依赖关系。
5、构件-连接器视图及其作用
1.构件-连接器视图,最重要的视图,反映运行时模型。
2.分解视图,静态结构描述。
3.分配视图,投影到外部环境,又从软件/硬件方面分为实现视图(制品视图)和部署视图。
4.行为视图,考虑时间因素,追踪和控制系统,又分为基于消息、概要活动、单元素行为视图,以及转化为用例视图。
UML是最普遍的视图。
6、体系结构活动
使用体系结构称为体系结构活动;体系结构活动带来的成本和收益需要权衡;随着软件的复杂性提高,体系结构投入成为趋势;任何阶段都可以有体系结构活动;
总之,是否运用体系结构需要决策;如同方法学、哲学,用关键原则指导解决问题;
具体活动包括:
建模、由需求导出体系结构、编档体系结构、基于体系结构文档讨论、分析、评估、实现系统与体系结构一致、用体系结构引导测试、从遗留系统中重构体系结构等。
7、其他
构件-连接器结构
动态的,运行时的结构
进程结构
并发结构
共享数据或存贮库
客户机-服务器
软件的模块结构
分解结构
使用结构
增量模型:
把软件产品分解成一系列的增量构件,在增量开发迭代中逐步加入。
每个构件由多个相互作用的模块构成,并且能够完成特定的功能。
增量开发方法的新演进版本叫做“极限程序设计(eXtremeProgramming)”。
分层结构
元素:
层(模块的聚合)
关系:
允许使用的关系
每个层就是一个虚拟机,此外,还存在一些对虚拟机之间关系的约束条件。
虚拟机:
虚拟机是一种抽象计算设备;一般说来,它是一种程序,该程序能充当其他软件和实际硬件之间的接口。
类或泛化
泛化风格支持面向对象的设计:
它是基于继承性的面向对象的系统设计的主要方法。
类图。
扩展和演化:
局部更改或变化:
体系结构的用途之一是提供稳定的结构,以便允许局部更改或变化。
泛化是一种在较高层定义共性和将差异性定义为子模块的方法。
重用:
适当的抽象可以只在接口层重用,抽象模块的定义能为重用创造机会。
“4+1”视图模型
LogicalView
支持主要的功能需求---系统应当向用户提供什么样的服务。
我们能利用“模块结构”和“构件-连接器”结构来编档“逻辑视图”。
(将模块分解风格、使用风格、泛化风格结合起来后,即可利用子系统和类等元素表示逻辑视图的结构部分;而构件-连接器视图类型则允许我们利用构件和端口表示运行时特征)
ProcessView
主要考虑的是系统的非功能属性:
如性能、可用性等。
它所面对的问题有并发、分布,系统的完整性、容错能力等。
DevelopmentView
关注的是在软件开发环境中软件模块的实际组织,软件被打包成可由单个或少量程序员开发的各种小的部分:
程序库或子系统。
一般来说子系统被组织为层次化的体系,每一层为上一层提供一个严密的、明确的接口。
DeploymentView
描述将软件系统映射到各个物理节点上。
用例视图(场景视图):
利用用例来验证和描述其它的视图。
软件体系结构是必要的:
1、表述系统的初始概要信息,为开发早期进行质量分析和评估提供帮助。
2、为系统实现提供约束条件。
3、支撑重用和软件生产线的实现。
4、为涉众之间的交流奠定基础。
5、决定如何组织团队和分配任务。
第二章知识要点(要求:
标记、理解、应用,题型分布:
填空、选择、分析、综合)
每种风格模式应用在哪个领域。
管道-过滤器应用于编译器
隐式调用(消息驱动):
界面,如:
决策自制系统
数据黑板:
专家系统(用可分析数据的模糊推理的)
控制环:
控制系统
C/S:
网络
虚拟机是作解释器的,模糊的则选择异构风格
1、模式与风格
风格与模式是相同还是不同,存在争议,可以看作一回事,也可以区分对待,关键还是定义的争议,但这并不影响其运用.
模式是某一相关问题的设计结论,是一个解决方案,是过程和实体.
风格是解决问题的一些方法特征,是解决方案的框架.
其核心内容是:
(1)控制原则
(2)质量属性
风格与模式通常从两个方面分类:
数据和控制
风格与模式划分的具体为:
数据流系统、调用返回系统、独立构件系统、虚拟机系统、中央存储系统。
数据流系统:
批处理、管道-过滤器风格
调用返回系统:
面向对象、分层风格
独立构件系统:
通信过程、事件驱动风格
虚拟机系统:
翻译、基于系统规则风格
中央存储系统(仓库):
数据库、超文本、黑板等风格
过程控制风格:
开环,闭环
其它系统:
C/S、B/S、WEB、P2P、BT等风格
2、各种模式风格
面向对象风格描述
数据及其操作被封装成抽象数据类型(对象)
特点:
封装、继承、多态
数据抽象风格(ADT)是特殊化的面向对象风格,区别在于:
ADT只有封装的特点,而没有继承和多态的特点。
优点:
因为对象对其它对象隐藏它的表示,所以可以改变一个对象的表示,而不影响其它的对象;设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。
缺点:
对象之间的耦合度比较紧:
为了使一个对象和另一个对象通过过程调用等进行交互,必须知道对象的标识。
只要一个对象的标识改变了,就必须修改所有其他明确调用它的对象;必须修改所有显式调用它的其它对象,并消除由此带来的一些副作用。
例如a使用了对象b,c也使用了对象b,那么,c对b的使用所造成的对a的影响可能是不可预测的。
面向对象风格的优点是什么?
4.模块化、易于维护扩展、重用。
基于事件的风格(隐式调用)
基于事件(event-based)的风格,又被称为隐式调用(implicitinvocation)的风格。
在此类风格的系统结构中,组件并不直接调用一个过程,而是声明或广播一个或多个事件。
系统中的其他组件可以把某一过程注册为与它所关心的事件相关联。
当某一事件发生时,系统会调用所有与之相关联的过程,即一个事件的激发隐含地导致了对其他模块的过程调用。
隐式调用的最大不足之处在于,组件对系统进行的计算放弃了主动控制。
一个组件不能假设其他组件将会对它的请求做出响应,也不能知道事件被处理的先后顺序。
分层风格
语境:
一个需要分解的大系统
问题:
假设你正在设计一个系统,它的显著特征是混合了低层与高层问题,这里的高层操作依赖于低层操作。
这样的系统往往需要一些与其垂直子划分正交的水平构建。
即几个操作处在同一个抽象层,但彼此之间在很大程度上是独立的。
优点:
支持基于抽象程度递增的系统设计,使设计者可以把一个复杂系统按递增的步骤进行分解;支持功能增强,因为每一层至多和相邻的上下层交互,因此功能的改变最多影响相邻的上下层;支持重用。
只要提供的服务接口定义不变,同一层的不同实现可以交换使用。
这样,就可以定义一组标准的接口,而允许各种不同的实现方法。
缺点:
并不是每个系统都可以很容易地划分为分层的模式,甚至即使一个系统的逻辑结构是层次化的,出于对系统性能的考虑,系统设计师不得不把一些低级或高级的功能综合起来;很难找到一个合适的、正确的层次抽象方法。
分层风格应用广泛,特点是什么?
它是如何实现一个大的系统设计的?
分解、纵向和水平分解。
调用返回风格
主程序、子调用
抽象数据类型,面向对象的风格
层次结构
特点:
用共享数据获得性能;共享数据的结构是所有模块必须知道的。
优点:
系统自然分解,符合人的处理习惯;数据共享,处理效率高。
缺点:
改变数据的表示将影响所有的模块;数据存储对所有的模块而言都是显式的,没有信息隐藏;系统构件紧耦合,难以支持复用。
独立构件风格
这种软件体系结构通过对各自部分计算的解耦操作来达到易更改的目的。
它们之间相互的传输数据,但是不直接控制双方。
消息可能传递给:
指定的参与项(交互过程风格);未指定的参与项使用发布/登陆范型(事件风格)。
独立组件架构的特点是:
系统由松耦合的一些独立运行的计算单元构成,这些单元之间通过消息传递信息。
一般情况下,这些独立的计算单元能够自主地完成一些计算任务。
消息的发出者通常并不知道谁会接收并处理这些消息,更不了解这些消息是如何被处理的。
由于系统基于消息,因此有较好的并发性能,容错性和可伸缩性。
独立组件系统中通常不存在比较明显的主-从结构。
通常只有一个比较弱的服务器,甚至没有服务器
Broker风格(代理风格)
有利于分布式的数据组织;
构件间位置透明,客户和服务器都不用考虑对方的运行位置;
具有良好的可扩展性,易于对服务器进行修改、扩展或增加服务。
3、各种模式风格的定义及其应用领域
1.管道-过滤器风格:
过滤器独立,便于重用易于维护评估,但缺乏交互性,一般用于通信和编译器。
2.面向对象风格:
模块化好,代码封装好,易于维护扩展,但引用需要较高的耦合,需知道知道对象,比较适合JAVA、C#应用。
3.事件驱动风格:
适合多元素、并发系统、扩展性好,缺点是对系统控制力弱,共享数据困难,对象间关系复杂,常用于集成环境。
4.分层风格:
支持抽象和重用,扩展与维护好,但性能可能不高。
一般用于通信协议。
5.数据中心风格:
知识库扩展好,易于扩展,适合专家系统、自然语言处理和模式识别应用。
6.解释器风格:
固定的伪码和解释器引擎结构,适合语言解释器。
7.反馈环风格:
通过学习构件和决策者构件的运用,利用学习和信息更新增强自身功能,适合于生产管理系统。
4、异构风格的集成
对于不能归于某种风格的系统,称为复合系统。
对于复合系统的构件模型被称为异构风格。
一个完善的系统可能由各种风格组成。
恰当的运用体系结构风格、满足需要的质量属性是最好的设计。
什么是“复合系统”,它有什么风格?
没有明确的风格
第三章知识要点(要求:
标记、理解、应用,题型分布:
分析、综合)
Agent结构不是简单的C/S访问,是访问平台。
平台上有很多服务点,具有代理功能,应用于网络、应用。
1、AGENT模式
2、AGENT应用案例分析
3、C/S模式应用案例分析
第四章知识要点(要求:
标记、理解、应用,题型分布:
简答、分析、综合)
UML的名词定义。
典型的风格(C2,其特征是什么)
UML是否可用于前期设计,是在总体设计之前,还是之后。
1、UML
UML(UnifiedModelingLanguage)是下面这些最好的建模方法中最好部分的集成:
商务流程模型(WorkFlow)、对象建模方法、软构件建模思想。
UML是一种用可视化方法对软件系统进行描述、实施和说明的标准语言。
支持用不同实现技术进行的软件开发全过程。
2、UML模型
3、面向对象、面向体系结构
4、各种风格特性
第五章知识要点(要求:
理解、应用,题型分布:
分析、综合)
1、架构设计
体系结构设计的原则:
抽象
分而治之
封装和信息隐蔽
模块化
高内聚和低耦合
关注点分离
策略和实现的分离
接口和实现的分离
体系结构设计方法的分析
为了获取对体系结构设计的抽象,人们已经提出了许多方法。
我们把这些体系结构设计方法分类为:
工件驱动(artifact-driven)的方法
特点:
从方法的工件描述中提取体系结构描述。
缺点:
(1)文本形式的系统需求不够清楚、精确、完整。
以它作为导出体系结构抽象的来源作用不够。
(2)子系统的语义过于简单,难以作为体系结构构件。
(3)对子系统的组合支持不足。
用例驱动(use-case-driven)的方法
目的:
作为系统预期功能及其环境的模型,并在客户和开发者之间起到合约的作用。
缺点:
(1)难以适度把握领域模型和商业模型的细节。
(2)对于如何选择与体系结构相关的用例没有提供系统的支持。
(3)用例没有为体系结构抽象提供坚实的基础。
(4)包的语义过于简单,难以作为体系结构构件。
模式驱动(pattern-driven)的方法
缺点:
(1)在处理范围广泛的体系结构问题时,模式库可能不够充分。
(2)对模式的选择仅依靠通用知识和软件工程师的经验。
(3)模式的应用并不是一个简单直接的过程,它需要对问题进行全面的分析。
(4)对于模式的组合没有提供很好的支持。
域驱动(domain-driven)的方法
主要用于产品线体系结构设计和特定领域的软件体系结构设计。
缺点:
(1)问题领域分析在导出体系结构抽象方面效果较差。
(2)解决方案领域分析不够充分。
2、模式选择
3、重点模式
数据流风格:
批处理序列、管道/过滤器风格;过程控制风格:
开环,闭环;调用/返回风格:
主程序/子程序、面向对象风格、层次结构;独立构件风格:
进程通信、事件系统;虚拟机风格:
解释器;仓库风格:
数据库系统、黑板系统;其它:
C/S;C2等
主要分析、综合应用知识要点(要求:
综合应用,题型分布:
分析、综合)
1、数据流风格及特性
数据流系统(模式):
批处理、管道-过滤器风格
语境:
处理数据流
问题:
建立一个必须处理或转换输入数据流的系统。
解决方案:
把系统分解为几个序贯的处理步骤,这些步骤采用通过系统的数据流连接---一个步骤的输出是另一个步骤的输入
过滤器组件:
是处理单元。
通过计算和增加信息来丰富数据
通过浓缩或摘录信息来提炼数据
通过以别的表示形式交付数据来转换数据
过滤器组件的类型
随后的单元从过滤器中拉出输出单元
前面的单元把新的数据压入过滤器
过滤器以循环的方式,从流水线中拉出其输入数据,并将其输出数据压入后续单元
被动过滤器、主动过滤器
过滤器组件:
增量式的处理数据。
特点:
过滤器组件是独立的。
除输入和输出外,每个过滤器不受任何其它过滤器运行的影响。
过滤器之间不共享任何信息。
每个过滤器不知道其上游或下游过滤器的ID号。
长处:
系统易于升级:
过滤器组件的重用
通过重组增加了灵活性
支持并发:
每个过滤器作为一个单独的执行任务,可以与其它过滤器并发执行。
短处:
共享状态信息或者昂贵或者不灵活(如果处理阶段需要共享大量的全局数据,则应用该模式就低效)
不适于交互处理。
往往导致批处理的方式.
数据转换的额外开销(考虑进行数值计算并使用unix管道的系统,必须在每个过滤器中把ASCII字符转换成实数或者将实现转换成ASCII字符。
一个简单的过滤器,如两个数相加,它的绝大部分处理时间消耗在格式转换上)
点评:
面向数据流的方法也是软件工程的基本方法,例如:
数据流图、杰克逊面向数据结构的方法都与数据流模式(风格)相关联。
其中采用数据流图进行建模、分析、导出概要设计的思想已成为经典技术。
2、过程控制风格及特性(反馈环风格描述)
所谓对某个过程进行控制,指设法使该控制过程的功能或特性有效达到所期望的目标。
目标可以是满足所规定的各种性能特征,也可以是在一定限制条件下,某个代表性能的量达到或者接近最佳。
开环控制:
是指被控对象的输出(被控制量)对控制器(controller)的输出没有影响。
在这种控制系统中,不依赖将被控量反送回来以形成任何闭环回路。
闭环控制:
特点是系统被控对象的输出(被控制量)会反送回来影响控制器的输出,形成一个或多个闭环。
闭环控制系统有正反馈和负反馈,若反馈信号与系统给定值信号相反,则称为负反馈(NegativeFeedback),若极性相同,则称为正反馈,一般闭环控制系统均采用负反馈,又称负反馈控制系统。
3、虚拟机风格及特性
解释器风格,通常被用来建立一种虚拟机以弥合程序的语义与作为计算引擎的硬件的间隙。
解释器实际上创建了一个软件虚拟出来的机器,因此该风格又称为虚拟机风格。
优点:
有助于应用程序的可移植性和程序设计语言的跨平台能力;可以对未实现的硬件进行仿真(有时实际测试可能是复杂的、昂贵的或危险的)。
缺点:
额外的间接层次带来了系统性能的下降。
例如:
如果不引入JIT(justintime)技术的话,java应用程序的速度相当慢。
虚拟机技术为JAVA语言提供了什么优点?
基本原理是什么?
跨平台、解释器技术原理。
4、仓库风格及特性
Component:
两大类
中心数据结构:
它表示当前的状态
独立组件的集合:
对中央数据结构进行操作
一般用于:
专家系统(没有现成、直接的解的情况下)
黑板中的知识可能相互矛盾或者有错误
黑板风格
Component:
中央数据单元、知识源、控制单元。
中央数据单元:
整个系统的核心部件,它对系统需要解决的问题预先进行了分析和定义,总结出了系统运行过程中将要出现的各种状态,并制定了这些状态下系统的相应策略。
其中的数据不只是单纯的数据信息,它们代表了状态是状态信息。
这些数据由数据源提供,数据随数据源信息的改变而变化,从而实现系统的功能。
数据源:
它们是知识库中信息的来源,彼此之间在逻辑上和物理上是相互独立的。
多个数据源之间通过中央数据单元协调进行交互
控制单元:
控制单元的驱动完全是由知识库的状态变化承担的;知识源将系统需要处理的信息源源不断地输入到知识库中,导致知识库的状态信息发生变化,当状态信息的变化符合系统预先定义好的某些控制策略时,相应的控制单元就被触发,也就实现了系统的功能控制。
数据共享风格一般应用于什么系统的开发?
与数据库技术是相同的技术吗?
专家系统、不同。
5、C/S风格及特性
适用于这样的应用系统:
它的数据和处理分布在一定范围的多个构件上,构件之间通过网络连接。
简单的客户机/服务器系统结构中,应分成两部分。
客户机负责用户输入和展示,服务器则处理低层的功能,例如数据库的运作等。
如果一个系统被划分为两类不同的但相互联系的组成部分,其中一方提出对信息或服务的请求,而另一方提供这种信息或者服务,那么这种体系结构就可看作是一种客户机/服务器模型。
Tcp/ip协议也采用了client/server模型,使用tcp/ip协议的程序分为两类。
客户程序一般可以任意选择其进行通信的端口的端口号,而服务程序往往使用较固定的端口号。
客户程序如要使用某台主机相应的服务,就只要往该服务对应的套接字上发送数据即可。
C/S风格中Server端有什么作用?
通信端之一,为Client端提供处理等服务。
6、C2风格及特性
是一种基于构件和消息的体系结构风格;是一种层次网络;某一构件只能感知层次高于自己的构件所提供的服务,而不能感知层次比自己更低的构件的服务;C2风格主要用于具有图形化用户界面的应用程序。
C2风格的通信规则要求,构件之间的所有交互必须以消息传递的方式实现。
有以下几个特点:
1)组成规则:
C2也是以构件和连接件为基础的。
C2风格中定义了构件和连接件的顶端和底端。
构件的顶端与连接件的底端相连接
构件的底端与连接件的顶端相连接
对连接到某个连接件上的构件或连接件的数目没有限制
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 体系结构 复习 纲要 汇总