Deriving Energy Models from Profiling Results

application. Thus, additional test cases can be realized rather easily by defining new sequences of transitions within the abstract benchmark specification or by duplicating existing sequences with new test data. The concrete test cases can be derived and generated afterwards for all applications bound with test case bindings to the respective usage domain, saving a large amount of implementation effort and, thus, development time. Besides the eased implementation of new test cases, existing test cases can be modified and extended rather easily. Similarly, if an application evolves (e.g., if the text of a button to be pressed to trigger a specific transition changes), the transition mapping has to be adapted only once. All related test cases can be updated (by regeneration) automatically. As each transition is defined only once, besides the general reduction of redundancy of UI interaction code, also the likelihood of implementation errors is reduced. If a transition mapping is erroneous, it is very likely that the fault will appear within one of the affected test cases, and thus, all test cases using this transition will be corrected soon.

Besides the advantages of separating abstract test cases and concrete transition map- pings, this approach also introduces a drawback during test code maintenance. The separation of abstract test case definitions and concrete transition mappings leads to maintenance processes being more hard to comprehend. Instead of modifying indivi- dual test cases, abstract test cases and related transition mappings have to be modified separately. However, it is always possible to investigate the resulting testing code to understand the impact of the latest changes. Tooling for round-trip engineering and traceability (e.g., by applying the techniques of Seifert [113]) could help to decrease the impact of this drawback (e.g., by allowing the modification of generated testing code and propagating the changes to the test case binding automatically).

6.3. Deriving Energy Models from Profiling Results

Once application-specific test cases have been generated, they have to be executed to retrieve comparable energy consumption information for the respective application (cf. /R5-4/). As the JouleUnit framework presented in Chapter 4 is reused for this process step, the test case execution and energy profiling are not described in the following. However, the resulting energy consumption information has to be stored as an energy model to allow the computation of average energy consumption values and energy labels afterwards (cf. /R5-6/). Thus, in this section, two different alternatives for energy models are discussed: (1) a simple path-based energy modeling approach, storing the profiling results as simple tuples of average power rates and execution times for each profiled test case, and (2) a test-case independent, automata-based approach that extracts the average power rates for the individual transitions of the service model and stores them as metadata for the service model. In the following, both approaches are presented, together with a discussion of their advantages and disadvantages.

6. Applying Model-Driven Technologies for Energy Benchmarking

6.3.1. A Simple Path-Based Energy Model

The first, energy modeling approach takes the average profiling results for individual executed test cases and stores them in a simple tuple-based manner:

Given is:

• A set of use cases Ud={u1, u2, . . . un} for a usage domain d.

A path-based energy model EMa, for an application a belonging to the usage domain d is defined as:

• EMa ={(p1, et1), (p2, et2), . . . (pn, etn)}, being a set of tuples (pi, eti) for each path (or use case) through a service model ui; whereby pirepresents the average power rate profiled for this use case and eti represents its average profiled execution time.

For example, if the test cases defined for the email example given above were profiled and an energy model EMak9mail for the K-9 Mail application would be derived, this energy model could be specified as follows:

• Ue={u1, u2, . . . un} = {CheckF orMails, SendMail, . . . BackgroundService}

• EMk9mail ={(1.61W, 10.6s), (1.39W, 111.8s), . . . (0.25W, 900.0s)}

6.3.2. An Automata-Based Energy Model

As a second possibility for the derivation of energy models, an abstraction from the specific results of individual profiled test cases is proposed. The major idea is that, instead of storing average power rate values for the individual profiled test cases, the average power rate values for the transitions defined in the service model are stored (e.g., the average power rate for the transitionopen accountis computed as the average power rate from its execution in all profiled use cases). Therefore, the energy model does not express the average power rates for individual test cases, but can be used to approximate the energy consumption of (1) the profiled test cases and (2) other use cases defined on the service model, not being profiled, by simulating their execution on the energy model.

Given is:

• A service model SMd= (S, sinit, sf inal, T ), for a usage domain d, as defined in Section 6.1.

An automata-based energy model EMa for an application a, belonging to the usage domain d is defined as follows:

6.3. Deriving Energy Models from Profiling Results

• EMa={(p1, et1), (p2, et2), . . . (pn, etn)} is a set of tuples (pi, eti) for each tran- sition ti ∈ T ; whereby pi represents the average power rate profiled for this transition and eti represents its average execution time. eti may remain unde- fined (eti= ), if a transition’s execution time depends on user interaction and has thus, to be specified by the respective user.

Figure 6.3 shows an example graphical representation of a automata-based energy model

EMk9mail for the email client service model defined in Figure 6.1 and the profiled energy

consumption for the K-9 Mail mail client application. As can be seen, all transitions are annotated with average power rates, except for thestart,startApp,stop, andstoppApp transitions, which have not been profiled, as the K-9 Mail mail client is initially started it itsApplicationStartViewand thus, the transitions can be considered as having zero execution time and thus, zero power rates.

Besides the average power rate of each transition, a automata-based energy model requires average execution times of each transition, as both values are required to com- pute the average power rate or consumed energy of a use cases approximated on this energy model afterwards. However, in some cases it is more sensible to derive the exe- cution time values from the user’s usage model, as some transitions my highly depend

start app [0mW, 0s] stop app [0mW, 0s] add account [1590mW, 71.4s] delete account [1529mW, 14.4s] stop [0mW, 0s] start [0mW, 0s] Background Service start background service

[0mW, 0s]

stop background service [0mW, 0s] run in background [253mW, ε] Account View Mail Compose View close account [1852mW, 3.2s] open account [1699mW, 2.7s] open mail [1662mW, 2.1s] close mail [1768mW, 1.7s] read mail [1520mW, ε] open attachment [1695mW, 6.3s] check for mails

[1800mW, 3.9s] browse mails [1614mW, ε] send mail [2099mW, 6.7s] forward mail [1928mW, ε] delete mail [1691mW, 6.5s] write mail [1563mW, ε] add attachment [1715mW, ε] Application Start View Mail View new mail [1893mW, 1.6s]

Figure 6.3.: Example energy model for the K-9 Mail mail client application and the service model defined in Figure 6.1.

6. Applying Model-Driven Technologies for Energy Benchmarking

on the user’s usage behavior (e.g., it is likely that different users have different exe- cution times for the write mail transition of the email client service model shown in Figure 6.1). Therefore, the energy model shown in Figure 6.3 shows execution times for some transitions, where execution times for other transitions are declared to be filled by the respective usage model of a user whose average energy consumption for the respec- tive application shall be computed (e.g., for the transitionswrite mailandread mail, marked with an ε in Figure 6.3). The information which transitions depend on the user’s interaction speed and, thus, on execution times provided by the usage model should be declared within the service model (e.g., by introducing two types of transitions declaring the origin of their execution time), to ensure that the energy and usage models of all applications and users belonging to the usage domain provide execution times for the same transitions.

Once power rates and execution times are given, an automata-based energy model can be used to approximate energy consumption values for the profiled as well as other use cases based on the transitions from the service model (e.g., a use case sending multiple mails or sending, receiving and reading mails alltogether). Therefore, a usage model defining probabilities for individual transitions of the service model is required. How such a usage model can be defined is discussed in more detail in Chapter 7. The approximation of a user’s average energy consumption for a specific application based on an energy model and a user model is described in more detail in Section 8.1.

6.3.3. Advantages and Disadvantages

Both energy modeling approaches come together with advantages and disadvantages. Whereas the path-based energy model is limited by representing the energy consumption of the profiled test cases only, it is both less complex and likely to be more accurate for the profiled use cases; as their profiled power rates and execution times are not mixed up in average values for the individual transitions of the service model. However, it is limited to the profiled test cases and therefore, new profiling runs are necessary, whenever other scenarios and use cases than the beforehand profiled scenarios shall be considered. It is therefore, more limited w.r.t. the adaptation of the energy model to the users’ individual usage scenarios and requirements.

The automata-based energy model, in contrast, is more abstract and thus, allows for the consideration of further use cases, for which no real energy measurements have been done. However, the approach is more likely to introduce approximation errors. Power rates for the individual executed transitions within the executed test cases are bundled in an average power rate for each transition, which may be less accurate for the respective transition in the context of individual use cases. Especially for transitions whose power rate is context-dependent (e.g., the average power rate of the transition send mail in Figure 6.3 may highly vary for use cases were the respective mail includes or excludes an attachment), an average power rate over all its uses may introduce high errors, due