Mapa de procesos

JavaDL is a multimodal typed first-order logic. Besides standard typed first-order logic terms, JavaDL provides a Java program Prg, a set of program variables PV and three modal operators: box[π], diamond⟨^π⟩and update{U}, where π is a program fragment in the context of Prg (shortly denoted π∈Prg) and U an update term. Definition 1 shows the JavaDL signature Σ, Definition 2 the JavaDL set of terms Trm_Σ, Definition 3 the set of JavaDL updates U pdΣ, and Definition 4 the set of JavaDL formulas FrmΣ—all derived form [77].

4Only some of the SMT solvers do support quantified formulas. These are for instance CVC4, Yices and Z3

2.3 KeY 15

Definition 1 (JavaDL Signature). A JavaDL signature Σ is a tuple(𝒯^,⪯^,𝒱^,𝒫𝒱^,ℱ^,ℱu,𝒫^{, α,} Prg)consisting of:

• a set𝒯 of types

• a partial order⪯on𝒯

• a set𝒱of variables

• a set𝒫𝒱of program variables

• a setℱof function symbols

• a setℱu⊆ ℱof unique function symbols

• a set𝒫of predicate symbols

• a (static) typing function α :𝒱 ∪ 𝒫𝒱 ∪ ℱ ∪ 𝒫 → 𝒯^* (where 𝒯^* denotes an arbitrary long Cartesian product of𝒯s) such that v is an instance of T (denoted by v@−T) for any v∈ 𝒱 ∪ 𝒫𝒱 with α(v) =T, f : T1× · · · ×Tn−1→Tn for any f ∈ ℱwith α(f) = (T₁, . . . , Tn), and P⊆^T1× · · · ×^Tnfor any P∈ 𝒫with α(P) = (T1, . . . , Tn)

• a Java program Prg —a set of Java classes and interfaces

Definition 2 (JavaDL Terms). Given a JavaDL signature Σ and a type A∈ 𝒯 different than boolean, the set Trm^A_Σof JavaDL terms of type A is defined inductively as follow:

• v is in Trm^A_Σif v∈ 𝒱 ∪ 𝒫𝒱with α(v) =A

• f is in Trm_Σ^Aif f ∈ ℱ with α(f) =A

• f(t₁, . . . , tn)is in Trm^A_Σif f ∈ ℱ with α(f) = (T₁, . . . , Tn, A)and ti∈^TrmT_Σ^i′with T_i^′⪯^Tifor all 1≤ⁱ≤ⁿ

• i f(ϕ)then(t1)else(t2)is in Trm_Σ^Aif ϕ∈^FrmΣ, and t1, t2∈^Trm_Σ^A

• {U}t is in Trm^A_Σif U∈U pd_Σand t∈Trm_Σ^A

The set Trm_Σof all JavaDL terms is defined as Trm_Σ=^S_A∈TTrm_Σ^A.

Definition 3 (JavaDL Updates). Given a JavaDL signature Σ, the set of JavaDL update terms U pd_Σis defined recursively as follow:

• v :=t is in U pdΣif v∈PV and t∈Trm^A_Σwith α(v) =A

• u1||^u2is in U pd_Σif u1, u₂∈^{U pd}Σ

• {^u1}^u2is in U pdΣif u1, u2∈^{U pd}Σ

16 Chapter 2 Foundations: Alloy, SMT, KeY

The update terms of the form v :=t are called elementary and, intuitively, assigns the value of the term t to the program variable v like a side effect Java assignment.

Complex updates are build using parallel update terms u1||u2and sequential update terms{u1}u2.

Definition 4 (JavaDL Formulas). Given a JavaDL signature Σ, the set Frm_Σof JavaDL formulas is defined inductively as follow:

• true, false are in Frm_Σ

• P(t1, . . . , tn)is in FrmΣif P∈ 𝒫 with α(P) = (T1, . . . , Tn)and ti ∈Trm^T_Σ^i′ with T_i^′⪯^Tifor all 1≤ⁱ≤ⁿ

• ¬ϕ, ϕ∧^ϕ′, ϕ∨^ϕ′, ϕ→^ϕ′, ϕ↔^ϕ′are in FrmΣif ϕ, ϕ^′∈Frm_Σ

• ∀Ax; ϕ,∃Ax; ϕ are in Frm_Σif A∈ 𝒯, x∈ 𝒱and ϕ∈^FrmΣ

• {^U}ϕ is in Frm_Σif u∈^{U pd}Σand ϕ∈^FrmΣ

• [π]ϕ,⟨^π⟩ϕ are in Frm_Σif π∈Prg and ϕ∈^FrmΣ

17

Chapter 3

AlloyPF —an Example

This chapter gives an overview of the automatic proof process in AlloyPF. The details of the individual techniques used in the proof process are described in the next four chapters. In this chapter, however, we will briefly explain, based on an example, how the actual proof process works.

3.1 Example

Figure 3.2 shows an Alloy specification of a generic file system. The specification con-sists of a type hierarchy, relations between the types, implicit constraints introduced by keywords, and explicit constraints introduced by fact formulas. As one can see, the syntax of Alloy is very similar to that of object-oriented programming languages:

types are introduced by the class-like signatures, relations by fields of signatures.

The type hierarchy of our Alloy specification consists of the two toplevel types Object for file system objects (Line 1) and DirEntry for directory entries (Line 12).

The first toplevel type Object is labeled with the keyword abstract which constraints each element of this type to belong to one of its extending subtypes File for files (Line 3) and Dir for directories (Line 5). Types are extended in Alloy using the keyword extends. The second toplevel type DirEntry is neither abstract nor extended. The last type in this type hierarchy is Root (Line 10). It extends the type Dir and is represented as singleton using the keyword one. Singleton sets can be and are often used in Alloy specifications as aliases of their unique element.

Based on the introduced types and the Alloy multiplicity constraints set, lone, and one, the specification introduces: (1) the binary relations entries⊆^Dir×^DirEntry which maps each directory to a set of directory entries (Line 6), (2) the binary relation parent⊆Dir×Dir which maps each directory to at most one parent directory (Line 7), and (3) the binary relation contents⊆DirEntry×Object which maps each directory entry to exactly one¹file system object (Line 13). Figure 3.1 shows the corresponding class diagram of the Alloy file system specification.

1The default multiplicity constraint for binary relations is one.

18 Chapter 3 AlloyPF —an Example

File Dir

Root

DirEntry Object

parent contents

entries

Figure 3.1: A corresponding class diagram of the Alloy file system specification

In addition to the above discussed implicit constraints, the specification introduces five explicit general constraints as fact formulas. Facts in Alloy specifications are comparable to class invariants in object-oriented programming languages. The first fact formula (Line 17) constraints each file element to be a content of at least one directory. The second fact formula (Line 18) constraints the set of parent directories of a directory d to be equal to the set of all directories which have a directory entry that has d as content. The third fact formula (Line 19) constraints the singleton set Root to be reachable from each directory, except itself, following the parent relation. The fourth fact formula (Line 20) constraints Root to not have a parent directory —“no e”

is equivalent to “e=∅”. The last fact formula (Line 21) constraints each directory entry to belong to exactly one directory.

The part of an Alloy specification that specifies the actual system only, like in Figure 3.2, is called model. Given a Alloy model, the user can specify properties of that model using the assert keyword. The Alloy Analyzer allows to check the bounded-correctness of an Alloy specification², constituted from an Alloy model and an Alloy assertion, by checking the validity of its assertion within scopes. An assertion is valid within a given scope iff it is satisfied in each logical structure of its corresponding model within the given scope.

In order to demonstrate the proof process of AlloyPE, we use two assertions of the file system model that deduce two Alloy specifications belonging to two different classes of complexity.

2When speaking of the bounded-correctness of an Alloy specification, we always assume the existence of an assertion.

3.1 Example 19

1 abstract sig Object{}

2

3 sig File extends Object{}

4

5 sig Dir extends Object{

6 entries: set DirEntry,

7 parent: lone Dir

8 }

9

10 one sig Root extends Dir{}

11

12 sig DirEntry{

13 contents: Object

14 }

15

16 fact{

17 all f: File| some d: Dir | f in d.entries.contents

18 all d: Dir| d.parent = d.^∼contents.^∼entries

19 all d: Dir| d != Root⇒Root in d. ˆ parent

20 no Root.parent

21 all de: DirEntry| one de.^∼entries

22 }

Figure 3.2: An Alloy specification of a generic file system

The first assertion below asserts that if each directory has exactly one parent di-rectory and is the content of exactly one didi-rectory entry, then there are no didi-rectory aliases.

1 assert noDirAliases{

2 (all d: Dir - Root| one d.parent and one contents.d)

3 ⇒

4 (all o: Dir| lone o.^∼contents)

5 }

The second assertion below asserts that beside the root directory(s) each directory is a content of at least one directory entry.

1 assert someDir{

2 all o: Object - Root| some contents.o

3 }

20 Chapter 3 AlloyPF —an Example