RAMON SIMÕES ABÍLIO DETECTING CODE SMELLS IN SOFTWARE PRODUCT LINES - PDF

Description
RAMON SIMÕES ABÍLIO DETECTING CODE SMELLS IN SOFTWARE PRODUCT LINES LAVRAS MG 2014 RAMON SIMÕES ABÍLIO DETECTING CODE SMELLS IN SOFTWARE PRODUCT LINES Dissertação apresentada à Universidade Federal de

Please download to get full document.

View again

of 28
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information
Category:

Religious & Philosophical

Publish on:

Views: 20 | Pages: 28

Extension: PDF | Download: 0

Share
Transcript
RAMON SIMÕES ABÍLIO DETECTING CODE SMELLS IN SOFTWARE PRODUCT LINES LAVRAS MG 2014 RAMON SIMÕES ABÍLIO DETECTING CODE SMELLS IN SOFTWARE PRODUCT LINES Dissertação apresentada à Universidade Federal de Lavras, como parte das exigências do Programa de Pós- Graduação em Ciência da Computação, área de concentração em Banco de Dados e Engenharia de Software, para a obtenção do título de Mestre. Orientador Dr. Heitor Augustus Xavier Costa (DCC/UFLA) Coorientador Dr. Eduardo Figueiredo (DCC/UFMG) LAVRAS - MG 2014 Ficha Catalográfica Elaborada pela Coordenadoria de Produtos e Serviços da Biblioteca Universitária da UFLA Abílio, Ramon Simões. Detecting code smells in software product lines / Ramon Simões Abílio. Lavras : UFLA, p. : il. Dissertação (mestrado) Universidade Federal de Lavras, Orientador: Heitor Augustus Xavier Costa. Bibliografia. 1. Feature-oriented programming. 2. Measures-based detection strategy. 3. Software quality. 4. Software measurement. 5. Software metrics. I. Universidade Federal de Lavras. II. Título. CDD 005.1 RAMON SIMÕES ABÍLIO DETECTING CODE SMELLS IN SOFTWARE PRODUCT LINES (DETECTANDO ANOMALIAS DE CÓDIGO EM LINHAS DE PRODUTO DE SOFTWARE) Dissertação apresentada à Universidade Federal de Lavras, como parte das exigências do Programa de Pós- Graduação em Ciência da Computação, área de concentração em Banco de Dados e Engenharia de Software, para a obtenção do título de Mestre. APROVADA em 25 de fevereiro de Dr. Eduardo Magno Lages Figueiredo Dr. Elder José Reioli Cirilo Dr. Ricardo Terra Nunes Bueno Villela UFMG/DCC UFSJ/DCOMP UFLA/DCC Dr. Heitor Augustus Xavier Costa Orientador LAVRAS - MG 2014 AGRADECIMENTOS À Universidade Federal de Lavras (UFLA) e ao Departamento de Ciência da Computação (DCC), pela oportunidade concedida para realização do mestrado. À Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (Capes) pela concessão da bolsa de estudos. Aos professores do DCC da UFLA, pelos ensinamentos transmitidos e harmoniosa convivência. Aos professores Dr. Heitor Augustus Xavier Costa e Dr. Eduardo Figueiredo pela orientação, amizade, dedicação e seus ensinamentos que foram de grande relevância para a realização deste trabalho e meu crescimento pessoal e profissional. Aos professores Dr. Elder Cirilo, Dr. Ricardo Terra e Dr. André Freire por se disporem a participar como membros na banca examinadora e pelas preciosas sugestões. Em especial, ao professor Dr. André Freire pelo auxilio na análise estatística, pelo conhecimento compartilhado, pela revisão do meu trabalho, pelos conselhos e pela amizade. Aos professores Dr. Marco Túlio Valente, Dr. Marcelo Maia e Dr. Alessandro Garcia que foram muito atenciosos ao me receber na Universidade Federal de Minas Gerais (UFMG), Universidade Federal de Uberlândia (UFU) e na PUC-Rio, respectivamente, para discutir ideias sobre meu trabalho. Aos amigos do Software Engineering Laboratory (LabSoft) do DCC da UFMG pela atenção que dedicaram a mim. Aos amigos pós-graduandos do DCC da UFLA pelos momentos de estudo, compartilhamento de conhecimentos e experiências. À minha família, que me apoiou incondicionalmente durante todo esse tempo e esteve presente em todos os momentos. ABSTRACT Code smells are symptoms that something is wrong in the source code. They have been catalogued and investigated in several programming techniques, such as object-oriented and aspect-oriented programming. These techniques could also be used to develop Software Product Lines (SPL).Feature-oriented programming (FOP) is a specific technique to deal with the modularization of features in SPL. One of the most popular FOP languages is AHEAD, and as far as we are concerned. Despite of that, we still lack systematic studies on the categorization and detection of code smells in AHEAD-based SPL. Therefore, this work extended the definitions of three traditional code smells, namely God Method, God Class, and Shotgun Surgery, to consider FOP abstractions. We then proposed eight new FOP measures to quantify specific characteristics of compositional approaches like AHEAD. Finally, we combined the proposed and existing measures to define three detection strategies for identifying the investigated code smells and developed a computational tool to measure and detect the code smells. To evaluate the detection strategies, we performed an exploratory study involving 26 participants (Software Engineering experts). The participants performed manual inspections relying on measures to identify code smells in methods and components and we compared their results with the strategies using statistical tests. Our analysis showed that the proposed detection strategies can be used as code smell predictor, since the statistical tests indicated agreement between results obtained from the strategies and those obtained from the study participants. Therefore, the main contributions of this work are fourfold: eight measures that address specific mechanisms of compositional approaches; a different perspective of three traditional code smells; three measure-based detection strategies; and a computational tool to measure and detect the target code smells in AHEAD source code. Keywords: Code Smells. Detection Strategy. Feature-Oriented Programming. Software Product Lines RESUMO Anomalias de código são sintomas que indicam que alguma coisa está errada no código fonte. Essas anomalias têm sido catalogadas e investigadas em diversas técnicas de programação, como as programações orientadas a objetos e orientadas a aspectos. Essas técnicas podem ser utilizadas para desenvolver Linhas de Produtos de Software (LPS). A programação orientada a características (POC) é uma técnica específica para tratar a modularização de características em LPS. Uma das linguagens POC mais populares é a AHEAD e é também utilizada neste trabalho. Apesar disso, ainda faltam estudos sistemáticos sobre a categorização e detecção de anomalias de código em LPSs baseadas em AHEAD. Portanto, este trabalho estende as definições de três anomalias de código tradicionais, chamadas God Method, God Class e Shotgun Surgery, para que elas abordem as abstrações da POC. Foram propostas, inclusive, oito novas medidas para quantificar características específicas de abordagens composicionais como a AHEAD. Finalmente, essas medidas foram combinadas com medidas existentes para definir três estratégias de detecção para identificar as anomalias investigadas e desenvolver uma ferramenta computacional para medir e detectar anomalias de código. Para avaliar as estratégias de detecção, um estudo exploratório foi realizado envolvendo 26 participantes (especialistas em Engenharia de Software). Os participantes realizaram inspeções manuais baseadas em medidas para identificar anomalias de código em métodos e componentes, e os resultados foram comparados com os resultados das estratégias utilizando testes estatísticos. As análises indicam que as estratégias de detecção propostas podem ser utilizadas como preditoras das anomalias, pois os testes estatísticos indicam acordo entre os resultados obtidos a partir das estratégias e os resultados obtidos a partir dos participantes. Portanto, as principais contribuições deste trabalho são: oito medidas que abordam mecanismos específicos de abordagens composicionais; perspectivas diferentes para três anomalias de código tradicionais; três estratégias de detecção baseadas em medidas e uma ferramenta computacional para medir e detectar as anomalias investigadas em código fonte AHEAD. Palavras-chave: Anomalias de Código. Estratégias de Detecção. Programação Orientada a Características. Linhas de Produto de Software. LISTA DE FIGURAS Figure 1-1 Methodological Procedures Figure 2-1 Shotgun Surgery detection strategy Figure 2-2 SPL's Activities Figure 2-3 Domain and Application Engineering Processes Figure 2-4 Phases of the FOSD Figure 2-5 HelloWorld Feature Model Figure 2-6 Source Code of (a) Constant and (b) Refinement Figure 2-7 Mapping Features from Feature Model to Directories Figure 2-8 ATS Composition Process (ATS-AHEAD, 2013) Figure 3-1 Template Figure 3-2 Distribution of the Measures among the Properties Figure 3-3 Feature Model of the TankWar SPL Figure 4-1 SPL God Method Detection Strategy Figure 4-2 SPL God Class Detection Strategy Figure 4-3 SPL Shotgun Surgery Detection Strategy Figure 4-4 VSD Popup Menu Figure 4-5 VSD Measures View Collapsed Figure 4-6 VSD Measures View Expanded Figure 4-7 VSD God Method View Figure 4-8 VSD Preferences Page Figure 5-1 Chart of Selected Thresholds Figure 5-2 Number of Indications per Method - SPL God Method Figure 5-3 Number of Indications per Component - SPL God Class Figure 5-4 Number of Indications per Component - SPL Shotgun Surgery. 107 LISTA DE TABELAS Table 2-1 Traditional and Object-Oriented Measures Table 2-2 Domain Engineering - Subprocesses Table 2-3 Application Engineering - Subprocesses Table 2-4 Jak Resources Table 2-5 Main Differences between Jak and Java Table 3-1 Measures Table 4-1 Analyzed Software Product Lines Table 4-2 SPLs' Measures Table 4-3 Values of the Relation between Measures Table 4-4 Thresholds Values Table 4-5 VSD Measures Table 4-6 Number of Methods/Components with Code Smells found by VSD Table 4-7 Sample of Methods with SPL God Method Table 4-8 Sample of Components with SPL God Class Table 4-9 Sample of Components with SPL Shotgun Surgery Table 5-1 Participants' Courses Table 5-2 Participants' Work Experience Table 5-3 Participants' Knowledge Table 5-4 Example of Inspection Table 5-5 Example of Threshold Tabulation Table 5-6 Example of Inspected Data Tabulation Table 5-7 Kappa's Reference Values (LANDIS; KOCH, 1977) Table 5-8 Thresholds Selected by Participants - SPL God Method Table 5-9 Thresholds Selected by Participants - SPL God Class... 91 Table 5-10 Thresholds Selected by Participants - SPL Shotgun Surgery Table 5-11 Inspection Results and Agreement - SPL God Method Table 5-12 Inspection Results and Agreement - SPL God Class Table 5-13 Inspection Results and Agreement - SPL Shotgun Surgery Table 5-14 Fleiss' Kappa Measures SUMÁRIO 1 INTRODUCTION Motivation Goals Methodological Procedures Dissertation Structure BACKGROUND Initial Considerations Related Work Software Measures Code Smells Software Measures and Code Smells Detection Strategies Software Product Lines Feature-Oriented Software Development Feature-Oriented Programming Final Considerations MEASURES FOR FEATURE-ORIENTED PROGRAMMING Initial Considerations Properties Measures for Annotative, Aspects, and Independent Approaches Measures for Compositional Approaches Final Considerations MEASURES-BASED CODE SMELL DETECTION IN SPL Initial Considerations Analyzed Software Product Lines and Threshold Values SPL God Method SPL God Class SPL Shotgun Surgery Computational Tool for Variability Smell Detection Detecting the Code Smells in the Analyzed SPLs Final Considerations EXPLORATORY STUDY Initial Considerations Participants Training and Manual Inspection Sessions Analysis Procedures Results and Discussions Selected Thresholds SPL God Method... 93 5.5.3 SPL God Class SPL Shotgun Surgery Statistical Tests Threats to Validity Final Considerations FINAL CONSIDERATIONS Conclusion Contribution Future Work Publication Results REFERENCES APPENDIX 12 1 INTRODUCTION The measurement of attributes and properties of projects, process, and software may help companies to control and achieve their main goal: raise their profits with the commercialization of products and services with lower costs, high quality, and lower time to market. To evaluate the quality of software in general, we can follow standards, such as ISO/IEC 25000, which reviews and substitutes ISO/IEC 9126 and ISO/IEC In this standard, the term metric was changed to measure . To develop software with lower costs, high quality, and lower time to market, different approaches are employed in the academia and in industry (SOFTWARE ENGINEERING INSTITUTE - SEI, 2014). Software Product Lines (SPL) is an example of these approaches. In this approach, software is developed from a set of common properties and differs itself by some features to meet needs of the market or of the specific clients (POHL; BOCKLE; LINDEN, 2005; SEI, 2014). SPL is an emergent approach to software design and development whose aim is to promote large-scale and systematic reuse of components (CLEMENTS; NORTHROP, 2002; DAVID; WEISS, 1992). This reuse is possible due to the SPL architecture: common features of a domain compose the kernel and other features define points of variation (JACOBSON; GRISS; JOHNSON, 1997). A feature may be defined as a prominent or distinctive user-visible aspect, quality, or characteristic of software (KANG et al., 1990) and can be implemented with different approaches, such as Compositional and Annotative. In the Compositional approach, features are implemented in separate artifacts, using Feature-Oriented Programming (FOP) (BATORY; SARVELA; RAUSCHMAYER, 2003; PREHOFER, 1997) or Aspect-Oriented Programming (AOP) (KICZALES et al., 1997). In the Annotative approach, features are 13 identified in the code using, for example, preprocessors (APEL; KASTNER, 2009). For these approaches, new measures 1 were proposed or existing measures were adapted to address their specific characteristics (ALI et al., 2010; REVELLE; GETHERS; POSHYVANYK, 2011). The systematic use of the feature concept in the software lifecycle can be achieved with the Feature-Oriented Software Development (FOSD) process. This process has four phases (APEL; KASTNER, 2009): i) Domain Analysis; ii) Domain Design and Specification; iii) Domain Implementation; and iv) Product Configuration and Generation. Companies that intend to use SPL may follow orientations of the frameworks available in literature, including works such as A Framework for Software Product Line Practice (NORTHROP; CLEMENTS, 2007) and A Framework for Software Product Line Engineering (POHL; BOCKLE; LINDEN, 2005). 1.1 Motivation Regarding composition approaches, different techniques may be used to modularize features, such as AHEAD (Algebraic Hierarchical Equations for Application Design) (BATORY; SARVELA; RAUSCHMAYER, 2003), AspectJ (KICZALES et al., 2001), and CaesarJ (MEZINI; OSTERMANN, 2003). Some of those techniques have been studied in order to compare their capability to implement features as basic blocks, to group these blocks, and assign a name to them so that they can be manipulated as cohesive modules (LOPEZ-HERREJON; BATORY; COOK, 2005). In general, the studied techniques are based on two properties: i) base code: it has the main implementation; and ii) delta: it has fragments of code that add functionality to the base code. 1 We used measure instead of metric in alignment with ISO/IEC 14 In spite of the mechanisms for feature modularization, source code developed with FOP may present symptoms of poor quality, such as low cohesion (APEL; BEYER, 2011) and code clones (SCHULZE; APEL; KASTNER, 2010). Some refactoring methods were adapted from traditional methods to minimize code clones (SCHULZE et al., 2012), which is a code smell. Code smell is an indication that there might be something wrong in the source code (FOWLER et al., 1999). Along the years, different code smells have been defined and catalogued. For instance, Kent Beck in Fowler's book (FOWLER et al., 1999) defined 22 code smells for Object-Oriented Programming (OOP). Similarly, Monteiro and Fernandes (2005) proposed a set of code smells based on AOP constructs and abstractions. In fact, we can find code smells in software written in every programming technique. However, we have not found systematic studies concerning code smell characterization and detection on FOP-based SPL. 1.2 Goals The goal of this study was to investigate the presence of code smells in FOP-based SPL developed with compositional approaches and how we can detect them using measure-based detection strategies mechanisms for formulating measures-based rules that capture code smells (LANZA; MARINESCU, 2006; MARINESCU, 2004). Specifically, we intended to: a) Identify and study contemporary measures related to software internal quality using a Systematic Literature Review; b) Identify a repository of SPLs developed with compositional approaches; c) Study how traditional code smells can occur in SPLs; 15 d) Study measure-based detection strategies and how to apply them to detect code smells in SPL; e) Perform an exploratory study to verify if the proposed measure-based detection strategies can be used to detect code smells rather than use manual inspection; f) Develop a tool to measure source code and detect code smells. 1.3 Methodological Procedures This work started on March 2012 and was concluded on February Figure Erro! Nenhum texto com o estilo especificado foi encontrado no documento.-1 depicts the main stages that began with a bibliographical study on software quality, measurement, and SPL. Based on that study, we performed a Systematic Literature Review (SLR) to catalogue FOP and AOP measures and investigated code smells and detection strategies in SPLs. Analyzing the measures found in the SLR, the compositional approaches for feature implementation, FOP source code developed in AHEAD, and code smells definitions, we proposed eight measures to address characteristics of FOP and adapted three definitions of Object-Oriented (OO) code smells. The proposed measures and code smells were necessary since the measures encountered and OO code smells do not address specific mechanisms of SPL and compositional approaches. Finally, we combined those measures with existing measures to define detection strategies (LANZA; MARINESCU, 2006; MARINESCU, 2004) for each code smell. We performed an exploratory study with 26 participants (undergraduate and graduate students) from two different universities. This study aimed to verify if our strategies could be used instead of manual inspections. The participants inspected 60 items (methods or components) observing measure 16 values only, i.e., they had no access to the source code. Based on the participants results and the detection strategies analyses, we performed statistical tests to verify the agreement between them. Figure Erro! Nenhum texto com o estilo especificado foi encontrado no documento.-1 Methodological Procedures 1.4 Dissertation Structure This dissertation is organized as follows. Chapter 2 presents related work and other concepts used to perform this work, such as software measures, code smells, measure-based detection strategies, and Software Product Lines. Chapter 3 discusses FOP measures and presents eight new measures for the compositional approach. Chapter 4 details the adapted code smell definitions, our detection strategies, and a computational tool developed to measure and detect code smells. Chapter 5 explains the study settings, results, and discusses the threats to validity. Chapter 6 presents the conclusion, contribution, future work, and publication results. 17 2 BACKGROUND 2.1 Initial Considerations Developers, project managers, clients, and software maintainers are interested in measuring different properties of software projects, processes, and products. For example, developers might measure software properties aiming at checking requirements, quality, and if the source code is ready to test; and maintainers should be able to evaluate the current system to see what can be upgraded and improved (FENTON; PFLEEGER, 1996). Regarding software internal quality, we can measure properties, such as size, coupling, and complexity. However, such measures are too fine grained and it is necessary to combine them to capture more meaningful properties or symptoms of code smells, such as God Class or God Method (FOWLER et al., 1999). Those measures can be used in the context of SPL and
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks