Epsilon and Epsilon/J Tetsuo Tamai The University of Tokyo 12 January, 2004

Objects Change to Cope with Environment Change Environments change Environments change  periodically (e.g. day/night)  as objects move  multiple environments coexist and objects choose among them Objects evolve Objects evolve

Motivation(1): Adaptation Objects adapt to multiple environments. Objects adapt to multiple environments.  “Hanako(object) is a wife(role) in her family and a researcher(role) at office. She preserves her identity even if she retires from office.”- Honda et al. ‘92.  agents adaptive to field change (Flage) - Kumeno et al. ‘98.

Motivation(2): Evolution Objects evolve with environment change. Objects evolve with environment change.  organic programming of Gaea - Nakashima et al. ‘98.  dynamic change of DB schemas - Gottlob et al. ‘96.

Motivation(3): Collaboration Objects engage in various collaborations in different situations. Objects engage in various collaborations in different situations.  UML ： use case, collaboration diagram  role model based methodology - OOram by Reenskaug et al. ‘96  role model as a design pattern - M. Fowler ‘98  collaboration-based design - VanHilst & Notkin ‘96, Smaragdakis & Batory ‘02

Example by M. Fowler Personnel roles in a company Personnel roles in a company  roles: engineers, salesmen, directors, and accountants  cases: la person plays more than one roles la person changes roles

Example by E. Kendall bureaucracy patterns bureaucracy patterns  roles: director, manager, subordinate, clerk, client  environments: ldealing: client deals with clerk lbureaucracy: manager & subordinate: subclasses of clerk; manager supervises subordinate and reports to director

Motivation(4): Mobility mobile agents: mobile agents:  Agents move to a new environment and acquire roles defined there. [Ubayashi & Tamai,Reflection ’01]

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

Model Features Contexts encapsulate collaboration fields enclosing a set of roles. Contexts encapsulate collaboration fields enclosing a set of roles. Objects freely enter a context/ assume roles and leave a context/ discard roles. Objects freely enter a context/ assume roles and leave a context/ discard roles. Objects can belong to multiple contexts at a time. Objects can belong to multiple contexts at a time.

Epsilon Model - Ubayashi & Tamai ‘98 object Context: field of collaboration role unbinding: leaving context binding: adaptation to environment Through binding, an object acquires: ・ role attributes ・ role methods ・ access to other roles of the context and context services An object engages in col- laboration with other objects through entering the context

Example: Contract-Net role:manager role:contractor （１） （３） （２ ） context:contract-net binding object multiple binding

Programming Language EpsilonJ A language based on the Epsilon model A language based on the 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/attributes of its context. Roles can see only each other and methods/attributes of its context.

Binding Objects with Roles 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.

Multiple Objects can Bind to a Role Person suzuki=new Person(); todai.Employee.newBind(suzuki); “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 objects as a collection and by instance are provided. Both ways of handling those objects as a collection and by instance are provided.

Binding with Name Replacement Binding to a role usually should affect states and behavior of the object (interaction of object and role). Binding to a role usually should affect states and behavior of the object (interaction of object and 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 save(int s) {money+=s;}} void save(int s) {money+=s;}} todai.Employee.newBind(tanaka) replacing deposit(int) with save(int);

Method Replacing and Overriding 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)

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

Goal: separate components from their relations (Sullivan et al., ‘02) Goal: separate components from their relations (Sullivan et al., ‘02) A simple integrated system A simple integrated system Bit: binary state(on/off) Equality: relation to make two Bits at the same state Trigger: when source is on, target gets on. No synchro- nization otherwise It is hard to implement them separately on OO. A Simplified Model

Simple Approach Embed relations to other Bits in Bit class definition Embed relations to other Bits in Bit class definition Bit Set() Clear() Bit[] equalities... for e in equalities e.Set() end... Implementation of relations scatters in Bit class.

Introduction of Design Patterns Separate Bit and binary relations Separate Bit and binary relations a Bit may belong to multiple relations a Bit may belong to multiple relations

Mediator Pattern Bit class must know Mediator （ Equality, Trigger, etc. ） → Bit depends on Mediator Bit class must know Mediator （ Equality, Trigger, etc. ） → Bit depends on Mediator Colleague Bit Bit(Mediator m); void set(); void clear(); Mediator Equality

Observer Pattern Essentially the same as Mediator Pattern Essentially the same as Mediator 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 Subject Bit boolean get(); void set(); void clear(); Observer Equality void update(); … subject.get() …

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

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.

Other Examples Mediator Pattern Mediator 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 Ichiyama) Bunraku: Epsilon implementation in Ruby (by 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

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 views views  B. Nuseibeh et al. ‘94

Related Work(3) composition and decomposition composition and decomposition  composition of hidden sort components - Iida ‘99  compositional hierarchy of labeled transition systems - Cheung & Kramer ‘96 multiple inheritance multiple inheritance  mixin - Bracha & Cook ‘90  delegation (Self etc.)