L-第四章_软件体系结构基础

1、第四章第四章 软件体系结构软件体系结构(Software Architecture)软件体系结构基础软件体系结构基础建筑的例子建筑的例子狗舍狗舍一个人搭建，需要一个人搭建，需要最小化建模最小化建模简单的过程简单的过程简单的工具简单的工具建筑的例子建筑的例子住房住房一个团队高效和适时地建造，需要一个团队高效和适时地建造，需要仔细的建模仔细的建模良好定义的过程良好定义的过程良好的工具良好的工具建筑的例子建筑的例子摩天大楼摩天大楼 软件体系结构的开发是大型软件系统开发软件体系结构的开发是大型软件系统开发的关键环节。体系结构在软件生产线的开的关键环节。体系结构在软件生产线的开发中具有至关重要的作用。发

2、中具有至关重要的作用。 在这种开发生产中，基于同一个软件体系在这种开发生产中，基于同一个软件体系结构，可以创建具有结构，可以创建具有不同功能的多个系统不同功能的多个系统。 在软件产品族之间在软件产品族之间共享体系结构和一组可共享体系结构和一组可重用的构件重用的构件，可以增加软件工程和降低开，可以增加软件工程和降低开发和维护成本。发和维护成本。 从软件危机谈起从软件危机谈起 软件危机是指在计算机软件的开发和维护软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题过程中遇到的一系列严重问题 1968年国际软件工程会议提出，并被人们广泛年国际软件工程会议提出，并被人们广泛认识到认识到 软件

3、危机的表现软件危机的表现 软件成本日益增长软件成本日益增长 开发进度难以控制开发进度难以控制 软件质量差软件质量差 软件维护困难软件维护困难软件危机的表现软件危机的表现 软件成本日益增长软件成本日益增长 20世纪世纪50年代，软件成本在整个计算机系统成年代，软件成本在整个计算机系统成本中所占的比例为本中所占的比例为10%-20%。到。到20世纪世纪60年年代中期，软件成本在计算机系统中所占的比例代中期，软件成本在计算机系统中所占的比例已经增长到已经增长到50%左右。左右。 而且，该数字还在不断地递增，下面是一组来而且，该数字还在不断地递增，下面是一组来自美国空军计算机系统的数据：自美国空军计算

4、机系统的数据：1955年，软件年，软件费用约占总费用的费用约占总费用的18%，1970年达到年达到60%，1975年达到年达到72%，1980年达到年达到80%，1985年达年达到到85%左右。左右。软件危机的表现软件危机的表现 开发进度难以控制开发进度难以控制 由于软件是逻辑、智力产品，软件的开发需建由于软件是逻辑、智力产品，软件的开发需建立庞大的逻辑体系，这是与其他产品的生产不立庞大的逻辑体系，这是与其他产品的生产不一样的。一样的。 在软件开发过程中，用户需求变化等各种意想在软件开发过程中，用户需求变化等各种意想不到的情况层出不穷，令软件开发过程很难保不到的情况层出不穷，令软件开发过程很难

5、保证按预定的计划实现，给项目计划和论证工作证按预定的计划实现，给项目计划和论证工作带来了很大的困难。带来了很大的困难。 盲目增加软件开发人员并不能成比例地提高软盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理等方面的员的组织、协调、通信、培训和管理等方面的问题将更为严重问题将更为严重软件危机的表现软件危机的表现 软件质量差软件质量差 软件项目即使能按预定日期完成，结果却不尽软件项目即使能按预定日期完成，结果却不尽人意。人意。1965年至年至1970年，美国范登堡基地发射年，美国范登堡基地发射

6、火箭多次失败，绝大部分故障是由应用程序错火箭多次失败，绝大部分故障是由应用程序错误造成的。误造成的。 在在“软件作坊软件作坊”里，由于缺乏工程化思想的指里，由于缺乏工程化思想的指导，程序员几乎总是习惯性地以自己的想法去导，程序员几乎总是习惯性地以自己的想法去代替用户对软件的需求，软件设计带有随意性，代替用户对软件的需求，软件设计带有随意性，很多功能只是程序员的很多功能只是程序员的“一厢情愿一厢情愿”而已，这而已，这是造成软件不能令人满意的重要因素。是造成软件不能令人满意的重要因素。软件危机的表现软件危机的表现 软件维护困难软件维护困难 由于在软件设计和开发过程中，没有严格遵循由于在软件设计和开

7、发过程中，没有严格遵循软件开发标准，各种随意性很大，没有完整的软件开发标准，各种随意性很大，没有完整的真实反映系统状况的记录文档，给软件维护造真实反映系统状况的记录文档，给软件维护造成了巨大的困难。成了巨大的困难。 特别是在软件使用过程中，原来的开发人员可特别是在软件使用过程中，原来的开发人员可能因各种原因已经离开原来的开发组织，使得能因各种原因已经离开原来的开发组织，使得软件几乎不可维护。软件几乎不可维护。 有资料表明，工业界为维护软件支付的费用占有资料表明，工业界为维护软件支付的费用占全部硬件和软件费用的全部硬件和软件费用的40%-75%。 从软件危机谈起从软件危机谈起 软件危机的原因软件

8、危机的原因 用户需求不明确用户需求不明确 缺乏正确的理论指导缺乏正确的理论指导 软件规模越来越大软件规模越来越大 软件复杂度越来越高软件复杂度越来越高软件危机的原因软件危机的原因 用户需求不明确用户需求不明确 在软件开发完成之前，用户不清楚软件的具体在软件开发完成之前，用户不清楚软件的具体需求；需求； 用户对软件需求的描述不精确，可能有遗漏、用户对软件需求的描述不精确，可能有遗漏、有二义性、甚至有错误；有二义性、甚至有错误； 在软件开发过程中，用户还提出修改软件功能、在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求；界面、支撑环境等方面的要求； 开发人员对用户需求的理解与用

9、户本来愿望有开发人员对用户需求的理解与用户本来愿望有差异差异软件危机的原因软件危机的原因 缺乏正确的理论指导缺乏正确的理论指导 缺乏有力的方法学和工具方面的支持。由于软缺乏有力的方法学和工具方面的支持。由于软件不同于大多数其他工业产品，其开发过程是件不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造程序设计人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化，也是发生软件危性，加剧软件产品的个性化，也是发

10、生软件危机的一个重要原因。机的一个重要原因。 软件危机的原因软件危机的原因 软件规模越来越大软件规模越来越大 随着软件应用范围的增广，软件规模愈来愈大。随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，大型软件项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件系统的经验，而多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面的经验。而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确、有时还各类人员的信息交流不及时、不准确、有时还会产生误解。会产生误解。 软件项目开发人员不能有效地、独立自主地处软件项目开发人员

11、不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。产生疏漏和错误。 软件危机的原因软件危机的原因 软件复杂度越来越高软件复杂度越来越高 软件不仅仅是在规模上快速地发展扩大，而且软件不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。软件产品的特殊性和其复杂性也急剧地增加。软件产品的特殊性和人类智力的局限性，导致人们无力处理人类智力的局限性，导致人们无力处理“复杂复杂问题问题”。 所谓所谓“复杂问题复杂问题”的概念是相对的，一旦人们的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了采用先进的组织形式、开发方

12、法和工具提高了软件开发效率和能力，新的、更大的、更复杂软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前的问题又摆在人们的面前从软件危机谈起从软件危机谈起 如何克服软件危机如何克服软件危机 人们面临的不光是技术问题，更重要的是管理问题。管理不善必人们面临的不光是技术问题，更重要的是管理问题。管理不善必然导致失败然导致失败 。 要提高软件开发效率，提高软件产品质量，必须采用工程化的开要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。发方法与工业化的生产技术。 在技术上，应该采用基于复用的软件生产技术；在管理上，应该在技术上，应该采用基于复用的软件生产技

13、术；在管理上，应该采用多维的工程管理模式。采用多维的工程管理模式。 诞生了软件工程诞生了软件工程 用工程、科学和数学的原则和方法研制、维护计算机软件的有关用工程、科学和数学的原则和方法研制、维护计算机软件的有关技术及管理方法技术及管理方法 方法：方法：“如何做如何做”的技术手段的技术手段 工具：为方法提供的自动或者半自动的软件支撑环境工具：为方法提供的自动或者半自动的软件支撑环境 过程：将软件工程的方法和共计综合起来以达到合理、及时地进行过程：将软件工程的方法和共计综合起来以达到合理、及时地进行计算机软件开发地目的计算机软件开发地目的 软件体系结构是软件工程学科的分支软件体系结构是软件工程学科

14、的分支软件重用软件重用 软件重用是指在两次或多次不同的软件开软件重用是指在两次或多次不同的软件开发过程中重复使用相同或者相近软件元素发过程中重复使用相同或者相近软件元素的过程的过程 软件元素软件元素包括程序代码、测试用例、设计文档、包括程序代码、测试用例、设计文档、设计过程、需求分析文档甚至领域知识设计过程、需求分析文档甚至领域知识软件重用软件重用 软件系统极少是全新的软件系统极少是全新的 它们通常是它们通常是“主旋律的变奏主旋律的变奏” 建造建造“每类一个每类一个”的系统过于昂贵的系统过于昂贵 在任何工程领域都是如此在任何工程领域都是如此 在软件工程领域，尤其如此在软件工程领域，尤其如此 针

15、对针对“新新”问题，有大量现成的解决方案问题，有大量现成的解决方案 OTS (off-the-shelf 现成的现成的)系统系统 可能只提供部分解决方案可能只提供部分解决方案 代码行不再是基本的软件构造单元代码行不再是基本的软件构造单元 模块模块/构件成为开发、功能、演化构件成为开发、功能、演化/维护和复用的单元维护和复用的单元 类似于土木工程类似于土木工程重用的好处重用的好处 减少开发时间减少开发时间 潜在的潜在的“即插即用即插即用” 增加可靠性增加可靠性 通过测试通过测试 多重使用多重使用 改善质量改善质量 可移植性可移植性 互操作性互操作性 快速重新配置快速重新配置 用户编程用户编程 通

16、过构件组装通过构件组装软件重用的经济环境软件重用的经济环境 为复用而设计需要更高的前期投资为复用而设计需要更高的前期投资 开发成本增加开发成本增加10%至至50% 维护可复用资产库的附加成本维护可复用资产库的附加成本 可复用构件的维护可复用构件的维护 当一个构件被复用时，这些成本将得到补偿当一个构件被复用时，这些成本将得到补偿 成本节省成本节省 2倍倍 至至 20倍倍 需要远见需要远见 管理层的支持是必须的管理层的支持是必须的 OTS复用伴随着一定的风险复用伴随着一定的风险 缺乏信任缺乏信任 被复用软件未知的可靠性被复用软件未知的可靠性 被复用软件不充分的理解被复用软件不充分的理解 成本和预算

17、超支的可能成本和预算超支的可能复用的技术困难复用的技术困难 OTS系统没有包含可清晰辨识的构件系统没有包含可清晰辨识的构件 OTS构件粒度过大或过小构件粒度过大或过小 OTS构件没有正好提供所要求的功能集构件没有正好提供所要求的功能集 OTS构件的规约和集成不可预见地复杂构件的规约和集成不可预见地复杂 复用一个构件的附加成本可能比重新开发更高复用一个构件的附加成本可能比重新开发更高 定位定位/选取选取 理解理解 提取提取 评估评估/适应性改造适应性改造 集成集成软件复用的实情软件复用的实情Krueger 1992 复用技术要想有效，必须缩短系统的初始概念和复用技术要想有效，必须缩短系统的初始概

18、念和最终可执行实现之间的距离最终可执行实现之间的距离 复用技术要想有效，必须使复用制品的难度低于复用技术要想有效，必须使复用制品的难度低于重新构造的难度重新构造的难度 选择一个制品复用，必须知道它做什么选择一个制品复用，必须知道它做什么 要想有效地复用一个软件制品，必须能够以比构要想有效地复用一个软件制品，必须能够以比构造它更短的时间内发现它造它更短的时间内发现它软件体系结构的焦点和范围软件体系结构的焦点和范围 软件体系结构是一个软件系统的设计图软件体系结构是一个软件系统的设计图(blueprint) 解决复杂性问题解决复杂性问题 提高复用和构件市场的潜力提高复用和构件市场的潜力 包含形式化方

19、法包含形式化方法 两个主要焦点两个主要焦点 系统结构系统结构 需求和实现之间的对应需求和实现之间的对应 构件构件 + 组装规则组装规则 + 行为规则行为规则 理解系统级关注的框架理解系统级关注的框架 全局流动率，通讯模式，执行控制机构，可升级性，全局流动率，通讯模式，执行控制机构，可升级性，系统演化路径，容量，吞吐量，一致性，构件兼容性，系统演化路径，容量，吞吐量，一致性，构件兼容性，等等软件体系结构的软件体系结构的发展史发展史“无体系结构无体系结构”设计阶段设计阶段萌芽阶段萌芽阶段以汇编语言进行小规模应用程序开以汇编语言进行小规模应用程序开发为特征发为特征以描述系统的高层抽象结构为中心，以描

20、述系统的高层抽象结构为中心，不关心具体的建模细节，划分了体系不关心具体的建模细节，划分了体系结构模型与传统软件结构的界限，该结构模型与传统软件结构的界限，该阶段以阶段以KruchtenKruchten提出的提出的“4+14+1”模型为模型为标志标志出现了从不同侧面描述系统的结构模出现了从不同侧面描述系统的结构模型，以型，以UMLUML为典型代表为典型代表。出现了程序结构设计主题，以控制流出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征图和数据流图构成软件结构为特征高级阶段高级阶段初期阶段初期阶段软件体系结构的软件体系结构的发展史发展史PerryPerry和和WolfWolf认为认

21、为未来的年代是研究软件体系结构的时代未来的年代是研究软件体系结构的时代 概念起源概念起源(1) 对软件体系结构的研究可以追溯到对软件体系结构的研究可以追溯到20世纪世纪60年代，年代，当时主要是对软件结构的研究。当时主要是对软件结构的研究。 1969年，年，Brooks提出提出“概念结构概念结构” In programming, the term architecture was first used to mean a description of a computer system that applied equally to more than one actual system 体系

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

23、划分和结构化，而不是简单地编程以产生正确的结果确的结果 以操作系统为例，以操作系统为例，Dijkstra首次提出首次提出“层次结构层次结构”的想的想法，程序被归结到不同的层次，只有相邻层次的程序法，程序被归结到不同的层次，只有相邻层次的程序可以互相访问可以互相访问 通过上述系统组织所展现出的概念完整性，可以减轻通过上述系统组织所展现出的概念完整性，可以减轻开发和维护的负担开发和维护的负担概念起源概念起源(3) 1970年代初，年代初，David Parnas提出一系列重要的思提出一系列重要的思想想 1972年，信息隐蔽年，信息隐蔽 (information-hiding) 1974年，软件结构

24、年，软件结构 (software structures) 1975年，程序家族年，程序家族 (program families) 一个程序家族是一组程序（并非所有这些程序已一个程序家族是一组程序（并非所有这些程序已经或将被构造），把它们作为一组看待是有益或经或将被构造），把它们作为一组看待是有益或有用的有用的 理论上，一个程序家族可以通过遍历一个决策树进行理论上，一个程序家族可以通过遍历一个决策树进行枚举，树的叶节点代表装配好的、可执行的系统枚举，树的叶节点代表装配好的、可执行的系统 这个概念支持从现存的家族成员导出新成员的想法，这个概念支持从现存的家族成员导出新成员的想法，过程是在决策树上回

25、溯，直到达到一个公共的节点过程是在决策树上回溯，直到达到一个公共的节点（决策点），然后沿着新的路径导出希望的成员（决策点），然后沿着新的路径导出希望的成员概念起源概念起源(4) 在决策树上越靠近根节点的部分，越代表了对程在决策树上越靠近根节点的部分，越代表了对程序家族成员保持稳定的那些早期设计决策序家族成员保持稳定的那些早期设计决策 在这样的上下文中，早期决策代表特定的体系结构在这样的上下文中，早期决策代表特定的体系结构 后期决策（靠近叶节点）代表琐细、易变的决策，例后期决策（靠近叶节点）代表琐细、易变的决策，例如编译时刻、甚至加载时刻的常量如编译时刻、甚至加载时刻的常量 程序家族概念对软件体

26、系结构的意义在于，软件程序家族概念对软件体系结构的意义在于，软件体系结构包含了决策树根部或靠近根部的那些决体系结构包含了决策树根部或靠近根部的那些决策策 1976年，年，Frank DeRemer和和Hans Kron提出了模提出了模块连接语言块连接语言MIL75 “Programming-in-large versus programming-in-small”,IEEE Trans. on SE, June 1976概念起源概念起源(5) 以编译器为例，在以编译器为例，在19701980年代，编译器设计年代，编译器设计发展成为标准的程序发展成为标准的程序 对所有编译器公共的决策被复用，例如

27、，词法分析器、对所有编译器公共的决策被复用，例如，词法分析器、语法分析器、语义树、属性文法、目标代码生成器、语法分析器、语义树、属性文法、目标代码生成器、优化器，等优化器，等 许多其他领域的成员之间，呈现出许多其他领域的成员之间，呈现出 公共结构，互连策略，功能到构件的分配，构件接口，公共结构，互连策略，功能到构件的分配，构件接口，整体合理化基础整体合理化基础 软件体系结构的工作可被看作一种事后努力软件体系结构的工作可被看作一种事后努力 为可复用的家族范围的设计信息提供结构化的仓库为可复用的家族范围的设计信息提供结构化的仓库 试图整理程序家族各成员之间的共性，从而家族成员试图整理程序家族各成员

28、之间的共性，从而家族成员内在的高层设计决策不需要重复地发明、验证和描述内在的高层设计决策不需要重复地发明、验证和描述概念起源概念起源(6) 从从1980年代初期开始，人们在软件设计方面的注年代初期开始，人们在软件设计方面的注意力逐渐集中到面向对象方法上。经过二十多年意力逐渐集中到面向对象方法上。经过二十多年的研究和实践，人们形成了这样一个共识：的研究和实践，人们形成了这样一个共识： 对象并不是解决所有设计问题的灵丹妙药，软件工程对象并不是解决所有设计问题的灵丹妙药，软件工程必须超越面向对象方法，形成以体系结构为中心的新必须超越面向对象方法，形成以体系结构为中心的新方法方法 面向对象方法在软件体

29、系结构设计中存在的误区面向对象方法在软件体系结构设计中存在的误区 基本特征：模块化、封装、继承、多态等基本特征：模块化、封装、继承、多态等 OO程序员更多关注的是低层次，而不是高层次的抽象程序员更多关注的是低层次，而不是高层次的抽象 对象（类）的粒度过小：趋向于实现层次对象（类）的粒度过小：趋向于实现层次 对象（类）之间的关系类型过于一般化：依赖对象（类）之间的关系类型过于一般化：依赖(dependency)，泛化，泛化(generalization)，关联，关联(association)发展现状发展现状(1) 真正现在意义上的软件体系结构的研究始于，真正现在意义上的软件体系结构的研究始于，

30、Dewayne Perry和和Alexander Wolf PW1992, and David Garlan和和Mary Shaw GS1993的奠基性工作的奠基性工作, and 其他人对体系结构风格的分类和评价其他人对体系结构风格的分类和评价 KBA+1994, and 特定领域软件体系结构特定领域软件体系结构 (DSSAs)的研究和应用的研究和应用 DSSA1992 应用现状应用现状 体系结构的设计是建立在直觉和经验、而非坚实的工体系结构的设计是建立在直觉和经验、而非坚实的工程原则之上的程原则之上的 体系结构的描述是非形式化的和随意的，经常采用框体系结构的描述是非形式化的和随意的，经常采用

31、框线图（线图（box-and-line diagram）加文字注释的方法）加文字注释的方法发展现状发展现状(2) 应用后果应用后果 体系结构设计只是被开发人员含糊地理解体系结构设计只是被开发人员含糊地理解 难以对体系结构设计作出一致性或完整性的分析难以对体系结构设计作出一致性或完整性的分析 随着系统的演化，难以保持同系统原有体系结构的一随着系统的演化，难以保持同系统原有体系结构的一致，并且致，并且 难以开发有效的工具，辅助人们进行体系结构的设计、难以开发有效的工具，辅助人们进行体系结构的设计、性质分析和验证性质分析和验证发展现状发展现状(3) 在在“软件复用的展望和策略软件复用的展望和策略”

32、DoD1992报告中，报告中，美国国防部强调了美国国防部强调了“以体系结构为中心的复用以体系结构为中心的复用”在整个软件生存周期中，对于软件开发和支持的在整个软件生存周期中，对于软件开发和支持的重要性。重要性。 以下是一些同体系结构相关的研究项目，以下是一些同体系结构相关的研究项目， STARS, DOD CARDS, DOD PRISM, DOD RAPIDE , Stanford Uni. C2 style and ADL, California Uni. Able (Architecture Based Languages and Environments), CMU ACME Arch

33、itecture Interchange Language, CMU Vitruvius, CMU发展现状发展现状(4) 鉴于是否有一个稳定的软件体系结构，对软件的鉴于是否有一个稳定的软件体系结构，对软件的质量和成本影响很大，因此如何获得一个良好的质量和成本影响很大，因此如何获得一个良好的体系结构就成为当今软件界研究的重点。体系结构就成为当今软件界研究的重点。 当前软件体系结构研究和实践中，一些最活跃的当前软件体系结构研究和实践中，一些最活跃的领域包括：领域包括： 各种体系结构风格的汇编和总结各种体系结构风格的汇编和总结 体系结构描述语言体系结构描述语言 体系结构的形式化基础体系结构的形式化基

34、础 体系结构分析技术体系结构分析技术 基于体系结构的开发方法基于体系结构的开发方法 体系结构恢复和再工程体系结构恢复和再工程 支持体系结构设计的工具和环境支持体系结构设计的工具和环境 特定领域的软件体系结构特定领域的软件体系结构(DSSA) 软件体系结构的定义软件体系结构的定义(1) Perry and Wolf, 1992 软件体系结构（元素，形态，基本理论）软件体系结构（元素，形态，基本理论） 软件体系结构是一组具有特定形式的设计元素。这里软件体系结构是一组具有特定形式的设计元素。这里的设计元素被分为三类：处理元素的设计元素被分为三类：处理元素 (processing elements)、

35、数据元素、数据元素 (data elements)和连接元素和连接元素(connection elements) Kruchten, 1994 软件体系结构涉及软件高层结构的设计和实现软件体系结构涉及软件高层结构的设计和实现,通过组通过组装一定数量的具有良好形态的元素，以满足主要的功装一定数量的具有良好形态的元素，以满足主要的功能和性能需求，例如，可扩展性和可用性能和性能需求，例如，可扩展性和可用性 涉及抽象、分解涉及抽象、分解/组装、风格组装、风格/审美审美软件体系结构的定义软件体系结构的定义(2) Shaw and Garlan, 1996 一个软件系统的体系结构定义了组成系统的计算构件一

36、个软件系统的体系结构定义了组成系统的计算构件和构件之间相互作用的关系和构件之间相互作用的关系 软件体系结构层次的设计主要包括以下方面：软件体系结构层次的设计主要包括以下方面： 组成系统的构件描述组成系统的构件描述 构件之间的交互构件之间的交互 指导构件交互的模式，以及指导构件交互的模式，以及 施加在模式上的约束施加在模式上的约束 Bass, Clements, and Kazman, 1997 软件体系结构是一个系统的结构，包括软件构件、构软件体系结构是一个系统的结构，包括软件构件、构件的外部可见属性、以及构件关系件的外部可见属性、以及构件关系 这里，这里，“外部可见外部可见”属性指的是其他构

37、件可以对该构件所做属性指的是其他构件可以对该构件所做的假定，比如它提供的服务、性能特性、错误处理、共享资的假定，比如它提供的服务、性能特性、错误处理、共享资源的使用等源的使用等软件体系结构的定义软件体系结构的定义(3) Booch, Rumbaugh, and Jacobson, 1999 软件体系结构是一组关于下述问题的重要决定，软件体系结构是一组关于下述问题的重要决定， 软件系统的组织软件系统的组织 构成系统的结构化元素和它们接口的选择构成系统的结构化元素和它们接口的选择 这些模型元素之间的协作所描述的行为这些模型元素之间的协作所描述的行为 这些结构化和行为元素的组装，以形成更大的子系统这

38、些结构化和行为元素的组装，以形成更大的子系统 指导这种组织（静态和动态元素，以及它们的接口、协作和指导这种组织（静态和动态元素，以及它们的接口、协作和组装）的体系结构风格组装）的体系结构风格 软件体系结构不仅关注结构和行为，也关注使用、功能、性软件体系结构不仅关注结构和行为，也关注使用、功能、性能、弹性、复用、可理解性、经济和技术约束与折衷、审美能、弹性、复用、可理解性、经济和技术约束与折衷、审美考虑考虑软件体系结构的定义软件体系结构的定义(5) 一个软件系统的体系结构定义了组成系统的一个软件系统的体系结构定义了组成系统的 构件（构件（components），）， 连接件（连接件（connec

39、tors），和），和 它们之间的匹配它们之间的匹配 这里，构件用于实施计算和保存状态，连接件用这里，构件用于实施计算和保存状态，连接件用于表达构件之间的关系，构件和连接件之间的匹于表达构件之间的关系，构件和连接件之间的匹配表示了系统的拓扑结构。配表示了系统的拓扑结构。A2A1A3B1B2程序的构成以及发展 程序程序 = 算法算法 + 数据结构（数据结构（1960s ） 程序程序 = 子程序子程序 + 子程序（子程序（1970s ） 对象对象 = 算法算法 + 数据结构数据结构程序程序 = 对象对象 + 对象（对象（1980s） 程序程序 = 构件构件 + 连接件（连接件（1990s）构件与软件

40、重用构件与软件重用构件的定义构件的定义 构件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辨识的系统；结构上，它是语义描述、通讯接口和实现代码的复合体。 简单说，构件是具有一定的功能，能够独立工作或能同其他构件装配起来协调工作的程序体。 面向对象技术达到了类级重用(代码重用)。构件对一组类的组合进行封装。 构件模型的三个主要流派构件模型的三个主要流派构件与软件重用构件与软件重用 OMG（Object Management Group，对象管理集团）的CORBA（Common Object Request Broker Architecture，通用对象请求代理结构）S

41、un的EJB（Enterprise Java Bean）Microsoft的DCOM（Distributed Component Object Model，分布式构件对象模型）。 构件获取构件获取构件与软件重用构件与软件重用 从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可重用的构件； 通过遗留工程，将具有潜在重用价值的构件提取出来，得到可重用的构件； 从市场上购买现成的商业构件，即COTS（Commercial Off-The-Shell）构件； 开发新的符合要求的构件。 构件管理构件管理 构件与软件重用构件与软件重用 构件描述构件描述 构件分类与组织构件分类与组织 人员及权限

42、管理人员及权限管理对大量的构件进行有效的管理，以方便构件的存对大量的构件进行有效的管理，以方便构件的存储、检索和提取，是成功重用构件的必要保证。储、检索和提取，是成功重用构件的必要保证。构件管理的内容包括：构件管理的内容包括：构件模型及实现构件模型及实现 构件描述构件描述 构件模型是对构件本质的抽象描述，主要是为构件模型是对构件本质的抽象描述，主要是为构件的制作与构件的复用提供依据；构件的制作与构件的复用提供依据； 从管理角度出发，也需要对构件进行描述，例从管理角度出发，也需要对构件进行描述，例如：实现方式、实现体、注释、生产者、生产如：实现方式、实现体、注释、生产者、生产日期、大小、价格、版

43、本和关联构件等信息，日期、大小、价格、版本和关联构件等信息，它们与构件模型共同组成了对构件的完整描述。它们与构件模型共同组成了对构件的完整描述。构件管理构件管理 构件分类与组织构件分类与组织 关键字分类法关键字分类法 刻面分类法刻面分类法 超文本组织方法超文本组织方法 构件管理构件管理 关键字分类法关键字分类法图形用户界面键盘事件处理拖放处理数据录入对话框信息对话框文字窗口图形窗口对话框菜单事件处理窗口点击处理弹出式菜单主菜单 人员及权限管理人员及权限管理 一般来讲，构件库系统可包括五类用户，即注一般来讲，构件库系统可包括五类用户，即注册用户、公共用户、构件提交者、一般系统管册用户、公共用户、

44、构件提交者、一般系统管理员和超级系统管理员。理员和超级系统管理员。 4.1.4 4.1.4 软件体系结构设计原则软件体系结构设计原则抽象的原则抽象的原则分而治之的原则分而治之的原则封装和信息隐蔽原则封装和信息隐蔽原则模块化原则模块化原则高内聚和低耦合高内聚和低耦合关注点分离原则关注点分离原则策略和实现的分离原则策略和实现的分离原则接口和实现分离原则接口和实现分离原则4.1.5 4.1.5 软件体系结构的现状及发展方软件体系结构的现状及发展方向向应用现状应用现状形成研究热点，仍处于非形式化水平形成研究热点，仍处于非形式化水平软件体系结构的形式化方法研究软件体系结构的形式化方法研究 软件体系结构的

45、建模研究软件体系结构的建模研究 发展基于体系结构的软件开发模型发展基于体系结构的软件开发模型 软件产品线体系结构的研究软件产品线体系结构的研究 4.1.5 4.1.5 软件体系结构的现状及发展方软件体系结构的现状及发展方向向2. 研究热点研究热点提供新的软件体系结构描述语言提供新的软件体系结构描述语言对软件体系结构的专门知识的整理对软件体系结构的专门知识的整理 提供特定领域的体系结构框架提供特定领域的体系结构框架 提供软件体系结构的形式化基础提供软件体系结构的形式化基础 建立评价软件体系结构的方法建立评价软件体系结构的方法 4.1.5 4.1.5 软件体系结构的现状及发展方软件体系结构的现状及

46、发展方向向3. 发展方向发展方向各种各种ADLs之间的信息互换之间的信息互换 设计工具和环境设计工具和环境 体系结构再工程体系结构再工程 4.2 4.2 通用的软件体系结构通用的软件体系结构 主机主机/终端结构终端结构 两层结构两层结构客户客户/服务器体系结构服务器体系结构 浏览器浏览器/服务器结构服务器结构 三层三层C/S结构结构 三层三层C/S结构应用实例结构应用实例 4.2.1 4.2.1 主机主机/ /终端结构终端结构 早期计算机系统多是单机系统，多个用户早期计算机系统多是单机系统，多个用户是通过联机终端来访问的，没有网络的概是通过联机终端来访问的，没有网络的概念。即所谓的主机分时系统。念。即所谓的主机分时系统。 连接的终端完全没有事务处理的能力，只连接的终端完全没有事务处理的能力，只是输入和显示信息。是输入和显示信息。 所有的事务处理功能完全放在主机进行。所有的事务处理功能完全放在主机进行。因此主机的负载很重，整个系统的事务处因此主机的负载很重，整个系统的事务处理能力全部取决于主机。理能力全部取决于主机。 目前，主机终端模