软件体系结构课件

软件体系结构

(SoftwareArchitecture)一、软件体系结构起源和基本概念软件体系结构

(SoftwareArchitecture)建筑的例子——狗舍一个人搭建，需要最小化建模简单的过程简单的工具建筑的例子——狗舍一个人搭建，需要建筑的例子——住房一个团队高效和适时地建造，需要仔细的建模良好定义的过程良好的工具建筑的例子——住房一个团队高效和适时地建造，需要建筑的例子——摩天大楼建筑的例子——摩天大楼

从软件危机谈起软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题1968年国际软件工程会议提出，并被人们广泛认识到软件危机的表现软件成本日益增长开发进度难以控制软件质量差软件维护困难从软件危机谈起软件危机是指在计算机软件的开发和维护过程中软件危机的表现软件成本日益增长20世纪50年代，软件成本在整个计算机系统成本中所占的比例为10%-20%。到20世纪60年代中期，软件成本在计算机系统中所占的比例已经增长到50%左右。而且，该数字还在不断地递增，下面是一组来自美国空军计算机系统的数据：1955年，软件费用约占总费用的18%，1970年达到60%，1975年达到72%，1980年达到80%，1985年达到85%左右。软件危机的表现软件成本日益增长软件危机的表现开发进度难以控制由于软件是逻辑、智力产品，软件的开发需建立庞大的逻辑体系，这是与其他产品的生产不一样的。在软件开发过程中，用户需求变化等各种意想不到的情况层出不穷，令软件开发过程很难保证按预定的计划实现，给项目计划和论证工作带来了很大的困难。盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理等方面的问题将更为严重软件危机的表现开发进度难以控制软件危机的表现软件质量差软件项目即使能按预定日期完成，结果却不尽人意。1965年至1970年，美国范登堡基地发射火箭多次失败，绝大部分故障是由应用程序错误造成的。在“软件作坊”里，由于缺乏工程化思想的指导，程序员几乎总是习惯性地以自己的想法去代替用户对软件的需求，软件设计带有随意性，很多功能只是程序员的“一厢情愿”而已，这是造成软件不能令人满意的重要因素。软件危机的表现软件质量差软件危机的表现软件维护困难由于在软件设计和开发过程中，没有严格遵循软件开发标准，各种随意性很大，没有完整的真实反映系统状况的记录文档，给软件维护造成了巨大的困难。特别是在软件使用过程中，原来的开发人员可能因各种原因已经离开原来的开发组织，使得软件几乎不可维护。有资料表明，工业界为维护软件支付的费用占全部硬件和软件费用的40%-75%。软件危机的表现软件维护困难从软件危机谈起软件危机的原因用户需求不明确缺乏正确的理论指导软件规模越来越大软件复杂度越来越高从软件危机谈起软件危机的原因软件危机的原因用户需求不明确在软件开发完成之前，用户不清楚软件的具体需求；用户对软件需求的描述不精确，可能有遗漏、有二义性、甚至有错误；在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求；开发人员对用户需求的理解与用户本来愿望有差异软件危机的原因用户需求不明确软件危机的原因缺乏正确的理论指导缺乏有力的方法学和工具方面的支持。由于软件不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化，也是发生软件危机的一个重要原因。软件危机的原因缺乏正确的理论指导软件危机的原因软件规模越来越大随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确、有时还会产生误解。软件项目开发人员不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。软件危机的原因软件规模越来越大软件危机的原因软件复杂度越来越高软件不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。软件产品的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。所谓“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前软件危机的原因软件复杂度越来越高从软件危机谈起如何克服软件危机

人们面临的不光是技术问题，更重要的是管理问题。管理不善必然导致失败。要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。在技术上，应该采用基于复用的软件生产技术；在管理上，应该采用多维的工程管理模式。诞生了软件工程用工程、科学和数学的原则和方法研制、维护计算机软件的有关技术及管理方法方法：“如何做”的技术手段工具：为方法提供的自动或者半自动的软件支撑环境过程：将软件工程的方法和共计综合起来以达到合理、及时地进行计算机软件开发地目的软件体系结构是软件工程学科的分支从软件危机谈起如何克服软件危机软件复用软件复用是指在两次或多次不同的软件开发过程中重复使用相同或者相近软件元素的过程软件元素包括程序代码、测试用例、设计文档、设计过程、需求分析文档甚至领域知识软件复用软件复用是指在两次或多次不同的软件开发过程中重复使用软件复用软件系统极少是全新的它们通常是“主旋律的变奏”建造“每类一个”的系统过于昂贵在任何工程领域都是如此在软件工程领域，尤其如此针对“新”问题，有大量现成的解决方案OTS(off-the-shelf)系统可能只提供部分解决方案代码行不再是基本的软件构造单元模块/构件成为开发、功能、演化/维护和复用的单元类似于土木工程软件复用软件系统极少是全新的复用的好处减少开发时间潜在的“即插即用”增加可靠性通过测试多重使用改善质量可移植性互操作性快速重新配置用户编程通过构件组装复用的好处减少开发时间软件复用的经济环境为复用而设计需要更高的前期投资开发成本增加10%至50%维护可复用资产库的附加成本可复用构件的维护当一个构件被复用时，这些成本将得到补偿成本节省2倍至20倍需要远见►管理层的支持是必须的OTS复用伴随着一定的风险缺乏信任被复用软件未知的可靠性被复用软件不充分的理解►成本和预算超支的可能软件复用的经济环境为复用而设计需要更高的前期投资复用的技术困难OTS系统没有包含可清晰辨识的构件OTS构件粒度过大或过小OTS构件没有正好提供所要求的功能集OTS构件的规约和集成不可预见地复杂复用一个构件的附加成本可能比重新开发更高定位/选取理解提取评估/适应性改造集成复用的技术困难OTS系统没有包含可清晰辨识的构件软件复用的实情[Krueger1992]复用技术要想有效，必须缩短系统的初始概念和最终可执行实现之间的距离复用技术要想有效，必须使复用制品的难度低于重新构造的难度选择一个制品复用，必须知道它做什么要想有效地复用一个软件制品，必须能够以比构造它更短的时间内发现它软件复用的实情[Krueger1992]复用技术要想有效，软件复用的方法(1)高级语言复用语言命令模式设计和代码挖掘需要巨大的时间/精力投入收益不可预知源代码构件专为复用开发的构件成功用于小的、易于理解的领域通用构件库倾向于不实用软件模式使用抽象的算法和数据结构，而非源代码在高于代码的抽象层次上形式化规约可能因为太复杂而难以定位、理解和使用软件复用的方法(1)高级语言软件复用的方法(2)应用系统生成器类似于程序语言编译器，但适用于较窄的领域应用于非常高层、专用的抽象不适用于广泛的应用甚高级语言和转换系统使用“可执行的规约语言”典型的数学抽象，例如，集合论更通用的应用，但不像生成器功能强大（人工引导）从规约到实现的转换软件体系结构软件复用的方法(2)应用系统生成器软件开发当前所处的位置软件系统天生是复杂的某些复杂性是可控的提高为开发人员提供的抽象层次努力同开发人员的思维模式相匹配针对上述问题，出现的特定技术描述软件系统的符号体系从可复用的、粗粒度的构造块搭建系统的技术和工具关注于整体系统结构 还有很长的路要走！软件开发当前所处的位置软件系统天生是复杂的软件体系结构的焦点和范围软件体系结构是一个软件系统的设计图(blueprint)解决复杂性问题提高复用和构件市场的潜力包含形式化方法两个主要焦点系统结构需求和实现之间的对应►构件+组装规则+行为规则理解系统级关注的框架全局流动率，通讯模式，执行控制机构，可升级性，系统演化路径，容量，吞吐量，一致性，构件兼容性，等软件体系结构的焦点和范围软件体系结构是一个软件系统的设计图(软件体系结构的发展史“无体系结构”设计阶段萌芽阶段以汇编语言进行小规模应用程序开发为特征以描述系统的高层抽象结构为中心，不关心具体的建模细节，划分了体系结构模型与传统软件结构的界限，该阶段以Kruchten提出的“4+1”模型为标志出现了从不同侧面描述系统的结构模型，以UML为典型代表。出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征高级阶段初期阶段软件体系结构的发展史“无体系结构”设计阶段萌芽阶段以汇编语言软件体系结构的发展史Perry和Wolf认为未来的年代是研究软件体系结构的时代

软件体系结构的发展史Perry和Wolf认为概念起源(1)对软件体系结构的研究可以追溯到20世纪60年代，当时主要是对软件结构的研究。1969年，Brooks提出“概念结构”Inprogramming,thetermarchitecturewasfirstusedtomeanadescriptionofacomputersystemthatappliedequallytomorethanoneactualsystem体系结构和实现被仔细区分开来ArchitecturetellswhathappensImplementationtellshowitismadetohappen体系结构作为“一组系统的公共描述”的想法被保持下来，并成为概念的核心概念起源(1)对软件体系结构的研究可以追溯到20世纪60年代概念起源(2)1968年，EdsgerDijkstra提出“层次结构”的想法当时，软件体系结构的研究主要是针对软件结构，即软件如何划分和结构化，而不是简单地编程以产生正确的结果以操作系统为例，Dijkstra首次提出“层次结构”的想法，程序被归结到不同的层次，只有相邻层次的程序可以互相访问通过上述系统组织所展现出的概念完整性，可以减轻开发和维护的负担概念起源(2)1968年，EdsgerDijkstra提出概念起源(3)1970年代初，DavidParnas提出一系列重要的思想1972年，信息隐蔽(information-hiding)1974年，软件结构(softwarestructures)1975年，程序家族(programfamilies)一个程序家族是一组程序（并非所有这些程序已经或将被构造），把它们作为一组看待是有益或有用的理论上，一个程序家族可以通过遍历一个决策树进行枚举，树的叶节点代表装配好的、可执行的系统这个概念支持从现存的家族成员导出新成员的想法，过程是在决策树上回溯，直到达到一个公共的节点（决策点），然后沿着新的路径导出希望的成员这个概念还支持从一个公共决策点导出多个家族成员，以此解释这些成员之间的相似和不同概念起源(3)1970年代初，DavidParnas提出一概念起源(4)在决策树上越靠近根节点的部分，越代表了对程序家族成员保持稳定的那些早期设计决策在这样的上下文中，早期决策代表特定的体系结构后期决策（靠近叶节点）代表琐细、易变的决策，例如编译时刻、甚至加载时刻的常量程序家族概念对软件体系结构的意义在于，软件体系结构包含了决策树根部或靠近根部的那些决策1976年，FrankDeRemer和HansKron提出了模块连接语言MIL75“Programming-in-largeversusprogramming-in-small”,[IEEETrans.onSE,June1976]概念起源(4)在决策树上越靠近根节点的部分，越代表了对程序家概念起源(5)以编译器为例，在1970~1980年代，编译器设计发展成为标准的程序对所有编译器公共的决策被复用，例如，词法分析器、语法分析器、语义树、属性文法、目标代码生成器、优化器，等许多其他领域的成员之间，呈现出公共结构，互连策略，功能到构件的分配，构件接口，整体合理化基础软件体系结构的工作可被看作一种事后努力为可复用的家族范围的设计信息提供结构化的仓库试图整理程序家族各成员之间的共性，从而家族成员内在的高层设计决策不需要重复地发明、验证和描述概念起源(5)以编译器为例，在1970~1980年代，编译器概念起源(6)从1980年代初期开始，人们在软件设计方面的注意力逐渐集中到面向对象方法上。经过二十多年的研究和实践，人们形成了这样一个共识：对象并不是解决所有设计问题的灵丹妙药，软件工程必须超越面向对象方法，形成以体系结构为中心的新方法面向对象方法在软件体系结构设计中存在的误区基本特征：模块化、封装、继承、多态等OO程序员更多关注的是低层次，而不是高层次的抽象对象（类）的粒度过小：趋向于实现层次对象（类）之间的关系类型过于一般化：依赖(dependency)，泛化(generalization)，关联(association)概念起源(6)从1980年代初期开始，人们在软件设计方面的注发展现状(1)真正现在意义上的软件体系结构的研究始于，DewaynePerry和AlexanderWolf[PW1992],andDavidGarlan和MaryShaw[GS1993]的奠基性工作,and其他人对体系结构风格的分类和评价[KBA+1994],and特定领域软件体系结构(DSSAs)的研究和应用[DSSA1992]应用现状体系结构的设计是建立在直觉和经验、而非坚实的工程原则之上的体系结构的描述是非形式化的和随意的，经常采用框线图（box-and-linediagram）加文字注释的方法发展现状(1)真正现在意义上的软件体系结构的研究始于，发展现状(2)应用后果体系结构设计只是被开发人员含糊地理解难以对体系结构设计作出一致性或完整性的分析随着系统的演化，难以保持同系统原有体系结构的一致，并且难以开发有效的工具，辅助人们进行体系结构的设计、性质分析和验证发展现状(2)应用后果发展现状(3)在“软件复用的展望和策略”[DoD1992]报告中，美国国防部强调了“以体系结构为中心的复用”在整个软件生存周期中，对于软件开发和支持的重要性。以下是一些同体系结构相关的研究项目，STARS,DODCARDS,DODPRISM,DODRAPIDE,StanfordUni.C2styleandADL,CaliforniaUni.Able(ArchitectureBasedLanguagesandEnvironments),CMUACMEArchitectureInterchangeLanguage,CMUVitruvius,CMU发展现状(3)在“软件复用的展望和策略”[DoD1992发展现状(4)鉴于是否有一个稳定的软件体系结构，对软件的质量和成本影响很大，因此如何获得一个良好的体系结构就成为当今软件界研究的重点。当前软件体系结构研究和实践中，一些最活跃的领域包括：各种体系结构风格的汇编和总结体系结构描述语言体系结构的形式化基础体系结构分析技术基于体系结构的开发方法体系结构恢复和再工程支持体系结构设计的工具和环境特定领域的软件体系结构(DSSA)……发展现状(4)鉴于是否有一个稳定的软件体系结构，对软件的质量软件体系结构的定义(1)PerryandWolf,1992软件体系结构＝（元素，形态，基本理论）软件体系结构是一组具有特定形式的设计元素。这里的设计元素被分为三类：处理元素(processingelements)、数据元素(dataelements)和连接元素(connectionelements)Kruchten,1994软件体系结构涉及软件高层结构的设计和实现,通过组装一定数量的具有良好形态的元素，以满足主要的功能和性能需求，例如，可扩展性和可用性涉及抽象、分解/组装、风格/审美软件体系结构的定义(1)PerryandWolf,19软件体系结构的定义(2)ShawandGarlan,1996一个软件系统的体系结构定义了组成系统的计算构件和构件之间相互作用的关系软件体系结构层次的设计主要包括以下方面：组成系统的构件描述构件之间的交互指导构件交互的模式，以及施加在模式上的约束Bass,Clements,andKazman,1997软件体系结构是一个系统的结构，包括软件构件、构件的外部可见属性、以及构件关系这里，“外部可见”属性指的是其他构件可以对该构件所做的假定，比如它提供的服务、性能特性、错误处理、共享资源的使用等软件体系结构的定义(2)ShawandGarlan,1软件体系结构的定义(3)Booch,Rumbaugh,andJacobson,1999软件体系结构是一组关于下述问题的重要决定，软件系统的组织构成系统的结构化元素和它们接口的选择这些模型元素之间的协作所描述的行为这些结构化和行为元素的组装，以形成更大的子系统指导这种组织（静态和动态元素，以及它们的接口、协作和组装）的体系结构风格软件体系结构不仅关注结构和行为，也关注使用、功能、性能、弹性、复用、可理解性、经济和技术约束与折衷、审美考虑软件体系结构的定义(3)Booch,Rumbaugh,a软件体系结构的定义(4)DesignviewDeploymentviewImplementationviewProcessviewUsecaseviewvocabularyfunctionalitysystemassemblyconfigurationmanagementsystemtopologydistributiondeliveryinstallationperformancescalabilitythroughputbehavior采用UML进行软件体系结构建模软件体系结构的定义(4)DesignviewDeploym软件体系结构的定义(5)一个软件系统的体系结构定义了组成系统的构件（components），连接件（connectors），和它们之间的匹配这里，构件用于实施计算和保存状态，连接件用于表达构件之间的关系，构件和连接件之间的匹配表示了系统的拓扑结构。A2A1A3B1B2软件体系结构的定义(5)一个软件系统的体系结构定义了组成系统体系结构的关键概念三类基本的“积木(buildingblocks)”构件(components)连接件(connectors)配置(configurations)理想地，“积木”应该独立定义支持在不同上下文环境中的复用支持没有被当初的开发者预料到的互连体系结构的关键概念三类基本的“积木(buildingblo构件构件是计算或数据储存的单元Perry&Wolf定义中的处理元素和数据元素构件是计算和状态的场所客户(clients)服务器(servers)数据库(databases)过滤器(filters)层次(layers)抽象数据类型(ADTs)构件可以是简单的或复合的复合构件描述了一个（子）系统构件构件是计算或数据储存的单元连接件连接件是对以下内容进行建模的体系结构元素构件之间的交互指导这些交互的规则简单交互过程调用共享变量访问复杂和语义丰富的交互客户/服务器协议数据库访问协议异步事件广播管道数据流连接件连接件是对以下内容进行建模的体系结构元素连接件传统方法中，构件之间的连接关系通常并不独立存在，而是从属于构件，且表达能力较弱由于以下原因，表达构件之间关系的连接件应该从中分离出来，作为同构件平等的第一类实体：连接件可能要表达构件之间相当复杂的关系语义，需要详细的定义和复杂的规约复杂连接件的定义应当局部化，而不是分散定义在多个构件中，以保证系统具有良好的结构构件之间的关系并非是固定不变的，有可能随着系统的运行需要动态改变，这种改变应封装在连接件中连接件和构件一样，都应该是独立的和各有分工的。构件应该只定义它的能力（包括功能和非功能两个方面）；连接件应该规定构件之间的交互系统开发时常常复用已有的连接件，例如过滤器、客户－服务器协议、数据库访问协议等连接件传统方法中，构件之间的连接关系通常并不独立存在，而是从配置/拓扑体系结构的配置或拓扑是构件和连接件的连接图(connectedgraph)，描述了系统结构适当的连接并发和分布特性符合设计启发式规则和风格规则复合构件本身就是配置配置/拓扑体系结构的配置或拓扑是构件和连接件的连接图(con构件模型及实现构件的定义构件是指语义完整、语法正确和有可复用价值的单位软件，是软件复用过程中可以明确辨识的元素；结构上，它是语义描述、通讯接口和实现代码的复合体。构件模型及实现构件的定义构件模型及实现构件模型的三个主要流派OMG（ObjectManagementGroup，对象管理集团）的CORBA（CommonObjectRequestBrokerArchitecture，通用对象请求代理结构）Sun的EJB（EnterpriseJavaBean）Microsoft的DCOM（DistributedComponentObjectModel，分布式构件对象模型）。构件模型及实现构件模型的三个主要流派构件模型及实现青鸟构件模型构件模型及实现青鸟构件模型构件模型及实现构件获取从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可复用的构件；通过遗留工程，将具有潜在复用价值的构件提取出来，得到可复用的构件；从市场上购买现成的商业构件，即COTS（CommercialOff-The-Shell）构件；开发新的符合要求的构件。构件模型及实现构件获取构件模型及实现构件管理构件描述构件分类与组织人员及权限管理构件模型及实现构件管理构件模型及实现构件描述构件模型是对构件本质的抽象描述，主要是为构件的制作与构件的复用提供依据；从管理角度出发，也需要对构件进行描述，例如：实现方式、实现体、注释、生产者、生产日期、大小、价格、版本和关联构件等信息，它们与构件模型共同组成了对构件的完整描述。构件模型及实现构件描述构件管理构件分类与组织关键字分类法刻面分类法超文本组织方法构件管理构件分类与组织构件管理关键字分类法构件管理关键字分类法刻面分类法使用环境应用领域功能层次表示方法刻面分类法超文本组织法超文本组织法人员及权限管理一般来讲，构件库系统可包括五类用户，即注册用户、公共用户、构件提交者、一般系统管理员和超级系统管理员。人员及权限管理构件复用检索与提取构件理解与评价构件修改构件构件组装构件复用检索与提取构件检索与提取构件基于关键字的检索刻面检索法超文本检索法其他检索方法检索与提取构件理解与评价构件构件的功能与行为相关的领域知识可适应性约束条件与例外情形可以预见的修改部分及修改方法理解与评价构件软件体系结构的意义体系结构是风险承担者进行交流的手段软件体系结构代表了系统的公共的高层次的抽象。这样，系统的大部分有关人员（即使不是全部）能把它作为建立一个互相理解的基础，形成统一认识，互相交流。体系结构提供了一种共同语言来表达各种关注和协商，进而对大型复杂系统能进行理智的管理。这对项目最终的质量和使用有极大的影响。软件体系结构的意义体系结构是风险承担者进行交流的手段软件体系结构的意义体系结构是早期设计决策的体现软件体系结构明确了对系统实现的约束条件软件体系结构决定了开发和维护组织的组织结构软件体系结构制约着系统的质量属性通过研究软件体系结构可能预测软件的质量软件体系结构使推理和控制更改更简单软件体系结构有助于循序渐进的原型设计软件体系结构可以作为培训的基础软件体系结构的意义体系结构是早期设计决策的体现软件体系结构的意义软件体系结构是可传递和可复用的模型软件体系结构级的复用意味着体系结构的决策能在具有相似需求的多个系统中发生影响，这比代码级的复用要有更大的好处软件体系结构的意义软件体系结构是可传递和可复用的模型软件体系结构的应用现状软件体系结构描述语言体系结构描述构造与表示体系结构分析、设计与验证体系结构发现、演化与复用基于体系结构的软件开发方法特定领域的体系结构框架软件体系结构支持工具软件产品线体系结构建立评价软件体系结构的方法软件体系结构的应用现状软件体系结构描述语言软件体系结构的应用现状软件体系结构描述语言ADL提供了具体的语法与刻画体系结构的概念框架。ADL使得系统开发者能够很好地描述他们设计的体系结构，以便与他人交流，能够用提供的工具对许多实例进行分析。软件体系结构的应用现状软件体系结构描述语言软件体系结构的应用现状体系结构描述构造与表示（1）按照一定的描述方法，用体系结构描述语言对体系结构进行说明的结果则称为体系结构的表示，而将描述体系结构的过程称为体系结构构造软件体系结构的应用现状体系结构描述构造与表示（1）软件体系结构的应用现状体系结构描述构造与表示（2）Kruchten提出的“4+1”模型。Booch从UML的角度给出了一种由设计视图、过程视图、实现视图和部署视图，再加上一个用例视图构成的体系结构描述模型。IEEE于1995年成立了体系结构工作组，起草了体系结构描述框架标准IEEEP1471。Rational从资产复用的角度提出了体系结构描述的规格说明框架。软件体系结构的应用现状体系结构描述构造与表示（2）软件体系结构的应用现状体系结构分析、设计与验证（1）体系结构分析的内容可分为结构分析、功能分析和非功能分析。非功能分析：定量分析方法、推断分析方法。Kazman等人提出了一种非功能分析的体系结构分析方法SAAM，并运用场景技术，提出了基于场景的体系结构分析方法，而Barbacci等人提出了多质量属性情况下的体系结构质量模型、分析与权衡方法ATAM。软件体系结构的应用现状体系结构分析、设计与验证（1）体系结构分析、设计与验证（2）生成一个满足软件需求的体系结构的过程即为体系结构设计。体系结构设计过程的本质在于：将系统分解成相应的组成成分（如构件、连接件），并将这些成分重新组装成一个系统。体系结构分析、设计与验证（2）体系结构分析、设计与验证（3）体系结构设计有两大类方法：过程驱动方法和问题列表驱动方法。基于过程驱动的体系结构设计方法适用范围广，易于裁减，具备动态特点，通用性与实践性强。问题列表驱动法的基本思想是枚举设计空间，并考虑设计维的相关性，以此来选择体系结构的风格。该方法适用于特定领域，是静态的，并可以实现量化体系结构设计空间。体系结构分析、设计与验证（3）体系结构分析、设计与验证（4）体系结构设计研究的重点内容之一就是体系结构风格或模式，体系结构模式在本质上反映了一些特定的元素、按照特定的方式组成一个特定的结构，该结构应有利于上下文环境下的特定问题的解决。体系结构分析、设计与验证（4）体系结构分析、设计与验证（5）体系结构模式分为两个大类：固定术语和参考模型。已知的固定术语类的体系结构模型包括管道过滤器、客户/服务器、面向对象、黑板、分层、对等模式、状态转换、一些派生的固定术语类的体系结构模式，包括GenVoca，C2和REST等；而参考模型则相对较多，常常与特定领域相关。体系结构分析、设计与验证（5）体系结构分析、设计与验证（6）体系结构测试着重于仿真系统模型，解决体系结构层的主要问题。由于测试的抽象层次不同，体系结构测试策略可以分为单元/子系统/集成/验收测试等阶段的测试策略。在体系结构集成测试阶段，Debra等人提出了一组针对体系结构的测试覆盖标准，PaolaInveradi提出了一种基于CHAM的体系结构语义验证技术。体系结构分析、设计与验证（6）体系结构发现、演化与复用（1）体系结构发现解决如何从已经存在的系统中提取软件的体系结构，属于逆向工程范畴。Waters等人提出了一种迭代式体系结构发现过程，即由不同的人员对系统进行描述，然后对这些描述进行分类并融合，发现并解除冲突，将体系结构新属性加入到已有的体系结构模型中，并重复该过程直至体系结构描述充分。体系结构发现、演化与复用（1）体系结构发现、演化与复用（2）由于系统需求、技术、环境、分布等因素的变化而最终导致软件体系结构的变动，称之为软件体系结构演化。软件系统在运行时刻的体系结构变化称为体系结构的动态性，而将体系结构的静态修改称为体系结构扩展。体系结构扩展与体系结构动态性都是体系结构适应性和演化性的研究范畴。体系结构发现、演化与复用（2）体系结构发现、演化与复用（3）体系结构复用属于设计复用，比代码复用更抽象。由于软件体系结构是系统的高层抽象，反映了系统的主要组成元素及其交互关系，因而较算法更稳定，更适合于复用。体系结构模式就是体系结构复用研究的一个成果，而体系结构参考模型则是特定域软件体系结构的复用的成熟的象征。体系结构发现、演化与复用（3）基于体系结构的软件开发方法（1）在引入了体系结构的软件开发之后，应用系统的构造过程变为“问题定义—>软件需求—>软件体系结构—>软件设计—>软件实现”，可以认为软件体系结构架起了软件需求与软件设计之间的一座桥梁。基于体系结构的软件开发方法（1）基于体系结构的软件开发方法（2）软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架，给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为三种类型:以软件需求完全确定为前提的瀑布模型。在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型等。以形式化开发方法为基础的变换模型。基于体系结构的软件开发方法（2）基于体系结构的软件开发方法（3）所有开发方法都是要解决需求与实现之间的差距。但是，这三种类型的软件开发模型都存在这样或那样的缺陷，不能很好地支持基于软件体系结构的开发过程。在基于构件和基于体系结构的软件开发逐渐成为主流情况下，已经出现了基于构件的软件工程。但是，对体系结构的描述、表示、设计和分析以及验证等内容的研究还相对不足，随着需求复杂化及其演化，切实可行的体系结构设计规则与方法将更为重要。基于体系结构的软件开发方法（3）特定领域的体系结构框架特定领域的体系结构是将体系结构理论应用到具体领域的过程，常见的DSSA有：CASE体系结构、CAD软件的参考模型、信息系统的参考体系结构、网络体系结构DSSA、机场信息系统的体系结构和信息处理DSSA等。国内学者提出的DSSA有：北京邮电大学周莹新博士提出的电信软件的体系结构，北京航空航天大学金茂忠教授等人提出的测试环境的体系结构等。特定领域的体系结构框架软件体系结构支持工具几乎每种体系结构都有相应的支持工具，如Unicon，Aesop等体系结构支持环境，C2的支持环境ArchStudio，支持主动连接件的Tracer工具等。支持体系结构分析的工具，如支持静态分析的工具、支持类型检查的工具、支持体系结构层次依赖分析的工具、支持体系结构动态特性仿真工具、体系结构性能仿真工具等。软件体系结构支持工具软件产品线体系结构（1）产品线代表着一组具有公共的系统需求集的软件系统，它们都是根据基本的用户需求对标准的产品线构架进行定制，将可复用构件与系统独有的部分集成而得到的。软件产品线是一个十分适合专业的软件开发组织的软件开发方法，能有效地提高软件生产率和质量、缩短开发时间、降低总开发成本。软件产品线体系结构（1）软件产品线体系结构（2）软件体系结构有利于形成完整的软件产品线。体系结构在软件产品线的开发中具有至关重要的作用，在这种开发生产中，基于同一个软件体系结构，可以创建具有不同功能的多个系统软件产品线体系结构（2）建立评价软件体系结构的方法目前，常用的三个软件体系结构评估方法是：体系结构权衡分析方法（ATAM方法）软件体系结构分析方法（SAAM方法）中间设计的积极评审（ARID方法）建立评价软件体系结构的方法目前，软件体系结构尚处在迅速发展之中，越来越多的研究人员正在把注意力投向软件体系结构的研究。关于软件体系结构的研究工作主要在国外展开的，国内到目前为止对于软件体系结构的研究尚处在起步阶段。软件体系结构在国内未引起人们广泛注意的原因主要有两点：软件体系结构从表面上看起来是一个老话题，似乎没有新东西。与国外相比，国内对大型和超大型复杂软件系统开发的经历相对较少，对软件危机的灾难性体会没有国外深刻，因而对软件体系结构研究的重要性和必要性的认识还不很充分。目前，软件体系结构尚处在迅速发展之中，越来越多的研究人员正在练习题1、根据自己的经验，谈谈对软件危机的看法。2、就项目管理方面而言，软件复用项目与非复用项目有哪些不同之处3、实际参与/组织一个软件复用项目的开发，然后总结你是如何组织该项目的开发的。4、为什么要研究软件体系结构？5、根据软件体系结构的定义，你认为软件体系结构的模型应该由哪些部分组成？6、在软件体系结构的研究和应用中，你认为还有哪些不足之处？练习题1、根据自己的经验，谈谈对软件危机的看法。谢谢大家！Questionsorcomments?谢谢大家！Questionsorcomments?软件体系结构

(SoftwareArchitecture)一、软件体系结构起源和基本概念软件体系结构

(SoftwareArchitecture)建筑的例子——狗舍一个人搭建，需要最小化建模简单的过程简单的工具建筑的例子——狗舍一个人搭建，需要建筑的例子——住房一个团队高效和适时地建造，需要仔细的建模良好定义的过程良好的工具建筑的例子——住房一个团队高效和适时地建造，需要建筑的例子——摩天大楼建筑的例子——摩天大楼

从软件危机谈起软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题1968年国际软件工程会议提出，并被人们广泛认识到软件危机的表现软件成本日益增长开发进度难以控制软件质量差软件维护困难从软件危机谈起软件危机是指在计算机软件的开发和维护过程中软件危机的表现软件成本日益增长20世纪50年代，软件成本在整个计算机系统成本中所占的比例为10%-20%。到20世纪60年代中期，软件成本在计算机系统中所占的比例已经增长到50%左右。而且，该数字还在不断地递增，下面是一组来自美国空军计算机系统的数据：1955年，软件费用约占总费用的18%，1970年达到60%，1975年达到72%，1980年达到80%，1985年达到85%左右。软件危机的表现软件成本日益增长软件危机的表现开发进度难以控制由于软件是逻辑、智力产品，软件的开发需建立庞大的逻辑体系，这是与其他产品的生产不一样的。在软件开发过程中，用户需求变化等各种意想不到的情况层出不穷，令软件开发过程很难保证按预定的计划实现，给项目计划和论证工作带来了很大的困难。盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理等方面的问题将更为严重软件危机的表现开发进度难以控制软件危机的表现软件质量差软件项目即使能按预定日期完成，结果却不尽人意。1965年至1970年，美国范登堡基地发射火箭多次失败，绝大部分故障是由应用程序错误造成的。在“软件作坊”里，由于缺乏工程化思想的指导，程序员几乎总是习惯性地以自己的想法去代替用户对软件的需求，软件设计带有随意性，很多功能只是程序员的“一厢情愿”而已，这是造成软件不能令人满意的重要因素。软件危机的表现软件质量差软件危机的表现软件维护困难由于在软件设计和开发过程中，没有严格遵循软件开发标准，各种随意性很大，没有完整的真实反映系统状况的记录文档，给软件维护造成了巨大的困难。特别是在软件使用过程中，原来的开发人员可能因各种原因已经离开原来的开发组织，使得软件几乎不可维护。有资料表明，工业界为维护软件支付的费用占全部硬件和软件费用的40%-75%。软件危机的表现软件维护困难从软件危机谈起软件危机的原因用户需求不明确缺乏正确的理论指导软件规模越来越大软件复杂度越来越高从软件危机谈起软件危机的原因软件危机的原因用户需求不明确在软件开发完成之前，用户不清楚软件的具体需求；用户对软件需求的描述不精确，可能有遗漏、有二义性、甚至有错误；在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求；开发人员对用户需求的理解与用户本来愿望有差异软件危机的原因用户需求不明确软件危机的原因缺乏正确的理论指导缺乏有力的方法学和工具方面的支持。由于软件不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化，也是发生软件危机的一个重要原因。软件危机的原因缺乏正确的理论指导软件危机的原因软件规模越来越大随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确、有时还会产生误解。软件项目开发人员不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。软件危机的原因软件规模越来越大软件危机的原因软件复杂度越来越高软件不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。软件产品的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。所谓“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前软件危机的原因软件复杂度越来越高从软件危机谈起如何克服软件危机

人们面临的不光是技术问题，更重要的是管理问题。管理不善必然导致失败。要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。在技术上，应该采用基于复用的软件生产技术；在管理上，应该采用多维的工程管理模式。诞生了软件工程用工程、科学和数学的原则和方法研制、维护计算机软件的有关技术及管理方法方法：“如何做”的技术手段工具：为方法提供的自动或者半自动的软件支撑环境过程：将软件工程的方法和共计综合起来以达到合理、及时地进行计算机软件开发地目的软件体系结构是软件工程学科的分支从软件危机谈起如何克服软件危机软件复用软件复用是指在两次或多次不同的软件开发过程中重复使用相同或者相近软件元素的过程软件元素包括程序代码、测试用例、设计文档、设计过程、需求分析文档甚至领域知识软件复用软件复用是指在两次或多次不同的软件开发过程中重复使用软件复用软件系统极少是全新的它们通常是“主旋律的变奏”建造“每类一个”的系统过于昂贵在任何工程领域都是如此在软件工程领域，尤其如此针对“新”问题，有大量现成的解决方案OTS(off-the-shelf)系统可能只提供部分解决方案代码行不再是基本的软件构造单元模块/构件成为开发、功能、演化/维护和复用的单元类似于土木工程软件复用软件系统极少是全新的复用的好处减少开发时间潜在的“即插即用”增加可靠性通过测试多重使用改善质量可移植性互操作性快速重新配置用户编程通过构件组装复用的好处减少开发时间软件复用的经济环境为复用而设计需要更高的前期投资开发成本增加10%至50%维护可复用资产库的附加成本可复用构件的维护当一个构件被复用时，这些成本将得到补偿成本节省2倍至20倍需要远见►管理层的支持是必须的OTS复用伴随着一定的风险缺乏信任被复用软件未知的可靠性被复用软件不充分的理解►成本和预算超支的可能软件复用的经济环境为复用而设计需要更高的前期投资复用的技术困难OTS系统没有包含可清晰辨识的构件OTS构件粒度过大或过小OTS构件没有正好提供所要求的功能集OTS构件的规约和集成不可预见地复杂复用一个构件的附加成本可能比重新开发更高定位/选取理解提取评估/适应性改造集成复用的技术困难OTS系统没有包含可清晰辨识的构件软件复用的实情[Krueger1992]复用技术要想有效，必须缩短系统的初始概念和最终可执行实现之间的距离复用技术要想有效，必须使复用制品的难度低于重新构造的难度选择一个制品复用，必须知道它做什么要想有效地复用一个软件制品，必须能够以比构造它更短的时间内发现它软件复用的实情[Krueger1992]复用技术要想有效，软件复用的方法(1)高级语言复用语言命令模式设计和代码挖掘需要巨大的时间/精力投入收益不可预知源代码构件专为复用开发的构件成功用于小的、易于理解的领域通用构件库倾向于不实用软件模式使用抽象的算法和数据结构，而非源代码在高于代码的抽象层次上形式化规约可能因为太复杂而难以定位、理解和使用软件复用的方法(1)高级语言软件复用的方法(2)应用系统生成器类似于程序语言编译器，但适用于较窄的领域应用于非常高层、专用的抽象不适用于广泛的应用甚高级语言和转换系统使用“可执行的规约语言”典型的数学抽象，例如，集合论更通用的应用，但不像生成器功能强大（人工引导）从规约到实现的转换软件体系结构软件复用的方法(2)应用系统生成器软件开发当前所处的位置软件系统天生是复杂的某些复杂性是可控的提高为开发人员提供的抽象层次努力同开发人员的思维模式相匹配针对上述问题，出现的特定技术描述软件系统的符号体系从可复用的、粗粒度的构造块搭建系统的技术和工具关注于整体系统结构 还有很长的路要走！软件开发当前所处的位置软件系统天生是复杂的软件体系结构的焦点和范围软件体系结构是一个软件系统的设计图(blueprint)解决复杂性问题提高复用和构件市场的潜力包含形式化方法两个主要焦点系统结构需求和实现之间的对应►构件+组装规则+行为规则理解系统级关注的框架全局流动率，通讯模式，执行控制机构，可升级性，系统演化路径，容量，吞吐量，一致性，构件兼容性，等软件体系结构的焦点和范围软件体系结构是一个软件系统的设计图(软件体系结构的发展史“无体系结构”设计阶段萌芽阶段以汇编语言进行小规模应用程序开发为特征以描述系统的高层抽象结构为中心，不关心具体的建模细节，划分了体系结构模型与传统软件结构的界限，该阶段以Kruchten提出的“4+1”模型为标志出现了从不同侧面描述系统的结构模型，以UML为典型代表。出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征高级阶段初期阶段软件体系结构的发展史“无体系结构”设计阶段萌芽阶段以汇编语言软件体系结构的发展史Perry和Wolf认为未来的年代是研究软件体系结构的时代

软件体系结构的发展史Perry和Wolf认为概念起源(1)对软件体系结构的研究可以追溯到20世纪60年代，当时主要是对软件结构的研究。1969年，Brooks提出“概念结构”Inprogramming,thetermarchitecturewasfirstusedtomeanadescriptionofacomputersystemthatappliedequallytomorethanoneactualsystem体系结构和实现被仔细区分开来ArchitecturetellswhathappensImplementationtellshowitismadetohappen体系结构作为“一组系统的公共描述”的想法被保持下来，并成为概念的核心概念起源(1)对软件体系结构的研究可以追溯到20世纪60年代概念起源(2)1968年，EdsgerDijkstra提出“层次结构”的想法当时，软件体系结构的研究主要是针对软件结构，即软件如何划分和结构化，而不是简单地编程以产生正确的结果以操作系统为例，Dijkstra首次提出“层次结构”的想法，程序被归结到不同的层次，只有相邻层次的程序可以互相访问通过上述系统组织所展现出的概念完整性，可以减轻开发和维护的负担概念起源(2)1968年，EdsgerDijkstra提出概念起源(3)1970年代初，DavidParnas提出一系列重要的思想1972年，信息隐蔽(information-hiding)1974年，软件结构(softwarestructures)1975年，程序家族(programfamilies)一个程序家族是一组程序（并非所有这些程序已经或将被构造），把它们作为一组看待是有益或有用的理论上，一个程序家族可以通过遍历一个决策树进行枚举，树的叶节点代表装配好的、可执行的系统这个概念支持从现存的家族成员导出新成员的想法，过程是在决策树上回溯，直到达到一个公共的节点（决策点），然后沿着新的路径导出希望的成员这个概念还支持从一个公共决策点导出多个家族成员，以此解释这些成员之间的相似和不同概念起源(3)1970年代初，DavidParnas提出一概念起源(4)在决策树上越靠近根节点的部分，越代表了对程序家族成员保持稳定的那些早期设计决策在这样的上下文中，早期决策代表特定的体系结构后期决策（靠近叶节点）代表琐细、易变的决策，例如编译时刻、甚至加载时刻的常量程序家族概念对软件体系结构的意义在于，软件体系结构包含了决策树根部或靠近根部的那些决策1976年，FrankDeRemer和HansKron提出了模块连接语言MIL75“Programming-in-largeversusprogramming-in-small”,[IEEETrans.onSE,June1976]概念起源(4)在决策树上越靠近根节点的部分，越代表了对程序家概念起源(5)以编译器为例，在1970~1980年代，编译器设计发展成为标准的程序对所有编译器公共的决策被复用，例如，词法分析器、语法分析器、语义树、属性文法、目标代码生成器、优化器，等许多其他领域的成员之间，呈现出公共结构，互连策略，功能到构件的分配，构件接口，整体合理化基础软件体系结构的工作可被看作一种事后努力为可复用的家族范围的设计信息提供结构化的仓库试图整理程序家族各成员之间的共性，从而家族成员内在的高层设计决策不需要重复地发明、验证和描述概念起源(5)以编译器为例，在1970~1980年代，编译器概念起源(6)从1980年代初期开始，人们在软件设计方面的注意力逐渐集中到面向对象方法上。经过二十多年的研究和实践，人们形成了这样一个共识：对象并不是解决所有设计问题的灵丹妙药，软件工程必须超越面向对象方法，形成以体系结构为中心的新方法面向对象方法在软件体系结构设计中存在的误区基本特征：模块化、封装、继承、多态等OO程序员更多关注的是低层次，而不是高层次的抽象对象（类）的粒度过小：趋向于实现层次对象（类）之间的关系类型过于一般化：依赖(dependency)，泛化(generalization)，关联(association)概念起源(6)从1980年代初期开始，人们在软件设计方面的注发展现状(1)真正现在意义上的软件体系结构的研究始于，DewaynePerry和AlexanderWolf[PW1992],andDavidGarlan和MaryShaw[GS1993]的奠基性工作,and其他人对体系结构风格的分类和评价[KBA+1994],and特定领域软件体系结构(DSSAs)的研究和应用[DSSA1992]应用现状体系结构的设计是建立在直觉和经验、而非坚实的工程原则之上的体系结构的描述是非形式化的和随意的，经常采用框线图（box-and-linediagram）加文字注释的方法发展现状(1)真正现在意义上的软件体系结构的研究始于，发展现状(2)应用后果体系结构设计只是被开发人员含糊地理解难以对体系结构设计作出一致性或完整性的分析随着系统的演化，难以保持同系统原有体系结构的一致，并且难以开发有效的工具，辅助人们进行体系结构的设计、性质分析和验证发展现状(2)应用后果发展现状(3)在“软件复用的展望和策略”[DoD1992]报告中，美国国防部强调了“以体系结构为中心的复用”在整个软件生存周期中，对于软件开发和支持的重要性。以下是一些同体系结构相关的研究项目，STARS,DODCARDS,DODPRISM,DODRAPIDE,StanfordUni.C2styleandADL,CaliforniaUni.Able(ArchitectureBasedLanguagesandEnvironments),CMUACMEArchitectureInterchangeLanguage,CMUVitruvius,CMU发展现状(3)在“软件复用的展望和策略”[DoD1992发展现状(4)鉴于是否有一个稳定的软件体系结构，对软件的质量和成本影响很大，因此如何获得一个良好的体系结构就成为当今软件界研究的重点。当前软件体系结构研究和实践中，一些最活跃的领域包括：各种体系结构风格的汇编和总结体系结构描述语言体系结构的形式化基础体系结构分析技术基于体系结构的开发方法体系结构恢复和再工程支持体系结构设计的工具和环境特定领域的软件体系结构(DSSA)……发展现状(4)鉴于是否有一个稳定的软件体系结构，对软件的质量软件体系结构的定义(1)PerryandWolf,1992软件体系结构＝（元素，形态，基本理论）软件体系结构是一组具有特定形式的设计元素。这里的设计元素被分为三类：处理元素(processingelements)、数据元素(dataelements)和连接元素(connectionelements)Kruchten,1994软件体系结构涉及软件高层结构的设计和实现,通过组装一定数量的具有良好形态的元素，以满足主要的功能和性能需求，例如，可扩展性和可用性涉及抽象、分解/组装、风格/审美软件体系结构的定义(1)PerryandWolf,19软件体系结构的定义(2)ShawandGarlan,1996一个软件系统的体系结构定义了组成系统的计算构件和构件之间相互作用的关系软件体系结构层次的设计主要包括以下方面：组成系统的构件描述构件之间的交互指导构件交互的模式，以及施加在模式上的约束Bass,Clements,andKazman,1997软件体系结构是一个系统的结构，包括软件构件、构件的外部可见属性、以及构件关系这里，“外部可见”属性指的是其他构件可以对该构件所做的假定，比如它提供的服务、性能特性、错误处理、共享资源的使用等软件体系结构的定义(2)ShawandGarlan,1软件体系结构的定义(3)Booch,Rumbaugh,andJacobson,1999软件体系结构是一组关于下述问题的重要决定，软件系统的组织构成系统的结构化元素和它们接口的选择这些模型元素之间的协作所描述的行为这些结构化和行为元素的组装，以形成更大的子系统指导这种组织（静态和动态元素，以及它们的接口、协作和组装）的体系结构风格软件体系结构不仅关注结构和行为，也关注使用、功能、性能、弹性、复用、可理解性、经济和技术约束与折衷、审美考虑软件体系结构的定义(3)Booch,Rumbaugh,a软件体系结构的定义(4)DesignviewDeploymentviewImplementationviewProcessviewUsecaseviewvocabularyfunctionalitysystemassemblyconfigurationmanagementsystemtopologydistributiondeliveryinstallationperformancescalabilitythroughputbehavior采用UML进行软件体系结构建模软件体系结构的定义(4)DesignviewDeploym软件体系结构的定义(5)一个软件系统的体系结构定义了组成系统的构件（components），连接件（connectors），和它们之间的匹配这里，构件用于实施计算和保存状态，连接件用于表达构件之间的关系，构件和连接件之间的匹配表示了系统的拓扑结构。A2A1A3B1B2软件体系结构的定义(5)一个软件系统的体系结构定义了组成系统体系结构的关键概念三类基本的“积木(buildingblocks)”构件(components)连接件(connectors)配置(configurations)理想地，“积木”应该独立定义支持在不同上下文环境中的复用支持没有被当初的开发者预料到的互连体系结构的关键概念三类基本的“积木(buildingblo构件构件是计算或数据储存的单元Perry&Wolf定义中的处理元素和数据元素构件是计算和状态的场所客户(clients)服务器(servers)数据库(databases)过滤器(filters)层次(layers)抽象数据类型(ADTs)构件可以是简单的或复合的复合构件描述了一个（子）系统构件构件是计算或数据储存的单元连接件连接件是对以下内容进行建模的体系结构元素构件之间的交互指导这些交互的规则简单交互过程调用共享变量访问复杂和语义丰富的交互客户/服务器协议数据库访问协议异步事件广播管道数据流连接件连接件是对以下内容进行建模的体系结构元素连接件传统方法中，构件之间的连接关系通常并不独立存在，而是从属于构件，且表达能力较弱由于以下原因，表达构件之间关系的连接件应该从中分离出来，作为同构件平等的第一类实体：连接件可能要表达构件之间相当复杂的关系语义，需要详细的定义和复杂的规约复杂连接件的定义应当局部化，而不是分散定义在多个构件中，以保证系统具有良好的结构构件之间的关系并非是固定不变的，有可能随着系统的运行需要动态改变，这种改变应封装在连接件中连接件和构件一样，都应该是独立的和各有分工的。构件应该只定义它的能力（包括功能和非功能两个方面）；连接件应该规定构件之间的交互系统开发时常常复用已有的连接件，例如过滤器、客户－服务器协议、数据库访问协议等连接件传统方法中，构件之间的连接关系通常并不独立存在，而是从配置/拓扑体系结构的配置或拓扑是构件和连接件的连接图(connectedgraph)，描述了系统结构适当的连接并发和分布特性符合设计启发式规则和风格规则复合构件本身就是配置配置/拓扑体系结构的配置或拓扑是构件和连接件的连接图(con构件模型及实现构件的定义构件是指语义完整、语法正确和有可复用价值的单位软件，是软件复用过程中可以明确辨识的元素；结构上，它是语义描述、通讯接口和实现代码的复合体。构件模型及实现构件的定义构件模型及实现构件模型的三个主要流派OMG（ObjectManagementGroup，对象管理集团）的CORBA（CommonObjectRequestBrokerArchitecture，通用对象请求代理结构）Sun的EJB（EnterpriseJavaBean）Microsoft的DCOM（DistributedComponentObjectModel，分布式构件对象模型）。构件模型及实现构件模型的三个主要流派构件模型及实现青鸟构件模型构件模型及实现青鸟构件模型构件模型及实现构件获取从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可复用的构件；通过遗留工程，将具有潜在复用价值的构件提取出来，得到可复用的构件；从市场上购买现成的商业构件，即COTS（CommercialOff-The-Shell）构件；开发新的符合要求的构件。构件模型及实现构件获取构件模型及实现构件管理构件描述构件分类与组织人员及权限管理构件模型及实现构件管理构件模型及实现构件描述构件模型是对构件本质的抽象描述，主要是为构件的制作与构件的复用提供依据；从管理角度出发，也需要对构件进行描述，例如：实现方式、实现体、注释、生产者、生产日期、大小、价格、版本和关联构件等信息，它们与构件模型共同组成了对构件的完整描述。构件模型及实现构件描述构件管理构件分类与组织关键字分类法刻面分类法超文本组织方法构件管理构件分类与组织构件管理关键字分类法构件管理关键字分类法刻面分类法使用环境应用领域功能层次表示方法刻面分类法超文本组织法超文本组织法人员及权限管理一般来讲，构件库系统可包括五类用户，即注册用户、公共用户、构件提交者、一般系统管理员和超级系统管理员。人员及权限管理构件复用检索与提取构件理解与评价构件修改构件构件组装构件复用检索与提取构件检索与提取构件基于关键字的检索刻面检索法超文本检索法其他检索方法检索与提取构件理解与评价构件构件的功能与行为相关的领域知识可适应性约束条件与例外情形可以预见的修改部分及修改方法理解与评价构件软件体系结构的意义体系结构是风险承担者进行交流的手段软件体系结构代表了系统的公共的高层次的抽象。这样，系统的大部分有关人员（即使不是全部）能把它作为建立一个互相理解的基础，形成统一认识，互相交流。体系结构提供了一种共同语言来表达各种关注和协商，进而对大型复杂系统能进行理智的管理。这对项目最终的质量和使用有极大的影响。软件体系结构的意义体系结构是风险承担者进行交流的手段软件体系结构的意义体系结构是早期设计决策的体现软件体系结构明确了对系统实现的约束条件软件体系结构决定了开发和维护组织的组织结构软件体系结构制约着系统的质量属性通过研究软件体系结构可能预测软件的质量软件体系结构使推理和控制更改更简单软件体系结构有助于循序渐进的原型设计软件体系结构可以作为培训的基础软件体系结构的意义体系结构是早期设计决策的体现软件体系结构的意义软件体系结构是可传递和可复用的模型软件体系结构级的复用意味着体系结构的决策能在具有相似需求的多个系统中发生影响，这比代码级的复用要有更大的好处软件体系结构的意义软件体系结构是可传递和可复用的模型软件体系结构的应用现状软件体系结构描述语言体系结构描述构造与表示体系结构分析、设计与验证体系结构发现、演化与复用基于体系结构的软件开发方法特定领域的体系结构框架软件体系结构支持工具软件产品线体系结构建立评价软件体系结构的方法软件体系结构的应用现状软件体系结构描述语言软件体系结构的应用现状软件体系结构描述语言ADL提供了具体的语法与刻画体系结构的概念框架。ADL使得系统开发者能够很好地描述他们设计的体系结构，以便与他人交流，能够用提供的工具对许多实例进行分析。软件体系结构的应用现状软件体系结构描述语言软件体系结构的应用现状体系结构描述构造与表示（1）按照一定的描述方法，用体系结构描述语言对体系结构进行说明的结果则称为体系结构的表示，而将描述体系结构的过程称为体系结构构造软件体系结构的应用现状体系结构描述构造与表示（1）软件体系结构的应用现状体系结构描述构造与表示（2）Kruchten提出的“4+1”模型。Booch从UML的角度给出了一种由设计视图、过程视图、实现视图和部署视图，再加上一个用例视图构成的体系结构描述模型。IEEE于1995年成立了体系结构工作组，起草了体系结构描述框架标准IEEEP1471。Rational从资产复用的角度提出了体系结构描述的规格说明框架。软件体系结构的应用现状体系结构描述构造与表示（2）软件体系结构的应用现状体系结构分析、设计与验证（1）体系结构分析的内容可分为结构分析、功能分析和非功能分析。非功能分析：定量分析方法、推断分析方法。Kazman等人提出了一种非功能分析的体系结构分析方法SAAM，并运用场景技术，提出了基于场景的体系结构分析方法，而Barbacci等人提出了多质量属性情况下的体系结构质量模型、分析与权衡方法ATAM。软件体系结构的应用现状体系结构分析、设计与验证（1）体系结构分析、设计与验证（2）生成一个满足软件需求的体系结构的过程即为体系结构设计。体系结构设计过程的本质在于：将系统分解成相应的组成成分（如构件、连接件），并将这些成分重新组装成一个系统。体系结构分析、设计与验证（2）体系结构分析、设计与验证（3）体系结构设计有两大类方法：过程驱动方法和问题列表驱动方法。基于过