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

“学习不仅是一种必要，而且是一种愉快的活动。” - 尼尔·阿姆斯特朗

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

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

历史方面

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

经济方面

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

维护方面

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

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

现代软件维护观点

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

交付后维护的重要性

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

需求、分析和设计方面

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

团队开发方面

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

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

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

面向对象范型

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

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

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

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. 螺旋模型将每个阶段看作相对独立的，然而软件开发是迭代与增量的过程。

总结

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


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