Actor-Role Pattern

Most people don't confuse actors from the roles they play. Keanu Reeves is an actor. Ted, Neo, and Buddha are some of the roles he has played. In modeling it's a good idea to decouple actors from the roles they play. In this way an actor can quickly shift from one role to another. The actor object is also a good place to store personal information like name and address.

Here's the basic pattern:

Examples of roles include:

Employee, Customer, Supplier, Nurse, Doctor, Patient, Teacher, Student, Commander

The plays association can be bi-directional or not. In the unidirectional case it's possible to navigate from a role to the actor who currently plays it:

class Actor {
   private String name;
   private String address;
   private String phone;
   // etc.
}

class Role {
   private String description;
   private Actor actor;
   // etc.
}

The Agent-Behavior Pattern

In the bi-directional case the role specifies a behavior the actor must execute. This situation commonly appears in agent-based systems such as Jade:

A composite behavior is a finite state machine in which each state represents a micro-behavior and a transition represents the flow of execution from one micro-behavior to the next.

Examples of behaviors include:

Auctioneer, Bidder, Seller, Requestor, Provider, Publisher, Broker

The Actor-Role and Agent-Behavior may be seen as formalizations of some basic ideas from Sociology.

Implementation

An agent is an active object that perpetually cycles through a schedule of behaviors:

class Agent extends Thread {
   private List<Behavior> schedule
      = new ArrayList<Behavior>();
   public void add(Behavior b) {
      b.setAgent(this);
      schedule.add(b);
   }
   public void run() {
      int next = 0;
      while(0 < schedule.size()) {
         Behavior b = schedule.get(next);
         if (!b.execute()) {
            schedule.remove(b);
            if (schedule.size() == 0) break;
         }
         next = (next + 1) % schedule.size();
      }
   }
}

A cyclic behavior is a simple behavior that executes some task a fixed number of times:

class Behavior {
   private Agent agent;
   private int cycle = 0;
   private int maxCycle;
   public Behavior(Agent a, int max) {
      agent = a;
      maxCycles = max;
   }
   public void setAgent(Agent a) {
      agent = a;
   }
   public boolean execute() {
      if (maxCycle <= cycle++) return false; // done
      System.out.println("cycle = " + cycle); // the task
      return true; // call again
   }
}

Role types as objects

In the following diagram role types are represented by classes:

This hierarchy can become large. Reorganization can be a nightmare. We can reduce the hierarchy to just two classes using the Types as Objects pattern:

Accountability

Accountability is the relationship between commissioners and the accountable:

For example, in most schools we have the terminological rules:

T1: Students are accountable to teachers.
T2: Teachers are accountable to principals.

At Springfield Elementary we have the additional assertions:

A1: Mrs. Crabapple is accountable to Principal Skinner.
A2: Lisa is accountable to Mrs. Crabapple.
A3: Bart is accountable to Mrs. Crabapple.

Here's the object diagram that models the assertion:

The terminological rules can also be represented in our model by adding a second accountability association between role types:

Note the two links added to represent the terminological rules:

Association Classes: Links as Objects

We can add type checking to our model by representing the accountability links as objects. A link object is an instance of an association class:

Here's the new object diagram. Note that rules and assertions are represented as objects:

Here's how the ruls and assertions above might be constructed in Java:

Rule T1 = new Rule(principal, teacher);
Rule T2 = new Rule(teacher, student);
Assertion A1 = T1.makeAssertion(thePrincpal, aTeacher);
Assertion A2 = T2.makeAssertion(aTeacher, student1);
Assertion A3 = T2.makeAssertion(aTeacher, student2);

We can add type checking code to makeAssertion:

class Rule {
   private RoleType commissioner;
   private RoleType accountable;
   public Assertion makeAssertion(Role comm, Role, acct)
   throws Exception {
      if (!comm.getType().equals(commissioner)) {
         throw new Exception("Type error");
      } else if (!acct.getType.equals(accountable)) {
         throw new Exception("Type error");
      }
      Assertion result = new Assertion(comm, acct);
      result.setType(this);
      return result;
   }
}

Affiliation

Affiliation is a relationship between a parent organization and a subsidiary organization:

For example:

A1: The Raiders are a subsidiary of the Western Division
A2: The Western Division is a subsidiary of the AFC
A3: The AFC is a subsudary of thge NFL

It turns out the Affiliation model is very similar to the Accountability model.