《软件工程方法与实践》—— 1.5 软件工程开发方法学-阿里云开发者社区

开发者社区> 华章出版社> 正文
登录阅读全文

《软件工程方法与实践》—— 1.5 软件工程开发方法学

简介: 在软件工程学科中,方法学用来表示一套涵盖整个软件生产过程的技术的集合。目前使用得较广泛的软件工程开发方法学,分别是结构化开发方法学和面向对象开发方法学。

本节书摘来自华章出版社《软件工程方法与实践》一 书中的第1章,第1.5节,作者窦万峰,更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.5 软件工程开发方法学

在软件工程学科中,方法学用来表示一套涵盖整个软件生产过程的技术的集合。目前使用得较广泛的软件工程开发方法学,分别是结构化开发方法学和面向对象开发方法学。

1.5.1 结构化开发方法学

结构化开发方法学自1968年提出后,经过几十年的发展,形成了一套完整的规范。构成结构化开发方法学的技术包括结构化分析、结构化设计、结构化编程和结构化测试,这些技术在以数据为主或小型系统方面得到广泛应用。
结构化开发方法学采用结构化方法来完成软件开发的各项任务,并使用适当的软件工具或软件工程环境支持结构化方法的运用。结构化开发方法学把软件的生存周期依次划分为若干个阶段,然后顺序地完成每个阶段的任务,从对问题的抽象逻辑分析开始,一个阶段接一个阶段地进行开发,从而降低了整个软件开发工程的困难程度。
结构化开发方法学获得成功的原因是,结构化方法要么是面向行为的,要么是面向数据的,但没有既面向数据又面向行为的。软件的基本组成部分包括产品的行为和这些行为操作的数据。有些结构化方法,如数据流分析是面向行为的,这些方法集中处理产品的行为,数据则是次要的;反之,有些方法,如JSP系统开发技术是面向数据的,这些方法以数据结构为中心,在数据结构上操作的行为则是次要的。
随着软件产品规模的不断增大,结构化开发方法学有时不能满足要求。换句话说,结构化方法处理50000行以下代码是有效的。然而,当今的软件产品,50000行或5000000甚至更多行代码的产品非常普遍。在结构化开发方法学中,软件维护的费用占到软件费用的2/3。

1.5.2 面向对象开发方法学

面向对象开发方法学把数据和行为看成同等重要,即将对象视作一个封装了数据与操作的统一的软件组件。对象的概念符合业务或领域的客观实际,反映了实际存在的事物,也符合人们分析业务本质的习惯。
面向对象技术自20世纪90年代提出以来得到快速发展,并被应用在各种各样的软件开发中。面向对象技术将数据和数据上的操作封装在一起,对外封闭实现信息隐藏的目的。使用这个对象的用户只需要知道其暴露的方法,通过这些方法来完成各种各样的任务,完全不需要知道对象内部的细节,保证相对独立性。
面向对象方法的优势主要体现在维护阶段。相对于结构化方法,无论对象的内部细节如何变化,只要对象提供的接口(方法定义)保持不变,则整个软件产品的其他部分就不会受到影响,不需要了解对象内部的变化。因此,面向对象开发方法使维护更快、更容易,同时产生回归的机会也大大降低了。面向对象开发方法学使开发变得相对容易。大多数情况下,一个对象对应物理世界的一个事物。软件产品中的对象和现实世界的同等对应物之间的密切对应关系,促进了更优化的软件开发。对象是独立的实体,因此面向对象促进了复用,降低了开发维护的时间和费用。
目前,传统软件开发方法学是软件工程学发展的基础。广大软件工程师对这种范型比较熟悉,而且在开发某些类型的软件时也比较有效,因此,在相当长一段时期内,结构化开发方法学还会有生命力。此外,如果没有完全理解传统的结构化开发方法学,也就不能深入理解其与面向对象开发方法学的差别,以及面向对象开发方法学为何优于传统的结构化开发方法学。
在使用结构化开发方法学时,分析阶段和设计阶段过渡太快,而面向对象开发方法学是一种迭代地从一个阶段向另一个阶段过渡,比结构化开发方法学平滑得多,从而降低了开发过程中返工的概率。

1.5.3 重型软件工程与轻型软件工程

按照规则的多少和约束的强弱,可以大致地把软件开发方法学分为重型软件工程方法学和轻型软件工程方法学两种。重型软件工程方法学比较正规和严谨,在采用重型软件工程方法学的项目中,开发人员具有较强的可替换性,因为方法学本身强制要求开发者把他所创造的所有的制品(artifact)都记录在案(按照该方法学规定的格式),所以参与项目的新人能借助这些文档很快上手(前提是新人也熟悉这种方法学规定的格式),从而开发人员的变化(如跳槽)对项目的冲击也相对较小。
在传统的观念中,我们认为重型方法要比轻型方法安全许多。因为我们之所以想出重型方法,就是由于在中大型的项目中,项目经理往往远离代码,无法有效地了解目前的工程进度、质量、成本等因素。为了克服未知的恐惧感,项目经理制定了大量的中间管理方法,希望能够控制整个项目,最典型的莫过于要求开发人员频繁地递交各种表示项目目前状态的报告。
项目经理可能会比较偏爱这样的方法学,因为这样一来他们掌控的因素比较多,风险就比较小。当然,一些开发人员则不会喜欢这样的方法学,因为在采用重型软件工程方法学的项目中,他们难以感觉到自己的重要性,无法体现自己的价值。
重型软件工程方法学的一个弊端在于,大家都在防止错误,都在惧怕错误,要达到充分的沟通也是很难的。最终,连对个人的评价也变成以避免错误的多少作为考评的依据,而不是成就。
轻型软件工程方法学则具有相反的特质。在采用轻型软件工程方法学的项目中,记录在案的制品不多,交付的就是代码以及可以运行的产品,还有测试用例。大多数交流是口头的、非正式的,开发效率高,但也只存在项目成员的脑海中。如果成员从项目中离开,那么他脑海中的这些东西也随之带走。因为开发人员往往都希望自己具有不可替代的重要性,而且一般都觉得写程序比写文档有意义,因为不必把时间浪费于编写正规文档,所以开发人员一般都比较偏爱轻型软件工程方法学。
一般而言,大型项目采用重型软件工程方法学好一点,因为项目人手多、周期长,即便所有员工都很喜欢这个项目,但这么多人在这么长时间内一个都不跳槽或一个都不生病也是不太可能的;而小型项目往往采用轻型软件工程方法学好一点。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: