-
Notifications
You must be signed in to change notification settings - Fork 1
Code Quality Metrics
Rationale: this kind of metric is aimed at providing a quantitative measure of the software in terms of co de sizes and mo dularity. Despite a large code size can be a symptom of a lot of provided features, it might led to an higher probability to contain bugs [1].
| Metrics | Description | Measuring Method |
|---|---|---|
| Number of Byte- code Instructions (NBI) | This metric counts the total number of smali byte-code instructions, ignor- ing comment lines and blank lines (i.e., NCLOC) |
This metric is evaluated by counting all the smali byte-code instructions not beginning with the characters “#” (since it introduces a comment line) and “.” |
| Number of Classes (NOC) | This metric computes the number of classes within the app package | The metric is computed by counting the occurrences of the “.class” directive within the smali files |
| Number of Methods (NOM) | This metric estimates the amount of methods within the app package | The metric is computed by counting the occurrences of the “.method” directive within the smali files |
| Instructions per Method (IPM) | This metric is computed by the proportion between the total number of instructions (i.e., NBI) and the total number of methods (i.e., NOM) | The metric is computed through the formula IPM = NBI/NOM |
[1] Tian et. al. - What are the characteristics of high-rated apps? a case study on free android applications
Rationale: this kind of metrics estimate the complexity of applications. Since program comprehension is closely related to program complexity, these indicators help us in understanding how expensive is the comprehension of a product when testing activities have to be done. A more complex program has more possible paths of execution, so it is difficult to test fully. More complex programs are also more difficult to understand and maintain [2].
| Metrics | Description | Measuring Method |
|---|---|---|
| Cyclomatic Complexity (CC) | This is a complexity metric introduced by Thomas McCabe. This metric measures the number of linearly independent paths contained in the control flow of the program | We computed this metric by counting the occurrences of conditional instructions contained in the smali files and incremented the resulting number of a unit. For calculating the average cyclomatic complexity of app’s classes we used the formula CC = (#ifinstructions + 1)/ NOC
|
| Weighted Methods per Class (WMC) | This is a complexity metric introduced by Chidamber and Kemerer. The WMC metric is the sum of the complexities of all class methods | For each app we computed the average of this metric, through the formula: WMC = (NOM/NOC) * #paths |
[2] Taba et.al. - An Exploratory Study on the Relation between User Interface Complexity and the Perceived Quality.
Since the mobile apps are implemented with object-oriented programming languages (i.e., Java, C++, C#, etc.), it is possible to assess the quality of applications’ code by using the metrics suite by Chidamber and Kemerer: a set of metrics which measure the code’s complexity, cohesion and coupling [3]. The “CK” metrics suite is a widely accepted standard for measuring object-oriented software systems.
| Metrics | Description | Measuring Method |
|---|---|---|
| Number of Children (NOCH) | This metric indicates the number of immediate subclasses subordinated to a class in the class hierarchy. Greater is the number of children, greater is the reuse, but if a class has a large number of children, it may require more testing of the methods in that class | In smali byte-code the parent of a class is identified by the .super directive. We used this to build a tree data structure in memory representing the class hierarchy. In order to reduce the data to a single value per app, we considered the maximum number of children for any class in the app |
| Depth of Inheritance Tree (DIT) | This metric indicates the depth (i.e., the length of the maximal path from the node representing the class to the root of the tree) of the class in the inheritance tree. Deeper trees constitute greater design complexity, since more methods and classes are involved | We considered the depth of each inheritance tree, found using the .super directive as discussed in the previous metric. In order to reduce the data to a single value per application, we considered the deepest tree for any class in the application |
| Lack of Cohesion in Methods (LCOM) | This metric indicates the level of cohesion between methods and attributes of a class | The level of cohesion is retrieved by calculating the number of access to each data field in a class, and find the average. Subtract from 100 to obtain a percent lack of cohesion. Lower percentages indicate greater cohesion of data and methods. In the smali byte-code, the class attributes are marked by the keyword .field and the access to a field is indicated by the “->” operator |
| Coupling Between Objects (CBO) | This metric indicates the dependency degree of a class by another one | The metric value is obtained by counting the external methods invocations, that in smali code are introduced by the keyword invoke-static
|
| Percent Public Instance Variables (PPIV) | This metric indicates the ratio of variables introduced by a public modifier |
We computed the average of this type of variables among all the classes of the app |
| Access to Public Data (APD) | This metric counts the number of accesses to public or protected attributes of each class |
We computed the average of this value among all app’s classes |
[3] Chidamber and Kemerer - A metrics suite for object oriented design
Rationale: previous research [4] showed that (i) app interfaces design, (ii) performances, (iii) battery power consumption issues, are factors impacting users' quality of experience. Thus, the Android-Oriented Metrics are aimed at evaluating aspects in the applications' code directly affecting these elements. In particular, they focus on the (i) management of resources (i.e., battery, storage and network), as well as the (ii) handling of possible error conditions, which could cause application not responding (ANR) messages
| Metrics | Description | Measuring Method |
|---|---|---|
| Bad Smell Method Calls (BSMC) | Kechagia and Spinellis individuated 10 Android methods throwing exceptions that can cause app crashes. These methods have to be invoked in a try- catch block |
We computed the number of times these methods are invoked outside a try-catch construct. |
| WakeLocks with no timeout (WKL) | A WakeLock allows to keep the device in an active state, avoiding the switch- off of the display. On a WakeLock object the following methods could be invoked: (i) the acquire() method to keep active the display, and (ii) the release() method to allow the display switch-off |
We the number of times in which only the acquire() method is invoked without invoking the release() method |
| Number of Lo- cation Listeners (LOCL) | Through the class LocationListener an Android application can keep track of the user’s position. However this functionality reduces the battery power |
This metric computes the number of times a LocationListener object is instantiated |
| Number of GPS Uses (GPS) | Location-aware applications can use GPS to acquire the user location. Although GPS is more accurate, it quickly consumes battery power | We count byte-code instructions containing the gps string |
| XML Parsers (XML) | In Android applications, event-based parsers have to be preferred because this kind of parsers can save the battery power | We count byte-code instructions of the type invoke-static(.*?) Landroid/util/Xml; ->newPullParser()
|
| Network Timeouts (NTO) | Network timeouts are mechanisms which allow app developers to set time limits for establishing a TCP connection. Without setting a timeout can produce ANR messages | We count all the smali byte-code instructions of the type: invoke- static(.*?) Lorg/apache/http/ params/HttpConnectionParams; ->setConnectionTimeout” and “invoke-static(.*?) Lorg/apache/http/ params/HttpConnectionParams; ->setSoTimeout
|
| Networking (NET) | In Android applications all the networking operations could introduce latency and consequently cause an Application Not Responding(ANR) message | To evaluate this type of metric we count all the smali byte-code instructions of the type: Landroid/net/ http/AndroidHttpClient; - >execute and “Lorg/apache/ http/impl/client/DefaultHttpClient; ->execute
|
| File I/O (I/O) | I/O operations could cause ANR messages, since even simple disk operations could exhibit significant and unexpected latencies | We count the occurrences among smali byte-code instructions of the invocation: new instance(.*?)Ljava/io/File
|
| SQLite (SQL) | The database accesses can generate substantial amount of expensive write operations to the flash storage, with obvious latency implications | To evaluate this metric we count the occurrences among byte- code instructions of the invocation: Landroid/database/sqlite/ SQLiteDatabase;->(.*?)
|
| Bitmaps (BMAP) | Processing of large bitmaps could be computationally expensive and produce ANR messages | For this metric assessment we count the occurrences of the method invocation BitmapFactory.decode
|
[4] Ickin et.al. - Factors influencing quality of experience of commonly used mobile applications