Analyzing the Change-Proneness of APIs and web APIs

Analyzing the Change-Proneness of APIs and web APIs APIs and web APIs are used to expose existing business logic and, hence, to ease the reuse of functionalities across multiple software systems. Software systems can use the business logic of legacy systems by binding their APIs and web APIs. With the emergence of a new programming paradigm called service-oriented, APIs are exposed as web APIs hiding the technologies used to implement legacy systems. As a consequence, web APIs establish contracts between legacy systems and their consumers and they should stay as stable as possible to not break consumers’ systems. This dissertation aims at better understanding the change-proneness of APIs and web APIs. Specifically to that end, we investigated which indicators can be used to highlight change-prone APIs and web APIs and we provided approaches to assist practitioners in refactoring them. To perform this analysis we adopted a research approach consisting of three different tracks: analysis of change-prone APIs, analysis of change-prone web APIs, and refactoring of change-prone APIs and web APIs. Change-Prone APIs Service-oriented systems are composed by web services. Each web service is implemented by an implementation logic that is hidden to its clients through its web APIs. Along the history of a software system the implementation logic can be changed and its changes can be propagated and affect web APIs. Among all the software units composing the implementation logic, APIs are likely to be mapped directly into web APIs. This scenario is likely to happen especially if a legacy API is made available through a web service. In this first track we focused on analyzing the change-proneness of APIs (i.e., the set of public methods declared in a software unit). Among all the metrics we analyzed, we have shown that the Interface Usage Cohesion (IUC) metric is the most suitable metric to highlight change-prone Java interfaces. This result suggests that software engineers should design interfaces with high external cohesion (measured with the IUC metric) to avoid frequent changes. Moreover, we analyzed the impact of specific antipatterns on the changeproneness of APIs. We showed empirically that changes to APIs are more likely to appear if APIs are affected by the ComplexClass, SpaghettiCode, and SwissArmyKnife antipatterns. As a consequence software engineers should refactor APIs affected by these antipatterns. Change-Prone Web APIs In the second track we analyzed the change-proneness of web APIs. First, we developed two tools to analyze software systems composed of web APIs. The first tool is called WSDLDiff and extracts fine-grained changes between subsequent versions of WSDL APIs. The second tool extracts the full chains of dependencies among web APIs at run time. Second, we performed an empirical study to investigate which scenarios can cause changes to web APIs. We showed that low externally cohesive APIs change frequently to 1) improve understandability and 2) ease maintainability and reduce clones in the APIs. Low internally cohesive APIs change frequently to 1) reduce the impact of changes on the many clients they have, 2) avoid that all the clients lead the APIs to be changed frequently, and 3) improve understandability. Moreover, we proposed a new internal cohesion metric (DTC) to measure the internal cohesion of WSDL APIs. Refactoring APIs and Web APIs Based on the results of the studies performed in the first and second track, we defined two approaches to refactor APIs and web APIs. The first approach assists software engineers in refactoring APIs with low external cohesion based on the Interface Segregation Principle (ISP). We defined the problem of splitting low externally cohesive APIs into smaller APIs specific for each client (i.e., ISP) as a multi-objective clustering optimization problem. To solve this problem we proposed a genetic algorithm that outperforms other search based approaches. The second approach assists software engineers in refactoring fine-grained web APIs. These APIs should be refactored into coarse-grained web APIs to reduce the number of remote invocations and avoid performance problems. To achieve this goal we proposed a genetic algorithm that looks for Façade APIs that cluster together the fine-grained methods of the original API. Conclusion We believe that these results advance the state-of-the-art in designing, analyzing, and refactoring software systems composed of web APIs (i.e., serviceoriented systems) and provide to the research community new insights into the change-proneness of APIs and web APIs.