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.

Made available in DSpace on 2014-06-12T15:55:28Z (GMT). No. of bitstreams: 2 arquivo2238_1.pdf: 2132040 bytes, checksum: 7403ada2f7f20b6592ef20ce13dad893 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / Conselho Nacional de Desenvolvimento Científico e Tecnológico / Programação Orientada a Aspectos (POA) é um mecanismo de programação proposto para modularizar os requisitos transversais, visando um aumento na modularidade de software. Entretanto, recentemente alguns autores tem alegado que o uso de POA quebra a modularidade das classes. Isso acontece pois, sem o uso de interfaces apropriadas entre classes e aspectos, diversas propriedades de um design modular, como compreensibilidade, manutenabilidade e desenvolvimento em paralelo, são comprometidas na presença de aspectos. Diversas interfaces especializadas (design rules) para desacoplar classes e aspectos foram propostas visando atenuar esse problema, como XPIs e LSD. Entretanto, tais interfaces são específicas para a linguagem AspectJ, que possui problemas de reúso e modularidade de aspectos. CaesarJ, por outro lado, é uma linguagem de programação orientada a aspectos com forte suporte para reúso e modularidade de aspectos. Essa linguagem combina as construções OA pointcut e advice com avan¸cados mecanismos de modularização OO. Nesse trabalho nós exploramos algumas construções de CaesarJ com o intuito de verificar se elas podem ser utilizadas para definir Design Rules que permitam um desenvolvimento modular de código OO e OA. Além disso, nós propomos CaesarJ+, uma extensão de CaesarJ que foca no aumento de modularidade. Essa extensão introduz construções que permitem impor restrições estruturais sobre os códigos OO e OA. Um compilador para CaesarJ+, que verifica se as restrições especificadas nas Design Rules estão sendo seguidas, e transforma o código CaesarJ+ em código CaesarJ também foi desenvolvido nesse trabalho. Para avaliar CaesarJ+, nós comparamos as implementações de três estudos de caso em CaesarJ+ e CaesarJ. Nossos resultados revelam que o uso de CaesarJ+ proporciona ganho de expressividade.