Alloy is a model specification language based on first-order logic and set theory [92]. Alloy specifies objects (e.g. person, vehicle, etc.), properties of objects (e.g. name
of a person, make and model of a vehicle) and their relations (relations between objects and relations between an object and its properties). An Alloy model also includes constraints and expressions (Facts, Predicates, Assertions, etc.) [64].
CAR PLANE + VE [1] - VE [2]
Figure 7.5: Contradictory Messages in Tree View
7.2.1
Alloy Language
Each Alloy model starts with the keyword module followed by its name, which is referred to as the module header. The building blocks of an Alloy model are Signatures (sets), Facts (constraints), Predicates and Functions (expressions). Each Signature (labelled with the keywordsig) represents a set of objects. A signature is similar to a ‘class’ definition in Object Oriented Programming. Below are examples of three signatures, namely ‘FileName’, ‘File’ and ‘Folder’.
sig FileName {} sig File {
name: one FileName, location: one Folder
}
sig Folder {
file: set File, subFolder: set Folder
}
signature, FileName, does not have any field. In this example, the ‘name’ and ‘location’ fields of the signature, File, specify that a file must have only one name and one location. Facts, functions and predicates are labelled with fact, fun and
pred respectively. A fact specifies a constraint that is always assumed to hold. A predicate defines a reusable (i.e. parametrised) constraint. A function defines a reusable expression that returns a value. Figure 7.6 shows the anatomy of a basic Windows File System Model written in Alloy (that assumes that different types of file will be in different folders i.e. all files in each folder will be of same type).
module FileSystem sig Folder
{
//A folder can contain zero or more files and folders file:set File,
subFolder:set Folder
}
sig File
{ //A file can have only one name and type
name: one FileName,
type: one FileType,
//A File can be in only one folder
location: one Folder
}
sig FileName{}
//In our system, file types are predefined.
//They are limited to the following types: Txt, Doc, Jpg, Mp3, Mp4
abstract sig FileType {}
one sig Txt, Doc, Jpg, Mp3, Mp4 extends FileType{}
fact
{
//Two files cannot have the same name and the same type
all file1,file2:File | (file1.name = file2.name) && (file1.type = file2.type) <=> (file1=file2)
all file1:File, fldr:Folder | (file1.location=fldr) <=>
(file1 in fldr.file)
//Policy: All files in a folder must be of same type
all fldr :Folder | #fldr.file.type = 1
}
//MyVideosFolder will contain only Mp4 files
pred MyVideosFolder[fName:FileName] {
all f:File | f.name = fName && f.type = Mp4
}
run MyVideosFolder for 1 but exactly 1 Folder
//MyPicturesFolder will contain only Jpg files
pred MyPicturesFolder[fName:FileName] {
all f:File | f.name = fName && f.type = Jpg
}
run MyPicturesFolder for 1 but exactly 1 Folder pred MixedFileTypesInFolder[fName1,fName2:FileName,
type1,type2:FileType]
A Signature, which is defining a set of ‘Folder’ objects
Facts
(Constraints that always holds)
Predicate (Reusable constraints)
Scope Comment
'extends' indicates
mutually exclusive subsets Module Header
‘run’: Command to check the satisfiability of the named predicate
7.2.2
Alloy Analyzer
Alloy’s tool, the Alloy Analyzer [92, 64], is a model finder that finds a model by analysing specifications written in the Alloy specification language. Alloy Analyzer takes the constraints of a model and tries to find an instance that satisfies them within a given scope (see Section 7.2.3 for more details on scope). Alloy Analyzer internally uses a SAT solver to check if a predicate is satisfiable and returns true or false based on the predicate’s satisfiability. However, a negative result given by the Alloy Analyzer is not absolute, because it examines only a finite space of cases based on the given scope, and therefore the analysis is not complete.
A basic Integrated Development Environment (IDE) is provided for manually writing new Alloy models, opening and editing existing models and executing dif- ferent commands for finding satisfying instances of predicates and assertions. Sat- isfying instances of a model can also be graphically viewed (as shown in Figure 7.7) and customised in the Alloy Analyzer.
Figure 7.7: Instance of an Alloy Model
7.2.3
Scope
Since Alloy Analyzer tries to find an instance of a model within a given scope, a predicate that is unsatisfiable (i.e. no satisfying instance can be found) with
one scope may be satisfied in a larger scope. For example, consider a predicate expressing:
“The driver of a car lost control and hit another car”.
At least 1 person and 2 cars are needed to satisfy this predicate i.e. theminimum scope required to satisfy the above predicate is 1 person and 2 cars. Hence, Alloy Analyzer will find it unsatisfiable if it tries with a scope 1 person and 1 car. Alloy Analyzer may start with a minimum scope; however, it has to keep on searching for a satisfying assignment by gradually increasing the scope of each variable. The smallest scope that satisfies a predicate is referred to as a “minimal scope”. In many cases, the minimum scope required to satisfy a predicate is unique in a given context (i.e. with a given set of facts and assumptions). For example, based on the facts that ‘Blue is not Red’ and ‘a car cannot hit itself’, it is necessary to have at least two cars in the universe for the predicate ‘a blue car hit a red car’ to be satisfiable. However, there may be some predicates that may have more than one minimum scope. For example, there may be a predicate P, which has two variables A and B. Predicate P can be satisfied in a state with 1A and 2Bs, and P can also be satisfied in a state with 2As and 1B. The scopes of the variables in both of these states need to be recorded (stored in the database) as minimum satisfying scopes. A predicate along with each of its minimum satisfying scopes may be referred to as a variant of that predicate. For example, if a predicate P has two minimum satisfying scopes S1 and S2, then the predicate P is said to have two variants PS1 and PS2.
The world view construction procedure (explained later in this chapter) will treat each these variants as a distinct predicate, except that none of the world views will contain more than one variant of an original predicate. Suppose a predicate P has two minimal scopes S1 and S2. During the process of constructing world views, predicate P along with its scopes should be treated as two different predicates PS1
and PS2. However, PS1 and PS2 cannot appear in the same world view.