Submitted by Kilvya Braga (kilvyabraga@hotmail.com) on 2018-05-17T13:52:52Z No. of bitstreams: 1 FILIPE NEVES CAVALCANTE - DISSERTAÇÃO (PPGCC) 2017.pdf: 1391449 bytes, checksum: bf8690a386cab833342c9beaf39b1211 (MD5) / Made available in DSpace on 2018-05-17T13:52:52Z (GMT). No. of bitstreams: 1 FILIPE NEVES CAVALCANTE - DISSERTAÇÃO (PPGCC) 2017.pdf: 1391449 bytes, checksum: bf8690a386cab833342c9beaf39b1211 (MD5) Previous issue date: 2017 / Java Collections Framework (JCF) oferece um conjunto de Tipos Abstratos de Dados (TADs) na linguagem Java, sendo um framework bastante utilizado. Entretanto, as particularidades de uso de cada coleção são negligenciadas em favor da praticidade, sendo muito comum, por exemplo, o uso de listas sem permitir repetições de elementos, como se fossem um TAD conjunto. Há abordagens semiautomáticas de correção desse tipo de problema, mas elas introduzem classes adaptadores ao código original, o que nem sempre é desejável. Já a Substituição Direta apenas troca uma chamada de método por outra(s) correspondente(s), realizando o mínimo de mudanças possíveis, parecendo ser uma opção melhor. Entretanto, ela é mais complexa, o que leva este trabalho a estudar as condições e consequências para que ela seja possível. Foram desenvolvidas transformações implementadas num ambiente de reescrita de programas, sendo estas testadas e analisadas por meio de um estudo de caso, a fim de verificar sua aplicabilidade, e também através de questionário destinado a programadores Java, que analisou a aceitabilidade das transformações em dois trechos de código. Como resultados do estudo de caso,tem-se a ocorrência de14% de projetos fazendo uso de listas atuando como conjuntos. E a ArrayList apresentou maior incidência (90%) já List ocorreu nos demais casos (10%). Em se tratando das avaliações realizadas pelos desenvolvedores Java no questionário, cerca de 45% dos participantes propuseram sugestões consideradas adequadas, de acordo com a API e JCF [1], para um trecho de código que utilizava o método add(E e) de List, e 25% deles para outro trecho que realizava uma chamada do método set(int index, E e). Com isso, percebe-se a relevância do problema, sendo necessário continuar desenvolvendo novas técnicas e ferramentas que façam um programa utilizar coleções de forma adequada, tornando-o mais legível e eficiente. / Java Collections Framework (JCF) offers a set of Abstract Data Types (ADTs) in the Java language, being a widely used framework. However, because particularities of each collection the usage are neglected in favor of practicality, beingvery common,for example, the use of lists without allowing repetitions of elements, as if they were a set ADT. There are semiautomatic approaches to correct this type of problem, but they insert adaptive classes to the original code, which is not always desirable. Direct substitution, however, only exchanges a method call for another(s) corresponding(s), making as few changes as possible, appearing to be a better option. However, it is more complex ,which leads this work to study the conditions and consequences to make it possible. It was developed transformations implemented in a program rewriting environment, which were tested and analyzed through a case study, anend to verify its application, and also through a questionnaire aimed at Java programmers, which analyzed the acceptability of transformations in two sections of code. Asacasestudy results, there is an occurrence of 14% of the works that make use of lists acting as sets. And an ArrayList presented higher incidence (90%) and List itself cases (10%). Regarding the revisions made by the Java developers in the questionnaire, about 45% of the participants proposed suggestions considered appropriate, according to an API and JCF [1], for a section of code that used the add (E e) method of List , And 25% of them for another section that performed a call of the method set (int index, E and). With this, we can see the relevance of the problem, being necessary to continue to develop new techniques and tools that will make a program using collection properly, making it more readable and efficient .

Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-04-16T18:53:29Z No. of bitstreams: 1 MIKAELA ANUSKA OLIVEIRA MAIA - DISSERTAÇÃO PPGCC 2014..pdf: 1160102 bytes, checksum: 5eb99698589be1aeca83623ca4b79e2f (MD5) / Made available in DSpace on 2018-04-16T18:53:29Z (GMT). No. of bitstreams: 1 MIKAELA ANUSKA OLIVEIRA MAIA - DISSERTAÇÃO PPGCC 2014..pdf: 1160102 bytes, checksum: 5eb99698589be1aeca83623ca4b79e2f (MD5) Previous issue date: 2014-08 / Apesar da diversidade que a API do Java Collections Framework(JCF) provê, com uma variedade de implementações para várias estruturas de dados, os desenvolvedores podem escolher interfaces ou classes inadequadas, em termos de eficiência ou propósito. Isto pode acontecer devido à documentação da API ser insuficiente ou a falta de análise ponderada pelo desenvolvedor de acordo com exigências do contexto. É possível a substituição manual, em paralelo com uma análise do contexto do programa. No entanto, isso é cansativo e suscetível a erros,desestimulando a modificação. Neste trabalho, nós definimos uma abordagem semi-automática para a seleção de interfaces e implementações dentro do JCF e a modificação de clientes do JCF, com base em técnicas de migração de API. A abordagem ajuda o usuário a escolher a coleção mais apropriada, com base em requisitos coletados por meio de perguntas mais intuitivas para o usuário. A seleção é resolvida com uma árvore de decisão que, a partir das respostas dadas pelo desenvolvedor, decide qual é a interface e implementação mais adequada do JCF. Após esta decisão, a modificação do programa é realizado por meio de adaptadores, minimizando a modificação do código fonte. Nós avaliamos a abordagem, implementada em uma ferramenta de apoio, com um estudo experimental que compreende estudantes de Ciência da Computação distribuídos aleatoriamente em grupos, os quais realizaram mudanças para clientes do JCF por diferentes métodos: manualmente, utilizando-se do EclipseJavaSearch e nossa abordagem. Os resultados foram avaliados na qualidade, esforço e tempo gasto. Descobrimos que a maioria dos usuários teve dificuldades em escolher a interface ou implementação apropriada para os requisitos apresentados. Nossa abordagem evidenciou uma melhora no esforço de selecionar a melhor coleção para a exigência, poupando algum tempo no processo. Sobre a qualidade da coleção selecionada, encontramos o mesmo comportamento usando as duas ferramentas. / Despite the API diversity that the Java Collections Framework (JCF) provides, with diverse implementations for several data structures, developers may choose inappropriate interfaces or classes, in terms of efficiency or purpose. This may happen due to insufficient API documentation or the lack of thoughtful analysis by the developer according to context requirements. A possible solution is manual replacement, in parallel with an analysis of the program context. However, this is tiresome and error-prone, discouraging the modification. In this work, we define a semi-automatic approach for (i) the selection of interfaces and implementation within the JCF and (ii) the modification of JCF clients, based on API migration techniques. The approach helps the user in choosing the most appropriate collection, based on requirements collected by means of simple yes/no questions. The selection is resolved with a decision tree that, from the answers given by the developer, decides which is the most adequate interface (and implementation) from the JCF. After this decision, the actual program modification is performed by means of adapters, minimizing the source code modification We evaluate the approach, as implemented in a supporting tool,with an experimental study comprising computer science students randomly distributed into groups,whose task was performing changes to JCF clients by different methods (manually, using Eclipse’s Java Search and our approach); the results were evaluated on quality, effort and time spent. We found that most students had a hard time choosing the right interface or implementation for the given requirements. Our approach seemed to improve the effort of selecting the best collection for the requirement, saving sometime in the process. Regarding the quality of the collection selected, we found the same behavior using both tools.