A MOF Metamodel for the Development of Context-Aware Mobile Applications Cléver R. G. de Farias1,2, Marcos M. Leite2, Camilo Z. Calvi3, Rodrigo M. Pessoa3, José G. Pereira Filho3
1
Departamento de Física e Matemática, University of São Paulo (FFCLRP/USP) Av. Bandeirantes, 3900 14040-901 − Ribeirão Preto (SP), Brazil
[email protected]
2
Programa de Mestrado em Informática, Universidade Católica de Santos (Unisantos) R. Dr. Carvalho de Mendonça, 144 11070-906 − Santos (SP), Brazil
{cleverfarias, medina}@unisantos.edu.br
ABSTRACT
Context-aware mobile applications are increasingly attracting interest of the research community. To facilitate the development of this class of applications, it is necessary that both applications and support platforms share a common context metamodel. This paper presents a metamodel defined using the OMG Meta Object Facility (MOF). This metamodel has been used as basis for the development of context-aware applications and an associated service platform.
Categories and Subject Descriptors
I.6.5 [Model Development]: Modeling Methodologies, C.2.4 [Distributed Systems]: Distributed Applications.
Keywords
MOF, Context-aware, Metamodelling.
1. INTRODUCTION
The new mobile standards and technologies and the increasing use of portable devices have stimulated the development of a new, highly dynamic, computing paradigm called ubiquitous or pervasive computing. Pervasive computing is characterized by constant changes in the environment caused by the mobility of its users, in contrast to the more traditional desktop-based computing paradigm. Pervasive computing deals with systems embedded in computationally rich environments, capable of providing services and information, whenever and wherever requested by their users. In the scope of pervasive computing, a class of applications that has raised increasing interest in the research community are context-aware mobile applications. These applications take into account in their decision making process and processing not only explicit, user supplied information, but also implicit information related to their physical and computational environment. Context-aware mobile applications are programmed to react to Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’07, March 11-15, 2007, Seoul, Korea. Copyright 2007 ACM 1-59593-480-4/07/0003…$5.00.
3
Programa de Pós-Graduação em Informática, Universidade Federal do Espírito Santo (UFES) P.O. Box 01-9011, 29060-970, Vitória (ES), Brazil
{camilozc, rpessoa, zegonc}@inf.ufes.br
and explore the constant changes in context within a dynamic domain. The development of such applications deals with a number of technological challenges and requires the existence of a suitable support infrastructure to facilitate the construction, deployment and execution of these applications. Particularly, support is needed to handle different sources and types of contextual information, provided by highly distributed, heterogeneous and constantly changing environments. In this sense, a number of initiatives related to the development of support platforms have been proposed in the literature, e.g., [2], [3], [4], [16]. These platforms aim at providing a number of services and suitable architectural support for the development of context-aware mobile applications. The development of such platforms is far from being a trivial task and involves a number of challenges [5]. A particular problem that has to be treated by any service platform is the definition of a model to describe the contextual domain in which a given application or service is defined. A number of context models have been proposed in the literature, such as [3], [6], [9], [18]. However, most of these models provide restricted solutions for modelling applications in different domains. Additionally, most of these models lack a formal representation of its syntax and semantics in order to guarantee the consistency between different representations of context used by applications, context providers and service platforms. These problems could be considerably reduced in case we had a context metamodel formally defined. This metamodel could be used to produce valid representations of context that could be consistently used and manipulated throughout the system development, deployment and operation. This paper investigates a number of context models described in the literature and proposes a context metamodel based on the main concepts and strengths found on these models. Our metamodel is formally described using the Meta Object Facility (MOF) specification [12], standardized by the Object Management Group (OMG). The remaining of this work is structured as follows: section 2 provides an overview of the service platform which is been developed in the context of this work; section 3 discusses some related work; section 4 presents the main aspects of our context metamodel; finally, section 5 presents some conclusions and outlines some future work.
2. SERVICE PLATFORM
Service platforms have been proposed for the development of mobile context-aware applications. We have been working on the development of a service-oriented platform that supports the creation and execution of mobile context-aware applications, called Infraware [17], [15]. Infraware can be considered an evolution of WASP platform [5], developed in the context of the WASP (Web Architectures for Services Platforms) project. The main components of the Infraware platform architecture are described in the sequel. Both the internal components of the platform and the external components share the same context metamodel. The Context Interpreter is responsible for interpreting the context within the platform. This component manipulates and refines the contextual information provided by different sources, so that this information can be used transparently by the applications. Additionally, this component provides general mechanisms for context acquisition and manipulation, enabling the reuse of components and methods during the development of new applications. A Context Provider is an element (either hardware or software) external to the platform that provides contextual information to the platform. Such information can be gathered from sensors, computational devices or other context providers. A number of context providers can be associated with the platform. A Service Provider is a functional entity that provides a service, not necessarily context-dependent, to the platform. A number of different service providers can be used by the platform. The offered services should be published before their use by the platform. The platform target clients are a number of context-aware applications (Context-Aware App). These applications interact with the platform through the subscription to a set of available services and use the context information provided by both the context providers and the platform itself to provide a more suitable service to its users. The Service Manager provides support to the use of services within the platform. This component is primarily responsible for service publication, service discovery and selection, service composition and service execution. The Registry Manager offers a homogeneous interface for accessing the records used by the platform, including services, user profiles and context history information. These records can be internal or external to the platform. In case another platform component needs some piece of information available in a database, such information is retrieved by the registry manager. The Monitor is the platform component responsible for interpreting and managing the applications´ subscriptions. In order to manage these subscriptions, the monitor uses the information provided by the registries and by the context interpreter. The monitor is responsible for triggering the demanded services in association with the Service Manager.
3. RELATED WORK
Different approaches for context modeling have been proposed in the literature. These different approaches reflect the diversity of contextual information and its use in different application
domains [11]. These approaches can mostly be classified according to the data structure used for representing contextual information. Key-value pairs are considered the simplest data structure used for contextual information modeling. Schilit et al. [18] propose the use of key-value pairs and their corresponding values for the representation of contextual information, which are then used as environment variables. This approach supports only simple value matching comparison, thus limiting its applicability. Object-Role Modeling (ORM) is used as basis for context modeling in [7], [8]. Henricksen et al. propose an extension to ORM by introducing a number of extensions to capture some properties of contextual information and their descriptions [9]. In ORM, the basic modeling concept is fact types. The creation of ORM models involves the identification of object types and the identification of relationships between object types, which are modeled as fact types. The proposed model classifies the fact types according to its static (fact type does not change over time) or dynamic nature. Additionally, dynamic fact types are also classified according to the source of information (profiled, sensed or derived). Extensions to capture constraints on temporal and alternative fact types, annotation of fact types with appropriate metadata types, and dependencies between pairs of fact types are also provided. Context models based on first order logic use logical expressions to define the conditions under which conclusions or facts can be derived from (a set of) other expressions or facts. A formal system is used to describe these conditions as a set of rules. Thus, the contextual information is defined as facts, expressions or rules. As any model based on logic, this type of representation is highly formal. Gray and Salber propose a context model that use first order logic to formally represent the transformations and relationships involving contextual information [6]. Ontologies have also been used for context modeling. An ontology is a formal description of the concepts and relationships present in a given domain. Due to its formalism, an ontology can be used to make inferences over its associated domain in order to generate new facts or to discover new relationships, a feature highly desirable in context-aware applications. The Context Broker Architecture (CoBrA) project [3] provides an agent-based architecture for the development of context-aware application. The main component of this architecture is the context broker, which shares an ontology-based context model and provides a number of services to facilitate the communication between distributed agents and devices. Brézillon propose the use of contextual graph to capture general solutions used to solve context-aware problems [1]. This approach consists of modeling contextual information as nodes in acyclic graphs, making use of three different types of context: contextual knowledge, proceduralized context and external context. New facts about contextual information can be derived by following the graph. Sheng and Benatallah propose a UML-based context metamodel and corresponding design notation to facilitate the development of context-aware web services [19]. The proposed metamodel does not refine contextual information and focuses on the association between basic contextual structures with service invocation interfaces for both contextual providers and context-aware applications.
4. CONTEXT METAMODEL
Software engineers are primarily concerned about choosing appropriate models to represent specific application domains. The use of a metamodel not only guarantees a strong and focused semantics tied to a particular application domain, but also offers a precise abstract syntax and a common representation to any developed model. Literature often considers UML [13], [14] a limited language regarding its capacity to adequately capture contextual information [8], [9]. UML is a general purpose modeling language, whose semantics was never intended to accommodate the specific features of ubiquitous applications. Context modeling demands a particular, more specific metamodel. This paper proposes a MOF-based contextual information metamodel. MOF is the foundation of the OMG metamodeling strategy and can be used to design the abstract syntax of any metamodel. MOF’s abstract syntax is represented using MOF itself and uses a UML class diagram as its concrete syntax. So, we can assume any MOF metamodel can be represented through UML tools, since an instance of a MOF model is also an UML class diagram. This characteristic is particularly relevant given that visual modeling is essential for expressiveness and productivity in modern software development practices. The concepts of our context metamodel were identified and grouped according to five different views, each one represented by a MOF package, viz., core, service, subscription, contextaware service and quality views. In the following subsections we discuss the purpose and main aspects of the two main views of our metamodel, viz., core and service view. We refrain from discussing the remaining views in this paper. For more information we refer to [6].
(metaclass Static) reveal a long-term relationship between the entity and the value of its attribute, which is kept unchanged throughout time. Dynamic associations (metaclass Dynamic) are classified according to three different types: sensed (metaclass Sensed), profiled (metaclass Profiled) and derived (metaclass Derived). These types of associations are used to stress the differences regarding origin, persistence, confidence level and temporality, and are useful for guiding the operation of the context-aware platform and associated applications. Sensed associations (metaclass Sensed) represent information about entities obtained through sensors within a context. This type of information is provided by a context provider. Frequently, sensed information needs to be recombined and transformed in order to reach a higher semantic level, such that it can be adequately used by applications that demand it. The confidence degree of sensed associations is considered lower, due to fast obsolescence, imprecision and physical limitations of the sensors. More than one source of sensed information can be used to reduce the risk of consuming outdate or imprecise data. Equivalent associations help managing alternative sources of sensed information (metaclass EquivalenceGroup). Profiled associations (metaclass Profiled) represent information provided by application users by means of configurable parameters. This type of information can be defined and updated whenever necessary during the entity lifetime.
The core view captures the main concepts used in our context metamodel. Figure 1 illustrates the core view of our context metamodel. These concepts were identified based on a number of proposals described in the literature and our experience in building context-aware applications and the Infraware service platform. Particularly, Henricksen et al. [9] propose a context metamodel based on three fundamental principles: entities, attributes and associations.
Derived associations (metaclass Derived) depend upon one or more associations. This type of information is obtained through conjunctions and transformations performed on the base associations. Each derived association provides a derivation function (metaattribute expression) that defines the rules and actions for using other context information. Dependencies of derived associations are explicitly represented. Based on derived associations, the service platform can provide contextual information at a higher abstraction level, which is fundamental service provided by the service platform to applications, i.e., the creation of (new) context information which can not be directly obtained through sensors. The abstract metaclass CWAssociationEnd is part of metaclass CWAssociation, which is responsible for associating the owner of the association with the owned CWClassifier. Each CWAssociation has only one CWAssociationEnd.
The context metamodel is organized around the metaclass
CWAssociationEnd allows the representation of information
4.1 Core View
CWClassifer, an abstract structure that generalizes the core concepts of any context: entities (metaclass CWEntity) and theirs attributes (metaclass CWAttribute). Entities correspond to physical
or conceptual objects from which contextual information is captured, such as: persons, organizations, devices and places. The contextual information is generally defined as an attribute. Attributes can be set statically or dynamically by using sensors. The states an attribute can assume during its lifetime are maintained as instances of the metaclass Content. The temporal behavior is an important aspect of context-aware applications and implies a chronological reference using timestamps. The abstract metaclass CWAssociation is used to define the relationships between entities and attributes and the relationships among entities themselves. Every association belongs to an entity (CWEntity owns CWAssociation). Any contextual information is classified either as static or dynamic, according to the type of association maintained with its owner. Static associations
regarding multiplicity and temporal aspects of associations.
CWAssociationEnd has two submetaclasses, viz., Simple and Composite. The metaclass Simple indicates that an entity keeps a
single value for its contextual information, while the metaclass
Composite indicates that an entity keeps more than one value for
its contextual information.
The abstract metaclass Composite has two submetaclasses, viz., Collection, which indicates a collection of active and simultaneously valid occurrences, and Alternative, which indicates a collection of mutually exclusive values. The metaclass CWAssociationEnd can be used to define temporal constraints to an association. These constraints indicate a valid time interval for using the corresponding contextual information. TemporalConstraint is an abstract metaclass with two submetaclasses, viz., RelativeInterval, which is used to define a time interval based on current time, and FixedInterval, which is used to explicit define the valid time interval.
Figure 1. Core View Concepts The constraint specification language OCL should be used to define the contents of metaattribute expression in the metaclass Derived. OCL was also used to refine the metamodel semantics by means of a number of invariants.
4.2 Service View
The availability of contextual information to context-aware applications relies on the definition of standard mechanisms for the interaction between the service platform and the context-aware applications. These mechanisms should comply to the following requirements: (a) loose coupling between applications and platforms, (b) high degree of flexibility to add, update and remove contextual information requests, with no impact over the platform or other applications operating on the same environment, (c) adaptability to accept different context models, provided they all share the same context metamodel; and (d) independency of a particular technological platform.
Based on these requirements, we decided to include a service view into our context metamodel. The major benefit of the service approach is to leverage the interoperability between platforms, applications and context providers, whenever context information is required, making much easier to add functionality in a standard way. Service-oriented architecture typically assures decoupling of applications, by only exposing service interfaces and by offering flexible and dynamic service composition schemes. Figure 2 shows the service view of our context metamodel. The abstract metaclass Service represents a service in our context metamodel. The metaattribute interaction defines the type of interaction used by the service. InteractionType defines the domain of possible values of the metaattribute interaction, viz., request-response, time-driven and event-driven. Services can be composed by other services. The abstract metaclass Service has a composition association with the metaclass Provider, which indicates the entity responsible for providing the service.
Figure 2. Service view concepts A context source service (metaclass ContextSourceService) offers primary contextual information to any platform (metaassociation provides). A context source service can be provided by any context provider. The metaclass ContextSourceService has two submetaclasses, defined according to a composite pattern, viz., the metaclass AtomicContextService, which represents a real leaf service, and the metaclass CollectionContextService, which represents a collection of equivalent and alternative services from different providers. The metaclass CollectionContextService is involved in setting QoS parameters for choosing between different, although equivalent, services that may vary in cost, availability, precision, and so far. The metaclass ContextAwareService specializes the metaclass Service and refers to any business service that demands or depends upon contextual information to operate. A context-aware application encompasses a collection of context-aware services. These services rely on other Services to perform their actions (metaassociation activates). A service consists of a number of operations, represented by the metaclass ServiceOperation. Operations are composed by messages (metaclass Message), as inputs, outputs, or faults. A message is constructed based on message parts (metaclass MessagePart). The role played by each message part during
interaction can be defined through the enumeration PartKind. Any message part can refer to a CWClassifier, CWEntity or CWAttribute.
5. CONCLUSION
This paper proposes a conceptual metamodel for the development of context-aware applications. This metamodel was developed according to an object-oriented approach, based on the Meta Object Facility (MOF) specification. The context metamodel was structured according to different views. We have also described the main concepts of two of these views. The MOF-based context metamodel provides a formal representation of contextual information, which enables the use of a wide variety of (standard) supporting tools in the development and manipulation of models. Additionally, we can also achieve model portability between different modeling environments. Context-aware mobile applications also benefit from a formally defined metamodel since we have a potential increase in the reuse of (proved) solutions. Moreover, this approach promotes interoperability between different applications and support platforms, provided they share or recognize the same metamodel. We have also provided a concrete syntax to our context metamodel in order to facilitate the design of mobile context-
aware applications. We developed a corresponding UML profile, the so-called UML-Context-Aware (UML-CW) [10]. Based on this profile we developed a case study where we modeled an application used in medical environment. This application basically provides the location and mapping of medical doctors inside a hospital based on the location of their associated PDAs and their corresponding schedules. More information regarding this case study can be found in [10]. The proposed context metamodel provides a common and tangible link between the Infraware platform and any context-aware application supported by the platform. The development of a context-aware application can be carried out independently of any specific knowledge of platform (and vice-versa), provided a common understanding of the underlying context metamodel. Thus, both the Infraware platform and any supporting application can evolve independently of each other. In the future we intend to investigate additional aspects regarding service definition, the mapping of contextual information to services, the characterization of mechanisms used to acquire contextual information and the representation of security aspects. Additionally, the development of this platform independent context metamodel was the first step towards a model-based approach for the development of context-aware mobile applications. We also intend to provide a number platform specific metamodels and to provide the corresponding platformindependent to platform-specific mappings.
6. ACKNOWLEDGMENTS
This work has been supported by CNPq under project number 50.6284/2004-2.
7. REFERENCES
[1] Brézillon, P.: Context-based modeling of operators’ practices by contextual graphs. Proc. of the 14th Mini-Euro Conf. on Human Centered Processes. Euro, pp. 129-137, 2003. [2] Chen, G. and Kotz, D.: SOLAR: A Pervasive-Computing Infrastructure for Context-Aware Mobile Applications. Technical Report TR2002-421, Dartmouth College, 2002. [3] Chen, H.: An Intelligent Broker Architecture for Pervasive Context-Aware Systems. Ph.D. Thesis, University of Maryland, USA, 2004. [4] Dey, A. K: Providing Architectural Support for Building Context-Aware Applications. Ph.D. Thesis, Georgia Institute of Technology, 2000. [5] Dockhorn Costa, P., Pereira Filho, J. G., van Sinderen, M.: Architectural Requirements for Building Context-Aware Services Platforms. In Proceedings of the Ninth Open European Summer School and IFIP Workshop on Next Generation Networks (EUNICE 2003), pp. 62-69, 2003. [6] Gray, P. D. and Salber, D.: Modelling and Using Sensed Context Information in the Design of Interactive Applications. Proceedings of Engineering for HumanComputer Interaction. Lecture Notes in Computer Science (2254), Springer, pp. 317-336, 2001.
[7] Henricksen, K. and Indulska, J.: Modelling and Using Imperfect Context Information. In Proceedings of the Second IEEE International Conference on Pervasive Computing and Communications, Workshop on Context Modelling and Reasoning (CoMoRea' 04). IEEE Computer Society, p. 3337, 2004. [8] Henricksen, K., Indulska, J. and Rakotonirainy, A.: Generating Context Management Infrastructure from HighLevel Context Models. In Proceedings of the 4th International Conference on Móbile Data Management, Industrial Track Proceedings, pp. 1-6, 2003. [9] Henricksen, K., Indulska, J. and Rakotonirainy, A.: Modeling Context Information in Pervasive Computing Systems. In Proceedings of the First International Conference on Pervasive Computing (Pervasive´02), LNCS (2414), p. 167-180, 2002. [10] Leite, M. M, de Farias, C. R. G., Pessoa, R. M., Pereira Filho, J. G. e Calvi, C. Z.: Metamodelo de Contexto e Perfil UML-CW (in portuguese). Project Deliverable, DBMWare/CNPq/D1.4, v.2.1, 2006. [11] Mostéfaoui, G. K., Pasquier-Rocha, J., Brezillon, P.: Context-Aware Computing: A Guide for the Pervasive Computing Community. In Proceedings of the IEEE/ACS International Conference on Pervasive Services (ICPS´04). IEEE Computer Society, pp. 39-48, 2004. [12] OMG: Meta Object Facility (MOF) Core Specification, OMG Available Specification, version 2.0. Object Management Group, 2006. [13] OMG: Unified Modeling Language: Infrastructure. OMG Specification, version 2.0, Object Management Group, 2005. [14] OMG: Unified Modeling Language: Superstructure. OMG Specification, version 2.0, Object Management Group, 2005. [15] Pessoa, R. M.: Infraware: Um Middleware de Suporte a Aplicações Sensíveis ao Contexto. Master Thesis, Universidade Federal do Espírito Santo (UFES), 2006. [16] Ranganathan, A., McGrath, R., Campbell, R. and Mickunas, M.: Use of Ontologies in a Pervasive Computing Environment. In The Knowledge Engineering Review, 18(3), p. 209-220, Cambridge University Press, 2004. [17] Santos, L. O. B. da S.: Semantic Services Support for Context-Aware Platforms. Master Thesis, Universidade Federal do Espírito Santo (UFES), 2004. [18] Schilit, W. N., Adams, N. I. and Want, R.: Context-Aware Computing Applications In Proceedings of the Workshop on Mobile Computing Systems and Applications. IEEE Computer Society, p 85-90, 1994. [19] Sheng, Q. Z., and Benatallah B.: ContextUML: A UMLBased Modeling Language for Model-Driven Development of Context-Aware Web Services. In Proceedings of the Fourth International Conference on Mobile Business (ICMB' 05), IEEE Computer Society, p. 206-212, 2005.
