Association class semantics need fixing: Should not be possible to have multiple linked instances among associated classes

[GoogleCodeExporter]

An association class works very similar to several 1--* associations, with the 
central class having all the * ends. However, there is one key semantic 
difference. It should only be possible to have one tuple among each combination 
of associated instances that are linked by the association class.

For example in the following code, Umple currently allows a person to make two 
bookings on the same flight, This should not be possible. Similarly one can't 
have the same member twice on a given team. Attempts to do this should fail 
with a run-time error.

class Flight {
  Integer number;

  public static void main(String[] argv) {
    Flight f1 = new Flight(100);
    Flight f2 = new Flight(200);
    Passenger p1 = new Passenger("Tom");
    Passenger p2 = new Passenger("Jan");

    // Book f1 for p1 - first booking in system
    Booking b1 = new Booking(f1,p1);

    // Book f1 for p2 - should be fine
    Booking b2 = new Booking (f1,p2);

    // Book again f1 for p2 - should not be possible
    Booking b3 = new Booking(f1, p2);

    System.out.println("Booking 1 "+b1);
    System.out.println("Booking 2 "+b2);
    System.out.println("Booking 3 "+b3);

  }
}
class Passenger {
  name;
}
associationClass Booking {
  * Flight;
  * Passenger;
  lazy seat;
}

Original issue reported on code.google.com by TimothyCLethbridge on 24 Jul 2014 at 2:12

• Blocked on: #647

[GoogleCodeExporter]

Original comment by TimothyCLethbridge on 24 Jul 2014 at 3:01

• Added labels: ucosp

[GoogleCodeExporter]

Original comment by TimothyCLethbridge on 12 Sep 2014 at 12:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It looks like this is occurring due to a misunderstanding of the 
List.contains().

For example:
Object One = new Object("One")
List.add(One)

Object Two = new Object("One")
if(List.contains(Two)) {
  return false  //Will never return false, as they are different references with the same attributes.
}

This is why our List does not throw an exception when adding multiples.

Original comment by EmailMarkGalloway@gmail.com on 14 Sep 2014 at 4:28

[GoogleCodeExporter]

It is important that for ordinary associations the current semantics is   
maintained.      

It will be OK in a regular pair of associations such as

class Flight {  Integer number; }
class Passenger { name; }
class Booking {
  * -- 1 Flight;
  * -- 1 Passenger;
  lazy seat;
}

To create two Bookings that are to the same flight and passenger.

However, Booking is an associationClass, as in issue 610, then there 
should be a run-time error. This means generating slightly different code
in that case.

Note also that the whole mechanism of failure on construction at run time needs 
to be studied to see how it works in other cases where run time construction 
does not work. 

It should also be impossible to change the passenger or flight of a Booking.

Original comment by TimothyCLethbridge on 14 Sep 2014 at 3:44

[GoogleCodeExporter]

Upon discussion the likely solution is to 'automatically' make the associations 
to be associated into elements of the key. If there is already a key, issue a 
warning if it doesn't have these associations in it.

Original comment by TimothyCLethbridge on 17 Sep 2014 at 9:41

[GoogleCodeExporter]

Everything regarding this task, including the the internal key and issued 
warning are complete, except for the added criteria: "It should also be 
impossible to change the passenger or flight of a Booking."

Original comment by EmailMarkGalloway@gmail.com on 11 Oct 2014 at 1:34

[GoogleCodeExporter]

for the above comment, the revision is r4601

Original comment by EmailMarkGalloway@gmail.com on 11 Oct 2014 at 2:15

[GoogleCodeExporter]

Original comment by EmailMarkGalloway@gmail.com on 3 Dec 2014 at 10:49

• Changed state: MostlyDone
• Now blocked on: #647