软件体系结构与设计模式第一章.ppt

第一章 软件危机, 什么是软件,1.1 软件, 软件的分类,1.1 软件,通用软件（Generic Software） 通用软件是由软件开发组织开发，面向市场用户公开销售的独立运行系统，有时也被称为套装软件。 举例：操作系统、数据库系统、字处理软件等 定制软件（Customized Software） 定制软件是由某个特定客户委托，软件开发组织在合同的约束下开发的软件。 举例：企业ERP 系统、卫星控制系统、空中交通指挥系统等, 软件的应用,1.1 软件, 软件的本质特征,1.1 软件,复杂性（Complexity ） 一致性（Conformity ） 可变性（Changeability ） 不可见性（Invisibility ）, 软件的本质特征,1.1 软件,复杂性 软件在规模上可能比任何由人类创造的其他实体都要复杂，复杂性是软件的本质特性。 软件的复杂性是必要属性 大量的组合状态 丰富的结构和相互依赖性 良好的接口用以封装内部的复杂性 开发问题也会增加复杂性 高效率的代码通常是复杂的 重用通用化的组件意味着复杂的状态连接 复杂的代码难以维护，导致设计上的更复杂, 软件的本质特征,1.1 软件,一致性 软件必须遵从人为的惯例并适应已有的技术和系统 软件必须遵循各种接口、协议和标准 有些情况下，兼容性是软件开发的目标 软件需要随接口的不同而改变，随时间的推移而变化，而这些变化是不同的人设计的结果。 许多复杂性来自保持与其他接口的一致，对软件的任何再设计，都无法简化这些复杂特性。, 软件的本质特征,1.1 软件,可变性 软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等，后者持续不断地变化着，这些变化无情地强迫着软件随之变化。 所有成功的软件都会发生变更！ 当人们发现软件很有用时，会在原有应用范围的边界，或者在超越边界的情况下使用软件； 功能扩展的压力主要来自那些喜欢基本功能，又对软件提出了很多新用法的用户们。, 软件的本质特征,1.1 软件,不可见性 软件是不可见的和无法可视化的 软件的客观存在不具有空间的形体特征 定义“需要做什么”成为软件开发的根本问题 人们一直试图使用不同的技术进行软件可视化 控制流程、数据流、依赖关系、UML、 这些技术仍然无法给出准确的、完整的描述 软件仍然保持着无法可视化的固有特性，从而剥夺了一些具有强大功能的概念工具的构造思路。这种缺憾不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流。, 软件工程的定义,1.2 软件的发展阶段,Bauer, 1972 软件工程是为了经济地获得能够在实际机器上高效运行的可靠软件而建立和使用的一系列好的工程化原则。 CMU, 1990 软件工程是以工程的形式应用计算机科学和数学原理，从而经济有效地解决软件问题。 IEEE, 1993 软件工程是将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护，即工程化应用到软件上；对中所述方法的研究。, 软件工程的关注焦点,1.2 软件的发展阶段,软件质量（Software Quality） 软件质量是软件产品与明确的和隐含的需求相一致的程度 软件质量通常采用一系列质量特性来描述 软件成本（Software Cost） 软件开发成本是指软件开发过程中所花费的费用 软件维护成本是指软件投入运行后软件变更所需的费用, 软件工程的三要素,1.2 软件的发展阶段, 软件工程面临的挑战,1.2 软件的发展阶段,遗留系统的问题 遗留系统是指那些过时或存在问题的计算机系统，通常是许多年以前开发的 挑战：既要以合理的成本维护和更新系统，又要能够继承系统中重要的商业信息和服务 异构系统的问题 网络环境下包含不同的硬件平台和软件系统 挑战：需要提出新的开发技术，能够使所开发的软件系统运行在不同的硬件平台和系统环境下, 软件工程面临的挑战,1.2 软件的发展阶段,高可信软件开发的要求 软件的重要作用要求正确性、可靠性、安全性等可信性质 挑战：如何在软件的开发和运行中保证其具有高可信的性质 软件开发方式的变化 网络时代带来的冲击 开源软件开发技术 Web 工程 挑战：研究分布式的软件体系结构和开发模式，探索与之相适应的软件工程策略, 软件危机的表现, 软件成本日益增长 开发进度难以控制 软件质量差 软件维护困难,1.3 软件危机, 软件危机的表现, 软件成本日益增长 20世纪50年代，软件成本在整个计算机系统成本中所占的比例为10%-20%。到20世纪60年代中期，软件成本在计算机系统中所占的比例已经增长到50%左右。 而且，该数字还在不断地递增，下面是一组来自美国空军计算机系统的数据：1955年，软件费用约占总费用的18%，1970年达到60%，1975年达到72%，1980年达到80%，1985年达到85%左右。,1.3 软件危机,1.1 从软件危机谈起, 软件危机的表现, 开发进度难以控制 由于软件是逻辑、智力产品，软件的开发需建立庞大的逻辑体系，这是与其他产品的生产不一样的。 在软件开发过程中，用户需求变化等各种意想不到的情况层出不穷，令软件开发过程很难保证按预定的计划实现，给项目计划和论证工作带来了很大的困难。 盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人员的组织、协调、通信、培训和管理等方面的问题将更为严重。,1.3 软件危机,1.1 从软件危机谈起, 软件危机的表现, 软件质量差 软件项目即使能按预定日期完成，结果却不尽人意。1965年至1970年，美国范登堡基地发射火箭多次失败，绝大部分故障是由应用程序错误造成的。 在“软件作坊”里，由于缺乏工程化思想的指导，程序员几乎总是习惯性地以自己的想法去代替用户对软件的需求，软件设计带有随意性，很多功能只是程序员的“一厢情愿”而已，这是造成软件不能令人满意的重要因素。,1.3 软件危机,1.1 从软件危机谈起, 软件危机的表现, 软件维护困难 由于在软件设计和开发过程中，没有严格遵循软件开发标准，各种随意性很大，没有完整的真实反映系统状况的记录文档，给软件维护造成了巨大的困难。 特别是在软件使用过程中，原来的开发人员可能因各种原因已经离开原来的开发组织，使得软件几乎不可维护。 有资料表明，工业界为维护软件支付的费用占全部硬件和软件费用的40%-75%。,1.3 软件危机,1.1 从软件危机谈起, 软件危机的原因, 用户需求不明确 缺乏正确的理论指导 软件规模越来越大 软件复杂度越来越高,1.3 软件危机,1.1 从软件危机谈起, 用户需求不明确 在软件开发完成之前，用户不清楚软件的具体需求； 用户对软件需求的描述不精确，可能有遗漏、有二义性、甚至有错误； 在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求； 开发人员对用户需求的理解与用户本来愿望有差异。,1.3 软件危机,1.1 从软件危机谈起, 软件危机的原因, 缺乏正确的理论指导 缺乏有力的方法学和工具方面的支持。由于软件不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化，也是发生软件危机的一个重要原因。,1.3 软件危机,1.1 从软件危机谈起, 软件危机的原因, 软件规模越来越大 随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确、有时还会产生误解。 软件项目开发人员不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。,1.3 软件危机,1.1 从软件危机谈起, 软件危机的原因, 软件复杂度越来越高 软件不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。软件产品的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。 所谓“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前。,1.3 软件危机,1.1 从软件危机谈起, 软件危机的原因, 如何克服软件危机,人们面临的不光是技术问题，更重要的是管理问题。管理不善必然导致失败 。 要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。 在技术上，应该采用基于重用的软件生产技术；在管理上，应该采用多维的工程管理模式。,1.3 软件危机,1.1 从软件危机谈起,1.4 软件过程,1.1 从软件危机谈起,1.4 软件过程,软件过程是软件工程人员为了获得软件产品而在软件工具的支持下实施的一系列软件工程活动。 软件过程应该明确定义 团队人员的工作和职责 所执行的活动及其顺序关系 活动的内容和步骤 软件过程的目标 标准化、预见性、生产率、高质量、计划进度和预算的能力,1.4 软件过程,软件过程的四个基本活动 规格说明（Specification） 定义软件功能以及对其使用的限制 软件开发（Development） 设计和实现满足规格说明的软件 软件确认（Validation） 验证软件以保证能够满足客户的要求 软件演化（Evolution） 改进软件以适应不断变化的需求 不同的组织或软件类型拥有不同的软件开发活动。,1.4 软件过程,软件规格说明,1.4 软件过程,软件设计与实现,1.4 软件过程,软件确认,1.4 软件过程,软件演化,1.4 软件过程,软件过程模型,软件过程模型 软件过程模型是对实际过程的抽象描述 包括软件过程的活动、软件产品以及参与人员的不同角色 常见的软件过程模型 瀑布模型 快速原型模型 增量模型 螺旋模型 形式化方法模型 基于组件的开发模型,1.4 软件过程,瀑布模型,1.4 软件过程,瀑布模型,适用 在开发的早期阶段软件需求被完整确定 挑战 实际的项目开发很少是线性的过程，客户很难明确地描述软件需求 缺点 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量 开发过程中很难响应客户的变更要求 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果,1.4 软件过程,快速原型模型,1.4 软件过程,快速原型模型,目的 减少开发风险和需求不确定性 缺点 原型系统的内部结构可能不好 开发人员需要掌握建立快速原型的开发技术和工具 适用 小型或中等规模的交互式系统 大型系统的某些部分，例如用户界面 生命周期较短的系统,1.4 软件过程,增量模型,1.4 软件过程,增量模型,优点 整个产品被分解成若干个构件逐步交付，用户可以不断地看到所开发软件的可运行中间版本 将早期增量作为原型有助于明确后期增量的需求 降低开发风险 重要功能被首先交付，从而使其得到最多的测试 缺点 需要软件具备开放式的体系结构 需求难以在增量实现之前详细定义，因此增量与需求的准确映射以及所有增量的有效集成可能会比较困难 容易退化为边做边改方式，使软件过程的控制失去整体性,1.4 软件过程,螺旋模型,1.4 软件过程,螺旋模型,螺旋回线 每一个回线表示开发过程的一个阶段 例如最中心的第一个回线可能与系统可行性有关，接着第二个回线与需求定义有关，第三个回线与软件设计有关等 四个步骤 确定该阶段目标、完成这些目标的可选方案及其约束条件 从风险角度分析方案的开发策略，努力排除各种潜在的风险，在需求不适当的情况下可能需要建造原型系统 软件开发和验证工作 评价该阶段的结果，并规划下一个开发阶段,1.4 软件过程,螺旋模型,优点 关注软件的重用 关注早期错误的消除 将质量目标放在首位 将开发阶段与维护阶段结合在一起 缺点 契约开发通常需要事先指定过程模型和发布产品 需要风险评估的经验,1.4 软件过程,形式化方法模型,1.4 软件过程,形式化方法模型,适用 特别适合于那些对安全性、可靠性和保密性要求极高的软件系统，这些系统需要在投