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

[pt] Sistemas impactados por Problemas de Projeto (PPs) podem se tornar difíceis de manter e evoluir. A identificação de PPs pode ocorrer por meio de múltiplos sintomas, tais como code smells. Após tal identificação, pode-se remover os PPs por meio de refatorações. No entanto, decidir onde e como refatorar é uma tarefa desafiadora. Assim, técnicas de recomendação de refatoração têm sido propostas. Apesar disso, ainda há pouco consenso sobre quais requisitos devem ser atendidos por elas. Nesta tese, estamos propondo quatro requisitos empiricamente identificados que tais técnicas devem seguir. Primeiro, cada PP geralmente está relacionado a vários tipos de sintomas no código-fonte e eles devem ser considerados juntos para gerar recomendações. Além disso, uma técnica de recomendação deve permitir a seleção de contextos específicos para refatoração. Quarto, também deve-se considerar as funcionalidades modificadas para criar recomendações úteis. Finalmente, os desenvolvedores nem sempre conduzem as refatorações mais eficazes na prática, muitas vezes inconscientemente, resultando na remoção incompleta de PPs. Assim, eles precisam de assistência para remover os PPs. Existem apenas técnicas que atendem parcialmente aos requisitos mencionados. Sendo assim, nós propomos a técnica OrganicRef. OrganicRef destina-se a ajudar os desenvolvedores na remoção de PPs em seus contextos de interesse. OrganicRef encontra as funcionalidades dos elementos de código usando um algoritmo de modelagem de tópicos. Em seguida, ele coleta múltiplos tipos de sintomas que afetam os elementos do código. Para recomendar refatorações, OrganicRef combina heurísticas baseadas em regras e baseadas em funcionalidades. OrganicRef também aplica otimização baseada em busca para derivar várias recomendações possíveis. Para avaliar o OrganicRef, realizamos um estudo experimental com seis projetos de software. Os resultados mostraram que as recomendações do OrganicRef melhoram significativamente a qualidade dos elementos refatorados. / [en] Software projects impacted by Design Problems (DPs) may become difficult to maintain and evolve. The identification of DPs may occur through symptoms such as code smells. After such identification, developers can remove the DPs through refactorings. However, deciding where and how to refactor is a challenging task. Thus, several refactoring recommendation techniques have been proposed. Nevertheless, there is still little consensus on which requirements must be satisfied by them. In this thesis, we are proposing four empirically identified requirements that any DP removal technique should follow. First, each single DP is usually related with multiple types of symptoms in the source code and they should be considered altogether for generating recommendations. Second, a recommendation technique should allow the selection of possible candidate contexts for refactoring. Fourth, the technique should consider the features of undergoing changes to create useful recommendations. Finally, developers do not always conduct the most effective refactorings in practice, quite often unconsciously, resulting in the incomplete removal of DPs. Thus, they need assistance to remove DPs. There are techniques partially fulfilling the aforementioned requirements, though none satisfactorily meets them all. Thus, we propose the OrganicRef technique. OrganicRef is intended to help developers in removing DPs in their contexts of interest. OrganicRef finds the contexts by capturing the features affecting relevant code elements using a topic modeling algorithm. Then, it collects multiple symptom types affecting the code elements. To recommend effective refactorings, OrganicRef combines rulebased and feature-driven heuristics. It also uses search-based optimization to derive multiple possible recommendations. To evaluate OrganicRef, we conducted an empirical study with six open source projects. Results showed that OrganicRef recommendations significantly improves the design of refactored elements.