Optimización de modelos de características con aplicaciones para la adaptación de composiciones de servicios

(1)

Universidad Nacional del Centro de la Provincia De Buenos Aires Facultad de Ciencias Exactas - Departamento de Computación y Sistemas

Doctorado en Ciencias de la Computación

Optimización de modelos de características

con aplicaciones para la adaptación de

composiciones de servicios

por

Luis Emiliano Sánchez

Director: Dr. Jorge Andrés Diaz-Pace

Co-Director: Dr. Alejandro Zunino

Tesis sometida a evaluación como requisito parcial para la obtención del grado de

Doctor en Ciencias de la Computación

(2)

(3)

Resumen

Los modelos de características, ofeature models (FM), son un formalismo acepta-do para capturar la variabilidad y reglas de configuración de sistemas de software complejos. Estos modelos son una representación compacta de las posibles configu-raciones o estados de un sistema, en términos defeatures(características) y relaciones lógicas entre estas. Las configuraciones de un sistema pueden diferenciarse por las propiedades no funcionales que definen sucalidad de serviciooQoS(del inglésQuality of Service), como el tiempo de respuesta, disponibilidad, costo, entre otros atributos. Por lo tanto, surge el problema de seleccionar una configuración válida de caracterís-ticas que optimice una función objetivo asociada a preferencias de calidad de servicio. Mediante este problema, denominado selección de configuraciones u optimización de FMs, se pueden abordar aplicaciones de Ingeniería de Software que involucran selec-cionar una de entre varias configuraciones posibles de un sistema o artefacto. Algunos ejemplos son: derivar un producto de una línea de productos de software, adaptar la configuración de un sistema, o seleccionar una composición de servicios entre múlti-ples servicios candidatos.

El problema se torna complejo si se considera que el número de posibles configu-raciones puede crecer exponencialmente debido a la variabilidad del sistema, es decir, la cantidad de características y parámetros alternativos que pueden combinarse. Este es un problema de optimización combinatoria NP-Hard, y ha sido abordado en dife-rentes trabajos con distintos algoritmos. Sin embargo, estos algoritmos presentan limi-taciones y a menudo apelan a simplificaciones del problema que acotan su aplicación, particularmente en escenarios en tiempo de ejecución donde la decisión debe tomar-se en tiempo acotado. Además, las propiedades de QoS a optimizar suelen entrar en conflicto y son difíciles de estimar porque emergen de la interacción entre las partes que forman el sistema. Por lo tanto, es importante que el algoritmo soporte funciones de QoS adecuadas como criterios de optimización del problema.

(4)

IV

(5)

Agradecimientos

Es un placer agradecer a las personas que me ayudaron durante la investigación y la escritura de esta tesis.

En especial a mis directores, Andrés y Alejandro, por su paciencia y dedicación para dirigir mi trabajo.

Al Instituto Superior de Ingeniería de Software de Tandil (ISISTAN) y a la Facul-tad de Ciencias Exactas de la Universidad UNICEN, que brindaron el lugar físico y los equipos necesarios para desarrollar los experimentos. También agradezco al Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET), por la ayuda financie-ra pafinancie-ra realizar mis estudios.

A mis amigos y colegas del instituto de investigación, cuyos comentarios y ayuda me permitieron mejorar la calidad de este trabajo y sobrepasar muchas dificultades. Todos ellos hicieron del lugar de trabajo un espacio agradable para escribir e investi-gar.

Por último, me gustaría agradecer especialmente a mis padres, Rosana y Luis, mis abuelos, Berta y Gumersindo, y mi hermana Ayelén, por su compañía y afecto, y por haberme alentado a realizar los estudios de posgrado.

A todos ellos, muchísimas gracias.

(6)

(7)

Índice general

Resumen III

Agradecimientos V

Índice general VII

Índice de figuras XI

Índice de cuadros XIII

Lista de acrónimos XV

1. Introducción 1

1.1. Composición de servicios basada en QoS . . . 2

1.2. La tesis . . . 3

1.3. Organización . . . 5

2. Marco teórico 7 2.1. Feature models . . . 7

2.1.1. Configuraciones . . . 8

2.1.2. Elementos básicos del lenguaje . . . 9

2.1.3. Extensiones del lenguaje . . . 10

2.2. Optimización de feature models . . . 11

2.2.1. Aplicaciones prácticas del problema . . . 12

2.2.2. Definición formal del problema de optimización . . . 13

2.3. Sistemas auto-adaptativos . . . 16

2.4. Ejemplo: Sistema de video vigilancia . . . 17

2.5. Composición de servicios . . . 20

2.6. Composición de servicios basada enQoS . . . 21

2.7. Resumen . . . 24

3. Trabajos relacionados 25 3.1. Optimización de composición de servicios . . . 25

3.1.1. Algoritmos genéticos . . . 25

3.1.2. Algoritmos evolutivos multi-objetivo . . . 27

3.1.3. Algoritmos de inteligencia de enjambres . . . 27

(8)

ÍNDICE GENERAL VIII

3.1.6. Algoritmos sobre grafos . . . 30

3.2. Optimización en feature models . . . 31

3.2.1. Algoritmos multi-objetivo . . . 31

3.2.2. Algoritmos exactos mono-objetivo . . . 34

3.2.3. Algoritmos aproximados mono-objetivo . . . 35

3.3. Feature models en sistemas adaptativos y basados en servicios . . . 37

3.4. Discusión . . . 38

4. Enfoque FMPlanning 41 4.1. Vista general del enfoque . . . 41

4.2. Planificación de la adaptación . . . 42

4.2.1. Traducción de Eventos al Modelo . . . 43

4.2.2. Algoritmo de Selección de Configuraciones . . . 44

4.2.3. Traducción del Modelo a Acciones . . . 44

4.2.4. Ejemplo de adaptación del sistema de videovigilancia . . . 44

4.3. Proceso de desarrollo . . . 47

4.3.1. Construcción del modelo . . . 47

4.3.2. Especificación de objetivos y restricciones de QoS . . . 51

4.3.3. Integración del planificador al sistema adaptativo . . . 55

4.4. Resumen . . . 56

5. CSA: Algoritmo de Selección de Configuraciones 57 5.1. Esquema general del algoritmo . . . 57

5.2. Estrategias de búsqueda . . . 61

5.2.1. Backtracking (BT)1 _{. . . 61}

5.2.2. Best-First Search (BestFS) . . . 61

5.2.3. Branch and Bound (B&B) . . . 62

5.3. Heurísticas . . . 63

5.3.1. Heurística HMO para funciones de agregación . . . 65

5.3.2. Heurística HTC para funciones de agregación . . . 66

5.3.3. Heurísticas admisibles para la función polinomial multi-lineal . . 67

5.3.4. Heurísticas admisibles para combinación lineal de funciones . . . 67

5.4. Selección de features . . . 68

5.5. Análisis del algoritmo . . . 69

5.6. Resumen . . . 70

6. Evaluación de CSA 71 6.1. Diseño experimental . . . 71

6.1.1. Métricas de evaluación . . . 72

6.1.2. Instancias del problema . . . 72

6.2. Experimento #1: escalabilidad de las configuraciones de CSA . . . 73

6.2.1. Diseño del experimento . . . 74

6.2.2. Resultados . . . 75

6.3. Experimento #2: comparación entre enfoques aproximados . . . 79

6.3.2. Resultados . . . 79

6.4. Experimento #3: comparación entre enfoques exactos . . . 81

6.4.2. Resultados . . . 82

1_{Para referenciar esta estrategia en figuras y cuadros, se utiliza la sigla}_BT _{en lugar de la palabra}

(9)

ÍNDICE GENERAL IX

6.5. Experimento #4: desempeño de CSA con interacciones entre features . . 85

6.5.2. Resultados . . . 86

6.6. Discusión . . . 87

6.7. Amenazas a la validez . . . 89

6.8. Resumen . . . 90

7. Casos de estudio 93 7.1. Consideraciones generales . . . 93

7.2. Caso de estudio #1: CVPipe . . . 95

7.2.1. Arquitectura . . . 95

7.2.2. Modelo . . . 96

7.2.3. Funciones objetivos de QoS . . . 97

7.2.4. Experimento #1: precisión de las funciones . . . 99

7.2.5. Integración del planificador . . . 102

7.2.6. Ejemplos de adaptación . . . 102

7.3. Caso de estudio #2: SAFD . . . 103

7.3.2. Modelo . . . 106

7.3.6. Ejemplos de adaptación . . . 111

7.4. Caso de estudio #3: TeXTracT . . . 112

7.4.2. Modelo . . . 115

7.4.4. Experimento #1: precisión de la función tiempo de respuesta . . . 117

7.4.6. Ejemplos de invocación . . . 120

7.4.7. Experimento #2: estudio con usuarios de TeXTracT . . . 121

7.5. Caso de estudio #4: ReSeP y TAS . . . 124

7.5.2. Modelo . . . 127

7.5.6. Experimento #2: comparación de estrategias de adaptación . . . . 131

7.6. Discusión . . . 134

7.7. Amenazas a la validez . . . 135

7.8. Resumen . . . 136

8. Conclusiones 137 8.1. Contribuciones . . . 138

8.2. Limitaciones . . . 139

(10)

ÍNDICE GENERAL X

Apéndice A. Enunciados y cuestionarios para la evaluación del caso de estudio

TeXTracT 143

A.1. Enunciados . . . 143

A.2. Preguntas generales del cuestionario . . . 144

A.3. Preguntas sobre los casos de test . . . 145

A.4. Otras preguntas . . . 146

Apéndice B. Publicaciones relacionadas 147

(11)

Índice de figuras

1.1. Esquema general del enfoque FMPlanning . . . 4

2.1. Ejemplo de FM . . . 8

2.2. Ejemplo de configuraciones del modelo de GPS . . . 9

2.3. Aplicaciones de la operación de selección de configuraciones sobre FMs 12 2.4. Ejemplo de modelo con atributos . . . 13

2.5. Frontera de Pareto de las configuraciones del modelo de GPS . . . 14

2.6. Modelo de referencia MAPE-K basado en FMs . . . 17

2.7. Ejemplos de aplicaciones del sistema de videovigilancia . . . 18

2.8. Posible configuración del sistema de videovigilancia . . . 18

2.9. Extracto del FM del sistema de video vigilancia . . . 19

2.10. Ejemplo de configuración completa del modelo del sistema de videovi-gilancia . . . 19

2.11. Ejemplo de workflow con 5 tareas, los servicios candidatos para cada una, y su modelo de variabilidad. . . 22

4.1. Esquema general del planificador . . . 42

4.2. Esquema general del proceso . . . 42

4.3. Ejemplo de configuraciones parciales . . . 45

4.4. Conjunto de configuraciones completas válidas . . . 46

4.5. Ejemplo de modelo en formato SXFM y su equivalente en código Java. . 48

4.6. Aspectos transversales de los servicios compuestos . . . 49

4.7. Visión general de un FM para sistemas basados en composiciones de servicios . . . 50

4.8. Variabilidad de Workflow y FM . . . 51

4.9. Estrategias para definir la función de una propiedadp . . . 52

4.10. Ejemplo de workflow con 5 tareas (A, B, C, D, E) y los servicios candi-datos para cada una. . . 53

4.11. Diagrama de secuencia que muestra la integración del planificador a un sistema adaptativo . . . 55

5.1. Ejemplo de árbol de espacio de búsqueda. . . 58

5.2. Parámetros del algoritmo CSA. . . 60

5.3. Ejemplo de problema relajado . . . 64

6.1. Frecuencia de modelos por rango de features . . . 73

(12)

ÍNDICE DE FIGURAS XII

6.3. Tiempo de respuesta de las configuraciones de CSA (Experimento #1

-parte 1) . . . 76

6.4. Tiempo de respuesta de las configuraciones exactas del algoritmo (Ex-perimento #1 - parte 2) . . . 78

6.5. Tiempo de respuesta y grado de optimalidad de las configuraciones aproximadas del algoritmo (Experimento #1 - parte 2) . . . 78

6.6. Tiempo de respuesta promedio por algoritmo y muestra . . . 84

7.1. Diagrama de clases simplificado de la plataforma . . . 96

7.2. Feature model del sistema CVPipe . . . 97

7.3. Ejemplos de salida de algunos servicios . . . 98

7.4. Propiedades medidas y estimadas. Las líneas negras punteadas son cur-vas de regresión y las líneas rojas representan la tendencia ideal. . . 101

7.5. Configuraciones completas de ejemplo del caso CVPipe . . . 103

7.6. Arquitectura de SAFD . . . 104

7.7. Ejemplo de composición del resultado de servicios en SAFD . . . 105

7.8. Feature model de SAFD . . . 107

7.9. Ejemplo de anotaciones de rostros en una imagen. . . 108

7.10. Propiedades medidas y estimadas con sus correspondientes funciones (rtime(C)yacc(C)). . . 110

7.11. Configuraciones parciales y completas de ejemplo del caso SAFD . . . . 111

7.12. Pipeline NLP . . . 113

7.13. Workflow completo de TeXTracT . . . 114

7.14. Métodos de la interfaz de TeXTracT y su extensión . . . 115

7.15. Extracto del FM del servicio TeXTracT . . . 115

7.16. Tiempos de respuesta medidos y estimados . . . 119

7.17. Configuración parcial de los ejemplos de TeXTracT . . . 120

7.18. Frecuencia de las puntuaciones de las preguntas sobre los métodos de la interfaz TeXTracT . . . 124

7.19. Diagrama de clases de ReSeP, TAS y estrategias de adaptación . . . 126

7.20. Workflow de TAS . . . 126

7.21. Feature model del sistema TAS . . . 127

7.22. Workflow de TAS y propiedades de los servicios atómicos . . . 128

7.23. Valores medidos de tasa de fallos y costo, con sus correspondientes va-lores estimados por las funciones f ailrate(C)ycost(C). . . 130

7.24. Interfaz gráfica de la plataforma ReSeP para la evaluación de estrategias de adaptación . . . 132

(13)

Índice de cuadros

2.1. TCs y CTCs en lógica proposicional. . . 9

2.2. Ejemplos de funciones objetivos . . . 15

2.3. Funciones de agregación para diferentes propiedades y estructuras de control . . . 23

3.1. Características de los enfoques basados en técnicas inspiradas en la na-turaleza . . . 32

3.2. Características de los enfoques basados en técnicas no inspiradas en la naturaleza . . . 33

3.3. Reglas para transformar las restricciones de FMs a distintos enfoques. . 35

3.4. Trabajos relacionados: características de los algoritmos y su evaluación. . 36

3.5. Trabajos relacionados: características del problema soportado. . . 36

5.1. Ejemplo de ejecución de cada estrategia con la heurística HMO . . . 65

5.2. Propiedades de las estrategias de búsqueda . . . 69

6.1. Propiedades generales del conjunto de modelos de SPLOT . . . 73

6.2. Tiempo de respuesta promedio y desvío estándar en ms (µ±σ) por con-figuración del algoritmo y muestras con 10, 50, 100, 200 y 400 features por modelo . . . 77

6.3. Correctitud de los algoritmos aproximados . . . 80

6.4. Optimalidad de los algoritmos aproximados . . . 80

6.5. Tiempo de respuesta de los algoritmos aproximados . . . 80

6.6. Resultados del experimento con diferentes algoritmos exactos. Tiempo de respuesta promedio y desvío estándar en milisegundos (µ±σ). . . 83

6.7. Tiempo de respuesta y optimalidad de los algoritmos evaluados en el Experimento #4 . . . 87

7.1. Características de los casos de estudio . . . 94

7.2. Propiedades de componentes individuales . . . 100

7.3. Resultados del experimento . . . 101

7.4. Características funcionales por cada servicio . . . 106

7.5. Resultados del experimento . . . 110

7.6. Tiempo de respuesta y precisión de los servicios individuales . . . 110

7.7. Tiempo de planificación y respuesta de los ejemplos de adaptación . . . 112

7.8. Propiedades de los algoritmos disponibles en TeXTracT . . . 117

(14)

ÍNDICE DE CUADROS XIV

7.10. Tiempo de planificación y respuesta de los ejemplos de invocación al servicio TeXTracT . . . 120 7.11. Interfaz de la herramienta TeXTracT usada en la evaluación . . . 122 7.12. Resultados basados en 20 estudiantes de grado, 10 sobre la versión

(15)

Lista de acrónimos

0-1 LP 0-1 Linear Programming

ACO Ant Colony Optimization

API Application Programming Interface

BCO Bee Colony Optimization

BPMN Business Process Model and Notation

B&B Branch and Bound

CNF Conjunctive Normal Form

COP Constraint Optimization Problem

CSA Configuration Selection Algorithm

CSOP Constraint Satisfaction Optimization Problem

CSP Constraint Satisfaction Problem

CTC Cross-Tree Constraint

DSPL Dynamic Software Product Line

FM Feature Model

FMPlanning Feature Model-based adaptation Planning approach

FODA Feature-Oriented Domain Analysis

GA Genetic Algorithm

HTTP Hypertext Transfer Protocol

LIP Linear Integer Programming

MMKP Multi-dimensional Multi-choice Knapsack Problem

MOEA Multi-Objective Evolutionary Algorithm

PSO Particle Swarm Optimization

(16)

REST Representational State Transfer

SLA Service Level Agreement

SOC Service-Oriented Computing

SPL Software Product Line

TC Tree Constraint

(17)

Cap´ıtulo

1

Introducción

Los modelos de características, ofeature models(FM), son un formalismo aceptado para representar y gestionar sistemas con gran variabilidad en término de configura-ciones, contextos y requerimientos. Originalmente fueron propuestos para el diseño delíneas de productos de software(Software Product Line,SPL) [1], los cuales son artefac-tos de software que representan familias de producartefac-tos o sistemas con características comunes. Actualmente, el uso de FMs se ha extendido también al modelado y adapta-ción de sistemas en tiempo de ejecuadapta-ción [2]. Un FM es un conjunto defeatures (caracte-rísticas) organizados jerárquicamente y vinculados mediante relaciones lógicas. Estas relaciones restringen las combinaciones válidas de features. Así, el modelo representa un conjunto compacto de todas las posibles configuraciones de un sistema o artefacto. Parte de la investigación en modelos de características se centra en técnicas y ope-raciones automáticas para el análisis y manipulación de estos modelos, y sus aplica-ciones en Ingeniería de Software [3]. Una operación que ha recibido atención por sus aplicaciones prácticas es la denominada optimización de FMs o selección de configura-ciones en FMs1. Esta operación consiste en tomar un FM y una función objetivo como entradas, y retornar la configuración, es decir, un subconjunto de features selecciona-dos del modelo, que maximiza (o minimiza) la función objetivo. La función objetivo asocia cada configuración a un valor numérico que determina la calidad de la solución con respecto a algún criterio de optimización, como puede ser el costo de la configu-ración, la satisfacción de sus usuarios, o la calidad de servicio. Lacalidad de servicio (QoSporQuality-of-Service) es el conjunto de propiedades no funcionales o atributos de calidad [4] que representan los aspectos que utilizan losstakeholderspara juzgar el funcionamiento de un sistema, tales como performance (por ej., tiempo de respuesta), disponibilidad (por ej., tasa de errores), precisión (por ej., porcentaje de tareas ejecuta-das correctamente), o costo (por ej., precio del servicio), entre otros.

La selección de configuraciones es un aspecto central en el proceso de derivación de productos [5], como un problema de ingeniería en donde se genera un producto de software a partir de unaSPLconsiderando un presupuesto disponible y la maximiza-ción de las preferencias del cliente. La selecmaximiza-ción de configuraciones puede también ser requerida en tiempo de ejecución, para la adaptación de sistemas cuya variabilidad y reglas de configuración son validadas y vinculadas dinámicamente [2]. Si el siste-ma se modela mediante FMs, la optimización de FMs puede usarse para seleccionar y adaptar la configuración de un sistema con el objetivo de maximizar o mantener determinado nivel deQoS, cuando cambian las preferencias de los usuarios o las

con-1_{En esta tesis, ambos términos se usan intercambiablemente. En la literatura, la operación también}

(18)

1.1. COMPOSICIÓN DE SERVICIOS BASADA EN QOS

diciones del contexto de ejecución, como por ejemplo cambios en la carga de trabajo o la disponibilidad de recursos.

Varios trabajos se han dedicado al diseño y validación de técnicas y algoritmos pa-ra resolver el problema de optimización de FMs [6, 7, 8, 9, 10, 11, 12, 13]. Formalmente es un problema de optimización combinatoriaNP-Hard, lo que significa que encontrar la solución óptima de una instancia puede tomar un tiempo significativo. Por este mo-tivo, los métodos existentes en la literatura presentan limitaciones y simplificaciones del problema para abordarlo, pero esto restringe su aplicación para tareas en tiempo de ejecución, como la adaptación dinámica de sistemas. Por ejemplo, la mayoría de los métodos sólo contemplan las notaciones básicas del lenguaje de definición de FMs y no soportan extensiones del lenguaje que aumentan su expresividad y son utilizadas por algunos modelos reales disponibles en repositorios comoSPLOT2. Además, para simplificar el problema, la mayor parte de los autores asumen funciones objetivos y restricciones lineales, que limitan el tipo de preferencias, métricas y modelos de QoS que se pueden optimizar. Por último, varios enfoques no proveen soluciones exactas, sino aproximadas, y algunos no son correctos, en el sentido que no aseguran retornar soluciones válidas, es decir, que satisfacen todas las restricciones del modelo.

Un problema de Ingeniería de Software interesante para explorar mediante la op-timización deFMs es el de composición de servicios basada en QoS (QoS-Aware Service Composition) [14]. La composición de servicios es el proceso mediante el cuál se cons-truye un nuevo servicio compuesto o sistema a partir del agregado de servicios más simples o atómicos, con el fin de satisfacer una funcionalidad compleja requerida por un grupo de clientes [15]. La composición de servicios basada enQoSes un problema de optimización que consiste en encontrar la configuración del servicio compuesto que optimiza sus propiedades de calidad de servicio. Este problema ha sido abordado en la literatura con diferentes enfoques y técnicas de optimización [14], pero ha sido poco explorado en relación a FMs y técnicas relacionadas.

1.1. Composición de servicios basada en QoS

Los servicios son componentes de software que proveen funcionalidades especí-ficas a través de una interfaz y que buscan satisfacer necesidades comunes de varios clientes, como por ejemplo, procesamiento de pagos electrónicos, búsqueda de conte-nido, consulta de pronóstico del tiempo, entre otras. En muchas situaciones, un único servicio no es capaz de satisfacer necesidades complejas. Por ejemplo, un usuario pue-de querer planificar un viaje completo que abarque la reserva y pago pue-de pasajes aéreos, hoteles y el alquiler de un vehículo. En la práctica es difícil encontrar un servicio que implemente una tarea tan compleja. Más bien, esta tarea puede resolverse descom-poníéndola en subtareas (reserva de hotel, reserva de pasajes aéreos, alquiler de un vehículo, y procesamiento del pago) y haciendo que cada una se corresponda con una solicitud a un servicio individual y diferente para satisfacer los requerimientos del usuario. En estas situaciones se hace necesaria la composición de servicios [16, 15].

Los servicios y sus parámetros pueden combinarse de varias maneras para cons-truir un servicio compuesto. Por ejemplo, la misma subtarea puede ser resuelta por servicios alternativos que ofrecen la misma funcionalidad pero con distintas propie-dades de QoS. A su vez, los servicios pueden invocarse con diferentes parámetros de configuración, y pueden orquestarse en diferentes workflows o flujos de ejecución, mientras se respeten las dependencias entre servicios. Siguiendo con el ejemplo

(19)

1.2. LA TESIS

rior, podría llevarse a cabo primero la reserva y pago del hotel y luego la reserva y pago de los pasajes aéreos, o viceversa, pero, por una restricción lógica, las reservas de un producto deben realizarse antes de su pago. Esto deriva en el problema de se-leccionar la configuración del servicio compuesto, es decir, una combinación válida de servicios y parámetros, que maximice elQoSdel sistema.

Encontrar la configuración óptima de un sistema en términos de QoS, con una composición compleja y un conjunto extenso de servicios candidatos, puede ser costo-so de realizar manualmente y también automáticamente, porque suele haber una gran cantidad de combinaciones para elegir. El problema puede implicar la optimización de una o más propiedades deQoSque pueden estar en conflicto entre ellas (puntos de trade-off). Por ejemplo, una configuraciónC1puede ofrecer menor tiempo de

respues-ta promedio que otra configuraciónC2, pero seguramente a expensas de un mayor

costo del servicio o menor disponibilidad. Por último y no menos importante, esti-mar con precisión las propiedades deQoSpara utilizar como criterio de selección es una tarea no trivial porque las propiedades no funcionales emergen de la interacción entre las partes [17] y pueden variar dinámicamente debido a cambios en el contexto de ejecución del sistema, como la carga de trabajo de un sistema o la disponibilidad de recursos del ambiente en el que se despliega. La medición de todas las posibles configuraciones antes de seleccionar la configuración óptica es un enfoque inviable.

Para optimizar los requisitos deQoS dinámicamente, se han propuesto arquitec-turas auto-adaptativas que monitorean el contexto de ejecución del sistema y actúan automáticamente en consecuencia [18]. Estas arquitecturas requieren de un modelo interno para representar la variabilidad del sistema y sus propiedades de QoS, y un proceso algorítmico para planificar la adaptación. En este sentido, los FMs son un formalismo aceptado para representar sistemas adaptativos [19] y basados en servi-cios [20]. No obstante, los enfoques existentes en la literatura basados en FMs han abordado este problema de manera parcial, no sólo por las limitaciones presentes en los algoritmos de optimización, si no además porque no ofrecen guías generales pa-ra modelar la variabilidad de composiciones de servicios, especificar sus propiedades de QoS, y asociar los features del modelo a elementos de software reales, es decir, los componentes, servicios y parámetros que forman la configuración real de un sistema.

1.2. La tesis

En esta tesis se presenta un enfoque basado en FMs para planificar la adaptación de sistemas y en particular composiciones de servicios, dirigida por requerimientos de calidad de servicio. El objetivo del enfoque es modelar la variabilidad del sistema mediante FMs, y abordar su adaptación como un problema de selección de configura-ciones en FMs. La hipótesis principal de trabajo es la siguiente:

El problema de selección de configuraciones en feature models puede resolverse de manera eficiente mediante técnicas de búsqueda heurística, que posibiliten resolver la selección y adaptación de composiciones de servicios dirigida por requerimientos de calidad de servicio.

(20)

1.2. LA TESIS

Sistema adaptativo Planiﬁcador

CSA

(Algoritmo de Selección de Conﬁguraciones) Modelo del

sistema

Eventos/Parámetros de ejecución

Actuador Sensor/

Monitor

Acciones de adaptación

Proceso de desarrollo

Usuarios Tiempo de

ejecución

Arquitecto/ Desarrolladores

Figura 1.1:Esquema general del enfoque FMPlanning

servicios con el objetivo de optimizar su QoS. En tiempo de ejecución, el planificador considera eventos y parámetros del sistema (por ej., errores de ejecución, cambios de requerimientos o disponibilidad de recursos, entre otros) para decidir las acciones de adaptación con las cuales reconfigurarlo. Internamente utiliza un FM que representa la variabilidad y posibles configuraciones del sistema, y un algoritmo, denominado CSA(Configuration Selection Algorithm), para seleccionar la configuración óptima del sistema en término de requerimientos de QoS.

En segundo lugar, se ha desarrollado el algoritmo CSA para resolver el proble-ma de selección de configuraciones en FMs. El algoritmo se puede parametrizar con una familia de heurísticas y estrategias de búsqueda basadas en técnicas de búsqueda sistemática y heurística [21]. Fue diseñado con el objetivo de resolver las principa-les limitaciones presentes en los algoritmos de la literatura, y presenta una serie de propiedades de desempeño que lo hacen adecuado para su aplicación en tiempo de ejecución, como parte del planificador de adaptación.

Por último, aplicar el enfoque requiere de un proceso para que los desarrolladores del sistema adaptativo puedan integrarlo al planificador. Este proceso involucra tres actividades: i) construir un FM del sistema que represente su variabilidad y posibles configuraciones, ii) establecer los objetivos de adaptación, como por ejemplo, optimi-zar determinadas propiedades y satisfacer determinadas restricciones de QoS, y iii) integrar el planificador al sistema adaptativo utilizando la API que ofrece este último para ser monitoreado y reconfigurado dinámicamente.

El desarrollo del enfoque y sus componentes se basa en los siguientes aspectos: Representar la variabilidad del sistema y su contexto mediante FMs. Estos mo-delos se destacan por su simplicidad para ser analizados y manipulados auto-máticamente, y por su expresividad para representar la variabilidad y posibles configuraciones de un sistema de software.

Soportar una definición general del problema de selección de configuraciones en FMs, que admita restricciones globales y funciones objetivos generales para representar distintos requerimientos de QoS.

(21)

1.3. ORGANIZACIÓN

Desde un punto de vista práctico, el enfoque puede ser utilizado para implementar sistemas auto-adaptativos, o brindar capacidades de adaptación a sistemas existentes. Este sistema puede ser, por ejemplo, una aplicación móvil que consume un grupo de servicios Web con propiedades tales como disponibilidad o performance, que necesi-ten ser ajustadas dinámicamente; o también un broker Web que orqueste un grupo de servicios o componentes distribuidos, y que se adapte de acuerdo a sus objetivos de QoS.

El enfoqueFMPlanning y el algoritmoCSAfueron evaluados con distintos méto-dos. Por un lado, el algoritmo se validó con una serie de experimentos utilizando mo-delos sintéticos y reales de diferentes dominios para compararlo empíricamente con alternativas de terceros, mostrando mejoras significativas de desempeño. Por otro la-do, el enfoque de adaptación se validó de manera práctica aplicándolo sobre distintos casos de sistemas adaptativos basados en servicios.

En resumen, las contribución principal de este trabajo es la utilización de técnicas de búsqueda sistemática con heurísticas originales para el problema de selección de configuraciones en FMs. Otras contribuciones incluyen: la definición de un proceso para modelar la variabilidad de composiciones de servicios mediante FMs, estrategias para representar propiedades de QoS mediante funciones matemáticas, y un planifi-cador para la adaptación de sistemas dirigida por requerimientos de QoS.

1.3. Organización

El resto de esta tesis está organizada de la siguiente manera. El Capítulo 2 explica el marco teórico del trabajo. En este se describen los conceptos principales mencionados a lo largo del documento, tales como: feature models, sistemas adaptativos y compo-siciones de servicios, y se definen el problema de optimización de FMs y el problema de composición de servicios basada en QoS.

El Capítulo 3 presenta los trabajos relacionados y se discuten sus limitaciones. Es-pecíficamente, los trabajos relacionados se organizan en tres líneas de investigación. Primero, se presentan técnicas y algoritmos para resolver el problema de composición de servicios basada en QoS. Segundo, se presentan técnicas y algoritmos para resolver el problema de optimización de FMs. Por último, se exploran trabajos que proponen utilizar FMs en el dominio de los sistemas adaptativos y basados en servicios.

El Capítulo 4 describe el enfoque FMPlanning, explicando el funcionamiento del planificador, y el proceso para aplicar el enfoque. Se incluyen ejemplos de adaptación de un sistema con su correspondiente FM para ilustrar los distintos aspectos del enfo-que.

El Capítulo 5 describe el algoritmo CSA. Primero se explica el esquema general del algoritmo. Luego se presentan las distintas estrategias de búsqueda y heurísticas con las que se puede parametrizar el algoritmo. Por último, se presenta un análisis teórico de estas variantes en términos de eficiencia y optimalidad.

El Capítulo 6 reporta una serie de experimentos llevados a cabo para validar em-píricamente el algoritmo CSA. Estos experimentos involucran distintas muestras del problema de optimización de FMs, basados en instancias sintéticas y reales de mode-los, y la comparación de las variantes del algoritmo CSA con algoritmos de terceros exactos y aproximados.

(22)

1.3. ORGANIZACIÓN

(23)

Cap´ıtulo

2

Marco teórico

El objetivo de este capítulo es introducir los conceptos fundamentales que servi-rán para contextualizar el trabajo de tesis y los trabajos relacionados. Primero, en la Sección 2.1 se presentan los FMs y conceptos relacionados. Luego, en la Sección 2.2 se describe el problema de optimización o selección de configuraciones en FMs. Luego, en la Sección 2.3, se introduce el concepto de sistemas auto-adaptativos, y en la Sec-ción 2.4 se presenta un ejemplo ilustrativo que se utiliza para explicar el enfoque y los conceptos relacionados. Por último, en la Sección 2.5 se presentan conceptos re-levantes de composición de servicios, y en la Sección 2.6 se describe el problema de optimización conocido como composición de servicios basada en QoS.

2.1. Feature models

Elmodelo de característicasofeature model(FM) [3] es un lenguaje de modelado para representar los aspectos comunes, variables y las reglas de configuración de un siste-ma. En la literatura se han propuesto varias herramientas y frameworks para definir estos modelos (por ej., FAMILIAR [22], SPLOT [23] y Feature IDE [24]) y también al-goritmos para manipularlos y analizarlos automáticamente con distintos propósitos [3].

Un FM es una representación compacta del conjunto de posibles configuraciones de un sistema. Estos se definen mediante una jerarquía defeaturesrelacionados entre si, que se visualizan mediante diagramas de características como el presentado en la Figura 2.1. En este caso el modelo representa una familia de dispositivos GPS, con los features que los forman, y sus posibles combinaciones. Un feature corresponde a un aspecto seleccionable del sistema de cualquier nivel de abstracción, como por ejem-plo: requerimientos funcionales y no funcionales, entidades y condiciones del contex-to de ejecución, parámetros y componentes del sistema, entre otros. Escontex-tos features se vinculan mediante restricciones, las cuales determinan las combinaciones válidas de features que se pueden seleccionar. Estas restricciones pueden ser de dos tipos:

Restricciones de árbol o TCs (del inglés Tree-Constraints). Son relaciones lógicas (por ej., opcional, mandatorio, alternativo) entre un feature padre y uno o más features hijos osub-features.

(24)

2.1. FEATURE MODELS

Figura 2.1:Ejemplo de FM

De acuerdo a las restricciones del ejemplo de la Figura 2.1, todos los dispositivos GPSdeben incluir software de enrutamiento (Routing) y una interfaz para su uso (In-terface). Esta interfaz consiste en una pantalla (Screen) que puede ser de dos tipos,LCD o táctil (Touch), y opcionalmente puede incluir un teclado (Keyboard). El dispositivo puede incluir además soporte paraRadioy alertas de tráfico (Traffic avoiding). El servi-cio de radio puede serAM,FM,Digitalo cualquier combinación de los tres. Por último, el modelo contiene dosCTCs:“Traffic avoidingimplicaAuto-rerouting”, y“Keyboard ex-cluyeTouch”. La primera restricción expresa que si el software del dispositivo provee alertas de tráfico, debe soportar además enrutamiento automático (Auto-rerouting). La segunda restricción expresa que el teclado es incompatible con una pantalla táctil. 2.1.1. Configuraciones

Los FMs se pueden analizar y manipular con diferentes enfoques [3], tales co-mo lógica proposicional, programación de restricciones, programación lineal, o en-foques ad-hoc. Con lógica proposicional, cadafeaturedel modelo corresponde a una variable booleana que puede tomar uno entre dos valores, Seleccionado o Deseleccio-nado(Verdadero, Falso o 1, 0), y las restricciones del modelo (TCs y CTCs) se tradu-cen a expresiones lógicas que restringen el valor de los features (por ej.,FeatureA⇒

FeatureB∧FeatureC). Una configuración válida del modelo es un conjunto de asigna-ciones de features a valores (SeleccionadooDeseleccionado) que satisfacen estas restric-ciones. Las configuraciones se pueden clasificar en parciales o completas dependiendo de la cantidad de features asignados:

Configuración completaoproducto1es aquella configuración donde todos los fea-tures tienen un valor asignado. Formalmente, una configuración completa es una tuplaC=hS,DidondeSyDson los conjuntos de features seleccionados y deseleccionados respectivamente, de tal forma queST

D=_∅ySS

D=F, siendo Fel conjunto total de features.

Configuración parcial es aquella configuración donde uno o más features no es-tán asignados. Estas configuraciones representan un conjunto de productos ya que los features sin asignar se pueden seleccionar y deseleccionar en diferentes combinaciones, dando lugar a diferentes productos. Formalmente, una configu-ración parcial es una tupla hS,D,Ui donde U es un conjunto de features sin asignar, de tal forma queS,D, yUson disjuntos por pares ySS

DS

U=F.

1_{En esta tesis, ambos términos se usan intercambiablemente, aunque en la literatura el término}

(25)

2.1. FEATURE MODELS

Relación Fórmula en lógica proposicional

(prepresenta un feature padre yc1, ...,cnson sus features hijos.

f1y f2denotan features arbitrarios)

Mandatorio c1⇔p

Opcional c1⇒p

Grupo Alternativo (W

1≤i≤nci⇔p)∧Vi<j(¬ci∨ ¬cj)

GrupoOr W

1≤i≤nci⇔p

Implicar f1⇒ f2

Excluir ¬(f1∧ f2)

Cuadro 2.1:TCs y CTCs en lógica proposicional.

Una configuración es válida o factible si los conjuntos S y D no violan ninguna de las restricciones impuestas por el modelo. En la Figura 2.2 se presenta un ejemplo de configuración completa y parcial válidas del modelo de GPS.

(a) Configuración parcial

(b) Configuración completa

Figura 2.2:Ejemplo de configuraciones del modelo de GPS

2.1.2. Elementos básicos del lenguaje

Los FMs fueron introducidos por Kang et al. como parte del métodoFODA (Feature-Oriented Domain Analysis) [1]. FODA define un lenguaje para FMs con un conjunto básico de relaciones (TCs y CTCs) entre features, que se resumen en el Cuadro 2.1. La mayoría de los trabajos en optimización de FMs sólo contemplan estas relaciones.

Estas relaciones incluyen las siguientes restricciones de árbol (TCs):

(26)

2.1. FEATURE MODELS

Opcional. Un feature hijo tiene una relación opcional con su padre cuando el hijo puede incluirse opcionalmente en los productos donde aparece su padre. En el ejemplo, la interfaz del GPS (Interface) puede incluir opcionalmente un teclado (Keyboard).

Grupo Alternativo. Un conjunto de feature hijos tienen una relación de grupo al-ternativo con un feature padre cuando sólo uno de los features del grupo debe ser seleccionado cuando su padre es parte del producto. En el ejemplo, la panta-lla del GPS (Screen) puede serLCDoTouch, pero sólo uno de ellos.

Grupo Or. Un conjunto de feature hijos tienen una relación de grupoOrcon un feature padre cuando uno o más de ellos pueden incluirse en los productos don-de aparecen su padre. En el ejemplo, los features3D Map,Auto-reroutingo ambos pueden ser seleccionados como parte del software de enrutamiento (Routing). Un feature hijo puede aparecer en un producto sólo si su padre lo hace, y, por defecto, el feature raíz es parte de todos los productos del modelo, es decir, que pertenece al conjunto de features seleccionados. Además de los TCs mencionados anteriormente, el lenguaje definido en FODA contempla las siguientes restricciones cruzadas (CTCs): Implicar(oRequerir). Si un feature f1“requiere” un feature f2, la inclusión de f1

en el producto implica la inclusión de f2. Por ejemplo, un GPS que incluyeTraffic

avoidingdebe incluir ademásAuto-rerouting.

Excluir. Si un feature f1“excluye” un feature f2, ambos no pueden ser parte del

mismo producto. Por ejemplo, Keyboardy Touch screenson features incompati-bles.

2.1.3. Extensiones del lenguaje

Se han propuesto varias extensiones a los elementos básicos del lenguaje [25], im-pulsadas por su integridad conceptual y aplicaciones prácticas. Entre ellas se destacan las siguientes tres extensiones:grupos de cardinalidadcomo TCs,formulas proposicionales generalescomo CTCs, yatributos de features e interacciones.

Grupos de cardinalidad. Un grupo de cardinalidad es una restricción de árbol (TCs) que se define usando multiplicidades similares a UML, llamadas cardinalida-des [25]. Un grupo de cardinalidad es un intervalo denotado como hn;mi, sien-donla cota inferior ymla cota superior que limitan el número de features hijos que pueden ser seleccionados como parte del producto cuando se selecciona el feature padre. Las relaciones de árbol básicas pueden representarse como grupos de cardinalidad, con los siguientes límites: h1; 1ipara relaciones mandatorias y grupos Alternativos,h0; 1ipara opcionales, y h1;nipara grupos Or, siendonla cantidad de sub-features de la relación.

(27)

2.2. OPTIMIZACIÓN DE FEATURE MODELS

(Keyboard sí y sólo sí LCD) es equivalente a (¬Keyboard∨LCD)∧(Keyboard∨ ¬LCD)en CNF.

Atributos de features e interacciones. Algunas aplicaciones requieren incluir infor-mación adicional sobre los features y sus interacciones, lo que se incorpora en término de atributos. No hay consenso sobre una notación para definir estos atributos, pero la mayoría de las propuestas coinciden en que un atributo de-be consistir al menos en un nombre, un dominio y un valor [8]. Los atributos de features generalmente especifican propiedades no funcionales como el cos-to, el rendimiento o la memoria necesaria para soportar el feature. Del mismo modo, los atributos de interacciones entre features representan la influencia de una combinación de features en una propiedad no funcional. Siguiendo el ejem-plo de modelo de GPS, los features3D mapyAuto-reroutingpueden tener cada uno un atributo de “3 MB” y “2 MB” respectivamente, representando el incre-mento en el tamaño del software de enrutamiento (Routing) si los features son incluidos. Adicionalmente, una interacción puede emerger si ambos features se seleccionan simultáneamente, porque, por ejemplo, la integración de ambos re-quiere código adicional que incrementan el tamaño del software. Esta diferencia se puede expresar como un atributo de interacción entre los features 3D mapy Auto-rerouting.

En optimización, los atributos de features e interacciones se usan para definir restric-ciones globales (por ej., la memoria total consumida por los features debe ser menor que un valorv) y funciones objetivos (por ej., minimizar el costo total de los features incluidos en el producto). Los atributos que se conocen de antemano pueden incorpo-rarse manualmente al modelo, o también pueden inferirse automáticamente midiendo la influencia de cada feature e interacción sobre alguna propiedad del sistema.

2.2. Optimización de feature models

Parte de la investigación con respecto a FMs se centra en las operaciones y algo-ritmos para analizar y manipular estos modelos. Un ejemplo simple de operación es determinar si dado un productoPeste es válido para un modelo M. Otra operación más compleja seria determinar el conjunto de todos los productos válidos de un mo-delo. Una referencia completa de operaciones propuestas en la literatura se reporta en [3].

Una operación que se destaca por sus aplicaciones prácticas es la denominada se-lección de configuraciones uoptimización de FMs. Esta operación consiste en tomar un modelo y una función objetivo como entradas y retornar el producto que maximiza (o minimiza) dicha función. La función objetivo mapea cada producto a un valor numé-rico que determina la calidad de la solución respecto a algún criterio de interés por el usuario, como por ejemplo, la calidad de servicio si el modelo representa un sistema en ejecución. Además de las restricciones del modelo, esta operación puede admitir restricciones globales que el producto seleccionado debe satisfacer. Estas restricciones se pueden usar para representar reglas de configuración más complejas que las res-tricciones del modelo (TCs y CTCs) no permiten.

(28)

Optimización

Linea de Productos de Software

Requerimientos del cliente

of(C) GC

Instancia del problema

Producto óptimo

(a) Selección de productos de una SPL

Optimización

Modelo del sistema

Eventos/Parámetros de ejecución

of(C) GC

Instancia del problema

Nueva conﬁguración

Actuador

Sensor Sistema en ejecución

(b) Selección de la configuración de un sistemas en tiempo de ejecución

Figura 2.3:Aplicaciones de la operación de selección de configuraciones sobre FMs

2.2.1. Aplicaciones prácticas del problema

Con la optimización de FMs se pueden modelar y resolver distintas tareas en Inge-niería de Software. En la Figura 2.3 se ilustran dos ejemplos. La primera tarea (Figura 2.3(a)) se conoce como proceso de derivación de productos en líneas de productos de software(SPLpor Software Product Line) [5]. Una SPL [28] es una familia de sistemas similares, que comparten software reutilizable y presentan puntos de variación. El proceso de derivar un producto de una SPL es una tarea en tiempo de diseño que consiste en seleccionar una instancia de laSPLconsiderando los requerimientos de un cliente. Los componentes y reglas de configuración de la SPL se representan mediante un FM, y los requerimientos del cliente se expresan en forma de restricciones globales (por ej., el cliente desea un producto con determinados features y cuyo costo no exce-da un presupuesto exce-dado) y una función objetivo (por ej., el cliente desea el producto con mayor tolerancia a fallos), y luego un algoritmo calcula el producto óptimo.

La segunda tarea (Figura 2.3(b)) consiste en seleccionar la configuración óptima de un sistema en tiempo de carga o de ejecución [19]. Esta operación es común en siste-mas adaptativos, los cuales se reconfiguran dinámicamente por razones como fallas del sistema, degradación de la calidad de servicio, cambios en la disponibilidad de recursos o cambios de requerimientos del usuario. En este contexto, un FM represen-ta las posibles configuraciones del sistema, y los eventos en el entorno de ejecución pueden desencadenar la selección/deselección de features del modelo (por ej., una fa-lla en un componente implica deseleccionar el feature asociado a ese componente) o cambiar la función objetivo (por ej., un aumento en la carga de trabajo requiere encon-trar una solución más escalable). Un algoritmo de optimización puede enconencon-trar que una nueva configuración del sistema es más óptima que la actual, lo que dispara una reconfiguración.

Siguiendo el ejemplo de línea de productos de GPS (Figura 2.4), podemos definir el problema de seleccionar el producto GPS con máximo beneficio que no exceda un presupuesto dado. La Figura 2.4 ilustra el modelo enriquecido con atributos asociados a propiedades de costo y beneficio de cada feature. El costo y beneficio de un producto

(29)

Figura 2.4:Ejemplo de modelo con atributos

Formalmente: beneficio(C) =∑_f_∈_Sbeneficiof y costo(C) =∑f∈Scostof. Nótese que

al-gunos features (por ej.,GPS, Interface, Screen) no tienen atributos asociados. Esto se interpreta como un costo y beneficio implícito igual a 0.

El producto con máximo beneficio is aquel que incluyeTraffic avoiding, todos los sub-features deRoutingy Radio,touchscreen en lugar deLCDscreen, y conkeyboard deseleccionado, ya que los featuresTouch yKeyboardno pueden ser seleccionados si-multáneamente por una restricción de exclusión. Este producto tiene un beneficio total de 29,5 y un costo de $ 61. Si se asigna un presupuesto de $ 60 como restricción glo-bal (costo(C)≤$60), el producto óptimo seria similar al anterior, pero con el feature AMdeseleccionado, lo que resulta en un producto de beneficio igual a 29 y costo de $ 60. Esta restricción de presupuesto sólo es satisfecha por 75 productos del total de 80 que pueden derivarse del modelo. A medida que el presupuesto se reduce, menos productos cumplen la restricción.

2.2.2. Definición formal del problema de optimización

Los enfoques que abordan el problema de optimización en FMs proponen distintas definiciones del problema de acuerdo a los elementos que soportan. En esta tesis se propone una definición general del problema para contemplar todos los elementos del modelo mencionados en la Sección 2.1. Así, las instancias del problema se definen como tuplashF,TC,CTC,GC,OFidonde:

F={f1, ...,fn}es el conjunto de variables booleanas que representan los dos

po-sibles estados de cada feature del modelo: seleccionado (1) o deseleccionado (0). Como ejemplo, el modelo de la Figura 2.1 contiene 14 variables (features). TC= {tc1, ...,tcm} es el conjunto de restricciones de árbol que relacionan los

features jerárquicamente. Estas restricciones pueden ser de los siguientes tipos: mandatoria, opcional, grupo alternativo, grupo Or, o grupo de cardinalidad. El modelo de ejemplo contiene 9 TCs: 3 mandatorias, 3 opcionales, 2 gruposOry 1 grupo alternativo.

CTC={ctc1, ...,ctcl}es el conjunto de restricciones cruzadas del modelo, el cual

puede ser vacío. Estas se representan mediante fórmulas en lógica proposicional que relacionan features. El modelo de ejemplo contiene 2 CTCs:Traffic avoiding⇒

Auto reroutingy¬Keyboard∨ ¬Touch. GC=

gc1, ...,gcg es un conjunto de restricciones globales que involucran un

(30)

pue-2.2. OPTIMIZACIÓN DE FEATURE MODELS

5 10 15 20 25 30 35

25 30 35 40 45 50 55 60 65

Be

ne

fi

cio

Costo Configuraciones

Pareto óptimas

Figura 2.5:Frontera de Pareto de las configuraciones del modelo de GPS

de ser vacío, y se usa para representar restricciones que no pueden expresarse medianteTCsyCTCs, como por ejemplo restricciones de desigualdad lineal de la forma

∑

_f

i∈Ffi×ai<αo

∑

fi∈Ffi×ai ≤α, dondeai es un atributo numérico

asociado al feature f_i(por ej., costo del feature, memoria requerida),αes un

lími-te asociado al atributo a, y fitoma un valor discreto entre 1 y 0 si el feature está

seleccionado o no. Estas restricciones se usan principalmente para representar limitaciones de recursos. Por ejemplo, un producto no debe exceder cierto pre-supuesto, o el tamaño de un sistema no puede exceder la capacidad de memoria del dispositivo.

OF={o f1, ...,o fo}es el conjunto de funciones objetivos de la forma maximizar

ominimizar o fi(C), donde o fi es una función que asigna a cada productoCun

valor numérico, generalmente asociado a alguna propiedad no funcional que se desea optimizar. Como un producto es una asignación completa de features a valores booleanos (C= [f1 =v1, ...,fn=vn]con vi ={0; 1}), cada función o fi

es una función pseudo-booleana [29], es decir, una función cuyo dominio es un arreglo de booleanos y su codominio real (o fi: {0; 1}n→R).

De acuerdo a la cantidad de funciones objetivos (OF), el problema puede clasificar-se enmono-objetivo o multi-objetivo. Si OF contiene una sola función, el problema es mono-objetivo y consiste en encontrar el producto válido que optimiza (maximiza o minimiza) la función. Este producto es llamado solución óptima. SiOFcontiene dos o más funciones, el problema es multi-objetivo y consiste en encontrar el subconjunto de productos válidos que sonPareto óptimosono dominados[30]. Se dice que una solu-ción es Pareto óptima cuando no existe otra solusolu-ción que sea más óptimo en todos los objetivos. El conjunto de soluciones Pareto óptimas se conoce comofrontera de Pareto. Por supuesto, computar la frontera de Pareto es más costoso computacionalmente que encontrar la solución óptima en un problema mono-objetivo.

(31)

Función Expresión Propiedad que representa

Polinomio multi-lineal of

PML_{(C) =}_a₊_∑ iaifi

+∑_i_<_jaijfifj+... Influencia de features y sus interacciones

en propiedades de performance

Función de agregación

Adición of+(C) = ∑

f∈S

af Costo del producto, consumo de memoria,

tiempo de respuesta en ejec. secuencial Producto of×(C) = _∏

f∈S

af Disponibilidad, fiabilidad, precisión

Máximo ofM(C) =Max

f∈S(af) Latencia, tiempo de respuesta

en ejecución paralela Mínimo ofm(C) =min

f∈S(af) Seguridad

Suma ponderada

n

∑

i=1

wi×ofi(C) Agregación de funciones objetivos

Cuadro 2.2:Ejemplos de funciones objetivos

objetivos simultáneamente, formando una frontera en el límite superior izquierdo del espacio de soluciones.

Existen distintos tipos de funciones objetivos. En el Cuadro 2.3 se listan aquellas que se referencian a lo largo de esta tesis y en los trabajos relacionados, con su corres-pondiente fórmula matemática y algunas de las propiedades que pueden representar. La primera, llamada función polinomial multi-lineal, se ha utilizada en la literatu-ra [31] paliteratu-ra representar la influencia de features y sus inteliteratu-racciones en propiedades de performance de una configuración (por ej. tiempo de ejecución). Cada término de la función esta formado por un coeficiente constanteai, y cero o más variables

boo-leanas fi. En el problema de optimización de FMs, los coeficientes de los términos

de primer orden pueden asociarse a atributos de features, mientras los coeficientes de mayor orden corresponden a atributos de interacciones entre features. Una carac-terística interesante es que cualquier función pseudo-booleana puede expresarse en términos de un polinomio multi-lineal [29], y por lo tanto esta función puede usarse para representar distintos objetivos y propiedades.

Otro tipo de funciones utilizado en la literatura son las llamadas funciones de agre-gación [32]. Estas calculan un valor (por ej., tiempo de respuesta, costo total, entre otros) de un productoC=hS,Dicomo la agregación de determinado atributoaf de

los features incluidos en el producto (f ∈S), sin considerar interacciones entre featu-res. Por ejemplo, el costo total de un producto puede calcularse como la suma de los costos individuales de los features que lo forman (costo(C) =_∑_f_∈_Scostof).

La suma ponderada o combinación lineal de funciones permite agregar varias fun-ciones objetivos en una única función matemática. En la literatura [33] se la utiliza como enfoque para transformar un problema multi-objetivo a uno mono-objetivo, de tal forma que la solución óptima del problema mono-objetivo es Pareto óptima del problema original. Dado un conjunto de funciones objetivosOF={of1, ..., ofn}, una

suma ponderada se define como∑n_i₌₁wi×ofi(C)dondewi es un peso asociado a

ca-da objetivo ofi. Si la solución óptima es aquella que minimiza la suma ponderada, los

(32)

2.3. SISTEMAS AUTO-ADAPTATIVOS

parametrización más adecuada de los pesos podría ser 0,5 para el costo y -0,5 para el desempeño (negativo para maximizar esta propiedad).

2.3. Sistemas auto-adaptativos

En los últimos años, distintos trabajos han propuesto aplicar FMs para la adapta-ción de sistemas en tiempo de ejecuadapta-ción. En este contexto, se han propuesto enfoques adaptativos en distintos dominios, como por ejemplo: composiciones de servicios [34], sistemas en la nube [35], y aplicaciones móviles [36]. Esto ha motivado el desarrollo de algoritmos más eficientes para contextos específicos.

Un sistema adaptativo es un sistema cuyo comportamiento y configuración se pue-den cambiar durante su ejecución. Sí el sistema además puede reaccionar de forma au-tónoma a cambios del contexto y adaptar automáticamente su propia configuración, se denomina auto-adaptativo [37]. Los eventos que disparan una adaptación pueden tener su origen en el propio sistema, por ejemplo un error durante su ejecución, o en el contexto del mismo, tal como una acción realizada por el usuario y cambios en el estado de los recursos. Los sistemas auto-adaptativos monitorean constantemente su estado y el de su contexto, y se adaptan a los cambios del mismo para optimizar su funcionamiento.

La Computación Autónoma [18] estudia los métodos y técnicas que brindan pro-piedades auto-adaptativas a estos sistemas. Según su objetivo, estas propro-piedades son: Auto-configuración: propiedad del sistema de configurarse por si mismo de acuer-do a requerimientos de la plataforma y de los usuarios.

Auto-optimización: propiedad del sistema de monitorear el uso de recursos, y re-configurarse proactivamente para mejorar su rendimiento o calidad del servicio. Auto-curación: propiedad del sistema de detectar y diagnosticar problemas, y de reconfigurarse para evitarlos y solucionarlos. Esta capacidad se relaciona con la tolerancia a fallos del sistema.

Auto-protección: propiedad del sistema de protegerse a si mismo de ataques ma-liciosos pero también de usuarios que inadvertidamente hacen cambios de soft-ware. El sistema se reconfigura en pos de la seguridad del sistema.

Los sistemas auto-adaptativos se suelen esquematizar como un bucle de control si-guiendo el modelo de referenciaMAPE-K[38], como se muestra en la Figura 2.6. En MAPE-K, el elemento gestionado es el sistema de software en ejecución, al que se la dan capacidades autónomas de adaptación acoplándolo a un componente que ges-tiona dicha adaptación. Este gestor se construye en términos de un modelo de cono-cimiento, el cual representa información interna del sistema, su contexto y requeri-mientos, y cuatro funciones o etapas denominadasMonitoreo,Análisis,Planificacióny Ejecución, que definen el bucle de control autónomo:

Monitoreo y Análisis: estas etapas involucran monitorear datos del sistema en eje-cución y analizarlos para obtener información útil que permita determinar si es necesario adaptar o no el sistema.

(33)

2.4. EJEMPLO: SISTEMA DE VIDEO VIGILANCIA

en reglas Evento-Condición-Acción(ECA) que producen directamente planes de adaptación a partir de combinaciones de eventos específicos.

Ejecución: se encarga de aplicar las acciones de adaptación determinadas por la etapa de planificación.

Gestor de adaptación

Eventos/Información del sistema

Ejecución

Monitoreo y Análisis

Sistema en ejecución

Planiﬁcación

Optimización Modelo del

sistema

of(C) GC

Nueva conﬁguración

Acciones de adaptación

Figura 2.6:Modelo de referencia MAPE-K basado en FMs

En el contexto de un enfoque adaptativo basados en FMs, como se ilustra en la Figura 2.6, los FMs se pueden usar para representar el sistema y su contexto. Cada producto o configuración completa del modelo representa una configuración concre-ta del sistema. De esconcre-ta forma, la planificación se puede abordar como una selección de configuraciones en FMs. Cuando la etapa de análisis informa algún evento o cam-bio en el contexto, se ejecuta el algoritmo de optimización para seleccionar una nueva configuración óptima del sistema. Si la configuración encontrada difiere de la configu-ración actual, el sistema debe adaptarse. Caso contrario, la adaptación no es necesaria.

2.4. Ejemplo: Sistema de video vigilancia

Un sistema de videovigilancia es un ejemplo de software que presenta variabilidad en varios aspectos de su arquitectura. Por el lado de su implementación, el sistema se puede ver como una composición secuencial de servicios donde una o más cámaras capturan video en tiempo real y una sucesión de servicios lo procesan con distintos objetivos. Su configuración es compleja debido a la cantidad de servicios alternativos que se pueden seleccionar, las diferentes maneras de conectarlos y parametrizarlos. Por el lado de los requerimientos también hay varios aspectos que presentan variabi-lidad. Por ejemplo, el sistema puede ofrecer distintas aplicaciones o funcionalidades de videovigilancia como se ilustra en la Figura 2.7, tales como rastrear objetos o indi-viduos en un video, detectar intrusiones y reconocer actividades en tiempo real, entre otras. También el contexto en el que se ejecuta el sistema (por ej., interior, exterior, luz artificial o natural), y la calidad del servicio que se requiere (por ej., precisión, desem-peño) puede variar.

(34)

2.4. EJEMPLO: SISTEMA DE VIDEO VIGILANCIA

Figura 2.7:Ejemplos de aplicaciones del sistema de videovigilancia

Image

acquisition Segmentation

Frame to frame (tracking)

Physical objects

Reference image Raw

image

Scenario Recognition Classification

Blobs

Figura 2.8:Posible configuración del sistema de videovigilancia

del sistema. Su arquitectura sigue un patrón depipes and filtersformando una cadena de servicios, donde la salida de cada servicio es la entrada del siguiente. La cadena comienza con la adquisición de imágenes, luego con la segmentación de las imágenes para agrupar regiones en blobs, clasificación de posibles objetos, seguimiento de estos objetos de un cuadro a otro, y finalmente reconocimiento de escenarios para, por ejem-plo, detectar intrusos. Los resultados de salida pueden visualizarse y generar alertas para observadores humanos. La cadena puede involucrar etapas adicionales (por ej., clustering, eliminación de sombras, fusión de imágenes), que requieren la ejecución de diferentes servicios de software. Estos servicios pueden tener variantes (por ej., algo-ritmos, estrategias, datos de entrada, etc.), cada uno correspondiente a un parámetro de configuración diferente.

Los requerimientos y el contexto del sistema pueden cambiar en tiempo de ejecu-ción, lo que implica adaptar la configuración del sistema dinámicamente. Por ejemplo, cambios de iluminación en el video de entrada pueden disparar el cambio o la repara-metrización de los algoritmos de adquisición y segmentación de la imagen. Como otro ejemplo, los usuarios pueden requerir reconocer diferentes eventos o realizar diferen-tes tareas, lo que implica reemplazar dinámicamente los componendiferen-tes dependiendo de la tarea requerida.

Representación mediante feature models

Los FMs pueden usarse para representar los puntos de variabilidad de los distin-tos aspecdistin-tos del sistema, y automatizar la selección de su configuración óptima, tanto en tiempo de despliegue (seleccionando la configuración inicial), y en tiempo de eje-cución (cambiando la configuración del sistema para adaptarlo). En este sentido, la Figura 2.9 presenta un FM del sistema de videovigilancia de ejemplo. Este modelo se diseñó con un foco en la separación de los requerimientos y los aspectos de implemen-tación, por lo tanto, la raíz del modelo se descompone en dos ramas o submodelos: VSspecificationyVScomponent. El primer submodelo representa "qué hacer" e incluye la funcionalidad ofrecida (featuresApplication, ObjectOfInterest), parámetros de cali-dad deseados por los usuarios (featureQoS) y condiciones ambientales y de hardware (featureContext). El segundo submodelo representa los componentes del sistema y sus parámetros, es decir "cómo (el software) debería hacerlo".

(35)

ejem-2.4. EJEMPLO: SISTEMA DE VIDEO VIGILANCIA

VS specification

Application QoS Context

with Recognition without Recognition Intrusion Lighting High Low VS component Segmentation Classification Image Acquisition Segmentation Precision High Low VS system Opcional Mandatorio Feature Alternativo Grupo Or Object of interest Restricciones cruzadas:

Application.Intrusion.WithRecognitionimplicaScenarioRecognition ShadowRemovalimplicaContext.Lighting.High

…

Shadow Removal

Scenario Recognition

Figura 2.9:Extracto del FM del sistema de video vigilancia

VS component Acquisition Shadow Removal Segmentation Classification Resolution Color Multi -Gaussian

Any object People

Scenario Recognition People based Simple Frame to frame Long term 3D Texture Color B&W Full

High Low 3D Color

Image acquisition Segmentation

Resolution Color Motion

based

Multi -Gaussian

Tracking Scenario Recognition

People based Simple Frame to frame Long term 3D Texture Color B&W NearIR Full

High Low 3D

Texture Color

VS system Restricciones cruzadas

ScenarioRecognition.People-basedimplicaClassification.People Tracking.*.TextureimplicaAcquisition.Resolution.High Tracking.*.Color implicaAcquisition.Color.Full

✘ ✔ ✔ ✔ ✔ ✔ _✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘ Feature abstracto

Feature concreto (servicio) Feature concreto (valor de parámetro)

Referencia

✔

✘SeleccionadoDeseleccionado Sin asignar ?

Figura 2.10:Ejemplo de configuración completa del modelo del sistema de videovigilancia

plo, si un servicioAdepende de los resultados de dos serviciosB yC, se incluye la restricción “A implica B y C” (A⇒B∧C). Además, las restricciones cruzadas entre ambos submodelos funcionan como un puente entre los requisitos de la aplicación y los elementos de software que cumplen esos requisitos. Por ejemplo, la restricción “ShadowRemovalimplicaLighting.Low” significa que si el featureLighting.Low, que re-presenta una condición de contexto de poca luz, se selecciona debido a un evento de atenuación de la luz, el servicioShadowRemovalse debe deseleccionar, es decir, no pue-de ser parte pue-de la configuración pue-del sistema en ejecución.

El modelo es una representación compacta de todas las posibles configuraciones del sistema. Así, cada configuración completa del modelo representa una configura-ción real del sistema. Como ejemplo, la Figura 2.10 muestra la configuraconfigura-ción del mo-delo que representa la configuración del sistema en la Figura 2.8 (por el tamaño del modelo, sólo se visualiza la ramaVScomponent). Los features seleccionados están aso-ciados con algún componente o parámetro de la configuración real del sistema.

En un contexto de ejecución dado, muchas configuraciones son válidas, pero só-lo una de ellas puede estar en ejecución. Esto significa que se debe seleccionar una configuración completa del modelo cuando se inicializa el sistema o se requiere una adaptación. Los cambios de contexto o las interacciones del usuario son eventos que pueden desencadenar reconfiguraciones del sistema. Por ejemplo, los cambios de ilu-minación pueden tener un impacto en la parametrización de los servicios de adqui-sición y segmentación de la cadena de procesamiento. Los usuarios pueden necesitar reconocer diferentes objetos o realizar diferentes tareas, lo que implica ajustar o inclu-so reemplazar un servicio por otro dependiendo de la tarea. También, la cantidad de recursos disponible, como energía o memoria, pueden implicar una reconfiguración del sistema.

(36)

configura-2.5. COMPOSICIÓN DE SERVICIOS

ción completa, sino más bien una configuración parcial del modelo que representa el conjunto de posibles configuraciones del sistema que son válidas para dicho contex-to. El desafío está en seleccionar la configuración completa "óptima" en términos de calidad de servicio, lo que se resuelve como problema de optimización de FMs.

2.5. Composición de servicios

Un dominio más reciente en el que se a propuesto utilizar FMs es el de sistemas basados en servicios [39]. En este contexto, se conoce como composición de servicios al proceso mediante el cuál se construye un nuevo sistema o servicio compuesto a partir del agregado de servicios más simples o atómicos, con el fin de satisfacer una funcionalidad más compleja requerida por un grupo de usuarios [15]. Por servicio se entiende a la funcionalidad brindada por un componente de software a través de mé-todos, funciones u operaciones. Un componente está formado así por dos partes: su interfaz de programación (API), que es la descripción funcional de los servicios que ofrece, y su implementación, encapsulada a través de la interfaz [40]. Los servicios promueven su composición en un esquema de “caja negra”, necesitando conocer la interfaz y protocolo de comunicación para la integración del servicio, pero no su im-plementación interna. Actualmente, la industria de software ha adoptado tecnologías Web para la implementación de servicios distribuidos denominados Servicios Web. En este contexto, los servicios pueden ser publicados, localizados y accedidos remota-mente utilizando protocolos Web estándares como HTTP, UDDI, WSDL y SOAP [41].

En cierta forma, un servicio compuesto o sistema basado en servicios puede ver-se como un proceso o flujo de ejecución (workflow) de ver-servicios [17], es decir, una secuencia de invocaciones de servicios/funciones que deben realizarse con el fin de lograr un objetivo conjunto. El flujo de ejecución es típicamente organizado con un grupo de estructuras o patrones de control, tales como: secuencia, selección, bucle y ejecución en paralelo [42].

A modo de ejemplo, el sistema de videovigilancia es una composición secuencial de servicios, como una arquitectura de pipeline, donde el primer servicio se encarga de capturar el video de entrada, y los siguientes van aplicando algún procesamiento sobre el mismo. Cada etapa de la composición es un servicio que provee funcionalidad específica a través de su interfaz para conectarse al siguiente servicio.

La composición de servicios se puede clasificar en base a tres aspectos principa-les [15]. En primer lugar, se distingue entre composición estática y dinámica. En se-gundo lugar, los enfoques de composición se dividen en manuales y automáticos. Por último, la composición de servicios se clasifica en orquestación y coreografía [43].