为什么要研究软件体系结构.docx
- 文档编号:9976832
- 上传时间:2023-02-07
- 格式:DOCX
- 页数:37
- 大小:1.74MB
为什么要研究软件体系结构.docx
《为什么要研究软件体系结构.docx》由会员分享,可在线阅读,更多相关《为什么要研究软件体系结构.docx(37页珍藏版)》请在冰豆网上搜索。
为什么要研究软件体系结构
软件危机的表现
1.软件成本日益增长
2.开发进度难以控制
3.软件质量差
4.软件维护困难
软件危机的原因
1.用户需求不明确
2.缺乏正确的理论指导
3.软件规模越来越大
4.软件复杂度越来越高
如何克服软件危机——软件工程
1.软件工程方法为软件开发提供了“如何做”的技术,是完成软件工程项目的技术手段;
2.软件工具为软件工程方法提供了自动的或半自动的软件支撑环境;
3.软件工程过程将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。
软件重用:
1软件部件
缩短开发时间和开销
改进可靠性和质量
2经济方面
重用需要早期投入
需要管理层的长远考虑的支持
重用获得的收益必须大于风险损失
3技术困难
系统的部件不容易标识
部件的粒度太大或太小
部件不能提供恰好所需的功能
部件集成复杂度高
1为什么要研究软件体系结构?
软件体系结构:
一种解决方法
软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象,由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
不仅指定了系统的组织结构和拓扑结构,而且显示了系统需求和构成系统的元素之间的对应关系,提供了一些设计决策的基本原理。
2根据软件体系结构的定义,你认为软件体系结构的模型应该由哪些部分组成?
软件体系结构三要素
部件:
计算或保存数据的实体
–例如:
●客户
●服务器
●数据库
●过滤器
●ADT
–部件可以是简单的或复合的
连接器
–对体系结构元素间的交互以及交互规则建模
–例如:
●过程调用
●共享变量
●客户-服务器间的协议
●数据库访问协议
●异步事件广播
配置/拓扑逻辑
–部件和连接器构成的连接图,描述了体系结构的属性:
●正确连接
●并发和分布属性
●设计启发和风格
–复合部件也是一种配置
3在软件体系结构研究与应用中,你认为还有哪些不足之处?
好的体系结构的特征
●可伸缩性的
●简单
●亲切的
●关系清楚明了
●职责分布明确
●效益和技术平衡
4软件体系结构的意义
●是风险承担者进行交流的手段
●是早期设计决策的体现
●是可传递和可重用的模型
●基于体系结构的软件开发方法
●问题定义
●软件需求
●软件体系结构
●软件设计
●软件实现
●特定领域的体系结构框架(DSSA)
●将体系结构理论应用于具体领域
●有效地实现重用
●软件产品线体系结构
●相同的体系结构可创建多个不同功能的多个系统
●软件生产线
●建立评价软件体系结构的方法
●体系结构权衡分析法(ATAM)
●软件体系结构分析法(SAAM)
●中间设计的积极评审(ARID)
5试说明从哪些方面描述软件体系结构,画图进行详细说明
四个角度
●概念:
系统的主要构件及其关系
●模块:
功能分解和层次结构
●运行:
系统的动态结构
●代码:
各种代码和库函数在开发环境中的组织
“4+1”视图模型
●每个视图只关心系统的一个侧面,5个视图结合在一起才能反映系统的软件体系结构的全部内容。
逻辑视图
●主要支持系统的功能需求,即系统最终提供给用户的服务。
–系统分解成一系列的功能抽象
–服务抽象来自问题领域
●面向对象技术中,通过抽象、封装和继承,可用对象模型来代表逻辑视图,用类图来描述逻辑视图。
开发视图
●主要侧重于软件模块的组织和管理;
●考虑软件内部的需求,如软件开发的容易性、软件的重用和软件的通用性,要充分考虑由于具体开发工具的不同而带来的局限性。
●通过系统输入输出关系的模型图和子系统图来描述
●开发视图最好采用4~6层子系统,而且每个子系统仅能与同层或更底层的子系统通讯;
●对各个层次,层次越低,通用性越强;
●开发视图的风格为层次结构。
进程视图
●侧重于系统的运行特性,主要关注一些非功能性的需求
–系统的性能和可用性
●强调并发性、分布性、系统集成性和容错能力,以及从逻辑视图中的主要抽象如何适合进程结构。
也具体定义逻辑视图中的各个类的操作具体是在哪个线程中被执行。
●可以描述成多层抽象,每个级别关注不同的方面。
–在最高层抽象中,进程结构可以看做是构成一个执行单元的一组任务
物理视图
●主要考虑如何把软件映射到硬件上,需要考虑到系统性能、规模、可靠性等,解决系统拓扑结构、系统安装、通信等问题。
●当软件运行于不同结点上时,各视图中的构件都直接或间接地对应于系统的不同结点上,因此,从软件到结点的映射要有较高的灵活性,当环境改变时,对其他视图的影响最小。
场景
●可以看做是重要系统活动的抽象,它使4个视图有机联系起来;
●是最重要的需求抽象;
●在开发体系结构时,帮助设计者找到体系结构的构件和它们之间的关系;
●也可用场景来分析一个特定的视图,或描述不同视图间是如何相互作用的。
6软件体系结构应用现状
●体系结构发现、演化和重用
–如何从现有系统中提取软件的体系结构
–系统需求、技术、环境、分布等因素的变化而最终导致软件体系结构的变动称为演化
●体系结构扩展:
静态修改
●体系结构动态性:
运行时的变化
–体系结构重用
●基于体系结构的软件开发方法
–问题定义
–软件需求
–软件体系结构
–软件设计
–软件实现
7建模概述
1.结构模型
2.框架模型
3.动态模型
4.过程模型
5.功能模型
结构模型
●最直观、最普遍的建模方法。
●以体系结构的构件、连接件和其他概念来刻画结构,并力图通过结构来反映系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质等。
●核心是体系结构描述语言。
框架模型
●不侧重描述结构的细节,而更侧重于整体的结构。
●主要以一些特殊的问题为目标建立只针对和适应这些问题的结构。
动态模型
●是对结构和框架模型的补充,研究系统的“大颗粒”的行为性质。
–描述系统的重新配置或演化
●动态可以指系统总体结构的配置、建立或拆除通信通道或计算的过程
过程模型
●研究构造系统的步骤和过程。
●结构是遵循某些过程脚本的结果。
功能模型
●认为体系结构是由一组功能构件按层次组成,下层向上层提供服务。
●一种特殊的框架模型
8软件体系结构的核心模型
●构件
●连接件
●配置
●端口
–构件只能通过接口与外界通讯,而接口由一组端口构成
●过程调用
●角色
–连接件也有接口,其接口由一组角色构成
●RPC的角色为caller和callee
●Pipe的角色为reading和writing
9引入了体系结构后,传统软件过程发生了哪些变化?
这些变化有什么好处?
●软件开发过程模型:
软件开发全过程、软件开发活动以及它们之间关系的结构框架
●指导软件开发和软件开发过程的定义
引入体系结构后,改善了使用瀑布模型的传统软件开发过程初始阶段就设计好系统的明确需求。
改善了使用迭代模型,随着软件需求的不断变化,最终软件产品可能与初始原型相差很大。
因为SA本身是可演化的,一个好的SA是清晰的,可大大减少修改的工作量;可以创建或再创建功能,用户界面,问题域模型,演化模型以满足新的软件需求
10软件体系结构的生命周期模型与软件生命周期模型有什么关系?
软件体系结构的生命周期模型
软件生命周期:
软件从提出开发开始到最终灭亡所经历的时期。
包括:
可行性研究、需求分析、概要设计、详细设计、实现、集成测试、确认测试、使用与维护、退役。
软件生命周期:
需求分析,体系结构构建,设计,实现
关系:
软件体系结构的建立应位于需求分析之后,软件设计之前。
在建立软件体系结构时,设计者主要从结构的角度对系统进行分析,最后形成框架以满足用户需求,为软件设计奠定基础。
11什么是体系结构风格?
是描述某一特定应用领域中系统组织方式的惯用模式
定义了一个系统家族,即一个体系结构定义一个词汇表和一组约束。
词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来。
体系结构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。
体系结构风格四要素:
•提供一个词汇表
•定义一套配置规则
•定义一套语义解释原则
•定义对基于这种风格的系统所进行的分析
12常见的体系结构风格
数据流系统
批处理系统
管道/过滤器系统
调用/返回系统
主程序/子程序系统,面向对象系统
独立构件
通信进程系统
事件系统
虚拟机
解释器,基于规则的系统
数据为中心的系统
数据库,超文本系统
管道和过滤器
特征
过滤器是独立实体,相互之间不共享状态
过滤器不了解其它过滤器的信息
优点
1.系统抽象度好,系统可以理解成为一个“黑盒子”,第一个管道是输入,最后一个管道是输出。
过滤器的实现对用户完全透明。
2.支持模块的复用。
只要基于相同的输入/输出理解,不同的过滤器就可以连接在一起;
3.可维护性和可扩展性较好。
只要接口一致,过滤器内部的改动与其他无关,不会影响系统表现。
4.并发性支持较好。
可以并行的设置同构过滤器,处理大规模并发流量。
5.支持一些特定的分析(流量分析、死锁判定)
数据抽象和面向对象组织
优点
1.高度模块性——对象是一个功能与数据独立的单元。
相互之间只有通过消息进行通讯。
2.封装功能——为信息隐藏提供具体的实现,用户不需要知道内部状态,只需要知道相应接口。
3.代码共享——继承性提供了一种代码共享的手段,可以避免为相同的功能实现多套代码。
4.灵活——对象的功能执行在消息传递时确定的,对象可以根据自己的特点进行功能实现。
5.易维护性——对象实现了抽象和封装。
对象的错误限制在内部,不会向外传播,易于检查和修改。
6.可扩充性——通过集成机制不断扩充功能,不影响原系统运行。
缺点
过程调用依赖于对象标识的确定。
如果一个对象要调用另外一个对象,就必须准
确的知道这个对象的标识。
某个对象的标识发生改变,就必须通知系统中所有和它有调用的对象,否则系统可能出错。
现代面向对象框架的重要问题就是解决对象的透明性(位置透明性、名字透明性等),以及对象的全局管理等。
基于事件的隐式调用
优点
1.与大部分现实社会组织模式接近;
2.存在最高管理系统,同级系统直接交互少,事件驱动系统非常适合描述并发处理和多任务操作系统;
3.可扩展性好。
新部件的加入只需要注册新的事件处理接口,不影响其他的系统部件;
4.管理部件支持递归组合,可以灵活组织系统;
5.简化客户代码,执行部件和管理部件对用户而言是透明的;
不足
1.构件自身削弱了对系统的控制能力。
发布消息的部件不能确定是否有响应,也不能确定响应顺序;
2.数据共享困难,一般需要设置全局共享缓冲区。
多个共享缓冲区权限控制较困难;
3.部件逻辑关系更加复杂,相互调用是不确定的,系统状态多变,追踪和状态再现相对困难;
13其他体系结构风格
1)分布式处理
特定拓扑结构:
星型、环型、令牌环、层次等
客户/服务器模型:
松散耦合的计算模式
(2)主程序/子程序组织
主程序调用各个子程序
通常需要提供一个控制循环
特定于领域的体系结构
DSSA:
DomainSpecificSoftwareArchitecture
缩小考虑范围
增加描述能力
提高代码复用率
提高开发效率
(4)状态转换系统
许多被动系统的公共组织是状态转换系统
这种系统根据一组状态和命名的转换来定义
这些转换可以使系统从一种状态过渡到另一种状态
14在软件开发中,采用异构结构有什么好处,其负面影响有哪些?
异构结构风格
(1)异构是不可避免的
不同风格的结构适合于不同的应用场合
新系统需要和老系统协调工作
(2)异构体系结构的复合
层次式
以某种体系结构实现的系统,其组成部分
内部可以是另一种体系结构,其连接部分
内部也可以具有体系结构。
对等式
系统以一种体系结构实现一个子系统,
以另外一种体系结构实现另一个子系统
(3)处理异构复合匹配问题的方法
不同构件之间不能协调工作的原因可能是它们
事先作了对数据表示、通信、包装、同步、语法等方面的假设(统称形式)。
解决方法(以构件A与B为例):
1形式A改变为B的形式
2在数据传输过程中从A的形式转变为B的形式?
?
3为B提供进口/出口转换器
4A与B协商以一种中间形式交流IDLRTF
负面影响:
初始化,时间,空间效率,灵活性和绝对的处理能力上差别很大。
15不同体系结构风格的比较,各自的优缺点和适用场景
所考虑的问题:
(1)处理算法的变化
(2)数据表示的变化
(3)系统功能的增强
(4)性能空间、时间
(5)复用构件的复用程度
(1)主程序/子程序加共享数据
优点:
允许数据有效地表达
计算问题被划分到不同的模块中
缺点:
处理变化的能力不足
例如:
数据存储格式的变化将影响
到几乎所有的模块
不易进行处理算法的改进与系统功能增强
对复用的支持不明显
(2)抽象数据类型
优点:
算法与数据表示可以在独立的模块中改变
对复用的支持好
缺点:
对功能增强支持不足
(3)隐式调用(事件)
优点:
对功能增强的支持好
对复用的支持好
缺点:
难以控制隐式调用模块的处理顺序
占用空间资源较多
(4)管道流水线
优点:
维护处理的直接性
支持复用
易于修改
缺点:
不便于进行引入交互机制
对空间的利用不足
16层次系统结构与基于消息的层次系统结构有什么区别?
分层系统
(2)应用
分层通信协议
操作系统
数据库系统
(3)优点
支持基于抽象程度递增的系统设计,使得设计者
可以把一个复杂系统按递增的步骤分解开。
支持功能扩展,每一层至多和相邻的层次交互。
支持复用,只要服务接口定义不变,不同的实现
可以交换使用。
(4)缺点
适应面不宽
区别:
层次消息总线风格支持构件的分发和并发,构件之间通过消息进行通信。
接口定义了构件发出和接收的消息集合。
消息是构件之间通信的唯一方式。
由于构件通过总线进行连接,并不要求各个构件具有相同的地址空间或局限在同一台机器上。
适用分布式并发系统。
层次结构,是指层与层之间逻辑保持相互独立,从而使整个系统逻辑清晰,能提高系统和软件的可维护性,可扩展性。
面向对象的。
17基于软件体系结构的设计方法
体系结构驱动,是指构成体系结构的商业、质量和功能需求的组合。
ABSD方法的3个基础:
●功能分解
●选择体系结构
●软件模板的使用
ABSD与生命周期
18请把基于软件体系结构的开发模型与其他软件开发模型进行比较。
常用的软件开发过程模型
–瀑布模型不足
缺乏灵活性
到最后阶段才能得到可运行的软件版本
–原型模型不足:
不能支持风险分析
–增量模型并行开发、管理复杂
–迭代模型通过逐步迭代,建立软件系统
–螺旋模型是瀑布模型、原型模型的有机结合,同时增加了风险分析
ABSDM基于软件体系结构的软件开发模型
19请把基于软件体系结构的软件设计方法与其他软件设计方法进行比较。
体系结构设计
软件设计准则:
信息隐藏、高内聚度、低耦合度
面向数据流的设计方法的主要过程
–确定数据流的类型:
变换流还是事务流
–划定流界
–将数据流图转换为软件结构
–通过设计复审和启发式策略精化软件结构
启发式设计策略
改造软件结构,降低耦合度,提高内聚度
–如果在几个模块中发现共有的子功能,一般应该将该子功能独立出来作为一个模块,以提高模块的独立性
–合并那些具有较多的控制信息传递的模块以降低模块之间的耦合度
减少扇出,追求高扇入
一个好的软件结构通常顶层扇出较高,中间层扇出较低,底层又高扇入到公共模块中去
使任一模块的作用域在其控制域内
作用域是指受模块内部判定影响的所有模块
控制域是指其所有的下属模块
其他启发式设计策略
降低模块接口复杂度和冗余度,提高协调性
模块功能可预测,避免对模块施加过多限制
追求单入口、单出口的模块
为满足设计和可移植性要求,把某些软件用包封装起来
20如何才能提高软件系统的可演化性。
体系结构的演化
–引起软件变化的原因是多方面的,如基础设施的改变,功能需求的增加,高性能算法的发现,技术环境因素的变化等。
可从上述方面提高演化性。
系统需求、技术、环境、分布等因素的变化而最终导致软件体系结构的变动称为演化
手段:
SA的静态演化,动态演化
21为什么要评估软件体系结构?
●为软件系统所选用的体系结构是否恰当?
●如何确保按照所选用的体系结构能顺利开发出成功的软件产品?
●评估可以只针对一个体系结构,也可针对一组体系结构。
●评估关注的是系统的质量属性。
22从哪些方面评估软件体系结构?
1性能
系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理的事件个数
2可靠性
软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。
可靠性通常用平均失效等待时间(MTTF)和平均失效间隔时间(MTBF)来衡量。
可靠性可以分为两个方面:
容错目的是在错误发生时确保系统正确的行为,并进行内部“修复”
健壮性保护应用程序不受错误使用和错误输入的影响,在遇到意外错误事件时确保系统处于已经定义好的状态。
只能保证软件按照某种已经定义好的方式终止执行
3可用性
系统能够正常运行的时间比例。
经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
4安全性
指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
安全性是根据系统可能受到的安全威胁的类型来分类的。
5可修改性
指能够快速地以较高的性价比对系统进行变更的能力。
通常以某些具体的变更为基准,考察变更的代价衡量可修改性。
包含四个方面:
●可维护性:
体现在问题的修复上——在错误发生后“修复”软件系统。
●可扩展性:
使用新特性来扩展软件系统,以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。
●结构重组:
重新组织软件系统的构件及构件间的关系。
●可移植性:
使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。
7功能性
系统所能完成所期望的工作的能力。
一项任务的完成需要系统中许多或大多数构件的相互协作。
8可变性
体系结构经扩充或变更而成为新体系结构的能力。
这种新体系结构应该符合预先定义的规则,在某些具体方面不同于原有的体系结构。
当要将某个体系结构作为一系列相关产品(例如,软件产品线)的基础时,可变性是很重要的。
9集成性
系统与其他系统协作的程度。
10互操作性
作为系统组成部分的软件不是独立存在的,经常与其他系统或自身环境相互作用。
为了支持互操作性,软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。
程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题,这种互操作性也影响应用的软件体系结构。
23软件产品线体系结构
软件产品线演化
从整体来看,软件产品线的发展过程有三个阶段,开发阶段、配置分发阶段和演化阶段。
引起产品线体系结构演化的原因与引起任何其他系统演化的原因一样:
产品线与技术变化的协调、现有问题的改正、新功能的增加、对现有功能的重组以允许更多的变化等等。
产品线的演化包括产品线核心资源的演化、产品的演化和产品版本升级。
这样,在整个产品线就出现了:
核心资源的新旧版本、产品的新旧版本和新产品等。
它们之间的协调是产品线演化研究的主要问题。
24什么是网络环境?
通过网络相互连接、相互协作,共同执行任务的一组计算机系统。
包括:
连接设备、计算机硬件、
支持网络的操作系统
与单机环境相对
网络环境(从各个个体角度)
分布式系统(从整体角度)
25结合自己经历或者了解的项目软件项目和产品,与6个特性进行对照分析比较,看满足哪些特点?
网络环境下应用系统的特点
1共享性一旦授权,可以访问环境中的任何资源:
硬件、软件、数据
2开放性
环境扩展与改进的需要
需要发布构件之间的接口细节
新构件需要能够与已存在的构件进行集成
必须解决异构性
3并发性
网络环境中的构件可以在并发的过程中被执行
构件可以访问、更新共享的资源
如果不对并发的更新进行协调
无法保持环境的完整性
4可伸缩性
利用网络环境可以:
为更多的用户服务
响应更快
5容错性
硬件、软件、网络发生错误的不可避免性
网络环境必须维护可用性
容错的实现途径:
恢复(recovery)
冗余(redundancy)
6透明性
网络环境对于用户与应用程序而言
应当是一个整体
26客户机/服务器计算模式的特点。
客户机/服务器
计算由两端协作完成,传递操作和数据
客户机-服务器计算模式中的两个重要概念:
用户界面操作(UserInterface)与
商业逻辑(BusinessLogic)
27三层系统与多层系统。
典型的客户机/服务器体系结构又称为两层(2-tier)模型。
在两层模型的设计中,由客户应用程序直接处理对数据库的访问。
为提高数据的安全性与系统的可扩充性,可在两层模型的基础上考虑多层(N-tier)设计模型,将数据库访问分布在一个或多个中间层。
客户程序与数据库的连接被中间层屏蔽,客户程序只能通过中间层间接地访问数据库。
中间层可能运行在不同于客户机的其他机器上,经过合理的任务划分与物理部署后,可使得整个系统的工作负载更趋均衡,从而提高整个系统的运行效率
28多层系统的特点与优势
使用多层分布式应用结构的优势
多层数据库模式将数据库应用程序合理地分块。
客户端程序专门处理数据显示和用户界面。
在理想的情况下,它不需要了解数据是如何被存储及维护的。
应用服务器(中间层)能够自动地协调和处理来自多个客户端的请求和数据更新。
它处理了所有定义的数据集的细节以及与数据库的交互。
把业务逻辑封装在共享的中间层里。
不同的客户端都访问相同的中间层。
这可以减少由于在每个单独的客户端应用中重复业务逻辑所造成的冗余(以及相应的维护成本)。
“瘦”的客户端。
客户端应用程序可以写得很小,而把大多数工作交给中间层处理。
客户端应用程序不仅是变小了,而且还更加的易于发布,可以通过Internet以更加灵活的方式发布。
分布式数据处理。
将一个应用系统的工作分布到几台机器上可以改善系统的性能,因为可以提供负载平衡以及用备用的机器去替代发生故障的机器。
可以通过使用不同的访问约束,来分层隔离敏感的功能,为系统提供灵活的和可配置的安全缓冲层。
29网络软件体系结构包
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 为什么 研究 软件 体系结构