Notes on Propositional logic

Models in Software Development(CISC836)

Introductions to Formal Logic andObject Modeling with Alloy and

UML/OCL

Winter 2013

c©Juergen Dingel

Queen’s University

January 2013

Draft — Do not distribute!

2

Contents

I Propositional and Predicate Logic: A Review 1

1 Propositional logic 31.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Satisfiability, validity, entailment, and counter examples . 61.2.2 New connectives as abbreviations . . . . . . . . . . . . . . 61.2.3 De Morgan laws . . . . . . . . . . . . . . . . . . . . . . . 81.2.4 Necessary and sufficient conditions . . . . . . . . . . . . . 9

1.3 Proof theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.1 Sequents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.2 Proof rules . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.3 Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.4 Constructing proofs . . . . . . . . . . . . . . . . . . . . . 131.3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.3.6 Remarks about proof rules . . . . . . . . . . . . . . . . . 171.3.7 Proof techniques I . . . . . . . . . . . . . . . . . . . . . . 18

1.4 Soundness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.5 Completeness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.6 Decidability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2 Predicate logic with equality 292.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.1.1 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.1.2 Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.1.3 Free and bound variables . . . . . . . . . . . . . . . . . . 312.1.4 Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.2.2 Using the semantics to evaluate a formula in a model . . 342.2.3 Satisfiability, validity, and entailment . . . . . . . . . . . . 362.2.4 Existential quantification . . . . . . . . . . . . . . . . . . 36

2.3 Proof theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.3.1 Universal quantification . . . . . . . . . . . . . . . . . . . 39

3

4 CONTENTS

2.3.2 Existential quantification . . . . . . . . . . . . . . . . . . 402.3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.3.4 Proof techniques II . . . . . . . . . . . . . . . . . . . . . . 432.3.5 Bounded quantification . . . . . . . . . . . . . . . . . . . 45

2.4 Soundness, completeness and decidability . . . . . . . . . . . . . 46

3 Theorem provers, SAT solvers, and proof checkers 47

4 Bibliographic notes 49

II Object Modeling with Alloy and UML/OCL 514.1 Object modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2 State diagrams and object models . . . . . . . . . . . . . . . . . 53

4.2.1 State diagrams . . . . . . . . . . . . . . . . . . . . . . . . 534.2.2 Object models . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3 Object model design and analysis using Alloy . . . . . . . . . . . 574.3.1 Example: Graphs, trees, and lists . . . . . . . . . . . . . . 574.3.2 Summary of Alloy language . . . . . . . . . . . . . . . . . 744.3.3 Using Alloy to specify operations and traces . . . . . . . . 784.3.4 Example: A simple file system . . . . . . . . . . . . . . . 784.3.5 Example: Family tree . . . . . . . . . . . . . . . . . . . . 864.3.6 Example: Air traffic control . . . . . . . . . . . . . . . . . 864.3.7 Example: Java . . . . . . . . . . . . . . . . . . . . . . . . 884.3.8 Analyzing Alloy object models . . . . . . . . . . . . . . . 904.3.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

4.4 Object model design and analysis using UML and OCL . . . . . 954.4.1 Background on UML . . . . . . . . . . . . . . . . . . . . . 954.4.2 Object modeling in UML . . . . . . . . . . . . . . . . . . 954.4.3 The Object Constraint Language . . . . . . . . . . . . . . 964.4.4 Representing and analyzing UML/OCL object models us-

ing USE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

5 Bibliographic notes and acknowledgments 113

List of Figures

1.1 Deciding the validity problem . . . . . . . . . . . . . . . . . . . . 251.2 Relationships between most common complexity classes . . . . . 261.3 Natural deduction rules for propositional logic . . . . . . . . . . . 281.4 Some derived rules for propositional logic . . . . . . . . . . . . . 28

4.1 Alloy model used as running example . . . . . . . . . . . . . . . 694.2 Textual constraints of a stack . . . . . . . . . . . . . . . . . . . . 794.3 Graphical constraints of a simple file system in Alloy [Jac06] . . 844.4 Textual constraints of a simple file system in Alloy [Jac06] . . . . 874.5 Graphical constraints for family tree in Alloy . . . . . . . . . . . 884.6 Textual constraints for family tree in Alloy . . . . . . . . . . . . 894.7 Validity versus satisfiability . . . . . . . . . . . . . . . . . . . . . 914.8 Design and analysis of object models using Alloy . . . . . . . . . 944.9 Graphical constraints for family tree in UML . . . . . . . . . . . 964.10 UML object model of the Royal and Loyal customer loyalty system 984.11 Textual constraints for family tree in OCL . . . . . . . . . . . . . 108

5

6 LIST OF FIGURES

Part I

Propositional and PredicateLogic: A Review

1

Chapter 1

Propositional logic

Our presentation of propositional logic is standard. Sections 1.1 and 1.3 definea syntactic domain while Section 1.2 defines a semantic domain. Sections 1.4and 1.5 connect the two domains by establishing soundness and completeness.Finally, Section 1.6 discusses the complexity of propositional logic and to whatextent it can be implemented.

1.1 Syntax

1.1.1 Formulas

We begin by defining the formulas we can legally write. A declarative statementis either true or false. For instance, “Tom hates logic”, and “The number 6 isprime” are declarative statements. “Go Steelers!”, “Could you please take thegarbage out?”, or “May the force be with you” are not declarative. An atomicproposition p is a declarative statement that cannot be decomposed such asdoor is open, ac on, temperature high, but also x > 0 and x = 13. Formulasare declarative statements that are built from a given set of atomic propositionsAP and the two connectives ¬ and ∧. The grammar in Backus-Naur form(BNF) for a formula ϕ is:

ϕ ::= p | an atomic proposition is a formula(¬ ϕ) | the negation of a formula is an formula(ϕ ∧ ϕ) the conjunction of two formulas is a formula(ϕ) a formula in matching parentheses is a formula

where p ∈ AP. Suppose, for instance, that the set of atomic propositionscontains ac on, temperature high; then the above grammar allows the formationof the following formulas: ac on, ¬ ac on, (ac on ∧ temperature high), etc.Note that this definition is inductive (recursive) with one base case and threeinductive cases.

3

4 CHAPTER 1. PROPOSITIONAL LOGIC

To save parentheses, the connectives are assigned the following binding pri-orities:

¬ negation binds most tightly∧ conjunction binds least tightly

Thus, for instance, ¬ p ∧ q is equivalent to ((¬ p) ∧ q).

1.2 Semantics

What does a formula ϕ mean? To answer this question, we present a seman-tic model. More precisely, we fix a semantic domain B = {true, false} withtwo elements: true to represent semantic truth and false to represent semanticfalsehood. Then, we show how the meaning of a formula can be obtained byevaluating it to one of the values in B. Before we can do that, though, we needto determine what our two connectives ¬ and ∧ and atomic propositions mean.

The meaning of the connectives is given by the following truth tables

ϕ ¬ ϕtrue falsefalse true

ϕ ψ ϕ ∧ ψtrue true truetrue false falsefalse true falsefalse false false

This table tells us, for instance, that whenever the meaning of a formula ϕ istrue, then the meaning of ¬ ϕ is false, whereas the meaning of ϕ ∧ ϕ is true.

What, however, does an atomic proposition such as p mean? How is it tobe evaluated? The answer is: It depends, p can evaluate to true or false, andwe need additional information to tell us to which. Given a formula ϕ, a modelfor ϕ, sometimes also called a truth assignment or valuation, is a mapping

l : AP → B

where AP is the set of atomic propositions in ϕ.

Exercise 1.2.1 How many models does a formula have?

Given a model l for ϕ, we are now fully equipped to precisely define how toevaluate ϕ with respect to l . There are two equivalent ways to describe thisevaluation: one using a satisfaction relation, and one using an evaluation func-tion. Both notions are defined inductively over the structure of the formulaϕ.

1. Satisfaction relation |=The so-called satisfaction relation |= describes when a formula holds in amodel. Formally, |= is a binary relation between models (that is, elementsin AP → B) and formulas. More precisely, let l be a model of ϕ. ϕ holdsin l if and only if l |= ϕ, which is short for (l , ϕ) ∈ |=. If ϕ does nothold in l , that is, (l , ϕ) �∈ |=, we write l �|= ϕ. The relation |= is defined

1.2. SEMANTICS 5

inductively over the structure of ϕ using the truth table definition of theconnectives. More precisely, |= is a binary relation between models l andformulas ϕ such that

l |= p iff l(p) = truel |= ¬ ϕ iff l �|= ϕl |= ϕ ∧ ψ iff l |= ϕ and l |= ψ.

For instance, the mapping l defined by

l(p) = true

l(q) = false

l(r) = true

is a model for the formula ¬ (p ∧ q) ∧ (r ∧ p). l makes this formulatrue, that is, we have l |= ¬ (p ∧ q) ∧ (r ∧ p). This is because l makes¬ (p ∧ q) true (we have l |= ¬ (p ∧ q)) and r ∧ p true (we have l |= r ∧ p).Similarly, l is also a model for ((p ∧ ¬ q) ∧ r). However, ((p ∧ q) ∧ r)does not hold in l , that is, we have l �|= ((p ∧ q) ∧ r).

2. Evaluation function evalAn alternative, but equivalent account of the semantics of a formula isobtained by using an evaluation function that maps every formula to atruth value. Given a truth assignment l , the meaning evall (ϕ) of a formulaϕ is defined inductively by

evall(p) = l(p)

evall(¬ ϕ) = eval¬ (evall(ϕ))

evall(ϕ ∧ ψ) = eval∧(evall (ϕ), evall(ψ))

where eval¬ and eval∧ represent two functions implementing the truthtables for negation and conjunction respectively. That is, eval¬ is definedby

eval¬ (true) = false

eval¬ (false) = true

and eval∧ is defined by

eval∧(x , y) =

{true, if x = y = truefalse, otherwise

Using the truth assignment l defined above, we thus get

evall(¬ (p ∧ q) ∧ (r ∧ p)

)= true

evall ((p ∧ q) ∧ r) = false

The connection between the two definitions is that for all truth assignments l ,we have l |= ϕ if and only if evall(ϕ) = true.

Exercise 1.2.2 Prove that l |= ϕ if and only if evall(ϕ) = true. Hint: Useinduction over the structure of ϕ.


1.2.1 Satisfiability, validity, entailment, and counter ex-amples

Given a formula ϕ, every truth assignment l that makes ϕ true (that is, we havel |= ϕ or evall(ϕ) = true) is called a satisfying assignment of ϕ. For instance,the formula ((p ∧ q) ∧ ¬ r) has the satisfying assignment l defined as

l(p) = true

l(q) = true

l(r) = false

For the formula ¬ (p ∧ ¬ p) every truth assignment is a satisfying assignment.The formula p ∧ ¬ p has no satisfying assignments. A formula ϕ is calledsatisfiable if it has a satisfying assignment. For instance, p and ¬ (p ∧ ¬ p) aresatisfiable. A formula is called unsatisfiable if it is not satisfiable. For instance,p ∧ ¬ p is unsatisfiable.

While satisfiability expresses the truth of a formula in one particular model,validity says that a formula is true in all its models. A formula ϕ is called valid,|= ϕ for short, if ϕ evaluates to true under all truth assignments, that is, l |= ϕfor all l . For instance, out of the formulas p, p ∧ ¬ p and ¬ (p ∧ ¬ p) only¬ (p ∧ ¬ p) is valid. Note that ϕ is valid if and only if ¬ ϕ is not satisfiable.Valid formulas are sometimes also called tautologies.

Remember that the symbol “�” expresses derivability and is thus a syntacticnotion. Now that we have a semantic model, we can complement it with asemantic notion called entailment. More precisely, the notation

ϕ1, ϕ2, . . . , ϕn |= ψ

expresses that whenever all premises ϕi evaluate to true for all 1 ≤ i ≤ n, thenψ will, too. More precisely, for all truth assignments l , whenever l |= ϕi holdsfor all 1 ≤ i ≤ n (or, equivalently, evall (ϕi) = true for all 1 ≤ i ≤ n) then l |= ψholds as well (or, evall (ϕ) = true).

Conversely, we say that ϕ1, ϕ2, . . . , ϕn does not entail ψ,

ϕ1, ϕ2, . . . , ϕn �|= ψ

if there exists a truth assignment l such that l |= ϕi holds for all 1 ≤ i ≤ n, butl �|= ψi . In this case, l is said to be a counter example for the sequent.

1.2.2 New connectives as abbreviations

The attentive reader might be missing other standard connectives like disjunc-tion or implication. It turns out that these and other connectives can be ob-tained through the following abbreviations.

1.2. SEMANTICS 7

ffdef= ϕ ∧ ¬ ϕ falsehood, contradiction

ϕ ∨ ψdef= ¬ (¬ ϕ ∧ ¬ ψ) disjunction

ttdef= ϕ ∨ ¬ ϕ truth

ϕ→ ψdef= ¬ ϕ ∨ ψ implication

ϕ↔ ψdef= (ϕ→ ψ) ∧ (ψ → ϕ) equivalence

Note that tt and ff are syntactic symbols, whereas true and false are semantic.From the above definitions we can read off the truth table definitions of the newconnectives.

ϕ ψ ϕ ∨ ψtrue true truetrue false truefalse true truefalse false false

ϕ ψ ϕ→ ψtrue true truetrue false falsefalse true truefalse false true

ϕ ψ ϕ↔ ψtrue true truetrue false falsefalse true falsefalse false true

The binding priorities of the new connectives are:

¬ binds most tightly∧,∨ bind tighter than →, but less than ¬→ binds tighter than ↔, but less than ∧ and ∨↔ binds least tightly

For instance, ¬ p ∨ q → p ↔ q stands for (((¬ p) ∨ q) → p) ↔ q.When determining the value of a formula ϕ containing new connectives, we

now have a choice:

• In a preprocessing step, we replace every subformula in ϕ that containsa new connective by the subformula it abbreviates. For instance, if ϕ isp → (p ∨ q) we obtain

p → (p ∨ q) = ¬ p ∨ (p ∨ q)

= ¬ (¬ ¬ p ∧ ¬ (p ∨ q))

= ¬ (¬ ¬ p ∧ ¬ ¬ (¬ p ∧ ¬ q))

The resulting ϕ′ formula only contains atomic propositions, negation, andconjunction and thus the evaluation function or the satisfaction relationpresented on page 4 can be used to determine the value of ϕ′.

• Alternatively, we augment the definition of the evaluation function and thesatisfaction relation to handle the new connectives directly. For instance,the value of a disjunction ϕ ∨ ψ is false if both subformulas evaluate tofalse. Otherwise, it is true. More formally,

evall(ϕ ∨ ψ) = eval∨(evall (ϕ), evall(ψ))


where eval∨ is defined as

eval∨(v1, v2) =

{false, if v1 = v2 = false,true, otherwise.

Exercise 1.2.3 Augment the definitions of the satisfaction relation l |= andthe evaluation function such that they can handle formulas containing tt, ff , ∨,→, or ↔ directly.

1.2.3 De Morgan laws

Sometimes, the connectives ∨ and → are defined directly rather than in termsof ¬ and ∧. The above definitions then arise as equivalences in the context ofthe De Morgan laws. Here are some of them:

¬ (¬ ϕ) ↔ ϕ

¬ (ϕ ∨ ψ) ↔ ¬ ϕ ∧ ¬ ψ

¬ (ϕ ∧ ψ) ↔ ¬ ϕ ∨ ¬ ψ

ϕ→ ψ ↔ ¬ ϕ ∨ ψ

ϕ1 ∧ (ϕ2 ∨ ϕ3) ↔ (ϕ1 ∧ ϕ2) ∨ (ϕ1 ∧ ϕ3)

ϕ1 ∨ (ϕ2 ∧ ϕ3) ↔ (ϕ1 ∨ ϕ2) ∧ (ϕ1 ∨ ϕ3)

Adequate connectives

A set of connectives is called adequate for a logic, if for every formula in thatlogic there exists an equivalent formula with only connectives from that set.When we defined the syntax and semantics we made use of the fact that the setof connectives {¬ ,∧} is adequate for propositional logic. Other adequate setsare {¬ ,∨}, {¬ ,→}, and {→,ff }. In general, if C ⊆ {¬ ,∧,∨,→,ff } and C isadequate, then ¬ ∈ C or ff ∈ C . What are the advantages and disadvantages ofdefining a logic using a set of adequate connectives and obtaining the remainingconnectives as abbreviations? Advantages include:

• The relationship between the connectives is revealed.

• The BNF is shorter. Consequently, proofs over the structure of a formulaare shorter, because there are fewer cases to consider.

• The definition of eval is shorter. Consequently, the implementation offormula evaluation is easier.

Disadvantages include:

• The intuitive meaning of a connective may be obscured. For instance,abbreviating ¬ ϕ ∨ ψ by ϕ → ψ may be surprising and counterintuitiveat first.

1.3. PROOF THEORY 9

• The evaluation of a formula requires a preprocessing step in which occur-rences of derived connectives are replaced by their corresponding expan-sion. The resulting formula is longer by a constant factor. Consequently,manual and automatic evaluations take longer.

1.2.4 Necessary and sufficient conditions

Given two statements ϕ and ψ, ϕ is said to be sufficient for ψ, if ψ is truewhenever ϕ is. That is, the implication ϕ→ ψ holds. Moreover, ϕ is necessaryfor ψ, if ϕ is true whenever ψ is. That is, the reverse implication ψ → ϕ holds.Consider, for instance, the statement

“If you have a Canadian passport, you are allowed to work in Canada”.

In other words, having a Canadian passport is sufficient for being allowed towork in Canada. Since you may also work in Canada with a work permit orpermanent residency status, a passport is not necessary for a work authorization,that is, the reverse implication

“If you are allowed to work in Canada, you have a Canadian passport”

is not true. Note, however, that “You are allowed to work in Canada” is neces-sary for “You have a Canadian passport”, that is, if ϕ is sufficient for ψ, then,by definition, ψ is necessary for ϕ.

If the truth of statement ϕ is both necessary and sufficient for the truth ofanother statement ψ, then the two are logically equivalent, that is, ϕ holds ifand only if ψ does, that is, ϕ↔ ψ holds. For instance, the statement

“Tom can sing ‘The Star-spangled Banner’ ”

is necessary and sufficient for the statement

“Tom can sing the American national anthem”,

because both are logically equivalent.

1.3 Proof theory

We present the proof theory of propositional logic using natural deduction. Theproof theory of a logic shows how a new formula can be obtained from other,old formulas by means of a syntactic process called derivation.

1.3.1 Sequents

Let ϕ1, . . . , ϕn and ψ be formulas. Then,

ϕ1, . . . , ϕn � ψis called a sequent. Intuitively, this sequent means that the conclusion ψ isderivable from the premises ϕ1, . . . , ϕn using the proof rules to be presentedin Section 1.3. Note that a sequent is not a formula. It expresses a syntacticrelationship between formulas.


1.3.2 Proof rules

By definition the sequentϕ1, ϕ2, . . . , ϕn � ψ

expresses that ψ is derivable from the formulas ϕ1, ϕ2, . . . , ϕn using a set ofproof rules. We now present these rules.

General shape of rules

Every rule has the following general form:

ϕ1 . . . ϕn

ψ1...ψ′1

. . .

ψm...ψ′m

ηname of rule

The formulas ϕ1 through ϕn above the bar are called premises of the rule.Them boxes above the bar represent subproofs in which ψ′

i must be shown usingψi as additional assumption. This additional assumption must only be usedinside the box, in other words, the box demarcates the scope of the assumption.The formula η below the bar is the conclusion of the rule. The name of the ruleappears on the right. The rule allows us to add the conclusion η to our proof,but only if the premises ϕ1 through ϕn already occur in the proof and all them subproofs have been completed, that is, in every box i the vertical dots havebeen replaced by a valid proof of ψ′

i .The following two special cases are worth mentioning:

• n = 0: The rule requires no premises.

• m = 0: The rule requires no subproofs.

If n = m = 0 the space above the bar is empty. There is no constraint on whenthe rule can be applied. Such a rule is often called axiom which is Latin for“that which is assumed”.

Soundness of a rule

An important property of rules is soundness. Informally, soundness means the“stuff above the bar implies the conclusion”. In other words, the rule neverallows you to draw a false conclusion. Formally, the rule with the general formabove is sound iff the premises ϕ1 through ϕn and the implications ψ1 → ψ′

1

through ψm → ψ′m entail the conclusion ψ, that is, we have

ϕ1, . . . , ϕn , ψ1 → ψ′1, . . . , ψm → ψ′

m |= η

1.3. PROOF THEORY 11

Examples for sound rules are

ϕ ∧ ψ

ϕ∧ e1

ϕ ∨ ψ

ϕ...η

ψ...η

η∨ e

Examples for unsound rules are

ϕ

ϕ ∧ ψ

ϕ ∨ ψ

ψ...η

η

The proof rules for Propositional Logic

All proof rules for Propositional Logic can be found in Figure 1.3 on page 28.For instance, the three proof rules for conjunction ∧ are

ϕ ψ

ϕ ∧ ψ∧ i

ϕ ∧ ψ

ϕ∧ e1

ϕ ∧ ψ

ψ∧ e2

The rule ∧ i allows us to conclude ϕ ∧ ψ provided that we have already provedϕ and ψ. Since it introduces a conjunction, it is called an introduction rule.This rule is obviously sound, because we have the entailment

ϕ, ψ |= ϕ ∧ ψ

as can easily be seen from the semantics of ∧.The rules ∧ e1 and ∧ e2 allow us to eliminate a conjunction. Given a

conjunction, we can also write down each of the conjuncts. They are examplesof elimination rules. Again, the soundness of these two rules follows from thesemantics of ∧.

Next, consider the rules for the introduction and elimination of an implica-tion:

ϕ...ψ

ϕ→ ψ→ i

ϕ ϕ→ ψ

ψ→ e

The premise of rule → i requires us to derive ψ from ϕ. The box demarcatesthe scope of the temporary assumption ϕ, that is, the assumption ϕ must notbe used outside the box. As we will see in Section 1.4, these boxes are necessaryto ensure that our rules are sound. Rule → e is also known as “modus ponens”.

Figure 1.3 on page 28 contains these and the other natural deduction proofrules for propositional logic. All rules should be fairly intuitive. Note that ruleff e says that everything is derivable from a contradiction.


1.3.3 Proofs

Now we are ready to define when the application of these rules makes up a legalproof. Informally, a proof of a sequent ϕ1, . . . , ϕn � ϕ is a sequence of formulasψ1, . . . , ψm such that

• the last formula in the sequence is the desired conclusion, that is, ψm = ϕ,and

• every formula ψi that is not a premise, that is, ψi �∈ {ϕ1, . . . , ϕn}, mustbe either

– an exact copy of a formula that appeared earlier in the sequencethat does not depend on an assumption whose box has already beenclosed, or

– the consequence of a proof rule applied to formulas earlier in thesequence.

Writing this down precisely requires a little work. A proof line is a triple

(line-number, ϕ, justification)

where line-number is a natural number, ϕ is a formula, and justification is either“premise”, “assumption”, “copy” or the name of a rule followed by one, two orthree line numbers. A set of proof boxes is a set of pairs of line numbers

{(a1, b1), . . . , (an , bn)}where ai and bi mark the beginning and end of box i , respectively, such that

• each box has at least size 1, that is, ai ≤ bi for all 1 ≤ i ≤ n, and

• every pair of boxes (ai , bi) and (aj , bj ) is either

– disjoint, that is, bi < aj or bj < ai , or

– nested, that is, ai < aj ≤ bj < bi or aj < ai ≤ bi < bj

for all 1 ≤ i , j ≤ n with i �= j .

The above box discipline ensures that subproofs are like subroutine calls: Ifa proof requires a subproof (through the rules ∨ e, → i , or ¬ i), then thatsubproof must be completed before the containing proof can complete.

A natural deduction proof of the sequent ϕ1, ϕ2, . . . , ϕn � ψ is a sequence Sof proof lines together with a set B of proof boxes such that

• the lines in S are numbered consecutively starting with 1, and

• each proof line(line-number, ϕ, justification)

in S is either


– a premise, that is, ϕ is one of ϕ1, ϕ2, . . . , ϕn and justification is“premise”, or

– an assumption at the beginning of a new box, that is, justification is“assumption” and there exists b such that (line-number, b) is in B ,or

– the copy of a previous formula that does not occur inside a box thathas already been closed, that is, justification is “copy(k)” and thereexists a proof line (k , ϕ, justificationk ) such that k < line-number andthere is no box (a, b) ∈ B such that a ≤ k ≤ b ≤ line-number, or

– the consequence of a unary proof rule r (¬ ¬ e, ff e, ∧ e1, ∧ e2, ∨ i1,or ∨ i2) applied to a formula that appears before the current line inthe sequence and that does not occur inside a box that has alreadybeen closed, that is, justification is “r(k)” such that k < line-numberand ϕ arises from applying rule r to the formula in line k and thereis no box (a, b) ∈ B such that a ≤ k ≤ b ≤ line-number, or

– the consequence of a unary proof rule r (→ i or ¬ i) applied toa box that appears before the current line in the sequence, that is,justification is “r(k)” such that ϕ arises from applying rule r to thebox ending in line k , and (k ′, k) ∈ B for some k ′, or

– the consequence of a binary proof rule r (∧ i , → e, or ¬ e) appliedto two formulas that appear before the current line in the sequenceand that do not occur inside a box that has already been closed,that is, justification is “r(k,l)” such that k , l < line-number and ϕarises from applying rule r to the formulas in lines k and l , andthere is no box (a, b) ∈ B such that a ≤ k ≤ b ≤ line-number ora ≤ l ≤ b ≤ line-number, or

– the consequence of a tertiary proof rule r (∨ e) applied to a formulaand two boxes that appear before the current line in the sequencesuch that the formula does not occur inside a box that has alreadybeen closed, that is, justification is “r(k,l,m)” such that k , l ,m <line-number and ϕ arises from applying rule r to the formula in linek and two boxes (l ′, l) ∈ B and (m ′,m) ∈ B for some l ′,m ′, andthere is no box (a, b) ∈ B such that a ≤ k ≤ b ≤ line-number, and

• the desired conclusion ψ occurs in the sequence. Typically, the proof endsas soon as the conclusion has been derived.

If a sequent has a proof it is said to be valid.

1.3.4 Constructing proofs

Finding a proof for a sequent can be easy, tricky, or impossible. We alwaysstart with a proof that has a “hole”, i.e., an incomplete part, in it. Suppose,for instance, we want to find a proof for the sequent ϕ1, ϕ2 � ψ. We write


down what we have, i.e., the premises, on top and what we need to get, i.e., theconclusion, at the bottom. In the middle, we leave a lot of space.

1 ϕ1 premise

2 ϕ2 premise

3...

4 ψ

Then, we start filling the space with proof steps that eventually connect thetop with the bottom. We typically fill in the space from both directions: fromthe top by thinking about how what we already have can be used to concludea new formula; from the bottom by thinking from which new (hopefully alsoderivable) formulas the conclusion can be obtained.

1.3.5 Examples

We illustrate the definition of a proof with some examples. We will representa proof graphically. The correspondence between the graphical representationand the textual one used in the definition above should be obvious.

1. The following example is taken from [HR00]. The sequent p ∧ q → r �p → (q → r), for instance, has the following proof:

1 p ∧ q → r premise

2 p assumption

3 q assumption

4 p ∧ q ∧ i(2, 3)

5 r → e(1, 4)

6 q → r → i(5)

7 p → (q → r) → i(6)


2. The contraposition of an implication ϕ → ψ is ¬ ψ → ¬ ϕ. We will showthat every implication implies its contraposition. For instance, considerthe sentence “If you’re French, then you’re European”. If this implicationholds, then the sentence “If you’re not European, then you’re not French”is also true. We prove that the sequent p → q � ¬ q → ¬ p is valid.

1 p → q premise

2 ¬ q assumption

3 p assumption

4 q → e(1, 3)

5 ff ¬ e(2, 4)

6 ¬ p ¬ i(5)

7 ¬ q → ¬ p → i(6)

3. Moreover, every contraposition also implies the original implication. Forinstance, if the contraposition “If you’re not European, then you’re notFrench” holds, then “If you’re French, then you’re European” is also true.The proof of ¬ q → ¬ p � p → q is like that of p → q � ¬ q → ¬ p exceptthat it additionally requires the use of rule ¬ ¬ e.

4. The next example illustrates the use of the rules for disjunction. It is


taken from [HR00]. We prove q → r � p ∨ q → p ∨ r .

1 q → r premise

2 p ∨ q assumption

3 p assumption

4 p ∨ r ∨ i1(3)

5 q assumption

6 r → e(1, 5)

7 p ∨ r ∨ i2(6)

8 p ∨ r ∨ e(2, 4, 7)

9 p ∨ q → p ∨ r → i(8)

5. Our last example is closer to reality. Consider each of the following state-ments and their abbreviations. Let

“If JD oversleeps and the printer is not working, then JD is late for class”“JD oversleeps”“JD is not late for class”

be abbreviated by, respectively,

JDos ∧ ¬ pw → JDlateJDos¬ JDlate

We want to conclude from these facts that pw holds, that is, that the


printer is working.

1 JDos ∧ ¬ pw → JDlate premise

2 JDos premise

3 ¬ JDlate premise

4 ¬ pw assumption

5 JDos ∧ ¬ pw ∧ i(2, 4)

6 JDlate → e(1, 5)

7 ff ¬ e(3, 6)

8 ¬ ¬ pw ¬ i(4, 7)

9 pw ¬ ¬ e(8)

1.3.6 Remarks about proof rules

Rules for derived connectives

Remember that in Section 1.2.2 we introduced ff and the connectives ∨ and→ asabbreviations of combinations of ¬ and ∧. We could use these abbreviations toobtain sound proof rules for ff , ∨, and →. For instance, since ϕ ∨ ψ abbreviates¬ (¬ ϕ ∧ ¬ ψ) we could use

¬ ϕ ∧ ¬ ψ...ff

ϕ ∨ ψ∨ i

instead ofϕ

ϕ ∨ ψ∨ i1

ψ

ϕ ∨ ψ∨ i2

As can be seen in this example, the problem with using the rules obtainedthrough the abbreviations is that they tend to be lot more difficult to use thanthe ones in Figure 1.3.


A resulting slight inconvenience of the new rules for the derived connectives∨ and → is that they can now be read in two different ways. For instance, therule → i in Figure 1.3, suggests that ϕ → ψ means “if ϕ holds, then ψ holds,too”. However, if we read ϕ → ψ as an abbreviation of ¬ ϕ ∨ ψ, then ϕ → ψmeans “either ϕ doesn’t hold or ψ does”. Both readings are obviously quitedifferent. However, both are correct and can be shown to be equivalent.

Derived rules

A proof rule is derived if it is obtained using other rules. Intuitively, derived rulesare similar to macros in programming. Figure 1.4 on page 28 lists a few usefulderived rules where MT, RAA, and LEM stand for “modus tollens”, “reductoad absurdum”, and “law of excluded middle” respectively. The rule MT, forinstance, is derived, because we can find a proof of

ϕ→ ψ,¬ ψ � ¬ ϕ

just using the rules in Figure 1.3:

1 ϕ→ ψ premise

2 ¬ ψ premise

3 ϕ assumption

4 ψ → e(1, 3)

5 ff ¬ e(2, 4)

6 ¬ ϕ ¬ i(5)

1.3.7 Proof techniques I

This is a good place to discuss some general techniques to prove a formula.Suppose we want to prove that ϕ � ψ. Each technique will be described using a“proof schema” for the above sequent. Note that the step denoted by . . . mayconsist of several steps possibly using ϕ.

• Direct proof. ψ can be shown directly from ϕ. If, for instance, ϕ says “nis divisible by 4” and ψ says “n is divisible by 2”, then ψ can be showndirectly from ϕ (and the definition of “divisible”). To write the proof


down formally, we would use the rules for implication:

1 ϕ premise

2 ϕ assumption

3... . . .

4 ψ . . .

5 ϕ→ ψ → i(4)

6 ψ → e(1, 5)

• Proof by contradiction. We derive a contradiction from the premises ϕand ¬ ψ. In other words, if ϕ holds, then ¬ ψ cannot also be true. Thus,if we know that ϕ holds, then ψ must hold, too.

1 ϕ premise

2 ¬ ψ assumption

3... . . .

4 ff . . .

5 ψ RAA(4)

Here is an example. Suppose, for instance, we want to show that Tommust be older than 16, if he is licensed to drive a car in Canada. AssumingCanada’s traffic laws and that Tom has a license and is younger than 16leads us to a contradiction. Therefore, if the laws apply and he has alicense, he must be older than 16.

• Proof by case study. Suppose, we additionally know

ϕ→ ϕ1 ∨ ϕ2

This implication allows us to prove ψ by considering two cases. The boxesused by the elimination rule for disjunction ∨ e are written next to each


other.1 ϕ premise

2 ϕ→ (ϕ1 ∨ ϕ2) premise

3 ϕ1 ∨ ϕ2 → e(2, 1)

4 ϕ1 assumption

5... . . .

6 ψ . . .

ϕ2 assumption

... . . .

ψ . . .

7 ψ ∨ e(3, 6)

For instance, suppose we want to prove that the trip from Kingston toMontreal will take at least 2 hours, if you use public transport. We con-sider every means of public transportation and try to conclude that thetrip always takes at least 2 hours using that means of transportation.

The list omits proof by induction, because only universally quantified formu-las can be proved inductively. In other words, induction is not applicable topropositional formulas.

Exercise 1.3.1 For each of the following sequents, either prove it using Japeor show a counter example for the sequent.

1. p ∨ q � ¬ (¬ p ∧ ¬ q)

2. � (¬ p ∨ q) → (p → q)

3. ¬ (p ∨ q) � ¬ p ∧ ¬ q

4. p ∨ (q ∧ r) � (p ∨ q) ∧ (p ∨ r)

5. p ∨ (q ∨ r) � (p ∨ q) ∨ r

1.4 Soundness

In Section 1.3.2 we already introduced the notion of soundness for rules. In-tuitively, a rule is said to be sound if its application never resulted in a falseconclusion. A proof theory is said to be sound, if everything that is derivableusing the rules also is valid in the model. More precisely, the theory is sound, if

1.4. SOUNDNESS 21

the following holds: Whenever ϕ1, . . . , ϕn � ψ is derivable using the proof rulesin the theory, then ϕ1 . . . , ϕn |= ψ. Before we show that our theory is indeedsound, we present an example for an unsound theory. Suppose, for instance,we dropped the side condition from the rule for implication introduction, thatis, whenever the rule → i is used, we allow the assumption introduced at thebeginning of the box to be used outside the box. We show that the resultingtheory is unsound. Let the atomic proposition p stand for “The sun is shining”.If we dropped the side condition from rule → i, the following would be a legalproof of � p.

1 p assumption

2 p copy(1)

3 p → p → i(1)

4 p → e(1, 3) without side condition

Consequently, without any assumptions we can always conclude p, that is, thatthe sun is shining. However, p clearly is not valid. Not even in Kingston. Moreprecisely, p evaluates to false under a truth assignment l with l(p) = false. Thus,p is derivable but not valid. The theory is unsound. With the side condition,however, our theory is indeed sound.

Theorem 1 (Soundness)For every sequent ϕ1, . . . , ϕn � ψ that is derivable using the proof rules in Fig-ures 1.3 and 1.4, we have ϕ1, . . . , ϕn |= ψ.

Proof: The proof proceeds by induction over the length of the proof of

ϕ1, . . . , ϕn � ψ.

Base The shortest proof has length 1. In that case, no rule is applied and thesequent is of the form ϕ1, . . . , ϕn � ϕi for some 1 ≤ i ≤ n. Since all ϕi hold byassumption, we have ϕ1, . . . , ϕn |= ϕi .

Step Let the length of the proof be k+1 for k ≥ 0. Thus, at least one rule wasapplied. Let r be the rule that was used to obtain ψ, the last the formula in theproof. We perform a complete case study over r . We discuss only one case. Theremaing cases are similar. Suppose r =∧ i , that is, ψ is of the form ψ1 ∧ ψ2.Then, then we have two proofs: One for ψ1 and the other for ψ2. Their lengthmust be less than k + 1. Thus, by inductive hypothesis, ϕ1, . . . , ϕn |= ψ1 andϕ1, . . . , ϕn |= ψ2. Consequently, ϕ1, . . . , ϕn |= ψ.

Thus, the inductive step consists of showing for each rule that if all premisesof the rule evaluate to true, then the conclusion does too.


Exercise 1.4.1 Consider adding each of the following three rules to our prooftheory.

ϕNEW 1

ϕ ∧ ψ

ϕ ∨ ψNEW 2

ϕ ∨ ψ

ϕ ∧ ψNEW 3

Which rules would make the theory unsound? Explain your answer, that is,argue why the rule is sound or show a formula that is derivable in the newtheory but not valid.

1.5 Completeness

A proof theory is said to be complete, if whenever the entailment ϕ1, . . . , ϕn |= ψholds, then there exists a proof for the sequent ϕ1, . . . , ϕn � ψ. The followingproposition is strongly related to completeness and will aid in its proof.

Proposition 1.5.1 (Completeness)Every tautology is also a theorem, that is, if |= ψ, then � ψ for all formulas ψ.

Proof: Suppose ψ contains n distinct atomic propositions p1, . . . , pn . Ignoringthe details, the proof proceeds as follows:

1. If ψ holds, we know that ψ evaluates to true in all 2n rows of the truthtable for ψ. Each of the rows can be written as a sequent. More precisely,for row k we have the sequent

p′1, . . . , p

′n � ψ

where p′i is pi if the entry for pi in row k is true, otherwise p′

i is ¬ pi . Forinstance, if ψ is p ∨ ¬ p, we obtain four sequents

p, q � p ∨ ¬ pp,¬ q � p ∨ ¬ p¬ p, q � p ∨ ¬ p¬ p,¬ q � p ∨ ¬ p

2. By induction over the structure of ψ, we can show that each of the above2n sequents is provable.

3. Using the law of excluded middle, these 2n proofs can be assembled intoa single proof of ψ.

Note that the above proof crucially depends on the fact that the number ofatomic propositions in a formula is finite.

Theorem 2 (Completeness)For every entailment ϕ1, . . . , ϕn |= ψ that holds, there exists a proof of thesequent ϕ1 . . . , ϕn � ψ using the rules in Figure 1.3.

1.5. COMPLETENESS 23

Proof: The proof proceeds as follows. Assume ϕ1, ϕ2, ϕ3, . . . , ϕn |= ψ.

1. A simple truth table argument shows that

|= ϕ1 → (ϕ2 → (ϕ3 → (. . .→ (ϕn → ψ) . . .)))

also holds.

2. Using Proposition 1.5.1 we can conclude that the entailment is provable,that is, there is a proof for the sequent

� ϕ1 → (ϕ2 → (ϕ3 → (. . . → (ϕn → ψ) . . .)))

3. A proof for ϕ1, . . . , ϕn |= ψ is obtained as follows. First, we take theproof of � ϕ1 → (ϕ2 → (ϕ3 → (. . . → (ϕn → ψ) . . .))) and augmentit by introducing ϕ1, . . . , ϕn as premises. Then, the modus ponens rule→ e is used n times to derive the conclusion ψ. We thus have a proof ofϕ1, . . . , ϕn � ψ.

Soundness and completeness: The big picture. We have seen the se-mantic account of propositional logic in Section 1.2 and the syntactic accountin Section 1.3. The notion of soundness links the two in one direction: Every-thing that is derivable also holds in the semantics. The notion of completenesslinks the two in the other direction: Everything that holds in the semanticsalso is derivable. We conclude this section with some more general thoughtson this bidirectional connection between syntax and semantics. Soundness andcompleteness are ...

1. ... signs of quality: Informally, both soundness and completeness saysomething about the quality of the proof rules of a theory. If we havesoundness then the rules don’t allow the derivation of a formula that’swrong in the model. Compare the derivation of a formula with lookingup a number in a telephone book. A sound telephone book contains onlycorrect entries. Completeness, on the other hand, says that in some sensethere are “enough” rules in the theory such that everything that holds inthe model can be derived. A complete telephone book contains an entryfor every household with a phone.

2. ... more general than you think: As the above analogy illustrates, thenotions of soundness and completeness not only make sense in the con-text of logic and proof systems. For instance, they also apply to analysistechniques that attempt to extract properties from a specification, an ob-ject model, or a program and will thus be used frequently throughout thiscourse. A sound analysis technique only yields true results. A completeanalysis technique is capable of determining every true property.

3. ... a big help: Let Γ denote a sequence of premises ϕ1, . . . , ϕn . To showthat ψ is derivable from Γ we find a proof of Γ � ψ. However, suppose wehave difficulty finding such a proof. We can be in one of three cases:


• ψ is a not a consequence of Γ, and thus no sound proof theory willallow us to write down a proof of Γ � ψ.

• ψ is a consequence of Γ, but our proof theory does not contain therules required to write down the proof of Γ � ψ.

• ψ is a consequence of Γ and our logic contains the required rules, butwe have simply not yet found a proof.

In the first two cases, trying to find a proof is a waste of time. However,to prove that there is no proof the theory offers us no other choice but tosomehow systematically consider every possible candidate proof and arguethat it is not a proof of Γ � ψ. In other words, showing that a sequentis provable is much easier than showing that it is not. Thus, in a sense,proof theory thus gives a ‘optimistic’ account of the logic. Semantics, onthe other hand, works in the opposite way. Showing that that ψ is not aconsequence of Γ is easy, because we just need to find a ‘counter example’,that is, a truth assignment that makes all formulas in Γ true but not ψ.To show that ψ is a consequence of Γ, however, is much harder, becausewe need to argue that every truth assignment that makes the formulas inΓ true also makes ψ true. Since the number of possible assignments toconsider grows exponentially in the number of atomic propositions, thiscan be an impossible task. Semantics thus gives us a ‘pessimistic’ accountof the logic. We draw two conclusions from these observations:

• It is important to study both the proof theory and the semantics.

• Soundness and completeness form a connection between syntax andsemantics that allows us to have the best of both worlds. That is,whether or not ψ is a consequence of Γ and whether or not we knowthat, we can be assured that “there is an easy way out there”:

– Case: ψ is a consequence of Γ. Then, by completeness, thereexists a proof of Γ � ψ. Once we have a proof of Γ � ψ, soundnessallows us to conclude Γ |= ψ.

– Case: ψ is not a consequence of Γ. Then, there exists a counterexample. Once we have found a counter example, we can con-clude Γ �|= ψ. Soundness then allows us to conclude that there isno proof of Γ � ψ, that is, we have Γ �� ψ.

Of course, given arbitrary Γ and ψ we may not know which one ofthe two cases we are in. Experience and gut feeling helps here. And,of course, it’s comforting to know that an easy way to the truth isout there.

4. ... not always necessary: In the best case, a proof theory (or a tele-phone book or an analysis technique) is sound and complete. Then, thesyntactic notion of proof/derivation (�) and the semantic notion of evalu-ation/truth tables (|=) are freely interchangeable. However, completenesscan be hard or even impossible to come by. As long as we can live with

1.6. DECIDABILITY 25

��

�

“No, ϕ is not valid”

program P “Yes, ϕ is valid”

ϕ

Figure 1.1: Deciding the validity problem

the fact that certain valid formulas are not derivable, a sound but in-complete theory could still be useful. In contrast, logicians have alwaysdeemed unsound theories useless. Their argument is that one cannot relyon the results of an unsound theory. With an unsound telephone bookyou cannot be absolutely certain that you won’t get the wrong person outof bed. However, a more pragmatic view holds that unsound theories canbe just as useful as incomplete ones. More precisely, the usefulness of anunsound theory depends on your use and the “degree of unsoundness”.For instance, if Kingston’s telephone book contains only one wrong entryand that entry happens to be that of a funeral home, the book wouldstill be very useful for the average college student. Lately, researchers inautomatic program analysis have proposed unsound, but yet useful anal-ysis techniques. Towards the end of the course we will hopefully see someexamples of this strategy.

1.6 Decidability

The problem of deciding whether a formula in a given logic is valid is known asthe validity problem. A solution is a mechanical procedure, that is, a programP that takes a formula as input, always terminates, and outputs “yes” if theinput formula is valid and “no” otherwise (Figure 1.1). If such a program exists,the logic is said to be decidable. Decidability of a problem is an indication ofits complexity. Undecidable problems are more difficult than decidable ones,just like problems that can only be solved in quadratic time are more difficultthan problems solvable in linear or constant time. The relationship betweendecidability and the measures of algorithmic complexity such as “constant”,“linear”, etc is given in Figure 1.2.

We see that undecidable problems top the scale of difficulty. Undecidableproblems are impossible to solve.

Theorem 3 (Decidability of propositional logic)The validity problem for propositional logic is decidable.

Proof: We present a mechanical procedure that always terminates with thecorrect output. Suppose the input is a formula ϕ. The procedure consists oftwo steps:


constant

linear

quadratic

polynomial

exponential

undecidabledecidable

Figure 1.2: Relationships between most common complexity classes

1. Determine the distinct atomic propositions in ϕ. Since formulas are finite,this step always terminates.

2. Suppose there are n distinct atomic propositions in ϕ. Evaluate ϕ un-der all possible 2n truth assignments, that is, compute evall (ϕ) for alltruth assignments l . As soon as we find a truth assignment l ′ such thatevall′(ϕ) = false, we terminate and output “no”. If none of the 2n possibletruth assignments makes ϕ false, we terminate and output “yes”. Since ϕis finite, the computation of evall(ϕ) always terminates. Thus, this stepalso always terminates.

Note that a solution to the decidability problem does not have to be efficient,it just needs to terminate always. The procedure described in the above proofis O(2n) and thus not efficient (“efficient” usually means better than cubic). Inapplications, formulas ϕ with at least 100 atomic propositions are not uncom-mon. Even if we assume, somewhat optimistically, that we can check 109 truthassignments per second, the algorithm would take 1014 years and thus longerthan the age of the universe to determine whether ϕ is valid. It is unknownwhether the validity problem for propositional logic can be solved in polyno-mial time. In fact, the validity problem is NP-complete which means that theexistence of a polynomial decision procedure for validity for propositional logicimplies P=NP. We conclude that the validity problem for propositional logic iseasy enough to be decidable, but most likely too hard to be solvable efficiently.

Remember that a formula ϕ is valid if and only if its negation ¬ ϕ is notsatisfiable. In other words, the satisfiability problem is reducible to the validityproblem. This has two consequences:

• The satisfiability problem for propositional logic also is decidable, becausethe above decision procedure can also be used to determine satisfiability.

• The satisfiability problem for propositional logic also is NP-complete.

1.6. DECIDABILITY 27

Exercise 1.6.1 Devise a procedure that decides the satisfiability problem forpropositional logic formulas.


introduction elimination

∧ ϕ ψ

ϕ ∧ ψ∧ i

ϕ ∧ ψ

ϕ∧ e1

ϕ ∧ ψ

ψ∧ e2

∨ ϕ

ϕ ∨ ψ∨ i1

ψ

ϕ ∨ ψ∨ i2

ϕ ∨ ψ

ϕ...η

ψ...η

η∨ e

→

ϕ...ψ

ϕ→ ψ→ i

ϕ ϕ→ ψ

ψ→ e

¬

ϕ...ff

¬ ϕ¬ i

ϕ ¬ ϕ

ff¬ e

ff no introduction rule for ffff

ϕff e

¬ ¬ ¬ ¬ ϕ

ϕ¬ ¬ e

where the assumptions in the first line of the boxes in rules ∨ e, → i,and ¬ i can only be used inside these boxes.

Figure 1.3: Natural deduction rules for propositional logic

ϕ→ ψ ¬ ψ

¬ ϕMT

ϕ

¬ ¬ ϕ¬ ¬ i

¬ ϕ...ff

ϕRAA

ϕ ∨ ¬ ϕLEM

Figure 1.4: Some derived rules for propositional logic

Chapter 2

Predicate logic withequality

Before we plunge into the details of predicate logic1, we will investigate in whatsense propositional logic is insufficient by means of an example. Can the state-ment “All months have 31 days” be expressed in propositional logic? Our firstattempt is to identify the statement simply with a single atomic proposition p.However, this does not adequately express the statement. To see this, supposethat another atomic proposition q expresses “April has 30 days”. The intu-itively obvious relationship between the two statements is completely hidden.We know that the two statements cannot both be true. However, we cannotderive this, because p ∧ q is satisfiable. The idea behind our second attemptis the insight that “All months have 31 days” really is an abbreviation for thetwelve-fold conjunction “January has 31 days and February has 31 days and . . .and December has 31 days”. A more detailed model therefore would be

pJanuary ∧ pFebruary ∧ . . . ∧ pDecember

where pm abbreviates the atomic proposition “m has 31 days”. This modelis more accurate because we are now able to derive that the two statements“All months have 31 days” and “April has 30 days” are contradictory. Whatmakes this example work is the fact that there are only finitely many months.A formula with infinitely many conjunctions would be necessary to model, forinstance, “All prime numbers are odd” using the same technique. However, for-mulas of infinite length are prohibited, since they cannot be derived with thegrammar on page 3. At this point we have to admit defeat and concede thatstatements like “All prime numbers are odd”, although declarative, cannot beexpressed in propositional logic. Predicate logic overcomes this deficiency byallowing us to syntactically separate the objects that a statement talks aboutfrom the properties that the statement claims the objects have. In other words,

1Predicate logic is sometimes also called first order logic or first order predicate logic

29

30 CHAPTER 2. PREDICATE LOGIC WITH EQUALITY

predicate logic contains terms to denote objects and predicates to express prop-erties of these objects. For instance, “April has 30 days” asserts that the monthApril has the property of consisting of 30 days. Predicate logic allows us to writeP(apr) where apr is a constant denoting the month April and P is a predicatethat is true of a month if and only if that month has 30 days. “All prime num-bers are odd” can be expressed as ∀x .Prime(x ) → Odd(x ) where ∀ x denotes auniversal quantification over the variable x , Prime represents the predicate thatholds for a number if and only if that number is prime, and Odd represents thepredicate that holds for a number if and only if that number is odd.

2.1 Syntax

2.1.1 Terms

We have already used constants and variables to denote a single object. Thedifference is that a constant always denotes a specific object. In contrast, avariable denotes an unspecified object. We will find it convenient to apply afunction to one or more objects to obtain some other object. For instance, itmay be useful to have a function that when given a month returns the monththat succeeds it. To this end, the syntax contains function symbols. Usingconstants, variables, and function symbols we can now build expressions thatdenote objects. These expressions are called terms. Note that 0-ary predicatesymbols are atomic propositions as we used them in Chapter 1 for propositionallogic. Similarly, constants can be viewed as 0-ary functions. We adopt thisconvention because it simplifies the formal definition of terms. Let V be a setof variables and let F be a set of function symbols. The BNF for terms over(V ,F) is

t ::= x | f (t1, t2 . . . , tn)where x ∈ V and f is a function symbol in F with arity n with n ≥ 0. Note thatfunction symbols with n = 0 denote constant values such as “3” or “Sunday”.Again, note how this definition is inductive. As we will see, this will allow usto, e.g., define functions on terms inductively.

2.1.2 Formulas

Just like for propositional logic, we define the syntax of formulas only in terms ofnegation and conjunctions. The remaining connectives again arise as abbrevia-tions. Let P be sets of predicate symbols. The BNF for formulas over (V ,F ,P)is

ϕ ::= P(t1, . . . , tn) | (t1 = t2) | (¬ ϕ) | (ϕ ∧ ϕ) | (∀x .ϕ) | (ϕ)where P is a predicate symbol in P with arity n, all ti are terms over (V ,F),and x is a variable in V . Since we are studying predicate logic with equality, wecan always compare two terms for equality.

2.1. SYNTAX 31

The binding priorities are as before except that quantification binds likenegation.

¬ , ∀ negation and quantification bind most tightly∧ conjunction binds least tightly

Example Let

V = {x , y, z}F = {zero, succ, add}

where zero, succ, and add have arity 0, 1, and 2 respectively. Also, let

P = {≤, isZero}where ≤ takes two arguments and isZero takes one argument. Examples forwell-formed formulas over (V ,F ,P) include:

isZero(succ(zero))zero = x

∀ y.succ(zero) = zero∀ x .¬ (add(x , succ(succ(x ))) = x )

Exercise 2.1.1 Show how propositional logic arises as a special case from pred-icate logic.

2.1.3 Free and bound variables

Intuitively, the occurrence of a variable x in a formula is called bound if it isunder the scope of a quantifier ∀ x . Otherwise it is called free. For instance, theoccurrence of x is bound in ∀x .P(x , y) while the occurrence of y is free. Weneed to distinguish between free and bound occurrences of a variable, becausethey are evaluated differently. A bound occurrence of x stands for any possiblevalue of x , while additional information is needed to determine which value afree occurrence of x stands for. A variable is free in a formula if it has a freeoccurrence in the formula. Given a formula ϕ, the function fv computes the setfv(ϕ) of free variables in ϕ:

fv(x ) = {x}fv(f (t1, . . . , tn)) =

⋃ni=1 fv(ti)

fv(P(t1, . . . , tn)) =⋃n

i=1 fv(ti)fv(t1 = t2) = fv(t1) ∪ fv(t2)

fv(¬ ϕ) = fv(ϕ)fv(ϕ ∧ ψ) = fv(ϕ) ∪ fv(ψ)fv(∀x .ϕ) = fv(ϕ)\{x}

where S1\S2 denotes the set subtraction. Note that a variable can both occurbound and free in a formula. Consider Q(x ) ∧ ∀x .P(x ) for instance. However,each individual occurrence of a variable in a formula are always either bound orfree, never both at the same time.


2.1.4 Substitution

Since variables are place holders one important operation on them is to replacethem with more concrete information. This information can be given in theform of a constant, another variable, or some function application. That is,we need to be able to replace variables by terms. Consider, for instance, theformula y > x +1. We know from elementary arithmetic that if x = 3+ z theny > (3 + z ) + 1. Substitution allows us to formalize this process. As a firstattempt, let ϕ[t/x ] denote the formula that looks just like ϕ except that everyfree occurrence of x in ϕ is replaced by t . For example, (y > x + 1)[3 + z/x ]denotes y > 3 + z + 1. For a second example, consider x = z and ¬ ∀z .z = x .Intuitively, ¬ ∀z .z = x is true because says that it is not the case that x is equalto all numbers. Substituting z for x in ¬ ∀z .z = x however, yields ¬ ∀z .z = zexpressing that it is not the case that all numbers are equal to themselves whichclearly is a contradiction. This example tells us that a substitution must becarried out with care. More precisely, in a substitution ϕ[t/x ] it must not bethe case that a variable in t becomes bound in ϕ[t/x ]. We say that t is free for xin ϕ if no free occurrence of x in ϕ is under the scope of a quantification ∀ y forany variable y in t . For instance, z is not free for x in ¬ ∀z .z = x . Substitutionswill be subject to this condition. Note that whenever a term t fails to be freefor a variable x in some formula ϕ, then there always is a formula ϕ′ such thatϕ and ϕ′ are logically equivalent and t is free for x in ϕ′. That formula ϕ′

is obtained from ϕ by renaming the violating bound variables consistently andappropriately. Consequently, the freeness condition does not really limit theapplicability of substitutions. For instance, z is the bound variable that causesz not to be free for x in ¬ ∀z .z = x . However, the formula ¬ ∀y.y = x islogically equivalent to ¬ ∀z .z = x and now z is free for x in ¬ ∀y.y = x . Theresult of the substitution then is ¬ ∀y.y = z . In summary, a substitution ϕ[t/x ]proceeds in two steps:

1. If t is not free for x in ϕ, then determine the bound variables in ϕ thatcapture the variables in t , rename them appropriately and consistently,call the result ϕ, and

2. Return the formula that is like ϕ except that every free occurrence of xin ϕ is replaced by t . Formally, this step is defined by induction over thestructure of ϕ.

Examples We have

(x = y + 1

)[3/y] = x = (3 + 1)(

x = y + 1 ∧ ∀ y.y > 10)[3/y] = x = (3 + 1) ∧ ∀ y.y > 10(

x = y + 1)[3 + x/y] = x = (3 + x ) + 1(∀x .x = y + 1)[3 + z/y] = ∀x .x = (3 + z ) + 1(∀x .x = y + 1

)[3 + x/y] = ∀z .z = (3 + x ) + 1.

2.2. SEMANTICS 33

As we will see, substitution is crucial for the formulation of sound proof rulesfor quantification.

2.2 Semantics

The syntax of prediate logic allows us to build formulas such as ∀ x . ≤ (x , succ(x ))or ∀ x . ∀ y. ≤ (x , y). But what exactly do these formulas mean? Under preciselywhat circumstances is one formula true and another false? When are two for-mulas equivalent? How do we evaluate them? The formulation of a formalsemantics for predicate logic will allow us to answer these questions.

The evaluation of propositional formulas over atomic propositions AP re-quires a truth assignment l assigning truth values to each of the atomic propo-sitions in AP. The evaluation of predicate formulas requires a bit more machin-ery. Given a set of function symbols F and a set of predicate symbols P , thetriple (DM,FM,PM) is a (F ,P)-model, if

• DM is a non-empty set of concrete values, sometimes called the domainor universe of the interpretation. If, for instance, we want to interpret aformula in the natural numbers or the set of strings over {0, 1}, we wouldchoose D = N or D = {0, 1}∗ respectively.

• FM is a set of functions such that for each n-ary function symbol f in F ,there is a function fM : (DM)n → DM in FM. Formally,

FM = {fM : (DM)n → DM | f ∈ F ∧ f has arity n}

where (DM)n denotes the n-fold cartesian product of DM, that is,

DM × . . .×DM︸︷︷︸n times

• PM is a set of predicates such that for each n-ary predicate symbol P inP , there is a predicate PM : (DM)n → B in PM. Formally,

PM = {PM : (DM)n → B | P ∈ P ∧ P has arity n}

We need one more piece before we can formally define how a predicate logicformula is evaluated. For instance, to evaluate ∀x .ϕ, we need to determine whatϕ evaluates to for all concrete values in our model. More precisely, for all valuesd ∈ DM, we evaluate ϕ assuming that x is a place holder for d . We currentlyhave no way of formalizing these evaluations, because they use a syntactic entityϕ and a semantic entity d simultaneously. For instance, performing substitutionand evaluating ϕ[d/x ] for each d does not work, because ϕ[d/x ] is not a legalformula. We are forced to store the corresponding value for x in a mappingl : V → DM called an environment and to perform the evaluation relative tothis environment.


Now, finally, we’re ready to rumble. Given a formula ϕ over (V ,F ,P), a(F ,P)-model M with environment l , we define an evaluation function

evalM,l : t → DM

that determines which concrete value a term stands for. Since terms have aninductive structure, our definition of evalM,l will also be inductive.

evalM,l (x ) = l(x )

evalM,l(f (t1, . . . , tn)) = fM(evalM,l(t1), . . . , evalM,l(tn))

The satisfaction relation M, l |= ϕ holds if ϕ evaluates to true in the model Mrelative to the environment l . Just like for propositional logic, we define thisrelation by induction over the structure of ϕ.

M, l |= P(t1, . . . , tn) iff PM(evalM,l(t1), . . . , evalM,l (tn)) = trueM, l |= t1 = t2 iff evalM,l(t1) = evalM,l(t2)M, l |= ¬ ϕ iff it is not the case that M, l |= ϕ holdsM, l |= ϕ ∧ ψ iff M, l |= ϕ and M, l |= ψ holdsM, l |= ∀x .ϕ iff M, l [x �→ d ] |= ϕ holds for all d in the domain DM

where l [x �→ d ] is the environment that is just like l except that x is associatedwith value d . We typically write M, l �|= ϕ if M, l |= ϕ does not hold.

Given ϕ, let l and l ′ be two environments that agree on all free variables inϕ. Then, M, l |= ϕ holds if and only if M, l ′ |= ϕ does. The proof proceeds byinduction over the height of the parse tree of ϕ. Thus, when ϕ is closed, that is,has no free variables, M, l |= ϕ holds, or does not hold, for all environments l .Intuitively, since l determines the values of free variables, the truth of a closedformulas ϕ in M is independent of l . Thus, if ϕ is closed, we write M |= ϕ.

2.2.1 Examples

Let

F def= {zero, succ, add}

where zero, succ, and add have arity 0, 1, and 2 respectively. Also, let

P def= {≤, isZero}

where ≤ takes two arguments and isZero takes one argument.

2.2.2 Using the semantics to evaluate a formula in a model

We present three different (F ,P)-models called M1, M2, and M3.

1. Let the model M1 be given by

• DM1def= N,

2.2. SEMANTICS 35

• FM1def= {zeroM1 , succM1 , addM1} where zeroM1 = 0 ∈ N, succM1 is

the successor function on N and addM1 is the addition function onN, and

• PM1def= {≤M1 , isZeroM1} where ≤M1 is “less than or equal” on N,

and isZeroM1(x ) = true if and only if x = 0.


• DM2def= {0, 1}∗,

• FM2def= {zeroM2 , succM2 , addM2} where zeroM2 is the empty word

ε, succM2(w) = w1 for all w ∈ {0, 1}∗, and addM1(w1,w2) = w1w2

for all w1,w2 ∈ {0, 1}∗, and• PM2

def= {≤M2 , isZeroM2} where≤M2 is the prefix relation on {0, 1}∗,

that is, w1 ≤M2 w2 if and only if w1 is a prefix of w2, and isZeroM2

returns true if and only if the argument is ε.


• DM3def= {off, on},

• FM3def= {zeroM3 , succM3 , addM3} where zeroM3 = off and

succM3(off) = on

succM3(on) = off,

and addM3 is the function defined by

addM3(off, off) = off

addM3(off, on) = addM3(on, off) = on

addM3(on, on) = off,

and

• PM3def= {≤M3 , isZeroM3} where

≤M3 (x , y) =

{false, if x = on and y = offtrue, otherwise.

and isZeroM3(x ) = true if and only if x = off.

As different as these models seem on first glance, they have a lot in common.For instance, the formulas

isZero(zero)¬ isZero(succ(zero))∀ x .add(x , zero) = x

∀ x . ∀ y.add(x , y) = x → isZero(y)∀ x . ∀ y.(x ≤ add(x , y) ∧ ¬ (x = add(x , y))

) → ¬ (isZero(y))


hold in all three models. However, there also are some differences. The followingformulas hold in models M1 and M2 but not in M3:

¬ isZero(succ(succ(zero))∀ x .x ≤ succ(x )

While the formula¬ (∀ x .¬ (isZero(succ(x ))))

holds in M3 but not in M1 or M2.It is tempting to think that isZero(zero) holds in any (F ,P)-model. However,

we can easily give a model in which isZero(zero) does not hold. For instance,if isZero is interpreted as the predicate that returns false on all its arguments,then that predicate will also yield false on the interpretation of zero. Rememberthat function and predicate symbols are just syntax that can be interpreted anyway we like.

2.2.3 Satisfiability, validity, and entailment

Let ϕ be a closed formula over the symbols F and P . ϕ is satisfiable if thereexists a (F ,P)-model M such that ϕ holds in M, that is, M |= ϕ.

Formula ϕ is valid if ϕ holds in all (F ,P)-models. Like in propositionallogic, a valid formula is also called tautology. Tautologies are general truthsthat hold independent of particular interpretations. For instance, all of theformulas mentioned in the example above are satisfiable. None of them is atautology. Examples for tautologies are

ϕ1 ∨ ¬ ϕ1( ∀ x .ϕ1 ∧ ϕ2

) ↔ ( ∀ x .ϕ1

) ∧ ( ∀ x .ϕ2

)((∀ x .ϕ1) ∨ (∀ x .ϕ1)

) → ( ∀ x .ϕ1 ∨ ϕ2

)( ∀ x . ∀ x .ϕ) ↔ ( ∀ x .ϕ)

for any syntactically well-formed formulas ϕ1 and ϕ2.Let ϕ1, . . . , ϕn and ψ be closed formulas over the symbols F and P . Entail-

ment ϕ1, . . . , ϕn |= ψ expresses that for all (F ,P)-models M and environmentsl , whenever M, l |= ϕi for all 1 ≤ i ≤ n, then M, l |= ψ.

Note that the symbol |= is overloaded in predicate logic. It is used to denotesatisfiability of closed formulas

M |= ϕ

and semantic entailmentϕ1, . . . , ϕn |= ψ

2.2.4 Existential quantification

Just as disjunction can be defined in terms of conjunction and negation, ex-istential quantification can be defined in terms of universal quantification and

2.2. SEMANTICS 37

negation.

∃x .ϕ def= ¬ ∀x .¬ ϕ

In the introduction to predicate logic we already mentioned that universalquantification over a domain with n objects is short for an n-fold conjunction.With the above abbreviation we see that existential quantification over the samedomain is short for an n-fold disjunction. The proof rules for both quantifiersto be presented in the next section will reflect this correspondence.

To save parentheses, the quantifiers and connectives are assigned the follow-ing binding priorities:

¬ , ∀, ∃ negation and quantifiers bind most tightly∧,∨ conjunction and disjunction have medium binding power→ implication binds least tightly

Using the semantics to show that formulas are (not) equivalent

Consider the three formulas

f1def= ∀ x . ∃ y. ≤ (x , y)

f2def= ∀ y. ∃ x . ≤ (y, x )

f3def= ∃ y. ∀ x . ≤ (x , y)

Which one of these formulas are equivalent? How do we show this?

1. Consider f1 and f2. These two formulas are equivalent. Using the seman-tics, we show this as follows. Given some model M and some environmentl , we have

M, l |= ∀ x . ∃ y. ≤ (x , y)

iff for all d1 in DM, there exists d2 in DM such that

M, l [x �→ d1][y �→ d2] |=≤ (x , y)


≤M (d1, d2)


M, l [y �→ d1][x �→ d2] |=≤ (y, x )

iffM, l |= ∀ y. ∃ x . ≤ (y, x )

This example shows that consistently renaming bound variables in a for-mula does not alter its meaning.


2. Consider f1 and f3. These two formulas are not equivalent. Using thesemantics, we show this as follows. Given model M1 (as defined above)and some environment l , we have

M1, l |= ∀ x . ∃ y. ≤ (x , y)


M1, l [x �→ d1][y �→ d2] |=≤ (x , y)


≤M1 (d1, d2)

To see that the last statement holds in M1, let d2def= d1 + 1 for every

d1 ∈ DM. We conclude that f1 holds in M1.

However, f3 does not hold in M1. To see this, we observe

M, l |= ∃ y. ∀ x . ≤ (x , y)

for some l iff there exists d1 in DM such that for all d2 in DM we have

≤M1 (d2, d1)

However, such a d1 cannot exist. We show this by contradiction. Supposewe have a d1 ∈ DM1 such that (*) for all d2 in DM1 , ≤M1 (d2, d1). Then,

if we choose d2def= d1 + 1, we get �≤M1 (d2, d1) which contradicts (*).

Consequently, there is at least one model in which f1 holds, but not f3.So, the two formulas are not equivalent.

As another example, consider

f4def= ∀ x .(∃ y.Q(x , y)) → P(x )

f5def= ∀ x . ∃ y.Q(x , y) → P(x )

These formulas differ only in the scope of the variable y. In f4, the scopecomprises Q(x , y) only, whereas in f5, y has Q(x , y)) → P(x ) as its scope.Perhaps surprisingly, these two formulas are not equivalent; there is a modelthat distinguishes them. For instance, consider M2 with

• DM2def= {a, b},

• PM2def= {PM2 ,QM2} where PM2(a) = PM2(b) = false, QM2(a, a) =

QM2(b, a) = true and QM2(a, b) = QM2(b, b) = false.

Then. M2 �|= f4, but M2 |= f5.


2.3 Proof theory

The new syntactic constructs in predicate logic come with new proof rules.These rules augment the propositional proof rules presented in the previouschapter.

2.3.1 Universal quantification

The rules for universal quantification are

x0

...ϕ[x0/x ]

∀x .ϕ ∀ x i∀x .ϕϕ[t/x ]

∀ x e

where x0 is a fresh variable that does not occur free anywhere in the proof. Theintroduction rule uses a box to introduce a dummy variable x0 that does notoccur free anywhere. Consequently, we cannot make any assumptions about x0and it can thus be thought of as representing all terms. Thus, being able toderive ϕ[x0/x ] under these circumstances means that ϕ is derivable for any valuethat x may take on. Consequently, it is sound to conclude ∀x .ϕ. To illustratethe rule, consider an informal proof of the statement

“For every natural number, (2.1)

there exists another natural number that is greater”

An informal proof of this statement could go like this:

“Let n be a natural number.Then, n + 1 also is natural number.Moreover, n + 1 is greater than n”.

The proof starts with fixing an arbitrary natural number and naming it n. Then,it proceeds to show the desired conclusion. Since no assumptions where madeabout n, it works for every natural number and thus establishes the universallyquantified statement (2.1). The rule ∀ x i formalizes this kind of reasoning. Theonly minor difference is that it uses x0 rather n as a place holder.

The elimination rule also is very intuitive. If we know that ϕ holds nomatter what value x takes on, then it will clearly also hold if x takes on thevalue denoted by some term t . If we think of the universal quantification as aconjunction, the similarity between the above rules and the rules for conjunctionbecomes apparent.


2.3.2 Existential quantification

The rules for existential quantification are

ϕ[t/x ]

∃x .ϕ ∃ x i∃x .ϕ

x0 ϕ[x0/x ]...η

η∃ x e

where x0 is a fresh variable that does not occur free anywhere in the proof.Intuitively, if ϕ holds when x takes on the value denoted by t , then ∃ x .ϕ alsoholds. The rule ∃ e performs a case analysis similar to rule ∨ e. Due to thepremise ∃ x .ϕ we know that ϕ is true for at least one value of x . Since wedon’t know which value that is, the second premise performs a case analysisover all possible values, writing x0 as a generic value that represents them all. Ifassuming ϕ[x0/x ] allows us to prove some η that does not mention x0, then thisη must be true whichever x0 it was. Note that if x0 is mentioned in a formulasomewhere outside the box, it loses its ability to represent all possible valuesexplaining the side condition on x0. Thus, the box in ∃ e controls the scope notonly of the assumption ϕ[x0/x ] but also of the variable x0.

2.3.3 Examples

The following examples illustrate the use of the above rules. The first three aretaken from [HR00].

1. The sequent

∀ x .(P(x ) → Q(x )), ∀x .P(x ) � ∀x .Q(x )

can be proved by

1 ∀x .(P(x ) → Q(x ))

premise

2 ∀x .P(x ) premise

xo 3 P(x0) → Q(x0) ∀ x e(1)

4 P(x0) ∀ x e(2)

5 Q(x0) → e(3, 4)

6 ∀x .Q(x ) ∀ x i(3)


2. A minister reasons:

“If all quakers are reformists and if there is a protestant whois also a quaker, then there must be a protestant who is also areformist.”

Formally,

∀x .(Q(x ) → R(x )), ∃x .(P(x ) ∧ Q(x )

) � ∃x .(P(x ) ∧ R(x )).

Is he right? Yes, he is:

1 ∀x .(Q(x ) → R(x ))

premise

2 ∃x .(P(x ) ∧ Q(x ))

premise

xo 3 P(x0) ∧ Q(x0) assumption

4 Q(x0) → R(x0) ∀ x e(1)

5 Q(x0) ∧ e2(3)

6 R(x0) → e(4, 5)

7 P(x0) ∧ e1(3)

8 P(x0) ∧ R(x0) ∧ i(7, 6)

9 ∃x .P(x ) ∧ R(x ) ∃ x i(8)

10 ∃x .P(x ) ∧ R(x ) ∃ x e(2, 9)

3. The sequent

∃x .P(x ), ∀x .∀y.(P(x ) → Q(y)) � ∀y.Q(y)


is proved by

1 ∃x .P(x ) premise

2 ∀x .∀y.(P(x ) → Q(y))

premise

yo 3

xo 4 P(x0) assumption

5 ∀y.(P(x0) → Q(y)) ∀ x e(2)

6 P(x0) → Q(y0) ∀ y e(5)

7 Q(y0) → e(6, 4)

8 Q(y0) ∃ y e(1, 7)

9 ∀y.Q(y) ∀ y i(3, 8)

4. The last example will illustrate the importance of the side condition onrule ∃ x e. Consider the sequent ∃x .P(x ) � ∀x .P(x ). This sequent is,obviously, not valid, that is, there must not be a proof for it. However, ifwe allow the variable x0 introduced by rule ∃ x e to be used in a formula


outside the box, then the sequent is provable.

1 ∃x .P(x ) premise

xo 2

xo 3 P(x0) assumption

4 P(x0) copy(3)

5 P(x0) ∃ x e(1, 3)

6 ∀x .P(x ) ∀ x i(4)

Without the side condition the rule ∃ x e becomes unsound because itallows the variable x0 to be used in a formula outside its scope.

Exercise 2.3.1 For each of the following sequents, either prove it using Japeor show a counter example, that is, a model in which the sequent is not valid.

1. (∀x .P(x )) ∨ (∀ x .Q(x )) � ∀x .(P(x ) ∨ Q(x ))

2. ∃x .(P(x ) ∨ Q(x )) � (∃x .P(x )

) ∨ (∃x .Q(x ))

3.(∃x .P(x )

) ∨ (∃x .Q(x )) � ∃x .(P(x ) ∨ Q(x )

)

4. ∀x .¬ Q(x ),P → (∀x .Q(x )) � ¬ P

5. S (m, n), ∀x .P(x ) → ¬ S (x , n) � ¬ P(m)

6. ∃x .P(x ) ∧ ¬ Q(x ), ∀x .P(x ) → R(x ) � ∃x .R(x ) ∧ ¬ Q(x ).

2.3.4 Proof techniques II

Suppose we want to prove that ϕ � ∀x .ψ. We want to revisit the techniquespresented in the previous section, and also briefly discuss induction.

• Proof by induction. We have not introduced a proof rule for induction, sothis technique is mentioned here only for the sake of completeness.


If the premise ϕ defines some kind of inductive set S and the conclusionψ makes a statement over S , then we may be able to prove the sequentby induction over the elements of S . For instance, consider

∀x .Even(x ) ↔ (x = 0 ∨ ∃y.(x = s(y) ∧ Odd(y))

),

∀x .Odd(x ) ↔ (x = s(0) ∨ ∃y.(x = s(y) ∧ Even(y))

),

∀x .Nat(x ) ↔ (x = 0 ∨ ∃y.x = s(y)

)� ∀x .Nat(x ) → Even(x ) ∨ Odd(x )

Similarly, we could prove that every formula generated using the BNF onpage 3 contains an even number of parentheses. Note, however, that wehave to encode the inductive structure of the elements of S in the premise,so that it is available to us in when proving the conclusion.

• Proof by case study. Now we use the case analysis to group the set ofvalues that x ranges over into several subsets. Suppose, we additionallyknow

ϕ→ ∀x .(ϕ1 ∨ ϕ2).

In other words, we partitioned the domain of x into a subset characterizedby ϕ1 and into a subset characterized by ϕ2. This allows us to prove ∀x .ψby considering two cases.

1 ϕ premise

2 ϕ→ ∀x .(ϕ1 ∨ ϕ2) premise

3 ∀x .(ϕ1 ∨ ϕ2) → e(1, 2)

x0 4 ϕ1[x0/x ] ∨ ϕ2[x0/x ] ∀ x e(3)

5 ϕ1[x0/x ] assumption

6... . . .

7 ψ[x0/x ] . . .

ϕ2[x0/x ] assumption

... . . .

ψ[x0/x ] . . .

8 ψ[x0/x ] ∨ e(4, 7)

9 ∀x .ψ ∀ x i


For instance, we show that all moons of planet Saturn are smaller thanthe Earth, by considering each of Saturn’s planets and comparing its sizeto that of the Earth.

• Proof by contradiction. Universally quantified formulas express that someproperty ϕ holds for all values and thus can be very hard to prove. Often,it is much easier to prove instead that the assumption that there exists aninstance such that ¬ ϕ leads to a contradiction. Suppose, for instance, wewant to prove that for all natural numbers x there exists a number thatis greater than x , that is, Γ � ∀x .∃y.x < y where Γ formalizes the naturalnumbers. We could attempt to prove the sequent with induction, but it ismuch easier by contradiction, because the negation ∃x .∀y.x ≥ y is easilyseen to be wrong, because no matter what x is, x + 1, for instance, willalways be greater.

2.3.5 Bounded quantification

A quantified variable ranges over the entire semantic domain. Sometimes, how-ever, it is convenient to make it explicit in the formula that a quantified vari-able ranges over a particular set S by using bounded quantification ∀ x : S .ϕ or∃ x : S .ϕ. For instance, to formalize that there is no greatest natural numberwe could write ¬ ∃ x : N. ∀ y : N.x ≥ y. In this case it is apparent that theappropriate semantic domain for the interpretation of this formula is the set ofnatural numbers. Note that bounded quantifications do not add any expressivepower to our logic and can actually be viewed as abbreviations of standard,unbounded quantifications:

∀ x : S .ϕdef= ∀ x .inS (x ) → ϕ

∃ x : S .ϕdef= ∃ x .inS (x ) ∧ ϕ

where inS is a unary predicate symbol that is to be interpreted by a predicateinSM that returns true precisely when its argument is an element of the setS . Also note how the treatment of universal and existential quantification isslightly different.

We can also introduce an abbreviation that enumerates the values that thevariables can take on. For instance, ∀ x : [1..5].ϕ means that ϕ has to be truefor all natural numbers x between 1 and 5. The translation of these formulasare:

∀ x : [l ..u].ϕdef= ∀ x .(l ≤ x ∧ x ≤ u) → ϕ

∃ x : [l ..u].ϕdef= ∃ x .(l ≤ x ∧ x ≤ u) ∧ ϕ

where ≤ is a binary predicate symbol denoting “less than or equal” and l andu are natural numbers.

Other ways of bounding the quantifiers are possible. The point is that thisdoes not increase the expressive power of the logic as they can all be expressedin pure predicate logic.


2.4 Soundness, completeness and decidability

Our presentation of predicate logic is sound and complete. The proofs arebeyond the scope of this document.

Theorem 4 (Soundness)For every sequent ϕ1, . . . , ϕn � ψ that is derivable using the presented proofrules we have ϕ1, . . . , ϕn |= ψ.

Theorem 5 (Completeness)For every entailment ϕ1, . . . , ϕn |= ψ that holds, there exists a proof of thesequent ϕ1 . . . , ϕn � ψ using the presented proof rules.

In the introduction we have argued that propositional logic is not capableof expressing all formulas of predicate logic. Now is the time to pay the pricefor that increase in expressiveness. There is an informal tradeoff between theexpressiveness of a logic and its computational complexity. In other words, themore expressive a logic is, the harder it becomes to solve the decision problem.In contrast to propositional logic, predicate logic is not decidable. Validity is astatement over all models of a formula. Intuitively, predicate logic is undecid-able, because a predicate logic formula typically has infinitely many models. Apropositional formula with n atomic propositions has 2n , and thus only finitelymany, models (truth assignments). Recall that the proof of the decidability ofpropositional logic (Theorem 3) relied crucially on this fact.

Theorem 6 (Decidability)There is no mechanical procedure, that when given a sequent as input, alwaysterminates, and outputs “yes” if the sequent is provable, and “no” otherwise.

Note, however, it can be shown that validity for predicate logic is semi-decidable, that is, there is a procedure that when given a valid predicate logicformula always terminates with output “Yes”. However, when the input is notvalid, the procedure may run forever. The proof of this property is beyond thescope of these notes. Informally, it relies on the fact that the set of all possi-ble models of a predicate logic formula, although infinite, can be enumeratedsystematically.

The first person to show that predicate logic is sound, complete, and un-decidable was the Austrian logician Kurt Godel. Godel is most famous for hisIncompleteness Theorem (published in 1931) which says that in any logic strongenough to encode the basic arithmetic (that is, natural numbers with addition,subtraction, multiplication, and division), there are always formulas that cannotbe proved or disproved with the rules of the logic. The Incompleteness Theo-rem ended a hundred years of attempts to establish logics in which the wholeof mathematics could be dealt with.

Chapter 3

Theorem provers, SATsolvers, and proof checkers

The primary purpose of a theorem prover is to formally derive a new formulaf from an existing set of formulas {f1, . . . , fn} using the rules of the logic. Inother words, the prover checks if

f1, . . . , fn � f

is valid. Theorem provers usually work with predicate logic.The overall result of the previous two chapters is that while propositional

logic can be analyzed fully automatically, predicate logic cannot. Thus, for everytool P that attempts to determine the validity or satisfiability of predicate logicformulas, there will be a formula f such that the execution of P on f will either

• produce the wrong result (loss of soundness), or

• run forever without ever producing an answer (loss of termination), or

• not be fully automatic, that is, require user interaction (loss of automa-tion).

In the face of this negative result, theorem provers typically maintain sound-ness and termination, but sacrifice automation. While the prover may be ableto prove a small class of simple formulas automatically, it will require userguidance on more complex formulas. Despite the absence of full automation,theorem provers can be very useful. They relieve the user from the bookkeepingnecessary to ensure soundness of the constructed proof. Moreover, the proofsearch mechanism of the prover may be able to construct large parts of theproof completely automatically, leaving only a few steps for the user to fill in.On the other hand, whenever the prover asks for help from the user, a lot ofexpertise and knowledge is required. Although there have been many successfuluses of theorem proving reported in the literature (e.g., [BBFM99]), the use oftheorem proving techniques is confined to a small group of experts.

47

48CHAPTER 3. THEOREMPROVERS, SAT SOLVERS, AND PROOF CHECKERS

A SAT solver checks the satisfiability of a formula. Given a formula, thesolver will search for a model in which the formula holds. If such a model canbe found, the solver will output it. If not, the solver will output an appropriatemessage.

A proof checker is like a theorem prover without proof search. Its sole pur-pose is to do the bookkeeping. The user has to find the entire proof.

The most popular theorem provers include PVS [SRI], Isabelle [Cam], HOL [GM93],ACL2 [KMM00b, KMM00a] and Never [ORA], the prover that the Z/Eves sys-tem is built on. Examples for SAT solvers are SPASS, CHAFF [MMZ01], andSATO [Zha97]. In class, we will see how, e.g., the SPASS theorem prover canbe used to solve Sudoku puzzles.

An example for a proof checker is Jape [Oxf]. We will use Jape in class tosee how a proof checker works.

Chapter 4

Bibliographic notes

The truth value semantics of propositional logic presented here and in everylogic book today was invented only about 160 years ago, by G. Boole [Boo54].The first account of predicate logic reasonably close to the ones used todaywas given by G. Frege in 1879 [Fre03]. Natural deduction was invented by G.Gentzen [Gen69], and further developed by D. Prawitz [Pra65].

The book by Huth and Ryan [HR00] gives a more detailed treatment of thematerial presented here and is highly recommended. It also discusses programverification, model checking and uses of modal logic.

49

50 CHAPTER 4. BIBLIOGRAPHIC NOTES

Part II

Object Modeling with Alloyand UML/OCL

51

4.1. OBJECT MODELING 53

Since the mid 1990ties, object-orientation has become very popular. Thereare many reasons for this development. A number of systems can naturally bethought of a collection of interacting objects. These objects often are relatedthrough a type hierarchy which is supported by inheritance and allows codereuse. Dynamic method dispatch (sometimes also called polymorphism) allowsthe invocation of different methods on different objects through the same pieceof code and thus helps writing succinct code.

How can the specification and design of object-oriented systems best besupported? Lots of processes for object-oriented systems development havebeen suggested. Each of these processes is centered around their own set ofmodels and employ their own notation. However, object models play a centralrole in most of them.

4.1 Object modeling

The object model is the key design representation in most object-oriented meth-ods. It shows what objects there are and how they are connected. In the require-ments analysis and specification phases, object models are essential for ensuringthat the right domain notions have been identified, and that the complexitiesof their relationships have been captured correctly. In the design phase, objectmodels are essential for ensuring that the system hangs together: that good ab-stractions have been chosen, and that invariants that relate objects are correctlyestablished.

This document will discuss two different approaches to the specification andanalysis of object models. The first approach is based on Alloy, a object model-ing notation developed at MIT [Jac06]. The second approach is based on UMLand OCL.

4.2 State diagrams and object models

Essentially, an object model describes the states a system is allowed to runthrough during execution. More precisely, it describes the structure of the states(e.g., What are the objects? What fields does an object have?), the relationshipsbetween state components (e.g., How are objects related to each other?), andthe constraints the states must obey (e.g., Can the field of this object be null?Can this object be shared, that is, pointed to, by several other objects? Whichinvariants do the objects have to satisfy?).

Before we can discuss object models in more detail, we must first describehow a single state will be represented.

4.2.1 State diagrams

A state can always be represented textually by listing the values of all compo-nents of the state. However, often a graphical notation is more concise. State

54

diagrams (sometimes also called object diagrams) provide a graphical descrip-tion of a single state or configuration. Suppose, for instance, we have a state sthat contains exactly two objects, one object a of class A, and another objectb of class B . Object a is accessed via variable aRef and object b via variablebRef. Furthermore, suppose that in s object a contains a field r whose value isobject b. The state diagram of s looks as follows.

ra

(A) (B)

b

aRef bRef

Objects are represented by ovals and arrows between ovals represent fields ofobjects. Field arrows are labeled with the name of the field. The diagram mayalso include the values of variables, shown as arrows from a variable name toan object. Optionally, ovals can be labeled with identifiers for talking aboutparticular objects, and show the type of an object in parentheses.

Consider, for instance, the following Java code implementing parts of a sim-ple file system.

class DirEntry {

Dir contents;

String name;

DirEntry (Dir c, String n) {

contents = c;

name = n;

}

}

class Dir {

String pn;

Dir parent;

Vector entries;

int num;

Dir (Dir p, String n) {

parent = p;

pn = n;

entries = new Vector();

num = 0;

}

void add (DirEntry c) {

entries.addElement(c);

num = num + 1;

}

}

Note that for simplicity, the above code does not account for files. A directorycan only contain other directories. We now can create directory objects using,for instance, the following code

Dir root = new Dir(null, "\");

Dir lib = new Dir(root, "\lib");

DirEntry e = new DirEntry(lib, "lib");

4.2. STATE DIAGRAMS AND OBJECT MODELS 55

which results in the state:

(Dir)

root

(String)(String) "\"0 e

pn namenum

(Dir)

(String) "\lib"

0num

pn

lib

(DirEntry)contents

"lib"

parent

We add the directory entry e into the root directory.

root.add(e)

which results in the state

(Dir)

root

entries elts[0] contents(Vector)

(String)

parent

(String) "\" "lib"1 e

pn namenum

(DirEntry) (Dir)

(String) "\lib"

0num

pn

lib

Primitive values are not considered objects. State diagrams distinguish primi-tive values from objects by not enclosing them in ovals. Often, we will want toelide objects such as the vector and only show the more interesting user definedobjects. For instance, the vector is part of the representation of the directoryobject, and a client that only calls the methods of Dir doesn’t see a Vectorobject. So, we might draw instead

(Dir)

root

(DirEntry) (Dir)contents

parent

0num

1 e

namenum

lib

"\" "\lib""lib"

entry[0]

pn pn

in which the abstract field arrow labeled entry from the Dir object to the Di-rEntry object hides the Vector object. Note that for the sake of brevity we alsohave elided the oval for String objects.

Many states can be created using the above code, but not all of them aredesirable. In this state two directories share the same path name.

56

(Dir)

(Dir)

"\"

d1

d2

pn

pn

0

0num

num

In the next diagram, we have a state in which all directory entries alwaysbelong to two directories.

(Dir)

(Dir)

(Dir)

(Dir)

(DirEntry)

(DirEntry)d1

d2

(Vector)entries

entries

contents

contents

name

name "lib"

"usr"

2

num

2

num

parent

parent

pn

pn

"/home/hans"pn

"/home/franz"pn

"/home/hans/lib"

"/home/hans/usr"

elts[0]

elts[1]

In the next state, a directory contains the same entry twice.

(Dir)

(Dir) (Vector) (DirEntry)entries

elts[0]

elts[1]

"/home/hans"

parent2

num

pn

contents

name "lib"

pn

"/home/hans/lib"

Whether these are in fact problematic depends on the intent of the designer ofthese classes. As we will see, the object model describes a set of allowed statediagrams by succinctly summarizing some code features and adding textualconstraints about potential clients of the code.

For instance, suppose we constrained instances of the directory class by thefollowing representation invariant:

The value of num is equal to the number of elements in entries.

Now, the second state shown above exemplifies a problematic situation. Supposetwo directories d1 and d2 share their entries. If an entry is added to d1, thenum counter of d1 is incremented and the num counter of d2 is not. After theaddition, directory d2 will thus violate the representation invariant.

4.2.2 Object models

Programs manipulate state. This state often has a complex structure, even if welimit our attention to that part of the structure that is visible to the user. For

4.3. OBJECT MODEL DESIGN AND ANALYSIS USING ALLOY 57

instance, a user of a file system needs to understand the purpose and structure offiles and directories and the relationship between them. We use object modelsto describe the potentially infinite set of program states a system is allowedto exhibit. You can think of an object model as representing a set of statediagrams. Many problems involve states or configurations, so the use of objectmodels is not confined to requirements specifications. In constructing an objectmodel, one is forced to answer a variety of important questions — a processthat often reveals inadequate understanding of the problem. More precisely, anobject model consists of

• a declaration of the sets, subsets, and relations

• a description of the relationships between the sets and relations

The result is a reasonably precise definition of which components and relation-ships make up the program state. Moreover, object models form a good basis forprogram design, since the designer is more likely to understand what to build.

4.3 Object model design and analysis using Al-loy

Alloy is an object modeling notation developed at MIT [Jac06]. This sectionserves as an introduction to object modeling in general, the Alloy notation, andthe Alloy Constraint Analyzer. We will use a running example to illustrate thevarious concepts. The software can be obtained from http://alloy.mit.edu

where also additional documentation can be found. We will be using Alloy4(release candidate 11).

4.3.1 Example: Graphs, trees, and lists

The Alloy GUI allows us to load Alloy specifications, and to edit, compile, andanalyze them.

Signatures and fields

After selecting New in the File pull-down menu, we input the following Alloyspecification into the editor window on the left (note that internal editor mustbe enabled in the Options menu).

module Graphs

sig Node {} // signature Node

sig Name {} // signature Name

sig Graph { // signature Graph

name : Name, // every Graph has exactly one Name

initial : set Node, // every Graph has 0 or more initial Nodes

58

curr : lone Node, // every Graph has 0 or 1 current Nodes

next : Node -> Node // every Graph has a successor relation

}

It declares three signatures called Node, Name and Graph. Comments start with//. A signature stands for a set of atoms. We cannot make any assumptionsabout the interpretation, structure and order of the elements of a signature.Top-level signatures (i.e., those that do not extend any other user-defined sig-nature) are mutually disjoint. The signature Graph signature declares fourfields.

• The field name associates a name with each graph, or, more precisely, itassociates an atom from signature Name with each atom from signatureGraph. Formally, name is total function that returns a Name for everyGraph.

• The field initial associates a set of nodes with each graph, or, more pre-cisely, it associates a set of atoms from signature Nodes with each atomfrom signature Graph. The Alloy keyword set is the power set constructor.Formally, initial is an unconstrainted relation between Graph and Node.

• The field curr associates with each graph either the atom null or exactlyone node. The notation lone A adds the atom null to the set of atoms A.Formally, curr is a possibly partial function from Graph to Node.

• The field next associates with each graph a binary relation next on nodes.The notation A→B denotes the cross product of the sets A and B , thatis,

A→B = {(a, b) | a ∈ A ∧ b ∈ B}.Formally, next is function from Graph to (Node→Node). That is, given agraph next returns a binary relation between Nodes. Note that the crossproduct is also often denoted by A× B .

Finding instances of an object model

An object model stands for a set of states. More precisely, every state thatsatisfies the constraints expressed in an object model M is said to be a state ora satisfying instance of M . We can use Alloy to find sample states of an objectmodel. By adding the lines

pred Show {}

run Show for 3

to our object model and save it (as graphs.als, for instance). The Alloy commandrun in graphs.als causes Alloy to find a state of the object model and is calledwith two arguments: the name of a predicate and a scope. Informally, thepredicate specifies additional constraints the state has to satisfy, while the scopelimits the number of candidate states Alloy has to consider. More precisely, the


scope places an upper bound on the number of atoms in each signature in theobject model. So, the command

run Show for 3

in the above example causes Alloy to attempt to find a state of the object modelin scope 3, that is, a satisfying instance that does not use more than three atomsfrom each signature.

We can ask Alloy to find a state of the above object model by clickingExecute and selecting Run Show for 3. Alloy will inform us that an instance(i.e., solution) was found. There are different formats to display the instance.The most interesting for us are Viz (visualization) and Tree. If we choose thevisualization, we see1

By clicking the Next button, more instances can be generated. Here isanother instance found by Alloy:

This instance has two graph objects (Graph0, Graph1), one name object (Name)and two node objects (Note0, Node1). The successor relation for Graph0 issuch that Node0 has itself as successor (indicated by the edge from Graph0 toNode0 labeled next[Node0]) and Node1 has Node0 as successor (indicated by theedge from Graph0 to Node0 labeled next[Node1]). The successor relation forGraph1 says that Node0 has two successors (Node0 and Node1) and Node1 hasno successor. In the Alloy GUI “Themes” can be used to customize the layoutof the instances and to make them more legible. Alternatively, an instance canbe represented in terms of a tree. Here is the tree for the instance above:

1By default, Alloy displays objects as rectangles; for us, however, objects will always beshown by ovals (ellipses) and classes as rectangles; to change Alloy’s visualization layout,choose Theme in the visualization window.

60

Note that signatures univ, Int, and seq/Int are always part of any model. Signa-ture univ contains all atoms, and thus is similar to, e.g., the root class Objectin Java. Signatures Int and seq/Int contain a subset of the integers. Both rep-resentations tell us that the instance consists of the following sets and relations:

Name of set Atoms contained in itGraph {Graph0, Graph1}Name {Name}Node {Node0, Node1}


Name of relation Tuples contained in itcurr {(Graph0, Node1), (Graph1, Node0)}initial {(Graph0, Node0), (Graph1, Node0)}name {(Graph0, Name), (Graph1, Name)}next { (Graph0, Node0, Node0),

(Graph0, Node1, Node0),(Graph1, Node0, Node0),(Graph1, Node0, Node1) }

To force Alloy to find a state with only one graph we add a constraint tothe predicate Show.

pred Show {

one Graph

}

The formula

one Graph

expresses that the set Graph must contain exactly one atom where one is one ofAlloy’s existential quantifiers. Alloy has five quantifiers: all, some, no, one, andlone. Alloy quantifiers are used the same way as quantifiers in predicate logic.For instance,

one x : X | fis true precisely if there exists exactly one atom in X such that replacing thatatom for x in f makes f true. Given a set S and an Alloy quantifier quant, thenotation

quant S

is short for

quant x : S | true.For instance, one S is true precisely if

quant x : S | true,that is, if S is a singleton set. After adding one Graph to predicate Show,example states found by Alloy include:

and

62

where, e.g., the edge from Graph to Node1 with label next[Node0] means thatNode1 is the successor of Node0 in Graph, i.e., (Graph, Node0, Node1)∈next.Internally, the compilation translates the object model M and the given scopeconstraint into a predicate logic formula fM . Solving M means, in logical terms,finding a satisfying model for fM , that is, finding a model of fM that makesfM true. A state of M is a satisfying model for fM . Note that the constraintsexpressed in the object model can be contradictory, that is, the formula fM canbe equivalent to false. In that case, the checker will not find a state and respondwith

No instance found. Predicate may be inconsistent. 0ms.

For instance,

pred Show {

one Graph // signature Graph has exactly one element and

no Name // signature Name is empty

}

is contradictory, because in our model, every graph has exactly one name. Thus,the moment we have at least one graph, we also have at least one name.

Checking properties of an object model

Assertions are used to check properties of an object model. For instance, afteradding

assert CurrAtMostSingleton {

// every graph has at most one current Node

all g : Graph | lone g.curr

}

to graphs.als and

check CurrAtMostSingleton for 3

the analysis checks that in every instance of the model in scope 3, the fieldcurr contains at most one element. In general, lone x : X | f is true preciselyif either there is no x in X that makes f true, or there is exactly one such xin X . Consequently, given a set S , lone S holds if and only if S has at mostone element. Note that in assertion CurrAtMostSingleton Alloy uses a “.” toreference the fields of an object. For now, we can think of the dot-notation asnavigation just like in, e.g., Java. The true meaning of “.” will be discussedlater.


When checking an assertion fA, the checker attempts to find a counter ex-ample for fA, that is, a state of the object model within the scope that violatesfA. Assertion fA is valid in the model if and only if such a counter example doesnot exist. More precisely, the checker shows fM → fA by showing that fM ∧¬ fAis unsatisfiable, that is, that fM ∧¬ fA has no solution. Consequently, fA is validin M if and only if fM ∧ ¬ fA does not have a satisfying instance.

In this case, Alloy responds with

No counterexample found. CurrAtMostSingleton may be valid. 20ms.

meaning that in the specified scope every instance of our Graphs object model issuch that a graph has at most one current node. Note that this is not surprisingat all, because the declaration curr : lone Node enforces this.

For another example, consider the assertion

assert NextIsTotal {

all g : Graph | all n : Node | some n.(g.next)

}

which expresses that every node in every graph has at least one successor. Moreprecisely, n.(g.next) is the set of nodes that can be reached in one step fromnode n using g’s transition relation, g.next . Thus, NextIsTotal requires this setto be non-empty for all graphs g and nodes n, that is, given any node n in anygraph g, n always has at least one successor node. In general, given a relationr : A→B and an element a : A, a.r denotes the relational image of a under r ,that is, it is the set of b : B that are related to a via r . Formally,

a.r = {b | (a, b) ∈ r}The assertion NextIsTotal is not valid in Graphs in scope 3 (or any scope).

Alloy produces the following counterexample

in which Node1 does not have a successor.The assertion

assert AllNodesAreReachable {

all n : Node | some g : Graph | n in (g.initial).*(g.next)

}

also is invalid. It expresses that for every node n, there exists a graph g, suchthat n can be reached from the initial nodes of g by following the next relationzero or more times. Formally, ∗ is a relational operator, that, when given abinary relation r : A→A builds the reflexive and transitive closure of r , that is,∗r is the relation

64

∗r =⋃

i=0ri

where r0 is the identity relation over A and r i+1 = r .r i and r .s denotes rela-tional composition. Consequently,

(n0, nk) ∈ ∗(g.next)if and only if nk can be reached from n0 by using next zero or more times, that is,if n0 = nk or there exist n1, . . . ,nk−1 such that (ni−1, ni) ∈ r for all 1 ≥ i ≥ k .Thus, (g.initial).∗ (g.next), for instance, stands for the set of all nodes that canbe reached from one of g’s initial nodes using g.next , g’s transition relation.Finally, n ∈ (g.initial). ∗ (g.next) expresses that n is reachable from the initialstates of g.

When analyzing assertion AllNodesAreReachable, the checker produces thefollowing counter example:

In this instance, the graph has no initial node and an empty successor re-lation. Thus, Node is not reachable from any of the initial nodes of the graph.More precisely, we have

(Graph.initial).*(Graph.next) = {}

Invariants

We want to eliminate isolated nodes and force every node in a graph to bereachable from the initial nodes. To this end we add the following fact

fact {

all g : Graph, n : Node | n in (g.initial).*(g.next)

}

to our model. Facts, also called invariants, enforce all states of a model tosatisfy a given property, that is, the checker will only consider those statesthat satisfy the facts. Consequently, after adding the above fact, the assertionAllNodesAreReachable now is valid in the model Graphs in scope 3.

Facts can be incorporated into signature declarations. This allows a furthernotational simplification.

sig Graph {

name : Name,

initial : set Node,

curr : lone Node,

next : Node -> Node

}{

all n : Node | n in initial.*next

}


Contraints attached to signature declarations need to be read slightly differentlythan the “stand-alone” facts that we have been considering so far. Given

sig A {...}{f}

constraint f is equivalent to

all this : A | f’

where f ′ is just like f except that each occurrence of a field g in f or oneof its supertypes is replaced by this.g. To prevent a field name from beingexpanded like this, you can prefix it with “@”. For example, the signatureabove is equivalent to

sig Graph {

name : Name,

initial : set Node,

curr : lone Node,

next : Node -> Node

}{

all g : Graph | all n : Node | n in (g.@initial).*(g.@next)

}

After also adding a fact saying that current nodes better be reachable

fact CurrentNodesAreReachable {

all g : Graph | g.curr in (g.initial).*(g.next)

}

Alloy finds the following instance

After projecting on the object Graph, the connections between nodes in theinstance become more legible:

66

Extension

A signature can extend another signature. For instance, the Graph signaturecan be extended into a signature for acyclic graphs.

sig AcyclicGraph extends Graph {

}{

no n : Node | n in n.^next

}

pred Show {

one Graph

one AcyclicGraph

}

where the quantifier no expresses that no node satisfies the formula that followsand the relational operator ^next denotes the transitive closure of next . Givena binary relation r : A→A, the transitive closure ^r is the relation

^r =⋃

i=1ri

Thus,

n.^next

is the set of all nodes that can be reached from n in one or more steps using thenext relation. The fact

no n : Node | n.^nextexpresses that no node is its own successor. In general, the formula no x :X | f holds if and only if there is no atom in X that makes f true. Given twosignatures, S and subS , the clause subS extends S expresses a subset relationship.More precisely, all atoms in subS also are atoms in S. For instance, every atomin AcyclicGraph also is an atom in Graph. However, not every atom in Graphalso is in AcyclicGraph. Note that subsignatures of a signature are mutuallydisjoint (just like “top-level” signatures). So, in, e.g.,

sig A {}

sig B {}

sig A1 extends A {}

sig A2 extends A {}

A and B are disjoint, and so are A1 and A2, but we cannot conclude that A1+ A2 = A. A check of this new model with the assertion

assert Acyclic {

all d : AcyclicGraph, n : Node | n !in n.^(d.next)

}

where ! denotes negation, shows that the model is correct and that all statesof the model are indeed acyclic.

We now extend acyclic graphs further into trees using


sig Tree extends AcyclicGraph {

root : initial

}{

all n : Node | lone n.~next

}

where ~r denotes the inverse of r , that is,

~r = {(b, a) | (a, b) ∈ r}.The specification says that trees are acyclic graphs that have one distinguishedinitial node called root, and whose nodes have at most one predecessor, that is,

lone n.~next

has at most one element.

An inconsistent object model

In the current model, two trees may share nodes. For instance, the following isan instance of our model:

In other words, while a node can have at most one predecessor in the same tree,it can more than one predecessor in other trees. To remedy this situation, weadd a subsignature with a constraint saying that no node is reachable from theroots of two trees.

sig TreeNoSharing extends Tree {

}{

all t1, t2 : TreeNoSharing | no (t1.@root).*(t1.@next) &

(t2.@root).*(t2.@next)

}

where & denotes set intersection. There is a problem with the above specifica-tion. When we ask the checker to find a satisfying instance using

pred Show {

some TreeNoSharing

}

run Show for 3

we find that our specification now is contradictory, because the checker respondswith

No instance found. Predicate may be inconsistent. 39ms.

68

The problem is that if t1 and t2 are the same there are nodes that arereachable from the root of t1 and t2. We forgot to say that t1 and t2 must bedifferent.

all t1, t2 : TreeNoSharing | t1 != t2 =>

no (t1.@root).*(t1.@next) &


or

all t1 : TreeNoSharing, all t2 : TreeNoSharing - t1 |

no (t1.@root).*(t1.@next) &


where => and - denote implication and set difference respectively.

Functions

Functions allow us to state the above property more legibly and succinctly.

fun reachableNodes[g : Graph] : set Node {

{n : Node | n in (g.initial).*(g.next)}

}


}{

all t1, t2 : TreeNoSharing |

t1 != t2 => no (reachableNodes[t1] & reachableNodes[t2])

}

The notation {a : A | f } denotes the set of all atoms in A that satisfy f andis commonly called set comprehension. While set comprehension is very usefulin general, in the above case it is not necessary. The definition

fun reachableNodes[g : Graph] : set Node {

(g.initial).*(g.next)

}

is equivalent yet shorter.Rather than defining a function that returns the nodes reachable in a graph,

we could have defined a predicate reachable(g, n) that returns true if and onlyif node n is reachable in graph g.

pred reachable[g : Graph, n : Node] {

n in (g.initial).*(g.next)

}


}{

all t1, t2 : TreeNoSharing |

t1 != t2 => no n : Node | reachable[t1, n] && reachable[t2, n]

}

where && denotes logical conjunction. Note the predicate above does not containa declaration of a result type.

The whole Alloy model for the running example used in this section is shownin Figure 4.1.


module Graphs

sig Node {}

sig Name {}

sig Graph {name : Name, // every Graph has exactly one Nameinitial : set Node, // every Graph has 0 or more initial Nodescurr : lone Node, // every Graph has 0 or 1 current Nodesnext : Node -> Node, // every Graph has a successor relation

}

fact GraphFacts {// all nodes belong to at least one graphall n : Node | some g : Graph | n in (g.initial).*(g.next)// current nodes belong to a graphall g : Graph | g.curr in (g.initial).*(g.next)

}

sig AcyclicGraph extends Graph {}{

no n : Node | n in n.^next}

sig Tree extends AcyclicGraph {root : initial

}{all n : Node | lone n.~next

}

sig TreeNoSharing extends Tree {}{all t1, t2 : TreeNoSharing | t1 != t2 =>

no (reachableNodes[t1] & reachableNodes[t2])}

fun reachableNodes [g : Graph] : set Node {(g.initial).*(g.next)

}

assert CurrAtMostSingleton {all g : Graph | lone g.curr

}

assert NextIsTotal {all g : Graph | all n : Node | some n.(g.next)

}

assert AllNodesAreReachable {all n : Node | some g : Graph | n in (g.initial).*(g.next)

}

assert Acyclic {all d : AcyclicGraph, n : Node | n !in n.^(d.next)

}

pred Show() {some TreeNoSharing

}

run Show for 4check CurrAtMostSingleton for 4check NextIsTotal for 4check AllNodesAreReachable for 4check Acyclic for 4

Figure 4.1: Alloy model used as running example

70

Functions and predicates can also be used for the specification of operations.Here is the specification of an operation that adds a new node as the root ofa tree; the old root becomes the one and only child; additionally, the new rootbecomes the current node.

fun addNodeAtRoot[before, after : Graph, n : initial] {

after.root = n

after.curr = n

(after.root).(after.next) = before.root

after.name = before.name

}

Scalars are singletons

Next, let us specify lists as trees without sharing that have a last node andwhose nodes have at most one successor.

sig List extends Tree {

last : Node

}{

all n : Node | lone n.next

// last = {n : Node | no n.next} // explicit definition

no last.next // implicit definition

}

The specification shows an explicit and implicit definition of last . Both def-initions are equivalent. However, the implicit definition is shorter and thuspreferable. The explicit definition is surprising. The field last is declared as avariable ranging over nodes. However, the explicit definition assigns a singletonset to it. Alloy’s type checker does not complain, because Alloy does not distin-guish between the two. In other words, scalars are singleton sets in Alloy. Moreprecisely, the declaration a : A declares a field named a containing singletonsets of atoms of A. If the specification forces a to take on a non-singleton setas a value, the specification will be contradictory and thus have no satisfyinginstances. Consider, for example, the following model.

module Test

sig A {

}{

some a1, a2 : A | a1 != a2 // A has at least 2 elements

}

sig B {

a1, a2, a3, a4 : A

}{

a1 = a2 // ok

a2 = {a : A | a in a1} // ok

// a3 = A // contradiction

// a4 = {a : A | a in a1 && a !in a1} // contradiction

}

pred Show {

some B // show state with at least one atom in B


}

run Show for 3

The declaration b : set B removes the singleton constraint and allows b to rangeover sets of atoms of B of all sizes. Similarly for a declaration c : lone C .

We can now properly explain the meaning of in. in always denotes thesubset relation. The constraint

reachableNodes[t1] in reachableNodes[t2]

for instance, says that the reachable nodes of tree t1 are a subset of the reachablenodes of tree t2. Consider the constraint

all n : Node | all t : Tree | n in reachableNodes[t]

Here, in can be read as “is element of”. However, since the scalar n denotes asingleton set containing n, it also denotes subset.

The main advantage of treating scalars as singletons is notational uniformity.For instance, the relational image e.r of an expression e under a relation r canbe treated the same way regardless of whether e evaluates to a scalar or a set.

Multiplicity constraints

Finally, doubly linked lists are lists with a partial function prev that is theinverse of the next function.

sig DoublyLinkedList extends List {

prev : Node lone -> lone Node

}{

prev = ~next

}

where lone denotes a multiplicity constraint. In general, the source end and thetarget end of every binary relation r : A→B can be decorated with multiplicityconstraints as follows r : A m→n B . The meaning of the constraint m on thesource end is that every element in B is reached through r from m elements inA. The meaning of the constraint n on the target end is that every element inA is related to n elements in B through r . There are four different choices form and n: set, lone, one, and some. Their meaning is as follows:

set zero or morelone zero or oneone exactly onesome one or more

Multiplicity set is the default and does not need to be mentioned explicitly. Inother words, r : A set→ set B is the same as r : A → B . Multiplicities lone andone can be used to, e.g., turn a relation into a function, or to make it injective orsurjective. For instance, the constraints in r : A → one B and s : A → lone Bmake r and s total and partial functions respectively. t : A one →B is aninjective (one-to-one) relation. The declaration pred : Node lone → lone Nodeexpresses that every node has at most one predecessor (lone at target end) andthat every node is the predecessor of at most one node (lone at source end).

72

How to represent Alloy object models graphically

Certain aspects of an Alloy model can easily be represented graphically byusing a notation familiar from UML class diagrams. Extension is shown usingan arrow with a hollow head

A Bsig B {}sig A extends B {}

whereas binary relations are shown using arrows with a standard head.

A Br

sig B {}sig A { r : set B}

The Alloy GUI does not quite stick to this convention and always uses a filledarrow head with extension arrows marked by a label. For instance, selectingExecute | Show metamodel in the GUI, Alloy generates the following graphicalrepresentation of the object model in Figure 4.1.

It is not obvious how to display relations of arity greater than 2. Alloyadopts the convention that a relation r : A1 → (A2 → . . . (An−1 → An) . . .) isshown as an arrow from A1 to An with label r [A2, . . . ,An−1] as in, for example,

A C

sig B {}sig A { r : B −> C}

r[B]

sig C {}

and some of the previous models.While we cannot represent all textual constraints graphically, multiplicity

constraints can easily be shown (as in, e.g., UML class diagrams). For brevity,we adopt the following notation:


Symbol Meaning∗ zero or more? zero or one! exactly one+ one or more

How to represent graphical multiplicity constraints textually

Sometimes, we are given a graphical representation of an object model (in, e.g.,Alloy or UML notation), and then need to create the corresponding textualrepresentation in Alloy. While this is straight-forward for the most part, dealingwith multiplicities requires some care. We will show the translation by example.

• Dealing with multiplicities on the target end of a relation. Thekeywords lone and set help us here. The Alloy model

BEDf4 f2

+ ?

f1

f3 *

*

A

*

C

!

*

*

is represented as

sig A {}

sig B {}

sig C {}

sig D {}

sig E {

f1 : A // ’one’ on target of f1

f2 : lone B // ’lone’ on target of f2

f3 : set C // ’set’ on target of f3

f4 : some D // ’some’ on target of f4

}

Note that the encoding of + in the declaration of f4 requires an additionalfact that prevents f4 to be null.

• Dealing with multiplicities on the source end of a relation. Allnon-trivial multiplicity constraints at the source end of a relation need tobe expressed by facts. The Alloy model

74

BEDf4 f2

+ ?

f1

f3 *

!

A

?

C

!

*

+

is represented as

sig A {}

sig B {}

sig C {}

sig D {}

sig E {

f1 : A // ’one’ on target of f1

f2 : lone B // ’lone’ on target of f2

f3 : set C // ’set’ on target of f3

f4 : some D // ’some’ on target of f4

}

fact Multiplicities {

all a : A | one a.~f1 // ’one’ on source of f1

all b : B | lone b.~f2 // ’lone’ on source of f2

all d : D | some a.~f4 // ’some’ on source of f4

}

4.3.2 Summary of Alloy language

Expressions

Every Alloy expression denotes (evaluates to) a relation, that is, a set of tuples(a0, . . . , an). The following special cases arise: The relation denoted by e maycontain

• nothing. In that case, e represents the empty relation ∅.• a single unary tuple, e.g., (a). In that case, e can be thought of just theatom (or, scalar, value) a.

• more than one unary tuple, e.g., (a0), (a1), (a2). In that case, e can bethought of as the set {a0, a1, a2}.

• one or more non-unary tuples, e.g., (a1, . . . , an) for n ≥ 2. In that case,e represents an n-ary relation. Every tuple in a relation has the samelength.

As in programming languages (like Java, for instance), Alloy expressions arebuilt from constants, variables and operators. A signature is a constant in


Alloy and stands for a set of atoms. Signature Node, for instance, stands for aset of nodes. Alloy offers the standard operators (union, intersection, difference)on expressions (that is, sets):

+ union& intersection- difference

We have already seen how to obtain the relational image s .r of a set s : set Aunder a relation r : A→B :

s .r = {b : B | ∃ a : s . (a, b) ∈ r}Note that s .r can also be written as r [s ] in Alloy.

Turns out, relational image is a special case of a more general operation onrelations: relational composition. Two tuples

(a1, a2, . . . , an−1, an)

and(b1, b2, . . . , bm−1, bm)

can be composed, if an = b1. In that case, their composition is the tuple

(a1, a2, an−1, b2, . . . , bm−1, bm).

The relational composition s .r of two relations s and r is the set of all com-positions of tuples in s and r . If s is a set of atoms and r is a relation, s .rspecializes to relational image discussed above. If, however, s is a relation andr is a set of atoms, s .r denotes the relational pre-image of r under s , that is,

s .r = {a : A | ∃ b : r . (a, b) ∈ s}We have seen two closure operations: transitive closure and reflexive and

transitive closure. The transitive closure ^r of a binary relation r : A→A is thesmallest relation that contains r and is transitive. The reflexive and transitiveclosure ∗r is the smallest relation that contains r and is reflexive and transitive.

^r = r + r .r + r .r .r + . . . =⋃

i=1ri transitive closure

*r = idA + ^r =⋃

i=0ri reflexive and transitive closure

where r : A→A for some A and idA is the identity relation on A, that is,idA = {(a, a) | a ∈ A}.

The transpose (or inverse) of a relation r reverses the order of all tuples inr :

~r = {(an , . . . , a1) | (a1, . . . , an) ∈ r}The product s→r of two relations s and r is obtained by taking every tuple

in s and concatenating it with every tuple in r . That is,

s→r = {(a1, . . . , an , b1, . . . , bm) | (a1, . . . , an) ∈ s ∧ (b1, . . . , bm) ∈ r}

76

Formulas

The smallest boolean expressions, i.e., formulas, are obtained by comparing tworelations. s in r is true if and only if every tuple in s also is in r . s = r is true ifand only if s in r and r in s . Alloy contains the standard boolean connectivesfamiliar from predicate logic. It only uses ASCII symbols to represent them.Let f and g be formulas:

!f negation: not ff && g conjunction: f and gf || g disjunction: f or gf => g implication: if f then g

f <=> g equivalence: f if and only if gall x : T | f universal quantification: f true for all x in Tsome x : T | f existential quantification: f true for at least one x in Tone x : T | f f true for exactly one x in Tlone x : T | f f true for at most one x in Tno x : T | f f true for no x in T

Note that quantifiers can be applied to expressions, too:

all e e contains every elementsome e e contains at least one elementone e e contains exactly one element

lone e e contains at most one elementno e e contains no element

Syntax and semantics of Alloy Kernel

To finish off the discussion of the Alloy language itself, we now present the syntaxand semantics of the Alloy kernel language (i.e., its smallest core language) aspresented in [Jac06].

The syntax of formulas in the Alloy kernel is:

f ::= expr in expr | expr = expr | elementary formulas!f | f && f | composed formulasall var : expr | f quantified formulas

Expressions are defined by:

expr ::= rel | var | none | expr binop expr | unop exprbinop ::= + | & | - | . | ->unop ::= ~ | ^

where rel represents free relation variables (i.e., the names of signatures andfields) and var represents variables bound by quantifiers. Note that constantsuniv (denoting the union of the top-level signatures in the model), and iden(denoting the identity relation over that union) are not defined here, becausethey depend on the declarations in a particular model.


Back in Section 1.2 on page 4, we defined an evaluation function evall whichmapped propositional logic formulas to a truth value with the help of a truthassignment l . We will do a similar thing now. However, the role of the truthassignment will be played by an Alloy instance i . More precisely, we define afunction

evalFi : Formula → Boolean

where i is an instance, i.e., a function that assigns a relation to every relationname used in the formula

i : RelationName → RelationValue

The evaluation of formulas also requires the evaluation of expressions (similarto the function evalM,l defined in Section 2.2 on page 33 to evaluate terms).Therefore, we will also need a function

evalEi : Expression → RelationValue

Let us start with the definition of evalFi . The definition proceeds, as usual,by structural induction over kernel formulas.

evalFi(!f ) = ¬ evalFi(f )

evalFi(f1 && f2) = evalFi(f1) ∧ evalFi(f2)

evalFi(p in q) = evalEi(p) ⊆ evalEi(q)

evalFi(p = q) = (evalEi(p) = evalEi(q))

evalFi(all x : e | f ) = evalFi[x �→v1](f ) ∧ . . . ∧ evalFi[x �→vn ](f ) where

{v1, . . . , vn} = {vi ∈ evalEi(e) | #vi = 1}The meaning of kernel formulas is as discussed previously. For instance, theoperator in is just conventional subset. Also, an instance i makes formulaall x : e | f true if f is true in all instances i [x �→ vi ] which map x to a scalarvalue (i.e., a singleton set) in evalEi(e).

Now, we define evalEi .

evalEi(none) = ∅evalEi(r) = i(r)

evalEi(p+q) = evalEi(p) ∪ evalEi(q)

evalEi(p&q) = evalEi(p) ∩ evalEi(q)

evalEi(p-q) = evalEi(p)\evalEi(q)

evalEi(p.q) = {(p1, . . . , pn−1, q2, . . . , qm) |(p1, . . . , pn) ∈ evalEi(p) ∧ (q1, . . . , qm) ∈ evalEi(q) ∧ pn = q1}

evalEi(p->q) = {(p1, . . . , pn , q1, . . . , qm) |(p1, . . . , pn) ∈ evalEi(p) ∧ (q1, . . . , qm) ∈ evalEi(q)}

evalEi(~p) = {(p2, p1) | (p1, p2) ∈ evalEi(p)}evalEi(^p) = {(x , y) | ∃ p1, . . . , pn .(x , p1), (p1, p2), . . . (pn , y) ∈ evalEi(p)}

The meaning of expressions is as discussed previously.

78

4.3.3 Using Alloy to specify operations and traces

Predicates can be used to formalize the effect of an operation by capturing itspre-conditions and post-conditions. Consider, for instance, the Alloy specifica-tion of a stack in Figure 4.2. The facts express, respectively, that a stack isnever empty after a push and that a pop immediately after a push yields theoriginal stack and the pushed data object.

Note how operations push and pop take two stacks as parameters. The firstis used to represent the stack before executing the operation. The second isused to represent the stack after executing the operation. These two parametersthen allow the expression of pre-conditions (e.g., !isEmpty[before]) and post-conditions (e.g., after.head.data = d).

Alloy’s util library offers a parametric (generic) signature ordering whichallows elements of a signature to be put into a linear order which can be accessedvia the functions first, last, and next. ordering can be used to specifytraces, that is, linear sequences of “snapshots” with each snapshot arising fromthe previous via the application of some operation. For instance,

module Traces

open util/ordering[Stack]

pred init[s:Stack] {isEmpty[s]}

fact traces {

init[first]

all s:Stack-last |

let s’=next(s) |

some d:Data | push(d,s,s’) or pop(s,s’,d) or (top(s,d)&&s=s’)

}

specifies sequences of stacks which arise from the successive use of pop, push,or top. Predicate init[s] says that s should be empty. Fact traces expressesthe constraints that make the ordering an execution trace: init[first] saysthat the stack should be empty initially (i.e., in the first state). What follows isa constraint saying that the next stack s’ in the trace arises from the previouss via the application of one of the three stack operations.

4.3.4 Example: A simple file system

We now return to the file system example used in Section 4.2.1. We will usethis example to introduce the graphical representation of object models in Alloy.This example is taken from [Jac06].

Sets and subsets

Each box in an object model denotes a set of objects. If the object modeldescribes a computer system to be developed, each box typically is implementedby a class. In that case, the set of objects denoted by the box coincides with theobjects of that class and we will use the terms “set” and “class” synonymously.That is, when a box labeled A in an object model is referred to as class A, we


module Stacks

sig Data {}

sig Node {

data : Data

succ : lone Node

}

sig Stack {

head : lone Node

}

pred isEmpty[s : Stack] {

no s.head

}

pred push[d : Data, before, after : Stack] {

after.head.data = d

after.head.succ = before.head

}

pred top [s : Stack, d : Data] {

!isEmpty[s]

d = s.head.data

}

pred pop [before, after : Stack, d : Data] {

!isEmpty[before]

after.head = before.head.succ

d = before.head.data

}

fact NeverEmptyAfterPush {

all s1, s2 : Stack | all d : Data | push[d, s1, s2] => !isEmpty[s2]

}

fact PopAfterPush {

all s1, s2 : Stack | all d : Data | push[d, s1, s2] => pop[s2, s1, d]

}

fact NoCycles {

all s : Stack | no n : (s.head).*succ | n in n.^succ

}

pred Show {

some s1, s2, s3 : Stack | some d1, d2 : Data | push[d1, s1, s2] &&

push[d2, s2, s3]

// some s : Stack | some d : Data | push[d, s, s]

}

Figure 4.2: Textual constraints of a stack

80

really mean the set of objects implemented by class A. In the object model, anarrow with a closed head from a box labeled A to a box labeled B , denotes setinclusion: every object of set A also is contained in set B . A is a subset of B .If the sets are implemented with two classes A and B , A is a subclass of B .

A Bsig B {}sig A extends B {}

The arrowhead indicates whether the subset contains all elements of its superset(the arrowhead is filled) or just some elements of the superset (the arrowhead isunfilled). Subsets can share an arrow; in this case, they are mutually disjoint,and the arrowhead indicates whether or not their union exhausts the superset.Subsets that don’t share an arrow are not necessarily disjoint. The cardinalityof a set can be constrained. This can be done by writing the cardinality of theset within the corresponding box. For example, a “!” means that the set hasexactly one object. A “?” expresses that the set contains at most one object.

Consider, for example, the figure below showing a simple object model of apart of a file system. In contrast to the code in Section 4.2.1, this file systemwill allow directories to contain not only other directories but also files.

FSObject

Dir

sig FSObject {}sig Name {}sig File extends Object {}sig Dir extends Object {}fact FileDirPartition { no File & Dir File + Dir = Object}sig Root extends Dir {}{ one Root}sig Cur extends Dir {}{ lone Cur}

Root

Curr ?

!

File

The box labeled File represents the set of all objects of a class called File.The class Dir has two subclasses Root and Curr. The subclass Root containsexactly one object representing the root directory. Classes with exactly oneobject are called singletons. The subclass Curr contains at most one objectrepresenting the current directory. Note that this means that there may beno current directory. Also, since Root and Curr do not share an arrow, theyneed not be disjoint. Consequently, the root directory may also be the currentdirectory. An FSObject can either be a file or a directory. These two subclassesare disjoint and exhaust their superclass.

Relations

Depending on whether we consider a single state or a set of states, relationseither connect objects or classes.

Between objects In Section 4.2.1 we have already seen how a field of anobject gives rise to a relation and how that relation is represented graphically.More precisely, the field arrows in state diagrams express a relation between theobject containing the field and the object contained in the field. The name of


the field is the name of the relation. For instance, consider again the followingstate diagram

a br

The field r relates the object a to object b, that is, we have a relation r thatconnects a to b, or, more formally, (a, b) ∈ r .

Between classes Suppose that in every execution state, every object of classA contains a field r whose value is an object of class B . This relationshipbetween the classes is expressed by a relation r that relates A to B , that is,(A,B) ∈ r . Relations between classes are described in the object model. Graph-ically,

A Br

sig B {}sig A { r : set B}

While a state diagram describes a single state, an object model thus describesa set of states. More precisely, the object model specifies a set of states byimposing the constraint that each object in the state belong to one of the objectmodel boxes, and that the field arrow in the state diagram connect objects fromthe appropriate boxes. If part of the requirements specification, an object modelthus summarizes the set of permissible states. Consider, for instance, the model

String

parent

Dir DirEntrycontent

entries

namenum pn

int

num : set int,sig Dir {sig String {}

parent : set Dir, entries : set DirEntry, pn : set String }sig DirEntry { content : set Dir, name : set String}

The arrow labeled pn from Dir to String expresses that every object of the Dirclass has a field called pn whose value is an object of class String. Note thatAlloy does not contain any build-in datatypes, that is, the String class must bedeclared as a domain like Dir and DirEntry. For instance, this object modelallows this state

(Dir) (Dir)(DirEntry)

parent

entries content

"/home/hans""hans""/home"

0

pnpn name1

num

num

82

but not this state

(Dir) (Dir)

1 "/hans"0"/"

parent

pnnumpnnum

entries

or this state

(Dir) (DirEntry) (DirEntry)contentcontent

"hans""/home"

pn name1

name

entries

"mail"

num

Note that the model above does not place constraints on the relative number ofobjects and thus also allows this state

(Dir)

"/home/franz"

"/home/hans"

pn

pn

which the code in Section 4.2.1 clearly rules out (pn would have to be an arrayor vector for this state to be feasible).

Multiplicities

So far, the model does not allow us express that, for instance, a directory objectmay contain several entries or that every entry belongs to exactly one directory.Let’s add multiplicities to our file system model.

String

parent

!*?

! *

?Dir DirEntry

content

entries*

pnname

!

?

!

int!

num!

parent : lone Dir, entries : set DirEntry, pn : String}{ lone this.~content}sig DirEntry { content : Dir, name : String}{ one this.~entries}

num : int,

sig String {}{ lone this.~pn}sig Dir {

The meaning of the multiplicities at the target end of the relations is as follows:

• From Dir to DirEntry: The ∗ at the target end of the entries arrow tellsus that in any legal state, there may be zero or more DirEntry objectsassociated with each Dir object, that is, a directory can contain zero ormore directories. Note that the multiplicity ∗ is chosen by default.


• From Dir to String : The ! at the target end of the pn arrow tells us thatin any legal state, there is exactly one String object associated with eachDir object, that is, every directory has exactly one path name. Note thatthis implies that the pn field in a Dir object can never be null. Similarlyfor the name relation.

• From Dir to Dir : The ? at the target end of the parent arrow tells us thatin any legal state, there is zero or one Dir object associated with each Dirobject. Thus, the parent field in a Dir object may be null.

The meaning of the multiplicities at the source end of the relations is as follows:

• From Dir to DirEntry: The ! at the source end of the entries arrow tellsus that in any legal state, every DirEntry object is contained in exactlyone directory. Consequently, directory entries cannot be shared by severaldirectories, that is, different directory objects must have different elementsin entries .

• From Dir to String : The ? at the source end of the pn arrow meansthat a String object will represent the name of at most one Dir object.Consequently, a String object can represent the path name of at most onedirectory. In other words, path names cannot be shared.

• From Dir to Dir : The ∗ at the source end of the parent arrow tells us thatin any legal state, a directory can be the parent of zero or more directories.

• From DirEntry to String : The ∗ at the source end of the name arrow tellsus that in any legal state, each String object may be the name of zero ormore DirEntry objects, that is, different directory entries can share thesame name (for instance, many user directories contain a directory withthe name “mail”).

Multiplicity constraints may or may not be enforced by code. For instance,if the code allows the name field of a directory entry to be set to null, themultiplicity constraint on the name relation would be violated. To enforce thisconstraint in code, we could, for instance,

• declare the name field as private. This would ensure that the name fieldis only set by the DirEntry constructor and never by code outside theDirEntry class.

• ensure that the DirEntry constructor never sets name to null.

Note, however, that not every constraint in the model can be enforced in thecode. Consider, for instance, the non-sharing requirement of directory entries,that is, every directory entry must belong to exactly one directory (the ! atthe source end of the entries relation). Assuming the code in Section 4.2.1, thisconstraint cannot easily be enforced, because we cannot prevent the user fromcreating two directories that share an entry:

84

FSObject

Dir

Root ! Curr ? String

*?

File DirEntry

!

*

content

entries

*

!

*name

!

! *

parent

pnint

num

Figure 4.3: Graphical constraints of a simple file system in Alloy [Jac06]

Dir d1 = new Dir(null, "d1");

Dir d2 = new Dir(null, "d2");

DirEntry e = new DirEntry(null, "e");

d1.add(e);

d2.add(e)

To guarantee this constraint, we could, for instance, make entries cloneable andmodify the addmethod such that it always insert clones of the argument entries.

Figure 4.3 contains the graphical constraints of the file system.

Invariants

We will now list constraints on our simple file system that cannot be expressedgraphically.

The parent of a directory is the directory that contains an entry for it:

sig Dir extends FSObject {...}{

...

// A directory’s parent is the directory that has an entry for it

parent = this.~@contents.~@entries

// or parent = {d : Dir | this in (d.@entries).@contents}

...

}

This constraint rules out, for instance, the following state which is allowed bythe model and also the code presented in Section 4.2.1.


(Dir)

parent

parent

(DirEntry) (Dir)content

(DirEntry) (Dir)contententries[1]

entries[0]

The next constraint ensures that every directory except the root has exactlyone parent.

fact OneParent {

// all directories besides root have one parent

all d: Dir - Root | one d.parent

}

So far, there is nothing in our model that prevents a directory from contain-ing itself:

(DirEntry)(Dir)parent

content

entries[0]

Thus, we want to express that the root directory is an ancestor of every directoryexcept itself and that there are no cycles in an ancestor chain.


...

// A directory is not its own ancestor and every directory

// but the root has the root as ancestor

this !in this.^@parent

this != Root => Root in this.^@parent

...

}

This constraint implies that every directory in thef ile system either is the rootdirectory or is accessible from the root. A similar constraint limits the files inthe system:

sig File extends FSObject {...}{

...

// Every file has an entry in some directory

some d : Dir | this in (d.@entries).@contents

...

}

Together, the two constraints imply that every file system object is accessiblefrom the root. For a user this means that files not reachable from the rootcannot be used. For the implementor this means that, for instance, unreachableobjects can be garbage collected.

Here’s another constraint that ensures that directory entries are uniquelyidentified by their name.

86


...

// A directory contains at most one entry with a given name

all e1, e2 : entries | e1.name = e2.name => e1 = e2

...

}

The textual constraints of the final Alloy model of a simple file system aresummarized in Figure 4.4.

The constraints that we’ve written do not contain everything that is trueabout the system. Some facts are implied by the constraints. For instance, thefact that the root has no ancestor is implied by the above constraints.

The next and final constraint brings us to one of Alloy’s weaknesses. Wewant to express that the num field of a directory contains the number of entriesof that directory.


...

// num contains the number of entries

this.num = #(this.entries)

...

}

Unfortunately, the current version of Alloy only has the booleans as built-intype. In particular, there are no integers or natural numbers. Consequently,the above constraint cannot (easily) be expressed in Alloy. Note, however, thatit can easily be enforced in code. If the fields num and entries are declaredprivate, they can only be accessed through the add method which then ensuresthe above constraint.

4.3.5 Example: Family tree

Our running example of a file system models a computer system. In this exam-ple, an object model is used to describe family relationships (Figure 4.5). Theset Person has three subsets: Married, Man, and Woman. The sets Man andWoman are partition Person: Every person is either a man or a woman. Aperson may be associated with other persons through the parents and siblingsrelations. Every person has exactly one name. Every man has at most one wifeand every woman is the wife of at most one man. Every woman has at mostone husband and every man is the husband of at most one woman.

To obtain an adequate model of family trees, the graphical constraints inFigure 4.5 need to be complemented with the textual constraints in Figure 4.6.

4.3.6 Example: Air traffic control

In this example an object model is used to describe an organizational struc-ture. It describes how airspace is divided into sectors, and how controllers areassociated with aircraft.


sig File extends FSObject {

}

// Model of a simple file system

module FileSystem

sig FSObject {}

sig String {}{ lone this.~pn // path names are not shared

sig Dir extends FSObject {

entries : set DirEntry,

parent : lone Dir,

pn : String

}{ parent = this.~@contents.~@entries

// parent = {d : Dir | this in (d.@entries).@contents}

all e1, e2 : entries | e1.name = e2.name => e1 = e2

this !in this.^@parent

this != Root => Root in this.^@parent

sole this.~content // dirs are not shared

}

sig DirEntry {

name: String,

content : FSObject

}{ one this.~entries // every entry belongs to one directory

}

fact FileDirPartition {

no File & Dir

File + Dir = FSObject

}

sig Root extends Dir {

}{ one Root

no parent

}

sig Cur extends Dir {

}{ lone Cur

}

fact OneParent {

// all directories besides root have one parent

all d: Dir − Root | one d.parent

}

fun NonTrivial () {

some DirEntry

}

assert NoDirAliases {

// Only files may be linked (that is, have more than one entry)

// That is, all directories are the contents of at most one

// directory entry. Invalid!

all o: Dir | lone o.~contents

}

assert OneRoot {

one Root

}

run NonTrivial for 3

// check NoDirAliases for 3

// check OneRoot for 3

}{ some d : Dir | this in (d.@entries).@contents

}

Figure 4.4: Textual constraints of a simple file system in Alloy [Jac06]

88

Married Person Name

Man Woman

parents siblings

name

!

wife

husband? ?

? ?

Figure 4.5: Graphical constraints for family tree in Alloy

Center Controller

AircraftSector

controls

within

containscovers

worksFor

!

+

?

+ !

!

The model shows that there are centers, each of which contains one or moresectors. Air traffic controllers work for centers and cover sectors. An aircraft iscontrolled by a controller and flies within a sector. A controller works for at mostone center. A center contains at least one sector and each sector is contained byexactly one center. An aircraft is always exactly in one sector, that is, sectorsdon’t overlap or have gaps between them. Each aircraft is controlled by exactlyone controller. A sector is covered by at least one controller.

Invariants Our graphical model does not express that

• if an aircraft is flying in a sector, then it is being controlled by a controllerthat covers that sector.

• controllers only cover sectors contained by centers they work for.

Appropriate textual constraints would have to be formulated and added to themodel.

4.3.7 Example: Java

This example shows how an object model can be used to describe how variables,references and objects are related in Java programs. The model could thus forma useful part of a Java language description.


sig Person {

}

parents : set Person,

siblings : set Person,

name : Name

}

sig Man extends Person {

wife : lone Woman

sig Woman extends Person {

}

husband : lone Man

fact Partition {

Man + Woman = Person

}

fact MarriedBasics {

Married = Man.wife + Woman.husband // MB1

all p : Person | some p.wife iff p in (Man & Married) // MB2

all p : Person | some p.husband iff p in (Woman & Married) // MB3

}

run Show for 4

// check HusbandsWife for 3

// run Marry for 4

fun Show () {

some Man

some Woman}

pred Marry[wife, wife’: Man −> Woman, m : Man, w : Woman] {

m not in Married && w not in Married

m.wife’ = w

all p : Man−m | p.wife’ = p.wife}

// Partial model of a family tree

module Family

sig Name {}

sig Married extends Person {}

fact ParentsBasics {

}

all p : Person | lone (p.parents & Man) && sole (p.parents & Woman) // PB1

no p : Person | p in p.^parents // PB2

fact WifeIsInverseOfHusband {

wife = ~husband // WIH

}

all p, q : Person | q in p.siblings <=> (p.parents = q.parents) // DS

fact DefSiblings {

}

Figure 4.6: Textual constraints for family tree in Alloy

90

PrimVal ObjectRef

Val

Var Class

Field Fname

otype

holds

dtype

ftype

nameval

fields

to

subclass

!

! !

!

?

!

Null ObjRef!

Java programs have variables, which have declared types that are classes. Classesare related by subclassing. Variables hold values, divided into primitive valuesand references. References are further divided into the null reference and refer-ences to objects. An object has fields, each of which has a name and a value.Objects have types, too. Every variable and every field have a value (althoughit may be null). Every object reference points to an object. Note that these arefundamental properties of a safe programming language.

The declared type of a variable cannot change. The type of an object can-not change either. Objects cannot migrate between classes. An object cannotchange what fields it has, and the name of a field cannot change.

Invariants The fundamental property guaranteed by the Java type systemcan be expressed as a textual object model constraint: If a variable or field holdsa reference to an object, the type of the object is the same class or subclass ofthe declared type of the variable or field.

4.3.8 Analyzing Alloy object models

We now discuss in more detail how the Alloy Constraint Analyzer works. Givenan object model M , we can use the Alloy Constraint Analyzer for the animationof M , checking consistency of M , and checking assertions of M . Each task canbe reduced to a satisfiability problem. Let the constraints expressed in M begiven by the predicate logic formula fM .

• Animation: The analyzer shows us a state that satisfies fM , that is, itshows us a model of fM that makes fM true.


P

P’

f !f"Yes"

"No"

"No"

"Yes"

Figure 4.7: Validity versus satisfiability

• Checking consistency: The analyzer tells us whether or not fM is consis-tent, that is, satisfiable.

• Checking assertions: Let fA be an assertion. The analyzer tells us whetherfA is true, whenever fM is, that is, whether fM → fA is valid. fM → fAis valid if and only if fM ∧ ¬ fA is unsatisfiable. If fM ∧ ¬ fA is true insome state s , then fM → fA is not valid and s is a counter example. Moreformally,

fM → fA valid iff¬ (fM ∧ ¬ fA) valid ifffM ∧ ¬ fA unsatisfiable

Unfortunately, it turns out that the satisfiability problem for Alloy formulas isundecidable. To see this, remember that validity for first-order predicate logicis undecidable.

Theorem 7 (Validity in first-order predicate logic is undecidable)The validity problem for first-order predicate logic is undecidable.

The undecidability of validity directly implies the undecidability of satisfia-bility.

Theorem 8 (Satisfiability in first-order predicate logic is undecidable)The satisfiability problem for first-order predicate logic is undecidable.

Proof: By contradiction. Suppose there was a procedure P that, when given afirst-order predicate logic formula f , always terminates and outputs “Yes”, if fis satisfiable and “No” otherwise.

P(f ) =

{“Yes”, if f satisfiable“No”, otherwise

Using P , we can construct a procedure P ′ as follows.

P ′(f ) =

{“Yes”, if P(¬ f ) = “No”“No”, otherwise

Figure 4.7 illustrates the construction. Remember that f is a theorem if andonly if ¬ f is not satisfiable. So, P ′ decides the validity problem. Contradictionto Theorem 8.

Since Alloy contains quantifiers it is as expressive as first-order predicatelogic. Therefore, satisfiability in Alloy is also undecidable.

92

Corollary 4.3.1 (Satisfiability in Alloy is undecidable)The satisfiability problem for Alloy is undecidable.

The above result means that satisfiability in Alloy cannot be automated.For every procedure P for finding satisfying states there will always exist aformula f such that the execution of P on f either does not terminate, producesthe wrong output, or requires user interaction. If we implement P such thatit always terminates with the correct result, but requires user interaction, Pis essentially a theorem prover. However, we want our analysis tools to hidethe details and complexities of the underlying logic and analysis techniquesfrom the user. To this end, it is imperative that our tools require as little userinteraction as possible. So, rather than accepting user interaction and analyzingAlloy formulas by means of a theorem prover, we break the impasse by tradingexpressiveness of the analysis for automation. We do this by limiting the analysisto a finite subset of the entire state space.

Bounded satisfiability

The Alloy Constraint Analyzer achieves full automation despite the expressive-ness of the Alloy logic and its resulting undecidability by explicitly keeping thesearch space finite. Whenever we ask the checker to find a satisfying instance, wehave to define the scope of the search. We call the problem of deciding whethera formula has a satisfying instance within a given scope the bounded satisfia-bility problem. While general satisfiability is not decidable for Alloy, boundedsatisfiability is. In a finite scope, every Alloy formula f has only finitely manycandidate models that could make f true. This means that the bounded satis-fiability problem for Alloy is decidable.

Theorem 9 (Decidability of bounded satisfiability problem)Given an Alloy formula f and a scope n ∈ N, the problem of deciding whetherf has satisfying states in scope n is decidable.

Proof idea: The number of possible models for f is finite. Thus, we canconstruct a procedure P that exhaustively generates all models and for eachmodel checks whether it makes f true. P will always eventually terminate withthe correct answer.

Essentially, the Alloy checker is built using the brute force method describedin the above proof. First, it translates the model M into one large first-orderpredicate logic formula fM . Then, fM is passed to an off-the-shelf satisfiabilitysolver for predicate logic called Satlab. If Satlab finds a satisfying model forfM , it is output by the Alloy checker. Otherwise, Alloy answers “No solutionfound”.

Interpreting Alloy analysis results

To achieve decidability and thus full automation, the Alloy checker thus sacri-fices informativeness of the analysis. Instead of answering the question


Q1: “Is this formula satisfiable?”

it answers the question

Q2: “Is this formula satisfiable in scope n?”

where n is some natural number. A positive answer of the Alloy checker to Q2provides as much information as a positive answer to the question Q1. However,a negative answer does not. If the checker says that model fM is not satisfiablein scope n, then fM could be satisfiable in some larger scope, or it could not besatisfiable at all.

Theorem 10 (Bounded satisfiability I)If f satisfiable in scope n, then f satisfiable in general. If f not satisfiable inscope n, then f may or may not be satisfiable in general.

Since the scope is an upper bound on the size of the underlying sets, thestates of a model M in scopes n ′ < n are a subset of the states of M in scopen. This has the consequence that if assertion A is valid in M in scope n, thenA also is valid in M in all scopes n ′ < n. In other words, if no state of M inscope n was a counter example for A, then no state of M in n ′ can be a counterexample either.

However, A may or may not be valid in M in scopes larger than n. Intu-itively, this is because a counter example for A may require a scope larger thann.

Theorem 11 (Bounded satisfiability II)If assertion fA does not have a counter example in scope n,

• then it does not have a counter example in scopes less than n.

• then it may or may not have a counter example in scopes greater than n.

4.3.9 Summary

In summary, the Alloy notation allows the succinct specification of object mod-els and their properties. The Alloy checker allows states of the model to bedisplayed and properties of the model to be verified with respect to the givenscope. The counter examples produced by the checker allow the refinementof the model. Due to the scope restriction, the checker only has to performa bounded, finite search. This allows all interactions with the checker to befully automatic and always terminating. However, bounded unsatisfiability isa weaker property than general unsatisfiability. Consequently, the absence ofa counter example in some scope does not imply the absence of a counter ex-ample in all scopes. Figure 4.8 summarizes the usage of the Alloy checker andillustrates the iterative nature of the process of designing and analyzing Alloyobject models.

94

analyzecounterexam

ple

more

instances?instance

ok?

is therecounter

example?

enlargescope

done

satisfyinginstance?

modify

model

modify

model

modify m

odel orenlarge scope

check otherassertion

model &

assertions

Is the model consistent?

If so, what instances does it have?

n

ycheck

n

runy

y

n y

Does m

odel satisfy certain properties?

n

Figure

4.8:Desig

nandanalysis

ofobject

models

usin

gAlloy

4.4. OBJECT MODEL DESIGN AND ANALYSIS USING UML AND OCL95

4.4 Object model design and analysis using UMLand OCL

4.4.1 Background on UML

As object-orientation became more and more popular in the late 1980s and early1990s a large number of methods for object-oriented software development wereproposed including, for instance,

• Object-oriented Analysis method (OOA) by Coad and Yourdon [CY89],

• Object-orientedModeling technique (OMT) by Rumbaugh et al [RBP+91],

• Jacobson Method by Jacobson et al [JCJG92], and

• Booch’s method (ODD) [Boo91].

However, as the world expected a “methods war”, Rumbaugh and Jacobsonjoined Booch’s company Rational Software and declared in 1995 that they in-tended to merge their methods. Initial efforts led to drafts of the so-calledUnified Method. Then, however, the focus shifted from the development of aunified method to the development of a unified modeling language which ledto UML [FS97]. UML thus is a combination of the notations and models ofthe methods of Rumbaugh, Booch, and Jacobson. It includes different mod-els (like class models, use case models, interaction and collaboration diagrams,state and activity diagrams, and implementation diagrams), their (informal)semantics, and an interchange format for CASE tools. UML has the backing ofa large consortium that includes Microsoft, Oracle, HP, and IBM and was madestandard by the Object Management Group (OMG).

4.4.2 Object modeling in UML

UML uses so-called class models for object modeling. UML class models containall the features of Alloy object models. Classes may have attributes (fields),operations, and subclasses. Associations show dependencies between classes.Multiplicities put restrict these dependencies quantitatively. UML representsthese features graphically in very much the same way as Alloy does. Consider,for instance, the UML class diagram in Figure 4.9 for the family tree examplepresented in Section 4.3.5. The most notable difference probably is the use ofrolenames in UML which name the ends of associations. For instance, in Alloy,we have two relations husband and wife between Man and Woman. In UML,however, the association itself remains unnamed and the two rolenames wifeand husband are used instead. As we will see, the rolenames of an associationcan be used to refer to the objects connected by the association. Also note thatthe disjointness of the types Man and Woman is expressed graphically in UML,whereas it is expressed textually in Alloy.

UML object models offer a few features that Alloy does not support. Forinstance, UML class models may contain so-called association classes, that is,

96

Married NamePerson

Man Womanwifehusband

0..1 0..1

parents siblings

0..*0..* 0..*

0..*

name1

{disjoint}

Figure 4.9: Graphical constraints for family tree in UML

classes that are attached to an association. Moreover, in UML, object modelsmay also be related through aggregation or composition. For more informationon object modeling with UML see [PS99], for instance.

4.4.3 The Object Constraint Language

Just like in Alloy, an object model in UML consists of graphical and textualconstraints. While Alloy chooses predicate logic to express all constraints, UMLuses the Object Constraint Language (OCL) for textual constraints. OCL is anexpression language that enables one to restrict the values of (parts of) anobject-oriented model or system using invariants and pre- and post-conditionsOCL originated in the Syntropy method and has been developed by IBM. Itis used in the semantics document of UML (the so-called meta model) to placeconstraints on which UML models are well-formed, as well as being availableto users of UML to place constraints on their own models. OCL intends tocombine the rigor and precision of mathematics with the ease of use of naturallanguage. In other words, it is meant to be formal, precise and unambiguousand to be used by average software developers. To this end, OCL was made astrongly typed, functional (i.e., side-effect free) language with the syntax of anobject-oriented programming language. However, the developers of OCL haveachieved their goals only partially. OCL does not have a formal semantics yet,so it is not really a formal language. Moreover, it features all the complexities ofa full-fledged object-oriented programming language which in many cases makesit hard to use.

We will now give a brief overview of OCL. A more comprehensive introduc-tion to OCL can be found in [WK99]. The formal definition is available onlineat the OMG site at [Gro97].


OCL constraints

An OCL constraint is boolean-valued OCL expression. It always complementsan existing UML class model. It puts restrictions on the set of states of the modelby limiting the values an attribute can take on or the relationships betweenobjects. The model in Figure 4.10 is taken from [WK99] and will be used as arunning example.

OCL expressions have a context that determines which element of the classmodel the expression refers to. Different kinds of OCL expressions have differentkinds of context.

Invariants Boolean-valued OCL expressions can be used to specify invariants.The context of an invariant always is a class in the model. Invariants can havetwo different purposes.

• Restrict values of attributes in single class. For instance, the invariant

LoyaltyAccount

self.points > 0

constraints the values of the points attribute of an object of type

LoyaltyAccount

to always be greater than zero. In other words, an account cannot have anegative number of points. While it is sometimes necessary to explicitlyrefer to the context object using the keyword self, it can be omitted here.

LoyaltyAccount

points > 0

• Restrict values of attributes in several classes. Often, there is a relation-ship between the attributes of associated classes that we want to capture.For instance, the person owning a customer card is the same as the personmentioned on the card. Moreover, the name printed on the card should begiven by the title and the name of the customer owning the card. Thereare two ways to use an association to navigate from an object to the ob-jects associated with it. The first involves the rolenames of the associationwhile the second involves the name of the target class starting with a lowercase character. Given an association

ClassA ClassBr s

and an object anA of type classA, the expressions anA.s and anA.classBboth refer to all objects (if any) of type classB that are related to anA.The multiplicity constraints determine whether the value of anA.s andanA.classB is either undefined, a single object, or a collection of objects.Thus, the two constraints above are expressed by

98

numberOfCustomers : Integer

ProgramPartnerMembership

LoyaltyProgram

enroll(c : Customer)

name : Stringtitle : StringisMale : Boolean

age() : Integer

Customer

valid : BooleanvalidFrom : DategoodThru : Datecolor : enum{silver, gold}printedName : String

CustomerCard

earn(i : Integer)burn(i : Integer)isEmpty() : Boolean

points : Integer

LoyaltyAccount

condition : BooleanpointsEarned : IntegerpointsBurned : Integerdescription : String

Service

date : Date points : Integer

Transaction

program() : LoyaltyProgram

EarningBurning

ServiceLevel

name : String

program

partners

deliveredServices

availableServices

transactions

transactions

transactions

card

card

owner

cards

1..*

{ordered} 1..* actualLevel

0..*

0..*

0..*

0..*

0..*0..*

0..*

0..*

1..*

0..1

Figure 4.10: UML object model of the Royal and Loyal customer loyalty system


Membership

card.customer = customer

and

CustomerCard

printedName = customer.title.concat(customer.name)

respectively. Note that the first constraint could also be written as

Membership

card.owner = customer

or

Membership

customerCard.customer = customer

Pre- and post-conditions OCL expressions can also be used to describe thebehaviour of operations. The context of a pre- or a post-condition always isthe operation being specified. Formal parameters of the operations can be usedin the conditions. The result returned by the operation can be described usingthe distinguished variable result. For instance, the isEmpty() operation onaccounts is described by

LoyaltyAccount::isEmpty() : Boolean

pre : -- none

post : result = (points=0)

where -- introduces a comment.As another example, consider the following OCL specification of a method

that sorts integer sequences. In this example, the post-condition is broken upinto three parts and each part is named.

someClass::sort(s : Sequence(Integer)) : Sequence(Integer)

pre : s.isDefined

post SameSize:

result->size = s->size

post SameElements:

result->forAll(i | result->count(i) = s->count(i))

post IsSorted:

sequence{1..(result->size-1)}->forAll(i | result.at(i) <= result.at(i+1))

Some operations, like isEmpty() or age() simply query the current statewithout changing it, and return a result. Such operations are called query op-erations and should be declared as such in the UML model using the booleanlabel isQuery. Other operations, however, change the state by, for instance,creating or deleting objects, or changing the value of attributes. To be able tospecify the behaviour of these kinds of operation, the Z language used the prime

100

notation to refer to the value of a variable in the next state. OCL, however,uses the @pre keyword to refer to the value of an attribute or association in theprevious state. Consider, for instance,

LoyaltyAccount::enroll(c : Customer)

pre : c.isDefined and (not customer->including(c))

post : customer = customer@pre->including(c)

The pre-condition expresses that the argument to the operation must be non-null and not currently be a customer of the account. The post-condition saysthat the set of customer objects associated with an account object after execu-tion of the enroll(c : Customer) operation is given by the customers of theaccount right before execution of the operation plus the object c. Note that oneoccurrence of @pre only refers to the attribute or association directly preceedingit. Suppose, for instance, an operation changes the attributes a and b of theobjects x, y, and z as follows

attribute state s0 state s1x.a {y,z} {z}y.b 0 2z.b 1 3

where s0 and s1 refer to the states right before and right after execution of theoperation. Then, the following expressions have the following values in state s1:

x.a.b = {3}[email protected] = {2, 3}

[email protected]@pre = {0, 1}Note that the @pre keyword is only permitted in post-conditions.

Short description of OCL

The description of OCL distinguishes between pre-defined and user-definedtypes.

Predefined types and their operations Predefined types and their oper-ations are always available.

Predefined operations on all objects The OCL type hierarchy is rootedat OclAny. The meta-type OclType is the type of all types in OCL. The follow-ing operations apply to all objects.

= (o : OclAny) : Boolean

<> (o : OclAny) : Boolean

oclType : OclType

oclIsTypeOf(t : OclType) : Boolean

oclIsKindOf(t : OclType) : Boolean

oclAsType(t : OclType) : OclType

4.4. OBJECTMODEL DESIGN AND ANALYSIS USING UML AND OCL101

oclIsNew : Boolean

oclType returns the type of the context object. oclIsTypeOf returns true ifthe argument is the type of the context object. oclIsKindOf determines if theargument is either the type or a supertype of the context object. For instance,

Burning

self.oclType = Burning

self.oclIsTypeOf(Burning) = true

self.oclIsKindOf(Burning) = true

self.oclIsTypeOf(Transaction) = false

self.oclIsKindOf(Transaction) = true

self.oclIsTypeOf(Earning) = false

self.oclIsKindOf(Earning) = false

oclAsType is a narrowing type conversion just like

Object o = new ClassA();

ClassA a = (ClassA) o;

in Java. If the argument is not the type of the context object the result ofoclAsType(t : OclType) is undefined.

Basic types OCL supports the basic types Boolean, Integer, Real, andString where Integer is a subtype of Real. Each basic type offers the followingoperations.

type operationsBoolean not, =, and, or, xor, implies, if then else

Real =, <>, <, <=, >, >=, <, <, +, -, *, /, abs, floor, round, max, minInteger div, modString =, size, concat, toUpper, toLower, substring

The meaning of these operations is standard.

Collection types There are three different kinds of collections: sets, bags,and sequences. The operations on collections will be given later.

User-defined types and their operations

Use of user-defined types Every type specified in the UML model is avalid type in OCL.

Use of attributes Every attribute of a type defined in the UML model canbe used in OCL. For instance, if the class Customer is defined as in Figure 4.10,then Customer is a valid type in OCL and all its attributes can be used. Thestandard dot-notation is used to refer to an attribute of the object. For instance,if c is a customer object, then the expressions

102

c.name

c.isMale

are legal and evaluate to, respectively, a string and a boolean.

Use of operations OCL is a side-effect free language, that is, the eval-uation of an OCL expression will never change the state. Consequently, onlythose operations in the UML model that have been declared as queries, that is,non-state changing, are allowed in OCL expressions. The standard dot-notationis used to invoke an operation on an object. For instance, if c is an object oftype Customer as declared in Figure 4.10, then the expression

c.age()

is legal and evaluates to an integer.

Use of associations and aggregations Every association and aggrega-tion declared in the model can be used in OCL. As described above, rolenamesand lower case class names can be used to navigate from an object to an as-sociated object. Navigations across associations are subject to the followingrules:

• The navigation across an association with multiplicity 0 results in an un-defined value.

• Navigation across an association with multiplicity 1 results in a singleobject.

• Navigation across an association with multiplicity greater than 1 typicallyresults in a set of objects.

• Navigation across more than one association with multiplicity greater than1 results in a bag of objects.

The difference between sets and bags will be explained below. Note that thedot-notation is used to refer to the object on the other end of the association.Consider, for instance, the expression

c.cards

If the customer c has no customer cards, the value of the expression is undefined.If the customer has one card, then a set containing that card is returned. If thecustomer has several cards, a set containing all of them is returned. Expression

c.cards.transactions

evaluates to the bag of all transactions performed using all cards of customer c.


Use of association classes Association classes are classes that belong toan association. From an association class we can always navigate to both endsof the association. For instance, if m is a membership object, the expressions

m.customer

m.loyaltyProgram

refer to, respectively, the customer and the loyalty account that the membershipis associated with.

To travel to an association class we simply use the name of the associationclass starting with a lower case character. For instance,

c.membership

evaluates to all membership objects associated with c.

Collection types and their operations

Collections, sets, bags, and sequences Collection is an abstract typewith subtypes Set, Bag, and Sequence. Sets are unordered collections of ob-jects without duplicate elements. Bags (sometimes also called multisets) areunordered collections of objects possibly with duplicated objects. Finally, se-quences are ordered collections of objects with possibly repeated objects. Allthree kinds of collection can be specified in OCL using the name followed by alist of elements in curly brackets:

Set{1, 2} = Set{2, 1, 1}Bag{1, 1, 2, 2} = Bag{2, 2, 1, 1}not Bag{1, 1, 2} = Bag{1, 2}not Sequence{1, 2} = Sequence{2, 1}

All expressions evaluate to true. Note that collections are always implicitly“flattened”, that is,

Set{1, 2} = Set{1, Set{2}}Bag{1, 1, 2} = Bag{Bag{1}, Bag{1, 2}}

hold.

Operations on collections We list some of the operations available oncollections. See [WK99] or [Gro97] for a complete list. Note that the applicationof an collection operator op to a collection c1 is always of the form c1->op.

• c1->size. Returns the number of elements in the collection. The invariant

Customer

cards->size <= 2

expresses that a customer cannot own more than 2 customer cards.

104

• c1->count. Returns the number of different elements in the collection.The invariant

ProgramPartner

numberOfCustomers = loyaltyProgram.customer->count

expresses that the value of the numberOfCustomerattribute of a ProgramPartnerobject is given by the number of different customers that are enrolled ina loyalty program offered by the program partner.

• c1->includes(o : OclAny). Returns true if o is an element of c1. Forinstance, the invariant

Membership

customer.card.membership.includes(self)

expresses that, intuitively, if membership m is associated with customer c,then c owns a customer card for m.

• c1->includesAll(c2 : Collection). Returns true if all elements inc2 are present in c1.

• c1->excludes(o : OclAny). Returns true if o is not an element of c1.

• c1->isEmpty. Returns true if c1 is empty. For instance, the constraint

ServiceLevel

availableServices->isEmpty implies

membership.loyaltyAccount.transactions->isEmpty

expresses that if a service level l offers no services, then no loyalty accountof any membership with actual level l has transactions associated with it.

• c1->notEmpty. Returns true if c1 is not empty.

• c1->including(o : OclAny). Returns a collection consisting of o andall elements in c1.

• c1->excluding(o : OclAny). Returns a collection consisting of all ele-ments in c1 except o.

• c1->union(c2 : Collection). Returns a collection consisting of all theelements in c1 or c2.

• c1->intersection(c2 : Collection). Returns a collection consistingof all the elements in c1 and c2.

• c1->select(x | expr) where expr is a boolean expression. Returns thecollection of all elements e of c1 for which expr[e/x] evaluates to true.The following expression evaluates to the set of all transactions involvingmore than 100 points


CustomerCard

self.transactions->select(t | t.points > 100)

The invariant

Customer

program->size = cards->select(c | c.valid)->size

expresses that the number of programs a customer is enrolled in is equal tothe number of valid customer cards she owns. If pp is a program partner,the expression

pp.loyaltyProgram.partners->select(p | p<>self)

evaluates to the bag of program partners that are different from pp andthat offer one of the loyalty programs also offered by pp.

Sometimes, the objects select iterates over can remain unnamed, that is,the short form

c1->select(expr)

can be used. For instance, the first two constraints above can be shortenedto

CustomerCard

self.transactions->select(points > 100)

and

Customer

program->size = cards->select(valid)->size

respectively. Note that the third expression cannot be shortened the sameway.

• c1->forAll(x | expr) where expr is a boolean expression. Returns trueif expr[e/x] is true for all elements e in c1. For instance,

LoyaltyProgram

partners.deliveredServices->forAll(s | s.pointsEarned=0

and s.pointsBurned=0)

implies membership.loyaltyAccount->isEmpty

expresses that if a loyalty program does not offer the possibility of earningor burning points, then the members of the program do not have loyaltyaccounts.

• c1->exists(x | expr) where expr is a boolean expression. Returns trueif expr[e/x] is true for at least one element e in c1. For instance,

Customer

cards->exists(valid)

106

expresses that every customer has to have at least one valid card. Notethat forAll and exists offer the same shorthand as select.

• c1->sum where c1 is a collection of integers or reals. Returns the sum ofall the elements in c1. For instance,

LoyaltyProgram

partners.deliveredServices.transaction.points->sum < 10,000

limits the total number of points all partners can use in transactions in-volving any of their services to 10,000.

Adding and removing existing objects The enroll(c : Customer) op-eration demonstrates how the addition of an object to an association can bespecified using @pre and including. The removal of an existing object from anassociation is similar.

LoyaltyAccount::remove(c : Customer)

pre : c.isDefined and (customer->including(c))

post : customer = customer@pre->excluding(c)

Creating and deleting objects Sometimes, an operation needs to add anew object with certain properties to an association. Consider, for instance,

LoyaltyAccount::enroll(name : String, title : String, isMale : Boolean)

pre : title="Mr" implies isMale

pre : (title="Mrs" or title="Ms") implies not isMale

post : customer->exist(c | c.oclIsNew and c.name=name and

c.title=title and c.isMale=isMale)

post : customer->size = customer@pre->size + 1

post : customer->includesAll(customer@pre)

Informally, an object satisfies oclIsNew in the context of a post-condition of anoperation, if the object was created by the operation.

Given a type A, the evaluation of the expression A.allInstances in somestate s yields the set of objects of type A that the state s contains. For instance,if s contains two customer objects C1 and C2, then

Customer.allInstances = Set{C1, C2}

The removal of an object from a type is specified using allInstances andexcluding.

Customer::dies()

pre : -- none

post : Customer.allInstances->excluding(self)


Example: Family tree

The graphical UML constraints for the family tree were given in Figure 4.9.The textual constraints in OCL for the family tree are given in Figure 4.11.Compared with the Alloy constraints in 4.5, the OCL specification has thefollowing notable features:

• OCL does not treat classes as sets. For instance, in Alloy fathers can bedefined using a simple set intersection. In OCL, on the other hand, thisrequires the use of explicit quantification and programming-language liketype checking using oclIsKindOf. Similar remarks apply to the definitionof the set of married persons.

• Alloy offers operations on relations (inverse, transitive closure, and re-flexive and transitive closure). In OCL, these operations have to be de-fined and implemented by the user. For instance, to be able to expressin OCL that a person cannot be its own ancestor in OCL we need toformulate 3 auxiliary functions (getParents, getParentsClosure, andgetAncestors) to compute the transitive closure of the parent relation.

• In Alloy, the application of a relation defined in a subclass to an elementof the superclass simply yields the empty set. For instance, if m is a man,the expression m.husband evaluates to the empty set. This is becausesubclasses are modeled as subsets. In OCL, the application of a rolenameof an association defined on a subclass to an object of supertype results ina error. Consequently, the constraint that a person p has a wife if and onlyif p is a man and married cannot be expressed. Instead, the constraintthat a man has a wife if and only if he’s married must be used.

• Alloy offers the direct comparison of relations (equality, subset). In OCLthese comparisons have to be expressed “pointwise” using explicit quan-tification. This complicates the expression that, for instance, the wiferelation is the inverse of the husband relation.

Semantics

We briefly discuss the meaning of OCL expressions and constraints.

Semantics of OCL expressions We mentioned above that OCL is morelike a programming language than a logic. On the one hand, this means thatOCL features many constructs found in a programming language like Java andthat the semantics of these constructs is very similar. On the other hand, italso complicates the analysis of OCL specifications. More precisely, while theevaluation of an Alloy constraint always returns a truth value, the evaluation ofan OCL constraint may also not terminate or result in the value “undefined”.This means that some features one would normally expect in a specificationlanguage are lost. For instance, there are boolean OCL expressions e1 for which

108

Person

−− operation returning the transitive closure of the parents relation−− uses fixed point iteration; always terminatesgetParentsClosure(s : Set(Person)) : Set(Person) =

else self.getParentClosure(s−>union(s.getParent()−>asSet)) if s−>includesAll(s.getParent()) then s

endif

getParents() : Set(Person) = −− operation returning a set containing the parents

if (parents.isDefined) then parents else Set{} endif

getAncestors() : Set(Person) = getParentClosure(getParent())−− always terminates−− operation returning set of all ancestor directories

Man

self.wife−>notEmpty = self.oclIsKindOf(Married) −− MB2self.oclIsKindOf(Married)−>self.wife.husband=self −− WIH1

Woman

self.husband−>notEmpty = self.oclIsKindOf(Married) −− MB3self.oclIsKindOf(Married)−>self.husband.wife=self −− WIH2

Man::Marry(w:Woman)

pre: not self.oclIsKindOf(Married) and not w.oclIsKindOf(Married)post: self.wife = w and Man.allInstances−>forall (m|m != self implies m.wife@pre=m.wife)

−− Partial OCL model of family tree

self.parents−>select(oclIsKindOf(Man))−>size<=1 −− PB1.1

self.parents−>select(oclIsKindOf(Woman))−>size<=1 −− PB1.2

not self.getAncestors()−>includes(self) −− PB2

self.siblings = Person.allInstances−>select(parents=self.parents) −− DS

self.oclIsKindOf(Married) = (Man.allInstances.wife−>includes(self) or Woman.allInstances.husband−>includes(self)) −− MB1

self.oclIsKindOf(Man) or self.oclIsKindOf(Woman) −− Part

Figure 4.11: Textual constraints for family tree in OCL


e1 and false

is not equal to false. This is because the evaluation of e1 may not terminate.Moreover, there are boolean expressions e2 for which

e2 or not e2

does not evaluate to true. This is because the value of an expression may beundefined.

Non-terminating expressions We have seen in the family tree examplethat the expression of some properties in OCL requires the user to define opera-tions that describe how certain values are to be computed. An obvious source ofnon-termination are user-defined non-terminating, recursive operations. Con-sider, for instance,

Foo

bar() : Boolean = bar()

There is no foo for which the application of bar() will ever terminate.However, the non-termination may also be due to a specific feature of the

current state. Consider, for instance, the function getAncestorswhich is meantto compute the set of all ancestors of a given person in the family model inFigure 4.11.

Person

getAncestors() : Set(Person) = parents->union(parents.getAncestors()->asSet)

If the parents relation is circular in the current state, and person p is in thatcycle, the evaluation of the expression p.getAncestors() will not terminate.If the function is to be used to express a constraint enforcing the absence ofcycles in the parents relationship, we are left in the following unsatisfactorysituation: If the parents association is indeed acyclic in the current state, thenthe evaluation of the constraint will terminate successfully. If, however, theparents associations in the current state can be connected to form at least onecycle, then the evaluation of the constraint will never terminate and thus fail toinform us of the fact that the state is erroneous.

Undefined expressions Not all operations in OCL are total, that is, de-fined on all inputs. For instance, the result of an access to undefined attributes ofan object is “undefined”. Moreover, navigation across an undefined associationwith multiplicity less than or equal to 1 at the target also yields “undefined”.Finally, if the state contains infinitely many objects of type A, then result ofA.allInstances also is undefined. Thus,

Integer.allInstances->select(i | i mod 2 = 0)

does not evaluate to the set of even integers.Typically, undefined values propagate, that is, if a subexpression is unde-

fined, the entire expression is undefined. Consider, for instance,

110

undefined and true = undefined

undefined or false = undefined

undefined or not undefined = undefined

For boolean operations, notable exceptions include

(true or undefined) = true

(undefined or true) = true

(false and undefined) = false

(undefined and false) = false

(false implies undefined) = true

(undefined = undefined) = true

(undefined = true) = false

(undefined = false) = false

Note that the evaluation of expressions containing undefined subexpressionsmay have unexpected results.

Semantics of OCL constraints Let s be some state of a UML class model.State s is a permissible state if and only if all OCL constraints are true in s .That is, if at least one constraint is false or undefined in s , s is not permissible.The conformance of an implementation to the constraints could be checked atrun-time.

4.4.4 Representing and analyzing UML/OCL object mod-els using USE

[RG00]

Representation

some features of OCL not supported in USE

Analysis

• animation: generate state (manually or using a script) and display itgraphically

• evaluation: check if current state satisfies constraints

• simulation: check if current state satisfies precondition of an operation;perform state changes simulating the execution of the operation; check ifresulting state satisfies postcondition

• analysis confined to single state.

4.5. SUMMARY 111

4.5 Summary

Alloy was designed to be as compatible as possible with UML class models.Alloy also intends to overcome the flaws of OCL.

• Both Alloy and UML express the graphical constraints of an object modelsimilarly. However, in contrast to UML, Alloy does not support rolenames, aggregation, composition, or association classes.

• In Alloy the graphical constraints can also be expressed textually whereasin UML they cannot.

• Every OCL specification always needs to be complemented with a (graph-ical) UML object model whereas Alloy models can be standard-alone.

• Alloy distinguishes between constraints (facts) and assertions, that is, re-dundant formulas that are expected to be implied. OCL does not makethis distinction.

• An OCL constraints must be assigned a context. Alloy constraints, how-ever, may also be “free-standing”.

• OCL is heavily influenced by C++, and UML encourages the designer toemploy its programming language-specific features. Alloy is programming-language-independent, so an Alloy design can be implemented in any lan-guage.

• Despite best intentions by its designers, OCL does not have a precisesemantics, so the meaning of a model may be ambiguous and obscuremaking rigorous analysis impossible. Alloy has a mathematical semanticswhich results in a simpler and more coherent set of features.

• Alloy’s precise semantics allows the development of analysis tools. Theconcept of bounded satisfiability allows Alloy’s checker to perform non-trivial analyses fully automatically. Tools supporting OCL do not supportanalyses of that power. USE, for instance, allows the animation of anobject model through the construction of a single state. Arbitrary OCLexpressions can be evaluated in that state and OCL constraints can bechecked. However, with USE it is not possible to do assertion checking,that is, to check directly that all states of a given model will always havesome other property.

• Alloy employs a standard logical syntax, and is much simpler than a pro-gramming language. OCL, however, is more like a programming lan-guage. While it does use the standard logical connectives like negation,conjunction and disjunction, it applies these in the context of a program-ming model that includes subclass and parametric polymorphism, opera-tor overloading, multiple inheritance, and introspection. On the one hand,this means that it potentially is easier and more intuitive to a user with

112

object-oriented programming experience. On the other hand, however, itintroduces complexities like undefined or non-terminating expressions toOCL that make it, in many cases, hard to learn and use.

• Constraints involving iterated navigations (eg, that in a file system everyfile is reachable from the root, or that a directory cannot be its ownancestor) are hard to express in OCL. Alloy has transitive closure built-in.

• OCL supports bags and sequences. Alloy does not.

Moreover, the development of a formal semantics for OCL poses a majorchallenge and is a topic of current research. Unfortunately, a formal semanticsis a prerequisite to the design of any tool performing a non-trivial analysis.

Chapter 5

Bibliographic notes andacknowledgments

The introduction to state diagrams, object modeling, and Alloy in Sections 4.2and 4.3 used [Jac99, LG00, Jac00, Jac01] as sources. The file system exampleused in Sections 4.2 and 4.3.4 is taken from [Jac00]. Section 4.4 was preparedusing [WK99] and [DHH01]. The running example used Section 4.4 is takenfrom [WK99].

A number of articles report on the successful application of formal techniquesin large projects. These include [MDL90, CM90, BBFM99].

113

114CHAPTER 5. BIBLIOGRAPHIC NOTES AND ACKNOWLEDGMENTS

Bibliography

[BBFM99] P. Behm, P. Benoit, A. Faivre, and J.M. Meynadier. Meteor: Asuccessful application of B in a large project. In Proceedings ofthe World Conference on Formal Methods in the Development ofComputing Systems, pages 369–387. Springer Verlag, 1999. LNCS1708.

[Boo54] G. Boole. An Investigation of the Laws of Thought. Dover, NewYork, 1854.

[Boo91] G. Booch. Object Oriented Design with Applications. Ben-jamin/Cummings, Menlo Park, CA, 1991.

[Cam] Cambridge University and Technical University of Mu-nich. Isabelle: A generic theorem proving environment.http://www.cl.cam.ac.uk/Research/HVG/Isabelle/.

[CM90] R.H. Cobb and H.D. Mills. Engineering software under statisticalquality control. IEEE Software, (6):45–54, 1990.

[CY89] P. Coad and E. Yourdon. OOA-Object-Oriented Analysis. Engle-wood Cliffs New Jersey: Prentice Hall, 1989.

[DHH01] M. Dwyer, J. Hatcliff, and R. Howell. Slides for course on SoftwareSpecifications (CIS771), Kansas State University. Personal commu-nication, November 2001.

[Fre03] G. Frege. Grundgesetze der Arithmetik, begriffsschriftlichabgeleitet, 1903. Volumes I and II (Jena).

[FS97] M. Fowler and K. Scott. UML Distilled: Applying the StandardObject Modelling Language. Addison Wesley, 1997.

[Gen69] G. Gentzen. Investigations into logical deduction. In M.E. Szabo,editor, The Collected Papers of Gerhard Gentzen, pages 68–129.North Holland, 1969.

[GM93] M.J.C. Gordon and T.F. Melham, editors. Introduction to HOL:A theorem proving environment for higher order logic. CambridgeUniversity Press, 1993.

115

116 BIBLIOGRAPHY

[Gro97] Object Modelling Group. Object constraint languagespecification. Technical report, OMG, September 1997.ftp://ftp.omg.org/pub/docs/ad/97-08-08.pdf.

[HR00] M. Huth and M. Ryan. Logic in Computer Science: Modeling andreasoning about systems. Cambridge University Press, 2000.

[Jac99] D. Jackson. A Comparison of Object Modelling Notations: Alloy,UML and Z. MIT, Lab for Computer Science, August 1999.

[Jac00] D. Jackson. Lecture notes for 6.170 (Laboratory in Software Engi-neering). MIT Laboratory for Computer Science, October 2000.

[Jac01] D. Jackson. Micromodels of software: Mod-elling & analysis with alloy. Draft, available athttp://sdg.lcs.mit.edu/alloy/book.pdf, November 2001.

[Jac06] M. Jackson. Software Abstractions: Logic, Languge, and Analysis.MIT Press, 2006.

[JCJG92] I. Jacobson, M. Christerson, P. Jonsson, and O. Gunnar. Object-oriented Software Engineering: A Use Case Driven Approach. Ad-dison Wesley, 1992.

[KMM00a] M. Kaufmann, P. Manolios, and J. Strother Moore, editors.Computer-Aided Reasoning: ACL2 Case Studies. Kluwer AcademicPublishers, June 2000.

[KMM00b] M. Kaufmann, P. Manolios, and J. Strother Moore, editors.Computer-Aided Reasoning: An Approach. Kluwer Academic Pub-lishers, June 2000.

[LG00] B. Liskov and J. Guttag. Program Development in Java. AddisonWesley, 2000.

[MDL90] H.D. Mills, M. Dyer, and R.C. Linger. Cleanroom software engi-neering. IEEE Software, pages 19–25, September 1990.

[MMZ01] Chaff: engineering an efficient SAT solver, 2001. Las Vegas,Nevada, United States.

[ORA] ORA Canada. Never: An automated deduction system.http://www.ora.on.ca/eves.html.

[Oxf] Oxford University. Just Another Proof Editor (JAPE).http://users.comlab.ox.ac.uk/bernard.sufrin/jape.html.

[Pra65] D. Prawitz. Natural Deduction: A Proof-Theoretical Study.Almquist & Wiksell, 1965.

BIBLIOGRAPHY 117

[PS99] R. Pooley and P. Stevens. Using UML. Software Engineering withObjects and Components. Addison Wesley, 1999.

[RBP+91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen.Object-oriented Modelling and Design. Prentise Hall, 1991.

[RG00] M. Richters and M. Gogolla. Validating UML models and OCLconstraints. In Springer Verlag, editor, UML 2000 - The UnifiedModeling Language. Advancing the Standard. Third InternationalConference, LNCS 1939, 2000.

[SRI] SRI International. Computer Science Laboratory. Prototype Verifi-cation System (PVS). http://pvs.csl.sri.com.

[WK99] J. Warmer and A. Kleppe. The Object Constraint Language. PreciseModeling with UML. Object Technology Series. Addison Wesley,1999.

[Zha97] SATO: An efficient propositional prover, July 1997.

Documents

Notes on Propositional logic