Peer Review Form for Robust IntRelation
=======================================

Reviewer information
--------------------

Name:
Id.number:
Date:

Criteria
--------

Rate each of the following five items on a scale from 0 through 2,
and motivate the score.  Enter these results in the template below
the cut line.

When filled out, submit this entire file as review report and submit
the total score as Grade for the peer review.


1. Data Representation

The data representation should balance memory usage and
efficiency of operations.  In this case, it should use a
Map<Integer, Set<Integer>> to store the related pairs,
so that sparse relations use less memory and still perform well.
The relation's extent must be stored separately, because it cannot be
inferred from the map of sets.

  2. The data representation consists of
     one private Map<Integer, Set<Integer>> (for the relation) and
     one private int (for the extent).
     Protected instead of private is OK, since it.  might be useful
     when extending this implementation.

  1. The data representation consists of the items under 2 above AND
     additional variables, OR one of the items is not private/protected.

  0. The data representation misses items under 2 above, OR uses other types,
     OR has multiple fields that are not private/protected.

Briefly point out enough violations to explain a score < 2.


2. Representation Invariant

Not all possible values for the data representation are desirable.
In this case, we wanted to exclude elements  a  that are not related
to some element  b  from the map.  Thus, the rep invariant must
express that if key  a  occurs in the map, then its set is not empty.
In particular, if  a  occurs as key in the map, then it is not
mapped to null.

  2. The rep invariant FORMALLY expresses the minimality requirement above.

  1. The rep invariant expresses the minimality requirement above INFORMALLY,
     OR the formal expression has a conjunct to address minimality but
     it contains a "small" (easily repairable) mistake.

  0. The rep invariant does not (correctly) address the minimality
     requirement above.

Briefly point out enough violations to explain a score < 2.


3. Abstraction Function

The abstraction function expresses which abstract value (here: set of
integer pairs) corresponds to each data rep value that satisfies the
rep invariant.

  2. The abstraction function FORMALLY expresses

  1. As 2, but one constructor or method misses a precondition check,
     or does not include an appropriate message in the thrown exception.

  0. Two or more methods lack a complete contract.

Briefly point out enough violations to explain a score < 2.


4. Implementation

Indicate to what extent the implementation is correct, ignoring
robustness; i.e., assuming that calls are only done when the
precondition holds.  This concerns all constructors, queries, and
commands mentioned in the contracts of IntRelation.java, including
isRepOk().

  2. Perfect; that is, constructor(s), isRepOk, extent, isValidPair,
     areRelated, add, and remove are obviously correct.

     N.B. Note that areRelated, add, and remove must explicitly deal
     with the case that  a  does not appear as key in the map:
     ! relation.contains(a).  (relation.get(a) == null is acceptable here,
     but in general a bit dangerous, because  a  might appear as key
     mapped to null.)

     N.B. Note that remove also has to deal with the case where
     the last  b  to which  a  is related is removed; in that case,
     the resulting empty set must be removed explicitly from the map
     to preserve the rep invariant.

  1. One constructor/method is not clearly correct (that includes
     "clearly not correct" :-).

  0. Multiple methods are not clearly correct.

Briefly point out enough violations to explain a score < 2.


5. Robustness

Indicate to what extent the implementation is robust.

  2. All constructors and methods have robust implementations
     that throw exceptions according to the contract, and each
     thrown exception has a message explaining where it occurred
     and why.

  1. As 2, but one constructor or method misses a precondition check,
     or does not include an appropriate message in the thrown exception.

  0. Two or more methods lack a complete contract.

Briefly point out enough violations to explain a score < 2.


-----8<----- cut line -----8<-----

1. Data Representation

Score: 

Motivation: 

2. Representation Invariant

Score: 

Motivation: 

3. Abstraction Function

Score: 

Motivation: 

4. Implementation

Score: 

Motivation: 

5. Robustness

Score:

Motivation: 

----- -----  --
Total score: 
----- -----  --

(End of Peer Review Form)