Collaboration based Role-Oriented Programming

1
Collaboration based Role-Oriented Programming

• Kasper B. Graversen

2
The OOP advocacy

• The terminology of the problem domain/real world
  is found as entities in the solution domain.
• But this is a simplistic view, since what an
  account is to a bank customer is entirely
  different from what the same account is to the
  bank system.
• User balance, withdraw, deposit
• Bank system logging, interest calculations,
  transactions
• How should class Account then look like?

3
Todays menu

• Roles
• dynamic specialization of object
• Collaborations
• focus on processes

4
Context and objects

• Phenomena are typically represented as objects.
  But what possibilities does OOP offer?
• Aggregation
• - Not of the same type
• - No late binding of self
• - Methods are not inherited
• Dynamic
• Multiplicity

Account
Role A
Role B
5
Context and objects

• Phenomena are typically represented as objects.
  But what possibilities does OOP offer?
• Aggregation
• - Not of the same type
• - No late binding of self
• - Methods are not inherited
• Dynamic
• Multiplicity

Account
Role A
Role B
6
Context and objects

• Inheritance
• Of the same type
• Late binding of self
• Methods are inherited
• - Dynamic
• - (Multiplicity)

Account
Role A
Role B
7
Roles and visibility

• Several roles instances can be attached to the
  same intrinsic object. Each role represents the
  object in a given context.
• Role extensions are only visible to those who
  references the intrinsic object through the role
  instance.
• If a role instance changes the state of an
  intrinsic object, then the value is changed for
  all attached roles.

RA
8
Roles and programming

• The notion of classes focuses on the capabilities
  of objects.
• The notion of roles focuses on the position and
  responsibility of an object within the overall
  structure of objects.
• We get clear separation of concerns.

9
Roles for roles a context in a context

• A role being a role for a role.
• Enables extensions of an already extended object.

10
The difference between class and role inheritance
A
A
C
B
B
C
Run-time A or AB or AC or ABC Context for entity
A
Compile-time A or AB or AC Distinct entities of
a family A

• Roles are dynamic and non-exclusive

11
The difference between class and role inheritance
A
A
role subclass
role for role
B
C
B
C
Run-time A or AB or AC or ABC Defines contexts
B, C for context A
Compile-time A or AB or AC Distinct role
entities of a family A

• Roles are dynamic and non-exclusive

12
Roles adaptive behavior
University Economy System

• Roles are only used where dynamics occurs

• Roles for roles are applied where further
  specialization is needed.

Teacher weekhours

• Role constraint support

• A new system easily adapts on top of the existing.

Course Administration System
13
Constituent methods

• Are invoked regardless of reference (either
  through role or intrinsic).
• Invoked around the original method (it can
  completely take over the method call if needed).
• Can be used as
• e.g. input/output filters.
• Observer
• ...

14
Constituents

• Needed in order to express flexible extensions on
  the same entry point or to overcome reference
  hell

foo m()
15
Constituents

• Needed in order to express flexible extensions on
  the same entry point or to overcome reference
  hell

logging
foo m()
16
Constituents

• Needed in order to express flexible extensions on
  the same entry point or to overcome reference
  hell

logging
caching
foo m()
17
Constituents

• Needed in order to express flexible extensions on
  the same entry point or to overcome reference
  hell

?
logging
caching
foo m()
18
Constituents

• Needed in order to express flexible extensions on
  the same entry point or to overcome pointer
  hell

logging
foo m()
caching
m()
m()
constituent method binding
19
Collaborations
20
Whats wrong with this picture?

• Roles are sort of dangling.
• Roles are divided in two groups, but this is
  difficult to see and is not reflectedin the
  object-structure.

Teacher weekhours
21
Whats wrong with this picture?

• Roles are sort of dangling.
• Roles are divided in two groups, but this is
  difficult to see and is not reflectedin the
  object-structure.

Teacher weekhours
22
Collaborations

• Collaborations represents processes

• Functionality regarding the process is
  encapsulated
• and placed in well-defined place (does not
  belong to either party)
• state is shared between the entities in the
  collaboration

collaboration hospitalization state
Patient Nurse Doctor public
functionality() private functionality()
23
Collaboration
collaboration hospitalization state
Patient Nurse Doctor
functionality()
class Hospitalization state class
Patient class Nurse class Doctor
functionality()
Hospitalization
Patient
Nurse
Doctor
24
Collaboration
Person
Hospitalization
Hospitalization
Patient
Patient
Person
Nurse
Nurse
Doctor
Doctor
Person
25
Multiple concurrent collaborations
Person
Person
Hospitalization
Hospitalization
Patient
Patient
Person
Nurse
Nurse
Doctor
Doctor
Person
Person

• A person can play several roles in several
  collaborations

26
Collaboration scope rules

• Which i is found when accessed from A?

E
F
B i
i
A
C

• Having three search paths may show to be
• to complex in practice
• Letters denote lookup order

D i
27
Collaboration scope rules

• Since the objects inheritance has precedence,
  accidentally intro introducing the field i on (or
  method m) an intrinsic object, breaks
  collaborations
• Rememberobjects can be busy

H
K
P
28
Collaboration scoping rules

• The same unfortunate effect also occurs when
  introducing fields and methods on an intrinsic,
  since a method in the role will overwrite it
• This may call for an explicit override keyword as
  seen in C and Beta?
• Such a keyword will limit the objects on which
  the role can be applied, that may give rise to
  unnatural restrictions (for a dynamically typed
  language)

29
Abstraction mechanisms

• Since collaborations are just classes we can
• Aggregate collaborations
• Public behavior serves as the collaborations
  outer interface (what can be done on the
  collaboration)
• Specialize collaboration behavior
• Private/public behavior can be specialized, where
  private behavior is usable only to the
  collaboration or its entities.
• Specialize collaboration roles
• Since inner classes/roles are virtual they too
  can be specialized
• Nest collaboration inside collaborations

30
Virtual classes and multiple views

• Virtual classes may be problematic, in that they
  live longer than a method invocation

class Person Inner i void makeInner()
i new self.Inner() void
foo() i.foo() class Inner
int foo()return 1
Role R for Person class Inner
int foo()return 2
P p new P() P p new P()
R r new
R(p) p.makeInner()
r.makeInner() p.foo()
p.foo() gt 1 gt 2
31
Roles and collaborations

• A role can be applied a collaboration
• Changes the public interface of the coll.
• A role can contain a role
• Overwrites a role of the coll.
  
• A role can contain a class
• Overwrites a class of the coll.
• A role can contain a coll.
• Overwrites a coll. of the coll.

32
Roles and collaborations
on mismatching types

• A role can contain a role
• Converting a class to a role
• The role must know for which class and
  instantiate this as its intrinsic object
• A role can contain a class
• Converting a role to a class but does it make
  sense??
• The class must somehow have the same type as the
  role
• Can only perform consultation semantics rather
  than delegation

33
Roles and collaborations

• Constituent methods can be used for the same
  things
• Changes the role/class instantly we are not
  forced to call through the role
• Has addititive behaviour (several around methods
  can be defined for the same method)
• Can more elegantly change deeply nested
  classes/roles (e.g. a role C in a role B in a
  coll. A)
• An advice and a pointcut
• Or in the role R put a role A inside it have a
  role B inside this have a role C

34
The End
35
Open questions
36
Collaborations and real usage

• There are some practical issues (or is it just me
  who is pedantic?)
• Collaborations needs be created
• May make applications more memory hungry (this
  Im not worried about)
• Code is more tedious to write, since one cannot
  just allocate an object, but has to allocate a
  collaboration, a role and the object
• Object Teams and Caesar has made a
  within-construct to ease this somewhat (hiding
  the fact that role and coll. is allocated). But
  only works if intrinsic type are distinct!

37
Collaborations and real usage

• If the collaboration should know about which
  instances it contains, there needs be factory
  methods for each inner class/role and
  functionality for moving instances out of the
  collaboration
• These could be auto-generated by the compiler
  e.g. by introducing subtypes of Intrinsic and
  Role so this behavior is not forced upon the
  programmer.
• Should instantiation outside these factory
  methods then be forbidden?