Relatório Iniciação Científica Engenharia De Software

[pic 1]

CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DE MINAS GERAIS CURSO DE BACHARELADO EM ENGENHARIA DE COMPUTAÇÃO

RELATÓRIO INICIAÇÃO CIENTÍFICA

ENGENHARIA DE SOFTWARE

Yuri Barbosa Carvalhais

Belo Horizonte – Minas Gerais

Março de 2023

CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DE MINAS GERAIS CURSO DE BACHARELADO EM ENGENHARIA DE COMPUTAÇÃO

RELATÓRIO INICIAÇÃO CIENTÍFICA

ENGENHARIA DE SOFTWARE

Yuri Barbosa Carvalhais

Análise de Impacto de Propagação de Modificação em Software Orientado a Objetos.

Belo Horizonte – Minas Gerais

Março de 20

Sumário

Introdução1

Objetivos1

Desenvolvimento2

Estudo e manutenção dos scripts2

Coleta e organização de dados4

Conclusão7

Referências8

Introdução

A análise de impacto é uma etapa essencial no desenvolvimento de software orientado a objetos, cujo objetivo é identificar possíveis efeitos colaterais decorrentes de mudanças em uma determinada funcionalidade. De acordo com Garcia e Lopes (2016), é preciso garantir que uma alteração não afete negativamente outras partes já existentes no sistema, o que pode gerar erros no código e, consequentemente, afetar a qualidade do software.

Decorrente desse tipo de análise, destaca-se a ideia de propagação de alterações entre classes, quando uma alteração é feita em uma classe e suas dependentes também precisam ser atualizadas, gerando um efeito cascata que pode se espalhar por todo o sistema. Segundo Souza et al. (2012), "a propagação de mudanças em sistemas orientados a objetos é uma preocupação recorrente entre desenvolvedores, uma vez que pequenas mudanças podem afetar diversas partes do sistema". Esse fenômeno pode ser causado por diversos fatores, como a complexidade do código, o tamanho do sistema e a dependência entre as classes.

        A quantificação e estipulação de diversos fatores relacionados a esse fenômeno é possível utilizando-se de ferramentas de estruturação e/ou versionamento de código, como histórico de mudanças em projetos sediados em IDE’s e a modulação de código estipulada no serviço Git. O estudo da forma como se comporta essa propagação é necessário para adotar e testar métodos que evitem esse problema, como a utilização de técnicas de refatoração, padrões de projeto e arquiteturas em camadas.

Objetivos

        Realizar manutenção, atualizar e utilizar scripts em Python que têm por finalidade recolher informações sobre a propagação de alterações em projetos orientados a objetos, através do estudo de commits subsequentes nesses códigos. Ademais, organizar e postular os arquivos de resultados da análise para posterior utilização para fins de pesquisa.

Desenvolvimento

        O trabalho, inicialmente e primordialmente, foi desenvolvido em cima dos scripts já desenvolvidos pelo membro anterior do projeto, Diego Santos Gonçalves, que criou algoritmos capazes de recolher boa parte dos arquivos necessários para a análise pretendida no início da pesquisa. Portanto, a ordem que foi seguida foi o estudo do projeto, com relatórios e teses do Diego, da professora coordenadora do projeto (Kécia Aline Marques Ferreira) e da desenvolvedora de tese com base nos dados do projeto (Mivian Marques), a resolução de problemas em relação a compatibilidade e integração com o projeto, a manutenção do scripts para resolução de bugs e organização mais controlada, e ao fim a coleta e armazenamento dos dados necessários através da execução dos scripts na ordem correta.

        Todo esse processo foi realizado em paralelo com reuniões semanais com a Kécia e a Mivian, normalmente nas quintas e de forma remota. As reuniões organizavam todo o caminho necessário para seguir com o projeto, além de tirar as principais dúvidas acerca de detalhes dos scripts.

Estudo e manutenção dos scripts

        A primeira fase do projeto foi o estudo e entendimento da proposta e do que já havia sido feito. Para isso, inicialmente foram estipuladas partes da tese da professora Kécia, sobre o tema do projeto, para estudo, onde uma boa base sobre a teoria usada foi absorvida. Posteriormente, o estudo foi com base no relatório da Iniciação Científica pelo Diego, que mostrava detalhes da implementação direta dos algoritmos usados. E por fim, um estudo do artigo publicado com base nas análises desenvolvidas pela Mivian para sua tese, onde relacionava diretamente os resultados já obtidos pelo projeto e a teoria da propagação de modificação em softwares orientados a objetos. Essa fase de leitura e estudo foi importante para a integração no projeto e entendimento tanto da teoria quanto da prática aplicadas no caso.

        Em sintonia com o conhecimento obtido na parte anterior, foi iniciado o contato direto com os scripts de recolhimento de informações desenvolvidos pelo Diego. Essa fase de início foi marcada por muitas dificuldades em relação a compatibilidade de algumas bibliotecas e do próprio computador utilizado, chegando ao ponto de até mesmo tentar utilizar computadores da sessão reservada de Engenharia de Software de Departamento de Computação do CEFET. Os erros tinham origem no uso das bibliotecas MongoDB e tidyextractors, sendo ambas bibliotecas que foram substituídas com o passar do projeto, mas ainda permaneciam em algumas instâncias ao decorrer do código, causando confusão sobre a ordem a se seguir e, no caso da tidyextractors, causando erro de instalação devido à descontinuidade da mesma pelos seus desenvolvedores.

        Assim, enquanto ocorria o aprendizado da ordem correto e correlação entre fases do processo de recolhimento, foi desenvolvida uma organização melhor dos scripts, excluindo pastas/arquivos/pedaços que não tinham utilidade direta no projeto, o deixando mais enxuto e coeso em relação ao passo a passo de extração de dados. Essa organização atual pode ser encontrada em forma de pasta compactada no Drive do projeto, que será referenciado novamente posteriormente, na pasta “IC 2022”. A organização em primeiro nível (focando apenas nas pastas e arquivos importantes para extração) ficou assim: pasta ExtractRepoCSV (com scripts necessários para importar os repositórios escolhidos e gerar seus respectivos CSV’s), pasta MatrizCochange, pasta Matriz_Cochange_H3, pasta MatrizCochange_CommitPuro (sendo essas três com os scripts necessários para gerar os arquivos com as matrizes co-change referentes a cada uma das três heurísticas escolhidas), pasta DependencyGraph (com os scripts necessários para a geração dos grafos e CSV’s de comparação) e arquivo repo_baixar.csv (onde serão expostos os repositórios escolhidos para início do processo de importação, além de informações necessárias, como classe de tamanho e link no GitHub). Outros arquivos também podem ser encontrados na pasta compactada, mas têm papel de organização, configuração de máquina ou documentação, por isso não foram citados, não sendo diretamente necessários para a execução dos scripts, podendo até mesmo ser excluídos se necessário.