[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.
| Identifer | oai:union.ndltd.org:puc-rio.br/oai:MAXWELL.puc-rio.br:65736 |
| Date | 02 January 2024 |
| Creators | ANDERSON JOSE SILVA DE OLIVEIRA |
| Contributors | ALESSANDRO FABRICIO GARCIA, ALESSANDRO FABRICIO GARCIA |
| Publisher | MAXWELL |
| Source Sets | PUC Rio |
| Language | English |
| Detected Language | Portuguese |
| Type | TEXTO |
Page generated in 0.0022 seconds