Keywords

1 Introduction

Due to modern-day rapid-changing business requirements, especially in the mobile space, and the advent of agile methodologies for tracking project status came need to continuously monitor the overall picture of energy consumption. At the beginning, it was assumed that only hardware metrics influence energy efficiency levels [1]. Lately, more focus has been given to software (code) and process related metrics [2, 3]. In order to achieve the products’ continuous delivery it is necessary in each step of software development process to help the development team to assess energy efficiency levels and suggest ways of potentially improving it. Therefore, our research tries to pinpoint the software, process and project-related metrics that have the influence on energy efficiency, and then optimizing these metrics. This paper highlights the steps we took to design, architect and develop a dashboard specifically made for the use case of monitoring energy efficiency and optimizing the set of parameters needed to be displayed to different users.

1.1 Outline of the Paper

We start by mentioning the importance of the problem we are trying to solve as well as the research hypothesis by giving a literature review in Subsect. 1.2. The primary sections containing the majority of paper’s novel contributions are Sects. 2, 3 and 4 where we decomposed our action plan and outlined all the metrics we used, and major design and architecture decisions. Here we talk at length about the aspects like technology choice, design style guide, layout, widgets, charts, security, complex systems and more. As the solution we have developed is still in its infancy, Sect. 5 pinpoints the key ways our research is going to progress with the dashboard being one of the central tools. Finally, Sect. 6 brings out some reflections.

1.2 Related Work

The field of effective dashboard design has gained traction at the beginning of the new millennium thanks to Stephen Few, among others. His “Information dashboard design” [4] is still being referenced by many. He starts by arguing that dashboards in the 1990s had major flaws, and that their root problem was in the inability to effectively communicate. Few also said that dashboards have to hold a balance between clarity and complexity [5]. With recent advances in the field of User Experience (UX) and User Interface (UI) design, dashboards started getting significantly more traction [6,7,8,9,10]. This resulted in dashboards being way more able to focus on the communication aspect, thus increasing use cases, leading to their wide-spread adoption [4]. Dashboard are becoming also of strategic importance in lean and agile environments [11, 12], to spread knowledge across workers [13, 14], and in distributed development environments [15,16,17].

Meanwhile, with the increasing popularity of mobile devices, energy efficiency has become an ever-growing concern. Recent research by Pinto et al. [2] pinpointed that energy efficiency has to be addressed at all levels of the software stack. More specifically, they argue that it is due to the developers having the lack of knowledge and lack of tools. These bottlenecks prevent software developers from identifying, fixing, refactoring, and removing energy consumption hotspots [18].

Finally, it would be advisable to take an open source approach to this topic, since it would ensure a larger diffusion of the dashboard [19,20,21].

2 Energy-Efficiency Related Metrics

In this section we describe the importance of metrics included in the dashboard we are developing. We start by providing an overview of the project as well as additional information to place the system in context. Firstly, the dashboard we are building is mainly concerned with monitoring the energy efficiency of software artifacts. The goal is to make it easy and convenient for managers as well as other users to track the energy consumption of the software. Overall, energy consumption metrics referring to the energy consumption can be divided into:

  • Process metrics

  • Project metrics

  • Product metrics

We provide several Process and Product metrics throughout this paper that encapsulate the functionality of the dashboard.

Dashboard’s primary purpose is to share important information in terms of different metrics to the end user. Determining what it is that is important to the user is the most critical part of designing the dashboard. By considering the metrics provided one would gain crucial insights, allowing them to make more educated decisions faster.

By working closely with the industry representatives, as well as consulting the literature in this field (data and findings revealed in [22,23,24,25,26]), we have come up with the list of metrics that the potential users would find most valuable [27,28,29] (Table 1).

These metrics are of paramount importance in qualifying the results of the work so that developers can judge objectively the development status. The main contribution can be directed into the energy efficient development of software in teams and individually. The proposed metrics were computed by applying rules common to the existing hierarchical measures of other internal software attributes. For example, by knowing the Number of classes in the source code we can easily calculate other metrics like: Number of Immediate sub-classes of a Class, Response for a Class, Weighted methods per Class as well as the Number of Children metric. It can be followed by better development estimates and more qualified product that can maintain the customers expectations. As it was stated in the paper [25], developers need a set of valid indicators in assisting the developers for better applications. Thus, the study results showed that Cyclomatic complexity, Number of classes, LOC, number of parameters, nested block depth, number of methods, weighted methods per class and method lines have direct relationship with power consumption of mobile applications. Authors of the paper [22] demonstrated specific coding practices for reading array length information, accessing class fields and performing invocations help to lower the overall energy consumption and improve the usability of the software.

Expanding the list of energy consumption metrics is already on our research agenda. However, not only obtaining additional metrics is of high significance. Combining the already existing ones, as well as easily modifying them is very important. Thus, Sect. 4 describes how we utilized these metrics in greater detail.

Table 1. Code metrics for the energy efficiency measurement
Full size table

3 Design, Visualization and Development

3.1 Design

S. Few in his [4, 5, 30, 31] pointed out several key characteristics that all dashboard should have. This section makes a bridge between the Sect. 2 and the design guidelines. As he (Few) puts it,

“A dashboard is a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance.”

We strongly agree with the majority of his guidelines. First, all elements of a dashboard have to have a purpose and only the most important information that truly contributes to a specified goal should be shown to the end user. A dashboard is a mean of communication, and in order to effectively convey the message to the user, the message has to be clear, concise and goal-oriented.

Message has to be Clear. The information presented on a dashboard is most commonly a combination of graphics and text, with the emphasis on visual representations. The reason is that visuals can communicate with richer meaning than text on its own. Having clear, easy to understand graphics is one of the crucial requirements from the design perspective.

Message has to be Concise. It is highly advisable to fit the main metrics of the dashboard to one screen and one screen only, without horizontal and vertical scrolling. The users should be able to easily scan through all the visuals effortlessly and obtain the insights they are looking for. If the system consists of dozens and even hundreds of smaller metrics and they all need to be shown, the ones that are less important should be moved elsewhere. Only the metrics with high level of importance should appear on the main page.

Message has to be Goal-Oriented. Whether it is to gain an important business insight, or to successfully finish a project on time, dashboard’s goal is to get users as close to their objectives as possible. What we have found is that a feedback loop, where users would report which metrics are more relevant to the goal than others, is one of the most valuable insights we could get to improve the set of metrics that get shown. This approach will be thoroughly examined later.

3.2 Visualization

As mentioned in the previous subsection, the visual representation and layout play a crucial role in designing a goal-oriented dashboard. Hence, visuals like widgets [32], graphs, charts all require special attention. Thus, we needed to develop a style guide, a set of standards and styles that all of our visual elements would conform to. It would enforce style to improve communication via consistency and clarity. The fully developed style guide can be viewed at: https://innometrics-12856.firebaseapp.com/.

Here is a comprehensive list of visual elements and containers chosen for the style guide:

  • Colors

  • Typography

  • Container Elements (cards, carousels, modals, tables, etc.)

  • Functional Elements (forms, menus, etc.)

  • Charts

We have divided colors into three parts: theme colors, grays, and additional colors. This way the theme could be changed, and the users could tune the settings to their liking. Next, typography for headings one through six, as well as bolded, italicized and underlined text has also been defined. In addition, cross-functional and organizational elements such as forms (with buttons and input fields), tables (with cells), and different types of containers also needed a well-defined set of styling rules (Fig. 1).

Fig. 1.
figure 1

Typography - headings 1 through 6

Full size image

However, the main page of the dashboard consists almost entirely of widgets and charts. As we noted earlier, it is crucial to keep the main page free of clutter and not have to scroll or click elsewhere to get to the crucial information. That is why, due to their effectiveness and expressive power, we chose to fine tune their visual appearance. Taking multiple existing charting libraries into consideration and comparing their advantages and disadvantages, we decided to go with ChartJS. It has all the visuals we wanted, such as bar, line, and area charts and allows for editing when needed. Figure 2 depicts some of them that we decided to include in our prototype.

Fig. 2.
figure 2

Different types of charts from ChartJS

Full size image

3.3 Technology

Considering the architectural decisions from Sect. 2 and design decisions from Sects. 3.1 and 3.2, choosing the platform was relatively straightforward, it had to be a web application. That means that the main programming language for development should be JavaScript (JS).

However, choosing the appropriate JS framework/library was a challenging task. There are numerous options, and all of them offer similar functionality that we need. The one that stood out and ultimately we ended up choosing is ReactJS. The primary reason being that its Virtual DOM (Document Object Model) is optimized for real-time applications and that it facilitates the overall process of writing components. Our system could potentially consist of hundreds of metrics, and reusing existing components while at the same time having impressive performance is critical.

In addition, file structure in ReactJS, although not opinionated, could be organized in very practical and clear ways. Consider, for example, our code structure, shown in the Fig. 3. It captures almost all the functionality while still remaining organized. Notice that we have left some of the implementation parts due to the lack of space.

To manage application’s state we use Redux, a flexible, and predictable state container. It allows us to easily handle user input, authentication and authorization, as well as storing the results from REST API calls. One of the main benefits of using a state container is the centralization, where application’s state and logic enable capabilities like undo/redo, state persistence and much more.

Fig. 3.
figure 3

File structure of the implementation

Full size image

4 Dashboards as Complex Systems

As mentioned in the Subsect. 3.1, all dashboards must be optimized for a certain objective. As energy efficiency became a greater problem in recent years [33], our research agenda encapsulated that. It was immediately noticeable that the majority of state-of-the-art energy efficient software solutions had a very limited and strictly defined set of metrics to optimize for.

We took a different approach to addressing energy efficiency concerns. Instead of having a fully deterministic system, one in which each and every metric is manually chosen to be displayed, we opted for a system where an algorithm would decide whether or not to display a certain metric. The system would still take into consideration the manually entered metrics, albeit not relying on them heavily. All of this would be supported by a feedback loop, where users would rate the importance of the metrics they have been shown.

4.1 Self-adaptable Systems and Energy-Efficiency Dashboards

Self-adaptable systems (systems with behavior just mentioned) have recently gained traction [34], and they could be used as an abstraction to represent the software artifact, such as a dashboard. The rationale behind choosing Complex Systems (CS) to perform the self-adaptation is the following; by definition, a CS is a system with components particularly difficult to model. As it has not yet been fully investigated which factors (metrics) influence the efficiency the most, one approach would be to try and make all combinations of metrics and record the results. However, one may notice that as the number of metrics significantly increases, generating all combinations becomes unfeasible. In addition, metrics do not necessarily need to interact with others in linear fashion [35]. In fact, most of the interactions in CS are nonlinear, and often stochastic.

Therefore, we argue that dashboards for energy efficiency applications should be represented as a Complex System. Metrics (presented in Sect. 2), key components of dashboards, become agents within the system. That allows us to closely monitor the relationships each metric has with the other. It became apparent that almost no metrics are isolated, i.e. energy saved depends on a vast majority of software metrics that interact with each other. Thus, carefully monitoring and reacting to change is critical.

By embracing feedback loop and adaptation, these metrics are able to synchronize their internal states with the other metrics in the system. Additionally, the system should be able to recognize these changes and self-adjust with the emergence of globally coherent patterns of adjustment developing. This way the system would notice a change, and adapt to it.

So far we have only discussed the interactions between the metrics contributing to the global state. However, a major part of any CS is the ability of the system to feed back the globally coherent patterns to micro-level agents. These patterns are discovered either by the system or the dashboard user. An example of a system-discovered pattern in the energy efficiency context would be battery drainage per minute. The system, if noticed irregularities, would notify the agents, and they would adjust to that situation. The next section showcases the implementation details of such an approach.

4.2 Application of Evolutionary Algorithms

To be able to achieve the self-adaptation needed from our dashboard, a mechanism for handling the fittest metrics is needed [36, 37]Footnote 1. The goal can be derived from the fitness function, which we define as follows:

Definition 1

An agent has a higher contribution/fitness to the overall system if and only if a slight change in a specific metric would yield a significant change in the amount of energy saved, the difference between the expected energy efficiency level and the current level diverge significantly, or a metric answers custom energy-related questions that users may have.

With this in mind, by applying the fitness function to each of the metrics inside the system we would get a numeric score for each of them. This tells the system how much does each individual metric influence the overall energy efficiency level of system as a whole. Furthermore, the user would be shown only the metrics particularly relevant to the current state of the system. Thus, by choosing this exact fitness function, these would follow:

  • metrics that deviate from the mean are more likely to be shown to the user;

  • metrics whose improvement may result in other metrics’ fitness are more likely to be shown to the user;

  • metrics of all sizes whose improvement would not yield a substantial increase/decrease in energy efficiency levels, have less change of being shown to the user.

The final algorithm would then run as follows:

  1. 1.

    assign a fitness score to each agent in the system (according to the fitness function defined above)

  2. 2.

    select members to act upon using some variation operators (crossover and mutations) [38]Footnote 2

  3. 3.

    replace certain members of the population with these children from variation operators

  4. 4.

    keep some members from the previous population in the new population

The next step would be then to perform the natural selection between the metrics. More specifically, we chose the tournament-like contest in which the winner would continue to breed, and the loser would be most likely eliminated [39, 40].

4.3 Dynamic Equilibrium

As energy efficiency monitoring solutions became larger, stakeholders operating such systems would have significant difficulties determining which metric to display and optimize for, and which to ignore. Such a system is said to be deterministic, as all the change has to be manually done and the system has no means of improvement.

Advances in the field of big data and machine learning indicate that the above-mentioned system architecture could be transformed to be stochastic, with no absolute governance. In addition, the data being collected is growing exponentially [41], and thus more metrics are going to become available for processing. A non-deterministic system operating in such a way would neither be in the state of maximum entropy, nor would it be completely stable. Such a state is referred to as Dynamic Equilibrium, where actors are loosely bound to each other while still having plenty of room to improve.

5 Future Research Agenda

To date, research on software-oriented energy efficiency has been focusing almost solely on code-related metrics, such as those presented in Sect. 2. However, no evidence proves the importance of process-related metrics (productivity, turnaround time, throughput, iteration burn-down, error rate, etc.) to the energy efficiency. Thus, our research agenda includes primary research to investigate the correlation of above-described metrics to the energy consumption and saving levels.

In addition, we aim to extend the list of energy consumption code metrics considered by the dashboard. For example by knowing the Number of Classes (NoC) in the source code we can easily calculate other metrics like: Number of Immediate sub-classes of a Class, Response for a Class, Weighted methods per Class as well as the Number of Children. This may lead to performance benefits and ultimately savings in computing power. Performance is one of the key aspects that is also a part of our research agenda.

Finally, we would like to supplement metrics with a reliable prediction system [42,43,44,45].

6 Conclusions

Energy efficiency, the minimization of the amount of energy required to provide products and services, has become a growing issue. Mobile phones, smart watches and other portable devices operate in a very power-constrained environment. Research in the area of energy efficiency would facilitate the efforts to cut energy costs, and ultimately reduce greenhouse gas emissions [46].

Advent of software solutions, on the other hand, have profoundly impacted almost all spheres of human existence. To date, more attention has been given to the study of energy efficiency in hardware, rather than in software [47]. This paper considered code, as well as process and project-related metrics as indicators of potential energy savings. Additionally, we presented a dashboard that tracks such metrics and only displays the ones that are most relevant. It manages to do so by combining the notions from Complexity Theory (Non-linear dynamics, Dynamic Equilibrium) with Evolutionary Algorithms (natural selection) to synthesize an adaptable stochastic tool.