Submitted by Pedro Henrique Rodrigues (pedro.henriquer@ufpe.br) on 2015-03-05T19:54:44Z No. of bitstreams: 2 rcaa-dissertacao.pdf: 2306258 bytes, checksum: c627fb646b9c6f3cadf93565c0b59dd9 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-05T19:54:44Z (GMT). No. of bitstreams: 2 rcaa-dissertacao.pdf: 2306258 bytes, checksum: c627fb646b9c6f3cadf93565c0b59dd9 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2012-03-02 / FACEPE, CNPq, INES / Companies are adopting the Software Product Line (SPL) development paradigm to obtain significant improvements 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 different products applying various compositions. There is a variety of widely used techniques to develop SPLs, such as aspect-oriented programming (AOP), feature-oriented programming (FOP), and conditional compilation. These techniques differ in the type of composition to create a product within the SPL static or dynamically. In this context, it is important to define when certain features should be activated in the product due to specific client requirements and different application scenarios. Thereby, the binding time of a feature is the time that one decides to activate or deactivate the feature from a product. In general, static and dynamic binding times are considered. 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. For devices without constrained resources, the binding time can be flexible, features can be activated or deactivated statically or users may do it on demand (dynamically). To provide flexible binding time for features, researchers proposed an AOP idiom based on AspectJ and design patterns named Edicts. The idea consists of supporting binding time flexibility of features in a modular and convenient way. However, we observe modularity problems in the Edicts idiom. Although we usually use aspects to tackle crosscutting concerns common in classes, such a problem now appears within the own aspects. Indeed, several studies indicate that these concerns hurt software modularity. This way, we observe that Edicts clones, scatters, and tangles code throughout its implementation, which may lead to time consuming tasks, such as maintaining duplicated code. This way, we develop three idioms and implement them to provide flexible binding time for features of four different applications. In addition, we evaluate Edicts and the three idioms quantitatively by means of metrics with respect to code tangling, scattering, cloning, size, and also try to guarantee that our idioms do not change feature code behavior among the different implementations.