Model-View-Controller and Object Teams: A Perfect Match ... - CiteSeerX

Model-View-Controller and Object Teams: A Perfect Match of Paradigms Matthias Veit

Stephan Herrmann

Fraunhofer FIRST, Berlin

Technical University Berlin

[email protected]

[email protected]

ABSTRACT

From the early days of obje t-oriented programming, the model-view- ontroller paradigm has been pursued for a lear design whi h separates dierent responsibilities within an intera tive appli ation. In ontrast to its untyped implementation in Smalltalk, any implementation in a stati ally typed language involves ertain trade-os whi h either blur the lear stru ture, destroy the intended independen e, or introdu e undue administrative overhead. Ea h alternative

reates a dierent ari ature of the originally risp ar hite ture. The programming model Obje t Teams provides a new modeling unit alled Team plus a number of binding me hanisms by whi h a Team and its ontained roles an be bound to existing parts of an appli ation. It turns out that these me hanisms t ni ely for implementing a lear modelview- ontroller design not only for single elements but also for omplex stru tures of GUI elements plus their binding to omplex model stru tures. We furthermore propose to use the model-view- ontroller paradigm as a ben hmark for AOSD approa hes, sin e it ombines a set of typi al problems on erning the separation and integration of on erns.

Keywords

GUI design, a-posteriori integration, omposition, ollaborations, programming language, evaluation

1.

INTRODUCTION

Long before the dawn of aspe t-orientation, separation of

on erns for user interfa es has been addressed by resear h at very dierent levels. Most prominently, the model-view ontroller paradigm [8℄ (MVC for short) de nes an ar hite tural pattern, whi h ensures a good degree of de oupling if appli ations stri tly adhere to its onstraints. Other work de nes ar hite tures at an even larger s ale, like the Chiron [12℄ system, whi h also supports distribution of its omponents. Libraries | frequently addressed as toolkits | apply

ommon prin iples of obje t oriented design, notably a wide range of design patterns, for providing reusable elements of

user interfa es. Examples are Interviews, Motif and Swing. Usage of su h libraries employs a mixture of inheritan e and aggregation. GUI-builders are tools, whi h support the intera tive assembly of user interfa es. These tools usually generate sour e ode. Also trigger me hanisms as present in some databases are used for implementing part of the link between an appli ation and its user interfa e. Some of these approa hes also enhan e a given programming language for

onvenient development of user interfa es. All in all, separation of on erns for user interfa es an be said to be a well explored issue. We see two reasons for re- onsidering this topi : 1. Pra ti al development of user interfa es is still subje t to ompromise between several goals that haven't been re on iled yet. Ea h of the solutions mentioned above has spe i draw ba ks when they are put into pra ti e in the real world. 2. The on eptual understanding of the issues in separating on erns for user interfa es makes this a well suited ben hmark for approa hes to aspe t-oriented software development, whi h laim to improve modularity and separation of on erns. Taylor and Johnson [12℄ give a very good des ription of why many approa hes that are sound on epts on their own fail under real world onditions: \Current user interfa e te h-

nologies often impose a fairly rigid set of onstraints on how the appli ation must be stru tured. In a large appli ation, however, there are typi ally many ar hite tural desiderata, so it is undesirable for the user interfa e to enfor e a parti ular ar hite ture." If spe ialized te hnology fails be ause it

on i ts with other requirements, it should be worth onsideration how lose to an optimal solution for user interfa es we an get using general purpose te hniques only. On the other hand the MVC ar hite tural pattern an also be seen as an ar hetype in module de oupling and integration. Thus, we propose to regard the realization of an MVC ar hite ture as a ben hmark for approa hes for AOSD. This paper reports on our results in using a re ent AOSD approa h

alled Obje t Teams [6℄ for the development of user interfa es and investigates the gains in de oupling and reusability that are a hieved by this approa h. We laim that Obje t Teams not only te hni ally provide a basis whi h very well ts the task at hand, but also the metaphors behind Obje t Teams orrespond very smoothly to the MVC paradigm, su h that both \paradigms" support ea h other very well.

view messages user input

Controller

1

*

change messages

display output 1

*

model access and editing messages 1

1

Model

View

change messages

Figure 1: MVC { multipli ities and message ows Se t. 2 will re ap the MVC ar hite tural pattern and point out some weaknesses. Se t. 3 introdu es Obje t Teams in a nutshell. In Se t. 4 we present how MVC an be realized using Obje t Teams. For this presentation we use two examples: a simple stop wat h and a lass browser. Se t. 5 presents some details of Obje t Teams that make a dieren e in realizing MVC. Se t. 6 evaluates the presented solutions. We on lude with a dis ussion of related work (Se t. 7) and an outlook (Se t. 8).

2.

MODEL VIEW CONTROLLER

Almost all modern graphi al user interfa e (GUI ) widget libraries rely on the distin tion between model, view and

ontroller [8℄ (see Fig. 1). A model in this paradigm is a

lass whi h originates in a spe i domain. It is an abstra tion of a domain spe i entity and has no knowledge about the GUI. The representation of the model as GUI element is alled view. A view an be seen as a wrapper around the model, whi h is apable of displaying a subset of the data that is en apsulated in the model. Ea h view has an asso iated ontroller. A ontroller is responsible for all possible a tions that are de ned in the view on erning the asso iated model. A model an have multiple views, where the views among themselves an dier. This is not surprising be ause there are many possibilities to represent the same set of data. The en apsulation of GUI-spe i details inside a view and the management of the view inside a ontroller lead to a lean ode base of the domain spe i model. The model is built without any knowledge about views and

ontrollers. There is an impli it asso iation via an observer me hanism [4, observer pattern℄. The model must implement the fun tionality de ned in the role `Subje t' and introdu e noti ations in all pla es where the state of the model is hanged. The update message is sent to every atta hed view or ontroller. View and ontroller use an expli it asso iation to the model to query its state. A view an de ne a tions and an send events, if a spe i a tion has happened. The ontroller is able to listen to spe i events of the asso iated view and has to handle all those events, whi h have meaning to the asso iated model. A ontroller `translates' from spe i GUI events to appli ation logi .

2.1 A simple example

To demonstrate some design prin iples, a simple example shall be introdu ed: a stop wat h. The on ept of a stop wat h omprises the apability to start, stop and reset a

ounter. When running, the stop wat h ontinuously advan es this ounter. The value of the ounter an be queried at any time. A lass alled StopWat h is introdu ed, whi h

implements the des ribed behavior. The method start starts a thread. The thread invokes advan e at every se ond and sleeps for the rest of the time until stop is alled, whi h will stop the running thread. The method getValue returns the elapsed time as an obje t of type Duration. A view lass Wat hDisplay onsists of a label whi h displays the elapsed time and three buttons start, stop and lear. The ontroller implements methods to handle the events, that are sent by these buttons. To syn hronize the model and the view ve styles of ommuni ation are needed: 1. The display has to register itself as an observer of the stop wat h (View!Model). 2. The stop wat h must all notify every time the elapsed time has hanged (Model!View). The only mutator of StopWat h is advan e. 3. The display has to ask the stop wat h about the a tual elapsed time (View!Model). 4. If the user presses start, stop or lear the view must send proper events to the ontroller (View!Controller). 5. Events pro essed by the ontroller have domain semanti s. The ontroller `translates' those events to domain spe i a tions, whi h are delegated to the model (Controller!Model). Without loss of generality, intera tions Model!Controller and Controller!View are not onsidered in this paper.

2.2 Weak points of a MVC based design

The stri t separation of responsibilities on erning the same entity leads to a very tight stru ture of the distin t parts that belong together. Eviden e for this an be seen in Fig. 1 | ea h pair of omponents is linked by a bidire tional ommuni ation path. The model should not be aware of the GUI. To gain abstra t syn hronization of model and view an observer infrastru ture is needed, whi h in fa t is not a fun tionality of the domain lass. The design of this infrastru ture requires preplanning in the model. At a rst look this seems well tolerable. This in ludes, however, the de nition at whi h level of granularity hanges should be propagated, i.e., whi h events are available for observation. This may lead to designs of overly eager model lasses that broad ast a large number of events, of whi h only few are used by views. On the other hand, if some hanges are initially not onsidered for noti ations the addition of a new view might require the model

lass to be modi ed to this new requirement, whi h again demonstrates an undesirable dependen y of the model. View and ontroller are developed with an expli it binding to a spe i model. Thus, view and ontroller lasses are not reusable for dierent models. A ommon solution to

ir umvent that problem an be found in many widget libraries. To gain reusability of the view and ontroller, the de nition of the model is de lared abstra t: as an interfa e or pure abstra t lass. To apply su h views/ ontrollers to a domain lass, this lass has to be adapted to ful ll the spe i ed ontra t and type. This leaves two alternatives: either the model must be developed onforming to the abstra t model interfa e as de ned by the view library, or obje t adapters have to be implemented whi h provide the desired

interfa e and delegate all requests to the real model. Neither alternative is optimal for obvious reasons. The problems that arise with a MVC ar hite ture are addressed by spe ial te hniques of obje t-orientation. It is possible to ir umvent many problems, but there is a need to ta kle the real ause, not just the ee t. The a tual nature of the problems at hand might be ome

learer, if we forget about MVC for a moment and analyze the nave solution where ea h model element is also responsible for its presentation and user intera tion. Here the implementation of ea h view is s attered over the set of involved model lasses. Views are tangled with appli ation ode and if dierent views use the same model lass these views are also tangled with ea h other. From this it should be lear that views and ontrollers are aspe ts, too. Applying aspe t te hnology should also help to improve the modularity of GUIs. Hen e, we are seeking aspe t-oriented solutions that address the issues of MVC in a more radi al way than traditional obje t-oriented te hniques do.

3.

INTRODUCTION TO OBJECT TEAMS

Obje t Teams is a re ent programming model, whi h ombines two on epts for improving modularity: aspe ts and

ollaborations. The dire t prede essors of Obje t Teams are Aspe tual Components [9℄ and LAC [5℄. From this ba kground, Obje t Teams is a general AOSD approa h aiming at a broad range of modularity issues. Before demonstrating the appli ability of Obje t Teams for the MVC{ar hite ture, let us brie y show, how the on epts of ollaborations and aspe ts are re ned to teams, roles and dierent styles of binding.

c:Connector r:Role lowering

lifting b:Base

Figure 2: Role to base relation introdu es stru tured gluing te hniques for applying roles to domain lasses. For this purpose, a Team an be used as a

onne tor. A onne tor is a re nement of a Team and ontains de nitions like: the behavior of role lass R is applied to the domain lass D. Bindings are expli itly denoted in a su

in t, de larative style. At method level binding uses the me hanism of forwarding. Forwarding from an abstra t method of a role lass to a dedi ated method of a domain lass, alled base, is named

allout. The base lass implements an abstra t method of a role lass and an be seen as sub- lass of the role lass. The opposite dire tion, forwarding from a base to its role, is named allin. A allin de nition de lares an invo ation of a role method:  before the base method gets alled,  after the base method gets alled, or  instead of alling the base method (repla e).

The advi e of su h a forwarding is woven into the base lass at runtime. It is possible to onne t many role lasses to the same domain lass. Another way to all the base from the role exists during a

Aspe ts are fun tionalities, that annot leanly be en apsulated by means of obje t oriented te hniques. Dierent aspe ts with ollaborating fun tionality an be s attered over dierent lasses of a domain. The paradigm of Obje t Teams introdu es a module on ept alled Team, where

ollaborating aspe ts an be grouped to one larger entity. An aspe t inside a Team en apsulates a behavior, whi h is spe i for its surrounding Team. Su h a stereotypi al behavior is alled `role behavior'. Aspe ts inside a Team are therefore alled Roles. Roles are implemented as lasses. A Team an be seen as an outer lass, in whi h all ollaborating roles are realized as inner lasses.

repla e allin, where the repla ed base method is a

essible.

A role lass is marked abstra t if it has abstra t methods. A Team is marked abstra t, if it ontains one or more abstra t roles. Be ause a Team itself is a lass, inheritan e an be applied. Team spe ialization uses a parti ular inheritan e te hnique, alled impli it inheritan e : all roles de ned in the super-Team are automati ally available in the inherited Team. If a sub-Team de nes a role with the same name as a role within a super-Team, this is automati ally a sub- lass of the previously de ned role with the option of overriding inherited methods.

Obje t Teams introdu e a translation alled lifting, whi h maps from a base obje t to a orresponding role obje t. The translation ba k to the base is alled lowering (see Fig. 2). If a allin binding is hit, the base is lifted to its role. The

all is forwarded to the spe i ed role method. A role an

all its base via allout or in a repla ed method using base. In this ase the role is lowered to its base and the all is forwarded. The pro ess of lifting and lowering during method forwarding in ludes all parameters and results. It is ompletely automated: all ne essary translations are woven automati ally into the system. Su h a me hanism ensures a safe disjun tion of two worlds: the obje ts of a Team and the obje ts of the domain.

An approa h that de lares separation and en apsulation of s attered fun tionality in a stru tured way must also de lare how to bring together these separate pie es. Be ause roles of a Team are in omplete entities whi h are intended to ontribute one aspe t to a larger domain entity, Obje t Teams

Here the role a ts as a sub- lass of the base whi h overrides an existing method. A new keyword base is introdu ed, whi h an be used inside su h methods. This me hanism is known from overriding, where super.m() alls the overridden method in the super lass. An ee tive onne tor (Team) an be instantiated. The a tivation and dea tivation of bindings is based on the a tivation and dea tivation of the en losing onne tor instan e. If a onne tor is a tivated, all allin bindings are woven into the base lasses, dea tivation removes those advi es.

In Se t. 4.1 we will show these me hanisms at work using the stopwat h example of Se t. 2.1.

4.

` LA OBJECT TEAMS MVC A

The paradigm of Obje t Teams enables a type of binding between lasses, that is as powerful as the binding by inheritan e but gains mu h more modularity and exibility. This binding is as versatile as the binding by (hand- oded) forwarding, but it is supported by the runtime system, whi h takes are of safety. The paradigm of MVC relies on the binding by forwarding, whi h is extremely exible but taken in isolation it is too weak to solve all requirements. Using the te hniques of Obje t Teams we repla e this weak binding by role binding. The idea of per eiving the view as a role of the model enables an equally exible but more powerful stru ture. Those bindings lead to better independen e between model and view: View lasses do not operate on a spe i type of model, they de lare open spots that are bound by allout. Views remain abstra t, ustomization is done in the onne tor. Syn hronization between model and view is de ned by allin binding, any expli it observer stru ture be omes obsolete. Dierent views with dierent syn hronization poli ies are possible | a result of dierent

allin bindings, requiring no hange to the model. Another problem always omes along with forwarding: identity. From an abstra t point of view the model and its representation are the same entity, from a stru tural point of view they are not. Obje t Teams solve this duality: the model and the view seem to have the same identity, the view in the

ontext of its Team, the model in the domain. The relation is ensured by a onne tor and the te hniques of lifting and lowering. As a result, any attempt to ompare a role and a base obje t will ause either obje t to be translated to the

ontext of the other obje t, thus re-establishing identity. In the next se tions we present examples for better support of separation and gluing of fun tionality in the sense proposed by the paradigm of MVC.

4.1 Stop watch with Object Teams

The design of the stop wat h example is quite dierent from the lassi al solution when the te hnology of Obje t Teams is used. A new Team Wat h is reated, where one role Wat hDisplay is de ned. This role drives a simple label and three buttons. The ontra t for the orresponding model is de ned by abstra t methods: stringValue is used to obtain the string to display, start, stop and lear are alled, if the orresponding buttons are pressed. Those methods are ne essary for the role to a t properly, but the role an not implement them, be ause it should remain independent and reusable. Conversely, Wat hDisplay implements the method update, whi h displays the string returned from stringValue. The Team Wat h, however, ontains no all to this method, be ause the events that should trigger an update o

ur in the model not in the view. Thus, the method has to be bound to all methods in the model, where the displayed value will be hanged. Using this style of a-posteriori method binding, the model does not have to support an expli it observer infrastru ture. The role lass is de laratively

omplete in the sense that all open spots are expli itly de lared using abstra t methods. All de lared open spots must be implemented, either in a sub lass or in the orresponding base.

1 2 3

Team lass Wat hConne tor extends Wat h f

lass Wat hDisplay playedBy StopWat h f // model operations:

4

start

5

stop

6

lear

! ! !

start; stop; reset;

7

// model query:

8

String stringValue()

with f result

9

// observer trigger:

10

11
12 13

g

g

update

!

Duration getValue()

result.toString()

g

;

after advan e;

Figure 3: Binding view and model using a onne tor The Team Wat h is abstra t, be ause of the abstra t role Wat hDisplay. This role is apable of displaying a string as

a label, whi h an be ontrolled by three buttons. It does not dependent on any other lass. To use this team, four abstra t methods have to be de ned. Binding a view to a model is done by de ning a onne tor that re nes this Team and binds the relevant methods to a base lass. Fig. 3 shows the Team Wat hConne tor that re nes Team Wat h (line 1) and binds the role lass Wat hDisplay to the domain lass StopWat h (line 2). To make this team ee tive, all abstra t methods of the role lass Wat hDisplay have to be de ned, either by inpla e implementation or by forwarding to a base method. All abstra t methods are bound to the lass StopWat h. Callout bindings are de ned by !, allin bindings by plus modi er. The abstra t methods start and stop have equal names as their ounterparts in StopWat h; lear is mapped to reset (line 4,5,6). If one of the three buttons in the view is pressed, the bound method of the model is

alled on the asso iated model instan e. This instan e is obtained by the lowering translation, whi h is automati ally inserted by the ompiler. Similarly, the abstra t method stringValue is bound to getValue in the domain lass (line 8). Sin e getValue returns an obje t of type Duration but stringValue needs an obje t of type String, the result has to be adapted. Obje t Teams allow the adjustment of parameters and results as part of a method binding. Ea h parameter adjustment maps an expression of the alling level to a formal parameter of the re eiver method. result serves as a spe ial identi er for method results. In the example, the obje t of type Duration is onverted to a string via the standard toString method. Due to these bindings the onne tor Team is ee tive, but syn hronization of model and view is not yet handled. The view shall be updated every time the model has hanged. A hange to the observable state of StopWat h is only performed by the method advan e. The allin binding (line 11) ensures an invo ation of the method update every time advan e is alled. The Wat hConne tor is ee tive and instantiable. If it is a tivated, the observer hook is woven into advan e. Ea h instan e of StopWat h an be asso iated to one or more views.

Lifting omes into play when advan e is alled while a Wat hConne tor is a tive. The runtime system automati ally lifts the StopWat h instan e to a Wat hDisplay in order to invoke its update method. Lifting is performed relative to a given Team instan e. By this me hanism the advantages of stati and dynami integration te hniques are ombined: the role base binding has the exibility of delegation based te hniques but it does not exhibit the administrative overhead, whi h is usually the pri e of su h exibility. The key to automating the base-to-role translation is the on ept of Teams as ontexts for roles. Whenever a StopWat h instan e is about to enter the ontext of a Wat hConne tor Team, that team is responsible for looking up the orre t Wat hDisplay role. While several roles of this type may exists for the same base obje t, this lookup is disambiguated by the urrent Team. In Se t. 2.1 ve types of ommuni ation are des ribed. The

ommuni ation itself is not repla ed, but the style by whi h it is de ned has hanged: 1. The observer registration is realized by advi e weaving during Team a tivation (line 11). 2. Update noti ation is ensured by allin binding (line 11). 3. Value queries on the model rely on allout bindings of abstra t methods in the view (line 8). 4. Event invo ation uses the allba k me hanism of the used widget library ( lassi al). 5. Operation invo ation is done using allout bindings of open spots, de lared in the view (lines 4, 5, 6). The ommuni ation hannels between model and view are repla ed by allout and allin bindings. Two lasses are de ned separately, be ome onne ted externally and remain independent.

4.2 Complex Structures

Modern GUI widget libraries have a hieved a high degree of reusability. A set of low level widgets an be synthesized to widgets of arbitrary omplexity with the help of GUIbuilders and ode generators | no line of ode has to be implemented manually. The binding of these widgets to domain lasses usually have several drawba ks, either in maintenan e or in type safety. Obje t Teams support the de nition of the intera tion between model and view/ ontroller without introdu ing new stru tural types, whi h lead to implementation dependen y of the model (see 2.2). The binding takes pla e neither in the view nor in the model, but in a third entity: the onne tor. Expli it provided interfa es of view lasses and stru tured spe ialization via team inheritan e ensure easy maintenan e. Type safety is ensured by (stati ) type he king. The reation of a GUI with widgets that are aware of Obje t Teams should be more natural, elegant, safe and modular than known from lassi al widget libraries. As a proof of on ept we designed a Team that is able to display tree hierar hies. This Team is applied to a ode parser infrastru ture. The result is a simple lass browser, whi h allows graphi al browsing and navigation of sour e ode, known from typi al IDEs. This example is implemented in Ruby [13℄ using Ruby Obje t Teams [15℄ and uses the GTK

«abstract»

Tree Tree -gtktree +createNode(t:TreeNode) +updateNode(t:TreeNode) +moveNode(t:TreeNode) +removeNode(t:TreeNode) +findNode(g:GtkTreeNode) +addToRoot(t:TreeNode) +initializeTree(f:Frame) TreeRenderer

+

CellStyle

*

TreeNode -gtktreenode +getParent(): TreeNode +getSibling(): TreeNode +getChildren(): TreeNode[] +getData(): +getType(): Object +isLeaf(): bool +addChild(t:TreeNode) +removeChild(t:TreeNode) +update() +move()

Figure 4: An abstra t tree model v1.2 [16℄ widget library. Sin e the on ept an be transfered to any other language following the Obje t Teams model, the ode examples are written in Obje tTeams/Java [1, 7℄ to ensure a well-known syntax.

4.2.1 The View: Tree Widgets A graphi al tree stru ture de nes two responsibilities, that are en apsulated as roles: a tree as root of all bran hes and leaves and a tree node, whi h model the visible elements of a tree. Ea h graphi al representation of a tree node onsists of the displayed data and a set of graphi al attributes ( olor, i on, et etera) that is de ned by a spe i tree style. The abstra t de nition of those requirements an be seen in Fig. 4. Classes Tree and TreeNode a t as obje t adapters to their pendant de ned by GTK. The API of those lasses has several short omings that are leveraged here. A Tree is a widget, whi h an display a whole tree stru ture

onsisting of TreeNode-obje ts. Be ause this lass is de ned in the abstra t Team TreeView, only two methods are implemented, but ve are de lared abstra t: ea h spe ializing

on rete tree style has to implement these methods. By the abstra t methods both roles de ne their expe ted interfa e, i.e., fun tionality that must be provided at integration time. This interfa e is de ned in a way that is most appropriate for the TreeView Team. Considerations about those lasses that eventually provide this behavior are hardly needed, be ause we an rely on the mapping apabilities of role binding with allout de larations. The abstra t method findNode has an ex eptional position, it is needed only be ause of the obje t adapter: the tree has to make a relation between a GTK tree node and a Team tree node | findNode implements this mapping. Ea h tree uses a TreeRenderer, whi h ontrols the appearan e of a tree node. To support ustom representations, the tree renderer uses CellStyle-obje ts, whi h en apsulate a spe i representation and are registered under a ertain type. This type is mat hed by the type of a tree node and de nes its graphi al representation. The lass CellStyle must be spe ialized in every spe ializing tree style, to support the ustom appearan e. A TreeNode is a graphi al representation (view) of an entity as item inside a tree. The tree is de ned by the three methods parent, sibling and hildren. The position of a tree node inside a tree is spe i ed by the relation to the

Entry +name: String +type: String +line: int +getName() +getType() +getLine() +addEntry() +removeEntry() +...()

Session

XClassFileFactory

+addClass() +parse() +removeClass()

*

parent sibling children

XClassFile +getRoot()

*

*

«adapts»

Parser

TagReader

CPPClass JavaClass CTagsReader

Figure 5: A sour e ode parsing infrastru ture parent and the sibling. The displayed ontent of the item is fet hed via getData1 . The graphi al representation, e.g. ba kground olor, pixmap, font et etera, is spe i ed by a spe i obje t returned by getType. This type obje t is used by the tree renderer to spe ify a ell style. The method isLeaf indi ates, whether this tree node is a leaf. All those methods are abstra t and an not be de ned in the view, be ause this relates to appli ation logi . These methods are needed to orre tly paint a tree node. There are four additional methods to syn hronize the model and the view via allin: addChild and removeChild should be alled whenever the set of hildren has hanged, update should be

alled, whenever the displayed data has hanged and move should be alled, whenever the position of this tree node has

hanged. All roles are grouped into the abstra t Team TreeView. Two re nements of TreeView have been implemented: a normal tree without any graphi al additions (NTree) and a olumn tree, alled CTree | a table like widget, where ea h entry itself onsists of multiple olumns. In both Teams, role lass Tree implement all abstra t methods of its super

lass. The Team CTree re nes the CellStyle to support pixmaps for any state of ea h tree node and olored text. Both Teams NTree and CTree remain abstra t, be ause the

lass TreeNode is still abstra t. All abstra t methods shall be bound to domain lasses to work properly, no further re nement is needed.

4.2.2 The Model: A Code Parsing Infrastructure We have implemented a simple ode parsing infrastru ture, whi h is shown in Fig. 5. The details of most lasses are omitted. The fo us is set on the stru ture and binding to a graphi al view. The pro ess of parsing relies on sour e ode and abstra ts from spe i programming languages. The abstra t lass XClassFile represents a sour e le of a spe i programming language. Ea h spe i XClassFile obje t has a number of entries found in the le: pa kage, lass, method, attribute de nitions et etera are modeled as Entry obje ts. An Entry obje t en apsulates the name and type of the entry plus the line number, where the entry was found. Su h entries an build a tree, e.g.: pa kage

lass(es) method(s). The knowledge of the stru ture is implemented

;

1

«connector»

ClassBrowser

Figure 6: Ar hite ture of the lass browser

* root

«team»

CTree

;

The return type of getData is used inside lass Tree. A spe i sub Team has to bind the template parameter to its used type. As long as there is no support for generi ity in the programming language, this te hnique an be repla ed by an additional role de laration Data, whi h is re ned to the needed type for a spe i tree.

in sub- lasses of XClassFile. To support parsing of different programming languages, dierent parsers are needed. Every XClassFile asso iates a parser whi h implements the TagReader interfa e. To mat h a dedi ated XClassFile and parser against a spe i le type, the XClassFileFa tory is used. The stati method parse(file:File):XClassFile is the main entry point. A Session is a ontainer, to hold a set of XClassFile obje ts. The model is a regular pa kage without any Obje t Teams enhan ements.

4.2.3 Binding View and Model To a hieve a graphi al representation of a parsed stru ture, we have to apply a view to the domain pa kage. We have

hosen the olumn tree, where ea h item onsists of the name, the type and the line number. The overall ar hite ture is shown in Fig. 6. The entral Team ClassBrowser inherits from CTree and adapts the Parser pa kage by allout and allin bindings. A binding of the Team CTree requires a binding of two roles: the tree and the tree node. All

lasses that have been parsed are kept in a session. To display all lasses, we apply the Tree role to Session. The role TreeNode is applied to the Entry lass, be ause ea h entry of a sour e le should be displayed. This role requires binding of abstra t methods: the methods that de ne the tree stru ture are implemented with the same names as de lared in the abstra t role. As de nition of getType in TreeNode we use the equally named method of Entry. The en apsulated type is a simple string, so it is easy to reate ell styles and register them under a ertain type that an appear in a lass: e.g. "method" or " lass". This style is used by the tree renderer if an entry with that type is found. A node is supposed to display the name, type and line number of the orresponding entry. It would be possible to implement getData inside Entry to t this requirement. This would result in view fun tionality tangled within the model. Moreover, the only possibility to de lare dierent views with dierent ontent is the implementation of dierent methods bound to getData for ea h dierent view. To ustomize the view for this spe i requirement getData is implemented inside the onne tor. The TreeNode remains reusable, the Entry is not aware of any view fun tionality | the onne tor lls the gap for ustomization:

publi team lass ClassBrowser extends CTree f

lass TreeNode playedBy Entry f // de lare methods needed by getData

abstra t int getLine(); abstra t String getName();

// ustomize ontent by implementing getData

f

f

String[℄ getData() String[℄

return new

g

ontinued . . .

getName(), (String)getType(), Integer.toString(getLine()) ;

g

of this integration. Both are independently re-usable.

. . . lass TreeNode ontinued // allout bindings

! ! ! ! ! ! !

getParent

getParent;

getSibling

getSibling;

getChildren isLeaf

isLeaf;

getName getLine

getType

getChildren;

getName;

getLine; getType;

// syn hronize model and view: addChild

after addEntry; before removeEntry; after f setName, setLine, setType g;

removeChild update

g

// (no bindings to move )

lass Tree playedBy Session f

Inline with view. This design dire tly maps to the Do u-

void addToRoot(TreeNode tn)

after void addClass(XClassFile xf)

with f tn

xf.getRoot()

with f tn

xf.getRoot()

g

;

void removeNode(TreeNode tn)

g

g

4.2.4 The Controller A ontroller is responsible for mediating between view and model. It must translate view events, whi h originate from user input, to model operations. It an also in uen e the behavior of the view in a

ordan e to the state of the model. Su h a fun tional des ription an have several realizations, whi h gives rise to a dis ussion of available design hoi es. There is one hara teristi that all hoi es share: the ontroller needs to dire tly ommuni ate with the role that implements the view fun tionality. To enable this a

ess, the

ontroller is designed as a part of the Team.

before void removeClass(XClassFile xf)

g

;

// Team features omitted ...

To syn hronize model and view both roles have to de lare some allin bindings: Every time a lass is inserted into a session, all its entries are made visible inside the tree. Before a lass is removed from the session, all visible items are deleted. The same kind of logi is applied inside TreeNode: every time an entry is inserted beneath a parent entry, this entry is displayed as sub-entry. Deletion works a

ordingly. For all these bindings, lifting is essential, be ause the operation of adding an entry to a parent entry is mapped to adding a tree node to a parent tree node. Lifting is applied uniformly to the all target and all relevant arguments of a allin invo ation. The allin bindings in lass Tree need more adjustment, be ause the base methods addClass and removeClass have arguments of type XClassFile. This

lass is not mapped within the Team. A simple parameter mapping after the keyword with inserts the expression xf.getRoot() whi h yields the root Entry of that lass. Lifting nally translates the root entry to its orresponding tree node, whi h is passed as argument tn to the role method. Even if an entry is represented within dierent views, lifting will always yields the orre t role instan e with regard to the en losing Team. There are three mutator methods inside Entry. These methods have to be adapted to also all update of the view, sin e the displayed ontent has hanged. The hook method move is not bound to the model, be ause there is no orresponding fun tionality in the model. Another appli ation might use this allin method for its desired behavior. As the de nition of Team ClassBrowser shows, this Team is designed as a onne tor, whi h means, that little fun tionality is added but the main purpose of this Team is to bind lasses and methods from the pa kages that implement model and view. This is the only part of the program that knows about both worlds. Model and view remain ignorant

ment-View pattern, a spe ial form of the MVC paradigm. This is the easiest form, be ause the ontroller is integrated into the view. This is suÆ ient for most simple tasks. GUIevents are dire tly mapped to allout methods, as seen in the stop wat h example. If a dire t mapping requires additional translations, ustomization an be done in the onne tor.

Team features. This approa h is very similar to the rst one and an be seen as pendant to the ` lassi al' ontroller. All ontrolling fun tionalities are entralized in one pla e and an be re ned by standard obje t oriented te hniques. A Team has only a

ess to the view. Spe i methods in the domain lass have to be de lared in the view and must get bound to the model. Be ause an instan e of a Team is always required, no additional ontroller obje ts have to be maintained. Contained obje ts. It is possible to en apsulate a spe i state inside a separate ontroller, whi h refers to spe i view role(s). These ontrollers are not bound roles, but are still ontained in the Team. As with Team features, these

ontrollers operate only on view obje ts. Invo ations on the model are only possible via allout bindings of the view. Any translation of GUI-events is possible. Su h a ontroller is not a

essible outside the Team. Bound role obje ts. The most versatile approa h is the usage of ontrollers that share the base obje ts (model) with their orresponding view roles. Thus, view and ontroller are roles of the same model inside the same Team. Su h a

ontroller an de lare its own allout de nitions to invoke spe i model operations that are needed. Fig. 7 shows the ontroller fun tionality of our lass browser. It is implemented as Team features. The onstru tor of the Team is initialized with a Session-obje t. This session obje t is lifted expli itly to its role. Obje t Teams allows an expli it lifting via a spe ial type de laration: Session as Tree. This tree is pla ed in its own window. To gain full

ontrol over the view, additional methods are implemented: The method show a tivates the Team and shows the window, hide will hide the window and dea tivates the Team. A tivation and dea tivation orrelates with the visibility of the view. The initialization pro ess looks like this: Session session = new Session(); ClassBrowser browser = new ClassBrowser(session); browser.show();

publi team lass ClassBrowser extends CTree f

has no ee t for a base obje t that does not yet have a

orresponding role in the Team under onsideration.

// expli it lifting of Session to Tree

publi ClassBrowser(Session as Tree tree) f

g

// reate window, register for events, setup ...

void show()

f

publi team lass ClassBrowser f publi addEntry (Entry as TreeNode e) f /* empty body */

a tivate();

g

// onne tor is a tivated. show window...

void hide()

g

f

g

g

// jump to the spe i ed entry

void onTreeNodeSele ted(Sele tionEvent sev)

g

f

// role mappings omitted ...

Figure 7: Tree ontroller as Team features

4.2.5 Instance considerations The above ode has shown, how a browser and its model (session) are asso iated at runtime. The dynamism of this asso iation is a entral feature of the MVC ar hite ture. With Obje t Teams a base obje t may play a role in multiple Teams simultaneously. Roles within dierent Teams do not dire tly ommuni ate with ea h other. Of ourse, modi ations of a shared base obje t are propagated to all its roles in dierent views. As a result, an Obje t Teams implementation of MVC supports multiple views (of same or dierent types) sharing ommon base obje ts without further eort.

DETAILS OF OBJECT TEAMS

During the development of the lass browser example, the fairly young model of Obje t Teams has been subje t to a few enhan ements. Please note that none of these extensions

on erns the language proper, but all are realized by de ning additional methods by with the lient program an intera t with the runtime environment of Obje t Teams.

5.1 Team freezing

g

b.addEntry(e1);

If a XClassFile obje t is put into this session, all entries of that lass be ome visible inside the tree. The user intera tion with the lass browser is not very omplex. The user has the possibility to li k on an entry. An asso iated editor jumps to the position, where this entry was found. The handler for this event is implemented in the method onTreeNodeSele ted. The event passes the GTK tree node whi h was li ked. The asso iated role a ting as an obje t adapter is a

essible via the method findNode of the tree.

5.

/* . . . */

ClassBrowser b = . . .

// hide window and dea tivate onne tor...

dea tivate();

If a more expli it style is desired for asso iating obje ts to a Team the following idiom an be used:

An a tive Team usually reates a new role for ea h mappable base obje t when a allin binding is hit. This means, that a base lass as a set of obje ts is mapped in full to a set of orresponding role obje ts. In GUI implementation it is, however, desirable to expli itly map a subset of a base lass only. Initializing a window requires to a

ess all base obje ts relevant for its display. After initialization, a Team an be frozen, whi h means that no allin binding is allowed to

reate new role obje ts for this Team, i.e., a allin binding

b.addEntry(e2);

b.freeze();

Here the addEntry method has the only purpose of ausing its Entry argument to be lifted to a TreeNode, whi h ensures that e1 and e2 have roles within b.

5.2 Sibling role creation

If view and ontroller are de ned as distin t roles over shared base obje ts, widget setup requires to reate a ontroller role given a view role. For this purpose a ontroller role may have a onstru tor of this fashion:

publi MyController (MyView v) f shareBase(v);

g

// spe i initialization

The reason for en apsulating this initialization in shareBase is, that (for the sake of safety) the program is not allowed to dire tly a

ess the role-base link, whi h is ompletely managed and en apsulated by the runtime system.

5.3 Suspending Teams

The issue of update granularity has been tou hed already. It is a re urring topi of design trade-os, sin e two requirements seem to on i t with ea h other: (1) ea h small

hange at a base obje t should be propagated to the view. (2) view updates should be bundled if possible to redu e

omputational overhead and s reen i kering. In AOSD a similar problem has been reported as the \jumping aspe ts" problem [2℄. Obviously, observer granularity and join-point granularity refer to the same auses and ee ts. The Obje t Teams model provides a solution using temporary Team dea tivation. Re all that allin bindings (advi e weaving in AOP terminology) are oupled to Team a tivation and have no ee t if no Team is a tive. API fun tions suspend and resume of lass Team an now be used, to temporarily dea tivate a Team. This an be used to observe a ompound operation (say: addedNodeList()) and disable observation of its atoms (e.g.: addedNode()). The ee t is, that an atomi operation only triggers the allin method if not invoked via the ompound operation. While the ee t is similar to the Aspe tJ flow onstru t, we onsider a tivating and suspending more general, sin e it gives full ontrol to the programmer by a seamless representation of ontext within the imperative part of the language. Aspe tJ programmers might be more familiar with omplex

onditional point uts. In ontrast, we feel that the advi e of addedNodeList() is indeed a suitable pla e for solving the problem, be ause this is what a tually aused the undesirable aspe t re-entran e.

6.

EVALUATION

When using Obje t Teams for developing appli ations a

ording to the MVC paradigm, the goal of de oupling has been a hieved by the ombination of advi e weaving and role binding. Callin binding is used to insert triggers into base lasses whi h have not been designed for su h noti ations. We argue that this is preferable over in luding observer fun tionality in base lasses not only be ause base lasses should not know about any noti ation me hanism but also be ause the granularity of noti ations is unknown when designing base

lasses and even on i ting requirements may exist within the same appli ation. Lifting of all target and arguments automati ally manages all ne essary instan e relations. Role binding and allout method binding help to bridge the gap between a view that is implemented against spe i interfa e assumptions regarding its underlying model and the on rete model to be onne ted. This allows fully independent development of both omponents and a-posteriori integration thereof. This is based on the on ept of abstra t Teams as open modules whi h are ompleted not by inheritan e but by role-base relations and allout bindings. This binding te hnique an be regarded as on-demand remodularization of model lasses in order to adapt these to their orresponding view lasses. Using both dire tions of method binding in onjun tion with the possibility to hand- ode ertain translations by methods within a onne tor we have at hand a well suited set of tools for programming the integration between a model and a view. Su h a-posteriori integration gains in importan e if UI-builders ome into fo us. The ode generated by su h tools should better not be edited manually. Nor should the model be hanged to integrate the generated UI. A distin t onne tor module is a perfe t pla e to implement this integration. Obje t Teams provide a good balan e of guiding the developer and providing openness and freedom of design hoi es. The metaphor of roles as views of underlying model elements provides a good intuition on how to ome to a good design. An essential on ept in a MVC-ar hite ture is the mapping between view elements and model elements. A pure obje toriented solution has to ght a proliferation of obje ts or needs further me hanisms for managing the asso iations between the dierent fa ets of a ommon abstra tion. The solution using Obje t Teams an exploit the servi es provided by the general Team infrastru ture. Lifting and lowering transparently manage the role{base asso iation without the need for manual house-keeping. Despite this guidan e by metaphors, the given programming

onstru ts are general enough to allow arbitrary ombination of on epts. Our dis ussion of design de isions regarding ontroller implementations should have given an idea of how the general on ept an be adjusted to dierent s ales and requirements. Finally, the Obje t Teams infrastru ture has drawn bene t from our ase study, sin e it helped identify some ne points like Team freezing. Su h re nements of the Obje t Teams model do not bloat the language but an be provided simply by adding new methods to the most general lass Team.

The ar hite tural style of model-view- ontroller proved to be a multi-fa eted hallenge for separation and integration of on erns. Only a pre ise analysis of ommuni ations and reuse requirements leads to a solution that doesn't just propagate the intermediate solution based on various design patterns but trans ends the apabilities of traditional obje t oriented programming.

7. RELATED WORK

This paper proposes to use the model-view- ontroller paradigm as a ben hmark for AOSD approa hes. So far, only few AOSD te hniques have been evaluated for GUI development. Fidgets [3℄ emphasize the importan e of joint re nements of ollaborating roles espe ially for the ontext of omplex widget stru tures. Their me hanisms of sibling pattern and

onstru tor propagation have semanti s similar to our te hnique of impli it role inheritan e. The main problem addressed in [3℄ is, however, exible bindings of widgets to dierent hardware/OS platforms. The fo us of this paper was on integrating the three omponents model, view and

ontroller. On-demand re-modularization a

ording to [10℄ has the same roots as Obje t Teams. Therefor, it shouldn't surprise that both approa hes have similar apabilities of a-posteriori integration of two omplex stru tures, namely view and model. By introdu ing an expli it interfa e between a onne tor and a ollaboration [10℄ suggests to reuse onne tors for dynami

omposition with dierent ollaborations (Teams in our terminology). The work in [10℄ only mentions as future plans the integration of our allin (in [10℄: allba ks) and a tivation me hanisms. Also, no pra ti al experien e with that model exists. Outside the eld of AOSD, support for MVC is also provided by GUI builders. Su h tools either emit sour e ode or de larative des riptors whi h apture the stru ture of windows and their widgets. For binding su h a generated GUI to a model several alternatives exist: 1. The invo ation of model operations has to be hand oded at spe i points within generated sour e ode. 2. A tions an be de ned by strings whi h are evaluated through re e tive apabilities of the programming language. Interpreter based environments may simply evaluate the stored string. 3. A tions may be en oded by user de ned names (also strings), whi h have to be interpreted expli itly within

lient ode. This is omparable to the style of properties hange listeners of Java Beans. Option (1) provides no satisfa tory separation of a view and its binding to a model. Options (2) and (3) are not type safe be ause su h string based interfa es ir umvent the type system. Thus even simple typos annot be dete ted by the

ompiler. Dierent approa hes for building intera tive appli ations have been mentioned in the introdu tion. A good dis ussion on this behalf an, e.g., be found in [12℄.

8.

STATUS, SUMMARY AND FUTURE

Obje t Teams [6, 11℄ have their roots in Aspe tual Components [9℄. Two prototypi al implementations exists. LAC [5℄ was the rst pra ti al demonstration, that the on epts proposed in [9℄ an in fa t be implemented and operate as expe ted. After further re nements of on epts and terminology, Obje t Teams have been implemented on the basis of Ruby [13℄. This prototype has a fully fun tional integration to the GTK widget library. Most of the experien e reported in this paper has been gathered using Ruby Obje t Teams and GTK. Implementation of a Java-based ompiler and runtime system for Obje t Teams is progressing and the examples in this paper have also been elaborated using Obje tTeams/Java [1, 7℄ and the Swing library. This papers has shown, how the te hni al requirements of the model-view- ontroller paradigm an easily be mapped to onstru ts of the Obje t Teams model. Obje t Teams a hieve a level of independen e between those three omponents, that, to the best of our knowledge, has not been a hieved before in a stati ally typed language. Su h independen e is possible due to a-posteriori binding of lasses and methods. It is essential to support method bindings in both dire tions, allout and allin. Consistent re nement of omplex widget stru tures and their appli ation to omplex model stru tures are a hieved by the module on ept of Teams. Aside from te hni al onsiderations, it turns out, that the metaphor of role obje ts within a ontext, whi h are views of underlying base obje ts, is extremely helpful for designing good ar hite tures in the style of MVC. This on rms our impression that Obje t Teams are not only a powerful ombination of te hniques, gathered from the resear h of many dierent groups and resear hers (see [6℄ for a dis ussion), but also provide an appropriate metaphor whi h enables developers to naturally use the new me hanisms without thinking in terms of me hanisms only but in terms of powerful abstra tions that hide mu h of the omplexity of the underlying exe ution model. On the other hand, the examples shown in this paper also report that a system built with the said abstra tions does not exhibit any unpleasant surprise, i.e., the metaphors are also sound and imply semanti s that are a tually pre isely met by the implementation. A rst medium sized ase study is urrently in progress [14℄, where a proje t management information system is being developed, using Ruby Obje t Teams. It evaluates the apabilities of a Team-based design, whi h separates ommon aspe ts like persisten e, a

ess ontrol or GUI visualization from domain ode. The user interfa e of that system onsistently applies the MVC paradigm in the style presented in this paper. The possibility of en apsulating dierent ross utting (large s ale) aspe ts and their synthesis in a domain model shows the versatility of Obje t Teams whi h appear ready for real world problems. This kind of ase study helps to identify remaining open issues. Features like Team freezing demonstrate how advan ed requirements an be met by new API fun tions of the infrastru ture, instead of new language onstru ts. From su h observations, we onsider the language Obje tTeams/Java quite stable, shifting the fo us of further development and resear h on infrastru ture, tools, pra ti al experien e, method and tutorials.

Acknoledgements

We would like to thank Robert Hirs hfeld and the anonymous reviewers for their helpful omments.

9. REFERENCES

[1℄ Christof Binder. Aspe tual Collaborations: Erweiterung des Java-Compilers fur verbesserte Modularitat dur h aspekt-orientierte Te hniken. Diploma Thesis (German), TU Berlin, 2002. [2℄ J. Bri hau, W. De Meuter, and K. De Volder. Jumping aspe ts. position paper at the workshop "Aspe ts and Dimensions of Con erns", ECOOP 2000, June 2000. [3℄ R. Cardone, A. Brown, S. M Dirmid, and C. Lin. Using mixins to build exible widgets. In Pro . AOSD, pages 76{85, 2002. ACM Press.

[4℄ E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns - Elements of Reusable Obje t-Oriented Software. Addison Wesley, 1995.

[5℄ S. Herrmann and M. Mezini. Combining omposition styles in the evolvable language LAC. In Pro . of ASoC workshop at the 23nd ICSE, 2001. [6℄ Stephan Herrmann. Obje t teams: Improving modularity for ross utting ollaborations. In Pro . Net Obje t Days 2002, www.netobje tdays.org, 2002. [7℄ Christine Hundt. Byte ode-Transformation zur Laufzeitunterstutzung von aspekt-orientierter Modularisierung mit Obje tTeams/Java. Diploma Thesis (German), TU Berlin, 2003 (in preparation). [8℄ G. E. Krasner and S. T. Pope. A ookbook for using the model-view- ontroller user interfa e paradigm in smalltalk-80. JOOP, Aug./Sept. 1988. [9℄ K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspe tual omponents. In Te hni al Report, Northeastern University, April 1999. [10℄ M. Mezini and K. Ostermann. Integrating independent omponents with on-demand remodularization. In Pro . of OOPSLA'02, 2002. [11℄ Obje t Teams home page.

http://www.Obje tTeams.org.

[12℄ R. Taylor and G. Johnson. Separations of on erns in the hiron-1 user interfa e development and mangagement system. In Pro . of INTERCHI'93, pages 367{374. ACM, 1993. [13℄ D. Thomas and A. Hunt. Programming Ruby: A Pragmati Programmer's Guide, Addison Wesley, 2000. [14℄ Matthias Veit. Evaluierung modularer Softwareentwi klung mit "Obje t Teams" am Beispiel eines Projektmanagementsystems. Diploma Thesis (German), TU Berlin, 2002. [15℄ Matthias Veit. Ruby Obje t Teams.

http://sour eforge.net/proje ts/robje tteam.

[16℄ Gimp ToolKit http://www.gtk.org/