determine what a "good" JPDD translation looks like, i.e. it is necessary to ... Aspect-Oriented Software Development; Aspect-Oriented Design;. Query Models. 1.
From Aspect-Oriented Design To Aspect-Oriented Programs: Tool-Supported Translation of JPDDs Into Code Stefan Hanenberg, Dominik Stein, and Rainer Unland Institute for Computer Science and Business Information Systems (ICB) University of Duisburg-Essen, Germany
{ stefan.hanenberg, dominik.stein, rainer.unland }@icb.uni-due.de
Abstract Join Point Designation Diagrams (JPDDs) permit developers to design aspect-oriented software on an abstract level. Consequently, JPDDs permit developers to communicate their software design independent of the programming language in use. However, developer face two problems. First, they need to understand the semantics of JPDDs in addition to their programming language. Second, after designing aspects using JPDDs, they need to decide how to map them into their programming language. A tool-supported translation of JPDDs into a known aspect-oriented language obviously would ease both problems. However, in order to achieve this goal, it is necessary to determine what a "good" JPDD translation looks like, i.e. it is necessary to have a number of principles that determine the characteristics of a "good" translation. This paper describes a toolsupported translation of JPDDs to aspect-oriented languages. Principles for translating JPDDs are described and a concrete mapping to the aspect-oriented language AspectJ is explained.
Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques. K.6.3 [Management of Computing and Information Systems]: Software Management – software development. D.2.7 [Software Engineering]: Distribution, Maintenance, and Enhancement – documentation.
Keywords Aspect-Oriented Software Development; Aspect-Oriented Design; Query Models
1. Introduction «Join Point Designation Diagrams» (JPDDs [22, 23, 24]) are a graphical means to represent join point selections in a programming language-independent manner. They are intended to help developers communicate the underlying conceptual ideas of their join point selections to others (cf. [24]). However, in order to use JPDDs in daily software development, developers have to solve two problems: First of all, they need to learn and understand 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, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. AOSD 07, March 12-16, 2007, Vancouver, Canada Copyright 2007 ACM 1-59593-615-7/07/03... $5.00
the notation and the semantics of JPDDs. Otherwise, they wouldn't be able to create "correct" JPDDs, or read the ones of others. Furthermore, they need to have a well-defined mapping between the symbols used in JPDDs and their programming language constructs. Otherwise, it would be hard to map a given join point selection, outlined by a JPDD, to program code and, moreover, to exploit an existing pointcut design, expressed by a JPDD, in a different software development project. One way to tackle these problems would be to use a tool that is capable to translate JPDDs into code. Such a tool would help developers to solve both of the mentioned problems: It would help them in mapping JPDDs to their "native" programming language, i.e. it would help them in detecting and exploiting a given JPDD in their own program code. Thereby, it would also help them to learn and understand the notation and semantics of JPDDs since the translation would codify/reproduce the semantics of a given JPDD in terms of the semantics of an aspect-oriented programming language that is known to the developer. In particular to enable the latter, it is essential that the tool generates pointcut code that is easy to understand and that is inline with the JPDD it was generated from. Therefore, the quality of the mapping implemented in the tool is significant. In this paper, we present a (non-exclusive) set of principles operationalizing a set of requirements that "good" mappings should obey in our opinion, i.e. mappings • • •
which are easy to comprehend, which meet the "spirit" of the target programming language, and which are in-line with the respective JPDD.
Based on these principles, we furthermore present a concrete mapping for the aspect-oriented programming language AspectJ [11], and discuss how the mapping complies to the principles. The remainder of this paper is structured as follows: In section 2, we motivate the contributions of our work with help of an example. In section 3, we introduce JPDDs as the graphical design notation that should be transformed into program code. In section 4, we discuss alternative mappings of JPDDs to program code and conclude principles that "good" mappings should obey. In section 5, we outline concrete mappings to the aspect-oriented programming language AspectJ. In section 6, we relate our work to existing work. Section 7 concludes the paper.
2. Problem Statement The contributions of this work yielded to the development of aspect-oriented software is best motivated with help of an illustrative example: Imagine a JAsCo [26] programmer and that
is interested in implementing a data mining application on top of an existing online shop (as described in [28], for example). One of the data to be mined is the response of customers to promotional offers. In particular, the developer is interested in selecting low promotion-prone customers, i.e. customers who seem to discover promotional offers merely "by accident" (example adopted from [28], with slight modifications). The JAsCo programmer probably wants to exploit the stateful aspect language constructs of JAsCo to realize the data mining aspects. The following code snippet is adopted from [28] (with slight modifications), and shows only those lines of code that are responsible for the join point selection (we abstract from the rest since all other lines of code are irrelevant for the subsequent considerations). //defining join point selection hook LowPromotionProneCustomerHook { LowPromotionProneCustomerHook( browseProducts(Category category), accessPromotions(CustomerID customer)) { start > helperTrans; helperTrans : execute(browseProducts) > helperTrans || browsePromotionTrans; browsePromotionTrans : execute(accessPromotions); } //classify customer as low promotion-prone after browsePromotionTrans () {...} } [...] //binding join point selection to concrete method calls LowPromotionProneCustomerHook hook1 = new LowPromotionProneCustomerHook( * OnlineShop.browse*(*), * OnlineShop.getPromotions(CustomerID) ) [...] After having implemented these lines of code, let's assume that the occasion arises that the developer needs to communicate the aspect (i.e. your join point selection, in this case) to an audience that is not familiar with JAsCo – for example, to other developers who are interested in the underlying pointcut design and who have not studied JAsCo, yet. However, if the audience has not studied JAsCo yet, it is impossible to communicate the pointcut design using the source code – because this requires in-depth knowledge about JAsCo. With help of a JPDD, it is possible to explain the join point selection to a non-JAsCo-aware audience. The JPDD in Figure 1, for example, can be used to illustrate the join point selection realized by the code snippet shown above. The JPDD outlines that the join point selection LowPromotionProneCustomerHook distinguishes between different states. The transitions between these states outline a protocol that customers must perform in order to be classified as a low promotion-prone customer. First, customers have to browse the online shop (to any location/product) at least once. Then, they may continue browsing as long as they feel like. Ultimately, though, they must find (and follow) the promotions link. This is the situation when the online shop receives the message getPromotions. At this point, the aspect intercepts, and performs the desired action. This correspond to after browsePromotionTrans in the
JAsCo code. In the JPDD this point is indicated by identifier
