Introduction to Alloy

Topic 1: Introduction

14 July 2013

In which we get started.

1 Preliminaries

1.1 Preliminaries

  • schedule
  • what's where
  • a warning
  • a request
  • goals of the course
  • organization of the course

1.2 What's where

  • parking: where did you park? did you pay?
  • restrooms
  • wireless
  • sign-in sheet
  • lunch, breaks

1.3 Goals of the course

When you leave, you should:
  • have an overview of Alloy
  • have used Alloy a bit yourself, hands-on
  • be able to fend for yourself
You will not become an expert here. (Sorry.)
Why won't you become an expert?
A lot of very bright people have spent more than a decade developing Alloy, and a lot of others have spent centuries developing its logical underpinnings. You are not going to master that technology in two days.
So you really need to learn to fend for yourselves. By that I mean that when you go back home and try to do something more ambitious, you will run into trouble (if your experience is at all like mine). You should know in principle what's possible, but when things don't work ‘right’ (i.e. as you expect), you need to be able to discover, in practice and in detail, what's wrong.
So in some of the exercises I am going to let you flounder a bit, while I stand by heartlessly watching you struggle. You need to get used to floundering; it's part of the task of learning a new language. (This is true both for programming languages and natural languages, by the way.)

1.4 Some things you won't learn

To fit the course in the time, we give some topics short shrift:
  • module structuring
  • utility library
  • identifier overloading
  • integers

1.5 Assumptions (about the environment)

The slides and exercises assume some things:
  • You have a network connection.
  • A reasonably current Java (5 or 6) is installed on your machine.
  • A copy of Alloy 4.2 is installed on your machine.
If any of these assumptions is false, please raise your hand now.

1.6 Assumptions (about you)

  • You have some interest in modeling.
  • You have a passing acquaintance with symbolic logic (or some tolerance for confusion).
  • You may have an interest in software development (as programmer or manager or client).
If any of these assumptions is false, please let me know.

1.7 Installing Alloy

Don't have Alloy installed?
  1. Navigate to http://alloy.mit.edu/
  2. Click Download.
  3. Select .jar or .dmg.
  4. Install in ‘the usual way’.

1.8 Rules

  • If you cannot hear, speak up.
  • If you do not understand, ask a question. (I may not answer right away.)
  • Digressions: please hold for break time.*
  • If I'm going too fast, let me know.
  • If I'm going too slow, and boring you, please signal “pick up the pace!” or “End the digression!”
  • In exercises, you may experiment with variations on the exercise. But if your experiments lead to complications, you're on your own.
* On digressions. I often find digressions seductive, so the point about digressions is as much for me as for the participants. You need to hold digressive questions for break time, because if you ask a tempting question, I may fall for it.

1.10 Acknowledgements

I thank the Alloy team in general for their work on the tool, and Daniel Jackson in particular for his friendly encouragement and help.
Syd Bauman reviewed a draft version of this course.

2 Introductions around the table

2.1 Introductions

  • What is your name?
  • Why are you here / what do you hope to learn?
  • Have you ever studied symbolic logic? written a computer program?
  • What is your favorite thing about Nebraska?

3 Modeling, formal methods, Alloy

3.1 What is modeling?

To an observer B, an object A* is a model of an object A to the extent that B can use A* to answer questions that interest him about A.

Marvin Minsky, ‘Matter, Mind and Models’ (1954, rev. 1968, rev. 1995).
As a definition, this isn't much good, because it includes a lot that we don't think of as models (native speakers as a way to answer questions about their languages; books to answer questions about their topics, ...).
But it does capture some key aspects of models:
  • Models (like A*) are models of something (A).
  • Models (like A*) are models for someone (B) and for some purpose.
  • Models need not be complete.

3.2 Axes of variation

Models vary in several ways:
  • a priori vs a posteriori
  • utilitarian or ends in themselves
  • formal or informal
  • prescriptive vs. descriptive
  • for ourselves or for others

3.3 Abstraction

No substantial part of the universe is so simple that it can be grasped and controlled without abstraction. Abstraction consists in replacing the part of the universe under consideration by a model of similar but simpler structure.

Rosenblueth and Wiener, ‘The role of models in science’, Philosophy of Science 12 (1945): 316
Rosenblueth and Wiener continue “Models, formal or intellectual on the one hand, or material on the other, are thus a central necessity of scientific procedure.”

3.4 Simplification

Models typically simplify the object:
  • as a pragmatic compromise (to keep cost low).
  • as a pedagogic or heuristic device.
  • as an attempt to distinguish essence from accidence.

3.5 What is modeling (2)

Modeling is the making explicit of our assumptions and beliefs about a thing.
More precisely: Modeling is the making more or less explicit of some of our assumptions and beliefs about a thing.

3.6 What's it good for?

Models can aid:
  • planning (e.g. for software design)
  • clarity, pedagogy
  • insight

3.7 Modeling for planning

Ihr [der EDV] Einsatz ist überall dort möglich, wo Daten irgendwelcher Art — also auch Texte — nach eindeutig formulierbaren und vollständig formalisierbaren Regeln verarbeitet werden müssen.
Wilhelm Ott, Metrische Analysen zu Vergils Aeneis, Buch VI (Tübingen: Niemeyer, 1973), p v.

3.8 Modeling for clarity of thinking

No, humanists don't need to write their own programs ... But experience with computer programming provides an understanding of fundamental computing concepts, familiarity with the principles of algorithmic thought, and a grasp of the ways in which information is stored, accessed, and manipulated ...
So, yes, humanists need to learn how to program, not in order to write their own software but to learn how to look at the materials within their disciplines in new ways and intelligently utilize (and perhaps develop) tools that help them do it.
Nancy M. Ide, Pascal for the humanities (Philadelphia: Univ. of Pennsylvania Press, 1977), p. X.

3.9 Modeling for insight

I think that some of those linguists who have questioned the value of precise and technical development of linguistic theory may have failed to recognize the productive potential in the method of rigorously stating a proposed theory and applying it strictly to linguistic material with no attempt to avoid unacceptable conclusions by ad hoc adjustments or loose formulation.

Noam Chomsky, Syntactic Structures (The Hague: Mouton, 1957), p. [5]

3.10 Software models

Programs are explicit, and in some ways formal.
Are they models?
In some sense, yes. But not necessarily clean, clear, insightful, or insight-inducing.
And very hard to reason about.

3.11 Taking modeling seriously

So, if we want to model things, how should we go about it?
  • metaphor (“the desktop model” of user interfaces)
  • small-scale working systems (mockups, prototypes)
  • database designs
  • vocabulary designs (DTD, XSD, RNG, ...)
  • programs
  • symbolic logic
This course is about the last option.

3.12 A virtue of formality

Precisely constructed models for linguistic structure can play an important role, both negative and positive, in the process of discovery itself. By pushing a precise but inadequate formulation to an unacceptable conclusion, we can often expose the exact source of this inadequacy and, consequently, gain a deeper understanding of the linguistic data. More positively, a formalized theory may automatically provide solutions for many problems other than those for which it was explicitly designed.

Noam Chomsky, Syntactic Structures, p [5]

3.13 More Chomsky ...

Obscure and intuition-bound notions can neither lead to absurd conclusions nor provide new and correct ones, and hence they fail to be useful in two important respects.

Noam Chomsky, Syntactic Structures, p [5].

3.14 Logic

Logic attempts to make common sense more systematic.
What are the formal patterns of reasoning that produce true inferences from true premises?

3.15 The automation of logic

Long process or formalization and automation:
  • medieval syllogistic (and Llull!)
  • Leibniz and mechanical reasoning
  • Boole and algebraic logic
  • Peano, Frege, Russell/Whitehead
  • Hilbert, Gödel, Herbrand, Gentzen
  • Robinson, unification, Prolog
  • theorem provers

3.16 Formal methods

Formal methods are “mathematically rigorous techniques and tools for the specification, design and verification of software and hardware systems” (-Butler).
  • formal specification (VDM, Z, ...)
  • formal development
  • formal verification
  • machine proofs
Isn't that way too complicated?

3.17 Lightweight formal methods

Getting the advantages of formal methods without a big initial investment.

3.18 Alloy

A modeling tool aimed at lightweight formal methods, especially sanity checking for software designs.
Daniel Jackson, Software abstractions (Cambridge: MIT Press, 2006, 2d ed. 2012).
Exploits progress in ‘model-checking software’ and SAT-checking.

4 Concrete examples

Watch this space.

5 Using the Analyzer

5.1 The absolute minimum of Alloy syntax

Minimal pattern of a model: signatures, facts, predicates, assertions:
// hello, world
sig res {}
sig terra, caelum extends res {}
sig creator in res {
  creavit : set res
}
sig Deus extends creator {}{
  creavit = terra + caelum
}
fact unus_deus { one Deus }
pred creata [ r : res ] {
  some c : creator | r in c.creavit
}
assert deus_creator { Deus in creator }
assert deus_solus_creator { creator in Deus }

5.2 Declaring signatures

A signature is (or: “introduces”) a set of atoms.
sig res {}
sig terra, caelum extends res {}
sig creator in res { ... }
sig Deus extends creator {}{ ... }
  • The sets res, terra, caelum, creator, and Deus exist.
  • terra, caelum, and creator are subsets of res.
  • Deus is a subset of creator.

5.3 Facts

A fact expresses an invariant axiomatic truth.
fact unus_deus { one Deus }
  • The set Deus has exactly one member.

5.4 Predicates

A predicate defines a state of affairs or condition which may or may not apply.
pred creata [ r : res ] {
  some c : creator | r in c.creavit
}
  • The predicate creata is true of some atom r from the set res, if and only if there is some atom c from the set creator, such that the pair (c, r) is in the set creavit (or equivalently: iff r is a member of the set c.creavit).
The run command asks the Analyzer to find an instance of a predicate.
run creata
run ecce

5.5 Assertions

An assertion claims that a state of affairs applies.
assert deus_creator { Deus in creator }
assert deus_solus_creator { creator in Deus }
  • The (singleton) set Deus is a subset of the set creator (i.e. Deuscreator; informally, Deus is a creator).
  • The set creator is a subset of the set Deus (informally: only Deus is a creator).
The check command asks for a counter-example.
check deus_creator
check deus_solus_creator

5.6 Hello, world

Now try this yourselves.