Software Analytics for Mobile ApplicationsInsights & Lessons LearnedRoberto Minelli & Michele LanzaREVEAL @ Faculty of Inf...
Software   Analytics...
...to Mobile     Applications
...to Mobile               ApplicationsApps are software systemsaimed at smartphones, tabletPCs, and other handheld devices
Apps are written in different         Languages...C++                               Java           Objective-C      C#    ...
Apps are written in different           Languages... C++                                 Java             Objective-C     ...
The marketplace   is vast1,000,000apps to download
$4.5 billions   “Mobile application and its global impact”                R. Islam, R. Islam, and T. Mazumder [IJEST 2010]...
$4.5 billions         “Mobile application and its global impact”                      R. Islam, R. Islam, and T. Mazumder ...
$4.5 billions         “Mobile application and its global impact”                      R. Islam, R. Islam, and T. Mazumder ...
Apps are becoming more    popular...
...and evolve      over time...
...thus maintenance           is critical!
“Programs, Life Cycles, andLaws of Software Evolution”         1980           1981   1982
“Software evolution observations        based on product release history”                        “Implications of evolutio...
2006   2007   2008   2009   2010   2011
S A MO A                   Software Analytics for MObile Applications             “Software Analytics for Mobile          ...
S A MO AA web-based software analytics tool for apps
Software Analyticsfor MObile A pplications
S A MO Ahttp://samoa.inf.usi.ch
Source CodeEvolutionUse of3 rd   Party Libraries
Source CodeEvolutionUse of3 rd   Party Libraries
Source CodeEvolutionUse of3 rd   Party Libraries
Snapshot   view
<manifest xmlns:androi                        d="http://schemas. android.com/apk/res/an                        droid"  pac...
Snapshot     viewHistory   view
Snapshot     viewHistory   viewEcosystem view
S A MO ADEMOhttp://samoa.inf.usi.ch
BACK-END                                               FRONT-END                                 Source code model extract...
TheOutcome
www.F-Droid.org
...Android apps
Name                    Rate         Installs          Start rev.        End rev.         Size (LOC)Alogcat               ...
Metric    DescriptionNOP       The Number of Packages of a project.NOC       The Number of Classes defined by the user.NOM...
Metric         DescriptionNOP            The Number of Packages of a project.NOC            The Number of Classes defined ...
Metric        DescriptionNOP           The Number of Packages of a project.NOC           The Number of Classes defined by ...
Catalogue    o f c h a r a c t e r is t ic s                                                             of apps          ...
Insights &Lessons Learned
Apps are smaller than traditional software systems.                    Facts:                    ✴Average size is 5.6 kLOC...
Apps are inherently complex, mostly because theyrely on third-party libraries.                   Facts:                   ...
The size and complexity of apps grow in correlationwith the addition of third-party method invocations.                   ...
The use of inheritance is almost absent in apps.                          Average Hierarchy Height (AHH)   = 0.09We studie...
Some apps contain the entire source code of third-party libraries.                    Facts:                    ✴In Java s...
Some developers use versioning systems only at  later stages of the development.                     Facts:               ...
Some developers use versioning systems only at  later stages of the development.                               Facts:     ...
Some developers use versioning systems only at  later stages of the development.                       Facts:             ...
Developers often break the connection betweenAndroid manifest and source code.                   Facts:                   ...
Developers often break the connection betweenAndroid manifest and source code.                   Facts:                   ...
Developers often break the connection between Android manifest and source code.                       Facts:              ...
Development guidelines are often ignored.                            Facts:                            ✴Software systems s...
Some apps are only composed of the core.                                       Facts:                                     ...
...for Mobile                Apps are written in differentSoftware Analytics for Mobile ApplicationsInsights & Lessons Lea...
Apps are inherently complex, mostly because they                            The size and complexity of apps grow in correl...
Software Analytics for Mobile Applications – Insights & Lessons Learned [CSMR2013]
Upcoming SlideShare
Loading in …5
×

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

544 views

Published on

Mobile applications, known as apps, are software systems running on handheld devices, such as smartphones and tablet PCs. The market of apps has rapidly expanded in the past few years into a multi-billion dollar business. Being a new phenomenon, it is unclear whether approaches to maintain and comprehend traditional software systems can be ported to the context of apps.

We present a novel approach to comprehend apps from a structural and historical perspective, leveraging three factors for the analysis: source code, usage of third-party APIs, and historical data. We implemented our approach in a web-based software analytics platform named SAMOA.

We detail our approach and the supporting tool, and present a number of findings obtained while investigating a corpus of mobile applications. Our findings reveal that apps differ significantly from traditional software systems in a number of ways, which calls for the development of novel approaches to maintain and comprehend them.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
544
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. Software Analytics for Mobile ApplicationsInsights & Lessons LearnedRoberto Minelli & Michele LanzaREVEAL @ Faculty of InformaticsUniversity of Lugano, Switzerland Università della Svizzera italiana R E V E A L
  2. 2. Software Analytics...
  3. 3. ...to Mobile Applications
  4. 4. ...to Mobile ApplicationsApps are software systemsaimed at smartphones, tabletPCs, and other handheld devices
  5. 5. Apps are written in different Languages...C++ Java Objective-C C# C/C++, Java, etc.
  6. 6. Apps are written in different Languages... C++ Java Objective-C C# C/C++, Java, etc....and distributed via differentApp Stores
  7. 7. The marketplace is vast1,000,000apps to download
  8. 8. $4.5 billions “Mobile application and its global impact” R. Islam, R. Islam, and T. Mazumder [IJEST 2010].in 2009
  9. 9. $4.5 billions “Mobile application and its global impact” R. Islam, R. Islam, and T. Mazumder [IJEST 2010].in 2009 “Mobile application sales to reach $17.5bn by 2012” http://news.bbc.co.uk $17.5in billions 2012
  10. 10. $4.5 billions “Mobile application and its global impact” R. Islam, R. Islam, and T. Mazumder [IJEST 2010].in 2009 “Mobile application sales to reach $17.5bn by 2012” http://news.bbc.co.uk “Global mobile application market (2010- 2015)” Markets and Markets, August 2010. $17.5in billions 2012 $25 billions in 2015
  11. 11. Apps are becoming more popular...
  12. 12. ...and evolve over time...
  13. 13. ...thus maintenance is critical!
  14. 14. “Programs, Life Cycles, andLaws of Software Evolution” 1980 1981 1982
  15. 15. “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 sourceevolution revisited” software: A case study” 1996 1997 1998 1999 2000 20
  16. 16. 2006 2007 2008 2009 2010 2011
  17. 17. S A MO A Software Analytics for MObile Applications “Software Analytics for Mobile Applications – Insights & Lessons Learned”0 2011 2012 2013
  18. 18. S A MO AA web-based software analytics tool for apps
  19. 19. Software Analyticsfor MObile A pplications
  20. 20. S A MO Ahttp://samoa.inf.usi.ch
  21. 21. Source CodeEvolutionUse of3 rd Party Libraries
  22. 22. Source CodeEvolutionUse of3 rd Party Libraries
  23. 23. Source CodeEvolutionUse of3 rd Party Libraries
  24. 24. Snapshot view
  25. 25. <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" android:label="@string/ title_details" /> <activity android:name=".YetAno therActivity" android:launchMode="s ingleTop" android:label="@string/ title_configure" android:windowSoftInpu tMode="stateHidden"> </activity></application> Manifest.xml
  26. 26. Snapshot viewHistory view
  27. 27. Snapshot viewHistory viewEcosystem view
  28. 28. S A MO ADEMOhttp://samoa.inf.usi.ch
  29. 29. 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/PHPData acquisition Java SVN JSON Internet crawler Files Metrics extraction AST-based MSE-based metrics metrics
  30. 30. TheOutcome
  31. 31. www.F-Droid.org
  32. 32. ...Android apps
  33. 33. Name Rate Installs Start rev. End rev. Size (LOC)Alogcat 4.6 >100k 2 48 876Andless 4.2 >100k 2 93 2372Android VNC 4.3 >1m 2 203 4949Anstop N/A N/A 2 61 1142AppSoundmanager 4.5 >50k 1 157 1605AppsOrganizer 4.6 >1m 3 191 8321CSIPSimple 4.4 >100k 2 1415 20777Diskusage 4.7 >50k 2 69 4749Mythdroid N/A N/A 76 640 6114Mythmote 4.6 >10k 2 281 1593Open GPS Tracker 4.2 >100k 2 1255 9754Opensudoku 4.6 >1m 15 415 3813Replicaisland 4.2 >1m 2 7 14192Ringdroid 4.6 >10m 2 66 3516Search Light 4.7 >100k 2 4 272Share My Position 4.6 >10k 2 76 468SIPDroid 4.0 >500k 50 620 14019Solitaire for Android 4.3 >10m 2 30 3343Zirco Browser 3.8 >10k 65 457 6429Zxing 4.3 >50m 569 2257 3407
  34. 34. Metric DescriptionNOP 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 anAHH interface and not derived from user-defined classes. The Number of Internal Calls, i.e., invocations of methods that implementINTC internal behaviorEXTC 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.
  35. 35. Metric DescriptionNOP 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 anAHH interface and not derived from user-defined classes. The Number of Internal Calls, i.e., invocations of methods that implementINTC internal behaviorEXTC 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.“Object-oriented Software Metrics” “Object-Oriented Metrics in Practice” M. Lorenz and J. Kidd, 1994 M. Lanza and R. Marinescu, 2006
  36. 36. Metric DescriptionNOP 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 anAHH interface and not derived from user-defined classes. The Number of Internal Calls, i.e., invocations of methods that implementINTC internal behaviorEXTC 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.“Software Analytics for Mobile Applications” Roberto Minelli, MSc Thesis, 2012
  37. 37. 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
  38. 38. Insights &Lessons Learned
  39. 39. 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.
  40. 40. Apps are inherently complex, mostly because theyrely 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.
  41. 41. The size and complexity of apps grow in correlationwith 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.
  42. 42. The use of inheritance is almost absent in apps. Average Hierarchy Height (AHH) = 0.09We studied breadth and depth of the inheritance... Average Number of Derived Classes (ANDC) = 0.19Facts:✴The apps in our corpus have very small average values forboth these metrics.✴Apps tend to be small, thus there is little potential forinheritance.Implications:✴We suspect that if they evolve over a long time, they willgrow in size, according the Lehman’s software evolution laws.
  43. 43. 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.
  44. 44. 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.
  45. 45. 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. “Initial add, corresponds to On average, the LOC of the first market version✴1.8”.(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.
  46. 46. 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.Implications:✴Incomplete histories make retrospective software evolutionanalysis difficult.
  47. 47. Developers often break the connection betweenAndroid 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.
  48. 48. Developers often break the connection betweenAndroid manifest and source code. Facts: ✴As all software systems, apps are also made up of pieces which are not source code. ✴The manifest file identifies core “unbroke the app after the big subpackage reshuffle of ’09: elements of an app. Updated manifest entries [...]” ✴Developers must manually maintain this file in sync with the source code.
  49. 49. Developers often break the connection between Android manifest and source code. Facts: ✴As all software systems, apps are also 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.Implications:✴We believe that the maintenance and understanding of suchpieces will become a concern. “An empirical study of build maintenance effort” S. McIntosh et al., [ICSE 2009]
  50. 50. 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
  51. 51. 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.
  52. 52. ...for Mobile Apps are written in differentSoftware Analytics for Mobile ApplicationsInsights & Lessons Learned Applications Languages... C++ JavaRoberto Minelli & Michele LanzaREVEAL @ Faculty of InformaticsUniversity of Lugano, Switzerland Objective-C C# C/C++, Java, etc. 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 billionsin 2009 “Mobile application and its global impact” R. Islam, R. Islam, and T. Mazumder [IJEST 2010]. “Mobile application sales to reach $17.5bn by 2012” 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 LearnedEvolution History viewUse of3rd Party Libraries Ecosystem view
  53. 53. 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 softwareWe 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 isboth these metrics. Implications: (b) (c) connected to the quality of the✴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 evolutiongrow in size, according the Lehman’s software evolution laws. analysis difficult. Developers often break the connection between 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. ✴Developers must manually maintain Implications: Implications: ✴Those apps violate basic design this file in sync with the source code. ✴Multiple main activities are multiple guidelines (i.e., separation ofImplications: entry points, complicating the concerns and encapsulation).✴We believe that the maintenance and understanding of such comprehension of apps. ✴“God activities”, like god classes, arepieces 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

×