Repositorio Institucional de Documentos

Proyecto Fin de Carrera de Ingenier´ ıa en Inform´ atica Implementaci´ on de un generador de estrategias de autoconfiguraci´ on para la mejora de prestaciones de software autoadaptativo Mar´ ıa Est´ ıbaliz Fraca Santamar´ ıa Director: Diego Carmelo P´ erez Palac´ ın Codirector: Jos´ e Javier Merseguer Hern´ aiz Departamento de Inform´ atica e Ingenier´ ıa de Sistemas Centro Polit´ ecnico Superior Universidad de Zaragoza Marzo 2010 Implementaci´ on de un generador de estrategias de autoconfiguraci´ on para la mejora de prestaciones de software autoadaptativo RESUMEN Dentro del campo de la Ingenier´ ıa del Software, este trabajo se enmarca en el paradigma openworld software. El objetivo de este trabajo es estudiar c´ omo satisfacer propiedades extra-funcionales en este tipo de sistemas, en concreto la propiedad de rendimiento o prestaciones. Es este un tema de investigaci´ on nuevo, y todav´ ıa se encuentra lejos de estar resuelto. Con este trabajo intentamos avanzar en lo que se refiere al desarrollo de herramientas que faciliten y automaticen dichas tareas de evaluaci´ on. El paradigma de desarrollo open-world software propone la creaci´ on de sistemas software heterog´ eneos y distribuidos donde el entorno de ejecuci´ on cambia de forma continua e impredecible (por ejemplo, en t´ erminos de disponibilidad de servicios y degradaci´ on o aumento de las prestaciones de los mismos). Adem´ as, el paradigma entiende que los sistemas deben (a) ser conscientes de esos cambios en el entorno y (b) ser capaces de reaccionar ante ellos modificando su comportamiento, es decir, deben ser autoreconfigurables o autoadaptativos. Estos sistemas pueden seguir estrategias de reconfiguraci´ on para decidir cu´ ando y c´ omo hacer su adaptaci´ on . Un ejempo de open-world software son las arquitecturas del estilo SOA (Arquitectura Orientada a Servicios), donde el software a construir requiere servicios que son proporcionados por otras aplicaciones. Este trabajo consiste en la implementaci´ on de una parte de la arquitectura propuesta en [1] por P´ erez-Palac´ ın, Merseguer y Bernardi para la creaci´ on de estrategias de reconfiguraci´ on para software autoadaptativo. El modelado de la arquitectura se ha realizado siguiendo el est´ andar UML aumentado con informaci´ on sobre prestaciones utilizando el est´ andar “Modeling and Analysis of Real-Time and Embedded systems” (MARTE). La evaluaci´ on de los sistemas software se ha realizado utilizando el m´ etodo formal de las redes de Petri estoc´ asticas, que han sido generadas a partir de de los modelos UML anotados con MARTE. El resultado de esa evaluaci´ on sirve para crear la estrategia de reconfiguraci´ on, la cual indica al sistema que se reconfigure o permanezca el estado actual. El resultado obtenido ha sido la creaci´ on de un paquete ejecutable preparado para ser integrado en sistemas autoadaptativos que siguen la arquitectura de tres capas utilizada. Este software desarrollado corresponde a la capa m´ as desafiante y todav´ ıa desconocida de la arquitectura, la que conoceremos como “generador de estrategias”. Mediante la realizaci´ on de este paquete ejecutable se ha dado un paso adelante hacia la implementaci´ on real de los sistemas autoadaptativos en base a sus prestaciones. El resultado generado por este paquete es una estrategia de reconfiguraci´ on que dirigir´ a las reconfiguraciones del software autoadaptativo reaccionando ante los cambios percibidos en el entorno del sistema. Agradecimientos Quiero agradecer en primer lugar su apoyo, su ayuda y su inter´ es en mi proyecto a Diego P´ erez y a Jos´ e Merseguer. A Diego por las videoconferencias de una hora, por resolver mis dudas justo al poco rato de aterrizar de un avi´ on, por emocionarse con las redes de Petri contagiando su ilusi´ on. A Jos´ e por su constancia, por resolver con sencillez y eficacia las cuestiones que para mi eran un mundo, por sus palabras de ´ animo, por su rapidez en responder emails y solucionar problemas. Tambi´ en a quienes me han acompa˜ nado en mi estancia diaria en el L1.03a: Ricardo, que aun con mil cosas en la cabeza simpre saca tiempo para un caf´ e; Misho, y las conversaciones profundas durante las comidas; Hanife, con su inocencia y sinceridad; y Simona, que apareci´ o justo cuando necesit´ e ayuda con las redes de Petri. No quiero olvidarme de mis compa˜ neros/as de carrera durante estos cinco a˜ nos y pico... Alberto, Adri´ an, Pablo, Jorge, mis doce diferentes compa˜ neros/as de pr´ acticas, y otros muchos que no nombro por temor a dejarme a alguien. Finalmente, quiero agradecer su apoyo y confianza en m´ ı a Elisardo, Blanca y David; a´ Oscar; a M´ onica, Silvia, Fernando y Chema; a Erika, a Mar´ ıa, a Anna, a Nacho... Gracias. ´ Indice general I Memoria XI 1. Introducci´ on 1 1.1. Contexto......................................... 1 1.2. Objetivo y alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3. Fasesdedesarrollo ................................... 2 1.4. ´ Ambito y motivaci´ on .................................. 3 1.5. M´ etodos y herramientas empleados . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5.1. Lenguajes y est´ andares............................. 3 1.5.2. Herramientas.................................. 4 1.6. Organizaci´ ondeldocumento .............................. 4 2. Conceptos previos 5 2.1. UML .......................................... 5 2.1.1. Diagrama de Actividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. MARTE......................................... 6 2.3. XML .......................................... 7 2.4. XMI........................................... 7 2.5. RedesdePetri...................................... 7 2.6. Open-worldsoftware .................................. 8 2.7. Sistemas auto-adaptativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.8. Arquitectura de tres capas para sistemas auto-adaptativos . . . . . . . . . . . . . . . 9 3. Planteamiento del problema 11 3.1. Capa de Control de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Capa de Gesti´ ondelCambio .............................. 12 3.3. Capa de Gesti´ ondeObjetivos.............................. 12 4. Implementaci´ on del Generador de Estrategias 15 4.1. Obtenci´ on de las precondiciones del algoritmo . . . . . . . . . . . . . . . . . . . . . 15 4.1.1. Elecci´ on de una herramienta de modelado UML . . . . . . . . . . . . . . . 16 4.1.2. Lectura de los ficheros XMI . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.3. Obtenci´ on de la informaci´ on temporal de los componentes . . . . . . . . . . 16 4.2. Estrategia de reconfiguraci´ on.............................. 17 4.3. Descripci´ on de la generaci´ ondeestrategias ...................... 18 4.4. Evaluaci´ on de los workflow ............................... 21 VII 4.4.1. Traducci´ on de los flujos de ejecuci´ on a redes de Petri . . . . . . . . . . . . . 21 4.4.2. Evaluaci´ ondelasredesdePetri ........................ 22 5. Planificaci´ on temporal. 25 6. Conclusiones y trabajo futuro 27 6.1. Conclusiones y resultados obtenidos. . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2. Trabajofuturo...................................... 27 Bibliograf´ ıa 30 II Ap´ endices 31 A. Caso pr´ actico 33 A.1. Descripci´ on del problema a resolver . . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.2. Obtenci´ ondelosdatosdeentrada ........................... 34 A.2.1. Obtenci´ on del diagrama de Actividades anotado con MARTE . . . . . . . . 35 A.2.2. Obtenci´ on del diagrama de Componentes . . . . . . . . . . . . . . . . . . . 36 A.2.3. Almacenamiento de los datos durante la implementaci´ on........... 38 A.3. Descripci´ on de la generaci´ ondeestrategias ...................... 39 A.4. Estrategia de reconfiguraci´ onobtenida......................... 41 B. El paquete ejecutable desarrollado 43 B.1. Elpaqueteejecutable .................................. 43 B.2. Diagrama de clases del componente desarrollado . . . . . . . . . . . . . . . . . . . 44 C. Fases de desarrollo. Hitos y problemas encontrados 47 D. MARTE 49 E. Traducci´ on de los diagramas de Actividad de redes de Petri 51 F. Empleo de la herramienta GreatSPN 57 F.1. Formato de los ficheros de GreatSPN . . . . . . . . . . . . . . . . . . . . . . . . . . 57 F.2. Invocaci´ ondelsimulador................................ 59 G. Glosario y abreviaturas empleadas 61 ´ Indice de figuras 2.1. Ejemplo de Diagrama de Actividades . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Ejemplo de Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. EjemplodeficheroXML................................ 7 2.4. EjemplodereddePetri................................. 8 2.5. Esquema de adaptaci´ on externa para sistemas autoadaptativos . . . . . . . . . . . . 9 2.6. Esquema de la arquitectura de tres capas propuesta por Kramer y Merge . . . . . . . 10 3.1. Arquitectura de tres capas aplicada al paradigma open-world ............. 11 4.1. Ejemplo de estrategia de reconfiguraci´ on........................ 18 4.2. Ejemplo de traducci´ on de elementos de un diagrama de Actividades a LGSPN . . . . 22 4.3. Ejemplo de composici´ on de LGSPN. Se remarcan los elementos compuestos en uno solo 23 4.4. ReddePetriaevaluar.................................. 23 5.1. Diagrama de Gantt del desarrollo del proyecto . . . . . . . . . . . . . . . . . . . . . 25 5.2. Distribuci´ on del esfuerzo en las fases de desarrollo . . . . . . . . . . . . . . . . . . 25 A.1. Diagrama de Actividad con anotaciones MARTE . . . . . . . . . . . . . . . . . . . 33 A.2.DiagramadeComponentes............................... 34 A.3. Diagrama de Actividad modelado en la herramienta Papyrus con anotaciones MARTE 35 A.4. Componentes e interfaces del diagrama de Componentes . . . . . . . . . . . . . . . 36 A.5. Diagrama de Componentes modelado en la herramienta Papyrus . . . . . . . . . . . 37 A.6. Diagrama de Clases de la implementaci´ on del diagrama de Actividad . . . . . . . . . 38 A.7. Diagrama de Clases de la implementaci´ on del diagrama de Componentes . . . . . . 38 A.8. GSPN param´ etrica obtenida a partir del workflow del sistema . . . . . . . . . . . . . 39 A.9. Estrategia de reconfiguraci´ onobtenida......................... 41 B.1. Componente software desarrollado . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 B.2. Diagrama de Clases del componente desarrollado . . . . . . . . . . . . . . . . . . . 45 D.1. Anotaci´ on GaWorkloadEvent de MARTE . . . . . . . . . . . . . . . . . . . . . . . 49 D.2. Anotaci´ onResourcedeMARTE ............................ 50 D.3. Anotaci´ onGaAcqStepdeMARTE........................... 50 D.4. Anotaci´ onGaRelStepdeMARTE ........................... 50 D.5. Anotaci´ onGaRelStepdeMARTE ........................... 50 E.1. Diagrama de Actividades a traducir . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 E.2. Red de Petri obtenida de la traducci´ on del diagrama de Actividad . . . . . . . . . . . 52 E.3. Traducci´ on a RdP de los elementos de Acci´ on..................... 53 IX 41. Introducci´ on 1.5.2. Herramientas Papyrus [14]. Herramienta de modelado UML. Se alinea con el est´ andar UML 2 y soporta anotaciones con diferentes perfiles (UML profiles). Desde nuestro conocimiento es la ´ unica que soporta anotaciones del est´ andar MARTE. Se ha empleado la versi´ on 1.11. GreatSPN [7]. Herramienta de modelado, validaci´ on y evaluaci´ on de Redes de Petri estoc´ asticas generalizadas (GSPN) y su extensi´ on coloreada. Se ha empleado la versi´ on 2.0. 1.6. Organizaci´ on del documento El presente documento est´ a dividido en dos partes: la memoria, donde se explica el desarrollo del Proyecto; y los ap´ endices, donde se ampl´ ıa la informaci´ on de ciertos puntos relevantes. El cap´ ıtulo 1expone los objetivos del proyecto e introduce el documento. El cap´ ıtulo 2define los algunos conceptos previos que servir´ an de ayuda para comprender el resto del documento, como UML, red de Petri, o sistema autoadaptativo. A continuaci´ on, el cap´ ıtulo 3explica la arquitectura de tres capas en la que se enmarca el trabajo. El cap´ ıtulo 4explica la implementaci´ on del algoritmo Generador de Estrategias, as´ ı como la obtenci´ on de los datos de entrada y el significado de los datos de salida. En el cap´ ıtulo 5se hace balance del esfuerzo temporal empleado en la realizaci´ on del PFC. Finalmente, el cap´ ıtulo 6presenta las conclusiones de car´ acter personal y t´ ecnico obtenidas durante la elaboraci´ on de este Proyecto Fin de Carrera; as´ ı como una serie de trabajos futuros que complementar´ ıan y ampliar´ ıan el trabajo desarrollado. Respecto a los ap´ endices, el ap´ endice Aes un caso pr´ actico que muestra algunos detalles t´ ecnicos (modelado de diagramas con Papyrus, formato de los fichros XML, etc); y detalla la generaci´ on de estrategias trav´ es de un ejemplo. El ap´ endice Bexpone el paquete software obtenido como resultado del PFC y explica su empleo y parametrizaci´ on. Adem´ as, muestra su diagrama de Clases. A continuaci´ on, el ap´ endice Denumera y explica las anotaciones MARTE empleadas en este trabajo. Los ap´ endices EyFdetallan la traducci´ on de los diagramas de Actividad a redes de Petri y explican el empleo de la herramienta GreatSPN para la evaluaci´ on de las redes. Por ´ ultimo, el ap´ endice Gdefine algunos conceptos y abreviaturas empleados en la memoria. Cap´ ıtulo 2 Conceptos previos En el presente cap´ ıtulo se presentan los conceptos m´ as relevantes dentro de cada una de las ´ areas sobre las que trata este Proyecto Fin de Carrera. Lo explicado en este cap´ ıtulo quiere servir de base para comprender el trabajo realizado que se desarrollar´ a en los siguientes cap´ ıtulos. 2.1. UML El est´ andar UML es una especificaci´ on semi-formal que define un lenguaje gr´ afico que sirve para visualizar, especificar, construir y documentar los elementos de un sistema [10]. Fue adoptado por Object Management Group (OMG) en 1998 y es un est´ andar ISO. Actualmente se encuentra en su versi´ on 2. Proporciona soporte para la planificaci´ on y control del ciclo completo de vida del software, independientemente de la plataforma para la que se desarrolla. En ´ el tambi´ en se definen reglas sem´ anticas y de correcci´ on de modelos a trav´ es del lenguaje OCL (Object Constraint Language). UML define doce tipos distintos de diagramas gr´ aficos que sirven para describir las vistas que un modelo puede necesitar para ser caracterizado, enfocados desde el paradigma Orientado a Objetos (OO). Los empleados en este proyecto han sido diagrama de Actividad y diagrama de Componentes. 2.1.1. Diagrama de Actividad Los diagramas de Actividad se utilizan para modelar los aspectos din´ amicos de un sistema (los pasos secuenciales y concurrentes de un proceso computacional). Son un caso especial de las m´ aquinas de estados en los que ´ unicamente hay actividades y no se producen cambios de estado en el objeto que realiza dichas actividades. En la figura 2.1 se muestra ejemplo un diagrama de actividades. Los elementos principales de este tipo de diagramas son las actividades o acciones, que representan cada uno de los pasos de un proceso (en la figura se representa con rect´ angulos redondeados). Cabe destacar que podemos encontrarnos con actividades secuenciales o concurrentes. En el ejemplo anterior (ver figura 2.1) algunas actividades son ejecutadas de manera secuencial y otras que lo hacen manera concurrente, a trav´ es de los elementos de fork yjoin (bifurcaci´ on y uni´ on) representados mediante cajas verticales. La selecci´ on entre dos rutas alternativas y el fin de una selecci´ on se representa con un cuadrado rotado 45o. 2.1.2. Diagrama de Componentes Los diagramas de Componentes se utilizan para representar c´ omo un sistema software es dividido en componentes. Normalmente contienen interfaces, componentes y relaciones entre ellos; siendo un componente una parte sustituible de un sistema que realiza una interface y que puede ser reemplazable 5 62. Conceptos previos Figura 2.1: Ejemplo de Diagrama de Actividades Figura 2.2: Ejemplo de Diagrama de Componentes por otro que realice la misma interface. Y siendo una interface una especificaci´ on para las operaciones externas visibles de un componente, sin especificar su estructura interna. En la figura 2.2 se muestra un ejemplo de un Diagrama de Componentes en el que se pueden ver los componentes, las interfaces requeridas y proporcionadas por ellos, y las relaciones entre ellos. Las interfaces ofrecidas por los componentes se representan como circunferencias, mientras que las interfaces requeridas por los componentes se representan con semicircunferencias. 2.2. MARTE MARTE (Modeling and Analysis of Real-Time and Embedded systems) [3]. Es un perfil de UML 2.0 para el modelado y an´ alisis de sistemas embebidos y de tiempo real, incluidos los aspectos software yhardware. Proporciona soporte para las etapas de especificaci´ on, dise˜ no y verificaci´ on. El est´ andar MARTE ha sido desarrollado por OMG para extender las capacidades de UML para el desarrollo de sistemas de tiempo real y sistemas embebidos. Tiene el objetivo de proporcionar un est´ andar com´ un de modelado para mejorar tanto la comunicaci´ on entre desarrolladores como la interoperabilidad entre herramientas. En este proyecto el perfil MARTE se emplea para a˜ nadir anotaciones de prestaciones (anotaciones temporales) a los diagramas UML. En el anexo Dse ampl´ ıa informaci´ on acerca de las anotaciones MARTE empleadas en este PFC. 2. Conceptos previos 7 2.3. XML El est´ andar XML (Extensible Metadata Language) [12] es un metalenguaje basado en etiquetas que permite la definici´ on de lenguajes para diferentes necesidades. Algunos lenguajes y especificaciones basados en XML son XHTML, SVG o XMI. <fecha> <dia> 8 </dia> <mes> Mayo </mes> <año> 2010 </año> </fecha> Figura 2.3: Ejemplo de fichero XML Algunas de las ventajas que proporciona el empleo de XML son su generalizaci´ on, su car´ acter est´ andar como lenguaje de intercambio de datos y su simplicidad de uso tanto por humanos (es f´ acil de comprender al estar basado en texto) como por m´ aquinas (mediante su procesado mediante SAX o´ arboles DOM, su transformaci´ on mediante XSLT, u otros). La figura 2.3 muestra un ejemplo de un fichero XML. Existen dos aproximaciones para el procesado de XML: SAX y DOM, caracterizadas por diferentes ventajas y desventajas. En este proyecto se ha empleado DOM debido a que los ficheros a tratar no son especialmente grandes y a que se realizan muchas consultas sobre el mismo fichero XML. 2.4. XMI XMI (XML Metadata Interchange) [6] es una especificaci´ on basada en XML para el intercambio de modelos entre diferentes herramientas de modelado UML, desarrollada por OMG. Los diagramas UML empleados en este proyecto fueron obtenidos a trav´ es de la herramienta de modelado Papyrus y exportados en el formato XMI. Una vez obtenido el fichero XMI, ´ este fue procesado. 2.5. Redes de Petri Las redes de Petri (RdP) [4] son una herramienta matem´ atica que sirve para modelar sistemas cuyos comportamientos din´ amicos se caracterizan por la concurrencia, la sincronizaci´ on, la exclusi´ on mutua y los conflictos. Poseen una representaci´ on gr´ afica en forma de grafo dirigido en el cual los nodos pueden ser o lugares, representados como c´ ırculos, o transiciones, representadas como barras o cajas. Los arcos entre nodos pueden estar dirigidos desde un lugar hacia una transici´ on o desde una transici´ on hacia un lugar. Adem´ as, un lugar puede tener una o m´ as marcas. Los lugares suelen describir estados del sistema, mientras que las transiciones se pueden interpretar como los eventos que modifican un estado determinado del sistema. El comportamiento din´ amico de las RdP est´ a dirigido por la regla de disparo. Una transici´ on puede dispararse si todos sus lugares de entrada contienen al menos una marca o token (o tantas marcas como las indicadas en el arco que lo une con la transici´ on), entonces se dice que la transici´ on est´ a sensibilizada. Tras dispararse la transici´ on, se eliminan tantas marcas como las indicadas en cada arco y se generan nuevas marcas en los lugares de salida. En este trabajo se emplean redes de Petri estoc´ asticas generalizadas (GSPN); caracterizadas por: 82. Conceptos previos P1 P2 P3 P4 P5 T1 t4t2 t6 t5t3 Figura 2.4: Ejemplo de red de Petri 1. Las transiciones pueden ser de dos tipos: temporizadas (representadas en color blanco) e inmediatas (representadas en color negro). 2. Dos transiciones en conflicto pueden ser equiprobables o bien tener diferentes pesos asociados. 3. Las transiciones pueden tener diferente prioridad. Al a˜ nadir este concepto, la condici´ on de sensibilizaci´ on de transiciones para un marcado mse restringe, y solo quedan sensibilizadas en mlas transiciones que tienen mayor prioridad. Toda transici´ on inmediata tiene m´ as prioridad que cualquier transici´ on temporizada. 2.6. Open-world software Tradicionalmente, los paradigmas de desarrollo del software han asumido un entorno cerrado, donde el software contaba con requisitos y circunstancias conocidos e invariables. ´ Estos permanec´ ıan estables desde la definici´ on del problema y durante la ejecuci´ on del mismo. Sin embargo, estas suposiciones dejan de ser v´ alidas para un n´ umero cada vez m´ as amplio de casos. Por ejemplo, en dispositivos port´ atiles o integrados en otros aparatos de uso com´ un (computaci´ on obicua o ubiquitous computing), donde el entorno es esencialmente abierto. Teniendo en cuenta estas caracter´ ısticas, aparece el paradigma open-world [2]. El m´ etodo tradicional de desarrollo de software (con las etapas de definici´ on de requisitos, especificaci´ on, implementaci´ on y pruebas sobre esos requisitos) no es lo suficientemente flexible para este tipo de problemas. El open-world software propone la creaci´ on de sistemas software heterog´ eneos y distribuidos, donde el entorno de ejecuci´ on, que es la red, cambia de forma continua e impredecible (por ejemplo, en t´ erminos de disponibilidad de servicios y degradaci´ on o aumento de las prestaciones de los mismos). En el open-world, el mundo es intr´ ınsecamente abierto; por lo tanto, las circunstancias (o el entorno) del software pueden cambiar en cualquier momento de manera imprevista.Pueden aparecer nuevos componentes, su comportamiento puede verse modificado y los componentes accesibles pueden dejar de estarlo; todo ello durante el tiempo de ejecuci´ on. Por ello, el software deber´ ıa reconocer esos cambios y reaccionar ante ellos de manera aut´ onoma y en tiempo de ejecuci´ on. Desde una perspectiva hist´ orica, el desarrollo del software ha ido evolucionando hacia ser cada vez m´ as cada vez m´ as modular y distribu´ ıdo. Partiendo de la programaci´ on estructurada, pasando por los lenguajes OO, y llegando hasta la programaci´ on basada en servicios open-world. 2. Conceptos previos 9 2.7. Sistemas auto-adaptativos Los sistemas software auto-adaptativos son aquellos capaces de modificar su comportamiento din´ amicamente, y por ello se necesitan t´ ecnicas y mecanismos para que puedan adaptarse a cambios en su entorno. Algunos mecanismos que soportan una cierta auto-adaptaci´ on son ya conocidos, ampliamente empleados, y proporcionados por ciertos lenguajes de programaci´ on o librer´ ıas run-time: manejo de excepciones, comprobaci´ on de guardas (runtime assertion checking), etc. Estos m´ etodos son adecuados para reconocer y evitar errores, pero no reconocen anomal´ ıas m´ as sutiles como la degradaci´ on gradual de las prestaciones o la p´ erdida de fiabilidad. Con el objetivo de lograr mecanismos m´ as sensibles y sutiles, en [9] se propone “adaptar” el sistema de manera externa, seg´ un se muestra en la figura 2.5. El sistema es monitorizado por un componente externo que determina si la ejecuci´ on cumple unos par´ ametros aceptables, y en caso de que no lo haga, es el responsable de reparar el sistema. Modelo del Sistema Análisis y reparación Sistema en ejecución Monitorización Adaptación Figura 2.5: Esquema de adaptaci´ on externa para sistemas autoadaptativos Algunas ventajas de esta aproximaci´ on son: su reusabilidad, debido a su independencia del sistema; que diferentes modelos pueden ser empleados dependiendo qu´ e se quiere comprobar; y que pueden ser mantenidos con independencia del sistema. 2.8. Arquitectura de tres capas para sistemas auto-adaptativos Kramer y Magee proponen en [5,15] una arquitectura de referencia basada en tres capas para sistemas auto-adapatativos, capaz de detectar cambios din´ amicos que se produzcan durante la ejecuci´ on del sistema y autoconfigurarse para continuar satisfaciendo su especificaci´ on. Esta arquitectura est´ a inspirada en otras arquitecturas desarrolladas en el campo de la rob´ otica, en particular la descrita por Gat [16]. Kramer y Magee reconocieron que tanto los sistemas de rob´ otica como los sistemas software auto-adaptativos eran cierto tipo de sistemas aut´ onomos. Bajo esa idea, adaptaron una arquitectura de tres capas empleada tradicionalmente en rob´ otica al ´ ambito de los sitemas auto-adaptativos. En su propuesta no definen una implementaci´ on concreta, sino que proponen una arquitectura de referencia (esquematizada en la figura 2.6) que intenta satisfacer las necesidades de los sistemas auto-adapatativos y que puede ser adaptada a diferentes problemas. A continuaci´ on se describen las tres capas de la arquitectura. Capa de Control de Componentes Esta capa realiza un control directo sobre los componentes del sistema. Monitoriza su comportamiento, e informa de la situaci´ on actual a la capa inmediatamente superior (Capa de Gesti´ on del Cambio). 10 2. Conceptos previos Figura 2.6: Esquema de la arquitectura de tres capas propuesta por Kramer y Merge Capa de Gesti´ on del Cambio La capa intermedia tiene una conjunto de planes o estrategias para conseguir el objetivo de la aplicaci´ on. En base a la informaci´ on sobre la situaci´ on actual que obtiene de la capa inferior (Capa de Gesti´ on de Componentes), esta capa comprueba sus estrategias, y si es necesario realiza modificaciones para obtener una nueva configuraci´ on. Esto puede implicar introducir nuevos componentes o cambiar las interconexiones entre ellos. Cuando la situaci´ on actual no es soportada por ninguna de las estrategias que tiene esta capa, solicita una nueva estrategia a la capa superior (Capa de Control de Objetivos). Capa de Control de Objetivos Esta capa controla la consecuci´ on de los objetivos del sistema. Su tarea es crear nuevas estrategias para conseguir los objetivos del sistema teniendo en cuenta la situaci´ on actual del mismo. Esta capa recibe de la capa inferior (Capa de Gesti´ on del Cambio) tanto la petici´ on para realizar una estrategia como la informaci´ on que necesita acerca de la situaci´ on actual. Cap´ ıtulo 3 Planteamiento del problema En este este cap´ ıtulo se presenta la arquitectura propuesta e implementada en este PFC, basada en [1], para la desarrollo de un sistema autoadaptativo en base a medidas de prestaciones en un entorno open-world. En esta propuesta, se adapta la arquitectura de tres capas de Kramer y Magee (ver 2.8) al contexto del open-world software, en concreto a la evaluaci´ on de prestaciones. La arquitectura tendr´ a las mismas tres capas que la propuesta referida: Control de Componentes, Gesti´ on del Cambio y Gesti´ on de Objetivos. A continuaci´ on se definen las tareas y responsabilidades para cada etapa, adaptada a este supuesto de open-world software en base a prestaciones. El esquema obtenido se presenta en la figura 3.1. Objetivos de Prestaciones Reconfiguración Estrategias de Generador de Workflow del sistema con espeficicaciones temporales Componentes Diagrama de Configuración ejecución Sistema en Monitor Configuración Nueva Estado actual Gestión de objetivos Gestión del Cambio Componentes Gestión de Estrategia de Reconfiguración la Configuración Controlador de Nueva Estrategia Petición de nueva estrategia Figura 3.1: Arquitectura de tres capas aplicada al paradigma open-world 3.1. Capa de Control de Componentes La capa de Control de Componentes es la de m´ as bajo nivel, en contacto con el sistema y el entorno de ejecuci´ on. Por lo tanto, debe reaccionar con rapidez a los cambios que se puedan producir para adaptar el sistema de manera ´ agil. En nuestro contexto, esta capa es la responsable de gestionar los bindings yunbindings entre los diferentes componentes que propocionan ciertos servicios dentro del entorno de ejecuci´ on. Se identifican diferentes tareas que se deber´ an llevar a cabo en esta capa: Medir en cada momento las prestaciones de cada componente de la configuraci´ on actual. 11 12 3. Planteamiento del problema Descubrir nuevos componentes que proporcionen los servicios requeridos por el sistema. Comprobar si los componentes involucrados en la configuraci´ on actual siguen disponibles. Se propone situar en esta capa un monitor (ver figura 3.1) que deber´ a llevar a cabo estas tres tareas. Para ello, necesitar´ a conocer el workflow a ejecutar por el sistema, as´ ı como la configuraci´ on actual. Una configuraci´ on indica a qu´ e proveedor requerir cada uno de los servicios solicitados en el workflow del sistema. Entendiendo por workflow la descripci´ on de los pasos de ejecuci´ on a realizar por el sistema y ser´ a representado como un diagrama de Actividades conforme con el est´ andar UML [10]. Para realizar la primera de las tareas (medida de prestaciones de la configuraci´ on actual), el monitor medir´ a el tiempo transcurrido entre las llamadas a cada componente; mientras que para realizar las otras dos las tareas (descubrir nuevos componentes o detectar su falta de disponibilidad), puede emplear m´ etodos ya conocidos y empleados en aplicaciones open-world (por ejemplo en el caso de los servicios web, la utilizaci´ on del registro universal de descripci´ on, descubrimiento e integraci´ on UDDI [17]). Esta capa informar´ a a la capa superior del estado actual del sistema cada vez que sea realizada una llamada a un componente, as´ ı como informar´ a cuando un componente deje de estar disponible o cuando nuevos componentes sean encontrados. 3.2. Capa de Gesti´ on del Cambio La funci´ on de la capa de Gesti´ on del Cambio es reaccionar frente a cambios que se detecten en la capa de Control de Componentes. Una caracter´ ıstica clave de esta capa es que la reacci´ on frente a los cambios debe realizarse en un tiempo despreciable. Esta capa deber´ a reaccionar de acuerdo con un conjunto de estrategias de reconfiguraci´ on en las que se indica c´ omo reaccionar a cada cambio. Estas estrategias no son creadas, sino consultadas, por lo que el tiempo de respuesta es mucho menor al de la creaci´ on de la estrategia. Cada estrategia de autoconfiguraci´ on puede estar referida a un diferente criterio de inter´ es: coste del servicio, prestaciones, etc. Adem´ as, esta capa debe detectar, si se da el caso, que el conjunto de estrategias de las que dispone dejen de ser adecuadas (porque se han producido cambios que las estrategias actuales no soportan, por ejemplo ya no se cumple el objetivo de prestaciones o los componentes seleccionados dejan de estar disponibles), en cuyo caso solicitar´ a la creaci´ on de nuevas estrategias a la capa superior. Aunque ser´ ıa deseable disponer de varias estrategias de reconfiguraci´ on en base a diferentes criterios, simplificamos el problema refiri´ endonos s´ olo a la medida de prestaciones. Proponemos un Controlador de la Configuraci´ on (ver figura 3.1) que realice las tareas nombradas para esta capa. Dicho Controlador de la Configuraci´ on necesitar´ a la estrategia de reconfiguraci´ on a emplear obtenida de la capa superior, as´ ı como el estado actual obtenido de la capa inferior, y un diagrama de Componentes en el que est´ e descrito el comportamiento de cada componente. 3.3. Capa de Gesti´ on de Objetivos Por ´ ultimo, la misi´ on de la capa de Gesti´ on de Objetivos es que el sistema cumpla ciertas restricciones globales de prestaciones. Este objetivo ser´ a logrado a trav´ es de la creaci´ on de estrategias de reconfiguraci´ on. Para ello, se propone un Generador de Estrategias, (ver fig. 3.1) que cree una nueva estrategia de reconfiguraci´ on cada vez que la capa de Gesti´ on del Cambio la solicite. Para crear dicha estrategia, el Generador necesitar´ a conocer el objetivo de prestaciones del sistema; el workflow de ejecuci´ on junto 3. Planteamiento del problema 13 a la especificaci´ on de ciertas propiedades de prestaciones; y la configuraci´ on actual de los componentes, proporcionada por la capa de Gesti´ on del Cambio. La estrategia de reconfiguraci´ on obtenida para conseguir el objetivo de prestaciones, ser´ a comunicada a la capa inferior para reemplazar a la estrategia anterior. Se considera que la implementaci´ on de la capa de Gesti´ on de Objetivos es la m´ as desafiante ya que es para la que menos mecanismos existen actualmente y sobre la que menos se ha investigado hasta ahora. Por ello, enfocamos nuestra atenci´ on en su definici´ on e implementaci´ on. El cap´ ıtulo 4 detalla la implementaci´ on del Generador de Estrategias, objeto de este PFC. 20 4. Implementaci´ on del Generador de Estrategias Algorithm 2 Creaci´ on de un nodo Require: nodo predecesor (N0), servicio que es modificado (k){y la informaci´ on de AD,CD,TT} Ensure: Nodo (mejorConf) 1: posiblesConf ←obtenerPosiblesConfiguraciones(N0,k) 2: tiempoRespMin ← ∞ 3: for all conf ∈posiblesConf do 4: rdp ←crearRdP(AD, conf) 5: tiempoResp ←evaluarRdP(rdp) 6: if tiempoResp < tiempoRespMin then 7: tiempoRespMin ←tiempoResp 8: mejorConf ←conf 9: end if 10: end for 11: return mejorConf la mejor de sus fases de trabajo. Tras la evaluaci´ on, se selecciona como configuraci´ on del nodo inicial aquella que proporciona un mejor tiempo de respuesta para el sistema. Cuando la creaci´ on de un nodo Ntse realiza a partir de otro nodo N0y un cierto servicio k, se realiza la evaluaci´ on de todas las posibles configuraciones, partiendo de la configuraci´ on del nodo N0, y variando o bien el componente que proporciona el servicio k, o bien la fase del componente que proporcionaba el servicio ken N0. Como resultado, se selecciona como configuraci´ on del nuevo nodo aquella que mejor tiempo de respuesta proporcione. El proceso de evaluaci´ on de los workflows se realiza a trav´ es de su traducci´ on a redes de Petri y la evaluaci´ on de estas a trav´ es de la herramienta GreatSPN. La evaluaci´ on de los workflows se explica con mayor detalle en la secci´ on 4.4. El algoritmo de creaci´ on de un arco, algoritmo 3, recibe como par´ ametros de entrada los nodos origen (No) y destino (Nd) y el servicio (k) que es modificado entre uno y otro. Con esta informaci´ on, el algoritmo calcula el nivel de confianza. N´ otese que debido a la caracter´ ıstica open-world del sistema, las decisiones de paso de un nodo a otro (la capa de Gesti´ on del Cambio decide los cambios de nodo al interpretar la estrategia) son tomadas en base a predicciones sobre el comportamiento de los componentes que proveen los servicios. Estas predicciones pueden ser acertadas o err´ oneas. Cuando se produce una predicci´ on err´ onea se denomina “falso positivo”. El c´ alculo del nivel de confianza para pasar de un nodo a otro se calcula relacionando la ganancia de prestaciones ante una predicci´ on acertada y la p´ erdida de prestaciones ante un falso positivo. Este nivel de confianza se calcula a partir de dos valores: la mejora de prestaciones al realizar una reconfiguraci´ on debido a una predicci´ on correcta (l´ ıneas 6-11 del algoritmo 3), la mejora entre la configuraci´ on de Nocon las prestaciones degradadas y Nd;ylap´ erdida de prestaciones al realizar una reconfiguraci´ on por una falso positivo, la p´ erdida por emplear la configuraci´ on de Nten lugar de la de No, que sigue con su comportamiento sin degradar (l´ ınea 11 del algoritmo 3): nivelConf =mejoraP rest mejoraP rest +perdidaP rest La obtenci´ on del nodo empeorado Nemp (l´ ınea 6 del algoritmo) de N0respecto a kse realiza tomando los mismos componentes proveedores que N0, de los cuales todos mantienen sus fases de trabajo excepto aqu´ el que provee el servicio k, que pasa a su siguiente fase. Cuando los nodos origen y destino de un arco tienen los mismos componentes activos (pero con uno de ellos en una fase diferente), el nivel de confianza se calcula relacionando los tiempos de 4. Implementaci´ on del Generador de Estrategias 21 Algorithm 3 Creaci´ on de un arco Require: nodo origen (No), nodo destino (Nd), servicio que es modificado (k){y la informaci´ on de CD,TT} Ensure: Arco de NoaNd {Calcular tiempo de respuesta nodeo} 1: rdpo←crearRdP(workflow,nodeo) 2: tiempoRespo←evaluarRdP(rdpo) {Calcular tiempo de respuesta noded} 3: rdpd←crearRdP(workflow,noded) 4: tiempoRespd←evaluarRdP(rdpd) 5: if componentesActivos(No)6=componentesActivos(Nd)then 6: nodeemp ←obtenerNodoEmp(nodeemp,k) {Calcular tiempo de respuesta nodeocon condiciones empeoradas (nodeemp) para k} 7: rdpemp ←crearRdP(workflow,nodeemp) 8: tiempoRespemp ←evaluarRdP(rdpemp) 9: mejoraP rest =tiempoRespemp −tiempoRespd 10: perdidaP rest =tiempoRespd−tiempoRespo 11: nivelConf =mejoraP rest mejoraP rest+perdidaP rest 12: else 13: nivelConf =tiempoRespo tiempoRespd 14: end if 15: return hk, nivelConfi respuesta del nodo origen y el nodo destino (l´ ınea 13 del algoritmo 3): nivelConf =tiempoRespo tiempoRespd 4.4. Evaluaci´ on de los workflow El Generador de Estrategias requiere la evaluaci´ on del workflow (representado por un diagrama de Actividad) para diferentes configuraciones del sistema. Esta evaluaci´ on se realiza a trav´ es de una red de Petri que es traducci´ on del diagrama de Actividad que lo representa. El comportamiento temporal de esta red de Petri se evalua mediante la herramienta GreatSPN [7]. 4.4.1. Traducci´ on de los flujos de ejecuci´ on a redes de Petri La traducci´ on de diagramas de Actividad a redes de Petri fue propuesta de manera te´ orica en [18,19] y ha sido implementada en algunos PFCs [20,21,22] desarrollados con anterioridad. Se trata de un potente mecanismo de traducci´ on que convierte del metamodelo de diagramas de Actividad de UML al metamodelo de las redes de Petri. Por ello, cualquier diagrama conforme con el metamodelo podr´ a ser traducido a su correspondiente red de Petri. El m´ etodo empleado ha consistido en la traducci´ on de cada elemento del diagrama de Actividad con anotaciones en MARTE en una red de Petri estoc´ astica, generalizada y etiquetada (LGSPN) equivalente. Los elementos (lugares o transiciones) iniciales y finales de cada LGSPN parcial son etiquetados con el nombre del elemento que ha sido traducido. Una vez traducidos todos los elementos, y partiendo de su etiquetado, se realiza la composici´ on de todas las LGSPN parciales en una sola. . Los elementos del diagrama de Actividad y las anotaciones del perfil MARTE traducidos a LGSPN se nombran a continuaci´ on. La traducci´ on concreta de cada elemento se presenta en el Ap´ endice E. 22 4. Implementaci´ on del Generador de Estrategias 1. Acciones: Engloban las actividades (o acciones) y los nodos inicial y final. En la traducci´ on, los lugares y transiciones inicial y final son etiquetados con el nombre de la acci´ on. 2. Transiciones de los diagramas de Actividad: Representan la uni´ on entre dos o m´ as acciones en forma de secuencia, selecci´ on, fin de selecci´ on, bifurcaci´ on y fin de bifurcaci´ on. Para posibilitar su correcta composici´ on posterior, los lugares y transiciones son etiquetados con el nombre de las acciones predecesoras o sucesoras seg´ un corresponda. 3. Adquisici´ on y liberaci´ on de recursos: La adquisici´ on y liberaci´ on de recursos, as´ ı como el recurso en s´ ı, son obtenidos a partir de las anotaciones MARTE del diagrama de Actividad y tambi´ en son traducidas con elementos en la red de Petri resultante. t1 t1|activ1 p1|activ1 p2 p1|activ2 t2|activ1 t1 p1|activ2 p2 t2|activ2 Activ1 Activ2 (a) (b) (c) Figura 4.2: Ejemplo de traducci´ on de elementos de un diagrama de Actividades a LGSPN En la figura 4.2 se ejemplifica la traducci´ on de tres elementos de un diagrama de actividad: dos actividades y la transici´ on secuencial que las une. La composici´ on de redes de Petri se propone de manera te´ orica en [23]. La idea intuitiva bajo la composici´ on de una red rdp1con una red rdp2se explica a continuaci´ on. Partiendo de la red de Petri rdp1, para cada lugar (o transici´ on) de rdp2se comprueba si existe un lugar (o transici´ on) en rdp1 con la misma etiqueta. Si es as´ ı, ambos lugares (o transiciones) se identifican como uno solo. Si no lo es, entonces se a˜ nade dicho lugar (o transici´ on) de rdp2como un lugar (o transici´ on) nuevo. La figura 4.3 ejemplifica c´ omo se realiza la composici´ on de tres LGSPN en una sola, a partir de la composicion de dos de las redes y el resultado de estas con la tercera. 4.4.2. Evaluaci´ on de las redes de Petri Una vez obtenidas las redes de Petri a partir de los diagramas de Actividad, se eval´ ua su comportamiento temporal con ayuda de la herramienta GreatSPN. N´ otese que el tipo de redes de Petri a evaluar en este trabajo han sido redes de carga abierta. La evaluaci´ on de prestaciones de una red de Petri se puede realizar mediante dos t´ ecnicas: an´ alisis y simulaci´ on. El an´ alisis consiste en resolver la red de manera te´ orica a trav´ es del an´ alisis de su espacio de estados. Las herramientas conocidas no implementan el an´ alisis de redes de Petri de carga abierta como las que aqu´ ı se abordan. 4. Implementaci´ on del Generador de Estrategias 23 t1 t1|activ1 p1|activ1 p2 p1|activ2 t2|activ1 t1 p1|activ2 p2 t2|activ2 (a) (b) componer por activ1 t1 p1|activ1 p2 t3|activ1 p3|activ2 t1 p1|activ1 p2 t3|activ1 p3|activ2 componer por activ2 t1 p1|activ1 p2 t3|activ1 p4|activ2 t4 p5 t5|activ2 Figura 4.3: Ejemplo de composici´ on de LGSPN. Se remarcan los elementos compuestos en uno solo La simulaci´ on, por su parte, consiste en ejecutar el comportamiento de la red hasta que se satisfacen ciertos umbrales de precisi´ on y obtener los valores medios resultantes. La t´ ecnica de simulaci´ on s´ ı est´ a implementada para el estudio y an´ alisis de redes de carga abierta. En este PFC se emplea la simulaci´ on debido a que es la t´ ecnica implementada por GreatSPN para las redes de Petri de este trabajo. p1 p2 p3 p4 p5 t3 T1 t5 t4 t2 Figura 4.4: Red de Petri a evaluar La simulaci´ on de las redes de Petri obtenidas a partir del diagrama de Actividades se realiz´ o con 24 4. Implementaci´ on del Generador de Estrategias llamadas a las funciones de GreatSPN. Para ello, hubo que realizar las siguientes operaciones: ·Exportar las redes de Petri a un fichero acorde con el formato de la herramienta GreatSPN. ·Realizar la llamada a la funci´ on de simulaci´ on de GreatSPN (WNSIM) desde el programa implementado en JAVA, a trav´ es de una llamada a un comando de sistema. ·Leer el fichero resultante de la ejecuci´ on de la funci´ on de GreatSPN para obtener los resultados de la simulaci´ on. ·Calcular el tiempo de respuesta medio a partir de los datos de la simulaci´ on aplicando la Ley de Little, como se explica a continuaci´ on. Este tiempo de respuesta medio es el empleado como resultado de la “evaluaci´ on” de la red en el algoritmo Generador de Estrategias. La ley de Little [24] relaciona los valores medios de tres variables de importancia en un sistema, y se enuncia como: El n´ umero medio de usuarios en el sistema (N) es igual a la tasa media de llegada (λ) multiplicado por el tiempo promedio de un cliente en el sistema o tiempo medio de respuesta del sistema (T). N=λ∗T Empleando la ley de Little, se puede calcular el tiempo medio de servicio T. A partir del ejemplo de la figura 4.4, se define el n´ umero medio de usuarios en el sistema como el n´ umero medio de tokens en el lugar p1, ya que es el n´ umero de peticiones que han tenido que esperar en el lugar p1 para ser ejecutadas; sumado al n´ umero medio de peticiones en ejecuci´ on. Esto es 1 - (ocupaci´ on media de p5). Por ´ ultimo, la tasa media de llegada equivale al rendimiento (throughput) de la transici´ on T1. En la f´ ormula enunciada a continuaci´ on, se denota #piel n´ umero medio de tokens en el lugar Piy thrg(Tj)el throughput medio de la transici´ on Tj. T=#p1 + (1 −#p5) thrg(T1) Cap´ ıtulo 5 Planificaci´ on temporal. Este cap´ ıtulo proporciona una revisi´ on acerca de la planificaci´ on temporal del proyecto, as´ ı como el tiempo invertido en cada una de las fases de desarrollo en las que ´ este fue dividido. En el ap´ endice Cse explican los hitos de cada fase de desarrollo, as´ ı como los problemas encontrados. Figura 5.1: Diagrama de Gantt del desarrollo del proyecto El diagrama de Gantt de la figura 5.1 muestra c´ omo ha evolucionado el proyecto a lo largo del tiempo. El diagrama de la figura 5.2 distribuye de las horas empleadas en las diferentes fases de desarrollo. Figura 5.2: Distribuci´ on del esfuerzo en las fases de desarrollo 25 26 5. Planificaci´ on temporal. El proyecto ha sido realizado entre septiembre de 2009 y febrero de 2010. El trabajo ha sido constante durante este periodo, con dedicaci´ on completa. Esto hace un total de seis meses de trabajo y un total de 470 horas empleadas. Cap´ ıtulo 6 Conclusiones y trabajo futuro Este cap´ ıtulo presenta algunas conclusiones obtenidas de la elaboraci´ on de este PFC. Adem´ as, plantea el trabajo futuro. 6.1. Conclusiones y resultados obtenidos. Una vez terminado todo el proceso que me ha llevado a redactar estas l´ ıneas, desde la tarea de elegir Proyecto Fin de Carrera hasta la redacci´ on de esta misma memoria, puedo ahora obtener ciertas conclusiones, tanto t´ ecnicas como personales. Respecto al trabajo desarrollado, se ha cumplido el objetivo propuesto. Se ha obtenido como resultado la implementaci´ on de un paquete ejecutable que se encarga de generar estrategias de reconfiguraci´ on. Este paquete ejecutable est´ a listo para ser integrado en sistemas autoadaptativos que siguen la arquitectura de tres capas explicada. Con la integraci´ on de este paquete en el sistema, se conseguir´ a, dado el workflow de la aplicaci´ on software, que el sistema sea capaz de autoconfigurarse respondiendo a est´ ımulos recibidos en un entorno open-world. Este software desarrollado corresponde a la capa m´ as desafiante y todav´ ıa desconocida de la arquitectura. Por lo tanto, mediante la realizaci´ on de este paquete ejecutable se ha dado un paso adelante hacia la implementaci´ on real de estos tipos de sistemas autoadaptativos en base a sus prestaciones. Por ello, se considera que este trabajo tiene cierta relevancia en el ´ ambito de la investigaci´ on de nuevos m´ etodos y t´ ecnicas para el open-world software y sistemas autoadaptativos en tiempo de ejecuci´ on. En cuanto a lo personal, estoy satisfecha con el trabajo realizado. El tama˜ no del proyecto y el hecho de dedicarme a tiempo completo a ´ el (sin horarios ni calendarios previamente fijados) han causado que haya aprendido a organizar mi tiempo, as´ ı como a realizar una planificaci´ on inicial y revisarla peri´ odicamente. Por otra parte, he ampliado mis conocimientos sobre redes de Petri (PN, GSPN, LGSPN...) y sobre evaluaci´ on de prestaciones; as´ ı como otras tecnolog´ ıas como el procesado de ficheros XML o la aplicaci´ on de perfiles (como el est´ andar MARTE) a los diagramas UML. Finalmente, este trabajo me ha acercado al ´ ambito de la investigaci´ on cient´ ıfica, debido a que se trata de implementar algo recientemente investigado y a que he tenido que leer y comprender varios art´ ıculos. Adem´ as, he podido entender algunos desaf´ ıos que plantea y plantear´ a en los pr´ oximos a˜ nos el paradigma del open-world software, el cu´ al todav´ ıa est´ a en etapas tempranas de investigaci´ on. 6.2. Trabajo futuro En esta secci´ on se exponen algunos trabajos futuros que completar´ ıan o ampliar´ ıan el trabajo desarrollado en este PFC: 27 28 6. Conclusiones y trabajo futuro El generador de estrategias considera los principales elementos de los diagramas de Actividad (selecci´ on, bifurcaci´ on, uni´ on, etc), pero no todos. Podr´ ıa ampliarse el sistema para que tratase otros elementos como el env´ ıo y recepci´ on de se˜ nales, los cuales pueden provocar interrupciones en el flujo de ejecuci´ on. Implementar de manera m´ as precisa la creaci´ on de los arcos de retorno. En la actualidad, se emplea como tiempo de retorno el tiempo medio de llegada de nuevas cargas de trabajo. Dedic´ andole m´ as tiempo de investigaci´ on se podr´ ıa realizar un c´ alculo m´ as sofisticado que mejorase la precisi´ on de la predicci´ on para estos arcos. En el entorno open-world, los retrasos obtenidos al solicitar un servicio son la suma del retraso del servicio en s´ ı y los retrasos causados por la red de comunicaci´ on (sat´ elite, WLAN, LAN, etc). En este proyecto no se realiza distinci´ on entre cu´ al es la causa del retraso, sin embargo s´ ı podr´ ıa realizarse. Para ello podr´ ıa a˜ nadirse al sistema un diagrama de Distribuci´ on de UML y una tabla asociada en la que almacenar los retrasos causados por la red. Este es un tema que necesita todav´ ıa investigaci´ on. El objetivo ser´ ıa conseguir cierto grado de confianza al predecir si un retraso percibido por el cliente se refiere a (1) una respuesta lenta del servidor o (2) a un retraso causado por la red de comunicaci´ on entre componentes. La estrategia de reconfiguraci´ on considerada en el sistema es obtenida en base a las medidas de prestaciones de los proveedores de servicios. Sin embargo, podr´ ıan calcularse y emplearse otras estrategias de reconfiguraci´ on basadas en otros criterios, como el coste del servicio o la fiabilidad del servicio obtenido o incluso llegando a compromisos entre ellas. PNML[25] es un est´ andar para el intercambio de redes de Petri basado en XML de creciente popularidad. En este PFC los diagrama de Actividad se traducen directamente a redes de Petri. El diagrama de Actividad ser´ ıa convertido a una red de Petri representada con el est´ andar PNML, y dicha red de Petri en formato PNML ser´ ıa convertida a una red de Petri en forma- to de entrada de GreatSPN. Esto podr´ ıa mejorar la potencia de comunicaci´ on y colaboraci´ on con otros paquetes o m´ odulos. Por ejemplo en caso de (1) utilizar las RdP creadas por otros paquetes o (2) facilitar la el uso de las redes creadas por otros paquetes que las necesiten. Implementaci´ on de las capas inferiores (capa de control de componentes y capa de gesti´ on del cambio) de la arquitectura propuesta en el cap´ ıtulo 3. Estas capas completar´ ıan el sistema, de manera que no solo se crear´ ıan las estrategias de reconfiguraci´ on sino que el sistema ser´ ıa capaz de emplearlas y autoconfigurarse. Abordar esta tarea de implementaci´ on exige un trabajo previo de investigaci´ on sobre las particularidades de dichas capas. Bibliograf´ ıa [1] D. P´ erez-Palac´ ın, J. Merseguer, and S. Bernardi. Performance aware open-world software in a 3-layer architecture. In Proceedings of the 1st International Conference on Performance Engineering (ICPE’10), pages 49–56. [2] Luciano Baresi, Elisabetta Di Nitto, and Carlo Ghezzi. Toward open-world software: Issue and challenges. Computer, 39(10):36–43, 2006. [3] Object Management Group, http://www.promarte.org.A UML Profile for MARTE., 2009. [4] M. Silva. Las redes de Petri en la Autom´ atica y la Inform´ atica. AC, Madrid (Spain), 1985. [5] Jeff Kramer and Jeff Magee. Self-managed systems: an architectural challenge. In FOSE ’07: 2007 Future of Software Engineering, pages 259–268, Washington, DC, USA, 2007. IEEE Computer Society. [6] XML Metadata Interchange (XMI). http://www.omg.org/technology/documents/formal/xmi.htm. [7] La herramienta GreatSPN. http://www.di.unito.it/˜greatspn. [8] D. P´ erez-Palac´ ın and J. Merseguer. Performance evaluation of self-reconfigurable serviceoriented software with stochastic petri nets. In Proceedings of the Fourth International Workshop on Practical Applications of Stochastic Modelling (PASM’09), Electronic Notes in Theoretical Computer Science (2010). [9] David Garlan and Bradley Schmerl. Model-based adaptation for self-healing systems. In WOSS ’02: Proceedings of the first workshop on Self-healing systems, pages 27–32, New York, NY, USA, 2002. ACM. [10] G. Booch, I. Jacobson, and J. Rumbaugh. The Unified Modeling Language. Addison Wesley, 1999. [11] Object Management Group. Unified Modeling Language: Superstructure, July 2005. Version 2.0, formal/05-07-04. [12] The Extensible Markup Language (XML). http://www.w3.org/XML. [13] Java technology. http://www.sun.com/java/. [14] La herramienta de modelado Papyrus UML. http://www.papyrusuml.org/. 29 36 A. Caso pr´ actico Parseo del fichero XMI La herramienta exporta el diagrama de acuerdo con el est´ andar XMI. En el fichero XMI, el diagrama de Actividades est´ a representado como un elemento dentro del elemento que representa al sistema (el componente Sistema del diagrama de componentes). Cada elemento del diagrama de Actividades es representado en el fichero XMI como un elemento dentro del elemento diagrama de Actividad. Por ejemplo, el nodo inicial de nuestro diagrama de actividades es representado como: <node xmi:type="uml:InitialNode" xmi:id=" nOvYgOiqEd6GKesHY96ouQ" name="Nodo Inicial" outgoing=" L9Z40OirEd6GKesHY96ouQ"/> El atributo xmi:type representa el tipo de elemento UML del que se trata, xmi:id es un identificador ´ unico que el programa asigna a este elemento, name es el nombre visible y modificable por el usuario y outgoing es el identificador del siguiente elemento del diagrama, en este caso, el identificador de la transici´ on secuencial que sucede al nodo inicial. A.2.2. Obtenci´ on del diagrama de Componentes Obtenci´ on del diagrama con la herramienta Papyrus La obtenci´ on de un diagrama de Componentes en Papyrus requiere en primer lugar realizar un diagrama de clases en el que se definan los componentes, sus interfaces, y las relaciones de “uso” o “realizaci´ on” que existen entre ellos (ver figura A.4). Figura A.4: Componentes e interfaces del diagrama de Componentes En segundo lugar, se realiza el diagrama de Componentes. La herramienta muestra las interfaces ofrecidas (“realizaci´ on”) o requeridas (“uso”) de cada componente. Las interfaces usadas y sus correspondientes realizaciones son unidas gr´ aficamente en el diagrama de actividad a trav´ es de una uni´ on de “dependencia”. El diagrama de componentes del sistema propuesto como ejemplo es el mostrado en la figura A.5 Procesado del fichero XMI Al igual que en el caso del diagrama de Actividades, el fichero XMI es obtenido directamente a partir de la herramienta Papyrus. Es posible la obtenci´ on de ambos diagramas a partir de un ´ unico fichero XMI. El fichero relaciona los componentes, las interfaces, las realizaciones y los usos. La l´ ınea de ejemplo presentada a continuaci´ on representa el componente “Sistema”: A. Caso pr´ actico 37 Figura A.5: Diagrama de Componentes modelado en la herramienta Papyrus <packagedElement xmi:type="uml:Component" xmi:id=" iUmesMInEd6Az8L0rwC1FA" name="C0" clientDependency=" MC0CMMIoEd6Az8L0rwC1FA MPtOsMIoEd6Az8L0rwC1FA MdDHIMIoEd6Az8L0rwC1FA"/> Los atributos xmi:type,xmi:id yname tienen el mismo significado que el explicado para los diagramas de Actividades. El atributo clientDependency engloba los idenficadores de todas las relaciones de “realizaci´ on” o “uso” en los que est´ a implicado este compontente. En este caso, tres relaciones de “uso”, correspondientes a S1,S2yS3. A continuaci´ on se presenta una de las relaciones de “uso” de este componente, en la cual se puede comprobar que est´ an relacionados a trav´ es de sus identificadores: <packagedElement xmi:type="uml:Usage" xmi:id=" MC0CMMIoEd6Az8L0rwC1FA" name="FromC0toS1" supplier=" 4ZkKsMInEd6Az8L0rwC1FA" client=" iUmesMInEd6Az8L0rwC1FA"/> Obtenci´ on de la tabla de tiempos asociada a los proveedores Con el objetivo de parsear la informaci´ on temporal acerca de los componentes proveedores planteada en la tabla A.1,´ esta es escrita en un fichero XML con la estructura siguiente: <timeTable> <provider name=’C11’> <phase serviceTime=’5’ sojournTime=’3000’/> <phase serviceTime=’20’ sojournTime=’6000’/> </provider> (...) <provider name=’C31’> <phase serviceTime=’20’ sojournTime=’2000’/> <phase serviceTime=’70’ sojournTime=’2000’/> </provider> <provider name=’C32’> <phase serviceTime=’30’ sojournTime=’1000’/> </provider> 38 A. Caso pr´ actico </timeTable> El elemento ra´ ız del fichero XML, <timeTable> representa la tabla temporal en su conjun- to. Cada proveedor (provider) est´ a identificado por su nombre, y puede tener una o m´ as fases de funcionamiento. serviceTime representa el tiempo medio de respuesta del proveedor, y sojournTime representa el tiempo medio en el que el proveedor est´ a en dicha fase. Como se ha explicado, este fichero es parseado mediante DOM, y la informaci´ on proporcionada por cada de las fases es almacenada en el diagrama de Componentes junto al correspondiente componente proveedor de un servicio. A.2.3. Almacenamiento de los datos durante la implementaci´ on Una vez obtenidos los datos, son almacenados en objetos de JAVA para servir de par´ ametro de entrada para el Generador de Estrategias implementado en JAVA. El diagrama de Clases de la figura A.6 muestra el metamodelo de los diagramas de Actividades empleados en este proyecto. El diagrama de Componentes est´ a estructurado seg´ un el diagrama de Clases de la figura A.7; el cual engloba la informaci´ on obtenida del diagrama de Componentes a trav´ es del fichero XMI y la informaci´ on sobre las fases de cada componente obtenidas a partir de la tabla. El anexo Bmuestra el diagrama de clases completo del Generador de Estrategias desarrollado. Figura A.6: Diagrama de Clases de la implementaci´ on del diagrama de Actividad Figura A.7: Diagrama de Clases de la implementaci´ on del diagrama de Componentes A. Caso pr´ actico 39 A.3. Descripci´ on de la generaci´ on de estrategias El workflow de ejecuci´ on (ver figura A.1) es traducido a una red de Petri como la mostrada en la figura A.8.                                   Llegada carga de trabajo ! " # $ % & ' ( ) $ *!+ , - . / 0 1 2 3 . 4!5 6 7 8 9 : ; < = 8 >@?BA CD E E F G t_S1 AcqRes Res_C0 RelRes t_S2 t_S3 HJIJK L M NJOP Q R Llamada S1 Llamada S2 Llamada S3 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 Figura A.8: GSPN param´ etrica obtenida a partir del workflow del sistema Debido a que la estructura de la red de Petri resultante para cada configuraci´ on del sistema es la misma, y lo ´ unico que cambia es el tiempo de algunas transiciones temporales, se emplea una red de Petri param´ etrica. De esta manera, la traducci´ on del workflow a red de Petri se realiza s´ olo una vez. Cada vez que es necesario simular el sistema, se modifican los par´ ametros de dicha red de Petri param´ etrica y se realiza la simulaci´ on. En el diagrama de Actividad se indica que las operaciones S1yS3se ejecutan una vez, y que la operaci´ on S2es ejecutada tres veces en promedio (“extOpCount = 3”). La llamada a S2se traduce con un elemento. El recurso “C0” es traducido como un lugar con un token. El lugar se queda vac´ ıo cuando se dispara la transici´ on “AcqRes”, justo antes de realizar la llamada a la operaci´ on S1; y vuelve a ser ocupado por el token cuando se dispara la transici´ on de “RelRes”. El primer paso del algoritmo es la creaci´ on del nodo inicial. Para ello, se toman las mejores fases de cada proveedor (ver tabla A.1): C11:fase1, C21:fase1, C22:fase1, C31:fase1, C32:fase1. Durante la ejecuci´ on del algoritmo de creaci´ on del nodo, se crean las cuatro configuraciones posibles. Se presentan a continuaci´ on, con la representaci´ on “(proveedor utilizado:fase)” para cada uno de los tres servicios, S1,S2yS3. 40 A. Caso pr´ actico Conf1 (C11:fase1, C21:fase1, C31:fase1) Conf2 (C11:fase1, C21:fase1, C32:fase1) Conf3 (C11:fase1, C22:fase1, C31:fase1) Conf4 (C11:fase1, C22:fase1, C32:fase1) La red de Petri param´ etrica es instanciada para cada una de las cuatro posibles configuraciones del sistema. El resultado de la evaluaci´ on ha sido: Conf1 60.5 u.t. Conf2 177.7 u.t. Conf3 72.5 u.t. Conf4 193.8 u.t. El algoritmo de creaci´ on de un nodo elige aquella con mejor tiempo de respuesta calculado: (C11:fase1, C21:fase1, C31:fase1) Esta configuraci´ on consituye el nodo inicial, Nodo0en la figura A.9. En este caso, la configuraci´ on obtenida como nodo inicial est´ a compuesta por los proveedores que mejores tiempos de respuesta individuales ten´ ıan. Sin embargo, en otros sistemas es posible que el mejor tiempo de respuesta global no sea proporcionado por los mejores tiempos de respuesta locales, sino por otra configuraci´ on. Por ejemplo en sistemas donde varios proveedores pueden competir por recursos compartidos. Una vez creado el nodo inicial, se considera que cada uno de los proveedores activos en la configuraci´ on del nodo inicial degrada su tiempo de respuesta. En ese caso, crea un nuevo nodo para cada posible proveedor degradado (C11, C21 y C31): los nodos Nodo1,Nodo2yNodo3respectivamente. Nodo1es creado suponiendo que C11 degrada sus prestaciones. Para crear un nuevo nodo, se calculan las posibles configuraciones que mantienen la configuraci´ on de Nodo0, modificando el proveedor y/o la fase de S1. En este caso existe una ´ unica configuraci´ on posible: (C11:fase2, C21:fase1, C31:fase1) Esta es la configuraci´ on elegida para Nodo1, ya que es la ´ unica posible. El arco entre Nodo0yNodo1se etiqueta con el servicio S1, ya que es aqu´ el cuyo comportamiento se ve modificado. Para calcular el nivel de confianza, se emplea tiene en cuenta que los componentes activos son los mismos en Nodo0yNodo1, y se calcula como el tiempo de respuesta de Nodo0 dividido por el de Nodo1: nivelConfianza =tiempoRespo tiempoRespd Cabe observar que ning´ un arco sale de Nodo1con la etiqueta del servicio S1, debido a que todos los proveedores de S1(C11) han pasado por todas las fases posibles (C11:fase1 y C11:fase2). En la creaci´ on de Nodo2, se calculan todas las configuraciones posibles: (C11:fase1, C21:fase2, C31:fase1) (C11:fase1, C21:fase2, C32:fase1) (C11:fase1, C22:fase1, C31:fase1) (C11:fase1, C22:fase1, C32:fase1) Las dos primeras son las posibles configuraciones manteniendo el componente C21, el cual es considerado en su fase 2 (con prestaciones degradadas). En la tercera y la cuarta posibles configuraciones el componente proveedor del servicio S2 cambia de C21 a C22, el cual se considera en su fase1. Las cuatro posibles configuraciones son evaluadas a partir de la red de Petri. La tercera de ellas obtiene el mejor tiempo de respuesta, por lo que es elegida como Nodo2. A. Caso pr´ actico 41 El arco que une Nodo1yNodo2est´ a etiquetado con el servicio modificado entre ellos: S2. El nivel de confianza se calcula relacionando dos cantidades: la mejora potencial de prestaciones, calculada como lo que se gana al emplear C22 en su fase 1 en lugar de emplear el componente C21 con las prestaciones degradadas (fase 2); y la p´ erdida potencial de prestaciones debida a una mala predicci´ on (falso positivo), esto es, se pasa a emplear C22 en su fase 1, sin embargo C21 se mantiene en su fase 1. mejoraP otencial =tiempoRespemp −tiempoRespd perdidaP otencial =tiempoRespd−tiempoRespo nivelConfianza =mejoraP otencial mejoraP otencial +perdidaP otencial El resto de nodos y arcos del diagrama son creados de manera an´ aloga. Una vez creados todos los nodos y sus correspondientes arcos, el algoritmo genera los arcos de retorno. Estos arcos permiten volver a una configuraci´ on anterior en la que los componentes funcionaban en una fase mejor. Tomando un ejemplo, la configuraci´ on de Nodo1tiene un componente (C11) que no est´ a en su mejor fase (que ser´ ıa C11:fase1), sino en su fase 2. Este componente que est´ a funcionando en una fase que no es su fase mejor, puede volver a su fase 1. Este cambio de fase de un componente que est´ e en cualquier fase (que sea distinta de su fase 1) hacia su fase 1 es representado con un arco de retorno. Los otros dos componentes de Nodo1(C21 y C31) est´ an en su fase 1, por lo que no pueden pasar a una fase mejor y Nodo1no tiene m´ as arcos de retorno. A.4. Estrategia de reconfiguraci´ on obtenida La estrategia obtenida de ejecutar el Generador de Estrategias con el ejemplo propuesto en este anexo es la presentada en la figura A.9. Por claridad, solo se muestran dos de los arcos de retorno (los arcos en l´ ınea discontinua). <s3,0.81> Nodo0 C11:fase1 C21:fase1 C31:fase1 Nodo1 C21:fase1 C31:fase1 Nodo2 C11:fase1 C22:fase1 C31:fase1 Nodo3 C11:fase1 C21:fase1 C32:fase1 <s2,0.71> <s1,0.77> Nodo4 C22:fase1 C31:fase1 Nodo5 C21:fase1 C32:fase1 Nodo6 C11:fase1 C31:fase1 Nodo7 C11:fase1 C22:fase1 C32:fase1 <s1,0.88> <s1,0.80> <s2,0.72> <s2,0.93> <s2,0.72> <s3,0.82> <s3,0.81> C11:fase2 C11:fase2 C11:fase2 C21:fase2 Nodo8 C21:fase2 C31:fase1 C11:fase2 Nodo9 C22:fase1 C32:fase1 C11:fase2 Nodo10 C22:fase2 C31:fase1 C11:fase1 Nodo11 C21:fase2 C32:fase1 C11:fase1 Nodo12 C22:fase2 C31:fase1 C11:fase2 Nodo13 C21:fase2 C32:fase1 C11:fase2 Nodo14 C22:fase2 C32:fase1 C11:fase1 <s2,0.89> <s3,0.85> <s2,0.81> <s1,0.96> <s2,0.98> <s3,0.97> <s1,0.80> <s2,0.86> <s2,0.92> <s2,0.96> <s3,0.99> <s1,0.96> <s1,0.93> <s3,0.84> <s2,0.99> <s1,0.70> <s2,0.99> Nodo15 C22:fase2 C32:fase1 C11:fase2 <s3,0.90> <s3,after(500)> <s2,after(500)> Figura A.9: Estrategia de reconfiguraci´ on obtenida 42 A. Caso pr´ actico Exportado de la estrategia al formato XML Esta estrategia de reconfiguraci´ on se exporta a un fichero XML. La estructura empleada para el fichero XML es la siguiente: <ReconfigurationStrategy> <NodeList> (...) </NodeList> <EdgeList> (...) </EdgeList> </ReconfigurationStrategy> A continuaci´ on se presenta la traducci´ on del nodo Node0. Cada nodo es traducido de la misma manera y es incluido dentro del elemento NodeList. <Node name="Node 0"> <Phase providedService="S1" providerComponent="C11" phase="phase1"> <ServiceTime>5</ServiceTime> <SojournTime>3000</SojournTime> </Phase> <Phase providedService="S2" providerComponent="C21" phase="phase1"> <ServiceTime>10</ServiceTime> <SojournTime>6000</SojournTime> </Phase> <Phase providedService="S3" providerComponent="C31" phase="phase1"> <ServiceTime>20</ServiceTime> <SojournTime>2000</SojournTime> </Phase> </Node> Tanto los nodos normales como los arcos de retorno son incluidos en el elemento EdgeList. Ejemplos de dos de ellos son mostrados a continuaci´ on. <Edge source="Node 0" target="Node 1"> <Service>S1</Service> <ConfidenceLevel>0.7576326433377804</ConfidenceLevel> </Edge> <WayBackEdge source="Node 1" target="Node 0"> <Service>S1</Service> <TimeOut>after(500.0)</TimeOut> </WayBackEdge> Ap´ endice B El paquete ejecutable desarrollado B.1. El paquete ejecutable El resultado del desarrollo del software es un paquete ejecutable que constituye el generador de estrategias. Se presenta en un fichero JAR (StratGenerator.jar) que realiza la generaci´ on de estrategias, representado en la figura B.1. Este paquete ejecutable puede integrarse en un sistema conectado a ´ el a trav´ es de la interfaz CreateNewStrategy. Para dar respuesta a una petici´ on de una nueva estrategia, el paquete necesita evaluar redes de Petri, requiere la interfaz EvaluatePN. Strategy Generator CreateNew Strategy EvaluatePN Figura B.1: Componente software desarrollado Adem´ as, el generador de estrategias puede ejecutarse de manera independiente. Para ello, recibe como par´ ametros de entrada un fichero XMI, que debe contener el diagrama de Actividad y el diagrama de Componentes, y el fichero XML que representa la tabla de tiempos; y devolviendo como resultado una estrategia de reconfiguraci´ on. Para parametrizar estos valores, el ejecutable consulta el fichero settings.xml (si existe). Dicho fichero puede contener los siguientes datos: umlDiagFilename: ruta del fichero XMI donde est´ an contenidos los diagramas UML. ttFilename: ruta del fichero XML que almacena de tabla temporal asociada a cada componente. directoryFilenamePN: indica un directorio en el que almacenar las redes de Petri generadas como resultado intermedio. strategyFilename: ruta del fichero en el que se almacenar´ a el resultado de salida (la estrategia generada) en XML. PATH WNSIM: ruta del ejecutable para la simulaci´ on de redes de Petri de la herramienta GreatSPN. WNSIM acepta, entre otros, dos par´ ametros: accuracy y conflevel. ACCURACY: Indica el accuracy level (nivel de exactitud) con el que son realizadas las llamadas al simulador WNSIM. CONFLEVEL: Indica el confidence level (nivel de confianza) con el que son realizadas las llamadas al simulador WNSIM. 43 44 B. El paquete ejecutable desarrollado Un ejemplo de fichero settings.xml es el siguiente: <settings> <umlDiagFilename>umlDiagrams/modelosICPE.uml</umlDiagFilename> <ttFilename>timeTable.xml</ttFilename> <directoryFilenamePN>./GSPNnets/</directoryFilenamePN> <strategyFilename>Strategy.xml</strategyFilename> <PATH WNSIM>/usr/local/GreatSPN/WNSIM</PATH WNSIM> <ACCURACY>5</ACCURACY> <CONFLEVEL>95</CONFLEVEL> </settings> B.2. Diagrama de clases del componente desarrollado En este anexo se muestra, en la figura B.2, el diagrama de clases del componente desarrollado. B. El paquete ejecutable desarrollado 45 Figura B.2: Diagrama de Clases del componente desarrollado 52 E. Traducci´ on de los diagramas de Actividad de redes de Petri Figura E.1: Diagrama de Actividades a traducir Figura E.2: Red de Petri obtenida de la traducci´ on del diagrama de Actividad LGSPN han sido los siguientes: 1. Acciones: engloban las acciones y los nodos inicial y final. En la traducci´ on, los lugares y transiciones inicial y final son etiquetados con el nombre de la acci´ on. Actividad: puede ser una actividad sencilla de duraci´ on determinada o una actividad en la que se realiza una petici´ on de un servicio a un cierto proveedor (anotado con MARTE), en ambos casos es traducida con transiciones temporizadas y lugares. Adem´ as, la actividad puede ser ejecutada en promedio una o m´ as veces, modelado con transiciones con probabilidad. Nodo inicial: los nodos iniciales son los encargados de gestionar la carga de trabajo que soporta el workflow (n´ umero de usuarios ejecutando o n´ umero de peticiones de ejecuci´ on por unidad de tiempo). Este proyecto se ha centrado en el n´ umero de peticiones por unidad de tiempo, lo que se entiende como carga abierta. El nodo inicial es traducido como una transici´ on que “genera” tokens con una cierta funci´ on de probabilidad. Un ejemplo de ello es la transici´ on t1de la figura 4.4. Nodo final: se traduce como una transici´ on que no genera tokens al dispararse (no est´ a seguida por ning´ un lugar). E. Traducci´ on de los diagramas de Actividad de redes de Petri 53 t2|initialNode p1 t1 (a) (c) InitialNode <<workloadEvent>> pattern=open=...(exp(X,tu)) t1 p1|activ1 p2 t2|activ2 Activ1 FinalNode p1|finalNode t1 (b) (d) t3 p2 p3 t4|activ2 Activ2 <<PaStep>> extOpDemands = prov extOpCount = n λ=1/x λ=prov <<PaStep>> extOpDemands = prov extOpCount = 1 t1|activ2 p1|activ2 t2 ω=n/(n+1)ω=1/(n+1) Figura E.3: Traducci´ on a RdP de los elementos de Acci´ on 2. Transiciones de los diagramas de Actividad: representan la uni´ on entre dos o m´ as acciones. Para posibilitar su correcta composici´ on posterior, los lugares y transiciones son etiquetados con el nombre de las acciones predecesoras o sucesoras seg´ un corresponda. Secuencia: representa la uni´ on secuencial de dos acciones. Se traduce como una transici´ on y un lugar que unen de manera directa dichas acciones. Selecci´ on: representa la selecci´ on de uno de los flujos de ejecuci´ on sucesores a la selecci´ on. Se traduce con un lugar y varias transiciones con probabilidad, una por cada acci´ on sucesora. De esta manera, cuando un token llegue a dicho lugar, s´ olo una de las transiciones se disparar´ a y s´ olo uno de los flujos de ejecuci´ on ser´ an ejecutados. Fin de selecci´ on: es la transici´ on en la que convergen varios flujos de ejecuci´ on diferentes generados por una o varias transiciones de selecci´ on. Se traduce con varias transiciones, una por cada flujo de ejecuci´ on predecesor, que convergen en un ´ unico lugar, de manera que independientemente de desde qu´ e flujo de ejecuci´ on llegue el token, este ´ unico lugar obtendr´ a un ´ unico token. Bifurcaci´ on: representa el inicio de la ejecuci´ on concurrente de varios flujos de ejecuci´ on. Se traduce con una transici´ on y varios lugares, de manera que cuando la transici´ on se dispara, se producen varios tokens, uno por cada flujo de ejecuci´ on. Fin de bifurcaci´ on: es la transici´ on en la que convergen varios flujos de ejecuci´ on concurrentes generados por una o varias bifurcaciones. Se traduce con varias transiciones que desembocan en varios lugares y una ´ unica transici´ on, seguida por un ´ unico lugar, de manera que s´ olo cuando todos los lugares tengan alg´ un token la transici´ on ser´ a disparada. Los lugares contienen un token por cada flujo de ejecuci´ on que hab´ ıa antes del fin de bifurcaci´ on, y tras ´ el la transici´ on dispara un ´ unico token, permitiendo un ´ unico flujo de ejecuci´ on. 54 E. Traducci´ on de los diagramas de Actividad de redes de Petri (a) (c) (b) (d) t1|Activ1 p1|Activ2 Sequence Activ1 Activ2 Activ1 Activ2...ActivN t1|Activ1 p1|Activ2|...|ActivN Selection Fork Activ1 Activ2 ActivN ... t1|Activ1 p1|Activ2 pN-1|ActivN (e) Activ1 Activ2...ActivN Activ1 Activ2 ActivN ... p1|Activ2 t1|Activ2 pN-1|ActivN tN-1|ActivN tN pN|Activ1 End Selection End Fork t1|Activ2 tN|ActivN p1|Activ1 ... ... ... Figura E.4: Traducci´ on a RdP de los elementos de Transici´ on 3. Adquisici´ on y liberaci´ on de recursos: la adquisici´ on y liberaci´ on de recursos, as´ ı como el recurso en s´ ı, son obtenidos a partir de las anotaciones MARTE del diagrama de Actividad y tambi´ en son traducidas con elementos en la red de Petri resultante. p1|Res1 t1|Res1_acq Res1 Acquisition t2|Res1_acqt1|Res1_rel p1|Res1 Resource Res1 Res1 Release p1|Res1 t1|Res1_rel Figura E.5: Traducci´ on a RdP del elemento Recurso Recurso: un recurso puede representar el sistema en s´ ı o un recurso externo que el sistema deba emplear. En la red de Petri resultante de un diagrama de Actividad, un recurso se representa como un lugar con un token. Un ejemplo de representaci´ on de un recurso es el E. Traducci´ on de los diagramas de Actividad de redes de Petri 55 lugar p5de la figura 4.4. Adquisici´ on de recurso: la adquisici´ on de un recurso, denotada como una anotaci´ on MARTE anexa a una actividad, representa que una actividad adquiere un cierto recurso antes de comenzar a ejecutarse. Se traduce como un lugar y una transici´ on unidos por un arco. Al componer las distintas redes parciales, el lugar ser´ a compuesto con el recurso en s´ ı y la transici´ on que ser´ a compuesta con el comienzo de la actividad asociada a la adquisici´ on del recurso. Liberaci´ on de recurso: la liberaci´ on de un recurso, por su parte, representa la liberaci´ on de dicho recurso al finalizar una cierta actividad. Se traduce de manera equivalente a la adquisici´ on de recurso. Se traduce como una transici´ on y un lugar unidos por un arco desde la transici´ on hasta el lugar. Al componer las distintas redes parciales, la transici´ on ser´ a compuesta con el final de la actividad asociada a la adquisici´ on del recurso y el lugar ser´ a compuesto con el recurso en s´ ı. Ap´ endice F Empleo de la herramienta GreatSPN Como se ha explicado, la evaluaci´ on de las redes de Petri se realiza mediante la simulaci´ on de las redes de Petri. Para ello se ha empleado la herramienta GreatSPN mediante la invocaci´ on de una de sus funciones: “WNSIM”. F.1. Formato de los ficheros de GreatSPN WNSIM necesita la red en el formato de GreatSPN, por lo que ´ esta es transformada a dicho formato. GreatSPN requiere dos ficheros para la definici´ on de una red de Petri: nombreRdP.net ynombreRdP.def. La conversi´ on de las redes de Petri a este formato es realizada mediante el empleo de una API desarrollada en el PFC de L.Arrac´ o [26] para dicho objetivo. p1 p2 p3 P5 P4 t3 t1 t5 t4 t2 Figura F.1: Red de Petri correspondiente a simpleGSPN.def y simpleGSPN.net Para ilustrar el formato de los ficheros, A continuaci´ on se presenta un ejemplo de los ficheros simpleGSPN.def ysimpleGSPN.net, correspondiente a la red de Petri de la figura F.1, en los que se puede apreciar el particular formato de dichos ficheros. simpleGSPN.def |256 % | Este fichero puede definir ciertas variables, como datos relacionados con la creaci´ on de redes de Petri coloreadas, las cuales no son relevantes en nuestro trabajo. 57 58 F. Empleo de la herramienta GreatSPN simpleGSPN.net |0| | f0505100 p1 0 1.800000 0.916667 1.983333 0.900000 0 p2 0 1.800000 2.016667 1.966667 2.050000 0 p3 0 1.800000 3.050000 2.000000 3.100000 0 p5 3 2.616667 2.483333 2.816667 2.450000 0 p4 0 1.800000 3.966667 1.966667 4.000000 0 G1 1.816667 1.500000 1 t3 1.500000e+01 1 0 1 0 1.800000 2.483333 1.950000 2.558332 1.966666 2.566666 0 1200 1 1300 0 t1 2.000000e-03 0 0 0 0 1.800000 0.391667 2.000000 0.383333 1.966667 0.475001 0 1 1100 0 t5 1.000000e+00 1 1 1 0 1.800000 4.516667 1.966667 4.550000 1.966667 4.600000 0 1500 0 0 t4 1.000000e+00 1 1 1 0 1.800000 3.533333 1.966667 3.524999 1.966667 3.616667 0 1300 2 1400 1500 0 t2 1.000000e+00 1 1 2 0 1.800000 1.483333 1.983333 1.516667 1.966666 1.566666 0 1400 1100 1 1200 0 Las dos primeras l´ ıneas, en las que aparece |0| y|, son obligatorias para todos los ficheros .net de GreatSPN, pudiendo contener comentarios la segunda de las l´ ıneas. La l´ ınea que comienza por fintroduce la definici´ on de los lugares en las cinco siguientes l´ ıneas. La definici´ on de un lugar (por ejemplo p5) indica el n´ umero de tokens del lugar (3 en p5), las coordinadas del lugar ((2.616667,2.483333) en p5) y las coordenadas de su etiqueta ((2.816667,2.450000) en p5). La l´ ınea que comienza por Gintroduce la definici´ on de las transiciones. La definici´ on de una transici´ on almacena si esta es inmediata o temporizada, as´ ı como almacena si est´ a parametrizada (y en ese caso almacenar´ ıa el par´ ametro asociado). De manera an´ aloga a los lugares, almacena las coordenadas de su posici´ on, de la posici´ on de su etiqueta y de la posici´ on de su throughput. F. Empleo de la herramienta GreatSPN 59 F.2. Invocaci´ on del simulador La invocaci´ on al simulador WNSIM se realiza con dos par´ ametros: la precisi´ on o accuracy (con el par´ ametro -a) y el nivel de confianza o confidence level (par´ ametro -c): WNSIM nombreRdP -a 5 -c 95 Con dicha invocaci´ on, el ejecutable simula la red con valores aleatorios hasta que las soluciones convergen con una precisi´ on del 5 % en la estimaci´ on de cada valor, con un nivel de confianza del 95 %. El resultado de la simulaci´ on (WNSIM simpleGSPN -a 5 -c 95) se obtiene en un fichero con el siguiente formato (simpleGSPN.simres): ****** Simulation ******* MEAN NUMBER OF EVENTS : 1.907089 MAX NUMBER OF EVENTS : 4 MIN NUMBER OF EVENTS : 1 ********************************** Results : Throughput of t3 (291.000000 ): 0.00199854914967 <= X <= 0.00200314835031 Value 0.00200084592788 Mean Value 0.00200084874999 Accuracy 0.114931241885 Throughput of t1 (291.000000 ): 0.00199847725768 <= X <= 0.0020030707145 Value 0.0020007711662 Mean Value 0.00200077398609 Accuracy 0.114791996831 Throughput of t5 (291.000000 ): 0.00199849923187 <= X <= 0.00200309921617 Value 0.00200079639826 Mean Value 0.00200079922402 Accuracy 0.114953670612 Throughput of t4 (291.000000 ): 0.00199855546029 <= X <= 0.00200315699845 Value 0.00200085340404 Mean Value 0.00200085622937 Accuracy 0.114989225369 Throughput of t2 (290.000000 ): 0.00199846879527 <= X <= 0.00200306609077 Value 0.00200076462455 Mean Value 0.00200076744302 Accuracy 0.114888302292 Mean n.of tokens in p1 : 0.000351026857691 <= mu <= 0.000387976220463 Value 0.000369499837469 Mean Value 0.000369501539077 Accuracy 4.99989294558 Mean n.of tokens in p2 : 0.1532063827 <= mu <= 0.153817455764 Value 0.153511650283 Mean Value 0.153511919232 Accuracy 0.199031146003 Mean n.of tokens in p3 : 0 <= mu <= 0 Value 0 Mean Value 0 Accuracy 0 Mean n.of tokens in P5 : 2.84618254424 <= mu <= 2.8467936173 Value 2.84648834972 Mean Value 2.84648808077 Accuracy 0.0107338067153 Mean n.of tokens in P4 : 0 <= mu <= 0 Value 0 Mean Value 0 Accuracy 0 Efficiency --->83759 transition firings per second Time required for 17840841 events ------->213 Simulated time -------->1784124804.492880 Numero di campioni usati -------->7143 Grado di approssimazione -------->5 Livello di confidenza -------->4 ********************************** A partir de la lectura de este fichero simpleGSPN.simres, se puede obtener el throughput de cada transici´ on (t1,t2, etc) o el n´ umero medio de tokens en cada lugar (p1,p2, etc). Partiendo de dicha informaci´ on, se puede evaluar la red de Petri seg´ un lo explicado en la memoria principal de este trabajo (secci´ on 4.4.2). A modo de ejemplo, en el fichero mostrado, el troughput de la transici´ on t1 es 0.00200077398609 y el n´ umero medio de tokens en el lugar p1 es 0.000369501539077. Ap´ endice G Glosario y abreviaturas empleadas Este glosario define algunos de los conceptos empleados en la memoria principal, as´ ı como las abreviaturas empleadas. bind/unbind En el contexto de la Ingenier´ ıa del Software Basada en Componentes, el t´ ermino bind denota la uni´ on entre dos componentes y el t´ ermino unbind denota su separaci´ on. CASE Computer Aided Software Engineering. Las herramientas CASE son herramientas de apoyo al desarrollo del software. Algunas de sus funcionalidades pueden ser el modelado de sistemas con diagramas UML, el calculo de costes, implementaci´ on de parte del c´ odigo autom´ aticamente con el dise˜ no dado, compilaci´ on autom´ atica o documentaci´ on entre otras. DOM Document Object Model [27]. Es una interface independiente del lenguaje o de la plataforma que permite a los programas (o scripts) acceder y modificar el contenido de ficheros XML. Se emplea para generar documentos HTML din´ amicos y para procesar ficheros XML desde un programa JAVA, entre otros. Representa la informaci´ on del fichero XML como una estructura de ´ arbol, que es cargado completamente en memoria. Es adecuado para realizar consultas aleatorias y b´ usquedas sobre un fichero XML. MARTE Modeling and Analysis of Real-Time and Embedded systems [3]. Es un perfil de UML 2 para el modelado y an´ alisis de sistemas embebidos y de tiempo real, incluidos los aspectos software yhardware. Proporciona soporte para las etapas de especificaci´ on, dise˜ no y verificaci´ on del software. Metalenguaje Lenguaje que describe un lenguaje. Metamodelo Modelo que representa un modelo. OMG Object Management Group [28]. Es un consorcio a nivel internacional que integra a los principales representantes de la tecnolog´ ıa de informaci´ on Orientada a Objetos. El OMG tiene como objetivo central la promoci´ on y el impulso de la industria Orientada a Objetos, proponiendo y adaptando especificaciones que se convierten en est´ andar ISO por defecto. OO Orientaci´ on a Objetos. Paradigma para el desarrollo de sistemas de software que representa el dominio de aplicaci´ on bas´ andose en los objetos que se implican en dicho dominio. Emplea diversos m´ etodos para representar de forma abstracta los objetos, definiendo su estructura, comportamiento, agrupaciones, estados, etc. Open-world software [2] Es un paradigma de desarrollo de aplicaciones software que propone la creaci´ on de sistemas software heterog´ eneos y distribuidos, donde el entorno de ejecuci´ on cambia de forma continua e impredecible (por ejemplo, en t´ erminos de disponibilidad de servicios y degradaci´ on o aumento de las prestaciones de los mismos). 61