An Adaptive Object Model with Dynamic Role Binding Tamai, T. (U. Tokyo), Ubayashi, N. (Kyushu Inst. Tech.), Ichiyama, R. (U. Tokyo)

Objects & Environments Objects reside in an environment or in multiple environments at a time. Objects reside in an environment or in multiple environments at a time. Objects change their behavior according to environments Objects change their behavior according to environments  e.g. day/night, weekdays/weekend Objects evolve to adapt to environment changes. Objects evolve to adapt to environment changes.

Example (1): Adaptation (Honda et al. ‘92) Objects adapt to multiple environments. Objects adapt to multiple environments.  “Hanako (object) is a wife in her family and a researcher at office. She preserves her identity even if she retires from office.”

Example (2): Multiple Roles (M. Fowler) Personnel roles in a company Personnel roles in a company  roles: engineers, salesmen, directors, and accountants  cases: l a person plays more than one roles l a person changes roles

Example (3): Role Patterns (E. Kendall) bureaucracy & dealing patterns bureaucracy & dealing patterns  roles: director, manager, subordinate, clerk, client  patterns: l dealing: client deals with clerk l bureaucracy: manager & subordinate are subclasses of clerk; manager supervises subordinate and reports to director

A New Role Model: Epsilon Design goals: Design goals:  support adaptive evolution  enable separation of concerns  advance reuse

Features of Epsilon Contexts encapsulate collaboration fields enclosing a set of roles. Contexts encapsulate collaboration fields enclosing a set of roles. Objects freely enter a context assuming roles and leave a context discarding roles. Objects freely enter a context assuming roles and leave a context discarding roles. Objects can belong to multiple contexts at a time. Objects can belong to multiple contexts at a time. Contexts (with roles) are independent reuse components to be deployed separately from objects. Contexts (with roles) are independent reuse components to be deployed separately from objects.

Programming Language EpsilonJ A language based on Epsilon model A language based on Epsilon model Constructs for defining a context enclosing roles to describe and encapsulate collaboration Constructs for defining a context enclosing roles to describe and encapsulate collaboration Dynamic binding and unbinding mechanism of an object and a role Dynamic binding and unbinding mechanism of an object and a role

Declaration of Context and Roles context Company { static role Employer { /* static means static role Employer { /* static means singleton instance */ singleton instance */ int salary=100; int salary=100; void pay() { void pay() { Employee.getPaid(salary);}} Employee.getPaid(salary);}} role Employee { role Employee { int save; int save; void getPaid(int salary) { void getPaid(int salary) { save+=salary;}}} save+=salary;}}}

Context and roles are like class and inner classes but roles are more concrete and couplings among them are stronger. (Context is composition rather than aggregation.) Context and roles are like class and inner classes but roles are more concrete and couplings among them are stronger. (Context is composition rather than aggregation.) Roles can see only each other and methods/fields of its context. Roles can see only each other and methods/fields of its context.

Binding Objects with Role class Person { string name;} string name;} Person tanaka=new Person(); Person sasaki=new Person(); Company todai=new Company(); todai.Employer.bind(sasaki);todai.Employee.newBind(tanaka);

Objects Acquire New Functions through Binding sasaki.(todai.Employer).pay();tanaka.(todai.Employee).getPaid(); Objects can access to functions of contexts (collaboration fields) only through binding to roles. Objects can access to functions of contexts (collaboration fields) only through binding to roles.

Role may have Multiple Instances Person suzuki=new Person(); todai.Employee.newBind(suzuki); Binding is between an object and a role instance. Binding is between an object and a role instance. “newBind” is a two step process: (new todai.Employee()).bind(suzuki); “newBind” is a two step process: (new todai.Employee()).bind(suzuki); Role here shows a feature of class. Role here shows a feature of class. Both ways of handling those roles as a collection and by instance are provided. Both ways of handling those roles as a collection and by instance are provided.

Method Import/Export by Binding Binding an object to a role affects states and behavior of the object and the role (interaction between the object and the role). Binding an object to a role affects states and behavior of the object and the role (interaction between the object and the role). Interface for binding can be defined and used in binding. Interface for binding can be defined and used in binding.

Role Interface interface PersonI {void deposit(int);} context Company {... role Employee requires PersonI { role Employee requires PersonI { void getPaid(int salary) { void getPaid(int salary) { deposit(salary);}}} deposit(salary);}}}

Method Binding as Importing Interface class Person { string name; int money; string name; int money; void deposit(int s) {money+=s;}} void deposit(int s) {money+=s;}} Person tanaka = new Person(); todai.Employee.newBind(tanaka); /* Hereafter, when deposit of todai.Employee role instance that “tanaka” is bound to is invoked, the object method deposit is called instead. */

Method Import with Renaming class Person { string name; int money; string name; int money; void save(int s) {money+=s;}} void save(int s) {money+=s;}} Person tanaka = new Person(); todai.Employee.newBind(tanaka) replacing deposit(int) with save(int);

Method Overriding and Call of Super interface PersonI {void deposit(int);} context Company {... role Employee requires PersonI { role Employee requires PersonI { void deposit(int salary) { void deposit(int salary) { super.deposit(salary);}}} super.deposit(salary);}}}

Method Binding as Exporting Interface class Person { string name; int money; string name; int money; void save(int s) {money+=s;}} void save(int s) {money+=s;}} todai.Employee.newBind(tanaka) replacing deposit(int) with save(int); /* Hereafter, when save of “tanaka” is invoked, role method deposit is called instead. */

Context role import export (overriding) import & export (overriding and call of super)

Object Method Replacing Multiple Role Methods An object method may replace multiple role methods. An object method may replace multiple role methods.  Case 1: replaced methods are all imported (not overridden)  Case 2: replaced methods are all exported (overridden)  Case 3: some imported, others exported

Case 1: simple Case 1: simple Case 2: when the object method is called, all the overriding methods are invoked in an undefined order. Case 2: when the object method is called, all the overriding methods are invoked in an undefined order. Case 3: imported method is always the current overridden method, except “super” Case 3: imported method is always the current overridden method, except “super” Object Method Replacing Multiple Role Methods(2)

Comparison to AspectJ Advice Precedence No complex precedence rule. No complex precedence rule. Principle: binding/unbinding is dynamic. Principle: binding/unbinding is dynamic.  The current status of binding is always respected.

When a component takes an action, related components behave accordingly. When a component takes an action, related components behave accordingly. E.g. integrated environment of editor/compiler/debugger E.g. integrated environment of editor/compiler/debugger Example: Integrated Systems

A simple integrated system (Sullivan et al., ‘02) A simple integrated system (Sullivan et al., ‘02) A Simplified Model Bit { //binary state //binary state set(); set(); clear();} clear();} Keep the pair of Bits in the same state One way relation

Scalability and Evolvability Is it easy to add a new node? Is it easy to add a new node? Is it easy to add a new type of nodes? Is it easy to add a new type of nodes? Is it easy to add a new relation? Is it easy to add a new relation? Is it easy to add a new type of relations? Is it easy to add a new type of relations?

Conventional approaches do not work nicely Simple OO mixes Bit & Relations description. Simple OO mixes Bit & Relations description. Design patterns, Mediator and Observer, do not fit either. Design patterns, Mediator and Observer, do not fit either. AspectJ solution also has problems. AspectJ solution also has problems. New approaches have been proposed New approaches have been proposed  ABT (Sullivan & Notkin ‘92)  Association Aspect (Sakurai et al. ‘04)

Mediator Pattern Bit class must know each Mediator （ Equality, Trigger, etc. ） → Bit depends on Mediator Bit class must know each Mediator （ Equality, Trigger, etc. ） → Bit depends on Mediator Colleague Bit void set(); void clear(); Mediator Equality Equality e1,e2; … e1.notify(); e2.notify(); …

Observer Pattern Better for dealing with the case a Bit instance involved in multiple relations Better for dealing with the case a Bit instance involved in multiple relations Bit must inherit Subject and must use its method notify. Bit must inherit Subject and must use its method notify. Subject Bit void set(); void clear(); Observer Equality void update(); … notify(); …

Using AspectJ Doesn’t work nicely (Sullivan et al.) Doesn’t work nicely (Sullivan et al.)  Implementing Equality as an Aspect does not scale for new equality introduction.  Preventing unbounded recursion doesn’t work due to lack of Aspect instantiation. (Sakurai et al.)

Probable Solutions A table to keep all relations A table to keep all relations  local problems solved globally ABT (Sullivan & Notkin ‘92) ABT (Sullivan & Notkin ‘92)  Object(Bit) defines operations (set, clear) and also announces events (justset, justcleared).  Mediator listens to events and invoke corresponding operations.

Our Solution class Bit { boolean state=false; boolean state=false; void set() {state=true;} void set() {state=true;} void clear() {state=false;} void clear() {state=false;} boolean get() {return state;}} boolean get() {return state;}} interface ActorInterface { void fire();} void fire();}

context Equality { boolean busy=false; boolean busy=false; role Actor1 requires ActorInterface { role Actor1 requires ActorInterface { void fire() { void fire() { super.fire(); super.fire(); if(!busy) { if(!busy) { busy=true; busy=true; Actor2.fire(); Actor2.fire(); busy=false;}}} busy=false;}}} role Actor2 //likewise... role Actor2 //likewise...}

Equality Actor1 Actor2 fire()

Bit b1=new Bit(); Bit b2=new Bit(); Bit b3=new Bit(); Bit b4=new Bit(); Equality e12=new Equality(); Equality e23=new Equality(); Trigger t34=new Trigger(); e12.Actor1.bind(b1) replacing fire() with set(); e12.Actor2.bind(b2) replacing fire() with set(); e23.Actor1.bind(b2) replacing fire() with set();......

Results Bit and Equality are totally independent and reusable. Bit and Equality are totally independent and reusable. It scales to new relation instance introduction and new type relation introduction. It scales to new relation instance introduction and new type relation introduction.

Comparison with Caesar Observer pattern example (Mezini & Ostermann ‘03) Observer pattern example (Mezini & Ostermann ‘03) The goal of Caesar is to decouple aspect interface, aspect implementation and aspect binding. The goal of Caesar is to decouple aspect interface, aspect implementation and aspect binding.

Aspect Collaboration Interface in Caesar interface ObserverProtocol { interface Subject { interface Subject { provided void addObserver(Observer o); provided void addObserver(Observer o); provided void removeObserver(Observer o); provided void removeObserver(Observer o); provided void changed(); provided void changed(); expected String getState();} expected String getState();} interface Observer interface Observer {expected void notify(Subject s);}} {expected void notify(Subject s);}}

ACI Implementation in Caesar class ObserverProtocolImpl implements ObserverProtocol { implements ObserverProtocol { class Subject { class Subject { List observers = new LinkedList(): List observers = new LinkedList(): void addObserver(Observer o) { void addObserver(Observer o) { observers.add(o);} observers.add(o);} void removeObserver(Observer o) { void removeObserver(Observer o) { observers.remove(o);} observers.remove(o);} void changed() { void changed() { Iterator it = observers.iterator(); Iterator it = observers.iterator(); while (iter.hasNext()) while (iter.hasNext()) ((Observer)iter.next()).notify(this);}}} ((Observer)iter.next()).notify(this);}}}

EpsilonJ Solution context ObserverPattern { static role Subject static role Subject requires{void changed();} { requires{void changed();} { void changed() { void changed() { super.changed(); super.changed(); Observer.notify(this);}} Observer.notify(this);}} role Observer role Observer requires{void notify(Subject);} {} requires{void notify(Subject);} {}}

Description in EpsilonJ Much more concise Much more concise Crucial behavior of Observer Pattern is not expressed in Caesar ACI but clearly visible in EpsilonJ. Crucial behavior of Observer Pattern is not expressed in Caesar ACI but clearly visible in EpsilonJ. Binding mechanism in EpsilonJ is much simpler. Binding mechanism in EpsilonJ is much simpler.

Other Examples Mediator Pattern Mediator Pattern Observer Pattern Observer Pattern Visitor Pattern Visitor Pattern Kendall’s example Kendall’s example Rental shop Rental shop Dining philosophers Dining philosophers

Implementation Bunraku: Epsilon implementation in Ruby (by R. Ichiyama) Bunraku: Epsilon implementation in Ruby (by R. Ichiyama) Features of context and role declaration, binding (with replacing), and unbinding are all implemented. Features of context and role declaration, binding (with replacing), and unbinding are all implemented. ~ichiyama/rolemodel ~ichiyama/rolemodel

Implementation on Java Use the annotation feature of Java2 5.0 Use the annotation feature of Java2 5.0 Syntax is a little modified. Syntax is a little modified. Full implementation is still ongoing. Full implementation is still ongoing.

Related Work AOP & AspectJ: AOP & AspectJ:  describe aspects separately and weave them together. - Kiczales et al. ‘97. MDSOC & Hyper/J: MDSOC & Hyper/J:  separate multiple concerns to different dimensions and integrate them. - Ossher & Tarr ‘01 Composition Filters (Aksits et al.) Composition Filters (Aksits et al.) Demeter & Adaptive Methods (Lieberherr et al.) Demeter & Adaptive Methods (Lieberherr et al.)

Related Work(2) various role models various role models  D. Riehle  B. Kristensen et al.  L. Wieringa et al. contracts contracts  Helm, Holland, & Gangopadhyay ‘90 multiple inheritance multiple inheritance  mixin - Bracha & Cook ‘90, McJava(Kamina & Tamai ‘04)  delegation (Self etc.)

Future Work Full implementation Full implementation Larger examples Larger examples