Submitted by PGCOMP UFBA (pgcomp@ufba.br) on 2016-10-27T17:09:13Z No. of bitstreams: 1 PGCOMP-MSC03-ElienaiBitencourt.pdf: 1427996 bytes, checksum: 750d8f268e5cfc27f56aa6e6bd22fd2c (MD5) / Approved for entry into archive by Vanessa Reis (vanessa.jamile@ufba.br) on 2016-11-03T14:26:41Z (GMT) No. of bitstreams: 1 PGCOMP-MSC03-ElienaiBitencourt.pdf: 1427996 bytes, checksum: 750d8f268e5cfc27f56aa6e6bd22fd2c (MD5) / Made available in DSpace on 2016-11-03T14:26:41Z (GMT). No. of bitstreams: 1 PGCOMP-MSC03-ElienaiBitencourt.pdf: 1427996 bytes, checksum: 750d8f268e5cfc27f56aa6e6bd22fd2c (MD5) / Fapesb / Coesão pode ser de nida como o grau pelo qual um m odulo de um software está focado na realiza ção de uma unica responsabilidade. Acredita-se que a coesão pode interferir em atributos de qualidade de software, tais como, manutenibilidade e facilidade de compreensão. Em particular, a literatura de engenharia de software afi rma que quanto maior for a coesão, mais f acil ser a para se compreender o c odigo fonte de um m odulo. Pesquisadores têm de nido uma s erie de m etricas para quantifi car coesão. No entanto, faltam evidencias experimentais sobre a existencia de uma rela ção entre coesão, quanti ficada por meio de m étricas, e o esfor ço para se compreender programas. Diante desse contexto, realizamos três quase-experimentos para avaliar a rela ção entre medidas de coesão e o esfor ço para se compreender o c ódigo fonte de classes de sistemas orientados a objetos. Al ém disso, avaliamos se dois diferentes tipos de m etricas -- estrutural e conceitual -- apresentam rela ção diferente com o esfor ço de compreensão. Nesses experimentos, participantes executaram atividades que demandaram a compreensão do c odigo fonte de diferentes classes com diferentes graus de coesão. Os resultados mostraram que a coesão não teve impacto na compreensibilidade de programas. Isso ocorreu principalmente porque a influência muito mais forte de outros atributos do c odigo fonte acaba minimizando a influência da coesão.

Submitted by Maria Medeiros (maria.dilva1@ufcg.edu.br) on 2018-05-18T11:37:53Z No. of bitstreams: 1 NORMANDO GOMES DE CARVALHO JÚNIOR - DISSERTAÇÃO (PPGCC) 2017.pdf: 835253 bytes, checksum: 37804bf340b68162490c02e52c346fe8 (MD5) / Made available in DSpace on 2018-05-18T11:37:53Z (GMT). No. of bitstreams: 1 NORMANDO GOMES DE CARVALHO JÚNIOR - DISSERTAÇÃO (PPGCC) 2017.pdf: 835253 bytes, checksum: 37804bf340b68162490c02e52c346fe8 (MD5) Previous issue date: 2017 / CNPq / Compreender programas é difícil porque cada trecho de código atende requisitos específicos. Em alguns casos, fatores como compreender programas que foram escritos por outras pessoas, o escopo limitado das ferramentas existentes, e a falta de documentação adicionam complexidade. Sendo assim, os desenvolvedores necessitam de uma abordagem de compreensão efetiva que diminua os custos na manutenção e que reduzam os riscos de erros, caso o entendimento do programa seja incompleto. Existem abordagens sistemáticas, apoiadas por ferramentas, para compreensão que utilizam verificações estáticas (análise do código fonte) ou dinâmicas (dados sobre a execução). As abordagens dinâmicas são utilizadas por sua efetividade, pois basta executar um teste para ver o resultado, no entanto, falham por não utilizar informações de alto nível sobre o comportamento que possam ser verificadas. Todavia, estas informações podem ser capturadas ao definir contratos, como por exemplo, na metodologia Design by Contract. Contudo, não existe uma abordagem sistemática de compreensão que utilize contratos. Este trabalho, propõe um estudo para compreender programas apoiada por uma abordagem sistematizada a fim de priorizar a escrita de contratos em programas C# utilizando os princípios de Design by Contract por meio da biblioteca Code Contracts. Podendo, mesmo assim, ser utilizada em qualquer linguagem de programação que dê suporte a Design by Contract. A avaliação foi feita em ambientes de desenvolvimento de software com 12 desenvolvedores de um centro de pesquisa e desenvolvimento em ciência da computação, considerando a aplicação da abordagem a três métodos (rotinas) de um projeto open-source. Os resultados do estudo apontam indícios de melhor compreensão dos métodos usando contratos, e por outro lado, de favorecimento da própria escrita dos contratos em métodos,a princípio desconhecidos pelos desenvolvedores. / Program comprehension is generally a difficult task, since each part of code meets specific requirements. In some cases, factors - such as comprehend programs that were written by others, limited scope of existing tools, and lack of documentation - add complexity. There fore, developers need an effective program comprehension approach that reduces maintenance costs and the risk of errors whether the program comprehension is incomplete. In order to mitigate that problem, systematic approaches are used, supported by tools, to verify comprehension using static (source code analysis) or dynamic (data on execution). Dynamic approaches are used because of their effectiveness, since they simply run a test to see the result, however, they fail to use high-level behavioral information that can be verified. Still, this information can be captured while defining contracts, for example in the Design by Contract methodology. Nevertheless, for the best of our knowledge, there is no systematic approach to program comprehension that uses contracts. In this work, we propose a study to program comprehension supported by a systematized approach, in order to prioritize the writing of contracts in C# programs using the principles of Design by Contract through the Code Contracts library. It can still be used in any programming language that supports Design by Contract. We evaluated it in software development environments with 12 developers of a research and development center in computer science, considering the approach application to three methods (routines) of an open-source project. The results of our study indicate better comprehension of methods using contracts, and, on the other hand, favoring the writing of contracts in methods, initially unknown to developers.