Software developers often encapsulate reusable code as Application Programming Interfaces (APIs). The co-evolution of applications and APIs may motivate an API migration: the replacement of application dependencies to an original API by dependencies to an alternative API that provides similar functionality and abstractions. In this dissertation, we investigate issues associated with API migration in object-oriented systems, with special focus on wrapping approaches. We present two studies and a set of developer interviews that elicit issues in the process and techniques used in API migration in practice. The results suggest that the most pressing issues relate to discovery and specification of differences between APIs, and to assessment of migration correctness. This dissertation introduces techniques and a method to address these issues. We propose the use of design patterns to support the specification of API wrappers. API wrapping design patterns encode solutions to common wrapping design problems. We present an initial catalog of such patterns that were abstracted from programming idioms found in existing API wrappers. We introduce the concept of compliance testing for API migration, a form of automated testing. Compliance testing supports the discovery of behavioral differences between a wrapper and its corresponding original API, as well as assessment of wrapper correctness. Compliance testing uses API contracts and assertion tunings to explicitly capture and enforce the notion of a “good enough” wrapper that is informal in practice. We present the Koloo method for wrapper-based API migration. The method prescribes practical steps to use compliance testing as a means to elicit the requirements for the API migration, and to assess its correctness. Koloo fits within the iterative, sample-driven general API migration process usually followed by developers in practice. We evaluate the Koloo method in an empirical study. The subjects cover the domains of XML processing, GUI programming and bytecode engineering. The results provide evidence that Koloo is superior to alternative methods in driving the development of a wrapper that is tailored for the application under migration. The results also show that API contracts help driving the evolution of the wrapper, and assertion tuning is necessary to relax the semantics of strict equality contracts, and useful to compromise on features that are difficult to emulate perfectly. Finally, we validate that the proposed design patterns are used in practical wrappers.

Software developers often encapsulate reusable code as Application Programming Interfaces (APIs). The co-evolution of applications and APIs may motivate an API migration: the replacement of application dependencies to an original API by dependencies to an alternative API that provides similar functionality and abstractions. In this dissertation, we investigate issues associated with API migration in object-oriented systems, with special focus on wrapping approaches. We present two studies and a set of developer interviews that elicit issues in the process and techniques used in API migration in practice. The results suggest that the most pressing issues relate to discovery and specification of differences between APIs, and to assessment of migration correctness. This dissertation introduces techniques and a method to address these issues. We propose the use of design patterns to support the specification of API wrappers. API wrapping design patterns encode solutions to common wrapping design problems. We present an initial catalog of such patterns that were abstracted from programming idioms found in existing API wrappers. We introduce the concept of compliance testing for API migration, a form of automated testing. Compliance testing supports the discovery of behavioral differences between a wrapper and its corresponding original API, as well as assessment of wrapper correctness. Compliance testing uses API contracts and assertion tunings to explicitly capture and enforce the notion of a “good enough” wrapper that is informal in practice. We present the Koloo method for wrapper-based API migration. The method prescribes practical steps to use compliance testing as a means to elicit the requirements for the API migration, and to assess its correctness. Koloo fits within the iterative, sample-driven general API migration process usually followed by developers in practice. We evaluate the Koloo method in an empirical study. The subjects cover the domains of XML processing, GUI programming and bytecode engineering. The results provide evidence that Koloo is superior to alternative methods in driving the development of a wrapper that is tailored for the application under migration. The results also show that API contracts help driving the evolution of the wrapper, and assertion tuning is necessary to relax the semantics of strict equality contracts, and useful to compromise on features that are difficult to emulate perfectly. Finally, we validate that the proposed design patterns are used in practical wrappers.

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 .

Software components expose Application Programming Interfaces (APIs) as a means to access their functionality, and facilitate reuse. Developers use APIs supplied by programming languages to access the core data structures and algorithms that are part of the language framework. They use the APIs of third-party libraries for specialized tasks. Thus, APIs play a central role in mediating a developer's interaction with software, and the interaction between different software components. However, APIs are often large, complex and hard to navigate. They may have hundreds of classes and methods, with incomplete or obsolete documentation. They may encapsulate concurrency behaviour that the developer is unaware of. Finding the right functionality in a large API, using APIs correctly, and maintaining software that uses a constantly evolving API are challenges that every developer runs into. In this thesis, we design automated techniques to address two problems pertaining to APIs (1) Concurrency analysis of APIs, and (2) API mining. Speci cally, we consider the concurrency analysis of asynchronous APIs, and mining of math APIs to infer the functional behaviour of API methods. The problem of concurrency bugs such as race conditions and deadlocks has been well studied for multi-threaded programs. However, developers have been eschewing a pure multi-threaded programming model in favour of asynchronous programming models supported by asynchronous APIs. Asynchronous programs and multi-threaded programs have different semantics, due to which existing techniques to analyze the latter cannot detect bugs present in programs that use asynchronous APIs. This thesis addresses the problem of concurrency analysis of programs that use asynchronous APIs in an end-to-end fashion. We give operational semantics for important classes of asynchronous and event-driven systems. The semantics are designed by carefully studying real software and serve to clarify subtleties in scheduling. We use the semantics to inform the design of novel algorithms to find races and deadlocks. We implement the algorithms in tools, and show their effectiveness by finding serious bugs in popular open-source software. To begin with, we consider APIs for asynchronous event-driven systems supporting pro-grammatic event loops. Here, event handlers can spin event loops programmatically in addition to the runtime's default event loop. This concurrency idiom is supported by important classes of APIs including GUI, web browser, and OS APIs. Programs that use these APIs are prone to interference between a handler that is spinning an event loop and another handler that runs inside the loop. We present the first happens-before based race detection technique for such programs. Next, we consider the asynchronous programming model of modern languages like C]. In spite of providing primitives for the disciplined use of asynchrony, C] programs can deadlock because of incorrect use of blocking APIs along with non-blocking (asynchronous) APIs. We present the rst deadlock detection technique for asynchronous C] programs. We formulate necessary conditions for deadlock using a novel program representation that represents procedures and continuations, control ow between them and the threads on which they may be scheduled. We design a static analysis to construct the pro-gram representation and use it to identify deadlocks. Our ideas have resulted in research tools with practical impact. Sparse Racer, our tool to detect races, found 13 previously unknown use-after-free bugs in KDE Linux applications. Dead Wait, our deadlock detector, found 43 previously unknown deadlocks in asynchronous C] libraries. Developers have fixed 43 of these races and deadlocks, indicating that our techniques are useful in practice to detect bugs that developers consider worth fixing. Using large APIs effectively entails finding the right functionality and calling the methods that implement it correctly, possibly composing many API elements. Automatically infer-ring the information required to do this is a challenge that has attracted the attention of the research community. In response, the community has introduced many techniques to mine APIs and produce information ranging from usage examples and patterns, to protocols governing the API method calling sequences. We show how to mine unit tests to match API methods to their functional behaviour, for the specific but important class of math APIs. Math APIs are at the heart of many application domains ranging from machine learning to scientific computations, and are supplied by many competing libraries. In contrast to obtaining usage examples or identifying correct call sequences, the challenge in this domain is to infer API methods required to perform a particular mathematical computation, and to compose them correctly. We let developers specify mathematical computations naturally, as a math expression in the notation of interpreted languages (such as Matlab). Our unit test mining technique maps subexpressions to math API methods such that the method's functional behaviour matches the subexpression's executable semantics, as defined by the interpreter. We apply our technique, called MathFinder, to math API discovery and migration, and validate it in a user study. Developers who used MathFinder nished their programming tasks twice as fast as their counterparts who used the usual techniques like web and code search, and IDE code completion. We also demonstrate the use of MathFinder to assist in the migration of Weka, a popular machine learning library, to a different linear algebra library.