HADAS: Asistente de eco-eficiencia con repositorio de consumo energético

HADAS: Asistente de eco-eciencia con repositorio de consumo energético Daniel-Jesus Munoz, Mónica Pinto y Lidia Fuentes Universidad de Málaga, Andalucía Tech, Spain {danimg,pinto,lff}@lcc.uma.es , http://caosd.lcc.uma.es/ Resumen El interés por la Ingeniería del Software verde, o sea, sensible al consumo de energía, es relativamente reciente. Su objetivo es concienciar a los desarrolladores de software de la inuencia que tienen sus decisiones de diseño e implementación en el gasto energético del producto nal. Hasta el momento se han publicado muchos resultados experimentales que comparan el consumo de energía de varias soluciones alternativas, y que demuestran que se puede reducir dicho consumo hasta en un 70%. Aunque estos resultados sean de libre disposición, no es sencillo que un desarrollador aplique este conocimiento a sus aplicaciones. En consecuencia, en este artículo presentamos el eco-asistente HADAS cuya utilidad es: (i) los investigadores almacenarán sus resultados en un repositorio de libre disposición; (ii) los desarrolladores podrán razonar y obtener las conguraciones que menos energía consuman y que satisfaga sus requisitos. Nos centraremos en mostrar los elementos principales de nuestra propuesta y como se aplica a casos de estudio reales. Keywords: CVL, Energía, Línea de Productos Software, Variabilidad, Java, Servidor. 1. Introducción Las políticas eco-ecientes, que persiguen la eciencia energética, son una preocupación creciente, debido a las emisiones de CO 2 y al efecto invernadero, provocado en parte por los sistemas de información de uso personal e industrial. Aunque el software no consume directamente energía, sí que tiene impacto en el gasto energético del hardware donde se ejecuta (ej.: un dispositivo móvil). Este impacto del software en el consumo de energía no es precisamente despreciable, por lo que recientemente ha surgido un interés por concienciar al desarrollador de software, de la inuencia que tienen sus decisiones de diseño e implementación en el gasto energético del producto nal. Por tanto, el desarrollador de software no solamente debe tener en cuenta la modularización, rendimiento o mantenibilidad del software, sino que también debe tener en cuenta el ahorro energético. El interés por las tecnologías de información verdes y en especial por la Ingeniería del Software sensible al consumo energético (Energy-aware Software Engineering [10]) es relativamente reciente. La mayoría de los trabajos sobre e- ciencia energética del software son estudios empíricos que se centran en estudiar qué partes del código son las que consumen más energía [7,14,15], o en comparar el consumo energético de varias soluciones alternativas [2,5,8,10,16]. Existen artículos que comparan el consumo de energía, tanto con métricas reales; en redes con dispositivos Android [13], en servidores [3] o en colecciones Java [8]; como con simulaciones, de aplicaciones Android [11] con eCalc, de aplicaciones Java Enterprise Edition (EE) [4], o de compresión de audio [10,17] con Palladio PCA. De estos trabajos se deduce que vale la pena optimizar el consumo de energía a nivel de código ya que se puede ahorrar entre un 2% y un 70%. Sin embargo, aunque todos estos trabajos empíricos muestran resultados muy interesantes, estos no son fáciles de trasladar a los procesos de desarrollo software industrial. Por ejemplo, en [8] se muestra el consumo de energía de las diferentes colecciones de datos (ej.: ArrayList, HashSet, Map, etc.) implementadas utilizando diferentes frameworks . Los autores han puesto de libre disposición sus resultados almacenados en cheros .csv, pero solo con estos cheros no es sencillo conseguir que un desarrollador reutilice este conocimiento en sus aplicaciones. En consecuencia, en este trabajo nos planteamos la denición de un ecoasistente (HADAS) que contenga los elementos funcionales que más inuyen en el consumo de energía de la aplicación (los consumidores de energía ), junto con sus alternativas de diseño (ej.: usar el algoritmo de cifrado AES) e implementación (ej.: Apache Commons Crypto). El objetivo del eco-asistente HADAS es el de concienciar al desarrollador de que debe analizar con cuidado las diferentes alternativas de diseño/implementación de estos consumidores, desde el punto de vista del consumo energético, y ayudarle a elegir la mejor. La utilidad del asistente es doble. Por un lado, los investigadores podrán almacenar sus resultados experimentales en un repositorio que quedarán disponibles para el resto de la comunidad. Por otro lado, los desarrolladores podrán utilizar estos para razonar acerca de las distintas versiones de los consumidores de energía, y elegir aquella solución que les satisfaga, siendo conscientes de la energía que podría consumir. Existen repositorios como el proporcionado por la herramienta de minería GreenMiner [12], orientado a almacenar resultados de pruebas experimentales relativos al consumo de energía. Sin embargo, este repositorio sirve únicamente para la ejecución y consulta de pruebas concretas y queda fuera de su alcance el aconsejarle al desarrollador sobre la solución más eco-eciente. De hecho, desarrollar un asistente como el que planteamos en este artículo es una tarea muy ambiciosa, a la vez que novedosa. En este artículo mostraremos los elementos principales de nuestra propuesta, centrándonos en presentar la estructura interna del asistente y en cómo este le permite a un desarrollador razonar sobre el consumo de energía de las diferentes conguraciones de los consumidores de energía. Concretamente, este razonamiento se basa en explotar un modelo de variabilidad que almacena las diferentes alternativas de los consumidores de energía y nos permite generar diferentes conguraciones válidas, y los datos de energía de cada una de ellas. Hay que tener en cuenta que el objetivo del asistente no es dar valores concretos de consumo de energía, ya que estos dependen mucho del hardware, sino mostrar en forma de grácas cómo varía el consumo de energía de dos o más soluciones. Por tanto, se pretende que el desarrollador identique tendencias de consumo y no asegurarle que su aplicación consumirá una determinada cantidad de Julios. De hecho, ninguna de las mediciones de energía realizadas tanto con herramientas software como hardware (ej.: Monsoon Power Monitor, osciloscopios) pueden tomarse como valores absolutos dado que el consumo real de una aplicación en ejecución depende de multitud de factores que no pueden controlarse (ej.: temperatura, carga del dispositivo, recolectores de basura, etc.). Las ventajas del eco-asistente HADAS serían: (i) el desarrollador no necesita disponer de, ni conocer, las herramientas hardware y/o software disponibles para medir el consumo de energía; (ii) el desarrollador no tiene que simular o hacer mediciones del consumo de energía de las diferentes alternativas de los consumidores de energía; (iii) HADAS ofrece una interfaz web sencilla que le ayuda al desarrollador a identicar los consumidores de energía de su aplicación y navegar para congurar las diferentes alternativas; (iv) HADAS devuelve grácas comparativas que le mostrarán las tendencias de consumo de energía de varias implementaciones alternativas. El artículo se organiza de la siguiente manera. La Sección 2 describe los requisitos y la visión general del eco-asistente HADAS. La Sección 3 detalla la estructura y funcionamiento de HADAS. En la Sección 4 evaluamos nuestra propuesta mediante dos escenarios diferentes, y mostramos la mejora del análisis de sostenibilidad al usar HADAS. La Sección 5 describe el trabajo relacionado. Finalmente, la Sección 6 discute las conclusiones y el trabajo futuro. 2. Requisitos y Visión General del Eco-Asistente HADAS En esta sección vamos a describir los requisitos que el repositorio HADAS debe cumplir para que sea útil, tanto a los investigadores que llevan a cabo los experimentos de consumo de energía, como a los desarrolladores que quieren reutilizar los resultados de dichos experimentos en sus aplicaciones. Daremos también una visión general de las partes más relevantes del repositorio. En cuanto a los requisitos que el repositorio HADAS debería tener en cuenta, hemos identicado los descritos a continuación. Los requisitos R1-R3 son comunes tanto a investigadores como a desarrolladores, mientras que el requisito R4 es especíco de los desarrolladores de aplicaciones y el requisito R5 especíco de los investigadores en consumo de energía: R1. Identicar los Consumidores de Energía. El primer paso para poder razonar sobre el consumo de energía de una aplicación es identicar aquellos elementos que de forma recurrente pueden tener un mayor impacto en su consumo energético. Estos elementos serían los que llamamos consumidores de energía . HADAS, al menos en esta primera fase, debería incorporar aquellos consumidores que más se utilizan en las aplicaciones, y dejar de lado aquellos más especícos de un dominio particular. R2. Modelar la Variabilidad de los Consumidores de Energía. Para un mismo referente de consumo energético podría haber disponible distintas soluciones, tanto de diseño como de implementación. Dado que queremos poder comparar entre distintas alternativas para un mismo referente, éstas deben ser modeladas, y su variabilidad representada de forma explícita. Dentro de este modelo también será necesario identicar las dependencias entre distintos consumidores (ej: entre autenticación y distribución). R3. Registrar el Consumo Energético de los Consumidores de Energía. Junto a cada referente, el repositorio HADAS debe almacenar información que permita calcular y razonar sobre el consumo energético de cada una de sus variantes, teniendo en cuenta los parámetros de conguración que afectan a dicho consumo. R4. Dar soporte para realizar un Análisis de Eco-eciencia. El desarrollador debe poder congurar los diferentes consumidores de energía (ej.: frameworks de desarrollo web PHP) de forma parcial, de manera que seleccione aquellas características variables sobre las que ya ha tomado una decisión, porque son imprescindibles de acuerdo a los requisitos de su aplicación (ej.: usar PHP plano) pero deje sin seleccionar otras características donde existe mayor exibilidad a la hora de elegir entre las alternativas disponibles. De esta forma el repositorio HADAS podría devolverle grácas comparativas con todas las soluciones posibles. El desarrollador podrá entonces realizar un análisis de la eco-eciencia de las distintas soluciones y optar por una de ellas. R5. Dar soporte para integrar los resultados de experimentación. Como ya hemos comentado anteriormente, no sería un objetivo viable el que los desarrolladores del eco-asistente HADAS fueran los encargados de medir y almacenar todas las conguraciones posibles de todos los consumidores de energía que existan en cualquier dominio de aplicación. Para esto, la idea es basarnos en un modelo colaborativo, donde el repositorio esté preparado para incluir las con- guraciones y mediciones aportadas por profesionales, investigadores e, incluso, extraídas de artículos ya publicados. Dada la gran variedad de hardware existente y las distintas posibilidades de medición, HADAS debería permitir agrupar aquellas medidas que se hayan realizado con el mismo hardware. Nuestra visión general de cómo debería ser el eco-asistente HADAS puede verse en la Figura 1. Por un lado, el Formulario y el Modelo de Variabilidad modelan de forma explícita cada uno de los consumidores de energía contenidos en el asistente, haciendo hincapié en la variabilidad existente y en su contexto energético. El Formulario es la interfaz con los desarrolladores, que les hace transparente los detalles del modelo de variabilidad, haciéndoles más fácil su utilización, mientras que el Modelo de Variabilidad es una representación formal de la variabilidad de los consumidores de energía y su contexto energético, que permite congurarlos y razonar sobre ellos. Toda la estructura que nos indica el modelo de variabilidad, junto a las mediciones de energía para cada consumidor Formato HADAS Desarrolladores Desarrolladores Modelo de Variabilidad HADAS Consumidores de energía Contexto Energético Modelo de Variabilidad HADAS Consumidores de energía Contexto Energético Modelo de Variabilidad HADAS Consumidores de energía Contexto Energético Repositorio de Eficiencia Energética Mediciones de Energía Mediciones de Energía Diseño Implementación Diseño Implementación Repositorio de Eficiencia Energética Mediciones de Energía Diseño Implementación Modelo de Variabilidad HADAS Consumidores de energía Contexto Energético Repositorio de Eficiencia Energética Mediciones de Energía Diseño Implementación Eco-asistente HADAS Formulario (Vista de Árbol) Interfaz x Interfaz x Interfaz x Formulario (Vista de Árbol) Interfaz x Investigadores Investigadores Gráficas de Sostenibilidad Gráficas de Sostenibilidad Análisis de Sostenibilidad Datos Generados Configuración Insertar Métricas Consumidores de Energía Visualización de Gráficas Resultados de Experimentación Figura 1. Visión general del eco-asistente HADAS y cada contexto energético, estarán almacenados en el Repositorio de Eciencia Energética . Una vez generada una Conguración , total o parcial, a través del Formulario se accederá al repositorio para obtener información sobre las mediciones de energía asociadas a esa conguración, y se generarán las Grácas de Sostenibilidad necesarias para realizar el análisis energético de las variantes seleccionadas. Como hemos mencionado anteriormente se distinguen claramente dos roles, el de los Desarrolladores y el de los Investigadores . ¾Cómo utiliza el eco-asistente HADAS un investigador? El investigador dispone de datos de experimentación sobre una variante determinada de un consumidor de energía y quiere integrarlos en el eco-asistente HADAS para que los desarrolladores de aplicaciones puedan utilizarlos. Básicamente, de acuerdo a la Figura 1, el investigador tendrá que representar los datos tomados en un formato entendible por HADAS, y habrá que actualizar de forma adecuada tanto el modelo de variabilidad del consumidor de energí,a como el repositorio con las métricas. ¾Cómo utiliza el eco-asistente HADAS un desarrollador? Un desarrollador de aplicaciones desea conocer cuáles son los posibles puntos de fuga de energía de la aplicación que va a desarrollar, y quiere realizar un análisis eco-eciente de las distintas alternativas que le da el eco-asistente HADAS. Para ello, navegará por los formularios donde HADAS le muestra información de todos los consumidores de energía que tiene registrado junto a sus variantes. El desarrollador seleccionará qué consumidores de energía quiere analizar, qué variantes quiere pre-selecciona, cuales no para que el asistente le ayude a elegir. Con toda esa información el eco-asistente HADAS generará una conguración parcialmente instanciada. Esto es posible porque por debajo de este formulario, transparente al desarrollador de aplicaciones, el eco-asistente tiene denido el modelo de variabilidad de todos los referentes de consumo y de todas sus variantes. Además, enlazado con este modelo de variabilidad, estará la información de las mediciones de energía que hay disponibles. Una vez denida una conguración de los consumidores de energía que se desean analizar, el eco-asistente generará las grácas que permitirán al desarrollador realizar su análisis de sostenibilidad. 3. Estructura de HADAS En la Figura 1 podemos visualizar que, tanto las métricas como su estructura (características de diseño e implementación), se encuentran en una base de datos, formando lo que hemos denominado repositorio de eciencia energética. La estructura del repositorio viene dada por el modelo de variabilidad, que en nuestro caso, sería una representación del árbol de variabilidad en un formato manejable para el eco-asistente HADAS. Hemos elegido una representación en modo texto, concretamente el formato EFM (Famas Extended Model) [18]. De esta forma es fácil chequear su corrección utilizando la herramienta FaMa-FW (del inglés Feature automated Model analyses - FrameWork) [1]. Como se ve en Alternativas de implementación Variantes de diseño Contexto energético Consumidores de energía 1..*1..* HADAS Referente 1 1 4 ... Eco-asistente HADAS Consumidores de energía Memoria Distribuido Seguridad Compresión Distribución P2P Cliente/Servidor Servidor PHP Servidor Web Contexto Energético Servidor Parámetros del Servidor Operación del Servidor Parámetros MaxUsuarios = 50 Referente n Diseño 1 Diseño 2 Diseño 2.1 Diseño 2.n Tecnología 1 Tecnología 2 Tecnologías Diseño 2.1 ContextoEnergético Diseño 2.1 Tecnología 2.1 Tecnología 2.n 1..11..1 1..*1..* 1..*1..* 1..11..1 Parámetros Diseño 2.1 TipodeDato Diseño 2.1 1..*1..* Operación Diseño 2.1 Variable 1: Int Variable n: Int 1..*1..* Tipo 1 Tipo n 1..11..1 Op 1 Op n 1..*1..* Opción Variable: Tipo 1..n1..n selección entre 1 y n selección obligatoria selección opcional Leyenda VSpec decisión si/no especificar un valor del tipo 2 3 Figura 2. Estructura por niveles de la variabilidad del árbol y del formulario la parte derecha de la Figura 2, y también en el ejemplo de la Figura 3, el árbol de variabilidad que usa HADAS se divide en tres niveles: (1) en este nivel se sitúan los consumidores de energía identicados no solamente por nosotros, sino en los diferentes trabajos de experimentación (ej.: seguridad, almacenamiento, distribución ...). en el primer nivel de la Figura 3); (2) para cada referente se denirá un sub-árbol con las opciones de diseño disponibles (ej.: en la Figura 3 para la distribución tenemos la arquitectura cliente/servidor). Dependiendo de la complejidad del consumidor de energía habrá uno o varios sub-niveles; (3) para cada hoja del sub-árbol de diseño (ej.: Diseño 2.1 en Figura 2) se dene un sub-árbol Tecnologías y otro sub-árbol con el Contexto Energético . El sub-árbol Tecnologías dene las diferentes alternativas que existen para implementar cada uno de los diseños. Aquí podemos distinguir entre diferentes frameworks, APIs, etc., y sus respectivos lenguajes de programación. Esta información es la que nos permitirá darle al desarrollador el consumo de energía de un diseño concreto, implementado con diferentes tecnologías. El sub-árbol Contexto Energético contiene tres características hijas: (i) Parámetros : el consumo de energía de una implementación varía en función de algunos parámetros de su diseño, como por ejemplo la compresión de un chero dependerá del tamaño del chero a comprimir, por lo tanto, el desarrollador podría indicar un tamaño máximo; (ii) Tipo de Datos : normalmente los consumidores de energía manipulan datos de diferente tipo (ej.: texto plano, XML, etc.) y el tipo de datos suele inuir en el consumo de energía; (iii) Operaciones : cada diseño de un referente ofrece una interfaz de uso, que es el conjunto de operaciones que se invocarán desde la aplicación (ej.: para las colecciones de datos, las operaciones son insertar, borrar, etc.). Tanto las operaciones, como el tipo de datos, no tienen por qué estar implementadas en todas las tecnologías, y esto lo expresamos mediante restricciones entre sub-árboles del tipo Tecnología i implies NOT Op j . Una vez denimos nuestro modelo de variabilidad, este hay que representarlo mediante formularios dinámicos al desarrollador y permitirle que seleccione las diferentes alternativas, respetando las restricciones entre sub-árboles (ver parte izquierda de la Figura 2, que sigue la misma leyenda de colores que el esquema del árbol de variabilidad). Concretamente, el eco-asistente HADAS hace una representación web del modelo de variabilidad, en forma de árbol desplegable en profundidad. El formulario dinámico implementa las dependencias de manera dinámica, es decir, se marcarán y desplegarán las ramas objeto de restricciones, de manera automática, si son activadas. Pero este árbol de variabilidad no contiene las métricas, sino que éstas se almacenan en una base de datos. Por lo tanto, conectamos el árbol de variabilidad a una base de datos que, conjuntamente, conforman el repositorio. La estructura de la base de datos se corresponde con la del modelo de variabilidad, donde cada nivel tiene su referente en una tabla concreta (tablas Referente, Diseño, Tecnología, TipodeDato, Operación, Variable). Además, la tabla Métrica, relacionará estas tablas con el consumo y el tiempo de ejecución. Para permitir la inclusión de datos de energía diferentes (de distintas fuentes) para la misma conguración, se incluye la tabla Metadato, donde se incluirá el sistema de medición y el hardware usado para obtener éstos datos, lo que le permitirá al desarrollador realizar un análisis más rico, al poder basarse en varias fuentes. El desarrollador va generando diferentes conguraciones que se traducen a consultas en la base de datos del repositorio. Las conguraciones se generan con un razonador ( SAT solver ) que nos garantiza que se generan todas las con- guraciones válidas. A continuación, se formaliza la correspondencia entre una conguración del modelo de variabilidad y la información en la base de datos. Esta correspondencia permite la generación automática de las consultas SQL, que le darán al desarrollador la información necesaria para realizar un análisis. Nos basamos en la formalización del árbol de variabilidad denida en [6] extendiéndola. Dada una conguración parcial CP arcial del modelo de variabilidad y después de aplicarle un razonador (FaMa-FW) obtendremos un conjunto con todas las conguraciones correspondientes. Para cada conguración completa CCompleta se denen los siguientes conjuntos y operaciones: V SP EC V SP EC V SP EC . Conjunto nito, no vacío, de identicadores (nombres únicos) de todas las características (VSpecs) de una conguración completa. V SP EC ={HADAS, Distribuci ó n, Cliente/Servidor, Servidor, T ecnolog í asServidor, P HP, P lainP HP, Lavarel, ...} hijos :V SP EC →P(V SP EC) hijos :V SP EC →P(V SP EC) hijos :V SP EC →P(V SP EC) . Función que dada una característica, devuelve todos sus hijos. padre :V SP EC →V SP EC padre :V SP EC →V SP EC padre :V SP EC →V SP EC . Función que dado una característica devuelve la característica padre, o ∅ si es la raíz. antecesores :V SP EC →P(V SP EC) antecesores :V SP EC →P(V SP EC) antecesores :V SP EC →P(V SP EC) . Función que dado una característica devuelve todos sus antecesores, o ∅ si es la raíz. Referentes :CCompleta →V SP EC Referentes :CCompleta →V SP EC Referentes :CCompleta →V SP EC . Dada una conguración completa devuelve los referentes de consumo de energía de la conguración, es decir: Referentes ={c∈CCompleta |c∈ hijos(HADAS)} T ECRa í z:CCompleta →P(V SP EC) T ECRa í z:CCompleta →P(V SP EC) T ECRa í z:CCompleta →P(V SP EC) . Dada una conguración completa devuelve las características raíz de las tecnologías: T ECRa í z={c∈CCompleta |c.startsW ith(”T ecnolog í as”)} VDise ñ o:CCompleta →P(V SP EC) VDise ñ o:CCompleta →P(V SP EC) VDise ñ o:CCompleta →P(V SP EC) . Dada una conguración completa devuelve todas sus variantes de diseño: VDise ñ o={c∈CCompleta | ∃t∈T ECRa í z, c =padre(t)} T ecnolog í as :CCompleta →P(V SP EC) T ecnolog í as :CCompleta →P(V SP EC) T ecnolog í as :CCompleta →P(V SP EC) . Dada una conguración completa devuelve todas las tecnologías usadas en la conguración: T ecnolog í as ={c∈CCompleta |hijos(c) = ∅ ∧ ∃a∈ antecesores(c)∧a∈T ECRa í z} P ARAMRa í z:CCompleta →P(V SP EC) P ARAMRa í z:CCompleta →P(V SP EC) P ARAMRa í z:CCompleta →P(V SP EC) . Dada una conguración completa devuelve las características raíz de los parámetros: P ARAMRaz ={c∈CCompleta |c.startsW ith(”P ar á metros”)} P ar á metros :CCompleta →P(V SP EC) P ar á metros :CCompleta →P(V SP EC) P ar á metros :CCompleta →P(V SP EC) . Dada una conguración completa devuelve todos los parámetros usados en la conguración: P ar á metros ={c∈CCompleta |hijos(c) = ∅ ∧ ∃a∈ antecesores(c)∧a∈P ARAMRa í z} value :p→R value :p→R value :p→R . Dado un parámetro p devuelve el valor seleccionado por el desarrollador en la interfaz. De manera análoga a la denición de las variantes de parámetros se denen los contextos energéticos, tipos de datos y operaciones. Con esta información, se genera una consulta SQL para cada conguración completa CCompleta : SELECT Energy, Time, Metadatos.* FROM TMétrica JOIN Metadatos ON Metadatos.idMétrica = TMétrica.id JOIN RefsMétrica ON RefsMétrica.idMétrica = TMétrica.id JOIN TReferente ON TReferente.id = RefsMétrica.idReferente ⇑ Enlazamos una medida a uno o varios referentes JOIN VsDisMétrica ON VsDisMétrica.idMétrica = TMétrica.id JOIN TVDiseño ON TVDiseño.id = VsDisMétrica.idVDiseño ⇑ Enlazamos una medida a una o varias variables de diseño JOIN TecsMétrica ON TecsMétrica.idMétrica = TMétrica.id JOIN TTecnología ON TTecnología.id = TecsMétricas.idTecnologia ⇑ Enlazamos una medida a una o varias alternativas tecnológicas ... ⇒ De manera análoga enlaza para cada tabla/conjunto WHERE (( ∀r∈Referentes , TReferente.nombre = r ) AND ( ∀v∈V Dise ñ o , TVDiseño.nombre = v ) AND ( ∀t∈T ecnolog í as , TTecnología.nombre = t ) AND ... ⇒ De manera análoga filtra para cada tabla/conjunto ( ∀p∈P ar á metros , TParámetro.nombre = p AND TParámetro.valor ≤value(p) )) ⇒ Acota por valores máximo Una vez obtenidos los datos para cada conguración, el sistema hará uso de la API Google Charts para mostrar las grácas de consumo y tiempo de ejecución pertinentes, permitiendo el análisis del caso de uso. 4. Evaluación En esta sección presentamos dos escenarios de uso de HADAS. En el primero mostramos que es posible integrar los datos generados por otros investigadores en el eco-asistente, mejorando el análisis de consumo de energía que se puede realizar, y en el segundo seguimos el proceso completo generando y almacenando primero los datos y usando después el eco-asistente. 4.1. Colecciones en Java En [8] se calcula el consumo de energía de distintas colecciones de Java (Lista, Mapa y Set) para diferentes operaciones (insertar al principio, en medio, al nal, borrar, iterar...), utilizando distintas APIs (JCF, ACC, Trove) y distintas implementaciones (HashMap, TreeMap...). Se realiza la experimentación teniendo en cuenta distintos tipos de datos (Int, Object) y tamaño de los datos (hasta 5000 elementos). Toda esta información está accessible mediante archivos CSV en una web. ¾Cómo utilizaría entonces un desarrollador esta información sin usar HADAS? Puede consultar las grácas estáticas proporcionados en la página web, pero no es trivial identicar todos los posibles análisis que existen, ya que no hay una forma fácil de conocer todas las variantes a analizar. Nosotros mostraremos como se pueden integrar estos datos en el eco-asistente y veremos que es posible realizar un análisis más rico del consumo de energía de las colecciones con dichas métricas. Dado que no existe información de estos referentes energéticos en el actual repositorio, el primer paso es evolucionar el árbol de nuestro modelo de variabilidad. Por tanto, en la Figura 2, al nivel de variantes de diseño, bajo la rama Memoria->Volátil incluiríamos los tres tipos List , Map y Set ), y, en cada uno, las alternativas tecnológicas, es decir, los tres frameworks usados en esta experimentación ( JCF , ACC , Trove ) y, de estos últimos, sus respectivas implementaciones ( HashMap , TreeMap ...). También se incluye el contexto energético de memoria volátil, donde contemplamos el máximo número de datos, el tipo de datos ( Int , Object ) y las operaciones. Para introducir los datos en el repositorio hemos implementado también una función de ltrado, la cual extrae los datos de diseño, implementación y energía que necesitamos de todos los CSV (tipo de dato, operación, clase, implementación, consumo en julios y tiempo de ejecución). A partir de estos datos se calcula la mediana de los Julios (ya que existen 32 pasadas para cada conguración completa), y esto es lo que añadiríamos a la base de datos de nuestro repositorio. Tras introducirlo en HADAS, junto a las restricciones necesarias (ej.: Map implica no Insert at the beginning|end ), hemos evaluado el árbol de variabilidad EFM correspondiente a este caso de estudio con FAMA-FW, y nos devuelve 11904 conguraciones correctas. Este alto nivel de variabilidad demuestra que no es viable realizar el análisis de forma manual, y, también, que la información proporcionada en [8] es muy interesante, pero que se podría ampliar analizando muchas otras opciones no contempladas por los autores en [8].