PPPJ 2006

1. Interaction among Objects via Roles Sessions and Affordances in Java M. Baldoni1, G. Boella1, L. van der Torre2 1 Dipartimento di Informatica Università degli Studi di Torino 2 University of Luxembourg PPPJ 2006

2. Properties are not always objective • A printer offers many modalities to access it with different privileges: guest, user, and super-user • Example: a method print with different meanings • Different methods for different privileges • Different classes can have the same privileges • Keep track of the state/history of the interaction between objects Printer print(job) hp8100 User print(job) print(job) Super-user Guest chris Person

3. Parameters and overloading solution void print(Job job, Person p) { if (p instanceof Guest) { ... } } • Implement parametricor overloaded methods looking at the class of the caller • How to distinguish the same person in different calls? • How to model different classes with the same privileges? • How to keep track of the state of the interaction? E.g.: counting printed pages Printer print(job, chris) hp8100 User print(job, chris) print(job, chris) Super-user Guest chris Person

4. Specialization solution (1) • A possibility is to implement many printers as specializations of a common (abstract) class • How to make the printer change class before each call? • How to keep track of the state of the interaction? E.g.: counting printed pages Printer print(job) User print(job) Super-user print(job) Guest Person

5. Specialization solution (2) • ... or a person can implement one or more interfaces for accessing the printer (or even extend multiple classes...) • How to implement the print method outside the Printer class? • Different print methods? • How to keep track of the state of the interaction? E.g.: counting printed pages Printer print(job) User print(job) Super-user print(job) Guest Person

6. Others solutions • Dynamic reclassification (e.g. Fickle) • Objects can change class dynamically but it does not take into account dependency of object properties from the interaction • Aspect programming(e.g. AspectJ) • Contexts/environments are considered but less clear how to manage sessions of an interaction and the set of properties may change completely • Possible integration: environments of interaction as a crosscutting concern? Printer hp8100 properties offered Session-based interaction may depend on properties of the caller chris Person

7. Affordances • Properties of objects emerge at the moment of the interaction and depend from involved actors • The properties of an object depend on the properties of the agent conceptualizing the object • Affordances from cognitive science [Gibson, 79] • Objects have affordances Printer print(job) hp8100 User Printer print(job) Super-user Printer print(job) Guest Printer chris Person

8. Roles as affordances • Considering every object as an institution • Considering roles as different ways of interacting with an object: roles as affordances • The methods offered (the powers of a role) depend on the requirements imposed on the caller • Eventually different objects can access with different privileges institution Printer print(job) User Printer role print(job) role Super-user Printer print(job) Guest Printer role Person player

9. Specifying a role/affordance Interface AccountedPerson { Login getLogin(); } role User playedby AccountedPerson{ int print(Job job); int getPrintedPages(); } role SuperUser playedby AccountedPerson { int print(Job job); int getTotalPrintedPages(); } class Person implements AccountedPerson { Login login; Login getLogin() { return login; } [...] } • Role as “double-sided” interface • Requirements: the methods required to a class playing the role • Powers: the methods offered to objects playing the role requirements powers powers their instances will meet the requirements!

10. Implementing a role/affordance class Printer { private int totalPrintedPages = 0; private void print(Job job, Login login) { performs printing totalPrintedPages += job.getNumberPages(); } definerole User { int counterPages = 0; public int print(Job job) { if (counter > MAX_PAGES) throw ... counterPages += job.getNumberPages(); Printer.this.print(job, that.getLogin()); return job.getNumberPages(); } define SuperUser { public int print(Job job) { Print.this.print(job, that.getLogin()); return job.getNumberPages(); } public int getTotalPrintedPages() { retun totalPrintedPages; } } } • Role implementation • Java inner classes that implement the powers specified by the role definition • keyword “that” • A role implementation has access to the state of the institution (like inner classes w.r.t. outer classes) • that is used to invoke methods (requirements) of the player

11. Linking a role/affordance Printer hp8100 = new Printer(); Person chris = new Person(); Person sergio = new Person(); hp8100.new User(chris) hp8100.new SuperUser(sergio); hp8100.new SuperUser(chris); • Roles: created similarly to instances of inner classes • Implicit parameter of type “requirements” (the player of the role) • Each role instance has a reference to the instance of its institution, like an instance of a Java inner class has a reference to its outer class (directly provided by Java compiler) institution Printer role hp8100 Printer.this SuperUser Printer Printer.this that that Person role User Printer player chris

12. Playing a role/affordance (receiver <-(role/affordance) sender).method(...) (hp8100 <-(User) chris).print(job1); (hp8100 <-(SuperUser) sergio).print(job2); (hp8100 <-(SuperUser) chris).print(job4); institution Printer role • Methods can be invoked from the players through an affordance • Sending a message: specifying both the sender and the receiver, moreover it is necessary to specify the affordance the sender refers to hp8100 Printer.this SuperUser Printer Printer.this that that Person role User Printer player chris

13. Roles as sessions • Role instances can access the private state of the institution • A role instance is uniquely associated with a institution and a player, so they can keep track of the state of the interaction • Roles represent the session of the interaction between players and institution objects institution Printer print(job) User Printer role print(job) role Super-user Printer print(job) Guest Printer role Persons can play more than one role in the same institution and they can play same role in more than one institution Person player

14. Session-aware interaction (hp8100 <-(User) chris).print(job1); (hp8100 <-(SuperUser) sergio).print(job2); (hp8100 <-(SuperUser) chris).print(job4); (hp8100 <-(User) chris).print(job5); • Roles are objects and they have a state • They maintain a state for the interaction between the player and the institution • Sessions similarly to JSP and Servlet session totalPrintedPages: 0 totalPrintedPages: 10 totalPrintedPages: 25 totalPrintedPages: 40 totalPrintedPages: 60 institution Printer print(job) hp8100 SuperUser Printer print(job, login) role role print(job) Person User Printer counterPages: 0 counterPages: 10 counterPages: 25 player chris

15. Beyond Access Control • (a) and (b): an object interacts with another by means of the roles(s) offered by it • (c): two abjects interact by means of the roles of an institution (coordination) • (d): role as colletive state of many objects • (e): two objects interact with each other, each playing a role offered by the other: protocols

16. Conclusions • Object properties are subjective rather than objective • Modelling and programming interaction among objects • Objects are modelled as an institution that offers affordances • State of the interaction among objects in sessions • Patterns for realizing the role concept: • Role object pattern (Baumer et al.): context-specific view as role objects dynamically attached but they do not consider requirements and that powers of a role are offered by an institution • Strategy design pattern: dynamic change of method implementations but hard to implement and they do not consider properties of the caller and state of interaction • Protocols: interactions as relations with roles