软件体系结构课件

《软件体系结构课件》由会员分享，可在线阅读，更多相关《软件体系结构课件（81页珍藏版）》请在金锄头文库上搜索。

1、1,软件体系结构 (Software Architecture),一、软件体系结构起源和基本概念,2,建筑的例子狗舍,一个人搭建，需要 最小化建模 简单的过程 简单的工具,3,建筑的例子住房,一个团队高效和适时地建造，需要 仔细的建模 良好定义的过程 良好的工具,4,建筑的例子摩天大楼,5,从软件危机谈起,软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题 1968年国际软件工程会议提出，并被人们广泛认识到 软件危机的表现 软件成本日益增长 开发进度难以控制 软件质量差 软件维护困难,6,软件危机的表现,软件成本日益增长 20世纪50年代，软件成本在整个计算机系统成本中所占的比例为

2、10%-20%。到20世纪60年代中期，软件成本在计算机系统中所占的比例已经增长到50%左右。 而且，该数字还在不断地递增，下面是一组来自美国空军计算机系统的数据：1955年，软件费用约占总费用的18%，1970年达到60%，1975年达到72%，1980年达到80%，1985年达到85%左右。,7,软件危机的表现,开发进度难以控制 由于软件是逻辑、智力产品，软件的开发需建立庞大的逻辑体系，这是与其他产品的生产不一样的。 在软件开发过程中，用户需求变化等各种意想不到的情况层出不穷，令软件开发过程很难保证按预定的计划实现，给项目计划和论证工作带来了很大的困难。 盲目增加软件开发人员并不能成比例地

3、提高软件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理等方面的问题将更为严重,8,软件危机的表现,软件质量差 软件项目即使能按预定日期完成，结果却不尽人意。1965年至1970年，美国范登堡基地发射火箭多次失败，绝大部分故障是由应用程序错误造成的。 在“软件作坊”里，由于缺乏工程化思想的指导，程序员几乎总是习惯性地以自己的想法去代替用户对软件的需求，软件设计带有随意性，很多功能只是程序员的“一厢情愿”而已，这是造成软件不能令人满意的重要因素。,9,软件危机的表现,软件维护困难 由于在软件设计和开发过程中，没有严格遵循软件开发标准，各种随意性很大，没有完整的真实反映系统状

4、况的记录文档，给软件维护造成了巨大的困难。 特别是在软件使用过程中，原来的开发人员可能因各种原因已经离开原来的开发组织，使得软件几乎不可维护。 有资料表明，工业界为维护软件支付的费用占全部硬件和软件费用的40%-75%。,10,从软件危机谈起,软件危机的原因 用户需求不明确 缺乏正确的理论指导 软件规模越来越大 软件复杂度越来越高,11,软件危机的原因,用户需求不明确 在软件开发完成之前，用户不清楚软件的具体需求； 用户对软件需求的描述不精确，可能有遗漏、有二义性、甚至有错误； 在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求； 开发人员对用户需求的理解与用户本来愿望有差异

5、,12,软件危机的原因,缺乏正确的理论指导 缺乏有力的方法学和工具方面的支持。由于软件不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化，也是发生软件危机的一个重要原因。,13,软件危机的原因,软件规模越来越大 随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确、有时还会产生误解。 软件项目开发人员不能有效地、独立自主地

6、处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。,14,软件危机的原因,软件复杂度越来越高 软件不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。软件产品的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。 所谓“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前,15,从软件危机谈起,如何克服软件危机 人们面临的不光是技术问题，更重要的是管理问题。管理不善必然导致失败 。 要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。 在技术上，应该采用基于复用的

7、软件生产技术；在管理上，应该采用多维的工程管理模式。 诞生了软件工程 用工程、科学和数学的原则和方法研制、维护计算机软件的有关技术及管理方法 方法：“如何做”的技术手段 工具：为方法提供的自动或者半自动的软件支撑环境 过程：将软件工程的方法和共计综合起来以达到合理、及时地进行计算机软件开发地目的 软件体系结构是软件工程学科的分支,16,软件复用,软件复用是指在两次或多次不同的软件开发过程中重复使用相同或者相近软件元素的过程 软件元素包括程序代码、测试用例、设计文档、设计过程、需求分析文档甚至领域知识,17,软件复用,软件系统极少是全新的 它们通常是“主旋律的变奏” 建造“每类一个”的系统过于昂

8、贵 在任何工程领域都是如此 在软件工程领域，尤其如此 针对“新”问题，有大量现成的解决方案 OTS (off-the-shelf)系统 可能只提供部分解决方案 代码行不再是基本的软件构造单元 模块/构件成为开发、功能、演化/维护和复用的单元 类似于土木工程,18,复用的好处,减少开发时间 潜在的“即插即用” 增加可靠性 通过测试 多重使用 改善质量 可移植性 互操作性 快速重新配置 用户编程 通过构件组装,19,软件复用的经济环境,为复用而设计需要更高的前期投资 开发成本增加10%至50% 维护可复用资产库的附加成本 可复用构件的维护 当一个构件被复用时，这些成本将得到补偿 成本节省 2倍 至

9、 20倍 需要远见 管理层的支持是必须的 OTS复用伴随着一定的风险 缺乏信任 被复用软件未知的可靠性 被复用软件不充分的理解 成本和预算超支的可能,20,复用的技术困难,OTS系统没有包含可清晰辨识的构件 OTS构件粒度过大或过小 OTS构件没有正好提供所要求的功能集 OTS构件的规约和集成不可预见地复杂 复用一个构件的附加成本可能比重新开发更高 定位/选取 理解 提取 评估/适应性改造 集成,21,软件复用的实情Krueger 1992,复用技术要想有效，必须缩短系统的初始概念和最终可执行实现之间的距离 复用技术要想有效，必须使复用制品的难度低于重新构造的难度 选择一个制品复用，必须知道它

10、做什么 要想有效地复用一个软件制品，必须能够以比构造它更短的时间内发现它,22,软件复用的方法(1),高级语言 复用语言命令模式 设计和代码挖掘 需要巨大的时间/精力投入 收益不可预知 源代码构件 专为复用开发的构件 成功用于小的、易于理解的领域 通用构件库倾向于不实用 软件模式 使用抽象的算法和数据结构，而非源代码 在高于代码的抽象层次上形式化规约 可能因为太复杂而难以定位、理解和使用,23,软件复用的方法(2),应用系统生成器 类似于程序语言编译器，但适用于较窄的领域 应用于非常高层、专用的抽象 不适用于广泛的应用 甚高级语言和转换系统 使用“可执行的规约语言” 典型的数学抽象，例如，集合

11、论 更通用的应用，但不像生成器功能强大 （人工引导）从规约到实现的转换 软件体系结构,24,软件开发当前所处的位置,软件系统天生是复杂的 某些复杂性是可控的 提高为开发人员提供的抽象层次 努力同开发人员的思维模式相匹配针对上述问题，出现的特定技术 描述软件系统的符号体系 从可复用的、粗粒度的构造块搭建系统的技术和工具 关注于整体系统结构还有很长的路要走！,25,软件体系结构的焦点和范围,软件体系结构是一个软件系统的设计图(blueprint) 解决复杂性问题 提高复用和构件市场的潜力 包含形式化方法 两个主要焦点 系统结构 需求和实现之间的对应 构件 + 组装规则 + 行为规则 理解系统级关注

12、的框架 全局流动率，通讯模式，执行控制机构，可升级性，系统演化路径，容量，吞吐量，一致性，构件兼容性，等,26,软件体系结构的发展史,“无体系结构”设计阶段,27,软件体系结构的发展史,Perry和Wolf认为未来的年代是研究软件体系结构的时代,28,概念起源(1),对软件体系结构的研究可以追溯到20世纪60年代，当时主要是对软件结构的研究。 1969年，Brooks提出“概念结构” In programming, the term architecture was first used to mean a description of a computer system that appli

13、ed equally to more than one actual system 体系结构和实现被仔细区分开来 Architecture tells what happens Implementation tells how it is made to happen 体系结构作为“一组系统的公共描述”的想法被保持下来，并成为概念的核心,29,概念起源(2),1968年，Edsger Dijkstra提出“层次结构”的想法 当时，软件体系结构的研究主要是针对软件结构，即软件如何划分和结构化，而不是简单地编程以产生正确的结果 以操作系统为例，Dijkstra首次提出“层次结构”的想法，程序被归结

14、到不同的层次，只有相邻层次的程序可以互相访问 通过上述系统组织所展现出的概念完整性，可以减轻开发和维护的负担,30,概念起源(3),1970年代初，David Parnas提出一系列重要的思想 1972年，信息隐蔽 (information-hiding) 1974年，软件结构 (software structures) 1975年，程序家族 (program families) 一个程序家族是一组程序（并非所有这些程序已经或将被构造），把它们作为一组看待是有益或有用的 理论上，一个程序家族可以通过遍历一个决策树进行枚举，树的叶节点代表装配好的、可执行的系统 这个概念支持从现存的家族成员导出新

15、成员的想法，过程是在决策树上回溯，直到达到一个公共的节点（决策点），然后沿着新的路径导出希望的成员 这个概念还支持从一个公共决策点导出多个家族成员，以此解释这些成员之间的相似和不同,31,概念起源(4),在决策树上越靠近根节点的部分，越代表了对程序家族成员保持稳定的那些早期设计决策 在这样的上下文中，早期决策代表特定的体系结构 后期决策（靠近叶节点）代表琐细、易变的决策，例如编译时刻、甚至加载时刻的常量 程序家族概念对软件体系结构的意义在于，软件体系结构包含了决策树根部或靠近根部的那些决策 1976年，Frank DeRemer和Hans Kron提出了模块连接语言MIL75“Programm

16、ing-in-large versus programming-in-small”,IEEE Trans. on SE, June 1976,32,概念起源(5),以编译器为例，在19701980年代，编译器设计发展成为标准的程序 对所有编译器公共的决策被复用，例如，词法分析器、语法分析器、语义树、属性文法、目标代码生成器、优化器，等 许多其他领域的成员之间，呈现出 公共结构，互连策略，功能到构件的分配，构件接口，整体合理化基础 软件体系结构的工作可被看作一种事后努力 为可复用的家族范围的设计信息提供结构化的仓库 试图整理程序家族各成员之间的共性，从而家族成员内在的高层设计决策不需要重复地发明、验证和描述,33,概念起源(6),从1980年代初期开始，人们在软件设计方面的注意力逐渐集中到面向对象方法上。经过二十多年的研究和实践，人们形成了这样一个共识： 对象并不是解决所有设计问题的灵丹妙药，软件工程必须超越面向对象方法，形成以体系结构为中心的新方法 面向对象方法在软件体系结构设计中存在的误区 基本特征：模块化、封装、继承、多态等 OO程序员更多关注的是低层次，而不是高层次的抽象 对象（类）的粒度过小：趋向于实现层次 对象（类）之间的关系类型过于一般化：依赖(dependency)，泛化(generalization)，关联(association),