Submitted by Diogo Barreiros (diogo.barreiros@ufba.br) on 2017-06-08T11:28:18Z No. of bitstreams: 1 Dissertação Mydiã_Freitas.pdf: 3038925 bytes, checksum: 799df53dc64e5b455ed52bb760695ae2 (MD5) / Approved for entry into archive by Vanessa Reis (vanessa.jamile@ufba.br) on 2017-06-12T15:16:18Z (GMT) No. of bitstreams: 1 Dissertação Mydiã_Freitas.pdf: 3038925 bytes, checksum: 799df53dc64e5b455ed52bb760695ae2 (MD5) / Made available in DSpace on 2017-06-12T15:16:18Z (GMT). No. of bitstreams: 1 Dissertação Mydiã_Freitas.pdf: 3038925 bytes, checksum: 799df53dc64e5b455ed52bb760695ae2 (MD5) / Code smell é definido como um potencial problema de design localizado em determinada parte do código fonte de um sistema de software e pode indicar deficiências no design que podem influenciar a facilidade de manutenção, facilidade de teste e confiabilidade do software. Um bom exemplo de code smell que vai de encontro aos princípios do bom design definido na programação orientada a objetos é o Shotgun Surgery, que corresponde a classes cuja modificação implica em muitas pequenas alterações em muitas outras classes. Quando as modificações estão espalhadas, elas são difíceis de serem encontradas. Como resultado, é fácil perder uma mudança importante, causando assim, problemas na manutenção do sistema. A atividade de identificação de code smells é analisada e confirmada pelo próprio programador ou um revisor independente, contudo, a detecção manual de code smells por meio de inspeções de código consume muito tempo e é pouco escalável. Ferramentas que auxiliam a identificação de code smells têm sido bastante utilizadas em diversos estudos. Neste contexto, esta dissertação propõe investigar se a detecção automática de code smells por meio de ferramentas é considerada útil pelos desenvolvedores como forma de avaliar a qualidade do design de sistemas de software, principalmente em termos de facilidade de manutenção. Realizamos três estudos: sendo um estudo preliminar e dois estudos experimentais similares. O objetivo do estudo preliminar era nos auxiliar a perceber e corrigir problemas que pudessem surgir no decorrer do desenvolvimento dos estudos experimentais. O objetivo desses estudos era investigar a qualidade do design de sistemas de softwares e code smells através do uso de ferramentas de detecção. Os resultados desses estudos indicam que existe relação entre os code smells God Class, Data Class, Shotgun Surgery, Refused Bequest e Feature Envy com problemas de design associados a dificuldades no processo de manutenção de sistemas de softwares.

This study provides a critical analysis of refactoring by surveying the refactoring tools in IDEA and Eclipse. Ways are discussed to locate targets for refactorings, via detection of code smells from static code analysis in IDEA and during the compilation process in Eclipse. New code smells are defined as well as the refactorings needed to remove the code smells. The impacts the code smells have on design are well documented. Considerable effort is made to describe how these code smells and their refactorings can be used to improve design. Practical methods are provided to detect code smells in large projects such as Sun’s JDK. The methodology includes a classification scheme to categorise code smells by their value and complexity to handle large projects more efficiently. Additionally a detailed analysis is performed on the evolution of the JDK from a maintainability point of view. Code smells are used to measure maintainability in this instance. / Dissertation (MSc (Computer Science))--University of Pretoria, 2008. / Computer Science / unrestricted

An approach using dot plots as an aid to visualizing smells within Java source files is presented. Dot plots are a visual tool that allows for viewing duplication in a document or text string. Our approach uses a plug-in for the Eclipse Java IDE to convert Java source files into dot plots. The goal here is to find problem areas in the code, known as "Code Smells", that could indicate that the source file needs to be modified or refactored. In the dot plot these problem areas appear as sections that contain interesting dot formations. Color is also used to enhance places of the dot plot that could be important. Duplication is a common problem in source code and also an important Code Smell. We will show that through finding the Duplicate Code smell we will also be able to find other code smells creating a plug-in that a programmer can use during the coding process to help improve code design.

Submitted by Mayara Nascimento (mayara.nascimento@ufba.br) on 2016-05-31T14:36:19Z No. of bitstreams: 1 DissertaçãoMestrado - Luciana Lins versão completa (1) 22.12.15.pdf: 3112045 bytes, checksum: 6d585e19435cc700b532cd4aed755f85 (MD5) / Approved for entry into archive by Alda Lima da Silva (sivalda@ufba.br) on 2016-06-03T23:25:31Z (GMT) No. of bitstreams: 1 DissertaçãoMestrado - Luciana Lins versão completa (1) 22.12.15.pdf: 3112045 bytes, checksum: 6d585e19435cc700b532cd4aed755f85 (MD5) / Made available in DSpace on 2016-06-03T23:25:31Z (GMT). No. of bitstreams: 1 DissertaçãoMestrado - Luciana Lins versão completa (1) 22.12.15.pdf: 3112045 bytes, checksum: 6d585e19435cc700b532cd4aed755f85 (MD5) / A revisão sistemática é um recurso importante para a engenharia de software baseada em evidências, que consiste em uma forma de síntese dos resultados de pesquisas primárias relacionados com um problema específico. O presente trabalho tem como objetivo apresentar um método refinado de síntese temática em Engenharia de Software com base na proposta de Cruzes e Dyba [20]. O método foi testado na análise qualitativa de um conjunto de estudos primários provenientes de uma revisão sistemática sobre o tema Code Smells. Os principais resultados são a apresentação passos que compõem o método adotado, lições aprendidas, principais dificuldades durante o processo, bem como as descobertas relacionadas aos resultados obtidos para o tema analisado.

Much of software engineering research and practice is concerned with improving software quality. While enormous prior efforts have focused on improving the quality of programs, this dissertation instead provides the means to educate the next generation of programmers who care deeply about software quality. If they embrace the culture of quality, these programmers would be positioned to drastically improve the quality of the software ecosystem. This dissertation describes novel methodologies, techniques, and tools for introducing novice programmers to software quality and its systematic improvement. This research builds on the success of Scratch, a popular novice-oriented block-based programming language, to support the learning of code quality and its improvement. This dissertation improves the understanding of quality problems of novice programmers, creates analysis and quality improvement technologies, and develops instructional approaches for teaching quality improvement. The contributions of this dissertation are as follows. (1) We identify twelve code smells endemic to Scratch, show their prevalence in a large representative codebase, and demonstrate how they hinder project reuse and communal learning. (2) We introduce four new refactorings for Scratch, develop an infrastructure to support them in the Scratch programming environment, and evaluate their effectiveness for the target audience. (3) We study the impact of introducing code quality concepts alongside the fundamentals of programming with and without automated refactoring support. Our findings confirm that it is not only feasible but also advantageous to promote the culture of quality from the ground up. The contributions of this dissertation can benefit both novice programmers and introductory computing educators. / Doctor of Philosophy / Software remains one of the most defect-prone artifacts across all engineering disciplines. Much of software engineering research and practice is concerned with improving software quality. While enormous prior efforts have focused on improving the quality of programs, this dissertation instead provides the means to educate the next generation of programmers who care deeply about software quality. If they embrace the culture of quality, these programmers would be positioned to drastically improve the quality of the software ecosystem, akin to professionals in traditional engineering disciplines. This dissertation describes novel methodologies, techniques, and tools for introducing novice programmers to software quality and its systematic improvement. This research builds on the success of Scratch, a popular visual programming language for teaching introductory students, to support the learning of code quality and its improvement. This dissertation improves the understanding of quality problems of novice programmers, creates analysis and quality improvement technologies, and develops instructional approaches for teaching quality improvement. This dissertation contributes (1) a large-scale study of recurring quality problems in Scratch projects and how these problems hinder communal learning, (2) four new refactorings, quality improving behavior-preserving program transformations, as well as their implementation and evaluation, (3) a study of the impact of introducing code quality concepts alongside the fundamentals of programming with and without automated refactoring support. Our findings confirm that it is not only feasible but also advantageous to promote the culture of quality from the ground up. The contributions of this dissertation can benefit both novice programmers and introductory computing educators.

Code smells are defined as poor implementation and coding practices, and as a result decrease the overall quality of a source code. A number of code smell detection tools are available to automatically detect poor implementation choices, i.e., code smells. The detection of code smells is essential in order to improve the quality of the source code. This report aims to evaluate the accuracy and quality of seven different open-source code smell detection tools, with the purpose of establishing their level of trustworthiness.To assess the trustworthiness of a tool, we utilize a controlled experiment in which several versions of each tool are scrutinized using the most recent version of the same tool. In particular, we wanted to verify to what extent the code smell detection tools that reveal code smells in other systems, contain smells themselves. We further study the evolution of code smells in the tools in terms of number, types of code smells and code smell density.

[pt] Sistemas de software provavelmente enfrentarão os chamados problemas de projeto. Um problema de projeto é o resultado de más decisões que podem afetar alguns atributos de qualidade importantes do sistema de software, como manutenção, desempenho e afins. Dada a típica falta de documentação do projeto, os desenvolvedores precisam confiar em sintomas que aparecem a nível de implementação para identificar e remover problemas de projeto. Um sintoma a nível de implementação geralmente se manifesta como uma anomalia de código, que se trata de uma microestrutura no programa possivelmente indicando a presença de (ou parte de) um problema de projeto. Grandes programas possuem centenas ou milhares de elementos (pacotes, classes, interfaces e afins) nos quais uma proporção significativa é afetada por anomalias. No entanto, muitas dessas anomalias não possuem relação com problemas de projeto, em outras palavras, elas não são anomalias relevantes ao problema de projeto. Desse modo, torna-se difícil e demorado priorizar os elementos anômalos do programa que são suspeitos de terem problema de projeto. Infelizmente, a literatura não fornece aos desenvolvedores heurísticas que auxiliem a priorização destes elementos de projeto suspeitos. Neste contexto, esta dissertação reporta dois estudos que objetivam auxiliar na elaboração de tais heurísticas, visando auxiliar o desenvolvedor nas decisões de priorização. O objetivo destas heurísticas é localizar uma pequena lista de elementos suspeitos de terem anomalias de código relevantes ao problema de projeto. Nosso primeiro estudo consiste em uma análise qualitativa para determinar os critérios utilizados pelos desenvolvedores para a priorização de elementos suspeitos de terem problemas de projeto. Com base nesses critérios, derivamos um conjunto preliminar de heurísticas de priorização. Nosso segundo estudo centrou-se na avaliação destas heurísticas. Como resultado, descobrimos que duas das nove heurísticas alcançaram os melhores resultados de precisão. As melhores heurísticas são baseadas em dois critérios: diversidade de anomalias e granularidade das anomalias. Nossas descobertas sugerem que fomos capazes de obter uma primeira abordagem promissora para apoiar os desenvolvedores na priorização de elementos com anomalias de código relevantes ao projeto de software. / [en] Software systems are likely to face what is called design problems. A design problem is the result of bad decisions that can aect some important quality attributes of the software system such as maintainability, performance and the like. Given the typical lack of design documentation, developers have to rely on implementation-level symptoms to identify and remove design problems. An implementation-level symptom usually manifests as a code smell, a micro-structure in the program possibly indicating the presence of (or part of) a design problem. Large programs have hundreds or thousands of program elements (packages, classes, interfaces, and the like) in which a significant proportion is aected by smells. However, many of these smells may bear no relationship with design problems, i.e. they are not design-relevant smells. Then, it becomes hard and time-consuming to prioritize smelly program elements being suspects of having a design problem. Unfortunately, the literature fails to provide developers with heuristics to support the prioritization of these suspicious program elements. In this context, this dissertation reports two studies aimed at assisting in the elaboration of such prioritization heuristics. The goal of these heuristics is to locate a short (high priority) list of smelly program elements, which are suspects of having design-relevant smells. Our first study consists of a qualitative analysis on recurring criteria used by developers, in practice, to prioritize elements suspicious of having design problems. Based on these criteria, we derived a preliminary suite of prioritization heuristics. Our second study focused on the evaluation of the proposed heuristics. As a result, we found that two out of nine heuristics reached the best results in precision. The best heuristics are based on two criteria: smell diversity and smell granularity. Our findings suggest that we were able to derive a first promising approach to support developers in prioritizing elements with design-relevant smells.

Software development can be a difficult and time consuming task. In addition, producing good code is even more difficult. Poor design and implementation choices in software code can result in an end product that is both difficult to understand and difficult to maintain. A collective name for implementation and design choices that is considered to have a negative impact or indicate something negative in software code is Code smells. In this study, we identify 34 unique code smells through a systematic literature study. The results are then ranked and validated with interviews with people who work or have worked with Javascript in a professional environment at some point during the past five years. The end result is a ranked list of 32 code smells that are applicable to Javascript. The result shows that the five highest ranked code smells are Variable name conflict in closures, Depth, Argument Type Mismatch, Duplicated code and Excessive global Variables.

[pt] O projeto de software resulta das decisões ao longo do seu desenvolvimento. Algumas dessas decisões podem levar a problemas de projeto, afetando negativamente os requisitos não funcionais (RNFs). Embora seja crucial identificar esses problemas, essa é uma tarefa complexa, especialmente quando o código-fonte é o único artefato disponível. Nessa tarefa, os desenvolvedores podem ter que considerar vários sintomas (por exemplo, anomalias de código) para identificar até mesmo um único problema de projeto. Estudos anteriores sugerem que usar um único sintoma pode ser inadequado para identificar tais problemas. Portanto, nesta tese, investigamos como múltiplos sintomas podem ser usados nessa identificação. Em nosso primeiro estudo, nos concentramos em investigar o uso de anomalias de código bem conhecidos (anomalias de manutenabilidade). Nós identificamos que os desenvolvedores podem se beneficiar desse tipo de sintoma quando as ocorrências das anomalias afetam a mesma localização do programa e formam um padrão, podendo indicar melhor a presença de um problema de projeto. No entanto, também revelamos as limitações ao depender exclusivamente desse tipo de sintoma, destacando a necessidade de contexto adicional. Isso nos levou ao segundo estudo, onde investigamos um tipo adicional de sintoma, anomalias de robustez, e seu uso combinado com anumalias de manutenabilidade. Nós identificamos que ambos os tipos de anomalia de código podem ajudar os desenvolvedores na identificação de problemas de projeto principalmente relacionados à má modularização do sistema. Através desses dois estudos, observamos a necessidade de compreender as perspectivas e estratégias dos desenvolvedores em relação aos RNFs do sistema. Ao fazê-lo, podemos potencialmente entender quem são os desenvolvedores mais capazes de prevenir, discutir e identificar problemas de projeto. Isso nos levou ao terceiro estudo, onde investigamos como os desenvolvedores discutem e abordam RNFs em seus sistemas, revelando estratégias comuns em relação a esses requisitos. Esses resultados nos proporcionaram uma compreensão mais abrangente de como os desenvolvedores podem combinar diferentes sintomas e como percebem sua importância dentro de seus sistemas. / [en] Software design results from stakeholder decisions made through software development. Some of these decisions may lead to design problems, negatively impacting non-functional requirements (NFRs). Even though identifying design problems is crucial, this is a complex task, especially when the source code is the only artifact available. Along this task, developers may have to reason about multiple symptoms (e.g., code smells and nonconformities with NFRs) to identify even a single design problem. In fact, previous studies suggest that relying on a single symptom may be inadequate for the design problem identification. Thus, in this thesis, we investigate the role that the use of multiple symptoms may have on the identification of design problems. In our first study, we focused on investigating the use of well-known code smells (called here maintainability smells) to support this task. Our results indicated that developers could benefit from this type of symptom when smell occurrences affect the same program location and form a pattern; i.e., a set of co-occurring maintainability smells may better indicate the presence of a design problem. Nevertheless, we also reveal the limitations of relying solely on this type of symptom, highlighting the need for additional context. This leads us to the second study, where we investigate an additional type of symptom, robustness smells, and its combined use with maintainability smells. Our results indicated that the use of both types of smells can help developers in the identification of design problems mainly related to bad modularization of the system (e.g. excess of responsibilities assigned to the same component). Through these two studies, we observed the need to understand the perspectives and strategies of developers toward the NFRs of the system. In doing so, we can potentially understand who are the developers better able to prevent, discuss and identify design problems. That led us to our third study, where we investigated how developers discuss and address NFRs in their systems, uncovering common strategies toward these requirements. These results led us to a more comprehensive understanding of how developers can combine different symptoms and how they perceive their significance within their systems.

Denna rapport har sitt ursprung i det kodefaktoriseringsarbete som utfärdats våren 2013 som examensarbete i dataingenjörsprogrammet vid Örebro Universitet. Arbetet utfärdades på Nethouse i Örebro, och hade stort fokus på koddesign och kodkvalitet. I rapporten diskuteras vilka faktorer som påverkar hur underhållbar och läsbar en kod är, men också hur man på ett rimligt sätt kan utvärdera och mäta kodkvalitet. Den teoretiska biten blandas med den praktiska, där läsaren introduceras för ett flertal metoder, och hur dessa sedan implementerades i det faktiska projektet som Nethouse tillhandahöll. / This report has its origins in the code refactoring work issued in spring 2013 as a Degree Project in the Computer Engineering Programme, at Örebro University. The work took place at Nethouse in Örebro, and had a major focus on code design, and code quality. The report discusses the factors that affect how maintainable and readable a code is, but also how to reasonably evaluate and measure code quality. The theory is mixed with the practical, where the reader is introduced to a variety of methods, and how these were then implemented in the actual project that Nethouse provided.