-Measuring specific software quality requirements in a continuous way and at runtime all along the development processes is crucial. Moreover, considering principles of measurement theory, it is still very complex to integrate green metrics in a common standardized and autonomous framework. In our approach, we propose an automated solution based on continuous analysis of SW green measurements, using at runtime a machine learning algorithm. The method allows to suggest and aid in the decision of the use of new or updated green metrics during the software measurement processes. Experiments are performed on the greentrace datasets.
and management factoid that has to provide useful metrics for quality requirements. Currently the assessment of these quality requirements is not automated, not empirically validated in real contexts, and the assessment is often defined without considering principles of measurement theory. Further, it is still very complex to integrate green metrics in a common standardized framework. Besides, it is difficult to understand where and how to improve the software (SW) following obtained measurements and green requirements. The main challenges are to define adequate and useful green metrics for quality requirements, software design documents and other SW artefacts (e.g., testing). Most of the time, the obtained measures are manually analyzed to target the specific requirements that have to be improved. Further, the ways of designing/integrating green concepts in a system, or to measure them on a SW, are often based on know-how and best practices transmitted between specifiers or developers.
The main scientific problematics that are tackled in our work are: (i) formally defining metrics and its supporting tools for measuring modern SW engineering activities with respect to green concepts, (ii) automatically analyzing the measurement results for identifying unexpected or undesired SW data, and (iii) the measurement process automation in order to reduce the development time. The herein approach proposes a highly automated and easy-to-deploy solution based on continuous analysis of SW green measurements, using at runtime, a machine learning algorithm. It aims at defining, in an autonomous manner, updated green SW metrics or new ones that can be applied to the measured software in a recursive process. The metrics are chosen from the analysis of the measurements and the use of a runtime machine learning approach. Our methodology allows to improve the SW quality, to reduce the time to process, the software greenability and to decrease the development costs.
We summarize our main contributions as it follows : (i) a formal description of a green SW metric using the standard SMM, (ii) an autonomous SW green measurement framework based on a machine learning methodology to analyze the measures at runtime, and (iii) experiments based on the greentrace dataset illustrated our approach.
The paper is built as followed: Section II provides the state of art on green SW measurements. Section III presents the ITEA3 project MEASURE, Section IV defines our methodology, Section V describes the OMG standard and experiments in Section VI before concluding in Section VII.
literature for many years now. A measurement can be
defined as “single-point-in-time data on a specific factor to
be measured" produced as “results of data collection,
analysis, and reporting”. A metric is seen as a "descriptions
of data derived from measurements” [
Besides, while there is a current need for providing valid
metrics, the literature still contains a highly diverse set of
opinions on what constitutes a valid and efficient metric [
ITEA3 project has started in December 2015 [
As above mentioned, we aim at improving the software
measurement processes by focusing on an autonomous SW
green metric framework. This approach is based on a
learning methodology allowing to analyze the results at
runtime and during all along the software development
process. Indeed, the main objective is to guide the
measurements in a smart way by automatically refining it.
Based on the measurements analysis and its interpretation,
the next metric to be executed will be determined. It can be a
novel metric which is the intersection of several metrics or
one metric of the set initially defined. Then, they are
provided as inputs to a new SW measurement cycle
(containing notably the analysis and metric generation). By
that way, a continuous measurement process on the SW
architecture is defined, allowing, for each cycle, to execute
the refined metrics or other metric, and to target suspicious
failing aspects that could eventually cause green deficiencies.
The Fig. 1 illustrates our approach. To perform the
measurement cycle, our approach uses a machine learning
process. From well-defined measurements classifications,
based on expert decisions or known datasets, and obtained
experimented results, we intend to detect suspicious or faulty
values. We target specific quality aspects of the measured
SW by applying, at runtime, new updated sets of metrics.
The S3VM (Semi-Supervised Support Vector Machines)
learning method [23] is herein used. Semi-Supervised
techniques allow a smart analyze in real time and during all
the development process. The learning process occurs on the
results of measures (measurements) applied on the software
architecture. For that purpose, two datasets are needed: one
for training, one for working. Training data are labeled and
working data working are unlabeled. Based on training data,
a Semi-Supervised algorithm is learning on working data, to
provide a separating hyperplane that classifies data into
different categories. The S3VM features aim at adding two
constraints to each working data in order to minimize the
classification errors. In our approach, we aim at using a set
of green software metrics values, the “greentrace” dataset
from the PROMISE public repository [19]. Greentrace
contains the mean power consumption and the corresponding
invocation count of system calls [
using the tool Modelio [24]. One of our aims is to allow that tool to refine the running metrics into a continuous measurement process. We plan to obtain the green SW measurements using specific SW tools such as MMT provided by Montimage, a MEASURE partner.
The version 1.1.1 of the SMM specification [
As illustrated in the Fig. 2, the SMM meta-model allows to represent abstract Measures and concrete Measurements. For example, it would allow to represent a measure like Lines of Code and a measurement like File X has 537 lines of code. A SmmModel contains therefore MeasureLibraries and Observations. Measures are grouped into MeasureLibraries so that they can be shared among different projects and tools. Each Observation represents an observation performed by an observer, with a tool on a given moment (whenObserved). An observation produces a set of ObservedMeasures, each of them related to one specific Measure, and for this measure, a set of Measurements.
Modelio [24] is a modeling environment based on UML (Unified Modeling Language). It defines all UML concepts as mainly Interface, Class, Package, Attribute, Property, etc., and relationships between those entities as inheritance, implementation, association etc. Modelio allows to model software and business architectures and to generate XMI files from a model. From a model, it supports the code generation to C or Java. Modelio supports several OMG’s standards like SysML, MARTE, SoaML, UTP and SMM. This environment offers the possibility to extend its functionalities with the module addition which allows to create a new concept by specifying existing concepts.
Our approach is applied on a real case study as defined in
[
As defined in [20], to compute the Computational Energy Cost of a Java-based software at component-level (public interface), it is necessary to compute the energy costs of the architecture JVM’s bytecodes, its native methods and its monitor mechanism execution while the interface method is invoked. The monitor mechanism, provided by the JVM, is used to manage threads synchronization.
To specify the Computational Energy Cost metric (CECm) in SMM, we define three measures which refer to those three cost types. One for the bytecodes execution cost called BytecodesMeasure (BM), one for the cost of native methods invoked called NativeMethodMeasure (NMM) and one for the monitor mechanism cost called MonitorMeasure (MM). We modeled the Computational Energy Cost metric in SMM using Modelio. The model is illustrated in the Fig. 3. This model is made of two SMM packages: Measure Library contains all aspects about measures and Observation contains the measure results. For each measure, a measurement is modeled by a UML class in the Observation package. Each of them is linked to its associated measure by an association UML link called ObservedMeasure. Concerning the Measure Library package, the three measures are modeling by a UML class and are associated to their unit of measure class called Joule, by an association link called UnitLink. Those are associated to a Scope element named JVM that defines the domain of measurement. The three measures compute different values of the same domain and return the same unit of measure. That is the reason why they are associated to the same Scope with a ScopeLink and Unit element. We reason in a similar way for the Characteristic element called EnergyConsumption. It computes the energy consumption of elements of the same domain. The measure elements are matched to their characteristic by the TraitLink.
In our experiments, we aim at measuring the computational energy cost of a Java-based application as a mailbox call, which offers services such as sending, removing and saving data. During its real use by a user and as above-mentioned, our approach is learning on the greentrace dataset and obtains the three values corresponding to CECm measurements applied on that Java-based application. Each value is classified by the S3VM algorithm within two categories: suspicious value and not suspicious value. This classification is based on expert decisions concerning the threshold for this type of measurement. Herein the threshold is set to 20. Results strictly higher than 20 may reveal an issue. When the classification is done, the detected suspicious values are analyzed to determine the best next metric to run: one already defined or a correlation of several already existing metrics which is more specific to the measure of the corresponding suspicious value.
For instance, in our experiments, we obtained the
following CECm measurements as illustrated in the Table 1.
Based on [
They are used to execute, recursively, a novel green software measure process cycle to determine an application anomaly.
In this paper, we presented a novel autonomous software green measurement framework based on a machine learning methodology. It allows to improve the actual sequential and trace measurement process by analyzing the measures results in real time. We aim at improving the next measurement cycle to have information of possible failure during the development process. This smart measurement is then applied to the measured application (or system, service, embedded component, etc.) in an autonomous and recursive manner. Experiments based on the greentrace dataset are also performed to illustrate the feasibility of our approach.
Currently, our approach is based on the greentrace dataset while the common knowledge, good practices and know-how of the practitioners are not available online through a database or dataset. We plan to use such concepts to allow a better and refined learning classification (>2 classes) to improve the “metric management”. Further, through the MEASURE project, we expect to integrate our approach in a whole tool chain from the SMM modeling to the metric execution and measurements analysis.
by the ITEA3 project 14009, MEASURE. [19] PROMISE, greentrace dataset, http://openscience.us/repo/greenmining/greentrace.html