{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

10-alloy

# 10-alloy - Alloy Readings Section 2.7 In this module we...

This preview shows pages 1–7. Sign up to view the full content.

Alloy Readings: Section 2.7. In this module, we look at Alloy, an analyzer that uses a simple structural modelling language based on first-order logic. Alloy is a free download for all major platforms from alloy.mit.edu , and we encourage you to download it and experiment with it. The textbook uses the syntax from an earlier version (2.0), but we will be using 3.0 syntax in our examples. 1

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document
Specification and modelling We have seen that it is decidable whether M | = φ for a finite model M , and typically the structures we are working with in computer science are finite. However, if φ describes some property of a software design, then this may be too restrictive, as we are committing to a particular model. A better option might be to describe the specification of our design by a set of formulas Γ , and then show that Γ | = φ . However, we know that this is undecidable. Alloy attempts to attain the advantages of both these approaches. 2
It does so by restricting the size of models under consideration to some small finite number. Semantic entailment thus becomes decidable. The language of Alloy combines elements of predicate logic, mathematics, and computer science. It offers a fairly natural way to specify a system. That being done, there are two ways it can be used: we can make a logical assertion and ask Alloy to find a counterexample of bounded size, or we can ask Alloy to verify that the assertion holds in all models of bounded size. This facilitates interactive refinement of a specification. 3

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document
Signatures An Alloy file starts with a module statement. We will not be talking about situations where multiple modules are used, so this is just a bit of necessary naming syntax. Next come a number of signatures , or structured types. These are reminiscent of structures in imperative languages, or class definitions in object-oriented languages. However, it is possible for a signature to have no internal structure. As our first example, we will revisit the “None of Alma’s lovers’ lovers love her” situation from lecture module 07, which the text also reuses in section 2.7. 4
module AboutAlma sig Person {} sig SoapOpera { cast : set Person, alma : cast, loves : cast -> cast } Here, Person is a type with no internal structure, and SoapOpera contains what appear to be three fields. One has name cast and represents a set whose elements are of type Person ; one has name alma , and is an element of cast ; and one is clearly intended to represent the “loves” relation among the cast of characters of the soap opera. 5

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document
Interpretations of Alloy signatures The most obvious interpretation is the object-oriented one, though already the declaration alma:cast seems to violate the typing rules we know from programming languages. The OO interpretation can help when trying to understand code, but in order to write it and to understand error messages, we have to go deeper.
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

### Page1 / 43

10-alloy - Alloy Readings Section 2.7 In this module we...

This preview shows document pages 1 - 7. Sign up to view the full document.

View Full Document
Ask a homework question - tutors are online