Intermediate Common Model—The Solution to Separate Concerns and Responsiveness in Dynamic Context-Aware System

Nowadays, many works are interested in adapting to the context without taking into account neither the responsiveness to adapt their solution, nor the ability of designers to model all the relevant concerns. Our paper provides a new architecture for context management that tries to solve both problems. This approach is also based on the analysis and synthesis of context-aware frameworks proposed in literature. Our solution is focus on a separation of contextual concerns at the design phase and preserves it as much as possible at runtime. For this, we introduce the notion of independent views that allow designers to focus on their domain of expertise. At runtime, the architecture is splitted in 2 independent levels of adaptation. The highest is in charge of current context identification and manages each view independently. The lowest handles the adaptation of the application according to the rules granted by the previous level.


Introduction
Today, it is essential that software applications are able to adapt to their environment.The vision of Weiser [1] on Ubiquitous computing and works of Dey et al. [2] [3] about context opened the way for a multitude of solutions to this problem.The majority of these solutions (named Auto adaptive system in Fig-  define the adaptation capacities (also call adaptation range) of the application (or provide by the Auto adaptive system).But problems remain with those solutions and in particular if we want to improve the adaptation capacities to take into account new situations or contexts.Indeed, the interest of having an automatic adaptation of an application to the context is to allow the continuity in the services of the user, and that, whatever the context.If we add this to the increasing mobility of users, it is necessary to adapt the applications to all situations of life, whether professional, personal or others.
With this system, if we want to increase the adaptation capacities which are necessary in order to take account of the continuity of user services, we must use more Adaptation Rules to drive the decision process.But this results in: -System takes more time to adapt properly.
-Risk of conflict between Adaptation Rules is also increasing.
Many works have been dedicated to advance the adaptation domain [4]; frameworks [2] [5] [6], methods and techniques [3] [7] [8] [9], principles [10] [11] have already been proposed.However, most of these information focus on solving problems of system at runtime and they do not provide any solution to separate concerns and responsiveness in dynamic context-aware system.Some others suppose to use meta-model [7] [11], in design time that consistently defines related concepts, properties and relationships, establishing a common ground for implementing adaptation.This approach provides a good solution to manage context elements but it makes each expert's task become complicated.
In this paper, we propose an approach called Intermediate Common Model with main purpose that is improving the adaptation capacities of system.Intermediate Common Model uses independent views that will increase the reuse of views between different applications.In addition, we propose to use contextaware management to manage views; it is the solution to separate concerns and responsiveness in dynamic context-aware system.
This paper is organized as follows: Section 2 presents and discuss related work, motivates this research; Section 3 details hypotheses and architecture of system; Section 4 describes Intermediate Common Model; Section 5 applies the results and implementation; Section 6 presents limitation of approach and Section 7 concludes this work and future work.
G. Rey et al.

Related Works and Motivation
We can find many work has been done in the area of context-aware application in the past few year.In this section we present the results or proposals of works that focus on building context-aware application based on models to improve the adaptation capacities of system.
The work has been done by Dey et al. [2] which develop a context toolkit based on composed of sensor to collect information from context.This architecture supports a framework and reusability of components, evolution of applications and the acquisition and use of complex context.The context toolkit provides methods to access to such information, transform the context information into high-level formats that are easier to handle, allow the separation of acquisition process and context representation of the adaptation.However, these systems do not provide solution to use specific views and context management, so it is become complicated to use in large system with the wide range of context.
Henricksen [10] focuses on modeling at the conceptual level using Context Modeling Language, a novel modelling approach which offers a graphical notation and an accompanying modelling methodology for describing context information.A modeling process involving the following steps is assumed: construction of a conceptual model of context requirements using Context Modeling Language; mapping of the conceptual model to the relational model; and generation of a context management infrastructure based on the relational model.This approach use domain independent support on developing contextaware system but it is slightly hindered by the absence of a context modeling editor.
Person is AD [5], is a context-aware framework which builds upon the homogenous modeling of all the entities relevant to supporting ubiquitous applications.In this approach, the model is organized as a tree of model context which contain the components of the model.This framework makes it possible to quickly create new context-aware applications.The Person is AD architecture is based upon a small set of operations for applications to interact with the models: access, ask and tell.The service discovery facilitates distributing the models across various machines across a network.The application writer can simply use these, in conjunction with the active models, to build applications.This approach offers reusing active model in different applications but it does not consider information about the context-aware system behavior.Moreover, they do not provide an solution to replace or change model when the application change during adaptation process.
Costa [12] proposes an integrated solution for development of context-aware system.In this approach, context-aware application behaviors can be described as logic rules, which are called Event-Condition-Action rules that are consistent with the Event-Control-Action pattern.The context processor component gathers context information from the user's environment performs context reasoning and generates context and situation events.The controller Component observes events from context processors, monitors conditions rules, and triggers actions on action performer when the condition is satisfied.This approach provides a solution that facilitates the dynamic configuration and execution of particular application behaviors which based on a rule engine that gathers context and situation values from context processing components.However, this approach was not support solution to separate the management context and adaptation process and no concrete implementation was suggested.
Achilleas, Kun and Nektarios [6] propose a model-driven approach that provides a higher level of automation in software generation.The approach is strictly based on the Model Driven Architecture paradigm and provides the capability to semi-automatically generate service creation environments for different application domains.Hence, the approach and the generic framework are utilized to define and generate the Context Modeling Framework in the form of an Eclipse plug in.The plug in is then integrated into the generic framework, comprising a new software capability.Consequently, merely the modelling, validation and implementation tasks must be carried out for the creation of pervasive services.In addition the capability to generate diverse implementations and deploy pervasive services on different devices is provided.This simplifies the process and enables the rapid creation of pervasive services at the static compile time.Although this approach supports the ATL editor to transfer context to context, they do not provide solution to use independent models which can increase reusability of views.
AOCI [11] proposes programming support for context-aware adaptations that is built upon a semantic model.Their solution is integrated within our Aspect-Oriented Component Infrastructure (AOCI) framework that so far was limited to handle basic annotations using a semantic layer to make AOCI enhanced applications adaptable.They extend this basic support by explicit modelling of the context as well as application-specific domains inside this layer using ontologies of different granularity of abstraction.This mechanism supports context management ability and adapting of application, but they do not propose any implementation or code for development.
TriPlet [4] is structured in three core components: a meta-model is called Context-Aware Meta Model that formalizes and abstracts the main concepts for implementing Context-aware adaptation; a reference frameworkis called Contextaware Reference Framework that provides stakeholder support to define, specify and to decide the design for implementing Context-aware adaptation.It can be used before the implementation phase of an application, as an extensive catalogue to guide developers in taking design decisions, or after the implementation phase of an application, to analyze and to evaluate the concepts that were considered, aiding also to identify underexplored areas for future extensions.; and a design space, Context-aware Design Space that supports stakeholders in analyzing, comparing and evaluating the coverage levels of adaptation for contextaware applications.The major drawback of this approach is that it offers only methodology for building applications.Firstly, with Context model, some requirements are inspired from works in the previous section such as Domain independent [7], Rich and Dynamics context [2], Behavioral and Structural [12].Another important requirement of Context model is "Change and Reuse of views" that is use to improve adaptation ability, simplify expert's work and develop application.The information in Table 1 shows that no any approach suppose all necessary requirements of Context Modeling.Some works use meta-model to represent the static and dynamic aspect of the context.However, in case of applications that using many specific views, the combination of views in meta-model is very complex and the work of each developer is not simple.Moreover, if we want to add, delete or replace views that can't be done either by automatic process.It is motivation to our propose use Intermediate Common Model which can adapt requirement about reusable views and improve adaptation capacity of system.
Secondly, the requirements with architecture of system are defined in works in the previous section such as Adapting of application [7], Context Interpreting and Storage [2], Separate Context Aware Manager and adaptation, Separation of Concerns [12].During adaptation process context can be change and system need Update current context that relate to correctly of adaptations and reduce the decision time of system with application.Responsiveness is ability of system we can conclude that no single approach has the features to address all the issues that were identified.We propose an approach that is usingAuto Adaptive Systemto take care current context without care to manage context.Moreover, it also support the separation of concerns and responsivemess which necessary to improve adaptation capacity.
Thirdly, with requirement about Rapid development and deployment of application [7], our approach use independent common model at design time com- bination with two independent execution cycles of the Context Aware Manager and the Auto Adaptive System at run time which can address all issues with development and deployment of application.

Hypotheses and Architecture of System
When we want to improve the adaptation capacity by use more Adaptation rules (Adaptation Rules) to drive the decision process such mentioned in introduction section.We must solve problem conflict between Adaptation Rules, but solving that problems at design time are even more sensitive to the increased context that we would like to cover and thus increasing the number of rules.More rules, more potential conflicts between them are importance.We must develop automatic methods of detection and conflict resolution.But this is much more difficult to do at runtime.In addition, these methods take, due to their complexity, considerable time.This has the effect of greatly reducing the responsiveness of the process of adaptation to the context.Or if this time is too long, the context may change.Then, we are in a situation where the performed adjustment does not make sense and it is necessary to calculate a new one.This can result in significant disruption of Building on this, we propose here a hybrid approach that will increase the number of Adaptation Rules and thus improve the consideration of the context while ensuring a reasonable time to adapt to the application.
In firstly, we assume that current Auto adaptive systems (Auto Adaptive System) are enough good to manage limited number of situations (defined by a short list of Adaptation Rules).So we make the choice to only manage this Auto Adaptive System by controlling their list of Adaptation Rules, and by relying on them for the adaptation functions.
We get architecture (as shown in Figure 2 While this is not the object of our study, it is also desirable that the Auto Adaptive System proceeds in the same way, i.e. the life cycle and the operation of the application are independent of the adaptation process.Thus, the application can continue to operate during the decision stage (calculating adaptation functions) and is interrupted only during the implementation of the adaptation plan.
Secondly, we assume that address challenges of context awareness means managing various views.By views, we mean different concerns taken into account in the design of an application as business processes, privacy, human tasks, security, etc.
Few studies take into account different views and most focus on the contextualization of one view (e.g. by extending the business process [13]).Or, the views are not managed independently and are mixed in a single model: the model of context [7].
But like we say in introduction, it is very difficult to produce at design time a unique model including all views.Therefore, we believe that each expert should be able to work on his domain of expertise independently of others experts.For Figure 2. The runtime architecture model.
example, a domain expert can produce a BPMN [14], an ergonomist produces scenarios [15], whereas a security expert can focus on others specific models [12].
And we must be able to dynamically combine these views in them during the application runtime.
Figure 3 presents the design part of our architecture.It preserves the independence of the different views during the design.
In view of the diversity and unpredictability of developments in ubiquitous environment, to solve conflict between Adaptation Rules at design time does not reasonable today.Because it would mean that designer should able to evaluate all the possible combinations (between Adaptation Rules) that could meet a user.
Indeed, if we analyze the company's business processes, we quickly see that they only cover the nominal case.Unexpected situations, such as their qualifier suggests, are not taken into account.
The reason for this is that the analysis and context modeling is currently global way.Designers define a single large model of context, which still has the advantage of resolving conflicts as possible during the design phase.But making the task long, tedious and even impossible if we increase significantly the context we wish to support.
Instead, each expert can specify its own view, without having to know the views specified by the other experts.In fact, the work of each expert is simpler and can therefore be described in more detail without increasing the working time.
In addition to ease of modeling, we believe that the separation into independent views will increase the reuse of views between different applications.
We associate a set of views based on adaptive capacities that we want to provide to our application.This set may change over time (add, delete or replace views).This can be done either by automatic process or by the end user and without the need to bring in an expert.

Intermediate Common Model
We currently introduce an intermediate common model (Intermediate Common

Intermediate Common Model Description
In design time, the developer must transform each special view into XML description to provide data for Context Aware Manager. Figure 4 shows overviews of Intermediate Common Model approach in design time.
The input of each Intermediate Common Model is a special view such as BP-MN, Scenario, etc.The Intermediate Common Model is an XML description of a Moore automaton described by the following 6-tuple (S, S0, Σ, Ʌ, δ, λ): -S is a finite set of states.
-Σ is an input alphabet defined as a finite set of predicates used to identify the states in S. N predicates leads a maximum of 2N possible states.
-Λ:Λ → (Ω, φ ) is an output alphabet defined as a pair of finite Adaptation Rules sets.The first set Ω contains observation rules used by Context Aware Manager for its observation i.e. the evaluation of Σ predicates.The second set φ contains the application rules that will be deployed on Auto Adaptive Sys- tem as shown in Figure 1.
-δ:S x Σ → S' is a transition function mapping a set of state S and the input alphabet Σ to the next set of state S'.
-λ:S → Λ is an output function mapping each set of state S to the output alphabet Λ. Relying on XML extensibility property, the Common Model does not require the type of adaptation rules that it contains the description.Similarly, it allows you to specify different way predicates and therefore how the Context Aware Manager will perform observation.
The goal was to build a model flexible enough to support our various experiment -Figure 5 shows graphic of XML schema that uses to define Intermediate Common Model.

Example
We use two different views Security and Process to analyze information from the worker and then active status of Tool and display Worker's task.With P is authenticate from worker and S is a finite set of states, we have: -In view: Security.

Context Definition
In summary, we distinguish the design time from the runtime.
-At design, designers independently write views that correspond to the contextual concerns of each of these designers.Each view decomposes into a set of states defined by a set of predicates specific to each view.In each state, we also associate a list of adaption rules to adapt the application to the current state?-At runtime, the evaluation of the predicates of each of the views makes it possible to identify the current situation (i.e. the set of current states of each view).
Depending on this situation, a list of adaptation rules will be applied.
It can then be said that the context is the set of possible situations for a given set of views.
Our context definition therefore does not approach this notion according to the type of entities or attributes observed but rather as a set of photographs of the elements components world where the applications designers have the freedom to observe what interests them depending on their concerns.

Application and Current Implementations
Our implemented solutions are based on an auto adaptive system, named W-Comp.This Auto Adaptive System supports the adaptation of application during runtime depending on the presence or absence of devices [8].A performance model is available in [16], allowing to estimate the responsiveness of the adaptation based on the number of rules deployed by the Context Aware Manager.
The current Context Aware Manager implementations support an independent way of management views.Each view is described according to Context Model.Context Aware Manager is able to set up observations mechanisms to identify the current situation (via predicates described in the Context Model).Once the situation of each view, identified, it deploys all the relevant Adaptation Rules on the Auto Adaptive System.The Auto Adaptive System is in charge of enforcing the rules when it can and managing conflicts that could occur [17].

First Solution
We have focused on our currents explorations on observation part.Our first Context Aware Manager implementation (Figure 6), used in the project ANR CONTINUUM [18], is based on a knowledge base for evaluating predicates.The predicates are then modeled inside the Context Model as SP Adaptation Rules QL queries whose answer is true or false.The knowledge base is in charge of observing the environment, to infer new knowledge and responding to requests from Context Aware Manager.
The problem with this solution is the need to lock the knowledge base during the evaluation of predicates so as to have answers based on the same knowledge.
However, during the lock, the base does not update its knowledge (that is the purpose of the lock).But this causes problems if you want to share the base between several Context Aware Managers, the base may be locked continuously.

Current Solution
After several experiments on modeling of predicates, we have taken up the idea of contextual observation chains that introduced by Rey [8].Each predicate is an application modeled by way of an assembly of components.Context Aware Manager (Figure 7), to set up his observation will deploy an application for each predicate that it wants to evaluate.During this deployment, the Context Aware Manager set how it wants to receive the evaluation of the predicate (requests, notifications ...).To do this we rely on our WComp framework.
Two solutions are then possible: -Either a single container is used for all applications, simplifying management for Context Aware Manager and saves resources.
-Or each application has its own container, simplifying the sharing of applications (thus predicates) between different Context Aware Manager.
The advantages of this solution are many.
-First, there is no central point of failure as was the case with the knowledge base.
-Second, the sharing of observation mechanism in several Context Aware Managers is facilitated.Because each predicate is managed independently, the lock is not necessary.But the Context Aware Manager needs to manage data synchronization.
-Finally, as we used our WComp framework for the creation of applications, we can make them benefit from its capacity for self-adaptation.Each application is able to adapt to variations of the devices in the environment.This improves observation by making it more robust.

Limitation
The current work is based on few assumptions that could be seen as limitations.
We estimate that all the thinking models (views) used at design time can be projected in our context model.To validate this, we must experiment with other views and evolve our intermediate common model according to these experiments.For now, we only carried out some tests and experimentally validated the On the other hand, the current approach strongly links the state of a view (the current situation) with the rules to be deployed (adaptation rules).Our first experiments (carried out in the projects mentioned above) showed that the designers of the views are not able to write these rules.That is why we are interested in the intentional approach.The aim would then be to associate intent with a state of a view and to be able to rediscover the adaptation rules to be implemented according to the set of intentions identified as required.

Conclusions and Future Work
This article presents a new architecture for context management using independent view models to design specification and using 2 independent levels of adaptation at runtime.
Preserving the independence views at design time, this approach simplifies the work of designers and increases the reusability of views between different applications.
At runtime, the use of two independent levels, this allows Auto Adaptive System to focus on the adaptation of the application without sacrificing responsiveness, whereas, at the same time, Context Aware Manager focuses on identifying the current context to change the behavior of Auto Adaptive System.
In the future, we will rely on our experimental results to develop our model.
These changes aim to ease the transition from specific expert models and to detect and to resolve possible conflicts between views or Adaptation Rules by the Context Aware Manager.

ure 1 )
Figure1, and take their decision based on the set of rules (or equivalent) which

Figure 1 .
Figure 1.Classical model of Auto adaptive system.

Figure 3 .
Figure 3.The design architecture model.

Figure 4 .
Figure 4. Overview of design time.

Figure 6 .
Figure 6.Our first solution of Context aware manager.

Figure 7 .
Figure 7.Our current solution of Context aware manager.
[7]SDA[7]provides architecture of context-aware framework which is formed of two parties.It describes the development process of a context-aware application by the developer in design time for it is consistent with us framework in run time.In the other hand, it describes the architecture of this framework in run time.In design time, the developer must build a context model of its application to be consistent with meta-model and follow a set of steps guided by mechanisms and tools to generate at the end a context-aware application integrated in the CAISDA framework.In runtime, when the user launches the application, it must be able to capture and to interpret the context elements possible to change during the application execution.This approach is good with applications which use single view but with applications use many different views, the analyze context will become complicate and take more time.
They have offered neither implementation nor code nor development or configuration mechanisms to help programmers to develop applications.G. Rey et al.

Table 1 .
Comparison Context-model of current context-aware frameworks.adjustquickly to suddenly alter external conditions, as of the changing of current context applications, add or delete views without undue delay.Most of worked propose solution to update current context, but the combination of management, analysing and selecting context elements at run time can make conflict between different applications.Table2summarizes all supporting of literature mentioned with requirement of architecture system.Based on the analysis information provided in Table2, to

Table 2 .
Comparison architecture of current context-aware frameworks.
) where a new Context Aware Manager has been introduced to manage the Auto Adaptive System.In addition to managing the list of Adaptation Rules to be deployed on the Auto Adaptive System, this architecture preserves the independence of the execution cycle of the Auto Adaptive System.The execution cycles of the Context Aware Manager and the Auto Adaptive System are independent.This allows the Auto Adaptive Sys- tem to take care of changes in the current context.As the Context Aware Manager handles, depending on its own rhythm, context switching requires Auto Adaptive System reconfiguration.