clover architecture for groupware
TRANSCRIPT
ABSTRACTIn this paper we present the Clover architectural model, anew conceptual architectural model for groupware. Ourmodel results from the combination of the layer approachof Dewan's generic architecture with the functionaldecomposition of the Clover design model. The Cloverdesign model defines three classes of services that agroupware application may support, namely, production,communication and coordination services. The threeclasses of services can be found in each functional layer ofour model. Our model is illustrated with a working system,the CoVitesse system, its software being organizedaccording to our Clover architectural model.
KeywordsConceptual Software Architecture, Clover Design Model.
INTRODUCTIONPeople's interest in collaborating with others is growingdaily and in particular on the internet. This is not only inorder to read web pages or download files but also tocommunicate, to play multi-user games or to exchange datasuch as music files. In a nutshell, to interact with others.This leads to an outbreak of a multitude of multi-usersystems (or groupware) designed to chat, such as ICQ, toplay, such as Quake or to share mp3 files, such as the well-known Napster (peer-to-peer). Despite the multiplicity ofexisting groupware, their development still remainscomplex and unsystematic. It is widely recognized that,although the adhoc development of software is acceptablefor throw-away prototypes, architectural design of complexsystems can no longer simply emerge from craft skills. Inthis paper we address the architectural design of groupwareby defining a conceptual software architectural model forgroupware.
A conceptual software architecture is an organization ofcomputational elements and the description of theirinteractions. A conceptual software architecture modeldefines a vocabulary of design elements, imposesconfiguration constraints on these elements, determines asemantic interpretation that gives meaning to the systemdescription, and enables analysis of the system properties[22].
For example, Dewan's generic architectural model [8]structures a groupware application as a stack of shared andreplicated layers which communicate with each other byexchanging events. A conceptual software architecture isthen mapped into an implementat ion architecturedependent on the software tools available. Software toolsfor the construction of groupware such as the Groupkitinteraction toolkit [21] or the COCA [16] and DragonFly[1] platforms will not eliminate conceptual architecturalissues as long as the construction of these systems requiresprogramming. Clearly, a conceptual model for identifyingand organizing the components of groupware is still anecessity. As explained in [5], without an adequatearchitectural framework, the construction of groupware andin general interactive systems is hard to achieve, theresulting software is difficult to maintain and iterativerefinement is impossible.
Several conceptual software architectural models forgroupware exist, such as Dewan's generic architecture [8],Clock [11] and PAC* [5]. Our Clover architectural model iscomplementary to the existing models by defining at a finergrain how functionalities should be structured at each levelof abstraction in the architecture. To do so, we base ourarchitectural model on the Clover design model [9][23].The Clover design model defines three classes of services:production, communication and coordination services.During the system design phase, the three types of servicesmust be identified and their access harmoniously combinedin the user interface. Our Clover architectural model makessuch system design concepts explicit within the software.Indeed, because software architecture modeling is a designactivity at the interface between the system design field andthe programming field, software architecture must take intoaccount attributes of both fields: these attributes includeproperties of the designed system and of the future softwareto be implemented [17].
The structure of the paper is as follows: first, we introducethe Clover design model and stress its impact on the designof the system as well as on the design of the user interface.We then present the main characteristics of threearchitectural models, Arch, Dewan's architecture andPAC*, all three of which our Clover metamodel relies on.Our Clover architectural model is a metamodel i.e. severalClover architectural models can be derived from it. We firstpresent one Clover architectural model and then thegeneralization, the metamodel. We close with thepresentation of the clover architecture of a running system,CoVitesse, which enables collaborative navigation on theWorld Wide Web. The discussion will be illustrated with
Clover Architecture for GroupwareYann Laurillau
Laboratoire CLIPS/IMAGUniversity of Grenoble
Domaine Universitaire, BP 5338041 Grenoble, FRANCE
Laurence Nigay1
University of GlasgowDepartment of Computer Science
17 Lilybank GardensGlasgow G12 8QQ
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the fullcitation on the first page. To copy otherwise, or republish, to post on servers or toredistribute to lists, requires prior specific permission and/or a fee.CSCW'02, November 16-20, 2002, New Orleans, Louisiana, USA.Copyright 2002 ACM 1-58113-560-2/02/0011…$5.00.
1. On sabbatical from the University of Grenoble, CLIPS Labora-tory, BP 53, 38041 Grenoble Cedex 9, France.
two systems, CoVitesse system, whose main features arepresented in the next section.
AN ILLUSTRATIVE EXAMPLE: COVITESSE SYSTEMWe applied our Clover architectural model to the softwaredesign of the CoVitesse system.
CoVitesse [7][14] is a groupware application that enablescollaborative navigation on the WWW. Users sharing thesame information space can cooperate to seek information.This system is built on the Vitesse system [19], a single-user application that visualizes the results of a querysubmitted to a search engine on the WWW. As shown inFigure 1, CoVitesse displays the overall set of results: eachretrieved page (node) is displayed by a polygon. Users arerepresented by colored shapes (a red Y for Yann and a blueL for Laurence). When a user wants to visit a page, she/hedouble-clicks on the corresponding polygon and the webpage is downloaded in a separate browser. Darker polygonsindicate visited web pages. At any time, a user can see allother users moving in the space, use the chat box (which isbelow the information space) to communicate with otherusers, or organize her/his own caddy which contains themarked pages.
CoVitesse allows users to create groups. A group isidentified by a name and a color. For example, in Figure 1,Yann, represented by the shape Y, is a member of a groupidentified with a red color. In the current version of thesystem, four kinds of groups, i.e. collaborative navigationaltasks, are available: guided tour, opportunistic navigation,shared navigation and cooperative navigation. According tothe group type, different functionalities are available. Forexample, within a group defined as an opportunistic
navigation group, a member can take control of thenavigation of the other members; such a functionality is notpossible with a Shared navigation group. Moreover, accessrights to data are different according to group types; rightsare imposed on the group caddy (i.e. the pages selected bythe group) as well as on the group preferences. Grouppreferences include the information related to the group, thechoice or not to publish the gathered results and thepublication filter applied on the results. For example, anymember of an opportunistic navigation can modify thegroup preferences. More details about these navigationtypes can be found in [14].
CoVitesse provides persistent access to all the data,modified or produced during a session. These data includeinformation about users and groups such as the avatarshape, the gathered results and the preferences. These dataare protected with a simple mechanism of username/password. Then, when a user starts a new session, she/herecovers her/his own private data.
CLOVER DESIGN MODELDescriptionThe Clover design model [9][23] provides a high levelpartitioning for reasoning about the collaborative services agroupware application may support. As shown in Figure 2,a groupware application covers three kinds of services:production, communication and coordination.
• The production space refers to the objects produced by agroup activity or to the objects shared by multiple users.In the CoVitesse system, the production is the set ofresults gathered by users and groups during a session.
• The communication space refers to person-to-personcommunication such as e-mail, relay chat, mediaspace.The CoVitesse system provides a chat room for usersnavigating in the same information space.
• The coordination space covers activities dependenciesincluding temporal relationships between the multi-useractivities. It also refers to the relationships between actorsand activities. In the CoVitesse system, coordination tasksinclude creating, joining, leaving a group or accepting anew member. Looking at the avatars moving within theinformation space is also a coordination task.
However, not all the existing groupware support the threefacets of the Clover design model. This point is furtherdiscussed in the following section.
CSCW Design IssuesThe Clover design model is useful for the design ofgroupware during the functional specification phasebecause it defines three classes of functionalities that agroupware application may support. For example, the
Figure 1: Snapshot from the CoVitesse system.
ProductionSpace
CommunicationSpace
CoordinationSpace
Figure 2: Groupware as “functional clover”.
CoVitesse system supports the following three types offunctionalities:
• Production: the system manages a caddy of collectedresults for each user and group. It is possible to modify thegroup caddy according to the defined access rights.
• Communication: the system provides a simple chat box.Currently, the communication group is composed of allthe users.
• Coordination: the system provides services to join/leave asession, to create/join/leave a working group. In addition,coordination is done when a user moves her/his avatar inthe information space or when s/he modifies thepreferences.
As we mentioned in the previous section, not all thee x i s t in g g ro u p wa re su p p o r t t h e th r e e ty p e s o ffunctionalities. For example, a mediaspace, a systemdedicated to informal communication to enhance teamawareness, is built upon communication functionalities andfew coordination functionalities such as joining or leaving asession. In this example, there is no support for production.In addition some approaches treat the coordinationfunctionalities as special in contrast to the production andcommunication functionalities: coordination functionalitiesare separated from the system itself. For example in [8] thesession manager dedicated to coordination is modeled as anexternal software component. Another example is theCOCA platform [16]. The platform is dedicated tocoordination and is able to manage tools includingconference tools or whiteboards based on a set of rulesdefined in a prolog-like language. These rules dedicated tocoordination are interpreted at the runtime by the COCAvirtual machine. The key idea of this platform is to extractthe coordination functionalities from the system. Theplatform therefore enables the reuse of non-collaborativesystems, but it provides no support for production andcommunication. Moreover an exist ing groupwareapplication may include its own coordination model whichmay not match with the COCA one.
W h e n th e C lo ve r mo d e l d e f i nes th r e e t yp e s o ffunctionalities, it also defines three classes of datastructures manipulated by these functionalities. Forexample let us consider the implementation of the notion ofgroup in a chat box used to manage a lecture. We considertwo types of actors: the lecturer and the audience. Thesystem implements coordination functions, to join a sessionand to assign roles (i.e., lecturer or audience) and enablescommunication between the lecturer and the audience. Inorder to avoid interference generated by the audiencechatting, we should consider two communication channels:one channel for communication between the lecturer andthe audience and another channel between the members ofthe audience excluding the lecturer. The system thereforemaintains two data structures related to the notion of group:
• one structure containing the representation of a lecturerand an audience, for coordination and communication,
• one structure containing the representation of an audiencewith its members and excluding the lecturer, dedicated tocommunication only.
The example illustrates the fact that data structures can beclassified according to the three Clover facets. In additionthe example shows that the same data structure can beshared and manipulated by different Clover functionalities.The data structure therefore belongs to one of theintersections of the three facets in Figure 2. To furtherillustrate this last point we consider CoVitesse: when a usermoves her/his avatar in the information space:
• the shape is drawn at the new coordinates in each user’sview: a coordination functionality;
• the URL is added to the group history: a productionfunctionality.
One data structure is used for modeling the position of anavatar in the information space and several Cloverfunctionalities manipulate this unique structure.
In conclusion, the Clover design model can be used as aguideline in the design of groupware for specifying thefunctionalities as well as the data structures. The usefulnessof the model for the design of the user interface is moreproblematic.
HCI Design IssuesWhile the Clover model is useful for identifying theservices provided by groupware, it should not be used as aguideline for designing the user interface. For example,having separate windows or panels dedicated to eachClover space will lead to a complex interaction. The firstdesign of the CoVitesse user interface was based on theClover design model. The following three windows are partof the first CoVitesse user interface:
• a window dedicated to the production containing theinformation space and the marked web pages,
• a window dedicated to communication that includestextual chat, and,
• a third window dedicated to coordination that allows theuser to create and edit a group.
Informal tests with groups of four users having to perform ascenario (i.e., collect a list of the ten most relevant websites about human-computer interaction), lead us toconclude that the information space and the chat box shouldbe combined at the user interface (combination ofproduction and communication). Indeed, at the end of thetest sessions, users complained about a lack of awareness:they were not able to perform a navigational task and tolook at chat exchanges at the same time.
In addition to our own experience with CoVitesse, severalgroupware systems combine the services provided by eachof the three Clover spaces, making them accessible andobservable through appropriate user interface compositeobjec ts . For example , as shown in Figure 3, thecollaborative scrollbar introduced in [5] and based on themulti-user scrollbar of the SASSE editor [2] coversfunctionalities of the three spaces. The right scrollbar,
dedicated to production, is an ordinary scrollbar forscrol ling the text. The left scrollbar, dedicated tocommunication and coordination, contains multipleelevators, one per remote user who can be seen in a videothumbnail inside the elevator. On the one hand, from afunctionality viewpoint, it is easy to observe that thecoordination is covered by the current position of remoteusers in the text and communication by a video service. Onthe other hand, from a user interface viewpoint, a singleinteraction object (a scrollbar) is used for coordination aswell as communication.
In conclusion, our own experience as well as existinggroupware widgets underline the fact that the Clover designmodel is useful in identifying the funtionalities that the userinterface should provide but should not be applied as aguideline for designing the user interface itself. Suchconc lus ions have a di rec t impact on our Cloverarchitectural model. Before presenting our model, we showthe main characteristics of three architectural models onwhich our model relies.
SOFTWARE ARCHITECTURESThis section contains the description of three architecturalmodels, Arch, Dewan's generic architecture and PAC*. Thethree models serve as foundations for our Cloverarchitectural metamodel.
Arch model
Software architectures for groupware are often based onarchitectural models for single-user interactive systems. Inthis field, the Arch model [3], an extension of the Seeheimmodel [10], is a reference model that defines a canonicalfunctional decomposition of an interactive system. Archadvocates domain dependent components as well as userinterface components. As shown in Figure 4, the Archmodel breaks up an interactive system into five layers orcomponents:
• The Functional Core component implements domain-specific concepts and functions, in a presentationindependent way. The data structures managed by thiscomponent are domain objects.
• The Functional Core Adapter component serves as amediator between the Dialog Control ler and theFunctional Core. Data exchanged with the FunctionalCore are the domain objects that the Functional Coreexports to the user. Data exchanged with the DialogControl ler are conceptual objects. These defineperspectives on domain objects intended to match theuser’s mental representation of domain concepts.
• The Physical Interaction component denotes theunderlying platform, both software and hardware(interaction devices). It supports the physical interactionwith the user and corresponds to the services of a UserInterface toolkit.
• The Logical Interaction component implements theperceivable behavior of the application for outputs as wellas inputs. It relies on the Physical Interaction component.The Logical Interaction component is usually compared toan abstract User Interface toolkit. It serves as an adapterbetween the Physical Interaction component and theDialog Controller.
• The Dialog Controller component is the keystone of thearch. It has the responsibility for task-level sequencing. Itmanages both conceptual objects and presentation objects.
Dewan’s Generic Architecture for Groupware
Dewan's generic collaborative architecture [8] can be seenas a generalization of the "zipper model" [20] and the Archmodel. Dewan's architecture structures a groupwareapplication into a variable number of layers from thedomain-dependent level to the hardware level. A layer is asoftware component corresponding to a specific level ofabstraction. As shown in Figure 5, the top-most layercorresponds to the semantic layer while the bottom-mostlayer corresponds to the hardware layer. To make a parallelwith the Arch model, the top-most layer coincides with theArch Functional Core component and the bottom-most
Ordinary
Productionscrollbar
elevator
Coordination andCommunication
scrollbar
Remote users elevatorsincluding video thumbnails
Figure 3: Collaborative scrollbar.
FunctionalCore
FunctionalCore
Adaptor
DialogController
Logical
Physical
Interaction
Interaction
Figure 4: Arch model.
Sha
red
laye
rsR
eplic
ated
laye
rs
0
1
0
1
L L
Layer L+1
Layer N
Outputs Inputs
Figure 5: Dewan’s generic collaborative architecture.
layer coincides with the Arch Physical Interactioncomponent.
The overall structure is composed of a stem and severalbranches. The stem, as shown in Figure 5, is composed ofshared layers (layers L+1 to N). A branch is composed ofreplicated layers (layers 0 to L). The layer L of Figure 5defines the branch point of replicated or versioned layers[8]. A branch contains private layers for each user of theapplication. Moreover the objects managed by layers of abranch are all private objects of a user. Conversely, sharedlayers and shared objects are public . The layerscommunicate with each other using two types of events:interaction and collaboration events. Interaction eventsdenote events sent up (input events) and down (outputevents) between layers. Events sent between layers ofdifferent branches are collaboration events.
In the rest of the discussion, we shall often use the termslayer and component interchangeably. Although a softwarecomponent can encompass several layers, for simplicity weassume that there is one layer per component.
PAC* model
PAC* [5] is the collaborative extension of the PAC-Amodeus hybrid architectural model [18]. PAC-Amodeusreuses the main components of the Arch model andpopulates the Dialog Controller with PAC agents. A PACagent is composed of three facets:
• a Presentation facet which defines the user interface of theagent,
• an Abstraction facet which manages the domain concepts,and,
• a Control facet which manages the links and constraintsbetween its two surrounding facets (i.e., the Presentationand the Abstraction facets) as well as its relationships withother agents.
A PAC* agent, as shown in Figure 6 (a), is a PAC agent inwhich each facet is structured along with the threefunctional classes of the groupware clover. Alternatively, aPAC* agent can be seen as a cluster of three PAC agents,
each agent dedicated to one functional class of thegroupware clover. The cluster of PAC agents represented inFigure 6 (b) is a hybrid form of a PAC* agent: the threeclover agents can communicate with each others via theirControl facets and a single handle is in charge ofcommunication with the external world (i.e., other agents).
CLOVER ARCHITECTUREThe Clover architectural metamodel relies on the threeabove models. From our metamodel, several Cloverarchitectural models can be derived. In this section wepresent one Clover architectural model derived from themetamodel, the latter being presented in the next section.
Description
The Clover architectural model of Figure 7 is derived fromDewan's model using the functional layers of the Archmodel [3]. Nevertheless instead of the five layers of theArch model, our model advocates six layers: the ArchFunctional Core (FC) component is split into twocomponents: the shared and replicated FCs. In Figure 7, toavoid a visual overload, we have not drawn the ArchLogical and Physical Interaction components, which arelocated below the Dialog Controller in the stack. Inaddition, some arrows, between layers of the two branchesare not drawn.
Having defined the canonical component decomposition,let us now consider the global architecture made of sharedand replicated components. All the Arch components arereplicated components except the shared FC. In this model,we focus on the functional components and we have madeno assumptions about the Dialog Controller and thePresentation Components. Compared to the PAC* model,in which the FC is a completely shared layer, the FC is splithere in two layers: one is replicated and private; the other isshared and public. The latter provides shared domain-
A C PProduction
Communication
Coordination
a) functional decomposition of a PAC* agent
AC
P
AC
P
AC
PCoordination
Communication
Production
Handleb) a PAC* agent as three dedicated PAC agents
Figure 6: PAC* architectural model.
FunctionalCore Adaptor
DialogController
Sha
red
laye
rsR
eplic
ated
laye
rs
FunctionalCore Adaptor
Dialog
Controller
Figure 7: Clover architecture.
Clover
wra
pper
Prod.
Coord.
Comm.
Clover
wra
pper
Prod.
Coord.
Comm.
Replicated FC
Clover
wra
pper
Prod.
Coord.
Comm.
Shared FC
Replicated FC
Wrapper
dependent objects and functions that are manipulated by allthe users during the interaction. Conversely, the replicatedFC maintains the state of a single user and manages privatedomain-dependent objects. As in Dewan’s model, thecollection of shared and user’s private objects defines theinteraction state for a particular user. This point isillustrated with the example of the software design ofCoVitesse in the last section.
The originality of this architecture comes from the Cloverdecomposition of the Shared and Replicated FCs. The FCsare made of a wrapper which embeds three sub-FCs, eachsub-FC being dedicated to one of three functional classes ofthe groupware clover. Each Clover FCs manipulatessemant ic objects dedicated to one of the Cloverfunctionalities and performs specific processing functionson their objects. The wrapper approach is similar to thesoftware component oriented programming in CORBA.The design rationale for the wrapper is threefold:
• The wrapper encapsulates the three Clover FCs and actsas a functional glue. The wrapper is also responsible forcommunication with other layers. Because the wrapper isa software interface that hides the Clover partitioning, itenables communication with non-clover aware layers. Forexample the shared FC wrapper serves as a mediatorbetween the three Clover shared FCs and the FunctionalCore Adapter. The wrapper allows us to stack a Cloverpartitioned component with a component that is notcollaboration aware or Clover aware.
• The wrapper maintains a common state, i.e. the commonsemantic objects, among the production, communicationand coordination FCs. Such objects common to the threeClover spaces have been identified and illustrated in thesection entitled "Clover design model".
• The wrapper provides functionalities including the systemservices and single-user functionalities, which are notintrinsically collaboration aware or Clover aware.
The communication between layers in the stack andbetween peer layers follows the same rules as described inDewan’s model. Moreover interaction and collaborationevents are categorized into three classes of events:production, communication and coordination events. Thisenables direct communication between Clover FCs.Nevertheless the model maintains a general event forcommunication between layers that are not Clover aware.
Finally, we have explained in a previous section that theClover model should not be used as a guideline fordesigning the user interface. As a consequence, we onlypartitioned the FC component according to the three Cloverfunctional classes and not the presentation components(Logica l and Physica l Inte rac t ion components) .Furthermore it is important to note that the model is oneexample of a model derived from our metamodel: in thismodel we have unzipped the architecture at the FC layer,the branching point being the Replicated FC. Differentbranching points are possible. Fixing the branching point isa design issue and defines the versioning/replicationarchitectural degree, as defined in [8]. In our Cloverarchitecture, the Replicated FC being the branching point,
the corresponding replication degree is high. The Clovermodel therefore allows relaxed WISIWYS (What I See IsWhat You See). Indeed a low repl icat ion ( i .e . anarchitecture unzipped at the Physical or Logical Interactionlayers) implies strict WISIWYS.
An Extension of PAC*Our Clover architectural model is complementary to thePAC* model. Indeed in the PAC* model, a PAC* agent ofthe Dialog Controller exchanges events with the FunctionalCore via the Functional Core adapter. In our Clover model,if the Dialog Controller is populated by PAC* agents(Figure 6), each Clover Abstraction facet of a PAC* agentwill communicate with the corresponding CloverReplicated FCs. But for a high modifiability of the code,the communication will not be direct but will be via theFunctional Core Adapter that is not necessarily Cloveraware, and then via the Replicated FC wrapper.
Moreover in Figure 6(b), a PAC* agent contains a handle.This latter is responsible for managing the communicationwith the external world, i.e. the other agents. The role of thehandle is one of the roles fulfilled by a wrapper in ourClover model. The wrapper manages communicationbetween the three Clover FCs and their surrounding layers.
CLOVER METAMODELHaving presented one Clover architectural model, we nowdescribe the generalization: the Clover metamodel.
DescriptionThe Clover architectural metamodel of Figure 8 structures agroupware application into a variable number of layers, asopposed to the previously presented Clover model which isbased on the five layers of the Arch model. Compared withthe previous Clover model of Figure 7, Layer Lcorresponds to the replicated FC and Layer L+1 to theShared FC.
The originality of this metamodel comes from the Cloverdecomposition of the software units that compose thebranches and the stem. As shown in Figure 8, each unit ofthe model contains a wrapper that encapsulates threeClover sub-components: production, communication andcoordination sub-components. Interaction and collaborationevents exchanged between layers are subsequentlycategorized into three classes of events: production,communication and coordination events. The metamodelnevertheless authorizes a general event for communicationbetween layers that are not Clover aware. In Figure 8, inorder to avoid a visual overload, we have not drawn everyarrow corresponding to an exchange of events betweenlayers.
As explained in the previous section, one role of a layerwrapper, which encompasses a Clover’s structure, is to hidet h e C l o v e r b r e ak d o w n f ro m th e o t h e r l ay e r s .Communication between a Clover aware layer and a non-Clover aware layer is thus possible. Indeed, a layer does notnecessarily implement a collaboration semantic and istherefore not necessarily decomposed according to thethree Clover functionalities. This is usually the case for thelowest layers, which are dedicated to the physical andlogical interaction with a user. For example, as shown inFigure 8, Layer 0 (the leaf of the branch) which
corresponds to the hardware layer, is typically a non-Cloveraware layer.
Moreover the full decomposition of a layer according to thethree Clover functionalities is not mandatory. A layer mayinclude Production and Coordination functionalities and noCommunication functionality: this is for example the casefor Layer 1 in Figure 8.
BENEFITS AND PROPERTIESThe Clover functional partitioning establishes a directmapping between the design concepts and the softwarearchitecture modeling. This partitioning provides a clearguide in the organization of the functionalities identifiedduring the design phase. In addition it is complementary tothe traditional parti tioning of functionali ties intocomponents, where each of them corresponds to one levelof abstraction as for instance in Dewan’s architecture orArch model. Indeed, for a component corresponding to onelevel of abstraction, the Clover metamodel advocates threesub-components dedicated to production, communicationand coordination. Such a highly modular implementationsatisfies the modifiability, reusability and extensibilityproperties. These properties are crucial for supporting auser-centered design. For example, in the CoVitessesystem, it would be possible to add a video service as a newcommunication channel by modifying the Shared andReplicated Functional Core dedicated to communicationwithout endangering the other components. Moreovermodularity is a well-known software engineering
mechanism for reducing the cost of development. Based onour own experience, applying the Clover architecturalmodel to the CoVitesse software design made it easy todevelop parts of the system without having a global view ofthe overall code. For example, the three Shared FunctionalCores and the three Replicated Functional Cores, describedin the following paragraph, have been developed and testedindependently.
The metamodel does not fix the number of layers: layerscan be used to increase the separation of functionalities i.e.to increase the modularity of the code. This approach isorthogonal to the Clover breakdown of a layer.
The Clover breakdown of a layer can be partial. Themetamodel therefore allows a pile of several layers withdifferent Clover breakdowns. For example, instantmessaging (communication functionality) is usually usedfor managing coordination among users [24]. To implementsuch a coordination which is based on communication, ashared layer dedicated to coordination is stacked on top of ashared layer that contains communication functionalitiesonly.
In our metamodel the coordination, production andcommunication functionalities are all treated the same way.This is in contrast to previous studies [8][16] where thecoordination functionalities are treated as special whereasthe production and communication functionalities are not.For example, in Dewan's architecture [8], the sessionmanager is a special component that should be locatedoutside the architecture. This external component managesthe users and the groups during a session. This componentis therefore responsible for creating the tree and forconnecting the branches with the stem. In the Clovermetamodel, the session manager is a coordinationcomponent located in a stem layer. Indeed we argue thatthere is always a shared layer in the conceptual softwarearchitecture. The conceptual architecture is then mappedinto an implementation architecture by assigning processesto components; the processes in turn must then be assignedto hosts. Different approaches to distribution can be appliedto a conceptual architecture. Distribution and layerdecomposition (or software component decomposition) aretwo orthogonal mechanisms. In particular, a shared layer atthe conceptual level does not imply a central site at theimplementation level.
Finally the Clover metamodel extends Dewan's genericarchitectural model [8]. An architecture based on Dewan'sgeneric model is described by an awareness degree. Theawareness degree is equal to the level of the highest layerthat is collaboration-aware. Extending the awarenessdegree , we def ine a product ion-aware degree, acommunication-aware and a coordination-aware degree.Such extensions will allow a more precise classification ofexisting systems from an architectural point of view, thanthe one presented in Table 9.1 in [8].
CLOVER MODEL IN PRACTICE: COVITESSE SOFTWARE DESIGNIn this section, we show how the Clover model can be usedin practice by presenting the Clover software designsolution of CoVitesse.
Layer 0
Clover
wra
pper
Coord.
Layer 1
Clover
wra
pper
Prod.
Coord.
Comm.
Layer L
Prod.
Sha
red
laye
rsR
eplic
ated
laye
rs
Figure 8: Generalized Clover architecture.
Layer 0
Clover
wra
pper
Coord.
Layer 1
Clover
wra
pper
Prod.
Coord.
Comm.
Layer L
Prod.
Clover
wra
pper
Prod.
Coord.
Comm.
Layer L+1
Clover
wra
pper
Prod.
Coord.
Comm.
Layer N
Figure 9 illustrates the application of the Clover model tothe software design of CoVitesse. At the conceptual level,we applied the Clover model of Figure 7 that includes areplicated Functional Core and a shared Functional Core.At the implementation level, CoVitesse is a client/serverapplication written in Java. The shared components are onthe server side and the replicated components on both sides(client and server). The communication between clients andthe server is based on network streams.
We describe the CoVitesse architecture from the highestlayer (top of Figure 9) to the lowest. The highest layer, theShared Functional Core (FC), is made of a FCprod, aFCcomm, a FCcoord, and a meta-server. The meta-serveris a wrapper: it encompasses the three Clover FCs andmanages the access to the underlying network.
• Shared Production Functional Core (FCprod):This component manages concepts related to production,represented as a document icon in FCprod of Figure 9.These concepts are document, reference, album andcatalogue. A document is an elementary unit that ismanipulated by a group. A reference is a pointer on adocument. An album is a container, created and managedby authors: an album contains documents and references.A catalogue is a set of references. These four concepts areimplemented as Java interfaces. There are severalfunctions available including: the creation or obtaining ofa catalogue, creation of an album, addition or removal ofan author from an album, addition of a document in analbum, modification of the content of an album. InCoVitesse, a reference is an URL, a document is the
content of a web page, i.e. an HTML document, acatalogue is a set of URLs resulting from a querysubmitted to a search engine and an album is a set ofURLs created by authors.
• Shared Communication Functional Core (FCcomm):This component manages communication channels thatare represented by a tube in FCcomm of Figure 9 Thecommunication channel is the only concept manipulatedby FCcomm. A client can subscribe or unsubscribe to acommunication channel and can post a message on thechannel. A channel is implemented in Java. In CoVitesse,the unique communication channel is a chat channel,which can be compared to a mailing list: when a userposts a message on this channel, the message is broadcastto all the subscribers.
• Shared Coordination Functional Core (FCcoord):This component has the responsibility for coordinatingusers and groups. It first hosts a database of users andgroups. Therefore this component allows persistent accessto the description of the users and the groups. Moreover,this component provides mechanisms for concurrencycontrol and for consistency control. For instance, itsynchronizes a concurrent access for two members tomodify group preferences. This component also notifiesall the clients, for consistency purposes, when a usermodifies her/his own private preferences. Consequentlythe concepts manipulated by FCcoord are related to usersand groups; these concepts are implemented as Javainterfaces.
- User: Two functions are implemented to read andmodify information about a user as well as two functionsto read and modify the access rights to those pieces ofinformation. This implementation allows the developer todefine the user's description according to the nature of thagroupware application. In CoVitesse, a user is describedby a name, a password, a geometrical shape, filteringpreferences, an E-mail address, etc. The user is identifiedby her/his username and password.
- Group: A Group is defined by, a set of members, rightsfor joining a group and a minimal set of functions. Thesefunctions include setting or obtaining information about agroup, creating a group, joining a group (a user sends arequest to all the members who accept or do not accept thenewcomer), leaving a group. In CoVitesse, a group isdescribed by: a group name, a color, filtering preferences,a navigation type and navigation preferences.
As shown in Figure 9, the layer under the SharedFunctional Core is the Replicated Functional Core. At theimplementation level, the Replicated Functional Core issplit into two parts: one part on the server side and one parton the client side. The part on the client side maintains aduplicated version of the current session, which isoriginally saved on the server side. This mechanism ofcaching data is used to increase performance at runtime.The Shared Functional Core (on the server side as well ason the client side) is made of two Clover FCs, namelyFCprod and FCcoord. These two Clover components
FCcoord
group
users and groupsFCprod FCcomm
channel
FCA
Client’s private functional layer
CoVitesse DC
Sha
red
laye
rsR
eplic
ated
laye
rs
FC prod FC coordprivateprivate
album
Figure 9: CoVitesse implementation architecture.
Network
Local state’s functional layer
FC prod FC coordlocal statelocal state
Public layer
preferences
user
user
shareddocument
maintain private data owned by the client. This designsolution enables the server part to provide persistent accessto those private data.
• Replicated FCcoord maintains the user 's privatepreferences and communicates with other clients throughthe Shared Functional Core. Both replicated and sharedcomponents dedicated to coordination manipulate thesame data about a user. Nevertheless only the replicatedcomponent is allowed to modify private data such as theusername and password, while the shared component canread the private data about a user when it is published.
• Replicated FCprod hosts the user's private albumcontaining the collected URLs. Moreover FCprod hasaccess to the group album managed and protected by theShared Functional Core dedicated to production.
In the current implementation of CoVitesse, there is noReplicated Functional Core dedicated to communication.Consequently the wrapper transfers communication eventsdirectly, in a bidirectional way, between the sharedFCcomm and the Functional Core Adapter (FCA inFigure 9). However, future developments are planned forimplementing this missing facet. For example, privatealiases of recipients such as mailing-lists can be managedby the shared FCcomm. Moreover, we have planned toextend the shared FCcomm in order to allow privatechannels for chatting within a defined group of users.
In the rest of the architecture, the components do notimplement a Clover structure. These components are theFunctional Core Adapter (FCA), the Dialog Controller(DC) and the Logical and Physical Interaction components.In Figure 9, the Logical and Physical Interact ioncomponents are not drawn. They should be drawn under theCoVitesse DC.
VALIDATION OF THE CLOVER METAMODELSoftware tools for the construction of groupware will noteliminate architectural issues as long as the construction ofgroupware requires programming. Developers andmaintainers of groupware need to rely on architecturalmodels:
• for identifying software components, • for organizing their interconnections, • for reasoning about components and interconnections, • for modifying and maintaining them in a productive way,• for verifying ergonomic and software properties.
Nevertheless an architectural design is neither inherentlygood nor bad, but is conformant (or not) to a set of specificproperties [4]. The SAAM method shows how to assess anarchitectural design along these lines [13]. Shaw et al.demonstrate that different software architecture modelshave different strengths and weaknesses and therefore leadto different architectural design solutions with significantlydifferent software properties [22]. Therefore, softwarearchitecture models should be chosen in accordance withthe system requirements and a software architecture modelis suitable for a sub-set of properties. By “suitable” wemean that the model helps to either verify or assess aproperty. In this paper, we presented a set of properties that
the Clover architectural metamodel verifies. In particular,the Clover metamodel accommodates style heterogeneityby allowing a pile of several layers with different Cloverbreakdowns, modif iabil ity, reusabil ity as well asextensibility.
Another avenue to validate an architectural model is toshow that it corresponds to an implicit software practice:the model therefore makes explicit programmers savoir-faire. To do so, in [15], we studied the code of threegroupware applications: a mediaspace developed in ourteam [6], a shared text edi tor NetEdit [25] and acollaborative ping-pong game [12]. By reverse engineeringbased on the code of the three applications, we showed thatthe modules of the existing code are organized according toour Clover metamodel.
Finally the generality of the metamodel (and in particularthe variable number of layers and the possible partialClover breakdown of a layer) is a required property forembracing the diversity and the novelty of the technicalproblems raised by groupware. Indeed the generality of anarchitectural model stems from its capacity to adapt to avariety of constraints according to a sound design rationale.So far the Clover metamodel has proven useful intriggering the right software design questions and inproviding operational answers for several cases, both forforward design and engineering as well as for reversedesign and engineering. On the one hand, the Clovermetamodel guides the development of a future system suchas CoVitesse; on the other hand it helps in understandingthe organization of existing code. We do feel however thatClover metamodel patterns and heuristic rules need to bedevised to respond to recurrent problems in multi-usersystems. Indeed the unavoidable generality of themetamodel makes its application difficult. As done for ourPAC-Amodeus software architectural model [17],providing patterns and rules will serve as guidelines forapplying the Clover architectural metamodel.
CONCLUSIONWe have presented a new conceptual architecturalmetamodel, the Clover architectural metamodel. TheClover metamodel results from the combination of the layerapproach of Dewan's generic architecture with thefunctional decomposition of the Clover design model. TheClover architectural model has the following properties:
• By applying a Clover functional breaking up of each layerof our metamodel, we make system design issues explicitwithin the software architecture. Indeed the softwarearchitecture modeling is a design activity at the turningpoint between two worlds: the system design field and theprogramming field. Because of its interlinking location,software architecture must take into account design issuesand properties of the two worlds.
• The Clover metamodel results from a motivatedcombination of existing architectural models selected forthe complementarity of their properties. In particular ourmetamodel inherits the generic property from the layerapproach of Dewan's generic architecture. The metamodelalso refines each layer and event according to the three
Clover facets. This Clover breakdown of the layerincreases the modularity of the code.
One architectural model derived from the Clovermetamodel has been applied to the software design of theCoVitesse system. This derived model (Clover model), thathas been presented in the paper and illustrated usingCoVitesse, refines the Functional Core in terms ofrepl icated and shared components. Moreover theFunctional Core components are partitioned into threeClover sub-components dedicated to production,communicat ion and coordinat ion, the three sub-components being encapsulated by a wrapper.
Future developments consist of completing a Cloverplatform for developing groupware. The platform illustratesour Clover architectural metamodel by providing softwarecomponents dedicated to the three Clover facets. Theplatform implements reusable encapsulated mechanismsthat facilitate the implementation of any groupware. TheCoVitesse system has both implemented using ourplatform. We are currently testing the robustness of theplatform.
ACKNOWLEDGMENTSThis work has been partly supported by the FrenchMinisters of Research and Industry Contract SIRII. Specialthanks to G. Serghiou for help with style and EnglishGrammar.
REFERENCES1. Anderson, G., Graham, T.C.N., Wright, T., Dragonfly:
Linking Conceptual and Implementation Architecturesof Multiuser Interactive Systems, in Proceedings ofICSE’00, 2000, p. 252-261, ACM Press.
2. Baecker, R.M., Nastos, D., Posner, L.R., Mawlby, M.K.,The user-centered iterative design of collaborativewriting, in Proceeding of the Workshop on Real TimeGroup Drawing and Writing Tools, CSCW’92, 1992.
3. Bass, L., and al., A Metamodel for the RuntimeArchitecture of an Interactive System, The UIMS ToolDevelopers Workshop, in SIGCHI Bulletin, vol. 24(1),1992, p. 32-37, ACM Press.
4. Bass, L., Clements, P., Kazman, R., SoftwareArchitecture in Practice, 1998, 452 pages, AddisonWesley.
5. Calvary, G., Coutaz, J., Nigay, L., From Single-UserArchitectural Design to PAC*: a Generic SoftwareArchitecture Model for CSCW, in Proceedings ofCHI’97, 1997, p. 242-249, ACM Press.
6. Coutaz, J., Bérard, F., Carraux, E., Astier, W., CoMedi:Using Computer Vision to Support Awareness andPrivacy in Mediaspaces, in Proceedings of CHI’99,1999, p. 13-14, ACM Press.
7. CoVitesse system, http://iihm.imag.fr/demos/CoVitesse/
8. Dewan, P., Architectures for CollaborativeApplications, in Beaudouin-Lafon (eds.), ComputerSupported Cooperative Work, 1999, p. 169-194, JohnWiley & Sons Ltd.
9. Ellis, C., Wainer, J., A Conceptual Model ofGroupware, in Proceeding of CSCW’94, 1994, p. 79-88,ACM Press.
10.Green, M., Report on Dialogue Specification Tools, inUser Interface Management Systems, EurographicsSeminars, 1985, p. 9-20, Springer Verlag.
11. Graham, T.C.N., Urnes, T., Nejabi, R., Efficientdistributed implementat ion of semi-replicatedsynchronous groupware, in Proceedings of UIST'96,1996, p. 1-10, ACM Press.
12. java, http://www.javasoft.com/
13.Kazman, R., Bass, L., Abowd, G., Webb, M., SAAM: AMethod for Analyzing the Properties of SoftwareArchitectures, in Proceedings of ICSE'94, 1994, p. 81-90, ACM Press.
14.Laurillau, Y., Synchronous Collaborative Navigation onthe WWW, in Extended Abtracts of CHI’99, 1999, p.308-309, ACM Press.
15.Laurillau, Y., Conception et réalisation logicielles pourles collecticiels centrées sur l’activité de groupe : lemodèle et la plate-forme Clover, Ph.D. dissertation,University of Grenoble, France, 2002, 264 pages.
16.Li, D., Muntz, R., COCA: Collaborative objectscoordination architecture, in Proceedings of CSCW'98,1998, p. 179-188, ACM Press.
17.Nigay, L., Coutaz, J., Software architecture modelling:Bridging Two Worlds using Ergonomics and SoftwareProperties, Formal Methods in Human-ComputerInteraction, 1997, p. 49-73, Springer Verlag.
18.Nigay, L., Coutaz, J., A Generic Platform forAddressing the Multimodal Challenge, in Proceedingsof CHI’95, 1995, p. 98-105, ACM Press.
19.Nigay, L., Vernier, F., Design Method of InteractionTechniques fo r Large In format ion Spaces , inProceedings of AVI'98, 1998, p. 37-46, ACM Press.
20.Patterson, J.F., A taxonomy of Architectures forSynchronous Groupware Applications, in Workshop onSoftware Architectures for Cooperative Systems ofCSCW’94, 1994, p. 79-88, ACM Press.
21.Roseman, M., Greenberg, S., Building Real-TimeGroupware with GroupKit, A Groupware Toolkit, inACM ToCHI, vol. 3(1), 1996, p. 66-106, ACM Press.
22.Shaw, M., Garlan, D., Software Architecture:Perspectives on an Emerging Discipline, 1996, 242pages, Prentice Hall.
23.Salber, D., De l'interaction homme-machineindividuelle aux systèmes multi-utilisateurs. Ph.D.dissertation, University of Grenoble, France, 1995, 305pages.
24.Whittaker, S., Nardi, B., Bradner, E., Interaction andOuteracion Instant Messaging In Action, in Proceedingsof CSCW’00, 2000, p. 79-88, ACM Press.
25.Zafer, A., NetEdit: a Collaborative Editor, Master ofScience, University de Virginia, USA, 2001, 82 pages.