Leyes y Decretos Nacionales

Based on the requirements discussed in the previous section, this thesis proposes a process for the semi-automated benchmarking and energy labeling of mobile applications. The overall process consists of five steps (cf. Fig. 5.1): (1) service modeling, (2) service model binding, (3) benchmarking, (4) usage modeling, and (5) energy consumption estimation. All five steps are described in the following in more detail.

(1) Service Modeling

To compare mobile applications from a usage domain, a prerequisite for their compari- son is the identification of representative use cases (cf. /R5-1/). Thus, during service modeling, general use cases for a usage domain are specified, resulting in a service model comprising these use cases (e.g., the service model for the usage domain of email clients can comprise use cases such as checking for new mails, reading a mail, and writing a

5.2. The Labeling Process at a Glance

mail). The service model can be understood as a set of typical states, an application of this domain can have (e.g., waiting for the selection of an email account, waiting for the selection of an email in an inbox, and displaying a specific email) and a set of transitions between these states, representing typical user interactions (e.g., selecting an account, selecting a mail to be opened, and closing a mail).

Afterwards, based on the service model, abstract test cases, forming the benchmark for the usage domain are defined (cf. /R5-2/). They can be understood as paths through the service model (e.g., a sequence of transitions to open an email account and selecting an email to be read). Besides, they define test data to execute the respective paths for an AUT (e.g., the name and login of an email account or the text of an email to be sent). Theoretically, such paths can be derived from the service model automatically (e.g., by applying test case generation tools relying on graph coverage). However, defining such test cases manually will result in more representative test cases and, thus, more accurate benchmarking results for the evaluated usage domain.

Together, the service model and the abstract test cases form an abstract benchmark which specifies, how to profile an application of a certain usage domain (e.g., email clients). The technical realization of these test cases for each application (e.g., which buttons, text fields, etc. have to be used to run the tests for a certain email application) is not part of the service model, but is part of the the following, second process step.

When realizing the benchmarking process for a market place providing energy labels for mobile applications, the service modeling step would be realized by a benchmark designer. A benchmark designer has sufficient domain knowledge for a specific usage domain, being able to extract typical services and to design representative abstract test cases. Although theoretically application vendors could be responsible to design such a benchmark, a neutral institution or the market place provider should be responsible for service modeling to avoid benchmarks designed in advantage for specific applications belonging to the respective usage domain.

(2) Service Model Binding

If a new application shall be evaluated, the abstract test cases have to be concretized for this application (cf. /R5-3/). Thus, during service model binding, the transitions of the service model are bound to sequences of application-specific UI interactions (e.g., the transition open inbox is bound to a click event on the button “inbox”). The result is a set of concretized test cases for the application, ready for execution. The advantage of binding the individual transitions of the service model to UI interactions instead of writing the testing code for each abstract test case, is that the code of a bound transition can be reused for each concretized test case including this transition. Thus, large amounts of the test code can be derived and generated from the service model and the binding in an automated manner. How the abstract test cases are concretized or bound to a specific application and how the testing code is generated, is described in more detail in

5. An Energy Labeling Process for Mobile Applications

Chapter 6.

As application vendors or developers typically know their applications best, they should be responsible to deploy their applications together with a service-model binding in the market place. However, the deployment of test cases by the vendors together with their applications requires trust that vendors will not realize dummy bindings, leading to test cases causing less energy consumption than the use cases intended for bench- marking. Thus, it could be sensible, to investigate test cases provided by application vendors by a neutral organization, either based on spot tests or in a systematic manner. (3) Benchmarking

Once concrete test cases for an application are available, they can be executed and pro- filed (cf. /R5-4/). This process step is majorly realized by reusing the JouleUnit profiling framework presented in Chapter 4. As in the context of an automated benchmarking pro- cess for mobile applications in a market place (cf. /R5-8/) an automated energy profiling is required, the profiling service introduced in Section 4.5 is applied for benchmarking. The benchmarking step results in an energy model for each profiled application, describ- ing its energy behavior in the context of the specified use cases. The energy model can be considered as being a simple path-based set of measured mean power rates for the individual profiled test cases, or an automata-based model providing energy annotations for all transitions of a service model (e.g., transitions such as displaying an email or sending an email are annotated with power rates expressing the mean power rate of the application when being in these states). Both energy modeling approaches are discussed in more detail in Section 6.3.

As mentioned above, the benchmarking process step can be performed in an automated manner. However, application vendors should be able to investigate the results for their applications, to identify potential for optimization within their applications.

(4) Usage Modeling

Although the benchmarking results are sufficient to compare the energy consumption of mobile applications, their average power rates can be highly influenced by the usage behavior of individual application users. Thus, it is sensible to adapt the approxi- mation of average power rates to the usage requirements of individual application users (cf. /R5-5/). Thus, during usage modeling, the usage behavior of individual users is modeled. In this thesis, two different options to construct a usage model are considered. First, application users can estimate their usage behavior by creating a usage model manually, by simply rating the importance of individual use cases (e.g., a user can specify that he is writing five times the emails he is reading on his mobile device). The second possibility is to derive a usage model by gathering all necessary information automatically. This can be achieved by installing a special usage recording application,

5.3. Summary

constantly monitoring the user’s usage behavior on his mobile device for applications of the respective usage domain. The resulting usage model can either be a simple set of weights for the individual use cases of a usage domain, or again metadata annotating the transitions of the service model with average durations (e.g., the average time to browse mails in the inbox) and statistical information (e.g., how often an email is written). Both usage modeling approaches, as well as the automated logging of usage data and the derivation of usage models are discussed in more detail in Chapter 7.

Depending on whether the usage model is created by the user or derived from recorded usage data, the usage modeling step can be either executed automatically or performed by the application user manually.

(5) Energy Consumption Estimation

After modeling a usage-domain specific benchmark, profiling the energy consumption of the respective applications, and selecting or creating a usage model, the gained energy and usage models can be combined to approximate the average energy consumption of mobile applications (cf. /R5-6/). By exchanging or altering the usage model, the approxi- mation can be adapted to other usage scenarios. Moreover, for energy approximations for other mobile devices, the energy model can be exchanged. This way, the labeling process allows for an easy adaptation to other user, software and hardware contexts. Based on the energy consumption estimates for a usage domain, energy labels can be specified for each profiled application (cf. /R5-7/).

The final process step of energy estimation can be realized in a rather automated manner. Application users searching for mobile applications are only responsible to specify queries against the market place’s database and the energy labels of applications belonging to the respective usage domain are computed automatically. How energy consumption estimation and the computation of energy labels can be realized is discussed in more detail in Chapter 8.

5.3. Summary

In this chapter, a process for the semi-automated energy profiling and labeling of mobile applications has been presented. General requirements for the energy labeling of mobile applications have been analyzed, resulting in a process consisting of five steps, being (1) service modeling, (2) service model binding, (3) benchmarking, (4) usage modeling, and (5) energy consumption estimation. The process steps service modeling, service model binding, and benchmarking are discussed in more detail in Chapter 6. Following, Chapter 7 focuses on the usage modeling more specifically. Afterwards, Chapter 8 discusses multiple solutions for the energy consumption estimation process step. Finally, Chapter 9 evaluates the overall process for multiple usage domains.

6

Applying Model-Driven Technologies for

Energy Benchmarking

The last chapter presented a process for the energy labeling of mobile applications. This chapter focuses on the three first process steps in more detail, being (1) service modeling, (2) service model binding, and (3) energy benchmarking. It is shown, how techniques from MDSD and MBT can be applied to ease the specification of service models and application-independent test cases, as well as to automate the generation of concrete test code, representing the benchmark instantiations for individual applications. Afterwards, the derivation of energy models from the benchmarking results is discussed. Finally, this chapter comprises a short summary of the implementation of these three process steps for Android applications.

The contributions given in this chapter are the following:

• A mechanism specifying service models for usage domains and benchmark test cases in an application-independent manner (Section 6.1).

• A mechanism binding these application-independent test cases to applications in a way that executable testing code can be generated from these specifications without further source code modifications (Section 6.2).

• Two different energy modeling approaches to derive and store energy con- sumption information from the benchmarking results, for individual appli- cations of a usage domain (Section 6.3).