Comprehension of Ads-supported and Paid Android Applications: Are They Different?

The Android market is a place where developers offer paid and-or free apps to users. Free apps are interesting to users because they can try them immediately without incurring a monetary cost. However, free apps often have limited features and-or contain ads when compared to their paid counterparts. Thus, users may eventually need to pay to get additional features and-or remove ads. While paid apps have clear market values, their ads-supported versions are not entirely free because ads have an impact on performance. In this paper, first, we perform an exploratory study about ads-supported and paid apps to understand their differences in terms of implementation and development process. We analyze 40 Android apps and we observe that (i) ads-supported apps are preferred by users although paid apps have a better rating, (ii) developers do not usually offer a paid app without a corresponding free version, (iii) ads-supported apps usually have more releases and are released more often than their corresponding paid versions, (iv) there is no a clear strategy about the way developers set prices of paid apps, (v) paid apps do not usually include more functionalities than their corresponding ads-supported versions, (vi) developers do not always remove ad networks in paid versions of their ads-supported apps, and (vii) paid apps require less permissions than ads-supported apps. Second, we carry out an experimental study to compare the performance of ads-supported and paid apps and we propose four equations to estimate the cost of ads-supported apps. We obtain that (i) ads-supported apps use more resources than their corresponding paid versions with statistically significant differences and (ii) paid apps could be considered a most cost-effective choice for users because their cost can be amortized in a short period of time, depending on their usage.Comment: Accepted for publication in the proceedings of the IEEE International Conference on Program Comprehension 201

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

A Machine-learning Based Ensemble Method For Anti-patterns Detection

Anti-patterns are poor solutions to recurring design problems. Several empirical studies have highlighted their negative impact on program comprehension, maintainability, as well as fault-proneness. A variety of detection approaches have been proposed to identify their occurrences in source code. However, these approaches can identify only a subset of the occurrences and report large numbers of false positives and misses. Furthermore, a low agreement is generally observed among different approaches. Recent studies have shown the potential of machine-learning models to improve this situation. However, such algorithms require large sets of manually-produced training-data, which often limits their application in practice. In this paper, we present SMAD (SMart Aggregation of Anti-patterns Detectors), a machine-learning based ensemble method to aggregate various anti-patterns detection approaches on the basis of their internal detection rules. Thus, our method uses several detection tools to produce an improved prediction from a reasonable number of training examples. We implemented SMAD for the detection of two well known anti-patterns: God Class and Feature Envy. With the results of our experiments conducted on eight java projects, we show that: (1) our method clearly improves the so aggregated tools; (2) SMAD significantly outperforms other ensemble methods.Comment: Preprint Submitted to Journal of Systems and Software, Elsevie

Towards the exploration strategies by mining Mylyns' interaction histories

When developers perform a maintenance task, they always explore the program, i.e., move from one program entity to another. However, even though maintenance is a crucial task, the exploration strategies (ES) used by developers to navigate through the program entities remain unstudied. This lack of study prevents us from understanding how developers explore a program and perform a change task, from recommending strategies to developers, and (ultimately) from critically evaluating a developer's exploration performance. As a first step towards understanding ES, we mined interaction histories (IH) gathered using the Eclipse Mylyn plugin from developers performing a change task on four open-source projects (ECF, Mylyn, PDE, and Eclipse Platform). An ES is defined and characterized by the way (how) the developers navigate through the program entities. Using the Gini inequality index on the number of revisits of program entities, we observe that ES can be either centralized (CES) or extended (EES). We automatically classified interaction histories as CES or EES and performed an empirical study to ascertain the effect of the ES on the task duration and effort. We found that, although an EES requires more exploration effort than a CES, an EES is less time consuming than a CES. Extensive work (number of days spent performing a task) typically imply a CES. Our results show that developers who follow an EES have a methodical investigation of source code while developers who follow a CES have an opportunistic exploration of source code

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

Analysing Anti-patterns Static Relationships with Design Patterns

Anti-patterns are motifs that are usually thought to be good solutions tosome design or implementation problems, but back-fires badly when applied. Previousstudies have reported that anti-patterns make object oriented systems hard tomaintain. Anti-patterns motifs usually have dependencies with other classes in thesystem. In this paper, we propose to analyse these dependencies (with in particulardesign patterns) in order to understand how developers can maintain programscontaining anti-patterns. To the best of our knowledge, no substantial investigationof anti-pattern dependencies with design patterns has been done before. This paperpresents the results of a study that we performed on three different systems, ArgoUML,JFreeChart, and XercesJ, written in Java, and of size ranges from 1,191to 3,325 classes, to analyse the static relationships between anti-patterns and designpatterns. We found that these relationships (1) exist, but (2) are temporaryand (3) classes participating in such relationships are more change-prone but lessfault-prone than other anti-pattern classes