软件维护过程中,将会引起维护副作用

软件维护戚芹过程中，将会引起维护副作用，相关知识介绍如下：

一、软件维护介绍：

1、软件维护是一个软件工程名词，是指在软件产品发布后，因修正错误、提升性能或其他属性而进行的软件修改。

2、软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改，修改时应充分利用源程序。修改后要填写《程序修改登记表》，并在《程序变更通知书》上写明新旧程序的不同之处。

3、完善性维护是为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。这些功能对完善系统功能是非常必要的。

二、维护副作用：

1、所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况，有三种副作用，修改斗橘代码的副作用，修改数据的副作用和文档的副作用。

2、在使用程序设计语言修改源代码时，都可能引入错误。例如删除或修改一个子程序，高销毕删除或修改一个标号， 删除或修改一个标识符，改变程序代码的时序关系，改变占用存储的大小，改变逻辑运算符，修改文件的打开或关闭，改进程序的执行效率，以及把设计上的改变翻译成代码的改变，为边界条件的逻辑测试做出改变时，都容易引入错误。

C 语言中，术语搏轿副作用（side effect）是指对数据对象或者文件的修改。例如，以下语句var = 99

的副作用是把 var 的值修改成 99。对表达式求值也可能产生副作用，例如：

se = 100

对这个表达式求值所产生的副作用就是 se 的值被修改成 100。

序列点（sequence point）是指程序运行中的一个特殊的时间点，在该点之前的所有副作用已经结束，并且后续的副作用还没发生。

C 语句结束标志——分号（）是序列点。也就是说，C 语句中由赋租洞值、自增或者自减等引起的副作用在分号之前必须结弊银枯束。我们以后会说到一些包含序列点的运算符。任何完整表达式（full expression）运算结束的那个时间点也是序列点。所谓完整表达式，就是说这个表达式不是子表达式。而所谓的子表达式，则是指表达式中的表达式。例如：

f = ++e % 3

这整个表达式就是一个完整表达式。这个表达式中的 ++e、3 和 ++e % 3 都是它的子表达式。

有了序列点的概念，我们下面来分析一下一个很常见的错误：

int x = 1, y

y = x++ + x++

这里 y = x++ + x++ 是完整表达式，而 x++ 是它的子表达式。这个完整表达式运算结束的那一点是一个序列点，int x = 1, y中的 也是一个序列点。也就是说，x++ + x++ 位于两个序列点之间。标准规定，在两个序列点之间，一个对象所保存的值最多只能被修改一次。但是我们清楚可以看到，上面这个例子中，x 的值在两个序列点之间被修改了两次。这显然是错误的！这段代码在不同的编译器上编译可能会导致 y 的值有所不同。比较常见的结果是 y 的值最后被修改为 2 或者 3。在此，我不打算就这个问题作更深入的分析，各位只要记住这是错误的，别这么用就可以了。有兴趣的话，可以看看以下列出的相关资料。

C 语言标准对副作用和序列点的定义如下：

Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression may produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.

翻译如下：

访问易变对象，修改对象或文件，或者调用包含这些 *** 作的函数都是副作用，它们都会改变执行环境的状态。计算表达式也会引起副作用。执行序列中某些特定的点被称为序列点。在序列点上，该点之前所有运算的副作用都应该结束，并且后继运算的副作用还没发生。

软件维护的副作用主要是在修该原有错误时会引入新备虚羡的错误。

预防的措施主要是程序模块化，信誉悉息隐蔽，高内聚、低耦合等。面向对象分析设计中使用封装、抽象、继承仿拍等办法。具体的包括：

1、按模块把修改分组；

2、自顶向下地分析所修改模块的顺序；自底向上修改有关模块。

3、每次修改一个模块；牵涉到全局性的基础模块改动必须仔细分析。

4、对于每个修改了的模块，在安排修改下一个模块之前，要确定这个修改的副作用，主要是关注修改后对调用这个模块的其他模块的功能影响。

---