Experiences Refactoring Ambient Intelligence ... - Semantic Scholar

Experiences Refactoring Ambient Intelligence Applications with Aspects Lidia Fuentes, Daniel Jiménez, Mónica Pinto {lff,priego,pinto}@lcc.uma.es Dpto. de Lenguajes y Ciencias de la Computación. Universidad de Málaga. ETSI Informática, Boulevard Louis Pasteur, 35, Málaga, Spain Nowadays, we are facing a new era where we will be surrounded by smart devices with computational and communication capabilities. This technology is known as Ubiquitous Computing or Ambient Intelligence. In order to reach this new technological evolution step, we must resolve one important question: How can the software and hardware evolution problem be handled at programming level?. The Object Oriented Programming techniques have proven to be not suitable enough to adapt software to new requirements imposed by clients or to emerging technologies. Consequently, it is necessary to use new programming paradigms that allow us to adapt software to changing requirements. In this paper, we show our experiences using AspectJ to refactor an Ambient Intelligence application, the problems encountered during this process, and the advantages and benefits obtained from it. The main goal is to show that using aspect-oriented techniques we can obtain more adaptable and evolvable Ambient Intelligence applications.

Keywords: Refactoring, Ubiquitous Computing, Ambient Intelligence, Aspects, AspectJ, PCOM.

1. INTRODUCTION The origins of Ambient Intelligence (or AmI) are first found in 1991, when Mark Weiser wrote an article about Ubiquitous Computing [1]. For Weiser, the ubiquitous computing term is the opposite to virtual reality. While virtual reality puts people inside a computer-generated world, Ubiquitous Computing forces the computer to live in the real world. Consequently, Ubiquitous Computing is referred as the capacity of integrating autonomous computational devices in the real world. This means that users are not aware of the computer presence and they have not to learn how to use such devices. These devices are able to extract data from the real world surrounding them to perform some data processing that may be used afterwards by others devices. Unfortunately, Weiser's ideas were not implemented because technology in those days did not support the requirements imposed by these applications, like wireless communication or high processing capacity in resource constrained devices. However, in the last years, Weiser's ideas were retaken and the AmI concept was adopted after several meetings of the European ISTAG [2] (Information Societies Technology Advisory Group). This organisation tries to promote and extend the use of AmI technologies in Europe. AmI applications, as conceived by the ISTAG, encompass three main properties. The first one is the ubiquitous computing property, which means that all devices (sensors, mobiles, PDAs, laptops, etc.) have computing capabilities. The second one is the ubiquitous communication property, meaning that AmI devices are able to communicate with other devices everywhere. The third one is the natural user interfaces property that implies that user interfaces must be non-intrusive and user friendly, like gesture or speech recognition. Finally, since AmI applications need to be continuously upgraded due to the continuous evolution of software and hardware, we add a fourth property named dynamic evolution. The achievement of these properties makes the construction of AmI applications a highly complex task. In order to cope with this complexity it is very important to choose the appropriate software technology. However, the first AmI applications were developed specifically to work with concrete hardware, and most solutions were developed ad hoc to solve specific problems; for instance, the communication system of a concrete device. But this way of software development brings a series of weak points and problems. The first one is the hardware and software heterogeneity. Hundreds of devices exist and each one of them uses proprietary software and communication mechanisms. So, interoperatibility among devices is very limited. The second problem, derived from the first one, is the little capacity of software reuse and evolution due to device heterogeneity and ad hoc solutions. Imagine that a new communication technology appears. The provided ad hoc solutions will not be able to adapt the application to use it and a new application must be built and released. Therefore, we need to use new software technologies. In this way, the Software Engineering continuously evolves proposing new software technologies that avoid the development of applications starting from scratch. The final objective of these technologies is to achieve a high degree of reusability, configuratibility, extensibility, adaptability and evolution, making possible to upgrade applications easily according to the new

requirements and modifications that continuously affect these systems. This adaptation should be performed both dynamically and statically. Some recent works in this way are component-based platforms such as Aura [11] or PCOM [5] and operating systems like Gaia [12], specifically designed to build AmI applications. These platforms offer basic AmI services like user friendly interfaces, communication services or device heterogeneity support. However, they do not provide enough support for dynamic evolution. We think that Aspect-Oriented Software Development (AOSD) [3] may solve this problem. The main question proposed by this paper is if it is possible to apply the AOSD techniques to develop AmI applications in order to improve the evolution of these applications over the time. To make this possible, we need to understand how the AOSD can be applied to AmI applications. Inside of any AmI application we can find code related to application properties like communication, location, coordination, security, persistence, energy consumption, etc. These properties limit the application evolution because it is scattered over all the application code and it is highly coupled with the application implementation. Using AOSD our main goal is to achieve a better modularization of AmI applications, making them more adaptable and configurable. Moreover, since AOSD promotes the modelling of crosscutting properties separately, developers will be able to cope with evolving technologies more easily. This means that we will be able to model properties like transmission protocols (e.g. Bluetooh, 802.11, etc.), persistence, security, etc. as independent aspects, making them more reusable and allowing the application to be adapted to such evolving technologies without affecting its core functionality. Some works, like [8][9], have shown that it is possible to refactor applications for Resource Constrained Devices, whose problems are similar to AmI Applications, using aspects. Moreover, they also show that there are a lot of problems to solve in order to refactor old applications and adapt them to AOSD. In this work we will show the PCOM1 architecture and the results of applying AOSD techniques upon it to refactor the application code and transform it into an aspect oriented application. We have used AspectJ[14] to do the refactoring. The structure of this paper is as follows. After this introduction, section 2 describes the most important features of the PCOM architecture. Section 3 details how we have found and have extracted aspects from PCOM. Additionally, we describe new aspects that we consider are interesting for AmI application and that were not considered in PCOM. Section 4 shows a concrete example of aspect extraction. Finally, in section 5 we present our main conclusions and future work.

2. PCOM ARCHITECTURE PCOM [5] is a component system for AmI computing. The PCOM architecture, shown in Figure 1, is structured in two well differentiated parts. The upper part, named PCOM, offers a high-level programming abstraction to application programmers. Using this abstraction, a PCOM application is defined in terms of a set of components, which are deployed inside PCOM containers. Similarly to CCM/CORBA containers, PCOM containers provide services for the instantiation, adaptation and communication of components. In PCOM, component dependences are described in terms of contracts. A PCOM container defines a remote container interface that is used to: (1) expose the contracts of local components; (2) offer services to other containers, and (3) instantiate remote components. Additionally, PCOM defines a signalling-based adaptation mechanism that provides several adaptation strategies to support automatic adaptation in cases where the execution environment changes. For example, when a remote device is no more available or an error in communications happens. The lower part of the PCOM architecture is BASE (see Figure 1), a communication architecture composed by several layers. PCOM is built upon the first layer, the Application Layer. This layer provides an API to access the services defined by the architecture.

Figure 1 PCOM and BASE Architecture Overview

1

Acknowledges to C. Becker and M. Handte for providing us the PCOM architecture source code.

Under this layer, the System Core Layer contains the most important BASE entities, like the ServiceRegistry, which registers the services provided by the upper Application Layer. In addition, we found the DeviceRegistry object that maintains a list of the devices detected in the environment, and the InvocationBroker object that manages the Plug-in Manager in the next layer and provides device searching, message delivery and reception services. Additionally, this level offers to programmers static (SII), providing stub and skeleton support to the upper layer, and dynamic (DII) invocation interfaces to use these services. Under this layer, we found the Plug-in Layer managed by the Plug-in Manager that provides support and manages the device used plugins. These plugins provide several services like the transport plugin to communicate with other devices or the discovery plugin to detect other devices in the environment. Finally, the Device Capability Layer determines the services provided by the PCOM platform and it is implemented by the different plugins that compose the plug-in Layer. In PCOM, the application architecture is defined determining the services that the application needs. When an application is executed, PCOM tries to find the required services in any local or remote PCOM container. PCOM will determine if the application will be executed examining the available component contracts that define which services are supported. The component contracts provide information about the components’ needs (required libraries or memory), the functionality provided by them, and the dependences with other components. Moreover, PCOM does not define any central or coordination element as is required in other environments like Aura [11] or Gaia [12]. So, each device manages all connections and interactions with the environment by itself. Thus, this architecture is adequate to produce applications that are executed in resource constrained devices that do not rely on additional infrastructures. Finally, PCOM delegates all communications to the BASE middleware. The communications in AmI environments are spontaneous and highly dynamic and BASE has to deal with this problem automatically by establishing alternative communication channels if the current one is lost. The most important fact about BASE is that it performs automatic and generic adaptation when these communication errors occur, so the user does not need to do it manually.

3. APPLYING ASPECTS TO PCOM The idea of applying aspects to PCOM appears clearly when we consider software and hardware evolution. Using AOSD techniques we can adapt the application behaviour to new requirements and new technologies. We only need to modify those application parts that are affected by the changes, modularizing the code related to the same concern and making it more readable and easy to maintain. Therefore, our goals are in the first place, determine which aspects can be extracted from PCOM, then extract these aspects’ code and refactor the platform’s architecture, using AspectJ[14], maintaining its functionality and finally generalize the obtained aspects to reuse them in other applications. Used Techniques We need to use two kinds of techniques when we want to apply AOSD to refactor an existing application. The first ones are techniques used to identify aspects within the code, and the second ones are techniques to extract aspects from the code. Additionally, in the case of AmI applications implemented with Java, we have to deal with some limitations imposed by J2ME (Java 2 Micro Edition) in the implementation of resource constrained devices. For instance, it is not possible to use methods that use reflection, like those that access the intercepted join point in most AOSD approaches including AspectJ [14], so our expressivity is somewhat limited. Regarding to the first techniques, we have used techniques based in the detection of regular expressions and data mining to detect possible aspects inside of applications; like the ones used by several tools described in [7] like Aspect Browser or Aspect Mining Tool. The main problem about these tools is that they are not very accurate detecting complete aspects. This is due to the difficult of determining what an aspect is. Therefore, in order to identify aspects in PCOM, we had to rely on our knowledge about the application domain, direct source code observation, and the help of these tools to detect hot spots that could probably be identified as part of an aspects. After aspect identification, we have to extract these aspects from the original source code. Once again, there are no standard techniques to extract aspect code from application code. Additionally, the use of AspectJ forced us to modify the original source code in some places, in order to provide better pointcuts to extract the aspect advice code. For example, to extract a trace code located in the middle of a method, we have to define a new private method in the class that executes that code. Otherwise, we will be unable to extract the aspect code from the application using the current AspectJ language constructs. In this sense, the work of [10] has been a great help to find solutions and providing ideas in some cases where it was complex determine how to proceed to extract the aspect code from the application source code. To conclude this section we must say that in our experience, currently, the main tool to detect aspects and refactor the application remains the application programmer and, unfortunately, the most commonly used technique is the trial and error method.

Identified Aspects After analyzing the PCOM architecture code, we have found and extracted several aspects. The first one was a Trace aspect, which provides information about the application execution. We extracted this aspect code from PCOM and classified it in two different aspects. The first one contains messages related to normal application execution and, the other one, messages related to application exceptions. We have found problems especially with tracing code that was located in the middle of a function or inside of an “if” clause. In these cases, as we pointed before, in order to extract the aspect code we had to refactor the source code to provide a join point that AspectJ could intercept.. After completely extract the trace code, we removed completely one class from the application, thus reducing slightly the application size. We were able to remove it because AmI devices do not usually use tracing messages. Finally, we tried to generalize the extracted aspects, but unfortunately the tracing messages use classes defined by the core PCOM architecture and thus they are too much dependant on the current PCOM implementation to be reused in other applications. The second aspect detected in PCOM was a Device Configuration aspect. In this case we extracted the code that configures some device parameters. For instance, the DeviceRegistry class (see Figure 1) manages the time interval to check if a device is active in the environment. These configuration parameters were hard coded inside the application using constants, and in some cases, scattered between several classes, making it harder to maintain and modify. We extracted these parameters to an aspect, and consequently all possible configuration changes are now performed in only one place. A third kind of aspect was detected inside the plugins provided by the application. In this case, each plugin models a service (device discovery, transport, etc. ) and its current implementation is based on TCP/IP. Using aspects it is possible to replace the plugins by others that use different communication technologies, like Bluetooh. The fourth extracted aspect was the Graphical User Interface aspect. This aspect was pretty easy to extract because its code was only located in the application main class. So, it is easy to replace the implementation in the aspect by other GUI classes. Finally, one of the most interesting aspects found was the Plugin Manager aspect. This aspect extracts the functionality of the plugin manager class. This eases the replacement of this service by other more suitable for simpler devices. We extracted it from the original code to replace the plugin manager behaviour easily. In section 4 we will show how we achieved this separation. Adding new Aspects After analyzing the PCOM architecture, we realized that it does not consider some useful and important functionality related to AmI applications that other works [13] consider, like security, authentication or energy control. This lack of functionality is probably due to the minimalist implementation strategy adopted by PCOM, but we consider that these aspects are highly important for AmI applications. Now, we are going to explain briefly three aspects we added to improve PCOM with new functionality. Firstly, the Authentication aspect is applied before the application starts and verifies the user identity using a simple username/password approach. More sophisticated authentication mechanisms can be provided depending on the device capabilities. The advantage of using aspects is that the use of other authentication mechanism only requires to modify the aspect code, no changes to PCOM and other parts of the AmI application are required. So, we can implement voice, password or biometrics authentication if adequate hardware is available. Secondly, the Security aspect encodes messages before a device sends it to other and decodes messages when other devices receive them. Obviously, this aspect is applied every time that a communication pluging send or receive a message. This aspect adds security to data transmitted between devices. But one problem remains. How the receiving application can determine which security aspect version is being used?. Finally, the Energy Control aspect verifies if the device has enough power to perform the required task by checking the device battery level. When the battery level reaches a certain threshold the aspect shows to the user a warning message or preventive measures are automatically taken. For example, saving the device state when the energy goes suddenly down to the 5% of the device energy capacity level. This aspect is applied when the application is started or when a message is sent. As previously mentioned, the incorporation of these aspects to PCOM was fairly easy because they are orthogonal to PCOM core functionality, so we only need to determine the adequate pointcuts where apply them, analyzing the original application code.

4. EXAMPLE Now, we are going to show an example of how we have extracted the plugin manager aspect and the benefits and problems we have found using AspectJ to do it. We focus this example around the plugin manager object defined inside the BASE architecture, shown in Figure 1.

public class InvocationBroker { …………. pri vate PluginManager pluginManager; …………. public void invoke(Invocation invocation) { …………. if (SystemID.SYSTEM.equals(target.getSystem())) { InvocationHandler handler = getOb jectRegistry().getInvocationHandler(target.getObject()); if (handler == null) invocation.setException(new InvocationException("Target not found.")); else handler.invoke(invocation); } e lse getPluginManager().invoke(invoc ati on); ………… } ………… public PluginManager getPluginManager() { if (p luginManager == nu ll) pluginManager = new PluginManager(getDe viceRegistry()); return pluginManager; }

Figure 2 Original Plugin Manager Architecture In the current PCOM implementation, the PluginManager class implements the plugin Manager Layer. This class provides services to dynamically add new plugins, but most AmI devices will work only with a fixed set of these plugins, depending on its hardware capabilities. So, this class contains some functionality that will never be used by very limited devices, increasing unnecessarily the application code size and complexity. To solve this problem, an elegant solution is to change the PluginManager class implementation by a simpler one in devices that use fixed plugins. However, in the current implementation of PCOM this means to maintain a different version of BASE for each kind of device. Using aspects, we can do this in a more elegant way. After determining that this is an aspect, the first step to take is to localize the PluginManager class definition and determine where it is used. Using AOSD tools [7] like Aspect Browser and Aspect Mining Tool, we see that in PCOM, the InvocationBroker class creates a PluginManager instance the first time that the getPluginManager method is invoked, as is shown in Figure 2. So, the modelling of the PlugingManager as an aspect is relatively easy. We only need to define the pointcut that intercepts all calls to the getPluginManager method and create an around AspectJ advice to replace the method behaviour. The second step is to extract the class reference from the original application code refactoring the application. To achieve this, we create a new aspect (PluginManagerAspect), a new pointcut (InvocationbrokerPointcut) and the advice of this aspect using the original getPluginManager method code. As we observe in the around advice shown in Figure 3, we need to obtain the target class reference (InvocationBroker) in order to use a method (getDeviceregistry) used in the advice code. Fortunately, this method was public. Otherwise we need to modify the method visibility in order to use it in the aspect, and this can cause unexpected problems in other application parts. Finally, we remove the declaration of the PluginManager variable from the original class and modify the original getPluginManager method that now only returns “null”, as shown in Figure 3. Additionally, we have to convert the PluginManager class in an interface, and the new PluginManager implementation (PluginManagerImpl) used by the aspect must implement this interface. This is done to achieve a better aspect reuse using different PlugingManager implementations. We do not include this in this paper but the conversion is trivial. public aspect PluginManagerAspect { pri vate PluginManager pluginManager; pointcut Invoc ationBrokerPoi ntcut(base.system.InvocationBroke r invocationBroker): target(invocationBroker) && ca ll(public PluginManager base.system.InvocationBroke r.getPluginManager()); PluginManager around(base.system.Invoc ati onBr oker invocationBroker): Invoc ati onBr okerPointc ut(invocationBroke r){ if (p luginManager == nu ll) pluginManager = (PluginManager) new PluginManagerImpl(invoc ationBroker.getDe viceRegistry()); return pluginManager; } public class InvocationBroker { …………. //pri vate PluginManager pluginManager; …………. public PluginManager getPluginManager() { return null; }

Figure 3 Modified Architecture

The advantages of this approach are obvious. Firstly, we can provide simpler plugin manager implementations for devices that do not need the PCOM full version removing the unused functionality from the application. Secondly, we preserve the PCOM core architecture and we only need to maintain different Plugins Managers for different devices making easy the application deployment for different kind of devices. Finally, all classes related to the original PluginManager class that are not used by the application can be excluded from the final application, reducing the application size and obtaining a better application performance.

5. CONCLUSIONS AND FUTURE WORK AmI technology is growing and making its way among actual technologies. In the future, we will face more and more complex AmI applications and these applications will need to be supported by dynamic, extensible and adaptive platforms. Our work shows that it is possible to apply AOSD techniques to AmI applications in order to achieve more flexible, evolvable and adaptable solutions. The advantages of using AOSD are, in the first place, to obtain less tangled code, which will be easier to maintain and understand. The second advantage is to reduce the number of program classes and, therefore, the program size. In the context of constrained resource devices, a little reduction in the application size can dramatically improve its performance. For example, in the PCOM architecture we have eliminated the class in charge of tracing the application execution. This means that in the AOSD version of PCOM we can maintain this trace code while debugging, while we will remove it completely from the production version. Finally, as indicated in section 3, it is fairly easy to add new functionality not previously considered by the application, such as energy control, security or authentication. On the other hand, the main drawbacks of applying the AOSD techniques is, in first place, that we need a good understanding of the problem domain in order to extract the application aspects properly. Secondly, we need to be familiarized with the application to modify it when necessary to obtain better pointcuts for AspectJ aspects. And finally, we need a good understanding of AspectJ to model the extracted aspect in order to reuse then within other applications. In our example, it was relatively easy to extract the trace aspect but it is very difficult to reuse it. The use of AOSD has not been considered currently by developers in other AmI platforms like Aura or Gaia, but the obtained results lead us to think that the benefits of reusing aspects and manage the software evolution are attractive enough to be taken into account. So, currently we are developing our own component and aspect platform for AmI devices [13] and getting experiences from people working in this emerging field like those indicated in [8] and [9].

6. REFERENCES [1] Weiser M., ''The computer for the Twenty-First Century”, Scientific American 165, 1991. [2] ISTAG. Information Societies Technology Advisory Group. http://www.cordis.lu/ist/istag-reports.htm [3] AOSD. Aspect-Oriented Software Development Web Site. http://www.aosd.net [4] Kickzales G., et Al, “Aspect-Oriented Programming”, Proceeding of ECOOP'97, Jyväskylä, Finland, June, 1997. [5] Becker, C., Handte, M., Schiele G., Rothermel, K., “PCOM – A Component System for Pervasive Computing”, Second IEEE International Conference on Pervasive Computing and Communication. PerCom’04. Orlando, Florida, March, 2004. [6] Becker, C., Schiele, G., Gubbels, H., Rothermel, K., “BASE – A Micro-kernel-based Middleware For Pervasive Computing”, First IEEE International Conference on Pervasive Computing and Communication. PerCom’03. Fort Worth, USA, 2003. [7] AOP tools. http://www.info.ucl.ac.be/ingidocs/people/km/AIRPort/AIRTools.htm [8] Dantas, A., Borba, P., “Developing Adaptive J2ME Applications Using AspectJ”, Proceedings of the VII Brazilian Symposium on Programming Languages SBLP, 2003 [9] Birov, D., “Aspects Pattern Oriented Architecture For Distributed adaptive Mobile Applications”, International Conference on Computer Systems and Technologies. CompSysTech 2004. [10] Monteiro, M.P., “Catalogue of Refactorings for AspectJ”, Technical Report UM-DI-GECSD-200401, Departamento de Informática Universidade do Minho, Portugal, August 2004. [11] Garlan, D., Siewiorek, D., Smailagic, A., Steenkiste, P., “Project Aura: Towards Distraction-Free Pervasive Computing”. IEEE Pervasive Computing, vol.1, no.2, pp.22-31, April-June 2002. [12] Román, M., Cambell, R., “Gaia: Enabling Active Spaces”. Proceedings of the 9th ACM SIGOPS European Workshop, Kolding, Denmark, pp.229-234, September 2000. [13] Fuentes, L., Jimenez, D., Pinto, M., “Towards the development of ambient Intelligence Environments using AspectOriented techniques”, Proceedings of the Aspects, Components, and Patterns for Infrastructure Software workshop (ACPSI), AOSD 2004, Lancaster, UK. 2004. [14] AspectJ Web. http://eclipse.org/aspectj/