\documentclass{article}
\usepackage{html}
\usepackage{amsmath}
\usepackage{hyperref}
\usepackage{epsfig}

\input{preamble.tex}

\newcommand{\lk}[2]{\htmladdnormallink{#1}{#2}}
\newcommand{\tup}[1]{\langle #1 \rangle}

\begin{document}
\lecture{1: Course Overview and Introduction to Alloy}{February 6, 2001}{Daniel Jackson}{Bill Thies}

\section{Course Overview}

\subsection{Contacting the Lecturer}

Please use the email address {\bf {\tt
\lk{dnj+6898@mit.edu}{mailto:dnj+6898@mit.edu}}} to contact Daniel, to
help him organize mail for the course.

\subsection{Expectations}

The following tasks are expected to be completed by the student.  They
are described in more detail on the course \lk{webpage}{http://theory.lcs.mit.edu/~dnj/6898/index.html}.

\begin{itemize}

\item Scribe one lecture -- take notes and write them up in HTML.
There might be enough people registered for the course that not
everyone will have to scribe.

\item Attend class and participate.

\item Read assigned
\lk{papers}{http://theory.lcs.mit.edu/~dnj/6898/readings.html}, and
answer a few short questions about the papers before coming to class.
These answers should be emailed to
\lk{Daniel}{mailto:dnj+6898@mit.edu} the day before the class meeting.

\item Complete three projects:

\begin{enumerate}

\item A modeling exercise.  This will be challenging, but not
open-ended.

\item A programming exercise.

\item A term project.  The project can be of three types:

\begin{enumerate}

\item Do an open-ended research project.  This can be done in a team
or individually, and will result in a paper with an oral presentation.

\item Build something as a design project.  This must be done
individually, and requires only a written presentation.

\item Re-design an existing piece of software, as a design ``clinic''.
This must be done individually, and requires only a written
presentation.

\end{enumerate}

\end{enumerate}

\end{itemize}

In all, the course should require an average of about 6 hours/week of
outside work, but the work will be sporadic since there are only a few
assignments.

\subsection{Collaboration Policy}

It is fine to discuss solutions in a group, but all work that is
handed in must be {\it written} individually.

\subsection{Course Outline}

This course will focus on advanced topics of software design.  We will
concentrate on how to express, analyze, and realize high-level design
ideas, and will examine current techniques, languages, tools, and
methods in the field.  We will try to bring together perspectives from
different communities, including:

\begin{enumerate}

\item The programming language community, especially those interested
in functional programming.

\item The formal methods community.

\item The ``extreme programming'' community, which embraces
open-source models with communal incremental refactoring of code.

\item The theoretical design community, {\it e.g.} those that are
interested in decoupling theory.  This area the lecturer is less
familiar with, but is interested in exploring as part of the course.

\end{enumerate}

Speaking of communities, Alan Donovan is organizing a programming
languages \lk{reading
group}{http://pag.lcs.mit.edu/~adonovan/reading-group/} that meets
from 4-5 p.m. on Tuesdays.  Everyone is welcome to join.

\subsubsection{The Lecturer's Biases}

Daniel gave a disclaimer as to his own biases in software design.
They include:

\begin{enumerate}

\item {\bf He is a reductionist}.  How can you capture the essence of
software?  What makes a design different from other designs?  How can
designs be most simple?

\item {\bf He likes tools}.  It's kind of strange to note that
software designers are one of the only ``computer scientists'' who
don't necessarily use computers in their work -- currently, they just
think about the design without much help of automated tools.  This is
especially true for the early stages of design.  Some people are
concerned that software design is a craft, and shouldn't be reduced to
a science--a tool would be too rigid and restrictive.  However, most
people don't take this view about structured programming, even though
it met with some resistance at first.  Is it possible to factor out
repeated human tasks and capture common structures in the design
process, too?

\item Regarding formal methods, {\bf he likes lightweight formalism}.
Some people argue for reducing all of software design into a
mathematical formula, but this has the unappealing aspects of 1) not
really capturing everything in the design, and 2) not being practical.
Instead, the use of formal methods should be risk-driven, motivated by
``bang for the buck''.  For example, if a product needs to be highly
reliable, then lightweight methods can be valuable for providing a
precise design and a mechanical analysis of the program's properties.

\end{enumerate}

\subsubsection{Topics to be Covered}

There are four main topics planned for the course, although they are
flexible:

\begin{enumerate}

\item {\bf Modeling Languages}, including the idioms and analyses that
are characteristic of each.  We will start with
\lk{Alloy}{http://sdg.lcs.mit.edu/alloy/}, the language being
developed in Daniel's group.  This will provide a clean notation to
use for discussing design ideas in the remainder of the class.  Also,
we'll consider \lk{JML}{http://www.cs.iastate.edu/~leavens/JML.html}.

\item {\bf Design Patterns}.  There are two types of patterns that we
will consider:

\begin{itemize}

\item {\it Patterns of Problems}.  These include \lk{Martin
Fowler's}{http://www.martinfowler.com/} \lk{book}{
http://www.amazon.com/exec/obidos/ASIN/0201895420/002-7423095-5935232}
on refactoring, and \lk{Michael
Jackson's}{http://dspace.dial.pipex.com/jacksonma/} work on problem
frames.  The latter work takes the approach of classifying design
problems into known categories before attempting solutions.

\item {\it Patterns of Solutions}.  This includes the classic
\lk{Design Patterns}{http://hillside.net/patterns/DPBook/DPBook.html}
book by the \lk{Gang of
Four}{http://hillside.net/patterns/DPBook/GOF.html}.

\end{itemize}

\item {\bf Programming Language support} for software design.
Examples include:

\begin{enumerate} 

\item {\it Functors}, which are constructs in ML for building module
generators and sharing constraints.

\item {\it Type classes}, which are provided in
\lk{Haskell}{http://www.haskell.org/} as a decoupling mechanism for
something related to overloading.

\item {\it Units}, a theoretical idea that is being developed by
\lk{Matthias
Felleisen}{http://www.ccs.neu.edu/home/matthias/index.html} (who is
teaching a related type-theory
\lk{course}{http://www.ccs.neu.edu/home/matthias/3810-w02/} at
Northeastern this spring).  Units are being incorporated into the Java
pre-processor.

\item {\it Open Classes}, which allows one to dynamically add methods
to a class.

\item {\it Aspect-Oriented Programming}, which is a technology for
separation of concerns in software development.

\end{enumerate}

\item {\bf Theoretical underpinnings}, including \lk{Nam
Suh's}{http://me.mit.edu/people/npsuh.html} work on software design,
as well as \lk{Design
Rules}{http://www.amazon.com/exec/obidos/ASIN/0262024667/002-7423095-5935232}
by \lk{Thomas Baldwin}{http://www.dcs.shef.ac.uk/~tom/} and Kim Clark,
which views design from the perspective of economic theory.

\end{enumerate}

\section{Introduction to Alloy}

We'll discuss the Alloy language at the beginning of this class, both
as a foundation for discussing design concepts later, and as a means
for understanding a modeling language.  Alloy has some operators that
are generalized versions of normal operators, which makes it very
succinct and expressive.

\subsection{Overview}

The high-level ideas and properties of Alloy are as follows:

\begin{enumerate}

\item {\bf Declarative Modeling}.  Alloy is for recognizing that a
program has a given property.  It answers the modeler's question ``how
can I recognize that property {\it P} has happened?'' rather than the
engineer's question of ``how can I make property {\it P} happen?''
Also, Alloy code can be executed, {\it e.g.} to demonstrate that a
sorting algorithm works.

\item {\bf Expresses Structure}.  Everything in Alloy is done with
relations -- there are no sets or other mathematical entities in the
language.  This keeps things simple.

\item {\bf First-Order}.  All the logical constraints in Alloy are
first-order, which allows them to be analyzed automatically with a
tool.  This is in contrast to some higher-order logics that are harder
to analyze.

\item {\bf Slick Syntax}.  The syntax is designed to be compact and
completely textual, so that you don't need \LaTeX~to get it onto paper.

\end{enumerate}

The following sections describe the main concepts of Alloy in more
detail.

\subsection{Atoms}

An {\it atom} is the basic modeling object in Alloy.  An atom is:

\begin{enumerate}

\item {\bf Indivisible}.  It has no parts.

\item {\bf Immutable}.  It doesn't change over time.

\item {\bf Uninterpreted}.  That is, there is no ``theory'' coming
with it--for example, numbers don't count as atoms.

\end{enumerate}

We pretend that things are atoms even when they're not, since not many
things in real life strictly satisfy the above properties.  For
example, we can model a compound object $a$ that contains two
components $b$ and $c$ by treating all three objects as atoms and
defining a $contains$ relation:
\begin{figure}[h]
\centering
\psfig{figure=1.pdf,width=1.5in}
\end{figure}
\subsection{Basic Types}

Every atom in Alloy belongs to a single {\it basic type}.  That is,
there is no subtyping in Alloy, and all basic types are disjoint.  We
write basic types in capital letters:

\begin{figure}[h]
\centering
\psfig{figure=2.pdf,width=2in}
%\caption{Basic types.\protect\label{fig:types}}
\end{figure}

The types of atoms are not declared, but inferred by Alloy from the
types of relations (see below) that are used with the atoms.

\subsection{Relations}

Every expression in Alloy is a relation.  A relation is a set of
tuples, where each element of the tuple is of a basic type.  One can
visualize a relation as a fixed-width table with one or more columns
and zero or more rows; each row is a tuple of the relation.  All of
the entries in a given column must have the same basic type.  As in
other applications, the number of columns is called the {\it arity} of
the relation, and the number of rows is called the {\it cardinality}.

Alloy allows arbitrary $k$-relations (the arity can be any natural
number).  We'll refer to 1-relations as {\it unary}, 2-relations as
{\it binary}, and 3-relations as {\it ternary}.  Sometimes people use
the word ``relation'' to describe only binary relations.  We'll
consider sets to be unary relations, as they are just an unordered
list of atoms.

\subsection*{Example}

We are going to define some relations.  First we give their types:
\begin{verbatim}
        spouse:  <PERSON, PERSON>
        sibling: <PERSON, PERSON>
        Daniel:  <PERSON>
        Tim:     <PERSON>
        Claudia: <PERSON>
        Emily:   <PERSON>
\end{verbatim}
Each of the relations above is a {\it variable}.  {\tt Daniel} is a
unary relation (which we also refer to as a {\it set}), and in this
case we presume that it contains only one element ({\it i.e.,} it is
is a {\it singleton})--we use the word {\it scalar} to refer to
singleton sets.  We could say that {\tt Daniel} is an instance of the
{\tt DANIEL} atom.  Atoms are never declared explicitly; Alloy is
concerned only with variables, and it ``generates'' atoms.

Now let us specify some values for the relations above:
\begin{verbatim}
        spouse:  { (Daniel, Claudia), 
                   (Claudia, Daniel),
                   (Tim, Emily),
                   (Emily, Tim) }

        sibling: { (Daniel, Tim),
                   (Tim, Daniel),
                   (Claudia, Emily),
                   (Emily, Claudia) }
\end{verbatim}
As depicted in Figure~\ref{fig:family}, these relations illustrate the
lecturer's remark:  ``If you didn't know me, you wouldn't know that
I'm a living example of a commuting diagram!''
\begin{figure}[t]
\centering
\psfig{figure=3.pdf,width=3in}

\parbox{3in}{\caption{Example of some relations.  Here, a
bi-directional arrow is used for shorthand to indicate a relation in
both directions.\protect\label{fig:family}}}
\end{figure}

To get a taste of Alloy, we can express this remark in the language:
\begin{verbatim}
        Some ( Daniel.spouse.sibling & 
               Daniel.sibling.spouse )
\end{verbatim}
This states that the intersection between Daniel's spouse's siblings
and his sibling's spouses is non-empty.

\subsection*{Notes}
A few notes about relations:
\begin{itemize}

\item Note the tuple-notation \verb+(a, b)+ denotes an {\it ordered}
list of {\tt a} and {\tt b}.  As usual, the notation \verb+{a, b}+
denotes an unordered set.

\item In Alloy (unlike in some set theories), there is no distinction
between a variable $a$, a 1-tuple of $a$, a singleton set $a$, and a
singleton set of the 1-tuple of $a$.  That is, in Alloy syntax,
\verb+a = (a) = {a} = {(a)}+.

\item The relations defined above are all {\it homogeneous}, meaning
that they relate variables of the same type.  Alloy also supports {\it
heterogeneous} relations between variables of different types.  For
example, one could define a relation for a routing table as \verb+table: <ROUTER, IP, LINK>+

\end{itemize}

\subsection{Operators}

\subsubsection{Binary Operators}

\begin{table}[t]
\centering
\begin{tabular}{|c|c|c|} \hline
{\bf Type} & {\bf Symbol} & {\bf Meaning} \\
\hline
Set & + & union \\
\hline
& - & difference \\
\hline
& \& & intersection \\
\hline
Comparison & in & subset \\ \hline
& = & equality (have same set of tuples) \\ \hline
Relational & $\sim$ & transpose \\ \hline
& $\rightarrow$ & product \\ \hline
& . & join \\ \hline
\end{tabular}
\caption{Binary operators in Alloy.\protect\label{tab:oper}}
\end{table}

Some of the binary operators that Alloy supports are shown in
Table~\ref{tab:oper}.  A few of the operators deserve further
explanation:

\subsubsection*{Transpose}

The transpose operation is only defined for binary relations.  So, for
example, \verb+~parents = child+ .

\subsubsection*{Product}

The product operation is defined as follows:
\begin{align*}
[[p \rightarrow q]] = \{~&(s_1, \dots, s_n, t_1, \dots, t_m) \\
 &|~~(s_1, \dots, s_n) \in [[p]] ~~\wedge \\
 &~~~(t_1, \dots, t_m) \in [[q]]~\}
\end{align*}
Roughly speaking, the product operation takes all combinations of
elements in $p$ followed by elements in $q$.  For example, if we have
the following relations:
\begin{verbatim}
        Knows:        <PERSON, PROGRAMMING-LANGUAGE>
        MITGrad:      <PERSON>
        LISP-Dialect: <PROGRAMMING-LANGUAGE>
\end{verbatim}
then the assertion \verb+MITGrad+$\rightarrow$\verb+LISP-Dialect+
would mean that all MIT graduates know all dialects of LISP.

\subsubsection*{Join}

The join operation is defined as follows:
\begin{align*}
[[p.q]] = \{~&(s_1, \dots, s_{n-1}, t_2, \dots, t_m) \\
 &|~~(s_1, \dots, s_n) \in [[p]] ~~\wedge \\
 &~~~(t_1, \dots, t_m) \in [[q]] ~~\wedge \\ 
 &~~~s_n = t_1~\}
\end{align*}
That is, the join operation ``links together'' tuples from $p$ and $q$
that have matching ends, and the element that matches is omitted from
the linked set.  For example, if we have the following relations:
\begin{verbatim}
        room:  <STUDENT, ROOMS>
        phone: <ROOM, PHONE>
\end{verbatim}
with the following values:
\begin{verbatim}
        room:  { (s1, r1), (s2, r1), (s3, r2), (s4, r3) }
        phone: { (r1, p1), (r2, p2) }
\end{verbatim}
Then the expression \verb+room.phone+ gives you
\verb+{ (s1, p1), (s2, p1), (s3, p2) }+, as illustrated by the
following diagram:
\begin{figure}[h]
\centering
\parbox{2in}{\psfig{figure=4.pdf,width=2in} \\ \\ The {\tt room} and {\tt phone} relations.} \hspace{1in} \parbox{2in}{\psfig{figure=5.pdf,width=1.3in} \\ \\ The {\tt room.phone} relation.}
\end{figure}

As an example of the join operator, we can note that
\verb+Daniel.parents = ~parents.Daniel+ .

\subsubsection{Constants}

Before we can define the closure operator, we need some expressions
for constructing standard expressions in Alloy.  These expressions are
as follows:

\begin{table}[h]
\centering
\begin{tabular}{|c|c|c|} \hline
{\bf Expression} & {\bf Type Signature} & {\bf Meaning} \\
\hline
none[$r$] & $\tup{t_1,t_2} \rightarrow \tup{t_1,t_2}$ & \begin{minipage}{3.2in}~ \\ Given a relation $r$,
returns the empty relation $\{\}$ within the same domain as $r$ \\ \end{minipage} \\ \hline
iden[$e$] & $t \rightarrow \tup{t,t}$ & \begin{minipage}{3.2in} ~ \\ Given an expression $e$ of basic type $t$, returns
the relation $\{(a, a)~|~ a \in t\}$ -- that is, the relation
that maps each element to itself. \\ \end{minipage} \\ \hline
univ[$r$] & $\tup{t_1,t_2} \rightarrow \tup{t_1,t_2}$
& \begin{minipage}{3.2in} ~ \\ Given a relation $r: \tup{t_1,t_2}$, returns the relation
$\{\tup{a,b}~|~a \in t_1, b \in t_2\}$ -- that is, the universal
relation that maps every element of type $t_1$ to every element of
type $t_2$. \\ \end{minipage} \\ \hline
\end{tabular}
\end{table}

In the use of these constants in the following sections, we are
slightly sloppy about the arguments that are passed to the
constructors.  This issue will become clear in the following lectures
once we talk about declaring {\it signatures}.

\subsubsection{Closure}

We can now define the closure operators:

\begin{table}[h]
\centering
\begin{tabular}{|c|c|} \hline
{\bf Operator} & {\bf Meaning} \\
\hline
\verb+^+$r$ & $r + r.r + r.r.r + \dots$ \\ \hline
$\ast r$ & iden[$r$] + \verb+^+$r$ \\
\hline
\end{tabular}
\end{table}

For example, \verb+ancestor = ^parent+ .

\subsubsection{Navigation Expressions}

Let's compare the use of the join operator as a navigator for
relations with the navigation of Java fields and methods via the same
syntax.  In both Alloy and Java, you could write something like
\verb+x.f.g+ .  The difference is that in Alloy, {\tt x} could map to
either none, one, or many variables, whereas in Java it can map to
either one or none (if the object is {\tt null}).

In addition, Alloy allows {\it branching} and {\it iterative}
constructors as part of join operations, which further tightens the
syntax.  An example of branching is \verb-Daniel.(spouse + sibling)-,
which gives both the spouse and siblings of Daniel.  An example of
iteration is \verb+Daniel.^friend+, which gives the entire network of
Daniel's friends.  As another example, if \verb+next+ is a list, then
\verb+l.^next+ gives all the elements of the list.  Finally, the
following assertion states that there are no cycles in a list:
\begin{verbatim}
        ^next & iden[list] = none[list]
\end{verbatim}

\subsection{Properties of Operators}

We could consider the following properties of binary relations (we
give them with their Alloy syntax):

\begin{itemize}

\item {\bf Homogeneous.}  The types in the relation are the same.

\item {\bf Heterogeneous.}  The types in the relation are different.

\item {\bf Functional.}  Each atom is mapped to at most one other: \verb+no a:t | #a.r > 1+

\item {\bf Injective.}  No two disjoint elements map to the same
element.  We have to express this in set terms in case the relation is
not functional (an element maps to more than one element):

\verb+no a:t | #a.~r > 1+

\item {\bf Reflexive.}  \verb+all a:t | a->a in r+

\item {\bf Symmetric.}  \verb+all a:t | a->b in r => b->a in r+

\item {\bf Transitive.} \verb+all a,b,c:t | (a->b in r && b->c in r) => (b->c in r)+

\item {\bf Irreflexive.} \verb+no a:t | a->a in r+

\item {\bf Anti-symmetric.}
\verb+all a,b:t | (a->b in r && b->a in r) => a=b+

\end{itemize}

\subsection{Examples}

Finally, we consider some examples of binary relations and the
properties that these relations might have.  In designing software, it
is useful to think about these properties before doing an
implementation.

\subsubsection*{Containment}
\begin{verbatim}
        folderContents: <FOLDER, MSG>
\end{verbatim}
This relation is heterogeneous, which implies that folders can't
contain other folders.  Also, it is usually injective in most
implementations, where a message is only in one folder.  However, it
wouldn't have to be this way (you could have overlapping folders).

\begin{verbatim}
        groupContains: <OBJ, OBJ>
\end{verbatim}
This is a homogeneous relation.  We would expect it to be irreflexive,
since groups shouldn't contain each other.

\subsubsection*{Labeling}
\begin{verbatim}
        ip: <MACHINE, IP>
\end{verbatim}
This relation maps machines to IP addresses.  We would expect it to be
injective at any given time, since no two machines have the same IP
address at once.  However, since a time is not specified as part of
the tuple, the relation as written could cover many times and thus
might not be injective.

\subsubsection*{Security}
\begin{verbatim}
        canReadDoesBy: <PERSON, PERSON>
\end{verbatim}
This relation is expressing if one person can read what another person
does.  We would expect it to be transitive, but not symmetric.

\subsubsection*{Graphics}
\begin{verbatim}
        occludes: <WINDOW, WINDOW>
\end{verbatim}
This relation expresses whether or not a window on the screen occludes
another.  We would expect it to be asymmetric, since windows can't
occlude each other.  However, it is not transitive (even in one
dimension!)

\subsubsection*{Grouping}
\begin{verbatim}
        conflicts: <MACHINE, MACHINE>
\end{verbatim}
We didn't have time to talk about this one.

\subsubsection*{Linking}
\begin{verbatim}
        links: <URL, URL>
\end{verbatim}
We didn't have time to talk about this one.

\section{Next Time}

Next week, we'll look at the Alloy language itself on Monday and use
it to consider software idioms on Wednesday.

\end{document}







