Katholieke Universiteit Leuven - KU Leuven

Download PDF
0 downloads 0 Views 2MB Size Report
Comment
according to this context. ... Several context elements have to be specified during this phase, such as .... Figure 4 shows an excerpt of the purchase sequence.
MDD Approach and Evaluation of the Development of Context-Aware Applications Dhouha Ayed Didier Delanote Yolande Berbers Report CW 495, May 2007

Katholieke Universiteit Leuven Department of Computer Science Celestijnenlaan 200A – B-3001 Heverlee (Belgium)

MDD Approach and Evaluation of the Development of Context-Aware Applications Dhouha Ayed Didier Delanote Yolande Berbers Report CW 495, May 2007

Department of Computer Science, K.U.Leuven

Abstract Context-aware systems offer entirely new opportunities for application developers and for end users by gathering context information and adapting systems behavior accordingly. Several context models have been defined and various context-aware middleware has been developed in order to simplify the development of context-aware applications. Unfortunately, the development of an application by using these middleware products introduces several technical details in the application. These technical details are specific to a given middleware and reduce the possibility of reusing the application on other middleware. In this paper, we propose an MDD (Model Driven Development) approach that makes it possible to design context-aware applications independently of the platform. This approach is based on several phases that approach step by step the context platform and allow designers to automatically map their models to several platforms through the definition of automatic and modular transformations. To be able to apply this approach we define a new UML profile for context-aware applications that we use to explore our approach. Keywords : Model-Driven Development, Context-Awareness, Adaptation. CR Subject Classification : D.2.2, D.2.3, D.2.11

MDD Approach and Evaluation of the Development of Context-Aware Applications Dhouha Ayed, Didier Delanote, and Yolande Berbers Department of Computer Science, K.U.Leuven B-3001 Leuven, Belgium

Abstract. Context-aware systems offer entirely new opportunities for application developers and for end users by gathering context information and adapting systems behavior accordingly. Several context models have been defined and various context-aware middleware has been developed in order to simplify the development of context-aware applications. Unfortunately, the development of an application by using these middleware products introduces several technical details in the application. These technical details are specific to a given middleware and reduce the possibility of reusing the application on other middleware. In this paper, we propose an MDD (Model Driven Development) approach that makes it possible to design context-aware applications independently of the platform. This approach is based on several phases that approach step by step the context platform and allow designers to automatically map their models to several platforms through the definition of automatic and modular transformations. To be able to apply this approach we define a new UML profile for context-aware applications that we use to explore our approach.

1

Introduction

Model Driven Development (MDD) is an approach to developing software that proposes using machine-readable models at various levels of abstraction as its main artifacts. The key idea is to automatically transform highly abstract models into more concrete models from which an implementation can be generated in a straightforward way. The MDD approach is supported by the MDA (Model Driven Architecture) initiative of the OMG (Object Management Group), which introduced the notion of PIM (Platform Independent Model) and PSM (Platform Specific Model) [1]. A PIM is a model of a system that contains no technical details while a PSM is a representation of the same system containing all technical details that are needed to realize it on a concrete technology platform. The mapping between PIM and PSM is realized using an automatic transformation. This can capitalize on the PIM and generate PSMs for different technology platforms. The platform specific knowledge is moved to the transformations, effectively separating those concerns from the main application. Context-aware applications can collect context information and quickly adapt their behavior to context changes. Context is ”any information that can be used

to characterize the situation of entities (i.e. whether a person, place or object) that are considered relevant to the interaction between a user and an application, including the user and the application themselves” [2]. Context is typically the location, preference and state of people and computational and physical objects. Design and development of context-aware applications is particularly complex. First, Context acquisition is not an easy process. Context information, which can be acquired from heterogeneous and distributed sources (sensors, files, applications), may be dynamic and may require an additional interpretation in order to be meaningful for an application. Second, the adaptation process can be based on different types of mechanisms depending on the required dynamism and may be related to the semantics of the application. Consequently, context-aware applications need specific development mechanisms. Several middleware products have been defined to ease the development of context-aware applications, but no solution has been specifically proposed to design context-aware applications. The applications that are developed with the existing middleware are not portable. They include several technical details that are specific to a given technology and their reuse on a different technology platform requires redevelopment. This problem can be avoided by concentrating efforts on application design, modeling the application independently from the platform, and automatically generating the code for several platforms. In this paper, we propose an MDD approach that makes it possible to model context-aware applications independently from the platform. In order to be able to apply this approach, we propose a UML profile that allows designers to model the contexts that impact an application and the variability of the application according to this context. The application is modeled independently from the complex and heterogeneous mechanisms that are required to acquire context information and to perform adaptations. These mechanisms are approached step by step for more model extensibility and reusability in several platforms. The defined platform independent models (PIMs) can be automatically mapped to several platforms through the definition of automatic transformations. The transformations we use have a more general sense of separation of concerns than just pure technical concerns by separating non-functional concerns from the functional application concerns. The paper is organized as follows. Section 2 gives an overview of the phases of our MDD Approach. This approach is detailed phase by phase in Sections 3 to 7. Section 8 describes the implementation of our approach. Section 9 discusses related work. The paper concludes in Section 10.

2

Phases of an MDD Approach for the Development of Context-aware Applications

An MDD-based project includes several preparation activities that structure and plan the work. These preparation activities enable knowledge reuse, which is one of the main benefits of the MDD. We propose six phases in order to follow

an MDD methodology for the development of a context-aware application (see Figure 1). These phases are described as follows:

Fig. 1. MDD Phases for the Development of Context-aware Applications

1. Identification of the required context information: this phase aims at modeling context information that can have an impact on the application. Several context elements have to be specified during this phase, such as the context types, the required context quality, and the specification of the collection process. These specifications must be made independently from the platform that will be used to collect context information. 2. Definition of the application variability: this phase aims at specifying how the application can adapt to the context. It consists in defining structure, behavior or parameters of the application that will vary according to context. The result of this phase is a model of how the structure, the behavior or the parameters of the application need to be changed, specified independently from the platform that will be used to perform the adaptation activities. 3. Identification of the context collection mechanisms: this phase aims at defining an abstract model of the platform that will be used to collect context information. It consists in specifying the mechanisms required for the collection of the context elements that were specified in the first phase. The defined abstract platform model allows designers to determine the concrete context platform that will be used. 4. Identification of the adaptation mechanisms: this phase aims at defining an abstract model of the platform that will be used to perform the adaptations. It consists in specifying the required mechanisms that will make the adaptations that were specified in the second phase.

5. Definition of the target platform and model to model transformations: once context collection mechanisms and adaptation mechanisms are identified, the designer can specify the concrete target platform and use model transformations to automatically generate more concrete models. These transformations must be defined step by step for more modularity and reusability. 6. Code generation: this phase aims at defining model to code transformations that take the concrete models generated in phase 5 as input and generate code. These phases allow designers to approach the concrete context platform and adaptation platform step by step and provide more reusability. Phases 1 and 2 can be performed in parallel. Phase 2 can help in determining the contexts that impact the application. Designers of context-aware applications need specific solutions and formalisms to assist them in performing the phases we mentioned above. Since only development tools have been already proposed for context-aware applications, we propose a UML profile that allows the designers to apply this MDD approach. We chose to extend UML rather than creating a new modeling language because UML is a standard that is used by a large software engineering community. This profile allows the existing UML practitioner community to embrace our approach without giving up their existing modeling environment and process. It also allows the context-aware applications designed by this profile to be integrated with existing UML-based software without special difficulties. In order to illustrate the various phases of our approach we use an example of an online shopping application. The application consists of a Graphical User Interface (GUI), a Data Base (DB), a Local View (LV) and a Cart. The DB contains information about the items, i.e. their characteristics and prices. The GUI allows the users to visit the store’s departments and to choose the items they want to buy by putting them in the Cart. When the user asks to buy something, the GUI is connected to the DB of the nearest store. The LV provides a view of a distant DB, on the user’s device. The LV contains only information related to some departments which are selected by the user. The LV is useful only if the network connection can be lost or when the user wants to work in a disconnected mode in order to save money. In the following sections we detail the various phases we mentioned above and for each phase we describe the UML profile elements that play a role in this phase.

3

Identification of the required context information

Not all applications are sensitive to the same types of contexts. Consequently, the first step that a designer has to perform is to identify the types of context information that can impact the application, and to specify the requirements of the application in terms of their collection process. The specification of the

collection process consists in defining how each type of context information must be collected i.e. to specify if the collection has to be performed synchronously or asynchronously, the frequency, and the quality attributes of the collection. The result of this phase is a platform-independent model of the context collection process. Figure 2 presents the elements of the context-aware profile we propose that allow a designer to specify such a model. These elements are defined in the StaticContextIdentification package. They extend the UML class diagram. The stereotypes are defined as classes stereotyped with >. UML metaclasses are defined as classes stereotyped with >. Tagged values are defined as attributes for the defined stereotypes. The elements of the staticContextIdentification package are as follows: – The > stereotype describes the context type, such as the location zone of the user, network bandwidth, and user preferences. It permits to determine the context sources that will be used to collect this information once the context-aware middleware has been chosen. – The > stereotype represents the elements necessary to collect the context, such as the starting time of collection, collection duration (e.g. three hours), number of samples (e.g. 100), and freshness which specifies how recent the context data must be. This stereotype is abstract, and it is used only to define the common tags of two types of context collections: event-based collection (defined by the > stereotype) and periodic collection (defined by the > stereotype). The event tag indicates the condition that must be satisfied by the context before a new context value is returned. The period tag indicates the rate at which context data should be collected. – The > stereotype represents the quality attributes that must be satisfied by the context such as the accuracy, the precision, the correctness, and the levelOfTrust. – The > stereotype makes it possible to specify the relevant context states that have an impact on a given application in order to be filtered. The base tags of an > stereotype represent the context type, an operator, and a particular value of the context. The binary conjunction and disjunction relationships between elementary context states and context states is specified by means of associations with the > and > stereotypes, respectively. All the context elements mentioned above are important for the collection of context information and the identification of the context states that are relevant to the adaptation process of a given application.

4

Definition of the application variability

Apart from the context information to which the application is sensitive, the application designer has to specify how the application can adapt to the context. We can distinguish three types of adaptation:

Fig. 2. Extensions of the UML class diagram to model the context

– Structural adaptation consists in extending the structure of the application by for example adding or deleting methods or attributes to and from objects. – Architectural adaptation consists in adding and deleting components or objects to and from an application according to context. – Behavioral adaptation adapts the behavior of the applications’ elements. In this section, we explain how a designer can model an application adaptation independently from the platform by presenting the elements of the UML profile we propose in order to model the three types of adaptation. 4.1

Structural Adaptation

In order to support structural adaptation we extend the UML class diagram. Each class whose structure is able to vary will be defined by an abstract class and a set of subclasses which represent its different possible versions. The abstract class will be defined with the stereotype > and each subclass will be defined with the stereotype >. An object can be instantiated from one of the subclasses according to the context. The tag contextStateIds is applied to the classes stereotyped with > in order to specify in which context states a given subclass version is used to instantiate an object. This contextStateIds represents a set of identifiers of relevant context states that have already been specified by the designer (see Section 3).

Figure 3 shows the class diagram of the online shopping example. The GUI is defined as an abstract class with two concrete subclasses: GUILastCart and GUIDiscount. The GUIDiscount allows users to display special discounts. It is used when the user is subscribed to the online shopping service. The GUILastCart enables users to display the contents of the Cart they used last time. The GUILastCart is used when the user has already used online shopping at least once and has preferred to store his Cart. The GUI will be instantiated from one of these subclasses according to the user context (user type: subscribed or not, user preference: wants to reuse his cart or not, user history: has already used the service or not). When several context states associated with different subclasses are satisfied, a new subclass that represents a disjunction of the attributes and the operations of these subclasses is generated during the model transformation in order to be used in the instantiation process. For example, when the user has a saved Cart and he is subscribed to the service, a new subclass that provides each of the displayLastCart() and the displayDiscounts() operations will be dynamically defined.

DataBase

GUI Cart

logIN() : void purchase() : void displayCart() : void displayItems() : void saveCart() : void

selectItems() : void selectView() : void storeCart() : void

putItems() : void

{contextStateIds={nearDisconnectedZone,disconnectedModePreference }} LocalView

selectItems() : void newOperation() : void

{contextStateIds={"hasLastCart"}} GUILastCart

displayLastCart() : void

{contextStateIds={subscribedUser}} GUIDiscount

displayDiscounts() : void

Fig. 3. Example of Structural and Architectural Adaptation

4.2

Architectural Adaptation

In order to support architectural adaptation we extend the UML class diagram with the > stereotype. This stereotype specifies the option-

ality of an object. To specify in which context states an optional object has to be instantiated in an application, we associate a tag contextStateIds to the class stereotyped with >. This contextStateIds tag represents a set of identifiers of context states that have already been specified by the designer (see Section 3). The LV class in Figure 3 is defined with the stereotype >. This class will be instantiated in the application only when the network connection can be lost (expressed with the context state nearDisconnectedZone that indicates that the user is located near to a disconnected zone) or when the user prefers to work in a disconnected mode (expressed with the context state disconnectedModePreference). 4.3

Behavioral Adaptation

Since behavioral adaptation impacts the dynamic aspect of an application and the UML sequence diagram models this dynamic aspect, we propose to extend the UML sequence diagram. For this purpose, we introduce two stereotypes > and >. > is associated with interactions which are variable according to the context. For a given context, only one interaction variant defined by the stereotype will be present in the derived sequence diagram. The different variants of one variable interaction are defined by a > stereotype. This stereotype is tagged by the contextStateIds tag in order to indicate the context states in which each interaction variant will be executed (see Section 3). The optionality of the objects is specified using the stereotype >. Figure 4 shows an excerpt of the purchase sequence diagram. It illustrates the variation of the select interaction. The user can select an item from a LocalView or a distant Data Base according to the users location zone. The LocalView line is defined as optional. 4.4

The Adaptation Profile Structure

Figure 5 presents the adaptation aspects of the context-aware profile we propose. The extensions proposed for class diagrams are defined in the StaticAdaptationAspect package and the extensions proposed for the sequence diagrams are gathered in the DynamicAdaptationAspect package. Each of the > and > stereotypes are applied to the Class metaclass. The > stereotype inherits from the > stereotype, which means each version is a variable structure. The > stereotype is applied to the Lifeline metaclass and the > stereotype is applied to the Interaction metaclass. The > stereotype inherits from the > stereotype, which means each sequence variant is a variable sequence. All the profile elements we described in this section allow designers to create a PIM adaptation model in the second phase. The goal of the first and the second

sd purchase



u:User

g:GUI

d:DataBase

l:LocalView

c:Cart

purchase()



sd select

{contextStateIds={"connectedMode"}} selectItems()

{contextStateIds={"disconnectedModePreference","nearDisconnectedZone"}} selectView() selectItems()

putItems()

Fig. 4. Example of Behavioral Adaptation

Fig. 5. UML extensions for adaptation modeling

phases is to model the required context and the adaptation of the application independently from the platform. The goal of the third and fourth phases is to step by step approach the platforms that will be used to collect context and to perform adaptations by defining the mechanisms they require. We describe phase three in Section 5 and phase four in Section 6.

5

Context Collection Mechanism Requirements

The goal of the first phase is to model the required context independently from the platform. The role of this third phase is to approach the platform that will be used to collect context by defining an abstract model of this platform (see Figure 1). During this phase, designers identify the mechanisms and the technologies required for the collection of contexts that were specified in the first phase and specify the types of sensors that are necessary for that purpose. According to [3], sensors can be classified in three types: – Physical sensors: represent hardware sensors capable of capturing physical data, such as photodiodes to capture light, microphones to capture audio, and biosensors to measure skin resistance or blood pressure. – Virtual sensors: these sensors collect context data from software applications. For example, it is possible to determine the activity of a person by browsing his electronic calendar. – Logical sensors: these sensors use several context sources, and combine physical and virtual sensors with additional information in order to derive higher level context. They can interpret and reason about context information. Figure 6 shows the StaticContextM echanisms package of our context-aware profile. This package includes the UML class diagram extensions necessary for the specification of context collection mechanisms. These extensions are defined as follows: – The > stereotype describes the required properties of a sensor, such as its location or its quality attributes as well as its configurable parameters. This stereotype is abstract, and represents the three types of sensors: physical, virtual and logical. – The > stereotype represents a physical sensor. For this type of sensor, the designer has to specify the type of physical sensor and the technology used. – The > stereotype represents a virtual sensor. For this type of sensor, the designer has to specify the software entity that will be used to collect context. – The > stereotype represents a logical sensor. For this type of sensor, the designer has to specify the software entity that will reason about the collected context information, but he has also to specify which context sensors will be used by this logical sensor in order to aggregate

Fig. 6. UML Class Diagram Extensions for Modeling Context Collection Mechanisms

context information. The relationship between a logical sensor and another sensor that collects coarse context information is specified by an association with the > stereotype. – All sensors are related to the context types they collect by an association with the > stereotype.

6

Adaptation Mechanism Requirements

The goal of the second phase is to model the adaptation of the application independently from the platform. The role of this fourth phase is to approach the platform that will be used to perform adaptations by defining an abstract model of this platform. During this phase, designers identify the mechanisms that are required to adapt the application as specified in the second phase. Among the existing adaptation mechanisms we can mention reflection, aspect oriented programming, contracts, and the component-based paradigm [4]: – Reflection is the capacity of a system to observe and to modify itself [5]. Observation is the mechanism of introspection and modification is the mechanism of intercession. Reflection distinguishes two levels, the first level is dedicated to adaptation management and the second level includes the application. – Aspect-oriented programming enables developers to build applications by separating functional from non-functional aspects of the application. These aspects are combined using pointcuts and weaving [6]. To develop adaptive applications using this approach, the adaptation process is implemented as non-functional aspects. – Contracts enable developers to specify constraints to be satisfied by context, so that the application behaves as expected [7]. They also allow developers to describe adaptation policies without hard-coding these into the adaptation process. Policies are described in a file that is interpreted by an adaptation process, and can be loaded and unloaded at run-time. – The fourth major technology supporting adaptation is component-based design. Software components are software units that third parties can independently develop, deploy, and compose [4]. The developer can add, remove, or reconfigure components within an application at runtime. In this phase, the designer specifies for each class stereotyped with > or > and for each interaction stereotyped with > (see Figure 5) the various mechanisms that can be used to achieve the adaptation. These mechanisms can be specified by using the following profile elements (see Figure 7): – The stereotype > describes an adaptation mechanism in a UML class diagram. – The stereotype > describes an adaptation mechanism in a UML sequence diagram.

Fig. 7. UML Extensions for Modeling Adaptation Mechanisms

– All the specified adaptation mechanisms are related to the classes they have to adapt by an association with the > stereotype. Since it is possible to associate several possible adaptation mechanisms with only one variation point, the stereotypes > and > have a conditions tagged value that allows the designer to specify in which conditions a mechanism can be used. The third and fourth phases approach the platforms that will be used to collect context and to perform adaptation without specifying technologies that are specific to a given platform. This intermediate step between the definition of the PIM and the definition of the concrete platforms allows a designer to identify efficiently the various platforms that are possible to use. Moreover, the defined abstract platforms permit the definition of intermediate transformations (from the PIM to these abstract platforms) that can be reused for several PSM transformations.

7

Definition of the target platform and model to model transformations

The goal of this phase is to identify the target platform and to transform the platform independent models defined in phases 1 and 2 to more concrete models according to the mechanism requirements specified in phases 3 and 4. Model transformations can provide a more general sense of separation of concerns than just pure technical concerns [8] by separating non-functional concerns, such as distribution, security, and transactions from the functional application concerns. In this case, it is not practically attainable to implement all the concerns in one single transformation. Besides splitting up transformations according to technical concerns (a separate transformation for each PSM), we

should decompose transformations according to non-functional concerns. Ideally, each transformation should address only one non-functional concern so that it becomes easy to implement and to reuse. As a result, we get a chain of transformations that need to be applied subsequently to weave all non-functional concerns into the application model. In this phase, the designer first has to define the abstract transformations that transform the models without introducing technical details. Then he has to define more and more concrete transformations that generate concrete platform-specific models. Consequently he will first define the non-functional transformations. Then he will identify the target platform. Finally, he will specify the technical transformations. In the following, we describe each of these steps. 7.1

Non-functional Transformations

In this step, the designer has to identify the non-functional services required by the application that must be provided by the underlying middleware, such as distribution, security, remote data access, deployment, etc. In the case of context-aware applications, these services are also required to be adaptive. Our goal is to automatically generate the variability models of these non-functional services so designers are relieved from specifying this variability. For this purpose, transformations of the application variability that was specified in the second phase (see Section 4) have to be defined. These transformations generate variability models of non-functional services that are still platformindependent. In Section 8 we give an example of this stype of transformations. 7.2

Definition of the Target Platform

Once context collection mechanisms (see phase 3), adaptation mechanisms (see phase 4), and required non-functional services are identified, the designer can study the existing context and adaptation platforms and choose the one that best satisfies the requirements in terms of these mechanisms. 7.3

Technical Transformations

In this step, the designer specifies the PIM to PSMs transformations that will transform the abstract models defined throughout the phases of the MDD approach into concrete models that are specific to the chosen context platform and adaptation platform respectively. The generated variability models of the non-functional services also need to be transformed according to the services provided by the chosen underlying middleware.

8

Implementation

As a proof-of-concept, we made an implementation of the UML profile and the model transformations presented in this paper.

The Context-Aware Profile was implemented using MagicDraw UML 12.0. In order to explore our approach, we followed the MDD phases we described in this paper, to model the online shopping application by using our ContextAware profile. We chose The Context Toolkit [2] as a context target platform and CARISMA [9] as an adaptation target platform. We extended the CARISMA XML encoding of application service request to be able to support extended non-functional service description and context types. Model to model transformations are implemented using ATL [10]. As an example of a non-functional transformation, we implemented a transformation that transforms an application variability model such as the one described in Figure 3), into a deployment service variability model. In Figure 8 we give an excerpt of these transformation rules in ATL (some details in the code have been left out for clarity). These rules perform the following transformations. – A class stereotyped with > is transformed into a > interaction having two sequence variants. (1) The first variant is tagged with the same context states as the transformed class, mentioned in the tagged value contextStateIds, and includes an instantiateComponent() message. (2) The second variant is tagged with the negation of these context states, and includes a deleteComponent() message. – A class stereotyped with > is transformed into a > interaction fragment, having several sequence variants. (1) The number of sequence variants represents the number of versions of the transformed class. (2) Each sequence variant matches one version of the class and is tagged with the same context states as the transformed class version, mentioned in the tagged value contextStateIds. (3) Each sequence variant includes an instantiateVersion() message whose parameter indicates the class version to be used during the instantiation. Using these non-functional transformation rules, the application variability model given in Figure 3, was transformed into the deployment service variability model given in Figure 9. This deployment service behaves as follows. It instantiates all the classes stereotyped with > as soon as the context states, mentioned in the tagged values contextStateIds associated with these classes, are satisfied. In the same way, it deletes these objects when the relevant context states are not satisfied. Classes stereotyped with > indicate that only one version of this class will be instantiated. As an example of a technical transformation, we implemented a transformation that transforms the deployment service variability model generated using a non-functional transformation, into a variability model specific to the CARISMA adaptation platform. The transformation we implemented in ATL is a UML to XML transformation, that transforms the service variability model into a CARISMA XML encoding of application service request. This model will be used by the CARISMA middleware in order to perform adaptations. An excerpt of this transformation is given in Figure 10. By applying our approach, we generated almost all the Java code of the online shopping application using MagicDraw 12.0. This approach simplifies the

Fig. 8. Example of non-functional transformation written in ATL

a:Ap

ff:Middleware

d:DeploymentService

deploy()



{contextStateIds={nearDisconnectedZone,disconnectedModePreference}}

instantiateComponent(LocalView)

{contextStateIds={nearconnectedZone,connectedModePreference}} deleteComponent(LocalView)

{contextStateIds={hasLastCart}} instantiateVersion(GUI, GUILastCart)

{contextStateIds={subscribedUser}}

instantiateVersion(GUI, GUIDiscount)

Fig. 9. Generated Deployment Service Variability Model

Fig. 10. Example of UML to XML transformation written in ATL

tasks of application designers and developers and saves time, by relieving them of specifying the adaptation of non-functional services, and automatically generating the code for several platforms without having to worry about technical details. However, both non-functional and technical transformations are difficult to write. The UML profile we propose does not support any intelligence that can deduce automatically new adaptation rules. Designers have to imagine all the possible adaptations according to the context.

9

Related Work

Several context models have been defined, such as the key-value pairs [11], the object-oriented model [12], the sentient object model [13], and the models based on ontologies [14]. The aim of these models was to provide a high level abstraction of context information in order to store, manage, and process the context, but no solution has been proposed in order to model context-aware applications and their adaptation according to this context. The majority of existing work has proposed solutions to simplify the complicated development of context-aware applications without tackling the problem of their modeling or defining a complete process to model and develop them. These existing solutions consist in middleware and frameworks that enable context collection and that can even provide adaptation mechanisms. The most consistent attempts at developing reusable solutions for context acquisition, interpretation, and rapid prototyping of context-aware applications is context Toolkit [2, 15], SOCAM [16], CoBrA [17], CASS [18], and CORTEX [19].

Among middleware solutions that allow the developers to implement adaptation mechanisms we can mention CARISMA [9], K-Components [20], ReMMoc [21], OpenORB [22], CORTEX [19], and RAM [23]. The advantage of the existing context-aware middleware consists in enabling the separation of context management and processing from the development of applications. They play a significant role in simplifying the development of context-aware applications by implementing the mechanisms that collect and interpret the context as well as the mechanisms that adapt the application to the context, but introduce several technical details in the developed applications and reduce their portability. [24] proposes a UMLbased solution to design context-aware web services. [25] is another modeling approach that includes an extension to the ORM (ObjectRole Modeling) by context information. This approach allows developers to program with context at a high level without the need to consider issues related to context collection. These works are focused on context modeling and do not support adaptation aspects. The MDD approach we propose in this paper defines a complete process that covers all the production phases of context-aware applications. This approach specifies how to model the applications independently from the platform and how to automatically generate its code by using step by step transformations.

10

Conclusion

Design and development of context-aware applications is particularly complex. They require the identification of the context information that has an impact on the application and the specification of the various behaviors of the application according to this context information. In this paper, we propose an MDD approach that enables the concentration of efforts on applications design and their modeling independently from the platform. This platform independence hides the complexity and the heterogeneity of the context-aware and adaptive mechanisms. The MDD approach we propose defines phases that cover preparation activities that structure and plan the work. These phases make it possible to first model the contexts that impact an application and the variability of the application according to this context in an abstract manner, and then to approach step by step the mechanisms required to acquire context information and perform adaptations. The step by step approach followed by these phases provides a model extensibility and reusability in several platforms. The MDD approach we propose defines a methodology to model a context collection process and the variability of an application structure, as well as its behavior and its architecture, independently from the platform. The defined platform independent models can be automatically mapped to several platforms through the definition of automatic transformations. The transformations we use have a more general sense of separation of concerns than just pure technical concerns by separating non-functional concerns from the functional application

concerns. In addition to platform specific models they are able to generate the adaptation models of the required non-functional services. In order to be able to apply this approach, we propose a UML profile that allows designers to model context-aware applications. This profile allows the existing UML practitioner community to embrace our approach without giving up their existing modeling environment and process. It also allows the contextaware applications designed by this profile to be integrated with existing UMLbased software. We implemented our approach and applied it on an online shopping application. Through this example we showed that our approach simplifies the tasks of an application designer. The approach presented in this paper saves time by relieving the designer of specifying the adaptation of non-functional services and automatically generating the code for several platforms, without having to worry about technical details related to context collection and adaptations mechanisms. However, the transformations in our approach are complicated to write. In further phases we intend to extend the context-aware UML profile we propose to support ontologies, in order to introduce more intelligence in the modeled context-aware applications by deducing new adaptation rules. We also want to define how to check the consistency of the adaptation rules during the design of applications.

References 1. OMG: MDA Guide version 1.0.1. omg/2003-06-1. (June 2003) 2. Dey, A., Abowd, G., Salber, D.: A Conceptual Framework and Toolkit for Supporting the Rapid Prototyping of Context-aware Applications. Human-computer Interaction 16(2-4 (special issue on context-aware computing)) (December 2001) 97–166 3. Indulska, J., Sutton, P.: Location Management in Pervasive Systems. In: CRPITS 03: Proceedings of the Australasian Information Security Workshop 4. Szyperski, C.: Component Software, Beyond Object-Oriented Programming, 2nd Edition. Addison Wesley Professional (2002) 5. Bobrow, D., Gabriel, R., White, J.: CLOS in Context - The Shape of the Design Space. In: Object-Oriented Programming : the CLOS Perspective, MIT Press (1993) 6. Kiczales, G.: Aspect-Oriented Programming. surveys 28A(4) (December 1996) 7. Meyer, B.: Applying design by contract. In: IEEE Computer. (1992) 40–51 8. Vanhooff, B., Ayed, D., Berbers, Y.: A framework for transformation chain design processes. In: First European Workshop on Composition of Model Transformations - CMT 2006 9. Capra, L., Emmerich, W., Mascolo, C.: CARISMA: Context-Aware Reflective mIddleware System for Mobile Applications. IEEE Transactions on Software Engineering 29(10) (October 2003) 929–945 10. Jouault, F., Kurtev, I.: Transforming models with atl. In: Proceedings of the Model Transformations in Practice Workshop at MoDELS 2005 11. Schilit, B., Theimer, M., Welch, B.: Customising mobile applications. In: Proceedings of USENIX Symposium on Mobile and Location-Independent Computing. (August 1993) 129–138

12. Henricksen, K., Indulska, J., Rakotonirainy, A.: Modeling context information in pervasive computing systems. In: Pervasive 2002, Zurich, Switzerland (2002) 167–180 13. Harter, A., Hopper, A., Steggles, P., Ward, A.: The anatomy of a context-aware application. In: Mobile Computing and Networking. (1999) 59–68 14. Preuveneers, D., Berbers, Y.: Semantic and syntactic modeling of component-based services for context-aware pervasive systems using owl-s. In: First International Workshop on Managing Context Information in Mobile and Pervasive Environments. (2005) 30–39 15. Dey, A.: Understanding and Using Context . Personal and Ubiquitous Computing Journal 5(1) (2001) 4–7 16. Gu, T., Pung, H.K., Zhang, D.Q.: A Middleware for Building Context-aware Mobile Services. In: IEEE Vehicular Technology Conference (VTC), Milan, Italy (2004) 17. Chen, H.: An Intelligent Broker Architecture for Pervasive Context-Aware Systems. PhD thesis, University of Maryland, Baltimore County (2004) 18. Fahy, P., Clarke, S.: A Middleware for Mobile Context-aware Applications. In: Workshop on Context Awareness, MobiSys 2004 19. Sorensen, C.F., Wu, M., Sivaharan, T., Blair, G.S., Okanda, P., Friday, A., DuranLimon, H.A.: A Context-aware Middleware for Applications in Mobile Ad Hoc Environments. In: Middleware for Pervasive and Ad-hoc Computing. (2004) 107– 110 20. Dowling, J., Cahill, V.: The K-Component Architecture Meta-model for SelfAdaptive Software. In: Reflection 2001. (2001) 21. Grace, P., Blair, G.S., Samuel, S.: ”remmoc: A reflective middleware to support mobile client interoperability”. In: International Symposium on Distributed Objects and Applications(DOA), Catania, Sicily, Italy (November 2003) 22. Blair, G.S., Coulson, G., Robin, P., Papathomas, M.: An Architecture for Next Generation Middleware. In: Proceedings of the IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing, London (1998) 23. David, P., Ledoux, T.: An Infrastructure for Adaptable Middleware. In: DOA’02, Irvine, California, USA, Springer-Verlag (October 2002) 24. Sheng, Q.Z., Benatallah, B.: ContextUML: A UML-Based Modeling Language for Model-Driven Development of Context-Aware Web Services. In: The 4th International Conference on Mobile Business (ICMB05). (2005) 25. Hendricksen, K., I.J., Rakotonirainy, A.: Generating context management infrastructure from high-level context models