secure systems research group - fau aspects and mobile applications sergio soares paulo borba,...

Secure Systems Research Group - FAU

Aspects and mobile applications

• Sergio Soares Paulo Borba, “PaDA: A Pattern for Distribution Aspects” In Second Latin American Conference on Pattern Languages of Programming, SugarLoafPLoP'2002, pages 87-100, Itaipava, Brazil, 5th-7th August 2002.

• Ayla Dantas, Paulo Borba, “Adaptability Aspects: An Architectural Pattern for Structuring Adaptive Applications with Aspects” In Third Latin American Conference on Pattern Languages of Programming, SugarLoafPLoP'03, Porto de Galinhas, PE, Brazil, pages 12-15, August 2003.

• Ayla Dantas, Paulo Borba, Vander Alves. “Using Aspect to Structure Small Device Adaptive applications” First Workshop on Reuse in Constrained Environments at the 18th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA'03, Anaheim, CA, USA, October 2003

• Dianxiang Xu, Vivek Goel “An Aspect-Oriented Approach to Mobile Agent Access Control”


PaDA: A Pattern for Distribution Aspects

• Background:

When implementing a distributed system that requires high modularity, meaning that the system should be independent of the distribution concern. To achieve better separation of concerns the use of aspect-oriented programming should be put into practice by applying PaDA.

• Problem:

Tangled code (code with different concerns interlacing to each other) and spread code (code regarding one concern scattered in several units of the system) decrease system modularity. Therefore, maintainability and extensibility are also decreased.



Goals:• Remote communication. Communication between two

system components should be remote to allow several clients accessing the system, considering that the user interface is the distributed part of the system.

• API independence. The system should be completely independent of the communication API and middleware to facilitate system maintenance, as communication code is not tangled with business or user interface code.

• A same system can use different middleware at the same time. This would allow, for instance, two clients accessing the system, one using RMI and the other CORBA.

• Facilitate functional tests. Functional tests are easier by testing the system with its local version; therefore, distribution code errors will not affect the tests.



• Structure:



• Original System’s Behavior


PaDA: A Pattern for Distribution AspectsBenefits:

• Distributed Implementation. The pattern provides remote communication between two components of a system.

• Modularity: PaDA structures the distribution code in aspects, which is completely separated of the system code, making the system source code API-independent.

• Incremental implementation: The system can be completely implemented and tested before implementing the distribution aspects, because are totally separated. The programmers should not take care about distribution problems, and allows requirements validation without the impact of distribution.

• Additional separation of concerns: PaDA structure defines exception handling as a crosscutting concern, which is not done by object-oriented programming techniques.

• Facilitate testing of functional requirements: Tests can be done easily if made using the system without the distribution. The distribution aspect is added to the system just if the composition process (weaving) is executed.


PaDA: A Pattern for Distribution AspectsLiabilities:

• New programming paradigm. The pattern uses a new programming technique that implies in learning a new programming paradigm to use the pattern. Also, the programmer of the functional requirements cannot see the resultant code that will implement the required concern, decreasing code legibility.

• Increased number of modules. PaDA adds three new modules into the system. increasing modules management complexity.

• Increased bytecode. Each aspect definition will result in a class after woven it into the system increasing system bytecode.

• Name dependence. The aspects definition depends of the system classes, methods, attributes, and argument names, which decreases the aspects reuse.

• Dynamic change of middleware. At the moment, the AOP languages do not allow dynamic crosscutting, which does not allow changing the distribution protocol at execution time.



Implementation Steps:• Identify the components, server and client, to have the

communication between them distributed.• Write the server-side aspect. The server-side aspect is

responsible to use specific distribution API code changing the server component, making it available to response remote calls.

• Write the client-side aspect. The client-side aspects are responsible to intercept the original local calls made by the client component redirecting them to remote calls made to the remote component (server).

• Write the exception handler aspect. The exception handler aspect is responsible handle with new exceptions added by the aspects definition.


Adaptability Aspects: An Architectural Pattern for StructuringAdaptive Applications with Aspects

• This architectural pattern is intended to show how to use aspects in order to better structure adaptive applications, which are able to change their behavior in response to context changes, such as the device new localization or its resources state.

• Adaptability has became a common requirement and its implementation usually affects many parts of the code. Most implementations of this requirement lead to tangled code, mixing different concerns such as application business rules, GUI code, and adaptive behavior implementation. It is sometimes hard to include the adaptability concern in new and existing applications in easily maintainable way

• Problem: Avoid lack of flexibility and code tangling mixing adaptive functionality implementation with different concerns such as application business rules and GUI code


Adaptability Aspects

Goals:• Separate adaptability concerns from other concerns, in

order to improve reuse and maintainability.• The adaptability functionality might be either plugged in/out

and also turned on/off, because the ways to acess the context and the behaviors triggered by environment state may change a lot.

• Not all the developers need to know a particular Aspect-Oriented Programming (AOP) language, because each team may focused on a different pattern module, that does not necessarily need AOM.

• The application should be easy to maintain.• The application can be implemented in any platform, from

embedded devices, such as cellular phones, to enterprise applications.

• The kind of contextual information might change and this should not cause a significant impact on the system



• Base Application: The core application functionalities, such as business and GUI code, and possibly persistence and distribution code, but no adaptability code.

• Adaptability Aspects: The aspects implementing the adaptability concern. They specify how the behavior of the base application functionalities should be changed to adapt to contextual changes.

• Auxiliary Classes: Classes used by the aspects to provide the adaptive behavior. Its isolation from the aspect is intended to improve reuse.

• Context Manager: Module responsible for analyzing context changes and triggering adaptive actions implemented by the aspects. Its implementation may be based on a variation of the Observer pattern.

• Adaptation Data Provider: Classes responsible for providing data for dynamic adaptations according to context changes. These classes can be organized as an Adaptive Object-Model (AOM)



Benefits:• Modularity. The base application is isolated from the

adaptability aspects and from the classes that actually execute actions at the identified adaptation points.

• Reuse. The use of auxiliary classes improves reuse, since these classes can be used by many aspects.

• Extensibility. As the aspects code is isolated from the core and auxiliary classes code, it becomes easier to maintain each part of the application and also to extend the system.

• Platform Independence. Its general structure can be applied to a wide range of systems, from embedded systems to enterprise applications.

• Dynamic changes. With the adaptation data provider module, dynamic changes in the application behavior can be performed, and those changes do not need to be expressed by new code.



Liabilities:• Code size. Implementations of the pattern are

usually bigger than alternative nonmodular solutions that tangle adaptation code with base application code.

• Efficiency. Due to the number of elements required by the architecture, the proposed pattern imposes a burden on efficiency when compared to other non-modularized solutions.

• Dynamic loading. An important requirement related to adaptability nowadays is dynamicity (the extent to which the adaptation should be dynamic).



• Example: Consider a dictionary application developed in Java for the J2ME platform.


Adaptability Aspects: Example

Dictionary capable of translating a word from English to Portuguese for a small device implemented using 3 approaches:

• AspSol: Using adaptability pattern• PatSol: Using only pure OO patterns• TangSol: Not using anything



InitializationTime(%)

ExecutionTime(%)

Used memory(%)

JAR size[byte code](%)

Source Code Size

(%)

AspSol xTangSol

25,0 30,9 23,0 35,7 2,6

AspSol x PatSol

10,4 12,5 14,1 16,0 -11,6



Conclusions:• The burden on memory use, performance and code

size while using aspects is not so significant when compared to a solution with patterns. However can achieve about a third in relation to a tangled version, what might not be desirable depending on the system resources and on the wanted degree of flexibility.

• The advantages brought by the Adaptability Aspects pattern use, such as better reuse, the separation of the adaptability concerns from business code, the pluggability of these concerns (which makes it easy to generate different versions of the same application depending on the device), better maintainability and the ability to divide the team for the implementation of the pattern modules are worthwhile, but the target system characteristics should be analyzed

secure systems research group - fau aspects and mobile applications sergio soares paulo borba,...

Documents

system code

distribution aspectspada

distributed system

system modularity

distribution code errors

distribution concern

system components

impact of distribution