《面向对象软件工程》笔记——1-2章-CSDN博客

第一章 面向对象软件工程的范畴

软件工程是一门以生产出没有错误、按时并且在预算内交付的满足客户需求的软件为目的的学科。这个定义非常广泛所以能使用到从数学、计算机科学到管理学、心理学等诸多专业的学科。开发软件的思想不同进行开发的整个流程也不一样当前世界上的主流思想是面向对象思想因此书中讲的也就是面向对象软件工程。本章先从历史经济维护需求、分析、设计团队开发这些方面讲述了软件工程的作用。

历史方面

在历史方面由于要研发出符合预算符合时间限制少有错误的软件很难因此许多开发组织的大部分软件都以失败告终并且软件开发是与传统工程不同的全新领域因此许多经验丰富的软件工程师联合开发了一套用于开发软件的方法论即软件工程。

经济方面

在经济方面软件工程会是工程师有效做出正确决策来节约预算。通过软件工程工程师能预测开发的那一部分比较重要需要多花力气哪一部分不太重要不值得浪费时间和金钱。

维护方面

维护是软件生命周期的一个步骤。为了描述一个软件的生命周期出现了多种生命周期模型。瀑布生命周期模型是一种比较旧的模型现在使用的生命周期模型很多都是它的变种。瀑布模型包括六个步骤

• 需求阶段探究并细化概念提取客户需求。
• 分析阶段分析客户需求将需求记录在规格说明文档中。分析结束时给出详细描述软件开发过程的计划称作软件项目管理计划。
• 设计阶段分成两个步骤首先进行体系结构设计将整体产品分解为若干模块然后进行详细设计设计每个模块的实现逻辑。结束时给出说明整个产品实现逻辑的设计文档。
• 实现阶段对每个组件进行单独的编码和单元测试。每完成一个组件将其与先前做好的组件合并成一个整体进行集成测试。最后客户对整个产品进行验收测试。
• 交付后维护包括纠错性维护软件修复和增强性维护软件更新。纠错性维护纠正软件的错误不修改规格说明文档增强性维护添加新功能或更改不合适的功能修改规格说明文档。增强性维护包括两类完善维护为了提高产品性能所做的维护适应性维护为了让程序适应环境的变化所做的维护。环境的变化如新的硬件/操作系统或政府的新规定。
• 退役产品推出服务。产品对客户没有任何用处时产品退役。

现代软件维护观点

现代软件开发中认为在软件的整个生命周期中即从需求到退役只要对软件已完成的部分有因为错误或需求变化而进行的改动都称作维护。上问的交付后维护是在软件交付给客户后进行的维护是维护的一个子集。

交付后维护的重要性

为了纠正软件中的错误并且让软件适应外界的不断变化开发组织会不断对软件进行交付后维护。事实上交付后维护会花费掉开发组织大部分的开发预算。

需求、分析和设计方面

由于在软件开发的过程中前面阶段的错误显然会影响后面阶段的成果物所以一个错误越晚发现越会耗费更多的时间和预算去解决且这种花费是指数级增长的。比如说如果在实现阶段才发现分析出现了错误那么从分析设计到部分模块的实现都要重新进行。
大部分错误出在需求、分析和设计阶段因此有完善的错误检测技术来检测这些阶段的错误是很重要的软件工程也包括如何进行错误检测。

团队开发方面

如果一个团队的成员之间不能互相协调组织良好那么将花费大量的无用功或重复劳动。软件工程包括确保对团队进行良好管理和组织的技术。

没有计划测试文档阶段的原因

虽然计划、测试和文档是开发过程中很重要的部分但是这三部分的工作贯穿整个生命周期所以无法划分出单独的阶段。

面向对象范型

传统的面向过程范型有两个缺点

• 无法应付规模较大的软件产品。由于是一整个整体进行开发随着代码规模增大代码之间的联系以极快的速度增长相应的开发难度也大大提升。
• 无法满足对交付后维护的期望。大规模的面向过程泛型软件产品是很复杂的有时常常会牵一发而动全身这给交付后维护带来了很大的难度。

面向对象范型由于将属性和操作包装呈一个对象克服了这两个缺点。由于现实世界的几乎所有物质都有属性和操作这两种概念组成因此把这两个概念包装在一起的对象就是这个物质在代码世界中的映射。面向对象范型的软件产品克服了上面的缺点。面向对象范型通过让这些对象相互之间进行消息的发送对象收到消息后进行具体的操作来完成任务由于如何执行操作是对象的职责因此面向对象设计也被称作职责驱动设计。通过将整个产品划分为一个个小型的独立的单元对象之间的联系清晰明了所以整个产品的逻辑也是清晰的开发和维护的难度也就大大降低了。
也是因为这种设计面向对象范型也有许多优点

1. 支持信息隐藏。由于每个对象的操作只局限在对象内部因此没有必要让对象外知道除了职责以外的信息。这种隐藏机制可以防止对象外的代码滥用对象的信息。
2. 促进重用。由于对象的强独立性可以将部分对象单独提出来重复使用在以后的软件开发中实现代码的重用。

然而面向对象范型也有缺点并且以后也会被更好的方法替代。

术语

客户雇人开发软件产品的实体
开发者开发产品的实体。注意用户和开发者可以属于同一组织。
用户使用所开发软件的实体。客户和用户可以是同一个实体。
定制软件为特定人编写的定制软件。
COTS软件商用现货软件以低廉的价格出售给大量购买者使用的软件。
开源软件消费者购买后可以获得源代码的软件。这种软件支持消费者进行二次修改和维护。
软件包括程序和文档的一种产品。
过错差错故障程序员的过错会导致软件的差错差错会导致软件进行不正确的行为即故障。

第二章 软件生命周期模型

在理想状态下软件产品从需求分析设计实现到维护退役走完一整个流程。但实际上在开发过程中由于错误或需求变化等原因需要进行维护也就是回到之前阶段进行重新修改。因此在软件开发时的瀑布模型如下不包括交付后维护和退役

其中红色代表开发流程蓝色代表维护流程。注意维护流程可以一级级连续向上。

迭代与增量

一个软件产品在开发时都关注于五个工作流需求工作流分析工作流设计工作流实现工作流测试工作流。
当软件产品完成了某一阶段的开发或者修改称该产品完成了一次迭代在实际开发过程中一般使用逐步求精的方法先选出最重要的一部分产品进行开发然后再选出次重要的进行开发这种一部分一部分开发的过程称为增量。
迭代与增量是交替使用的。当一个产品在开发的过程中它会经历多次增量每次增量都会对至少一个工作流进行修改有时还会对之前已完成的部分进行修改这就产生了迭代。每次增量的工作都需要进行多次迭代后才能完成。每次迭代都会进行测试在某种程度上对产品的正确性做出保证。
每次迭代-增量就是不断地重复使用瀑布模型。

迭代-增量模型的优点

• 多次验证软件产品的正确性。由于每次迭代后都会进行测试因此可以反复验证已完成部分的正确性。
• 确定底层结构的鲁棒性。由于是分块开发并且每次要修改之前完成的代码所以必须要求底层结构的鲁棒性可扩展性要好。
• 可以尽早降低风险。对于部分重要模块的开发可以让开发组织在花费较少预算的情况下对于这个项目能否按时按预算完成有一定的预见性从而决定是否要继续这个项目。
• 可以随时获得软件的工作版本。由于要求所开发的产品是能够被测试的因此可以随时获得能运行的软件版本。这样的话开发组织可以先将一部分的产品给予客户进行测试获得对于产品修改的意见同时对于部分产品的预先使用也可以让客户尽早开始熟悉新的软件降低学习成本。

其他生命周期模型

边写边改生命周期模型

顾名思义先实现软件的一个初始版本然后直接交给客户客户有什么不满意的拿回来修改如此反复直到软件退役。这种模型的缺点很明显由于没有任何文档没有经过详细的分析和设计可能会在交付后维护时产生大量错误由此产生高昂的成本没有文档也为维护造成了极大的困难。

瀑布生命周期模型

与上文不同的是完成的瀑布生命周期模型包括交付后维护和退役阶段其中交付后维护时可以返回到任何一个开发阶段进行维护并随瀑布逐渐回到交付后维护阶段。
瀑布模型是文档驱动的即约定每个阶段都要提供文档。这可以方便开发人员在修改产品时快速地找到方法。
然而瀑布模型也有缺点

• 虽然瀑布模型是文档驱动的但是大部分情况下只有开发人员能看懂文档客户是看不懂的所以客户不能主动提出文档哪里有错漏有可能导致理解偏差。
• 在瀑布模型中只有整个产品都被实现出来客户才能拿到第一个版本。这意味着如果有理解偏差那么需要花费高昂的代价修改产品有时甚至需要重新开发产品。

为了克服缺点软件工程师可以采用UML图等通俗易懂的语言撰写文档以便让客户也能尽量看懂。

快速原型生命周期模型

快速原型生命周期模型中开发团队先处理一部分比较重要的需求并将这些需求快速实现成一个可以让客户使用的版本这个版本称作快速原型。如果这个“预告版”中实现的大多数需求客户都比较满意团队就可以编制规格说明文档。
这样处理让后续开发时不需要进行像瀑布模型那样的反馈循环因为客户对快速原型的反馈帮助修正了团队对于需求的错误理解因此可以期望规格说明文档和设计中的错误都比较少从而认为实现中的错误也会比较少。
快速原型的唯一作用是确定客户的真实需求一旦达成目标就应丢弃快速原型并保留得到的经验。因此快速原型构建的唯一目标就是快速快速构建原型快速修改需求。

开源生命周期模型

开源生命周期模型包含三个阶段

1. 某个组织或某个人开发一个初始版本并发布给想要使用这个程序的人使用程序的人同时也能看到源代码。
2. 使用这个程序的人中有一部分愿意阅读源代码并找出其中的缺陷或者按照自己的想法进行扩展这些人被称为外围小组。他们会将这些修改作为报告提交给负责管理开源项目的核心小组有时只是发现了bug但没有找到代码中的缺陷也可以作为报告提交。如果是缺陷报告核心小组成员会选择将修复这些缺陷的任务自己完成或交给外围小组成员但最后所有对代码的修改都由核心小组成员安装到软件中。

开源软件的更新速度通常很快因为他们秉承“尽早发布经常发布”的原则。
可以发现开源生命周期模型中没有规格说明和设计文档但因为开源领域中有些成员出色的能力开源软件有些也有很高的实用性但所有开源产品最终的下场都是退役。

敏捷过程

极限编程是一种新的软件开发方法。下面是极限编程的步骤

1. 首先开发团队确定客户想要产品支持哪些特征对于每个特征开发团队告知客户实现该特征耗费的时间和成本。
2. 客户通过成本效益分析选定产品需要包含的特征。团队将这些特征分解为更小的任务。
3. 团队成员为每个任务编写测试用例这就是所谓的测试驱动开发。接下来进行结对编程来编写代码即两名程序员在同一台计算机上协同运作每15到20分钟换人编写代码此时不便携代码的人负责仔细检查代码。编写完成并通过测试用例后将任务集成到产品中。理想情况下完成每一任务的时间不超过几个小时。通常由多个小组同时结对完成任务每天将小组打乱以让不同的成员互相学习。

极限编程XP有许多新特性

• XP团队的计算机位于某个被隔断的大房间的中央。
• 客户代表一直与XP团队一起工作。
• 没有程序员能一直工作两个星期。
• 没有规格说明文档但所有XP团队成员都负责需求分析设计编码和测试。
• 没有总体设计在产品开发过程中可以一直修改设计这个过程称为重构只要测试用例尚未运行就可以重组代码直到XP团队认为设计简洁直观并能正确运行所有测试用例为止。

XP编程的原则是YAGNI你不会需要它和DTSTTCPW做可能起作用的最简单的事情即让特征数目最小化绝不超出客户实际所需。
XP编程是敏捷编程所包含的众多新型范型中的一种。敏捷过程极少强调分析和设计并且要求对需求修改做出快速响应因此要求更好的进行与客户之间的协作。
敏捷过程的特征之一是经常交付工作软件理想情况下每2-3周交付一次。因此要采用时间定量法。在敏捷编程中常常给某个任务定出三周的时间三周后进行新版本的迭代。一方面客户知道3周就可以让产品增加新功能另一方面团队成员直到他们只有3周来完成任务。在这3周中客户不能再提出对该次迭代所进行的任务的修改也不能再干扰团队。但是如果实在无法完成任务则可能要减小工作量。总之敏捷过程要求确定的时间而非确定的工作量。
敏捷过程的另一个特征就是在每天固定的时间开一个短会。在短会期间团队成员围着桌子站着不就座有助于在15分钟内结束会议。每个团队成员一次回答五个问题

1. 从昨天会议到现在我做了什么
2. 今天我正在做什么
3. 要顺利完成任务存在什么问题
4. 我们忽视了什么
5. 我学到了什么可以同团队分享什么

站立会议是为了发现而非解决问题后续会议负责解决问题这个会议最好安排在站立会议之后立即举行。
总之敏捷过程具有两个原则交流尽可能快的完成用户需求。
敏捷过程适用于进行小规模的代码开发但中型和大型的产品就需要更规范的过程。虽然如此但如果敏捷过程减少了交付后维护的成本则它们就会被广泛采用然而交付后如果要进行增强性维护性质的重构则成本就会很高。
尽管受人诟病然而其中的某些特征也具有可行性并可能被未来的主流软件工程实践所采纳。

同步稳定生命周期模型

微软公司的大部分COTS软件包都使用这类模型来开发。
首先与软件包的众多潜在客户会谈确定基本需求。抽取出要完成的特征列表并分为3-4个模块以重要程度来划分。将每个模块分给许多小型团队并行开发每天工作结束时所有团队相互同步即将已完成的组件集成对得到的产品进行测试。每个模块完成时进行稳定操作将检测到的所有错误都修正然后冻结模块即不再修改规格说明文档。
每天同步确保每个组件都能集成在一起可以让开发人员尽早了解产品的运作还可以在过程中修改需求甚至当规格说明文档不完整时也可以采用这种生命周期模型。

螺旋生命周期模型

螺旋生命周期模型是一种风险驱动模型即按照当前阶段评估的风险来决定下一阶段的开发是否进行。
一开始开发一个概念验证模型非快速原型虽然这个原型也是展示项目中比较重要的一部分但这一部分是开发团队认为最有可能会引起风险的部分即可能会引起不满足约束条件的部分。这个原型可以帮助开发人员估算整个项目的部分风险以决定是否能降低风险以继续进行项目或直接终止项目。
接下来在每个开发阶段前先进行风险分析。如果存在某些主要的风险无法被降低到可接受的程度则立即停止项目。
但是原型法对某些方面的风险评估没有用处。比如关键成员辞职。另外开发一个小的原型不能验证开发团队开发大型产品的能力因为开发不同规模的产品需要的能力水平不同。
下图是完整的螺旋模型

纵轴表示所花费的累积成本旋转角表示螺旋进展项目的实际开发流程按照螺旋的方向进行。每个象限代表不同的含义。一次开发从左上象限开始左上象限进行确定目标、选择、约束右上象限进行风险分析并开发各个阶段的原型右下象限进行各个阶段的开发左下象限进行下一阶段的计划。
螺旋模型的优点在于强调目标选择和条件约束支持已有软件的重用将软件质量作为特定目标可以保证测试是适量的不会浪费预算也不会测试不足由于在模型中将交付后维护设为一个平等的阶段可以保证软件人员不会轻视交付后维护。
螺旋模型的缺点在于

1. 螺旋模型专门用于组织内部开发大型软件。由于可能随时终止项目如果与组织外的客户签订契约那么螺旋模型就没有了实用性因为最后必须交付产品。
2. 螺旋模型仅适用于大型软件的开发因为对于小型项目来说风险分析的成本过高。
3. 螺旋模型中如果开发团队不善于进行风险分析那么有可能低估项目的风险以让螺旋模型变得全无用处这限制了它的可用性。
4. 螺旋模型将每个阶段看作相对独立的然而软件开发是迭代与增量的过程。

总结

各个生命周期模型的优缺点如下


我是霜_哀在算法之路上努力前行的一位萌新感谢你的阅读如果觉得好的话可以关注一下我会在将来带来更多更全面的知识讲解