328 research outputs found
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
- …