Using Aspects and Dynamic Composition to provide Context-Aware Adaptation for Mobile Applications† Flavia C. Delicato DIMAp - Federal University of Rio Grande do Norte (UFRN) Campus Universitario Lagoa Nova Natal – RN – Brazil +55 84 32153815
Isanio L. Araujo Santos, Paulo F. Pires, Ana Liz S. Oliveira, Thais Batista
[email protected]
DIMAp - UFRN
[email protected] {paulo.f.pires, analiz, thaisbatista}@gmail.com
Luci Pìrmez Núcleo de Computação Eletrônica Federal University of Rio de Janeiro Brazil Postal Box 2324 +55 21 25983214
[email protected]
ABSTRACT
as different development approaches and support platforms.
Mobile systems characterize by dynamic environments, thus requiring adaptive and context aware mechanisms to perceive changes in the execution context and to dynamically adapt to them. We propose a framework for developing adaptive context aware applications which employs aspect-oriented techniques and dynamic composition to modularize the adaptive behavior and to keep apart the application logic from this behavior.
The development of context-aware adaptive applications is complex, since the adaptation code, which implements the adaptive behavior, is often tangled with the application functional code, which implements the business logic. Due to the tangled phenomenon, the code responsible for the adaptation process tends to be scattered among several components of the system, characterizing a crosscutting behavior [9]. The crosscutting behavior negatively affects several attributes of the software system as its modularization and maintainability. The AspectOriented Software Development provides a paradigm for modularization of crosscutting concerns that can be used to decouple the adaptive and context-aware behavior from the application logic. In such paradigm, crosscutting behaviors are encapsulated in elements known as aspects. Aspects are composed with the business logic through a process called weaving. Therefore, components that implement the application business logic can be separated from the components that implement adaptation and context-aware behavior. All adaptive code can be encapsulated in a set of potentially reusable aspects, generating modular applications and facilitating their code maintenance, extension as well as promoting reuse.
Categories and Subject Descriptors D.2.1 [Requirements/Specifications]: Methodologies
General Terms Management, Performance, Design, Languages.
Keywords Mobile Computing, Aspect Oriented Software Development.
1. INTRODUCTION In mobile computing, applications characterize by constant changes in their execution state, caused by user mobility, device characteristics and the diversity of the available resources. The dynamic nature of the execution environment requires that applications adapt their behavior to the current context. Therefore, applications for mobile computing should meet two important requirements: (i) dynamic perception of the surrounding environment, known as context-awareness [6]; and (ii) adaptation to react to the changes in the environment, selecting and incorporating new behaviors at runtime, known as dynamic adaptation [4]. Adaptive context-aware applications monitor their execution state and explore the contextual information generated by the changes in the environment, providing adaptable and usercenter services. The dynamics of the execution environment demands the mobile applications to meet different requirements in comparison to applications running in static environments as well
We propose a framework, built on aspect oriented development and software dynamic composition, to support the development of adaptive context-aware applications for mobile computing. The focus of this paper is to present the services provided by the framework, its operation and a development process for mobile applications. Section 2 describes the framework and the application development approach. Section 3 presents a case study and Section 4 illustrates how to build applications using the proposed development process. Sections 5 and 6 present the evaluation and related works and Section 7 concludes the paper.
2. PROPOSED FRAMEWORK In the proposed framework, context handling functionalities are provided by a context provision middleware [10][12]. In the current version, we adopted MOCA [12], as the middleware to integrate the framework. MOCA consists of a set of APIs and services to collect and process contextual data for mobile devices. CIS (Context Information Service) is the service that notifies context changes in a mobile device, receiving information on the device and their environment provided by a component known as Monitor. Monitor runs in a mobile device and periodically sends contextual data to CIS. MOCA handles two types of contextual
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’09, March 8-12, 2009, Honolulu, Hawaii, U.S.A. Copyright 2009 ACM 978-1-60558-166-8/09/03…$5.00.
† Work partly supported by the National Council for Scientific and Technological Development (CNPq).
456
components allows keeping in memory only the code that is necessary for each execution context.
data: the device local context (battery level, CPU and memory usage) and the connectivity context. LIS (Location Inference Service) is the service responsible for inferring the approximate logical location, by comparing the current pattern of Radio Frequency signals received to the pattern of signals previously measured at reference points. The proposed framework uses CIS, LIS, Monitor and the MOCA’s Context Model.
The Adaptation Module governs the adaptation process by managing all the other components. It was conceived based on AOSD concepts and was developed as an abstract aspect (Abstract Adaptor) including functions commonly present in any contextaware adaptive application. Examples of functions are: (i) load and unload context provision service, (ii) subscribe the device MAC address or topics of interest to the application, (iii) issue queries about current context and (iv)issue queries about adaptation policies for each context. Abstract Adaptor intercepts situations that require adaptation. It has a standard behavior for each one of its methods and its abstract method adapt() should be redefined for each specific adaptive behavior (represented by concrete aspects). However, independent on the specific behavior, such method always gets the context stored in the Context Manager, sends the current context to the Adaptation Policy Manager and receives a composition specification which is sent to the Execution Manager, in order to the policy can be applied, through the dynamic composition of the application.
In our approach, adaptive context-aware services and the applications are built as a set of software modules. Adaptation strategies are based on specifying the sub-set of modules to be dynamically loaded and run according to predefined rules, in function of the different execution contexts.
2.1 Architecture of the Proposed Framework Figure 1 shows the proposed framework architecture and its integration with a context provision middleware. The Context Manager stores the current contextual information, which characterizes the device and network states and is frequently updated by notifications received from the context middleware. In MOCA, to allow CIS to notify about context changes, the device MAC address should be subscribed. Since this requirement is specific to the context provision platform, we performed such subscription in the Adaptation Module, thus providing transparency to the application.
To define the concrete aspects we identified a set of adaptive concerns that represent adaptive crosscutting behavior present in the mobile application domain. Therefore, in most of the cases, applications will use the predefined aspects and only need to define where and when, in the business code, such aspects are to be applied. On the other hand, the proposed aspect model can be easily extended, by including new concrete aspects representing the additional adaptive behavior. The concrete aspects are: (i) User Adaptor - responsible for adaptation based on the user profile, (ii) Screen Adaptor - responsible for adapting the GUI to screen characteristics of the devices to the device energy level; (iii) Network Adaptor - responsible for adaptation in function of the type and condition of the network (for instance, to compress data sent through the network in case of low bandwidth); (iv) Connectivity Adaptor - responsible for adaptation in function of the presence/absence of network connectivity, used to determine whether to access the local or remote databases.
Figure 1. Framework architecture The Policy Repository stores the adaptation policies, which are defined using XML. The Adaptation Policy Manager is responsible for the definition of the adaptive behaviors based on the current context. Such component analyzes the adaptation policies stored in the Policy Repository (including a XML parsing), to select the policy (ies) more suitable to the current context. Based on the selected policies, the Manager generates a specification representing the composition of modules for the current context. The Composer and the Execution Manager will use this specification. The Composer is in charge of defining the modules (according to the specification) to be dynamically loaded by the Execution Manager in each execution context. The Composer interprets the output generated by the Adaptation Policy Manager and assures that the dynamically loaded modules work properly. In our current version the composition validation was not addressed; we assume that all generated compositions are valid. The fully qualified names of classes selected by the Composer for the context current are sent to the Execution Manager that searches for them in the execution space. The Execution Manager uses a naming service (JNDI [7]) to search the classes on both remote and local spaces. Finally, the Execution Manager is in charge of dynamic loading the software modules, specified by the generated composition and located by their names in the application execution space. The Execution Manager plays an important role, since in mobile devices the memory consumption is a critical factor. Then, the dynamic load of
2.2 Development Approach Besides the framework we also propose a development process for adaptive mobile applications. The proposed process dictates a set of phases the developer must follow, which were adapted from traditional AOSD development approaches. These phases are: (i) to implement the GUI components and the application business logic using a modular decomposition approach, (ii) to define adaptation policies, which describe the behavior adopted by the application in each execution context, through rules that determine which components should be loaded in each context; (iii) to define the contextual events of interest and the business components that will be affected by such events, as well as the points in the components code to be intercepted (join points); (iv) to encapsulate adaptive behavior (defined in ii and iii) in one or more aspects, by defining pointcuts (group of points where adaptive behavior will be injected) and advices (code that contains the adaptive behavior to be injected in the application). Each aspect consists of a set of advices and pointcuts, describing the adaptive behaviors and the points where such behaviors are to be injected. Since we already provide a set of default adaptive concerns common to mobile applications, with concrete aspects
457
user profile and the device. Additionally, the application has a textual interface (TEXT-INTERFACE) that can be needed in some contexts. In the prototype built for the case study, Java 5.0 was used to implement the application base code. The implementation of the framework aspect-oriented constructs was made in two different versions: one with Aspect-Oriented framework JBoss AOP [8] and other in AspectJ [1].
implementing these adaptive concerns, the developer only needs to redefine the adapt() methods of each required concrete aspect according to the specific needs of his application.
3. CASE STUDY To illustrate the use of the proposed framework and development approach, a medical scenario was idealized in which the framework supports an application for querying and exchanging medical information in a mobile environment. The scenario requires that information about patients is concentrated in a server that can be accessed from different places (hospital, doctor's office, patient’s home). The devices where the retrieved information is visualized, as well as the format of the presented data (textual/graphical, encrypted, compressed) vary, depending on the user profile and location. The mobile application developed to automate the described scenario comprises functionalities to: visualize and prescribe medicines, exams and treatments, register diagnostics, query the patient medical register and manage medical attendance. It also contains a function to allow the remote monitoring of patients through physical sensors which are installed in the patient and periodically (or whenever a significant event occurs) send data through wireless network connections. The medical mobile application can be accessed by professionals (doctors or nurses) and patients, registered in different users’ profiles, representing the responsibilities of each group of user and constraining the functionalities to be accessed. The Nurse profile comprises responsibilities of informing the administration of prescriptions and medical procedures. They neither have permission to access patient personal information nor can prescribe medicines and treatments. Such activities concern to the Doctor profile. However, a nurse can receive notifications from sensors about critical states of patients. The Doctor profile can prescribe medicines, procedures and exams, issue diagnostics, access the patient personal information and medical history, receive notifications from the patient state and, whenever is needed, to conduct the patient to another specialist. The Patient profile was created to allow patients and their companions to get information about requested exams and their results, prescribed medicines and medical procedures. There is also an Administrator profile, representing users responsible for registering the doctors, nurses and patients allowed to access the application.
The Storage Module is responsible for storing data in a Remote or a Local Database. It interacts with the Cryptography Module whenever the traffic needs to be encoded. Remote Database is the repository of all application data. Local Database is used to temporarily store information in cases of network unavailability. In such cases, as soon as the network signal is reestablished, the information is transferred to the Remote Database component. After specifying the application GUI and logical modules, the next step to build an application is to define the adaptation policies by specifying rules that determine which components (functional modules) should be loaded in each execution context. Such policies are defined in a declarative way and stored in the Policy Repository. The next steps are: (i) the definition of the application contextual events and the definition of the points in the code that will be intercepted by the adaptive code (join points); (ii) the encapsulation of the adaptive behavior (defined in the previous steps) in one or more aspects. Those steps involve the use of AOP and they are described in the following sections.
4.1 AOP in the proposed Framework In the case study, we assumed that all the application functional modules are affected by contextual changes, meaning that join points should be defined for each module. Figure 3 illustrates a pointcut representing the loginButtonMouseClicked method execution. Pointcuts are defined in a declarative way in the file jboss-aop.xml of JBoss AOP, allowing the modification of pointcuts without needing to recompile the code. loginButtonMouseClicked(..))”/> Figure 2. Pointcut that defines the login method interception After defining the pointcuts, the advices that implement the adaptive behavior should be defined. The advices code (represented by the adapt method and its variants for each adaptive behavior) manages the adaptation process, obtaining the current context stored in the Context Manager and sending it to the Adaptation Policy Manager which selects the policy to be activated in such context. The set of adaptation rules applied to each adaptive concern is specified by the setOperation method, making the searching for the adaptation policy more efficient, since only a subset of the policies contained in the Repository has to be queried. After, the selected policy is sent to the Execution Manager for loading the requested modules. The code shown in Figure 4 is defined in the file jboss-aop.xml and it shows the association of the advice with a pointcut indicating that the adaptation code, contained in the adapt method implemented in ScreenAdaptor, will be executed when the ScreenAdapt pointcut is reached. Figure 5 presents the code that implements the adapt advice for the Screen adaptation. The method described in the figure is associated to the ScreenAdapt pointcut through the declaration shown in Figure 4. Since the adaptive behavior
The adaptive behavior considered in the case study is based on the following contextual features: (i) User Profile; (ii) Type and State of the Mobile Device; (iii) Network State; (iv) Location, represented as a symbolic region that reproduces the hospital area. The location context allows dividing the execution environment between external and internal; an internal environment represents the access to the application inside of the hospital area and it is considered “safe” (meaning that there is no need for mechanisms to enforce security, such as the use of cryptography). External environments, defined as any region outside of the hospital area, are considered “unsafe” and require adaptation, for instance, by loading the cryptography component.
4. BUILDING THE APPLICATION The components of the case study are Graphical User Interface (GUI), Functional Modules (the business logic), Storage and Cryptography Modules, Local and Remote Databases. GUI includes different graphic interfaces, exhibited depending on the
458
depends on the context, the aspect also includes all procedures for event handling provided by MOCA CIS, thus keeping the application code completely free from the context handling.
6. EVALUATION The goals of our framework are: to increase the modularity of adaptive applications producing applications easier to comprehend, maintain, manage and evolve; and to reduce the memory requirements, keeping loaded only the code really needed for each execution context. The evaluation process consisted of performing comparisons between two versions of the code implementing the application used as case study. The first version was built by adopting an Object-Oriented (OO) approach and without software dynamic composition. The second version was built by using our proposed approach based on Aspect-Oriented (AO) development and dynamic composition. In the OO version, the only component of the framework implemented was the Context Manager. The code implementing the context-aware adaptive behavior was tangled and spread over the application functional modules. The implementation of the OO version had two goals: (i) to highlight the crosscutting nature of the contextaware adaptive behavior, thus justifying its encapsulation as an Aspect; and (ii) to serve as a base for the quantitative comparison of the code generated in the two versions. The AO version used for purposes of evaluation was implemented in AspectJ, since in JBoss AOP there is no distinction between classes and aspects, thus hindering the use of the available measurement AO tools.
Figure 3. Advice associated to the ScreenAdapt pointcut public Object adapt(Invocation invocation) { try{ return invocation.invokeNext(); }catch (Throwable e) { e.printStackTrace(); return null; }finally { ContextManager.setOperation(“ScreenAdapt”); Context context = ContextManager.getContext(); ArrayList policy = ContextManager.selectPolicy (context); ExecutionManager.executePolicy(policy);}}
Figure 4. Method implementing the adapt advice The weaving process (combination of base and aspect codes) is realized in a transparent way by the JBoss AOP framework through Eclipse plug-in used to implement our framework. To enable the runtime adaptive behavior, the Execution Manager is responsible for the dynamic loading. It uses Java mechanisms for loading (class loader) and unloading (explicit calls to the Garbage Collector) components and it uses reflective mechanisms to inspect components and access their constructors, obtaining at runtime the appropriate constructor for instantiating a component.
The main indicators of the improvements in modularization obtained with our proposal were well known attributes of software quality: manageability, maintainability and comprehensibility [12]. In terms of metrics, we used LOC (Lines of Code) and RFM (Response for a Module) to evaluate comprehensibility; CBM (Coupling Between Modules) and CMC (Coupling on Method Call) to evaluate maintainability. Coupling metrics are also suitable to evaluate the manageability. The tool adopted to achieve all the metrics in the present work was AOP Metrics [1].
5. RELATED WORKS The work in [11] presents the framework CASA (Contract-based Adaptive Software Architecture) to enable dynamic adaptation of applications, in response to changes in their execution environment. The adaptation mechanism consists of the dynamic composition of application components. The focus of CASA is in the strategies for dynamic composition and component substitution, while our focus is in the approach to support dynamic composition and in building adaptive context-aware applications using AOSD. RSCM [13] (Reconfigurable ContextSensitive Middleware) is an adaptive middleware to facilitate the context-aware communication in ubiquitous environments. It requires the use of ORB (R-ORB) that follows CORBA standard. To enable the communication among objects an interface definition language is defined based on CORBA IDL. Similarly to our framework, the focus of RSCM is providing an infrastructure to facilitate the development of context-aware adaptive applications. However, the RSCM proposal concentrates efforts in promoting interoperability between applications by using the RORB, while our framework concentrates in facilitating the implementation of context-aware adaptive applications through the adoption of AOSD and dynamic composition.
6.1 RESULTS The measurements were performed in all the application modules, but for lack of space we illustrate only Administrator and Doctor Modules. CBM metric indicates the coupling between modules. A high level of coupling reduces the reuse and makes difficult to change the application, thus hindering the process of software evolution. Achieved results shown that, with the removal of the adaptive behavior from the base code (AO version), there was a reduction of about 30% in the coupling in comparison to the OO version for Administrator modules, and a reduction of 75% for Doctor modules. Such improvement was due to the fact that in the AO approach the adaptive behavior is encapsulated in the aspects. We also observe that the improvement concerning the degree of coupling increases with the number of adaptive concerns. Since the Doctor functionalities are exposed to a larger number of adaptations than the Administrator modules, the result of CBM in the AO version was significantly better in these modules.
In [2] a proposal is presented to realize runtime adaptation for context-aware systems. The use of aspect-oriented programming allows separating adaptive concerns and applying process composition to deal with the adding of new contextual information. Similar to our framework, this work uses the aspectoriented paradigm; however, the approach does not address issues about the architecture or implementation of adaptive applications. We propose a flexible architecture which comprises an aspect model as well as present a development approach both aiming at assisting the development of adaptive context-aware applications.
CMC metric indicates the number of modules or interfaces declaring methods that are possibly called by a given module. The use of a large number of methods from many different modules indicates that the functionality of such module cannot be easily isolated from the others (denoting high coupling). Results achieved for CMC were identical to the results of CBM. This coincidence points to the fact that in our approach the dependence between modules exists only in terms of methods, there are no dependence in terms of attributes. The dependence in terms of
459
attributes is given by the CFA (Coupling on Field Access) metric. In OO systems, the CFA value is often zero due to the encapsulation. On the other hand, in AO systems the aspects, through their intrusive behavior, can depend on a given field to perform an operation. In our work, however, this type of dependence was not inserted. The LCO metric represents the lack of cohesion among module operations. Cohesion is a strong indicator of good modularity. In a system involving crosscutting concerns developed by using OO approach, the modules has some tasks from which they do not have responsibility, since the crosscutting concerns are spread through the code, thus increasing the lack of cohesion. Results shown a reduction of about 50% in the lack of cohesion for the AO approach considering the Administrator module and about 57,2% for the Doctor module.
adaptive applications already exist, most of them lacks from mechanisms to manage the interaction among application and contextual attributes that can trigger the adaptation process at the system level. Our framework overcomes such drawbacks, providing adaptive behavior at the level system without burdening the application and its developers. Future works include addressing the validation of the generated modules compositions, thus assuring a safe adaptation [15]. To tackle this issue, formal specification techniques may be employed, such as Petri nets.
RFM metric refers to a module response, and it indicates the possibility of communication between modules, since methods and advices often execute in response to a message received by a given module. This metric in AO systems must take into account the implicit responsibilities that are trigger when a pointcut intercepts a module operation. Results shown that AO approach decreased the number of method calls in the base code, in about 36% for Administrator modules and 30.8% for Doctor modules. Regarding the lines of code metric (LOC), the achieved value was about 5.178 for the OO version and 3.880 for the AO version. Hence, the removal of the adaptation code spread over the application logic and its concentration in the aspect significantly reduces the programming effort, by the reuse of the aspect code.
[3] Cámara, J., Salaun, G. and Canal, C. (2007) On Run-time Behavioural Adaptation in Context-Aware Systems. 1st Workshop on Model-driven Software Adaptation, 2007.
8. REFERENCES [1] AOPMetrics. Available at: http://aopmetrics.tigris.org/. [2] AspectJ (2006). Available at: http://www.eclipse.org/aspectj.
[4] Canal, C., Murillo, J.M. and Poizat, P. (2006) Software Adaptation. L’Objet, 12(1), 2006. [5] Costa, C. M. et al (2008) An Aspect Oriented Middleware Architecture for Adaptive Mobile Computing Applications. In: 31st Annual International Computer Software and Applications Conference. China, v.2, p. 81-86. [6] Hoh, S., Tan, J.S. and Hartley, M. (2006) Context-aware systems - a primer for user-centred services. BT Technology Journal, v. 24 (2), april 2006, pp. 186 – 194, Kluwer Academic Pubs, MA, USA.
Regarding the memory consumption, measurements were carried out in two moments: (a) upon the user login; and (b) after invoking the method to prescribe medicine given a context where the network state is connected and the execution environment is external. This second moment was chosen since it requires loading several modules at the same time, thus demanding large memory consumption. For the OO version we achieved 1.50 and 1.69MB for situations (a) and (b). For the version based on AO and dynamic composition we obtained 1.25 and 1.41MB. Results shown that the version with dynamic composition provided smaller memory consumption than the monolithic OO version. To evaluate the impact of the dynamic composition regarding the response time of the application, we performed further measurements to evaluate the overhead imposed by the loading of modules. Based on the achieved results, we verified that the overhead of the modules load was insignificant for an interactive application thus concluding that it is worthwhile to dynamically load and unload modules instead of keeping them in memory, since this approach reduced the memory footprint of the application with no impact to the application performance.
[7] JNDI (2008). Java Naming and Directory Interface. Available at: http://java.sun.com/products/jndi/. [8] JBoss AOP (2008). Available at: http://labs.jboss.com/jbossaop. [9] Kiczales, G. et al. (1997) Aspect-Oriented Programming. In Proc. of ECOOP. Finland, 1997. [10] Le Sommer, N., Guidec, F. and Roussain, H. (2006), A Context-Aware Middleware Platform for Autonomous Application Services in Dynamic Wireless Networks. 1st International Conference on Integrated Internet Ad hoc and Sensor Networks, May 2006, France. [11] Mukhija, A. and Glinz, M., (2005) Runtime Adaptation of Applications through Dynamic Recomposition of Components. 18th International Conference on Architecture of Computing Systems, Innsbruck, Austria, March 2005. [12] Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules, Commun. ACM, vol. 15, no. 12, pp. 1053–1058, 1972. [13] Sacramento, V. et al., (2004) MoCA: A Middleware for Developing Collaborative Applications for Mobile Users. ACM Middleware Conference, Toronto, 2004.
7. CONCLUSION A major technological challenge in mobile computing is to adapt the behavior of the applications in runtime according to the constant changes in their execution state. We proposed a framework based on Separation of Concerns that provides a complete infrastructure for developing adaptive and context-aware applications, aiming at increasing the degree of modularity and flexibility of mobile applications. Our main contribution is to combine the use of AOSD and dynamic composition as a strategy to support the building of adaptive applications. In spite of various proposals of frameworks to support the development of
[14] Yau, Stephen S., Karim, Fariaz. (2004) An Adaptative Middleware for Context-Sensitive Communications for RealTime in Ubiquitous Computing Environments. Real-Time Systems, 26, 29-61, Kluwer Academic Publishers. [15] Zhang, J. et al (2005) Enabling safe dynamic componentbased software adaptation, In Architecting Dependable Systems III, Springer-Verlag, 2005.
460
