New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Nava2 opened this Issue Aug 26, 2015 · 9 comments

Comments

Projects
None yet
2 participants
@Nava2
Member

Nava2 commented Aug 26, 2015

Originally reported on Google Code with ID 610


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;
    }

Reported by @umple on 2014-07-24 14:12:12

@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

Reported by @umple on 2014-07-24 15:01:13

  • Labels added: ucosp
@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

Reported by @umple on 2014-09-12 12:25:52

  • Owner changed: emailmarkgalloway
@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

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.


Reported by emailmarkgalloway on 2014-09-14 04:28:45

@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

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 508, 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.


Reported by @umple on 2014-09-14 15:44:41

@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

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.


Reported by @umple on 2014-09-17 21:41:38

@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

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."


Reported by emailmarkgalloway on 2014-10-11 01:34:42

@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

for the above comment, the revision is r4601


Reported by emailmarkgalloway on 2014-10-11 02:15:09

@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

Reported by emailmarkgalloway on 2014-12-03 10:49:48

  • Owner removed
  • Status changed: MostlyDone
  • Blocked on: #545
@TimLethbridge

This comment has been minimized.

Member

TimLethbridge commented Sep 18, 2015

So what remains of this issue is to call the following upon completion of construction of the association class

canSetFlight = false;
canSetPassenger = false;

rather than just when computing hashCode;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment