软件工程_张海蕃_第五版PPT

1、课程介绍及要求课程介绍及要求课程介绍和要求教学目标n 为什么要学习这门课程为什么要学习这门课程l 有助于正确理解和认识有助于正确理解和认识“软件软件”的概念及其特点的概念及其特点l 理解软件开发面临的问题和挑战理解软件开发面临的问题和挑战l 掌握软件工程的原则、方法和思想来系统地开发软掌握软件工程的原则、方法和思想来系统地开发软件，尤其是复杂、庞大的软件的开发件，尤其是复杂、庞大的软件的开发l 了解和接触软件开发所需的各种技术手段了解和接触软件开发所需的各种技术手段n 理解、掌握和运用理解、掌握和运用理解n什么是软件工程什么是软件工程n为什么需要软件工程为什么需要软件工程(产生背景产生背景)n

2、软件工程需要解决那些问题软件工程需要解决那些问题n软件工程涉及那些方面内容软件工程涉及那些方面内容掌握n软件工程软件工程l概念概念l技术技术l过程过程l手段手段l工具工具运用n运用工程化思想进行软件开发运用工程化思想进行软件开发l需求分析需求分析l软件设计软件设计l程序设计程序设计l软件维护软件维护先导要求程序设计语言最好有一定的软件开发经验学习要求n听听l理解知识点和思想理解知识点和思想l无需死记硬背无需死记硬背n做做l实践实践l体会软件工程的原则、方法和技术，在体会软件工程的原则、方法和技术，在实践中提高实践中提高l培养抽象思维能力培养抽象思维能力l培养独立解决问题的能力培养独立解决问题的

3、能力l培养合作精神培养合作精神n想想l阅读相关资料阅读相关资料n教材教材l软件工程导论软件工程导论第五版第五版 张海藩编著张海藩编著 清华大清华大学出版社学出版社n参考教材参考教材l软件工程软件工程第八版第八版 （英）（英）Ian Sommerville 著著 程程成译成译 机械工业出版社机械工业出版社l软件工程软件工程 实践者的研究方法实践者的研究方法第六版第六版 （美）（美）Roger S. Pressman著著 郑人杰译郑人杰译 机械工业出版社机械工业出版社l实用软件工程实用软件工程 郑人杰编著郑人杰编著 清华大学出版社清华大学出版社教学与考核教学与考核n必修考查课，共必修考查课，共48

4、学时，其中理论学时，其中理论38学学时，实验时，实验10学时学时n平时（作业、考勤）平时（作业、考勤）20%，实验，实验20%，试卷试卷60%例例: : 美国美国IBM公司在公司在1963年至年至1966年开发的年开发的IBM360机的操作系统。这一项目花了机的操作系统。这一项目花了5000人一人一年的工作量，最多时有年的工作量，最多时有1000人投入开发工作，人投入开发工作，写出了近写出了近100万行源程序。万行源程序。.据统计，这个据统计，这个操作系统每次发行的新版本都是从前一版本中操作系统每次发行的新版本都是从前一版本中找出找出1000个程序错误而修正的结果个程序错误而修正的结果. 典型

5、案例典型案例1 这个项目的负责人这个项目的负责人F. D. BrooksF. D. Brooks事后总结事后总结了他在组织开发过程中的沉痛教训时说：了他在组织开发过程中的沉痛教训时说：“.正像一只逃亡的野兽落到泥潭中做垂正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。脱灭顶的灾难。.程序设计工作正像这样程序设计工作正像这样一个泥潭，一个泥潭，.一批批程序员被迫在泥潭中一批批程序员被迫在泥潭中拼命挣扎，拼命挣扎，.谁也没有料到问题竟会陷入谁也没有料到问题竟会陷入这样的困境这样的困境.”.”。IBM360IBM360操作

6、系统的历史操作系统的历史教训成为软件开发项目的典型事例为人们所记教训成为软件开发项目的典型事例为人们所记取。取。典型案例典型案例11 人员人员n挫伤人员的积极性挫伤人员的积极性n人员素质低人员素质低n对有问题的员工失控对有问题的员工失控n个人英雄主义个人英雄主义n项目后期加入人员项目后期加入人员n办公环境拥挤嘈杂办公环境拥挤嘈杂n开发人员与客户之间产生摩擦开发人员与客户之间产生摩擦n不现实的预期不现实的预期n缺乏有效的项目支持缺乏有效的项目支持n缺乏各种角色的齐心协力缺乏各种角色的齐心协力n缺乏用户介入缺乏用户介入n政治高于物质政治高于物质n充满想象充满想象典型错误典型错误2 过程过程n过于乐

7、观的计划过于乐观的计划n缺乏足够的风险管理缺乏足够的风险管理n承包人导致的失败承包人导致的失败n缺乏计划缺乏计划n在压力下放弃计划在压力下放弃计划n在模糊的项目前期浪费时间在模糊的项目前期浪费时间n前期活动不合要求前期活动不合要求n设计低劣设计低劣n缺少质量保证措施缺少质量保证措施n缺少管理控制缺少管理控制n太早或过于频繁的集成太早或过于频繁的集成n项目估算是遗漏了必要的任务项目估算是遗漏了必要的任务n追赶计划追赶计划n鲁莽编码鲁莽编码典型错误典型错误3 产品产品n需求的镀金需求的镀金n功能蔓延功能蔓延n开发人员镀金开发人员镀金n又推又拉的交易又推又拉的交易n研究导向的开发研究导向的开发典型错

8、误典型错误4 技术技术n 使用不成熟的技术使用不成熟的技术n 使用不适合的技术使用不适合的技术n 不恰当的使用不恰当的使用典型错误典型错误 处在十字路口的中国软件产业n 主权大国必须建立基于自主技术的、 完整的软件产业体系。 软件本国提供率：中国1/3左右，美国97%n “印度模式”还是“中国模式”n 软件人才结构不合理结构不合理，缺乏缺乏中中高级高级软软 件人才件人才，软件人员缺乏软件工程化的概，软件人员缺乏软件工程化的概念。念。 “软件工程”课程 “ “软件工程软件工程”课程教学与实践课程教学与实践的目标的目标u 转变对软件的认识： 上升 程序 系统u 转变思维定式： 上升 程序员 系统工

9、程师 (系统分析员)n 工程化训练系统分析员的地位系统分析员的地位用户用户分析员分析员程序员程序员软件工程技术的明显特点软件工程技术的明显特点u 强调规范化u 强调文档化第1章 软件工程概述软件工程产生的背景软件工程产生的背景(软软件危机件危机) 软件工程定义软件工程定义软件工程方法学软件工程方法学软件过程模型软件过程模型小结小结1.1 软件工程产生的背景1)软 件 a. 软件的定义Software）Program）Data）Document） Software = Program + Data + Document24非常复杂n逻辑复杂逻辑复杂l远远高于硬件的逻辑复杂远远高于硬件的逻辑复杂度

10、度n开发复杂开发复杂l成本难以估算成本难以估算l进度难以控制进度难以控制l人员素质要求人员素质要求l质量得不到保证质量得不到保证p96年年Ariane火箭发射失败，浮点数火箭发射失败，浮点数转换时发生错误转换时发生错误1.1 软件工程产生的背景软件工程产生的背景 b、软件的特征、软件的特征成本高(1/2)1.1 软件工程产生的背景软件工程产生的背景 b、软件的特征、软件的特征Copyright Xinjun Mao课程介绍和要求成本高(2/2)Copyright Xinjun Mao课程介绍和要求风险大n1995年美国年美国Standish咨询集团的统计咨询集团的统计分析分析(至至90年代初的

11、软件项目执行情况年代初的软件项目执行情况)l成功：成功：16.2%l失败：失败：31l受到挑战：受到挑战：53.8%n近几年来的统计数据近几年来的统计数据l成功：成功：26l失败：失败：28l受到挑战：受到挑战：46%1.1 软件工程产生的背景软件工程产生的背景 b、软件的特征、软件的特征维护困难n维护形式多样化维护形式多样化l改正性：修改故障改正性：修改故障l完善性：增加功能完善性：增加功能l适应性：移植适应性：移植n维护成本越来越高维护成本越来越高l55%到到70n维护带来的问题维护带来的问题1.1 软件工程产生的背景软件工程产生的背景 b、软件的特征、软件的特征1.1 软件工程产生的背景

12、c. c. 软件的发展软件的发展早期早期面向批处理有限的分布自定义软件第二阶段第二阶段多用户实时数据库软件产品第三阶段第三阶段分布式系统嵌入“智能”低成本硬件消费者的影响第四阶段第四阶段强大的桌面系统面向对象技术专家系统人工神经网络并行计算网路计算机195019601970198019902000 1968年年10月，北大西洋公约组织（月，北大西洋公约组织（NATO）的科学家在德）的科学家在德国召开的学术会议上正式提出了软件危机问题。国召开的学术会议上正式提出了软件危机问题。1.1 软件工程产生的背景2) 2) 、软件危机、软件危机 a a、软件危机的表现（、软件危机的表现（1/31/3） 成

13、本高IBM 360 OS, 5000多人年，耗时4年(19631966)，花费2亿多美元美国空军：1955年软件占总费用(计算机系统)的18%，70年60%，85年达到85美国全球军事指挥控制系统，硬件1亿美元，软件高达7.2亿美元计算机软件和硬件费用比软件质量得不到保证软件应用面的扩大：科学计算、军事、航空航天、工业控制、企业管理、办公、家庭软件越来越多的应用于安全攸关(safety critical)的系统，对软件质量提出更高的要求80年代欧洲亚丽安娜火箭的发射失败，原因是软件错误美国阿托拉斯火箭的发射失败，原因是软件故障英国1986年开发的办公室信息系统Folios经4年，因性能达不到要

14、求，1989年取消日本第5代机因为软件问题在投入50亿美元后于1993年下马由于软件质量问题导致失败的软件项目非常多a a、软件危机的表现（、软件危机的表现（2/32/3）a a、软件危机的表现（、软件危机的表现（3/33/3）进度难以控制项目延期比比皆是由于进度问题而取消的软件项目较常见只有一小部分的项目能够按期完成维护非常困难软件维护的多样性软件维护的复杂性软件维护的副作用b b、产生软件危机的原因、产生软件危机的原因-与软件本身的特点有关 (难于维护, 逻辑复杂)-与软件开发与维护的方法不正确有关:-软件软件程序程序-急于求成急于求成= =拔苗助长拔苗助长-各自为阵无方法各自为阵无方法/

15、 /学学n开发一个具有一定规模和复杂性的软件开发一个具有一定规模和复杂性的软件系统与编写一个简单的程序不一样系统与编写一个简单的程序不一样l正如建设狗窝和高楼大厦正如建设狗窝和高楼大厦n大型、复杂软件系统的开发是一项工程，大型、复杂软件系统的开发是一项工程，必须按照工程化的方法组织软件的生产必须按照工程化的方法组织软件的生产和管理，必须经过分析、设计、实现、和管理，必须经过分析、设计、实现、测试、维护等一系列软件过程和活动测试、维护等一系列软件过程和活动C C、软件工程（学）因危机而产生、软件工程（学）因危机而产生d、软件工程(学):克服软件危机的努力（1）从管理的角度）从管理的角度 软件开发

16、过程的研究、文档的软件开发过程的研究、文档的标准化以及人们标准化以及人们 的交流方式等的交流方式等（2）软件开发方法的研究）软件开发方法的研究结构化软件开发方法结构化软件开发方法, 面向对象的面向对象的开发开发提出有效的方法和工具支持软件开发1968年提出软件工程概念和思想20世纪70年代的结构化软件开发方法20世纪80年代的面向对象的软件开发方法新的技术: 软件重用、快速原型、需求工程典型技术: COM, Java, C+, J2EE, .Net, .支撑工具和环境：Jbuilder, Visual Studio, WebLogic, 1 1、解决危机的技术途径、解决危机的技术途径20世纪8

17、0年代末，美国DoD和工业界开始认识到管理的重要性美国DoD的一项研究表明，70%的项目由于管理不善导致难以控制进步、成本和质量；进一步的研究发现：管理是影响软件项目成功开发的全局性因素，而技术只影响局部如果软件开发组织不能对软件项目进行有效管理，就不能充分发挥软件开发方法和工具的潜力，也就不能高效率地开发出高质量的软件产品2 2、解决危机的管理途径、解决危机的管理途径1.2 软件工程定义(1) The establishment and use of sound engineering principles (methods) in order to obtain economically

18、software that is reliable and works on real machines. (1968- Fritz Bauer) 软件工程就是建立和使用一套合理软件工程就是建立和使用一套合理的工程原理，从而经济地获得可靠的、的工程原理，从而经济地获得可靠的、可以在实际机器上高效运行的软件。可以在实际机器上高效运行的软件。1.2 软件工程定义(2) Software engineering. (1) The application of a systematic, disciplined, quantifiable approach to the development, op

19、eration, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). (IEEE(The Institute for Electrical and Electronic engineers) Std 610-1990.） 软件工程是软件工程是：（：（1）把系统的、规范的、把系统的、规范的、 可度量的途径应用于软件开发、运行和维护可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；（过程，也就

20、是把工程应用于软件；（2）研究）研究（1）中提到的途径。中提到的途径。1.2 软件工程定义总之：总之： 软件工程是应用计算机科学、数学及软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。它借鉴管理科学等原理开发软件的工程。它借鉴传统工程的原则、方法，以提高质量，降传统工程的原则、方法，以提高质量，降低成本为目的。低成本为目的。1.2 软件工程定义软件工程的基本原理软件工程的基本原理 用分阶段的生命周期计划严格管用分阶段的生命周期计划严格管理理 坚持进行阶段评审坚持进行阶段评审 实行严格的产品控制实行严格的产品控制 采用现代程序设计技术采用现代程序设计技术 结果应能清楚地审查结果应能

21、清楚地审查 开发小组的人员应该少而精开发小组的人员应该少而精 承认不断改进软件工程实践的必承认不断改进软件工程实践的必要性要性软件工程：软件工程： 一种层次化技术一种层次化技术质量关注点质量关注点过程过程方法方法工具工具 软件工程层次图软件工程层次图软件工程三个要素软件工程三个要素：工具、方法、过程工具、方法、过程基础层，综合方法基础层，综合方法及工具，定义方法及工具，定义方法使用的顺序，所需使用的顺序，所需要的管理要的管理为软件开发提供为软件开发提供“如何做如何做”的技术的技术为软件开发提供自动或为软件开发提供自动或半自动的软件支撑环境半自动的软件支撑环境，建立计算机辅助软件，建立计算机辅助

22、软件工程工程(CASE)的软件开的软件开发支撑系统发支撑系统1. 传统方法学传统方法学2. 面向对象方法学面向对象方法学1.3 软件生命周期软件生命周期软件生命周期模型 问题定义 软件定义 可行性研究 需求分析 总体设计 详细设计软件生命周期 软件开发 编码 单元测试 综合测试 运行维护 持久满足用户需求各阶段基本任务各阶段基本任务各阶段基本任务各阶段基本任务1.4 软件过程模型 软件过程是为了获得高质量软件软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。了完成各项任务的工作步骤。工作任务里程碑、交付物SQA点 A

23、process defines Who is doing What, When, and How, in order to reach a certain goal.公共过程框架公共过程框架辅助活动辅助活动框架活动框架活动任务集合任务集合软件过程软件过程1.4 软件过程模型 软件生命周期的每一阶段都有明确的任务，把规模大、结构复杂、管理复杂的软件开发变得容易控制和管理。 各个阶段的活动如何衔接，开发过程中采用什么样的策略，应遵守什么样的规定和制约，将这些活动框架（忽略不必要的细节）用一种模型表示出来，称为软件过程模型软件过程模型（或软件软件开发模型开发模型或或软件生命周期模型软件生命周期模型）

24、。 也就是说， 软件过程模型是软件开发全部软件过程模型是软件开发全部过程、活动和任务的结构框架过程、活动和任务的结构框架。1.4 软件过程模型（1 1）瀑布模型）瀑布模型( (Waterfall Model ） 传统瀑布模型传统瀑布模型1.4 软件过程模型传统瀑布模型的特点传统瀑布模型的特点 提供了软件过程模型的基本框架（模板）。 强调了每一阶段活动的严格顺序。 质量保证观点：以经过评审确认了的阶段工作 产品（文档）驱动下一阶段的工作，便于管理。 是一种整体开发模型，程序的物理实现集中在 开发阶段的后期，用户在最后才能看到自己的 产品。 传统瀑布模型存在什么问题？传统瀑布模型存在什么问题？1.

25、4 软件过程模型实际的瀑布模型实际的瀑布模型1.4 软件过程模型瀑布模型适合于用户需求明确、完整、无瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。瀑布模型的成重大变化的软件项目开发。瀑布模型的成功在很大程度上是由于它基本上是一种文功在很大程度上是由于它基本上是一种文档驱动的模型。档驱动的模型。n “瀑布模型是由文档驱动的瀑布模型是由文档驱动的”这个事实也这个事实也是它的一个主要缺点。是它的一个主要缺点。 实际项目很少按照该模型给出的顺序进实际项目很少按照该模型给出的顺序进行；行； 用户常常难以清楚地给出所有需求；用户常常难以清楚地给出所有需求； 用户必须有耐心，等到系统开发完成。

26、用户必须有耐心，等到系统开发完成。 瀑布模型的优缺点瀑布模型的优缺点1.4 软件过程模型（2）原型模型）原型模型快速原型模型（快速原型模型（Rapid Prototype Model） 在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，快速建造一个原型（可运行的软件），然后进行评估，进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。建造建造/ /修改修改原型原型 听取用听取用 户意见户意见用户用户测试测试运行运行原型原型原型实现范型原型实现范型1.4 软件过程模型快速原型快

27、速原型验证验证规格说明规格说明验证验证设计设计验证验证编码编码测试测试综合测试综合测试维护维护变化的需求变化的需求验证验证维护过程维护过程开发过程开发过程1.4 软件过程模型原型模型存在的问题原型模型存在的问题 为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。 为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。 开发过程不便于管理。有效的使用原型模式有效的使用原型模式 建造原型仅是为了定义需求，之后就被抛弃（或被部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。1.4 软件过程模型（3 3）增量模型）增量模型 ( (Inc

28、remental Model) )是一种渐进地开发逐步完善的软件版本的模型。需求分析需求分析验证验证规格说明规格说明验证验证设计设计验证验证维护维护针对每个构件完成针对每个构件完成详细设计、编码和详细设计、编码和集成，经测试后交集成，经测试后交付给用户付给用户1.4 软件过程模型分析分析分析分析设计设计设计设计编码编码编码编码测试测试测试测试增量1增量2 增量3增量4 交付交付交付交付 反复的应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型反复的应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型过程产生一个过程产生一个“增量增量”的发布或提交，该增量均是一个可运行的产品。的发布或提交

29、，该增量均是一个可运行的产品。 早期的版本实现用户的基本需求，并提供给用户评估的平台。早期的版本实现用户的基本需求，并提供给用户评估的平台。增量模型增量模型1.4 软件过程模型1.在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。2.整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。3.逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。4.采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报

30、。增量模型的优点增量模型的优点1.4 软件过程模型增量模型的困难增量模型的困难1. 在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。软件体系结构必须是开放的。2. 开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。3. 多个构件并行开发，具有无法集成的风险。1.4 软件过程模型（4）螺旋模型）螺旋模型 (Spiral Model) 软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所

31、冒的风险也越大。 对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来，加入了风险分析。在该模型中，软件开发是一系列的增量发布，早期的迭代中，发布的增量可能是一个纸上的模型或原型，在以后的迭代中，逐步产生系统更加完善的版本。 螺旋模型的基本思想是降低风险。1.4 软件过程模型快速原型快速原型验证验证规格说明规格说明验证验证设计设计验证验证编码编码测试测试综合测试综合测试维护维护变化的需求变化的需求验证验证风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析可看作在每可看作在每个阶段之前个阶段之前都增加了风都增加了风险分

32、析过程险分析过程的快速原型的快速原型模型。模型。简化的螺旋模型简化的螺旋模型1.4 软件过程模型完整的螺旋模型完整的螺旋模型 螺旋模型风险风险分析分析工程工程实施实施用户通信用户通信用户用户评估评估产品维护项目产品维护项目产品增强项目产品增强项目新产品开发项目新产品开发项目概念开发项目概念开发项目计划计划建造及发布建造及发布1.4 软件过程模型螺旋模型的优点螺旋模型的优点对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标减少了过多测试或测试不足维护和开发之间并没有本质区别螺旋模型的特点螺旋模型的特点风险驱动，需要相当丰富的风险评估经验和专门知识，否则风

33、险更大主要适用于内部开发的大规模软件项目，随着过程的进展演化，开发者和用户能够更好的识别和对待每一个演化级别上的风险随着迭代次数的增加，工作量加大，软件开发成本增加1.4 软件过程模型（5 5）面向对象模型）面向对象模型喷泉模型喷泉模型( (Fountain Model) )分析分析设计设计实现实现测试测试集成集成演化演化特点特点：主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征1.4 软件过程模型可重用部件组装模型可重用部件组装模型 (构件集成模型构件集成模型) (Component Integration Model) 构件构件（components)也称为组件，是一段

34、实现一系列有确定接口的程序体，具有自己的功能和逻辑，能同其他构件集成起来协调工作。 该模型支持软件重用软件重用（Reusability） ，对缩短软件开发周期、降低项目成本有重要的现实意义。同时，建造符合某应用领域体系结构标准的构件，可以用来搭建分布式的、跨越不同操作平台(集成化软件开发环境集成化软件开发环境（ISEE）)的软件，扩展了软件的应用前景，促进了软件标准化、商品化的发展。 因此，在此基础上专家们又提出了“基于构件的软件基于构件的软件工程工程”(CBSE)。 构件集成模型如下图所示：1.4 软件过程模型 构件集成模型构件集成模型 软件体系结构被建立后，必须用构件去充实，这些构件可从复

35、用库中获得，或者根据专门需要而开发。整个过程可以演化地进行，面向对象方法给予技术上的支持。1.4 软件过程模型Sommerville提出基于组件开发有两种思路：提出基于组件开发有两种思路：完成高层设计，对设计中的组件给出描述，以便找出可复用的组件，这些组件可在体系结构层次上加入或更详细的设计层次上加入。先根据需求搜寻可复用组件，再将设计建立在获得的组件基础上。这两种思路可结合起来。设计系统设计系统体系结构体系结构描述组件描述组件搜寻可复搜寻可复用组件用组件集成系统集成系统先完成架构设计的复用先完成架构设计的复用系统需求系统需求描述描述搜寻可复搜寻可复用组件用组件对需求作对需求作某些修改某些修改

36、体系结构体系结构设计设计集成系统集成系统复用驱动设计复用驱动设计1.4 软件过程模型 构件技术主要有三种流行标准： OMG的CORBA： 对象管理组织发布的公用对象请求代理体系结构对象管理组织发布的公用对象请求代理体系结构(Common Object Request Broker Architecture)。通。通过一个对象请求代理（过一个对象请求代理（ORB)提供一系列服务，使得一个提供一系列服务，使得一个构件和其他构件通信，而不管它们在系统中的位置，实现构件和其他构件通信，而不管它们在系统中的位置，实现了远程对象通过接口进行通信的机制。了远程对象通过接口进行通信的机制。 为了解决为了解决C

37、ORBA对象引用不透明、缺少多重接口、对象引用不透明、缺少多重接口、系统过于复杂等问题，专家们又开发了新一代面向对象中系统过于复杂等问题，专家们又开发了新一代面向对象中间件平台间件平台 ICE （ Internet Communications Engine互联网通信引擎）。使构建分布式应用系统更容易、性能互联网通信引擎）。使构建分布式应用系统更容易、性能和伸缩性更好。和伸缩性更好。 1.4 软件过程模型 微软的COM / DCOM： 微软开发了构件对象模型（微软开发了构件对象模型（Component Object Model)，它提供了运行于，它提供了运行于windows之上的单个之上的单个

38、应用系统使用不同厂商生产的构件的规约。基于分布式应用系统使用不同厂商生产的构件的规约。基于分布式环境下的环境下的COM称为称为DCOM (Distribute COM)。 SUN的 EJB ( Enterprise JavaBean )： 随着随着Java在企业级应用的地位日趋重要，在企业级应用的地位日趋重要，Sun提出了一个统一的企业级提出了一个统一的企业级Java平台平台J2EE（Java 2 Enterprise Edition）。在）。在J2EE中，中，EJB负责最核心的负责最核心的业务处理。它为服务器端的应用程序提供了一种与厂商业务处理。它为服务器端的应用程序提供了一种与厂商无关的无关的Java接口，让任何符合接口，让任何符合EJB规范的构件都可以运规范的构件都可以运行在每一台这样的服务器上。行在每一台这样的服务器上。 构件技术主要有三种流行标准：构件技术主要有三种流行标准：1.4 软件过程模型（6）统一软件开发过程 是由是由Rational公司