Understanding and Tooling Framework API Evolution

RÉSUMÉ Les cadres d’applications sont intensivement utilisés dans le développement de logiciels modernes et sont accessibles au travers de leur Application Programming Interface (API), qui définit un ensemble de fonctionnalités que les programmes clients peuvent utiliser pour accomplir des tâches. Les cadres d’applications ne cessent d’évoluer au cours de leurs vies pour satisfaire la demande de nouvelles fonctions ou pour rapiécer des vulnérabilités de sécurité. L’évolution des cadres d’applications peut engendrer des modifications de l’API auxquelles les programmes clients doivent s’adapter. Les mises à jour vers les nouvelles versions des cadres d’applications prennent du temps et peuvent même interrompre le service. Aider les développeurs à mettre à jour leurs programmes est d’un grand intérêt pour les chercheurs académiques et industriels. Dans cette thèse, nous réalisons une étude exploratoire de la réalité des évolutions des API et de leurs usages dans le dépôt central de Maven et dans deux grands cadres d’applications avec de larges écosystèmes : Apache et Eclipse. Nous découvrons que les API changent dans environ 10 % des cadres d’applications et touchent 50 % des programmes clients. Il arrive plus souvent que des classes et des méthodes manquent et disparaissent dans les cadres d’applications. Ces classes et méthodes affectent les programmes clients plus souvent que les autres changements des API. Nous montrons aussi qu’environ 80 % des utilisations des API dans les programmes clients peuvent être réduits par refactoring. Forts de ce constat, nous faisons une expérience pour vérifier l’effectivité des règles de changement des API générés par les approches existantes, qui recommandent les remplacements pour les API disparues pendant l’évolution des cadres d’application. Nous confirmons que les règles de changement des API aident les développeurs à trouver des remplacements aux API manquantes plus précisément, en particulier pour des cadres d’applications difficiles à comprendre. Enfin, nous étudions l’efficacité des caractéristiques utilisées pour construire les règles de changement des API et différentes manières de combiner plusieurs caractéristiques. Nous soutenons et montrons que des approches basées sur l’optimisation multi-objective peuvent détecter des règles de changement des API plus précisément et qu’elles peuvent prendre en compte plus facilement de nouvelles caractéristiques que les approches précédentes.----------ABSTRACT Frameworks are widely used in modern software development and are accessed through their Application Programming Interfaces (APIs), which specify sets of functionalities that client programs can use to accomplish their tasks. Frameworks keep evolving during their lifespan to cope with new requirements, to patch security vulnerabilities, etc. Framework evolution may lead to API changes to which client programs must adapt. Upgrading to new releases of frameworks is time-consuming and can even interrupt services. Helping developers upgrade frameworks draws great interests from both academic and industrial researchers. In this dissertation, we first present an exploratory study to investigate the reality of API changes and usages in Maven repository and two framework ecosystems: Apache and Eclipse. We find that API changes in about 10% of frameworks affect about 50% of client programs. Missing classes and missing methods happen more often in frameworks and affect client programs more often than other API changes. About 80% API usages in client programs can be reduced by refactoring. Based on these findings, we conduct an empirical study to verify the usefulness of API change rules automatically built by previous approaches, which recommend the replacements for missing APIs due to framework evolution. We show that API change rules do help developers find the replacements of missing APIs more accurately, especially for frameworks difficult to understand. We describe another empirical study to evaluate the effectiveness of features used to build API change rules and of different ways combining multiple features. We argue and show that multi-objective-optimization-based approaches can detect more correct change rules and are easier to extend with new features than previous approaches

Spartan Daily, October 31, 1990

Volume 95, Issue 44https://scholarworks.sjsu.edu/spartandaily/8043/thumbnail.jp

A Systematic Mapping Study on Requirements Engineering in Software Ecosystems

Software ecosystems (SECOs) and open innovation processes have been claimed as a way forward for the software industry. A proper understanding of requirements is as important for these IT-systems as for more traditional ones. This paper presents a mapping study on the issues of requirements engineering and quality aspects in SECOs and analyzes emerging ideas. Our findings indicate that among the various phases or subtasks of requirements engineering, most of the SECO specific research has been accomplished on elicitation, analysis, and modeling. On the other hand, requirements selection, prioritization, verification, and traceability has attracted few published studies. Among the various quality attributes, most of the SECOs research has been performed on security, performance and testability. On the other hand, reliability, safety, maintainability, transparency, usability attracted few published studies. The paper provides a review of the academic literature about SECO-related requirements engineering activities, modeling approaches, and quality attributes, positions the source publications in a taxonomy of issues and identifies gaps where there has been little research.Comment: Journal of Information Technology Research (JITR) 11(1

The social side of software platform ecosystems

Software ecosystems as a paradigm for large-scale software development encompass a complex mix of technical, business, and social aspects. While significant research has been conducted to understand both the technical and business aspects, the social aspects of software ecosystems are less well understood. To close this gap, this paper presents the results of an empirical study aimed at understanding the influence of social aspects on developers' participation in software ecosystems. We conducted 25 interviews with mobile software developers and an online survey with 83 respondents from the mobile software development community. Our results point out a complex social system based on continued interaction and mutual support between different actors, including developers, friends, end users, developers from large companies, and online communities. These findings highlight the importance of social aspects in the sustainability of software ecosystems both during the initial adoption phase as well as for long-term permanence of developers.Cleidson R. B. de Souza, Fernando Figueira Filho, Müller Miranda, Renato Pina Ferreira, Christoph Treude, Leif Singe

Why and How Java Developers Break APIs

Modern software development depends on APIs to reuse code and increase productivity. As most software systems, these libraries and frameworks also evolve, which may break existing clients. However, the main reasons to introduce breaking changes in APIs are unclear. Therefore, in this paper, we report the results of an almost 4-month long field study with the developers of 400 popular Java libraries and frameworks. We configured an infrastructure to observe all changes in these libraries and to detect breaking changes shortly after their introduction in the code. After identifying breaking changes, we asked the developers to explain the reasons behind their decision to change the APIs. During the study, we identified 59 breaking changes, confirmed by the developers of 19 projects. By analyzing the developers' answers, we report that breaking changes are mostly motivated by the need to implement new features, by the desire to make the APIs simpler and with fewer elements, and to improve maintainability. We conclude by providing suggestions to language designers, tool builders, software engineering researchers and API developers.Comment: Accepted at International Conference on Software Analysis, Evolution and Reengineering, SANER 2018; 11 page

Software engineering : redundancy is key

Software engineers are humans and so they make lots of mistakes. Typically 1 out of 10 to 100 tasks go wrong. The only way to avoid these mistakes is to introduce redundancy in the software engineering process. This article is a plea to consciously introduce several levels of redundancy for each programming task. Depending on the required level of correctness, expressed in a residual error probability (typically 10-3 to 10-10), each programming task must be carried out redundantly 4 to 8 times. This number is hardly influenced by the size of a programming endeavour. Training software engineers does have some effect as non trained software engineers require a double amount of redundant tasks to deliver software of a desired quality. More compact programming, for instance by using domain specific languages, only reduces the number of redundant tasks by a small constant