Assessing Idioms for Implementing Features with Flexible Binding Times Rodrigo Andrade Informatics Center Federal University of Pernambuco Recife, Brazil rcaa2@cin.ufpe.br M´ arcio Ribeiro Informatics Center Federal University of Pernambuco Recife, Brazil mmr3@cin.ufpe.br Vaidas Gasiunas Technische Universit¨ at Darmstadt Darmstadt, Germany gasiunas@st.informatik.tu-darmstadt.de Lucas Satabin Technische Universit¨ at Darmstadt Darmstadt, Germany satabin@st.informatik.tu-darmstadt.de Henrique Rebˆ elo Informatics Center Federal University of Pernambuco Recife, Brazil hemr@cin.ufpe.br Paulo Borba Informatics Center Federal University of Pernambuco Recife, Brazil phmb@cin.ufpe.br Abstract—Maintainability of a software product line depends on the possibility to modularize its variations, often expressed in terms of optionally selected features. Conventional modulariza- tion techniques bind variations either statically or dynamically, but ideally it should be possible to flexibly choose between both. In this paper, we propose improved solutions for modularizing and flexibly binding varying features in form of idioms in aspect- oriented languages AspectJ and CaesarJ. We evaluate the idioms qualitatively by discussing their advantages and deficiencies and quantitatively by means of metrics. Index Terms—Flexible binding time; Modularity; Metrics; AspectJ; CaesarJ; Software Product Line; Aspects I. I NTRODUCTION Companies are adopting the Software Product Line (SPL) development paradigm in order to obtain significant improve- ments in time to market, maintenance cost, productivity and quality of products. SPL encompasses a family of software- intensive systems developed from reusable assets. By reusing such assets, it is possible to construct a large number of products by combining various features according to the requirements of specific customers [1]. Due to specific client requirements, it is important to define whether certain features should be activated or not. In this context, the binding time of a feature is the time at which one decides to activate or deactivate the feature from a product [2]. In general, two binding times are considered: static and dynamic. For example, products for devices with constrained resources may use static binding time instead of dynamic due to the performance overhead introduced by the latter [3]. For systems without constrained resources, the binding time can be flexible, features can be added or removed statically or users may enable or disable a feature on demand (dynamically). In this scenario, an idiom based on AspectJ [4] named Edicts was introduced with the goal to support the implemen- tation of features with flexible binding times in a modular and convenient way [2]. Although the authors claim that Edicts is modular, no assessment was performed with respect to modularity. Actually, the situation gets even worse: we observe problems when using the Edicts idiom, such as code duplication. This way, the task of maintaining the system becomes time consuming and error-prone. In this work, we use Edicts to implement flexible binding time into several features from four systems (Tetris J2ME 1 , Freemind [5], ArgoUML [6] and BerkeleyDB [7]). In order to address the shortcomings of the Edicts idiom, we propose two alternative idioms developed by us for imple- menting flexible binding time: another AspectJ-based idiom that relies on adviceexecution pointcut and aspect inheritance, and an idiom based on the flexible deployment supported by the CaesarJ programming language [8]. For the purpose of evaluating our idioms and compare them with Edits, we also use both to implement flexible binding time for the same set of features and provide a quantitative evaluation of the resulting implementations. In Sections III-A and III-B we introduce two novel idioms aiming at improving flexible binding time support for feature variability. Additionally, in Sections V-A V-B V-C and V-D, we present a quantitative evaluation of all tree idioms, based on several case studies, with regard to size, code repetition, scattering, and tangling. Furthermore, we show that some problems that directly affect the maintenance effort can be encountered in all of the idioms. Finally, in Section V-E, we discuss the idioms qualitatively. II. MOTIVATING EXAMPLE The same feature of a product line may need to have different binding time. For instance, the Facebook Farmville game needs to “dynamically turn off calls back to the plat- form” at peak times “since performance can be variable” [9]. Users would not be able to play Farmville at peak time 1 http://kiang.org/jordan/software/tetrismidlet/ 2011 15th European Conference on Software Maintenance and Reengineering 1534-5351/11 $26.00 © 2011 IEEE DOI 10.1109/CSMR.2011.29 230 2011 15th European Conference on Software Maintenance and Reengineering 1534-5351/11 $26.00 © 2011 IEEE DOI 10.1109/CSMR.2011.29 231