软件工程 系统的总结

1.1软件工程概述

软件：

软件是能够完成预定功能和性能的可执行的计算机程序和使程序正常执行所需的数据，加上描述程序的操作和使用的文档

软件危机

定义：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

典型表现：对软件开发成本和进度的估计常常很不正确

用户对“已完成的”软件系统不满意的现象经常发生

软件产品的质量往往靠不住

软件常常是不可维护的

软件通常没有适当的文档资料

软件成本在计算机系统总成本中所占的比例逐年上升

软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势主要原因：

软件自身的特点：

软件是逻辑的，而不是物理的产品；

软件是由开发或工程化而形成的，没有明显的制造过程；

软件在运行和使用期间，不存在硬件那样的磨损和老化问题，但它存在退化问题，开发人员必须维护软件;

大多数软件是自定的，而不是通过已有构件组装而成的;

软件成本相当昂贵;

软件本身是复杂的;

相当多的软件工作涉及到社会因素。

软件开发与维护的方法与认识

忽视软件需求分析的重要

认为软件开发就是写程序

轻视软件维护

消除软件危机的途径：

消除错误的概念和做法

推广使用实践中总结出来的成功技术和方法

开发和使用更好的软件工具

有必要的组织管理措施

软件开发策略：软件复用、分而治之、折中—优化

1.2 软件工程

定义：

软件工程是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法制作软件的工程。

基本原理：

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

采用现代程序设设计技术

实行严格的产品控制

坚持进行阶段评审

结果应能清楚地审查

开发小组的人员应该少而精 承认不断改进软件工程实践的必要性 方法学：

软件生命周期所使用的技术方法的合集

三个要素：

过程、方法和工具

1.3 软件生命周期

问题定义；可行性分析；需求分析；总体设计；详细设计；编码和单元测试；综合测试；软件维护

软件生命周期：软件定义：问题定义、可行性研究、需求分析

软件开发：总体设计、详细设计、编码和单元测试、综合测试

运行维护：改正错误、适应新环境、满足新需求

1.4 软件过程模型

瀑布模型；快速原型模型；增量模型；螺旋模型；喷泉模型；RUP （Rational Unified Process ） 敏捷过程与极限编程：

XP （Extreme Programming ）：极限编程

1.6CASE

Computer Aided Software Engineering 计算机辅助软件工程

2.1 可行性研究的任务

目的：用最小的代价，在尽可能短的时间内确定问题是否能够解决

任务：

技术可行性：使用现有的技术能实现这个系统

经济可行性：系统的经济效益能否超过开发成本

操作可行性：系统的操作方式在这个用户组织内是否行得通

根本任务：

对以后的行动方针提出建议

流程：

复查系统规模和目标

研究目前正在使用的系统 导出新系统的高层逻辑模型 进一步定义问题 导出和评价供选择的解法 推荐行动方针 草拟开发计划 书写文档提交审查

2.4 数据流图

DFD（Data Flow Diagram）

2.5 数据字典

是关于数据的信息集合，是对数据流图中包含的所有元素定义的集合

内容：

数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求

结构化分析的准则：

必须理解并描述问题的信息域，根据这条准则应该建立数据模型。

必须定义软件应完成的功能，这条准则要求建立功能模型。

必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。

必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。

需求规格说明（SRS software requirement specification）

3.1 需求分析的任务

确定对系统的综合要求

分析系统的数据要求

导出系统的逻辑模型

修正系统开发计划

验证软件需求的正确性：一致性、完整性、现实性、有效性。

3.2 与用户沟通获取需求的方法

需求分析困难的原因：

客户说不清楚需求

需求自身经常变动

分析人员或客户理解有误

解决方法：

访谈；面向数据流自顶向下求精；简易的应用规格说明技术；快速建立软件原型3.3 分析及建模与规格说明

数据模型--实体联系图

逻辑模型--数据流图

行为模型--状态转化图

3.4 实体-联系图

E-R图（Entity-Relationship diagram）

包含：实体关系属性

3.5 数据规范化

范式（NF normal forms）定义消除数据冗余的程度。1NF冗余最大5NF冗余最小

4

4.1 软件设计过程

设想供选择的方案；选取合理的方案；推荐最佳方案；功能分解；设计软件结构；设计数据库；制定测试计划；书写文档；审查和复审

4.2 软件体系结构

是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组合连接起来。

客户机/ 服务器（Client /Server）浏览器/服务器（Browser/Server）

4.3 设计原理

模块化：

把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，完成满足用户的需求。

易于阅读和理解；易于测试和调试；提高软件的可修改性；有助于软件开发工程组织与管理

功能独立性：是抽象、模块化和信息隐藏的直接产物，度量用模块间的耦合和模块的内聚。

内聚：低内聚：偶然内聚、逻辑、时间

过程、通信、信息、功能、

耦合：非直接、数据、特征、控制、公共、内容

尽量使用数据耦合，少用控制耦合和特征耦合。限制公共环境耦合的范围，完全不用内容耦合。

4.4 启发规则

模块功能的完善化；

改进软件结构提高模块独立性；

模块规模应该适中；

深度、宽度、扇出和扇入都应适当；

模块的作用域应该在控制域之内；

力争降低模块接口的复杂程度；

设计单入口单出口的模块；

模块功能应该可以预测

4.5 描绘软件结构的图形工具

HIPO

4.6 面向数据流的设计方法

数据流=变换型数据流+事务性数据流

设计步骤：

1）复审并精化数据流图；

2）确定数据处理流图的类型；

3）确定变换中心或事务中心；

4）将数据流图映射成软件模块结构图，设计出该数据流图对应的第一层模块结构；

5）基于数据流图逐步分解，设计下层模块；

6）运用模块设计和优化准则优化软件结构；

7）描述模块的接口。

5

基本任务：

?为每个模块进行详细的算法设计

?为模块内的数据结构进行设计

?对数据库进行物理设计

?其他设计，如：代码设计、输入／输出格式设计、人机对话设计

?编写详细设计说明书

?评审

5.2 人机界面

设计问题：系统响应时间；用户帮助设施；出错信息处理；命令交互

交互界面的基本类型：菜单界面；对话；其他（图像、窗口）

界面显示的基本元素：数据、字符、图形、音视频

5.3 过程设计的工具

图形工具：程序流程图（FC）；盒图（NS）；问题分析图（PAD）

表格工具：判定表；判定树

语言工具：过程设计语言（PDL）

过程设计语言（process Design Language , PDL）

5.5 程序复杂度的定量度量

McCabe方法：

原理：根据程序控制流的复杂程度定量度量程序的复杂程度，这样度量出的结果称为程序的环形复杂度。

计算：复杂度=V(G)=P+1P是流图中判定结点的数目

=V(G)=E-N+2E是流图中边的条数，N是结点数

流图中的区域数等于环形复杂度

Halstead方法：

原理：根据程序中运算符和操作数的总数来度量程序的复杂程度，令N1为程序中运算符出现的总次数，N2为操作数出现的总次数，程序长度N定义为：N=N1+N2 预测程序长度：详细设计完成之后，可以知道程序中使用的不同运算符(包括关键字)的个数n1，以及不同操作数(变量和常数)的个数n2，H = n1 log2 n1 + n2 log2 n2 预测程序错误数：E =N log2 (n1+n2)/3000

6.1 编码

语言选择：(1) 系统用户的要求。(2) 可以使用的编译程序。(3) 可以得到的软件工具。

(4) 工程规模。(5) 程序员的知识。(6) 软件可移植性要求。(7) 软件的应用领域。

6.2软件测试基础

软件测试的目的：

(1) 测试是为了发现程序中的错误而执行程序的过程；

(2) 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

(3) 成功的测试是发现了至今为止尚未发现的错误的测试。

7.1 软件维护的常识

软件维护：是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程。

分类：改正性维护；适应性维护；完善性维护；预防性维护

特点：结构化维护与非结构化维护差别巨大；维护的代价高昂；维护的问题很多

7.2 决定软件可维护性的因素

可理解性；可测试性；可修改性；可移植性；可重用性

提高可维护性的方法：确定质量管理目标和优先级；规范化程序设计风格；选择可维护性高的程序设计语言；改进程序文档；保证软件质量审查方法

7.3

逆向工程（reverse engineering）：指在软件生存周期中，将软件的某种形式描述转换成更抽象形式的活动

重构（restructuring）：指在同一抽象级别上转换系统的描述形式。如把C++ 程序转换成Java程序

设计恢复（design recovery）：指借助工具从已有程序中抽象出有关数据结构设计、总体结构设计和过程设计的信息。

再工程（reengineering）：指在逆向工程所获信息的基础上修改或重构已有的系统，产生系统的一个新版本。包含：业务过程再工程（BPR——Business Process Re-engineering），软件再工程

再工程的主要目的：为遗留系统转化为可演化系统提供一条现实可行的途径

过程：库存目录分析；文档重构；逆向工程；代码重构；数据重构；正向工程

8.1 面向对象方法学概述

OO（Object Oriented）面向对象= 对象+ 类+ 继承+ 消息通信

结构化范型软件生命周期

（1）陈述需求阶段

（2）规格说明（分析）阶段

（3）设计阶段

（4）实现阶段

（5）维护阶段

面向对象范型软件生命周期

（1）陈述需求阶段

（2）面向对象分析阶段

（3）面向对象设计阶段

（4）面向对象实现阶段

（5）维护阶段

8.2 面向对象建模

目的：设计结构与系统行为融会贯通

可视化和控制系统的体系结构

化解复杂性的问题

有效地管理开发风险

开发出高品质的软件

8.3 面向对象建模

模型：数据模型（实体联系图）逻辑模型（数据流图）行为模型（状态转化图）

面向对象建模的三种模型：对象模型动态模型功能模型

8.4 对象模型

类与类之间通常有4种关系：

?关联

?聚集

?泛化（继承）

?依赖和细化

8.5 动态模型

动态模型表示瞬时的、行为化的系统的“控制”性质，它规定了对象模型中的对象的合法变化序列。

状态事件行为

8.6 功能模型（用例）

行为者系统用例

8.7 三种模型之间的关系

1）针对每个类建立的动态模型，描述了实例的生命周期或运行周期。

2）状态转换驱使行为发生，这些行为在数据流图中被映射成处理，在用例图中被映射成用例，它们同时与类图中的服务相对应。

3）功能模型中的处理（或用例）对应于对象模型中的类所提供的服务。

4）数据流图中的数据存储，以及数据的源点/终点，通常是对象模型中的对象。

5）数据流图中的数据流，往往是对象模型中对象的属性值，也可能是整个对象。

6）用例图中的行为者，可能是对象模型中的对象。

7）功能模型中的处理（或用例）可能产生动态模型中的事件。

8）对象模型描述了数据流图中的数据流、数据存储以及数据源点/终点的结构。

10

10.1 面向对象设计的准则

模块化；抽象；信息隐藏；弱耦合；强内聚；可重用

10.3软件重用

重用：也叫再用或复用，是指同一事物不作修改或稍加改动就多次重复使用。

设计结果重用：有助于把一个应用系统移植到完全不同的软硬件平台上。

源代码重用：源代码剪切；源代码包含；继承

分析结果重用：适用于用户需求未改变，但系统体系结构发生了根本变化的场合。

类构件：

利用面向对象技术，可以更方便更有效地实现软件重用。面向对象技术中的“类”，是比较理想的可重用软构件，不妨称之为类构件。

特点：

模块独立性强。具有单一、完整的功能，且经过反复测试被确认是正确的。

具有高度可塑性。可重用的软构件必须具有高度可裁剪性，也就是说，必须提供为适应特定需求而扩充或修改已有构件的机制，而且所提供的机制必须使用起来

非常简单方便。

接口清晰、简明、可靠。软构件应该提供清晰、简明、可靠的对外接口，而且还应该有详尽的文档说明，以方便用户使用。

重用方式：

实例重构；继承重构；多态重构