Problem Description:
------------------------
You are to develop a simple model of a system for managing "ground
traffic" at an airport.  Such a system might be used by to advise
controllers about the safe movement of vehicles on the ground.  For
the purposes of this problem we can consider an airport to have two
basic kinds of resources: fixed resources (special locations) and
mobile resources.  Fixed resources include gates, runways, and
taxi-ways.  Airports have mobile resources like planes and service
vehicles (trucks for delivering fuel/food/etc.).  You are to develop a
very abstract model of the relationships between these kinds of
resources and explore the model using the Alloy analyzer.

It is often useful to distinguish between modeling of the
"environment" or physical conditions in which a system will execute
and modeling of the intended behavioral policies of the system.  In
this problem there is a clear distinction.  For example, we clearly
should model the physical condition that mobile resources can only be
one place at a time.  On the other hand, we would like "ground
traffic" to behave according to certain guidelines or policies which
our ground traffic control system will work to enforce.  For example,
one such policy is that only planes (and not service vehicles) can be
on runways.  In any case, the model must encode both types of
constraints, and as an analyst, we want to make sure that our policy
constraints can actually be satisfied in the presence of the given
physical constraints.

Here are some physical environment constraints and policy constraints
on resources that you must incorporate into your model:

 i)   Resources like planes and vehicles can be at one place at a time. 
 ii)  Only planes can be on runways.
 iii) Gates can have a single plane.
 iv)  Gates can have multiple service vehicles.
 v)   If a plane is at a gate, then a vehicle should be there to service it.

The first constraint is a property of the environment for our
"ground traffic control" system.  The last four constraints are
desired behaviors of that control system.  Alloy and its analyzer
do not make a distinction between the source of constraints. 
As specifiers we do this since the environment constraints are fixed;
any system we build must operate with those constraints.
We may choose, however, to vary the constraints that capture desired
system behavior to produce a workable system.

You will find that the Alloy analyzer will sometimes produce "trivial"
instances or counter-examples.  To make your model more realistic you
should include "realism" constraints that insure the existence of some
instances of each of the kinds of resources at the airport.

Do the following:

1) Generate an instance of the airport and insert this instance into
   your assignment solution.

2) Enable your "realism" constraints and generate another instance.
   Are they different? If so, insert the new instance into your 
   assignment solution.

3) Decrease the size of the scope to 2?  Run your analysis.  What
   happens?  Is the generated instance the same as in 1)?  If not,
   explain why not and insert the new instance into your assignment
   solution.  Does the inclusion of "realism" constraints affect
   your results?  If so, explain how and insert the new instance
   into your assignment solution.

4) Increase the size of the scope to 4?  Run your analysis.
   What happens?  Is the instance the same as in 1)? If not,
   explain why not and insert the new instance into your assignment
   solution.

5) Constraint v) from above requires the presence of a vehicle
   to service a plane.  Can service vehicles be present at a gate
   when a plane is not?  How would you generate a model instance that
   illustrates this using Alloy analyzer?  Insert the model instance
   into your assignment solution.

Notes and Hints:
--------------------

There are many ways to solve this problem.  Alloy allows constraints
to be encoded with types (definitions of sets and relation
multiplicities), conditions, definitions and invariants.  If you encode a
constraint in the types then their is no need to add another 
model component, e.g., an invariant, to enforce the constraint.

In defining a specification model like this it is often useful to
"layer" the constraints.  In this problem, you might define
constraints that apply to an entire class of resources, then define
constraints that apply to specific sub-classes of resources.  In this
way the instances of the sub-classes will "inherit" the constraints on
the broader class.

There are multiple ways to generate instances that satisfy a
particular property.  Asserting the negation of the property
and checking the assertion will cause ACA to generate a counter-example.
A counter-example to the negation of the property is an instance
satisfying the property (think about it).  A more direct approach
is to use conditions.  You can use conditions in a formula so
its possible to define a one condition as the conjunction of
several others.

After carrying the required actions above, our model solution
consisted of 22 lines of Alloy using a model comprised of: 2 domains,
5 sets, 2 relations, 3 invariants, and 2-3 conditions or assertions.

The most complicated formula we used had the form:

  quantifier id : set | 
    quantifier (expr expr-op set) logic-op quantifier (expr expr-op set)