体系结构第章认识体系结构精选PPT.ppt

《体系结构第章认识体系结构精选PPT.ppt》由会员分享，可在线阅读，更多相关《体系结构第章认识体系结构精选PPT.ppt（86页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、关于体系结构第章认识体系结构第1页，讲稿共86张，创作于星期一第1章软件体系结构概论w从软件危机谈起w软件成本日益增长w开发进度难以控制w软件质量差w软件维护困难第2页，讲稿共86张，创作于星期一w软件成本日益增长w20世纪50年代，软件成本在整个计算机系统成本中所占的比例为10%-20%。到20世纪60年代中期，软件成本在计算机系统中所占的比例已经增长到50%左右。w而且，该数字还在不断地递增，下面是一组来自美国空军计算机系统的数据：1955年，软件费用约占总费用的18%，1970年达到60%，1975年达到72%，1980年达到80%，1985年达到85%左右。第3页，讲稿共86张，创作于

2、星期一w开发进度难以控制w由于软件是逻辑、智力产品，软件的开发需建立庞大的逻辑体系，这是与其他产品的生产不一样的。w在软件开发过程中，用户需求变化等各种意想不到的情况层出不穷，令软件开发过程很难保证按预定的计划实现，给项目计划和论证工作带来了很大的困难。w盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理等方面的问题将更为严重。第4页，讲稿共86张，创作于星期一w软件质量差w软件项目即使能按预定日期完成，结果却不尽人意。1965年至1970年，美国范登堡基地发射火箭多次失败，绝大部分故障是由应用程序错误造成的。w在“软件作坊”里，由

3、于缺乏工程化思想的指导，程序员几乎总是习惯性地以自己的想法去代替用户对软件的需求，软件设计带有随意性，很多功能只是程序员的“一厢情愿”而已，这是造成软件不能令人满意的重要因素。第5页，讲稿共86张，创作于星期一w软件维护困难w由于在软件设计和开发过程中，没有严格遵循软件开发标准，各种随意性很大，没有完整的真实反映系统状况的记录文档，给软件维护造成了巨大的困难。w特别是在软件使用过程中，原来的开发人员可能因各种原因已经离开原来的开发组织，使得软件几乎不可维护。w有资料表明，工业界为维护软件支付的费用占全部硬件和软件费用的40%-75%。第6页，讲稿共86张，创作于星期一软件危机的原因w用户需求不

4、明确w缺乏正确的理论指导w软件规模越来越大w软件复杂度越来越高第7页，讲稿共86张，创作于星期一w用户需求不明确w在软件开发完成之前，用户不清楚软件的具体需求；w用户对软件需求的描述不精确，可能有遗漏、有二义性、甚至有错误；w在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求；w开发人员对用户需求的理解与用户本来愿望有差异。第8页，讲稿共86张，创作于星期一w缺乏正确的理论指导w缺乏有力的方法学和工具方面的支持。由于软件不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造

5、性，加剧软件产品的个性化，也是发生软件危机的一个重要原因。第9页，讲稿共86张，创作于星期一w软件规模越来越大w随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确、有时还会产生误解。w软件项目开发人员不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。第10页，讲稿共86张，创作于星期一w软件复杂度越来越高w软件不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。软件产品的特殊性和人类智力的局限性，导致人们无力处理“

6、复杂问题”。w所谓“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前。第11页，讲稿共86张，创作于星期一如何克服软件危机w人们面临的不光是技术问题，更重要的是管理问题。管理不善必然导致失败。w要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。w在技术上，应该采用基于重用的软件生产技术；在管理上，应该采用多维的工程管理模式。第12页，讲稿共86张，创作于星期一“建筑体系结构”第13页，讲稿共86张，创作于星期一前言体系结构简称架构或构架。构：本义架木造屋，引申为构造 构架：建

7、筑的结构 结：用绳、线、皮条等绾成的疙瘩；关键点；被联结状态 结构：组成整体的各部分的搭配和安排对住房的功能需求：能够居住。对住房的质量需求：安全性：能避免地震、台风、暴雨等各种自然灾害。居住者在建筑内的健康性，舒适性。美观性：有亲和感，社会文化的体现。不同住房具有相同的功能，但其架构不同，所满足的居住质量也不相同。第14页，讲稿共86张，创作于星期一人类最早的居住方式：巢居和穴居w炎热或高海拔地区的穴居方式，可获得相对稳定的室内热环境，顶部的天窗既可采光又可排烟。第15页，讲稿共86张，创作于星期一爱斯基摩雪屋的外观和室内布置 用干雪沏成，厚度500的墙体可以提供较好的保温性能。当室外平均温

8、度30时可维持室内温度5以上。第16页，讲稿共86张，创作于星期一大陆气候的中国民居土窑洞借助土壤大热惯性，达到冬暖夏凉的目的。第17页，讲稿共86张，创作于星期一w利用太阳高度角的特点，仅在北方出现。w四合院建筑冬季有效地利用了太阳能采暖和抵御北风侵袭，屋顶设计避免了夏季室内过热。中国四合院：座北朝南的典范第18页，讲稿共86张，创作于星期一湿热地区的中国民居云南干阑竹楼：防雨，防湿和防热。第19页，讲稿共86张，创作于星期一地球环境还可持续发展吗？遍布全球遍布全球遍布全球遍布全球的玻璃和钢筋的玻璃和钢筋的玻璃和钢筋的玻璃和钢筋盒子建筑盒子建筑盒子建筑盒子建筑空调的普及使人们不再关心建筑的冷

9、暖，但高能耗又使环境受到影响。第20页，讲稿共86张，创作于星期一为什么研究软件架构?思想有多远，我们就能走多远 高度决定思路，思路决定出路 系统的建立是为了满足组织的需求（包括功能和质量），质量需求决定了系统必须达到的特征,包括性能,可靠性,互操作性以及生命周期等。随着软件系统的日益复杂，涉众对软件的要求已不局限于功能上的满足，而是更加注重质量。很少有人注意到组织（开发组织、客户等）在系统设计和系统成败上扮演的角色。系统的质量特征受到软件架构的限制，或者说构架设计的选择受到要达到的质量特征的影响。第21页，讲稿共86张，创作于星期一w本课程的目的：对软件体系结构的产生、演化做通俗介绍，减少对

10、软件体系结构认识的神秘感，对软件体系结构设计提供实用的指导。第22页，讲稿共86张，创作于星期一w第1部分:软件构架的基础w第2部分:构架的创建w第3部分:构架的分析与评审第23页，讲稿共86张，创作于星期一w课程形式理论课、专题课、作业w成绩评定作业、考勤、考试作业+考勤30%、考试70%第24页，讲稿共86张，创作于星期一软件架构的概念控制处理(CP)特征损失模型回声模型噪音模型第25页，讲稿共86张，创作于星期一软件架构在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件、组件的外部可见属性及相互关系。外部可见属性指其它

11、组件可对该组件所做的假设，如该组件提供的服务、具备的性能特征、错误处理、共享资源的使用。为什么设计原则是架构的一部分？做事先做人 很多人不懂或不遵守走路的规则，结果丢掉性命 很多人不遵守开车的规则，结果造成严重交通事故 同样，不遵循架构设计的原则，架构也容易失败。软件架构的定义第26页，讲稿共86张，创作于星期一架构定义可以从下面六个方面来理解：架构应建立在一定的设计原则之上，否则很容易失败。系统可能由多个结构组成，其中任何一个结构都不能与构架等同。每个软件系统都有自己的架构。软件架构决定了各个组件。只要某个组件的行为可以从其它组件的角度观察到或区别开，这样的行为就是软件架构的内容。软件架构是

12、抽象的，它不考虑实现、算法和数据表示的细节，而集中研究“黑盒”组件的行为和交互，是设计第一步。第27页，讲稿共86张，创作于星期一其它观点观点1 软件架构是高层次的设计观点2 软件架构是软件系统的总体结构观点3 IEEE的定义：软件架构是一个程序或系统的组件结构、组件之间的相互联系及支配组件设计和进化的指导原则观点4 Perry和Wo1f提出：软件架构是具有一定形式的结构化元素，包括处理元素、数据元素和连接元素。处理元素负责对数据进行加工，数据元素是被加工的信息，连接元素把架构的不同部分组合连接起来。第28页，讲稿共86张，创作于星期一观点5 Mary Shaw和David Garlan认为软

13、件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。体系结构问题包括总体组织和全局控制、通讯协议、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通讯、同步与数据存取的协议，设计构件功能定义，物理分布与合成，设计方案的选择、评估与实现等。观点6 Kruchten指出，软件体系结构有四个角度，它们从不同方面对系统进行描述：概念角度描述系统的主要构件及它们之间的关系；模块角度包含功能分解与层次结构；运行角度描述了一

14、个系统的动态结构；代码角度描述了各种代码和库函数在开发环境中的组织。第29页，讲稿共86张，创作于星期一这些角度形成了一个“4+1”的视角模型。“4+1”模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软件体系结构。每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件体系结构的全部内容。“4+1”模型如图所示：第30页，讲稿共86张，创作于星期一观点7 Hayes Roth则认为软件架构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。观点8 Barry Boehm提出，软件架构包括系统构件，互联及约束的集合

15、；系统需求说明的集合；一个基本原理用以说明这一构件，互联和约束能够满足系统需求。观点9 软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。第31页，讲稿共86张，创作于星期一设计仅是系统功能需求分析的产物？功能需求设计系统开发？否也！2009年1月3号广州火车站16万张票同时出闸致系统瘫痪。911中是世界贸易大厦的倒塌。2007年1月18日，招商证券的客户发现，在公司进行网络交易时

16、，公司网站竟然无法登陆。一部分客户转向电话服务寻求帮助，却发现电话线路出现同样的阻塞。行情转瞬即逝。拥堵是由于交易量激增，原有系统容量不足引起的。奥运门票销售系统的失败软件架构的产生?第32页，讲稿共86张，创作于星期一软件体系结构研究的问题w结构性问题w系统的组织,由哪些组件构成w全局性的控制结构w通讯,同步或访问的协议w将功能分配到不同的系统组成部分w设计元素的组成w系统的物理分布w可扩展性,性能第33页，讲稿共86张，创作于星期一w主要内容包括wA对系统组成元素的描述wB这些元素相互之间的交互wC系统组成的模式wD模式的约束w所以在软件构架中,系统以组件和组件之间的交互进行定义w当前的系

17、统同时可以作为更高层设计的一个系统组件第34页，讲稿共86张，创作于星期一软件设计的层次w软件设计可以在多个不同的层次,在每一层我们都会发现相应的组件以及由这些组件组成更大的组件的组合机制.w二进制执行文件层w位模式w代码层w编程语言的原语,操作符;w记录,数组,过程;w构架层w模块第35页，讲稿共86张，创作于星期一软件体系结构的意义w体系结构是风险承担者进行交流的手段w软件体系结构代表了系统的公共的高层次的抽象。这样，系统的大部分有关人员（即使不是全部）能把它作为建立一个互相理解的基础，形成统一认识，互相交流。w体系结构提供了一种共同语言来表达各种关注和协商，进而对大型复杂系统能进行理智的

18、管理。这对项目最终的质量和使用有极大的影响。第36页，讲稿共86张，创作于星期一w体系结构是早期设计决策的体现w软件体系结构明确了对系统实现的约束条件w软件体系结构决定了开发和维护组织的组织结构w软件体系结构制约着系统的质量属性w通过研究软件体系结构可能预测软件的质量w软件体系结构使推理和控制更改更简单w软件体系结构有助于循序渐进的原型设计w软件体系结构可以作为培训的基础第37页，讲稿共86张，创作于星期一w软件体系结构是可传递和可重用的模型ww软件体系结构级的重用意味着体系结构的决策能在具有相似需求的多个系统中发生影响，这比代码级的重用要有更大的好处。第38页，讲稿共86张，创作于星期一软件

19、体系结构的发展史“无体系结构无体系结构”设计阶段设计阶段萌芽阶段萌芽阶段以汇编语言进行小规模应用程序开发以汇编语言进行小规模应用程序开发为特征为特征以描述系统的高层抽象结构为中心，以描述系统的高层抽象结构为中心，不关心具体的建模细节，划分了体系不关心具体的建模细节，划分了体系结构模型与传统软件结构的界限，该结构模型与传统软件结构的界限，该阶段以阶段以KruchtenKruchten提出的提出的“4+1”4+1”模型为模型为标志标志出现了从不同侧面描述系统的结构模出现了从不同侧面描述系统的结构模型，以型，以UMLUML为典型代表。为典型代表。出现了程序结构设计主题，以控制流出现了程序结构设计主题

20、，以控制流图和数据流图构成软件结构为特征图和数据流图构成软件结构为特征高级阶段高级阶段初期阶段初期阶段第39页，讲稿共86张，创作于星期一wPerry和Wolf认为w未来的年代是研究软件体系结构的时代第40页，讲稿共86张，创作于星期一软件体系结构的应用现状w软件体系结构描述语言w体系结构描述构造与表示w体系结构分析、设计与验证w体系结构发现、演化与重用w基于体系结构的软件开发方法w特定领域的体系结构框架w软件体系结构支持工具w软件产品线体系结构w建立评价软件体系结构的方法第41页，讲稿共86张，创作于星期一我们的目标w在软件开发过程中使用软件体系结构w成为系统架构师第42页，讲稿共86张，创

21、作于星期一系统架构师w系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单等。w系统构架师是近几年来在国内外迅速成长并发展良好的一个职位。比尔盖茨（首席软件架构师）；丁磊（首席架构师）第43页，讲稿共86张，创作于星期一w系统架构师的职责系统架构师的职责wl、领导与协调整个项目中的技术活动（分析、设计和实施等）、领导与协调整个项目中的技术活动（分析、设计和实施等）w2、推动主要的技术决策，并最终表达为软件构架、推动主要的技术决策，并最终表达为软件构架 w3、确定和文档化系统的相对构架而言意义重大的方面，包括系统的、

22、确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等需求、设计、实施和部署等“视图视图”w4、确定设计元素的分组以及这些主要分组之间的接口、确定设计元素的分组以及这些主要分组之间的接口 w5、为技术决策提供规则，平衡各类涉众的不同关注点，化解、为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻技术风险，并保证相关决定被有效的传达和贯彻 w6、理解、评价并接收系统需求、理解、评价并接收系统需求 w7、评价和确认软件架构的实现、评价和确认软件架构的实现第44页，讲稿共86张，创作于星期一w某集团公司要开发一个网络财务程序，使各地

23、员工能在互联网络上进行财务处理和报销。在设计该财务程序的体系结构时，项目组产生了分歧：w张工程师认为应该采用客户机/服务器（C/S）结构。各分公司财务部要安装一个软件客户端，通过这个客户端连接到总公司财务部主机。如果员工在外地出差，需要报销帐务的，也需要安装这个客户端才能进行。w李工程师认为应该采用浏览器/服务器（BS）结构，各分公司及出差员工直接通过Windows操作系统自带的IE浏览器就可以连接到总公司的财务部主机。第45页，讲稿共86张，创作于星期一架构受系统风险承担者的影响风险承担者对构建软件系统感兴趣的人或组织，包括合同中的客户、系统最终用户、开发人员、开发组织、系统维护人员等，他们

24、所关注的问题各不相同，但都要求系统在他们所关注的方面提供保证或优化。事物有主要矛盾和次要矛盾之分。开发系统时，首先要确定其软件构架。借助于构架，设计师可以分析众多风险承担者所提出的各种要求的优先级，并将这些要求转化为系统的各个特性，再针对它们在系统结构上做折衷，从而得到和谐的架构。第46页，讲稿共86张，创作于星期一 开发组织所关心的问题不同于客户，它对软件构架的影响分为3类：直接影响 如希望向产品线发展 长远影响 如行业布局 组织结构的影响 如软件外包 开发团队的经验对设计师的影响第47页，讲稿共86张，创作于星期一架构受设计师的素质和经验的影响 1 熟悉.NET的设计师在设计时会考虑.NE

25、T的框架和技术。2 熟悉J2EE的设计师在设计时会考虑J2EE的框架和技术。3 设计师具有数据库方向的背景，系统会被认为是数据库的应用。4 设计师具有网络安全的背景，系统的安全会被放在很突出的位置。第48页，讲稿共86张，创作于星期一构架受技术环境的影响 现在B/S样式很流行，设计师在设计时往往首先考虑系统能否在互联网环境下运行。第49页，讲稿共86张，创作于星期一需求(质量属性)设计师（小组）构架构架系统客户和最终用户开发组织技术环境设计师的经验、沟通能力架构所受的影响第50页，讲稿共86张，创作于星期一需求(质量属性)设计师（小组）构架构架系统客户和最终用户开发组织技术环境设计师的经验 软

26、件的架构不是静止的第51页，讲稿共86张，创作于星期一1.软件在开发过程中或交付使用后，都可能会发生修改，这些修改往往涉及到架构的变更。因此软件版本的演进也是软件架构的演进。2.软件架构影响设计师的经验。3.软件架构影响开发组织的内部结构和经营目标。4.软件架构可能会影响客户对下个系统的需求5.有些系统甚至会影响并实际改变软件工程的发展，以及开发人员学习和实践的技术环境，如互联网、嵌入式、手机等。第52页，讲稿共86张，创作于星期一架构商业周期架构是软件开发的必经之路和必要手段，它受到来自客户和开发组织的影响，也受到设计师的素质和经验以及技术环境的影响；反过来，构架也影响着被开发的系统，对客户

27、、开发组织、构架和技术环境也都有影响，还影响着客户及其开发组织的未来目标。围绕着构架的这些影响和反馈循环构成构架商业周期。事物是静止的，也是运动、发展和变化的，软件架构也不例外。软件的架构是运动、发展和变化的。第53页，讲稿共86张，创作于星期一构件与软件重用w构件模型及实现w构件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辨识的系统；结构上，它是语义描述、通讯接口和实现代码的复合体。第54页，讲稿共86张，创作于星期一w在大多数工程学科中，系统是通过组合现有构件进行设计的，这些构件已经在其它系统上使用过。w软件工程一直以来注重于原始开发，现在已经认识到要更快、更低

28、成本的获得更好的软件，我们需要采取一种基于系统化软件复用（systematic software reuse）的设计过程。第55页，讲稿共86张，创作于星期一w在软件演化的过程中，重复使用的行为可能发生在三个维上：w1.时间维：使用以前的软件版本作为新版本的基础，加入新功能，适应新需求，即软件维护。w2.平台维：以某平台上的软件为基础，修改其和运行平台相关的部分，使其运行于新平台，即软件移植。w3.应用维：将某软件(或其中构件)用于其他应用系统中，新系统具有不同功能和用途，即真正的软件复用。第56页，讲稿共86张，创作于星期一w促进从手工作坊式的软件开发向工业化开发发展：w核心的就是软件构件技

29、术。工业化的软件生产，应该有一个工业化的软件生产线，软件生产应该做成什么样，应该有不同的车间，有的车间专门是做构架的，就是框架。有的车间做构件，零件。第57页，讲稿共86张，创作于星期一复用的好处w增强可靠性（Increasedreliability）复用构件在工作系统上试用过，应该比新软件更可靠。失误已经在初始使用中暴露和解决，复用软件的失效数目应比较低。w减少过程风险（Reducedprocessrisk）有现成的软件，成本比重新开发低。同时降低了项目成本估算的不确定性。在大型系统中，如果子系统是复用的，效果最明显。w符合标准（Standardscompliance）有些象用户界面这样的标

30、准，就可以制成一组可复用的标准构件。例如，如果把用户界面中的菜单（Menu）做成可复用的构件，并让所有的应用都采用相同的菜单格式展现给用户。使用这样的标准用户界面就使系统的可信度得到改善，因为用户在相似的界面下更不容易出错。w加速开发（Accelerateddevelopment）尽快地把一个系统投入市场有时候比它的总开发成本更重要。因为减少了开发和确认的时间，复用软件能够加速系统生产。第58页，讲稿共86张，创作于星期一w构件模型的三个主要流派wOMG（ObjectManagementGroup，对象管理集团）的CORBA（CommonObjectRequestBrokerArchitect

31、ure，通用对象请求代理结构）wSun的EJB（EnterpriseJavaBean）wMicrosoft的DCOM（DistributedComponentObjectModel，分布式构件对象模型）。第59页，讲稿共86张，创作于星期一w“九五”期间，青鸟工程研究软件的工业化生产技术，开发软件工业化生产系统青鸟软件生产线系统，即基于构件构架模式的软件开发技术及系统，为软件开发提供整体解决方案，推行软件工业化生产模式，促进软件产业规模的形成。第60页，讲稿共86张，创作于星期一第61页，讲稿共86张，创作于星期一w青鸟构件模型第62页，讲稿共86张，创作于星期一w构件获取w从现有构件中获得符

32、合要求的构件，直接使用或作适应性修改，得到可重用的构件；w通过遗留工程，将具有潜在重用价值的构件提取出来，得到可重用的构件；w从市场上购买现成的商业构件，即COTS（CommercialOff-The-Shell）构件；w开发新的符合要求的构件。第63页，讲稿共86张，创作于星期一第64页，讲稿共86张，创作于星期一构件管理w构件描述w构件分类与组织w人员及权限管理第65页，讲稿共86张，创作于星期一w构件描述w构件模型是对构件本质的抽象描述，主要是为构件的制作与构件的重用提供依据；w从管理角度出发，也需要对构件进行描述，例如：实现方式、实现体、注释、生产者、生产日期、大小、价格、版本和关联构

33、件等信息，它们与构件模型共同组成了对构件的完整描述。第66页，讲稿共86张，创作于星期一第67页，讲稿共86张，创作于星期一w构件分类与组织w关键字分类法w刻面分类法w超文本组织方法第68页，讲稿共86张，创作于星期一w关键字分类法第69页，讲稿共86张，创作于星期一w刻面分类法w使用环境w应用领域w功能w层次w表示方法第70页，讲稿共86张，创作于星期一第71页，讲稿共86张，创作于星期一第72页，讲稿共86张，创作于星期一w超文本组织法第73页，讲稿共86张，创作于星期一第74页，讲稿共86张，创作于星期一w人员及权限管理w一般来讲，构件库系统可包括五类用户，即注册用户、公共用户、构件提交

34、者、一般系统管理员和超级系统管理员。第75页，讲稿共86张，创作于星期一构件重用w检索与提取构件w理解与评价构件w修改构件w构件组装第76页，讲稿共86张，创作于星期一检索与提取构件w基于关键字的检索w刻面检索法w超文本检索法w其他检索方法第77页，讲稿共86张，创作于星期一理解与评价构件w构件的功能与行为w相关的领域知识w可适应性约束条件与例外情形w可以预见的修改部分及修改方法第78页，讲稿共86张，创作于星期一修改构件w理想的情形是对库中的构件不作修改而直接用于新的软件项目。w但是，在大多数情况下，必须对构件进行或多或少的修改，以适应新的需求。w为了减少构件修改的工作量，要求开发人员尽量使

35、构件的功能、行为和接口设计更为抽象化、通用化和参数化。第79页，讲稿共86张，创作于星期一构件组装构件组装 w 基于功能的组装技术基于功能的组装技术w 基于数据的组装技术基于数据的组装技术w 面向对象的组装技术面向对象的组装技术第80页，讲稿共86张，创作于星期一w基于功能的组装技术w基于功能的组装技术采用子程序调用和参数传递的方式将构件组装起来。它要求库中的构件以子程序/过程/函数的形式出现，并且接口说明必须清晰。当使用这种组装技术进行软件开发时，开发人员首先应对目标软件系统进行功能分解，将系统分解为强内聚、松耦合的功能模块。然后根据各模块的功能需求提取构件，对它进行适应性修改后再挂接在上述

36、功能分解框架中。第81页，讲稿共86张，创作于星期一w基于数据的组装技术w首先根据当前软件问题的核心数据结构设计出一个框架，然后根据框架中各结点的需求提取构件并进行适应性修改，再将构件逐个分配至框架中的适当位置。此后，构件的组装方式仍然是传统的子程序调用与参数传递。这种组装技术也要求库中构件以子程序形式出现，但它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法，例如Jackson系统开发方法。第82页，讲稿共86张，创作于星期一w面向对象的组装技术w构造法w在子类中引进基类的对象作为子类的成员变量，然后在子类中通过成员变量重用基类的属性和方法。w子类法w将新子类直接说明为库中基类的子类，通过继承和修改基类的属性与行为完成新子类的定义。第83页，讲稿共86张，创作于星期一第84页，讲稿共86张，创作于星期一第85页，讲稿共86张，创作于星期一感感谢谢大大家家观观看看第86页，讲稿共86张，创作于星期一