User Manual    [Previous]   [Next]   

Player Role

When modeling, it is common to encounter situations where one wants to make multiple subclasses, but can not or should not for various reasons. One reason not to create a subclass is because instances may need to change class as their roles in the system change. Another reason not to create a subclass is because an instance may need to play two or more roles smultaneously.

The solution is to create a Role class and to link it by a many-to-one association to the main class (which we will call the Player class).

To use this pattern, add a use statement to incorporate the built-in PlayerRole.ump file. Then use isA statements to declare which class is a Player, and which is an Role (of which Player). Follow what is show in the second block of code below.

This is one of several patterns in Umple Umple that are built into the language as of 1.32 via a use statement. See the code below.

The Player Role pattern code that is imported by specifying use lib:PlayerRole.ump

// Generic pattern for players and roles
// In any Umple program say 'use lib:PlayerRole.ump;' to include this pattern.

// A player is an object that can have many roles
// A person can be an employee and a student
trait Player {}

// A captures some functionality that a player may have
// either temporarily or in conjunction with other roles
trait Role <Player> {
 * -- 1 Player;
}
      

Load the above code into UmpleOnline

Example of the Player-Role pattern to specify a system for a child sports team

/* Example of using builtin Umple
 * Player Role pattern
*/

use lib:PlayerRole.ump;

class Person {
 isA Player;
 name;
}

class TeamRole {
  isA Role<Player=Person>;
}

class Athlete {
  isA TeamRole;
}

class Coach {
  isA TeamRole;
}

class ParentOfAthlete
{
  isA TeamRole;
  * -- * Athlete;
}


class SportsTeam {
  nickname;
  * -- * TeamRole;
}

      

Load the above code into UmpleOnline