Embed Size (px)
Citation preview
This article was downloaded by: [Universitat Politècnica de València]On: 26 October 2014, At: 17:34Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registeredoffice: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK
Journal of Location Based ServicesPublication details, including instructions for authors andsubscription information:http://www.tandfonline.com/loi/tlbs20
Location-oriented coordinationin pervasive environments forcollaborative work scenariosManfred Bortenschlager aa Salzburg Research , Jakob-Haringerstr. 5/III, 5020 Salzburg,AustriaPublished online: 14 Dec 2009.
To cite this article: Manfred Bortenschlager (2009) Location-oriented coordination in pervasiveenvironments for collaborative work scenarios, Journal of Location Based Services, 3:4, 229-248,DOI: 10.1080/17489720903463666
To link to this article: http://dx.doi.org/10.1080/17489720903463666
PLEASE SCROLL DOWN FOR ARTICLE
Taylor & Francis makes every effort to ensure the accuracy of all the information (the“Content”) contained in the publications on our platform. However, Taylor & Francis,our agents, and our licensors make no representations or warranties whatsoever as tothe accuracy, completeness, or suitability for any purpose of the Content. Any opinionsand views expressed in this publication are the opinions and views of the authors,and are not the views of or endorsed by Taylor & Francis. The accuracy of the Contentshould not be relied upon and should be independently verified with primary sourcesof information. Taylor and Francis shall not be liable for any losses, actions, claims,proceedings, demands, costs, expenses, damages, and other liabilities whatsoever orhowsoever caused arising directly or indirectly in connection with, in relation to or arisingout of the use of the Content.
This article may be used for research, teaching, and private study purposes. Anysubstantial or systematic reproduction, redistribution, reselling, loan, sub-licensing,systematic supply, or distribution in any form to anyone is expressly forbidden. Terms &Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions
Journal of Location Based ServicesVol. 3, No. 4, December 2009, 229–248
Location-oriented coordination in pervasive environments for
collaborative work scenariosy
Manfred Bortenschlager*
Salzburg Research, Jakob-Haringerstr. 5/III, 5020 Salzburg, Austria
(Received 17 January 2009; final version received 4 July 2009; accepted 27 October 2009)
Mobile or pervasive environments are inherently characterised by a highdegree of dynamics and frequent changes in the environmental properties.This makes collaborative work of mobile users eminently difficult as thecoordination of their work processes needs to adapt steadily to thesechanging circumstances. As location is one of the most critical changingcontext dimensions, this adaptive coordination and subsequentre-orientation are mostly based on distinctive temporal and spatial objects(the so-called Schelling points). The contribution of this article is to showthe benefit of exploiting the human behaviour of using spatial objects forcoordination (which we refer to as location-oriented coordination).We present an approach for which we implemented the location-orientedcoordination considerations as a coordination pattern embedded in acoordination architecture, which serves as a runtime environment.By adopting this approach in a representative collaborative work scenario(in the domain of emergency management) and by presenting results fromuser tests we show its applicability and benefit.
Keywords: location-oriented coordination; mobile users; collaborativework; information distribution in pervasive environments; presentation ofspatial information on portable devices
1. Location-oriented coordination
Recent developments and technological advances in fields, such as hardware,communication and networking, distributed systems and mobile middleware,embedded systems and sensors, processing and storage of information, materialsand human-computer interaction are leading to an omnipresence of information andservices. The internet and (mobile) telecommunication networks are converging toone vast and ubiquitously available information space accessible through so-calledpervasive environments. The goal of pervasive computing is to create environmentswhere various devices provide unobtrusive connectivity, information, and services allthe time, thus improving human experience and quality of life without explicitawareness of technology. The major claim and challenge at the same time ofpervasive computing is to assist the users in their daily activities as unobtrusively as
*Email: [email protected] paper was originally prepared following the 5th International Symposium on LBS andTelecartography 2008.
ISSN 1748–9725 print/ISSN 1748–9733 online
� 2009 Taylor & Francis
DOI: 10.1080/17489720903463666
http://www.informaworld.com
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
possible (Satyanarayanan 2001). Such daily activities frequently involve coordinated,collaborative behaviours between individuals. Pervasive environments make use ofpervasive computing technology to achieve that vision.
In this work, we primarily focus on group- or teamwork where the team size isaround 20 members or less. This is an average number where teamwork can bebeneficially conducted (Borghoff and Schlichter 2000). Well-coordinated activitieswithin such groups are a key factor for effectiveness. We concentrate on one facet ofcoordination in pervasive environments: coordination of activities based on spatialinformation. People unaware of a location naturally orientate themselves with thehelp of particular and distinct objects (Sorrows and Hirtle 1999). This is also referredto as ‘focal’ or ‘Schelling points’ (Schelling 1960) in time and space. We exploit thisconcept for developing a coordination pattern that shall support people indecision-making and coordination of activities in collaborative applications inpervasive environments.
In this article we propose the location-oriented coordination (LOC) concept thatcan improve collaborative activities of mobile workers in pervasive environments.For this, we describe a coordination architecture that is exploited as the underlyinginfrastructure. The LOC concept is implemented as a coordination pattern that isdeployed and executed in the coordination architecture, which serves as a runtimeenvironment. Results of user tests in the domain of emergency management (EM)show the applicability and benefits of our approach.
The article is structured as follows: we present considerations about coordinationin pervasive environments in Section 2. Section 3 discusses relevant related workinitiatives. We present the used coordination architecture for pervasive environmentsin Section 4. The following Section 5 introduces the concept of LOC. Section 6 givesan introduction to the domain of EM as a preparation for Section 7 which givesdetails about the evaluation. This evaluation presents a discussion about theapplicability of the approach and also an analysis of the feedback from user tests.The last section concludes with the main outcomes and contributions and givesdetails about further work activities.
2. Coordination in pervasive environments
In coordination theory, Malone and Crowston defined coordination as the ‘act ofmanaging interdependences between activities’, where coordination managementcomprises four entities: goals, actors, activities and interdependences (Malone andCrowston 1994). In our work, we slightly amend this concept by adding alsoconstraints as we recognised that interdependences are always constrained by specificaspects – such as mutual access to shared resources. These amount to the five entitiesof coordination. Particularly, collaborative activities in pervasive environments arehighly constrained due to the inherent dynamics and the resulting necessity ofadaptations (Satyanarayanan 2001). Systems for applications in pervasive environ-ments need to be able to adapt to changing context. This ability is one of theadded-values of pervasive computing applications (Schilit et al. 1994, Schmidt et al.1999). Dey et al. (1999) defined context as any information which can be used tocharacterise the situation of an entity, where an entity is a person, place or an objectthat is considered relevant to the interaction between a user and an application,
230 M. Bortenschlager
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
including the user and the application themselves (Dey et al. 1999). Hence, there is abroad variety of possible context parameters. In Abowd et al. (1999), the authorspropose that for pervasive environments these parameters shall be classifiedaccording to primary and secondary context types, where the primary ones (actingentity, activity, location and time) cause the greater effect and should mainly beconsidered for characterising situations.
Coordination, furthermore, is intuitively dependent on communication: withoutcommunication coordination is not possible. This has also been argued by Klein(1998) and has empirically been examined in aircraft crew communication andcoordination (Kanki et al. 1989). Pervasive environments are dynamic andcommunication systems are prone to frequent disconnections. Tightly coupledcommunication is inappropriate. Systems for coordination in pervasive environ-ments need to provide appropriate communication means in a highly de-coupledmanner to build the basis for coordination.
According to Malone and Crowston (1994), the key to improve coordination isan effective resolution of the interdependences. In order to accomplish this, usuallycoordination rules are established and applied. These rules take into account the fiveentities of coordination as stated above. Systems supporting coordination need toencapsulate coordination logics which embody the architectural glue between thecommunication infrastructure and the applications. Moreover, it has been observedthat several types of coordinative behaviours are highly similar, often reoccurring,and typical for specific situations (Deugo et al. 2001). Consequently, various suchcoordination rules and strategies can be subsumed to so-called patterns, whichprovide standardised means to assist in these situations.
By coordination in pervasive environments, we take the abstract and generalconcepts of coordination theory (as discussed above) and concretely instantiate themfor the specific case of collaborative applications in pervasive environments. For this,we needed to take into account the specific characteristics of this application area.After revising related work in the following section, we show how we integrated andapplied the considerations presented in this section into a coordination architecturefor pervasive environments in Section 4.
3. Related work
In the previous section, we discussed three main building blocks as essential elementsof coordination in pervasive environments, namely context, communication andcoordination models. Below, we discuss related work efforts for each of theseelements.
3.1. Data models for context
The work around context-sensitive data structures, CSDS, (Payton et al. 2004)presents a relevant approach of data models capable of context processing. TheseCSDS provide a unified interface to contextual information. Context items aredefined as pieces of data generated by agents. Every agent can also generate its ownCSDS describing his current context arbitrarily. We believe that it is more beneficialto specify a certain structure a priori in order to facilitate interoperability between
Journal of Location Based Services 231
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
heterogeneous systems. Similarly, Julien and Roman (2006) introduced the notion ofviews denoting an individualised and egocentric projection of all data available toone specific reference agent. This is a beneficial concept as the large amount of datacan be tailored to the real specific needs of an agent according to its current context.Such mechanisms should be provided by a data model for context in order to addressspecific requirements of requesting entities. Schelfthout et al. (2005) defined viewsbased on the network connectivity within a MANET specifying context as theconfiguration of participating nodes and the corresponding available data. They useObjectPlaces as the coordination middleware to manage context which is subject tochange whenever information on reachable nodes, or the set of reachable nodes itselfchanges. de Freitas Bulcao Neto and da Graca Campos Pimentel (2005) presented auseful concept to model context. They split the context information up into variousrelevant context factors modelled as pre-defined fields. The work, however,particularly focuses on the context modelling by using well-defined and establishedontologies for e-learning scenarios.
3.2. Communication: decentralised tuple spaces
Components and entities in pervasive environments are subject to steady change anddynamics. In order to provide acceptable services to users, such systems must becapable of spontaneous interoperation. From this, Kindberg and Fox derived thevolatility principle (Kindberg and Fox 2002) stating that pervasive systems should bedesigned on ‘the assumption that the set of participating users, hardware, andsoftware is highly dynamic and unpredictable. Clear invariants that govern the entiresystem’s execution should exist.’ This observation and the related characteristics ofpervasive environments – such as frequent disconnections – favour a decoupled andopportunistic style of communication (Mascolo et al. 2002). By decoupled we meanthat computation needs to proceed even if entities are disconnected. Opportunisticrefers to the fact that connectivity has to be exploited whenever it becomes available.The synchronous communication paradigm supported by many traditionaldistributed systems has to be replaced by a new asynchronous communication style.
The tuple space paradigm favours data-oriented and asynchronous communica-tion. Linda (Gelernter 1985) was the first system using a central tuple space in orderto store and distribute data, which does not provide the flexibility as required bypervasive environments. Only later Linda implementations considered multiplespaces (Hupfer 1990) but still in stationary networks. LIME (Picco et al. 1998) is asystem that was built specifically to address mobility in a physical (i.e. devices) andlogical (i.e. software agents) sense. In LIME, each host carries its own space. As soonas hosts are connected the available spaces are consolidated to a space federation.The main drawback of LIME is that in a network only one primary copy of a tupleexists leading to dependence. The Klaim model (DeNicola et al. 1998) also supportslogical mobility or code migration, using locality-aware tuple spaces to provide ameans for interprocess communication. Klaim processes located at a given locationcommunicate through a co-located tuple space. There is no transient sharing amongseveral tuple spaces but a process can interact with any tuple space by identifying itslocality. An integral part of the Klaim model is also the specification of processmigration but instead does not explicitly address tuple replication issues.
232 M. Bortenschlager
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
3.3. Coordination models
Proposals for architectures or models for coordinative systems are sporadicallyavailable as in Ciancarini (1996) and Klein (1998). Klein described the interplaybetween communication, coordination and collaboration. He argued that commu-nication is necessary for coordination which improves collaboration and by this,communication enables collaboration. Ciancarini stated that coordinative processescan always be described by the triple of {E, M, L}. {E} represents the coordinableentities which in our approach would be the actors. {M} stands for the coordinationmedia (i.e. communication channels), which serve as connectors between the entitiesand facilitate communication (a tuple space-based communication infrastructurecould represent {M}). {L} is referred to as coordination laws defining how theinterdependences can be resolved. This is highly related to what coordination theoryproposes. Various mechanisms for resolving interdependences can be subsumed topatterns.
Patterns and related concepts covered in this article have also been intensivelyinvestigated within software engineering (Gamma et al. 1995) or software agentresearch (Nwana et al. 1996). Moreover, patterns have often proven to be helpfultools in order to tackle similar and reoccurring problems in other domains, such as inarchitecture (Alexander 1979) or business process modelling (van der Aalst et al.2003). In Dustdar and Hoffmann (2007), an approach is presented that tries to derivecollaboration patterns by analysing ad-hoc business processes in order to gain morein-depth knowledge and to optimise processes.
4. A coordination architecture for pervasive environments
We argue that in order to support collaborative applications in pervasiveenvironments an appropriate coordination architecture needs to take into accountthree elements: (i) an appropriate data model that can model the five entities ofcoordination (as introduced in Section 2) and allows for context processing, (ii) aflexible communication infrastructure that can tackle the characteristics of pervasiveenvironments and (iii) coordination mechanisms that comprise rules or patterns toresolve interdependences.
In this section, we present a coordination architecture for pervasive environmentsand provide details about how we address the three elements. In particular,Section 4.1 deals with the context data model, Section 4.2 with the tuple space-basedcommunication infrastructure and Section 4.3 with coordination patterns denotingour coordination mechanisms. This coordination architecture serves as the basis andthe runtime environment for the main contribution of that work: the LOC conceptthat is introduced and evaluated in later sections. It is essential, however, tounderstand the three elements of the coordination architecture and their interplay inprinciple.
4.1. The W5 context model
The volume and diversity of occurring data in pervasive environments require for anexpressive, yet simple model for representation. Such a data model must providemeans to model and combine information coming from heterogeneous sources and
Journal of Location Based Services 233
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
should account for adaptation to context and incomplete information. Our proposedcontext model considers that diverse data can be expressed by means of a five-fieldsdata construct (Who, What, Where, When, Whatabout): ‘someone or something(Who) does/did some activity (What) in a certain place (Where) at a specific time(When)’ Details about the W5 model can be found in a different publication(Bortenschlager et al. 2009).
Subsequently, each field is described in more detail. The examples used in thefollowing passages are oversimplified and mentioned for clarification. Each fieldcontains an optional type classifier and the mandatory value. The used notation is:type:value or value if no classifier is given or necessary. The representation of thefive fields in the concrete implementation of the coordination architecture is acomplex structure of associated objects.
The Who field associates a subject to a data item and depicts an actor. Who mayrepresent a human being, the ID of an agent responsible for a data source (e.g. theID of a sensor or an RFID tag), or the name of a web resource. The Who field alsocontains information about the type of an entity. Examples for valid entries for thisfield are firefighter:Smith or tag:tag#567.
TheWhat field describes the activity performed by an actor. This information caneither come directly from the data source (e.g. a sensor is reading a temperaturevalue) or be inferred from other context parameters (e.g. an accelerometer sensor canreveal that the user carrying it is running) or it can be explicitly supplied (e.g. contentof a web page). The information contained in this field is at least a description of thetype of the activity and information about the activity itself. For example, validentries for the What field are reading: ‘Emergency Instructions Version 1.1’,meeting:control room or read temperature:23.
The Where represents a location and thus represents a spatial description. In themodel the location may be a physical point represented by its geographic coordinates(e.g. longitude, latitude), a geographic region, or it can also be a logical place. Webresources, for instance, are also expressed as logical places by using an URI. Inaddition, context-dependent or relative spatial expressions like here or radius:300mcan be used for context-aware queries.
The When field describes a time, a time range or time periods. Valid examples are2006/10/17,1753, range:1600-1715 or periode:6h. Also in the case of the Whenfield, context-dependent expressions (e.g. now, yesterday, later:2h) can be definedand used for context-sensitive querying.
Pragmatical considerations led us to the decision to introduce a new field holdingmeta-information about tuples: the Whatabout field. It contains information, such asa universally unique identifier (UUID), a timestamp when the tuple was created, inwhich type of potentially different repositories it is stored, whether changes shouldbe kept in a history, if it is intended to be kept only locally on the device or thestrategy about how to distribute (i.e. replicate, see Section 4.2) this data item.
An example should clarify the concepts of the W5 model: Firefighter Smith iscurrently running on an emergency site. A software agent on his GPS-enabledportable device periodically (e.g. every 10 s) creates a tuple corresponding to hisactivity and position. The position is stored according to the GPS National MarineElectronics Association (NMEA) format. This example is illustrated in Figure 1.
The W5 concept can be exploited for context-sensitive coordination along fourdifferent dimensions of context (actor, activity, space and time), which – as they are
234 M. Bortenschlager
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
accordingly represented in the data model – can be availed and combined as neededto address the specific context of an actor in a particular situation. By adopting theW5 model, we provide a way to semantically combine diverse data from differentsources into one data model, which then can be exploited to provide additional andcontext-dependent information to the user. It provides a well-defined interface toaccess heterogeneous data items for other components of an infrastructure such asour proposed coordination architecture.
4.2. Tuple space-based communication
As argued in Section 3.2, tightly coupled communication is inappropriate inpervasive environments. Hence, we designed the communication infrastructure inour coordination architecture according to the distributed tuple space paradigm.Due to the inherent (spatial, temporal and referential) de-coupling mechanisms intuple spaces, this paradigm is very appropriate as a middleware technology fordeveloping mobile or pervasive information systems (Murphy et al. 2006). Weadopted the W5 context model (Section 4.1), which per se is a general concept andimplementation independent. In our coordination architecture, the W5 model isimplemented based on the tuple space paradigm where the data items are representedas W5 tuples. Such tuples can be addressed and retrieved by their contents (Gelernter1985). This adds additional flexibility as addresses or IDs need not to be known.Tuples are identified via associative matching by using the arity and type signatureinformation. The classic operations to interact with a tuple space (i.e. in(), out()and read()) are similar in our tuple space implementation.
The main difference between the classic Linda system and our tuple spaceapproach, however, is that we implement a decentralisation and distribution of severalspaces throughout the network of participating entities. Thus, our tuple spaceimplementation complies with peer-to-peer (P2P) design considerations. We differ-entiate between two sub-elements within our tuple space element of the proposedcoordination architecture: (i) the local tuple space, and (ii) tuple distribution. Withrespect to the first sub-element, every involved peer interacts directly with its ownlocal tuple space only. Application programmers do not have to deal with theprovision of tuples to or collection of tuples from remote peers. This distribution oftuples is entirely handled by our coordination architecture implementation (i.e. thesecond sub-element). Through rich replication mechanisms, the local tuple spaces aremerged to a ‘global federation’ of all tuple spaces of available, i.e. connected, peers atthe time.
Replication management has to provide mechanisms for all replicas of the samedata item to converge after an update into a mutually consistent state again(Borghoff and Schlichter 2000). Replica control algorithms are available that
Who: firefighter:Smith What: running:7kmh Where: nmea:$GPRMC,191419,A,4505.4690,N,01350.7140,E,0.0,0.0,170807,0.4,E,A*19 When: periode:10s Whatabout: UUID:8403184933;ts:1173085856;space:generic;history:false;local:false;strategy:1
Figure 1. W5 tuple example.
Journal of Location Based Services 235
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
guarantee a certain level of mutual consistency among replicated tuples. We adopt an
optimistic algorithm based on version vectors (Parker et al. 1983). Each replicated
tuple is associated with a version vector V. In the original proposal by Parker et al.,
the size n of that vector corresponds to the number of replicas (i.e. the number of
peers storing one copy) of that tuple. Whenever a tuple � is changed this is reflected
in the version vector and the other (reachable) tuples and their corresponding vectors
are updated. In its simplest form, at peer j the ith vector entry vi counts the number
of changes in � originating from peer i. Additional information can be tracked too
and appears to be reasonable in most cases. Thus, in our coordination architecture
this algorithm is changed such that we do not only count the updates but store the
time (in form of a time stamp) when the update happens. By counting the time stamp
entries per replica we can infer the number of updates processed on each tuple.A vector V of a replica is said to dominate another vector V0 of a replica of the
same tuple, if this expression holds true:
8i 2 f1, . . . , ng : �i � �0i
If the vector V dominates V0 then in V more updates arrived. Thus, V0 represents asubset of V and can easily be adapted. Two vectors are said to conflict if they are
different and neither dominates. This is the case when the replicas have received
different updates. Then the replication logic has to deal with it. The example depicted
in Figure 2 illustrates the procedure as proposed by Parker et al. (1983): a network
consists of three peers {P1, P2, P3} each holding one replica of a tuple, which is
denoted by the initial version vector associated with that tuple: hP1:null,P2:null, P3:nulli. No updates have been conducted yet. Let us assume that a
partition happen due to any reason into two groups: {P1, P2} and {P3}. Now, two
updates happen in the first group (indicated by two plus signs in Figure 2 underneath
the corresponding peer P1). Then, peer P2 leaves the first group and joins peer P3.
Figure 2. A version vector example.
236 M. Bortenschlager
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
At this time two updates happen concurrently: one in the first group (again by peerP1) and one in the second group (by peer P3). Finally, both groups rejoin resulting ina conflict of the two version vectors: hP1:{TS11,TS12,TS13}, P2:null,P3:nulli and hP1:{TS11,TS12}, P2:null, P3:{TS31}i. This conflict needs tobe resolved by appropriate replication and consistency logics within the tuple spacewhere in our implementation each of the different fields of the W5 tuples need to becompared and updated accordingly. The authors are aware that it might well happenthat some inconsistencies cannot be resolved such as two concurrent updates ofexactly the same field data. In that case, errors may occur and the pragmaticapproach to solve this problem is taking the most recent change on the tuple �i. Theother, older datum is kept in a separate tuple �i�1 which is stored in the same tuplespace and related to �i as a ‘historic’ tuple.
Building up on the concept of version vectors, different replication strategies aredeployed. We differentiate between two base strategies: (i) full replication, and(ii) context-dependent replication. The former is ‘expensive’ in terms of usingnetwork resources and the potential danger of inconsistencies regarding the contentsof the distributed local tuple spaces. Some information, however, needs to be fullyand permanently replicated such as address information (i.e. how to address theother peers in the network). The latter is much more resource-sensitive, moresophisticated but also more complex to design and implement.
Both strategies exhibit two further policies: push (event-based) and pull(on-demand); and can exchange one or more tuples in each replication transaction.The resulting four replication mechanisms are described as follows:
(1) Full Replication – Push. One or more produced tuples are sent from one peerto all currently connected peers. If not already existent at the remote peersthe, tuple(s) is/are stored there. Otherwise all fields are updated according tothe new values. This strategy usually is the reaction to an event. Remote peerscan register for such events and get the corresponding tuple when this eventfires.
(2) Full Replication – Pull. Peers can explicitly and on demand ask other peers forone or more tuples which are then transferred to the querying peer.
(3) Context-dependent Replication – Pull. Peers dependent on the describedcontext request certain fields of tuples. The described context does notnecessarily have to be their current context but can be any context which isnecessary. The context is described by the fields of the W5 model, hence inprinciple along four dimensions (actor, activity, space and time) plus meta-information.
(4) Context-dependent Replication – Push. Peers can also subscribe to events andget required fields of tuples event-based and in a context-dependent way.The subscribers define the event, the particular context, and the informa-tion (contained in fields) they are interested in. The peers that can providesuch information and listen to the requested events deliver this informa-tion as pushed tuples as soon as an event related to the defined contexthappens.
When deploying the tuple space-based communication of our coordinationarchitecture, the programmer can decide which strategies suit her requirements bestand can choose them accordingly.
Journal of Location Based Services 237
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
4.3. Pattern-based coordination
When working on something, building something or encountering problems, peoplenaturally do not tackle this by steadily inventing new solutions but recall similaractivities or problems which had already been solved. As this was successful once, theessence is applied again. This expert behaviour – i.e. thinking in problem-solutionpairs – is roughly what is described as a pattern (Buschmann et al. 1996). Patterns canhelp to exploit the collective experience of experts. Every pattern embodies a well-proven solution to a specific, recurring problem. This concept is domain-independentand has been explicitly reported in architecture (Alexander 1979), economics (Etzioni1964), social interaction (Newell and Simon 1972) and computer science; inparticular in software engineering (Gamma et al. 1995, Buschmann et al. 1996),middleware design (Freeman et al. 1999) and agent technologies (Deugo et al. 2001).By abstracting from specific problem-solution pairs and extracting common factors,generic patterns can be generated.
Also with respect to coordination, it has been observed that certain coordinationproblems are recurring and share many similarities (Deugo et al. 2001,Bortenschlager et al. 2006). Hence, the third element of the coordination architectureis a component that allows the deployment of coordination pattern implementations.Hence, the pattern-based coordination component is a runtime environmentfor coordination patterns. Pattern implementations can be taken from a library ofcoordination patterns or can be implemented on demand and executed in thecoordination architecture in order to solve particular coordination problems. Sincethe five entities of coordination occur in any coordination activity, also thecoordination patterns address them. With the internal coordination rules of a patternthe essential coordination entity is resolved: the interdependences. Eventually, eachpattern provides a solution to the given coordination problem.
The concept of LOC can be modelled as one such pattern. The following sectiongives details about this concept. Examples for further coordination patterns aresupervisor/worker or meeting. Others were proposed by Bortenschlager et al. (2006).
5. Location-oriented coordination
The concept of LOC describes the fact that people naturally use particular points intime and space in order to coordinate their activities. Such so-called ‘focal points’ (oralso Schelling Points) were described by Game Theorist Thomas C. Schelling (1960).During several experiments, Schelling discovered that people in order to approachmutually beneficial results tend to use very characteristic spots in time and space,which also works without direct communication. For instance, Schelling askedpeople where they would meet a stranger in New York while the stranger also wantsto meet them but they cannot communicate. A substantial majority answered: ‘underthe clock in Grand Central Station at noon’. As this specific concept of(location-oriented) coordination is a natural human behaviour, it is intuitive andbroadly accepted. It was our motivation to improve IT-supported collaborativeapplications in pervasive environments by adopting this concept and implementing itwithin a computational system. By interacting with this system, mobile users shall besupported in their activities by the embedded algorithms which provide themechanisms to resolve the interdependences related to LOC.
238 M. Bortenschlager
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
5.1. Formal definition of the LOC pattern
In order to formally describe the LOC pattern, we follow a similar approach that istaken to describe design patterns for software development (Gamma et al. 1995). Weuse the following properties: name, context, problem, solution, implementation,known use and related patterns.
NameLOC pattern
ContextResponsible entities or authorities need to reason or decide upon certain facts. In manycases – particularly in pervasive environments – available resources are volatile andfrequently changing. As a result, information is incomplete or only an excerpt of thewhole information present, which may lead to low-quality or wrong decisions. In thecontext of coordination, most of general decision-making processes imply reasoningabout spatial information and are often based on distinctive spatial objects (Schellingpoints) or on map-based representation of spatial information.
ProblemThe lack of ‘global’ knowledge may lead to wrong or suboptimal decisions or outcomes,respectively. Coordination of activities cannot be conducted effectively.
SolutionTo assist people in their decision-making processes, a (visual) representation of theposition related to time of relevant objects or people is provided. This implies thatdistinctive spatial objects are used to improve the coordinative activities in dynamic,pervasive environments.
ImplementationFigure 3 depicts a UML class diagram of the LOC pattern. The Schelling point classaggregates several Constraints. These are sub-classed by specific types of constraints,such as Location, Capabilities, Time or Activity and can be extended on demand. Themain coordination logic is encapsulated in the Actor class that calculates dependencesout of the constraints, composes, proposes and finally accepts Schelling points.
Known useIntuitively, people steadily use spatial objects, for instance, to determine a meetingpoint, i.e. using spatial information to coordinate their activities. Although, the conceptof wayfinding through landmarks has been proposed years ago (Sorrows and Hirtle1999) it only very slowly finds its way into today’s navigation systems.
Related patternsNo concrete related pattern is known. A similar approach is coordination viaenvironmental cues (Obermair et al. 2006), where entities are coordinated by thepossibility of reading present cues in the environment or ‘tagging’ spatial objects withcertain cues for others.
5.2. Structural and behavioural aspects of the LOC pattern
Structural and behavioural aspects of patterns are often described using the UMLnotation. Figure 3 shows the structure of the LOC pattern by using a UML classdiagram. The pattern consists of three core entities: the classes Actor, Schelling pointand Constraint. The Constraint class is sub-classed by the different types of possibleconstraints, which can be extended on demand. A Schelling point aggregatesConstraints.
Most of the logic necessary for this coordination pattern is encapsulated in theActor class. Figure 4 gives an overview of the behaviour of that pattern. In order tocreate and subsequently exploit a Schelling point an Actor actor-1 must invoke
Journal of Location Based Services 239
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
the method calculateDependences(), which checks the various Constraint
objects. Such a dependence could be represented by an Actor who is assigned an
Activity for which he needs a certain Capability. The Actor might require a tool
(toolNecessary¼true) in order to execute the activity. If the user has access to
such a tool, which is modelled in the Actor class, this dependence can be resolved
successfully. A further dimension could be added to this example if the Actor
requires a tool at a certain location during a particular time span. In that case one or
more Schelling points need to be composed and proposed to other Actors (see also
sequence diagram illustrated in Figure 4).
Figure 4. Sequence diagram of the LOC pattern.
Figure 3. Class diagram of the LOC pattern.
240 M. Bortenschlager
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
By calling composeSchellingPoint() or composeSchellingPoints()one or more Schelling point objects are instantiated. Then actor-1 can proposesuch a Schelling point to other Actors actor-n (proposeSchellingPoint()).actor-n can then either propose other Schelling points or accept the original one(acceptSchellingPoint()). The decision about acceptance or rejectionhappens again in the main Actor class by evaluating the constraints. If thedependences can be resolved (e.g. the tool from the example above is available at therequired location and time) a proposed Schelling point is accepted. After acceptance,all involved Actors start executing the related tasks (execute()).
It is important to mention that this LOC pattern is independent from anyimplementation. In general, patterns can be deployed either by using the program-ming libraries of available reference implementations of patterns, or by implement-ing specifications similar to the way design patterns are exploited in softwareengineering (Gamma et al. 1995). We implemented the LOC pattern for deploying itin our coordination architecture. For this, all the data objects are realised as W5tuples and kept within the distributed tuples spaces. Communication (e.g. betweenthe Actors when the proposeSchellingPoint() method is invoked) isexclusively conducted by the W5 tuple replication via the distributed tuple spaces.
The five entities of coordination theory are reflected in this approach as follows:actors (Who of W5), activities (What of W5) and constraints (When and Where ofW5) are covered by the W5 context model. The interdependences are resolved by thecoordination patterns. Goals are implicitly given by the activity or the application.
The application and evaluation of our implementation is presented in thefollowing sections.
6. Application to emergency management
An emergency is a broad term which includes rapid natural and man-made hazardscontaining avalanches and railway accidents, drought, famine or disease and disasterevents that have a different time lapse such as floods or forest fires. Emergencies havesevere consequences. The EM subsumes the activities of emergency operatorsnecessary to prevent and relief such situations. To increase efficiency operators aredivided into units, where the smallest unit in EM is the team with a size usually notlarger than 12 members working collectively on one task. Several teams are presentand depending on the dimension of the emergency a complex configuration of teamsof different organisations may exist. Close collaboration happens mainly withinteams; thus, representing a mobile, collaborative work environment and anappropriate area of application for the coordination architecture.
In the EU research project WORKPAD (see http://www.workpad-project.eu) we are developing a mobile geographic information system (GIS)for pervasive environments. The coordination architecture presented in this article isexploited for the realisation of this GIS application. We demonstrate the appropri-ateness of the approach and an application of the LOC pattern to an EM scenario ina pervasive environment. Although EM represents a very well-suited example, weemphasise that the approach presented in this article could be applied to anycollaborative work scenario in pervasive environments where coordination based onspatial objects is relevant.
Journal of Location Based Services 241
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
6.2. A typical scenario
One of the partners in the WORKPAD project was a user organisation, namely theCivil Protection Department of the Region of Calabria in Italy (Protezione CivileCalabria). Together with them we constructed several realistic scenarios that helpedto analyse and evaluate user requirements. An example is the following:
A group of five firefighters (four team members plus one commander) needs to get anoverview of an affected area after an earthquake in a city. They do not yet know if thereare still people in the area who may potentially be hurt. In this case, they mustimmediately rescue them, give first aid and make sure that necessary subsequent actionsare initiated (such as evacuation from the still dangerous area). To cover a greater areaat a time the firefighters spread out. Suddenly, one firefighter detects close to him aburning lorry. After first investigations, he notices that there is still someone inside. Heimmediately notifies his colleagues by way of the commander. The commander needs tofind out the location of the car and which tools and other team members are necessaryas they all have different trainings and capabilities. One firefighter is already occupiedby giving first aid to other wounded people. Although the other members are engagedtoo, their current tasks are of lower priority. As one possesses a portable fireextinguisher among his equipment and the other is specifically trained on first aid ofburns. Both are notified to arrive at the burning car. The first firefighter who detectedthe car is already on site. The commander follows. Soon, all four firefighters are presentand start conducting their activities. In parallel, the commander needs to find out wherethe closest vehicle is located to evacuate the rescued person. As soon as he knows he cancontact the responsible authorities to send this vehicle to his current position. The carshould arrive as soon as first aid is finished and the person is prepared for the transport.When all these activities are completed the group of five firefighters continues investi-gating the area.
This and other scenarios are used in the project WORKPAD for applying themobile GIS that is based on the presented coordination architecture and exploits theLOC pattern. The following section discusses evaluations of this application.
7. Evaluation
In this evaluation section we cover two things. First, we discuss the applicabilityof the coordination architecture and the LOC pattern to emergency scenarios, suchas the one presented above. Second, we present details from user tests conductedwith the system.
7.1. Applicability of the LOC pattern
Every actor is equipped with a portable device, which can also be only passivelycarried around. These devices comprise computational capabilities, wireless com-munication means and a location sensor. According to the five entities ofcoordination theory, the goals of the emergency scenario presented in Section 6would be the desired outcomes of the specific task, which in our example is on theone hand to get an overview of an affected area and on the other hand to rescue andevacuate all present people. The actors are the five firefighters, occurring vehicles andother emergency operators on site. The activities are represented by the currentand planned tasks of the actors as they are, in general, following specific actionplans. Their specific capabilities, their needs, and in particular their positions at
242 M. Bortenschlager
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
specific times would be modelled as constraints. Also, the position of vehicles, forinstance, would be constraints. The interdependences are related to constraints andshow that one firefighter cannot conduct one activity he is not trained for or he is notcapable of. Team members are interdependent as, for instance, there is a certainhierarchy and as they are spatially distributed and not available all the time. Also,different tasks are interdependent in the sense that they may have different prioritiesor the outcome of one task is input for another. The rules for resolving theseinterdependences are encapsulated in the logic of the LOC pattern.
The technical basis for making use of the LOC pattern is provided by thecoordination architecture, which is presented in Section 4. All the occurring artefacts –such as representations of objects or persons in the system such as firefighters orresources – are modelled according to the W5 data model. These are all reflected astuples in the tuple space federations in our implementation. Figure 5 illustrates ascreenshot of the concrete EM scenario and the corresponding GIS application wedescribed in this section. Diamonds represent emergency operators; in our casefirefighters. The diamond with ID-3 represents the one that was found in the burninglorry.
With respect to the distributed tuple space-based communication element of thecoordination architecture, in the mobile GIS we used two types of spaces that are
Figure 5. Screenshot of the intended EM application.
Journal of Location Based Services 243
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
available on each node in the network: one local space that keeps addressinformation of the involved nodes (i.e. portable devices) and one local space thatcontains the application information which is mostly geographic information. All thetuples are stored and managed in the W5 format.
Also replication of new or modified tuples is accomplished in a decentralisedmode, which implies circumventing the dependence on and drawback of a centralisedsingle point of failure (such as a server). Tuple replication is deployed according tovarious strategies. Address information, for instance, is always fully replicated at alltimes to all nodes. This is necessary because all nodes need to know how to reach theothers. Full replication is feasible in this case because address information iscomparatively lightweight – otherwise we could run into scalability problems. Other(geographic) information can be replicated in a context-sensitive manner. Location orstatus updates are only replicated to those nodes that really require that information.
7.2. Feedback from user tests
Within the course of WORKPAD two user tests were conducted. We investigated theuser opinion, which in Usability Testing comprised of the sub-metrics satisfaction,usefulness and ease-of-use. Studies in Usability Testing show that already five testusers discover 80% of the problems (Virzi 1992). According to this work, more usersdo not generate significantly more insights. More recent works (Lindgaard andChattratichart 2007) discovered that further factors are important to achieve thisproposed level of 80% discovery of problems. These factors are carefully choosingexperienced and cooperative users and a careful and realistic definition of thequantity and quality of the tasks the users are asked to execute. Respecting theserecommendations leads to the fact that a low number of test subjects suffices. Wedesigned our tests respecting these recommendations.
The first test was a Web-based online test. A mock-up for the mobile GIS wasdeveloped that showed the functionalities in principle. This test was used in order tobetter understand the users’ needs and to get feedback whether the requirements havebeen understood correctly. The advantage of such mock-up tests is that developersand system engineers get very early feedback about the intended component withouthaving programmed anything potentially suboptimal. The mock-up could be browsedon screen and the users were asked to fill in a subsequent questionnaire.
Thirteen users participated in that test. Nine users were from the Calabrian CivilProtection Department, one from ANAS S.p.A., one from the Department ofNational Civil Protection, one from the Centre of Studi Peter of the Calabrian CivilProtection Department and one from KRONOS (Calabria/Academia Kronos). Intheir daily work, these test users execute tasks, such as processing meteorologicaldata, processing climate data, management activities, coordination of the risk andcrisis management sectors, logistics, hydrogeological risk monitoring or riskprevention. Of these 58% were male and 42% were female; 75% were between 31and 45 years old, and 25% between 46 and 60.
The main results of the mock-up test regarding the mobile GIS application aresummarised as follows: 85% of the users claimed that such an application is relevantand useful for their daily work. Ten users regarded the interface as comprehensiveand intuitive. The indication of the current location of relevant persons or objects in
244 M. Bortenschlager
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
real-time is for 38% of all testers very useful and for 46% useful. Other functionalityof the mobile GIS was also examined. The presentation of geographic informationsemantically grouped into layers is for seven testers very necessary and for fournecessary. The possibility of creating, annotating and modifying relevantpoints-of-interest is for six testers very useful and for five useful.
Also an interesting fact is that one-third of the users claimed that they need toactively coordinate activities with colleagues. Three users, moreover, stated that amobile GIS is very useful for coordination activities; seven consider it as useful. Onlyone user mentioned that it seems to be impossible to visually coordinate by a sharedmap and shared geographic information without any audio communication.
The second test within WORKPAD was a live test with eight users using alreadya real functional prototype of the mobile GIS. The users had to execute realistic tasks(similar to the introduced scenario above) and for this use the software. In general,the feedback was positive. All users agreed that the software – if stable and matureenough – could support them in their daily work. The screen design of the realprototypes could be improved (‘more attractive’). Most of the users stated that theycould handle it without major difficulties and it is easy to use. The users appreciatedthe ‘position monitoring’ and the possibility of real-time information exchange. Asfields of improvements one outcome was that the used icons should be bigger. Alsocolours are significant. It is important to stick to the colour codes used by anemergency organisation and to be consistent in that usage. Finally, some usersstated, that it is essential that the software updates information fast and reliably. Ifonly unreliable information is available, it is better not to present it as it may distractor confuse the operator, which might lead to wrong decisions.
Both user tests gave us very important feedback. To sum up the examinedusability testing metrics, usefulness of the mobile GIS for EM was assessed with thehighest values. Satisfaction offers room for improvement. There were, for instance,some functions missing that users expected – such as a scale and the correct usage ofcolours. Ease-of-use was the most criticised metric but it is also the easiest to correct.This, for example, was related to unintuitive menu behaviour and unconventionalusage of terms.
It is natural that users, who are not system engineers and hence not familiar withinternal technical details, judge what they see and experience. Hence, it is difficult toassess the benefits of system internal specifics (such as mechanisms to exploitcoordination patterns or tuple space-based communication) as users do not directlyexperience these. However, if users feel comfortable with a software system and donot complain about performance problems, we can deduce that the technicalapproach is well applicable. The investigated meta-metric user opinion about themobile GIS application of WORKPAD is high, which we could show with our usertests. From the results we conclude that the LOC concept technically deployed as apattern in our coordination architecture is well suited for collaborative workscenarios in pervasive environments such as in EM.
8. Conclusion and further work
In this article, we showed that the concept of LOC based on Schelling points can bebeneficially applied to mobile, collaborative work scenarios. We embedded this
Journal of Location Based Services 245
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
concept as a coordination pattern in our implementation of a coordinationarchitecture that addresses specific requirements of pervasive environments. Weevaluated the applicability of this approach in the domain of EM. Realisticcollaboration scenarios could be modelled in a beneficial way respecting andexploiting the concepts of coordination theory. As a result of our user tests, the useropinion metric about the system is considerably high. Users clearly see the resultingbenefits – such as more effective collaboration if the position of relevant persons orobjects can be presented in real-time. From this we conclude that the presented LOCconcept based on Schelling points can be beneficially applied to collaborationscenarios and by this delivers added-value to users in pervasive environments.
Further efforts will be invested by conducting more system tests. The behaviourof the various replication strategies will be examined in more detail. In particular, sofar we assumed a group size of less than 20 members, which is realistic for mobilework environments. The system behaviour, however, will also be tested with moreusers. In addition, we are going to define, implement and evaluate furthercoordination patterns potentially derived from social sciences and studies.
Acknowledgement
This work is supported by the European Commission through the FP6-2005-IST-5-034749project WORKPAD.
References
Abowd, G.D., et al., 1999. Towards a better understanding of context and context-awareness.
In: HUC’99: Proceedings of the 1st international symposium on handheld and ubiquitous
computing. London, UK: Springer-Verlag, 304–307.Alexander, C., 1979. The timeless way of building. New York: Oxford University Press.
Borghoff, U.M. and Schlichter, J.H., 2000. Computer-supported cooperative work: introductionto distributed applications. Berlin: Springer.
Bortenschlager, M., Kotsis, G., and Reich, S., 2006. A generic coordination architecture as an
enabler for mobile collaborative applications. In: Distributed and mobile collaboration(DMC 2006) workshop – WETICE, Manchester, UK.
Bortenschlager, M., et al., 2009. A context-sensitive infrastructure for coordinating agents inubiquitous environments. Engineering Environments for Multiagent Systems of
International Journal on Multiagent and Grid Systems, 5 (1), 1–18 (Special issue).
Buschmann, F., et al., 1996. Pattern-oriented software architecture: a system of pattern. WestSussex, England: John Wiley & Sons.
Ciancarini, P., 1996. Coordination models and languages as software integrators. ACMComputing Surveys, 28 (2), 300–302.
de Freitas Bulcao Neto, R. and da Graca Campos Pimentel, M., 2005. Toward a domain-
independent semantic model for context-aware computing. In: LA-WEB’05:Proceedings of the 3rd Latin American web congress, Washington, DC, USA. IEEE
Computer Society, 61.DeNicola, R., Ferrari, G., and Pugliese, R., 1998. Klaim: A kernel language of agents
interaction and mobility. IEEE Transactions on Software Engineering, 24 (5), 315–330.
Deugo, D., Weiss, M., and Kendall, E., 2001. Reusable pattern for agent coordination.In: A. Omicini, F. Zambonelli, M. Klusch and R. Tolksdorf, eds. Coordination of
internet agents: models, technologies, and applications. Springer, 347–368.
246 M. Bortenschlager
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
Dey, A.K., Salber, D., and Abowd, G.D., 1999. A context-based infrastructure for smart
environments. In: Proceedings of the 1st international workshop on managing interactions
in smart environments (MANSE 99), 13–14 December 1999, 114–128.Dustdar, S. and Hoffmann, T., 2007. Interaction pattern detection in process oriented
information systems. Data and Knowledge Engineering, 62 (1), 114–128.Etzioni, A., 1964. Modern organizations Englewood Cliffs. NJ: Prentice-Hall.Freeman, E., Hupfer, S., and Arnold, K., 1999. JavaSpaces principles, patterns, and practice.
London: Pearson Education.Gamma, E., et al., 1995. Design patterns: elements of reusable object-oriented software. Boston:
Addison-Wesley Professional.Gelernter, D., 1985. Generative communication in Linda. ACM Transactions on Programming
Languages and Systems., 7 (1), 80–112.
Hupfer, S.C., 1990. Melinda: Linda with multiple tuple space. Technical Report YALE/DCS/
RR-766, Yale University.
Julien, C. and Roman, G.-C., 2006. Egospaces: facilitating rapid development of context-
aware mobile applications. IEEE Transactions on Software Engineering, 32 (5), 281–298.
Kanki, B., Lozito, H.F.S., and Foushee, H.C., 1989. Communication indices of crew
coordination. Aviation, Space, and Environmental Medicine, 60 (1), 56–60.Kindberg, T. and Fox, A., 2002. System software for ubiquitous computing. IEEE Pervasive
Computing, 1 (1), 70–81.Klein, M., 1998. Coordination science: challenges and directions. In: W. Conen and
G. Neumann (eds.) Coordination technology for collaborative applications-organizations,
processes, and agents, Lecture Notes in Computer Science, 1364. London: Springer-
Verlag, 161–176.Lindgaard, G. and Chattratichart, J., 2007. Usability testing: what have we overlooked?
In: Proceedings of the SIGCHI conference on human factors in computing systems,
CHI ’07, 28 April–03 May 2007, San Jose, CA, USA. New York, NY: ACM,
1415–1424.Malone, T.W. and Crowston, K., 1994. The interdisciplinary study of coordination. ACM
Computing Surveys, 26 (1), 87–119.Mascolo, C., Capra, L., and Emmerich, W., 2002. Mobile computing middleware. In:
Advanced lectures on networking. New York: Springer-Verlag, 20–58.Murphy, A.L., Picco, G.P., and Roman, G.-C., 2006. LIME: a coordination model and
middleware supporting mobility of hosts and agents. ACM Transactions on Software
Engineering and Methodology (TOSEM), 15 (3), 279–328.Newell, A. and Simon, H., 1972. Human problem solving. Englewood Cliffs, NJ: Prentice-Hall.
Nwana, H.S., Lee, L., and Jennings, N.R., 1996. Coordination in software agent systems. The
British Telecom Technical Journal, 14 (4), 79–88.
Obermair, C., et al., 2006. Cues in the environment: a design principle for ambient intelligence.
In: CHI’06 Extended abstracts on human factors in computing systems, New York, NY,
USA, ACM Press, 1157–1162.Parker, D.S., et al., 1983. Detection of mutual inconsistency in distributed systems. IEEE
Transactions on Software Engineering, 9 (3), 240–247.Payton, J., Roman, G.-C., and Julien, C., 2004. Context-sensitive data structures supporting
software development in ad hoc mobile settings. In: Proceedings of the 3rd international
workshop on software engineering for large-scale multi-agent systems, co-located with
ICSE 2004, Edinburgh, Scotland, 34–41.Picco, G.P., Murphy, A.L., and Roman, G.-C., 1998. LIME: Linda meets mobility. In:
D. Garlan, ed. Proceedings of the 21st international conference on software engineering
(ICSE’99), May 1999. Los Angeles, CA, USA: ACM Press, 368–377. Also available as
Technical report WUCS-98-21, July 1998, Washington University, St. Louis, MO,
USA.
Journal of Location Based Services 247
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
Satyanarayanan, M., 2001. Pervasive computing: vision and challenges. IEEE PersonalCommunications, 8 (4), 10–17.
Schelfthout, K., Holvoet, T., and Berbers, Y., 2005. Views: customizable abstractions forcontextaware applications in manets. In: SELMAS’05: Proceedings of the 4th
international workshop on software engineering for large-scale multi-agent systems,New York, USA. ACM Press, 1–8.
Schelling, T.C., 1960. Strategy of conflict. Cambridge, MA: Harvard University Press.
Schilit, B.N., Adams, N., and Want, R., 1994, Context-aware computing applications. In: 1stworkshop on mobile computing systems and applications, Lake District, UK.
Schmidt, A., Beigl, M., and Gellersen, H.W., 1999. There is more to context than location.
Computers and Graphics, 23 (6), 893–901.Sorrows, M.E. and Hirtle, S.C., 1999. The nature of landmarks for real and electronic spaces.
In: C. Freksa and D.M. Mark, eds. Spatial information theory: cognitive and
computational foundations of geographic information science, International conferenceCOSIT’99, Lecture Notes in Computer Science, vol. 1661, 37–50, 1999.
van der Aalst, W.M.P., et al., 2003. Workflow patterns. Distributed and Parallel Databases,14 (3), 5–51.
Virzi, R.A., 1992. Refining the test phase of usability evaluation: how many subjects isenough? Human Factors, 34 (4), 457–468.
248 M. Bortenschlager
Dow
nloa
ded
by [
Uni
vers
itat P
olitè
cnic
a de
Val
ènci
a] a
t 17:
34 2
6 O
ctob
er 2
014
