User Manual    [Previous]   [Next]   

Association Class Definition

An association class defines an object-oriented pattern to manage * -- * (many to many) associations when data needs to be stored about each link of that association.

An association class is a class and can have the items found in an ordinary class (attributes, state machines, etc.).

However it always has two or more 1..many associations to other classes. Each of these is written as:

• A multiplicity (usually *, but 1..* and similar cases are allowed)
• (optional) A role name, i.e. another name for association class in the context of this association.
• The name of the participating class
• (optional) Participating class role name.

The first role name is generally omitted. It is only required if both participating class names are the same (i.e. a reflexive association class). There is an example of this below.

The first example below shows classic use of association classes. A Ticket can be sold to Person in order to attend a Seminar. A Seminar can have many Persons, and a Person can attend many Seminars, so one might imagine simply creating a * -- * association between these classes. However, we want to record the ticket number and price for each Person attending each Seminar. We encode these attributes in the Ticket association class.

For most purposes, an association class behaves in the same manner as though it was an ordinary class with two * -- 1 associations to the participating classes (Person and Seminar in this first example). This is shown in the second example below. However, we want to restrict the possibility of having more than one Ticket sold to the same Person for the same Seminar. Association classes add this constraint.

The third example below shows that it is possible to have more than two classes participate in an association class.

The fourth and fifth examples show the use of the role name for the association class itself. The use of such role names is mandatory when the association class on a reflexive many-many association, i.e. the associated classes are the same. In this example there are Members (e.g. people in a club) and some are assigned to be mentors of others. We want to record the date of each assignment, and we do that using an association class. But since both associated classes are the same (Member), we need to use role names on both ends to ensure all links can be navigated unambiguously. At the Assignment end we have menteeAssignments and mentorAssignments (note the plural) and at the Member end we have roles mentor and mentee.

If we do not use the role names in the 5th example, then error 19 will occur because it will not be possible to refer unambiguously to either side of the association.

Example 1

// A person can attend many seminars,
// and a seminar can be attended by many people
// The relationship between Person and Seminar is
// thus many-to-many.
//
// There is, however, data to record about each
// ticket. This can be  recorded as an
// association class
//
// Note the following doesn't currently render
// in UmpleOnline using Correct UML
// association class notation.
// There are plans to fix this.
associationClass Ticket
{
  Integer ticketNumber;
  Double price = 0.0;
  
  * Person attendee;
  * Seminar;
}

class Person
{
  name;
}

class Seminar
{
  Date when;
  address;
}
      

Load the above code into UmpleOnline

Example 2

// The following shows how we might model sales of
// Ticket for Seminars to Persons without using an
// association class. Note, however, that in this
// model, it would be possible to sell more than
// one ticket to a Person for the same Seminar.
// Using an association class would hence be
// better than this.
class Ticket
{
  Integer ticketNumber;
  Double price = 0.0;
  
  * -- 1 Person attendee;
  * -- 1 Seminar;
}

class Person
{
  name;
}

class Seminar
{
  Date when;
  address;
}
      

Load the above code into UmpleOnline

Example 3

// The following shows a 'quaternary' association,
// where the association class represents data in
// an association that links four classes.
class SportsPlayer {
  name;
}

class Season {
  year;
}

// e.g. goalie, forward etc.
class PlayingPosition {
  description;
}

class Team {
  name;
}

// This gathers the number of points a player
// gained on a particular team in a particular
// season while playing in a particular position
// To get the total points in any one category,
// you would have to add the points several
// instances
associationClass PlayerInPosition {
  Integer points;
  * SportsPlayer player;
  * Season;
  * Team;
  * PlayingPosition position;
}
      

Load the above code into UmpleOnline

Example 4

// The following example is a simple class that
// shows an association class using both a
// single role name for one associated class (a1)
// and two role names to make links to the
// other associated class.
class A{
    f;
}


associationClass B{
    * A a1;
    * b2 C c1;
}


class C {
    d;
}
      

Load the above code into UmpleOnline

Example 5

// This shows a reflexive association class, where
// the associated classes are the same (Member).
// In this case we must use role names at both
// ends to ensure navigation to the correct sets
// (mentors, mentees)
class Member {
  name;
}

associationClass Assignment {
  Date dateEstablished;
  * menteeAssignments Member mentor;
  * mentorAssignments Member mentee;
}
      

Load the above code into UmpleOnline