Build and test conflicts in the wild
Autor(a) principal: | |
---|---|
Data de Publicação: | 2018 |
Tipo de documento: | Dissertação |
Idioma: | eng |
Título da fonte: | Repositório Institucional da UFPE |
dARK ID: | ark:/64986/0013000009nq1 |
Texto Completo: | https://repositorio.ufpe.br/handle/123456789/29991 |
Resumo: | Collaborative software development allows developers to simultaneously contribute to the same project performing different activities. Although this might increase development productivity, it also brings conflicts among developers contributions. Conflicts may arise in different development phases: during merging, when different contributions are integrated (merge conflicts); after integration, when building the integration results fail (build conflicts); or when testing, unexpected software behavior happens (test conflicts). To understand how different contributions from merge scenarios influence build and test conflicts occurrence, in this thesis we investigate the frequency, causes and adopted resolution patterns for these conflicts. We perform an empirical study evaluating merge scenarios from Java projects that use Travis CI for continuous integration and Maven as build manager. To identify conflicts, we access information from git repositories of the projects and their associated build process. Filters were applied to select merge commits that present unsuccessful build processes (caused by problems during the build creation or test execution), while their parent commits have successful build process. Besides parsing build logs for identifying the causes behind the broken builds, we also parse the source code to establish interference between contributions. Different from previous studies, we also evaluate scenarios that caused merge conflicts fixed by integrators, leading us to classify our results based on contributor and integrator changes to fix the conflicts. Although the number of build conflicts caused by contributor changes is high (66,4%), we have evidence that build conflicts can also be caused by changes performed after the integration by integrators (33,6%). The most recurrent causes of build conflicts concentrate on static semantic problems (80%), especially Unavailable Symbol (52,8% of all build conflicts that represents the attempt to use a symbol no longer available in the project). Test conflicts are caused by failed test cases, that are not restricted to old tests but also new or updated during the merge scenario. Additional analysis performed after tests execution can also cause test conflicts. Related to the adopted resolution patterns, build and test conflicts were fixed without returning to an old project version. Typically, parent commits authors are also responsible for fixing build and test conflicts. Our findings bring the evidence of build and test conflicts showing they occur independent of merge conflict occurrence during integration. For build conflicts, we define a catalog of causes that can be applied to assistive tools on software development aiming to avoid or treat such problems. For test conflicts, our scripts can be used to develop an assistive tool to developers when trying to understand the test case failure since we filter the parent’s contributions informing only those parts involved in the test failure. |
id |
UFPE_e727794c4597a50dee1d58c813ae339a |
---|---|
oai_identifier_str |
oai:repositorio.ufpe.br:123456789/29991 |
network_acronym_str |
UFPE |
network_name_str |
Repositório Institucional da UFPE |
repository_id_str |
2221 |
spelling |
SILVA, Léuson Mário Pedro dahttp://lattes.cnpq.br/8681457281512244http://lattes.cnpq.br/9395715443254344BORBA, Paulo Henrique Monteiro2019-04-02T20:44:48Z2019-04-02T20:44:48Z2018-02-19https://repositorio.ufpe.br/handle/123456789/29991ark:/64986/0013000009nq1Collaborative software development allows developers to simultaneously contribute to the same project performing different activities. Although this might increase development productivity, it also brings conflicts among developers contributions. Conflicts may arise in different development phases: during merging, when different contributions are integrated (merge conflicts); after integration, when building the integration results fail (build conflicts); or when testing, unexpected software behavior happens (test conflicts). To understand how different contributions from merge scenarios influence build and test conflicts occurrence, in this thesis we investigate the frequency, causes and adopted resolution patterns for these conflicts. We perform an empirical study evaluating merge scenarios from Java projects that use Travis CI for continuous integration and Maven as build manager. To identify conflicts, we access information from git repositories of the projects and their associated build process. Filters were applied to select merge commits that present unsuccessful build processes (caused by problems during the build creation or test execution), while their parent commits have successful build process. Besides parsing build logs for identifying the causes behind the broken builds, we also parse the source code to establish interference between contributions. Different from previous studies, we also evaluate scenarios that caused merge conflicts fixed by integrators, leading us to classify our results based on contributor and integrator changes to fix the conflicts. Although the number of build conflicts caused by contributor changes is high (66,4%), we have evidence that build conflicts can also be caused by changes performed after the integration by integrators (33,6%). The most recurrent causes of build conflicts concentrate on static semantic problems (80%), especially Unavailable Symbol (52,8% of all build conflicts that represents the attempt to use a symbol no longer available in the project). Test conflicts are caused by failed test cases, that are not restricted to old tests but also new or updated during the merge scenario. Additional analysis performed after tests execution can also cause test conflicts. Related to the adopted resolution patterns, build and test conflicts were fixed without returning to an old project version. Typically, parent commits authors are also responsible for fixing build and test conflicts. Our findings bring the evidence of build and test conflicts showing they occur independent of merge conflict occurrence during integration. For build conflicts, we define a catalog of causes that can be applied to assistive tools on software development aiming to avoid or treat such problems. For test conflicts, our scripts can be used to develop an assistive tool to developers when trying to understand the test case failure since we filter the parent’s contributions informing only those parts involved in the test failure.CAPESDesenvolvimento colaborativo de software permite que desenvolvedores contribuam simultaneamente para um mesmo projeto realizando diferentes atividades. Embora esta abordagem possa aumentar a produtividade de desenvolvimento, ela também traz consigo conflitos entre contribuições de desenvolvedores. Conflitos podem surgir em diferentes momentos. Durante cenários de merge, quando contribuições diferentes são integradas (conflitos de merge), como também após a integração, durante a tentativa de realizar o processo de build, quando este processo falha devido o resultado da integração falha (conflitos de build), ou mudança no comportamento do software (conflitos de teste). Para entender como contribuições diferentes de cenários de merge influenciam em conflitos de build e teste, nesta dissertação nós investigamos a frequência, causas e padrões de resolução adotados para resolver estes conflitos. Para tanto, nós realizamos um estudo empírico avaliando cenários de merge de projetos Java usando Travis (para integração contínua) e Maven (como gerenciador de build). Para identificar conflitos, nós acessamos as informações de repositórios git como também seus processos de build associados. Sucessivos filtros foram aplicados para selecionar commits de merge que apresentavam processos de build malsucedidos (causadas por problemas durante a criação da build ou execução dos testes), enquanto seus commits pais apresentavam processos bem-sucedidos. Além de analisar os logs das builds para extrair as causas das quebras, nós também avaliamos o código-fonte para identificar as interferências entre contribuições. Diferente de estudos anteriores, nós também avaliamos a ocorrência de conflitos em cenários oriundos de conflitos de merge levando-nos a classificar nossos resultados baseados nas mudanças dos contribuidores e integradores. Embora o número de conflitos de build causados por mudanças dos contribuidores seja alto (66,4%), nós temos evidência que conflitos de build também podem ser causados por mudanças feitas após a integração por integradores (33,6%). As causas mais recorrentes de conflitos de build concentram-se em problemas estáticos semânticos, especialmente Símbolo Indisponível (52,8% de todos os conflitos de build representando a tentativa de usar um símbolo indisponível no projeto). Conflitos de teste são causados por casos de teste falhos, que não são restritos a casos de teste antigos como também novos ou atualizados durante o cenário de merge. Análises adicionais realizadas após a execução de testes também causar conflitos de teste. Em relação aos padrões de resolução de conflitos, a solução mais utilizada consiste em adaptar as causas dos conflitos ao novo estado do projeto, ao invés de retornar para um estado antigo. Tipicamente, desenvolvedores autores pelos commits pais, também são responsáveis por resolver os conflitos. Nossas descobertas trazem a evidência de conflitos de build e teste mostrando que estes ocorrem independentes de conflitos de merge durante a integração. Em relação aos conflitos de build, nós identificamos um catálogo de causas que pode ser aplicado em ferramentas de suporte ao desenvolvimento de software evitando ou tratando estes problemas. Para conflitos de teste, nossos scripts podem apoiar o trabalho de desenvolvedores durante a tentativa de entender a falha de um caso de teste, uma vez que nós filtramos as contribuições dos commits pais informando apenas aquelas envolvidas na falha do teste.engUniversidade Federal de PernambucoPrograma de Pos Graduacao em Ciencia da ComputacaoUFPEBrasilAttribution-NonCommercial-NoDerivs 3.0 Brazilhttp://creativecommons.org/licenses/by-nc-nd/3.0/br/info:eu-repo/semantics/openAccessEngenharia de softwareConflitos de testeBuild and test conflicts in the wildinfo:eu-repo/semantics/publishedVersioninfo:eu-repo/semantics/masterThesismestradoreponame:Repositório Institucional da UFPEinstname:Universidade Federal de Pernambuco (UFPE)instacron:UFPETHUMBNAILDISSERTAÇÃO Léuson Mário Pedro da Silva.pdf.jpgDISSERTAÇÃO Léuson Mário Pedro da Silva.pdf.jpgGenerated Thumbnailimage/jpeg1224https://repositorio.ufpe.br/bitstream/123456789/29991/5/DISSERTA%c3%87%c3%83O%20L%c3%a9uson%20M%c3%a1rio%20Pedro%20da%20Silva.pdf.jpgd5161a405436d1a17222a75cdd290171MD55ORIGINALDISSERTAÇÃO Léuson Mário Pedro da Silva.pdfDISSERTAÇÃO Léuson Mário Pedro da Silva.pdfapplication/pdf2981762https://repositorio.ufpe.br/bitstream/123456789/29991/1/DISSERTA%c3%87%c3%83O%20L%c3%a9uson%20M%c3%a1rio%20Pedro%20da%20Silva.pdf7eaeac06c5141a9ae2d3da4e3b6427b7MD51CC-LICENSElicense_rdflicense_rdfapplication/rdf+xml; charset=utf-8811https://repositorio.ufpe.br/bitstream/123456789/29991/2/license_rdfe39d27027a6cc9cb039ad269a5db8e34MD52LICENSElicense.txtlicense.txttext/plain; charset=utf-82311https://repositorio.ufpe.br/bitstream/123456789/29991/3/license.txt4b8a02c7f2818eaf00dcf2260dd5eb08MD53TEXTDISSERTAÇÃO Léuson Mário Pedro da Silva.pdf.txtDISSERTAÇÃO Léuson Mário Pedro da Silva.pdf.txtExtracted texttext/plain255241https://repositorio.ufpe.br/bitstream/123456789/29991/4/DISSERTA%c3%87%c3%83O%20L%c3%a9uson%20M%c3%a1rio%20Pedro%20da%20Silva.pdf.txt314e8557a77d1538aac6751b1fdd6172MD54123456789/299912019-10-26 00:53:31.283oai:repositorio.ufpe.br:123456789/29991TGljZW7Dp2EgZGUgRGlzdHJpYnVpw6fDo28gTsOjbyBFeGNsdXNpdmEKClRvZG8gZGVwb3NpdGFudGUgZGUgbWF0ZXJpYWwgbm8gUmVwb3NpdMOzcmlvIEluc3RpdHVjaW9uYWwgKFJJKSBkZXZlIGNvbmNlZGVyLCDDoCBVbml2ZXJzaWRhZGUgRmVkZXJhbCBkZSBQZXJuYW1idWNvIChVRlBFKSwgdW1hIExpY2Vuw6dhIGRlIERpc3RyaWJ1acOnw6NvIE7Do28gRXhjbHVzaXZhIHBhcmEgbWFudGVyIGUgdG9ybmFyIGFjZXNzw612ZWlzIG9zIHNldXMgZG9jdW1lbnRvcywgZW0gZm9ybWF0byBkaWdpdGFsLCBuZXN0ZSByZXBvc2l0w7NyaW8uCgpDb20gYSBjb25jZXNzw6NvIGRlc3RhIGxpY2Vuw6dhIG7Do28gZXhjbHVzaXZhLCBvIGRlcG9zaXRhbnRlIG1hbnTDqW0gdG9kb3Mgb3MgZGlyZWl0b3MgZGUgYXV0b3IuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKTGljZW7Dp2EgZGUgRGlzdHJpYnVpw6fDo28gTsOjbyBFeGNsdXNpdmEKCkFvIGNvbmNvcmRhciBjb20gZXN0YSBsaWNlbsOnYSBlIGFjZWl0w6EtbGEsIHZvY8OqIChhdXRvciBvdSBkZXRlbnRvciBkb3MgZGlyZWl0b3MgYXV0b3JhaXMpOgoKYSkgRGVjbGFyYSBxdWUgY29uaGVjZSBhIHBvbMOtdGljYSBkZSBjb3B5cmlnaHQgZGEgZWRpdG9yYSBkbyBzZXUgZG9jdW1lbnRvOwpiKSBEZWNsYXJhIHF1ZSBjb25oZWNlIGUgYWNlaXRhIGFzIERpcmV0cml6ZXMgcGFyYSBvIFJlcG9zaXTDs3JpbyBJbnN0aXR1Y2lvbmFsIGRhIFVGUEU7CmMpIENvbmNlZGUgw6AgVUZQRSBvIGRpcmVpdG8gbsOjbyBleGNsdXNpdm8gZGUgYXJxdWl2YXIsIHJlcHJvZHV6aXIsIGNvbnZlcnRlciAoY29tbyBkZWZpbmlkbyBhIHNlZ3VpciksIGNvbXVuaWNhciBlL291IGRpc3RyaWJ1aXIsIG5vIFJJLCBvIGRvY3VtZW50byBlbnRyZWd1ZSAoaW5jbHVpbmRvIG8gcmVzdW1vL2Fic3RyYWN0KSBlbSBmb3JtYXRvIGRpZ2l0YWwgb3UgcG9yIG91dHJvIG1laW87CmQpIERlY2xhcmEgcXVlIGF1dG9yaXphIGEgVUZQRSBhIGFycXVpdmFyIG1haXMgZGUgdW1hIGPDs3BpYSBkZXN0ZSBkb2N1bWVudG8gZSBjb252ZXJ0w6otbG8sIHNlbSBhbHRlcmFyIG8gc2V1IGNvbnRlw7pkbywgcGFyYSBxdWFscXVlciBmb3JtYXRvIGRlIGZpY2hlaXJvLCBtZWlvIG91IHN1cG9ydGUsIHBhcmEgZWZlaXRvcyBkZSBzZWd1cmFuw6dhLCBwcmVzZXJ2YcOnw6NvIChiYWNrdXApIGUgYWNlc3NvOwplKSBEZWNsYXJhIHF1ZSBvIGRvY3VtZW50byBzdWJtZXRpZG8gw6kgbyBzZXUgdHJhYmFsaG8gb3JpZ2luYWwgZSBxdWUgZGV0w6ltIG8gZGlyZWl0byBkZSBjb25jZWRlciBhIHRlcmNlaXJvcyBvcyBkaXJlaXRvcyBjb250aWRvcyBuZXN0YSBsaWNlbsOnYS4gRGVjbGFyYSB0YW1iw6ltIHF1ZSBhIGVudHJlZ2EgZG8gZG9jdW1lbnRvIG7Do28gaW5mcmluZ2Ugb3MgZGlyZWl0b3MgZGUgb3V0cmEgcGVzc29hIG91IGVudGlkYWRlOwpmKSBEZWNsYXJhIHF1ZSwgbm8gY2FzbyBkbyBkb2N1bWVudG8gc3VibWV0aWRvIGNvbnRlciBtYXRlcmlhbCBkbyBxdWFsIG7Do28gZGV0w6ltIG9zIGRpcmVpdG9zIGRlCmF1dG9yLCBvYnRldmUgYSBhdXRvcml6YcOnw6NvIGlycmVzdHJpdGEgZG8gcmVzcGVjdGl2byBkZXRlbnRvciBkZXNzZXMgZGlyZWl0b3MgcGFyYSBjZWRlciDDoApVRlBFIG9zIGRpcmVpdG9zIHJlcXVlcmlkb3MgcG9yIGVzdGEgTGljZW7Dp2EgZSBhdXRvcml6YXIgYSB1bml2ZXJzaWRhZGUgYSB1dGlsaXrDoS1sb3MgbGVnYWxtZW50ZS4gRGVjbGFyYSB0YW1iw6ltIHF1ZSBlc3NlIG1hdGVyaWFsIGN1am9zIGRpcmVpdG9zIHPDo28gZGUgdGVyY2Vpcm9zIGVzdMOhIGNsYXJhbWVudGUgaWRlbnRpZmljYWRvIGUgcmVjb25oZWNpZG8gbm8gdGV4dG8gb3UgY29udGXDumRvIGRvIGRvY3VtZW50byBlbnRyZWd1ZTsKZykgU2UgbyBkb2N1bWVudG8gZW50cmVndWUgw6kgYmFzZWFkbyBlbSB0cmFiYWxobyBmaW5hbmNpYWRvIG91IGFwb2lhZG8gcG9yIG91dHJhIGluc3RpdHVpw6fDo28gcXVlIG7Do28gYSBVRlBFLMKgZGVjbGFyYSBxdWUgY3VtcHJpdSBxdWFpc3F1ZXIgb2JyaWdhw6fDtWVzIGV4aWdpZGFzIHBlbG8gcmVzcGVjdGl2byBjb250cmF0byBvdSBhY29yZG8uCgpBIFVGUEUgaWRlbnRpZmljYXLDoSBjbGFyYW1lbnRlIG8ocykgbm9tZShzKSBkbyhzKSBhdXRvciAoZXMpIGRvcyBkaXJlaXRvcyBkbyBkb2N1bWVudG8gZW50cmVndWUgZSBuw6NvIGZhcsOhIHF1YWxxdWVyIGFsdGVyYcOnw6NvLCBwYXJhIGFsw6ltIGRvIHByZXZpc3RvIG5hIGFsw61uZWEgYykuCg==Repositório InstitucionalPUBhttps://repositorio.ufpe.br/oai/requestattena@ufpe.bropendoar:22212019-10-26T03:53:31Repositório Institucional da UFPE - Universidade Federal de Pernambuco (UFPE)false |
dc.title.pt_BR.fl_str_mv |
Build and test conflicts in the wild |
title |
Build and test conflicts in the wild |
spellingShingle |
Build and test conflicts in the wild SILVA, Léuson Mário Pedro da Engenharia de software Conflitos de teste |
title_short |
Build and test conflicts in the wild |
title_full |
Build and test conflicts in the wild |
title_fullStr |
Build and test conflicts in the wild |
title_full_unstemmed |
Build and test conflicts in the wild |
title_sort |
Build and test conflicts in the wild |
author |
SILVA, Léuson Mário Pedro da |
author_facet |
SILVA, Léuson Mário Pedro da |
author_role |
author |
dc.contributor.authorLattes.pt_BR.fl_str_mv |
http://lattes.cnpq.br/8681457281512244 |
dc.contributor.advisorLattes.pt_BR.fl_str_mv |
http://lattes.cnpq.br/9395715443254344 |
dc.contributor.author.fl_str_mv |
SILVA, Léuson Mário Pedro da |
dc.contributor.advisor1.fl_str_mv |
BORBA, Paulo Henrique Monteiro |
contributor_str_mv |
BORBA, Paulo Henrique Monteiro |
dc.subject.por.fl_str_mv |
Engenharia de software Conflitos de teste |
topic |
Engenharia de software Conflitos de teste |
description |
Collaborative software development allows developers to simultaneously contribute to the same project performing different activities. Although this might increase development productivity, it also brings conflicts among developers contributions. Conflicts may arise in different development phases: during merging, when different contributions are integrated (merge conflicts); after integration, when building the integration results fail (build conflicts); or when testing, unexpected software behavior happens (test conflicts). To understand how different contributions from merge scenarios influence build and test conflicts occurrence, in this thesis we investigate the frequency, causes and adopted resolution patterns for these conflicts. We perform an empirical study evaluating merge scenarios from Java projects that use Travis CI for continuous integration and Maven as build manager. To identify conflicts, we access information from git repositories of the projects and their associated build process. Filters were applied to select merge commits that present unsuccessful build processes (caused by problems during the build creation or test execution), while their parent commits have successful build process. Besides parsing build logs for identifying the causes behind the broken builds, we also parse the source code to establish interference between contributions. Different from previous studies, we also evaluate scenarios that caused merge conflicts fixed by integrators, leading us to classify our results based on contributor and integrator changes to fix the conflicts. Although the number of build conflicts caused by contributor changes is high (66,4%), we have evidence that build conflicts can also be caused by changes performed after the integration by integrators (33,6%). The most recurrent causes of build conflicts concentrate on static semantic problems (80%), especially Unavailable Symbol (52,8% of all build conflicts that represents the attempt to use a symbol no longer available in the project). Test conflicts are caused by failed test cases, that are not restricted to old tests but also new or updated during the merge scenario. Additional analysis performed after tests execution can also cause test conflicts. Related to the adopted resolution patterns, build and test conflicts were fixed without returning to an old project version. Typically, parent commits authors are also responsible for fixing build and test conflicts. Our findings bring the evidence of build and test conflicts showing they occur independent of merge conflict occurrence during integration. For build conflicts, we define a catalog of causes that can be applied to assistive tools on software development aiming to avoid or treat such problems. For test conflicts, our scripts can be used to develop an assistive tool to developers when trying to understand the test case failure since we filter the parent’s contributions informing only those parts involved in the test failure. |
publishDate |
2018 |
dc.date.issued.fl_str_mv |
2018-02-19 |
dc.date.accessioned.fl_str_mv |
2019-04-02T20:44:48Z |
dc.date.available.fl_str_mv |
2019-04-02T20:44:48Z |
dc.type.status.fl_str_mv |
info:eu-repo/semantics/publishedVersion |
dc.type.driver.fl_str_mv |
info:eu-repo/semantics/masterThesis |
format |
masterThesis |
status_str |
publishedVersion |
dc.identifier.uri.fl_str_mv |
https://repositorio.ufpe.br/handle/123456789/29991 |
dc.identifier.dark.fl_str_mv |
ark:/64986/0013000009nq1 |
url |
https://repositorio.ufpe.br/handle/123456789/29991 |
identifier_str_mv |
ark:/64986/0013000009nq1 |
dc.language.iso.fl_str_mv |
eng |
language |
eng |
dc.rights.driver.fl_str_mv |
Attribution-NonCommercial-NoDerivs 3.0 Brazil http://creativecommons.org/licenses/by-nc-nd/3.0/br/ info:eu-repo/semantics/openAccess |
rights_invalid_str_mv |
Attribution-NonCommercial-NoDerivs 3.0 Brazil http://creativecommons.org/licenses/by-nc-nd/3.0/br/ |
eu_rights_str_mv |
openAccess |
dc.publisher.none.fl_str_mv |
Universidade Federal de Pernambuco |
dc.publisher.program.fl_str_mv |
Programa de Pos Graduacao em Ciencia da Computacao |
dc.publisher.initials.fl_str_mv |
UFPE |
dc.publisher.country.fl_str_mv |
Brasil |
publisher.none.fl_str_mv |
Universidade Federal de Pernambuco |
dc.source.none.fl_str_mv |
reponame:Repositório Institucional da UFPE instname:Universidade Federal de Pernambuco (UFPE) instacron:UFPE |
instname_str |
Universidade Federal de Pernambuco (UFPE) |
instacron_str |
UFPE |
institution |
UFPE |
reponame_str |
Repositório Institucional da UFPE |
collection |
Repositório Institucional da UFPE |
bitstream.url.fl_str_mv |
https://repositorio.ufpe.br/bitstream/123456789/29991/5/DISSERTA%c3%87%c3%83O%20L%c3%a9uson%20M%c3%a1rio%20Pedro%20da%20Silva.pdf.jpg https://repositorio.ufpe.br/bitstream/123456789/29991/1/DISSERTA%c3%87%c3%83O%20L%c3%a9uson%20M%c3%a1rio%20Pedro%20da%20Silva.pdf https://repositorio.ufpe.br/bitstream/123456789/29991/2/license_rdf https://repositorio.ufpe.br/bitstream/123456789/29991/3/license.txt https://repositorio.ufpe.br/bitstream/123456789/29991/4/DISSERTA%c3%87%c3%83O%20L%c3%a9uson%20M%c3%a1rio%20Pedro%20da%20Silva.pdf.txt |
bitstream.checksum.fl_str_mv |
d5161a405436d1a17222a75cdd290171 7eaeac06c5141a9ae2d3da4e3b6427b7 e39d27027a6cc9cb039ad269a5db8e34 4b8a02c7f2818eaf00dcf2260dd5eb08 314e8557a77d1538aac6751b1fdd6172 |
bitstream.checksumAlgorithm.fl_str_mv |
MD5 MD5 MD5 MD5 MD5 |
repository.name.fl_str_mv |
Repositório Institucional da UFPE - Universidade Federal de Pernambuco (UFPE) |
repository.mail.fl_str_mv |
attena@ufpe.br |
_version_ |
1815172771045441536 |