An Approach to Design Crosscutting Framework Families Valter Vieira de Camargo Centro Universitário Eurípides Soares da Rocha Univem – Avenida Hygino Muzzi Filho, 529 – Cep 17.525-901 – Cx. Postal 2041 – Marília – SP valtercamargo@hotmail.com Paulo Cesar Masiero Instituto de Ciências Matemáticas e de Computação ICMC-USP – Avenida do Trabalhador São carlense 400 - Cep 13.560-970 – São Carlos – SP masiero@icmc.usp.br ABSTRACT Crosscutting Frameworks are the most common type of aspect- oriented frameworks. They encapsulate only one crosscutting concern, such as persistence, distribution or synchronization. This kind of framework has been successfully used as infrastructure software providing services to higher level applications. However, as any common framework, when crosscutting frameworks are used for developing an application, usually all of their features and variabilities remain in the final architecture, even if only a subset of them was needed. This leads to a poor design with several pieces of death code, making the maintenance activities difficult. In this paper we present an approach to design a set of modules, called features, creating a family of Crosscutting Frameworks. So, during the developing of an application, just the features needed by the application are used, resulting in a clearer design, propitiating higher levels of maintainability and reusability. The approach is exemplified by means of a Family of Persistence Crosscutting Framework. Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques – Aspect-Oriented Framework Families. [Software Engineering]: Reusable Software – Aspect-Oriented Framework Families. General Terms Design, Standardization and Management Keywords Aspect-Oriented Frameworks, Crosscutting Frameworks, Aspect- Oriented Frameworks Design, Architecture. 1. INTRODUCTION The abstract mechanisms of Aspect-Oriented Programming (AOP) [13], such as abstract pointcuts, are essential to the implementation of crosscutting concerns in a generic way, propitiating the reuse of these concerns in other contexts. Usually, when a concern is implemented in a generic way it is called “aspect-oriented framework” (AOF) because it can be reused during the development of an application [9][15][16][17][19][19]. In a previous work, a more specific term for this kind of framework was suggested, namely “Crosscutting Framework” (CF) [5]. A CF is a framework which encapsulates only one crosscutting concern in a generic way. There is a large number of CFs proposed in literature which play the role of infrastructure software, such as persistency [16][17][19], concurrency [9] and security [15][18][19]. As in any object-oriented framework [10], a CF has variabilities which must be chosen during the reuse process. Another characteristic of CFs shared with conventional frameworks is that the more variabilities the CF has, the greater the possibilities of reusing it in other contexts. So, usually a framework implements many variabilities to increase its reuse levels, resulting in complex architectures. Another similarity with object-oriented frameworks, which is actually a problem, is that the application developed with framework support includes the whole framework, i.e., the final architecture contains the application modules and the framework modules. This is a problem when the application to be developed requires only a subset of the framework variabilities – which is actually a common situation. Therefore, instead of using only the subset of the variabilities, all of the available variabilities are included into the final architecture of the application. Therefore, we can find several parts of the code unused, resulting in a poor design and causing maintenance, evolution and reuse problems [2][4][3][8]. Although the term “variability” is well-known in framework domain, in this work we have decided to define, in a more precise way, the terms “variability” and “feature”. For us, variability is implemented as a set of small alternative choices which determine a specific function of the framework, i.e., it turns a specific function on or off [10][3]. Usually, they are implemented by known design patterns such as Strategy, Factory Method and Template Method [11]. A feature is a “bigger” functionality of the domain which deserves to be modularized as an independent module [12]. It is possible, for example, for a feature to have its own internal variabilities. For example, in the Security domain we can have a feature called “Wrong Tentative Control” aiming at blocking a user account if he/she types the username or password erroneously. This feature can have the variabilities “control by time” – which blocks the user account if he/she gets three errors within a specific period, or “control by tentative number” – which blocks the user account if he/she got a specific number of errors independently of the period. Our proposal is to divide the CF architecture into several “reusable features” which can be composed (or weaved) to generate a more restricted framework, i.e., a framework that only owns the features required by the application, avoiding features not used in the final architecture. Our approach can be seen as a family of frameworks, once several “members” can be built from the set of features available. For example, a family of persistence CFs includes several features that can be composed to generate a member; we can build a framework (member) with pooling, caching and connection features, or yet a member with only the pooling feature, or another member with only the caching feature, etc. The approach presented in this paper is exemplified by means of a family of Persistence CFs but the idea can be generalized to other CFs. A characteristic of our approach is that some features can be implemented in a generic way to allow their reuse out of the original framework family. For example, the feature Pooling can be used “as is” inside the framework family in order to generate a new framework, but it can also be used in another context as long