Software Analytics for Mobile Applications – Insights & Lessons Learned [CSMR2013]

Software Analytics for Mobile Applications
Insights & Lessons Learned

Roberto Minelli & Michele Lanza
REVEAL @ Faculty of Informatics
University of Lugano, Switzerland

Università
della
Svizzera
italiana R E V E A L

...to Mobile
Applications

...to Mobile
Applications

Apps are software systems
aimed at smartphones, tablet
PCs, and other handheld devices

Apps are written in different
Languages...
C++
Java

Objective-C
C# C/C++, Java, etc.

Apps are written in different
Languages...
C++
Java

Objective-C

...and distributed via different
App Stores

The marketplace
is vast

1,000,000
apps to download

$4.5 billions “Mobile application and its global impact”
R. Islam, R. Islam, and T. Mazumder [IJEST 2010].
in 2009

in 2009
“Mobile application sales to reach $17.5bn by 2012”
http://news.bbc.co.uk

$17.5in billions
2012

in 2009
http://news.bbc.co.uk

“Global mobile application market (2010- 2015)”
Markets and Markets, August 2010.

$17.5in billions
2012

$25 billions in 2015

Apps are becoming more
popular...

...and evolve
over time...

...thus maintenance
is critical!

“Programs, Life Cycles, and
Laws of Software Evolution”

1980 1981 1982

“Software evolution observations
based on product release history”
“Implications of evolution metrics
on software maintenance”
“Metrics and laws of software
evolution - the nineties view”
“Laws of software “Evolution in open source
evolution revisited” software: A case study”

1996 1997 1998 1999 2000 20

2006 2007 2008 2009 2010 2011

S A MO A
Software Analytics for MObile Applications

“Software Analytics for Mobile
Applications – Insights &
Lessons Learned”

0 2011 2012 2013

S A MO A
A web-based software analytics tool for apps

Software Analytics
for MObile A pplications

S A MO A
http://samoa.inf.usi.ch

Source Code

Evolution

Use of
3 rd Party Libraries

<manifest xmlns:androi
d="http://schemas.
android.com/apk/res/an
droid"
package="ch.inf.andro
id.app"
android:versionCode=
"1"
android:versionName=
"1.0">
<application android>
<activity
android:name="android
VNC"
android:label="@string/
title_info">
<intent-filter>
<action android:name=
"android.intent.action.M
<category AIN" />
android:name="android
.intent.category.LAUN
CHER" />
</intent-filter>
</activity>
<activity
android:name=".Anoth
erActivity"
android:theme="@andr
oid:style/Theme.Dialog"
title_details" />
<activity
android:name=".YetAno
therActivity"
android:launchMode="s
ingleTop"
title_configure"
android:windowSoftInpu
tMode="stateHidden">
</activity>
</application>

Manifest.xml

Snapshot view

History view

Snapshot view

History view

Ecosystem view

S A MO A

DEMO
http://samoa.inf.usi.ch

BACK-END FRONT-END

Source code model extraction SAMOA
SVN
SVN
SVN
SVN
AST generator MSE generator JSON retrieval d3.js

AST parser MSE parser JavaScript/
HTML/CSS
jQuery/PHP
Data acquisition

Java SVN JSON Internet
crawler Files

Metrics extraction

AST-based MSE-based
metrics metrics

Name Rate Installs Start rev. End rev. Size (LOC)
Alogcat 4.6 >100k 2 48 876
Andless 4.2 >100k 2 93 2372
Android VNC 4.3 >1m 2 203 4949
Anstop N/A N/A 2 61 1142
AppSoundmanager 4.5 >50k 1 157 1605
AppsOrganizer 4.6 >1m 3 191 8321
CSIPSimple 4.4 >100k 2 1415 20777
Diskusage 4.7 >50k 2 69 4749
Mythdroid N/A N/A 76 640 6114
Mythmote 4.6 >10k 2 281 1593
Open GPS Tracker 4.2 >100k 2 1255 9754
Opensudoku 4.6 >1m 15 415 3813
Replicaisland 4.2 >1m 2 7 14192
Ringdroid 4.6 >10m 2 66 3516
Search Light 4.7 >100k 2 4 272
Share My Position 4.6 >10k 2 76 468
SIPDroid 4.0 >500k 50 620 14019
Solitaire for Android 4.3 >10m 2 30 3343
Zirco Browser 3.8 >10k 65 457 6429
Zxing 4.3 >50m 569 2257 3407

Metric Description
NOP The Number of Packages of a project.
NOC The Number of Classes defined by the user.
NOM The Number of Methods defined by the user.
LOC The number of (non-empty) Lines of Code.
CYCLO McCabe’s Cyclomatic Complexity.
CALLS The number of (distinct) Method Calls.
FANOUT The Number of Called Classes.
ANDC The Average Number of Derived Classes. The metric does not count interfaces.
The Average Hierarchy Height of a system. A class is a root class if it is not an
AHH
interface and not derived from user-defined classes.
The Number of Internal Calls, i.e., invocations of methods that implement
INTC
internal behavior
EXTC The Number of External Calls, i.e., invocations that refer to 3rd-party libraries.
NOCE The Number of Core Elements.
CORELOC The sum of LOC of core elements.
COMMITS The Number of Commits of an app.
CALLR The ratio between INTC and EXTC.
CORER The ratio between CoreLOC and LOC.

Metric Description
AHH
INTC
internal behavior

“Object-oriented Software Metrics” “Object-Oriented Metrics in Practice”
M. Lorenz and J. Kidd, 1994 M. Lanza and R. Marinescu, 2006

Metric Description
AHH
INTC
internal behavior

“Software Analytics for Mobile Applications”
Roberto Minelli, MSc Thesis, 2012

Catalogue o f c h a r a c t e r is t ic s
of apps

S A MO A
Software Analytics for
MObile Applications

“Software Analytics for Mobile Applications”
Roberto Minelli, MSc Thesis, 2012

Apps are smaller than traditional software systems.

Facts:
✴Average size is 5.6 kLOC.
✴Smallest app is <300LOC.
✴Largest app is ~20kLOC.

Implications:
✴Often apps have few functionalities,
thus a few classes are enough to build
them...
✴...but it seems they are not trivial to
comprehend and maintain.

Apps are inherently complex, mostly because they
rely on third-party libraries.

Facts:
✴External calls are about 2/3 of all
method invocations.
✴In some apps external calls are more
than 75% of the total.
Implications:
✴To comprehend apps, analysts must
understand the behavior of the 3rd
party libraries, complicating program
comprehension and maintenance.

The size and complexity of apps grow in correlation
with the addition of third-party method invocations.

Facts:
✴The correlation between number of
external calls and complexity
number is high (x = 0.82).
✴The correlation between number of
LOC and complexity number is also
high (x = 0.84).
Implications:
✴The growth of an app can be
connected with the usage of the
external libraries.

The use of inheritance is almost absent in apps.

Average Hierarchy Height (AHH) = 0.09
We studied breadth and depth of the inheritance...
Average Number of Derived Classes (ANDC) = 0.19

Facts:
✴The apps in our corpus have very small average values for
both these metrics.
✴Apps tend to be small, thus there is little potential for
inheritance.
Implications:
✴We suspect that if they evolve over a long time, they will
grow in size, according the Lehman’s software evolution laws.

Some apps contain the entire source code of third-
party libraries.

Facts:
✴In Java systems 3rd party libraries
are reused by referencing JARs.
✴In some apps developers directly
import the entire source code of 3rd
party libraries.
Implications:
✴Copying external code into a
system can have a series of legal
consequences.

Some developers use versioning systems only at
later stages of the development.

Facts:
✴It is a good practice to put software
projects under revision control early.
✴On average, the LOC of the first
(a)
revision represents ca. 1/3 of the LOC
at the end of the evolution.
✴The quality of any software analysis is
(b) (c)
connected to the quality of the
available data.


Facts:
“Initial add, corresponds to
On average, the LOC of the first
market version✴1.8”.
(a)
(b) (c)
available data.


Facts:
✴On average, the LOC of the first
(a)
(b) (c)
available data.

Implications:
✴Incomplete histories make retrospective software evolution
analysis difficult.

Developers often break the connection between
Android manifest and source code.

Facts:
✴As all software systems, apps are also
“core drop” made up of pieces which are not
source code.
✴The manifest file identifies core
elements of an app.
✴Developers must manually maintain
this file in sync with the source code.


Facts:
made up of pieces which are not
source code.
“unbroke the app after the big
subpackage reshuffle of ’09:
elements of an app.
Updated manifest entries [...]”


Facts:
made up of pieces which are not
source code.
elements of an app.
Implications:
✴We believe that the maintenance and understanding of such
pieces will become a concern.
“An empirical study of build maintenance effort”
S. McIntosh et al., [ICSE 2009]

Development guidelines are often ignored.

Facts:
✴Software systems should conform to
a set of sound guiding principles.
✴In Android, one of such guidelines is
that an app must have only one main
activity.
Implications:
✴Multiple main activities are multiple
entry points, complicating the
comprehension of apps.

“Default” main activity Activity Main activity Service

Some apps are only composed of the core.

Facts:
✴On average, CORELOC represent ca.
half of the size of an entire app.
✴In our corpus 25% of the apps have
more than 70% of CORELOC.
Implications:
✴Those apps violate basic design
guidelines (i.e., separation of
concerns and encapsulation).
✴“God activities”, like god classes, are
a maintenance problem.
“Object-Oriented Design Heuristics”
A. Riel, 1996.

...for Mobile Apps are written in different
Software Analytics for Mobile Applications
Insights & Lessons Learned
Applications Languages...
C++
Java
Roberto Minelli & Michele Lanza
REVEAL @ Faculty of Informatics
University of Lugano, Switzerland Objective-C
Apps are software systems
aimed at smartphones, tablet ...and distributed via different
Università
della
Svizzera
italiana R E V E A L
PCs, and other handheld devices.
App Stores
$4.5 billions
in 2009
“Mobile application and its global impact”

S A MO A
Software Analytics for MObile Applications

http://news.bbc.co.uk http://samoa.inf.usi.ch
“Global mobile application market (2010- 2015)”
Markets and Markets, August 2010.

$17.5in billions
2012

...thus maintenance
$25 billions in 2015 is critical!

Source Code Snapshot view Insights &
Lessons Learned
Evolution History view

Use of
3rd Party Libraries Ecosystem view

Apps are inherently complex, mostly because they The size and complexity of apps grow in correlation
Apps are smaller than traditional software systems. with the addition of third-party method invocations.
rely on third-party libraries.

Facts: Facts: Facts:
✴Average size is 5.6 kLOC. ✴External calls are about 2/3 of all ✴The correlation between number of
✴Smallest app is <300LOC. method invocations. external calls and complexity
✴Largest app is ~20kLOC. ✴In some apps external calls are more number is high (x = 0.82).
than 75% of the total. ✴The correlation between number of
Implications:
LOC and complexity number is also
✴Often apps have few functionalities, Implications: high (x = 0.84).
thus a few classes are enough to build ✴To comprehend apps, analysts must
them... understand the behavior of the 3rd Implications:
✴...but it seems they are not trivial to party libraries, complicating program ✴The growth of an app can be
comprehend and maintain. comprehension and maintenance. connected with the usage of the
external libraries.

Some apps contain the entire source code of third- Some developers use versioning systems only at
The use of inheritance is almost absent in apps. party libraries. later stages of the development.

Average Hierarchy Height (AHH) = 0.09 Facts: Facts:
✴In Java systems 3rd party libraries ✴It is a good practice to put software
We studied breadth and depth of the inheritance...
are reused by referencing JARs. projects under revision control early.
Average Number of Derived Classes (ANDC) = 0.19 ✴In some apps developers directly ✴On average, the LOC of the first
import the entire source code of 3rd revision represents ca. 1/3 of the LOC
(a)

Facts: party libraries. at the end of the evolution.
✴The apps in our corpus have very small average values for ✴The quality of any software analysis is
both these metrics. Implications: (b) (c)
✴Apps tend to be small, thus there is little potential for ✴Copying external code into a
available data.
inheritance. system can have a series of legal
consequences.
Implications:
Implications:
✴We suspect that if they evolve over a long time, they will
✴Incomplete histories make retrospective software evolution
grow in size, according the Lehman’s software evolution laws.
analysis difficult.

Android manifest and source code. Development guidelines are often ignored. Some apps are only composed of the core.

Facts: Facts: Facts:
✴As all software systems, apps are also ✴Software systems should conform to ✴On average, CORELOC represent ca.
made up of pieces which are not a set of sound guiding principles. half of the size of an entire app.
source code. ✴In Android, one of such guidelines is ✴In our corpus 25% of the apps have
✴The manifest file identifies core that an app must have only one main more than 70% of CORELOC.
elements of an app. activity.
Implications:
Implications: ✴Those apps violate basic design
✴Multiple main activities are multiple guidelines (i.e., separation of
Implications: entry points, complicating the concerns and encapsulation).
✴We believe that the maintenance and understanding of such comprehension of apps. ✴“God activities”, like god classes, are
pieces will become a concern. a maintenance problem.
“Object-Oriented Design Heuristics”
“An empirical study of build maintenance effort” A. Riel, 1996.
S. McIntosh et al., [ICSE 2009] “Default” main activity Activity Main activity Service

Software Analytics for Mobile Applications – Insights & Lessons Learned [CSMR2013]

Recommended

Recommended

More Related Content

Similar to Software Analytics for Mobile Applications – Insights & Lessons Learned [CSMR2013]

Similar to Software Analytics for Mobile Applications – Insights & Lessons Learned [CSMR2013] (20)

More from Roberto Minelli

More from Roberto Minelli (18)

Recently uploaded

Recently uploaded (20)

Software Analytics for Mobile Applications – Insights & Lessons Learned [CSMR2013]