Usando Cumbia como plataforma de implementación de una versión extensible y adaptable de YAWL

Texto completo

(1)UNIVERSIDAD DE LOS ANDES DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION. USANDO CUMBIA COMO PLATAFORMA DE IMPLEMETACION DE UNA VERSION EXTENSIBLE Y ADAPTABLE DE YAWL. TRABAJO DE TESIS PRESENTADO COMO REQUISITO PARA OBTENER EL TITULO DE MAESTRIA EN INGENIERIA DE SISTEMAS. AUTORA: DIANA MARCELA PUENTES CORREDOR.

(2) BOGOTA, COLOMBIA. JUNIO DE 2010. INDICE 1.. INTRODUCCIÓN ................................................................................................................................ 4 1.1. ANTECEDENTES ....................................................................................................................... 4. 1.2. DEFINICION DEL PROBLEMA ................................................................................................ 5. 1.3. BACKGROUND TECNOLOGICO. ............................................................................................ 6. 1.3.1 PROBLEMAS PARA EXTENSIBILIDAD Y ADAPTABILIDAD EN MOTORES DE WORKFLOW ........................................................................................................................................... 6. 2.. 1.3.2. CUMBIA............................................................................................................................... 7. 1.3.3. YAWL................................................................................................................................... 7. ESTADO DEL ARTE........................................................................................................................... 8 2.1. CUMBIA....................................................................................................................................... 8. 2.2. YAWL......................................................................................................................................... 11. 2.3 EXTENSIBILIDAD Y ADAPTABILIDAD EN MOTORES DE WORKFLOW .............. ¡Error! Marcador no definido. 3.. OBJETIVO GENERAL Y ESPECIFICOS ........................................................................................ 19. 4.. YOC .................................................................................................................................................... 20 4.1. INTRODUCCION A YOC ......................................................................................................... 20. 4.2. ARQUITECTURA ..................................................................................................................... 20. 4.3. DIMENSION DE CONTROL .................................................................................................... 21. 4.4. DIMENSION DE RECURSOS .................................................................................................. 35. 4.5. DIMENSION DE TIEMPO ........................................................................................................ 36. 4.6. PRUEBAS................................................................................................................................... 37. 4.6.1 5.. ESCENARIOS Y RESULTADOS ..................................................................................... 38. EXTENSIONES A YOC .................................................................................................................... 48 5.1. ESCENARIO 1. AGREGANDO UN NUEVO ELEMENTO A YAWL ................................... 48.

(3) 5.2. ESCENARIO 2. CAMBIANDO LA DIMENSION DE TIEMPO DE YAWL POR XTM ....... 51. 5.3. ESCENARIO 3. AGREGANDO UNA DIMENSION DE LOG A YAWL ............................... 52. 6.. CONCLUSIONES .............................................................................................................................. 54. 7.. BIBLIOGRAFIA ................................................................................................................................ 55.

(4) USANDO CUMBIA COMO PLATAFORMA DE IMPLEMETACION DE UNA VERSION EXTENSIBLE Y ADAPTABLE DE YAWL. 1. INTRODUCCIÓN 1.1. ANTECEDENTES. En la actualidad las organizaciones buscan tener un cambio positivo en términos económicos del aprovechamiento de sus recursos (Datos, recursos humanos, infraestructura) pretendiendo una mejora continua de sus procesos, lo que implica tener que hacer un mantenimiento constante a sus procesos en pro de mantener su ventaja competitiva o de acortar la brecha con la competencia. Como respuesta a esta situación se hace necesario hacer una mejor gestión tecnológica a nivel de procesos lo cual en ocasiones implica una reingeniería en los procesos de la organización haciéndolos acorde a unas buenas prácticas que impone el mercado, el sector y la competencia. La ventaja competitiva exige un constante monitoreo a sus actividades, buscando siempre las mejores prácticas para el desarrollo de tareas, actividades e incluso sus procesos de negocio. Cuando se habla del modelado de un problema aplicable a flujos de Trabajo, no solo se tiene en cuenta la perspectiva de control para su descripción. En general este tipo de problemas abarcan otro tipo de perspectivas como la de recursos, datos, manejo de excepciones, etc. Cada uno de estos patrones proporciona de forma diferente una solución que unida a las soluciones provistas en cada perspectiva permite la finalización completa de cada una de las tareas de un proceso. De aquí la importancia de la existencia de herramientas que permitan el modelaje y/o ejecución de tareas, actividades y procesos que deben llevarse a cabo en cierto orden y entre diferentes interesados involucrados en la ejecución de un proceso de negocio. En particular, los sistemas y/o lenguajes de Workflow, o BPMS - Business Process Management Systems, consisten en modelar la interacción entre personas, procesos y máquinas, con el objetivo de reducir entender y mejorar la realización de un trabajo conjunto. Un motor de Workflow facilita la automatización de los flujos de trabajo de los procesos, permite integrar o rediseñar los procesos de la empresa, de acuerdo con a las estrategias que la organización disponga y finalmente se encarga de manejar las tareas en un flujo, de determinar cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento a su cumplimiento de las tareas..

(5) El uso de diferentes herramientas para modelar el comportamiento de este tipo de problemasWorkflows, donde se quiere hacer una gestión sobre las diferentes actividades y recursos para el logro de un objetivo cobra importancia de acuerdo con su capacidad de solucionar los problemas de forma integral y no desagregada, esta es la propuesta de diferentes herramientas como Bizagi, Yawl, BPMN, entre otras. Para lograr que un proceso sea cual sea su naturaleza se ejecute de manera automática y sistemática, es necesario contar con un motor de Workflow que es el medio por el cual se materializa y orquestan los recursos de los procesos, con el que se formalizan las reglas del negocio para automatizar el proceso de toma de decisiones, es decir, qué rama de Workflow elegir según el contexto. Por tanto es necesario que el motor de Workflow soporte adecuadamente las necesidades de administración y gestión de los recursos de procesos a través de las diferentes perspectivas.. 1.2. DEFINICION DEL PROBLEMA. Teniendo en cuenta la problemática definida anteriormente de las compañías, surgen varias inquietudes alrededor de los motores de Workflow existentes en el mercado y de sus capacidades para abarcar las necesidades cambiantes en los contextos actuales de la vida laboral y empresarial. En el mundo empresarial actual, el cual está cada vez mas asociado a la investigación y creación de nuevos productos, tendencias y técnicas para el desarrollo de las actividades, se hace fundamental la existencia de herramientas de apoyo que sean adaptables y extensibles de manera que puedan mantenerse vigentes como apoyo a las compañías en su continuo proceso de cambio. Precisamente esta motivación es la que ha originado la idea de este trabajo de tesis, en el cual se pretende demostrar que a través del uso de una plataforma de desarrollo extensible y adaptable es posible crear o reescribir motores de Workflow que ofrezcan las ventajas exigidas por los mercados actuales. Para poder suplir las características en un motor de Workflow, exigidas por el mercado actual, es fundamental, que el motor sea fácilmente extensible y adaptable. Existen herramientas extensibles en cierta medida a través de servicios web, o adaptables ofreciendo su código a la comunidad. En el primer caso las posibilidades de extensión son limitadas, por otro lado en el segundo aunque prácticamente las posibilidades de extensión son ilimitadas, las modificaciones de código existente por terceros en ocasiones pueden generar inconsistencias o funcionamientos inesperados en las herramientas. El objetivo entonces de este trabajo de tesis, es lograr que un lenguaje de Workflow (ya sea nuevo o existente) sea fácilmente extensible y adaptable. Para darle una estructura a este trabajo se determino encontrar un lenguaje de Workflow existente que contara con varias de las.

(6) características requeridas por los negocios actuales, el cual pudiera ser estudiado, y comprendido a profundidad, de manera que pudiera reescribirse sobre una plataforma extensible y adaptable, y así lograr los objetivos propuestos. En la búsqueda de un buen ejemplo de lenguaje de Workflow para el desarrollo del trabajo de investigación, se encontró YAWL como una buena alternativa, teniendo en cuenta que es una propuesta completa, bien documentada y que adicionalmente permite la revisión de su código al ser Open Source. Para realizar la propuesta que da sentido a este trabajo, se realizo inicialmente un levantamiento del funcionamiento y sentido de YAWL, dando como resultado la definición de un metamodelo que abstrae los elementos principales de YAWL, el cual puede ser desarrollado sobre la Plataforma CUMBIA de manera que se genero una versión de YAWL desarrollada sobre el concepto de Modelos Ejecutables implementado en CUMBIA. 1.3. BACKGROUND TECNOLOGICO. 1.3.1. PROBLEMAS PARA EXTENSIBILIDAD Y ADAPTABILIDAD EN MOTORES DE WORKFLOW. Los lenguajes de Workflow buscan hacer una representación (modelo) de las relaciones de intercambio entre los componentes internos de un sistema y su reacción a los estímulos de su medio ambiente que son sus entradas y salidas. Esto hace que este tipo de sistemas deban tener capacidad de adaptarse a cambios constantes. La adaptación de los lenguajes y motores de Workflow puede realizarse no solo realizando modificaciones a elementos existentes que deben adaptarse de acuerdo a las necesidades del ambiente cambiante, sino también extendiendo el lenguaje con utilidades totalmente nuevas que requiera de extensiones agregando nuevas dimensiones a un lenguaje existente. Tanto adaptar elementos existentes, como extender lenguajes de Workflow completos, son dos características deseables en los motores de Workflow que actualmente no son ofrecidas por casi ningún motor y/o lenguaje de Workflow, la problemática consiste en que la mayoría de lenguajes de Workflow se encuentran limitados por su plataforma, o están cerrados a modificaciones latentes. De manera que la extensión de estos no puede realizarse rápidamente, en muchos casos es necesario esperar a nuevas versiones, o utilizar diferentes lenguajes para lograr requerimientos específicos en el modelamiento de flujos de trabajo. Existen diversos lenguajes y/o motores de Workflow, cada uno con características distintas y a su vez con ventajas y limitaciones para su extensión y adaptabilidad. Por ejemplo motores como COSA, FLOWer, Oracle Bussines Process Manager, Microsoft BizTalk Server, Windows Workflow Foundation, etc. Son motores comerciales existentes actualmente que permiten agregar piezas de código a sus tareas, permitiendo en cierto modo extensibilidad en el sentido de agregar funcionamientos específicos a tareas especificas. Hacia la tendencia del software libre, existen otros motores de Workflow que exponen a la comunidad su código, en su mayoría con fines académicos, o simplemente por política de sus creadores, dentro de estos se encuentran Apache ODE, Syrus, JFlower, YAWL, entre otros. En el caso de los motores de código abierto, a diferencia del caso anterior, las posibilidades de extensión son mayores debido a que.

(7) eventualmente su código podría ser modificado y por ende su funcionalidad puede ser extendida o adaptada a nuevas necesidades. Las posibilidades de extensión en motores de código abierto son posibles, pero no en todos los casos, funcionalmente factibles, esto debido a que aunque el código del motor puede en teoría modificarse, usualmente los proyectos de intervención de código presentan riesgos mayores ya que durante las intervenciones pueden presentarse situaciones como inconsistencias entre el código y su documentación, código no estructurado, rutinas objetos, funciones (en general elementos) no documentados, etc. Con el fin de encontrar nuevas posibilidades de extensión y adaptabilidad en motores de Workflow existentes, surge este proyecto de maestría, que busca utilizar Cumbia, como una plataforma que permite la ejecución de modelos, y plantear una nueva manera de definir un motor de Workflow existente, que cuente adicionalmente a sus características intrínsecas, con opciones de extensión y adaptabilidad de manera que estas acciones puedan realizarse de manera estructurada, sin incurrir en riesgos comunes como el malfuncionamiento del motor como consecuencia de una extensión mal definida, el cambio de funcionamiento de la herramienta en sus características anteriores, etc. Se espera que teniendo en cuenta que las opciones de extensibilidad logradas al implementar un lenguaje existente sobre CUMBIA, las extensiones realizadas al lenguaje sean no invasivas y mucho mejor definidas que en los casos en que no existe una plataforma que permita este tipo de extensiones. El objetivo se pretende lograr realizando un ejercicio práctico, utilizando con YAWL como materia prima. Por esta razón a continuación se realizara una breve introducción a la plataforma utilizada: CUMBIA, y al lenguaje existente YAWL que se utilizarán en el ejercicio práctico. 1.3.2. CUMBIA. Al ser CUMBIA una plataforma que permite la ejecución de modelos, los cuales al partir de metamodelos bien definidos, pueden ser adaptados, extendidos y/o entretejidos entre ellos con menor dificultad que cuando se intentan realizar estas acciones sobre el código fuente de aplicaciones, el objetivo de extender y adaptar YAWL sin afectar sus características principales puede obtenerse, si se realiza una versión de YAWL sobre la plataforma CUMBIA. 1.3.3. YAWL. Este trabajo de tesis busca encontrar alternativas para la extensión de YAWL, Lenguaje de Workflow que tiene sus bases en redes de Petri, que soporta las perspectivas de control , recursos y tiempo en lenguajes de Workflow. Al ser YAWL un lenguaje de código abierto, las posibilidades de extensión y adaptabilidad son superiores a las que se tienen con otros lenguajes más cerrados. Se pretende con esta tesis aumentar las capacidades para modelar problemas con YAWL aprovechando la propiedad de extensibilidad de los sistemas que consiste en la capacidad de incorporar nuevas características (funcionalidades en este caso) sin afectar fuertemente sus características iniciales. Durante este trabajo se mostrara como puede realizarse una extensión para aumentar las capacidades en las perspectivas (dominios) de control y tiempo, y agregando el dominio de log(traza) sobre la plataforma de Cumbia..

(8) 2. ESTADO DEL ARTE 2.1. CUMBIA. En el contexto de la ejecución de modelos, y la creación de aplicaciones basadas en Workflow, La Universidad de los Andes y el grupo de investigación en construcción de software han desarrollado CUMBIA como una plataforma que permite la ejecución de modelos, usando una estructura especial que consiste en un meta modelo con comportamiento. Esta estructura facilita el desarrollo de aplicaciones basadas en Workflow. Metamodelos en Cumbia Un metamodelo de cumbia, es un conjunto de estructuras llamadas objetos Abiertos, que se encuentran relacionados entre sí a través de diferentes tipos de conexiones: Conexiones simples que pueden tener cardinalidades simples o múltiples y herencias entre elementos. En el contexto de Cumbia los metamodelos son definidos utilizando un XML en el cual además de enumerar las entidades se definen sus relaciones y además los roles jugados por cada una de las entidades e función de sus entidades relacionadas. Dentro de la definición de un metamodelo Cumbia, se define también para cada elemento los atributos y métodos de su entidad. Con el fin de que la plataforma pueda interrelacionar el metamodelo con su comportamiento definido directamente en el código del motor. Objetos Abiertos Como se introdujo en la sección anterior, los objetos abiertos están formados por una entidad y además está conformado por una maquina de estados, y un conjunto de acciones y eventos que permiten darle a un elemento del meta modelo la posibilidad de ejecutarse de forma autónoma, y de interactuar con los demás elementos de este (el meta modelo) ..

(9) Una entidad es simplemente un objeto tradicional con atributos y métodos, esta provee al Objeto Abierto su estado basado en atributos, mientras que los métodos implementan parte de su comportamiento. La máquina de estados presenta el ciclo de vida de la entidad, esta permite a otros conocer el estado actual de la entidad y de esta manera reaccionar a sus cambios mediante eventos. Finalmente las acciones son piezas de código asociadas a las transiciones de la máquina de estados, las cuales modelan el comportamiento de la entidad durante el cambio de estados en la máquina; Una vez una transición es iniciada las acciones asociadas a esta se ejecutan de manera sincronizada.. Fig 1. Ilustración de Un Meta modelo simple, y un ejemplo de uno de sus objetos abiertos. El objeto de CUMBIA es ser una plataforma para la creación de modelos ejecutables, para esto es necesaria la interacción entre elementos de un meta modelo (objetos abiertos), la cual se hace posible con los elementos descritos anteriormente. Esta interacción está basada en dos mecanismos: Generación de eventos, y llamado a métodos. En la especificación de una maquina de estados para un Objeto Abierto de CUMBIA, cada transición tiene asociado un evento de inicio, Cuando el objeto abierto identifica que el evento se ha generado, la transición en cuestión se ejecuta. Este mecanismo tiene por objetivo la sincronización entre objetos abiertos y la conservación de la consistencia del estado interno de la entidad. Una vez la transición en finalizada, se genera un evento que cambia el estado en la maquina, haciendo así que esta continúe su ejecución. Adicionalmente, la arquitectura de CUMBIA permite que se generen eventos también durante la ejecución de las acciones de una transición, de esta manera es posible sincronizar los objetos abiertos, a través de sus cambios de estado. Los eventos esperados por una maquina de estados de cumbia para su ejecución automática, se describen con una expresión del tipo [ELEMENTO]evento, en esta estructura “[ELEMENTO]” indica el.

(10) rol de quien es esperado surja el evento, mientras que “evento” especifica el evento particular esperado. Para implementar técnicas de reuso fácilmente en las maquinas de estado de CUMBIA, “ELEMENTO” no es el identificador de un elemento especifico del modelo, en cambio este nombre se refiere a una referencia relativa para localizarlo, esto es lo que en CUMBIA se define como ROL. Por ejemplo si un objeto abierto en una estructura jerárquica tiene un evento generado por [PADRE], entonces se entiende que el generador del evento se encuentra en una posición superior en la jerarquía, en cambio si el evento es generado por [ME], entonces es el propio objeto abierto el que ha generado dicho evento. El otro mecanismo de interacción entre objetos abiertos consiste en el llamado de métodos, mientras que el mecanismo por eventos es un mecanismo asíncrono, el llamado de métodos se caracteriza por ser una método de interacción síncrona, usada para ejecutar métodos ofrecidos por las entidades de el objeto abierto actual, o de otros objetos abiertos del modelo. Las entidades pueden recibir llamados a métodos de dos fuentes: pueden venir de fuentes externas como la interacción de un usuario o otras aplicaciones relacionadas; y también estos llamados pueden ser realizados por acciones de una transición las cuales usualmente invocan métodos de diferentes entidades en el modelo, jugando un papel central en la coordinación del modelo. Usando esta arquitectura es posible crear diferentes tipos de aplicaciones basadas en Workflows, en particular la estructura de objetos abiertos se ha utilizado para el desarrollo de diversas aplicaciones como Paper Express, Caffeine, XPM, XTM, Alegre, y YoC Desarrollando motores de Workflow usando Metamodelos En el contexto de CUMBIA y los modelos ejecutables, el desarrollo de motores de Workflow puede basarse en el concepto de los dominios y dimensiones de Workflow. Teniendo en cuenta la capacidad de los modelos para entretejerse entre sí, si sus metamodelos están bien definidos, la idea de modelar cada dimensión como un metamodelo distinto de manera en que se pueda crear un motor de Workflow fácilmente adaptable y extensible con la posibilidad de integrar nuevas dimensiones, se vuelve factible. En la búsqueda de una semántica grafica que permita ilustrar metamodelos y las relaciones entre estos, se identificaron diferentes tipos de relaciones que pueden darse al crear y entretejer modelos en una plataforma como CUMBIA que permite este tipo de interacciones..

(11) Fig 2ª. Diferentes Metamodelos relacionados entre si.. En la figura anterior se pretende ilustrar un Ejemplo de la posibilidad de interacción de varios metamodelos, y como al tener bien definidas las dimensiones de cada modelo se puede lograr un motor de Workflow completo que permita al usuario el manejo solo del control, sino de tantas dimensiones como se puedan definir en metamodelos independientes. Las relaciones entre metamodelos están definidas en términos de los tipos de relaciones definidos a continuación. Estos tres tipos de relaciones permiten que dos metamodelos se relacionen en tres diferentes tipos: a modo de extensión, a modo de interacción dependiente y a modo de interacción independiente.. Fig 2b. Semántica grafica para definir relaciones entre modelos. 2.2. YAWL. Como parte del desarrollo metodológico de la tesis, fue necesario entender y conoce a fondo YAWL, y las herramientas que este ofrece para el desarrollo y ejecución de flujos de trabajo. El objetivo de este conocimiento previo es reconocer los fundamentos de YAWL, con este conocimiento previo adquirido Antecedentes Tecnológicos de YAWL Como ha sido introducido en secciones anteriores de este documento YAWL, tiene como punto de partida las redes de Petri, pero adicionalmente agrega mecanismos a su lenguaje para soportar intuitivamente los patrones de Workflow Especificados [20]..

(12) Introducción a las redes de Petri Como introducción a YAWL, y con el fin de tener un marco bien referenciado de los elementos teóricos base de esta tesis, los cuales al final serán la base comparativa para determinar el buen logro de objetivos de esta tesis. Es indispensable introducir la teoría y las definiciones principales de las Redes de Petri. Las redes de Petri son una generalización de la teoría de autómatas, en la cual es posible expresar eventos concurrentes[21], apoyándose en elementos definidos para este fin a saber: lugares, transiciones, arcos dirigidos, y tokens. Al ser una red de Petri un grafo bipartito dirigido, el funcionamiento básico de una red de Petri consiste en la trasmisión de tokens entre lugares, a través de transiciones las cuales se habilitan en la medida de que existan tokens en las posiciones de entrada de estas transiciones. Cuando una transición es disparada en una red de Petri esta consume los tokens en la posición que le precede y genera la misma cantidad de tokens en la que lo antecede, permitiendo el flujo de estos dentro de la red. [21]. Fig3. Ejemplo de una red de petri [21]. Propiedades de las redes de Petri Las propiedades de las redes de Petri que permiten detectar fenómenos de interés en el sistema que modelan son: Vivacidad: Se dice que una Red de Petri está viva si todas sus transiciones son alcanzables, desde posiciones que las habilitan. De la misma manera una red es parcialmente viva, si no todas sus transiciones son alcanzables. Ciclicidad: Se dice que una red de Petri posee un comportamiento cíclico, si desde cualquier posición de la red existe una secuencia cíclica que permite alcanzar su estado inicial..

(13) Limitación: Esta propiedad permite identificar si la red es finita, y por tanto podría implementarse con recursos finitos. Una red de Petri es limitada a un número, si todas sus posiciones son limitadas a este número. Conservación: Se dice que una red de Petri es conservativa, si para cualquier secuencia de transiciones entre la posición inicial de una red de Petri y una posición Alcanzable desde esta posición inicial, la cantidad de Marcas en la red es el mismo. Conflictividad: Una red de Petri está en conflicto, si en ella un conjunto de transiciones al ser efectuadas da como resultado una des habilitación de una transición. Una situación de conflicto es en general inaceptable en las redes de Petri, por tanto las redes de Petri deben ser siempre persistentes. Para que una red de Petri sea persistente, no puede haber ningún conjunto de Transiciones en conflicto. Exclusión Mutua: Se dice que un conjunto de transiciones es mutuamente excluyente, si al ejecutarse una transición del conjunto todas las demás se deshabilitan Las redes de Petri cuentan con características que permiten identificar y prevenir ambiguedades y contradicciones en los procesos que modelan, y a su vez con sus elementos propios se pueden cumplir la mayoría de los patrones de Workflow, exceptuado algunos patrones especiales como “synchronizing merge”, el patrón discriminador, “N-out-of-M join” caso de cancelación, y múltiples instancias sin conocimiento en tiempo de ejecución a priori. Partiendo de las ventajas de las redes de Petri, surge YAWL, que entre otros conceptos, agrega tres conceptos particulares en la definición de su lenguaje: or-join, conjuntos de cancelación y tareas multi-instancia, los cuales permiten el cumplimiento de los 5 patrones de Workflow (no soportados directamente en las redes de Petri) nombrados anteriormente. En la siguiente parte de la sección se presentara YAWL, como un nuevo lenguaje de Workflow, el cual no solo se constituye en un lenguaje, sino también en una herramienta útil para el modelado y ejecución de flujos de trabajo debido a sus herramientas anexas. YAWL Como lenguaje de Workflow Elementos básicos del lenguaje Hablando específicamente del lenguaje definido para poder lograr los objetivos de YAWL, en cuanto al cubrimiento de la mayoría de los patrones de Workflow (Dimensión de Control), YAWL propone los siguientes elementos en su lenguaje los cuales permitirán modelar y controlar flujos de trabajo..

(14) Fig 4. Símbolos utilizados en YAWL [22] Elementos básicos de la Herramienta Como se ha descrito anteriormente, YAWL es una herramienta libre para modelaje y ejecución de Workflows, esta herramienta está basada en las Redes de Petri de manera que internamente tiene una semántica formal que implementa mecanismos para permitir un soporte directo e intuitivo para la mayoría de patrones de Workflow definidos en la literatura [17]. Como las redes de Petri soportan mas patrones de Workflow que otras aproximaciones, YAWL por ende soporta estos mismos patrones de Workflow, sin embargo y YAWL agrega nuevos conceptos a su solución: por ejemplo para el caso de la funcionalidad de las tareas ofrece al usuario la posibilidad de usar diferentes tipos de tareas, también permite el uso de servicios YAWL, formularios personalizados para las tareas, y a simple pero poderosa manera de manejar datos internamente usando XPATH. YAWL implementa con sus herramientas, no solo una muy buena propuesta para la dimensión de control en Workflows, sino también implementa dentro de su propuesta, las dimensiones de Recursos y de tiempo, de esta manera se presenta como una muy buena aproximación para la solución de varios problemas concernientes al flujo de trabajo.. Fig 5. Definición Grafica de YAWL. Teniendo en cuenta que dentro del contexto de CUMBIA se puede realizar una separación de dimensiones y se puede expresar cada una de las dimensiones como un metamodelo. La figura 5 sintetiza gráficamente las dimensiones existentes en YAWL, mostrando cada una de estas como un metamodelo diferente relacionado con otro metamodelo, esta síntesis puede realizarse utilizando la sintaxis definida para expresar relaciones entre metamodelos..

(15) YAWL como lenguaje de Workflow ha sido explicado durante esta sección, en adición los creadores de YAWL no solo han desarrollado un lenguaje sino también diferentes elementos, que permiten el diseño y ejecución de Workflows. Estos son: un editor grafico, un motor de ejecución, y un cliente web que permite la visualización de la ejecución de los procesos en el motor. EL EDITOR Para efectos del trabajo practico desarrollado durante esta tesis de maestría, el editor será una herramienta importante, ya que no desarrollaremos una herramienta de edición propia, sino que utilizaremos el editor existente en YAWL para diseñar gráficamente flujos YAWL. Una vez en YAWL se define gráficamente un flujo, este queda plasmado en un XML, el cual puede ser interpretado por alguna herramienta que El editor de YAWL, se presenta como una herramienta grafica muy poderosa, que permite modelar cualquier flujo con los elementos de YAWL, esta herramienta además de ser intuitiva, permite guardar los modelos diseñados, en formato XML, de manera que no solo el motor interno de YAWL puede interpretarlos, sino que cualquier interprete desarrollado para tal fin podría leer, interpretar, modelar y eventualmente ejecutar Workflows diseñados con el editor de YAWL.. Fig 6. Pantalla principal del Editor de YAWL. Adicional a las herramientas de diseño de Workflows, el motor contiene todas las herramientas para agregar al modelo elementos de manejo de la dimensión de tiempo, dando la oportunidad de agregar tareas con temporizadores, también permite agregar a las tareas la ejecución de servicios especiales o su correspondencia con formularios específicos..

(16) Fig 7ª. Herramienta para agregar Temporizadores a tareas YAWL.. Fig 7b. Herramienta para agregar formularios personalizados a tareas YAWL. La herramienta grafica soporta el manejo completo de recursos, en el cual para una tarea se puede determinar, quien la inicia, quien la ofrece y quien la asigna a su responsable. Y de la misma manera se pueden asignar características para el manejo de recursos de la tarea como: la posibilidad de pausar la tarea, la posibilidad de reasignación, la posibilidad de que la tarea sea rechazada por su responsable, etc. El manejo de datos en YAWL, se realiza utilizando variables de diversos tipos, las cuales pueden set manipuladas mediante el uso de expresiones XPATH, estas expresiones y definiciones de variables también se crean desde el editor, mediante herramientas simples que permiten la creación de nuevos elementos de datos, y su transformación dentro de las tareas.. Fig 8ª. Creación y administración de variables. Fig 8b. transformación de datos con XPATH. Una vez creado un proceso YAWL completo, la herramienta grafica permite su validación, y análisis, con el fin de evitar errores de creación en el proceso como ciclos infinitos estados, inalcanzables, etc..

(17) Fig 9. Validador de procesos. EL MOTOR Y SU CLIENTE WEB El Cliente para ejecución de procesos YAWL, es llamado “YAWL Control Centre”, esta aplicación Web permite la carga de Procesos YAWL definidos en el editor., y su respectiva ejecución, y asignación de recursos.. Fig 10ª. Pagina inicial del cliente Web. Fig 10b. Modulo de Carga de procesos YAWL. El cliente Web cuenta con un completo modulo de creación de responsables, en el cual no solo se crean recursos para la ejecución de los procesos YAWL, sino que también se asignan prioridades, roles y responsabilidades a cada uno de ellos, Al crear los usuarios y al asignarlos a un proceso previamente cargado.. Fig 11ª. Administracion de Usuario Roles y. Fig 11b. Modulo de administración de tareas y Colas..

(18) responsabilidades. El motor, puede manejar instancias de los procesos cargados, y asigna las tareas automáticamente a los responsables asignados. De esta manera los responsables pueden entrar al Control Centre con su usuario, y encontraran en su lista de tareas, únicamente aquellas que pueden iniciarse de acuerdo con el proceso en curso, para poder realizar las acciones especificadas, ya sea ejecutar la tarea, realizar algún procedimiento manual, reasignar la tarea (si esta lo permite), etc.. Fig 12. Administracion de tareas en el perfil de un recurso especifico. 2.3. POSIBILIDADES DE EXTENSION DE YAWL SOBRE CUMBIA. Como fue expresado durante la definición del problema identificado para el desarrollo de esta tesis, aunque la extensibilidad y adaptabilidad de un producto como YAWL es imaginable debido a su característica de código abierto, en este caso surgen los problemas descritos anteriormente, con respecto a la generación de inconsistencias en el código, la desestabilización de funcionalidades existentes, resultados inesperados, entre otros, si es que este código no es modificado correctamente. Si en particular YAWL estuviera desarrollado sobre una plataforma extensible, su extensión y adaptación se podría realizar manera controlada, y se facilitaría la implementación de nuevas funcionalidades utilizando estrategias como reutilización, extensión de funcionalidades existentes, etc. Teniendo en cuenta la problemática descrita se puede encontrar en Cumbia una plataforma para el desarrollo de un metamodelo de YAWL, en el cual se puedan implementar los comportamientos del lenguaje convirtiéndolo los procesos YAWL en modelos ejecutables. Esta aproximación requiere de un estudio previo del funcionamiento interno de YAWL, y de la implementación de mecanismos complejos en el Metamodelo que permitan la correcta interacción entre las representaciones de los elemento del lenguaje, asi como la.

(19) implementación de mecanismos de control específicos de YAWL, como el manejo de tokens, la resolución de conflictos de ejecución de tareas, etc. Adicionalmente la implementación de YAWL como un metamodelo cumbia permitirá su interacción con otros metamodelos, de manera que al final de esta tesis podrán comprobarse los enunciados descritos durante la introducción, en los cuales se plantea que el modelo propuesto facilita la extensibilidad y adaptabilidad en motores de Workflow.. 3. OBJETIVO GENERAL Y ESPECIFICOS El objetivo General de este trabajo de tesis consiste en la implementación de una versión de YAWL sobre la Plataforma CUMBIA, para tener como resultado un Motor de ejecución de procesos YAWL que pueda ser extendido fácilmente. Se exploraran diferentes técnicas para extender un motor de Workflow agregando nuevas funcionalidades y elementos al lenguaje elegido sin afectar directamente sus características y funcionamiento interno. En particular con este trabajo se pretenden cumplir los siguientes objetivos específicos: Desarrollar una versión funcional de YAWL sobre la plataforma CUMBIA Demostrar la capacidad de CUMBIA para desarrollar diversos motores de Workflow Demostrar que la Plataforma CUMBIA es adaptable y permite modificar elementos existentes de un lenguaje de Workflow Identificar diferentes tipos de interacciones entre dimensiones de Workflow Demostrar que la Plataforma CUMBIA es extensible y permite agregar nuevas dimensiones a un lenguaje de Workflow existente Verificar que el uso del lenguaje de tejido de metamodelos de CUMBIA es efectivo y permite entreteje cualquier conjunto de metamodelos desarrollados sobre la Plataforma Desarrollar una extensión a YAWL en la cual se pueda agregar un nuevo elemento a la dimensión de control de YAWL Desarrollar una extensión a YAWL que agregue una nueva dimensión al lenguaje Desarrollar una extensión a YAWL en la que se reemplace una dimensión actual de Workflow implementada por YAWL distinta a la de Control. Identificar nuevos métodos para adaptabilidad y extensibilidad de motores de Workflow Explorar opciones de reuso en el desarrollo de extensiones a motores de Workflow Ofrecer a la comunidad educativa una opción para el desarrollo de Motores de Workflow adaptables y extensibles.

(20) 4. YOC 4.1. INTRODUCCION A YOC. Con el fin de lograr los objetivos propuestos para esta tesis de maestría se realizo una revisión completa de las funcionalidades ofrecidas por YAWL, y de sus características internas. Este estudio permitió identificar la arquitectura de YAWL, a nivel de dimensiones de Workflow soportadas en el lenguaje. Al identificar todos los elementos de YAWL, puede llegarse a una abstracción de su arquitectura, y así poder desarrollar una nueva versión de YAWL sobre una plataforma diferente a la original, en este caso CUMBIA. En el proceso de desarrollo de esta tesis surge YoC como la versión sobre cumbia de YAWL. YoC parte de la interpretación realizada de los elementos de YAWL, teniendo en cuenta sus elementos se identifico una Arquitectura de primer nivel en la cual se identifican las dimensiones y sus relaciones. 4.2. ARQUITECTURA. Teniendo en cuenta el estudio previo realizado se definió YoC como un conjunto de Metamodelos, tres para ser exactos, los cuales entretejidos permiten modelar el funcionamiento completo de un proceso YAWL. Los tres metamodelos identificados para el desarrollo de YoC dan soporte a las dimensiones de control, Recursos y Tiempo, que son las tres dimensiones identificadas en el levantamiento de requerimientos sobre YAWL .. Fig 13. Definición Grafica de YoC.

(21) En contraste con las figura 3, el metamodelo de YoC, continua mostrando la dimensión de recursos como una dimensión dependiente de la de control, pero en nuestro desarrollo definimos la dimensión de tiempo de YoC como una dimensión independiente que conoce, observa, reacciona y actúa sobre la dimensión de Control. Es posible desarrollar la Arquitectura planteada sobre CUMBIA, ya que esta plataforma permite la división de conceptos o dimensiones en distintos metamodelos, y así mismo permite implementar las relaciones entre estos. En particular la dimensión de Control de YoC implementa toda la parte de YAWL que tiene que ver con la ejecución y coordinación de tareas y procesos YAWL, y el soporte a diferentes elementos de flujo propios del lenguaje: Tareas (atómicas, compuestas, multitareas.), condiciones, JOINS, SPLITS, Regiones de Cancelación, Flujos simples, Flujos condicionales, etc. Por otro lado la dimensión de recursos de YoC implementa todo lo concerniente a las reglas de asignación de las tareas a los recursos existentes en un proceso YAWL. Finalmente la dimensión de tiempo de YoC implementa un temporizador simple que puede agregarse a una tarea, tal como YAWL dispone en su lenguaje. 4.3. DIMENSION DE CONTROL. La dimensión de control en YoC, es la dimensión más compleja del conjunto de metamodelos identificados para su desarrollo, el diseño y desarrollo de este metamodelo, implica no solo la identificación de los elementos básicos del lenguaje, sino la implementación de elementos en el lenguaje que permitan a YoC, tener un comportamiento idéntico al de YAWL. Para el desarrollo de la dimensión de control el YoC, se tuvo en cuenta el comportamiento de las redes de Petri en cuanto al manejo de los tokens, y las asignación de estos a los estados con el fin de modelar el flujo de un proceso, tal y como lo haría YAWL. Para este fin se desarrollaron elementos particulares en YoC que permiten simular la forma en que las redes de Petri administran los tokens, y la asignación de tareas, en este caso la cola de ejecución de YoC, la cual será explicada a profundidad en esta sección. Para el manejo de otros elementos de YoC identificados que provienen de YAWL, pero no de sus bases en las redes de Petri, como las multitareas, se implementaron mecanismos especiales de manejo de datos, que permiten la sincronización interna de las variables del proceso y ofrecen consistencia a la ejecución, y algunos mecanismos de memoria compartida implementados. La dimensión de control en YoC, está compuesta por varios elementos, los cuales se encuentran definidos en un metamodelo de CUMBIA mediante el cual se pueden ejecutar modelos YAWL conformes al metamodelo definido..

(22) Fig 14. Metamodelo de Dimensión de Control en YoC. Construcción del metamodelo Los elementos del metamodelo de YOC surgen de una construcción basada en el estudio de YAWL, sus elementos y su comportamiento. El reconocimiento de YAWL como lenguaje y como herramienta para el modelado y ejecución de procesos, permitió hacer la distinción entre elementos de las diferentes dimensiones. El Metamodelo de la dimensión de control de YoC, cuenta con 26 elementos cada uno de los cuales esta internamente definido como un Objeto Abierto de CUMBIA, en este metamodelo de cumbia en particular, existen Objetos abiertos que cuentan con su respectiva Entidad y maquina de estados, y también existen elementos que por su naturaleza no requieren del modelamiento de su comportamiento usando una maquina de estados, sino que cuentan únicamente con una entidad que permite realizar acciones sobre el elemento que esta representa. A continuación de explicara detalladamente cada uno de los Elementos del metamodelo, haciendo énfasis en su funcionamiento, la descripción de su comportamiento a partir de la máquina.

(23) de estados asociada a cada uno en caso de existir, sus respectivos roles, y su respuesta a eventos generados por otros elementos del metamodelo. NET El elementos de NET, es el elemento principal del Modelo, este elemento representa la Red de Petri, la cual es la base para el funcionamiento de YAWL. La red tiene las responsabilidades de orquestar el inicio y fin de la ejecución de un proceso YAWL, así como de iniciar y administrar la cola de ejecución de tareas ,y la generación del token inicial para el proceso.. Fig15. Maquina de estados para el elemento NET del metamodelo. La máquina de estados de la Red, cuenta con diferentes acciones que permiten su ejecución: GenerateFirstToken, LookForTokens, InitializeQueue, DeliverInitialToken, PrepareOutputData, cada una de las acciones enunciadas anteriormente realiza cambios sobre el modelo YoC cuando es ejecutada, logrando la coordinación entre elementos y por ende la ejecución de modelos YoC de manera adecuada. En particular la acción GenerateFirstToken, es realizada cuando la condición inicial de la Red lanza el evento NotEnoughTokensReceived, en este caso es generado un nuevo token que permite la continuidad del proceso..

(24) La acción LookForTokens, es generada cuando una condición intermedia lanza el evento NotEnoughTokensReceived, este caso en particular se da cuando la red que se va a ejecutar es una tarea compuesta, en este caso la red que esta por ejecutarse se queda esperando un tokens hasta que uno llega por efecto de la coordinación de la ejecución del modelo Una vez el evento inicial de la red tiene todas las condiciones para iniciar, y en efecto inicia, esta condición genera un evento de inicio que activa la transición gettingInputData. Al realizarse esta transición se ejecuta la acción InitializeQueue, mediante la cual, la red inicializa la cola de ejecución, la cual se convertirá en parte fundamental en la coordinación y ejecución de las tareas, y en la resolución de conflictos de ejecución. Una vez la red ha recibido todos sus datos iniciales esta lista para empezar su ejecución, en este momento apropia red genera un evento de aviso de recepción de los datos, el cual permite la ejecución de la siguiente acción: DeliverInitialToken, esta acción pone a rodar el token generado al inicio de la red, para que el modelo empiece a ejecutarse por si solo dependiendo de las condiciones definidas previamente o durante su ejecución Una vez la red ha terminado de ejecutarse, situación conocida mediante la generación del evento de finalización generado por la condición final del modelo, se da inicio a la ejecución de la última acción del elemento Red: PrepareOutputData, en el cual toda la data de salida es preparada para finalizar la ejecución de la red, una vez preparada la data, esta es enviada y actualizada en las variables de salida de la red, para nuevamente volver al estado de inicio el cual la red queda habilitada para iniciar otro proceso dependiendo de las condiciones de la ejecución EXECUTION QUEUE Tal como se explico en secciones anteriores, la cola de ejecución es un elemento en el Modelo que no contiene una maquina de estados que describa su comportamiento debido a su simplicidad en funcionamiento, la cola de ejecución cuenta simplemente con una entidad que define en forma de atributos y métodos, todas la características de una Cola a nivel informático. La cola de ejecución es considerara dentro del metamodelos uno de los elementos más importantes, ya que es el elemento que permite la coordinación y resolución de conflictos de ejecución cuando más de una tarea cumple con todas las características para ejecutarse a la vez..

(25) Fig 16. Red YAWL que muestra tres tereas que podrían estar en competencia por su ejecución en un momento especifico. En los ejemplos anteriores se ilustran situaciones en las cuales dos o más tareas se encuentran a simple vista con las mismas posibilidades de ser ejecutadas, en estos casos la red debe elegir por qué camino seguir con el fin de evitar inconsistencias en la ejecución del Modelo. Para solucionar estos conflictos, la cola de ejecución es un elemento importante, ya que esta almacena en sus memoria interna el orden en el cual las tareas van informando a la red a través de eventos en momento en el cual están listas para ejecutarse. De esta manera al ser la cola de ejecución en efecto una Cola, cuando la ejecución de la red llega a un momento de resolución de conflictos, simplemente se ejecuta la tarea que haya entrado primero a la cola de ejecución. DECOMPOSITION El elemento Decomposition, al igual que la cola no tiene su comportamiento definido a través de una maquina de estados, la función de este elemento dentro del modelo es administrar y permitir el manejo de datos durante la ejecución del Modelo, en YAWL, y por ende en YoC, cuenta con este elemento el cual siempre va asociado a una tarea y permite su descomposición de variables, así como la posible asignación y modificación de sus valores. El elemento decomposition contempla variables de instancia validas en todo el proceso o internas para cada tarea, estas variables pueden ser de casi cualquier tipo (cadena de caracteres, entero, entero sin signo, fecha, etc.) y pueden ser manipuladas utilizando expresiones XQUERY. NET ELEMENT Un Elemento de Red en el modelo es el elemento genérico para representar las tareas y la condiciones en la Red, para este caso en particular, los elementos de red tienen cada uno un comportamiento diferente, por tanto son la Tarea y la condición las que para el caso de YoC, cuentan con su propia Maquina de estados. Con respecto a la entidad del objeto abierto, aunque cada uno de los elementos de red tiene su propia entidad, estos extienden la entidad de Net Element, para compartir comportamientos comunes..

(26) TASK En YAWL, y YoC, la tarea es el núcleo de las acciones realizadas durante un proceso, Es en una tarea donde acurren las transformaciones de variables, o donde se realizan acciones más elaboradas a través de servicios YAWL o formularios personalizados. Las condiciones para la ejecución de una tarea son en resumen 2. La primera que el flujo del proceso requiera la ejecución de la tarea, y que existan suficientes tokens para que esta pueda ejecutarse. En caso de que el flujo del proceso de cómo resultado la posible ejecución de dos o más tareas y solo haya tokens en la red suficientes para ejecutar una de ellas, la cola de ejecución es quien determina el orden de ejecución.. Fig 17. Maquina de Estados para el elemento TASK del metamodelo. Aunque cada uno de los elementos de tipo tarea (Single Instance Atomic Task, Single Instance Composite Taks, Multiple Instance Atomic Task, Multiple Instance Composite Taks) tienen su funcionamiento diferente, se utiliza la misma definición de comportamiento en la máquina de estados, lo que es diferente para cada uno de los tipos de tarea es su comportamiento definido en su entidad y en las acciones realizadas. En general el comportamiento de una tarea independientemente de su tipo es el mismo a nivel general. Esta se encuentra en estado de espera mientras ella misma genere un evento que indica que no se encuentra lista para ejecutarse [ME]NotReady. Cada vez que este evento es generado se ejecuta la acción ValidateBeforeTokens, que valida la posibilidad de ejecución de la tarea y si esta se.

(27) encuentra lista para ejecutarse la envía a la cola de ejecución y manda un evento que permite la validación de la tarea en la cola. Una vez la tarea se encuentra en la primera posición de la cola, la propia maquina de estados de la tarea, enviara un evento (inTheTop) que indica que la tarea ya tiene todas las condiciones para ser ejecutada, y el cual es el desencadenador de la transición que inicia la tarea y la ubica en su estado de recepción de datos de entrada. Una vez los datos de entrada son recibidos y organizados en variables dentro de la tarea, se da pie al procesamiento de la tarea, como consecuencia del evento InputDataReceived, una vez la tarea ha sido procesada y notifica mediante el evento processed, se inicia el proceso de preparación de datos de salida, para luego enviarlos a la red en caso de ser necesario, y regresar a la red a su esta inicial de Espera. SINGLE INSTANCE TASK Las tareas de instancia singular, tienen la característica de que cuando una de estas es ejecutada por la red, solo una instancia de la tarea es lanzada, de manera que no existe ninguna necesidad de controlar el tiempo modo de acceso a los datos, entre instancias de la misma tarea. SINGLE ATOMIC TASK Una tarea atómica simple, es una tarea básica, y en general el tipo de tarea más utilizada en la mayoría de procesos comunes. Una tarea de este tipo puede ser una tarea manual que puede realizarse fuera del ambiente de ejecución del proceso y requiere simplemente un cambio de estado, o automatizada que cambia valores o variables dentro de la red. Este tipo de tareas en YoC, realizan únicamente la acción básica para la que han sido programadas, ya sea la modificación de una o varias variables internas o de instancia, la validación de algún elemento, la ejecución de un servicio, etc. SINGLE COMPOSITE TASK Este tipo de tareas en YoC difieren de las anteriores ya que internamente cuentan con un proceso YoC el cual se ejecutara una vez la tarea deba ejecutarse según el flujo del proceso. En este caso la ejecución del proceso está controlada por la máquina de estados de la red, la cual entiende su ejecución a partir de una condición inicial de una red o de una condición intermedia que inicie su ejecución si es que la red se encuentra dentro de una tarea YAWL. MULTIPLE INSTANCE TASK Las tareas multi-instancia tienen exactamente el mismo comportamiento que las tareas simples en sus dos variedades, a diferencia que el control y manejo de los datos en este caso se realiza en YoC, cuidando guardar la consistencia de los datos. Ya que en el caso de variables de instancia estos serán usados y afectados simultáneamente por las instancias de la tarea en ejecución. MULIPLE ATOMIC TASK Para el caso de las tareas simples Multi-instancia, se creó en YoC, una estructura interna similar a la Cola de ejecución, en la cual las variables son manejadas de manera que cada instancia pueda tener su propia.

(28) copia de la información inicial de la variable y una vez finalice la tarea su valor global sea actualizado sin generar conflictos en la información. Con esta estructura se puede garantizar que todas la instancias de la tarea que se esta ejecutando cuentan con la misma información al iniciar, y se asegura que el resultado final de los datos si requiere ser guardado sea guardado adecuadamente en las variables de instancia respectivas. Fue una decisión de desarrollo permitir que en caso de las multi-instancias, sea una determinación del modelador del proceso YoC, el buen uso y administración de las variables en caso de que no se cuente con una variable por cada instancia, sino con una sola variable la cual a final tendrá un solo valor independientemente de los valores finales de esta variable en cada instancia. MULTIPLE COMPOSITE TASK En el caso de las tareas multi-instancia compuestas, la situación es prácticamente la misma haciendo salvedad que las datos de entrada y salida no se manejan directamente con las tareas de la red interna en la tarea, sino que la data de entrada y la de salida es la que controla la máquina de estados de la red. Esto significa que en el caso de las variables de instancia de la red interna son independientes y pertenecen únicamente a cada una de las redes instanciadas dentro de la tarea compuesta. Es la información de entrada a la red, y la preparada en la finalización de la ejecución de cada red interna la que se sincroniza de la misma manera explicada en el caso de las tareas multi-instancia simples.. CANCELATION REGION Una región de cancelación en YoC es un espacio en el proceso que si es alcanzado lanza el evento de Abort para que todas las tareas asociadas a esta región se aborten de inmediato. Las regiones de cancelación en YoC tal como esta planteado en el metamodelo, están asociadas a una tarea del modelo, y pueden tener “dentro de si” uno o mas elementos de Red.. [ME]NotAllAborted. ChekElements. Fig 18. Maquina de Estados para el elemento CANCELATION REGION del Metamodelo.

(29) El procedimiento que se lleva a cabo una vez se llega a una región de cancelación durante el flujo de ejecución de un modelo YoC, consiste en el siguiente: Una vez la tarea del modelo que tiene asociada la región de cancelación es alcanzada por la ejecución esta tarea envía el evento para activar la región de cancelación: ActivateRegion. Una vez el evento es lanzado por la tarea, se ejecuta la acción InitiateAbortingElementsCR, esta acción lanza todos los eventos que requieren las tareas como las condiciones para ser abortadas durante su ejecución. Cada uno de los elementos abortados inicia un proceso dentro de su comportamiento para cancelarse, una vez este proceso termina dentro de un Net Element, se lanza un evento que notifica a la red su respectiva cancelación. Estos eventos son validados por la acción CheckEelements, la cual una vez encuentra que todos los elementos de red asociados a la región han sido cancelados genera el evento AllElementsAborted. Una vez todos los elementos asociados a la región son cancelados, la región vuelve a su estado inicial quedando en espera de una próxima activación. CONDITION La condición en YoC se ha convertido en un elemento trasnsportador y contenedor de tokens, entre tareas, adicionalmente es el elemento que dependiendo de los tokens que tenga en un momento dado de su ejecución adiciona a la cola de ejecución las tareas que se encuentran listas para ser ejecutadas.. Fig 19. Maquina de estados del elemento CONDITION del metamodelo.

(30) EL funcionamiento del elemento CONDITION es simple, básicamente inicia en un estado en el cual no tiene tokens suficientes para que sus tareas subsiguientes se ejecuten. Por tanto se encuentra ejecutando continuamente la acción que valida los tokens recibidos e identifica si estos son suficientes o no para continuar. Una vez se hayan recibido tokens suficientes: EnoughTokensRecceived, la condición se encarga de validar los eventos emitidos por las tareas que ya se encuentran listas para ser ejecutadas y agrega la siguiente por orden de solicitud a la cola de ejecución. Posteriormente la condición queda en un estado de espera de solicitudes, de tal manera que la entrega de tokens se activa una vez una de las tareas próximas a ejecutarse a través de su JOIN adjunto solicite los tokens necesarios. Debido a que la condición puede ser la fuente de más de una tarea, si es que tiene aun tokens disponibles, una vez se entregan los tokens para la ejecución de una tarea, la condición vuelve a quedar en el estado de espera de solicitudes mientras sus tokens se terminen. Por otro lado si en cambio sus tokens se han terminado, la condición vuelve a su estado inicial a la espera de la llegada de más tokens. INITIAL CONDITION De acuerdo con el Metamodelo para la dimensión de control de YoC, un modelo YoC debe tener únicamente una condición de inicio, esta condición termina siendo el motor de arranque de la ejecución del modelo ya que como se pudo ver en la descripción de la máquina de estados de la red, esta no genera el primer token sino hasta que la condición inicial haya enviado el mensaje de tokens insuficientes NotEnoughokensReceived. Como es fácil de observar, una condición inicial no difiere en su comportamiento de la condición básica descrita anteriormente. Por esta razón aunque cada una de las tres variedades de condiciones tienen variaciones pequeñas en su comportamiento estas variaciones se ven reflejadas en YoC, no en la máquina de estados que es en funcionamiento la misma, sino en las entidades de cada una de las condiciones, y en la acciones de otros elementos del metamodelo que responden a cada una de las condiciones existentes en YoC. INTERMEDIATE CONDITION Una condición intermedia en YoC corresponde exactamente a la descripción realizada en la introducción al elemento CONDITION de YoC, Son las condiciones intermedias las encargadas del trafico de tokens, y de la moderación del flujo del Modelo con respecto a las tareas que están por ejecutarse. ENDING CONDITION La condición de Finalización en una red, al igual que la condición inicial cuenta con características y comportamientos especiales, pero a diferencia de la condición inicial, esta.

(31) condición final controla la finalización de la ejecución del Modelo. Para esto la condición Final al igual que las demás, valida la llegada de tokens, y una vez todos los tokens de la red hayan llegado a esta condición, genera el evento AllTokensReceived, que permite a la red continuar con sus procesos de finalización. En particular la validación de tokens recibidos se realiza durante el bucle originado por el evento NotEnoughTokensReceived, en el cual la acción que se ejecuta para el caso de cada tipo de condición es diferente, generando así los diferentes comportamientos de cada tipo de condición. La acción que se toma en el caso de generación del evento en cuestión en una condición de finalización. Valida que no haya más tokens en curso en el Modelo en ejecución, de manera que se pueda asegurar que el Modelo finalice sin generar inconsistencias, si esta validación es realizada y en efecto no hay mas tokens por procesar en la red, esta acción lanza el evento AllTokensReceived para que continúe el flujo de la red y se puedan preparar los datos de salida del proceso. CONDITIONAL FLOW El flujo condicional tiene sentido en un modelo YoC, cuando debe modelarse un flujo que parte de un SPLIT hacia un o mas tareas. En esta caso cada uno de los flujos que salen del Split, son flujos condicionales. El elemento CONDITIONAL FLOW, no cuenta en el metamodelo con una maquina de estados que defina su comportamiento ya que este es demasiado simple como para modelarlo con estados, al ser únicamente un elemento intermedio entre un Split y su consiguiente condición para transportar el l los tokens generados en la validación de condiciones del SPLIT. El flujo condicional cuenta entonces son una fuente, un destino, una identificador y una descripción de la condición que lo origino, esto para que posteriormente pueda ser graficado y/o identificado correctamente en los ambientes de pruebas y ejecución de YoC. SIMPLE FLOW El flujo simple en el metamodelo YoC es aquel que al contrario del condicional, inicia en una tarea y finaliza en un elemento JOIN. Vatios flujos simples pueden terminar en un Join, si es que en el Modelo YoC definido está previsto que la ejecución de varias líneas del proceso termine en un Join que las reúna. Al igual que el flujo Condicional, su comportamiento es muy simple, y cuenta con los mismos cuatro elementos en su definición. Una fuente, un destino, un identificador, y una etiqueta de descripción, de manera que pueda ser identificado..

(32) Fig 20ª. Flujo Condicional en una representación grafica de un modelo YoC. Fig 20b. Flujo Simple en una representación grafica de un modelo YoC. JOIN El elemento JOIN, en el metamodelo YoC es el responsable de recibir los flujos entrantes a una tarea, de validar las condiciones de entrada, y dependiendo del tipo de JOIN, decidir si la tarea a la cual está asociado el JOIN puede iniciar o no.. Fig 21. Maquina de estados del elemento JOIN del metamodelo.

(33) El funcionamiento del JOIN en YoC, inicia cuando uno de los flujos simples que llegan al JOIN le indica que ha llegado un Token, y puede empezar a validar las condiciones. Este proceso se realiza en un ciclo en el cual se realiza la validación del cumplimiento de las condiciones de los flujos que llegan. Mientras estas condiciones no se cumplan el JOIN no continua con el inicio de la tarea a la que esta asociada. Una vez las condiciones entrantes al JOIN hayan sido validadas y se cumplan las condiciones para que la tarea pueda empezar a ejecutarse: ConditionsAccepted. Se ejecuta la acción InitTask, que le indica a la tarea que ya se encuentra lista para ejecutarse. En ese momento entra en juego la máquina de estados de la tarea, que puede iniciar o no dependiendo de si tiene o no tokens suficientes para su funcionamiento. Una vez la tarea sigue con su ejecución y termina. Esta envía un evento de finalización: Finished que permite que el JOIN regrese a su estado inicial de espera para continuar con el flujo del proceso. Para efectos de funcionalidad y practicidad, en YoC se implementaron únicamente las variantes XOR y OR del elemento JOIN, ya que la implementación de un elemento complejo como el OR JOIN, no ofrecía ningún valor agregado para lograr los objetivos propuestos en este trabajo de investigación. XOR JOIN El elemento XOR JOIN, funciona exactamente igual al JOIN básico descrito anteriormente. La única diferencia en su funcionamiento se remite a la validación de las condiciones de incio. En este caso en particular, el Join da resultados de validación afirmativa cuando llega un token únicamente por uno de los flujos que llegan al JOIN. AND JOIN A diferencia del XOR al AND JOIN da resultado de validación positivo cuando se cumplen todas las condiciones que lo preceden. es decir que llega token por TODOS los flujos simples que lo preceden. SPLIT El elemento SPLIT de YoC, tiene sentido estando asociado a una tarea de YoC, este elemento es el que permite el flujo posterior a la ejecución de una tarea y da pie a la toma de decisiones y a la bifurcación un uno o mas flujos condicionales. El SPLIT, inicia su funcionamiento esperando el evento de finalización de procesamiento de la tarea que lo asocias. Ejecutando en bucle la acción LookForTaskState, mientas se haya generado el evento propio TaskNotFinalized. Una vez la tarea lanza su evento Finalized, el Split toma la información de variables de la tarea para poder procesar las condiciones programadas en su funcionamiento. Una vez se validan las.

(34) condiciones el Split está listo para enviar el o los tokens (dependiendo de si es un AND o un XOR SPLIT ), a sus condiciones y/o tareas destino. Al igual que en el caso del JOIN y para guardar la consistencia, solo se han desarrollado en YoC los elementos XOR y AND SPLIT.. Fig 22. Maquina de estados del elemento SPLIT del metamodelo. XOR SPLIT El XOR Split como su nombre lo indica al momento de procesar las condiciones envía el token generado únicamente a uno de los flujos condicionales subsiguientes al SPLIT. De esta manera un XOR Split no genera la posibilidad de abrir flujos en el proceso, sino que mediante su ejecución re direcciona el flujo únicamente por un camino dependiendo de la validación de las condiciones programadas. AND SPLIT El AND Split por su parte, no tiene condiciones programadas dentro de sí, ya que este tipo de SPLIT genera un nuevo token para continuar la ejecución a través cada uno de los flujos que salen de él. En entonces en los elementos AND SPLIT, de un Modelo YoC, en el único lugar en que pueden generarse Nuevos Tokens, que permiten situaciones que requieren la sincronización de la ejecución de tareas descrita anteriormente y solucionada en YoC utilizando la cola de ejecución. Aunque en un lenguaje como YAWL la dimensión de control es generalmente la más importante, y generalmente la única implementada con detalle en diversos motores de Workflow. YAWL implementa las dimensiones de Recursos y Control dentro de su motor. De esta manera YoC.

(35) también identifica estas dos dimensiones desarrolladas en YAWL, y realiza la implementación de estas dos dimensiones dentro del motor. Estas dimensiones aunque menos complejas que la dimensión de control, cuentan con los elementos necesarios para manejar los recursos asignados a las tareas de un modelo YoC, y un temporizador simple para las tareas que lo requieran. 4.4. DIMENSION DE RECURSOS. La dimensión de recurso en YoC permite la creación y administración de recursos para una instancia particular de un modelo YoC, asignando a estos recursos roles, responsabilidades y permisos determinados antes de iniciar la ejecución del modelo o incluso durante su ejecución en el caso de la asignación de responsabilidades.. Fig 23. Metamodelo para la dimensión de Recursos de YoC. Como se muestra en la grafica numero 23 la dimensión de recursos presentada por YAWL e implementada en YoC es simple contemplando únicamente cuatro nuevos elementos al metamodelo: Resource, Rol, Faculty y Position. Las cuales serán descritas a continuación. RESOURCE:. Fig 24. Maquina de estados para elemente RESOURCE del Metamodelo.

(36) Al ser en la practica un recurso un elemento de características limitadas este dentro de su máquina de estados debe contemplar la posibilidad de que pueda ser solicitado por varias tareas caso en el cual se encontraría disponible nicamente para una de ellas. Esto es que aunque un recurso sea en el modelo responsable de varias tareas solo puede ejecutar una tarea a la vez. Por esta explicación surge la definición de la máquina de estados de la figura 24 en la cual un recurso empieza su ciclo de vida esperando a que la tarea a la cual a sido asignado inicie su procesamiento. Una vez el evento started de la tarea asignada al recurso a sido lanzado por la tarea, se inicia la acción asignar tarea recurso la cual cambia el estado del recurso a processingtask en este estado el recurso no puede ser asignado a ninguna otra tarea hasta que el evento finalized a sido lanzado por la tarea en proceso. ROL Al igual que otros elementos del metamodelo definidos en YoC el elemento rol no cuenta con una maquina de estados que defina su comportamiento, ya que no cuenta con un comportamiento especifico si no que agrega significado a los recursos del metamodelo. Como su nombre lo indica un rol corresponde a una definición del recurso basada en sus características principales, en el caso de YoC pueden crearse en el modelo tantos roles como se quiera para asignarlos indistintamente a los recursos. Los roles en YoC no solo etiquetan al recurso si no que le permiten a los recursos asignados al rol la ejecución de ciertas acciones en el modelo. FACULTY Las facultades de un recurso son precisamente heredadas del rol que este recurso tiene asignada, al igual que el rol las facultades no tienen comportamiento: más bien es a través de la validación de estas facultades que un recurso pueda o no ejecutar una tarea ala cual a sido asignada. Pr tanto si en el momento de la ejecución de la acción asignartareaareurso si la validación de las facultades es denegada el recurso no será asignado a la tarea y quedara libre para ser asignada a otra, dejando entonces la tarea disponible para que otro recurso le sea asignado. Además de las facultades de un recurso con respecto a la ejecución de tareas en el modelo existen también otro conjunto de facultades que posibilita o imposibilitan al recurso para realizar acciones sobre el modelo por ejemplo posibilidad de finalizar tareas que no están asignada a él, posibilidad de instanciar tareas que no le corresponde, posibilidad de abortar elementos del modelo en cualquier momento, posibilidad de creación de instancias del modelo, etc.. 4.5. DIMENSION DE TIEMPO. La dimensión de tiempo en YAWL es una propuesta simple a la solución del problema de tareas dependientes del tiempo en un motor de workflow, debido a esto YoC implementa esta dimensión simple en la cual únicamente un nuevo elemento es agregado al metamodelo, este elemento es un temporizador que puede o no estar asignado a una tarea y que controla su ejecución..

(37) Fig 25. Metamodelo de YoC para la dimensión de Tiempo. TTEMPORIZADOR El temporizador en YoC es un elemento simple, cuyo comportamiento se encuentra definido en la máquina de estados de la figura 26.. Fig 26. Maquina de estados para elemente TIMER del Metamodelo. Cuando una tarea que tiene un timer definido dentro de su comportamiento , existe un momento durante el procesamiento en el cual el timer requiere de su activación, esto es mediante el evento InitTimer lanzado por la tarea durante su procesamiento. Una vez el timer reconoce este evento inicia el proceso de conteo y lanza un evento de terminación una vez el tiempo programado en el timer haya transcurrido, este evento de terminación es el punto de partida para que la tarea en cuestión determine el procedimiento a seguir de acuerdo con el tipo de timer instanciado. 4.6. PRUEBAS. El proceso de pruebas de YoC, tuvo como objetivo demostrar que en efecto cualquier modelo YoC conforme al metamodelo definido en la sección 4.3 que fuera ejecutado sobre el Motor YoC definido sobre CUMBIA, tuviera el mismo comportamiento que un modelo YAWL ejecutado sobre el motor de YAWL para Workflow..