Spreadsheets are a widely used end-user programming tool. Field audits have found that 80-90% of spreadsheets created by end users contain textual and formula errors in spreadsheets. Such errors may have severe negative consequences for users in terms of productivity, credibility, or profits. To solve the problem of spreadsheet errors, researchers have presented manual and automatic error detection. Manual error detection is both tedious and time-consuming, while automatic error detection is limited to only finding some formula error categories such as formula reference errors. Both approaches do not provide the optimum result in error detection. We have tested a new error detection approach by detecting bad smells in spreadsheets, which is an indication that an error might be present. Originally developed for object-oriented programming, examples include the large class, and the lazy class. We have adapted the concept of bad smells to spreadsheets. Each bad smell detector might indicate an issue in the spreadsheet, but the indication is not definitive, since the user must examine the spreadsheet and make a final judgment about whether an error is actually present. We evaluated 11 bad smell detectors by analyzing the true positives against the false positives. The result shows that six detectors can highlight some error categories, such as categorical errors and typographical errors. / Graduation date: 2013

Submitted by Santos Davilene (davilenes@ufba.br) on 2016-05-25T14:04:00Z No. of bitstreams: 1 FINAL Dissertação Mestrado - Hugo Sica de Andrade.pdf: 4068482 bytes, checksum: f4538e19111b94a4c1caae39a4e6c525 (MD5) / Made available in DSpace on 2016-05-25T14:04:00Z (GMT). No. of bitstreams: 1 FINAL Dissertação Mestrado - Hugo Sica de Andrade.pdf: 4068482 bytes, checksum: f4538e19111b94a4c1caae39a4e6c525 (MD5) / O paradigma de Linhas de Produto de Software (LPS) tem provado ser um meio efetivo para se obter reuso de grande escala em diferentes domínios. A abordagem tira proveito de aspectos comuns entre diferentes produtos, enquanto também considera propriedades específicas dos mesmos. A arquitetura tem um papel importante na engenharia de LPS, provendo meios para melhor entender e manter o ambiente de derivação de produtos. No entanto, é difícil evoluir tal arquitetura, pois nem sempre é claro onde e como refatorar. A arquitetura de uma LPS contém um modelo que irá resultar na arquitetura de produtos, e muitas vezes inclui soluções que indicam um design (arquitetural) inadequado. Uma forma de avaliar tais decisões de design é através da identificação de bad smells de arquitetura, ou seja, propriedades que prejudicam a qualidade do software, mas não são necessariamente errôneas ou representam falhas. Nesse sentido, o objetivo desta dissertação é obter um melhor entendimento de bad smells de arquitetura em LPSs. Primeiramente, o estado-da-arte atual em Arquiteturas de Linhas de Produto de software (ALP) é investigado através de um estudo de mapeamento sistemático. Este apresenta uma visão geral da área através de análise e categorização de evidências. O estudo idenfitica gaps, tendências, e provê direções futuras para pesquisa. Ademais, esta dissertação trata do fenômeno de bad smells de arquitetura no contexto de LPSs através de dois estudos exploratórios em domínios diferentes. O primeiro estudo exploratório conduz uma investigação sobre as implicações de propriedades estruturais em uma LPS no domínio de editores de texto, enquanto o segundo estudo foca em uma LPS no domínio mobile. Antes da busca pelos smells em ambos os estudos, informações relevantes para a arquitetura foram recuperadas do código fonte para que as arquiteturas fossem definidas.

Submitted by Lucienne Costa (lucienneferreira@ufcg.edu.br) on 2018-05-02T20:10:07Z No. of bitstreams: 1 MÁRIO HOZANO LUCAS DE SOUZA – TESE (PPGCC) 2017.pdf: 3990516 bytes, checksum: b6a38a396737d92fd11b9fa9fb3027f5 (MD5) / Made available in DSpace on 2018-05-02T20:10:07Z (GMT). No. of bitstreams: 1 MÁRIO HOZANO LUCAS DE SOUZA – TESE (PPGCC) 2017.pdf: 3990516 bytes, checksum: b6a38a396737d92fd11b9fa9fb3027f5 (MD5) Previous issue date: 2017-06-02 / Anomalias de código conhecidas como bad smells indicam estruturas em código que podem prejudicar a compreensão e manutenção de programas. A ausência de uma definição clara para os bad smells contribui para que diferentes interpretações sejam consideradas, fazendo com que desenvolvedores possuam uma noção particular do que são tais anomalias. Nesse sentido, algoritmos de aprendizagem de máquina têm sido utilizados para customizar a detecção de bad smells a partir de um conjunto de avaliações. Entretanto, tal customização não é guiada a partir das diferentes heurísticas utilizadas pelos desenvolvedores para a detecção de smells. Como consequência tal customização pode não ser eficiente, exigindo um esforço considerável para obter uma alta efetividade. Esse trabalho apresenta um extensivo estudo que investiga o quão similar os desenvolvedores detectam smells em código, e analisa fatores que podem influenciar em tal detecção. As conclusões desse estudo motivaram a criação de uma técnica de customização guiada para melhorar a eficiência na detecção de smells. Essa técnica, definida como Histrategy, guia a customização a partir de um conjunto limitado de estratégias para detectar um mesmo tipo de smell. A partir de um estudo experimental que envolveu 62 desenvolvedores e 8 tipos de bad smell. Os resultados indicaram que a Histrategy apresentou performance superior a 6 algoritmos de aprendizagem de máquina, utilizados em abordagens não guiadas. Por fim, os resultados confirmaram que a customização guiada foi capaz assistir desenvolvedores com estratégias de detecção eficazes e eficientes. / Bad smells indicate poor implementation choices that may hinder program comprehension and maintenance. Their informal definition allows developers to follow different heuristics to detect smells in their projects. In such context, machine learning algorithms have been adapted to customize smell detection according to a set of examples of smell evaluations. However, such customization is not guided (i.e. constrained) to consider alternative heuristics used by developers when detecting smells. As a result, their customization might not be efficient, requiring a considerable effort to reach high effectiveness. This work presents an extensive study concerning how similar the developers detect smells in code, and investigate which factors may influence in such detection. The findings of this study lead to the creation of Histrategy, a guided customization technique to improve the efficiency on smell detection. Histrategy considers a limited set of detection strategies, produced from different detection heuristics, as input of a customization process. The output of the customization process consists of a detection strategy tailored to each developer. The technique was evaluated in an experimental study with 62 developers and eight types of code smells. The results showed that Histrategy is able to outperform six widely adopted machine learning algorithms, used in unguided approaches. Finally, the results confirmed that the guided customization was able to support developers with effective and efficient detection strategies.

Tests are important artifacts in the software development process. Testing activities such as test automation, test maintenance, and test suite optimization mainly rely on an in-depth understanding of test specifications. The manual process of writing testspecifications in natural language can create many different quality issues such as ambiguous, incomplete, redundant, or inconsistent test cases. Nowadays, the concept of test smells is proposed by several researchers to be used as indicators of low-qualityattributes in test specifications. Quality assurance processes for test specifications often rely on manual reviews to detect these smells. The manual process of detecting these smells is considered time consuming and costly. However, there is currently no work that implements a comprehensive quality model that classifies and identifies these smells by using a systematic strategy. As a result, there is a need for machine-supported analytical measures that decrease the time and effort needed to detect these smells manually, especially when it comes to reviewing and validating large test specifications.This study aims to investigate which natural language smell metrics implemented in NALABS can be found in test specifications and to measure the sufficiency of those smellmetrics. It also aims to extend these smell metrics by exploring, proposing, or combining with new bad smell metrics to cover more aspects of natural language test quality. The results of the study show that the smell metrics exists in real-world test specifications and can uncover many potential quality issues by assisting test designers in identifying certain types of quality issues pertaining to for example the understandability and complexity of test specifications. Moreover, the results show thatthe list of smell metrics implemented in NALABS is incomplete and can be extended to cover more aspects of test quality.

A key factor in creating software of good quality is that the requirements for the project being developed are as unambiguous and clear as possible, so the developers will be able to develop the product quickly and effectively. So, there is a need for tools that help requirements engineers create quality requirements. The attributes that define a poorly written requirement are called bad smells. In this thesis we investigate the NALABS tools bad smell detecting capabilities when analyzing industrial requirements. First, we performed a literature study to investigate what types of bad smells exist for requirements and how they were specified. After that we used a case study to examine how many smells and of what categories the NALABS tool detects, when it analyzes industrial requirements. Lastly, we used a small experiment to examine how accurately NALABS detects smells, by designing a simple console application that counted instances of bad smell words in a set of keywords that were from the NALABS tool. The results we gathered gave us an indication that NALABS detects bad smells in all the categories of bad smells that are implemented in it, to a varying degree. Through this thesis we hope to extend the knowledge about bad requirements smells, clarify what attributes of a requirement might be a bad smell, and investigate to what degree the NALABS tool can detect bad smells in industrial requirements.

Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-08-16T14:17:44Z No. of bitstreams: 1 PABLO OLIVEIRA ANTONINO DE ASSIS - DISSERTAÇÃO PPGCC 2009..pdf: 1244760 bytes, checksum: 30e75bebed5cedb9f7f2d0eb80097c6f (MD5) / Made available in DSpace on 2018-08-16T14:17:44Z (GMT). No. of bitstreams: 1 PABLO OLIVEIRA ANTONINO DE ASSIS - DISSERTAÇÃO PPGCC 2009..pdf: 1244760 bytes, checksum: 30e75bebed5cedb9f7f2d0eb80097c6f (MD5) Previous issue date: 2009-03-13 / Capes / Nós investigamos a evolução de oito softwares open source e cinco proprietários, a fim de verificar a existência de correlações estatísticas entre complexidade e medidas de qualidade em termos de bad smells e bugs. Em todos os projetos, encontramos fortes correlações estatísticas entre medidas de complexidade (WMC) e qualidade. Todos os softwares proprietários e cinco open source apresentaram índices de correlação muito forte (r > 0.9). Surpreendentemente, em três dos softwares open source, a correlação encontrada foi forte, porém negativa. Isto é atribuído ao fato de que, nestes projetos, os bad smells foram removidos intencionalmente. Este resultado sugere que, apesar da correlação, não existe necessariamente relação de causa-efeito entre métricas de complexidade e de qualidade. Dessa maneira, concluímos que apenas eliminar bad smells não é uma boa estratégia a ser seguida se o objetivo for reduzir a complexidade do design e melhorar a qualidade nos termos associados à redução da complexidade. / We have studied the evolution of eight open source projects and five proprietary ones, looking for statistical correlations between complexity and quality measures in terms of bad smells and bugs detected. In all projects, we found strong statistical correlations between complexity (WMC) and quality measures. In all the legacies softwares and five of open sources, the correlation can be considered very strong (r > 0.9). Surprisingly, in three of the open source, the correlation is strong, but negative. This has been attributed to the fact that, in these projects, designers have intentionally controlled the quality measures under study, by applying refactoring strategies. These results suggest that, despite the correlation, there is no necessary cause-effect relation between complexity and quality measures. We conclude that just eliminate bad smells is not a good strategy to be followed if the desired objective is to reduce software design complexity. Then also does not improve software quality in terms associated to software complexity reduction.

Les changements sont faits de façon continue dans le code source des logiciels pour prendre en compte les besoins des clients et corriger les fautes. Les changements continus peuvent conduire aux défauts de code et de conception. Les défauts de conception sont des mauvaises solutions à des problèmes récurrents de conception ou d’implémentation, généralement dans le développement orienté objet. Au cours des activités de compréhension et de changement et en raison du temps d’accès au marché, du manque de compréhension, et de leur expérience, les développeurs ne peuvent pas toujours suivre les normes de conception et les techniques de codage comme les patrons de conception. Par conséquent, ils introduisent des défauts de conception dans leurs systèmes. Dans la littérature, plusieurs auteurs ont fait valoir que les défauts de conception rendent les systèmes orientés objet plus difficile à comprendre, plus sujets aux fautes, et plus difficiles à changer que les systèmes sans les défauts de conception. Pourtant, seulement quelques-uns de ces auteurs ont fait une étude empirique sur l’impact des défauts de conception sur la compréhension et aucun d’entre eux n’a étudié l’impact des défauts de conception sur l’effort des développeurs pour corriger les fautes. Dans cette thèse, nous proposons trois principales contributions. La première contribution est une étude empirique pour apporter des preuves de l’impact des défauts de conception sur la compréhension et le changement. Nous concevons et effectuons deux expériences avec 59 sujets, afin d’évaluer l’impact de la composition de deux occurrences de Blob ou deux occurrences de spaghetti code sur la performance des développeurs effectuant des tâches de compréhension et de changement. Nous mesurons la performance des développeurs en utilisant: (1) l’indice de charge de travail de la NASA pour leurs efforts, (2) le temps qu’ils ont passé dans l’accomplissement de leurs tâches, et (3) les pourcentages de bonnes réponses. Les résultats des deux expériences ont montré que deux occurrences de Blob ou de spaghetti code sont un obstacle significatif pour la performance des développeurs lors de tâches de compréhension et de changement. Les résultats obtenus justifient les recherches antérieures sur la spécification et la détection des défauts de conception. Les équipes de développement de logiciels doivent mettre en garde les développeurs contre le nombre élevé d’occurrences de défauts de conception et recommander des refactorisations à chaque étape du processus de développement pour supprimer ces défauts de conception quand c’est possible. Dans la deuxième contribution, nous étudions la relation entre les défauts de conception et les fautes. Nous étudions l’impact de la présence des défauts de conception sur l’effort nécessaire pour corriger les fautes. Nous mesurons l’effort pour corriger les fautes à l’aide de trois indicateurs: (1) la durée de la période de correction, (2) le nombre de champs et méthodes touchés par la correction des fautes et (3) l’entropie des corrections de fautes dans le code-source. Nous menons une étude empirique avec 12 défauts de conception détectés dans 54 versions de quatre systèmes: ArgoUML, Eclipse, Mylyn, et Rhino. Nos résultats ont montré que la durée de la période de correction est plus longue pour les fautes impliquant des classes avec des défauts de conception. En outre, la correction des fautes dans les classes avec des défauts de conception fait changer plus de fichiers, plus les champs et des méthodes. Nous avons également observé que, après la correction d’une faute, le nombre d’occurrences de défauts de conception dans les classes impliquées dans la correction de la faute diminue. Comprendre l’impact des défauts de conception sur l’effort des développeurs pour corriger les fautes est important afin d’aider les équipes de développement pour mieux évaluer et prévoir l’impact de leurs décisions de conception et donc canaliser leurs efforts pour améliorer la qualité de leurs systèmes. Les équipes de développement doivent contrôler et supprimer les défauts de conception de leurs systèmes car ils sont susceptibles d’augmenter les efforts de changement. La troisième contribution concerne la détection des défauts de conception. Pendant les activités de maintenance, il est important de disposer d’un outil capable de détecter les défauts de conception de façon incrémentale et itérative. Ce processus de détection incrémentale et itérative pourrait réduire les coûts, les efforts et les ressources en permettant aux praticiens d’identifier et de prendre en compte les occurrences de défauts de conception comme ils les trouvent lors de la compréhension et des changements. Les chercheurs ont proposé des approches pour détecter les occurrences de défauts de conception, mais ces approches ont actuellement quatre limites: (1) elles nécessitent une connaissance approfondie des défauts de conception, (2) elles ont une précision et un rappel limités, (3) elles ne sont pas itératives et incrémentales et (4) elles ne peuvent pas être appliquées sur des sous-ensembles de systèmes. Pour surmonter ces limitations, nous introduisons SMURF, une nouvelle approche pour détecter les défauts de conception, basé sur une technique d’apprentissage automatique — machines à vecteur de support — et prenant en compte les retours des praticiens. Grâce à une étude empirique portant sur trois systèmes et quatre défauts de conception, nous avons montré que la précision et le rappel de SMURF sont supérieurs à ceux de DETEX et BDTEX lors de la détection des occurrences de défauts de conception. Nous avons également montré que SMURF peut être appliqué à la fois dans les configurations intra-système et inter-système. Enfin, nous avons montré que la précision et le rappel de SMURF sont améliorés quand on prend en compte les retours des praticiens. / Changes are continuously made in the source code to take into account the needs of the customers and fix the faults. Continuous change can lead to antipatterns and code smells, collectively called “design smells” to occur in the source code. Design smells are poor solutions to recurring design or implementation problems, typically in object-oriented development. During comprehension and changes activities and due to the time-to-market, lack of understanding, and the developers’ experience, developers cannot always follow standard designing and coding techniques, i.e., design patterns. Consequently, they introduce design smells in their systems. In the literature, several authors claimed that design smells make object-oriented software systems more difficult to understand, more fault-prone, and harder to change than systems without such design smells. Yet, few of these authors empirically investigate the impact of design smells on software understandability and none of them authors studied the impact of design smells on developers’ effort. In this thesis, we propose three principal contributions. The first contribution is an empirical study to bring evidence of the impact of design smells on comprehension and change. We design and conduct two experiments with 59 subjects, to assess the impact of the composition of two Blob or two Spaghetti Code on the performance of developers performing comprehension and change tasks. We measure developers’ performance using: (1) the NASA task load index for their effort; (2) the time that they spent performing their tasks; and, (3) their percentages of correct answers. The results of the two experiments showed that two occurrences of Blob or Spaghetti Code design smells impedes significantly developers performance during comprehension and change tasks. The obtained results justify a posteriori previous researches on the specification and detection of design smells. Software development teams should warn developers against high number of occurrences of design smells and recommend refactorings at each step of the development to remove them when possible. In the second contribution, we investigate the relation between design smells and faults in classes from the point of view of developers who must fix faults. We study the impact of the presence of design smells on the effort required to fix faults, which we measure using three metrics: (1) the duration of the fixing period; (2) the number of fields and methods impacted by fault-fixes; and, (3) the entropy of the fault-fixes in the source code. We conduct an empirical study with 12 design smells detected in 54 releases of four systems: ArgoUML, Eclipse, Mylyn, and Rhino. Our results showed that the duration of the fixing period is longer for faults involving classes with design smells. Also, fixing faults in classes with design smells impacts more files, more fields, and more methods. We also observed that after a fault is fixed, the number of occurrences of design smells in the classes involved in the fault decreases. Understanding the impact of design smells on development effort is important to help development teams better assess and forecast the impact of their design decisions and therefore lead their effort to improve the quality of their software systems. Development teams should monitor and remove design smells from their software systems because they are likely to increase the change efforts. The third contribution concerns design smells detection. During maintenance and evolution tasks, it is important to have a tool able to detect design smells incrementally and iteratively. This incremental and iterative detection process could reduce costs, effort, and resources by allowing practitioners to identify and take into account occurrences of design smells as they find them during comprehension and change. Researchers have proposed approaches to detect occurrences of design smells but these approaches have currently four limitations: (1) they require extensive knowledge of design smells; (2) they have limited precision and recall; (3) they are not incremental; and (4) they cannot be applied on subsets of systems. To overcome these limitations, we introduce SMURF, a novel approach to detect design smells, based on a machine learning technique—support vector machines—and taking into account practitioners’ feedback. Through an empirical study involving three systems and four design smells, we showed that the accuracy of SMURF is greater than that of DETEX and BDTEX when detecting design smells occurrences. We also showed that SMURF can be applied in both intra-system and inter-system configurations. Finally, we reported that SMURF accuracy improves when using practitioners’ feedback.

No description available.