Evaluation of Kermeta for Solving Graph-based Problems

Kermeta is a meta-language for specifying the structure and behavior of graphs of interconnected objects called models. In this paper,\ud we show that Kermeta is relatively suitable for solving three graph-based\ud problems. First, Kermeta allows the specification of generic model\ud transformations such as refactorings that we apply to different metamodels\ud including Ecore, Java, and Uml. Second, we demonstrate the extensibility\ud of Kermeta to the formal language Alloy using an inter-language model\ud transformation. Kermeta uses Alloy to generate recommendations for\ud completing partially specified models. Third, we show that the Kermeta\ud compiler achieves better execution time and memory performance compared\ud to similar graph-based approaches using a common case study. The\ud three solutions proposed for those graph-based problems and their\ud evaluation with Kermeta according to the criteria of genericity,\ud extensibility, and performance are the main contribution of the paper.\ud Another contribution is the comparison of these solutions with those\ud proposed by other graph-based tools

A Domain Analysis to Specify Design Defects and Generate Detection Algorithms

Quality experts often need to identify in software systems design defects, which are recurring design problems, that hinder development\ud and maintenance. Consequently, several defect detection approaches\ud and tools have been proposed in the literature. However, we are not\ud aware of any approach that defines and reifies the process of generating\ud detection algorithms from the existing textual descriptions of defects.\ud In this paper, we introduce an approach to automate the generation\ud of detection algorithms from specifications written using a domain-specific\ud language. The domain-specific is defined from a thorough domain analysis.\ud We specify several design defects, generate automatically detection\ud algorithms using templates, and validate the generated detection\ud algorithms in terms of precision and recall on Xerces v2.7.0, an\ud open-source object-oriented system

Using FCA to Suggest Refactorings to Correct Design Defects

Design defects are poor design choices resulting in a hard-to- maintain software, hence their detection and correction are key steps of a\ud disciplined software process aimed at yielding high-quality software\ud artifacts. While modern structure- and metric-based techniques enable\ud precise detection of design defects, the correction of the discovered\ud defects, e.g., by means of refactorings, remains a manual, hence\ud error-prone, activity. As many of the refactorings amount to re-distributing\ud class members over a (possibly extended) set of classes, formal concept\ud analysis (FCA) has been successfully applied in the past as a formal\ud framework for refactoring exploration. Here we propose a novel approach\ud for defect removal in object-oriented programs that combines the\ud effectiveness of metrics with the theoretical strength of FCA. A\ud case study of a specific defect, the Blob, drawn from the\ud Azureus project illustrates our approach

From a Domain Analysis to the Specification and Detection of Code and Design Smells

Code and design smells are recurring design problems in software systems that must be identified to avoid their possible negative consequences\ud on development and maintenance. Consequently, several smell detection\ud approaches and tools have been proposed in the literature. However,\ud so far, they allow the detection of predefined smells but the detection\ud of new smells or smells adapted to the context of the analysed systems\ud is possible only by implementing new detection algorithms manually.\ud Moreover, previous approaches do not explain the transition from\ud specifications of smells to their detection. Finally, the validation\ud of the existing approaches and tools has been limited on few proprietary\ud systems and on a reduced number of smells. In this paper, we introduce\ud an approach to automate the generation of detection algorithms from\ud specifications written using a domain-specific language. This language\ud is defined from a thorough domain analysis. It allows the specification\ud of smells using high-level domain-related abstractions. It allows\ud the adaptation of the specifications of smells to the context of\ud the analysed systems.We specify 10 smells, generate automatically\ud their detection algorithms using templates, and validate the algorithms\ud in terms of precision and recall on Xerces v2.7.0 and GanttProject\ud v1.10.2, two open-source object-oriented systems.We also compare\ud the detection results with those of a previous approach, iPlasma

Are REST APIs for Cloud Computing Well-Designed? An Exploratory Study

International audienceCloud computing is currently the most popular model to offer and access computational resources and services. Many cloud providers use the REST architectural style (Representational State Transfer) for offering such computational resources. However, these cloud providers face challenges when designing and exposing REST APIs that are easy to handle by end-users and/or developers. Yet, they benefit from best practices to help them design understandable and reusable REST APIs. However, these best practices are scattered in the literature and they have not be studied systematically on real-world APIs. Consequently, we propose two contributions. In our first contribution, we survey the literature and compile a catalog of 73 best practices in the design of REST APIs making APIs more understandable and reusable. In our secondcontribution, we perform a study of three different and well-known REST APIs from three cloud providers to investigate how their APIs are offered and accessed. These cloud providers are Google Cloud Platform, OpenStack, and Open Cloud Computing Interface (OCCI). In particular, we evaluate the coverage of the features provided by the REST APIsof these cloud providers and their conformance with the best practices for REST APIs design. Our results show that Google Cloud follows 66% (48/73), OpenStack follows 62% (45/73), and OCCI 1.2 follows 56% (41/73) of the best practices. Second, although these numbers are not necessarily high, partly because of the strict and precise specification of best practices, we showed that cloud APIs reach an acceptable level of maturity

The Rise of Android Code Smells: Who Is to Blame?

International audienceThe rise of mobile apps as new software systems led to the emergence of new development requirements regarding performance. Development practices that do not respect these requirements can seriously hinder app performances and impair user experience, they qualify as code smells. Mobile code smells are generally associated with inexperienced developers who lack knowledge about the framework guidelines. However, this assumption remains unverified and there is no evidence about the role played by developers in the accrual of mobile code smells. In this paper, we therefore study the contributions of developers related to Android code smells. To support this study, we propose SNIFFER, an open-source toolkit that mines Git repositories to extract developers’ contributions as code smell histories. Using SNIFFER, we analysed 255k commits from the change history of 324 Android apps. We found that the ownership of code smells is spread across developers regardless of their seniority. There are no distinct groups of code smell introducers and removers. Developers who introduce and remove code smells are mostly the same

On the Survival of Android Code Smells in the Wild

International audienceThe success of smartphones and app stores have contributed to the explosion of the number of mobile apps proposed to end-users. In this very competitive market, developers are rushed to regularly release new versions of their apps in order to retain users. Under such pressure, app developers may be tempted to adopt bad design or implementation choices, leading to the introduction of code smells. Mobile-specific code smells represent a real concern in mobile software engineering. Many studies have proposed tools to automatically detect their presence and quantify their impact on performance. However, there remains—so far—no evidence about the lifespan of these code smells in the history of mobile apps. In this paper, we present the first large-scale empirical study that investigates the survival of Android code smells. This study covers 8 types of Android code smells, 324 Android apps, 255k commits, and the history of 180k code smell instances. Our study reports that while in terms of time Android code smells can remain in the codebase for years before being removed, it only takes 34 effective commits to remove 75% of them. Also, Android code smells disappear faster in bigger projects with higher releasing trends. Finally, we observed that code smells that are detected and prioritised by linters tend to disappear before other code smells

Code Smells in iOS Apps: How do they compare to Android?

International audienceWith billions of app downloads, the Apple App Store and Google Play Store succeeded to conquer mobile devices. However, this success also challenges app developers to publish high-quality apps to keep attracting and satisfying end-users. In particular, taming the ever-growing complexity of mobile apps to cope with maintenance and evolution tasks under such a pressure may lead to bad development choices. While these bad choices, a.k.a. code smells, are widely studied in object-oriented software, their study in the context of mobile apps, and in particular iOS apps, remains in its infancy.Therefore, in this paper, we consider the presence of object-oriented and iOS-specific code smells by analyzing 279 open-source iOS apps. As part of this empirical study, we extended the Paprika toolkit, which was previously designed to analyze Android apps, in order to support the analysis of iOS apps developed in Objective-C or Swift. We report on the results of this analysis as well as a comparison between iOS and Android apps. We comment our findings related to the quality of apps in these two ecosystems. Interestingly, we observed that iOS apps tend to contain the same proportions of code smells regardless of the development language, but they seem to be less prone to code smells compared to Android apps