An Adaptive Object Model with Dynamic Role Binding

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

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

3. Example (1): Adaptation (Honda et al. ‘92) • 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.”

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

5. Example (3): Role Patterns (E. Kendall) • bureaucracy & dealing patterns • roles: director, manager, subordinate, clerk, client • patterns: • dealing: clientdeals withclerk • bureaucracy: manager&subordinate aresubclasses ofclerk;managersupervisessubordinateandreportstodirector

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

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

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

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

10. 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.

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

12. 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.

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

14. 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). • Interface for binding can be defined and used in binding.

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

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

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

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

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

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

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

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

23. Scalability and Evolvability • 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 relation? • Is it easy to add a new type of relations?

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

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

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

27. Equality Actor1 Actor2 fire() fire()

28. 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(); ......

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

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

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

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

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

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

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

36. Implementation • Bunraku: Epsilon implementation in Ruby (by R. Ichiyama) • Features of context and role declaration, binding (with replacing), and unbinding are all implemented. • http://www.graco.c.u-tokyo.ac.jp/~ichiyama/rolemodel

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

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

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

40. Future Work • Full implementation • Larger examples