Home > Agile stuff > Roles in Java using ObjectTeams

Roles in Java using ObjectTeams

I’ve been testing ObjectTeams for a while now and think its a really cool way for using roles in the Java language. A role is a set of attributes and behavior a object can assume temporarily in a certain context. It’s like an actor behaving according to the film script. The actor plays the role as described in the script as long as he is shooting the film. After that he returns to be himself again.

Roles can help you in achieving a strict separation of concerns. This is because roles let you encapsulate context specific behavior in a role removing it from the class itself. In a collaboration you can have multiple roles working together to achieve some functionality. An example of a collaboration could be a car race. The Race collaboration exposes the role of a RaceCar for cars that want to participate in the race. A car object that assumes the RaceCar role will get additional state and behavior defined in the role RaceCar. These could be things like laps to go and car number. The Race collaboration itself can also have state like e.g. the participating race cars and the laps to go untill the race ends.

ObjectTeams is an extension to the Java language. It introduces some new language constructs that make it possible to program using roles. A collaboration is represented by a team and declared using the team keyword. Within the team you can define roles and their interaction. You can express that objects of a certain class will play a certain role using the playedBy keyword. As a result objects can be extend at run-tme with role specific behavior and state.

See below an implemtation of the SubjectObserver pattern in ObjectTeams.


public abstract team class SubjectObserver {
    …
    protected abstract class Subject {
        private LinkedList<Observer> observers = …
        public void attachObserver (Observer o) {…}
        ...
        public void notify() {
            for (Observer observer : observers)
                observer.update(this);
        }
}

    protected abstract class Observer {
        abstract void update(Subject s);
}
}

You see that we have a abstract team SubjectObserver that defines the roles of Subject and Observer. Lets assume that we have a TV and a Screen that needs to be updated when the TV changes state. We have to let TV play the role of Subject and Screen play the role of Observer.

public team class ObservingGraphical extends SubjectObserver {
    protected class Subject playedBy TV {
           notify <- after setPrice;
      }

    protected class ScreenObserver extends Observer playedBy Screen {
        update -> redraw;
}
…
}

We see that team ObservingGraphical extends SubjectObserver. Because it uses the same role name for Subject as its base, this role is implicitly extended using the same name. You can also see the use of playedBy keyword.

To couple the objects and roles the so called callin and callout statements are used. Using callin statement ‘notify <- after setPrice; ‘ you state that after method ‘setPrice’ is called on TV, method ‘notify’ of Subject should be called. Using callout statement ‘update -> redraw;’ a call of the ‘update’ method on Observer is mapped to method ‘redraw’ on Screen.

How to use the collaboration and its roles is shown below

final ObservingGraphical observingGrph = new ObservingGraphical();
TV tv = new TV();
Screen screen = new Screen();
within(observingGrph) {
observingGrph.attachSubjectObserver(tv, screen);
tv.setPrice(1000);
}

The interesting part is the within statement. It defines that the role specific behavior is active. During the statement the objects TV and Screen are extended with role specific behavior. After the within statement they are back to normal again.

References

[1] E. Gamma et al (1994). Design Patterns: Elements of Reusable Object-Oriented Software.
[2] Edsger W.Dijkstra (1974).  HYPERLINK “http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html&#8221; http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html.
[3] Robert C. Martin (2002). Agile Software Development: Principles, Patterns, and Practices.
[4] ObjectTeams.  HYPERLINK “http://www.objectteams.org&#8221; http://www.objectteams.org/
[5] ObjectTeams language definition.  HYPERLINK “http://www.objectteams.org/def/1.2/index.html&#8221; http://www.objectteams.org/def/1.2/index.html.
[6] Bertrand Meyer (1997). Object-Oriented Software Construction, Second Edition.
[7] Matteo Baldoni et el. The Interplay between Relationships, Roles and Objects.
[8] Trygve Reenskaug, Role Modeling.  HYPERLINK “http://folk.uio.no/trygver/themes/roles/roles-index.html&#8221; http://folk.uio.no/trygver/themes/roles/roles-index.html.

Advertisements
Categories: Agile stuff Tags: ,
  1. No comments yet.
  1. February 13, 2009 at 2:38 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: