软件工程与UML笔记

第一章面向对象软件工程概论

要求学习的内容：

软件危机
软件工程的由来
软件工程的定义
软件工程的范畴
软件工程实践的目标
软件开发包含的活动
软件维护的成本
修复bug的代价

一.软件危机

软件定义：软件是程序以及开发、使用和维护程序所需要的所有文档。

软件危机定义：软件开发和维护过程中遇到的一系列严重问题

表现：

对软件开发成本和进度的估计不准确；
软件产品质量很不可靠；
可维护性差，软件的文档资料不完整和不合格；
软件成本逐年上升；
软件开发生产率不高，不能满足客观需要。

软件危机原因：

（1）人们对于软件概念与范畴的理解。

早期软件工程师崇尚个人英雄主义，整个软件开发通常处于一种无序的状态。他们大多认为编写程序就是软件开发的全部。这种观念会导致随着软件规模的增大，程序员对于文档的忽略与不重视，使得软件开发产品的不健全与维护困难。

（2）软件的规模日益增长、设计日益复杂。
Visual Studio/Office等（M->G）

（3）软件开发组织发生变化。

在上述因素发生变化的同时，软件开发组织也在发生着变化。早期开发一款小型软件，可能1-2个开发人员就可以完成。然而随着软件规模的飞速增长，软件开发组织也在同比例增长，由单打独斗的状态改变为一个团队若干开发人员共同研发一款产品。人员由一个变成团队协同开发，这种组织形式的转变，必然给软件开发的协同组织带来挑战。同时造成潜在的进度、成本和质量的问题。

二.软件工程

软件工程的定义：软件工程是指导计算机软件开发和维护的工程科学。采用工程的概念、原理、技术和方法来开发和维护软件（1968）。

软件工程核心三要素：质量、时间、预算。

软件工程的目标：在给定的成本、按期交付高质量的软件产品。

软件工程范畴：软件工程是一门学科，目的是生产出能如期交付、在预算范围内、满足用户需求没有错误的软件产品。

软件质量控制质量要素影响因子：

1.关于软件的运行特征

可靠性:在给定时间间隔内,软件成功运行的概率
有效性:软件的时空效率（确认测试：验证软件的功能和其他特性是否与用户的要求一致）
可用性:使用软件的难易程度
可理解性:结构清晰,直接反映问题需求,易理解
可维护性:软件交付使用后进行修改的难易程度

2.关于软件承受修改的能力

灵活性:改变软件的功能或行为所需的工作量

3.关于软件对新环境的适应能力

可移植性:软件从一个环境移到另一个的难易程度
可重用性:软部件可以在多种场合应用的程度
可互操作性:多个软件交换信息并相互使用已交换信息的能力

插入：

著名软件工程专家 B.W.Boehm软件工程实践原则（1983年发表）

1．用分阶段的生命周期计划严格管理。

（1）一定要有项目计划；
（2）项目要划分生命周期阶段，每个阶段都要有计划；
（3）计划要分层或分阶段逐步细化；
（4）要使用项目计划管理项目，不能弃之不用。

2．坚持进行阶段评审。

（1）尽早发现错误。大部分缺陷是编码之前注入的，缺陷越早修复成本越低。
（2）尽早发现错误的措施：

3．实行严格的产品控制。

执行配置管理，确保工作产品之间的一致性。

4．采用现代程序设计技术。

采用现代化的开发方法、开发实践提升软件的效率与质量。

5．结果应能清楚地审查。

对于项目的阶段产出、各个小组之间的承诺、每个人的产出与承诺要明确、要可验证。

6．开发小组人员应少而精。

（1）人与人之间的效率差别达10倍甚至25倍以上，因此要使用精英团队。
（2）采用多种方式提升沟通的质量与效率：

不要通过加人的方式解决进度问题
项目的初期不要太多的人员
为高性能提供高的回报
淘汰低性能者
使用自动化的辅助工具
承认不断改进软件工程实践的必要性。
识别、分析技术与过程的改进，建立持续改进的机制。

三.软件生命周期方法学：从时间角度对软件开发和维护的复杂问题进行分解。

软件生命周期描述：将整个生命周期模型划分为一系列较小的步骤，称为阶段。与此对照，对某个具体的软件产品所做的一系列实际步骤，从概念开发到最终退役，称为该产品的生命周期。

软件生命周期阶段：需求、分析、设计、实现、交付后维护、退役

软件维护费用一般是软件开发费用的3倍。

发现和修复软件的费用：

软件设计瀑布模型：模块设计、实现、编译、单元测试、集成测试、系统测试。
系统规模与复杂度增加
发现和修复缺陷的平均代价增长10倍。

代码复查：1-2分钟
初始测试：10-20分钟
集成测试：1小时or more
系统测试：10-40小时
产品发布给客户：代价更大。

注意：测试的目的不是为了修复缺陷，而是为了评估产品

一个产品的质量是在它被开发时决定的

当编译阶段有许多缺陷时，在测试阶段也可能会有许多缺陷！
测试阶段的缺陷多，遗留在最终程序中的缺陷也就越多！
E.W.Dijkstra不是有一句名言“程序测试只能表明错误的存在，而不能表明错误不存在

软件工程范型

不独立存在的三个阶段：
1.计划
计划阶段的合适时机？
贯穿于软件生命周期的始终，不存在独立的计划阶段
2.测试（如有你认为有人会帮你检查，你就会松懈）
3.文档（完整的、正确的、最新的）

软件生命周期各阶段：

软件过程模型（软件工程范型）

线性顺序模型（瀑布模型）
原型模型
增量模型
螺旋模型
构件组装模型
并发开发模型
形式化方法模型
第四代技术(4GT)

面向对象软件过程与传统技术对比

传统结构化方法学的缺点:

不能解决软件产品规模越变越大的问题。
交付后维护是不能满足期望的第二个方面。
生产效率低，不能快速满足用户需求
软件复用程度很低
软件仍然很难维护
面向操作、或者面向属性，但未同时面向两者。

传统范型与面向对象范型对比：

传统范型与面向对象范型主要区别：

1.理论上的软件开发

软件开发在实践中有很大程度的不同，有两个原因：
首先，软件专业人员是人，因此也会犯错；
第二，当软件在开发时客户的需求会发生变化。

2.实例研究

为了缓解印第安纳州Winburg市区交通阻塞的状况，市长说服政府建立一个公共交通系统。将建立公共交通专用通道，鼓励通勤人员“停车换乘”，即将小汽车停在郊区的停车场，然后从该处乘公共汽车上下班，每乘一次花费1美元。
每辆公共汽车将设一个自动只接受1美元的收款机，乘客进入公共汽车时将1美元塞入进钞口，自动收款机中的传感器扫描该钞票，然后机器中的软件使用一个图像识别算法，确定该乘客是否确实在进钞孔中插入了一张真正的1美元钞票。
重要的是自动收款机要非常准确，因为一旦有随便一张纸就可骗过自动收款机的新闻传出，车费收入将直线下降为零，相反如果机器经常拒绝1美元真钞，乘客将不愿意坐公共汽车。另外，收款机必须速度快，如机器花费15秒钟才确认1美元真钞——这将使好几分钟只有少数乘客能登上汽车，乘客同样不愿意坐公共汽车。因此，对收款机软件的需求包括相应时间少于1秒钟并且平均准确度至少为98%。

第1幕：实现该软件的第1版
第2幕：要求确定1美元钞票有效地平均1s响应时间没有达到。需要10s才能响应。双精度-单精度。
第3幕：程序员修改完成之后，发现平均响应时间仍超过4.5s，没有接近规定的1s。问题在于图像识别算法。Luckly,刚发明了一个快速算法，成功。
尾声：几年后，传感器陈旧了，需要一个新的模块替代它，硬件的改变意味着需要新的软件，需要重新设计与实现。

该小型实例的进化树生命周期模型

注意：虚线方框表示实现没有完成

瀑布生命模型

瀑布生命模型分析：

如果在设计期间发现了一个需求中的差错引起的差错，顺着虚线向上的箭头，软件开发人员可以回溯设计到分析并由此到需求，并在那里做必要的修改。然后，向下移到分析，改正规格说明文档以反应对需求的改动，并顺次纠正设计文档。设计工作现在可以在原来差错的地方继续进行。

瀑布生命周期模型无法显示事件的顺序。而进化树模型在每一幕的结尾都有一个基准，一套完整的软件制品。

为什么需要对一个软件产品做出那么多的改变？

第一，软件专业人员是人，因此会出错。

第二，一个软件产品是现实世界的一个模型，而现实世界是不断改变的

迭代和递增

理想情况不存在，分析阶段散布在生命周期的各个阶段。
考察一个软件制品的版本，制作第一版、第二版…接近满意的版本。从这个观点看，基本的过程是迭代的。迭代是软件工程的一个固有特性。（瀑布模型1970年首次提出，它是迭代的，但非递增，已经使用30年）
开发现实世界软件的第二个方面是乔治.米勒指出：在任何时候，人类最多只能将精力集中在7桩事情上，然而，一个典型的软件制品远不止有7桩。例如一个编码制品很可能有远远超过7个变量，一个需求文档很可能远远多于7个需求。我们人类处理信息量的限制的一个办法是逐步求精。这是一个递增的过程。递增也是软件工程的一个固有特性。（已经使用45年。）
迭代与递增相互结合使用，迭代—递增生命周期模型：
将进化树模型与瀑布模型结合起来

递增五个核心工作流：
需求工作流、分析工作流、设计工作流、实现工作流、测试工作流。

递增图示