Proceedings of the 2010 14th International Conference on Computer Supported Cooperative Work in Design
Using a Metamodel to Design Structural and Behavioral Aspects in Context-Sensitive Groupware Vaninha Vieira
Patricia Tedesco, Ana Carolina Salgado
Computer Science Department Federal University of Bahia Salvador, Brazil
[email protected]
Informatics Center Federal University of Pernambuco Recife, Brazil [pcart,acs]@cin.ufpe.br
Abstract— A context-sensitive groupware uses information about a group and its participants’ context in order to provide useful information and services to improve group work. A relevant issue when designing Context-Sensitive Systems (CSS) is how to represent contextual information and the system’s behavior. This paper presents a Context Metamodel and shows preliminary experiments in two context-sensitive groupware performed to illustrate its usage and potential in designing CSS. The metamodel offers integrated support for modeling structural and behavioral aspects involved in context management and usage.
experts, and the DiSEN-Notifier, which supports notification of relevant events occurred in a group context.
Keywords-Context, Groupware, Context-Awareness, Metamodel
Modeling and metamodeling are similar activities, the difference being on their interpretation. A model is an abstract representation of a real-world system. A metamodel defines a language and the semantics for specifying models for particular domains. We propose a Context Metamodel [2] that defines concepts related to context manipulation in a high level domain-independent layer. Such a metamodel provides a conceptual infrastructure to support building context models. Since context is a novel and not well understood area, a challenge in context metamodeling is to identify and specify the concepts for context manipulation and their association to each other as well as their semantics.
I.
The paper is organized as follows: Section II details the Context Metamodel; Section III illustrates its usage through the two case studies; Section IV discusses our approach with related work; and, Section V presents our concluding remarks and future work. II.
INTRODUCTION
In computational systems, context is a set of relevant information that allows characterizing entities (e.g. person, group, place, event or shared objects) relevant in an interaction between a user and an application [1]. Computer systems that provide more relevant services or information according to contextual information are called Context-Sensitive Systems (CSS) [2]. There is an increasing interest in using context in different application domains, such as Computer Supported Cooperative Work (CSCW), where context is already present albeit associated to issues such as awareness and group memory [3]. Some works study how context of a collaborative interaction can be used to enrich group work and business processes (e.g. [4-7]). We call context-sensitive groupware a collaborative system that uses contextual information surrounding a group interaction to improve group work.
A CONTEXT METAMODEL FOR DESIGNING CSS
To this aim, we make a clear distinction between the concepts of context and contextual element (CE) [8]. CE is any piece of data or information that allows characterizing entities in a domain. A context is a dynamic concept that has a strong relation with an agent’s focus of attention. A focus can be a step in a task execution or in a decision making [9]. Focus is what allows one to determine which CEs should be instantiated and used to compose the context. A CE can be known, encoded and represented in advance; it is stable and can be defined at design time. Context is dynamic, dependent on a focus and is built at runtime, when an interaction occurs.
When designing a CSS, an emphasis should be given to the analysis of how users (should) interact with the CSS and how they expect the CSS to act on their behalf. Designers need to deal with issues associated to: which information to consider as context, how to represent it, how to manage it and how to integrate context usage into the system.
The context metamodel aims to assist context specification and representation in a generic domain-independent manner. It aids developers on modeling context and designing CSS. Concepts in the context metamodel were separated in two main categories: structural, which includes concepts for modeling the structure of a CSS (Section II.A), and behavioral, which encompasses concepts for modeling the context-sensitive behavior (Section II.B). UML Profiles assist context models creation using the metamodel is described in Section III.C.
In our work, we explore the idea that it is possible to modularize CSS development by separating elements related to the application business domain from those related to context manipulation. We propose a Context Metamodel that integrates the design of structural and behavioral aspects in context management. In this paper we present this metamodel and we describe how it was used on two different groupware tools: the ICARE, which fosters informal collaboration by recommending
978-1-4244-6763-1/10/$26.00 ©2010 IEEE 59
to the structural aspects of a CSS (Fig. 1): ContextualEntity, ContextSource, Focus and ContextualElement.
A. Modeling Structural Aspects in a CSS To illustrate the concepts’ explanation, we consider a system that supports researchers on planning academic missions (e.g. conference or meeting) [2]. A mission may have particular characteristics (e.g. duration, location, activities) and researchers may perform common tasks to accomplish a mission planning (e.g. subscribe or book a transport). A mission planning support system may have features, such as: to identify requirements and steps to be accomplished according to the mission type and the user’s profile; to aid a researcher on booking transport and accommodation; or to identify other concerns the researcher should be aware of about the mission (e.g. relevant activities, money exchange information or tips for touristic plans).
An entity represents a concrete representation of a real world object that can be both distinctly identified and relevant to describe a domain. It is used to classify individuals with similar characteristics and contains descriptions of these individuals through encapsulated attributes. Examples of entities in the academic mission domain are: Person, Professor, Student, Mission and Hotel. In a context model, a ContextualEntity represents the entities that should be considered for context manipulation purposes. These entities can be identified from the application conceptual model. A ContextualEntity is characterized by at least one ContextualElement.
Based on theoretical findings on context and context dynamics [2], we defined the following main concepts related
Figure 1. The Context Metamodel Main Concepts [2]
60
hotel’s comfort. However, a Professor could prefer a more comfortable hotel even if it is not the cheapest one. In the Context Metamodel (Fig. 1) this can be indicated by the relevance association between a Focus and a ContextualElement and a corresponding relevance weight that can be dynamically updated.
ContextualElement (CE) represents a property used to characterize a ContextualEntity. A CE can be identified from the set of attributes and relationships associated to an entity. Examples of CEs in the academic mission domain associated to the entity Student include: age, sex, academicDegree, advisor and livingLocation. For the entity Mission, examples of CEs are: location, duration, type, startDate and endDate. CE is the basic unit of information in the Context Metamodel. A context is composed by an aggregation of CEs. A CE should always be associated to a ContextualEntity. Not necessarily all properties of a ContextualEntity are classified as CE. The criterion to identify if a property is a CE is subjective and strongly dependent on the context requirements defined for the CSS.
When processing a CE or identifying a behavior for a CSS, it may be necessary to consider associated rules. In the Context Metamodel, a Rule is represented as a set of one or more conditions and a set of one or more actions. Each condition represents an expression, which results in a value true, false, or null (unknown) when matched to available data. An action indicates a procedure that must be executed when the rule’s conditions are satisfied (e.g. to trigger a system’s behavior, to assign a new value to a CE, or to assign a new relevance weight to an association between a CE and a focus).
A Focus aids to determine what should be considered in a context. When someone is performing some task or activity we say that this “person’s focus” is that task. In the metamodel, a focus is determined by the task together with who is executing it. The task executor is an agent, which can be a person, a group of people, a process or a software agent. An agent may perform different roles when executing the task. Thus, a Focus is defined as a composition of a Task and an Agent, where the Agent executes a Task performing some role. For example, in the academic mission system, we can identify that an agent Professor may perform some tasks, such as Request Financial Aid or Book a Hotel. Each tuple constitutes a distinct focus.
To support modeling behavior concepts, the metamodel proposes to use the formalism of contextual graphs [9]. Fig. 2 illustrates a contextual graph for a task Book Transportation in the academic mission domain. The condition associated to the node CE1 (“Mission.occursIn=Person.livesIn”) verifies if the mission is carried out in the same city where the person lives. Two paths can be followed according to the allowed values for CE1: yes or no. Depending on the CE1 value, the graph may follow two different paths. For example, if CE1.value=“yes” no transport is necessary and thus the contextual graph points to the end of the task execution. Depending on the path followed some actions may be activated. For example, when CE1.value=“no” and CE2.value=“CAPES” the activated action is “Contact CAPES Official Agency”, and then the end of the task execution. Each contextual node has an associated recombination node (labeled R1, R2 and R3, respectively), indicating the convergence of different paths. For example, the condition verified by CE3 ends in the node R3.
One characteristic of CSS is that context information may originate from heterogeneous and frequently external context sources (e.g. user dialog interfaces, profiles, physical sensors, desktop sensors and external databases). A context model should provide ways to inform how the CE acquisition occurs. In the Context Metamodel this can be done through the concept ContextSource and the association acquisition between a ContextSource and a CE. For example, the CE location may be provided by a GPS device (for outdoor places), a badge identification service (for indoor places) or still an IP (Internet Protocol) locator service (for network connections). Other information can be specified such as the acquisition type (e.g. Sensed, Profiled, User Defined, Queried and Derived) or the update periodicity for a CE value (e.g. never, occasionally, often and always).
Each path in the contextual graph contains the definition of a production rule that indicates the context influence over the application behavior. For example, the Rule 1 below, extracted from a path in the contextual graph in Fig. 2, states that if a person does not live in the place where the mission occurs, the mission is paid by the missionary and if the missionary is less than 26 years old, the following behaviors should be triggered in the sequence: “Lookup Transport”, then “Classify by Price”, then “Show Transport Options”.
B. Modeling Behavioral Aspects of a CSS The CSS Behavior metamodel is related to the dynamic aspect of context manipulation, i.e. the identification of CEs related to a Focus (CERelevance) and Rules that indicate how the system should act according to context variations.
Rule1: Conditions not (Mission.occursIn = Person.livesIn) Mission.whoPays = “missionary” Person.age < 26 Actions CallBehavior(“Lookup Transport”) CallBehavior(“Classify by Price” CallBehavior(“Show Transport Options”)
Context is a dynamic concept that should be rebuilt at each new focus, being composed by all CEs that are relevant to support the task defined in the focus. In this sense, an important issue in a context model is to identify at runtime the active context, meaning the instantiated CEs relevant to the current focus. The relevance level can be influenced by different agents performing a task. For example, when executing the task book a hotel, an agent Student can indicate that the hotel’s price must be considered with a higher relevance than the
61
updateFrequency); (contains two tag definitions: task and agent), (model the relevance relationship between a Focus and a CE using two tag definitions: element – reference to the corresponding CE – and weight – indicates how relevant the CE is to the focus), and .
C. Implementing the Metamodel with UML Profiles The UML profile mechanism [10] allows customizing the UML Metamodel for specific problem domains. This is achieved by extending existing metaclasses in the UML Metamodel using three extension constructs: stereotypes, tag definitions and constraints. We defined two profiles for the Context Metamodel according to the concepts defined for each category: the structure metamodel (Context Profile) and the behavior metamodel (CxG Profile).
The CxG Profile extends the UML Activity Diagram with the semantics defined in the contextual graphs. The stereotypes defined for the CxG Profile are: (indicates a model package containing contextual graph elements); (indicates a new CxG action node); (indicates actions that can be executed in parallel); (indicates a CxG contextual node with a tag definition condition); (indicates the deactivation of the condition tested in the corresponding contextual node); (represents an association from a contextual node to: another contextual node, an action or a parallel action grouping). The advantages of using the CxG Profile to model contextual graphs are twofold: we can design a contextual graph using any UML-based tool with the advanced modeling features provided by these tools, and we can integrate the CSS behavior model with the context conceptual model.
To model Focus, we propose the usage of the UML Use Cases Model, enriched with the stereotypes (extends the metaclass Actor); (extends the metaclasses UseCase and Activity); (extends the metaclass Association to explicitly represent an association between an Agent and a Task in a Focus). To model CEs and Contextual Entities, we extend the UML Class Model enriched with the stereotypes: , > (a tag definition type indicates a category for the CE), (classes in the context model that designate context sources), (models the relationship between a CE and a ContextSource, through four tag definitions: element, acquisitionType, matchingExpression,
Figure 2. Modeling Context-Sensitive Behavior: A Contextual Graph for a Focus [2]
III.
A. Case 1: Context in ICARE ICARE (Intelligent Context Awareness for Recommending Experts) [11] is an expert recommender system (ERS) that considers contextual information about users (who are requesting the recommendation) and experts when processing recommendations. ICARE maintains a base of experts. Users access ICARE through a recommendation interface and provide a set of keywords to receive a classified list of experts. To provide experts that better match users’ needs, ICARE uses a context interface. CEs related to the user performing the
APPLYING THE CONTEXT METAMODEL
In [8] we explain how the metamodel can be used integrated to a Software Engineering process to design CSS. This process was used conjoint with the metamodel in two case studies: an experts recommendation system that supports informal collaboration (Section III.A), and a notification system that supports context awareness (Section III.B).
62
recommendation and to the recommended experts are considered in addition to the keywords. To model context in ICARE we instantiated the context metamodel, as shown in Table 1. More information about context modeling in ICARE can be found in [11].
TABLE II.
Concept Focus
TABLE I.
Concept Focus
CONTEXT METAMODEL INSTANTIATION: ICARE
Examples of Instances in ICARE Agent User in Task Search Experts
Expert [availability, .approachability, location, contactInfo, worksIn, organizationLevel, currentActivity, interests, expertiseDegree (expertise), reputation] User [location, socialDistance(Expert), interests, organizationLevel, currentActivity]
ContextSource
Lattes Database (brazilian curricula database); GeoLite City (location data related to IP addresses); MSN (instant messenger program); User Profile (form filled by users in ICARE); History Cases (previous recommendations)
Rules
Rule1 Conditions User.availability >= 0.7 User.organizationalLevel > 0.5 Actions CallBehavior(“Solve Keywords”) CallBehavior(“Lookup Experts”) CallBehavior(“Set Accessibility HIGH”) CallBehavior(“Set Expertise HIGH”) CallBehavior(“Calculate Fitness”) CallBehavior(“Rank by Fitness”) CallBehavior(“Show Experts”)
Examples of Instances in DiSEN-Notifier Agent Manager in Task Define Participant
ContextualEntity Participant; Project Contextual Element
Participant (isInProject(Project), availability, location, hasExpertise (Subject), hasAbility(Subject)) Project (demandedExpertise (Subject), startDate, endDate, currentState)
ContextSource
PersistenceService
Rules
Rule 1 : Conditions Participant.hasExpertise (Project.demandedExpertise) Participant.availability = “available” Actions CallBehavior(“Set Participant as Candidate”) CallBehavior(“Verify Participant Afinnity”) CallBehavior(“Set Participant to Project”) CallBehavior(“Notify Participant”)
ContextualEntity User; Expert Contextual Element
CONTEXT METAMODEL INSTANTIATION: DISEN-NOTIFIER
IV.
RELATED WORK
Existing UML profiles for context modeling [13, 14] identify the concept equivalent to our Contextual Element (named, respectively, context and context item) as an extension of the Class metaclass. We propose to model contextual element as an extension of the Property metaclass, instead. This decision is due to our understanding that entities and contextual elements are two different but related concepts. A contextual element is used to characterize a contextual entity. So, instead of considering, for example, a Person as a contextual element, we should identify the person’s age or the person’s current location as some CEs that characterize Person. Semantically, this corresponds to the attributes associated to a class Person (e.g. age) or to the associations between that class with another (e.g. currentLocation, between classes Person and Location).
B. Case 1: Context in DISEN-Notifier A relevant issue in collaborative work is supporting activities coordination. To this aim, participants should be aware of information and events relevant to her/his activities execution. The DiSEN-Notifier is a notification manager integrated to the DiSEN (Distributed Software Engineering) environment. It handles events in the shared workspace and notifies group participants about events of their interest. Context usage in DiSEN-Notifier is twofold: (i) contextual information is used to compose the event notification (participants need to know about other participants’ context); and (ii) contextual information is used to filter events a user should be aware of, reducing information overload and keeping participants aware of relevant events according to their context. Table 2 summarizes context modeling in DiSEN-Notifier using the Context Metamodel concepts. Additional information about context in DiSEN-Notifier can be found in [12].
To specify the context metamodel concepts we based our design decisions on weaknesses found in reviewed context models, in a broad sense, not only in the CSCW domain (e.g. [13-15]). We noticed that the analyzed approaches: (i) do not make a clear distinction between the concepts of context and contextual element, calling everything as context, not considering explicitly the dynamic aspect of the context in comparison to the static aspect of the contextual element; (ii) do not consider a separation between the concepts of context and entity; in some cases (e.g. [14]) an entity is indicated as being a context, instead of assuming that context should be built by analyzing specific properties associated to the entities, not the entity as a whole; (iii) lack support for reusing existing application models in the construction of the context model, which results in no clear differentiation between the context model and the application model parts; this work argues against this practice and claims that reusing existing models is a way to diminish the complexity in building CSS.
63
There are several studies on how context can be modeled and managed in CSCW applications [16-19]. The conceptual framework proposed in [16] points out some contextual elements present in CSCW applications related to the group, its members, tasks, interactions and the environment. In [17] it is proposed a context-based awareness mechanism which filters the information delivered to the user according to a context description. Alarcon et al. [18] propose a preliminary taxonomy for context in groupware based on a survey of available work. Vieira et al. [19] propose an ontology for context representation in groupware. All these works propose solutions for the structural representation of contextual information in groupware. They do not integrate the modeling of how groupware behavior is affected by context. Our proposal and its application to different CSCW tools is a step forward in this direction. V.
REFERENCES [1] A. K. Dey, "Understanding and Using Context," Personal and Ubiquitous Computing, vol. 5, no. 1. pp.4-7, 2001. [2] V. Vieira, P. Tedesco, and A. C. Salgado, "Designing Context-Sensitive Systems : An Integrated Approach," Expert Systems with Applications, vol. (accepted, to appear), 2010. [3] Borges, M. R. S, Brézillon, P, Pino, J. A, and Pomerol, J.-C., "Groupware System Design and the Context Concept". Computer Supported Cooperative Work in Design (CSCWD'2004), Xiamen, China, pp.45-54, 2004. [4] M. R. S. Borges, P. Brézillon, J. A. Pino et al., "Dealing with the Effects of Context Mismatch in Group Work," Decision Support Systems, vol. 43, no. 4. pp.1692-1706, 2007. [5] Nunes, V. T., Santoro, F. M., and Borges, M. R. S, "Capturing Context about Group Design Processes". 11th International Conference on Computer Supported Cooperative Work in Design, Melbourne, Australia, pp.18-23, 2007.
CONCLUSIONS AND FURTHER WORK
[6] Veiel, D., Haake, J. M., and Lukosh, S., "Extending a shared workspace environment with context-based adaptations". 15th International Workshop on Groupware (CRIWG), Douro, Portugal, pp.174-181, 2009.
This paper presented a metamodel to support the design of context management and usage and described two case studies showing the metamodel usage in two different CSCW tools. It also presented the proposed UML Profiles [10] related to the context metamodel: Context Profile (for modeling structural concepts) and CxG Profile (for modeling CSS behavior).
[7] Messeguer, R., Damián-Reyes, P., Favela, J., and Navarro, L., "Context Awareness and Uncertainty in Collocated Collaborative Systems". 14th International Workshop on Groupware (CRIWG), Omaha, USA, pp.4156, 2008. [8] Vieira, V., Tedesco, P., and Salgado, A. C., "A Process for the Design of Context-Sensitive Systems". 13th International Conference on Computer Supported Cooperative Work in Design, Santiago, Chile, pp.143-148, 2009.
Benefits of using a context metamodel include: to achieve a common vocabulary that increases the understanding about context peculiarities and to provide a guide for the identification of the elements to be designed in a context model. Besides, the semantics enrichment provided by the stereotypes can ease the design and evaluation of the context concepts in the CSS and the evolution and maintenance of the CSS functionalities.
[9] P. Brézillon, L. Pasquier, and J.-C. Pomerol, "Reasoning with Contextual Graphs," European Journal of Operational Research, vol. 136. pp.290298, 2002. [10] OMG, "Unified Modeling Language: Superstructure, Version 2.1.2." http://www.omg.org/spec/UML/2.1.2/ . 2007. 2008. [11] Petry, H., Tedesco, P., Vieira, V., and Salgado, A. C., "ICARE: A Context-Sensitive Expert Recommendation System". Workshop on Recommender Systems (ECAI'08), Patras, Greece, pp.53-58, 2008.
Visual languages play an important role in Software Engineering because graphical models are easier to read and understand. Creating rules in a context-sensitive system is a straightforward task. The usage of contextual graphs to model the rules for further generation in a specific rule language was well accepted by the designers of ICARE and DiSEN-Notifier.
[12] Chaves, A. P., Huzita, E., Donega, W. C., and Vieira, V., "Notificação Baseada em Contexto como Apoio à Gerência e Coordenação em Equipes de Software Distribuídas"., Fortaleza, Brasil, 2009.
Modeling the dynamic aspect involved in using context is a hard and still unsolved problem. Extensions should be done to the context metamodel to improve the concept of a Focus and its relevance association to CE, which define what we consider the context in that focus. Besides, a mathematical formalization of the metamodel concepts could support solving possible ambiguities so appropriate modeling tools can be developed.
[14] C. Simons and G. Wirtz, "Modeling context in mobile distributed systems with the UML," Journal of Visual Languages and Computing, vol. 18. pp.420-439, 2007.
[13] Ayed, D., Delanote, D., and Berbers, Y., "MDD Approach for the Development of Context-Aware Applications". 6th International and Interdisciplinary Conference on Modeling and Using Context, Roskilde, Denmark, pp.15-28, 2007.
[15] Fuchs, F., Hochstatter, I., Krause, M., and Berger, M., "A Metamodel Approach to Context Information.". PerCom Workshops, Kauai Island, HI, pp.8-14, 2005. [16] Rosa, M. G. P., Borges, M. R. S., and Santoro, F. M., "A Conceptual Framework for Analyzing the Use of Context in Groupware"., SpringerVerlag Berlin, Heidelberg, pp.300-313, 2003.
ACKNOWLEDGMENTS Authors thank CNPq and CAPES for their financial support. This work was [partially] supported by the National Institute of Science and Technology for Software Engineering (INES), funded by CNPq grant 573964/2008-4.
[17] Kirsch-Pinheiro, M, Villanova-Oliver, M., Gensel, J., and Martin, H., "Context-Aware Filtering for Collaborative Web Systems: Adapting the Awareness Information to the User's Context"., Santa Fe, New Mexico, pp.1668-1673, 2005. [18] Alarcón, R., Guerrero, L. A., and Pino, J. A., "Groupware Components as Providers of Contextual Information"., Paris, France, 2005. [19] Vieira, V., Tedesco, P., and Salgado, A. C., "Towards an Ontology for Context Representation in Groupware"., Porto de Galinhas, Brasil, pp.367-375, 2005.
64
