CS 674 Homework 2

In this homework you will create a class model, including operation
contracts, for a Conference Manager system.  As in homework 1, you
will use Alloy to define the model, to generate some interesting
example instances, and to check some properties.  In particular, you
will define a system invariant and check that the invariant is
maintained according to the operation specifications --like in the
second model for homework 1. 

What to submit:
---------------

By email, send one text file called  yourfamilyname-confmgr-hw.als .
Include comments to make it easy for me to see how your model captures 
the requirements.

There should be a signature called State that holds the information
that can be changed by operations, and a predicate called Invar(s:State) 
that defines the system invariant.

There should be at least one predicate and run command to generate an
interesting instance of your model. 

For each operation there should be an Alloy "assert" that says the operation
maintains the system invariant. (That is, if Invar is true in the initial state
then it is also true in the final state.)

I will test the models on the cs.lab machines only.


Problem Description:
------------------------

The purpose of the Conference Manager system is to coordinate
submission and review of research papers submitted to a scientific
conference. 

Each paper has one or more authors; the authors cannot be changed.
Each paper comes with a non-empty set of topics.  These help classify
the subject matter for reviewing purposes. (A real paper would also
have a title, an abstract, and the actual content of the paper, but we
won't need to model those.  The topics are also useful for people
doing keyword searches on the net, but again that's not relevant.) 

There is a program committee (PC) and one member of the committee
is the chair of the PC.  There are also people who are not necessarily
PC members, namely, external reviewers and authors.    Members of the
PC are allowed to submit papers (of course not review their own
paper). So your classification of people needs to use multiple
inheritance.  Every reviewer has some areas of expertise.

Hint: review "extends" versus "in" for signatures in Alloy.    
Hint: There is no operation to change the membership or the
chairperson of the PC, so that shouldn't be part of the state.

A reviewer can submit a review for a paper. The review contains a
judgement: accept, reject, or uncertain.  It also contains a
confidence level: expert, familiar, or unfamiliar (i.e., what does the
reviewer know about the topic of the paper).  

Here are some additional requirements.  (You need to decide whether
they're part of the system invariant or what.)

1) Every PC member is a reviewer.

2) Every reviewer reviews at least one paper.

3) Reviews should be reasonable about expertise. If someone reviews a paper 
and at least one of its topics is in their areas of expertise, then 
their review should not have a confidence level of "unfamiliar".
(E.g., Suppose my topics are DataMining and Robotics, and I review a paper
called "Privacy Preserving Data Mining" which has DataMining and Security as 
its topics.   The category DataMining is very general; I might be an
expert about security issues, or maybe just familiar with data
mining. But I shouldn't say I'm unfamiliar with the area.)

4) In order to to make the reviewing as fair as possible,
a person is not allowed to review paper of which they are an author.  Moreover,
a person cannot review a paper written by one of their collaborators.
Two people are collaborators if there is a paper (not necessarily submitted) on
which they are both authors.

5) A paper cannot be reviewed unless it has been submitted.


Operations 
----------

submitPaper(s,s': State, p: Paper) 
Submit a paper p to the conference. Add the paper to the collection of submitted
papers of the conference.  It should not already be submitted. [You need to
decide how to interpret that condition; maybe a precondition, or check and if  
it is false then the operation should do return an error indicator?]

assignReviewers(s,s': State, rs: set Reviewer, p: Paper, unrs: set Reviewer)
Assign reviewers for a submitted paper
For this operation, unrs is playing the role of a result parameter.  
The effect of this operation is to assign each r in rs to be a reviewer of p, 
except that requirement (4) about reviewers must not be violated.  If it would
violate the rules to allow r to review p, then r should be in unrs, and
moreover those are the only elements of unrs.

submitReview(s,s': State, r: Review, p: Paper)
Precondition: the reviewer in r is assigned to the paper.
Effect: add r to the reviews for p

readyToDecide(s: State) 
Describes the situation in which the PC is ready to make final
acceptance/rejection decisions.  That is, all reviewers have reviewed
at least one paper, and every submitted paper is ready for a
decision.  A paper is ready if it has at least three reviews and these
include at least two with "familiar" confidence or better.