Return to search

Idioms to Implement Flexible Binding Times for Features

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.

Identiferoai:union.ndltd.org:IBICT/oai:repositorio.ufpe.br:123456789/10980
Date02 March 2012
CreatorsANDRADE, Rodrigo Cardoso Amaral de
ContributorsBORBA, Paulo Henrique Monteiro
PublisherUniversidade Federal de Pernambuco
Source SetsIBICT Brazilian ETDs
LanguageEnglish
Detected LanguageEnglish
Typeinfo:eu-repo/semantics/publishedVersion, info:eu-repo/semantics/masterThesis
Sourcereponame:Repositório Institucional da UFPE, instname:Universidade Federal de Pernambuco, instacron:UFPE
RightsAttribution-NonCommercial-NoDerivs 3.0 Brazil, http://creativecommons.org/licenses/by-nc-nd/3.0/br/, info:eu-repo/semantics/openAccess

Page generated in 0.0131 seconds