Software Evolution by Correctness Enhancement ∗

Wided Ghardallou Nafi Diallo Ali Mili

Universityy of Tunis El Manar NJIT NJIT
Tunis, Tunisia Newark, NJ 07102-1982 USA Newark, NJ 07102-1982 USA
[email protected] [email protected] [email protected]

ABSTRACT some program more-correct with respect to some specifica-

Relative correctness is the property of a program to be tion. Given that today most software is developed, not from
more-correct than another with respect to a specification; scratch, but rather by evolving existing software products,
this property enables us to rank candidate programs in we feel that exploration of this avenue may yield substantial
a partial ordering structure whose maximal elements are returns across software engineering practice. Our purpose,
the correct programs. Whereas traditionally we think of in this paper, is not to offer polished/ validated/ scalable
program derivation as a process of successive correctness- solutions; rather, it is merely to highlight some of the op-
preserving transformations (using refinement) starting from portunities that are opened by relative correctness in the
the specification, we argue that it is possible to derive pro- field of software evolution.
grams by successive correctness-enhancing transformations All our definitions and results are formulated in terms
(using relative correctness) starting from abort. One of the of (binary) relations, hence we assume the reader familiar
attributes of our approach is that it captures in the same with elementary relational concepts, though we will intro-
mathematical model, not only the derivation of programs duce our own notations as we go. In section 2 we introduce
from scratch, but also most (if not all) of the activities that a general framework in which we model relevant concepts
arise in software evolution. Given that most software is such as specifications, program functions, program correct-
developed nowadays by evolving existing products rather ness, refinement, etc; and in section 3 we define relative cor-
than from scratch, any advance in the technology of pro- rectness for deterministic and non-deterministic programs,
gram transformation by correctness enhancement stands to then we review some relevant properties that we need in
yield significant practical benefits. the remainder of the paper. In sections 4 to 7, we use rel-
ative correctness to model several aspects of software evo-
Keywords lution, including: the derivation of a correct program from
a specification; the derivation of a (not necessarily correct
Program correctness, Relative correctness, Absolute cor-
but sufficiently) reliable program from a specification; the
rectness, software maintenance, software evolution, correc-
merger of two programs; the upgrade of a program with a
tive maintenance, adaptive maintenance, software merger,
new feature; the removal of a fault from a program (correc-
software upgrade.
tive maintenance); and the transformation of a program to
satisfy a new specification (adaptive maintenance).
1. SOFTWARE EVOLUTION
Relative correctness is the property of a program to be 2. A PROGRAMMING FRAMEWORK
more-correct than another with respect to a given specifica-
tion. Intuitively, program P ′ is more-correct than program When a program p manipulates variables x and y, say,
P with respect to specification R if and only if P ′ obeys R of type X and Y , we let S be the cartesian product X × Y ,
more often (for a larger set of inputs) than P , and violates and we refer to S as the space of p and to an element of
R less egregiously (in fewer ways) than P . We came across S as a state of p. We denote the X-component (resp. Y -
relative correctness in our attempt to define what is a fault component) of state s by x(s) (resp. y(s)), and we may
in a program, and what is fault removal [2, 13]. We have write simply x (resp. y) if no ambiguity arises; whatever
since explored the impact of relative correctness in software decoration a state has (e.g. s′ , or s′′ ) is carried over to vari-
engineering [3], in software testing [5], and in software de- able names (hence we write x′ for x(s′ ) and x′′ for x(s′′ )).
sign [4]. In this paper, we build upon our results of [4] Given a program p on space S, we let the function of p be
by showing that relative correctness can be used not only the set of pairs of states (s, s′ ) such that if execution of p
for program development from scratch, but also for various starts in state s then it terminates in state s′ ; we denote this
forms of program evolution. We argue, in fact, that virtu- function by upper case P and we may, by abuse of notation,
ally all software evolution is nothing but an effort to make refer to a program p and its function P interchangeably.
Given two relations R and R′ on set S, we say that R′
∗
DOI reference number: 10.18293/SEKE2016-095 refines R (denoted by R′ ⊒ R or R ⊑ R′ ) if and only if
RL ∩ R′ L ∩ (R ∪ R′ ) = R, where L is the universal re-
lation on S (i.e. L = S × S) and the concatenation of
two relations represents their product (RR′ = {(s, s′ )|∃s′′ :
(s, s′′ ) ∈ R ∧ (s′′ , s′ ) ∈ R′ }). Note that RL can be writ-
ten as {(s, s′ )|s ∈ dom(R)}; it represents the domain of R Definition 2. A fault in program p with respect to a
in relational form. A program p is said to be correct with specification R is any feature f (lexeme, expression, state-
respect to a specification (relation) R on S if and only if ment, set of statements, etc) that admits a substitute that
P ⊒ R. This definition is equivalent to traditional defini- would make the program strictly more-correct. A fault re-
tions of total correctness [7], [8]. moval is a pair of features (f, f ′ ) such that f appears in
The refinement ordering has lattice-like properties, which p and program p′ obtained by replacing f with f ′ in p is
we briefly present below: strictly more-correct than p.

• Two relations admit a least upper bound if and only In the same way that refinement provides a formal model for
if they satisfy the following condition, which we call program derivation, relative correctness, as defined herein,
the consistency condition: RL ∩ R′ L = (R ∩ R′ )L. provides a formal model for fault removal; see Figure 3 (a).
To give the reader some confidence in the soundness of our
• Whenever two relations R and R′ do satisfy the con- definition of relative correctness, we present the following
sistency condition, their least upper bound (join) is properties, due to [13]:
defined by: R ⊔ R′ = R′ L ∩ R ∪ RL ∩ R′ ∪ (R ∩ R′ ).
• Relative correctness is reflexive and transitive, but not
• Two relations have a least upper bound if and only if antisymmetric.
they have an upper bound.
• Relative correctness culminates in (absolute) correct-
ness, i.e. a correct program is more-correct than (or
3. RELATIVE CORRECTNESS as correct as) any candidate program.

3.1 Definition • Relative correctness logically implies (but is not equiv-

Given a specification R and a program P , we refer to the alent to) higher reliability; relative correctness and
domain of (R ∩ P ) as the competence domain of program P higher reliability are not equivalent because the for-
with respect to specification R. When P is deterministic, mer is a logical property, whereas the latter is a stochas-
the competence domain of P with respect to R is the set of tic property.
initial states for which P behaves according to R; when P
is not deterministic (i.e. it may assign more than one final • The fourth property is the subject of the next propo-
state for a given initial state), the competence domain of P sition.
is the set of initial states for which the set of images by P
and the set of images by R overlap (i.e. have a non-empty Proposition 2. Given two programs P and P ′ , P ′ re-
intersection). We have the following definition, due to [2]: fines P if and only if P ′ is more-correct than P with respect
to any specification R. We write this as:
Definition 1. Given two programs p and p′ on space S
P ′ ⊒ P ⇔ (∀R : P ′ ⊒R P ).
and a specification R on S, we say that p′ is more-correct
than p with respect to R (written as: P ′ ⊒R P or P ⊑R P ′ )
if and only if (R∩P )L ⊆ (R∩P ′ )L∧(R∩P )L∩R ∩P ′ ⊆ P . 3.2 Relative Correctness and Refinement
We say that p′ is strictly more-correct than p if one of the Refinement is usually viewed as the touchstone of the
inclusions above is strict (⊂ vs. ⊆). derivation of provably correct programs; in such a deriva-
tion process, each transformation maps an artifact into a
The first clause provides that p′ has a larger competence do- more-refined artifact. But Proposition 2 provides that p′
main than p; the second clause provides that on the compe- refines p if and only if p′ is more-correct than p with re-
tence domain of p, p′ violates R in fewer ways than p (since spect to any specification. If we are trying to derive a pro-
any pair (s, s′ ) such that s is in the competence domain of gram that is correct with respect to a given specification
p and (s, s′ ) is in P ′ and is not in R, is necessarily in P ). In R, then R and only R ought to be the focus of our deriva-
[2], we find that whenever P ′ is deterministic, the condition tion effort. In [4] we argue that it is possible to derive a
of relative correctness can be simplified as follows. correct program from a specification by stepwise correct-
ness enhancing transformations using relative correctness,
Proposition 1. Given two programs p and p′ on space rather than by stepwise correctness preserving transforma-
S such that p′ is deterministic, and given a specification R tions using refinement. In this section, we briefly discuss the
on S, p′ is more-correct than p with respect to R if and only difference between a correctness-preserving transformation
if: (R ∩ P )L ⊆ (R ∩ P ′ )L. and a correctness-enhancing transformation.
As an illustrative example, we consider a space S de-
In the remainder of this paper, we restrict our study to de- fined by two integer variables x and y and we let R be the
terministic programs. Figure 1 shows an example of two following specification on S: R = {(s, s′ )|x′ = x + y}. We
deterministic programs p and p′ and a specification R such consider the following candidate programs:
that p′ is more-correct than p; the competence domains
of p and p′ are highlighted. Two observations are in or- p0: {while (y!=0) {y=y-1; x=x+1;}},
der regarding this example: Note that p′ is more correct P0 = {(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0}.
than p with respect to R, but they are both incorrect; also
note that even though p′ is more-correct than p, it does not p1: {x=x+y;}. P1 = {(s, s′ )|x′ = x + y ∧ y ′ = y}.
duplicate the correct behavior of p, rather it has its own
correct behavior. p2: {x=x+y; y=0;}, P2 = {(s, s′ )|x′ = x + y ∧ y ′ = 0}.
 R P P′
-
:
 0 XX :

0
 0
XX 0 0  0
  XXz
X


1 XX :
 1 1 XX :

XX XX 1 1  1
XXz
X XXz
X 
2 XX :
 2 2 XX 2 2 :
 2
X XX
XXX XX 
3  z
X z
X 


3 3 XX :



3 3 3
XX
- 4 4 XXz
X 
4 4 4 4

Figure 1: Enhancing correctness without duplicating behavior: P ′ ⊒R P

The reader can check (by referring to the definition of re- Attribute Refinement Based Based on Relative
finement given in section 2 and by Proposition 1) that p1 is Correctness
more-correct than p0 but does not refine it, whereas p2 re- Initialization a=R a = abort
fines p0 hence (according to Proposition 2) is more-correct Invariant a is correct a is a program
than p0. We have a simple explanation for this observa- Assertion
tion: if we consider the functional attributes of p0, we can a increasingly conc-
Variant a increasingly
distinguish between two sources of information:
Function rete (program-like) correct
• Functional attributes that are mandated by the spec- Exit test when a is a program when a is correct
ification, such as the clause {x′ = x + y} in P0 .

• Functional attributes that are not mandated by the Figure 2: Iterative Paradigms of Programming
specification, but stem from design decisions, such as
the clause {y ′ = 0} in P0 .
reliability; hence the successive programs generated by this
In order for a program to refine P0 , it has to preserve all process are increasingly reliable; so that the derivation of
the functional attributes of P0 , regardless of their origin a reliable program proceeds in the same way as the deriva-
(specification or design); this is the case for p2. But in order tion of a correct program, except that it terminates as soon
for a program to be more-correct than P0 , it suffices for as the reliability reaches or exceeds the required threshold.
it to preserve the functional attributes that are mandated Given that correctness is the culmination of reliability, it
by R; it may, in the process, override / alter functional is only fitting that the derivation of a correct program be
attributes that stem from design decisions; this is the case the culmination of the derivation of a reliable program. See
for program p1 which overrides {y ′ = 0} with {y ′ = y}. Not Figures 3 (b) and (c).
surprisingly, p1 is simpler than p2, because it is subject to
a less stringent condition.
5. PROGRAM MERGER
4. PROGRAM DERIVATION We consider a specification R and two candidate pro-
grams P1 and P2 (i.e. programs that are written to satisfy
4.1 Correct Programs R –they may or may not satisfy it in fact), each of which
fulfills the requirements of R to some limited extent, but not
To derive a correct program for a specification R, we
necessarily to the full extent. We are interested to merge
have to find an artifact that has two properties: it is a (ex-
programs P1 and P2 into a program that fulfills the require-
ecutable) program; and it is correct with respect to R. To
ments of R to the extent that P1 fulfills them, and to the
do this in a stepwise manner, we can either preserve correct-
extent that P2 fulfills them. We submit the following defi-
ness until we achieve executability (this is the traditional
nition.
refinement-based process), or we can maintain executability
until we achieve correctness (as we advocate in [4]). These Definition 3. Given a specification R and two candi-
two processes being iterative, we can characterize them by date programs P1 and P2 , a merger of P1 and P2 with re-
their initial state, their invariant assertion, their variant spect to R is any program P ′ that is more-correct than P1
function, and their exit condition, as shown in Figure 2. and more-correct than P2 with respect to R.
See also Figure 3 (b).
We mandate that a merger program be merely more-
4.2 Reliable Programs correct than programs P1 and P2 , rather than to refine
In many applications, correctness is unnecessary, and the them, for the following reasons:
cost of achieving correctness (as opposed to sufficient reli-
ability) may be unjustified by the stakes attached to (suffi- • Refinement is Unnecessary. When we resolve to re-
ciently infrequent) program failure. In such cases, it may be fine a program, we commit to refine all its functional
sufficient to produce a reliable program, rather than a cor- attributes, those that are mandated by the specifica-
rect program. Thankfully, the derivation model presented tion as well as those that stem from design decisions.
herein encompasses the derivation of reliable programs as But we have no reason to preserve design decisions of
well as the derivation of correct programs: as we remember P1 and P2 that do not advance the cause of relative
from section 3, relative correctness logically implies higher correctness.
 abort  abort 
Specifi- Specifi- Specifi-
cation R cation R cation R
Imperfect
 ⊑R A ⊑R A
Design  ⊑ Initialization ⊑ Initialization ⊑
 A ⊑RA
)
 ⊑ ⊑R
A ⊑ A ⊑
Incorrect ⊑R A ⊑R A
U
A
Program P ⊑ ⊑ ⊑
Reliable
H ⊑R
⊑R HH ?⊑ AU ?⊑
Program P ′′
?⊑
Monotonic ⊑R HH
j Correct Correct Correct
Fault ⊑R Program P ′ Program P ′ Program P ′
Removal
(b)
(a) (c)
Program Derivation
A Framework for Fault Removal Deriving Reliable Programs
by Correctness Enhancement

Figure 3: Alternative Program Evolution Paradigms

• Relative Correctness is Sufficient. If program P ′ is P ′ = {(s, s′ )|x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 4}.

more-correct than P1 and P2 with respect to specifica- Space restrictions preclude us from showing details, but it is
tion R, then it delivers all the specification-mandated easy to verify that the competence domain of P ′ ((R ∩P )L)
behavior of P1 and all the specification-mandated be- is equal to L, hence P ′ is more-correct than P1 and P2 . Note
havior of P2 . that while we found a program that is more-correct than P1
and P2 , we could not find a program that refines P1 and P2 .
• Refinement may be Impossible. Not only is it unnec- Indeed we can easily check that P1 and P2 do not sarisfy
essary to refine the design-related information of P1 the consistency condition, hence they admit no joint refine-
and P2 , it may actually be impossible: whereas the ment. Indeed, no program can simultaneously increase z by
specification-mandated information of P1 and P2 is 2 (to refine P1 ) and by 3 (to refine P2 ). This discrepancy be-
bounded by R, hence (according to section 2) can be tween what P1 does and what P2 does precludes P1 and P2
combined by the least upper bound operation, the from having a joint refinement, but does not preclude them
design-related information of P1 and P2 may be in- from having a program P ′ that is more-correct than them.
compatible, hence cannot be combined. The reason is: the statements {z=z+2} (in P1 ) and {z=z+3}
(in P2 ) are not mandated by the specification (which only
We consider the space S defined by three variables x, y and
requires {z ′ ≥ z + 2}) but stem instead from arbitrary de-
z of type integer, and we let R be the following specifica-
sign decisions; hence both can be overridden by the merger
tion: R = {(s, s′ )|x′ = x + y ∧ z ′ ≥ z + 2}. Let p1 and p2
program P ′ . The difference between refinement and rel-
be the following candidate programs for specification R:
ative correctness is that the former attempts to refine all
p1: {z=z+2; while (y!=0) {y=y-1; x=x+1;}}
the behavior of a program, regardless of its source, whereas
p2: {z=z+3; while (y!=0) {y=y+1; x=x-1;}}
the latter only refines the behavior that is mandated by the
The functions of these programs are, respectively:
specification. As we see in this simple example, refining all
P1 = {(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 2}
the behavior of P1 and all the behavior of P2 is not only un-
P2 = {(s, s′ )|y ≤ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 3}.
necessary, it is actually impossible. See Figure 4 (a), where
Indeed, the first program terminates only for initial y greater
R1 and R2 represent the specification-mandated behavior
than or equal to zero, and when it terminates, the final value
of P1 and P2 (we have explicit formulae for these, but their
of x contains x + y, the final value of y is zero, and z is in-
study is beyond the scope of this paper).
cremented by 2. As for the second program, it terminates
only for non-positive y, and when it does terminate, the
final value of y is zero, z is increased by 3 and x contains 6. PROGRAM UPGRADE
x + y. So that each program does some of what R asks, but We are given a specification R and a candidate program
neither is correct. A merger of these two programs is any P , and we are interested to augment program P with a new
program P ′ that is more-correct than P1 and more-correct feature that is specified by some relation Q. Typically, P
than P2 with respect to R. The systematic derivation of the may be a large, complex, comprehensive application that
merger of two programs is beyond the scope of this paper; delivers a wide range of services, and Q is a punctual addi-
we content ourselves with presenting a candidate program tional function or service that we want to incorporate into
then showing that it satisfies the definition of a merger. We P (for example, P is a sprawling corporate data process-
propose: ing application, and Q specifies an additional report to be
p’: {z=z+4; delivered, or an additional output screen, or an additional
if (y>0) {while (y!=0) {y=y-1; x=x+1;}} statistic on corporate transactions, etc). In transforming P
else {while (y!=0) {y=y+1; x=x-1;}}} into P ′ , we have every expectation that P ′ refines Q, be-
As far as x and y are concerned, this program imitates the cause Q is a fairly simple requirement and because it is the
behavior of P1 for non-negative values of y, and the behav- main goal of the operation. But we have no expectation
ior of P2 for non-positive values of y; as far as z is concerned, that P ′ refine P , because the implementation of Q may re-
this program overrides the behavior of both P1 and P2 and quire that some of the behavior of P be altered. Nor do we
increments z by 4. We argue that this program is more- expect that P ′ refines R, because in fact we are not even
correct than P1 and more-correct than P2 with respect to sure P refines R (P is typically incorrect, i.e. it fails to cor-
R. The function of this program is: rectly deliver all the required services in all circumstances).
 P′
• P
•
′

B@ @
 B@ @

⊒R  B @ ⊒R ⊒R  @⊒
 B @  @
⊒  B⊒ @ ⊒  @
P1•  B @• P2 P1•  @• Q
@  B @ 
@ 
⊒ B ⊒ ⊒@ 
@• B• @•
R1 R2 R1

(a) (b)
Merger of P1 and P2 Upgrading P1 with Feature Q

Figure 4: Merger and Upgrade

While we do not expect P ′ to refine P nor R, we most cer-

tainly expect P ′ to be more-correct than P with respect We argue in this section that corrective maintenance is
nothing but an instance of program transformation by rel-
to R; in other words, we do not want that in the process ative correctness: in fact it is merely a step in the process
of adding feature Q to P , we degrade the correctness of P we have outlined for program derivation by correctness en-
with respect to R. hancement; it starts at the current program (rather than
abort) and it ends a step later (rather than necessarily at a
Definition 4. Given a specification R and a candidate correct program). See Figure 5. As an illustration, we con-
program P , and given a feature Q that we want to add to sider the following program on the space S defined by its
P , an upgrade P ′ of P with feature Q is any program that variable declarations (due to [6], with some modifications):
refines Q and is more-correct than P with respect to R. p: #include <iostream> ... ... ... // line 1
main {(char q[]); int let, dig, other, i, l; char c;// 2
Given a specification R on space S defined by integer vari- i=0; let=0; dig=0; other=0; l=strlen(q); // 3
ables x and y, R = {(s, s′ )|x′ = x + y} and given the fol- while (i<l) { // 4
lowing candidate program, c = q[i]; // 5
if (’A’<=c && ’Z’>c) let+=2; // 6
p1: {x=x+10; while (y!=10) {y=y-1; x=x+1;}} else // 7
we consider the problem of upgrading program P1 with fea- if (’a’<=c && ’z’>=c) let+=1; // 8
ture Q defined by: Q = {(s, s′ )|y > 0∧y ′ = 0}. The function else // 9
if (’0’<=c && ’9’>=c) dig+=1; // 10
of program p1 is: else // 11
P1 = {(s, s′ )|y ≥ 10 ∧ x′ = x + y ∧ y ′ = 10}. other+=1; // 12
Note that P1 and Q do not satisfy the consistency condi- i++;} // 13
tion, since P1 sets y to 10 while Q mandates that we set We define the following sets: αA = {′ A′ . . .′ Z ′ }. αa =
it to 0 (for positive values of y). Therefore it is impossi- {′ a′ . . .′ z ′ }. ν = {′ 0′ . . .′ 9′ }. σ = {′ +′ ,′ −′ ,′ =′ , ...′ /′ }, the
ble to fulfill requirement Q without altering the behavior of set of all the ascii symbols. We let listhT i denote the set of
P1 . Fortunately, the feature of P1 that precludes us from lists of elements of type T, and we let #A , #a , #ν and #σ
refining Q, namely the clause y ′ = 10, is not a specification- be the functions that to each list l assign (respectively) the
mandated requirement, but stems instead from the specific number of upper case alphabetic characters, lower case al-
design of P1 . Hence while it is impossible for the upgrade phabetic characters, numeric digits, and symbols. We con-
program P ′ to refine P , it is not impossible for P ′ to be sider the following specification on S:
more-correct than P with respect to R. We consider the R = {(s, s′ )|q ∈ listhαA ∪ αa ∪ ν ∪ σi∧
following program: let′ = #a (q) + #A (q) ∧ dig ′ = #ν (q) ∧ other ′ = #σ (q)}.
p’: {while (y!=0) {y=y-1; x=x+1;}} The competence domain of P is:
The function of this program is: (R ∩ P )L = {(s, s′ )|q ∈ listhαa ∪ ν ∪ σi}.
P ′ = {(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0}. This is different from the domain of R, which is
While space limitation preclude us from showing detailed RL = {(s, s′ )|q ∈ listhαA ∪ αa ∪ ν ∪ σi},
calculations, it is easy to check that P ′ does refine Q. On hence P is not correct with respect to R. If we let P ′ be
the other hand, we can easily check that the competence the program obtained from P by changing {let=+2} into
domain of P1 is {(s, s′ )|y ≥ 10} whereas the competence {let=+1}, we find:
domain of P ′ is {(s, s′ )|y ≥ 0}. Hence P ′ is more-correct (R ∩ P ′ )L = {(s, s′ )|q ∈ listh(αA \ {′ Z ′ }) ∪ αa ∪ ν ∪ σi}.
than P1 with respect to R. While it is not possible to sat- Clearly, (R ∩ P ′ )L ⊃ (R ∩ P )L. Hence statement {let+=2}
isfy Q while preserving all the behavior of P1 , it is possible, is a fault in P with respect to specification R and the sub-
and sufficient, to satisfy Q while enhancing the correctness stitution of {let+=2} by {let+=1} is a fault removal in P
of P1 ; this is what P ′ does. See Figure 4 (b). with respect to R.

7. SOFTWARE MAINTENANCE 7.2 Adaptive Maintenance

Adaptive maintenance consists in taking a program P
7.1 Corrective Maintenance which was originally developed to satisfy some specification
 abort  Specifi- its definition of relative correctness (more successful/ less
Initiali- cation R unsuccessful assertions, vs. larger competence domains),
⊑R A zation ⊑ and its goals (fault diagnosis/ program repair vs. software
A
evolution).
Faulty ⊑R A ⊑
Program
-A
⊑R A ⊑ 9. REFERENCES
Corrected  A [1] Borzoo Bonakdarpour, Ali Ebnenasir, and Sandeep S.
Program ⊑R
A ⊑ Kulkarni. Complexity results in revising unity
⊑R A
programs. ACM Transactions on Autonomous and
⊑
AU ? Adaptive Systems, 4(1), January 2009.
Correct [2] Jules Desharnais, Nafi Diallo, Wided Ghardallou,
Program P ′
Marcelo Frias, Ali Jaoua, and Ali Mili. Mathematics
for relative correctness. In Relational and Algebraic
Figure 5: Corrective Maintenance Methods in Computer Science, 2015, pages 191–208,
Lisbon, Portugal, September 2015.
 Specifi- [3] Nafi Diallo, Wided Ghardallou, and Ali Mili.
abort
cation R Correctness and relative correctness. In Proceedings,
A Initialization
37th International Conference on Software
⊑R A ⊑
Engineering, Firenze, Italy, May 20–22 2015.
A [4] Nafi Diallo, Wided Ghardallou, and Ali Mili.
⊑R A ⊑
Program derivation by correctness enhancements. In
A
Refinement 2015, Oslo, Norway, June 2015.
A
⊑R ⊑
U
A [5] Wided Ghardallou, Nafi Diallo, Ali Mili, and Marcelo
⊑R ′
⊑
Frias. Debugging without testing. In Proceedings,

International Conference on Software Testing,
⊑R ′
⊑
Chicago, IL, April 2016.



? [6] A. Gonzalez-Sanchez, R. Abreu, H-G. Gross, and
Correct Correct A.J.C. van Gemund. Prioritizing tests for fault
Program wrt R′ Program wrt R localization through ambiguity group reduction. In
proceedings, Automated Software Engineering,
Figure 6: Adaptive Maintenance Lawrence, KS, 2011.
[7] D. Gries. The Science of programming. Springer
Verlag, 1981.
R and changing it to make it satisfy some new specification [8] E.C.R. Hehner. A Practical Theory of Programming.
R′ . We view this as simply trying to make P more-correct Prentice Hall, 1992.
with respect to R′ than it is in its current form. Clearly, one [9] Barbara Jobstmann, Andreas Griesmayer, and
does this if one believes that P is close enough to satisfy Roderick Bloem. Program repair as a game. In
R′ that it is more economical to evolve P than to start Computer Aided Verification, number 3576 in LNCS,
from abort. Be that as it may, we argue that adaptive pages 226–238, 2005.
maintenance is again a process of making a program more- [10] Shuvendu K. Lahiri, Kenneth L. McMillan, Rahul
correct with respect to a given specification. See Figure Sharma, and Chris Hawblitzel. Differential assertion
6. checking. In Proceedings, ESEC/ SIGSOFT FSE,
pages 345–455, 2013.
8. CONCLUSION [11] Francesco Logozzo and Thomas Ball. Modular and
In this paper, we consider the concept of relative cor- verified automatic program repair. In Proceedings,
rectness (due to [13]), and show that it pervades software OOPSLA, pages 133–146, 2012.
evolution, and is potentially more flexible, without being [12] Francesco Logozzo, Shuvendu Lahiri, Manual
less effective, than refinement-based program transforma- Faehndrich, and Sam Blackshear. Verification modulo
tions. In particular, we find that this concept can provide versions: Towards usable verification. In Proceedings,
a formal model for a wide range of software evolution ac- PLDI, page 32, 2014.
tivities, including software design, corrective maintenance, [13] Ali Mili, Marcelo Frias, and Ali Jaoua. On faults and
adaptive maintenance, software upgrade, program merger, faulty programs. In Peter Hoefner, Peter Jipsen,
etc. As a consequence, we argue that by evolving a tech- Wolfram Kahl, and Martin Eric Mueller, editors,
nology of program transformation with relative correctness, Proceedings, RAMICS: 14th International Conference
we stand to enhance a wide range of software engineering on Relational and Algebraic Methods in Computer
activities. Science, volume 8428 of Lecture Notes in Computer
Other authors have introduced similar-sounding but dis- Science, pages 191–207, Marienstatt, Germany, April
tinct notions of relative correctness [1, 9–12, 14]. Their work 28–May 1st 2014. Springer.
differs from ours in terms of its specification format (exe- [14] Hoang Duong Thien Nguyen, DaWei Qi, Abhik
cutable assertions vs. input/output relations), its program Roychoudhury, and Satish Chandra. Semfix: Program
semantics (execution traces vs. program functions), its def- repair via semantic analysis. In Proceedings, ICSE,
inition of correctness (successful assertions vs. refinement), pages 772–781, 2013.