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.
}
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.
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
}
}
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 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:
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 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.