Chameleon

1. 23rd april 2002 Chameleon Johannes Beyer Kasper B. Graversen IT University of Copenhagen at AOSD 2002, April 2002 www.it-c.dk/~kbilsted

2. Program • Simplified overview • The Chameleon framework • Case: An administrative system • Current research topics • Roles with multiple intrinsics • Constraints • Group concept

3. Person Calendar; name; address; Student Courses[]; role intrinsic object Intrinsic objects & roles • Intrinsic objects models the intrinsic properties. • Roles models the extrinsic properties.

4. Chameleon • Conceptual programming enables for implementation of dynamic behaviour based on our conceptual understanding of the environment. • Roles contains new state and functionality. • Roles are not objects, but roles. • Roles can not exist without being attached to an (intrinsic) object. • Our role definition is based on the works on conceptual programming by Kasper Østerbye and Bent Bruun Kristensen, 1995/96.

5. Person Calendar; name; address; Student Courses[]; Person Calendar; name; address; Person Calendar; name; address; Person Calendar; name; address; Teacher weekhours; Student Courses[]; Dynamic role binding • Roles are dynamically attachable and detachable to objects at runtime. • Conceptual programming support dynamic changes in a system at the language level.

6. Roles types • Dynamic role • Attachable and detachable at runtime. • Class role • Automatically gets instantiated and attached to instantiating intrinsic objects. • Manually detachable at runtime. • Comparable to compile time weaved aspects. • No difference – except for the automation.

7. a c Person Calendar; name; address; b Teacher weekhours; Student Courses[]; Multiple Roles & visibility • Several roles instances can be attached to the same intrinsic object. • 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 (as there is only one intrinsic).

8. Person info() getName() Student getName() Redefining Methods • Redefining a method of the intrinsic object has consequences for the execution of other intrinsic methods through the role. • Similar to inheritance in late binding OOP lang-uages such as Java.

9. From the roles point of view • The role instance can do the following on its intrinsic: • Gain full access to all methods and fields. • Re-define methods in the object • access modifier • return type • Re-define fields in the object • access modifier • type • Add new methods and fields

10. WageEarner salary; getSalary() BonusWage closured getSalary() Person Calendar; name; address; Teacher weekhours; 2nd extension Original system 1st extension Roles acting as intrinsic • A role being a role for a role. • Enables extensions of an already extended system. • Requires the original role (e.g. Teacher) to be active when the new role (e.g. WageEarner) is active.

11. BonusWage (closured after) WageEarner double salary; double getSalary() { return salary; } salary += calcBonus(); return salary; 3 2 1 wage = earner.getSalary(); Closured methods • Binds strongly to intrinsic methods. • invoked regardless of reference (either through role or intrinsic). • Invoked before, after or aroundthe original method. • Can be used as • e.g. input/output filters. • Observer • ...

12. Closured methods and evolution • Dangerous in software evolution, as it changes the object behaviour for everyone using it. • This includes all future uses and extensions of the system!

13. Person Professional Swimmer Athlete activate(’Athlete’) Student Courses[]; Active-Student selectCourse() deactivate() Inactive-Student Inactive-Student Simple role constraints • Activate/deactivate mechanism enables: • Automatic execution of code ensuring role constraints when a roles are activated/deactivated • Role cleanup at deactivation, etc.

14. Room Course int points Calendar Student-AsIncome amount; BonusWage closured getSalary() WageEarner salary; getSalary() Inactive Person Calendar; Name; Address; Active selectCourse() Teacher weekhours; Student Courses[]; Design example UniversityEconomy Administration system Intrinsic Role Multiple roles Standard OOP Role for a role Activate/deactivate Economy system Extending existing system CourseAdministration Closured methods

15. Program • Simplified overview • The Chameleon framework • Case: An administrative system • Current research topics • Roles with multiple intrinsics • Constraints • Group concept

16. Driver Car Driver Car Taxi Roles with multiple intrinsics(objects and roles) • Assembling objects/roles yields new possibilities(Object-level cross-cutting / Class-level cross-cutting) • Examples: • Game of cards (the whole is greater than the sum of the parts) • Taxi (creating a new whole by combining different units) • (this applies for roles acting as intrinsic as well) Combined Cards: new possibilities – e.g. give the cards a shuffle, use the cards in a game. Individual Cards: no mutual relations

17. Person Person Person Any Role Any Role Student Child Child Class-level constraints • Optional class-level constraints (constraints on all instances of a given class) • Intrinsic constraint • no roles can be played. • only specified roles can be played. • Role constraints • singular role – i.e. maximum one instance can be attached to the intrinsic object.

18. Class-level constraints • Inter-intrinsic/role constraints • exactly one Boss per Employee • many Employees per Boss... • Persistence level constraints • Terminate roles when deactivated • Let deactivated roles live in a store to be re-activated at a later stage (typically for roles with state) What about separate departments in a company?  The specification is too general!

19. Instance-level constraints • Optional instance-level constraints (Constraints on specific intrinsic objects and role instances) • Now we can set up the constraints for different departments. • but we can not logically group intrinsic objects and roles into separate departments.  The specification is too narrow! • We need something in-between the two…

20. Object C Object A Role K Object B Object B Role N Role M Role L Groups • Ordering of instances in logical groups defined by subscription • Intrinsic objects and roles can subscribe to groups either at compile time or runtime. • Groups span across inheritance trees (role & intrinsics). Group Q Group R Group P Role K Object A Object B Object F

21. Motivations for groups We assume groups have the following properties: • Encapsulate closured methods so they only affects objects within the group. • Logical grouping of roles and intrinsics implementing a cross-cutting concern. • Handles the “object-level constraints” (inter-intrinsic/role, persistence levels). • Collective operations such as “removeRole” & “addRole” • Establish a “friends” mechanism such as in C++. • Open question: Are “groups” and “roles with multiple intrinsics” basically the same construct (comparable to java interfaces and abstract classes), or two completely different things.

22. Chameleon and other systems • AspectJ • Static aspects (closured methods, class roles with multiple intrinsics) • Hyper/J • Hyperslices (groups, roles with multiple intrinsics) • JAC • Dynamic binding of aspects (object roles) • Composition Filters • Filters (closured methods) • New features (Chameleon) • Combination of strengths from many existing systems. • Provides a conceptual model rather than a technical solution.