Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTECENTRO DE CIÊNCIAS EXATAS E DA TERRA
CURSO DE BACHARELADO EM ENGENHARIA DE SOFTWARE
Investigação e Análise de Anomalias de Códigoem Aplicações Web
Sérgio Giordanno Medeiros de Luna
Natal-RN, Brasil
2021
Sérgio Giordanno Medeiros de Luna
Investigação e Análise de Anomalias de Código emAplicações Web
Monografia apresentada ao Curso deBacharelado em Engenharia de Software doCentro de Exatas e da Terra daUniversidade Federal do Rio Grande doNorte como requisito parcial para aobtenção do título de Bacharel emEngenharia de Software.
Orientador: Prof. Dr. Everton Ranielly de Sousa Cavalcante
Natal-RN, Brasil
2021
Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Luna, Sérgio Giordanno Medeiros de.Investigação e análise de anomalias de código em
aplicações Web / Sérgio Giordanno Medeiros de Luna. - 2021.62f.: il.
Monografia (Bacharelado em Engenharia de Software) -Universidade Federal do Rio Grande do Norte, Centro deCiências Exatas e da Terra, Departamento de Informática eMatemática Aplicada. Natal, 2021.Orientador: Prof. Dr. Everton Ranielly de Sousa Cavalcante.
1. Engenharia de software - Monografia. 2. Aplicações Web -Monografia. 3. Anomalias de código - Monografia. 4. Codesmells - Monografia. 5. Manutenção de software - Monografia.6. Mapeamento sistemático - Monografia. I. Cavalcante,Everton Ranielly de Sousa. II. Título.
RN/UF/CCET CDU 004.41
Elaborado por Joseneide Ferreira Dantas - CRB-15/324
Sérgio Giordanno Medeiros de Luna
Investigação e Análise de Anomalias de Código emAplicações Web
Monografia apresentada ao Curso deBacharelado em Engenharia de Software doCentro de Exatas e da Terra daUniversidade Federal do Rio Grande doNorte como requisito parcial para aobtenção do título de Bacharel emEngenharia de Software.
Trabalho aprovado. Natal-RN, Brasil, 3 de setembro de 2021:
___________________________________________
Prof. Dr. Everton Ranielly de Sousa CavalcanteUniversidade Federal do Rio Grande do Norte
Orientador
__________________________________________
Prof. Dr. Eiji Adachi Medeiros BarbosaExaminador
__________________________________________
Prof. Dr. Frederico Araújo de Silva LopesExaminador
Natal-RN, Brasil2021
Dedico este trabalho aos meus queridos avós, Aldomário de Luna (in memoriam) e GeraldaMedeiros (in memoriam).
AgradecimentosGratidão é reconhecer que em algum momento da nossa trajetória, o gesto ou a ação de
alguma pessoa foi fundamental para seguirmos em frente, para nos levantar naquelesmomentos mais difíceis, para entendermos a importância do próximo e que nada na nossa vidaé conquistado inteiramente sozinho; é necessário por muitas vezes uma palavra de incentivo,um gesto de compreensão e amor. Apesar da dificuldade de lembrar de todas as pessoas que meajudaram de alguma forma nessa caminhada que foi concluir o curso de Engenharia deSoftware e de externar esse sentimento por meio de palavras, tentarei agradecer aqueles queforam muito importantes para mim durante esse tempo e, desde já, peço desculpas caso nãotenha destacado alguma dessas pessoas.
Antes de mais nada, gostaria de agradecer a Deus, o Criador da Vida, pelaoportunidade que me foi concedida, por todas as minhas conquistas, por toda a minharesiliência e superação. Obrigado, Deus; sem a minha fé pelo Senhor, tudo seria bem maisdifícil. Obrigado por não me fazer desistir em nenhum momento, obrigado pela força que oSenhor me deu em todas aquelas noites cansativas de trabalho. Obrigado, meu Deus. “Assimdiz o Senhor, o seu redentor, o Santo de Israel: Eu sou o Senhor, o seu Deus, que lhe ensina oque é melhor para você e o guio pelo caminho que você deve seguir” (Isaías 48:17).
Agradeço aos meus pais, Sérgio Giordanno e Kathia Maria, pelos ensinamentos evalores que levarei por toda minha vida, por todo o esforço sob grandes dificuldades quetiveram de ser enfrentados na tentativa de me conceder uma boa educação e formação. Saibamque os senhores foram fundamentais e essa conquista é nossa.
Agradeço especial a minha amiga, namorada, parceira de vida Gabriella Medeiros, porme incentivar, por me ajudar em um dos momentos mais difíceis da minha vida, por toda asua compreensão, paciência, apoio e conselhos.
Agradeço também aos meus irmãos André Manoel e Rhinna Medeiros, por todapalavra de incentivo, gesto de compreensão e carinho. Amo imensamente vocês dois. Nãopoderia deixar de agradecer a meu grande amigo e cunhado, Fábio Henrique, por todos os seusconselhos e apoio. Agradeço aos meus queridos avós Aldomário de Luna (in memoriam),Glória de Luna e Geralda Medeiros (in memoriam) por todo o amor, carinho, compreensão eincentivo durante todos esses anos. Agradeço a todos os meus familiares, primos, tios e amigosque são a minha base e, em especial, ao meu tio Saulo de Luna, por todas as palavras decarinho e conselhos.
Agradeço imensamente ao amigo, professor, orientador Everton Cavalcante. Obrigado,professor, por todos os ensinamentos, disponibilidade em sanar as minhas constantes dúvidas,atenção, paciência, conselhos. Obrigado, Everton. Tenho certeza que, sem você, muitodificilmente teria chegado até aqui. Peço desculpas pelas mensagens de dúvidas de madrugada(risos). Sou muito grato por ter tido um excelente professor e orientador durante a minhajornada na Graduação.
“Persistence is the shortest path to success.”- Charles Chaplin
Resumo
Aplicações Web representam uma parcela significativa dos sistemas computacionaisatuais. Assim como em quaisquer outros sistemas de software, sua implementaçãopode ser afetada por más práticas de programação e violações de princípiosfundamentais na Engenharia de Software. Esses problemas são conhecidos comoanomalias de código (também conhecidas como code smells ou bad smells), as quaisreferem-se a um sintoma aparente de um problema mais grave no código fonte.Apesar de não impedirem o sistema de funcionar corretamente, anomalias de códigopodem prejudicar o desenvolvimento e gerar riscos futuros, principalmente notocante a compreensão e manutenção. Apesar de a literatura apresentar váriosestudos acerca de anomalias de código em sistemas de software tradicionais, sãopoucos os estudos que analisam tais anomalias especificamente em aplicações Web ecomo detectá-las. Também não há muitos estudos com o objetivo de verificar se asanomalias que ocorrem em sistemas de software tradicionais, já amplamenteestudadas, também se observam em aplicações Web ou se há anomalias que sejamespecíficas a esse contexto. Além disso, a literatura ainda não apresenta umpanorama do estado da arte com relação à investigação de anomalias de código emaplicações Web. A fim de preencher essa lacuna, este trabalho investiga anomalias decódigo em aplicações Web e identifica como elas ocorrem e podem ser detectadas.Para esse fim, um mapeamento sistemático da literatura foi realizado. Estudosprimários disponíveis na literatura foram coletados e analisados utilizandoprocedimentos e critérios bem definidos, seguindo diretrizes consolidadas. Estetrabalho apresenta os principais resultados do mapeamento sistemático realizado,fornecendo (i) uma visão geral acerca da ocorrência de anomalias de código nocontexto de aplicações Web, sua frequência e onde se observam, (ii) umaidentificação das abordagens e ferramentas empregadas para detectá-las e (iii) se ecomo aspectos de refatoração têm sido considerados nesse contexto.
Palavras-chave: Aplicações Web. Anomalias de código. Code smells. Manutenção desoftware. Mapeamento sistemático.
Abstract
Web applications represent a significant part of today's computer systems. As in anyother software system, their implementation may be affected by poor programmingpractices and violations of fundamental principles in Software Engineering. Theseproblems are known as code anomalies (also known as code smells or bad smells),which refer to an apparent symptom of a more severe problem in the source code.While not preventing the system from working correctly, code anomalies can hamperdevelopment and generate future risks, especially with regards to understanding andmaintenance. Although the literature presents many studies on code anomalies intraditional software systems, a few studies analyze such anomalies specifically inWeb applications and how to detect them. There are also not many studies aiming toverify if the anomalies that occur in traditional software systems, already widelystudied, are observed in Web applications or if there are anomalies specific to thiscontext. Furthermore, the literature does not still present an overview of the state ofthe art regarding the investigation of code anomalies in Web applications. Aiming tofill this gap, this work investigates code anomalies in Web applications and identifieshow they occur and can be detected. For this purpose, a systematic mapping studywas carried out. Primary studies available in the literature were collected andanalyzed through well-defined procedures and criteria and following consolidatedguidelines. This work presents the main results of the performed systematic mappingstudy, providing (i) an overview of the occurrence of code anomalies in the context ofWeb applications, their frequency, and where they are observed, (ii) an identificationof the approaches and tools used to detect them, and (iii) if and how aspects ofrefactoring are considered in this context.
Keywords: Web applications. Code anomalies. Code smells. Software maintenance.Systematic mapping.
Lista de ilustrações
Figura 1 – Exemplo da anomalia de código Primitive Obsession 20
Figura 2 – Exemplo da anomalia de código Data Clumps 21
Figura 3 – Exemplo da anomalia de código Switch Statements 22
Figura 4 – Exemplo da anomalia de código Temporary Field 23
Figura 5 – Exemplo da anomalia de código Message Chains 25
Figura 6 – Exemplo da anomalia de código Incomplete Library Class 26
Figura 7 – Processo para seleção dos estudos relevantes 35
Figura 8 – Distribuição dos estudos primários selecionados ao longo dos anos 37
Figura 9 – Veículos nos quais os estudos primários selecionados forampublicados
38
Figura 10 – Objetivos principais dos estudos primários selecionados 39
Lista de tabelas
Tabela 1 – Focos de investigação de estudos secundários relacionados aanomalias de código em sistemas de software
27
Tabela 2 – Itens de dados extraídos dos estudos selecionados 34
Tabela 3 – Lista dos estudos selecionados 35
Tabela 4 –Anomalias de código consideradas pelos estudos primáriosselecionados
39
Tabela 5 – Linguagens de programação consideradas nos estudos primáriosselecionados
44
Tabela 6 – Níveis de ocorrência de anomalias de código em aplicações Webconsiderados pelos estudos primários selecionados
45
Tabela 7 – Abordagens empregadas para detectar anomalias de código emaplicações Web reportadas pelos estudos primários selecionados
47
Tabela 8 – Ferramentas para detecção de anomalias de código em aplicaçõesWeb consideradas pelos estudos primários selecionados
48
Lista de abreviaturas e siglas
HTTP Hypertext Transfer Protocol
MVC Model-View-Controller
MTV Model-Template-View
POO Programação orientada a objetos
SRP Single Responsibility Principle
URI Uniform Resource Identifier
URL Uniform Resource Locator
Sumário1 Introdução 15
1.1 Motivação 16
1.2 Objetivos e contribuições 17
1.3 Organização do trabalho 18
2 Anomalias de Código 19
2.1 Bloaters 19
2.2 Object-Orientation Abusers 21
2.3 Change Preventers 23
2.4 Dispensables 24
2.5 Couplers 25
2.6 Outros 26
3 Trabalhos Relacionados 27
4 Metodologia de Pesquisa 30
4.1 Questões de pesquisa 30
4.2 Estratégia de busca 32
4.3 Critérios de seleção 33
4.4 Extração e síntese de dados 33
4.5 Processo de seleção 34
5 Resultados 37
5.1 Visão geral dos estudos selecionados 37
5.2 Ocorrência de anomalias de código em aplicações Web 39
5.3 Linguagens de programação 44
5.4 Local de ocorrência das anomalias de código em aplicações Web 45
5.5 Abordagens para detecção de anomalias de código em aplicações Web 46
5.6 Ferramentas para detecção de anomalias de código em aplicações Web 48
5.7 Aspectos de refatoração 49
6 Análise de Validade 51
7 Considerações Finais 53
Referências 55
Apêndice A – Adaptações da string de busca 61
A.1 ACM Digital Library 61
A.2 IEEEXplore 61
A.3 Scopus 61
A.4 ScienceDirect 61
A.5 Web of Science 62
15
1 IntroduçãoA World Wide Web, ou simplesmente Web, cresceu de forma exponencial nas
últimas décadas, impactando de forma significativa a forma através da qual usuáriosinteragem com sistemas computacionais. A Web é hoje uma plataforma dominantepara o desenvolvimento e implantação de sistemas das mais diversas naturezas ecomplexidades, que agora são capazes de trocar informações de forma mais facilitadaatravés da Internet. Murugesan (2008) opina que, a Web, assim como a Internet que aela dá suporte, tornou-se um dos desenvolvimentos mais importantes e influentesnão apenas na história da Computação, mas da própria humanidade.
Nesse contexto, uma aplicação Web refere-se a um sistema computacional cominterface implementada exclusivamente para a Internet, a qual é exibida através deum navegador (browser) e hospedada em um servidor remoto. A função básica deuma aplicação Web é receber uma solicitação de um cliente, que pode ser um usuárioou mesmo outra aplicação Web, e devolver uma resposta a ele. Para possibilitar acomunicação entre essas entidades, aplicações Web são estruturadas sobre trêselementos fundamentais: (i) um método para nomear e referenciar documentos, osUniform Resource Locators (URLs), os quais inclusive foram expandidos nos últimosanos para os chamados Uniform Resource Identifiers (URIs) com o intuito de identificarde forma única e referenciar qualquer tipo de recurso disponível na Internet; (ii) umalinguagem para representar documentos na Web, a HTML, e; (iii) um protocolo parapossibilitar a comunicação entre o dispositivo computacional do cliente e aqueleonde está hospedada a aplicação, o HyperText Transfer Protocol (HTTP) (JAZAYERI,2007).
Devido à alta relevância das aplicações Web no mundo atual, características dequalidade como desempenho, confiabilidade, manutenibilidade e escalabilidadetornaram-se de fundamental importância. Com isso, o projeto, desenvolvimento,implantação e manutenção de aplicações Web tornaram-se complexos e desafiadores,até mesmo em um nível superior em comparação a diversos sistemas de softwaretradicionais existentes (JAZAYERI, 2007). Murugesan (2008) afirma que a maioria dosdesenvolvedores de aplicações Web não considera de forma apropriada ascaracterísticas intrínsecas a esse tipo de aplicação, as quais diferem dos sistemas desoftware tradicionais. Algumas dessas características são, dentre outras(MURUGESAN; GINGE, 2004; MENDES; MOSLEY; COUNSELL, 2006; RIO; BRITO EABREU, 2017; BESSGHAIER; OUNI; MIKAOUER, 2020):
● o fato de que aplicações Web estão sujeitas a constantes mudanças, cujafrequência e grau são às vezes maiores em comparação a sistemas desoftware tradicionais, impondo assim desafios significativos quanto aoseu gerenciamento ao longo do seu ciclo de vida;
● vasta diversidade e imprevisível quantidade de usuários;
16
● diversidade de conteúdo tratado;● necessidade de interfaces com usuário que proporcionem uma boa
experiência de uso;● segurança e privacidade como requisitos de alta relevância;● questões de desempenho frente aos recursos de hardware e de rede
disponíveis, e;● heterogeneidade, uma vez que aplicações Web são construídas
considerando um conjunto de linguagens de programação, bibliotecas eframeworks de desenvolvimento, linguagens de formatação, diferentesplataformas de destino.
As aplicações Web, como quaisquer outros sistemas de software, podemrequerer manutenções evolutivas ao longo do tempo para acomodar novos requisitose mudanças no contexto no qual estão inseridas. Essas realizadas sobre o códigofonte do sistema podem impactar diretamente a sua qualidade, na medida que osdesenvolvedores podem tomar más decisões de projeto e implementação as quais,por consequência, dificultam a compreensão, manutenção e reuso da aplicação(BESSGHAIER; OUNI; MIKAOUER, 2020). Algumas dessas más decisões de projeto e deimplementação inclusive representam violações, por parte dos desenvolvedores,princípios fundamentais da própria Engenharia de Software, tais como alta coesão ebaixo acoplamento, além de boas práticas de programação.
As chamadas anomalias de código, mais comumente conhecidas pelos termoscode smell e bad smell, em inglês, tiveram seu conceito inicialmente introduzido Beck eFowler (1999) referindo-se a um sintoma aparente de um problema mais grave nocódigo fonte. As anomalias de código não representam faltas que podem levar a errosde execução no sistema, mas têm o potencial de prejudicar o desenvolvimento e gerarriscos futuros, principalmente no que se refere à compreensão e manutenção de umsistema de software. Diante disso, é imprescindível identificar tais anomalias,preferencialmente o mais cedo possível no processo de desenvolvimento,possibilitando assim reduzir o esforço e o custo de manutenção.
1.1 MotivaçãoAnomalias de código têm sido objeto de estudo de diversas pesquisas nos
últimos vinte anos, como reportam revisões de literatura realizadas por diversosautores (ZHANG; HALL; BADDOO, 2011; SINGH; KAUR, 2017; SHARMA;SPINELLIS, 2018; PAULO SOBRINHO; DE LUCIA; MAIA, 2021), todavia inseridosno contexto de sistemas de software tradicionais. Apesar da relevância do estudo deanomalias de código em e da popularidade das aplicações Web, ainda são poucos osestudos dedicados a analisar tais anomalias especificamente nesse contexto e comodetectá-las. Também não há muitos estudos com o objetivo de verificar se asanomalias que ocorrem em sistemas de software tradicionais, já amplamente
17
estudadas, também se observam em aplicações Web ou se há anomalias que lhessejam particulares. De acordo com Rio e Brito e Abreu (2017), os poucos trabalhospublicados acerca de anomalias de código em aplicações Web dizem respeitoprincipalmente a questões de programação do lado do cliente e, no lado servidor, osestudos publicados são ainda mais escassos. Investigar anomalias de código nessessistemas é fundamental, tendo em vista que aplicações Web frequentementeabrangem diferentes tecnologias, combinando aspectos de programação eformatação, o que implica em outra dimensão de complexidade em comparação aaplicações tradicionais (BESSGHAIER; OUNI; MIKAOUER, 2020).
Além da ausência de muitos estudos primários relacionados a anomalias decódigo em aplicações Web, não há, até o momento, estudos secundários, tais comorevisões de literatura, nesse contexto. Essa lacuna existente serviu, portanto, demotivação para a realização deste trabalho, a fim de possibilitar obter um panoramaque permita tanto pesquisadores quanto profissionais da área refletirem acerca doestado da arte atual, identificarem questões que podem direcionar pesquisas futurase compreenderem como as pesquisas existentes podem ser adequadas a necessidadestécnicas, de negócio e organizacionais.
1.2 Objetivos e contribuiçõesEste trabalho tem como objetivo investigar a ocorrência das anomalias de
código em aplicações Web e identificar como elas podem ser detectadas. Esse objetivogeral pode ser refinado nos seguintes objetivos específicos:
(i) identificar as anomalias de código que ocorrem em aplicações Web, suafrequência e onde se observam;
(ii) identificar e analisar as abordagens e ferramentas propostas na literaturapara detectar anomalias de código em aplicações Web, e;
(iii) observar se e como aspectos de refatoração têm sido considerados notocante a anomalias de código em aplicações Web.
A fim de alcançar os objetivos postos, foi realizado um mapeamentosistemático da literatura com vistas a prover um panorama do estado da arterelacionado a anomalias de código em aplicações Web. Em resumo, um mapeamentosistemático é uma forma bem estabelecida de estudo secundário que visa, através deum procedimento sistemático rigoroso de coleta, seleção e análise de estudosdisponíveis na literatura, obter uma visão abrangente acerca de um determinadotema, identificar lacunas em pesquisa e desenvolvimento, bem como coletarevidências que podem inclusive fornecer subsídios para a condução de outrosestudos (PETERSEN et al., 2008). Dessa forma, a principal contribuição deste trabalhoé reportar os resultados do mapeamento sistemático realizado, fornecendo uma visãogeral da ocorrência de anomalias de código no contexto de aplicações Web e asabordagens e ferramentas empregadas para detectá-las.
18
1.3 Organização do trabalhoO restante desta monografia é composto por seis capítulos que se somam a
esta Introdução, além de um apêndice. O Capítulo 2 traz uma explanação acerca deanomalias de código. O Capítulo 3 analisa e discute brevemente alguns trabalhosrelacionados presentes na literatura. O Capítulo 4 descreve a metodologia utilizadapara desenvolver o mapeamento sistemático, em termos das questões de pesquisa aserem investigadas e a estratégia de busca e seleção de estudos primários. O Capítulo5 apresenta os resultados da análise dos estudos primários considerados comorelevantes, incluindo respostas e discussão a respeito de cada questão de pesquisaformulada. O Capítulo 6 discorre sobre uma análise de validade para identificarpossíveis limitações do mapeamento sistemático realizado. O Capítulo 7 trazalgumas considerações finais. Por fim, o Apêndice A apresenta as adaptações feitasna string utilizada para a realização das buscas por estudos em cada base eletrônicade publicação considerada como fonte de busca neste trabalho.
19
2 Anomalias de CódigoAnomalias de código podem ser entendidos como indícios de que o código
fonte potencialmente possui problemas de compreensão e de manutenibilidade(FOWLER, 2019; PAULO SOBRINHO; DE LUCIA; MAIA, 2021). Diante dadiversidade de definições presentes na literatura, Sharma e Spinelli (2018), em umaampla revisão sistemática da literatura, destacaram algumas característicasintrínsecas às anomalias de código. Anomalias de código:
● podem normalmente ser um indicador ou um sintoma de um problemamais profundo em um projeto de software;
● são resultantes de uma solução ruim ou má decisão de programação;● implicam na violação de boas práticas recomendadas em um domínio de
aplicação;● afetam a qualidade do software, por dificultarem a sua evolução e
manutenção, e;● são causadoras de problemas recorrentes, por gerarem uma série de
problemas a longo prazo.
O catálogo de anomalias de código mais conhecido e discutido na literatura éo proposto por Beck e Fowler (1999). Neste capítulo, as anomalias catalogadas poresses autores serão descritas nos cinco grandes grupos presentes na taxonomiaproposta por Mäntylä (2003), a saber, Bloaters, Object-Orientation Abusers, ChangePreventers, Dispensables e Couplers, sendo descritas nas Seções 2.1 a 2.5. Há ainda umaanomalia do catálogo, a Incomplete Library Class, que não é classificada em nenhumdesses grupos, porém será descrita na Seção 2.6. Para melhor compreensão, algumasdas anomalias são ilustradas com exemplos apresentados por Aladdin (2018).
2.1 BloatersAs Bloaters referem-se a trechos de código, sejam eles métodos ou classes, que
aumentaram significativamente de tamanho ao longo do tempo, ao ponto de teremsua manutenção prejudicada. Não existe um número exato para que o código sejaclassificado como sendo um Bloater, dependendo assim do senso do desenvolvedorpara verificar quando esse código atingiu um tamanho desproporcional ao restantedo projeto.
Long Method. Esta anomalia se refere aos métodos com uma quantidadeextensa de linhas de código, variáveis e parâmetros considerados e, por este motivo,dificultam o entendimento e prejudicam o processo de manutenção.
Large Class (ou God Class). Semelhante ao Long Method, embora estejainserido no contexto das classes, esta anomalia de código refere-se a classes com
20
muitas linhas de código e muitos atributos/métodos. Além de prejudicar amanutenção, a Large Class é um indício de que, se uma classe possui muitosatributos/métodos ou muitas linhas de código, provavelmente ela está sob muitasatribuições no sistema, violando assim o crucial Princípio da Responsabilidade Única(em inglês, Single Responsibility Principle ou SRP).
Primitive Obsession. Esta anomalia refere-se à má prática de utilização detipos primitivos para representar um objeto em um domínio. Utilizar tipos primitivosem vez de criar um objeto, em determinadas situações causa dependência na criaçãode mais tipos primitivos. Por exemplo, considere-se uma aplicação Web em que há anecessidade de tratar informações referente a um livro. Em vez de o desenvolvedorimplementar um objeto com essa informação, ele apenas opta por criar uma string nointuito de armazenar o título do livro. Ao longo do tempo, cada vez que se tornanecessário armazenar mais uma informação acerca do livro, o número de tiposprimitivos criados aumenta e isso torna a manutenção cada vez mais difícil. Outroexemplo é o ilustrado na Figura 1. O fato do desenvolvedor optar por implementarum vetor para ser responsável pelas informações de um endereço e não uma classefaz com que ele precise criar essa quantidade de métodos específicos toda vez que fornecessário adicionar um endereço, enquanto que isso não seria necessário sehouvesse uma classe responsável pelo endereço.
Figura 1 - Exemplo da anomalia de código Primitive Obsession.Fonte: Aladdin (2018)
21
Long Parameter List. Esta anomalia de código ocorre se ao definir um númeroalto de parâmetros em um método, dificultando o seu entendimento, além danecessidade de sucessivas alterações na medida em que mais dados sejamnecessários.
Data Clumps. São definidos como sendo trechos de código encontrados emdiferentes locais da aplicação contendo um mesmo grupo de dados, na maioria doscasos, um mesmo grupo de variáveis. Esses trechos de código são considerados comouma má prática de programação visto que um objeto poderia ser utilizado paraunificar esses dados e assim tornar o código mais coeso e de fácil manutenção. DataClumps podem ser detectados ao se verificar uma quantidade alta de métodosutilizando a mesma ou uma lista semelhante de parâmetros. A Figura 2 ilustra umaclasse no qual quase todos os tipos de reserva exigem as mesmas informações depassaporte.
Figura 2 - Exemplo da anomalia de código Data Clumps.Fonte: Aladdin (2018)
2.2 Object-Orientation AbusersEste grupo de anomalias de código representa um conjunto de trechos de
código que por algum motivo apresentam uma aplicação incorreta ou incompleta dosprincípios fundamentais do paradigma de programação orientada a objetos (POO).
Switch Statements. Esta anomalia ocorre quando há mais de um trecho deuma instrução switch, uma instrução switch complexa ou em alguns casos umaextensa sequência de instruções if que dificulta a sua manutenção a cada vez que umnovo requisito surge. Esta é uma anomalia de código que apresenta uma deficiênciada aplicação por não aproveitar os recursos oriundos do princípio do polimorfismopresente na POO. A Figura 3 ilustra um exemplo da anomalia de código no qual aevent executa uma instrução switch contendo uma série de instruções if/else,promovendo dificuldade de leitura e, consequentemente, de manutenção.
22
Figura 3 - Exemplo da anomalia de código Switch Statements.Fonte: Aladdin (2018)
Temporary Field. Esta anomalia de código refere-se a variáveis temporáriascriadas de forma desnecessária ou utilizadas em cenários bem limitados, tambémdificultando o entendimento da lógica do código implementado, bem comoapresentando uma falta de organização. A Figura 4 apresenta um trecho de código noqual é possível identificar essa anomalia de código, em que as variáveis name econtactDetails são usadas apenas no método notify.
23
Figura 4 - Exemplo da anomalia de código Temporary Field.Fonte: Aladdin (2018)
Refused Bequest. Esta anomalia trata-se da má utilização do recurso dehierarquia oferecido pela POO. Em outras palavras, ela ocorre toda vez que sãocriadas subclasses com o objetivo de utilizar apenas alguns dados ou métodos dassuperclasses. Isso consiste em uma má prática de programação, pois o intuito de criarsubclasses é na verdade aproveitar todos os atributos e métodos que as superclassesdisponibilizam e a partir disso implementar novos recursos.
Alternative Classes with Different Interfaces. São representados por classesdiferentes que executam funções idênticas, mas com assinaturas de métodosdistintos. É uma anomalia normalmente presente em projetos de médio a grandeporte, nos quais o desenvolvedor, por desconhecer do código fonte, desenvolve umaclasse equivalente a outra já existente.
2.3 Change Preventers
Este grupo de anomalias de código representa trechos de código nos quais odesenvolvedor, quando realiza uma alteração em um dado local da aplicação,necessita realizar outras alterações em diversos locais do sistema. Dessa forma, sãotrechos que representam acima de tudo esforço de trabalho e custo de tempo.
Divergent Change. Esta anomalia de código ocorre quando é necessário fazermuitas mudanças em uma classe para acrescentar um novo recurso ou por uma
24
mudança de requisito, as quais inclusive podem ter pouco a ver com a que deuorigem ao processo. O ideal é que nessas situações seja preciso alterar apenas um oupoucos pontos dessa classe.
Shotgun Surgery. Esta anomalia acontece quando, após a alteração de umadeterminada classe, torna-se necessário realizar pequenas mudanças em váriasoutras classes.
Parallel Inheritance Hierarchies. Esta anomalia acontece quando, ao se criaruma subclasse para uma classe, é necessário criar uma outra subclasse para umaoutra classe. Isso é um sinal de um potencial problema devido a uma má utilizaçãodo conceito de hierarquia.
2.4 Dispensables
As Dispensables são anomalias de código que se referem a trechos de códigoque podem ser removidos por não serem relevantes para o funcionamento dosistema. A retirada desses trechos é fundamental para tornar o código mais limpo elegível, facilitando assim o seu processo de manutenção.
Comments. Comentários podem ser importantes para o código fonte. Noentanto, quando existem extensas linhas de comentários em métodos de uma classe,provavelmente esses comentários indicam trechos de código que precisam serrevisados e, por esse motivo, são considerados como uma anomalia de código. Beck eFowler (1999) observaram ainda que extensas linhas de comentários podem indicarqualquer outra anomalia de código do catálogo.
Duplicate Code. Dentre todas as anomalias de código, a duplicação de códigoé a que maior tem incidência nos projetos de software (PAULO SOBRINHO; DELUCIA; MAIA, 2021). Os desenvolvedores acabam realizando duplicações de códigono intuito de tentarem economizar tempo e esforço de trabalho, mas esta anomalia éna verdade considerada uma das que mais geram custo de manutenção.
Lazy Class. Esta anomalia refere-se a classes as quais, devido a muitasrefatorações ou pelo fato de que o planejamento inicial não se concretizou, acabaramnão sendo utilizadas e não sendo funcionais para o sistema. Essas classes sãodeterminadas como sendo anomalias de código por requererem tempo e esforço paraserem compreendidas. A título de exemplo, caso fosse realizada uma refatoraçãoreferente à classe representada na Figura 1, os métodos responsáveis pelo endereço(Address) poderiam ser transportados para uma classe separada (Extract Class),todavia, o mesmo não seria feito com o número de telefone do método HotLine, pelofato de que isso resultaria em uma Lazy Class sem muita utilidade.
Data Class. Esta anomalia diz respeito a classes que servem apenas paraarmazenar campos e métodos getters e setters. Na opinião de Beck e Fowler (1999), aData Class seria uma anomalia de código pois todas as classes devem ter uma
25
finalidade, apresentando comportamentos individuais e tornando o seu objetoimportante para o sistema.
Speculative Generality. Esta anomalia refere-se a classes, métodos, atributos eparâmetros que não são utilizados e, por esse motivo, não devem ser mantidos nocódigo fonte. Geralmente diz respeito a trechos de código criados com o intuito dedar suporte a algo que seria implementado no futuro, porém por algum motivonunca foi aproveitado.
2.5 Couplers
As Couplers são anomalias de código que contribuem para um altoacoplamento entre classes, em outras palavras, uma alta dependência entre diferentesmódulos do sistema e dessa forma dificultam o processo de manutenção do software.
Feature Envy. Esta anomalia de código ocorre quando uma classe aproveitamuito os métodos de uma outra classe. Nesses casos, o indicado é revisar essesmétodos e, se necessário, transportá-los para a classe que está mais sendoreferenciada e assim diminuir o acoplamento.
Inappropriate Intimacy. Esta anomalia ocorre quando uma classe utilizamuitos atributos de uma outra classe. Ela é semelhante à Feature Envy, entretanto, fazreferência aos atributos internos de uma classe.
Message Chains. Esta anomalia de código acontece quando se implementauma série de acessos a objetos de classes diferentes para obter um dado específico. AFigura 5 ilustra essa anomalia de código através da seguinte cadeia: a classe Employeeinvoca um método da classe EmployeeConfig que, por sua vez, invoca outro métodode outra classe, Config.
Figura 5 - Exemplo da anomalia de código Message Chains.Fonte: Aladdin (2018)
26
Middle Man. Esta anomalia pode ser compreendida como resultado daanomalia Message Chains, por retratar justamente classes cuja única função é delegarum acesso a um objeto de uma outra classe e, por este motivo, acaba não havendonecessidade de serem mantidas no sistema.
2.6 OutrosPor fim, a única anomalia de código do catálogo de Beck e Fowler (1999) que
não se relaciona com nenhum dos grupos propostos é a Incomplete Library Class. Estaanomalia refere-se a bibliotecas utilizadas na aplicação, mas que não satisfazem deforma plena as suas necessidades, fazendo com que sejam necessárias alterações nabiblioteca (o que pode não ser possível) ou mesmo sua remoção, na expectativa deincorporar outra que melhor as atenda.
A título de exemplo, a Figura 6 ilustra o cenário no qual uma biblioteca quelida com documentos pode recuperar um documento por seu identificador (ID)através do método deleteDocumentById ou recuperar todos os documentos de umavez a partir do getAllDocuments. O problema ocorre nesse caso, quando surge, aexemplo, a necessidade de recuperar todos os documentos de um determinadousuário, ou seja, um método que não consta na biblioteca; isto porque geralmente éincorreto ou impossível modificar uma classe de biblioteca para atender umanecessidade específica.
Figura 6 - Exemplo da anomalia de código Incomplete Library Class..Fonte: Aladdin (2018)
27
3 Trabalhos RelacionadosAnomalias de código têm sido objeto de estudo na Engenharia de Software há
vários anos, o que pode ser comprovado pelas centenas de estudos primáriosexistentes e, consequentemente, pelo corpo significativo de conhecimento exploradopelas diversas revisões de literatura relacionadas a esse tema. A Tabela 1 sumarizaalguns desses estudos secundários realizados com o objetivo de investigar aliteratura relacionada a anomalias de código, tanto de forma mais ampla (a exemplodos trabalhos de Sharma e Spinellis (2018) e de Paulo Sobrinho et al. (2021)) quantode forma mais específica, em termos de linguagem de programação (GUPTA et al.,2017), ferramentas para detecção (FERNANDES et al., 2016) e relacionamentos comatributos de qualidade e erros no software (CAIRO et al., 2018; KAUR, 2019). Noentanto, observa-se que o foco de investigação de nenhum desses estudossecundários diz respeito especificamente ao contexto de aplicações Web.
Tabela 1 - Focos de investigação de estudos secundários relacionados a anomalias decódigo em sistemas de software.
Estudos Objetivos
Zhang et al. (2011),Haque et al. (2018),Sharma e Spinellis (2018),Paulo Sobrinho et al. (2021)
Apresentar, de forma ampla, o estado da arte acerca deanomalias de código.
Sabir et al. (2018) Investigar similaridades e diferenças quanto à detecção deanomalias de código em sistemas orientados a objetos e aserviços.
Gupta et al. (2017) Apresentar um panorama da literatura acerca deanomalias de código e como são detectadas,especificamente na linguagem de programação Java.
Vale et al. (2014) Identificar a ocorrência de anomalias de código em linhasde produto de software.
Fernandes et al. (2016) Identificar e comparar, de forma empírica, as ferramentasexistentes para detecção de anomalias de código.
Caram et al. (2019), Azeemet al. (2019), Al-Shaaby et al.(2020)
Identificar as técnicas de Aprendizado de Máquinautilizadas com o intuito de detectar anomalias de código.
Kaur (2019) Investigar a relação entre anomalias de código e atributosde qualidade.
28
Cairo et al. (2018) Investigar a influência de anomalias de código naocorrência de erros de software
Singh e Kaur (2018),Lacerda et al. (2020)
Investigar técnicas de refatoração para solucionaranomalias de código.
Santos et al. (2018) Identificar e analisar estudos empíricos que investigam oimpacto de anomalias de código no processo dedesenvolvimento de software.
A fim de identificar revisões de literatura porventura existentes com relação aanomalias de código em aplicações Web, foi realizada uma busca piloto(FELIZARDO et al., 2017) na Scopus , uma das bases eletrônicas mais abrangentes1
dentre as comumente utilizadas na área de Engenharia de Software e que inclusiveindexa outras bases de publicação. Essa busca de caráter preliminar, realizada deforma automatizada, utilizou a seguinte string de busca, a qual considerou comotermos principais: (i) code smell e termos alternativos, para se referir a anomalias decódigo, (ii) web application, para aplicações Web, e (iii) literature review, survey e suasvariações para estudos secundários, sistemáticos ou não:
("code smell" OR "code smells" OR "bad smell" OR "bad smells" OR "code bad smell" OR"code anomaly" OR "code anomalies" OR "antipattern" OR "antipatterns" OR "anti-pattern"
OR "anti-patterns") AND ("web application" OR "web applications") AND ("literaturereview" OR "systematic literature review" OR "mapping study" OR "systematic mapping"
OR "systematic mapping study" OR survey)
Realizada inicialmente em abril de 2020 e atualizada em julho de 2021, a buscaautomatizada realizada na Scopus com a string de busca formulada, considerando oscampos referentes a título, resumo e palavras-chave, retornou apenas três resultados.Analisando-se tais resultados, pôde-se constatar que nenhum deles caracteriza-seespecificamente por ser uma revisão de literatura, sistemática ou não, voltada aoentendimento abrangente de anomalias de código em aplicações Web. Além disso,observou-se que apenas dois desses resultados efetivamente estavam inseridos nocontexto de aplicações Web, sendo esses dois estudos brevemente discutidos a seguir.
O trabalho de Bogner et al. (2019) diz respeito a uma revisão sistemática deliteratura realizada com o objetivo identificar antipadrões de aplicações orientadas aserviços e os relacionamentos entre eles. A análise de 14 estudos primáriosselecionados resultou em uma taxonomia composta de 36 antipadrões com vistas àorganização de um repositório Web colaborativo a ser utilizado por pesquisadores eprofissionais da área como referência. No entanto, o contexto desse trabalho é maisamplo e distinto, por estar relacionado a aplicações orientadas a serviços, assim comoocorre na revisão sistemática de literatura feita por Sabir et al. (2019). Dentre os
1 https://www.scopus.com
29
objetivos desta última revisão, destaca-se a investigação das principais técnicasempregadas para identificar anomalias de código em diferentes paradigmas daengenharia de software, de programação orientada a objetos a sistemas orientados aserviços, verificando semelhanças e diferenças na detecção dessas anomalias.
O trabalho de Shao et al. (2020) diz respeito à identificação de antipadrõesrelacionados a desempenho no acesso a bases de dados em aplicações Web. Osautores reportaram um total de 24 antipadrões existentes e propuseram dezantipadrões adicionais, estes últimos identificados a partir da análise daimplementação de sete aplicações Web reais que realizavam acesso direto a bases dedados. Esse estudo, entretanto, considerou especificamente problemas dedesempenho na implementação do acesso direto a bases de dados feito pelasaplicações.
30
4 Metodologia de PesquisaNo intuito de possibilitar alcançar o objetivo deste trabalho, que é investigar, a
partir da literatura, a ocorrência de anomalias de código em aplicações Web e comoelas podem ser detectadas, foi realizado um mapeamento sistemático de literatura. Ummapeamento sistemático é um tipo de estudo secundário que consiste em umarevisão de literatura realizada seguindo um processo sistemático, rigoroso e bemdefinido, que busca minimizar viés e aumentar a validade científica dos resultados.Essa metodologia oferece algumas vantagens, por exemplo, fornecer uma visãoabrangente do estado da arte no tópico de pesquisa investigado, ajudar a identificarlacunas relevantes na literatura e coletar evidências para incentivar novas pesquisas,evitando assim a duplicação de esforços (PETERSEN et al., 2008; KITCHENHAM;BUDGEN; BRETETON, 2011).
As etapas básicas de um mapeamento sistemático são três: (i) planejamento, aqual dá origem a um protocolo que tem como objetivo definir as questões depesquisa a serem respondidas, a estratégia de busca a ser adotada, os critérios aserem utilizados na seleção dos estudos e os métodos de extração e síntese dosdados; (ii) execução, na qual os estudos são identificados, selecionados e analisados deacordo com o protocolo; e (iii) relato, a qual agrega informações extraídas dos estudospertinentes considerando as questões de pesquisa e estabelecendo conclusões a partirdelas. Neste trabalho, essas etapas foram realizadas seguindo diretrizes consolidadasna literatura (KITCHENHAM; CHARTERS, 2007; KITCHENHAM; BUDGEN;BRETETON, 2016; FELIZARDO et al., 2017).
Este capítulo descreve a metodologia adotada para a realização domapeamento sistemático e está organizado da seguinte forma. A Seção 4.1 apresentaas questões de pesquisa e seus respectivos objetivos. A Seção 4.2 detalha a estratégiade busca implementada. A Seção 4.3 trata dos critérios de inclusão e exclusãoadotados. A Seção 4.4 apresenta os procedimentos para a extração e síntese dosdados coletados a partir dos estudos selecionados. Por fim, a Seção 4.5 descreve oprocesso de seleção dos estudos.
4.1 Questões de pesquisaCom o objetivo de encontrar estudos relevantes na literatura com abordagens
sobre anomalias de código em aplicações Web, foram propostas as seguintes questõesde pesquisa (QPs):
QP1: Que anomalias de código relacionadas a em aplicações Web são maisinvestigadas por estudos primários?
31
Objetivo: Identificar as anomalias de código no contexto de aplicações Web quesão objeto de estudo na literatura, observando não apenas o catálogo propostopor Fowler et al. (1999), mas também outras anomalias específicas paraaplicações Web e que ainda não tenham sido formalizadas.
QP2: Quais as linguagens de programação das aplicações Web consideradaspelos estudos primários?
Objetivo: Identificar as linguagens de programação das aplicações Webconsideradas pelos estudos primários, possibilitando observar se asabordagens existentes possuem um caráter mais genérico ou específico delinguagem, além de investigar se há algum tipo de relação entre a linguagemutilizada e a ocorrência de anomalias de código.
QP3: Quais os locais analisados pelos estudos primários quanto à ocorrênciade anomalias de código em uma aplicação Web?
Objetivo: Identificar os locais de ocorrência de anomalias de código emaplicações Web, por exemplo, a nível de front-end ou back-end, em camadas denegócio ou de acesso a dados, etc.
QP4: Quais as abordagens utilizadas pelos estudos primários na detecção deanomalias de código em aplicações Web?
Objetivo: Identificar as abordagens consideradas pelos estudos primários nadetecção de anomalias de código em aplicações Web.
QP5: Quais as ferramentas utilizadas pelos estudos primários para detectaranomalias de código em aplicações Web?
Objetivo: Identificar as ferramentas existentes para detectar anomalias decódigo em aplicações Web, sejam elas de propósito geral ou especificamentevoltadas para esse tipo de aplicação, ou ainda específicas para umadeterminada linguagem de programação.
QP6: Aspectos de refatoração têm sido considerados pelos estudos primárioscomo forma de mitigar anomalias de código em aplicações Web?
Objetivo: Identificar se e que técnicas e ferramentas de refatoração têm sidoutilizadas na mitigação de anomalias de código em aplicações Web.
32
4.2 Estratégia de buscaPara recuperar os estudos potencialmente relevantes para responder às QPs
postas a partir da literatura, foi utilizado um processo automatizado de buscarealizado sobre cinco bases de dados eletrônicas de publicação: IEEEXplore , ACM2
Digital Library , ScienceDirect , Scopus e Web of Science . A escolha por essas bases3 4 5 6
de publicação levou em consideração o fato de elas estarem entre as bases maispopulares na área de Engenharia de Software e atestarem boa cobertura da literatura(DYBÅ; DINGSØYR; HANSSEN, 2007; KITCHENHAM; BUDGEN; BRERETON,2016; FELIZARDO et al., 2017). Outros critérios importantes considerados foram aqualidade dos resultados retornados pelo procedimento de busca automática, adisponibilidade de texto completo dos estudos, a facilidade de uso, a regularidade deatualização de conteúdo e a versatilidade na exportação de resultados (DIESTE;GRIMÁN; JURISTO, 2009).
Com base nas QPs definidas, dois termos principais foram inicialmenteidentificados, a saber, code smell e web application. Considerando sinônimos e termosalternativos, além de formas no singular e no plural, foi constituída a seguinte stringde busca (em Inglês):
(code smell OR code smells OR bad smell OR bad smells OR code bad smell OR codeanomaly OR code anomalies OR antipattern OR antipatterns OR anti-pattern OR
anti-patterns) AND (web application OR web applications)
em que os termos principais foram conectados com o operador lógico de conjunção(AND) e as possíveis variações e sinônimos foram conectados com o operador lógicode disjunção (OR).
Um ponto importante a destacar diz respeito à utilização do termo antipattern(antipadrão) e suas variações na string de busca. Esse termo foi considerado apenaspelo fato de que o conceito de antipadrão frequentemente é usado na literatura comose referindo a anomalias de código, porém tais conceitos são distintos. Anomalias decódigo podem ser entendidas como indicativos de um problema que pode ou nãoexistir a nível de código fonte, além de geralmente ocorrerem inadvertidamente, pordiversas razões. Por sua vez, antipadrões caracterizam-se por problemas de fatoexistentes e que foram deliberadamente adotados para implementação, adoção essaque inclusive pode levar à ocorrência de anomalias de código. Este trabalhoacompanha a definição apresentada por Paulo Sobrinho et al. (2021) em queanomalias de código referem-se a indicativos de problemas observados em estruturas
6 https://www.webofknowledge.com5 https://www.scopus.com4 https://www.sciencedirect.com3 https://dl.acm.org2 https://ieeexplore.ieee.org
33
de mais baixo nível em um programa, além de seguir a linha de raciocínio de Sharmae Spinellis (2018) quanto à distinção desse conceito com relação a antipadrões.
4.3 Critérios de seleçãoOs critérios de seleção foram utilizados com o objetivo de incluir os estudos
potencialmente relevantes para responder às QPs estabelecidas, bem como excluiraqueles que não teriam um conteúdo necessário para responder essas questões. Doiscritérios de inclusão (CIs) e cinco critérios de exclusão (CEs) foram definidos:
CI1: O estudo apresenta ou discute anomalias de código presentes emaplicações Web.
CI2: O estudo apresenta uma estratégia ou ferramenta para detecção de codesmells em aplicações Web.
CE1: O estudo não trata de anomalias de código em aplicações Web.
CE2: O estudo é uma versão anterior de um estudo mais completo sobre amesma pesquisa, de forma que o primeiro seja dispensável.
CE3: O trabalho não possui resumo ou o texto em sua integralidade não estádisponível.
CE4: O estudo é um índice, prefácio, tutorial, editorial, palestra ou resumo deconferência.
CE5: O texto do estudo não está em Inglês, idioma mais usado em trabalhoscientíficos.
Neste trabalho, um estudo foi considerado relevante se tiver satisfeito pelomenos um dos CIs e tiver satisfeito nenhum dos CEs.
4.4 Extração e síntese de dadosPara extração de dados, foi desenvolvida uma planilha com alguns dos dados
mais significativos dos estudos, os quais identificados como D1 a D15 na Tabela 2. Aplanilha foi preenchida com dados básicos como título, ano de publicação, veículo depublicação, tipo de publicação (conferência, workshop, periódico), número de citações,objetivo(s) do estudo. Além disso, foram coletados dados pertinentes às QPsdefinidas, tais como anomalias de código, aplicações ou projetos Web considerados,linguagens de programação e nível de ocorrência das anomalias (front-end, back-end,camadas). Finalmente, foram também levados em consideração as abordagens paradetecção de anomalias de código, ferramentas de detecção de anomalias de código,método de avaliação e métricas, técnicas de refatoração e atributos de qualidade.
34
Tabela 2 - Itens de dados extraídos dos estudos selecionados.
ID Descrição
D1 Título
D2 Ano de publicação
D3 Veículo de publicação
D4 Tipo de publicação
D5 Objetivo(s) do estudo
D6 Anomalias consideradas
D7 Ferramentas para detecção de anomalias consideradas
D8 Linguagem(ns) de programação considerada(s)
D9 Nível de ocorrência das anomalias
D10 Abordagens para detecção de anomalias de código
D11 Técnicas de refatoração consideradas
D12 Comentários adicionais
4.5 Processo de seleçãoO processo de busca e seleção de estudos foi realizado entre abril de 2020 e
março de 2021, considerando estudos que foram publicados até o final do ano de2020. No processo automatizado de busca, a string base de busca (ver Seção 4.1) foiadaptada às especificidades de cada uma das bases eletrônicas de publicação. OApêndice A apresenta as adaptações da string de busca para cada base considerada.
Após a realização da busca pelos estudos, foram removidos os resultadosduplicados (isto é, aqueles recuperados por mais de uma base de publicação) e assimdado início ao processo de seleção, o qual foi feito em três etapas. A primeira etapateve como objetivo aplicar os critérios de seleção (CIs e CEs) estabelecidos noprotocolo do mapeamento sistemático a partir da leitura do título e resumo dosestudos recuperados. Por sua vez, na segunda etapa, foi realizada a aplicação dessescritérios a partir da leitura de introdução e conclusão dos estudos. Por fim, a terceirae última etapa consistiu em aplicar novamente os critérios de seleção após a leituracompleta dos estudos restantes. Após o processo de seleção, foi feito opreenchimento da planilha de extração de dados com todas as informaçõesexplanadas na Seção 4.4. A Figura 7 ilustra a execução dessas etapas, a qual resultou
35
em um conjunto de 11 estudos selecionados como relevantes, identificados como E1 aE11 na Tabela 3.
Figura 7 - Processo para seleção dos estudos relevantes.
36
Tabela 3 - Lista dos estudos selecionados.
ID Título Referência Número de citações(Google Scholar , ago. 2021)7
E1 Analyzing Web ApplicationsQuality Evolution
Rio e Brito eAbreu (2017)
2
E2 Code Smell Detection Tool forJavascript Programs
Almashfi e Lu(2020)
4
E3 Code Smells forModel-View-ControllerArchitectures
Aniche et al.(2017)
44
E4 Code Smells Survival Analysis inWeb Apps
Rio e Brito eAbreu (2019)
2
E5 Detecting Design Violations inDjango-based Web Applications
Correia eAdachi (2019)
3
E6 Detecting Unknown Inconsistenciesin Web Applications
Ocariza, Jr. et al.(2017)
8
E7 Detection of Embedded CodeSmells in Dynamic WebApplications
Nguyen et al.(2012)
36
E8 JSNOSE: Detecting JavaScript CodeSmells
Fard e Mesbah(2013)
125
E9 On the Diffusion and Impact ofCode Smells in Web Applications
Bessghaier et al.(2020)
2
E10 The A?B*A Pattern: Undoing Stylein CSS and RefactoringOpportunities it Presents
Punt et al. (2016) 13
E11 The Smell of Blood: EvaluatingAnemia and Bloodshot Symptomsin Web Applications
Huang et al.(2019)
0
7 https://scholar.google.com/
37
5 ResultadosEste capítulo sumariza os resultados do mapeamento sistemático realizado
considerando as QPs definidas e os dados extraídos/sintetizados a partir dos estudosprimários selecionados e analisados. A Seção 5.1 fornece uma visão geral dos estudosselecionados e as Seções 5.2 a 5.7 apresentam as respostas a cada QP.
5.1 Visão geral dos estudos selecionados
Distribuição dos estudos ao longo dos anos. A Figura 8 apresenta adistribuição da publicação dos estudos voltados à análise de anomalias de código emaplicações Web ao longo dos anos. Apesar de as pesquisas relacionadas a esse temaserem bastante recentes, perfazendo um período de menos de uma década(2012-2020), é possível notar um certo crescimento no número de estudos publicadosnos quatro últimos anos.
Figura 8 - Distribuição dos estudos primários selecionados ao longo dos anos.
Veículos de publicação. A Figura 9 ilustra os veículos nos quais os estudosselecionados foram publicados. Dez dos estudos selecionados foram publicados emconferências internacionais e apenas um estudo foi publicado em periódico, comdestaque à IEEE/ACM International Conference on Automated Software Engineering(ASE) , conferência voltada a pesquisas relacionadas a técnicas e ferramentas para8
automatização das mais diversas atividades do processo de desenvolvimento de
8 36th IEEE/ACM International Conference on Automated Software Engineering (ASE 2021):https://conf.researchr.org/home/ase-2021
38
software, e ao Empirical Software Engineering (EMSE) , periódico internacional que9
abrange temas diversos relacionados a estudos empíricos na área de Engenharia deSoftware. Outros fóruns de interesse, nos quais frequentemente são publicadosestudos relacionados a anomalias de código, são a International Working Conference onSource Code Analysis and Manipulation (SCAM) e a International Conference on Software10
Maintenance and Evolution (ICSME) . Apesar de a expressa maioria dos estudos ter11
sido publicada em conferências, os fóruns alvo são conhecidos pelo seu alto rigor,resultando na publicação de estudos de alta qualidade.
Figura 9 - Veículos nos quais os estudos primários selecionados foram publicados.
Objetivos. Outro ponto relevante a se analisar para possibilitar uma visãogeral dos estudos selecionados diz respeito aos seus objetivos principais. A Figura 10contempla esses objetivos, destacando-se (i) a detecção das anomalias de código emaplicações Web, (ii) a análise dos efeitos das anomalias em diferentes aspectos demanutenibilidade e qualidade de código e (iii) a proposta de técnicas para lidar compotenciais anomalias, dentre as quais refatoração. Além disso, vale salientar que umestudo pode endereçar mais de um objetivo, como é o caso do estudo E7, o qualbuscou explorar a detecção das anomalias de código e verificar seus impactos namanutenibilidade do sistema.
11 37th International Conference on Software Maintenance and Evolution (ICSME 2021):https://icsme2021.github.io
10 21st IEEE International Working Conference on Source Code Analysis and Manipulation (SCAM2021): http://www.ieee-scam.org/2021/
9 Empirical Software Engineering: https://www.springer.com/journal/10664
39
Figura 10 - Objetivos principais dos estudos primários selecionados.
5.2 Ocorrência de anomalias de código em aplicações Web
A questão de pesquisa QP1 tem por intuito identificar as anomalias de códigoque mais ocorrem em aplicações Web. A Tabela 4 apresenta as anomalias citadaspelos estudos selecionados, em total de 50, sendo possível verificar que algunsestudos consideram mais de uma anomalia e que as anomalias mais estudadas nocontexto de aplicações Web são as mesmas que aparecem com maior frequência emestudos relacionados a sistemas de software tradicionais (PAULO SOBRINHO; DELUCIA; MAIA, 2021), mais especificamente Long Parameter List, Long Method, LargeClass e Lazy Class. Essas anomalias estão de maneira geral fortemente relacionadas àuma simplicidade prejudicada e ao fato de que essas classes e métodos podem estarlidando com muitas responsabilidades, aumentando a complexidade e dificultando amanutenibilidade e a compreensão da implementação. Isso pode se caracterizarcomo um indício de que os estudos relacionados a anomalias de código emaplicações Web tendem a verificar se as anomalias que ocorrem em sistemas desoftware tradicionais e já catalogadas e estudadas ao longo dos anos também seobservam nesse contexto. Outra razão para a prevalência dessas anomalias é a suarelativamente fácil detecção, o que é amplamente apoiado por ferramentas existentes.
Tabela 4 - Anomalias de código consideradas pelos estudos primários selecionados.
Anomalias Estudos
Argument Count Mismatch E2
Argument Type Mismatch E2
Array Length Assignment E2
40
Brain Repository / Brain Persistence Method E3, E5
Brain Controller E3
Closure Smells E8
Coupling between JavaScript, HTML, and CSS E8
Coupling Between Objects E4
Cyclomatic Complexity E2
CSS in HTML E7
CSS in JS E7
Data Class E11
Depth of Inheritance E4, E9
Duplicate Declaration E2
Duplicate JS E7
Empty Catch Blocks E8, E9
Excessive Number of Children E4, E9
Excessive Global Variables E8
Fat Repository E3
Feature Envy E11
God Class/Excessive Class Length / Blob E8, E9, E11
Goto Statement E9
High Coupling E9
High NPath Complexity E9
HTML Syntax Error E7
Improper Use of Manager E5
JS in HTML E7
Laborious Repository Method / Laborious Persistence Method /High Method Complexity
E3, E5, E9
Lazy Class/Lazy Objects E2, E8
Long Parameter List/Excessive Parameter List E2, E8, E9
41
Long Message Chain E8
Long Method/Excessive Method Length E2, E8, E9
Loosely-typed Variables E2
Primitive Property Assignment E2
Promiscuous Controller E3
Meddling Model E5
Meddling Service E3
Meddling View E5
Negative Array Index E2
Nested Callback E8
Refused Bequest E8
Scattered Sources E7
Switch Statements E8
Too Many Methods E9
Too Many Public Methods E9
Undoing Style E10
Unreachable Code E2
Unused/Dead Code E8
Unused Declaration E2
Undeclared Variables E2
Nos estudos primários selecionados, foi possível ainda identificar algumasanomalias consideradas especificamente no contexto de aplicações Web, em total de12. Essas anomalias são brevemente descritas a seguir.
Brain Repository/Brain Persistence Method. Observada nos estudos E3 e E5,esta anomalia ocorre quando existe uma classe Repository contendo uma lógica denegócio ou consultas complexas. O estudo E3 menciona duas situações comuns emuma aplicação Web que podem acarretar nessa anomalia e que às vezes podemacontecer na mesma classe, a saber, (i) consultas SQL muito complexas, ou seja, umaúnica consulta que une tabelas diferentes, que contém filtros complexos, etc., ou (ii)lógica complexa para construir consultas dinâmicas ou objetos de montagem que
42
resultam da execução da consulta.
Brain Controller. Observada no estudo E3, esta anomalia ocorre quando existeum controle de fluxo complexo presente em uma classe Controller de uma aplicaçãoWeb. Em uma aplicação Web que segue o padrão arquitetural Model-View-Controller(MVC), os elementos Model são classes que representam as entidades gerenciadaspela aplicação, os elementos View representam as páginas Web que servem deinterface gráfica com o usuário e exibem informações a ele e os Controllers são classesque interceptam a interação do usuário através dos elementos View para outroselementos da aplicação (BUSCHMANN et al., 1996). Dessa forma, um Controller comcontrole de fluxo complexo, além de dificultar a sua manutenção, muitas vezes indicaum problema intrínseco ao projeto arquitetural do software.
CSS in HTML. Observada no estudo E7, esta anomalia indica uma violação àseparação de interesses (em inglês, Separation of Concerns), um dos princípiosimportantes no projeto de software. Ela ocorre quando há uma má combinação entreo código referente ao estilo de apresentação (CSS) e o de conteúdo de apresentação(HTML).
CSS in JS. Assim como a anomalia CSS in HTML, esta anomalia, observada noestudo E7, indica uma violação à separação de interesses. Ela ocorre quando há umamá combinação do código referente ao estilo de apresentação (CSS) e o da lógica deapresentação (JavaScript, por exemplo), ou seja, uma instrução de atribuição nocódigo define algumas propriedades do atributo de estilo de um elemento HTML.
JS in HTML. Observada no estudo E7, assim como as anomalias CSS in HTMLe a CSS in JS, esta anomalia indica uma violação à separação de interesses, ocorrendoquando há uma má combinação do código referente ao código de lógica deapresentação (JavaScript, por exemplo) e o de conteúdo de apresentação (HTML).
Fat Repository. Observada no estudo E3, esta anomalia ocorre quando umaclasse Repository lida com várias entidades (entities) ao mesmo tempo. Isto porquenormalmente há uma relação um-para-um entre uma classe Repository e uma classeEntity. Dessa forma, sendo responsável por mais de uma entidade, essa classeRepository pode ter baixa coesão e difícil manutenção.
Laborious Repository Method/Laborious Persistence Method/High MethodComplexity. Observada nos estudos E3 e E5, esta anomalia de código remete à ideiade que um método deve ter apenas uma responsabilidade e executar uma únicaoperação. Por exemplo, se um único método contém mais de uma consulta ou fazmais de uma ação com o banco de dados, este pode ser considerado muito complexoou pouco coeso, caracterizando assim uma anomalia. No caso de um LaboriousPersistence Method, tem-se um método de persistência realizando múltiplas açõesrelacionadas a operações com banco de dados. Em uma aplicação Web, osdesenvolvedores geralmente precisam invocar diferentes métodos para implementar
43
a consulta, passar parâmetros, executar e lidar com seu retorno em uma classeRepository (ou para aquelas aplicações que não utilizam o framework Spring MVC ,12
uma classe de persistência). Na definição apresentada pelo estudo E3, se um métodorealiza mais de uma ação de persistência, ele pode ser caracterizado como umLaborious Persistence Method.
Promiscuous Controller. Os Controllers presentes em aplicações Web queseguem o padrão arquitetural MVC devem ser enxutos e fornecer métodos coesos.Por esse motivo, esta anomalia, observada no estudo E3, ocorre quando há Controllersfornecendo diversos serviços para o sistema, implicando em dificuldade demanutenção uma vez que são muitas funcionalidades envolvidas.
Meddling Service. Observada no estudo E5, esta anomalia ocorre quando umauma classe Service acessa diretamente um mecanismo de persistência da aplicaçãoWeb. Isso acontece porque, no padrão arquitetural MVC adotado pelo frameworkSpring, há uma separação de responsabilidades em que as classes Service sãoresponsáveis por implementar a lógica de negócio, enquanto que as classes Repositorysão responsáveis por encapsular a lógica de persistência.
Meddling Model. Observada no estudo E5, esta anomalia remete às aplicaçõesWeb que seguem o padrão arquitetural Model-Template-View (MTV) e ocorre quando13
um método de uma classe Model implementa recursos de apresentação de dados,como formatação e retorno de dados em formato HTML, violando assim uma dasregras desse padrão arquitetural. Isso é problemático porque os elementos View sãoresponsáveis por codificar o formato de apresentação e recuperar os dadosnecessários para construir a saída a ser exibida ao usuário, enquanto que oselementos Template são responsáveis por realmente implementar as ações deapresentação.
Meddling View. Observada no estudo E5, esta anomalia também remete àsaplicações Web que seguem o padrão arquitetural MTV e ocorre quando um métododos elementos View implementa operações de persistência, violando assim uma dasregras desse padrão arquitetural. Isso é problemático, pois é de responsabilidade doselementos Model implementarem métodos de persistência, ou seja, métodos queexecutam consultas SQL ou realizam chamadas para interfaces de persistência.
Undoing Style. Observada no estudo E10, esta anomalia remete à linguagemCSS e ocorre quando uma dada propriedade é definida com um valor A, em seguidasubstituída por outro valor B, possivelmente várias vezes e, logo depois definida devolta para o valor original A. Essa anomalia trata de um padrão detectado no códigoCSS que dificulta a sua manutenção.
13 https://djangobook.com/mdj2-django-structure/12 https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/mvc.html
44
Principais resultados (QP1). Algumas das anomalias de código observadas nosestudos relacionados a aplicações Web são as mesmas estudadas em sistemas desoftware tradicionais, com destaque para Long Parameter List, Long Method, GodClass (Large Class) e Lazy Class. No entanto, há a descrição de anomaliasespecificamente voltadas para aplicações Web, tais como as relacionadas aoperações envolvendo bancos de dados, as relacionadas à mistura de código emdiferentes linguagens e outras específicas para aplicações Web que fazem uso depadrões arquiteturais específicos como Model-View-Controller (MVC) eModel-Template-View (MTV).
5.3 Linguagens de programação
A questão de pesquisa QP2 tem por objetivo identificar as linguagens deprogramação das aplicações Web consideradas pelos estudos, possibilitando observarse as abordagens existentes possuem um caráter mais genérico ou específico delinguagem, além de investigar se há algum tipo de relação entre a linguagemutilizada e a ocorrência de anomalias de código. Conforme apresentado pela Tabela5, é possível observar que as linguagens consideradas pelos estudos foram bastantediversificadas, dentre elas PHP (quatro estudos), JavaScript (quatro estudos), HTML(quatro estudos), CSS (três estudos), Java (dois estudos) e Python (um estudo). Épossível ainda observar que alguns estudos consideraram múltiplas linguagens paraa implementação das páginas que constituirão a interface com o usuário e dasfuncionalidades da aplicação.
Tabela 5 - Linguagens de programação consideradas nos estudos primários selecionados.
Estudos PHP JavaScript CSS Java Python HTML
E1 X
E2 X
E3 X
E4 X
E5 X
E6 X X
E7 X X X X
E8 X X X
E9 X
E10 X X
45
E11 X
A análise dos estudos primários selecionados permitiu também identificar quepoucas foram as pesquisas que abordaram anomalias de código específicas para umalinguagem de programação, como foi o caso dos estudos E2 e E8, que focaramespecificamente em anomalias relacionadas à linguagem JavaScript. Fazendo umarelação com os resultados da investigação da questão de pesquisa QP1, em que seobservou que as anomalias identificadas possuem uma natureza mais genérica, épossível concluir que não há evidências de uma relação exata entre a linguagemutilizada e a ocorrência de uma anomalia específica.
Principais resultados (QP2). As linguagens consideradas pelos estudos foramPHP, JavaScript, Java, Python, CSS e HTML, transitando entre a implementaçãoda interface com o usuário e a implementação da lógica de negócio da aplicação.
5.4 Local de ocorrência das anomalias de código em aplicaçõesWeb
Aplicações Web são tipicamente compostas por dois níveis principais, (i) ofront-end, o qual diz respeito às páginas que constituem a interface gráfica com ousuário e possibilitam que este interaja com a aplicação e (ii) o back-end, no qual alógica de negócio e de acesso a dados é geralmente implementada e que processa assolicitações provenientes da interação do usuário com a interface da aplicação.Considerando esses dois níveis, a questão de pesquisa QP3 tem por objetivoidentificar se as anomalias de código em aplicações Web ocorrem maisfrequentemente a nível de front-end e/ou de back-end e locais específicos nessesníveis, tais como camadas de negócio ou de acesso a dados, etc.
A partir da análise dos estudos selecionados, cujos resultados sãoapresentados na Tabela 6, é possível constatar que as anomalias de código emaplicações Web ocorrem de forma semelhante tanto a nível de front-end quanto deback-end, não sendo possível afirmar exatamente qual deles é mais afetado poranomalias de código. Os estudos que consideraram o front-end estavam mais focadosem encontrar anomalias de código em implementações realizadas com JavaScript eCSS, enquanto que aqueles que consideraram o back-end estavam focados em detectaranomalias encontradas em implementações realizadas na linguagem PHP.
Tabela 6 - Níveis de ocorrência de anomalias de código em aplicações Web consideradospelos estudos primários selecionados.
Nível Estudos
Front-end E1, E2, E6, E8, E10
46
Back-end E1, E4, E7, E9, 11
Arquitetural E3, E5
Dentre os estudos primários selecionados, identificou-se também que doisdeles (E3 e E5) estavam interessados em analisar violações ao projeto arquitetural deuma aplicação Web, especificamente aquelas que surgem ao adotar o padrão MVC.Nesses estudos, as violações de projeto dizem respeito a elementos do código fonte,tais como classes e métodos, que desrespeitam regras definidas pela arquiteturasubjacente ou que não respeitam bons princípios de projeto de software e, como tal,podem indicar elementos que comprometem a capacidade de manutenção e evoluçãodo software. De qualquer forma, nesses dois estudos, as anomalias consideradasestavam mais próximas de inconsistências detectadas a nível de back-end dos projetos,visto que anomalias intrínsecas a classes como Repository, Controller e Service, porexemplo, são encontradas nesse nível.
Outro ponto importante a ser destacado trata-se da relação dos locais deocorrência das anomalias de código em aplicações Web com as linguagens deprogramação utilizadas (ver Seção 5.3). Com exceção dos estudos E3 e E5, os quaistrataram anomalias de código relacionadas ao projeto arquitetural, todos os outrosestudos trataram de anomalias tanto em nível de front-end quanto de back-end nasdiferentes linguagens de programação.
Principais resultados (QP3). As anomalias de código ocorrem tanto no nível defront-end quanto de back-end, havendo também estudos com enfoque nainfluência de anomalias de código em níveis superiores de abstração.
5.5 Abordagens para detecção de anomalias de código emaplicações Web
Em sua revisão sistemática de literatura acerca de anomalias de código emsistemas de software tradicionais, Sharma e Spinellis (2018) categorizam asabordagens existentes para a detecção dessas anomalias em cinco grandes grupos: (i)detecção baseada em métricas, em que é calculado um conjunto de métricas relativas aao código fonte e, com base nos valores obtidos, determina-se a ocorrência ou não deuma anomalia com base em um limiar; (ii) detecção baseada em regras/heurísticas, emque são definidas regras ou heurísticas que caracterizariam uma anomalia e o códigofonte é analisado para verificar se tais regras/heurísticas são satisfeitas, indicandoassim a presença de tal anomalia; (iii) detecção baseada em histórico, a qual utilizainformações de como o código fonte foi modificado ao longo do tempo para inferir apresença de anomalias; (iv) detecção baseada em Aprendizado de Máquina, a qual usatécnicas de Inteligência Computacional para determinar a ocorrência de uma
47
anomalia considerando um modelo construído a partir de exemplos existentes e dopróprio código fonte, e; (v) detecção baseada em otimização, na qual algoritmos deotimização são utilizados sobre métricas do código fonte para detectar a ocorrênciade anomalias. A questão de pesquisa QP5 tem por objetivo identificar as abordagensempregadas pelos estudos primários selecionados para detectar anomalias de códigoem aplicações Web e como elas se enquadram em tais categorias.
Analisando os estudos primários selecionados à luz das cinco categoriasanteriormente mencionadas, foi possível constatar que todos eles fazem uso deabordagens baseadas em métricas ou em regras para possibilitar a detecção deanomalias de código em aplicações Web, tanto para as estudadas em sistemas desoftware tradicionais quanto as propostas especificamente no contexto de aplicaçõesWeb (ver Tabela 7). Essas observações alinham-se de certa forma com os resultadosreportados por Sharma e Spinellis (2018) em sua revisão sistemática de literatura, emque as abordagens mais utilizadas para detectar anomalias de código em sistemas desoftware tradicionais são as baseadas em métricas. Essa prevalência explica-se pelaampla disponibilidade de métricas de software na literatura e de ferramentas capazesde computá-las, facilitando assim a implementação de uma abordagem que faça usodessas métricas para detectar anomalias de código. Todavia, abordagens baseadas emmétricas dependem essencialmente da definição apropriada de limiares (thresholds)que caracterizariam a ocorrência de anomalias de código, o que não é trivial(FERREIRA et al., 2012; SHARMA; SPINELLIS, 2018).
Tabela 7 - Abordagens empregadas para detectar anomalias de códigoem aplicações Web reportadas pelos estudos primários selecionados.
Abordagens Estudos
Detecção baseada em métricas E2, E3, E4, E5, E8, E9
Detecção baseada em regras E2, E5, E6, E7, E10, E11
Dentre os estudos analisados, identificou-se ainda que dois deles (E2 e E5)utilizaram em conjunto os dois tipos de abordagens de acordo com a anomalia decódigo a ser detectada. De acordo com Sharma e Spinellis (2018), combinarabordagens baseadas em métricas e baseadas em regras podem maximizar acobertura da detecção de anomalias de código, tendo em vista que algumas delaspodem ser detectadas via métricas enquanto outras através da verificação de regras.
Por fim, outra constatação que pode ser feita a partir da análise dos estudosprimários é que nenhum deles propôs-se a utilizar técnicas de Aprendizado deMáquina para detectar anomalias de código em aplicações Web, o que já é feito parasistemas de software tradicionais, como reportam as recentes revisões sistemáticas deliteratura realizadas por Caram et al. (2019), Azeem et al. (2019) e Al-Shaaby et al.
48
(2020). Com isso, observa-se que há uma clara oportunidade de pesquisa na direçãode investigar como técnicas de Aprendizado de Máquina poderiam ser utilizadaspara detectar anomalias de código em aplicações Web.
Principais resultados (QP4). As abordagens empregadas para detectaranomalias de código em aplicações Web são essencialmente as baseadas emmétricas e as baseadas em regras. Apesar de sua popularidade, técnicas deAprendizado de Máquina ainda não têm sido investigadas para serem aplicadasna detecção de anomalias de código nesse contexto.
5.6 Ferramentas para detecção de anomalias de código emaplicações Web
A questão de pesquisa QP6 tem por objetivo identificar as ferramentasutilizadas pelos estudos para detectar anomalias de código em aplicações Web. Apartir dos estudos analisados, foi possível identificar uma ampla diversidade deferramentas utilizadas, as quais são listadas na Tabela 8. Dentre os estudos queempregam ferramentas para dar suporte à detecção de anomalias de código emaplicações Web, a maioria deles (6/9) propôs novas ferramentas, as quaisconstituíram contribuições próprias dos estudos. Além disso, três estudos (E1, E4 eE9) utilizaram a ferramenta PHPMD para detectar anomalias de código e outrasviolações de boas práticas de programação em PHP.
Tabela 8 - Ferramentas para detecção de anomalias de código em aplicações Web consideradaspelos estudos primários selecionados.
LinguagensFerramentas
PHPMD14
TAJSlint15 HOLOCRON
16WebScent PMD17 MTV-Checker
18JSNOS
E
PHP X X
Java X X
JavaScript X X X
HTML X X X
CSS X X
18 https://github.com/reniericorreia/MTVchecker17 https://pmd.github.io/16 https://github.com/DependableSystemsLab/Holocron15 https://www.brics.dk/TAJS/14 https://phpmd.org/
49
Python X
Outra observação decorrente da análise dos estudos primários selecionadosdiz respeito à multiplicidade de linguagens consideradas pelas ferramentasempregadas para detectar anomalias de código em aplicações Web. Devido àscaracterísticas desse tipo de aplicação, nota-se que as ferramentas devem dar suportea linguagens utilizadas tanto para implementar a interface gráfica com o usuário (taiscomo HTML e CSS, voltadas ao lado cliente) quanto para implementar a lógica denegócio (tais como PHP e Java, voltadas ao lado servidor), possibilitando assim umaanálise mais completa acerca da presença de anomalias de código na aplicação Web.Foi possível também observar que um dos estudos (E1) utilizou a PMD, umaferramenta de análise estática de código que não é especificamente voltada paraaplicações Web, mas que foi utilizada para detectar, com base em regras, possíveisanomalias de código em uma aplicação Web desenvolvida na linguagem deprogramação Java, nesse caso, restringindo-se à análise da implementação daaplicação a nível de back-end.
Principais resultados (QP5). As ferramentas utilizadas para detectar anomaliasde código em aplicações Web são diversas, a maioria delas tendo sido propostaspelos próprios estudos. Há ainda uma prevalência das ferramentas emutilizarem múltiplas linguagens para possibilitar uma análise mais completa dasaplicações, estando assim em conformidade com as características típicas deaplicações Web.
5.7 Aspectos de refatoração
O conceito de anomalias de código foi introduzido como indicativos deestruturas do código fonte que necessitam de refatoração, isto é, o processo depromover melhorias na qualidade do código fonte em termos de compreensão,complexidade e manutenibilidade sem alterar o comportamento visível da aplicação(FOWLER, 2019). Com a catalogação das anomalias de código, foram propostasdiferentes técnicas de refatoração para solucioná-las. Nessa perspectiva, a questão depesquisa QP6 tem por objetivo identificar se e que técnicas de refatoração forampropostas ou utilizadas nos estudos primários selecionados para solucionaranomalias de código em aplicações Web. No caso de novas anomalias, específicaspara esse contexto, esta QP também tem o interesse de identificar se novas técnicasde refatoração seriam propostas para solucionar tais problemas.
Pela análise dos estudos primários selecionados, observou-se que forampoucos os estudos que tornaram explícitas as técnicas de refatoração do código apósa detecção de anomalias em aplicações Web. Uma possível razão para isso é que,conforme reportado na Seção 5.2, a maior parte das anomalias consideradas pelos
50
estudos diz respeito às mesmas já observadas em sistemas de software tradicionais, jáexistindo, portanto, técnicas de refatoração conhecidas e catalogadas parasolucioná-las.
A Tabela 9 descreve as técnicas de refatoração descritas em dois dos estudosprimários selecionados (E3 e E5). Essas técnicas visam solucionar algumas dasanomalias de código identificadas especificamente no contexto de aplicações Web,como as listadas na Seção 5.2.
Tabela 9 - Técnicas de refatoração propostas para solucionar algumas anomalias de códigoespecíficas para aplicações Web.
Anomalias Técnicas de Refatoração
PromiscuousController
Dividir a classe Controller em duas ou mais classes, de forma quecada nova classe Controller passaria a conter um conjunto coeso deações oferecidas. O processo é repetido para cada nova classeController identificada ainda como problemática.
Brain Controller Transferir a lógica de negócio existente para uma entidade,componente ou uma classe Service específica.
Meddling Service Mover a consulta SQL existente para uma classe Repository.
Brain Repository Transferir a lógica complexa para um método e a própria consultaSQL para outro método. Se a lógica complexa for usada por outrasclasses Repository, é necessário também movê-la para umcomponente.
Laborious RepositoryMethod
Dividir as várias ações de persistência que existem em métodosdiferentes de uma única classe Repository, de forma que essesmétodos recém-criados podem ou não ser privados para essaclasse Repository, ou seja, se uma ação de persistência pode serusada sozinha, o novo método pode ser público.
Fat Repository Mover métodos que estão relacionados a outras entidades para aclasse Repository específica associada a essa entidade.
Brain PersistenceMethod / LaboriousPersistence Method
Trocar consultas SQL por objetos de um mapeamentoobjeto-relacional.
Principais resultados (QP6). Poucos estudos explicitam técnicas de refatoraçãodo código para solucionar anomalias de código em aplicações Web, em partepelo fato de que a maior parte das anomalias consideradas pelos estudos dizrespeito às mesmas já observadas em sistemas de software tradicionais, para asquais já se tem técnicas de refatoração catalogadas.
51
6 Análise de ValidadeUm ponto importante neste trabalho é aferir a validade dos resultados obtidos
a partir do mapeamento sistemático realizado, uma vez que resultados confiáveis ede alta qualidade trazem credibilidade junto à comunidade científica. Para alcançarresultados de fato corretos em qualquer estudo empírico, faz-se necessário investigartodas as causas capazes de influenciar nessas conclusões ou ainda as que podeminduzir a uma má interpretação destas. Essas causas, as quais podem surgir emqualquer fase do estudo e, por consequência, afetar a validade dos resultados econclusões decorrentes, são chamadas de ameaças à validade (SHADISH; COOK;CAMPBELL, 2001; WOHLIN et al., 2012). Essas limitações são identificadas por meiode uma análise de validade, além de serem discutidas as estratégias de mitigação delas(FELDT; MAGAZINIUS, 2010). Nessa perspectiva, este capítulo faz uma análise devalidade do mapeamento sistemático realizado neste trabalho, descrevendo asprincipais limitações identificadas e as estratégias adotadas para minimizá-las.
Validade externa. A validade externa diz respeito basicamente à capacidadede generalização dos resultados obtidos, o que, para um mapeamento sistemático daliteratura, estaria relacionado com a completude do estudo. A ameaça maissignificativa à validade externa deste trabalho está relacionada à possibilidade deestudos relevantes não terem sido considerados. Para reduzir essa ameaça, foramutilizadas cinco das bases eletrônicas de publicação mais relevantes na área deEngenharia de Software. Ainda assim, algumas limitações persistem. Primeiro,alguns estudos podem não ter sido recuperados devido a limitações técnicas dospróprios motores de busca automática das bases eletrônicas de publicação, sobre osquais não há controle preciso. Segundo, essas bases não representam uma listaexaustiva de fontes de publicação, de modo que outras bases poderiam ter sidotambém consideradas. Terceiro, não foi feito uso da técnica de snowballing (WOHLIN,2014), a qual permite identificar, a partir dos estudos primários selecionados, estudosadicionais que não foram recuperados no procedimento de busca automatizada.Quarto, este trabalho não considerou literatura cinzenta (por exemplo, white papers,relatórios técnicos, dissertações, artigos não revisados por pares, etc.) como fonte deestudos. Apesar do reconhecido valor que tem sido dado à literatura cinzenta comofonte de evidência no contexto da Engenharia de Software (KAMEI et al., 2021a;2021b), não considerá-la não é seria necessariamente uma ameaça adicional uma vezque processos de revisão por pares são requisito padrão para publicações de altaqualidade.
Validade interna. A validade interna possui foco na condução do estudo, emparticular nos procedimentos adotados para extração e síntese dos dados, e se existealgum fator que possa ter causado algum tipo de viés no processo. Duas potenciaisameaças à validade interna são a imprecisão do processo de extração de dados e viés
52
na síntese de dados, principalmente porque nem todos os estudos descrevem demaneira clara e suficiente as informações a serem extraídas deles. Assim sendo, foinecessário inferir algumas informações com relação aos itens de dados nos processosde extração e síntese de dados. Para minimizar essas ameaças, os itens de extração dedados foram definidos de forma precisa no protocolo (ver Seção 4.4), ao qual houveaderência estrita. Além disso, foram realizadas discussões com um pesquisador comconhecimento sólido em anomalias de código e aplicações Web no intuito declarificar quaisquer inconsistências.
Validade de construção. A validade de construção está relacionada àcapacidade do projeto do estudo em responder às questões de pesquisa investigadas.A seleção dos estudos primários de acordo com os critérios de inclusão e exclusão foirealizada de forma rigorosa para garantir que esses estudos fossem de fatoadequados para responder às QPs. Esses critérios e os estudos decorrentes das etapasde seleção (ver Seção 4.5) foram extensivamente discutidos com um pesquisador comconhecimento sólido em anomalias de código e aplicações Web.
Validade de conclusão. A validade de conclusão diz respeito principalmente àanálise dos resultados obtidos, estando relacionada a que ponto eles podem serconsiderados corretos e o quão rigoroso e reprodutível foi o processo para seestabelecer conclusões a partir desses resultados. A fim de mitigar potenciaisameaças à validade de conclusão, foi estabelecido um protocolo bem definido queorientou todas as atividades realizadas neste estudo (ver Capítulo 4). Esse protocolofoi extensivamente debatido com um pesquisador com experiência na condução derevisões e mapeamentos sistemáticos da literatura.
53
7 Considerações FinaisEste trabalho apresentou os resultados de um mapeamento sistemático da
literatura realizado com o objetivo de prover um panorama acerca do estado da arteacerca de anomalias de código em aplicações Web, investigando a sua ocorrência ecomo elas podem ser identificadas. Utilizando um processo rigoroso de coleta eseleção, elaborado com base em diretrizes bem estabelecidas na literatura, 11 estudosprimários, de um universo inicial de 92 estudos recuperados a partir de cincorelevantes bases eletrônicas de publicação, foram analisados para (i) identificar asanomalias de código que ocorrem em aplicações Web, (ii) identificar e analisar asabordagens e ferramentas propostas na literatura para detectar anomalias de códigoem aplicações Web e (iii) observar se e como aspectos de refatoração têm sidoconsiderados no tocante a anomalias de código em aplicações Web.
A análise dos estudos primários selecionados resultou nas seguintesconclusões acerca do estado da arte acerca de anomalias de código em aplicaçõesWeb:
● apesar de anomalias de código serem um tópico bastante investigado nocontexto de sistemas de software tradicionais, o mesmo não aconteceespecificamente para aplicações Web, não havendo ainda, portanto, umcorpo significativo de estudos relacionados a esse tópico;
● devido ao fato de certas anomalias de código serem objeto de investigaçãode dezenas de estudos considerando sistemas de software tradicionais,parece haver uma tendência a investigar se e como essas anomaliastambém se observam em aplicações Web, o que é comprovado pelo fato dea maioria das anomalias consideradas pelos estudos primáriosselecionados serem as que ocorrem com maior frequência no contexto desistemas de software tradicionais;
● as linguagens consideradas pelos estudos são diversas e as ferramentaspara detecção de anomalias de código em aplicações Web considerammúltiplas linguagens, como consequência da inerente heterogeneidadedessas aplicações;
● as anomalias de código identificadas ocorrem tanto no nível de front-endquanto de back-end, sem haver, a priori, uma prevalência;
● as abordagens mais utilizadas para detectar anomalias de código emaplicações Web são as baseadas em regras, sendo o código fonte analisadocontrastado com regras que representam potenciais anomalias;
● as ferramentas para detecção de anomalias de código são diversas, amaioria delas tendo sido propostas pelos próprios estudos, e;
● aspectos de refatoração para solucionar anomalias de código emaplicações Web não têm sido muito abordados de forma específica pelos
54
estudos, em parte devido à presença de anomalias de código de sistemasde software tradicionais para as quais já existem técnicas de refatoraçãocatalogadas.
Os resultados apresentados neste trabalho atestam que o número de estudosdedicados a anomalias de código em aplicações Web ainda é pequeno, o que indicaque há plena margem para a condução de diversas pesquisas nesse contexto, aexemplo da exploração de técnicas de Aprendizado de Máquina, como tem sidoabordado recentemente em uma série de estudos no contexto sistemas de softwaretradicionais (AZEEM et al., 2019; CARAM et al, 2019; AL-SHAABY; ALJAMAAN;ALSHAYEB, 2020). Além disso, como discutido no Capítulo 1 deste trabalho,aplicações Web possuem características que as diferem de forma significativa desistemas de software tradicionais e, por isso, investigar de maneira maisaprofundada anomalias de código que sejam específicas desse tipo de aplicação,possivelmente novas, representa uma direção promissora de pesquisa.
Finalmente, a identificação de anomalias de código que ocorrem em aplicaçõesWeb, conforme reportado neste trabalho, pode contribuir com a elaboração de umcatálogo de anomalias de código específico para esse contexto. A existência de umcatálogo como esse é importante para que seja possível documentar as anomaliasexistentes para que, com isso, desenvolvedores possam compreender e identificarmais adequadamente se tais anomalias manifestam-se em suas aplicações Web ecomo seria possível mitigá-las mediante refatorações. A proposição de tal catálogopode também ser útil para melhor orientar as abordagens e ferramentas atuais efuturas com vistas a uma detecção mais eficaz de anomalias de código em aplicaçõesWeb.
55
ReferênciasALADDIN, Mohamed. Write clean code and get rid of code smells with real lifeexamples. 2018. Disponível em:<https://codeburst.io/write-clean-code-and-get-rid-of-code-smells-aea271f30318>.Acesso em: 21 jul. 2021.
ALMASHFI, Nabil; LU, Lunjin. Code smell detection tool for Java Script programs.In: International Conference on Computer and Communication Systems, 5., 2020.Proceedings [...] USA: IEEE, 2020. p. 172-176. DOI 10.1109/ICCCS49078.2020.9118465.
AL-SHAABY, Ahmed; ALJAMAAN, Hamoud; ALSHAYEB, Mohammad. Bad smelldetection using Machine Learning techniques: A systematic literature review.Arabian Journal for Science and Engineering, v. 45, p. 2341-2369, Apr. 2020. DOI10.1007/s13369-019-04311-w.
ANICHE, Maurício; BAVOTA, Gabriele; TREUDE, Christoph; GEROSA, MarcoAurélio; VAN DEURSEN, Arie. Code smells for Model-View-Controller architectures.Empirical Software Engineering, v. 23, n. 4, p. 2121-2157, Aug. 2018. DOI10.1007/s10664-017-9540-2.
AZEEM, Muhammad Ilyas; PALOMBA, Fabio; SHI, Lin; WANG, Qing. MachineLearning techniques for code smell detection: A systematic literature review andmeta-analysis. Information and Software Technology, v. 108, p. 115-138, Apr. 2019.DOI 10.1016/j.infsof.2018.12.009.
BESSGHAIER, Narjes; OUNI, Ali; MKAOUER, Mohamed Wiem. On the diffusionand impact of code smells in Web applications. In: WANG, Qingyang; XIA, Yunni;SESHADRI, Sangeetha; ZHANG, Liang-Jie (eds.) Services Computing - SCC 2020.Switzerland: Springer Nature Switzerland AG, 2020. p. 67-84. (Lecture Notes inComputer Science, v. 12409) DOI 10.1007/978-3-030-59592-0_5.
BECK, Kent; FOWLER, Martin. Bad smells in code. In: FOWLER, Martin.Refactoring: Improving the design of existing code. USA: Addison-Wesley Longman,Inc., 1999.
BOGNER, Justus; BOCECK, Tobias; POPP, Matthias; TSCHECHLOV, Dennis;WAGNER, Stefan; ZIMMERMANN, Alfred. Towards a collaborative repository forthe documentation of service-based antipatterns and bad smells. In: 2019 IEEEInternational Conference on Software Architecture Companion. USA: IEEE, 2019.p. 95-101. DOI 10.1109/ICSA-C.2019.00025.
BUSCHMANN, Frank; MEUNIER, Regine; ROHNERT, Hans; SOMMERLAD, Peter;STAL, Michael. Pattern-oriented software architecture - Volume 1: A system of
56
patterns. United Kingdom: John Wiley & Sons, Inc., 1996 (Wiley Series in SoftwareDesign Patterns).
CARAM, Frederico Luiz; OLIVEIRA RODRIGUES, Bruno Rafael; SILVEIRACAMPANELLI, Amadeu; SILVA PARREIRAS, Fernando. Machine Learningtechniques for code smells detection: A systematic mapping study. InternationalJournal of Software Engineering and Knowledge Engineering, v. 29, n. 2, p.285-316, Feb. 2019. DOI 10.1142/S021819401950013X.
CAIRO, Aloisio S.; F. CARNEIRO, Glauco de; P. MONTEIRO, Miguel. The impact ofcode smells on software bugs: A systematic literature review. Information, v. 9, 2018.DOI 10.3390/info9110273.
CORREIA, Renieri; ADACHI, Eiji. Detecting design violations in Django-based Webapplications. In: Brazilian Symposium on Software Components, Architectures, andReuse, 13., 2019. Proceedings [...] USA: ACM, 2019. p. 33-42. DOI10.1145/3357141.3357600.
DIESTE, Oscar; GRIMÁN, Ana; JURISTO, Natalia. Developing search strategies fordetecting relevant experiments. Empirical Software Engineering, v. 14, n. 5, p.513-539, Oct. 2009. DOI 10.1007/s10664-008-9091-7.
DYBÅ, Tore; DINGSØYR, Torgeir; HANSSEN, Geir K. Applying systematic reviewsto diverse type studies: An experience report. In: International Symposium onEmpirical Software Engineering and Measurement, 1., 2007. Proceedings [...] USA:IEEE, 2007. p. 225-234. DOI 10.1109/ESEM.2007.59.
FARD, Amin Milani; MESBAH, Ali. JSNOSE: Detecting JavaScript code smells. In:IEEE International Conference on Source Code Analysis and Manipulation, 13., 2013.Proceedings [...] USA: IEEE, 2013. p. 116-125. DOI 10.1109/SCAM.2013.6648192.
FELDT, Robert; MAGAZINIUS, Ana. Validity threats in Empirical SoftwareEngineering research - An initial survey. In: International Conference on SoftwareEngineering and Knowledge Engineering, 22., 2010. Proceedings [...] USA: KSIResearch, Inc., 2010. p. 374-379.
FELIZARDO, Katia Romero; NAKAGAWA, Elisa Yumi; FABBRI, Sandra CamargoPinto Ferraz; FERRARI, Fabiano Cuguti. Revisão sistemática da literatura emEngenharia de Software: Teoria e prática: Brasil: Elsevier, 2017.
FERNANDES, Eduardo; OLIVEIRA, Johnatan; VALE, Gustavo; PAIVA, Thanis;FIGUEIREDO, Eduardo. A review-based comparative study of bad smell detectiontools. In: International Conference on Evaluation and Assessment in SoftwareEngineering, 20., 2016. Proceedings [...] USA: ACM, 2016. DOI10.1145/2915970.2915984.
FERREIRA, Kécia A. M.; BIGONHA, Marisa A. S.; BIGONHA, Roberto; MENDES,Luiz F. O.; ALMEIDA, Heitor C. Identifying thresholds for object-oriented software
57
metrics. Journal of Systems and Software, v. 85, n. 2, p. 244-257, Feb. 2012. DOI10.1016/j.jss.2011.05.044.
FOWLER, Martin. Refactoring: Improving the design of existing code. 2. ed. USA:Pearson Education, Inc., 2019.
GUPTA, Aakanshi; SURI, Bharti; MISRA, Sanjay. A systematic literature review:Code bad smells in Java source code. In: GERVASI, Osvaldo et al. (eds.)Computational Science and its Applications - ICCSA 2017. Switzerland: SpringerInternational Publishing AG, 2017. p. 665-682. (Lecture Notes in Computer Science, v.10408) DOI 10.1007/978-3-319-62404-4_49.
HUANG, Zijie; CHEN, Junhua; GAO, Jianhua. The smell of blood: Evaluatinganemia and bloodshot symptoms in Web Applications. In: International Conferenceon Software Engineering and Knowledge Engineering, 31., 2019. Proceedings [...]USA: KSI Research Inc., 2019. p. 141-186. DOI 10.18293/SEKE2019-061.
HAQUE, Md Shariful; CARVER, Jeff; ATKISON, Travis. Causes, impacts anddetection approaches of code smell: A survey. In: Proceedings of the ACMSE 2018Conference. USA: ACM, 2018. p. 1-8. DOI 10.1145/3190645.3190697.
JAZAYERI, Mehdi. Some trends in Web application development. Future ofSoftware Engineering. USA: IEEE, 2007. p. 199-213. DOI 10.1109/FOSE.2007.26.
KAMEI, Fernando; PINTO, Gustavo; WIESE, Igor; RIBEIRO, Márcio; SOARES,Sérgio. What evidence we would miss if we do not use grey literature? In:ACM/IEEE International Symposium on Empirical Software Engineering andMeasurement, 15., 2021. Proceedings [...] USA: ACM, 2021. DOI10.1145/3475716.3475777.
KAMEI, Fernando; WIESE, Igor; LIMA, Crescencio; POLATO, Ivanilton;NEPOMUCENO, Vilmar; FERREIRA, Waldemar; RIBEIRO, Marcio; PENA, Caroline;CARTAXO, Bruno; PINTO, Gustavo; SOARES, Sérgio. Grey literature in SoftwareEngineering: A critical review. Information and Software Technology, v. 138, Oct.2021. DOI 10.1016/j.infsof.2021.106609.
KAUR, Amandeep. A systematic literature review on empirical analysis of therelationship between code smells and software quality attributes. Archives ofComputational Methods in Engineering, v. 27, p. 1267-1296, Sep. 2020.
KITCHENHAM, Barbara; CHARTERS, Stuart. Guidelines for performingsystematic literature reviews in Software Engineering: Version 2.3. UnitedKingdom: Keele University/University of Durham, 2007.
KITCHENHAM, Barbara; BUDGEN, David; BRERETON, O. Pearl. Using mappingstudies as the basis for further research: a participant-observer case study.Information and Software Technology, v. 53, n. 6, p. 638-651, Jun. 2011. DOI10.1016/j.infsof.2010.12.011.
58
KITCHENHAM, Barbara Ann; BUDGEN, David; BRERETON, Pearl.Evidence-Based Software Engineering and systematic reviews. USA: Chapman andHall/CRC Press, 2016.
LACERDA, Guilherme; PETRILLO, Fabio; PIMENTA, Marcelo; GHÉHÉNEUC, YannGäel. Code smells and refactoring: A tertiary review of challenges and observations.Journal of Systems and Software, v. 167, Sep. 2020. DOI 10.1016/j.jss.2020.110610.
MÄNTYLÄ, Mika. Bad smells in software - A taxonomy and an empirical study.Master’s Thesis - Department of Computer Science and Engineering, HelsinkiUniversity of Technology, Helsinki, Finland, 2003.
MENDES, Emilia; MOSLEY, Nile; COUNSELL, Steve. Web Engineering: Anintroduction. In: MENDES, Emilia; MOSLEY, Nile (eds.) Web Engineering. Germany:Springer-Verlag Berlin Heidelberg, 2006. p. 1-27. DOI 10.1007/3-540-28218-1_1.
NGUYEN, Hung Viet; NGUYEN, Hoan Ann; NGUYEN, Tung Thanh; NGUYEN,Ann Tuan; NGUYEN, Tien N. Detection of embedded code smells in dynamic Webapplications. In: IEEE/ACM International Conference on Automated SoftwareEngineering, 27., 2012. Proceedings [...] USA: IEEE, 2012. p. 282-285. DOI10.1145/2351676.2351724.
MURUGESAN, San. Web application development: Challenges and role of WebEngineering. In: ROSSI, Gustavo; PASTOR, Oscar; SCHWABE, Daniel; OLSINA, Luis.Web Engineering: Modelling and implementing Web applications. United Kingdom:Springer-Verlag London Limited, 2008. p. 7-32. DOI 10.1007/978-1-84628-923-1_2.
MURUGESAN, San; GINGE, Athula. Web Engineering: Introduction andperspectives. In: SUH, Woojong. Web Engineering: Principles and techniques. USA:IGI Global, 2004. p. 1-30. DOI 10.4018/978-1-59140-432-3.ch001.
OCARIZA, JR., Frolin S.; PATTABIRAMAN, Karthik. MESBAH, Ali. Detectingunknown inconsistencies in Web applications. In: IEEE/ACM InternationalConference on Automated Software Engineering, 32., 2017. Proceedings [...] USA:IEEE, 2017. p. 566–577. DOI 10.1109/ASE.2017.8115667.
PAULO SOBRINHO, Elder Vicente de; DE LUCIA, Andrea; MAIA, Marcelo deAlmeida. A systematic literature review on bad smells - 5W 's: which, when, what,who, where. IEEE Transactions on Software Engineering, v. 47, n. 1, p. 17-66, Jan.2021. DOI 10.1109/TSE.2018.2880977.
PETERSEN, Kai; FELDT, Robert; MUJTABA, Shahid; MATTSSON, Michael.Systematic mapping studies in Software Engineering. In: International Conference onEvaluation and Assessment in Software Engineering, 12., 2008. Proceedings […]United Kingdom: British Computer Society, 2008. p. 68-77.
PUNT, Leonard; VISSCHER, Sjoerd; ZAYTSEV, Vadim. The A?B*A Pattern: Undoingstyle in CSS and refactoring opportunities it presents. In: International Conference on
59
Software Maintenance and Evolution, 32., 2016. Proceedings [...] USA: IEEE, 2016. p.67-77. DOI 10.1109/ICSME.2016.73.
RIO, Américo; BRITO E ABREU, Fernando. Analyzing Web applications qualityevolution. In: Iberian Conference on Information Systems and Technologies, 12., 2017.Proceedings [...] USA: IEEE, 2017. DOI 10.23919/CISTI.2017.7975959.
RIO, Américo; BRITO E ABREU, Fernando. Code smells survival analysis in Webapps. In: PIATTINI, Mario; CUNHA, Paulo Rupino da; DE GUZMÁN, Ignacio GarcíaRodríguez; PÉREZ-CASTILLO, Ricardo (eds.) Quality of Information andCommunications Technology. Switzerland: Springer Nature Switzerland AG, 2019.p. 263-271 (Communications in Computer and Information Science, v. 1010) DOI10.1007/978-3-030-29238-6_19.
SABIR, Fatima; PALMA, Francis; RASOOL, Ghulam; GUÉHÉNEUC, Yann-Gäel;MOHA, Naouel. A systematic literature review on the detection of smells and theirevolution in object-oriented and service-oriented systems. Software: Practice andExperience, v. 49, n. 1, p. 3-39, Jan. 2019. DOI 10.1002/spe.2639.
SABOURY, Amir; MUSAVI, Pooya; KHOMH, Foutse; ANTONIOL, Giulio. Anempirical study of code smells in JavaScript projects. In: International Conference onSoftware Analysis, Evolution and Reengineering, 24., 2017. Proceedings [...] USA:IEEE, 2017. p. 294-305. DOI 10.1109/SANER.2017.7884630.
SANTOS, José Amâncio M.; ROCHA-JUNIOR, João B.; PRATES, Luciana Carla Lins;NASCIMENTO, Rogeres Santos; FREIRAS, Mydiã Falcão; MENDONÇA, ManoelGomes. A systematic review on the code smell effect. Journal of Systems andSoftware, v. 144, p. 450-477, Oct. 2018. DOI 10.1016/j.jss.2018.07.035.
SHADISH, William R.; COOK, Thomas D.; CAMPBELL, Donald T. Experimental andquasi-experimental designs for generalized causal inference. 2. ed. USA: HoughtonMifflin, 2001.
SHAO, Shudi; QIU, Zhengyi; YU, Xiao; YANG, Wei; JIN, Guoliang; XIE, Tao; WU,Xintao. Database-access performance antipatterns in database-backed Webapplications. In: IEEE International Conference on Software Maintenance andEvolution, 2020. Proceedings [...] USA: IEEE, 2020. p. 58-69. DOI10.1109/ICSME46990.2020.00016.
SHARMA, Tushar; SPINELLIS, Diomidis. A survey on software smells. Journal ofSystems and Software, v. 138, p. 158-173, Apr. 2018. DOI 10.1016/j.jss.2017.12.034.
SINGH, Satwinder; KAUR, Sharanpreet. A systematic literature review: Refactoringfor disclosing code smells in object oriented software. Ain Shams EngineeringJournal, v. 9, n. 4, p. 2129-2151, Dec. 2018. DOI 10.1016/j.asej.2017.03.002.
VALE, Gustavo; FIGUEIREDO, Eduardo; ABÍLIO, Ramon; COSTA, Heitor. Badsmells in software product lines: A systematic review. In: Brazilian Symposium on
60
Software Components, Architectures and Reuse, 8. 2014. Proceedings [...] USA: IEEE,2014. p. 84-94. DOI 10.1109/SBCARS.2014.21.
ZHANG, Min; HALL, Tracy; BADDOO, Nathan. Code bad smells: A review ofcurrent knowledge. Journal of Software Maintenance and Evolution: Research andPractice, v. 23, n. 3, p. 179-202, Apr. 2011. DOI 10.1002/smr.521.
WOHLIN, Claes. Guidelines for snowballing in systematic literature studies and areplication in Software Engineering. In: International Conference on Evaluation andAssessment in Software Engineering, 18., 2014. Proceedings [...] USA: ACM, 2014.DOI 10.1145/2601248.2601268.
WOHLIN, Claes; HÖST, Martin; OHLSSON, Magnus C.; REGNELL, Björn;WESSLÉN, Anders. Experimentation in Software Engineering. Germany: Springer-Verlag Berlin Heidelberg, 2012. DOI 10.1007/978-3-642-29044-2.
61
Apêndice A – Adaptações da string de buscaA.1 ACM Digital Library
No mecanismo de busca avançada (Advanced Search) da ACM Digital Library,a string de busca considerou os identificadores Title, Abstract e Keyword, os quais sereferem respectivamente ao título, resumo e palavras-chave dos estudos a serembuscados, resultando na seguinte string de busca, a qual foi aplicada no campoAnywhere:
Title: (("code smell" OR "code smells" OR "bad smell" OR "bad smells" OR "codebad smell" OR "code anomaly" OR "code anomalies" OR "antipattern" OR
"antipatterns" OR "anti-pattern" OR "anti-patterns") AND ("web application" OR"web applications")) OR Abstract:(("code smell" OR "code smells" OR "bad smell"
OR "bad smells" OR "code bad smell" OR "code anomaly" OR "code anomalies" OR"antipattern" OR "antipatterns" OR "anti-pattern" OR "anti-patterns") AND ("web
application" OR "web applications")) OR Keyword:(("code smell" OR "code smells"OR "bad smell" OR "bad smells" OR "code bad smell" OR "code anomaly" OR "code
anomalies" OR "antipattern" OR "antipatterns" OR "anti-pattern" OR"anti-patterns") AND ("web application" OR "web applications"))
A.2 IEEEXploreNo mecanismo de busca avançada (Advanced Search) da IEEEXplore, a string
base de busca apresentada na Seção 4.1 foi utilizada na íntegra, sendo aplicada aoscampos Document Title, Abstract e Author Keywords, os quais se referemrespectivamente ao título, resumo e palavras-chave dos estudos a serem buscados,sendo feita uma disjunção entre esses campos utilizando o operador lógico OR.
A.3 ScopusO mecanismo de busca da Scopus realiza, por padrão, buscas por título,
resumo e palavras-chave dos estudos disponíveis na base. Assim sendo, não foi feitaqualquer tipo de adaptação na string base de busca apresentada na Seção 4.1.
A.4 ScienceDirectNo mecanismo de busca avançada (Advanced search) da ScienceDirect, há a
opção de se realizar a busca considerando título, resumo e palavras-chave dosestudos. No entanto, essa base eletrônica possui a limitação de não aceitar mais queoito conectores lógicos. Em razão disso, a string base de busca apresentada na Seção4.1 foi particionada em duas strings menores, os resultados de ambas sendo emseguida combinados (somados):.
62
("code smell" OR "code smells" OR "bad smell" OR "bad smells" OR "code badsmell" OR "code anomaly" OR "code anomalies") AND ("web application" OR "web
applications")
("antipattern" OR "antipatterns" OR "anti-pattern" OR "anti-patterns") AND ("webapplication" OR "web applications")
A.5 Web of ScienceO mecanismo de busca da Web of Science oferece a possibilidade de realizar a
uma busca por tópico, o que, de acordo com a documentação dessa base eletrônica,equivale a uma busca por título, resumo e palavras-chave dos estudos disponíveis nabase. Assim sendo, foi aplicada ao campo Topic a string base de busca (ver Seção 4.1)na íntegra.
