软件工程第九章面向对象方法学.pptVIP

第九章 面向对象方法学 9.1 面向对象方法学引论 1 传统方法学的缺点 传统的生命周期方法学的本质，是在具体的软件开发工作开始之前，通过需求分析预先定义软件需求，然后一个阶段接着一个阶段有条不紊地开发用户所要求的软件，实现预先定义的软件需求。 但它并不能完全消除软件危机。生命周期方法学仍然有许多不足之处，对某些类型的软件开发，这种方法学比较适用，对另一些类型的软件则可能完全不适用。 存在的问题 1．生产率提高的幅度远不能满足需要 生命周期方法学强调需求分析的重要性，强调在每个阶段结束之前必须进行评审，从而提高了软件开发的成功率，减少了重大返工的次数； 开发过程中实行严格的质量管理，采用先进的技术方法（主要是结构分析、设计、编程技术）和软件工具，也都加快了软件开发的速度。 但开发效率的提高仍然很有限，提高的幅度远远赶不上对软件产品的需要。 从用户提出要求到他们最终得到所需要的目标系统，往往需要经过几年甚至更长的延迟时间。 2．软件重用程度很低 重用也称为再用或复用，是指同一事物不经修改或稍加改动就多次重复使用。 软件重用是节约人力，提高软件生产率的重要途径。 结构分析、结构设计和结构程序设计（简写为 SA－SD－SP）技术，虽然给软件产业带来了巨大进步，但却没能很好地解决软件 重用问题。 几乎每次开发一个新的软件系统时，都要针对这个具体的系统作大量重复而又繁琐的工作。 3.软件仍然很难维护 传统的生命周期方法学强调文档资料的重要性，规定最终的软件产品应该由完整、－致的配置成分组成；在软件开发整个过程中，始终强调软件的可读性、可修改性和可测试性是软件的重要质量指标。因此，对这样的软件所进行的维护属于结构化维护的范畴，可维护性有比较明显的提高，软件从不能维护变成基本上可以维护。 但实践表明，即使是用生命周期方法学开发出的软件，维护起来仍然相当困难，软件维护成本仍然很高。 4．软件往往不能真正满足用户需要 用传统方法开发涉及多种不同领域知识的大型软件系统，或开发需求模糊或需求动态变化的系统时，所开发出的软件系统往往不能真正满足用户的需要。 所谓“不能真正满足用户的需要”，主要有以下两种表现： 一种是开发人员不能完全获 得或不能彻底理解用户的需求，以致开发出的软件系统与用户预期的系统不一致，不能满足用户的需要。 另一种表现是，所开发出的系统不能适应用户需求经常变化的情况，系统的稳定性和可扩充性不能满足要求。 出现问题的原因 1．僵化的设计模型 瀑布模型意味着在生命周期各阶段间存在着严格的顺序性和依赖性。生命周期方法学特别强调预先定义需求的重要性。 要求在着手进行具体的开发工作之前，必须通过需求分析预先定义并“冻结”软件需求，然后再一步一步地实现这些需求。 实践表明，在系统建立起来之前，往往很难仅仅依靠分析就确定出一套完整、准确、一致、有效的应用需求，这种预先定义需求的方法更不能适应用户需求不断变化的情况： 预先定义需求的策略所作的假设，只对某些软件成立，对于多数软件并不成立。人们为了充实和细化他们的初步设想，通常需要经过在某个能运行的系统上的实践过程。 项目参与者之间存在通信鸿沟 良好的通信和相互理解对于保证工程成功是至关重要的。 各种文档，本质上是被动、静止的通信工具，通过它们来理解一个动态系统是困难的。 预先定义的需求可能是过时的 一些类型的软件，用户对它们的需求与外部环境、公司经营策略或经营内容等密切相关，因此是随时间变化的，在不同时间用户的需求可能有较大不同。采用预先定义需求的策略，在一年或数年之前预先指定对需求随时间变化的软件的需求，显然是不切实际的。 按照这样预先指定的需求开发软件，当软件开发出来的时候就已经过时了，不符合那时的用户需要了。然而按照生命周期方法学，在开发后期修改需求需付出很高代价，甚至根本不可能修改。 2．结构化技术的缺点 用这种技术开发出的软件，其稳定性、可修改性和可重用性都比较差。 围绕实现处理功能的“过程”来构造系统的。然而用户需求的变化大部分是针对功能的——不稳定性 清楚地定义了目标系统的边界，软件通过界面与客观世界通信。系统结构依赖于对系统边界的定义，很难把这样的系统扩展到新的边界——系统较难修改和扩充 把处理分解成子处理的过程多少带些任意性，并且把数据和操作作为分离的实体——可重用性差 2 软件工程的新途径 快速原型法 克服传统方法学的致命弱点——所开发出的系统往往不能真正满足用户的需要 1．区分两类不同的软件系统 一类系统的需求比较稳定而且能够预先指定——预先指定的系统。开发这类系统应该预先进行严格的形式化的需求分析，制定出很精确的需求规格说明，并在严格管理下采用形式化的开发生命周期。 另一类系统的需求是模糊的或随时间变化的，通常在系统安装运行之后，还会由用户驱动对需求