Spelling suggestions: "subject:"pode smells"" "subject:"pode ramells""
1 |
INVESTIGANDO A RELAÇÃO ENTRE CODE SMELLS E PROBLEMAS DE DESIGN: ESTUDOS QUALITATIVOS EM MICROEMPRESAS DE SOFTWAREFreitas, Mydiã Falcão 16 December 2016 (has links)
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.
|
2 |
A critical analysis of two refactoring toolsDrozdz, Martin Zbigniew 24 June 2008 (has links)
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
|
3 |
Visualizing Java Code Smells with DotplotsJefferson, Alvin Hayes 01 January 2008 (has links)
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.
|
4 |
Aplicando síntese temática em engenharia de softwarePrates, Luciana Carla Lins 18 September 2015 (has links)
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.
|
5 |
Do Software Code Smell Checkers Smell Themselves? : A Self ReflectionBampovits, Stefanos, Löwe, Amelie January 2020 (has links)
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.
|
6 |
[en] ON THE PRIORITIZATION OF DESIGN-RELEVANT SMELLS / [pt] PRIORIZAÇÃO DE ANOMALIAS DE CÓDIGO RELEVANTES AO PROJETO DOS SISTEMAS DE SOFTWAREANDERSON JOSE SILVA DE OLIVEIRA 31 March 2020 (has links)
[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.
|
7 |
Automated Identification and Application of Code Refactoring in Scratch to Promote the Culture Quality from the Ground upTechapalokul, Peeratham 04 June 2020 (has links)
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.
|
8 |
Javascript code smells från en utvecklares perspektiv / Javascript code smells from a developer’s perspectiveMåbrink, Alexander, Möller, André January 2021 (has links)
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.
|
9 |
[pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS / [en] UNVEILING DESIGN PROBLEMS IDENTIFICATION: COMBINING MULTIPLE SYMPTOMSANDERSON JOSE SILVA DE OLIVEIRA 02 January 2024 (has links)
[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.
|
10 |
Kodrefaktorisering / Code RefactoringNylander, Amy January 2013 (has links)
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.
|
Page generated in 0.0524 seconds