Chameleon
Download
1 / 22

Chameleon - PowerPoint PPT Presentation


  • 390 Views
  • Updated On :

23rd april 2002 Chameleon Johannes Beyer Kasper B. Graversen IT University of Copenhagen at AOSD 2002, April 2002 www.it-c.dk/~kbilsted Program Simplified overview The Chameleon framework Case: An administrative system Current research topics Roles with multiple intrinsics

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Chameleon' - bernad


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Chameleon l.jpg

23rd april 2002

Chameleon

Johannes Beyer

Kasper B. Graversen

IT University of Copenhagen

at AOSD 2002, April 2002

www.it-c.dk/~kbilsted


Program l.jpg
Program

  • Simplified overview

    • The Chameleon framework

    • Case: An administrative system

  • Current research topics

    • Roles with multiple intrinsics

    • Constraints

    • Group concept


Intrinsic objects roles l.jpg

Person

Calendar;

name;

address;

Student

Courses[];

role

intrinsic object

Intrinsic objects & roles

  • Intrinsic objects models the intrinsic properties.

  • Roles models the extrinsic properties.


Chameleon4 l.jpg
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.


Dynamic role binding l.jpg

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.


Roles types l.jpg
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.


Multiple roles visibility l.jpg

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


Redefining methods l.jpg

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.


From the roles point of view l.jpg
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


Roles acting as intrinsic l.jpg

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.


Closured methods l.jpg

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

      • ...


Closured methods and evolution l.jpg
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!


Simple role constraints l.jpg

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.


Design example l.jpg

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


Program15 l.jpg
Program

  • Simplified overview

    • The Chameleon framework

    • Case: An administrative system

  • Current research topics

    • Roles with multiple intrinsics

    • Constraints

    • Group concept


Roles with multiple intrinsics objects and roles l.jpg

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


Class level constraints l.jpg

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.


Class level constraints18 l.jpg
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!


Instance level constraints l.jpg
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…


Groups l.jpg

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


Motivations for groups l.jpg
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.


Chameleon and other systems l.jpg
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.