[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.

[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.