[pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS

Bibliographic Details
Main Author: ANDERSON JOSE SILVA DE OLIVEIRA
Publication Date: 2024
Format: Doctoral thesis
Language: eng
Source: Repositório Institucional da PUC-RIO (Projeto Maxwell)
Download full: https://www.maxwell.vrac.puc-rio.br/colecao.php?strSecao=resultado&nrSeq=65736&idi=1
https://www.maxwell.vrac.puc-rio.br/colecao.php?strSecao=resultado&nrSeq=65736&idi=2
http://doi.org/10.17771/PUCRio.acad.65736
Summary: [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.
id PUC_RIO-1_2dc18a77d7f7f09d0f0cfbb7ffaf3409
oai_identifier_str oai:MAXWELL.puc-rio.br:65736
network_acronym_str PUC_RIO-1
network_name_str Repositório Institucional da PUC-RIO (Projeto Maxwell)
repository_id_str 534
spelling [pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS[en] UNVEILING DESIGN PROBLEMS IDENTIFICATION: COMBINING MULTIPLE SYMPTOMS[pt] REFATORACAO[pt] PROBLEMAS DE PROJETO[pt] REQUISITO NAO FUNCIONAL[pt] ANOMALIAS DE CODIGO[en] REFACTORING[en] DESIGN PROBLEMS[en] NON FUNCTIONAL REQUIREMENT[en] CODE 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. MAXWELLALESSANDRO FABRICIO GARCIAALESSANDRO FABRICIO GARCIAALESSANDRO FABRICIO GARCIAANDERSON JOSE SILVA DE OLIVEIRA2024-01-02info:eu-repo/semantics/publishedVersioninfo:eu-repo/semantics/doctoralThesishttps://www.maxwell.vrac.puc-rio.br/colecao.php?strSecao=resultado&nrSeq=65736&idi=1https://www.maxwell.vrac.puc-rio.br/colecao.php?strSecao=resultado&nrSeq=65736&idi=2http://doi.org/10.17771/PUCRio.acad.65736engreponame:Repositório Institucional da PUC-RIO (Projeto Maxwell)instname:Pontifícia Universidade Católica do Rio de Janeiro (PUC-RIO)instacron:PUC_RIOinfo:eu-repo/semantics/openAccess2025-04-28T00:00:00Zoai:MAXWELL.puc-rio.br:65736Repositório InstitucionalPRIhttps://www.maxwell.vrac.puc-rio.br/ibict.phpopendoar:5342025-04-28T00:00Repositório Institucional da PUC-RIO (Projeto Maxwell) - Pontifícia Universidade Católica do Rio de Janeiro (PUC-RIO)false
dc.title.none.fl_str_mv [pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS
[en] UNVEILING DESIGN PROBLEMS IDENTIFICATION: COMBINING MULTIPLE SYMPTOMS
title [pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS
spellingShingle [pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS
ANDERSON JOSE SILVA DE OLIVEIRA
[pt] REFATORACAO
[pt] PROBLEMAS DE PROJETO
[pt] REQUISITO NAO FUNCIONAL
[pt] ANOMALIAS DE CODIGO
[en] REFACTORING
[en] DESIGN PROBLEMS
[en] NON FUNCTIONAL REQUIREMENT
[en] CODE SMELLS
title_short [pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS
title_full [pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS
title_fullStr [pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS
title_full_unstemmed [pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS
title_sort [pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS
author ANDERSON JOSE SILVA DE OLIVEIRA
author_facet ANDERSON JOSE SILVA DE OLIVEIRA
author_role author
dc.contributor.none.fl_str_mv ALESSANDRO FABRICIO GARCIA
ALESSANDRO FABRICIO GARCIA
ALESSANDRO FABRICIO GARCIA
dc.contributor.author.fl_str_mv ANDERSON JOSE SILVA DE OLIVEIRA
dc.subject.por.fl_str_mv [pt] REFATORACAO
[pt] PROBLEMAS DE PROJETO
[pt] REQUISITO NAO FUNCIONAL
[pt] ANOMALIAS DE CODIGO
[en] REFACTORING
[en] DESIGN PROBLEMS
[en] NON FUNCTIONAL REQUIREMENT
[en] CODE SMELLS
topic [pt] REFATORACAO
[pt] PROBLEMAS DE PROJETO
[pt] REQUISITO NAO FUNCIONAL
[pt] ANOMALIAS DE CODIGO
[en] REFACTORING
[en] DESIGN PROBLEMS
[en] NON FUNCTIONAL REQUIREMENT
[en] CODE SMELLS
description [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.
publishDate 2024
dc.date.none.fl_str_mv 2024-01-02
dc.type.status.fl_str_mv info:eu-repo/semantics/publishedVersion
dc.type.driver.fl_str_mv info:eu-repo/semantics/doctoralThesis
format doctoralThesis
status_str publishedVersion
dc.identifier.uri.fl_str_mv https://www.maxwell.vrac.puc-rio.br/colecao.php?strSecao=resultado&nrSeq=65736&idi=1
https://www.maxwell.vrac.puc-rio.br/colecao.php?strSecao=resultado&nrSeq=65736&idi=2
http://doi.org/10.17771/PUCRio.acad.65736
url https://www.maxwell.vrac.puc-rio.br/colecao.php?strSecao=resultado&nrSeq=65736&idi=1
https://www.maxwell.vrac.puc-rio.br/colecao.php?strSecao=resultado&nrSeq=65736&idi=2
http://doi.org/10.17771/PUCRio.acad.65736
dc.language.iso.fl_str_mv eng
language eng
dc.rights.driver.fl_str_mv info:eu-repo/semantics/openAccess
eu_rights_str_mv openAccess
dc.publisher.none.fl_str_mv MAXWELL
publisher.none.fl_str_mv MAXWELL
dc.source.none.fl_str_mv reponame:Repositório Institucional da PUC-RIO (Projeto Maxwell)
instname:Pontifícia Universidade Católica do Rio de Janeiro (PUC-RIO)
instacron:PUC_RIO
instname_str Pontifícia Universidade Católica do Rio de Janeiro (PUC-RIO)
instacron_str PUC_RIO
institution PUC_RIO
reponame_str Repositório Institucional da PUC-RIO (Projeto Maxwell)
collection Repositório Institucional da PUC-RIO (Projeto Maxwell)
repository.name.fl_str_mv Repositório Institucional da PUC-RIO (Projeto Maxwell) - Pontifícia Universidade Católica do Rio de Janeiro (PUC-RIO)
repository.mail.fl_str_mv
_version_ 1849967325561749504