Projecting Programs on Specifications:

Definition and Implications

Jules Desharnais
Département d’Informatique, Université Laval, Québec, Canada
[email protected]

Nafi Diallo
New Jersey Institute of Technology, Newark, NJ
[email protected]

Wided Ghardallou
Faculté des Sciences de Tunis, El Manar, Tunisia
[email protected]

Ali Mili
New Jersey Institute of Technology, Newark, NJ
[email protected]

Abstract

Given a specification R, it is common for a candidate program P to be doing

more than R requires; this is not necessarily bad, and is often unavoidable, due
to programming language constraints or to otherwise sensible design decisions. In
this paper, we introduce a relational operator that captures, for a given specification
R and candidate program P , the functionality delivered by P that is relevant to R.
This operator, which we call the projection of P over R (for reasons we explain),
has a number of interesting properties, which we explore in this paper.

Key words: absolute correctness, relative correctness, refinement, projection,

lattices.

1 Projecting Programs on Specifications

Given a specification R and a program P that is written to satisfy R, we refer

to P as a candidate program for specification R, and we refer to R as the

Preprint submitted to Elsevier 7 January 2016

target specification of program P , regardless of whether P does or does not
satisfy specification R. Given a specification R and a candidate program P ,
the program P could well be falling short of some of the requirements of R,
while at the same time exceeding (i.e. doing more than needed) on some other
requirements. There is no shortage of reasons why a program may fall short
of the requirements mandated by the specification, but there are also ample
reasons why a program may do more than required: these include cases where
excess functionality is a byproduct of normal design decisions, cases where it
stems from programming language constructs, and more generally the need to
bridge the gap between a non-deterministic specification and a deterministic
program. Consider for example the following relational specification on space
S defined by integer variables x and y:

R = {(hx, yi, hx′, y ′i)|x′ = x + y},

and consider the following program on the same space:

{while (y!=0) {x=x+1; y=y-1;}}.
For non-negative values of y this program computes the sum of x and y in x
while placing 0 in y; for negative values of y, it fails to terminate. Hence its
function can be written as:

P = {(hx, yi, hx′, y ′i)|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0}.

This program does not do everything that specification R requires, since it

fails to compute the sum of x and y into x for negative values of y; on the
other hand, it puts 0 in y even though the specification did not ask for it (but
this is a side effect of the algorithm we have chosen to satisfy the specification).
Hence looking at specification R and program P , we would like to think that
the functionality of P that is relevant to (mandated by) R is captured by the
following relation:

π = {(hx, yi, hx′, y ′i)|y ≥ 0 ∧ x′ = x + y}.

Whatever else P does (e.g. it sets y to 0) is not relevant to specification R;

on the other hand, whatever else the specification mandates (computing the
sum of x and y into x for negative values of y), program P is not delivering.
In other words, relation π fails to specify y ′ = 0 because that is not mandated
by the specification, and it fails to specify the case y < 0 because that is not
delivered by the candidate program P .

In this paper, we introduce a relational operator that captures, for a given

specification specification R and program P , the functionality delivered by
P that is relevant to (i.e. mandated by) R; we refer to this operator as the
projection of P over R, for reasons that we elucidate in our subsequent discus-
sions. We define this operator in section 4, and we discuss its properties and
implications in section 5. The concept of projection of a program on a specifi-
cation comes about as a byproduct of the definition of relative correctness, i.e.

2
the property of a program to be more-correct than another with respect to a
specification. Relative correctness, due to Desharnais et al. (2015), is discussed
in section 3. In section 2 we introduce the mathematical background that we
use throughout this paper. In section 6 we ibriefly summarize and assess our
work, then compare it to related research.

2 Mathematical Background

2.1 Relational Notations

In this section, we introduce some elements of relational mathematics that we

use in the remainder of the paper to carry out our discussions. We assume
the reader familiar with relational algebra, and we generally adhere to the
definitions of Schmidt and Stroehlein (1990); Brink et al. (1997). Dealing with
programs, we represent sets using a programming-like notation, by introducing
variable names and associated data types (sets of values). For example, if we
represent set S by the variable declarations
x : X; y : Y ; z : Z,
then S is the Cartesian product X × Y × Z. Elements of S are denoted in
lower case s, and are triplets of elements of X, Y , and Z. Given an element
s of S, we represent its X-component by x(s), its Y -component by y(s), and
its Z-component by z(s). When no risk of ambiguity exists, we may write x
to represent x(s), and x′ to represent x(s′ ).

A relation on S is a subset of the Cartesian product S × S; given a pair (s, s′ )

in R, we say that s′ is an image of s by R. Special relations on S include the
universal relation L = S × S, the identity relation I = {(s, s′)|s′ = s}, and
the empty relation φ = {}. Operations on relations (say, R and R′ ) include
the set theoretic operations of union (R ∪ R′ ), intersection (R ∩ R′ ), difference
(R\R′ ) and complement (R). They also include the relational product, denoted
by (R ◦ R′ ), or (RR′ , for short) and defined by:

RR′ = {(s, s′ )|∃s′′ : (s, s′′ ) ∈ R ∧ (s′′ , s′ ) ∈ R′ }.

The power of relation R is denoted by Rn , for a natural number n, and defined

by R0 = I, and for n > 0, Rn = R ◦ Rn−1 . The reflexive transitive closure of
relation R is denoted by R∗ and defined by R∗ = {(s, s′ )|∃n ≥ 0 : (s, s′ ) ∈ Rn }.
The converse of relation R is the relation denoted by R b and defined by

b = {(s, s′ )|(s′ , s) ∈ R}.

R

Finally, the domain of a relation R is defined as the set dom(R) = {s|∃s′ :

b Op-
(s, s′ ) ∈ R}, and the range of relation R is defined as the domain of R.

3
erator precedence is adopted as follows: unary operators apply first, followed
by product, then intersection, then union.

A relation R is said to be reflexive if and only if I ⊆ R, symmetric if and only

if R = R,b antisymmetric if and only if R ∩ R b ⊆ I, asymmetric if and only
if R ∩ Rb = φ, and transitive if and only if RR ⊆ R. A relation is said to be
a partial ordering if and only if it is reflexive, antisymmetric, and transitive.
b and a relation R is
Also, a relation R is said to be total if and only if I ⊆ RR,
said to be deterministic (or: a function) if and only if RRb ⊆ I. In this paper
we use a property to the effect that two functions f and f ′ are identical if and
only if f ⊆ f ′ and f ′ L ⊆ f L. A relation R is said to be a vector if and only if
RL = R; a vector on space S is a relation of the form R = A × S, for some
subset A of S; we use vectors to represent subsets of S; in particular, we use
the product RL as a relational representation of the domain of R.

2.2 A Refinement Calculus

Throughout this paper, we interpret relations as program specifications or as

programs. A key concept in any study of program correctness is the refinement
ordering; the following definition gives our version of this ordering.

Definition 1. Given two relations R and R′ , we say that R′ refines R (abbrev:

R′ ⊒ R) if and only if: RL ∩ R′ L ∩ (R ∪ R′ ) = R.

The following proposition provides an alternative characterization of refine-

ment, which we may use in our proofs throughout this paper, as well as an
intuitive interpretation of the refinement relation.

Proposition 1. Given two relations R and R′ , R′ refines R if and only if

RL ⊆ R′ L ∧ RL ∩ R′ ⊆ R.

Proof. Proof of Sufficiency. Let R and R′ satisfy the conditions RL ⊆ R′ L

and RL ∩ R′ ⊆ R. We compute:
RL ∩ R′ L ∩ (R ∪ R′ )
= {hypothesis RL ⊆ R′ L}
RL ∩ (R ∪ R′ )
= {distributing pre-restriction}
RL ∩ R ∪ RL ∩ R′
= {identity, hypothesis RL ∩ R′ ⊆ R}
R.
Hence R′ refines R.

Proof of Necessity. Let R′ refine R; we must prove RL ⊆ R′ L and RL∩R′ ⊆ R.

For the first clause, we proceed as follows:

4
 RL
= {hypothesis}
RL ∩ R L ∩ (R ∪ R′ )L
′

= {distributivity, associativity}
(RL ∩ R L) ∩ (RL ∪ R′ L)
′

= {the first term is a subset of the second}

RL ∩ R′ L.
Hence (by set theory) RL ⊆ R′ L. For the second clause, we proceed as follows:
RL ∩ R′
⊆ {monotonicity}
RL ∩ (R ∪ R ) ′

= {since RL ⊆ R′ L}
RL ∩ R′ L ∩ (R ∪ R′ )
= {hypothesis}
R. qed

According to proposition 1, R′ refines R if and only if it has a larger domain

and assigns fewer images to elements in the domain of R.

We find in Boudriga et al. (1992) that the refinement relation is reflexive, anti-
symmetric and transitive, and that it has the following lattice-like properties:

• Any two relations R and R′ have a greatest lower bound, which we denote
by R ⊓ R′ and to which we refer as the meet of R and R′ . Also, we find:
R ⊓ R′ = RL ∩ R′ L ∩ (R ∪ R′ ).
• Two relations R and R′ admit a least upper bound if and only if they satisfy
the condition RL∩R′ L = (R∩R′ )L, which we call the consistency condition.
• Any two relations that satisfy the consistency condition admit a least upper
bound, which we denote by R ⊔ R′ and to which we refer as the join of R
and R′ . Also, we find:

R ⊔ R′ = (RL ∩ R′ ) ∪ (R′ L ∩ R) ∪ (R ∩ R′ ).

The join of two specifications (or programs) R and R′ is very important,

because it captures the specification that represents all the functional at-
tributes of R, all the functional attributes of R′ , and nothing else. It is
possible to capture all the functional attributes of R and R′ only if R and
R′ do not contradict each other: this is what the consistency condition rep-
resents.
• Two relations R and R′ have a least upper bound if and only if they have an
upper bound. Consequently, if R and R′ satisfy the consistency condition
and R refines Q and R′ refines Q′ then a fortiori Q and Q′ satisfy the
consistency condition. Conversely, as we refine R and R′ , we make it less
and less likely that they satisfy the consistency condition.

5
• The empty relation is the universal lower bound of this ordering.
• This ordering admits no universal upper bound. Total deterministic rela-
tions are the maximal elements of this ordering.

3 Absolute Correctness and Relative Correctness

Whereas absolute correctness characterizes the relationship between a spec-

ification and a candidate program, relative correctness ranks two candidate
programs with respect to a specification; in order to discuss the latter, it
helps to review the former, to see how it is defined in our notation.

3.1 Program Functions

Given a program p on space S, we denote by [p] the function that p defines

on its space, i.e.
[p] = {(s, s′ )|if program p executes on state s then it terminates in state
s }.
′

We represent program spaces by means of C-like variable declarations and we

represent programs by means of a few simple C-like programming constructs,
which we present below along with their semantic definitions:

• Abort: [abort] ≡ φ.
• Skip: [skip] ≡ I.
• Assignment: [s = E(s)] ≡ {(s, s′ )|s ∈ δ(E) ∧ s′ = E(s)}, where δ(E) is the
set of states for which expression E can be evaluated.
• Sequence: [p1 ; p2 ] ≡ [p1 ] ◦ [p2 ].
• Conditional: [if (t) {p}] ≡ T ∩ [p] ∪ T ∩ I, where T is the vector defined as:
T = {(s, s′)|t(s)}.
• Alternation: [if (t) {p} else {q}] ≡ T ∩ [p] ∪ T ∩ [q], where T is defined as
above.
• Iteration: [while (t) {b}] ≡ (T ∩ [b])∗ ∩ Tb , where T is defined as above.
• Block: [{x : X; p}] ≡ {(s, s′ )|∃x, x′ ∈ X : (hs, xi, hs′ , x′ i) ∈ [p]}.

Rather than use the notation [p] to denote the function of program p, we will
usually use upper case P as a shorthand for [p]. By abuse of notation, we may,
when it causes no confusion, refer to a program and its function by the same
name (which we represent by an upper case letter).

6
3.2 Absolute Correctness

Definition 2. Let p be a program on space S and let R be a specification on

S.

• We say that program p is correct with respect to R if and only if P refines

R.
• We say that program p is partially correct with respect to specification R if
and only if P refines R ∩ P L.

This definition is consistent with traditional definitions of partial and total

correctness Hoare (1969); Manna (1974); Gries (1981); Dijkstra (1976); Hehner
(1992). Whenever we want to contrast correctness with partial correctness, we
may refer to it as total correctness. The following proposition, due to Mills
et al. (1986), gives a simple characterization of correctness.

Proposition 2. Program p is correct with respect to specification R if and

only if (R ∩ P )L = RL.

Note that because (R ∩ P )L ⊆ RL is a tautology (by Boolean algebra), the

condition above can be written as: RL ⊆ (R ∩ P )L; this condition can, in turn
(due to relational algebra), be written as, R ⊆ (R ∩ P )L. Note also that the
condition set forth in this proposition holds only because P is deterministic;
in general, (R′ ∩ R)L = RL is not equivalent to R′ ⊒ R. From Definition 2
and Proposition 2 we infer that program P is partially correct with respect to
specification R if and only if (R∩P )L = RL∩P L. Interestingly, this condition
is equivalent to: P and R satisfy the consistency condition.

3.3 Relative Correctness: Deterministic Programs

Definition 3. Let R be a specification on space S and let p and p′ be two

deterministic programs on space S whose functions are respectively P and P ′ .

• We say that program p′ is more-correct than program p with respect to

specification R (denoted by: P ′ ⊒R P ) if and only if: (R ∩ P ′ )L ⊇ (R ∩ P )L.
• Also, we say that program p′ is strictly more-correct than program p with
respect to specification R (denoted by: P ′ =R P ) if and only if (R ∩ P ′ )L ⊃
(R ∩ P )L.

Interpretation: (R ∩ P )L represents (in relational form) the set of initial states

on which the behavior of P satisfies specification R. We refer to this set as the
competence domain of program P . Relative correctness of P ′ over P with re-
spect to specification R simply means that P ′ has a larger competence domain

7
 R P P′
0 : 0 0 XXX 0 0 :
 0
  XX
XXX  
 z 1 
1 XXX

: 1 1 XXX 1  :
 1

X
X
X XX
XXX 
 XXz z 
2 XXX
: 2 X
2 XX 2 2  :
 2

X

XXX XX
XXX 
 Xz z 
3 XXX

: 3 3 XXX 3 3  :
 3

X
X
X XX
XXX 
 XXz z 
4 XXX
: 4 4 XXX 4 4  :
 4

X

XXX  XX
XXX 
 Xz 5 XXX z 5 

:
5 5 5  5
XX
XXX  
6 6 6 z 6 
6 6
Fig. 1. Enhancing correctness without duplicating behavior: P′ ⊒R P

than P . Whenever we want to contrast correctness (given in Definition 2) with

relative correctness, we may refer to it as absolute correctness. Note that when
we say more-correct we really mean more-correct or as-correct-as; we use the
shorthand, however, for convenience. Note also that in order for program p′
to be more-correct than program p, it does not need to duplicate the behavior
of p over the competence domain of p; see Figure 1. In the example shown in
this figure, we have:
(R ∩ P )L = {1, 2, 3, 4} × S,
(R ∩ P ′)L = {1, 2, 3, 4, 5} × S,
where S = {0, 1, 2, 3, 4, 5, 6}. Hence p′ is more-correct than p with respect to
R.

In order to highlight the contrast between relative correctness and absolute

correctness, we consider the specification R on space S = nat

R = {(s, s′)|s2 ≤ s′ ≤ s3 },

and we consider the following programs, where along with each program we
indicate its function, then its competence domain with respect to R:

p0: {abort}. P0 = φ. CD0 = ∅.

p1: {s=0;}. P1 = {(s, s′ )|s′ = 0}. CD1 = {0}.
p2: {s=1;}. P2 = {(s, s′ )|s′ = 1}. CD2 = {1}.
p3: {s=2*s**3-8;}. P3 = {(s, s′ )|s′ = 2s3 − 8}. CD3 = {2}.
p4: {skip;}. P4 = I. CD4 = {0, 1}.
p5: {s=2*s**3-3*s**2+2;}. P5 = {(s, s′ )|s′ = 2s3 − 3s2 + 2}. CD5 = {1, 2}.
p6: {s=s**4-5*s;}. P6 = {(s, s′ )|s′ = s4 − 5s}. CD6 = {0, 2}.
p7: {s=s**2;}. P7 = {(s, s′ )|s′ = s2 }. CD7 = S.
p8: {s=s**3;}. P8 = {(s, s′ )|s′ = s3 }. CD8 = S.
2 3
p9: {s=(s**2+s**3)/2;}. P9 = {(s, s′)|s′ = s +s 2
}. CD9 = S.

Figure 2 shows how these ten programs are ordered according to their relative
correctness with respect to R; in this sample, programs P7 , P8 , P9 are (abso-
lutely) correct while programs P0 , P1 , P2 , P3 , P4 , P5 , P6 are incorrect because

8
 P7 , P8 , P9
@
@
@
@
@
@
@
@ @
P6 @ @
@ @P
P4 @ 5
@
@ @
@ @
@ @
@ @
@ @
P1 @P
@ @ 3
@ @ P2
@ @
@ @
@
@
@
@
@
@
P0
Fig. 2. Ordering Candidate Programs by Relative Correctness
their competence domain is strictly smaller than the domain of R.

3.4 Relative Correctness: Non-Deterministic Programs

In this section we extend the definition of relative correctness to non deter-

ministic program. There are several reasons why this is important/ useful:

• Non-determinacy is a convenient means to model deterministic programs

whose detailed behavior is difficult to capture, unknown, or irrelevant to a
particular analysis.
• We may want to reason about the relative correctness of deterministic pro-
grams without having to compute their function is all its minute details.
• We may want to apply relative correctness, not only to finished software
products, but also to partially defined intermediate artifacts, such as de-
signs.

We submit the following definition.

Definition 4. We let R be a specification on set S and we let P and P ′ be

(possibly non-deterministic) programs on space S. We say that P ′ is more-
correct than P with respect to R (abbrev: P ′ ⊒R P ) if and only if:

(R ∩ P )L ⊆ (R ∩ P ′ )L ∧

9
 0 XXX R - P P′
X
X
:0 H
0Z
HH  *

0 H
0Z
H 
*
0
 XXXX Z   ZHH
X
 z ZHH Z 
1 XX -

:1 1ZH ZH :
 1 1XHXX H
ZHH  1
X
X H H
Z
 *

>
 HXX
ZX*
 XXXX  
ZH
 H
Z H
j H
 H XHj
H
2X z
- 2 ZHH 2XX HZZXX
z
XX
XX:2
 Z 
 H
Z

H
:
*

2 XH
XXXH*

2
ZZ Z
XXXX 
 
 H>

~
Z
Z H
j  X
H
 
>

~
Z
j
H
XX

3 XXX
z
-  
  3XX  
z
XX:3
 
3  Z *

ZZ
3 X
XX *

3
XXXX
z

   ~  XX
XX
z

4 XXX - 4   XX 

X
X
:4  4 
4 X
XXX
4
 XXXX 
 
 X
 z
- XX
z
5 5 5 5 5 5
Fig. 3. Relative Correctness for Non-Deterministic Programs: P ′ ⊒R P .

(R ∩ P )L ∩ R ∩ P ′ ⊆ P.

Interpretation: P ′ is more-correct than P with respect to R if and only if

it has a larger competence domain, and for the elements in the competence
domain of P , program P ′ has fewer images that violate R than P does. As an
illustration, we consider the set S = {0, 1, 2, 3, 4, 5, 6, 7} and we let R, P and
P ′ be defined as follows:
R = {(0, 0), (0, 1), (1, 0), (1, 1), (1, 2), (2, 1), (2, 2), (2, 3), (3, 2), (3, 3), (3, 4),
(4, 3), (4, 4), (4, 5), (5, 4), (5, 5)}
P = {(0, 2), (0, 3), (1, 3), (1, 4), (2, 0), (2, 1), (3, 1), (3, 2), (4, 1), (4, 2), (5, 2),
(5, 3)}
P = {(0, 2), (0, 3), (1, 2), (1, 3), (2, 0), (2, 3), (3, 1), (3, 4), (4, 2), (4, 5), (5, 2),
′

(5, 3)}
From these definitions, we compute:
R ∩ P = {(2, 1), (3, 2)},
(R ∩ P )L = {2, 3} × S,
R ∩ P ′ = {(1, 2), (2, 3), (3, 4), (4, 5)}
(R ∩ P ′)L = {1, 2, 3, 4} × S
(R ∩ P )L ∩ P ′ = {(2, 0), (2, 3), (3, 1), (3, 4)}
(R ∩ P )L ∩ R ∩ P ′ = {(2, 0), (3, 1)}
By inspection, we do find that (R ∩ P )L = {2, 3} × S is indeed a subset of
(R∩P ′ )L = {1, 2, 3, 4}×S. Also, we find that (R∩P )L∩R∩P ′ = {(2, 0), (3, 1)}
is a subset of P . Hence the two clauses of Definition 4 are satisfied. Figure
3 represents relations R, P and P ′ on space S. Program P ′ is more-correct
than program P with respect to R because it has a larger competence domain
({2, 3} vs. {1, 2, 3, 4}, highlighted in Figure 3) and because on the competence
domain of P (={2, 3}), program P ′ generates no incorrect output unless P
also generates it ({(2, 0), (3, 1)}).

We show in Desharnais et al. (2015) that if P ′ is deterministic, then the

conditions (R ∩ P )L ⊆ (R ∩ P ′ )L and P ′ ⊒R P are logically equivalent,
which means that Definition 4 can be used in general for relative correctness.

10
3.5 Equal Correctness

Proposition 3. The relative correctness relation with respect to a given spec-

ification is reflexive and transitive.

Proof. Reflexivity is trivial. To prove transitivity, we consider relations R,

P , P ′ and P ′′, and we assume that P ′ is more-correct than P with respect
to R, and that P ′′ is more-correct than P ′ with respect to R. The condition
(R ∩ P )L ⊆ (R ∩ P ′′ )L stems readily from the hypothesis. We focus on the
condition (R ∩ P )L ∩ R ∩ P ′′ ⊆ P , which we prove as follows:
(R ∩ P )L ∩ R ∩ P ′′ ⊆ P
⇔ {Hypothesis: P ′ ⊒R P , hence (R ∩ P )L ⊆ (R ∩ P ′)L}
(R ∩ P )L ∩ (R ∩ P ′ )L ∩ R ∩ P ′′ ⊆ P
⇔ {Hypothesis: P ′′ ⊒R P ′ , hence (R ∩ P ′ )L ∩ R ∩ P ′′ ⊆ P ′ }
(R ∩ P )L ∩ (R ∩ P ′ )L ∩ R ∩ P ′′ ∩ P ′ ⊆ P
⇐ {Boolean algebra}
(R ∩ P )L ∩ R ∩ P ′ ⊆ P,
which holds, by hypothesis. qed

Since ⊒R is reflexive and transitive, it is a preorder; we use this preorder to

define an equivalence relation, as follows:

Definition 5. Two relations P and P ′ are said to be equally correct with

respect to specification R (abbrev: P ≡R P ′ ) if and only if P ⊒R P ′ and
P ′ ⊒R P .

For deterministic relations P and P ′ , equal correctness simply means having

the same competence domain; the following proposition characterizes equal
correctness for arbitrary (not necessarily deterministic) relations.

Proposition 4. Let R, P and P ′ be arbitrary relations on space S. Then

(P ≡R P ′ ) ⇔ (R ∩ P )L = (R ∩ P ′ )L ∧ (R ∩ P )L ∩ R ∩ P = (R ∩ P ′ )L ∩ R ∩ P ′ .

Proof. From P ≡R P ′ we infer readily that P and P ′ have the same com-
petence domain with respect to R. Also, from (R ∩ P )L ∩ R ∩ P ′ ⊆ P and
(R ∩ P )L = (R ∩ P ′ )L we infer:

(R ∩ P ′ )L ∩ R ∩ P ′ ⊆ (R ∩ P )L ∩ R ∩ P.

By interchanging P and P ′ and combining the two results, we find:

(R ∩ P ′ )L ∩ R ∩ P ′ = (R ∩ P )L ∩ R ∩ P.

11
The converse implication is trivial, if we replace equality by inclusion, and
note that an intersection is a subset of its terms. qed

4 Projections: Definition and Properties

4.1 Definition

Definition 6. Given a specification R and a program P , the projection of P

on R is the relation denoted by ΠR (P ) and defined by:

ΠR (P ) = (R ∩ P )L ∩ (R ∪ P ).

Even though the formula of ΠR (P ) is symmetric in R and P , we refer to it in

asymmetric terms, since the specification R and the program P play distinct
roles. The first property we explore about projection is idempotence (just like
projections in geometry).

Proposition 5. The projection of a program P on a specification R (viewed

as a function of P ) is idempotent, i.e. ΠR (ΠR (P )) = ΠR (P ).

Proof. ΠR (ΠR (P ))
= {Definition of ΠR }
(R ∩ ΠR (P ))L ∩ (R ∪ ΠR )
= {Definition of ΠR }
(R ∩ (R ∩ P )L ∩ (R ∪ P ))L ∩ (R ∪ (R ∩ P )L ∩ (R ∪ P ))
= {Boolean algebra}
((R ∩ P )L ∩ R)L ∩ (R ∪ (R ∩ P )L ∩ P )
= {(QL ∩ R)L = QL ∩ RL}
(R ∩ P )L ∩ RL ∩ (R ∪ (R ∩ P )L ∩ P )
= {Monotonicity of composition and Boolean algebra}
(R ∩ P )L ∩ (R ∪ (R ∩ P )L ∩ P )
= {Boolean algebra}
(R ∩ P )L ∩ (R ∪ P )
= {Definition of ΠR }
ΠR (P ) qed

Proposition 6. Given a specification R and a program P , specification R

refines the projection of program P over R.

12
Proof. Let π be the projection of P on R; according to Proposition 1, we
have to prove πL ⊆ RL and πL ∩ R ⊆ π. The first clause stems readily from
πL = (R ∩ P )L by monotonicity. The second clause can be proved as follows:
πL ∩ R
= {πL = (R ∩ P )L}
(R ∩ P )L ∩ R
⊆ {monotonicity}
(R ∩ P )L ∩ (R ∪ P )
= {substitution}
π. qed

Corollary 1. Given a specification R and two candidate programs P and P ′ ,

the projections of P and P ′ on R satisfy the consistency condition.

Proof. By Proposition 6 ΠR (P ) and ΠR (P ′ ) have an upper bound. By the

results provided in section 2.2, ΠR (P ) and ΠR (P ′ ) have a least upper bound,
which means that they satisfy the consistency condition. qed

Whereas P and P ′ may fail to have a join (due to divergent designs), their
projections on R may not (since they only reflect subspecifications of R).

Corollary 2. Given a specification R and a candidate program P , the pro-

jection of P over R is refined by the meet of P and R, i.e. R ⊓ P ⊒ ΠR (P ). In
addition, if P and R satisfy the consistency condition, then R ⊓ P = ΠR (P ).

Proof. By Proposition 6 R refines ΠR (P ). Using the proof of this proposition,

and since R and P play symmetric roles in the formula of the projection, we
infer that P also refines ΠR (P ). Hence ΠR (P ) is a lower bound of R and
P , whence it is refined by the greatest lower bound of R and P . We write:
R ⊓ P ⊒ ΠR (P ).

If R and P satisfy the consistency condition then (R ∩ P )L = RL ∩ P L; hence

the meet of R and P (RL ∩ P L ∩ (R ∪ P )) equals the projection of R over P
((R ∩ P )L ∩ (R ∪ P )). qed

4.2 Projection and Equivalent Correctness

The following propositions elucidate the relationship between the projection

of a program on a specification and its degree of relative correctness.

13
Proposition 7. Let R and P be relations on space S. Then the projection of
P over R is in the same equivalence class of ≡R as P .

Proof. We check that P and ΠR (P ) are equally correct.

P ≡R ΠR (P )
⇔ {Proposition 4}
(R ∩ P )L = (R ∩ (R ∩ P )L ∩ (R ∪ P ))L∧
(R ∩ P )L ∩ R ∩ P = (R ∩ (R ∩ P )L ∩ (R ∪ P ))L ∩ R ∩ (R ∩ P )L ∩ (R ∪ P )
⇔ {Relational identities Schmidt and Stroehlein (1990); Brink
et al. (1997)}
(R ∩ P )L = (R ∩ P )L ∧ (R ∩ P )L ∩ R ∩ P = (R ∩ P )L ∩ R ∩ P
which is a tautology. qed

Proposition 8. Let R and P be relations on space S. Then the projection of

P on R is the least refined element of the equivalence class of P modulo ≡R .

Proof. We let P ′ be an element in the equivalence class of P , and we show

that P ′ refines ΠR (P ).
P ′ ≡R P
⇔ {Proposition 4}
(R ∩ P )L = (R ∩ P ′ )L ∧ (R ∩ P )L ∩ R ∩ P = (R ∩ P ′ )L ∩ R ∩ P ′
⇒ {Boolean algebra}
(R ∩ P )L = (R ∩ P ′ )L ∧ (R ∩ P ′ )L ∩ R ∩ P ′ ⊆ P
⇔ {Shunting}
(R ∩ P )L = (R ∩ P ′ )L ∧ (R ∩ P ′ )L ∩ P ′ ⊆ R ∪ P
⇒ {P and P ′ have the same competence domain}
(R ∩ P )L ⊆ P ′ L ∧ (R ∩ P )L ∩ P ′ ⊆ (R ∩ P )L ∩ (R ∪ P )
⇔ {Substitution of ΠR (R), ΠR (P )L = (R ∩ P )L}
ΠR (P )L ⊆ P ′ L ∧ ΠR (P )L ∩ P ′ ⊆ ΠR (P )
⇔ {Definition of refinement}
P ⊒ ΠR (P ).
′
qed

Corollary 3. Let R be a specification on space S and P and P ′ be (candidate)

programs on S. Then P and P ′ are equally correct if and only if they have
the same projection on R.

Proof. Proof of Necessity. By Proposition 7, P and ΠR (P ) are in the same

equivalence class, and so are P ′ and ΠR (P ′ ). If P and P ′ are in the same
equivalence class, then (by symmetry and transitivity), so are ΠR (P ) and
ΠR (P ′ ). Then, by Proposition 8, ΠR (P ) ⊒ ΠR (P ′ ) and ΠR (P ′ ) ⊒ ΠR (P ). By
antisymmetry of refinement, we conclude ΠR (P ) = ΠR (P ′).

Proof of Sufficiency. If P and P ′ have the same projection, say π, then by

14
 R P P′
0 XXX -

:0 
:0
0HZH 0 0H
X
X
XX   ZHH
@H
 H
 X-
z
X Z H @H
1XXX :1
 1XHX Z H
-1 1 -
HH@ HH
:1
X
X HXX X
Z H H
XXX HH XXXHH H@ H
 z
X
- Z j
z
X
-

H@ j
H

X
2 XX :2
 2XHX HHZ 2 2HH HH

-
:2

X
X HXXX HZ 
@HH
XXX HH XXXH> HH
 z
X
-
~
Z
j
H
X
z
H  - H
j
H
@ -
X
3 XX :3
 3XHX 3 3H :
 3
X
X HXXXH 
HH* H H
@
H
 *

R
@
XXX HHXX H H
 z
X
- 
Xj
H
z
X
-

H
H
j
H
-
X
4 XX :4
 4XXXH H 4 4 4
X
X  
X HH   H
HH

XXX  XXXX
 j
H 

j
H
 z
X
- z
X
5 5 5 5 5 5
ΠR (P ) = ΠR (P ′ )
0 :0


  
1X
HX -

:1
HXXX
H
 XX
 HH X-
z
X
2X
HX H
:2
HXX H
HXX HH
HH XX-j
z
X
3X
HX X H:
 3
H XXHH
H

H XXXX
j
H
4X

XXXHH
z
- 4
 XXHH
XXX
j
H
z
5 5
Fig. 4. Equal Correctness of Non-Deterministic Programs: P ′ ≡R P .

Proposition 7, P ≡R π and P ′ ≡R π. By symmetry and transitivity, we infer

P ≡R P ′ . qed

Figure 4 shows an example of a specification R, two equally correct programs

with respect to R, P and P ′, and their common projection on R.

4.3 Projections and Relative Correctness

Because all the programs that are equally correct map to the same projec-
tion, one would expect that relative correctness is determined by considering
projections. This is confirmed by the following proposition.

Proposition 9. Let R, P and P ′ be relations on set S. Then P ′ is more-correct

than P with respect to R if and only if ΠR (P ′ ) refines ΠR (P ).

Proof. We proceed by equivalences:

ΠR (P ′ ) ⊒ ΠR (P )
⇔ {Formula of refinement}
ΠR (P )L ⊆ ΠR (P ′ )L ∧ ΠR (P )L ∩ ΠR (P ′ ) ⊆ ΠR (P )
⇔ {Substitutions, and ΠR (P )L = (R ∩ P )L}
(R∩P )L ⊆ (R∩P ′ )L∧(R∩P )L∩(R∩P ′ )L∩(R∪P ′ ) ⊆ (R∩P )L∩(R∪P )

15
⇔ {A ⊆ B ⇔ (A ∩ B = A)}
(R ∩ P )L ⊆ (R ∩ P ′ )L ∧ (R ∩ P )L ∩ (R ∪ P ′) ⊆ (R ∩ P )L ∩ (R ∪ P )
⇔ {(A ∩ B ⊆ A ∩ C) ⇔ (A ∩ B ⊆ C)}
(R ∩ P )L ⊆ (R ∩ P ′ )L ∧ (R ∩ P )L ∩ (R ∪ P ′) ⊆ R ∪ P
⇔ {Shunting, and Boolean algebra}
(R ∩ P )L ⊆ (R ∩ P ′ )L ∧ (R ∩ P )L ∩ P ′ ∩ R ⊆ P
⇔ {Substitution}
P ⊒R P .
′
qed

According to this proposition, the more-refined the projection of a program,

the more-correct the program. This begs the question: under what condition
is a candidate program absolutely correct? The answer is given below.

4.4 Projections and Absolute Correctness

Proposition 10. A program P is correct with respect to a specification R if

and only if the projection of P on R is R.

Proof. Proof of Sufficiency: Assume ΠR (P ) = R. Then by Proposition 6

P ⊒ ΠR (P ) = R.

Proof of Necessity: Assume P ⊒ R, i.e., RL ⊆ P L and RL ∩ P ⊆ R. We first

prove RL = (R ∩ P )L.

true
⇔ {Assumption}
RL ∩ P ⊆ R
⇔ {Boolean algebra}
RL ∩ P ⊆ R ∩ P
⇒ {Monotonicity of composition}
(RL ∩ P )L ⊆ (R ∩ P )L
⇔ {(QL ∩ R)L = QL ∩ RL}
RL ∩ P L ⊆ (R ∩ P )L
⇔ {Assumption RL ⊆ P L and Boolean algebra}
RL ⊆ (R ∩ P )L
⇔ {Boolean algebra, monotonicity of composition}
RL = (R ∩ P )L

And now the proof of ΠR (P ) = R.

ΠR (P )
= {Definition of ΠR }
(R ∩ P )L ∩ (R ∪ P )

16
 R, P arbitrary P partially correct wrt R P (totally) correct wrt R

R P R P P
• • • • •
A@
@
A@
@
A @
@
A @
@
A @•
@•
A R⊓P
R ⊓ P = ΠR (P )
A

A

A

A•
•
ΠR (P ) R = R ⊓ P = ΠR (P )

Fig. 5. The Meet (greatest lower bound) and the Projection

= {Previous proof}
RL ∩ (R ∪ P )
= {Boolean algebra and R ⊆ RL}
R ∪ RL ∩ P
= {Assumption RL ∩ P ⊆ R and Boolean algebra}
R

qed

Figure 5 captures the result of this Proposition, along with that of Corollary
2 in graphic form. The chart on the left shows the configuration of a specifi-
cation R and a candidate program P when they are unrelated; in that case,
according to Corollary 2, the meet of R and P refines the projection of P on
R. The chart in the middle shows the configuration of R and P when they
meet the consistency condition; for a deterministic program P , the consis-
tency condition means that P is partially correct with respect to R; in that
case, according to Corollary 2, the meet of R and P and the projection of P
over R are identical. The chart on the right represents the configuration of a
specification R and a program P where the program P is correct with respect
to the specification; in that case, according to Proposition 10, the projection
of P over R is equal to R, and according to the definition of refinement, the
meet of P and R is equal to R. In this figure, refinement is represented by
height (higher relations are more refined than lower relations).

To summarize, then: the projection of a program on a specification determines

the level of relative correctness of a program with respect to the specification;
all the programs that are equally correct have the same projection; a candidate
program is all the more-correct that its projection is more-refined; all projec-
tions are less-refined than or as refined as the specification; correct programs
are those whose projection is R.

We present herein a simple graphic interpretation of projection, which reflects

17
 66

R D

 
-
 6 E
 


Equivalence class,

modulo ≡R





ΠR (P )
P

Fig. 6. Projecting a Program on a Specification

all the properties listed above and justifies why we called it thus. Imagine a
horseboating arrangement whereby we want to pull a barge along a canal, and
to this effect we enlist a horse to walk on a path along the canal; let R be the
acceleration that we want to apply to the barge and let P be the acceleration
that the horse applies to the cable that connects it to the barge. Then P can
be decomposed into two components: the projection of P over the axis of the
canal, which represents the useful acceleration that will drive the barge; and
the orthogonal acceleration, which serves no purpose as far as accelerating
the barge, but is a byproduct of the horseboating design. We argue that the
projection of a program on a specification represents the same concept, namely
the functionality of P that is relevant to R (i.e. that contributes to meeting
requirements of R). See Figure 6; vector E represents the excess function of P
(i.e. functional features offered by P but irrelevant for the purpose of R) and
vector D represent the functional deficit of P (functionality that is required
by R but not fulfilled by P ). The oval in this figure represent programs that
are are equally correct, as they all have the same projection on R; the least
refined element of each oval is the projection (Proposition 8); farther elements
may be refinements of the projection, but they are not more-correct than the
projection.

4.5 Illustrative Example

We now consider some concrete (yet simple) programs and specifications and
discuss in what way the projection of a program on a specification is consistent
with the interpretation we make of it. We let S be the space defined by three
variables x, y and z of type integer, and we let R be the following relation/

18
specification on S:
{(s, s′)|x′ = x + y ∧ z < z ′ }.
We consider the following program on S,

{z=z+1; while (y!=0) {x=x+1; y=y-1;}};

The function of this program is:

P0 = {(s, s′)|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 1}.

The projection of P0 can be computed as follows:

(R ∩ P0 )L ∩ (R ∪ P0 )
= {substitution and simplification}
{(s, s )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 1} ◦ L
′

∩{(s, s′ )|x′ = x + y ∧ z < z ′ }

= {simplification}
{(s, s )|y ≥ 0 ∧ x′ = x + y ∧ z < z ′ }.
′

Indeed, program P0 works only when y ≥ 0, and when it does, it places x + y

in x and increases z; we know that P0 actually increments z by exactly 1, but
the projection of P0 on R keeps no record of that, as R only cares that z has
increased, and does not care by how much.

We consider another program on space S,

{z=z+1; while (y>0) {x=x+1; y=y-1;}};

The function of this program is:

P1 = {(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 1}∪

{(s, s′ )|y < 0 ∧ x′ = x ∧ y ′ = y ∧ z ′ = z + 1}.

The projection of P1 on R can be computed as follows:
(R ∩ P1 )L ∩ (R ∪ P1 )
= {substitution and simplification}
({(s, s )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 1}
′

∪{(s, s′ )|y < 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 1 ∧ x′ = x ∧ y ′ = y}) ◦ L

∩(R ∪ P1 )
= {y < 0 ∧ y ′ = 0 ∧ y ′ = y is a contradiction}
{(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 1} ◦ L
∩(R ∪ P1 )
= {computing the domain}
{(s, s )|y ≥ 0} ∩ (R ∪ P1 )
′

= {distribution, cancellation}

19
 {(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ z < z ′ }.

Interestingly, even though P1 refines P0 , P1 is not more-correct than P0 with

respect to R, since they have the same projection on R. In other words, P1
refines P0 in a way that is orthogonal to R, hence it does not enhance relative
correctness with respect to R. See Figure 7.

Next, we consider the following program:

{x=x+y; y=0; z=z+1;}

The function of this program is:

P2 = {(s, s′ )|x′ = x + y ∧ y ′ = y ∧ z ′ = z + 1}.

The projection of P2 on R is:

(R ∩ P2 )L ∩ (R ∪ P2 )
= {substitution and simplification}
{(s, s′ )|x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 1} ◦ L
∩{(s, s′ )|(x′ = x + y ∧ z < z ′ ) ∨ (x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 1}
= {simplification}
{(s, s′ )|x′ = x + y ∧ z < z ′ }
= {substitution}
R.

Since the projection of P2 on R is equal to R, we conclude that P2 is correct

with respect to R. See Figure 7. Note that P2 refines P0 , as does P1 ; but while
P2 is more-correct than P0 with respect to R, P1 is not. Intuitively, this is
because P2 refines P0 in the direction of R (so to speak), whereas P1 refines it
orthogonally to R; see Figure 7.

Next, we consider the following program:

{z=z+3; x=x+10; while (y!=10){y=y-1; x=x+1;}

The function of this program is:

P3 = {(s, s′)|y ≥ 10 ∧ x′ = x + y ∧ y ′ = 10 ∧ z ′ = z + 3}.

The projection of P3 on R is:

(R ∩ P3 )L ∩ (R ∪ P3 )
= {substitution and simplification}
{(s, s′ )|y ≥ 10 ∧ x′ = x + y ∧ y ′ = 10 ∧ z ′ = z + 3} ◦ L
∩{(s, s′ )|x′ = x + y ∧ z < z ′ }
= {simplification}

20
 R
=ΠR (P2 )
6
6

P2








ΠR (P0 )

=ΠR (P1 )


*

6  P1 P0












ΠR (P3 )
 :

6
  P3

 


 

 
ΠR (P4 )  

 - P4

Fig. 7. Projecting Candidate Programs on a Specification

{(s, s′ )|y ≥ 10 ∧ x′ = x + y ∧ z < z ′ }.

We find that the projection of P3 on R is less-refined than the projection of P0

and P1 on R, hence we conclude that P0 and P1 are both more-correct than
P3 with respect to R. See Figure 7.

Finally, we consider the following program:

{while (y!=0) {x=x+1; y=y-1;}}

The function of this program is:

P4 = {(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z}.

The projection of P4 on R is then:

(R ∩ P4 )L ∩ (R ∪ P4 )
= {substitution and simplification}
{(s, s )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z < z ′ ∧ z ′ = z} ◦ L
′

∩(R ∪ P4 )
= {the first term is empty, since z < z ′ ∧ z ′ = z is false}
φ.

Figure 7 gives a geometric representation of the five candidate programs P0 to

P4 , and serves to illustrate the definition of projection, as well as the property
that relative correctness can be judged by looking exclusively at the projec-
tions of candidate programs on the target specification.

21
Consider program P4 : even though it does some of what the specification
mandates, which is to add x and y into x, our calculations show its projection
to be the empty specification, hence P4 is as good as abort, as far as this
specification is concerned. This may sound counter-intuitive, but it is actually
consistent with the fact that our definition of relative correctness does not re-
flect how many clauses of the specification are satisfied; rather it reflects how
many initial states the program is handling correctly; and in this situation,
because the specification mandates to increase z and the program does not,
there is not a single initial state for which the program satisfies the specifica-
tion. It is possible to (re) define relative correctness in such a way as to reflect
the extent of requirements clauses that are satisfied rather than the extent of
the input domain for which the specification (as an indivisible monolith) is
satisfied; this matter is beyond the scope of this paper.

5 Implications and Applications

The purpose of this section is to summarily explore some implications and/or

applications of projections in software engineering; our only goal is to draw
attention to the fact that projections may be used to model several software
engineering processes. But first, we need to introduce a Proposition, which we
need in our subsequent discussions; this is the subject of section 5.1.

5.1 Refining a Projection

Proposition 9 provides that a program P ′ is more-correct than a program P

with respect to some specification R if and only if the projection of P ′ on
R refines the projection of P on R. But in practice, we find it convenient to
reason about relative correctness on the basis of a lower bound of P ′ , rather
than a lower bound of the projection of P ′ . The following Proposition provides
this lower bound.

Proposition 11. Given a specification R and two deterministic candidate

programs P and P ′ . Then P ′ ⊒R P if and only if P ′ ⊒ ΠR (P ).

Proof. Proof of Necessity. If P ′ is more-correct than P with respect to R then,

by Proposition 9, ΠR (P ′ ) refines ΠR (P ). On the other hand, by Proposition
8, P ′ refines ΠR (P ′). By transitivity, we infer that P ′ refines ΠR (P ).

Proof of Sufficiency. The proof uses the lemma proved in the proof of Prop.
5.1 in Desharnais et al. (2015):

Pb P ⊆ I ∧ Q ⊆ P ⇒ (R ∩ P )L ∩ Q = R ∩ Q. (1)

22
Shown first: if (R ∩ P )L ∩ P is deterministic and (R ∩ P )L ∩ R ∩ P ′ ⊆ P , then
(R ∩ P )L ∩ P ′ L = (R ∩ P )L ∩ (R ∩ P ′ )L.

(R ∩ P )L ∩ R ∩ P ′ ⊆ P
⇔ {taking the intersection with (R ∩ P )L}
(R ∩ P )L ∩ R ∩ P ′ ⊆ (R ∩ P )L ∩ P
⇒ {(R ∩ P )L ∩ P is deterministic and (1) with
P := (R ∩ P )L ∩ P and Q := (R ∩ P )L ∩ R ∩ P ′ }
(R ∩ (R ∩ P )L ∩ P )L ∩ (R ∩ P )L ∩ R ∩ P ′ = R ∩ (R ∩ P )L ∩ R ∩ P ′
⇔ {}
(R ∩ P )L ∩ R ∩ P ′ = φ
⇔ {taking the domain on both sides}
(R ∩ P )L ∩ (R ∩ P ′ )L = φ
⇒ {Identity}
((R ∩ P )L ∩ (R ∩ P ′ )L) ∪ ((R ∩ P )L ∩ (R ∩ P ′ )L) = (R ∩ P )L ∩ (R ∩ P ′)L
⇔ {Set theory}
(R ∩ P )L ∩ P L = (R ∩ P )L ∩ (R ∩ P ′ )L
′

And now the main proof.

P ′ ⊒ ΠR (P )
⇔ {substitution}
P ⊒ (R ∩ P )L ∩ (R ∪ P )
′

⇔ {definition of refinement}
(R ∩ P )L ⊆ P ′ L ∧ (R ∩ P )L ∩ P ′ ⊆ (R ∩ P )L ∩ (R ∪ P )
⇒ {taking the intersection with R, simplifying}
(R ∩ P )L ⊆ P ′ L ∧ (R ∩ P )L ∩ R ∩ P ′ ⊆ P
⇒ {Boolean algebra, P is deterministic
and result above}
(R ∩ P )L ⊆ (R ∩ P )L ∩ P ′ L ∧ (R ∩ P )L ∩ P ′ L = (R ∩ P )L ∩ (R ∩ P ′)L
⇒ {substitution}
(R ∩ P )L ⊆ (R ∩ P )L ∩ (R ∩ P ′ )L
⇔ {Boolean algebra}
(R ∩ P )L ⊆ (R ∩ P ′ )L qed

Hence in subsequent discussions, when we want a deterministic program P ′ to

be more-correct than a deterministic program P , we do not need to mandate
that the projection of P ′ refine the projection of P ; rather it suffices that P ′
refine the projection of P .

23
5.2 Program Merger

Given a specification R and two candidate programs P and P ′ , imagine that

each of P and P ′ delivers some (but not all) of the functionality mandated
by R, and we are interested to derive a program that delivers all of the func-
tionality of P and all of the functionality of P ′ ; we refer to this composite
program as the merger of P and P ′.

Definition 7. Given a specification R and two candidate programs P and P ′ ,

a merger of programs P and P ′ is a program P ′′ that is more-correct than P
and more-correct than P ′ with respect to R.

The first step in deriving the merger P ′′ of P and P ′ is to compute the specifi-
cation that P ′′ must satisfy. A naive approach would be to let the specification
of the merger be the join of P and P ′ . But this approach ought to be ruled
out for several reasons:

• The join of P and P ′ may not exist; we show an example below of such a
situation.
• When the join of P and P ′ does not exist, it is usually because of an in-
compatibility between the design of P and the design of P ′ ; it is never due
to an incompatibility between specification-relevant behaviors of P and P ′ .

A more interesting approach to the merger is to let the specification of the

merger be the join of the projections of P and P ′ over R; this approach has
the following advantages:

• According to Corollary 1, the projections of P and P ′ over R satisfy the

consistency condition, hence they necessarily admit a join.
• According to Proposition 6, the projections of P and P ′ over R are less-
refined than, respectively, P and P ′ . Less refined specifications are easier to
satisfy because they impose fewer/ weaker requirements.
• The projections of P and P ′ on R only capture requirements information
that is relevant to R, and exclude any information that may stem from
design decisions that have been taken in the derivation of P and P ′ .
• According to Proposition 11, if P ′′ refines the projections of P and P ′ on
R, then it is more-correct than P and P ′ .
• According to lattice theory, in order for P ′′ to refine the projections of P
and P ′ on R, it suffices that P ′′ refines their join.

We consider the following example: Let S be the space defined by variables x,

y and z of type integer, and let R be the following specification on S:

R = {(s, s′)|x′ = x + y ∧ z 6= z ′ }.

24
We let p and p′ be the following candidate programs on S:
p: {z=z+1; while (y!=0) {x=x+1; y=y-1;}},
p’: {z=z-1; while (y!=0) {y=y+1; x=x-1;}}.
The functions of p and p′ are, respectively:
P = {(s, s′)|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 1}
P ′ = {(s, s′ )|y ≤ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z − 1}
We compute the projections of P and P ′ on specification R. We find:
ΠR (P )
= {substitution}
{(s, s )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 1} ◦ L
′

∩(R ∪ P )
= {taking the domain}
{(s, s )|y ≥ 0} ∩ (R ∪ P )
′

= {since P ⊆ R}
{(s, s )|y ≥ 0} ∩ R
′

= {substitution}
{(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ z ′ 6= z}.
Likewise, we find:
ΠR (P ′ )
= {substitution}
{(s, s )|y ≤ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z − 1} ◦ L
′

∩(R ∪ P ′ )
= {taking the domain}
{(s, s )|y ≤ 0} ∩ (R ∪ P ′ )
′

= {since P ′ ⊆ R}
{(s, s′ )|y ≤ 0} ∩ R
= {substitution}
{(s, s )|y ≤ 0 ∧ x′ = x + y ∧ z ′ 6= z}.
′

We know, by Corollary 1 that these two projections satisfy the consistency

condition, hence we need not check it; we proceed directly with computing
their join. We compute in turn the three terms of the join:
ΠR (P ) ∩ ΠR (P ′) ◦ L
= {substitution, simplification}
{(s, s )|y > 0 ∧ x′ = x + y ∧ z ′ 6= z}.
′

The second term:

ΠR (P ′ ) ∩ ΠR (P ) ◦ L
= {substitution, simplification}
{(s, s′ )|y < 0 ∧ x′ = x + y ∧ z ′ 6= z}.
The third term:
ΠR (P ) ∩ ΠR (P ′)
{substitution, simplification}
{(s, s )|y = 0 ∧ x′ = x ∧ z ′ 6= z}.
′

To satisfy the union of these three terms, we write the following program:
{z=z+1;
//from P, contradicts P’, but compatible with projection of P’

25
 if (y>0) {while (y!=0) {x=x+1; y=y-1;}} // from P
else {while (y!=0) {y=y+1; x=x-1;}}} // from P’.
This program delivers all the functionality of P and all the functionality of
P ′ , and while it differs from P ′ in its effect on variable z, it is compatible with
the projection of P ′ over R, which is sufficient; it constitutes a merger of P
and P ′ , i.e. a program that is more-correct than P and more-correct than P ′
with respect to R.

Note that if we had tried to compute the join of P and P ′ (rather than their
projections on R), we would have failed: To check the consistency condition
between P and P ′ , we proceed as follows:
P L = {(s, s′ )|y ≥ 0}. P ′ L = {(s, s′)|y ≤ 0}.
Hence
P L ∩ P ′L = {(s, s′)|y = 0}.
On the other hand,
(P ∩ P ′ )L
= {substitution}
{(s, s )|y = 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ z ′ = z + 1 ∧ z ′ = z − 1} ◦ L
′

= {contradiction, simplification}
φ◦L
= {algebra}
φ.
Because this is different from P L ∩ P ′L, we conclude that P and P ′ have
no join. But we notice that the failure to satisfy the consistency condition
does not stem from requirements mandated by R; rather it stems from design
decisions taken in P and P ′ that turned out to be irreconcilable (whereas
program P satisfies specification z 6= z ′ by incrementing z, program P ′ satisfies
it by decrementing z). So that by trying to take the join of P and P ′ , we are
trying to combine, not only specification-relevant features of P and P ′ , but
also design-based features that stem from arbitrary design decisions taken in
the process of deriving P and P ′ . Such design decisions are not only irrelevant
for our purposes, they also run the risk of creating inconsistencies between P
and P ′ that preclude us from taking their join.

We summarize:

The merger of two candidate programs P and P ′ for specification R

is a program that is more-correct than P and more-correct than P ′
with respect to R. Its specification is obtained by taking the join of
ΠR (P ) and ΠR (P ′ ).

26
5.3 Program Upgrade

Let R be a specification on space S and let P be a candidate program for R.

Let Q be the specification of a feature that we want to add to program P .

Definition 8. Given a specification R, a candidate program P and a feature

specification Q. An upgrade of program P by feature Q is a program, say P ′
that is correct with respect to Q and more-correct than P with respect to R.

Typically, R is a massive / complex specification (e.g. the specification of an

enterprise data processing application) and Q is a small feature that we want to
add to P (e.g. a new report format); the upgrade of P by Q consists in fulfilling
requirements Q without degrading the relative correctness of P with respect to
R. According to Proposition 11, P ′ is more-correct than P with respect to R if
and only if P ′ refines the projection of P over R. According to lattice theory,
program P ′ refines Q and ΠR (P ) if and only if it refines their join. On the other
hand, the join of Q and ΠR (P ) exists if and only if Q and ΠR (P ) satisfy the
consistency condition. If they do not satisfy the consistency condition, then
no program can satisfy requirement Q while preserving (relative) correctness
with respect to R; in other words, any attempt to make P correct with respect
to Q will necessarily make it less-correct with respect to R. We summarize
this as follows:

Given a specification R and a candidate program P , and given a

specification Q of a feature we wish to add to P . If Q and ΠR (P )
satisfy the consistency condition, then there exists a program P ′ that
satisfies specification Q while being more-correct than (or as-correct-
as) P . If Q and ΠR (P ) do not satisfy the consistency condition, then it
is impossible to satisfy specification Q while preserving or enhancing
the relative correctness of P .

Note that if R and Q satisfy the consistency condition, then so do ΠR (P ) and

Q, since R refines ΠR (P ) for any P . Note also that Q and ΠR (P ) may satisfy
the consistency condition while P and Q do not, as we show in the illustrative
example below.

We consider space S defined by two variables x and y of type integer and

specification R defined as follows:

R = {(s, s′ )|x′ = x + y}.

We let P be the following program on space S:

{while (y!=0) {y=y-1; x=x+1;}}.

27
Note that program P is not correct with respect to R, since it fails to compute
the sum of x and y into x for negative y. We now consider the specification Q
defined by:
Q = {(s, s′ )|y > y ′}.
We want to upgrade program P to satisfy specification Q without making P
less-correct with respect to R in the process. To check whether this is possible,
we need to check whether Q and ΠR (P ) satisfy the consistency condition. To
this effect, it is sufficient, though not necessary, to prove that Q and R satisfy
the consistency condition, which we can easily see, since RL, QL and (R∩Q)L
are all equal to L.

We now compute the ΠR (P ), then the join of ΠR (P ) with Q.

ΠR (P )
= {definition}
{(s, s )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0} ◦ L
′

∩(R ∪ P )
= {taking the domain in the first term, simplifying the second}
{(s, s )|y ≥ 0 ∧ x′ = x + y}.
′

To check the consistency condition between Q and ΠR (P ), we compute the

intersection of their domains, then the domain of their intersection.
QL = L.
ΠR (P ) ◦ L = {(s, s′ )|y ≥ 0}.
(Q ∩ ΠR (P )) ◦ L = {(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ y > y ′} ◦ L = {(s, s′)|y ≥ 0}.
The consistency condition is satisfied, hence we now compute the join of Q
and ΠR (P ), and we find, for the first term:
QL ∩ ΠR (P ) = L ∩ ΠR (P ) = φ.
The second term:
ΠR (P )L ∩ Q = {(s, s′)|y ≥ 0} ∩ Q = {(s, s′)|y < 0 ∧ y > y ′ }.
The third term:
Q ∩ ΠR (P ) = {(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ y > y ′}.
The join can then be written as:

Q ⊔ ΠR (P ) = {(s, s′ )|y < 0 ∧ y > y ′ } ∪ {(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ y > y ′}.

The following program, say P ′ , satisfies this specification:

{if (y<=0) {y=y-1;}
else {while (y!=0) {y=y-1; x=x+1;}}}
Note that this program is not correct with respect to R, but neither is P ; It is,
however correct with respect to Q, and it is more-correct (though not strictly
more-correct) than P with respect to R. Note however that this program does
not duplicate the behaviour of P : for y = 0, program P preserves x and y
whereas program P ′ preserves x but decrements y (as mandated by Q).

Note that while Q and ΠR (P ) do satisfy the consistency condition, Q and P

do not, as we see below:

28
 QL = L.
P L = {(s, s′ )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0} ◦ L = {(s, s′ )|y ≥ 0}.
Hence QL ∩ P L = {(s, s′ )|y ≥ 0}. On the other hand,
(Q ∩ P )L
= {substitution}
{(s, s )|y ≥ 0 ∧ x′ = x + y ∧ y ′ = 0 ∧ y > y ′} ◦ L
′

= {simplifying, taking the domain}

{(s, s )|y > 0}.
′

Since QL ∩ P L is not identical to (Q ∩ P )L, specifications Q and P do not

satisfy the consistency condition, hence they admit no join. In other words,
it is impossible to satisfy specification Q while preserving the function of P ;
what we did above is to satisfy Q while preserving the projection of P over R
(so as to preserve the relative correctness of P with respect to R).

5.4 Program Documentation

Documentation is an important aspect of software engineering practice; pro-

fessional standards of software engineering dictate that one must document
software products by commenting on design features and/ or by providing
information about the programmer’s intent; traditionally, this has meant doc-
umenting the function of the program. The trouble with documenting the
function of the program is that typically, the function of the program reflects
two separate sources of information: the requirements that stem from the spec-
ification; and the functional features that stem from the design of the product.
We argue that it is important to distinguish between these, which the projec-
tion does, since it captures only the former. We illustrate this contrast by a
very simple example: consider a space S defined by a single integer variable
x, and consider the specification

R = {(x, x′ )|x < x′ }.

Let P be a candidate program (i.e. a program written to satisfy R) that raises

x to power 2. We give below the function of P , and the projection of P over
R:

• P = {(x, x′ )|x′ = x2 }.
• ΠR (P )
= {definition}
(R ∩ P )L ∩ (R ∪ P )
= {substitution}
{(x, x′ )|∃x′ : x < x′ ∧ x′ = x2 } ∩ (R ∪ P )
= {simplification}
{(x, x′ )|x < 0 ∨ x > 1} ∩ {(x, x′ )|x < x′ ∨ x′ = x2 }

29
 = {since (x < 0 ∨ x > 1) ⇒ x < x2 }
{(x, x′ )|(x < 0 ∨ x > 1) ∧ x < x′ }.

The question we discuss is: what is an appropriate comment for program P ?

• We could comment the program with the program function P : x=x*x; //

x’=x*x. But this comment reflects not only the specification that the pro-
gram is intended to satisfy, but also the design decisions that the program-
mer took in order to satisfy the specification. Yet in practice, we may want
to distinguish between these two aspects: in the context of corrective mainte-
nance, for example, it is important to distinguish between what stems from
the specification (which must, therefore, be preserved) and what stems from
the design (which may be modified if that is needed to remove the fault).
• We could, alternatively, comment the program with the specification R that
the program is intended to satisfy: x=x*x; // x<x’. The trouble with this
comment is that it does not hold, actually, since the program does not
increase x for x between 0 and 1.
• The third alternative is to comment this program with the projection of
P over R: x=x*x; // (x<0 || x>1) ==> x<x’. This comment captures
the essence of what program P does to satisfy specification R; it captures
neither the functional deficit of P (the fact that P does not satisfy R for x
between 0 and 1) nor the functional excess of P (the fact that P satisfies R
by raising x to power 2).

In light of this discussion, we argue that while documenting the projection of a

program on a specification is not necessarily always the best way to comment
on a piece of code, it is nevertheless a competitive option. Indeed, commenting
on a software product by means of its function may be unnecessary (i.e. provide
more information than needed) whereas commenting on it by means of its
target specification may be insufficient (i.e. recording what a program must
do, rather than what it actually does). We summarize our finding as follows:

When we comment on a program by documenting its projection on

the target specification, we capture all the functionality that the pro-
gram delivers to satisfy the specification, and nothing else (i.e. no
functionality that is not mandated by the specification, and no man-
dated functionality that is not delivered by the program).

30
6 Conclusion

6.1 Summary

Given a specification R and a candidate program P , it is very common for

program P to feature functional properties that are not mandated by the
specification, even while falling short of fulfilling the functional properties
that the specification does mandate. In this paper, we introduce a relational
operator that captures the functional properties of a candidate program that
are directly relevant to the requirements of the specification, and we analyze its
properties and its applications. We refer to this operator as the projection of
program P on specification R, and we liken it to a horseboating arrangement
whereby a horse pulls a barge along a canal by walking on a path that runs
alongside the canal; the acceleration applied by the horse to the cable that
connects it to the barge is composed of two vectors: The projection of the
acceleration on the axis of the canal, which is the useful acceleration; and the
orthogonal acceleration which serves no useful purpose but is a byproduct of
the system’s design. Among the most salient properties we have found for this
operator, we cite:

• The projection is idempotent.

• All the candidate programs that are equally correct with respect to specifica-
tion R have the same projection on R; the projection of P on R is as-correct
as P ; and the projection is the least refined element of its equivalence class.
• A candidate program is all the more-correct with respect to R that its
projection on R is more-refined.
• All the projections of candidate programs on specification R form a lattice,
in which abort is the minimal element and R is the maximal element.
• Candidate Programs whose projection on R is R are correct with respect
to R.

We tentatively analyze possible applications of program projections, and we

find the following:

• Documentation. In general, when we analyze the functional attributes of

a program, we are looking at two sources of information: information that
stems from the specification; and information that stems from design de-
cisions that were taken in the process of deriving the program from its
specification. To the extent that the projection of the program captures the
former information and abstracts away the latter, we feel that it may be
useful to document programs by describing its projection.
• Program Merger. When we want to merge two candidate programs so as to
cumulate their functional attributes, it is sensible not to try to combine all

31
 the functional attributes of each, but rather to combine the projections of
the programs on the specification. By focusing on projections rather than on
the original program, we ensure that we only deal with relevant information
(i.e. information that pertains to the specification, rather than information
that stems from design decisions), we ensure that we deal with minimal
specifications (that are easier to solve), and we ensure that the programs
can be combined (the join of the projections is defined).
• Program Upgrade. Given a specification R and a candidate program P , and
given a new feature Q, we model the upgrade of P by Q as the problem
of producing a program that is correct with respect to Q and more-correct
than P with respect to R. We find that the upgrade can be obtained by
refining the join of Q with the projection of P on R; we also find that if the
join does not exist, then the upgrade is not possible without degrading the
relative correctness of P with respect to R.

6.2 Related Work

Other researchers have introduced a concept of relative correctness, though

none, to the best of our knowledge, have talked about program projections.

In Logozzo et al. (2014) Logozzo et al. introduce a technique for extracting

and maintaining semantic information across program versions. The focus of
their analysis is the condition under which programs P and P ′ can execute
without causing an abort. They implement their approach in a system called
VMV (Verification Modulo Versions) whose goal is to exploit semantic infor-
mation about P in the analysis of P ′, and to ensure that the transition from P
to P ′ happens without regression; in that case, they say that P ′ is correct rela-
tive to P . The definition of relative correctness of Logozzo et al Logozzo et al.
(2014) is different from ours, for several reasons: whereas Logozzo et al. (2014)
talk about relative correctness between an original program and a subsequent
version in the context of adaptive maintenance, we talk about relative correct-
ness between an original (faulty) software product and a revised version of the
program (possibly still faulty yet more-correct) in the context of corrective
maintenance with respect to a fixed requirements specification; whereas Lo-
gozzo et al. (2014) use a set of assertions inserted throughout the program as a
specification, we use a relation that maps initial states to final states; whereas
Logozzo et al. (2014) represent program executions by execution traces, we
represent program executions by functions mapping initial states into final
states; finally, whereas Logozzo et al define a successful execution as a trace
that satisfies all the relevant assertions, we define it as an initial state/ final
state pair that satisfies the relational specification.

In Lahiri et al. (2013) Lahiri et al. introduce a technique called Differential

32
Assertion Checking for verifying the relative correctness of a program with
respect to a previous version of the program. Lahiri et al. explore applications
of this technique as a tradeoff between soundness (which they concede) and
lower costs (which they hope to achieve). Also, they define relative correctness
between programs P and P ′ as the property that P ′ has a larger set of success-
ful traces and a smallest set of unsuccessful traces than P ; and they introduce
relative specifications as specifications that capture functionality of P ′ that P
does not have. By contrast, we use input/ output (or initil state/ final state)
relations as specifications, we represent program executions by functions from
initial states to final states, we characterize correct executions by initial state/
final state pairs that belong to the specification, and we make no distinction
between abort-freedom (a.k.a. safety, in Lahiri et al. (2013)) and normal func-
tional properties. Another important distinction with Lahiri et al. (2013) is
that we do not view relative correctness as a compromise that we accept as
a substitute for absolute correctness; rather we argue that in many cases, we
ought to test programs for relative correctness rather than absolute correct-
ness, regardless of cost. In other words, whereas Lahiri et al. argue in favor of
relative correctness on the grounds that it optimizes a quality vs. cost ratio,
we argue in favor on the grounds that it optimizes quality.

In Logozzo and Ball (2012), Logozzo and Ball introduce a definition of relative
correctness whereby a program P ′ is correct relative to P (an improvement
over P ) if and only if P ′ has more good traces and fewer bad traces than P .
Programs are modeled with trace semantics, and execution traces are com-
pared in terms of executable assertions inserted into P and P ′; in order for
the comparison to make sense, programs P and P ′ have to have the same
(or similar) structure and/or there must be a mapping from traces of P to
traces of P ′ . When P ′ is obtained from P by a transformation, and when P ′
is provably correct relative to P , the transformation in question is called a
verified repair. Like the work cited above (Logozzo et al. (2014); Lahiri et al.
(2013)), Logozzo and Ball model programs by execution traces and distinguish
between two types of failures: contract violations, when functional properties
are not satisfied; and run-time errors, when the execution causes an abort; for
the reasons we discuss above, we do not make this distinction, and model the
two aspects with the same relational framework.

References

Boudriga, N., Elloumi, F., Mili, A., 1992. The lattice of specifications: Ap-
plications to a specification methodology. Formal Aspects of Computing 4,
544–571.
Brink, C., Kahl, W., Schmidt, G., January 1997. Relational Methods in Com-
puter Science. Springer Verlag.

33
Desharnais, J., Diallo, N., Ghardallou, W., Frias, M., Jaoua, A., Mili, A.,
September 2015. Mathematics for relative correctness. In: Relational and
Algebraic Methods in Computer Science, 2015. Lisbon, Portugal.
Dijkstra, E., 1976. A Discipline of Programming. Prentice Hall.
Gries, D., 1981. The Science of programming. Springer Verlag.
Hehner, E., 1992. A Practical Theory of Programming. Prentice Hall.
Hoare, C., Oct. 1969. An axiomatic basis for computer programming. Com-
munications of the ACM 12 (10), 576 – 583.
Lahiri, S. K., McMillan, K. L., Sharma, R., Hawblitzel, C., 2013. Differential
assertion checking. In: Proceedings, ESEC/ SIGSOFT FSE. pp. 345–455.
Logozzo, F., Ball, T., 2012. Modular and verified automatic program repair.
In: Proceedings, OOPSLA. pp. 133–146.
Logozzo, F., Lahiri, S., Faehndrich, M., Blackshear, S., 2014. Verification mod-
ulo versions: Towards usable verification. In: Proceedings, PLDI. p. 32.
Manna, Z., 1974. A Mathematical Theory of Computation. McGraw Hill.
Mills, H., Basili, V., Gannon, J., Hamlet, D., 1986. Structured Programming:
A Mathematical Approach. Allyn and Bacon, Boston, Ma.
Schmidt, G., Stroehlein, T., 1990. Relationen und Graphen. Springer-Verlag,
Berlin, Germany.

34