软件工程与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年。）
迭代与递增相互结合使用，迭代—递增生命周期模型：
将进化树模型与瀑布模型结合起来

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

递增图示

图说明了每个递增内的迭代以及在几乎每个迭代期间进行的对全部五个工作流的重复，尽管每次的比例有所改变

显示Winburg小型实例研究添加在迭代-递增生命周期模型之上的进化树模型