Systemizing Aspect-Oriented Framework Reuse with AFR

Download PDF
5 downloads 147 Views 262KB Size Report
Comment
reuse steps, it becomes very difficult for the application developer to reuse it. This work presents AFR (Aspect-oriented Framework. Reuse), an approach to ...
Systemizing Aspect-Oriented Framework Reuse with AFR Leonardo Penczek

Marcílio Mendonça

Toacy Cavalcante de Oliveira

PUC-RS Faculty of Informatics Av. Ipiranga, 6681 Porto Alegre, RS, Brazil [email protected]

University of Waterloo 200 University Avenue West Waterloo, Ontario, Canada [email protected]

PUC-RS Faculty of Informatics Av. Ipiranga, 6681 Porto Alegre, RS, Brazil [email protected]

Abstract

(aspects), and, optionally, OOP basic units (classes). This set represents the abstract design of solutions for a family of related problems [5]. According Camargo and Masiero [1], there is two types of AOFs: Aspect-Oriented Application Frameworks (AOAF) and Crosscutting Frameworks (CF). An AOAF implements a generic architecture for a specific domain, and its reuse produces a new application of this domain, i.e., the reuse of a Customer Relationship Management (CRM) AOAF will generate a new CRM system. A Crosscutting Framework (CF) has abstract composition mechanisms and variabilities corresponding to only one crosscutting concern (persistence, security, etc). A CF must be composed with an existing base code in order to work, that is, only its instantiation does not produce an application.

Aspect-oriented programming has introduced new possibilities for developing frameworks, but it also brought complexity to aspectoriented framework reuse. Therefore, if an aspect-oriented framework does not have well documented extension points and reuse steps, it becomes very difficult for the application developer to reuse it. This work presents AFR (Aspect-oriented Framework Reuse), an approach to facilitate the aspect-oriented framework reuse. The AFR assists application developer when placing application specific needs into frameworks extension points. Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques – Computer-aided software engineering (CASE) General Terms Verification.

Therefore, the AOFs reuse process can have two semantically distinct phases: instantiation, the conventional reuse process of OOFs which consists of adapting the extensions points; and composition, which consists of informing the join points of an existing base code that will be intercepted by the AOF. In some cases, the composition phase depends on information that is determined by the instantiation phase letting the instantiation to occur first. But if this dependency does not occur, both phases can be executed in any order, or in parallel. There are three possible forms of reuse for AOFs: 1) only instantiation, 2) only composition, and 3) instantiation and composition.

Documentation, Design, Languages,

Keywords Aspect-oriented frameworks reuse assistance, systematization.

1. Introduction Aspect-oriented programming (AOP) [6] offers new possibilities for the framework development, allowing new forms of extension points design and implementation. Moreover, as AOP is used together with object-oriented programming (OOP) – not replacing it –, an aspect-oriented framework (AOF) can use both aspectoriented and object-oriented forms of design and implementation for its extension points. Furthermore, AOFs have a more complex reuse process than object-oriented frameworks (OOFs), with a new composition reuse phase [1]. This is caused by the aspect’s nature of not being a standalone structure: they must be combined with an existing code in order to work.

3. AFR The AFR approach provides means to represent reuse activities explicitly, in a formal way. It is composed by: UML-AFR – a lightweight extension of UML for visual identification and documentation of extension points inside diagrams. The UML-AFR expands the UML-FI (Framework Instantiation) [7][8] from the RDL approach, adding new stereotypes to identify and to document framework extension points inside aspect/class diagrams.

Therefore, an AOF must have its extension points and reuse process documented in an easy, understandable and unambiguous way; otherwise, it will be very difficult for the application developer to reuse correctly the framework, without errors. To avoid these problems, this work proposes the AFR approach (Aspect-oriented Framework Reuse) for AOF reuse documentation and automated assistance. The AFR extends the RDL approach (Reuse Description Language) [7][8], which systemize OOF instantiation, incorporating AOF characteristics. In the following sections we will discuss about AOFs and our approach for AOF reuse assistance.

RDL+Aspects (Reuse Description Language enhanced with Aspects) – a process language with essential commands and types to specify the AOF reuse process steps into reuse – instantiation and composition – scripts. It is independent of framework programming language and domain, manipulating design elements expressed in UML-AFR. Its abstractions are based on cookbooks [9] and it exploits the use of design patterns [3] and idioms [4].

2. Aspect-oriented Frameworks

Reuse Tool – a runtime environment to execute RDL+Aspects instantiation and composition scripts, guiding the application developer through all phases of the reuse process. According the reuse phase being performed, the Reuse Tool will receive one or

An aspect-oriented framework (AOF) is a set of AOP basic units Copyright is held by the author/owner(s). OOPSLA’06 October 22–26, 2006, Portland, Oregon, USA. ACM 1-59593-491-X/06/0010.

665

two diagrams (in XMI - XML Metadata Interchange - format) and one script, and, together with the application developer feedback, it will generate another model. It will also perform validation tasks over the design elements produced to ensure that its structure is regular and well-formed. Figure 1 depicts the AFR operation for a CF with both instantiation and composition phases, where composition depends on instantiation.

AccessControl SecurityPoint FullSecurityPoint

AccessControlWeb FullSecurityPoint - myRequest - myResponse + analyseRights() + denyAccess()

AccessControlLocal FullSecurityPoint + analyseRights() + denyAccess()

Figure 2. Security CF UML diagram.

5. Conclusions This work presented the AFR approach, which is used to systemize AOF reuse. The AFR uses an UML extension to represent AOFs extension points at design level. It also proposes the RDL+Aspects language that has commands to represent reuse activities related to instantiation and composition phases of the AOF reuse process. A program written in RDL+Aspects formally describes the steps necessary to reuse an AOF, and when executed by a computer it assists the application developer through the reuse process. Therefore, the AFR facilitates error detection and control by the application developer. As future work, we aim to improve the Reuse Tool to have a more user-friendly interface. As well, we aim to do more elaborated case studies with some aspect-oriented frameworks (CFs and AOAFs) available in literature.

Figure 1. Overview of AFR operation for a CF.

4. Case Study An existing AOF [2] available in literature was used to illustrate the AFR approach usage. It is a simple security CF with only the composition phase in its reuse process. Its composition consists of selecting one of AccessControl subaspects and extending it to concretize SecurityPoint pointcut, informing which application points will be intercepted by the CF. The RDL+Aspects composition script for the security CF is listed below:

6. References [1] Camargo, V. and Masiero, P. “Frameworks Orientados a Aspectos”. XIX SBES, Uberlândia, Brazil, 2005. [2] Camargo, V., Ramos, R. and Masiero, P. "Implementação de Variabilidades em Frameworks Orientados a Aspectos desenvolvidos em AspectJ". In 1st WASP'04, Brasília, Brazil, 2004.

1. COOKBOOK SecurityCFComposition 2. RECIPE main 3. rA : ASPECT 4. rA = SELECT_ASPECT_EXTENSION(AccessControl) 5. compA : ASPECT 6. compA = ASPECT_EXTENSION(rA, ?) 7. secutityJP : POINTCUT 8. secutityJP = POINTCUT_EXTENSION( 9. AccessControl, "SecurityPoint", compA) 10. LOOP 11. ADD_JOINPOINT(security, ?) 12. END_LOOP 13. END_RECIPE 14.END_COOKBOOK

[3] Gamma, E., Helm, R., Johnson, R. and Vlissides, J. “Design Patterns, Elements of Reusable Object-Oriented Software”. Addison-Wesley, 1995. [4] Hanenberg, S. and Schmidmeier, A. “Idioms for Building Software Frameworks in AspectJ”. 2nd AOSD Workshop on ACP4IS, Boston, MA, March 17, 2003. [5] Johnson, R. and Foot, B. “Designing Reusable Classes”. Journal of Object-oriented Programming, 1 (2), 22-35. 1998. [6] Kiczales, G., Lamping, J., Menhdhekar, A., Maeda, C., Lopes, C., Loingtier, J. and Irwin, J. “Aspect-Oriented Programming”. ECOOP, vol. 1241, p. 220-242, 1997.

At line 4 the developer will be questioned about which subaspect of AccessControl he wanted – AccessControlWeb or AccessControlLocal. At line 6 the developer will inform a name for the new aspect being created that extends the previously selected aspect. At lines 8-9, the SecurityPoint pointcut will be redefined inside the aspect created at line 6. At lines 10-12, the developer will add joint points to the redefined pointcut as many times as he wants. Figure 2 shows the CF UML diagram already stereotyped with some UML-AFR stereotypes (select_aspect_extension, aspect_extension, pointcut_extension). The pointcut stereotype is merely used in this figure to represent a normal pointcut and it is not part of UML-AFR.

[7] Oliveira, T. “Uma Abordagem Sistemática para a Instanciação de Frameworks Orientados a Objetos”. PhD Thesis, PUC-Rio, Rio de Janeiro, Brazil, 2001. [8] Oliveira, T., Alencar, P., Filho, I., Lucena, C. and Cowan, D. “Software Process Representation and Analysis for Framework Instantiation”. IEEE Transactions on Software Engineering, v.30 n.3, p.145-159, March 2004. [9] Pree, W., Pomberger, G., Schapert, A. and Sommerlad, P. “Active Guidance of Framework Development”. Software Concepts and Tools 16: 94-103, Springer-Verlag, 1995.

666