OPENET4WF: marco de conocimiento para el modelado de flujos de trabajo formalizados mediante redes de Petri
Full text
Universidade de Santiago de Compostela Departamento de Electrónica e Computación TESIS DOCTORAL OPENET4WF: MARCO DE CONOCIMIENTO PARA EL MODELADO DE FLUJOS DE TRABAJO FORMALIZADOS MEDIANTE REDES DE PETRI Presentada por: Juan Carlos Vidal Aguiar Dirigida por: Alberto J. Bugarín Diz Manuel Lama Penín Santiago de Compostela, Mayo de 2010
Dr. Alberto J. Bugarín Diz, Profesor Titular de Universidad del Área de Ciencia de la Computación e Inteligencia Artificial de la Universidade de Santiago de Compostela Dr. Manuel Lama Penín, Profesor Contratado Doctor del Área de Ciencia de la Computación e Inteligencia Artificial de la Universidade de Santiago de Compostela HACEN CONSTAR: Que la memoria titulada OPENET4WF: Marco de conocimiento para el modelado de flujos de trabajo formalizados mediante redes de Petri ha sido realizada por D. Juan Carlos Vidal Aguiar bajo nuestra dirección en el Departamento de Electrónica e Computación de la Universidade de Santiago de Compostela, y constituye la Tesis que presenta para optar al grado de Doctor. Santiago de Compostela, Mayo de 2010 Asdo: Alberto J. Bugarín Diz Codirector de la tesis Asdo: Manuel Lama Penín Codirector de la tesis Asdo: Javier Díaz Bruguera Director del Departamento de Electrónica y Computación Asdo: Juan Carlos Vidal Aguiar Autor de la Tesis
Para mi familia, por su apoyo, paciencia y amor durante este largo camino.
Agradecimientos Deseo expresar mi más sincero agradecimiento a todas las personas que, de alguna u otra forma, me han ayudado en la realización de este trabajo, y especialmente: A Alberto J. Bugarín Diz y Manuel Lama, codirectores de esta tesis doctoral, por la confianza y ayuda que me han brindado a lo largo de estos años, sin las cuales la presente investigación no hubiera sido posible. Al Departamento de Electrónica y Computación, y, principalmente, a los miembros del Grupo de Sistemas Inteligentes, por su apoyo y por los buenos ratos pasados. Recuerdo especialmente los buenos momentos que he pasado con mis compañeros de despacho Félix, Molina, Dinani, Daniel, Álvaro y Carlos. A Reza Sadigh Balay por su colaboración y por el apoyo brindado a la hora de conseguir resultados en el difícil dominio de la fabricación de muebles. A los amigos y compañeros que me han hecho especialmente agradable estos años de intenso trabajo. Y, por supuesto, a mi familia; sin ella nunca habría llegado hasta aquí. Para finalizar, me gustaría agradecer el apoyo económico recibido para desarrollar esta investigación. Agradezco el soporte económico recibido de la Universidad de Santiago de Compostela a través de los proyectos “Sistema experto para la elaboración y seguimiento de ofertas en la industria del mueble” (PGIDT01INN35E) y “Sistema de planificación dinámica de la carga de trabajo de la fabricación en la industria del mueble” (PGIDIT04DPI096E); a la Xunta de Galicia a través del proyecto “Mellora da calidade educativa universitaria a través do deseño e execución de unidades de aprendizaxe soportados por tecnoloxías da Web Semántica” (PGIDIT06SIN20601PR); al Ministerio de Industria, Turismo y Comercio a través de los proyectos “SUMA elearning multimodal y adaptativo” (TSI-020301-2008-9) y “FLEXO: Desarrollo de aprendizaje adaptativo y accesible en sistemas de código abierto” (TSI-020301-2008-19) dentro del plan AVANZA; y del Ministerio de Ciencia e Innovación a través del proyecto “Descubrimiento automático de reglas borrosas no convencionales” (TIN2008-0040). Mayo de 2010
El modo de dar una vez en el clavo es dar cien veces en la herradura. Miguel de Unamuno La victoria es del más perseverante. Napoleón Bonaparte
Índice de Figuras 1.1. Tipos de WFs en función del valor de negocio y repetitividad . . . . . . . . . . . 12 1.2. Tipos de WFs en función de la estructuración y enfoque . . . . . . . . . . . . . . 12 1.3. Bucle característico de los metamodelos de comunicación . . . . . . . . . . . . . 16 1.4. Dimensiones del metamodelo tradicional de definición de WFs . . . . . . . . . . 18 1.5. Ejemplo de clasificación de recursos por agrupaciones funcionales . . . . . . . . . 20 1.6. Ejemplo de clasificación de recursos por roles . . . . . . . . . . . . . . . . . . . . 20 1.7. Diagrama de inferencia CommonKADS de un problema de control de calidad . . 25 1.8. Arquitectura de CommonKADS . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.9. Arquitectura de UPML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.10. Interfaces de orquestación y coreografía de WSMO . . . . . . . . . . . . . . . . . 30 1.11. Arquitectura conceptual de WSMF . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.12. Concepto de servicio en OWL-S . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.13. Metamodelo para la representación semántica de WFs en el que se introduce una nueva dimensión para el modelado del conocimiento en dominios complejos . . . 33 2.1. Patrones básicos de control. Cada rectángulo representa una actividad, las elipses representan construcciones de control y los arcos dirigidos representan las dependencias entre los distintos elementos. . . . . . . . . . . . . . . . . . . . . . 40 2.2. Cuatro patrones avanzados de control . . . . . . . . . . . . . . . . . . . . . . . . 41 2.3. Ejemplo de un patrón para instanciación múltiple . . . . . . . . . . . . . . . . . 42 2.4. Patrones de control basados en el estado . . . . . . . . . . . . . . . . . . . . . . 43 2.5. Ejemplo de tres patrones de cancelación . . . . . . . . . . . . . . . . . . . . . . . 44 2.6. Patrones de terminación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.7. Patrones que modelan estructuras iterativas . . . . . . . . . . . . . . . . . . . . . 46 2.8. Patrones de control basado en eventos . . . . . . . . . . . . . . . . . . . . . . . . 46 2.9. Patrones de visibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.10. Patrón de interacción entre dos tareas . . . . . . . . . . . . . . . . . . . . . . . . 48 2.11. Ciclo de vida del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.12. Estados del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.13. Dos lenguajes de representación de WFs . . . . . . . . . . . . . . . . . . . . . . . 53 2.14. Efecto de la visualización a la hora de interpretar dos modelos . . . . . . . . . . 53 2.15. Ejemplo de marcado, activación y disparo de una transición donde los círculos representan a las plazas, los rectángulos a las transiciones y las marcas se representan mediante puntos negros dentro de las plazas . . . . . . . . . . . . . . 55 2.16. Ejemplo de red de Petri coloreada . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.17. El patrón mezcla simple no puede resolverse con una transición normal . . . . . 59 vii
viii Índice de Figuras 2.18. Solución al patrón mezcla simple utilizando arcos inhibidores . . . . . . . . . . . 59 2.19. Representación de un bucle de tipo ciclos arbitrarios en π-calculus . . . . . . . . 61 2.20. Elementos básicos del lenguaje BPMN . . . . . . . . . . . . . . . . . . . . . . . . 64 2.21. Ejemplo simplificado de compra de una entrada de cine representada mediante un diagrama BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 2.22. Elementos básicos de los diagramas de actividad del lenguaje UML . . . . . . . . 71 2.23. Ejemplo simplificado de compra de una entrada de cine representada mediante un diagrama UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2.24. Metamodelo de proceso de XPDL . . . . . . . . . . . . . . . . . . . . . . . . . . 74 2.25. Representación en XPDL de una separación . . . . . . . . . . . . . . . . . . . . . 75 2.26. Metamodelo de proceso de BPML . . . . . . . . . . . . . . . . . . . . . . . . . . 77 2.27. Elementos básicos de YAWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 2.28. Taxonomía de OWL-S para la descripción de procesos . . . . . . . . . . . . . . . 86 2.29. Ejemplo de integración entre el modelo de servicio y la capa de conocimiento de OWL-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 2.30. Orquestación y coreografía de WSMO . . . . . . . . . . . . . . . . . . . . . . . . 89 3.1. Principio de localidad y concurrencia de las acciones t1et2. . . . . . . . . . . . 97 3.2. Representación del ejemplo de fabricación mediante un grafo de PN . . . . . . . 97 3.3. Disparo de las transiciones t1yt2.......................... 98 3.4. PN coloreada del ejemplo de fabricación . . . . . . . . . . . . . . . . . . . . . . . 99 3.5. Arcos anotados mediante multiconjuntos . . . . . . . . . . . . . . . . . . . . . . 99 3.6. Las transicións t1yt2se funden en la transición t1,2. . . . . . . . . . . . . . . . 100 3.7. Términos anotan arcos y transiciones . . . . . . . . . . . . . . . . . . . . . . . . 100 3.8. Ejemplo de sustitución (izquierda) y de fusión (derecha) . . . . . . . . . . . . . . 102 3.9. Ejemplo de red aplanada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.10. Definición del concepto nodo en las especificaciones RELAX NG de PNML y FLORA-2 de la ontología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.11. Definición de PN incorrecta a través de PNML . . . . . . . . . . . . . . . . . . . 107 3.12. Red semántica del modelo estático de la ontología de HLPNs . . . . . . . . . . . 110 3.13. PN que representa el estado inicial de una máquina de ensamblaje . . . . . . . . 113 3.14. Estado de la máquina de ensamblaje tras el disparo de la transición t1,2. . . . . 113 3.15. Red semántica del modelo de situación de las HLPNs . . . . . . . . . . . . . . . 123 3.16. Red semántica del modelo de ejecución de las HLPNs . . . . . . . . . . . . . . . 124 3.17. Red semántica de la ontología de redes de Petri jerárquicas . . . . . . . . . . . . 137 3.18. Ejemplo de fusión de plazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 3.19. Refinamiento del proceso de preparación de las piezas para el procesado . . . . . 142 3.20. Red semántica del morfismo que se define entre la red jerárquica compuesta de múltiples páginas y su la correspondiente red aplanada . . . . . . . . . . . . . . 144 3.21. PN de alto nivel aplanada resultante del mecanismo de sustitución representado en la Figura 3.19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 3.22. Ejemplo de HLPN inicialmente creada para estimar el coste de fabricación de un mueble pero que se puede reutilizar en el dominio de la fabricación de piensos compuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 3.23. Los agentes pueden compartir la información dinámica generada durante la ejecución de una HLPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 4.1. Marco de conocimiento para la descripción de WFs . . . . . . . . . . . . . . . . . 156 4.2. El papel de las ontologías en la arquitectura del metamodelo . . . . . . . . . . . 158 4.3. Ejemplo de una ontología de materiales . . . . . . . . . . . . . . . . . . . . . . . 159
Índice de Figuras ix 4.4. Pila de ontologías que describen la semántica del metamodelo . . . . . . . . . . . 161 4.5. Relación entre los componentes de conocimiento y las dimensiones de los WFs . 165 4.6. Taxonomía de tarea genérica definida por Chandrasekaran [59] . . . . . . . . . . 166 4.7. Niveles de abstracción que intervienen en la definición de un WF . . . . . . . . . 167 4.8. Taxonomía de tipos de problemas definida por la metodología KADS-1 [1, 228] . 168 4.9. Ejemplo de tarea de asignación de recursos . . . . . . . . . . . . . . . . . . . . . 170 4.10. Ejemplo de método compuesto para la asignación de recursos . . . . . . . . . . . 172 4.11. Ejemplo de método primitivo de selección . . . . . . . . . . . . . . . . . . . . . . 174 4.12. Ejemplo de diseño paramétrico usando HLPNs . . . . . . . . . . . . . . . . . . . 175 4.13. Ejemplo de modelo de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 4.14. Representación gráfica del modelo de control de las figuras 4.13 y 4.15 . . . . . . 177 4.15. Descripción parcial de algunas páginas del modelo de control de la Figura 4.13 . 178 4.16. Ejemplo de modelo del dominio de fabricación en la industria del mueble . . . . 180 4.17. Red semántica de la ontología de organización TOVE . . . . . . . . . . . . . . . 183 4.18. Ejemplo de modelo de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 4.19. Ejemplo de puente entre una tarea y un modelo del dominio . . . . . . . . . . . 186 4.20. Para establecer las correspondencias entre los conceptos Plan yAgenda de las taxonomías de la tarea y del dominio respectivamente, es necesario además definir la axiomática que permita unificar los distintos modos de establecer la duración de un programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 4.21. Ejemplo de puente entre una tarea y un método . . . . . . . . . . . . . . . . . . 188 4.22. Ejemplo de puente entre un método y un modelo de control . . . . . . . . . . . . 190 4.23. Parte de la descripción operacional del método descrito en la Figura 4.10 . . . . 191 4.24. Ejemplo de puente entre un método y un modelo de recursos . . . . . . . . . . . 192 4.25. Ejemplo de puente entre un modelo del dominio y un modelo de control . . . . . 193 4.26. Ejemplo de puente entre un modelo del dominio y un modelo de recursos . . . . 194 4.27. Ejemplo de refinador que especializa el método compuesto representado en la Figura 4.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 4.28. Ejemplo de puesta en común de un modelo de control para así aprovechar mejor la capacidad de reutilización de los refinadores . . . . . . . . . . . . . . . . . . . 198 5.1. Pila de ontologías que da soporte a la representación del modelo de control . . . 204 5.2. Patrón utilizado para la representación de un proceso . . . . . . . . . . . . . . . 208 5.3. Ejemplo de aplicación del patrón proceso ......................213 5.4. Red semántica de la taxonomía de patrones de flujos de trabajo . . . . . . . . . 214 5.5. Representación del patrón secuencia . . . . . . . . . . . . . . . . . . . . . . . . . 215 5.6. Bloques de control del patrón secuencia . . . . . . . . . . . . . . . . . . . . . . . 215 5.7. Representación del patrón separación . . . . . . . . . . . . . . . . . . . . . . . . 218 5.8. Representación del patrón sincronización . . . . . . . . . . . . . . . . . . . . . . 218 5.9. Separación y unión de dos hilos de ejecución . . . . . . . . . . . . . . . . . . . . 219 5.10. Bloques de control del patrón separación-unión . . . . . . . . . . . . . . . . . . . 220 5.11. Representación del patrón elección . . . . . . . . . . . . . . . . . . . . . . . . . . 221 5.12. Bloques de control del patrón elección . . . . . . . . . . . . . . . . . . . . . . . . 221 5.13. Representación de una mezcla simple de dos ramas . . . . . . . . . . . . . . . . . 222 5.14. Representación del patrón elección exclusiva-mezcla simpe para dos ramas . . . 224 5.15. Representación de la elección múltiple de dos ramas . . . . . . . . . . . . . . . . 225 5.16. Representación del patrón mezcla . . . . . . . . . . . . . . . . . . . . . . . . . . 226 5.17. Bloques de control del patrón mezcla . . . . . . . . . . . . . . . . . . . . . . . . 226 5.18. Representación de la elección múltiple-mezcla múltiple de dos ramas . . . . . . . 227 5.19. Representación del patrón repetir-mientras . . . . . . . . . . . . . . . . . . . . . 228
x Índice de Figuras 5.20. Bloques de control del patrón repetir-mientras . . . . . . . . . . . . . . . . . . . 228 5.21. Representación del patrón repetir-hasta . . . . . . . . . . . . . . . . . . . . . . . 230 5.22. Bloques de control del patrón repetir-hasta . . . . . . . . . . . . . . . . . . . . . 230 5.23. Sustitución de la transición scheduling por un patrón repetir-mientras . . . . . . 232 5.24. Ejemplo de sustitución de construcciones de control . . . . . . . . . . . . . . . . 234 5.25. Ejemplo de red para el control del flujo de datos . . . . . . . . . . . . . . . . . . 235 5.26. Ejemplo de red para el control del flujo de datos teniendo en cuenta el principio de localidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 5.27. Ejemplo del problema de lectura sucia en una red que controla el flujo de datos . 236 5.28. Ejemplo de red que representa un flujo de control . . . . . . . . . . . . . . . . . 236 5.29. Ejemplo de combinación de una red de datos y otra de control . . . . . . . . . . 237 5.30. Ejemplo de la segunda aproximación para el modelado de WFs . . . . . . . . . . 238 5.31. Ejemplo de un término que representa la llamada un operador . . . . . . . . . . 241 6.1. Arquitectura de la infraestructura tecnológica para la ejecución de WFs . . . . . 244 6.2. Ejemplo de diagrama de descomposición de tareas . . . . . . . . . . . . . . . . . 247 6.3. Integración del control dentro del diagrama de descomposición de tareas . . . . . 248 6.4. HLPNs del modelo de control del método 1 . . . . . . . . . . . . . . . . . . . . . 249 6.5. Creación de la estructura jerárquica del modelo de ejecución . . . . . . . . . . . 250 6.6. Precondiciones de un método primitivo en el álgebra del modelo de ejecución . . 251 6.7. Las transiciones que se resuelven mediante un método primitivo añadirán la precondición del recurso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 6.8. Correspondencias entre los componentes de conocimiento y el álgebra de la red . 253 6.9. Los tres niveles de la anotación algebraica . . . . . . . . . . . . . . . . . . . . . . 255 6.10. Modelo de publicación/suscripción del repartidor (broker) de mensajes . . . . . . 257 6.11. Adaptador para la integración de servicios web . . . . . . . . . . . . . . . . . . . 258 6.12. Adaptador para la integración de sistemas legados a través de CORBA . . . . . 259 6.13. Arquitectura del motor OPENET . . . . . . . . . . . . . . . . . . . . . . . . . . 260 6.14. Ejemplo de ejecución de un multiconjunto de modos de transición . . . . . . . . 261 6.15. Un arco debe conectar a nodos de distinto tipo . . . . . . . . . . . . . . . . . . . 262 6.16. Arquitectura del motor de flujos de trabajo . . . . . . . . . . . . . . . . . . . . . 265 6.17. Regla para la transformación de una red jerárquica en una red plana . . . . . . . 266 6.18. Regla para la unión de un conjunto de redes en una única red jerárquica . . . . 268 6.19. Regla para la creación de un patrón proceso (I) . . . . . . . . . . . . . . . . . . . 269 7.1. Ciclo de vida para la tarea de presupuestado de muebles . . . . . . . . . . . . . 276 7.2. Algunas de las uniones de madera más utilizadas . . . . . . . . . . . . . . . . . . 277 7.3. Descomposición en tareas del método que resuelve la tarea de presupuestado de muebles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 7.4. Flujo de trabajo del método encargado de seleccionar la base de reglas de estimación de tiempos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 7.5. Descomposición en tareas del método que resuelve la tarea encargada de crear la descripción del pedido a presupuestar . . . . . . . . . . . . . . . . . . . . . . . 286 7.6. Descomposición en tareas del método que resuelve la tarea encargada del diseño del producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 7.7. Flujo de trabajo para el cálculo del coste de materiales . . . . . . . . . . . . . . 288 7.8. Flujo de trabajo para el cálculo del coste de producción . . . . . . . . . . . . . . 289 7.9. Flujo de trabajo para la generación del plan de trabajo . . . . . . . . . . . . . . 290 7.10. Flujo de trabajo para establecer el plan de trabajo . . . . . . . . . . . . . . . . . 292 7.11. Arquitectura software de SEEPIM . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Índice de Figuras xi 7.12. Captura de la pantalla de modificación de una especificación de pedido . . . . . 294 7.13. Captura de la pantalla del resumen de un presupuesto . . . . . . . . . . . . . . . 297 7.14. Arquitectura del sistema de planificación . . . . . . . . . . . . . . . . . . . . . . 298 7.15. Captura de la pantalla de la carga de trabajo asociada a un pedido a través de un diagrama Gantt desde la interfaz web del sistema y exportada a Microsoft Project TM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 7.16. Esquema del sistema con la incorporación de los sistemas de planificación y aprendizaje al ciclo productivo de la empresa . . . . . . . . . . . . . . . . . . . . 301 8.1. El concepto de unidades de estudio en el EML de la OUNL [156] . . . . . . . . . 309 8.2. Diagrama de actividades del escenario real de aprendizaje en astronomía . . . . 311 8.3. Estructura genérica que se encargará del control de la ejecución de los método docentes, representaciones, actos y actividades de las unidades de aprendizaje . . 317 8.4. Elementos que participan en la suspensión de un método docente . . . . . . . . . 319 8.5. Flujo de trabajo que controla la ejecución de un conjunto de representaciones . . 321 8.6. Flujo de trabajo que controla la ejecución de una secuencia de actos . . . . . . . 322 8.7. Flujo de trabajo que controla la ejecución de las entidades de ejecución . . . . . 324 8.8. Flujo de trabajo que controla la ejecución de una actividad simple . . . . . . . . 325 8.9. Flujo de trabajo que controla la ejecución de una secuencia de entidades de ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 8.10. Flujo de trabajo que controla la selección de entidades de ejecución . . . . . . . 327 8.11. Arquitectura orientada a servicios que externaliza las capacidades del motor de IMS LD nivel B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 8.12. Arquitectura del motor de unidades de aprendizaje IMS LD nivel B . . . . . . . 330 9.1. Integración de los servicios OWL-S dentro del marco de conocimiento . . . . . . 336 9.2. Patrón utilizado para la representación de un proceso en OWL-S . . . . . . . . . 339 9.3. Ejemplo de aplicación del patrón proceso para un proceso de autenticación de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 9.4. Red de Petri que define las salidas y efectos de un proceso en función del contexto de ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 9.5. Ejemplo de aplicación del patrón resultado para un proceso de autenticación de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 9.6. Representación del patrón separación . . . . . . . . . . . . . . . . . . . . . . . . 345 9.7. Bloques de control del patrón separación . . . . . . . . . . . . . . . . . . . . . . 345 9.8. Representación del patrón elección . . . . . . . . . . . . . . . . . . . . . . . . . . 347 9.9. Bloques de control del patrón elección . . . . . . . . . . . . . . . . . . . . . . . . 347 9.10. Ejecución sin un orden predeterminado de dos procesos . . . . . . . . . . . . . . 349 9.11. Bloques de control del patrón sin-orden . . . . . . . . . . . . . . . . . . . . . . . 349 9.12. Representación del patrón if-then-else . . . . . . . . . . . . . . . . . . . . . . . . 352 9.13. Bloques de control del patrón if-then-else . . . . . . . . . . . . . . . . . . . . . . 352 9.14. Pantallazo de la herramienta WoPeD utilizado para la verificación de las estructuras de control de los patrones proceso yrepetir-mientras . . . . . . . . . . . . . 357 9.15. Arquitectura del motor de coreografías OWL-S . . . . . . . . . . . . . . . . . . . 360 9.16. Definición de un servicio de autenticación en OWL-S . . . . . . . . . . . . . . . . 361 A.1. Diseño conceptual a partir del cual se deducen las partes del mueble y los procesos de fabricación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 A.2. Máquina lijadora calibradora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 A.3. Gramática libre de contexto identificar los individuos válidos . . . . . . . . . . . 381
xii Índice de Figuras A.4. Típica regla para la estimación de tiempos de procesado . . . . . . . . . . . . . . 381 A.5. Algoritmo evolutivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 A.6. Ejemplo de cromosoma para el aprendizaje de tiempos de fabricación . . . . . . 383 A.7. Ejemplo de cruce de dos cromosomas . . . . . . . . . . . . . . . . . . . . . . . . 385 A.8. Típica base de reglas para la máquina ACM . . . . . . . . . . . . . . . . . . . . 390 B.1. Diagrama Gantt de un plan de trabajo. El símbolo Oi,j representa la operación jdel trabajo Ji. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 B.2. Diagram de Venn para los diferentes tipos de planes de trabajo . . . . . . . . . . 395 B.3. Diseño de una mesa de oficina . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 B.4. Representación en forma de red de Petri del método primitivo que resuelve el problema de planificación JSSP con máquinas dedicadas . . . . . . . . . . . . . . 401 B.5. Cálculo de la incertidumbre de una operación . . . . . . . . . . . . . . . . . . . . 402 B.6. Estructura del algoritmo NSGA-II [85] . . . . . . . . . . . . . . . . . . . . . . . . 404 B.7. Codificación de trabajo en paralelo de un ejemplo de planificación 4×4 (Primera parte del cromosoma) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 B.8. Codificación de las reglas de asignación para el ejemplo de planificación 4 ×4 (Segunda parte del cromosoma) . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 B.9. Fechas límite, ordenación de las operaciones y tiempos de procesado . . . . . . . 406 B.10. Método Giffer-Thompson modificado que se emplea para la generación del plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 B.11. Ejemplo de algunos pasos de la ejecución del método modificado de GifferThompson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 B.12. Cruce de filas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 B.13. Cruce de columnas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 B.14. Frente Pareto final del NSGA-II y del SPEA-II para el problema la24 . . . . . . 414
Índice de Tablas 1.1. Ventajas y desventajas de las distintas aproximaciones para el modelado de WFs 35 2.1. Posibles interpretaciones de plazas y transiciones en redes de Petri . . . . . . . . 55 2.2. Expresividad de los lenguajes de representación y ejecución de WFs (I) . . . . . 66 2.3. Expresividad de los lenguajes de representación y ejecución de WFs (II) . . . . . 67 2.4. Patrones de datos soportados por los lenguajes de representación y ejecución de WFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 2.5. Patrones de organización soportados por los lenguajes de representación y ejecución de WFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.1. Axiomas que restringen a la estructura del grafo. . . . . . . . . . . . . . . . . . 114 3.2. Axiomas asociados a la firma sintáctica. . . . . . . . . . . . . . . . . . . . . . . 117 3.3. Axiomas que restringen a la anotación del grafo . . . . . . . . . . . . . . . . . . 119 3.4. Axiomas que restringen al álgebra de una HLPN . . . . . . . . . . . . . . . . . . 122 3.5. Axiomas que restringen al estado de la red . . . . . . . . . . . . . . . . . . . . . 123 3.6. Axiomas que restringen a la ejecución de la red . . . . . . . . . . . . . . . . . . . 128 3.7. Correspondencias entre atributos del PNML y la ontología de HLPNs . . . . . . 134 3.8. Axiomas que restringen las fusiones de nodos . . . . . . . . . . . . . . . . . . . . 140 3.9. Axiomas que restringen a las sustituciones de nodos . . . . . . . . . . . . . . . . 143 3.10. Axiomas que restringen el morfismo entre redes (I) . . . . . . . . . . . . . . . . . 147 3.11. Axiomas que restringen el morfismo entre redes (II) . . . . . . . . . . . . . . . . 148 3.12. Capacidades de representación de las distintas ontologías de HLPNs . . . . . . . 151 4.1. Ventajas y desventajas de UPML y OPENET4WF para el modelado de WFs . . 201 5.1. Axiomas que restringen la semántica del patrón proceso . . . . . . . . . . . . . . 210 5.2. Axiomas que restringen la estructura de una rama de control . . . . . . . . . . . 216 5.3. Axiomas que restringen la semántica del patrón secuencia . . . . . . . . . . . . . 216 5.4. Axiomas que restringen la semántica del patrón separación . . . . . . . . . . . . 217 5.5. Axiomas que restringen la semántica del patrón sincronización . . . . . . . . . . 219 5.6. Axiomas que restringen la semántica del patrón separación-unión . . . . . . . . 220 5.7. Axiomas que restringen la semántica del patrón elección . . . . . . . . . . . . . . 222 5.8. Axiomas que restringen la semántica del patrón mezcla simple . . . . . . . . . . 222 5.9. Axiomas que restringen la semántica de la elección exclusiva-mezcla simple . . . 223 5.10. Patrones de control avanzado soportados por los principales WMS comerciales . 224 5.11. Axiomas que restringen el patrón elección múltiple . . . . . . . . . . . . . . . . . 225 xiii
xiv Índice de Tablas 5.12. Axiomas que restringen la semántica del patrón mezcla múltiple . . . . . . . . . 226 5.13. Axiomas que restringen el patrón elección múltiple-mezcla múltiple . . . . . . . . 227 5.14. Axiomas que restringen la semántica del patrón repetir-mientras . . . . . . . . . 229 5.15. Axiomas que restringen la semántica del patrón repetir-hasta . . . . . . . . . . . 231 5.16. Axiomas que restringen la semántica del concepto ExecuteSubstitution . . . . 233 5.17. Axiomas que restringen la semántica del concepto ControlSubstitution . . . . 233 7.1. Variables a tener en cuenta en un proceso de fabricación . . . . . . . . . . . . . . 278 7.2. Variables que intervienen en la elección de un proveedor . . . . . . . . . . . . . . 278 7.3. Error medio en la estimación de tiempo por centro de coste . . . . . . . . . . . . 302 9.1. Axiomas que restringen la semántica del patrón resultado . . . . . . . . . . . . . 342 9.2. Axiomas que restringen la secuencia . . . . . . . . . . . . . . . . . . . . . . . . . 345 9.3. Axiomas que restringen la separación . . . . . . . . . . . . . . . . . . . . . . . . 346 9.4. Axiomas que restringen la elección ..........................348 9.5. Axiomas que restringen la separación-unión . . . . . . . . . . . . . . . . . . . . . 348 9.6. Axiomas que restringen las ramas concurrentes del patrón sin-orden . . . . . . . 350 9.7. Axiomas que restringen el patrón sin-orden . . . . . . . . . . . . . . . . . . . . . 351 9.8. Axiomas para la integración de la separación y sincronización con cada una de las ramas concurrentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 9.9. Axiomas que restringen la rama si del patrón si-entonces-sino . . . . . . . . . . 353 9.10. Axiomas que restringen al patrón repetir-mientras . . . . . . . . . . . . . . . . . 354 9.11. Axiomas que restringen al patrón repetir-hasta . . . . . . . . . . . . . . . . . . . 354 9.12. Verificación de las propiedades de OWL-S (I) . . . . . . . . . . . . . . . . . . . . 358 9.13. Verificación de las propiedades de OWL-S (II) . . . . . . . . . . . . . . . . . . . 359 A.1. Error medio por centro de coste . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 A.2. Error medio por máquina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 A.3. Características de los conjuntos de datos . . . . . . . . . . . . . . . . . . . . . . 387 A.4. Resultados de la validación cruzada para las distintas máquinas . . . . . . . . . 389 B.1. Reglas de asignación de operaciones . . . . . . . . . . . . . . . . . . . . . . . . . 406 B.2. Resumen de los resultados obtenidos para los métodos multi-objetivo . . . . . . 412 B.3. Comparación entre el NSGA-II y los demás métodos . . . . . . . . . . . . . . . . 413 C.1. Correspondencias entre OWL y FLORA-2 . . . . . . . . . . . . . . . . . . . . . . 417
Prefacio El uso de flujos de trabajo (WF, del ingés Workflow) es una constante en el quehacer cotidiano de cualquier empresa o administración y constituye un pilar fundamental en la organización del trabajo. Ya sea de manera implícita o explícita, los WFs están presentes en la mayoría de los procedimientos a los que diariamente estamos sometidos (por ejemplo, la reserva de un viaje, un parte por un incidente de tráfico, o la solicitud de un préstamo bancario). Es más, desde la perspectiva de un trabajador, varias de las tareas que realizamos a lo largo del día son parte de algún WF (por ejemplo, solicitar una ayuda para una conferencia, registrar la venta de un producto, o realizar el control de calidad de una pieza recién fabricada). Claro está que muchos de los WFs no están implementados y monitorizados a través de un sistema de gestión de WFs y en la actualidad muchos siguen siendo manuales. Sin embargo, no hay duda de que disponer de algún tipo de sistema con tecnología de WFs proporciona un conjunto de herramientas que facilitan notablemente la adaptación y mejora de nuestros procesos de negocio. De los ejemplos anteriores se pueden intuir dos elementos diferenciados. Por una parte, la funcionalidad que aborda el WF y la coordinación de sus actividades, y por la otra, los agentes que participan en su ejecución y los criterios de asignación del trabajo. Otra característica muy importante, que suele pasar desapercibida, es la presencia de conocimiento, y con ello no nos referimos exclusivamente al conocimiento implícito en el WF (por ejemplo, la tarea de planificación no finaliza correctamente si no se asignan todos los procesos de fabricación a algún recursos) sino también a aquél que se utiliza para resolver una actividad en un determinado dominio de aplicación (por ejemplo, para el cálculo del tiempo de fabricación del seccionado se asume que siempre existen dos operadores de planta libres). En la mayoría de los sistemas comerciales, este último tipo de conocimiento no se aplica, ya que consideran que los WFs tienen un alto nivel de granularidad y, por lo tanto, las actividades manejan su propio conocimiento. Sin embargo, cada vez son más frecuentes los WFs en los que distintas aplicaciones intercambian información. Para esos casos es necesario representar, al menos en parte, ese conocimiento para controlar su ejecución [314]. En lo que se refiere a este último punto, las soluciones existentes en la bibliografía son también divergentes tanto en lo que se refiere a la granularidad en la que se representan los datos [314] (por ejemplo, si se describen a nivel de documentos, objetos o simplemente parámetros) como a su visibilidad,
81. Modelado de flujos de trabajo La automatización, completa o en parte, de un proceso de negocio durante la cual se define la secuencia de acciones, actividades o tareas utilizadas para la ejecución del proceso, incluyendo el conjunto de información intercambiada entre sus participantes. De manera más informal, un WF indica aquello que va a suceder en el proceso de negocio y quiénes van a realizarlo. Su objetivo es, por lo tanto, garantizar que el trabajo se realice en el momento indicado y por el participante o recurso más adecuado. Para conseguir este objetivo, los WFs aproximan la construcción de procesos de negocio desde una perspectiva que busca pasar: De la programación a la composición. De la orientación a datos a la orientación a procesos. Del diseño al rediseño. Este cambio de perspectiva también propicia un cambio en la terminología usada durante la definición de los procesos de negocio. Tradicionalmente se habla de entidades, objetos, funciones, tablas, etc. En cambio, con los WFs se habla de procesos, tareas, recursos, roles, unidades organizativas, reglas, etc. 1.1.1. Distintos modelos para distintos propósitos La esencia de un WF es modelar un proceso de negocio para así determinar un orden en el trabajo a realizar, las responsabilidades del personal, la interacción entre los recursos, el intercambio de información, etc. Por ello, el objetivo del modelado de WFs es incorporar todos los aspectos relevantes del proceso al tiempo que se descartan otros irrelevantes. Sin embargo, el resultado del modelado dependerá en gran medida del propósito u objetivo del WF. Aunque la mayoría de los WFs se usan con el propósito de controlar la ejecución de un conjunto de tareas, existen muchas otras razones por las cuales se puede querer crear un WF [209]. Destacan las relacionadas con la comunicación (difusión y documentación), la puesta en práctica (simulación, análisis y ejecución) y la organización. Es fácil imaginar que modelos de WFs que sirven para diferentes propósitos variarán tanto en los contenidos como en el detalle. Por ejemplo, un modelo de WF para el desarrollo de sistemas estará enfocado hacia la descripción de las tareas. Lo mismo sucede con los modelos usados para documentar cada uno de los pasos de la ejecución. En ellos cada paso define un conjunto de instrucciones que los recursos podrán consultar durante la ejecución del proceso de negocio. En cambio, un modelo de ejecución detallará tanto las tareas como el control sobre las mismas. Si el modelo se usa para la simulación deberá además incorporar la interacción con el cliente.
1.1. La ambigua noción llamada “flujo de trabajo” 9 1.1.2. Caracterización de los flujos de trabajo La caracterización de los WFs es también objeto de un gran debate. En función de la acepción o significado atribuido al término WF, se pueden encontrar en la bibliografía distintas opiniones acerca de cuáles son las características más relevantes, cómo llamarlas, qué comprende cada una de ellas o cómo cuantificar una determinada característica. En este apartado se describirán las cinco características más aceptadas por la comunidad investigadora de WFs [147]: funcionalidad, comportamiento, información, operacionalidad yorganización. Sin embargo, existen clasificaciones alternativas donde la aproximación da más importancia a otros aspectos. Por ejemplo, en [226] se añade la perspectiva temporal para fijar las restricciones temporales ligadas a la ejecución de las actividades del WF. En este trabajo también se clasifican los WFs en función de sus características transaccionales. Este concepto también es recogido por otras clasificaciones [164, 30] para tratar las características transaccionales, que dependiendo de si los WFs son internos a una organización o entre distintas organizaciones pueden tener una solución diferente. Respecto a los WFs entre distintas organizaciones, en [30] también se añade como característica la interacción para reflejar las interdependencias entre los recursos y actividades de distintas organizaciones. En [164], los WFs se caracterizan por su control, datos, modelo de organización y transaccionalidad, pero también por su granularidad ygestión de excepciones. Además, el modelo de la organización está partido de forma que también se identifican como características principales a los papeles (roles) que los usuarios pueden tomar así como a los compromisos (commitments, en inglés) que pueden alcanzar. Finalmente, en [210] se considera que la clasificación propuesta en [147] es a demasiado bajo nivel por lo que se propone analizar las características de los WFs en función del caso que tratan, sus mecanismos de enrutamiento, su asignación de recursos y sus características de ejecución. 1.1.2.1. Funcionalidad La perspectiva funcional responde a la cuestión “qué hace el WF” y suele incluir la descripción del objetivo del WF, sus datos de entrada y de salida, restricciones funcionales, así como la descomposición del WF en unidades de trabajo más pequeñas, que a su vez pueden ser actividades atómicas u otro (sub)WF. 1.1.2.2. Comportamiento La perspectiva de comportamiento, también llamada perspectiva de proceso, responde a la cuestión “cómo funciona el WF” y se refiere al flujo de control entre las actividades del WF. Esta especificación es una parte esencial de un WF, ya que indica cómo coordinar las actividades mediante una serie de primitivas de control. Aunque estas primitivas varían de un sistema a otro, existe un conjunto básico que cualquier sistema debería soportar, en el que se incluye la secuencia, separación, sincronización, y ejecución condicional. En el capítulo 2 se describirán con más detalle las principales primitivas de control existentes en el campo de los WFs.
10 1. Modelado de flujos de trabajo 1.1.2.3. Tratamiento de la información La perspectiva de la información contiene las estructuras de datos y el flujo de datos entre actividades. Su objetivo consiste en proporcionar el dato correcto en el tiempo indicado. Se pueden distinguir dos tipos de datos: Datos de producción. Son datos relevantes del proceso de negocio que el sistema utiliza para determinar las transiciones de una instancia de WF. Por ejemplo, datos usados dentro de las prey postcondiciones de las actividades o para realizar la asignación de trabajo. Datos de control. Son datos relevantes para gestionar el comportamiento del WF, pero que no tienen significado a nivel del proceso de negocio. Por ejemplo, los datos relativos a una instancia de WF. Los WMSs especifican sus datos a través de parámetros, variables y el propio flujo de datos. Los parámetros se utilizan para pasar datos entre las actividades, y de acuerdo con [147], pueden ser sólo de lectura, sólo de escritura o de lectura/escritura. Además tienen asociado un ámbito de aplicabilidad, como por ejemplo una actividad o todo el WF. Al contrario que los parámetros, las variables son globales a todo el WF, es decir, si un usuario crea una variable entonces será accesible desde cualquier parte del WF. Finalmente, el flujo de datos relaciona los datos con las actividades indicando a qué parámetros y variables se acceden y desde qué actividad. 1.1.2.4. Operacionalidad La operacionalidad responde a la pregunta “cómo están implementadas las actividades”. Sin embargo, la implementación de las operaciones del WF es transparente y está desacoplada del motor de WFs, ya que estará a cargo de aplicaciones (externas) que se integran dentro de los WMSs. Por ello, desde el punto de vista del diseñador la operacionalidad puede verse como una simple interfaz cuyos detalles de implementación carecen de importancia para el usuario. En cualquier caso, incluso prescindiendo de esos detalles, es necesario saber qué parámetros de entrada proporcionar, los parámetros a devolver, el modo de invocación, los códigos de error o incluso los detalles de la configuración de la aplicación externa a invocar. 1.1.2.5. Organización La perspectiva de organización responde a la pregunta “quién está a cargo de realizar el trabajo” en un WF, es decir, permite definir las restricciones que dirigirán la selección del recurso más indicado para realizar cada una de las actividades del WF. Tanto en la bibliografía como en los WMSs existen enfoques diametralmente opuestos acerca de los aspectos que debería cubrir esta perspectiva. Mientras algunos sistemas y publicaciones ignoran completamente la organización, otros discuten en detalle los requerimientos de este componente. Por ejemplo, este aspecto es muy poco
1.1. La ambigua noción llamada “flujo de trabajo” 11 relevante en los lenguajes de composición de servicios [213, 174] o en estándares de ejecución de WFs como BPEL [15] donde ni siquiera se trata. El problema radica en si se considera el aspecto organizativo como un elemento con entidad suficiente para ser modelado dentro del WF. Así, mientras algunos consideran que es un elemento imprescindible, aportando construcciones y desarrollando políticas de asignación de recursos [313, 255], otros proveen un soporte mínimo o incluso no llegan a definirlo [293]. Como se señala en [202], se suele describir la organización en base a tres aspectos: Estructura organizativa. Define los objetos de la institución, así como las relaciones entre esos objetos [147]. Por lo tanto, este aspecto es el encargado de especificar objetos como ’usuario’, ’rol’, ’grupo’, ’departamento’, división’, ’permiso’, etc. y relaciones del tipo ’supervisa’, ’pertenece a’, ’juega el papel’ o ’forma parte de’. Se trata pues de representar el esquema organizativo, así como la política de control y autorización de la institución. Gestión de la asignación de trabajo. Define la asignación del trabajo a los recursos y la forma de evaluar dicha asignación. De forma genérica se suele asignar un determinado trabajo a un conjunto dado de agentes, para lo cual existen muchos criterios de asignación. Los más aplicados son los basados en el rol que juega el agente dentro de la organización o en la división/departamento a la que pertenece, en las responsabilidades del agente, en sus habilidades, etc. El proceso de asignación en sí también puede variar. La mayoría de los WMSs asignan los recursos en tiempo de ejecución [224]. Sin embargo, algunos sistemas prefieren calcular la asignación en tiempo de diseño, con el consiguiente problema de tener que recompilar el WF para dar de alta nuevos agentes [224]. Otros utilizan una estrategia diferida [224], de forma que los recursos se calculan al iniciarse el WF. Sincronización de la asignación de trabajo. Define criterios de colaboración cuando el trabajo requiere o puede ser asignado a más de un recurso. En la mayoría de los WFs no es necesario indicar este aspecto. Sin embargo, en algunos contextos específicos puede resultar imprescindible. Por ejemplo, en [30] se enfatiza la necesidad de mecanismos de sincronización cuando la asignación de trabajo se realiza en WFs entre distintas organizaciones, y propone emplear dos estados de asignación adicionales denominados ’delegado’ y ’reenviado’ que se emplean en identificar qué trabajos han sido asignados a un socio externo y así no duplicar el trabajo. 1.1.3. Clasificación de los flujos de trabajo El esquema de clasificación más aceptado en la comunidad de WFs [255] categoriza los WFs en función de su valor de negocio y de su repetitividad. Por una parte, el valor de negocio expresa la importancia del WF en la organización. Por la otra, la repetitividad indica la frecuencia en la que el WF se lleva a cabo. Debido a que la creación de un WF es económicamente costosa, la mayoría de las organizaciones se
12 1. Modelado de flujos de trabajo WFs colaborativos WFs de producción WFs ad-hoc WFs administrativos ALTO BAJO ALTOBAJO VALOR DE NEGOCIO REPETITIVIDAD Figura 1.1: Tipos de WFs en función del valor de negocio y repetitividad WFs colaborativos WFs de producción WFs ad-hoc WFs administrativos MUY ESTRUCTURADO POCO ESTRUCTURADO CENTRADO EN EL PROCESO CENTRADO EN LA INFORMACIÓN ESTRUCTURACIÓN ENFOQUE Figura 1.2: Tipos de WFs en función de la estructuración y enfoque decantan habitualmente por automatizar los procesos de negocio que tengan un alto valor de negocio y una alta repetitividad. Las figuras 1.1 y 1.2 representan las cuatro clases de WFs identificadas: WFs colaborativos y ad-hoc. Son WFs de baja repetitividad que necesitan de la intervención humana para lograr la funcionalidad deseada. La principal diferencia entre ambas categorías está en su valor de negocio. Por una parte, los WFs colaborativos tienen un alto valor de negocio y prestan más atención a la comunicación entre los participantes y la compartición de información que a la definición del proceso. Este tipo de WF suele estar soportado por sistemas de trabajo en grupo (groupware en inglés), como Lotus Notes o Microsoft Exchange, más que por WMSs. Por otra parte, los WFs ad-hoc representan procesos donde el procedimiento no está definido de antemano, es decir, se crea y modifica durante la ejecución. Este tipo de WF tampoco suele estar soportado por WMSs [255]. WFs administrativos y de producción. Son el tipo de WF soportado por la mayoría de los WMSs y se caracterizan por tener una alta repetitividad. Por un lado, los WFs administrativos son procesos bien delimitados y conocidos dentro de la organización. Suelen poseer un bajo valor de negocio y se desarrollan en dominios administrativos como por ejemplo el envío de un informe o la autorización de un proceso. Los WFs de producción suelen tener un alto valor de negocio, ya que se encargan de dar soporte al núcleo del negocio de la organización, como por ejemplo la gestión de reclamaciones en una compañía de seguros o la gestión de préstamos en un banco. Se caracterizan por ser muy estructurados y tener pocas variaciones a lo largo de su vida útil. En esta tesis, únicamente se considerarán estos dos tipos de WFs.
1.1. La ambigua noción llamada “flujo de trabajo” 13 1.1.4. Lenguajes de modelado Existen muchos lenguajes de modelado de WFs. Estos lenguajes difieren en sus construcciones de control, su notación, su uso, y muchos más aspectos. Algunos están orientados a la representación, otros a la ejecución; algunos son formales, otros ni siquiera tienen semántica operacional; etc. Dos razones justifican tanta variedad: el propósito del modelo y las características del WF. 1.1.4.1. Un lenguaje para cada propósito Al igual que el propósito del WF influencia el contenido del modelo, el contenido del modelo hace lo propio con el lenguaje de modelado. Dependiendo de este contenido, algunos lenguajes son más indicados que otros: Divulgación. Los WFs orientados a divulgar información entre los participantes o a servir como soporte para la toma de decisiones suelen requerir de un lenguaje gráfico que facilite la interpretación de la información por parte de los participantes. Estos lenguajes centran el diseño en torno a las tareas y a sus participantes, pero también incorporan al modelo aspectos sociales y de comportamiento, de forma que sus modelos promuevan la conversación y la socialización de los WFs. En la práctica, este tipo de WFs suele utilizarse para introducir a los nuevos empleados a la estructura de los procesos de negocio, a los productos que distribuye o a las interdependencias inter-departamentales de la organización. Se caracterizan por ser sencillos y estar descritos a través de lenguajes informales [71]. Puesta en práctica. Los diseñadores suelen utilizar la técnica propietaria proporcionada por el WMS en el cual están realizando el modelado. Ello es comprensible, ya que minimiza el esfuerzo de trasladar el modelo del WF a un modelo ejecutable. Sin embargo, el uso de técnicas propietarias en el modelado es una práctica desaconsejada debido a que (i) dificulta el análisis de las características y del comportamiento del modelo, ya que pocos de estos lenguajes disponen de modelos formales que faciliten el análisis del WF; (ii) dificulta la portabilidad de los modelos entre distintos WMSs (los WMSs deben compartir al menos un lenguaje común y ser la semántica del lenguaje equivalente); (iii) suelen ser difíciles de mantener. Análisis. Si el WF está diseñado con el propósito de analizar alguna faceta del modelo es imprescindible utilizar un lenguaje de modelado que disponga de técnicas de análisis. El análisis y la simulación son dos de los factores más importantes a la hora de seleccionar un lenguaje de representación [254]. Incluso si el modelado no requiere de estas capacidades, este tipo de lenguaje suele tener una base formal evitando así ambigüedades en el modelo. En la práctica no existen muchos lenguajes con este tipo de capacidades.
14 1. Modelado de flujos de trabajo 1.1.4.2. Muchas características y pocos lenguajes La segunda razón que más influencia la selección de un determinado lenguaje para llevar a cabo el modelado concierne a las características del WF. Por ejemplo, un WF con un control complejo, que incluya tareas concurrentes, iteraciones o rutas condicionales, requiere de un lenguaje más expresivo que un WF que consista en una secuencia de tareas; si el WF se estructura en torno a las tareas, se modelará con lenguajes de modelado tradicionales; si lo hace en torno a la organización lo hará con técnicas que permitan la conversación y negociación entre los agentes; etc. Independientemente de las características del WF, la gran mayoría de los WMSs permiten el modelado de WFs estructurados, y, por lo tanto, centrados en el control sobre las tareas. Además, la capacidad expresiva de sus lenguajes es suficiente para representar los WFs que se dan en el mundo real. Por ello, en la práctica las características tienen menos influencia en la técnica de modelado elegida. 1.2. Aproximación tradicional al modelado de flujos de trabajo Aunque el concepto de WF no era nuevo, el impulso a esta tecnología no se produce hasta comienzos de los 90 cuando las organizaciones empezaron a prestar más atención a sus procesos de negocio y se dieron cuenta de las ventajas en cuanto a productividad, calidad del trabajo y reducción de costes de la automatización. En la actualidad, no se discute esta automatización, habida cuenta de que los procesos de negocio son cada vez más complejos, están sujetos a frecuentes cambios para adecuarse al mercado y el número de procesos que debe gestionar una organización es cada vez mayor. 1.2.1. Sistemas de gestión de flujos de trabajo Un WMS es un paquete software que se puede usar para dar soporte a la definición, gestión y ejecución de WF [255]. En principio, la gestión de los WFs puede realizarse sin usar WMSs; de hecho, los WFs ya existían antes de la aparición de los WMSs y muchas organizaciones no necesitan de esta tecnología para implementar sus procesos de negocio. Sin embargo, a medida que los procedimientos se complican, la gestión del trabajo se hace insostenible sin un WMS. La idea subyacente de los WMSs es la separación entre los procesos, los participantes y las aplicaciones. Por ello están enfocados a la logística del proceso de negocio y no al contenido de las tareas individuales. En la práctica, los WMSs se hacen cargo de entregar el trabajo a los recursos en tiempo y forma: cada vez que una pieza de trabajo ha sido completada durante la ejecución de un proceso de negocio, el WMS determina cómo continuar la ejecución y entrega la siguiente pieza de trabajo a realizar al recurso o recursos más adecuados. Los WMSs pueden asumir esta funcionalidad gracias al modelo del proceso de negocio en el que se definen todas las tareas así como sus dependencias. El WF también incorpora la información acerca del tipo de recurso
1.2. Aproximación tradicional al modelado de flujos de trabajo 15 requerido para la ejecución de cada tarea, facilitando así la selección del recurso más indicado (normalmente una persona, un servicio o un sistema) por parte del WMS. Al centrarse las empresas en el desarrollo de sus procesos de negocio, se han desarrollado a lo largo de los últimos años un conjunto de técnicas que son complementarias a las de gestión de WFs: Reingeniería de procesos de negocio (BPR, del inglés Business Process Reengineering). La BPR facilita el análisis y rediseño de procesos de negocio (y por lo tanto de WFs) dentro y entre organizaciones. BPR nace del trabajo [126] en el que se demuestra que en ocasiones cambios radicales en el diseño y organización de los procesos de negocio son necesarios para reducir costes e incrementar la calidad del servicio. Mejora continua de los procesos (CPI, del inglés Continuous Process Improvement). La CPI, al igual que la BPR, busca la mejora de los procesos de negocio pero mediante pequeñas mejoras en lugar de implementar un único paso con una gran mejora. Es una aproximación estratégica para promover una cultura de mejora continua en áreas como la fiabilidad, tiempos del proceso, costes, calidad o productividad. Se basa en la idea de que suele ser complicado encontrar una única causa de problemas en un proceso de negocio. Por ello, si no se está dispuesto a comenzar de nuevo el proceso de diseño, es mejor aplicar pequeñas mejoras dirigidas (i) eliminar las actividades sobrantes, (ii) reducir los tiempos de respuesta y (iii) simplificar el proceso o el diseño del producto. Gestión de logística (LM, del inglés Logistics Management). La logística se refiere al movimiento de mercancías, personas o energía desde un punto de origen hasta el cliente. La LM trata de optimizar cada parte del proceso de negocio para que el producto/funcionalidad llegue al cliente final de forma eficiente y en tiempo. Estas tecnologías permiten cubrir otros aspectos relacionados con la mejora de los procesos que no son tratados por la tecnología de gestión de WFs (WM, del ingles Workflow Management). Sería, por lo tanto, incorrecto considerar a los WMSs como herramientas que se centran exclusivamente en la WM, ya que en la actualidad, los WMSs comerciales incorporan algunas de estas tecnologías con el fin de mejorar sus funcionalidades. 1.2.2. Metamodelos de flujos de trabajo A pesar de los esfuerzos de los organismos internacionales, como la Workflow Management Coalition2(WfMC) o el Object Management Group3, hasta el momento no se ha desarrollado ningún metamodelo genérico, pese a que hay un buen número de 2http://www.wfmc.org 3http://www.omg.org
16 1. Modelado de flujos de trabajo Cliente Recurso propuesta negociación interpretaciónaceptación Figura 1.3: Bucle característico de los metamodelos de comunicación ellos descritos en la bibliografía [52, 54, 58, 87, 94, 138, 146, 150, 159, 169, 264] y la mayoría de ellos han sido construidos en base a alguna de las características comentadas en el apartado 1.1.2. La clasificación de estos metamodelos en base a estas características puede encontrarse en [147]. Otra de las clasificaciones más aceptadas los categoriza en función de su enfoque: Metamodelos de comunicación. Nacen del modelo denominado “Conversation for Action Model” [297] y su objetivo es especificar la comunicación entre las entidades que participan en el WF. Los WFs se modelan como bucles donde el recurso realiza una acción bajo petición de un cliente (ver Figura 1.3) y cada bucle consta de cuatro fases consecutivas: propuesta,negociación,interpretación yaceptación. En la primera fase (propuesta) el cliente solicita la ejecución de una acción bajo unas determinadas condiciones; en la segunda fase (negociación) el cliente y el recurso acuerdan dichas condiciones; en la tercera fase (interpretación) el recurso ejecuta la acción bajo los términos acordados; y finalmente, en la última fase (aceptación) el cliente informa al recurso acerca de la satisfacción del resultado. La funcionalidad completa de un WF se consigue enlazando distintos bucles. Más ejemplos de este tipo de metamodelo de WFs pueden encontrarse en [176, 151]. Metamodelos de actividades. Los metamodelos centrados en el flujo de control son hoy en día los más habituales y aceptados en la comunidad de WFs. Prueba de ello es la enorme cantidad de trabajos que en los últimos años han estado centrados en el modelado de procesos y de los que han surgido los actuales lenguajes de WFs [197, 10, 295, 247, 15, 259, 246, 168, 18, 129, 72]. En esta alternativa, la tarea/actividad es el elemento fundamental entorno al cual se crea el proceso. El control consiste en indicar el orden en el que se pueden ejecutar las tareas, sus condiciones de aplicabilidad y sus ejecutores. En esta tesis doctoral se ha optado por aproximar el modelado de WFs desde un metamodelo de actividades.
1.2. Aproximación tradicional al modelado de flujos de trabajo 17 Otras clasificaciones de metamodelos centran su atención en el paradigma/formalismo de representación del WF. En este sentido, la mayor parte de estas clasificaciones están enfocadas en el flujo de control y prácticamente no consideran otras características como la organización o la información. Por ejemplo, en [141] se distinguen metamodelos basados en las transiciones de estado, en las reglas o en los modelos imperativos. En cambio, en [298] se clasifican en base a: lenguajes de script,métodos orientados a redes,métodos basados en lógica,métodos algebraicos yreglas evento-condición-acción. En [19, 11, 80, 164] pueden encontrarse otras clasificaciones similares a las anteriores. Finalmente cabe mencionar que, independientemente de sus características, es deber del metamodelo proporcionar un lenguaje que dé soporte a la definición del WF [164]. 1.2.3. Metamodelo tradicional de modelado de flujos de trabajo El diseño de un WF es una tarea complicada que requiere realizar un profundo análisis del proceso de negocio y de los recursos que participan en su ejecución. Tradicionalmente, esta tarea ha sido desarrollada por ingenieros del software y su realización ha estado enfocada hacia la definición de una estructura de procesos que cumpla con los objetivos del problema a resolver. Esta estructura actúa como elemento de integración de las distintas aplicaciones que se encargan de realizar alguna de las actividades del WF. La Figura 1.4 muestra este enfoque tradicional de construir un WF basado en un metamodelo de actividades. Puede verse claramente como un WF está compuesto por dos dimensiones [255]: una dimensión de procesos, que modela las relaciones entre las distintas actividades a realizar, y una dimensión de recursos, que organiza los agentes que intervienen en la ejecución de las actividades del WF. Un WF es, por lo tanto, el punto de encuentro entre estas dos dimensiones, es decir, el lugar donde los agentes se integran dentro de la estructura del proceso. 1.2.3.1. Dimensión de procesos La dimensión de procesos determina la estructura de control del WF. El objetivo de esta dimensión es romper la estructura del proceso en partes más manejables, y el primer paso consiste en identificar los (sub)procesos, también denominados (sub)flujos, que encapsulan la complejidad del proceso en una relación jerárquica. Por ejemplo, un WF cuyo objetivo es la fabricación de un mueble podría dividirse en dos (sub)procesos: uno para la fabricación de cada una de las piezas y otro para el ensamblaje. La parte más pequeña de un proceso se denomina tarea, aunque también puede tomar el nombre paso, acción o actividad. Las tareas representan una unidad de trabajo cuyas características varían en cuanto al tiempo, espacio o requerimientos, pero todas suelen cumplir las propiedades transaccionales ACID; es decir, son atómicas, consistentes, independientes y duraderas. Por ejemplo, el encolado de dos piezas de madera podría considerarse como una tarea de un único paso donde la duración dependiese de las características del pegamento. Dentro de un proceso de negocio típicamente existen dependencias entre tareas, donde una dependencia suele indicar un orden de ejecución a respetar. Por ejemplo,
24 1. Modelado de flujos de trabajo CommonKADS, punto de partida de la mayoría de los metamodelos de conocimiento actuales, e introducirá cronológicamente los principales metamodelos de PSMs. Una especial atención merecen los dos últimos metamodelos descritos: WSMO [83] y OWL-S4[174]. Aunque ninguno de estos metamodelos han sido creado expresamente para representar WFs, la similitud existente entre algunos problemas del dominio de los servicios web y de los WFs hace que este modelado sea posible. Concretamente, la coreografía y la la orquestación de servicios web pueden verse como un problema de coordinación de procesos y, por lo tanto, como un problema de modelado de WFs. Aunque existen artículos teóricos que tratan el modelado de WFs con estos metamodelos, en la práctica únicamente existe un WMS implementado siguiendo la especificación OWL-S [24]. Este desarrollo se enmarca dentro del proyecto europeo NextGrid5cuyo objetivo es el desarrollo de la arquitectura de los futuros GRIDs. En cualquier caso, la falta de implementaciones no puede achacarse a la falta de interés sino a la juventud de ambas especificaciones. En el caso concreto de WSMO, a que algunas partes de la especificación todavía no están completas. 1.3.2.1. CommonKADS La aproximación KADS para el modelado de conocimiento ha sido formulada a lo largo de más de una década (1983-1994) y ha dado lugar a dos especificaciones conocidas como KADS-I y KADS-II: KADS-I (1983-1989) propone una metodología para el desarrollo de SBCs; y KADS-II (1990-1994) se centra en el desarrollo de un metamodelo para el modelado de conocimiento. La revisión CommonKADS [228] dio lugar a una nueva formulación que integra el metamodelo de KADS-II dentro de la metodología KADS. Se puede considerar a CommonKADS como el fundamento teórico a partir del cual se desarrollaron los actuales PSMs. Desde el punto de vista del modelado de procesos, CommonKADS distingue tres componentes principales para describir el conocimiento de una aplicación: tarea,inferencia ydominio. Las tareas describen qué se necesita para resolver el problema ycómo resolverlo. Su definición incluye las entradas, las salidas, los objetivos, la descomposición de la tarea y su control. Las inferencias describen las primitivas de razonamiento. Se consideran primitivas porque se describen exclusivamente desde el punto de vista funcional, ya que su estructura interna no es relevante desde la perspectiva del conocimiento. Finalmente, la última componente especifica la forma, estructura y contenidos del conocimiento relativo a un determinado dominio, que ha de ser relevante desde el punto de vista de la aplicación. Las relaciones entre los distintos componentes se establecen a través de los roles de conocimiento, es decir, a través de etiquetas abstractas que indican el papel que el conocimiento asociado a dicha etiqueta juega en el problema a resolver. La Figura 1.7 muestra un ejemplo de diagrama de inferencia de CommonKADS 4OWL-S no es un metamodelo de PSMs sino una ontología para describir servicios web semánticos. Sin embargo, la forma en la que modela el control de los servicios está claramente fundamentada en la teoría de los PSMs y es el motivo por el cual se incluyó esta aproximación en este apartado. 5http://www.nextgrid.org/
1.3. Aproximación desde la perspectiva del conocimiento 25 Problema calidad Posibles causas Causa Hallazgos Solución Generar hipótesis Comprobar hipótesis Seleccionar Conocimiento fabricación Figura 1.7: Diagrama de inferencia CommonKADS de un problema de control de calidad en el que se distinguen estos tres tipos de componentes: las tareas están representadas mediante rectángulos redondeados, las inferencias mediante elipses y los roles de conocimiento mediante rectángulos simples si son roles dinámicos o rectángulos abiertos en el caso de ser roles estáticos. La estructura de inferencia de este ejemplo muestra la resolución de una tarea de control de calidad en un centro de fabricación. La fabricación de una pieza es un problema complejo y por ello cuando se detecta un fallo de calidad es necesario analizar las posibles causas: la tarea generar hipótesis se encarga de generar cada una de las posibles causas que pueden ocasionar tal defecto y la inferencia seleccionar de escoger la más probable a partir del conocimiento de fabricación; finalmente, se comprueba si la hipótesis se verifica. Este ejemplo permite apreciar cómo CommonKADS establece la relación entre las distintas tareas/inferencias a través de los roles de conocimiento. Estos diagramas de inferencia, sin embargo, no establecen el orden a la hora de ejecutar las tareas o inferencias que componen una tarea más genérica. El principal aporte de CommonKADS al modelado de WFs sería (i) una mejor estructuración y reutilización de los datos, que se definirían a través de ontologías [122], (ii) la posibilidad de explicitar el conocimiento (normalmente a través de reglas) y(iii) una mayor capacidad de razonamiento acerca de las características funcionales de los procesos y de los modelos del dominio. Además, la metodología CommonKADS da soporte al modelado de la dimensión de recursos de los WFs. Como puede verse en la Figura 1.8, la metodología CommonKADS especifica un modelo de organización y un modelo de agentes a través de los cuales se puede capturar tanto la estructura como los recursos (humanos o software) de la organización. La integración entre los modelos de tareas, organización y agentes se realiza en los modelos de conocimiento
26 1. Modelado de flujos de trabajo Modelo de organización Modelo de tareas Modelo de agentes Modelo de conocimiento Modelo de comunicación Modelo de diseño Figura 1.8: Arquitectura de CommonKADS y comunicación. Por el contrario, cabe destacar las carencias de CommonKADS a la hora de modelar el control sobre las tareas. CommonKADS sólo especifica la descomposición de tareas en (sub)tareas y relaciona dichas tareas a través de roles de conocimiento. Por lo tanto, conceptos básicos como la concurrencia, la sincronización o la secuencia no están contemplados en este marco de representación. 1.3.2.2. Componentes de la experiencia Esta aproximación, denominada Components of Expertise en inglés, nació con el propósito de integrar un conjunto de propuestas esbozadas en los años ochenta en un marco de modelado comprensible [239]. La aproximación distingue tres componentes básicos de experiencia: tareas,métodos ydominios. La diferencia con respecto a CommonKADS es que las tareas sólo especifican aquello que debe resolverse y no la forma de resolverlo (esa parte del conocimiento está incluida en los métodos). Esta aproximación se caracteriza por introducir algunas ideas que luego fueron adoptadas por propuestas más modernas como puede ser Protégé II o, sobre todo, UPML. La principal es la separación entre tareas y métodos, o lo que es lo mismo entre funcionalidad y control. Esta separación permite resolver una misma tarea a través de métodos diferentes y, por lo tanto, reutilizar este elemento de control. En cuanto al modelado de WFs tiene la ventaja, con respecto a CommonKADS, de separar los métodos de las tareas y así capturar mejor las perspectivas funcional y de control de los WFs. El principal inconveniente de esta aproximación es su cercanía al nivel de implementación, es decir, los métodos están descritos al nivel simbólico y no de conocimiento. Así, se reduce la capacidad de reutilización del modelo. En resumen,
1.3. Aproximación desde la perspectiva del conocimiento 27 aunque introduce mejoras respecto a CommonKADS, sigue teniendo inconvenientes a la hora de representar el control de los procesos. Además, no contempla la dimensión de recursos de los WFs. 1.3.2.3. Tareas genéricas Como su nombre indica, esta aproximación [59] centra el modelado de conocimiento en torno a la noción de tarea genérica que integra tanto el concepto de tarea como el de método. Sin embargo, el enfoque de esta aproximación modela el conocimiento desde una perspectiva orientada a su uso: tanto la naturaleza como la representación del conocimiento del dominio están determinados por la tarea (o método), es decir, el conocimiento no se puede separar de su uso. Como consecuencia directa, esta aproximación sólo considera las tareas y los métodos. La relación entre métodos y tareas es también diferente: aunque las tareas siguen resolviéndose a través de métodos, estos últimos se descomponen en otras tareas cuando no son primitivos. Por lo tanto, la resolución de un método no primitivo no finalizará hasta que todas las (sub)tareas no se resuelvan a través de un método primitivo. En cuanto al modelado de WFs, la descomposición de los métodos en (sub)tareas tiene la ventaja de permitir estructurar el control en base a las funcionalidades (o tareas) a resolver. De esta forma, se flexibiliza la definición de un WF, que ahora no tendría por qué especificar el control de sus (sub)procesos. Por lo demás, esta solución tiene los mismos inconvenientes que las aproximaciones tradicionales al modelado de los WFs, es decir, integra el conocimiento del dominio dentro de las tareas/métodos minimizando así su posible reutilización. Finalmente, esta solución tampoco aporta una descripción del flujo de control al nivel de abstracción requerido por un WMS ni contempla el modelado de la organización. 1.3.2.4. Protégé-II La aproximación Protégé nació a partir del desarrollo de una herramienta de adquisición de conocimiento en el dominio de la medicina [206]. En su primera versión, el conocimiento se integraba desde la perspectiva de su uso y de forma similar a la propuesta de tareas genéricas. Sin embargo, los autores se dieron cuenta de las limitaciones de crear una herramienta exclusivamente para un determinado campo de aplicación y desarrollaron Protégé-II [113] con el fin de generalizar su uso a cualquier dominio y problema. Protégé-II reconoce tres tipos de componentes: tareas,métodos ydominios. En esta aproximación, los métodos se descomponen en (sub)tareas mientras que el término mecanismo se refiere a métodos directos. La principal diferencia con respecto a otras propuestas radica en que los métodos se describen en base a requerimientos ontológicos, relaciones de entrada y salida, flujo de control y flujo de datos. A pesar de fundamentarse en la perspectiva del uso de conocimiento, permite especificar métodos independientes del dominio y dominios independientes de los métodos para maximizar la reutilización. Para ello los métodos y dominios se integran a través de relaciones de correspondencias.
28 1. Modelado de flujos de trabajo Esta aproximación tiene la ventaja de modelar explícita y claramente el control, aunque de modo insuficiente para dar soporte a todas las características de los WFs. Así, la descomposición de los métodos en (sub)tareas, la descripción de éstos a través de ontologías y la separación de los modelos del dominio de los métodos convierten esta aproximación en una de las más utilizadas para representar PSMs. Por último, mencionar que en propuesta la perspectiva de la organización no está explícitamente modelada, aunque podría considerarse su definición como una parte del modelo del dominio. 1.3.2.5. UPML La aproximación UPML (del inglés Unified Problem-solving Method description Language) [196] nace como resultado del proyecto europeo IBROW [28] cuyo objetivo era el desarrollo de un servicio de consulta inteligente que permitiese recuperar componentes de conocimiento de librerías digitales distribuidas. UPML proporciona la arquitectura conceptual de IBROW y desde entonces se ha utilizado para el desarrollo de sistemas de razonamiento que hacen uso intensivo de conocimiento. UPML modela PSMs a través de componentes de conocimiento y de adaptadores. Los primeros se refieren a cada una de las piezas del nivel de conocimiento necesarias para describir un PSM. Específicamente, distingue cuatro tipos de componentes de conocimiento que son independientes entre sí: tareas,métodos,modelos de dominio y ontologías. Por un lado, las tareas detallan el problema que resuelve el PSM a través de la descripción de sus propiedades funcionales, es decir, sus objetivos, entradas, salidas, prey postcondiciones. Los métodos representan la solución a las tareas. Al describirse en el nivel de conocimiento no implementan una solución a nivel simbólico: en el caso de métodos primitivos simplemente se indican sus propiedades funcionales; mientras que si son métodos compuestos, detallan el control sobre las (sub)tareas que lo componen. Los modelos del dominio permiten describir el conocimiento del dominio de la aplicación a través del conjunto de hechos, reglas, propiedades y asunciones que lo caracterizan. Finalmente, las ontologías son el componente central del metamodelo UPML y aportan el vocabulario y la axiomática necesaria para describir la semántica de los tres componentes anteriormente citados. De esta forma, cualquier tarea, método o modelo del dominio se describirá a través de una o varias ontologías, facilitando así su descripción y reutilización. Como se muestra en la Figura 1.9 las tareas, métodos, modelos del dominio y ontologías se relacionan a través de un conjunto de adaptadores. Los adaptadores son relaciones binarias entre dos componentes de conocimiento: si la adaptación se establece entre componentes del mismo tipo, el adaptador se denomina refinador; en cambio, si se especifica entre componentes de distinto tipo se conoce como puente. Como su nombre indica, los refinadores permiten definir un nuevo componente añadiendo restricciones a la definición de otro componente preexistente. En cambio, los puentes se utilizan para adaptar la terminología empleada por dos componentes de conocimiento de forma que hablen el mismo lenguaje. Esta adaptación es sencilla si se puede asociar directamente el vocabulario de las ontologías que describen cada
1.3. Aproximación desde la perspectiva del conocimiento 29 Refinador Tarea Tarea Adaptador Ontología Ontologías Puente Método-Tarea Puente Tarea-Dominio Refinador Método Método Puente Método-Dominio Refinador Dominio Modelo del Dominio Figura 1.9: Arquitectura de UPML uno de los componentes de conocimiento, o más compleja si requiere la definición de axiomas para ello. La descripción de un WF a través de UPML permitiría subir un nivel más el ratio de reutilización, ya que en este marco todo es reutilizable. Respecto al modelado de la perspectiva de control, la propuesta es similar a la de Protégé-II, es decir, se distinguen dos tipos de métodos en función de si se descomponen en (sub)tareas o no y se especifica un control en un lenguaje que se define en el nivel del conocimiento y que, por lo tanto, no es procesable ni interpretable. Por lo tanto, la expresividad del control sigue siendo muy reducida comparada con los modelos de WFs. La perspectiva de la organización y de los recursos tampoco tiene un soporte directo, aunque al igual que en Protégé-II se podrían definir dentro del modelo del dominio a través de reglas de asignación y de ontologías. 1.3.2.6. WSMO La aproximación WSMO (Web Services Modeling Ontology) [83] nace como uno los esfuerzos de la web semántica para representar el conocimiento dentro de la web. Para tal tarea, WSMO define una arquitectura denominada WSMF [103] (del inglés Web Services Management Framework) que proporciona un modelo conceptual para desarrollar y describir servicios web. Se basa en dos principios complementarios: fuerte desacoplamiento de los múltiples componentes que describen una aplicación de comercio electrónico y fuerte servicio de mediación, que permite a cualquier aplicación comunicarse con otros servicios y aplicaciones de una manera escalable. La arquitectura conceptual de WSMF está representada en la Figura 1.11 y se estructura entorno
30 1. Modelado de flujos de trabajo Servicio de reserva de billete de avión solicitud de reserva tarjeta de crédito confirmación de reserva confirmación negativa Coreografía Orquestación <<wwMediator>> PagoPayPalMediador <<wwMediator>> PagoTarjetaCréditoMediador Red <<Web Service>> PagoPayPal <<Web Service>> PagoTarjetaCrédito Figura 1.10: Interfaces de orquestación y coreografía de WSMO a cuatro componentes: Ontologías. Permiten especificar formalmente la terminología usada por los demás componentes del metamodelo. Objetivos. Especifican los objetivos que el cliente debe poseer cuando consulta un servicio web. Se trata de especificar la capacidad del servicio a través de propiedades no funcionales, además de las prey postcondiciones, las asunciones y los efectos que un servicio web debe tener para cumplir con el comportamiento deseado. Servicios web. Describe lo que es un servicio web, sus características funcionales, no funcionales coreografía y orquestación. La Figura 1.10 muestra los dos tipos de interfaces que permiten componer un servicio web. Por una parte la coreografía describe la interacción del cliente a la hora de consumir el servicio: el proceso detalla los mensajes enviados y recibidos entre el cliente y el servicio, y también la tecnología de conexión y protocolos necesarios para que esta interacción tenga lugar. Por otra parte, la orquestación describe la forma de lograr la funcionalidad del servicio mediante la agregación de otros servicios web, y para ello, descompone la funcionalidad en (sub)funcionalidades. Mediadores. Permiten un fuerte desacoplamiento de los componentes de WSMO que describen los servicios web y se utilizan para la intermediación entre dichos componentes. Los mediadores facilitan la reutilización de cualquiera de los componentes WSMO en diferentes dominios y aplicaciones. Al contrario que los otros metamodelos de PSMs, WSMO describe el control a través de un formalismo de representación de procesos: máquinas abstractas con estado [124]. Sin embargo, como está explicado en el Capítulo 2, este formalismo no es el más adecuado para representar WFs debido a que no introduce construcciones de control con las que se abstrae la definición de la dimensión de procesos, permitiendo un mayor entendimiento del proceso y una mayor legibilidad. En otras palabras, en WSMO la descripción del control se realiza a bajo nivel de abstracción.
1.3. Aproximación desde la perspectiva del conocimiento 31 Objetivos Mediadores Ontologías Servicios Web Figura 1.11: Arquitectura conceptual de WSMF Service ServiceGrounding ServiceModel ServiceProfile presents supports describedBy (what it does) (how it works) (how to access it) Figura 1.12: Concepto de servicio en OWL-S El nivel de reutilización de componentes de WSMF es muy alto, sin embargo, al ser un metamodelo pensado para servicios web restringe su aplicabilidad a los WFs. Un ejemplo de ello es que WSMF no explicita la dimensión de recursos. En cualquier caso, WSMO permitiría definir implícitamente esta dimensión a través de las ontologías que capturan el conocimiento del dominio pero a costa de una menor capacidad de reutilización. 1.3.2.7. OWL-S Al igual que WSMO, OWL-S [174] surge de la necesidad de representar semánticamente los servicios web tradicionales para así facilitar la realización de operaciones de descubrimiento, selección, composición, negociación, invocación, monitorización y recuperación de forma (semi)automática. Un servicio web semántico está formado por un servicio web y una anotación semántica, que consiste en asociar conceptos y relaciones de una ontología especificada en el lenguaje OWL [84] con los parámetros y operaciones de dicho servicio. Al contrario que WSMO, OWL-S no posee una arquitectura conceptual que defina los componentes necesarios para realizar dichas operaciones sobre los servicios web semánticos. Como se puede ver en la Figura 1.12, OWL-S especifica a través de tres modelos la estructura de un servicio web: El perfil del servicios (Service Profile, en inglés) responde a la cuestión “qué hace el servicio” describiendo sus entradas/salidas, sus características funcionales, sus condiciones de aplicabilidad (pre/post-condiciones), y algunas características no funcionales, como es la calidad de servicio o la localización geográfica. El modelo de conexión (Service Grounding, en inglés) responde a la cuestión “cómo puede un agente acceder al servicio” describiendo los detalles del pro-
32 1. Modelado de flujos de trabajo tocolo de comunicaciones, formato de los mensajes y puertos de comunicación que son usados para invocar el servicio. El modelo de servicios (Service Model, en inglés) responde a la pregunta “cómo funciona el servicio” detallando al cliente las condiciones bajo las cuales un determinado resultado puede producirse y la coreografía de mensajes que debe tener lugar con el servicio para obtener dicho resultado. Desde el punto de vista del modelado, la estructura del proceso se establece en el modelo de servicios. OWL-S estructura el servicio en torno al concepto de proceso, que puede ser atómico ocompuesto en el caso de descomponerse en (sub)procesos. Además, al contrario de WSMO, OWL-S proporciona estructuras de control predefinidas para así facilitar la composición de los (sub)procesos. Por ejemplo, define secuencias de procesos, procesos en paralelo,sincronización de procesos, y estructuras iterativas o condicionales. El uso de OWL-S para representar WFs es, cuanto menos, mucho más sencillo que con WSMO. En este sentido, aunque OWL-S ha sido creado para representar servicios, éstos se describen como procesos. La estructuración de estos procesos es también más aplicable, ya que OWL-S proporciona un conjunto de construcciones de control, la mayoría de las cuales son típicas de los WFs. Por otra parte, la especificación OWL-S tiene la desventaja de que no ha sido creada a partir de un modelo formal y, por lo tanto, tiene una semántica operacional ambigua. Aunque se han propuestos algunos modelos que han intentado dotar de un soporte formal a OWL-S [191, 89, 34, 308, 64, 178, 14, 183, 81] ninguno de ellos tiene en cuenta todos los elementos de la especificación. En esta tesis doctoral se ha dado respuesta a esta cuestión desarrollando un modelo formal basado en redes de Petri que atiende a todos los aspectos de OWL-S [277]. La reutilización tampoco es el punto fuerte de OWL-S, ya que no proporciona el marco adecuado para ello. En este sentido, no indica cómo reutilizar el modelo de conexión o cómo reutilizar un (sub)servicio. Este hecho está en gran medida relacionado con la falta de un marco arquitectónico que permita relacionar todos los componentes de OWL-S. Desde la perspectiva de los recursos, OWL-S tampoco proporciona el marco adecuado para su modelado: aunque permite modelar recursos a través de una ontología de actores, esta ontología no está pensada para clasificar los recursos como requieren los WFs. 1.4. Conclusiones En este capítulo se ha profundizado en el concepto de WF y se han introducido algunas de las muchas variantes a partir de las cuales se puede enfocar su modelado. En particular, se ha ahondado en el marco de modelado tradicional, utilizado por la mayoría de los WMSs, donde la descripción del WF se centra en su modelo de control.
1.4. Conclusiones 33 Dimensión de procesos Dimensión de recursos Flujo de trabajo Representación del proceso (redes de Petri, diagramas de flujo de datos, texto, …) Estructura organizativa (departamentos, roles, …), personas y recursos Presidente Responsable de compras Director técnico Departamento de fabricación Departamento de desarrollo del producto Responsable proyecto A Sección de fabricación Unidad de desarrollo de producto El flujo de trabajo relaciona las tareas y los participantes ... ... Dimensión de conocimiento del dominio Ontología del dominio de aplicación A Representación del conocimiento del dominio de aplicación (ontologías, reglas, …) Ontología del dominio de aplicación B SI la unión es a inglete ENTONCES la longitud de fresado es igual a dos veces el lado fresado SI la unión es a inglete en Z ENTONCES la longitud fresada es igual a tres veces el lado fresado ... El conocimiento se integra dentro de la estructura del flujo de trabajo para facilitar la toma de decisiones El conocimiento también se refiere a los recursos que participan en el dominio de la aplicación Unidad de compras Figura 1.13: Metamodelo para la representación semántica de WFs en el que se introduce una nueva dimensión para el modelado del conocimiento en dominios complejos La combinación de este metamodelo con un potente lenguaje de representación de WFs dota a estos sistemas de una gran capacidad de representación. También se han citado los principales problemas intrínsecos a este tipo de modelado, los cuales se podrían resumir en un único punto: la falta de semántica del modelo [130]. Con el objetivo de paliar este problema, en esta tesis doctoral consideramos la hipótesis de modelar los WFs desde un punto de vista semántico. Para ello se han tomado las principales propuestas para el modelado del conocimiento, analizando sus ventajas e inconveniente respecto a la representación de WFs. Las ventajas de este tipo de propuestas son las siguientes: Arquitectura conceptual. Los metamodelos analizados se estructuran pensando en la mejor forma de construir los procesos. Esta característica está también vinculada con la capacidad de reutilización de los componentes del modelo recogida en la Tabla 1.1. Por ejemplo, CommonKADS utiliza siete modelos donde cada uno de estos modelos captura un elemento básico del proceso, pero no indica cómo reutilizarlos. En cambio, metamodelos más recientes, como WSMO o UPML,
40 2. Lenguajes de modelado de flujos de trabajo C B A B C AND A B C A B C AND A C A AND C B A AND C B B A B C A C A C B A C B SECUENCIA SEPARACIÓN SINCRONIZACIÓN ELECCIÓN EXCLUSIVA MEZCLA SIMPLE XOR XOR XOR XOR B AXOR a) b) A C B XOR Figura 2.1: Patrones básicos de control. Cada rectángulo representa una actividad, las elipses representan construcciones de control y los arcos dirigidos representan las dependencias entre los distintos elementos. Instanciación múltiple. Modelan situaciones donde puede existir más de un hilo de ejecución activo para una misma actividad y donde las distintas instancias comparten la misma implementación. La instanciación múltiple puede darse en tres situaciones: 1. Una actividad puede iniciar múltiples instancias de sí misma. Aunque estas instancias son independientes entre sí y, por lo tanto, pueden ejecutarse concurrentemente, cada una de ellas debe ejecutarse dentro del contexto de la instancia del proceso que las generó (por ejemplo, compartiendo el mismo identificador de proceso/caso y los mismos datos). 2. Una actividad puede ser iniciada múltiples veces. Por ejemplo si la actividad está en un bucle o si existen varias ramas concurrentes que inician la misma actividad. 3. Dos o más actividades en un proceso comparten la misma implementación. En WFs administrativos suele ser habitual que una misma tarea, o por lo menos una tarea muy similar, se repita a lo largo de la estructura. Aunque dichas tareas
2.1. Características de los lenguajes de flujos de trabajo 41 C B A B C A C A 2 de 3 B ELECCIÓN MÚLTIPLE UNIÓN PARCIAL MULTI CHOICE MULTI CHOICE B A C MULTI CHOICE B A C MULTI CHOICE a) b) c) C D A 2 de 3 B C D A DISC. B C A DISC. B C DISCRIMINADOR A B MEZCLA MÚLTIPLE A B C MULTI MERGE C A B A B C MULTI MERGE MULTI MERGE MULTI MERGE C A B A B CMULTI MERGE MULTI MERGE A DISC. B C Figura 2.2: Cuatro patrones avanzados de control sean distintas, bien por sus características bien por su localización dentro del WF, podrían tener la misma implementación. Sin embargo, estos patrones únicamente se refieren a la primera situación. Este grupo de patrones está enfocado a las distintas formas en las que se pueden separar y sincronizar múltiples instancias. Por ejemplo, la Figura 2.3 muestra la estructura del patrón unión parcial para instanciación múltiple (static partial join for multiple instances, en inglés), que trata la ejecución de la actividad con instanciación múltiple como un patrón de control avanzado, de forma que la actividad finaliza cuando dos de sus tres instancias hayan concluido. Control basado en el estado. Algunas situaciones, especialmente aquellas que requieren tener una visión completa de la ejecución del WF, se pueden resolver más
42 2. Lenguajes de modelado de flujos de trabajo A B C UNIÓN PARCIAL PARA MÚLTIPLES INSTANCIAS C C 2 de 3 D A B C C C 2 de 3 D A B C C C 2 de 3 D Figura 2.3: Ejemplo de un patrón para instanciación múltiple fácilmente si el lenguaje permite representar el estado. En este contexto, se considera estado del WF a la instancia del proceso que debería incluir tanto el estado de todas las actividades como a los datos más relevantes del caso. Esta categoría incluye siete patrones en los que el estado actual determina la acción a realizar desde la perspectiva del flujo de control. La Figura 2.4 muestra la estructura de estos patrones: Los dos primeros ejemplos tratan el disparo y unión de un conjunto de hilos de ejecución. Específicamente, el primer patrón, llamado separación hilo de ejecución, permite crear n= 3 hilos de ejecución mientras que el segundo, llamado mezcla hilo de ejecución, permite sincronizar n= 2 hilos de ejecución. El tercer patrón se denomina elección diferida (deferred choice, en inglés) y modela el caso donde la decisión acerca de qué rama ejecutar se basa en la interacción con el entorno operativo del proceso. Al contrario de la elección exclusiva (control básico) no existe un criterio explícito de selección, sino una carrera entre las ramas para ver cuál será elegida. El patrón enrutamiento paralelo alternado (interleaved parallel routing, en inglés) modela una situación donde un conjunto de actividades pueden ejecutarse en un determinado orden parcial pero no al mismo tiempo. El patrón enrutamiento alternado (interleaved routing, en inglés) elimina la ordenación entre las actividades del patrón anterior, de forma que éstas puedan ejecutarse en cualquier orden. El patrón hito (milestone, en inglés) modela una situación donde una tarea estará activa únicamente cuando el WF se encuentre en un determinado estado, que se representa explícitamente en el modelo y se conoce con el nombre de hito. En la Figura 2.4, ese estado está modelado con el círculo que tiene el trazo de guiones.
2.1. Características de los lenguajes de flujos de trabajo 43 F G B A C A C MEZCLA HILO DE EJECUCIÓN A C A C SEPARACIÓN HILO DE EJECUCIÓN 3 SPLIT 2 MERGE 3 SPLIT 2 MERGE A B C ELECCIÓN DIFERIDA DEFERRED CHOICE A C DEFERRED CHOICE Se pueden seleccionar B o C Se seleccionó B A B CStart Interleaving End Interleaving D E La ejecución de Start Interleaving alternará la ejecución de las ramas. ENRUTAMIENTO PARALELO ALTERNADO A B C Start Interleaving End Interleaving D E La ejecución de Start Interleaving alternará la ejecución de las ramas. ENRUTAMIENTO ALTERNADO AND A B E HITO F DEFERRED CHOICE G DC H AND I La actividad F no estará activa hasta que no haya una marca en el hito AND A B SECCIÓN CRÍTICA C AND D H E No puede haber marcas en las dos secciones a la vez Figura 2.4: Patrones de control basados en el estado Finalmente, el patrón sección crítica (critical section, en inglés), permite identificar (sub)grafos del WF como secciones críticas, de forma que podrá estar activa a la vez una única sección crítica. Cancelación. Esta categoría de patrones se utiliza para cancelar la ejecución de una parte o del proceso completo. La Figura 2.5 muestra algunos de los patrones de cancelación:
44 2. Lenguajes de modelado de flujos de trabajo A CANCELAR REGIÓN E B C D AND CANCEL REGION A E B C D AND CANCEL REGION A B C C D CANCELAR INSTANCIA MÚLTIPLE CANCEL A B C C D CANCEL A B C C D COMPLETAR INSTANCIA MÚLTIPLE COMPLETE A B C C D COMPLETE Figura 2.5: Ejemplo de tres patrones de cancelación El patrón cancelar región (region cancellation, en inglés) permite cancelar la ejecución de una determinada región del WF. Se puede observar en la figura cómo la cancelación de la región elimina todas las instancias de ejecución del proceso. El patrón cancelar instancia múltiple (multiple instance cancellation, en inglés) permite eliminar las instancias que se están ejecutando dentro de una tarea de instanciación múltiple. Finalmente, el patrón completar instancia múltiple (multiple instance completion, en inglés) muestra una alternativa al patrón anterior en la que se concluye la tarea de instanciación múltiple posteriormente a la eliminación de las instancias. Terminación. Las redes representadas en la Figura 2.6 muestran las dos únicas opciones mediante las cuales se puede escenificar la finalización de un WF. La primera asume la terminación implícita: la instancia de un proceso debe finalizar cuando se han completado todas las actividades, es decir, cuando no se pueden realizar más actividades ni ahora ni en el futuro, y la instancia del proceso no está en un ciclo mortal. En el ejemplo de la figura se puede ver cómo tras la ejecución de las tareas A yBno se aprecia ninguna marca de ejecución en la red de la derecha, con lo cual se considera la ejecución finalizada. El segundo patrón asume la terminación explícita, y modela expresamente el final del WF a través de un nodo de terminación, de modo que el proceso habrá finalizado cuando se haya alcanzado ese nodo. Esta finalización
2.1. Características de los lenguajes de flujos de trabajo 45 A B TERMINACIÓN IMPLÍCITA A B TERMINACIÓN EXPLÍCITA A B A B A B A B finalización tarea A finalización tarea A finalización tarea B finalización tarea B Figura 2.6: Patrones de terminación implica la cancelación de todo el trabajo relacionado con la instancia del proceso independientemente de si alguna de las tareas aún está en ejecución. En la Figura 2.6 se modela esta clase de terminación con un círculo. Iterativo. Estos patrones permiten modelar estructuras iterativas. Específicamente, se definen tres clases de bucles: estructurados, arbitrarios y recursivos. Los bucles estructurados son los más conocidos, ya que representan estructuras típicas de programación. Esta clase incluye entre otros a los bucles tipo repetir-mientras orepetir-hasta. La segunda clase, denominada bucles arbitrarios, representa estructuras iterativas donde el bucle puede tener más de un punto de entrada y más de un punto de salida. No tiene una correspondencia directa con ninguna instrucción de programación pero existe una cierta similitud entre este patrón y la combinación de instrucciones tipo goto utilizadas en programación no estructurada. Finalmente, la última clase representa la habilidad de una actividad de (auto)invocarse o de invocar a un antecesor en términos estructurales. La Figura 2.7 representa gráficamente los distintos tipos de patrones. Control basado en eventos. El inicio de una actividad puede requerir la intervención de una señal/evento externo. Los dos tipos de patrones que pertenecen a esta categoría se distinguen si el disparador de la señal es transitorio o permanente. La Figura 2.8 representa estos dos patrones. En la parte superior representa un caso de uso del patrón evento externo transitorio (transient trigger, en inglés). Se observa en la parte izquierda del ejemplo que la ocurrencia del evento no se almacena y al no estar activa la tarea C, el evento se pierde. En cambio, se puede advertir en el ejemplo del patrón evento externo transitorio (persistent trigger, en inglés) cómo el WF mantiene el evento incluso no estando activa la tarea C. Así, cuando finalmente se ejecute la tarea C, el evento podrá aplicarse a la tarea. 2.1.1.2. Patrones de datos Estos patrones modelan la utilización de los datos en los WFs y se corresponden con una revisión de los patrones presentados en [219, 216]. Dentro del contexto de un proceso, los datos pueden definirse y utilizarse de muchas formas, y por ello es necesario modelar aspectos como: Visibilidad. Típicamente, la visibilidad de unos datos suele estar restringida a una
46 2. Lenguajes de modelado de flujos de trabajo A BUCLE ESTRUCTURADO MERGE B C REPEAT D E A BUCLE REPETIR-MIENTRAS WHILE XOR BC D A BUCLE REPETIR-HASTA XOR B C REPEAT A BUCLE CICLOS ARBITRARIOS XOR B E XOR CXOR D DXOR B RECURSIÓN A C XOR D DEFERRED CHOICE A La tarea A se invoca a sí misma Figura 2.7: Patrones que modelan estructuras iterativas A B EVENTO EXTERNO TRANSITORIO C EVENTO se ejecuta el evento Al no estar activa la tarea C, el evento se piede A B C EVENTO La tarea C no puede ejecutarse hasta que vuelva a suceder el evento externo A B EVENTO EXTERNO PERMANENTE C EVENTO se ejecuta el evento Se mantiene la ejecución del evento a lo largo del tiempo A B C EVENTO Al mantener el event, la tarea C podrá finalizar su ejecución en el siguiente ciclo Figura 2.8: Patrones de control basado en eventos tarea, un bloque, un caso o al propio WF. La Figura 2.9 muestra estos cuatro principales tipos de visibilidad. La zona coloreada en gris circunscribe la zona en la que las
2.1. Características de los lenguajes de flujos de trabajo 47 A B C D E F A B D A B C D E F A B D A B C D E F A B D bloque instanciación múltiple caso flujo de trabajo (sub)flujo de trabajo A B C D E F A B D VISIBILIDAD DE FLUJO DE TRABAJO VISIBILIDAD DE BLOQUEVISIBILIDAD DE TAREA VISIBILIDAD DE CASO bloque instanciación múltiple caso flujo de trabajo (sub)flujo de trabajo bloque instanciación múltiple caso flujo de trabajo (sub)flujo de trabajo bloque instanciación múltiple caso flujo de trabajo (sub)flujo de trabajo Figura 2.9: Patrones de visibilidad variables están visibles. Los datos con visibilidad de WF son accesibles desde cualquier caso (o instancia de ejecución), tarea, construcción de control o (sub)flujo. Cuando la visibilidad se restringe al caso, los datos serán accesibles por parte de todas las tareas, construcciones de control y (sub)flujos que estén participando en la ejecución del caso. Si los datos tienen visibilidad de tarea, sólo serán accesibles dentro de la tarea. Finalmente, la visibilidad de bloque se refiere al acceso a los datos de una tarea cuando ésta se resuelve mediante un (sub)flujo. La accesibilidad a los datos no se restringe a estos elementos y se definen patrones de visibilidad para otros elementos herencia de los sistemas tradicionales de WFs: Ámbitos. Comparten datos entre un conjunto de tareas Carpetas. Comparten datos entre distintos casos Entornos. Se refieren a los datos disponibles en repositorios, servicios y aplicaciones externas que podrán ser accedidos por los elementos del WF. Interacción. Los patrones de interacción tratan las distintas formas en las que se pueden pasar datos entre distintos componentes de un proceso y cómo las características de los componentes pueden llegar a influenciar la forma en la que se produce el
48 2. Lenguajes de modelado de flujos de trabajo pasar(X,Y) pasar(X) pasar(Y) A usar(X,Y) B usar(X) C usar(Y) A usar(X,Y) B usar(X) C usar(Y) A usar(X,Y) B usar(X) C usar(Y) pasar(Y) Datos globales compartidos variable X variable Y MISMO CANAL DE DATOS Y CONTROL DISTINTO CANAL DE DATOS Y CONTROL DATOS GLOBALES Y COMPARTIDOS Figura 2.10: Patrón de interacción entre dos tareas tránsito de la información. Se pueden distinguir dos tipos de patrones de interacción. El primer tipo trata la comunicación entre componentes de un mismo proceso, por ejemplo, entre dos tareas, dos casos o entre un bloque y un (sub)WF. Por ejemplo, la Figura 2.10 muestra las tres posibles formas de comunicación entre dos tareas: compartiendo un mismo canal (o bus de comunicaciones), compartiendo un canal para datos y otro canal para el control, y compartiendo la misma zona de datos. El segundo tipo de patrones trata la interacción entre un componente de un proceso y un entorno externo, por ejemplo, entre una tarea y el entorno, entre el WF y el entorno, y viceversa. Básicamente se definen dos tipos de interacción, subir y bajar (push y pull, en inglés) , dependiendo del elemento que inicie la comunicación. Transferencia. Los patrones de transferencia tratan la forma en la que se pasan los datos entre componentes de un proceso. El patrón transferencia de entrada por valor permite pasar los datos de entrada de una tarea por valor evitando la necesidad de tener nombres compartidos o espacios de direcciones comunes entre el componente que manda y el componente que recibe. De la misma forma, el patrón transferencia de salida por valor permite el pase de datos por valor al siguiente elemento del WF. Por el contrario, los patrones transferencia por referencia con bloqueo ytransferencia por referencia sin bloqueo tratan el pase de parámetros por referencia, es decir, mediante el pase de una referencia a la localización del dato en algún dispositivo accesible por el emisor y el receptor. Ambos patrones se diferencian en las restricciones de concurrencia establecidas respecto a los datos compartidos. Así, el primer patrón establece un acceso dedicado al receptor de forma que los demás elementos del WF que accedan a ese mismo dato tengan acceso de sólo lectura. Otro patrón, denominado transferencia por copia permite (i) copiar los valores de un conjunto de datos desde una fuente externa a un espacio de direcciones y al finalizar la ejecución de la tarea
2.1. Características de los lenguajes de flujos de trabajo 49 (ii) volver a copiar los datos con sus valores finales nuevamente a la fuente externa. Finalmente, los dos últimos patrones de esta categoría se refieren a la transformación de los datos justo antes de la transferencia más que al propio proceso de transferencia. Por un lado, el patrón transformación de entrada se refiere a la transformación de los datos justo antes de ser pasados a la tarea. Por el otro, el patrón transformación de salida se refiere a la transformación de los datos justo antes de ser pasados al siguiente elemento del WF. Enrutamiento basado en datos. Los patrones de enrutamiento describen la influencia de los datos en la toma de decisiones de control. Varios de los patrones de esta categoría tratan los tipos de precondiciones y postcondiciones más utilizados en los WFs: el patrón precondición - existencia dato verifica la disponibilidad de algún dato antes de la ejecución de la tarea; el patrón precondición - valor dato verifica si un dato tiene un determinado valor en tiempo de ejecución; los patrones postcondición - existencia dato ypostcondición - valor dato tienen el mismo significado que en el caso de las precondiciones pero en este caso aplicado al completarse la tarea. Otros dos patrones de esta categoría tratan la forma de disparar/iniciar las tareas. El primero de ellos, denominado disparo de tarea por evento se refiere al comienzo de la tarea a partir de un evento externo y de los datos que ese evento le proporciona a la tarea. El segundo, denominado disparo de tarea por dato, se refiere al comienzo de la tarea cuando una determinada expresión basada en los datos de la instancia del proceso se evalúa a verdadero. Finalmente, el último patrón de esta categoría, denominado enrutamiento basado en datos alude al enrutamiento de los elementos de control de los WFs. Este patrón se refiere a las expresiones que algunos elementos de control pueden utilizar para tomar sus decisiones. Por ejemplo, los criterios de selección de un patrón de control básico como la elección exclusiva o el patrón avanzado conflicto (or split, en inglés). 2.1.1.3. Patrones de organización Estos patrones, también llamados patrones de recursos [225, 217], están centrados en el modelado de los recursos, independientemente de si son humanos o software, y en su interacción con los sistemas de gestión de procesos de negocio. Esta categoría está compuesta por los siguientes tipos de patrones: Creación. En este tipo de patrones se definen limitaciones en la forma en la cual se puede ejecutar un trabajo. Estas limitaciones se refieren, por un lado, al tipo de recurso que puede realizar la tarea y, por el otro, a los criterios de distribución del trabajo. En términos del ciclo de vida de un trabajo, los patrones de creación se ejecutan en el momento en el que se crea el trabajo. Por ejemplo, la Figura 2.11 muestra los estados por los que tiene que pasar el trabajo. Como se puede apreciar, la fase de creación es la primera en ejecutarse. La ejecución de la actividad CREAR ejecutará un determinado patrón que definirá el modelo organizativo en el que se identificarán unívocamente los recursos y el mecanismo de distribución del trabajo entre los recursos identificados en el modelo organizativo. Estos patrones se suelen especificar en tiempo de diseño, donde se define el modelo de distribución a la vez que
56 2. Lenguajes de modelado de flujos de trabajo 2.2.1.1. Variantes de redes de Petri Las redes de Petri clásicas son extremadamente útiles para la especificación y simulación de procesos complejos que requieran paralelismo y concurrencia de procesos. Sin embargo, su complejidad crece significativamente cuando se utilizan para modelar procesos complejos. Por ello, se han creado distintas variantes que permiten modelar de forma más sencilla a sistemas más complejos. Las extensiones, comúnmente denominadas redes de Petri de alto nivel, más aplicadas al modelado de WFs son: Redes de Petri coloreadas [149]. Estas redes permiten modelar la identidad de las marcas asociándoles un valor denominado color. Esto facilita una descripción más detallada de los objetos utilizados en los WFs. La red de la Figura 2.16 muestra un ejemplo de red de Petri coloreada. En ella puede verse que las plazas están tipadas, de forma que únicamente puedan almacenar objetos de su tipo. Por ejemplo, las marcas aybalmacenadas en la plaza p1tienen el tipo ColorA y se pueden utilizar para expresar condiciones, recursos o un simplemente un caso de un WF. Además, las transiciones y los arcos de la red están anotados con una expresión algebraica para razonar con esos colores: •Los arcos están anotados por multiconjuntos de términos, de modo que durante la evaluación de la expresión, cada uno de los elementos de ese multiconjunto deberá parearse con una de las marcas almacenadas en la red. Por ejemplo, el arco entre la plaza p1y la transición t1está anotado con el multiconjunto x+y. En este caso, tanto xcomo yson variables y podrán tomar durante la ejecución el valor x=aey=box=bey=a. Los arcos también pueden estar anotados por términos más complejos como, por ejemplo, la función f(x) entre la transición t2y la plaza p3. •Las transiciones pueden tener condiciones de activación que se evalúan a partir de las marcas almacenadas en sus plazas de entrada. Por ejemplo, la transición t1está anotada con la precondición (x=a∧x=b)∨(y= a∧y=b). Redes de Petri con tiempo [288]. Las redes de Petri básicas no son lo suficientemente expresivas para estudiar el rendimiento de un sistema, ya que no realizan ninguna asunción acerca de la duración de las actividades del sistema. Respondiendo a esta necesidad, varias propuestas extendieron las redes de Petri con tiempo. Las redes de Petri con tiempo (TPN del inglés Timed Petri Nets). Estas redes pueden dividirse en dos clases: TPN determinísticas, en las cuales a cada transición, plaza o arco se le asocia un tiempo de ocurrencia o intervalo de tiempo determinístico, y las TPN estocásticas, en las cuales cada transición tiene asociado un tiempo de ocurrencia aleatorio. Tanto las TPN determinísticas como las estocásticas son aplicadas en un amplio rango de aplicaciones que, principalmente, apuntan a la evaluación de sistemas dinámicos de eventos discretos. Por ejemplo, las TPN determinísticas se han utilizado con éxito para derivar el tiempo de producción, identificar cuellos de botella, verificar
2.2. Formalismos de representación de los lenguajes de flujos de trabajo 57 p1t1p2 x+y x+y a b ColorA ColorA [(x=a and y=b) or (x=b and y=a)] t2p3 x f(x) ColorB Multiconjunto de términos ( en este caso variables) Las plazas están anotadas con un color ( parte superior del círculo) Los arcos también pueden estar anotados con funciones: f:ColorA →ColorB Las transiciones tienen precondiciones Figura 2.16: Ejemplo de red de Petri coloreada restricciones temporales, etc; mientras que las TPN estocásticas también se han conseguido aplicar con éxito a la obtención de ratios de productividad, al análisis del rendimiento y de la demora, etc. Redes de Petri jerárquicas [149, 120]. Estas redes permiten componer redes más complejas a partir de otras más sencillas. Los elementos de composición suelen ser las plazas o las transiciones que ahora adoptan una semántica más compleja. Estos nodos pueden representar a otra red haciendo más fácil crear, mantener y entender modelos complejos. En el Capítulo 3 se detallarán los mecanismos que permiten crear y componer redes jerárquicas. 2.2.1.2. Ventajas de usar redes de Petri Muchos investigadores han defendido el uso de las redes de Petri para el modelado de WFs [255, 98, 227]. Una de las principales ventajas de las redes de Petri respecto a otros formalismos es su legibilidad: al disponer de una representación gráfica relativamente sencilla, los diseñadores pueden crear sus procesos sin necesidad de apoyo por parte de expertos en redes de Petri. Además, la expresividad es otro de sus puntos fuertes. Son sistemas Turing completo (si se asume la no existencia de límites tecnológicos), lo cual implica que se pueden utilizar para emular máquinas de Turing y, por lo tanto, para realizar cualquier tipo de cálculo. Otras importantes razones son [255]: 1. Al tener una semántica formal (i) la especificación del WF no es ambigua, (ii) la interpretación está definida matemáticamente y, por lo tanto, no depende de la implementación de una herramienta, y (iii) es posible razonar acerca de las propiedades del WF especificado. Existen muchas técnicas de análisis para verificar ciertas propiedades cualitativas y cuantitativas de los modelos de WFs basados en redes de Petri. Dentro de las cualitativas destacan la comprobación
58 2. Lenguajes de modelado de flujos de trabajo de la existencia de ciclos mortales, el análisis de la alcanzabilidad de cada transición, o la comprobación de los límites de marcas en cada una de las plazas. Respecto a las propiedades cuantitativas, es posible verificar algunas medidas de rendimiento como los tiempos de respuesta, de espera o los ratios de ocupación de los recursos. 2. Estas redes modelan explícitamente el estado, lo cual es de gran utilidad para el modelado de los WFs, ya que: Permite diferenciar entre la activación y la ejecución de una tarea; una tarea debe estar activa antes de ejecutarse, sin embargo la activación no implica que vaya a ejecutarse necesariamente. Esta diferenciación posibilita que la ejecución de una tarea pueda esperar por un determinado evento, por ejemplo, una acción del usuario, un mensaje externo o simplemente un evento temporal. Permite modelar la competición entre las tareas. Dos tareas que utilizan los mismos recursos (modelados como plazas) pueden estar activas al mismo tiempo; sin embargo, solamente una de ellas se ejecutará. Permiten cancelar la ejecución de casos eliminando las marcas de las plazas. En entornos distribuidos permite transferir los casos en ejecución de un sistema a otro simplemente transfiriendo las marcas de las plazas. Permite que los sistemas sean reactivos a cambios en el entorno. Por ejemplo, definiendo eventos externos que cambien el estado de la ejecución. El modelado del estado es una gran diferencia con respecto a los marcos conceptuales basados en eventos (como π-calculus), los cuales modelan únicamente las transiciones entre los distintos estados, por lo que no pueden acceder al estado y por ello carecen de las ventajas descritas anteriormente. 2.2.1.3. Inconvenientes de usar redes de Petri Aunque la expresividad es un punto fuerte de estas redes, esta afirmación no es relevante desde un punto de vista práctico, ya que se podría afirmar lo mismo de un lenguaje de programación: la clave no está sólo en la expresividad, sino también en lo complejo que sea lograrla. Por ello, aunque estas redes pueden representar cualquiera de los patrones de comportamiento descritos en el apartado 2.1.1.1, existen algunos inconvenientes a la hora de definir WFs mediante redes de Petri [261]: Aunque se puede usar el color para identificar múltiples instancias de un (sub)- proceso, por ejemplo asociando un identificador de la instancia de ejecución al color, no existe un soporte específico para patrones de instanciación múltiple. En estos casos, el diseñador debe soportar las redes para soportar el funcionamiento de los patrones de control a la instanciación múltiple.
2.2. Formalismos de representación de los lenguajes de flujos de trabajo 59 p1 t1p3 En este estado, la transición t1no puede ocurrir porque la plaza p2no tiene marcas: p2 MEZCLA Figura 2.17: El patrón mezcla simple no puede resolverse con una transición normal p1t1 p3 p2 t2 t3 En este estado, la transición t1podría ocurrir ya que el arco inhibidor entre la plaza p 2 y la transición estaría activo: Figura 2.18: Solución al patrón mezcla simple utilizando arcos inhibidores Algunos patrones de sincronización son difíciles de modelar a través de redes de Petri debido a la regla de transición. Por ejemplo, el patrón de mezcla simple tiene un comportamiento contrario a la regla de transición. Para dar soporte a este patrón no vale una simple red como la representada en la Figura 2.17, ya que la regla de transición requiere que las dos plazas p1yp2tengan al menos una marca. Es, por lo tanto, necesario adecuar la red para dar soporte al comportamiento especificado en el patrón. Una solución es añadir arcos inhibidores a la red, en los que la ausencia de marcas es la que activa la transición, y no la presencia de marcas, como sucede en los arcos normales. Por ejemplo, en la Figura 2.18 puede apreciarse la representación del patrón mezcla simple utilizando arcos inhibidores (en lugar de una flecha tienen un círculo). La ocurrencia de una transición es siempre local: se basa en las marcas localizadas en las plazas de entrada y afecta a las plazas de salida. Sin embargo, en un WF algunos eventos pueden tener efectos que no son locales. Por ejemplo, un error puede implicar el eliminar marcas de un conjunto de plazas sin saber a priori en qué plazas están las marcas. El modelado de este tipo de patrón de cancelación es un proceso engorroso, ya que requiere conectar todas esas plazas al mecanismo de cancelación. 2.2.2. Pi-calculus Pi-calculos (π-calculus) es un álgebra de procesos desarrollada por Robin Milner, Joachim Parrow and David Walker [180] que da continuación al cálculo de procesos CCS (del inglés Calculus of Communicating Systems) [179]. El objetivo de π-calculus es permitir la descripción de computaciones concurrentes cuya configuración puede cambiar durante la ejecución. Es un formalismo que permite la representación, simulación, análisis y verificación de sistemas móviles de comunicación. Un sistema representado mediante π-calculus, consta de múltiples procesos concurrentes que están agrupados
60 2. Lenguajes de modelado de flujos de trabajo en parejas y que pueden enviar y recibir mensajes de forma sincronizada. Esta comunicación se realiza sobre canales de entrada y salida, de modo que cuando un proceso recibe un mensaje, también recibe el canal para enviar sus respuestas. Esta característica, llamada movilidad, permite que las conexiones de la red cambien con las interacciones realizadas, es decir, se producen cambios dinámicos en la topología de la comunicación. Un proceso π-calculus es una entidad autónoma que posee puertos, para comunicarse con otros procesos, y que se representa de la siguiente forma: proceso(lista de puertos) = comportamiento De forma más detallada π-calculus define los siguientes elementos: Los nombres representan conceptos como los enlaces, los punteros, las referencias, los identificadores, etc. y donde cada nombre tiene un ámbito de aplicación. Los procesos se definen como: P::= M|P|P′|(vz)P|!P donde con Mse indica la evaluación de una expresión; con P|P′que los procesos PyP′son hebras ejecutadas de forma concurrente; con vzP que se aplicará una restricción vzal proceso P; y finalmente con !Pse representa que el proceso Pserá replicado, es decir, se ejecutará repetidas veces. Las expresiones pueden tomar los siguientes valores: M::= 0 |π.P |M+M′ donde el símbolo 0 representa un proceso especial, denominado nil, cuya ejecución es completa y ha finalizado; con π.P se indica que la aplicación de un determinado prefijo al proceso P; y con M+M′se representa una operación de elección entre los procesos MyM′, es decir, que únicamente uno de los dos procesos se ejecutará. Los prefijos se indican como: π::= xy |x(z)|τ|[x=y]π donde con xy se describe que el mensaje yse emitirá en el canal x(es decir, las entradas del proceso); con x(z) se representa que el mensaje zse recibe en el canal de comunicaciones x(las salidas del proceso); con τse indica una acción a realizar; y finalmente con [x=y]πse describe la condición [x=y] que el prefijo πdebe cumplir. La Figura 2.19 muestra la representación de un bucle tipo ciclos arbitrarios mediante una representación gráfica y su correspondiente representación en π-calculus. Puede apreciarse cómo cada uno de los rectángulos se corresponde con un proceso.
2.2. Formalismos de representación de los lenguajes de flujos de trabajo 61 A B D a b c d C A=!a.τA.b.0 B=!b.τB.c.0 C=!c.τC.(a.0 + d.0) D=d.τD.D′ Figura 2.19: Representación de un bucle de tipo ciclos arbitrarios en π-calculus 2.2.2.1. Ventajas de usar π-calculus Aunque en menor número que en el caso de las redes de Petri, muchos autores han defendido el uso de π-calculus para el modelado de WFs [234]. Con π-calculus también se pueden emular máquinas de Turing y, por lo tanto, implementar cualquier tipo de cómputo. Además, al ser un formalismo, tienen la ventaja de tener una semántica no ambigua. También disponen de herramientas de análisis, aunque en menor medida que las redes de Petri. 2.2.2.2. Inconvenientes de usar π-calculus El principal inconveniente de π-calculus es su falta de legibilidad. π-calculus es un lenguaje basado en texto que no tiene una notación gráfica estándar y incluye un conjunto mínimo de constructores/primitivas. Ello fuerza al diseñador a construir largas y complejas cadenas de texto que pueden llevarle a la equivocación. Por ejemplo, la Figura 2.19 muestra un típico bucle repetir-hasta y su código π-calculus asociado. Como se puede apreciar en la imagen, la legibilidad de la representación basada en texto es mucho menor. Aunque se pueden definir construcciones más complejas partiendo de π-calculus [181], todo el esfuerzo recae en el diseñador que debe tener sólidos conocimientos de π-calculus. Algunos lenguajes extienden π-calculus y definen sus propias construcciones para facilitar este paso, pero el manejo de estos lenguajes sigue siendo exclusivo para programadores. Debido a este inconveniente, la mayoría de los lenguajes o sistemas de WFs que fundamentan su ejecución en este formalismo utilizan un lenguaje gráfico para facilitar la representación del WF, y establecen las correspondencias con π-calculus en [306]. Sin embargo, con esta combinación, aunque se gana en legibilidad, se pierde en expresividad, ya que π-calculus queda restringido a la capacidad expresiva del lenguaje gráfico. Otro importante inconveniente de π-calculus es que no permite modelar el estado del WF. En este sentido, l os sistemas basados en π-calculus son reactivos, es decir, reaccionan ante eventos externos y no guardan el estado. Así, su expresividad es menor comparada con las redes de Petri, ya que no permite modelar los patrones de estado. 2.2.3. Máquinas de estados abstractos Las máquinas de estados abstractos (ASMs, del inglés Abstract State Machines) son máquinas de estado desarrolladas por Gurevich [124] que permiten operar en estados
62 2. Lenguajes de modelado de flujos de trabajo que manejan un conjunto de datos junto con una serie de funciones y relaciones que operan sobre los datos. Las ASMs tienen una base matemática sencilla y proporcionan una forma intuitiva de pseudo-código sobre datos abstractos. Por ello, la principal aplicación de este formalismo consiste en el modelado e implementación de la semántica de lenguajes como Prolog [39], C++ [287], Java [40] o BPEL [102]. Sin embargo, en los últimos años este método se ha aplicado a varios proyectos relacionados con el modelado de servicios web, WFs y procesos de negocio [41]. Una máquina secuencial ASM se define como un conjunto de reglas de transición con la siguiente forma: if Condition then Updates donde: Condition es una fórmula de primer orden, libre de variables, que representa la condición de guardia que debe satisfacerse para que la regla sea aplicable. Update es un conjunto finito de funciones f(t1,...,tn) := tdonde los términos tino contienen variables. En cada estado, todas las reglas aplicables se ejecutan simultáneamente para producir el siguiente estado. Además, también introduce instrucciones típicas de lenguajes funcionales como let ... in, para dar soporte al no determinismo: choose xwith φrule o para tratar el paralelismo síncrono en la ejecución de reglas ASMs: forall xwith φdo rule forall xwith φuntil rule El siguiente código muestra la representación de un bucle tipo ciclos arbitrarios mediante ASMs: forall a∈Activity Iterate(a) until StopCriterion(a) La notación que aparece está simplificada de acuerdo a la sintaxis introducida en [37]. 2.2.3.1. Ventajas de usar ASMs En los últimos años, varios autores han defendido el uso de las ASMs para el modelado de WFs [37]. Este formalismo ha probado su validez para el modelado y validación de la semántica operacional de varios lenguajes de programación y en lenguajes de procesos como por ejemplo BPEL [102]. Otra aportación relevante es la semántica operacional en ASMs para el modelado de procesos descritos mediante el lenguaje BPMN [41]. Como veremos en el apartado 2.3.1, BPMN (Business Process Modeling Notation) es el estándar OMG para la representación gráfica de procesos.
2.3. Lenguajes de representación 63 Las ASMs tienen la ventaja de ser muy expresivas, tener una semántica no ambigua y de disponer de herramientas para la validación. Respecto a este último punto, destacan en la detección de errores en las fases iniciales del desarrollo, donde la verificación, simulación y la prueba son menos costosas de aplicar. 2.2.3.2. Inconvenientes de usar ASMs Al igual que π-calculus, el principal problema de las ASMs es su falta de legibilidad. Además, su legibilidad se reduce a medida que se añaden reglas al modelo. Debido a este problema, este formalismo únicamente se usa para dar soporte a la ejecución de WFs. Los sistemas que lo implementan usan por ello un lenguaje de representación gráfica para facilitar la creación de los WFs y establecen las correspondencias con la semántica de las ASMs. 2.3. Lenguajes de representación Aunque no existan lenguajes formales creados específicamente para modelar WFs, sí existen modelos de representación directamente pensados para WFs. Algunos son modelos gráficos pensados exclusivamente para facilitar la labor del diseño, otros son adaptaciones de modelos tradicionalmente utilizados en la ingeniería del software, y finalmente unos pocos están ideados dentro de un escenario de intercambio electrónico de WFs. Algunos de estos lenguajes están por completo orientados a la descripción gráfica y, por lo tanto, carecen de una interpretación que les permita ser ejecutables. Sin embargo, a medida que estos modelos han adquirido importancia, han aparecido traductores que permiten trasladar la representación gráfica de estos lenguajes a un modelo u otro lenguaje ejecutable. Dentro de esta categoría las principales aportaciones son los lenguajes BPMN, UML y XPDL. 2.3.1. BPMN El lenguaje BPMN [197] (del inglés Bussiness Process Modeling Notation) es un estándar de notación de proceso publicado en el año 2003 por el Object Management Group2. Permite definir diagramas de procesos BPD (del inglés Business Process Diagram), que tienen como objetivo crear un modelo gráfico de las operaciones del proceso de negocio. Esto ha propiciado que BPMN haya sido combinado con otros lenguajes que pueden interpretar su representación gráfica como BPML, XPDL o BPEL [197, 232]. La Figura 2.20 muestra las categorías y los elementos básicos de BPMN: Objetos de flujo. Un BPD tiene únicamente tres componentes con los que se puede modelar un flujo de trabajo: 2http://www.bpmi.org
64 2. Lenguajes de modelado de flujos de trabajo Eventos Actividades Pasarelas Objetos de flujo Objetos de Conexión Swimlanes ( Calles de piscina) Artefactos Flujo de secuencia Flujo de mensajes Asociación Agrupación Calle/Carril Las anotaciones permiten que el diseñador aporte información adicional Grupo Anotación Objeto de datos Inicial Intermedio Final Tarea (Sub)Proceso XOR XOR-E OR AND Basado en evento Complejo Figura 2.20: Elementos básicos del lenguaje BPMN •Eventos. Representan un suceso en el curso del proceso de negocio. Afectan al flujo del proceso y normalmente tienen una causa (disparo) y un impacto (resultado). Existen tres tipos de eventos en función del momento en el que afecten al flujo: iniciales, intermedios y finales. •Actividades. Es un término genérico para referirse al trabajo a realizar. Cuando una actividad es atómica se denomina tarea mientras que si es compuesta se denomina (sub)proceso. •Pasarelas. Son los componentes o construcciones de control. BPMN contiene seis componentes: xor,xor explícito,and,or,complejo ybasado en evento. Objetos de conexión. Los objetos de flujo están interconectados para definir la estructura del proceso de negocio. BPMN define para ello tres tipos de objetos de conexión: •Secuencia de flujo. Se utiliza para mostrar el orden (secuencia) de actividades que se van a realizar en el proceso. •Flujo de mensajes. Muestra el envío y recepción de mensajes entre dos participantes del proceso (entidades o roles de negocio). Dichos participantes se representarán por medio de dos agrupaciones diferentes. •Asociación. Se utiliza para asociar datos, texto u otro artefacto con los objetos de flujo, permitiendo mostrar las entradas y salidas de las actividades.
2.3. Lenguajes de representación 65 Seleccionar película , butaca e introducir forma de pago Recibir reserva Comprobar reserva Aceptar cheque o metálico Procesar tarjeta de crédito Enviar entrada de cine Tarjeta de crédito Cheque o metálico Forma de pago ? Recibir entrada Distribuidor de entradas Cliente a) Solicitar entrada b) Enviar entrada Figura 2.21: Ejemplo simplificado de compra de una entrada de cine representada mediante un diagrama BPMN Calles o carriles de piscina (swimlanes, en inglés). Muchas metodologías de modelado de procesos utilizan el concepto de swimlane para organizar las actividades en categorías separadas, de forma que puedan ilustrar sus diferentes funciones o responsabilidades. BPMN soporta este concepto mediante dos construcciones: •Agrupación (pool, en inglés). Representa un participante del proceso, aunque también puede actuar como un contenedor de actividades. •Calle o carril (lane, en inglés). Es una (sub)partición dentro de una agrupación, y se utilizan para organizar y categorizar actividades. Artefactos. Son elementos cuya funcionalidad es dar flexibilidad de notación para identificar o describir elementos gráficos. BPMN define tres componentes principales, aunque esta parte del estándar está abierta: •Objeto de datos. Son un mecanismo para mostrar los datos requeridos o producidos por una actividad. Se conectan a las actividades mediante asociaciones. •Anotación. Permite al diseñador añadir información adicional acerca del diagrama. •Grupo. Se utiliza para agrupar elementos de cara a mejorar la documentación o el análisis, pero no tiene un significado dentro del proceso ni afecta al flujo de secuencia. La Figura 2.21 muestra un ejemplo de reserva de entradas de cine representado mediante BPMN. El diagrama contiene dos agrupaciones para distinguir los dos roles del modelo, es decir, los clientes y el distribuidor de entradas. Dentro de la agrupación del cliente puede verse cómo selecciona la película y la butaca, e introduce la forma
72 2. Lenguajes de modelado de flujos de trabajo Cliente Recibir reserva Comprobar reserva Aceptar cheque o metálico Procesar tarjeta de crédito Enviar entrada de cine Recibir entrada Distribuidor de entradas Seleccionar película , butaca e introducir forma de pago Figura 2.23: Ejemplo simplificado de compra de una entrada de cine representada mediante un diagrama UML conocido tanto por desarrolladores como diseñadores. Con respecto a otros lenguajes de representación, los puntos fuertes de estos diagramas son [215]: Soporte del concepto de envío y recepción de señal al nivel conceptual. Soporte de la descomposición de una actividad en (sub)actividades (BPMN y XPDL también soportan esta característica). La combinación de estas dos propiedades es un poderoso mecanismo para manejar la interrupción de actividades y con ello facilitar el desarrollo de los patrones de cancelación. Con respecto a los patrones de datos, UML soporta datos con visibilidad de tarea, de bloque, instancias múltiples y de WF. El único problema de UML respecto a este tipo de patrones es que no da cuenta de la visibilidad de caso, sobre todo teniendo en cuenta que los WFs están diseñados para dar soporte a casos de ejecución. El hecho de que el principal propósito de los diagramas de actividad no sea el modelado de WFs puede ser una causa de este problema. Además, UML permite modelar la interacción entre tareas, (sub)tareas (bloques) e instancias múltiples. Desde el punto de vista de la transferencia, al estar basado en la teoría de objetos, sólo permite el pase de parámetros por referencia. Finalmente, respecto a los patrones de enrutamiento, UML es el más completo de los lenguajes y únicamente no soporta el disparo de tareas
2.3. Lenguajes de representación 73 en base a valores de datos (la dinámica de la orientación a objetos está guiada por eventos). UML también da soporte a los mismos patrones de organización que BPML, es decir, permite una asignación directa y basada en roles (especificados a través de las calles de piscina). 2.3.2.2. Inconvenientes de usar UML A pesar del marco formal proporcionado por los diagramas de Harel [127], las características específicas de los diagramas de actividad de UML sólo están parcialmente formalizadas (a través de expresiones OCL) y su descripción es en lenguaje natural, dejando ambiguos muchos conceptos [91]. Aunque la definición de una semántica precisa de UML es sujeto de un intenso debate e investigaciones, los diagramas de actividades han recibido poca atención a este respecto [100, 38]. Además, algunos inconvenientes de los diagramas de actividad son: Algunos constructores no tienen una sintaxis ni una semántica precisa. No permiten representar algunos patrones básicos de sincronización como los discriminadores o las uniones múltiples. No tienen un formato de fichero estándar, de forma que es difícil trasladar su semántica gráfica a un lenguaje de ejecución. 2.3.3. XPDL El lenguaje XPDL [295] (del inglés, XML Process Definition Language) es un estándar de intercambio de ficheros definido por la Workflow Management Coalition3(WfMC). Este modelo fue inicialmente diseñado para intercambiar el diseño de procesos de negocio entre distintas herramientas. El punto de partida de XPDL es un conjunto mínimo de construcciones presente en la mayoría de productos de WFs. El metamodelo de procesos de XPDL está representado en la Figura 2.24 y está compuesto por los siguientes elementos: Aplicación (clase Application). Permite especificar aplicaciones/herramientas externas invocadas desde los procesos. Proceso (lase Process). Permite definir procesos o partes de un proceso, que se compone de dos tipos de elementos: •Actividad (clase Activity) es el componente principal de un proceso y se refiere a la realización de algún trabajo. Hay cinco tipos de actividades: 3http://www.wfmc.org
74 2. Lenguajes de modelado de flujos de trabajo Process Type Declaration Data Field (Property) Application Activity ActivitySet (Sub-Process) Transition (Sequence Flow) Participant LanePool uses uses uses performer performer from to reference Task/Tool Route Gateway SubFlow BlockActivity Event Figura 2.24: Metamodelo de proceso de XPDL ◦Las rutas (clase Route) son actividades vacías que no realizan ningún trabajo y que simplemente se utilizan con propósitos de enrutamiento. ◦Las implementaciones (clase Task/Tool) son actividades atómicas que se implementan con procedimientos automáticos o manuales y que no se descomponen. ◦Los bloques (clase BlockActivity) son un conjunto o agrupación de actividades y/o transiciones. Todos los elementos del bloque comparten el mismo espacio de nombres. ◦Los (sub)flujos (clase SubFlow) son contenedores para la ejecución de otro proceso. Este proceso puede ejecutarse localmente dentro del mismo servicio o (a través de la interfaz de interoperabilidad) en un servidor remoto y define sus propias actividades, transiciones, recursos y asignaciones. ◦Los eventos (clase Event) afectan a la ocurrencia/disparo de la actividad y a la ruta que puede tomar. •Transición (clase Transition) permite conectar actividades. Se usan para
2.3. Lenguajes de representación 75 AND A B C SEPARACIÓN <Activity> <Implementation/> ... <TransitionRestriction> <Split Type="AND"/> </TransitionRestriction> … </Activity> Figura 2.25: Representación en XPDL de una separación establecer restricciones y condiciones como por ejemplo separar o sincronizar actividades o definir actividades concurrentes. Las restricciones (clase TransitionRestriction) son las que manejan el enrutamiento entre las actividades. Dentro de esta clase podemos destacar a las clases Split yJoin que dan soporte a la separación y sincronización de actividades. Como se puede apreciar en la parte derecha de la Figura 2.25, el comportamiento de la separación (o de la unión) se establece a través del atributo Type que puede tomar los valores AND,OR yXOR. Participante (clase Participant). Especifica los participantes del WF, es decir, las entidades encargadas de realizar el trabajo. Existen seis tipos de participantes: conjunto de recursos,recurso,rol,unidad organizativa,humano ysistema. Al igual que en BPMN, los participantes del WF se introducen en el modelo dentro de calles de piscina (lane, en inglés). Campo de datos (clase Datafield) y Declaraciones de tipo (clase TypeDeclaration). Especifican los datos relevantes del WF. Estos datos se utilizarán para la toma de decisiones, para referirse a datos externos al WF y para el intercambio de información entre actividades y (sub)flujos. 2.3.3.1. Ventajas de usar XPDL Es un lenguaje bastante utilizado y está presente en la mayoría de las herramientas de WFs. La razón es simplemente práctica: a pesar de tener menos expresividad que los demás lenguajes de representación, posee un conjunto suficiente de elementos para especificar la gran mayoría de los WFs. Además, el lenguaje está pensado para el intercambio de WFs, y por ello, no solo especifica la coordinación entre procesos, sino que también trata aspectos gráficos como el tamaño y las coordenadas de los elementos del modelo. En este sentido, XPDL facilita la integración de WFs entre herramientas a través de un formato de intercambio basado en XML. 2.3.3.2. Inconvenientes de usar XPDL Deafortunadamente, con el conjunto mínimo de construcciones presente en XPDL no es posible representar un buen número de patrones de WFs que hoy en día están presentes en muchos de los productos de WFs. Como se aprecia en las tablas 2.2
76 2. Lenguajes de modelado de flujos de trabajo y 2.2, XPDL tiene casi la misma expresividad que BPMN y que los diagramas de actividad de UML. Para mejorar este aspecto, productos que usan XPDL, como Enhydra Shark4, Bonita5o WfMOpen6, ofrecen extensiones no estándar y utilizan su propio formato de XPDL extendido. Sin embargo, esta aproximación no está alineada con la filosofía de XPDL que pretende ser una lingua franca para WFs. Además del problema de expresividad, XPDL presenta un problema semántico. La WfMC no proporciona una especificación formal y sin ambigüedades de todos los elementos del lenguaje. Como resultado, muchos productos dicen ser compatibles con XPDL cuando en realidad interpretan algunos constructores de diferente manera [256]. Tampoco la legibilidad es un aspecto a destacar: los WFs están representados en XML y por ello pensados para ser interpretados por una herramienta. Por este motivo, XPDL suele combinarse con BPMN, aunque con menor expresividad y así tener una representación gráfica con la que se mejora su legibilidad. Si se compara con BPMN o UML, soporta menos patrones de datos y los mismos patrones de organización. 2.4. Lenguajes de ejecución Debido a las dificultades de definir un modelo de ejecución propio asociado a cada uno de los lenguajes de representación vistos en el apartado anterior, muchos investigadores han abordado el problema de la ejecución creando nuevos lenguajes. La mayoría de estos lenguajes se basan en alguno de los formalismos de representación previamente descritos en el apartado 2.2, para asegurar que su ejecución no sea ambigua. Dentro de esta categoría las principales aportaciones son los lenguajes BPML [247], BPEL [15] y YAWL [259]. 2.4.1. BPML BPML (Business Process Modeling Language) [247] es un estándar desarrollado y promovido por BPMI.org (Business Process Management Initiative). Los principales componentes de BPML, representados en la Figura 2.26, son: Actividades (clase Activity). Son componentes que realizan alguna funcionalidad. BPML define dos tipos de actividades: •Actividades simples (clases AtomicActivity. No se pueden descomponer y son atómicas. Una actividad simple puede ser de uno de los siguientes tipos: ◦Acción. Realiza una operación que implica el intercambio de mensajes de entrada y salida y la posterior actualización de propiedades. 4http://www.enhydra.org/index.php 5http://wiki.bonita.objectweb.org 6http://wfmopen.sourceforge.net
2.4. Lenguajes de ejecución 77 Process Atomic Activity ContextActivitySet Activity Complex Activity Action Operation Property Property Definition 1..* 0..1 1 * 1..* Figura 2.26: Metamodelo de proceso de BPML ◦Asignación. Escribe un valor nuevo a una propiedad. ◦Llamada. Instancia un proceso y espera a que se complete. ◦Compensación. Invoca una acción de reparación (o compensación) para un determinado proceso. ◦Retraso. Espera un determinado período de tiempo. ◦Vacío. No realiza nada. ◦Fallo. Lanza un fallo en el contexto actual. ◦Lanzar. Lanza una señal. ◦Generar. Instancia un proceso y no espera a que finalice. ◦Sincronizar. Espera la ocurrencia de una señal para continuar. •Actividades complejas (clase ComplexActivity. Se pueden descomponer en actividades más pequeñas. Existen los siguientes tipos de actividades complejas: ◦Todo. Ejecuta actividades en paralelo. ◦Selección. Elige una actividad, de entre un conjunto de alternativas, en función de un evento. ◦Para todo. Ejecuta cada una de las actividades de una lista. ◦Secuencia. Ejecuta actividades en secuencia. ◦Condicional. Ejecuta condicionalmente una actividad de entre un conjunto de ellas. ◦Repetir hasta. Ejecuta un conjunto de actividades una o más veces hasta que se alcanza una condición de salida. ◦Repetir mientras. Ejecuta un conjunto de actividades cero o más veces mientras se cumpla una determinada condición.
78 2. Lenguajes de modelado de flujos de trabajo Procesos (clase Process). Son actividades complejas que pueden invocarse desde otros procesos y que se componen de un conjunto de actividades (clase ActivitySet). Un proceso que se define independientemente de otros procesos se llama proceso de alto nivel, mientras que si se define para ser ejecutado dentro de otro proceso se denomina proceso encadenado. Además, existen otros dos tipos de procesos que tratan situaciones especiales: excepciones ycompensaciones. Contextos (clase Context). Definen un entorno para la ejecución de actividades relacionadas entre sí: se utilizan para intercambiar información y coordinar la ejecución del WF. Un contexto contiene definiciones locales que sólo se aplican dentro de un determinado ámbito, y que pueden incluir entre otros elementos, propiedades, procesos, y señales. Los contextos pueden encadenarse de forma que el contexto de los procesos hijo puedan heredar el del padre. Propiedades (clase Property). Se utilizan para intercambiar información y sólo existen dentro de un contexto. Una propiedad tiene un nombre y un tipo, y sus instancias tienen un valor con un rango que se corresponde con el tipo de su definición. Señales. Se utilizan para coordinar la ejecución de las actividades dentro de un contexto común, en lugar de utilizar construcciones de control típicas como secuencias o separaciones. En BPML las señales se entienden como mensajes y algunas actividades simples se utilizan para enviar esos mensajes (actividad atómica lanzar) y para esperar por esos mensaje (actividad atómica sincronizar). 2.4.1.1. Ventajas de usar BPML Al estar desarrollado por BPMI.org está soportado por varias organizaciones incluyendo Intalio, SAP, Sun, y Versata. Además, está fundamentado en π-calculus, con lo que es formal y, por lo tanto, no ambiguo. Ahora bien, no hemos encontrado evidencias de este hecho, ya que no se incluyen las correspondencias con π-calculus que relacionen ambas especificaciones. Otra ventaja de este estándar es que soporta directamente los principales patrones de control presentes en las herramientas comerciales de WFs. 2.4.1.2. Inconvenientes de usar BPML BPML es un lenguaje para ser ejecutado, por lo que no tiene una notación gráfica para el diseño de procesos. Está especificado en XML Schema [33], que se caracteriza entre otros aspectos por ser un formato pensado para ejecutar procesos en entornos de sistema a sistema, es decir, sistemas que no tienen en cuenta la interacción humana y, por lo tanto, la legibilidad de los modelos. En cuanto a la expresividad, BPML captura menos patrones que los modelos orientados a la representación como son BPMN o XPDL y también es menos expresivo que otras lenguajes para ejecutar WFs, tal y como se muestra en las tablas 2.2 y 2.3. Entre las limitaciones más importantes de
2.4. Lenguajes de ejecución 79 BPML cabe destacar que no permite representar patrones de mezcla avanzados, bucles arbitrarios o hitos [258]. Finalmente mencionar que la expresividad de los lenguajes estructurados en bloques, como BPML o BPEL, está limitada a procesos “bien estructurados”, donde existe una correspondencia uno-a-uno entre las separaciones y las uniones; es decir, todas las separaciones se cierran con una unión, asegurando que no existe descompensación entre el número de separaciones y uniones. Esto fuerza al diseñador a introducir entidades del tipo signal,raise ysynch para emular las características de los lenguajes basados en grafos como BPMN o UML. 2.4.2. BPEL4WS El lenguaje BPEL [15] (del inglés, Business Process Execution Language), también conocido como BPEL4WS (BPEL for Web Services), es un lenguaje de orquestación de servicios web definido por OASIS7. Es la convergencia del modelo teórico basado en π-calculus de XLANG [246] con la aproximación más tradicional basada en redes de Petri de WSFL [168]. El modelo de procesos resultante es formal y permite expresar la concurrencia y el dinamismo entre las tareas sin ambigüedades. Aunque existen algunos trabajos que asocian una notación gráfica a BPEL [132, 238, 208], la especificación del estándar no define ninguna y por ello su legibilidad es menor respecto a otros lenguajes. BPEL trata el modelado de dos tipos de procesos: Procesos abstractos. Es un protocolo de negocio que especifica el intercambio de mensajes entre distintos elementos, pero sin revelar el comportamiento interno de cada uno de ellos. Proceso ejecutable. Especifica el orden de un conjunto de actividades, los participantes, los mensajes intercambiados entre dichos participantes y el mecanismo de gestión de excepciones. La especificación de un proceso en BPEL es parecido a un diagrama de flujo. Cada elemento del proceso se llama actividad y puede ser primitiva oestructurada. Una actividad primitiva puede ser de los siguientes tipos: Invocar. Realiza una llamada a una operación de un servicio web descrito en WSDL. Recibir. Espera por un mensaje de una fuente externa. Responder. Envía un mensaje a una fuente externa. Asignar. Copia datos de un contenedor a otro. Lanzar. Indica un error en la ejecución 7http://www.oasis-open.org
80 2. Lenguajes de modelado de flujos de trabajo Terminar . Finaliza la instancia de ejecución del servicio. Vacío. No hace nada. Para facilitar la representación de construcciones de control BPEL facilita el siguiente conjunto de actividades estructuradas que se pueden encadenar a través de enlaces de control llegando a formar grafos acíclicos dirigidos: Secuencia. Define el orden de ejecución. Condicional. Define estructuras condicionales. Repetir mientras. Define estructuras iterativas. Seleccionar. Define condiciones de carrera basadas en tiempo o eventos externos. Flujo. Define estructuras que permiten la ejecución de actividades paralelas. Ámbito. Agrupa actividades en un mismo gestor de errores. 2.4.2.1. Ventajas de usar BPEL Se puede considerar BPEL como un subconjunto del lenguaje BPML. Es importante aclarar que a pesar de partir de un subconjunto del lenguaje BPML, la evolución del lenguaje BPEL hace que en la actualidad sea más expresivo. Ambos comparten las mismas tecnologías de servicios web (SOAP, WSDL) y de XML (XPath, XSDL) y han sido diseñados conjuntamente con otras especificaciones (WS-Security, WSTransactions). Sin embargo, BPEL no soporta algunas características de BPML de gran utilidad para el modelado de WFs como son el encadenamiento de procesos (en BPML un proceso es una actividad) o las transacciones complejas. A pesar de ello, BPML está siendo abandonado con la adopción de BPEL dentro de la pila de estándares de la iniciativa Business Process Management Initiative8. Debido a: (i) la cada vez mayor influencia de los servicios dentro de los motores de WFs y (ii) que BPEL es en la actualidad el estándar de referencia para la orquestación de servicios web. 2.4.2.2. Inconvenientes de usar BPEL Al igual que BPML, BPEL está pensado para ejecutar procesos en entornos de sistema a sistema y, por lo tanto, no tiene en cuenta la interacción humana. A pesar de ello, ha sido muy utilizado por los sistemas de WFs que tienen su origen en las soluciones de integración. Con la salida de la especificación BPEL4People [4], BPEL 2.0 [9] ha añadido soporte para la interacción basada en roles, y con ello permite asignar tareas a roles y delegar su ejecución a una persona. 8http://www.bpmi.org
2.4. Lenguajes de ejecución 81 En cuanto a la capacidad expresiva, como se puede observar en las tablas 2.2 y 2.3, BPEL representa menos patrones que los modelos orientados a la representación como son BPMN, UML o XPDL, pero más que otros lenguajes de ejecución como BPML [299]. Ello se debe a que BPEL elimina algunas restricciones heredadas por BPML de WSFL/IBM MQSeries. Sin embargo, adolece de patrones importantes como el de ciclos arbitrarios, que es un patrón muy común en los sistemas de WF. BPEL implementa algunos de los patrones de datos descritos en el apartado 2.1.1.1. Como se puede apreciar en la Tabla 2.4, soporta menos de la mitad de estos patrones, y da un soporte similar al de los lenguajes de representación UML y XPDL, aunque inferior al de BPMN. Finalmente, comentar que al igual que BPML o YAWL, BPEL no incorpora elementos que permitan modelar los patrones recursos descritos en el apartado 2.1.1.3. Sin embargo, algunas versiones comerciales del lenguaje, como Oracle-BPEL9o WebSphere-BPEL10, sí dan soporte a la mayor parte de estos patrones11. 2.4.3. YAWL YAWL (del inglés Yet Another Workflow Language) [259] es un lenguaje creado específicamente para ejecutar los patrones de comportamiento de los WFs. Las versiones iniciales de YAWL estaban orientadas a la perspectiva de control, y permitían implementar 19 de los 20 patrones originales de comportamiento [260]. En la actualidad están trabajando en una nueva versión (newYAWL) [220] que añade un soporte limitado a los patrones de datos y recursos, aunque este esfuerzo está dificultado por la falta de una descripción formal de este tipo de patrones. YAWL está fundamentado en un tipo de redes de Petri de alto nivel llamadas WFnets [255], aunque extiende su modelo para dar soporte a algunos de los patrones de control más avanzados [259]. Al estar basado en redes de Petri no necesitaría de otro formalismo de representación gráfica como BPMN o los diagramas de actividad de UML. Sin embargo, para simplificar la representación de los procesos, YAWL define un lenguaje de representación propio cuyos principales elementos se muestran en la Figura 2.27. Este lenguaje mantiene el característico grafo bipartito de las redes de Petri, donde los círculos representan a las condiciones, los rectángulos a las tareas y los arcos asocian dichos elementos. Sin embargo, al contrario que las redes de Petri de alto nivel, los arcos pueden conectar a dos tareas. Esta diferencia es únicamente a efectos de representación, ya que internamente se considera que existe una condición oculta entre ambas tareas. YAWL define tres tipos de condiciones: Condición de entrada. Todo WF tiene una única condición de entrada a partir de la cual se inicia la ejecución. 9http://www.oracle.com/technology/products/ias/bpel/index.html 10http://www.redbooks.ibm.com/abstracts/sg246381.html?Open 11http://www.workflowpatterns.com/evaluations/standard/index.php
88 2. Lenguajes de modelado de flujos de trabajo Reserva de billete de avión Sequence Perform Aerolínea Fecha ida Fecha vuelta Vuelos Obtener vuelos Perform Vuelos Vuelo Seleccionar vuelo Aerolínea Vuelo Fecha vuelta Fecha ida Aerolínea Vuelos Obtener vuelos Vuelos Vuelo Seleccionar vuelo WSDL Figura 2.29: Ejemplo de integración entre el modelo de servicio y la capa de conocimiento de OWL-S través del lenguaje SWRL [137], con lo que también soporta parte de los patrones de datos. Por último, este lenguaje soporta una gran variedad de operadores cubriendo las operaciones de existencia y valor que afectan a los datos. A pesar de ello, OWL-S no soporta por completo el enrutamiento basado en datos, ya que no soporta el patrón elección múltiple. El soporte de los patrones de organización es muy reducido, ya que en OWL-S la única referencia a un componente de organización es la relación entre el proceso y el participante, como se muestra en la Figura 2.28. Por ello únicamente se puede afirmar que OWL-S soporta una asignación directa de tareas. Finalmente, su utilización estaría restringida al ámbito de la ejecución al no disponer de una representación gráfica. Aunque esta ontología se especifica en el formato OWL, no deja de ser en último término un fichero RDF o en el mejor de los casos una representación gráfica de la jerarquía de clases de la ontología. 2.5.2. WSMO WSMO [213, 83] es una ontología que describe los componentes principales de WSMF [103], un marco de conocimiento que proporciona un modelo conceptual para descubrir, ejecutar y componer servicios web. La novedad de WSMO es que (i) introduce el concepto de mediación como parte de la infraestructura que trata el descubrimiento y la composición de servicios web: los mediadores describen las conexiones entre los componentes de WSMF; y (ii) representa la orquestación y la coreografía a través de reglas de transición definidas mediante máquinas de estados abstractos (ASMs, del inglés Abstract State Machines) [124].
2.5. Lenguajes basados en tecnología semántica 89 Implementación del servicio web (No tiene interés desde la perspectiva de escripción) WS WS WS Interfaz de COREOGRAFÍA Interfaz de ORQUESTACIÓN - Mensajes - Comportamiento externo - Conocimiento base (grounding) Interacción para consumir servicios web: - Descomposición funcional - Composición de servicios web Realización del servicio web utilizando otros servicios web: Figura 2.30: Orquestación y coreografía de WSMO En la Figura 2.30 representamos las interfaces de coreografía y de orquestación que constituyen la base para la composición de servicios en WSMO [214]. Ambas interfaces se especifican a través de un modelo de estados inspirado en el formalismo de las ASMs que proporcionan los mecanismos básicos para modelar la interacción entre los proveedores de servicios y los clientes en el nivel abstracto, y su uso tiene varios beneficios: Minimalidad. Las ASMs tienen un pequeño conjunto de primitivas de modelado. Expresividad. Las ASMs permiten simular máquinas de Turing y pueden, por lo tanto, modelar cualquier tipo de computación. Formalidad. Las ASMs definen un marco formal para expresar sistemas dinámicos. La coreografía y orquestación de WSMO toma prestados los mecanismos básicos de las ASMs: Una firma define los predicados y funciones que se usarán en la descripción. Los hechos especifican los estados de la base de datos. Los cambios de estado se describen mediante reglas de transición, que especifican cómo los estados cambian haciendo falsos (o borrando) algunos hechos previamente ciertos y haciendo ciertos (o insertando) otros hechos. En WSMO las firmas se definen usando ontologías. Estas ontologías están expresadas en el lenguaje WSML [47] que constituye otra de las grandes aportaciones de la propuesta WSMO, y le proporciona un lenguaje formal para la descripción de los
90 2. Lenguajes de modelado de flujos de trabajo servicios web. Los hechos forman la base de datos de estados y son instancias de los conceptos y relaciones definidas por la ontología en WSML. Los cambios de estados se describen en términos de creación de nuevas instancias o cambios en el valor de algún atributo de la ontología. Las reglas de transición de estados utilizadas en WSMO tienen una de las siguientes formas: if Condition then Rules forall Variables with Condition do Rules choose Variables with Condition do Rules La parte Condition se refiere a una condición o expresión lógica (también llamada guarda) definida en WSML [212]. Las parte de Rules es un conjunto de reglas ASM que representan cambios primitivos de estado como añadir, borrar o modificar algún hecho. Las reglas de transición tipo if −then,forall ychoose pueden usarse para definir cambios de estado más complejos. Como es usual con las ASMs, las reglas de la coreografía de WSMO y los cambios en el estado se evalúan en paralelo. Cuando una regla de una ASM es ejecutada, el motor de ASMs realiza una transición de un estado de la base de datos a otro. Una ejecución de una coreografía u orquestación en WSMO consiste, por lo tanto, en una secuencia finita o infinita de estados s0, s1,... donde s0es el estado inicial de la coreografía y, para cada n≥0, se puede realizar una transición desde el estado sn al estado sn+1 a través de la ejecución de un conjunto de reglas que manipulan los hechos. 2.5.2.1. Ventajas de usar WSMO No se puede considerar WSMO como un simple lenguaje, sino un metamodelo basado en ontologías (especificadas en WSML) que permite describir los aspectos más relevantes de los servicios web semánticos. Esta estructuración es uno de los puntos fuertes de WSMO para dar soporte al despliegue e interoperabilidad de servicios. Las ontologías son el núcleo de WSMO y todos sus componentes se definen a través de ellas. Por ello, el razonamiento acerca de las características funcionales y no funcionales de un proceso estaría cubierto a través de esta solución, lo cual facilitaría la composición automática de WFs. A través de WSMO también se facilita la reutilización de componentes: al estar todos los elementos definidos a través de ontologías y los modelos del dominio separados de la definición de los servicios, la reutilización consiste en definir mediadores entre todos estos componentes. Otra de las características a destacar de la coreografía y orquestación WSMO es su no ambigüedad gracias al uso del formalismo ASM en combinación con el lenguaje WSML. Ello permitiría usar una máquina virtual WSMO como ejecutor de WFs, sin
2.6. Conclusiones 91 embargo, en la actualidad aún no se dispone de una implementación de una máquina o motor que permita ejecutar coreografías y orquestaciones WSMO. 2.5.2.2. Inconvenientes de usar WSMO Desde el punto de vista del modelado de WFs, el principal inconveniente de la propuesta WSMO es su poca legibilidad. WSMO utiliza ASM para modelar la coreografía y orquestación de procesos, que en último término son reglas de transición. A medida que se añaden procesos y las condiciones de aplicabilidad se hacen más complejas, la legibilidad del modelo se reduce drásticamente y es sólo manejable por parte de un experto informático. Además, es necesario mencionar que tanto la semántica de los interfaces web (coreografía y orquestación) como el conocimiento base que permite invocar servicios externos, no están completamente definidos. Por ejemplo, no está definida la relación del conocimiento base de WSMO con WSDL, el actual estándar de descripción de servicios, complicando así la aplicabilidad de esta solución a un desarrollo de WFs. Al igual que los demás formalismos utilizados para representar procesos, las ASM permiten emular máquinas de Turing y, por lo tanto, cualquier tipo de computación. Sin embargo, la definición de algunos de los patrones de WFs resulta sumamente complicada y poco intuitiva para un diseñador inexperto. Sería necesario incluir una capa de patrones por encima de WSMO para así facilitar el uso de WSMO como lenguaje de representación de WFs. Por esta razón WSMO sale mal parado en la comparativa que se muestra en las tablas 2.2 y 2.3: las ASMs permiten sin ninguna duda dar soporte a la mayoría de estos patrones, sin embargo, no es un soporte directo con lo cual todas las entradas de la tabla tendrían un ’-’. En cualquier caso, este problema también lo tienen otros formalismos como π-calculus, las ASMs o las redes de Petri, pero, en el caso de las redes de Petri está atenuado por el hecho de que son un formalismo también gráfico que con un poco de notación adicional (como es el caso del lenguaje YAWL) permite fácilmente dar soporte a la mayor parte de los patrones. Finalmente, mencionar que a pesar de definir un metamodelo para servicios, no está claro que WSMO esté estructurado adecuadamente para maximizar la reutilización de los componentes que definen un WF. Algunas dimensiones, como la de recursos, no están claramente identificadas dentro de WSMO. 2.6. Conclusiones El campo del modelado de WFs ha sido muy activo desde la implantación de los primeros sistemas sistemas de información de oficinas en torno a los años setenta [96, 135, 310]. Estas primeras aproximaciones estaban basadas en redes de Petri, pero desde entonces han aparecido más lenguajes con el fin de mejorar el modelado de WFs. Además de los analizados en los apartados anteriores, merece la pena mencionar FDML [129], BPSS [72], XLANG [246], WSFL [168], o WSCI [18], que en
92 2. Lenguajes de modelado de flujos de trabajo algún momento llegaron a implantarse en alguno de los muchos sistemas que utilizan WFs: WFM (del inglés Workflow Management), BPM (del inglés Business Process Management), B2B (del inglés Business-to-Business), CRM (del inglés Customer Relationship Management) o ERP (del inglés Enterprise Resource Planning). Además, el cambio propiciado en la arquitectura de estos sistemas con la aparición del paradigma de servicios web ha acelerado la aparición de nuevos lenguajes. Así, varios productos comerciales como WebSphere MQ Workflow12 yOracle BPEL Process Manager13 ya usan BPEL tanto para el modelado como para la ejecución de WFs. También resultan llamativos los distintos enfoques desde los que se promueve este modelado. Algunos lenguajes modelan los WFs desde la perspectiva de la representación. Por ejemplo, BPMN extiende los diagramas de flujos para modelar diagramas de procesos, incorporando una semántica gráfica con una nueva notación más acorde con las necesidades de los WFs. Otro ejemplo son los diagramas de actividad de UML, que a pesar de no haber sido creados para modelar WFs, son ampliamente usados para diseñar WFs. Dentro de esta categoría también se pueden encontrar lenguajes pensados para el intercambio de WFs entre herramientas visuales. Éste es el caso del lenguaje XPDL que aboga por una representación que capture los aspectos comunes tanto de modelado como de representación gráfica. En el lado opuesto están los lenguajes de ejecución de WFs. Los principales representantes de esta categoría son BPML y BPEL, que aproximan la ejecución desde la orquestación de servicios. Estos lenguajes están basados en algún formalismo de procesos para evitar ambigüedades y así no permitir que distintas implementaciones puedan interpretar y ejecutar al mismo WF de manera distinta. Sin embargo, no suelen tener representación gráfica, por lo que se combinan con los lenguajes de representación. En estos casos surge el problema de expresividad, ya que no suele existir una correspondencia directa entre los elementos del lenguaje de representación y los del lenguaje de ejecución. Una excepción es YAWL, que además de semántica de ejecución fundamentada en un modelo formal, también proporciona un lenguaje gráfico. Dentro de los formalismos de representación de procesos destacan las redes de Petri, π-calculus y las ASMs. El primero es de largo el más extendido para el modelado de este tipo de procesos: su capacidad para modelar la concurrencia unida al hecho de que es un formalismo gráfico son el principal motivo del éxito de estas redes. En este sentido, existen muchos ejemplos del uso de redes de Petri en sistemas de WFs tanto de investigación como comerciales. Algunos de estos ejemplos utilizan directamente el formalismo de redes de Petri, mientras que otros usan un lenguaje cuya semántica está basada en estas redes, como WSFL o YAWL. En cambio, π-calculus y las ASMs no suelen usarse directamente en ninguna herramienta orientada al modelado de WFs. El motivo es su poca legibilidad, ya que su sintaxis es similar a la de un lenguaje de programación declarativo. Por ello, habitualmente se combinan con otro lenguaje de representación al que le añaden un soporte formal, como en el caso de BPML y XLANG, cuya ejecución está fundamentada en 12http://www-01.ibm.com/software/integration/wmqwf/ 13http://www.oracle.com/technology/products/ias/bpel/index.html
2.6. Conclusiones 93 π-calculus, o de BPMN en el caso de las ASMs. Tanto los lenguajes de representación como de ejecución de WFs aportan las funcionalidades necesarias para que los sistemas tradicionales puedan modelar sus WFs. Permiten estructurar procesos a través de construcciones de control, definir sus características funcionales (entradas, salidas y condiciones) a través de un álgebra/firma, e incluso definir canales de comunicaciones mediante los cuales distintos procesos pueden comunicarse entre sí. El principal problema de estos lenguajes es la carencia de semántica. Las construcciones de control, los parámetros y las expresiones utilizados para caracterizar a los procesos están definidas a nivel sintáctico y por ello no es posible razonar acerca de sus características. Teniendo en cuenta que las ontologías permiten la descripción semántica de cualquier dominio, la incorporación de ontologías al modelado de procesos daría lugar a WFs semánticos. Dotar de semántica a los WFs permitiría la composición y reutilización dinámica de WFs, problemas que han sido siempre difíciles de resolver para los sistemas de WFs tradicionales y que han requerido de la intervención de humanos. Con la aparición del paradigma de los servicios web semánticos, esta tecnología podría aplicarse a los WFs para automatizar la composición, invocación e interoperabilidad entre procesos. OWL-S y WSMO son las principales iniciativas de la web semántica para el modelado de servicios web y, además de permitir razonar sobre las ontologías del dominio de la aplicación, permiten razonar sobre la propia estructura del proceso, ya que se definen a su vez como ontologías. Sin embargo, carecen de la expresividad característica de los lenguajes de modelado de WFs. Redes de Petri como formalismo de representación. Del análisis llevado a cabo a lo largo de este capítulo y del uso típico de los sistemas de WFs se desprenden dos conclusiones: 1. Un modelo gráfico es imprescindible para garantizar la legibilidad del modelo de WFs, y por ello todos los sistemas comerciales de WFs lo incorporan. A través de algún tipo de diagrama gráfico, como UML, BPMN o redes de Petri, se facilita la comprensión de los modelos, y con ello no se circunscribe el proceso de diseño a un experto informático. 2. Un modelo formal es imprescindible para garantizar una ejecución sin ambigüedades. Los principales lenguajes de ejecución, como BPEL, BPML o YAWL fundamentan su comportamiento en algún formalismo. No existen muchos lenguajes que cumplan los requisitos anteriores. Aunque la combinación de un lenguaje gráfico con uno de ejecución podría llegar a satisfacer estas condiciones, no parece ser el paso más adecuado: requiere definir un conjunto de correspondencias entre ambos lenguajes y restringir la expresividad de alguno de ellos. Por ello, hemos optado por aproximar el modelado de WFs a través de un único lenguaje, seleccionando el formalismo de las redes de Petri de alto nivel, y más concretamente el lenguaje gráfico definido para representar este tipo de redes. Aunque
94 2. Lenguajes de modelado de flujos de trabajo existen otros lenguajes como YAWL que también cumplen con los requisitos anteriores, la principal razón por la que se optó por las redes de Petri se debe a que son el formalismo más aceptado y empleado, tienen una gran expresividad, y además poseen un importante conjunto de técnicas de simulación, validación y verificación. YAWL era otra de las posibles opciones, sin embargo, la carencia de técnicas de análisis, validación y simulación, unido a los problemas para extender YAWL y así dar soporte a muchos de los nuevos patrones de WFs [220] han motivado que optásemos por las redes de Petri. Como se ha señalado en el Capítulo 1, los marcos conceptuales basados en conocimiento tienen problemas para el modelado de WFs por su falta de expresividad a la hora de especificar el control entre los (sub)procesos. Por este motivo, si se completa la aproximación basada en conocimiento con el formalismo de las redes de Petri estamos en disposición de definir el marco de conocimiento objeto con el que se resuelven los problemas indicados en la Tabla 1.1. una ontología de redes de Petri Para facilitar el tratamiento de estas redes como una pieza de conocimiento dentro del metamodelo descrito en esta memoria en esta tesis doctoral es necesario construir una ontología de redes de Petri. Esta ontología se describirá de forma detallada en el Capítulo 3.
3 Una ontología de redes de Petri para modelar procesos La gran capacidad expresiva y de legibilidad de las redes de Petri (PNs, del inglés Petri Net) han convertido a este formalismo en el más empleado para el modelado de flujos de trabajo (WFs, del inglés Workflows). Sin embargo, muy pocas investigaciones han profundizado en un metamodelo que permita conceptualizar y explicitar estas redes de forma que puedan ser reutilizadas con más facilidad, por ejemplo entre distintos sistemas de WFs. Si este metamodelo permitiese además modelar la dinámica de estado y ejecución de estas redes, distintos sistemas de WFs podrían compartir, intercambiar o balancear la ejecución de WFs. Este capítulo está dedicado a la descripción de una ontología de PNs de alto nivel (HLPNs, del inglés High-Level Petri Nets) [266] que permite asumir este reto, ya que modela tanto los grafos como la semántica de ejecución de estas redes. Además, también se presentará una ontología de redes jerárquicas, construida sobre la base proporcionada por las HLPNs, a través de la cual se definirá la semántica de composición de las HLPNs de forma que un modelo complejo pueda construirse a partir de redes más simples. 3.1. Redes de Petri Carl Adam Petri [203] introdujo las PNs en su tesis doctoral como una herramienta para simular las propiedades dinámicas de los sistemas complejos mediante modelos gráficos de procesos concurrentes. Desde entonces su estudio y desarrollo ha tenido un auge importante debido fundamentalmente a las numerosas aplicaciones que se les han encontrado: modelos de redes abstractas, procesamiento paralelo y distribuido, teoría de grafos, problemas de transporte, problemas de decisión y reconocimiento de patrones, entre otras. En esta sección se introducirán los conceptos básicos de las PNs [203, 190] a partir de un ejemplo intuitivo que se describe a continuación y que permitirá explicitar de forma natural las principales características de las PNs: principio de localidad, concurrencia, representación gráfica y anotación algebraica. En este caso, se escogió un ejemplo que se encuentra en el ámbito de la fabricación donde varias piezas a ensamblar llegan a una máquina de una cadena de montaje. Las condiciones y accio95
96 3. Una ontología de redes de Petri para modelar procesos nes de este ejemplo se listan a continuación, aunque por simplicidad se restringió la fabricación/ensamblado a dos piezas: Lista de condiciones: •p1 : pieza aesperando •p2 : pieza apreparada •p3 : máquina preparada •p4 : pieza besperando •p5 : pieza bpreparada •p6 : pieza montada Lista de acciones: •t1 : preparar pieza a •t2 : preparar pieza b •t3 : procesar piezas 3.1.1. Redes de Petri de bajo nivel La separación entre elementos pasivos (como son las condiciones) y elementos activos (como son las acciones) es un paso muy importante en el diseño de cualquier sistema. Esta separación está claramente soportada por el principio de dualidad de las PNs, que define dos conjuntos de elementos disjuntos llamados respectivamente P y T. Las entidades del mundo real que son interpretadas como elementos pasivos, se representarán como elementos tipo P (plazas, condiciones, recursos, canales de comunicación, etc.); en cambio, sí son interpretadas como elementos activos se representarán mediante elementos tipo T (transiciones, eventos, acciones, transmisión de un mensaje, etc.). Es importante mencionar que la clasificación de un objeto como activo o pasivo dependerá del contexto. Por ejemplo, una sentencia de un lenguaje de programación podría modelarse como un elemento activo en el contexto de una ejecución o pasivo en el contexto de una operación de compilación. Otro de los principios esenciales de este tipo de redes es la localidad de las acciones. Supóngase que el estado inicial del ejemplo de fabricación previamente descrito viene dado por m1 : [p1= 1, p2= 0, p3= 1, p4= 1, p5= 0, p6= 0], donde se representa la verificación de las condiciones por medio de valores binarios. Asumiendo que las acciones t1yt2requieran únicamente que las piezas estén disponibles, tanto t1como t2podrían ejecutarse en el estado m1. Siguiendo con el ejemplo, la ejecución de la acción t1podría implicar que una pieza de tipo aestá prepara para ser procesada. Por lo tanto, dicha pieza pasaría de “estar esperando” a “estar preparada”. Lo mismo podría ocurrir con la ejecución de la acción t2, pero en este caso para la pieza de tipo b. La Figura 3.1 muestra el estado m2 resultante de la ejecución de estas dos transiciones.
3.1. Redes de Petri 97 m1: [ p1=1, p2=0, p3=1, p4=1, p5=0, p6=0 ] m2: [ p1=0, p2=1, p3=1, p4=0, p5=1, p6=0 ] t1t2 Figura 3.1: Principio de localidad y concurrencia de las acciones t1et2 La principal observación del ejemplo de la Figura 3.1 es que únicamente las condiciones relacionadas con las acciones ejecutadas se ven afectadas. Esta propiedad se conoce por el principio de localidad de las PNs, e indica que el comportamiento de una acción únicamente depende de su conjunto de objetos de entrada y salida. En el ejemplo anterior, la localidad de la acción t1es {t1, p1, p2}mientras que la de la acción t2es {t1, p4, p5}. Se puede verificar, por lo tanto, que las localidades de las acciones t1,yt2del ejemplo de fabricación no comparten condiciones. Esta propiedad define el principio de concurrencia, que establece que las acciones tienen que tener localidades disjuntas para poder ocurrir de forma independiente (concurrente). Es importante mencionar que la noción de concurrencia es diferente de la de paralelismo: las acciones paralelas implican una sincronización, mientras que las acciones concurrentes no están relacionadas por ninguna causalidad. La Figura 3.1 también representa gráficamente las acciones t1yt2y las relaciona con sus precondiciones y postcondiciones mediante arcos. Los arcos conectan cada uno de los elementos de tipo T con su localidad, la cual es un conjunto de elementos de tipo P. En este caso, las condiciones (elementos de tipo P) se representan mediante círculos llamados plazas, mientras que las acciones (elementos de tipo T) lo hacen mediante rectángulos llamados transiciones. Por lo tanto, una red está constituida por un conjunto de plazas, transiciones y arcos. La Figura 3.2 representa la red completa del ejemplo de fabricación en el estado inicial m1. p1t1p2 p4t2p5 p3t3p6 Figura 3.2: Representación del ejemplo de fabricación mediante un grafo de PN Las PNs también pueden describirse de forma algebraica de modo que para cada representación gráfica existe una representación algebraica equivalente. Esta descripción es muy útil para el análisis matemático de estas redes.
104 3. Una ontología de redes de Petri para modelar procesos La definición del grafo anotado de la HLPN es muy similar en ambos modelos. La principal diferencia entre ambas especificaciones es que PNML se queda en el nivel sintáctico de anotación de la red. Debido a que la mayor parte de los editores no dan soporte a la implementación de las funciones usadas para anotar las redes, PNML no entra en este aspecto. En cambio, el modelo de la ontología mantiene la separación entre la firma sintáctica y el álgebra del estándar ISO/IEC 15909-1. De esta forma, se enriquece el intercambio de HLPNs con respecto a la propuesta de PNML. Al disponer del álgebra, los editores podrían hacerse más ricos y permitir ejecutar y simular HLPNs directamente a partir de la ontología intercambiada. Además, ello facilitaría la reutilización de las redes y de su álgebra. Por ejemplo, una HLPN que se encarga de gestionar una planta de fabricación podría usarse en distintos dominios simplemente cambiando el álgebra (ontología del dominio) asociada a dicha red. La ejecución de las HLPNs no está modelada en PNML. Ésta es la principal diferencia entre ambas propuestas desde la perspectiva del modelado. Aunque capturar la semántica de ejecución no es uno de los objetivos actuales de PNML, es uno de los aspectos principales de la ontología de HLPNs. Hacer explícitos los modelos de estado y ejecución permite usar estas redes en dominios donde es necesario razonar acerca del comportamiento de la red. Por ejemplo, para comprobar el funcionamiento de servicios Grid o Web. Ambas soluciones proporcionan un conjunto de axiomas que restringen las instancias de la taxonomía/metamodelo. Aunque PNML utiliza sentencias OCL para este propósito, dichas sentencias se restringen a la definición del grafo y aspectos como la anotación de la red no son tenidos en cuenta. Por ejemplo, PNML no verifica que las condiciones de guarda de una transición tengan un valor lógico ni que los parámetros de las llamadas a operadores tengan el tipo adecuado. En cambio, nuestra ontología detalla un conjunto de axiomas para completar la semántica de cada uno de los elementos de una HLPN. 3.2.2. Desde el punto de vista tecnológico PNML describe un metamodelo en UML y lo traslada a un lenguaje basado en el formato XML. Las primeras versiones se basan en el lenguaje RELAX NG [73] mientras que se prevé que futuras versiones lo hagan en el lenguaje XML Schema [248]. El principal problema de la solución PNML (independientemente del uso de RELAX NG o XML Schema) consiste en que no extiende la semántica de representación proporcionada por el lenguaje XML y por ello no es lo suficientemente expresivo para describir la semántica asociada a los elementos del metamodelo. Aunque a través de esta estrategia PNML garantiza que los ficheros XML intercambiados tengan una sintaxis correcta, la semántica asociada a los elementos intercambiados debe de ser validada. Así se se hace necesario disponer de un validador del metamodelo que permita cotejar los ficheros XML intercambiados. Si el intercambio se produce en un entorno distribuido, la operación se complica, ya que además se requiere que tanto el remitente como el receptor compartan la misma versión del validador. La aproximación ontológica es bastante diferente respecto a este último punto: los ficheros intercambiados contienen
3.2. Lenguajes de intercambio de redes de Petri de alto nivel 105 − <grammar datatypeLibrary="http://www.w3.org/2001/ XMLSchema-datatypes"> + <a:documentation></a:documentation> − <start> <ref name="pnml.element"/> </start> + <define name="pnml.element"></define> ... − <define name="place.content"> − <a:documentation> A place may have several labels (place.labels) and the same content as a node. </a:documentation> − <interleave> <ref name="place.labels"/> <ref name="node.content"/> </interleave> </define> + <define name="place.labels"></define> ... + <define name="node.content"> − <a:documentation> A node has a unique identifier. </a:documentation> − <attribute name="id"> <data type="ID"/> </attribute> + <interleave></interleave> </define> ... </grammar> Especificación PNML en RELAXNG hlpn::thing [ hasName {1:1}*=> string , hasDescription {0:1}*=> string , hasNodes {0:*}*=> node , hasArcs {0:*}*=> arc , hasSignature {1:1}*=> signature , hasVariables {0:*}*=> variable ]. node::thing [ hasName {1:*}*=> string]. place::node [ hasSort {1:1}*=> sort]. transition ::node [ hasGuard {1:1}*=> term]. arc::thing [ hasSourceNode {1:1}*=> node , hasTargetNode {1:1}*=> node , hasAnnotations {1:1}*=> list (term )]. ... ... Especificación de la ontología de redes de Petri de alto nivel en Flora 2 Axiomática Taxonomía %error(hlpn_1, ?_net, ?_arc) :- ?_net:hlpn, ?_net[hasArcs -> ?_arc ], ?_arc[hasSourceNode -> ?_sno, hasTargetNode -> ?_ tno], not((?_sno:place , ?_tno:transition ; ?_sno:transition , ?_tno:place)). %error(hlpn_2, ?_net, ?_nod) :- ?_net:hlpn, ?_net[hasNodes -> ?_ nod], ?_nod:node, not((?_nod:place , not ?_nod :transition ; not ?_nod:place, ?_nod:transition )). transition place node arc sourceNode targetNode is-a is-a Los nodos origen y destino deben de tener tipos distintos La jerarquía de nodos es una partición disjunta Figura 3.10: Definición del concepto nodo en las especificaciones RELAX NG de PNML y FLORA-2 de la ontología. toda la semántica y la validación se realiza mediante razonadores estándar. En este contexto, las principales limitaciones de aplicar la estrategia seguida por PNML son: No permite definir explícitamente las relaciones jerárquicas (is-a) entre dos o
106 3. Una ontología de redes de Petri para modelar procesos más conceptos. Al no existir mecanismos de herencia difícilmente se pueden representar las taxonomías. Por ejemplo, en los ficheros XML intercambiados por PNML las plazas y las transiciones no heredan las propiedades ni las relaciones del concepto nodo a pesar de que el metamodelo sí las contempla. La Figura 3.10 compara la especificación del concepto nodo tanto en RELAX NG como en F-Logic. En esta comparación se puede verificar como el fichero en formato RELAX NG sólo contiene los elementos XML del metamodelo mientras que la ontología en FLORA-2 además de la taxonomía contiene los axiomas que restringen los conceptos de dicha taxonomía. Además, el formato RELAX NG no permite definir relaciones jerárquicas entre los elementos y, por ello, los atributos del nodo se añaden a las plazas y transiciones. En cambio, en el formalismo F-Logic dichas relaciones jerárquicas se establecen a través del constructor :: y por lo tanto, las plazas y transiciones heredan automáticamente las propiedades y relaciones del nodo. No permite definir las propiedades de las relaciones. RELAX NG no dispone de primitivas que permitan especificar propiedades matemáticas (como la simetría o la transitividad) ni taxonómicas (como la disyunción o las particiones exhaustivas) sobre las relaciones. Estas restricciones no tienen cabida en el formato RELAX NG a pesar de que en el metamodelo de PNML alguna de ellas se exprese a través de OCL. Por ello, con la estrategia PNML es necesario asegurar que ambos lados de la comunicación disponen de las mismas restricciones a nivel del metamodelo. En cambio, en F-Logic estas restricciones se expresan bien a través de anotaciones en los conceptos bien a través de axiomas y se incorporan en el fichero intercambiado. De esta forma, ambos lados de la comunicación tienen las mismas restricciones. No permite definir restricciones entre conceptos, atributos o relaciones. Los axiomas completan la semántica de los conceptos cuando ésta no se puede expresar directamente en el modelo. Por ejemplo, el axioma un arco conecta nodos de distinto tipo no se puede especificar en el lenguaje RELAX NG. Por el contrario, sí puede serlo en lenguajes de ontologías como Ontolingua [122], OWL [84] o F-Logic [152] Mencionar que estos inconvenientes no son carencias de la especificación PNML. Simplemente muestran las diferencias existentes entre la aproximación tecnológica seguida por PNML y una basada en ontologías. La propuesta de esta tesis doctoral intenta modelar el estándar ISO/IEC 15909-1 y consecuentemente asume su especificación matemática y las restricciones que dicha especificación impone tanto en la definición como en la ejecución de las redes. Por lo tanto, la solución tecnológica también debe de soportar dichas restricciones. Es más, debe de asegurar que la red transferida es correcta. Por el contrario, como se puede apreciar en la Figura 3.11, PNML no puede asegurar a través del formato de intercambio de ficheros que la red transferida es correcta, por ejemplo, no puede comprobar que un arco tiene un nodo origen y destino que son de distinto tipo, ya que ambos están definidos como atributos IDREF en RELAX NG. De ahí que PNML necesite acceder al nivel de la aplicación para comprobar este tipo de restricciones.
3.3. Ontologías de redes de Petri 107 <pnml xmlns=”http://www.informatik.hu-berlin.de/top/pnml/ptNetb”> <net id=”example1”type=”http://www.informatik.hu-berlin.de/top/pntd/ptNetb”> <name> <text>incorrect representation of a Petri net graph structure</text> </name> <Place id=”p1”> <name> <graphics><offset x=”0”y=”22”/></graphics> <text>p1</text> </name> <initialMarking> <graphics><offset x=”-20”y=”10”/></graphics> <text>1</text> </initialMarking> <graphics><position x=”50”y=”150”/></graphics> </Place> <Place id=”p2”> <name> <graphics><offset x=”-1”y=”20”/></graphics> <text>p2</text> </name> <initialMarking> <graphics><offset x=”24”y=”5”/></graphics> <text>0</text> </initialMarking> <graphics><position x=”250”y=”150”/></graphics> </Place> <arc id=”a1”source=”p1”target=”p2”> <inscription> <graphics><offset x=”20”y=”0”/></graphics> <text>1</text> </inscription> <graphics><position x=”75”y=”75”/></graphics> </arc> </net> </pnml> Figura 3.11: Definición de PN incorrecta a través de PNML. El arco a1 sombreado en la figura conecta las plazas p1 yp2. 3.3. Ontologías de redes de Petri Existen varias propuestas de ontologías de HLPNs. La principal diferencia entre dichas ontologías y la que se presentará en este capítulo es que, al igual que PNML, ninguna de las propuestas permite representar la semántica de ejecución de una red. Es decir, ninguna captura conceptos tan esenciales como las evaluaciones, los modos de transición o los disparos ni tampoco explicitan los axiomas que permiten validar
108 3. Una ontología de redes de Petri para modelar procesos si la ejecución ha sido correcta. En [112] Gasevic y Devedzic proponen una ontología de PNs con el objetivo de facilitar el intercambio de redes entre distintas aplicaciones. Esta ontología está basada en el estándar de intercambio de ficheros de PNML [292] y podría considerarse una traducción a OWL [84]. Con ello formalizan el metamodelo de PNML en un lenguaje de lógica descriptiva y, por lo tanto, evitan los problemas anteriormente mencionados que son intrínsecos del formato de intercambio basado en XML. Para el desarrollo de esta ontología los autores han representado el metamodelo de HLPNs en el lenguaje UML y las restricciones entre los conceptos en el lenguaje OCL [10]. Para su paso a OWL utilizaron el editor de ontologías Protégé1para modelar PNML y después generar automáticamente el metamodelo en el lenguaje OWL. Aunque la ontología de Gasevic y Devedzic tiene semejanzas con la propuesta en esta tesis doctoral, el enfoque seguido por ambas propuestas es diferente: la ontología de Gasevic y Devedzic está orientada a compartir PNs entre diferentes herramientas transformando la red al formato de la herramienta mediante plantillas XSLT; en cambio nuestra ontología está orientada a una completa especificación de las PNs, incluyendo el concepto de álgebra y la descripción de la semántica operacional que permita capturar la semántica de ejecución de las PNs. En [236] Songfeng presenta una ontología que describe el modelo estático de una PN a través de dos conceptos de alto nivel y un conjunto de correspondencias entre ellos: el concepto structure, que describe los elementos del grafo, y el concepto algebra, que representa las anotaciones en los nodos y arcos de la PN. La ontología facilita la reutilización, ya que separa la definición del grafo de su anotación, sin embargo, al no existir firma sintáctica, las correspondencias se deben establecer manualmente. Éste es el principal inconveniente de esta propuesta y reduce considerablemente su posible reutilización. Otras ontologías han sido propuestas para describir los principales elementos del grafo característico de estas redes y hacer uso de las ventajas del razonamiento del lenguaje de ontología en el que están especificadas. Estas ontologías se utilizan para representar (i) la semántica de procesos de negocio para determinar la similaridad entre dos procesos [45] y (ii) servicios web semánticos para comprobar la coreografía entre servicios descritos en OWL-S [290]. Del análisis del estado del arte en ontologías de HLPNs se puede concluir que ninguna de las ontologías propuestas en la bibliografía . Éste es un gran problema si la ontología se va a utilizar para modelar WFs y dar soporte a su ejecución. Las ontologías anteriormente descritas tampoco cumplen con el estándar ISO/IEC 159091, que especifica la estructura y semántica de las HLPNs: ninguna de las ontologías separa la firma sintáctica del álgebra que permite interpretarla y, por lo tanto, posibilitan una menor reutilización de las redes. Finalmente reseñar que la mayoría de las propuestas están orientadas a la transferencia/intercambio de grafos de PNs, de modo que detallan aspectos visuales como posiciones en la pantalla o colores, que tienen más que ver con los editores gráficos que con las propias redes. 1http://protege.stanford.edu/
3.4. Ontología de HLPNs 109 3.4. Ontología de HLPNs Las HLPNs definen la base a partir de la cual se representan los procesos en esta tesis doctoral: todos los procesos son en último término una HLPN y gracias a ello las herramientas de análisis de las propiedades y del comportamiento de estas redes pueden aplicarse a los WFs. Por lo tanto, un proceso se compone de un conjunto de plazas, transiciones, arcos y anotaciones que representan un grafo de PN. El éxito de estas redes radica precisamente (i) en su estructura en forma de grafo, que posibilita modelar sistemas complejos con facilidad, y además (ii) en su capacidad de análisis, que permite estudiar tanto la topología de los grafos como su comportamiento. La ontología que se presenta en este apartado describe las HLPNs como un componente más de conocimiento [266, 276]: especifica de modo explícita y formal la conceptualización de las HLPN, es decir, detalla la semántica de sus conceptos y sus propiedades, de forma que puedan ser entendidos por máquinas a través de un formalismo lógico. El objetivo es que un motor de inferencia pueda razonar sobre las instancias de los conceptos de la ontología, o lo que es lo mismo, que pueda razonar sobre las HLPNs. Además, el modelo que se presenta en este apartado está basado en el estándar ISO/IEC 15909-1 [144] que recoge el conocimiento consensuado de lo que es una HLPN a través de su descripción matemática. Esta ontología captura dicha especificación matemática y la traslada a (i) una taxonomía que recoge tanto los elementos estáticos como los dinámicos de estas redes, (ii) un conjunto de axiomas que restringen la semántica de los conceptos de dicha taxonomía, y (iii) una serie de reglas que modelan el conocimiento sobre la ejecución de la red. Ésta es una de las grandes ventajas de esta propuesta: con el razonador adecuado es posible definir y ejecutar una PN, ya que la ontología contiene todo el conocimiento necesario para ello. Además, esta ontología es compatible con el estándar ISO/IEC 15909-2 [145] para el intercambio de PNs entre distintas herramientas y aplicaciones. Ya que en la actualidad este estándar está siendo implantando en algunas de las más importantes herramientas de PNs, se han creado un conjunto de correspondencias que hacen compatibles los conceptos definidos en la ontología y en PNML. 3.4.1. Modelo estático Una de las propiedades más interesantes de las PNs es que su definición depende únicamente de componentes estáticos. Estos elementos constituyen las invariantes de las redes, es decir, aquellos elementos que no se ven afectados por la ejecución de la red. Por ejemplo, el grafo de una HLPN o las anotaciones del mismo no se pueden modificar durante una ejecución. Esta propiedad permite independizar la estructura de las redes de los elementos que intervienen en su ejecución y, por lo tanto, reutilizar el mismo grafo en múltiples ejecuciones. La Figura 3.12 representa a través de una red semántica el modelo estático propuesto. El concepto HLPN describe una PN de alto nivel y es el nodo raíz de la taxonomía.
110 3. Una ontología de redes de Petri para modelar procesos Operator Application Variable Term hasArguments Transition Place Node Arc hasSourceNode hasTargetNode hasGuard hasAnnotations HLPN hasNodes hasArcs hasVariables hasAlgebra hasSignature Sort Operator Signature hasOperators hasSorts Carrier Function Algebra hasFunctions hasCarriers interpretsOperator hasSort hasOperator Formula hasExpression hasRange hasDomain is-a is-a is-a is-a hasSort interpretsSort hasRange hasDomain Formula hasMappings Figura 3.12: Red semántica del modelo estático de la ontología de HLPNs donde las elipses modelan conceptos de la ontología y los arcos las relaciones entre dichos conceptos aunque estos últimos no reflejan la cardinalidad de dichas relaciones. El detalle de esta cardinalidad puede consultarse en el código asociado a cada uno de los conceptos. Este elemento aglutina al conjunto de conceptos que estructuran una HLPN como un grafo bipartito y dirigido: subClassOf(HLPN, Thing). La definición de una HLPN tiene tres partes: el nombre y la descripción, que aportan información acerca de las características de la red; los nodos y los arcos, que permiten describir su estructura; y finalmente la firma, álgebra y variables, que facilitan su
3.4. Ontología de HLPNs 111 anotación algebraica. De forma más detallada, los atributos del concepto HLPN son los siguientes: La propiedad hasName se refiere al nombre de la HLPN que puede usarse como identificador de la red: dataProperty(hasName). domain(hasName, HLPN). range(hasName, String). La propiedad hasDescription proporciona una breve descripción de la HLPN que resume su funcionalidad y sus particularidades: dataProperty(hasDescription). domain(hasDescription, HLPN). range(hasDescription, String). maxCardinality(hasDescription, 1). La relación hasNodes contiene los vértices o nodos del grafo, que pueden ser plazas o transiciones: objectProperty(hasNodes). domain(hasNodes, HLPN). range(hasNodes, Node). La relación hasArcs contiene las aristas del grafo, que se caracterizan por ser dirigidas y conectar nodos de distinto tipo: objectProperty(hasArcs). domain(hasArcs, HLPN). range(hasArcs, Arc). La relación hasSignature contiene la firma sintáctica de la red, que agrupa los colores (tipo de las plazas) y operadores que se pueden usar para anotar la HLPN. Es sintáctica, ya que declara los elementos, pero no los dota de ninguna semántica operacional (por ejemplo, los operadores no tienen implementado el código que realiza su funcionalidad): objectProperty(hasSignature). domain(hasSignature, HLPN). range(hasSignature, Signature). cardinality(hasSignature, 1). La relación hasAlgebra aporta la semántica operacional de las anotaciones de la red. Para que una red sea operativa, sus colores y operadores deben tener asociada una semántica, que se explicita en el nivel del lenguaje de representación de la ontología:
112 3. Una ontología de redes de Petri para modelar procesos objectProperty(hasAlgebra). domain(hasAlgebra, HLPN). range(hasAlgebra, Algebra). cardinality(hasAlgebra, 1). Las anotaciones están descritas mediante términos que pueden ser variables o llamadas a operadores. La relación hasVariables contiene las variables con las que se anota la red: objectProperty(hasVariables). domain(hasVariables, HLPN). range(hasVariables, Variable). 3.4.1.1. Estructura del grafo Como se comentó anteriormente, las HLPNs son grafos dirigidos con dos tipos de nodos. El concepto Node se refiere a los vértices del grafo, independientemente de su tipo, y define una partición exhaustiva y disjunta, de forma que todos los nodos sean o bien una plaza o bien una transición, y que además no puedan ser simultáneamente de ambos tipos: subClassOf(Node, Thing). subClassOf(Place, Node). subClassOf(Transition, Node). oneOf(Node,[Place, Transition]). disjoint(Place, Transition). Los nodos se identifican por uno o varios nombres. Debido a la complejidad y tamaño de estas redes, su diseño suele realizarse en distintas etapas y típicamente consiste en la unión de distintos modelos. Por ello, cabe la posibilidad de que los nodos estén identificados por distintos nombres: domain(hasName, Node). Para distinguir las marcas asociadas a una plaza, la relación hasSort asocia un color al concepto Place. El nombre color es herencia de las PNs coloreadas, que son el fundamento de las redes de alto nivel: objectProperty(hasSort). domain(hasSort, Place). range(hasSort, Sort). cardinality(hasSort, 1). Por ejemplo, las plazas p1,4,p2,5yp6de la Figura 3.13 son de tipo pieza lo que implica que dichas plazas únicamente pueden contener marcas del tipo pieza. En cambio, la plaza p3contendrá marcas del tipo maquina.
3.4. Ontología de HLPNs 113 p1,4 t1, 2 p2,5 p3t3p6 x+y x+y ax+y a m m b m maquina pieza pieza pieza [(x=a and y=b) or (x=b and y=a)] [(x=a and y=b) or (x=b and y=a)] Figura 3.13: PN que representa el estado inicial de una máquina de ensamblaje p1,4 t1, 2 p2,5 p3t3p6 x+y x+y ax+y a m m b m maquina pieza pieza pieza [(x=a and y=b) or (x=b and y=a)] [(x=a and y=b) or (x=b and y=a)] Figura 3.14: Estado de la máquina de ensamblaje tras el disparo de la transición t1,2 A diferencia de las PNs de bajo nivel, la ejecución de una transición en una HLPN puede estar condicionada por las precondiciones asociadas a la transición, y por las restricciones de la regla de disparo de transiciones. La relación hasGuard del concepto Transition contendrá la condición de activación asociada a la transición que dará soporte a este comportamiento: objectProperty(hasGuard). domain(hasGuard, Transition). range(hasGuard, Term). cardinality(hasGuard, 1). En PNs, si una transición no está activa, no podrá ocurrir. Por ejemplo, si en la plaza p1,4de la Figura 3.13 no existe al menos una pieza de tipo ay otra de tipo b, la transición t1,2no podrá ocurrir al no verificarse su precondición (x=a∧y= b)∨(x=b∧y=a). El concepto Arc representa las aristas del grafo. En PNs, estos arcos son dirigidos: la relación hasSourceNode apunta al nodo origen de la arista, mientras que la relación hasTargetNode apunta al nodo destino. Al ser redes bipartitas los arcos no pueden establecer una conexión entre nodos del mismo tipo; es decir, un arco no puede conectar dos plazas o dos transiciones: subClassOf(Arc, Thing). objectProperty(hasSourceNode). domain(hasSourceNode, Arc). range(hasSourceNode, Node). cardinality(hasSourceNode, 1). objectProperty(hasTargetNode). domain(hasTargetNode, Arc). range(hasTargetNode, Node). cardinality(hasTargetNode, 1).
120 3. Una ontología de redes de Petri para modelar procesos En este contexto, un álgebra proporciona una semántica operacional a cada uno de los colores y de los operadores de la firma, es decir, asocia soportes a colores y funciones a operadores a través de las relaciones interpretsSort einterpretsOperator, respectivamente: objectProperty(interpretsSort). domain(interpretsSort, Carrier). range(interpretsSort, Sort). maxCardinality(interpretsSort, 1). objectProperty(interpretsOperator). domain(interpretsOperator, Function). range(interpretsOperator, Operator). maxCardinality(interpretsOperator, 1). Cuando una función interpreta a un operador es necesario que el dominio y rango de la función coincidan con los del operador. Así, la relación functionDomain contiene una lista de soportes donde cada soporte interpreta el correspondiente color dentro del dominio del operador. Lo mismo sucederá con la relación functionRange para el rango de la función y del operador. Por ejemplo, si la función autenticar : cadena ×cadena →logico interpreta al operador login :string ×string →boolean es necesario que los tipos cadena ylogico sean los soportes de los colores string y boolean, respectivamente. objectProperty(functionDomain). domain(functionDomain, Function). range(functionDomain, CarrierList). cardinality(functionDomain, 1). objectProperty(functionRange). domain(functionRange, Function). range(functionRange, Carrier). cardinality(functionRange, 1). La separación entre (i) soportes y colores y entre (ii) funciones y operadores permite utilizar distintas álgebras (nivel semántico) para una misma firma (nivel sintáctico). Esto también facilita la definición de HLPNs independientemente del álgebra usada en su ejecución. Por ejemplo, la red de la Figura 3.13 podría usarse para controlar otros procesos distintos al proceso de ensamblaje para el cual ha sido diseñada. Por ejemplo, si esta red se quiere usar para mezclar dos componentes de un pienso para animales, bastaría con usar un álgebra donde el soporte compuesto interprete el color pieza, el soporte mezclador interprete el color máquina, y un par de instancias del soporte compuesto interpretasen las constantes ayb. La expresividad de las funciones del álgebra estará limitada por la expresividad del modelo de representación del lenguaje de la ontología en la que se implementa. Por ejemplo, las propiedades hasMappings yhasExpression dependerán del lenguaje en que se implementen, en la medida en que si se describen con F-Logic serán mucho más expresivas que en OWL (que tiene un conjunto predefinido y limitado de funciones).
3.4. Ontología de HLPNs 121 objectProperty(hasMappings). domain(hasMappings, Carrier). range(hasMappings, Formula). cardinality(hasMappings, 1). La propiedad hasMappings se utiliza para renombrar o definir correspondencias entre soportes y colores y entre funciones y operadores. Por ejemplo, se puede usar para establecer correspondencias entre formatos distintos de fechas. objectProperty(hasExpression). domain(hasExpression, Function). range(hasExpression, Formula). cardinality(hasExpression, 1). La propiedad hasExpression permite definir una fórmula que actuará como descripción operacional de la función (o lo que es lo mismo, será su implementación). Cuando el motor de HLPNs evalúa un término que hace uso de un operador, accede a la función que interpreta dicho operador y ejecuta su expresión con los datos correspondientes. La Tabla 3.4 recoge los axiomas que aseguran que todos los colores y operadores de la firma sintáctica son interpretados por los soportes y las funciones incluidas en el álgebra. 3.4.2. Modelo dinámico El modelo presentado en el apartado anterior describe las HLPNs independientemente de su estado. Es una propiedad deseable en cualquier modelo y que además permite razonar acerca de la estructura y definiciones de la red sin tener en cuenta o depender de su estado. Como complemento a este modelo estático en este apartado se describen dos nuevos modelos que permiten capturar el estado y la ejecución de las HLPNs. A través de ellos se podrá saber tanto el estado de la red en un determinado instante de tiempo como la sucesión de eventos que la han llevado a dicho estado. Además, estos modelos se han diseñado con la intención de facilitar la depuración de la ejecución. Para cada evento se guardará el valor que toman cada una de las variables y cada uno de los términos que anotan los arcos relacionados con las transiciones ejecutadas. 3.4.2.1. Estado El modelo de situación se representa en la Figura 3.15 y describe aquellos componentes que definen el estado de una HLPN, el cualestá compuesto por las marcas localizadas en cada una de las plazas. Este modelo, por tanto, describe los conceptos que permiten relacionar una plaza con sus marcas en cada instante de ejecución de la red. El concepto PlaceMarking define el estado de una plaza: subClassOf(PlaceMarking, Thing).
122 3. Una ontología de redes de Petri para modelar procesos Tabla 3.4: Axiomas que restringen al álgebra de una HLPN En una HLPN, cada tipo de datos de la firma sintáctica (Sort) tiene un tipo de datos asociado dentro del álgebra (Carrier). ∀A, H, S, SoAlgebra(A)∧HLPN(H)∧Signature(S)∧Sort(So)∧ hasSignature(H, S)∧hasAlgebra(H, A)∧hasSorts(S, So)→ ∃C Carrier(C)∧hasCarriers(A, C)∧interpretsSort(C, So) En una HLPN, cada operador de la firma sintáctica tiene una función asociada dentro del álgebra. ∀A, H, S, OAlgebra(A)∧HLPN(H)∧Signature(S)∧Operator(O)∧ hasSignature(H, S)∧hasAlgebra(H, A)∧hasOperators(S, O)→ ∃F Function(F)∧hasF unctions(A, F )∧interpretsOperator(F, O) El dominio de una función está compuesto por una lista de tipos de datos (Carrier) del álgebra. Cada uno de estos tipos tiene asociado dentro del contexto de la firma sintáctica a su par correspondiente, de forma que el dominio de la función y del operador asociado a la función coincidan. ∀F, LF, LO, O, S F unction(F)∧Operator(O)∧Sort(S)∧ interpretsOperator(F, O)∧functionDomain(F, LF)∧operatorDomain(O, LO)∧ member(S, LO)→ ∃C Carrier(C)∧member(C, LF)∧interpretsSort(C, S) El rango de una función está definido por un tipo de dato (Carrier) del álgebra que interpreta a su par correspondiente dentro del contexto de la firma sintáctica, de forma que el rango de la función y del operador asociado a la función coincidan. ∀F, O, S F unction(F)∧Operator(O)∧Sort(S)∧interpretsOperator(F, O)∧ functionRange(F, S)→ ∃C Carrier(C)∧interpretsSort(C, S) objectProperty(hasPlace). domain(hasPlace, PlaceMarking). range(hasPlace, Place). cardinality(hasPlace, 1). objectProperty(hasTokens). domain(hasTokens, PlaceMarking). range(hasTokens, FunctionMultiset). maxCardinality(hasTokens, 1). La relación hasPlace se refiere a la plaza cuyo estado está siendo representado, mientras que la relación hasTokens contiene una lista de valores. De esta forma, el concepto PlaceMarking asocia una plaza al conjunto de marcas que contiene. Como ya se comentó a lo largo de este capítulo, los valores (o constantes) se representan como funciones sin dominio, por lo que la relación hasTokens apunta a una lista (multiconjunto) de funciones. Por ejemplo, suponiendo que la red de la Figura 3.13 se utiliza para mezclar piensos, el valor ase definiría como una función a: []−> compuesto, es decir, sería una constante (no tiene dominio) con rango de tipo compuesto. Los valores almacenados en una plaza han de cumplir una restricción adicional: su rango ha de ser compatible con el color de la función, o lo que es lo mismo, el rango soporte de la función debe interpretar el color de la plaza. En el ejemplo anterior esta restricción se cumple, ya que el soporte compuesto interpreta el color pieza.
3.4. Ontología de HLPNs 123 hasPlace hasPlaceMarkings Marking Place Place Marking Function ( constant ) hasTokens (multiset) Figura 3.15: Red semántica del modelo de situación de las HLPNs Tabla 3.5: Axiomas que restringen al estado de la red El estado de la red contiene un único estado asociado a cada plaza. ∀E, H, M, P, M1, M2Marking(M)∧Place(P)∧P laceMarking(M1)∧ PlaceMarking(M2)∧hasP laceMarkings(M, M1)∧hasP laceMarkings(M, M2)∧ hasPlace(M1, P)∧hasPlace(M2, P )→M1=M2 Los valores asociados a una plaza son “compatibles” con el color de dicha plaza. ∀C, F, M, P, L, S Carrier(C)∧F unction(F)∧P laceMarking(M)∧ Place(P)∧hasP lace(M, P)∧hasT okens(M, L)∧member(F, L)∧ functionRange(F, C)∧hasSort(P, S)→interpretsSort(C, S) Las marcas de las plazas son constantes. ∀F, M, L F unction(F)∧PlaceMarking(M)∧hasT okens(M, L)∧ member(F, L)→functionDomain(F, []) El estado completo de la red se representa por medio del concepto Marking, que agrupa el estado de cada una de las plazas a través de la relación hasPlaceMarkings: subClassOf(Marking, Thing). objectProperty(hasPlaceMarkings). domain(hasPlaceMarkings, Marking). range(hasPlaceMarkings, PlaceMarking). inverseOf(hasMarking, hasPlaceMarkings). Por ejemplo, el estado inicial de la red representada en la Figura 3.13 contendría las instancias del concepto PlaceMarking asociados a las plazas p1,4yp3. Es necesario comentar que el estado de cada plaza (place marking) se incluye una única vez en el estado correcto de la red (marking). En caso contrario, una plaza podría estar en varios estados en el mismo instante de tiempo, lo cual sería inconsistente con la especificación ISO/IEC 15909-1. La Tabla 3.5 recoge los axiomas que aseguran que tanto el concepto Marking como el concepto PlaceMarking capturan la semántica de estado previamente detallada.
124 3. Una ontología de redes de Petri para modelar procesos hasModes (multiset) Marking Firing HLPN hasCurrent Marking hasInitial Marking HLPN Execution executes hasTarget Marking hasSource Marking Mode Transition Evaluation Assignment Operation Evaluation hasTransition hasEvaluations hasBindings Term Carrier hasValue evaluates Term hasFirings is-a is-a Figura 3.16: Red semántica del modelo de ejecución de las HLPNs 3.4.2.2. Ejecución El modelo de ejecución captura el flujo de información definido entre dos estados de la red. Específicamente, detalla el camino de eventos a seguir para alcanzar un estado dado, entendiendo por evento al disparo u ocurrencia de una transición. La Figura 3.16 representa este modelo, cuya raíz es el concepto HLPNExecution que asocia una determinada instancia de ejecución a una única red a través de la relación executes: subClassOf(HLPNExecution, Thing). objectProperty(executes). domain(executes, HLPNExecution). range(executes, HLPN). cardinality(executes, 1). Cada ejecución parte de un estado inicial (relación hasInitialMarking) y se encuentra en un estado actual (relación hasCurrentMarking): objectProperty(hasInitialMarking). domain(hasInitialMarking, HLPNExecution). range(hasInitialMarking, Marking). cardinality(hasInitialMarking, 1). objectProperty(hasCurrentMarking). domain(hasCurrentMarking, HLPNExecution). range(hasCurrentMarking, Marking). cardinality(hasCurrentMarking, 1).
3.4. Ontología de HLPNs 125 Además, el concepto HLPNExecution también contiene el conjunto de eventos que han producido un cambio de estado a través de la relación hasFirings. Esta relación almacena ordenadamente cada disparo de una transición de una lista ordenada, y con ello se puede seguir la traza desde el estado inicial hasta el estado actual de ejecución. objectProperty(hasFirings). domain(hasFirings, HLPNExecution). range(hasFirings, FiringList). maxCardinality(hasFirings, 1). El concepto Firing (disparo en castellano) es el núcleo del modelo de ejecución, dado que captura el cambio de estados producido por el disparo de un conjunto de transiciones: subClassOf(Firing, Thing). Un disparo se refiere a un paso de ejecución entre un estado inicial y un estado final. Las relaciones hasSourceMarking yhasTargetMarking apuntan respectivamente a estos estados: objectProperty(hasSourceMarking). domain(hasSourceMarking, Firing). range(hasSourceMarking, Marking). cardinality(hasSourceMarking, 1). objectProperty(hasTargetMarking). domain(hasTargetMarking, Firing). range(hasTargetMarking, Marking). cardinality(hasTargetMarking, 1). Por ejemplo, supóngase que el disparo f1representa el cambio de estado entre las figuras 3.13 y 3.14. En este caso, f1detalla el paso de un estado m1: [p1,4={a, b}, p2,5= ∅, p3={m}, p6=∅] a un estado m2: [p1,4=∅, p2,5={a, b}, p3={m}, p6=∅]. Es necesario precisar que el concepto Firing no está restringido a la ejecución de una única transición, sino que puede referirse a un multiconjunto de transiciones; es decir, el disparo se identifica con un paso de ejecución, independientemente del número de transiciones ejecutadas en él. Es más, en un mismo paso, una misma transición puede ejecutarse varias veces, por lo que es necesario distinguir cada una de esas ejecuciones. Por ello, la relación hasModes apunta a una lista con cada uno de los modos de transición ejecutados: objectProperty(hasModes). domain(hasModes, Firing). range(hasModes, ModeMultiset). cardinality(hasModes, 1).
126 3. Una ontología de redes de Petri para modelar procesos Un modo de transición (concepto Mode) asocia una transición a un conjunto de asignaciones de variables. Específicamente, un modo indica que una transición está activa (se cumple su precondición) cuando un conjunto de variables toman un determinado valor. La relación hasTransition se refiere a la transición activa, mientras que la relación hasBindings apunta al conjunto de asignaciones que permiten activar dicha transición: subClassOf(Firing, Thing). objectProperty(hasTransiton). domain(hasTransiton, Mode). range(hasTransiton, Transition). cardinality(hasTransiton, 1). objectProperty(hasBindings). domain(hasBindings, Mode). range(hasBindings, Assignment). cardinality(hasBindings, 1). En el ejemplo de ensamblaje de la Figura 3.13 un posible modo para la transición t1,2 tendría los siguientes valores x=aey=b. Este mismo modo podría usarse en el diaparo f1que establece el paso de la red de un estado m1a un estado m2. Dado que un disparo permite la ejecución de varios modos de transición, es necesario asegurar que: Una variable no puede tomar valores diferentes en un mismo disparo. Por lo tanto, los distintos modos de transición del paso compartirán las mismas asignaciones. Existen suficientes valores en las plazas de entrada para satisfacer la ejecución concurrente de los modos que componen el paso. Por ejemplo, si el estado inicial de la red de la Figura 3.13 fuese m1: [p1,4={a, a, b, b}, p2,5=∅, p3={m}, p6= ∅], en un paso se podría disparar dos veces la transición t1,2con los valores x=a ey=b. El cambio entre dos estados está definido por los valores que se han consumido y aquellos que se han producido después de la ejecución de un evento. Para completar el modelo de ejecución, la ontología también captura la evaluación de los términos que indican qué marcas es necesario consumir y cuáles producir. De esta forma, es posible comprobar la corrección del cambio de estado verificando que, para los modos de transición ejecutados, las marcas eliminadas se corresponden con las evaluaciones de los arcos de entrada y que las nuevas marcas se corresponden con las evaluaciones de los arcos de salida de los modos de transición ejecutados. Cuando se calcula el valor de un término, esta ontología permite guardar su evaluación a través del concepto Evaluation: subClassOf(Evaluation, Thing).
3.4. Ontología de HLPNs 127 objectProperty(evaluatesTerm). domain(evaluatesTerm, Evaluation). range(evaluatesTerm, Term). cardinality(evaluatesTerm, 1). objectProperty(hasValue). domain(hasValue, Evaluation). range(hasValue, Carrier). cardinality(hasValue, 1). La relación evaluatesTerm se refiere al término evaluado mientras que la relación hasValue guarda su valor. Además, el modelo contempla dos tipos de evaluaciones en función de si el término es una variable o una llamada a un operador: subClassOf(Assignment, Evaluation). subClassOf(OperatorEvaluation, Evaluation). allValuesFrom(evaluatesTerm, Assignment, Variable). allValuesFrom(evaluatesTerm, OperatorEvaluation, OperatorApplication). oneOf(Evaluation,[Assignment,OperatorEvaluation]). disjoint(Assignment, OperatorEvaluation). El concepto Assignment captura la evaluación de una variable, mientras que el concepto OperatorEvaluation hace lo propio con la evaluación de la llamada a un operador, la cual extiende el concepto Evaluation con la relación hasEvaluations, que se refiere al valor que toma cada uno de los parámetros de la llamada al operador. Como cada uno de esos parámetros es un término, el valor se determinará a partir de su evaluación: objectProperty(hasEvaluations). domain(hasEvaluations, OperatorEvaluation). range(hasEvaluations, EvaluationList). maxCardinality(hasEvaluations, 1). La Tabla 3.6 recoge los axiomas que restringen la semántica del modelo de ejecución representado en la Figura 3.16. 3.4.3. Reglas El desarrollo de esta ontología se ha fundamentado en una aproximación homogénea donde la taxonomía, los axiomas y las reglas están representadas en un mismo lenguaje lógico. Específicamente, se usó el lenguaje F-Logic [152]. Este lenguaje está basado en el formalismo de la lógica de marcos y permite combinar reglas y taxonomías de forma natural. Así, se han definido reglas que permiten (i) gestionar la creación, modificación y borrado de los elementos que componen estas redes; y (ii) ejecutarlas. En este sentido, la capa de reglas está unida al formalismo de lógica de marcos y no es
128 3. Una ontología de redes de Petri para modelar procesos Tabla 3.6: Axiomas que restringen a la ejecución de la red El resultado de una evaluación tiene un tipo que interpreta el color del término que evalúa. ∀E, T, S Evaluation(E)∧T erm(T)∧Sort(S)∧ evaluatesT erm(E, T )∧hasV alue(E, V )∧hasSort(T, S)→ ∃C instance(V, C)∧Carrier(C)∧interpretsSort(C, S) En un modo de transición, la evaluación de la precondición de la transición tiene el valor true para el conjunto de asignaciones definido. ∀E, T, P, M, B Evaluation(E)∧T ransition(T)∧ Term(P)∧Mode(M)∧evaluatesTerm(E, P )∧ hasTransition(M, T )∧hasGuard(T, P )∧hasV alue(E, V )∧ hasBindings(M, B)∧validBinding(B)→V=true directamente aplicable a razonadores basados en lenguajes con una menor expresividad (como, por ejemplo, OWL). Sin embargo, la adaptación a las características de otro razonador es posible, ya que las reglas expresadas en F-Logic se pueden trasladar a lenguajes lógicos más conocidos que comparten una sintaxis similar, como Prolog. Por esta razón, y para facilitar su comprensión, las reglas se expresarán en Prolog. 3.4.3.1. Reglas para la evaluación de términos El dinamismo de las HLPNs está determinado por la evaluación de sus anotaciones. Las reglas que evalúan las llamadas a los operadores y a las variables son los elementos más representativos de esta categoría. Por una parte, las asignaciones de las variables que anotan los arcos de las redes se infieren con la siguiente regla: Assignment(asi(?_var, ?_tok)) :- hasCurrentMarking(?_exe, ?_mar), hasMarking(?_pma, ?_mar), hasPlace(?_pma, ?_pla), hasTokens(?_pma, ?_tol), hasSourceNode(?_arc, ?_pla), hasAnnotation(?_arc, ?_tel), useTerm(?_arc, ?_var), hasSort(?_pla, ?_sor), hasSort(?_var, ?_sor), member(?_tok, ?_tol). Esta regla requiere que los arcos tengan como nodo de inicio una plaza que contenga una marca. Por lo tanto, se limita la creación de asignaciones a las marcas existentes en la red, para así no sobrecargar el razonador con asignaciones y evaluaciones innecesarias. El predicado useTerm se utiliza para comprobar si el término que anota el arco o alguno de sus (sub)términos contienen la variable a evaluar. Cada vez que la regla anterior se evalúa con éxito, se genera un nuevo hecho (en este caso una asignación) con el identificador asi(?_var, ?_tok), donde ?_var
3.4. Ontología de HLPNs 129 y?_tok indican la variable y el valor que conforman la asignación respectivamente. Esta asignación se completa asociando al identificador las propiedades evaluatesTerm yhasValue a través de las siguientes reglas: evaluatesTerm(asi(?_var, ?_tok), ?_var) :- Assignment(asi(?_var, ?_tok)). hasValue(asi(?_var, ?_tok), ?_tok) :- Assignment(asi(?_var, ?_tok)). Por otra parte, las llamadas a operadores se evalúan con dos reglas. La primera contempla la evaluación de las constantes (la propiedad hasArguments es una lista vacía), y en ella la llamada a la constante está representada por la expresión ?_nam([], ?_tok), donde la variable ?_nam indica el nombre de la función a invocar, el símbolo [] indica que la llamada no tiene parámetros, y la variable ?_tok contiene el resultado de la evaluación: OperatorEvaluation(ope(?_opa, ?_tok, [])) :- hasOperator(?_opa, ?_opr), hasArguments(?_opa, []), interpretsOperator(?_fun, ?_opr), hasName(?_fun, ?_nam), ?_nam([], ?_tok). La segunda regla se refiere a la evaluación de los operadores n-arios con un número de argumentos mayor que cero: OperatorEvaluation(ope(?_opa, ?_tok, ?_evl)) :- HLPNExecution(?_exe), hasHLPN(?_exe, ?_net), hasCurrentMarking(?_exe, ?_mar), hasNodes(?_net, ?_tra), Transition(?_tra), hasInputTokens(?_tra, ?_mar), useTerm(?_tra, ?_opa), hasOperator(?_opa, ?_opr), hasArguments(?_opa, ?_arl), getArgumentListEvaluation(?_arl, ?_evl), formatOperatorArguments(?_evl, ?_cal), interpretsOperator(?_fun, ?_opr), hasName(?_fun, ?_nam), ?_nam(?_cal, ?_tok). En esta segunda regla se filtran los operadores a evaluar tomando únicamente aquellos relacionados con una transición que contiene marcas en cada una de sus plazas de entrada. Por un lado, el predicado hasInputTokens indica las transiciones ?_tra activas en un determinado estado ?_mar. Por el otro, el predicado useTerm indica los términos que se relacionan con cada transición, es decir, los términos que anotan sus arcos de entrada y de salida, y sus precondiciones. En el caso de que el término
232 5. Modelo de control HLPN2 x x x Context Context Context scheduling Enabled scheduling Finished scheduling Input schedulingPreconditionIf [ resources(x,r) and not empty l(r) ] schedulingPreconditionElse [ not (resources(x,r) and not empty l(r)) ] scheduling scheduling Output schedulingPostconditionIf [ operations (x,s) and member(o,s) => assignment (o,r) ] schedulingPostconditionElse [ not (operations (x,s) and member(o,s) => assignment (o,r)) ] x message (scheduling , precondition , x) message (scheduling , postcondition , x) x Execute Substitution assignOperation Context Context Context End Assignment begin Assignment x x x x hasMoreOperations [ operations (x,o) and scheduledOperations (x,s) and length (o) > length (s) ] noMoreOperations [ not (operations (x,o) and scheduledOperations (x,s) and length (o) > length (s)) ] Red de Petri de alto nivel aplanada x x x Context Context scheduling Finished scheduling Input schedulingPreconditionIf [ resources(x,r) and not empty l(r) ] schedulingPreconditionElse [ not (resources(x,r) and not empty l(r)) ] scheduling Output schedulingPostconditionIf [ operations (x,s) and member(o,s) => assignment (o,r) ] schedulingPostconditionElse [ not (operations (x,s) and member(o,s) => assignment (o,r)) ] x message(scheduling , precondition , x) message (scheduling , postcondition , x) x assignOperation Context Context begin Assignment x x x x hasMoreOperations [ operations (x,o) and scheduledOperations (x,s) and length (o) > length (s) ] noMoreOperations [ not (operations (x,o) and scheduledOperations (x,s) and length (o) > length (s)) ] HLPN1 Figura 5.23: Sustitución de la transición scheduling por un patrón repetir-mientras construcciones de control donde la primera representa un patrón separaciónunión y la segunda una estructura iterativa repetir-mientras. Además no existe ninguna limitación para este tipo de sustituciones, permitiendo la definición de descripciones operacionales muy complejas. La unión entre las redes se efectúa a través de la sustitución de una transición hasControlTransitionipor uno de los patrones que representan una construcción de control. El concepto ControlSubstitution ha sido definido para dar soporte a este tipo de sustitución: subClassOf(ControlSubstitution, TransitionSubstitution). allValuesFrom(hasRefinement, ControlSubstitution, ControlPattern). Este concepto restringe la relación hasRefinement para que únicamente pueda tomar un valor del tipo ControlPattern, es decir, un patrón del tipo secuencia, separación-sincronización,elección exclusiva-mezcla,elección múltiple-mezcla
5.6. Anotación algebraica 233 Tabla 5.16: Axiomas que restringen la semántica del concepto ExecuteSubstitution El nodo sustituido es la transición run process del patrón proceso. ∀S, T ExecuteSubstitution(S)∧hasAbstraction(S, T )→ ∃P ProcessP attern(P)∧hasRunP rocessT ransition(P, T) Una de las fusiones debe agrupar a la plaza de entrada del patrón sustituto con la plaza de entrada de la transición sustituida. ∀R, S, F ExecuteSubstitution(S)∧hasRefinement(S, R)∧hasInterfaces(S, F )→ ∃P, P1, P2ProcessPattern(P)∧hasFusionSet(F, P1)∧hasFusionSet(F, P2)∧ hasInputP lace(R, P1)∧hasInputP lace(P, P2) Una de las fusiones definida debe agrupar a la plaza de salida del patrón resultado con la plaza de salida de la transición sustituida. ∀R, S, F ExecuteSubstitution(S)∧hasRefinement(S, R)∧hasInterfaces(S, F )→ ∃P, P1, P2ProcessPattern(P)∧hasFusionSet(F, P1)∧hasFusionSet(F, P2)∧ hasOutputPlace(R, P1)∧hasOutputP lace(P, P2) Tabla 5.17: Axiomas que restringen la semántica del concepto ControlSubstitution El nodo sustituido es una transición del tipo control constructide un patrón de control. ∀S, T ControlSubstitution(S)∧hasAbstraction(S, T)→ ∃P, B ControlPattern(P)∧hasControlBlock(P, B)∧hasControlT ransitions(B, T ) Una de las fusiones debe agrupar a la plaza de entrada del patrón de control con la plaza de entrada de la transición sustituida. ∀R, S, F ControlSubstitution(S)∧hasRefinement(S, R)∧hasInterfaces(S, F )→ ∃P, P1, P2ControlP attern(P)∧hasF usionSet(F, P1)∧hasFusionSet(F, P2)∧ hasInputP lace(R, P1)∧hasInputP lace(P, P2) Una de las fusiones debe agrupar a la plaza de salida del patrón de control con la plaza de salida de la transición sustituida. ∀R, S, F ControlSubstitution(S)∧hasRefinement(S, R)∧hasInterfaces(S, F )→ ∃P, P1, P2ControlP attern(P)∧hasF usionSet(F, P1)∧hasFusionSet(F, P2)∧ hasOutputPlace(R, P1)∧hasOutputP lace(P, P2) múltiple, etc. La Tabla 5.17 contiene los axiomas que completan la definición de este concepto. 5.6. Anotación algebraica La anotación algebraica de las HLPNs permite precisar las condiciones de activación de los eventos de la red y los efectos del disparo de dichos eventos. Por ello, la potencia de los WFs dependerá de la expresividad del álgebra que interprete las anotaciones. En este apartado se describirá la firma de estas redes, es decir, los colores que anotarán las plazas y los operadores para construir los términos, ya que el álgebra que la interpreta se asociará a través de los modelos del dominio del metamodelo.
234 5. Modelo de control Patrón Secuencia hasControl Transition 1 Context ContextContext hasInputPlace hasOutputPlacehasControl Transition2 Control Substitution hasAbstractionhasRefinement Control Substitution hasAbstraction hasRefinement hasSplit Transition Patrón Separación-Unión hasJoin Transition hasControl Transition2 hasControl Transition1 Context Context Context Context ContextContext hasOutput Place hasInput Place x x x x x x Patrón Repetir-Mientras hasControl Transition Context Context Context hasOutput Place hasInput Place x x x x hasIfTransition [ whileCondition ] hasElseTransition [ not whileCondition ] Figura 5.24: Ejemplo de sustitución de construcciones de control 5.6.1. Contexto de ejecución En el metamodelo de WFs, el flujo de datos y de control no siempre tienen por qué coincidir. En ocasiones los PSMs no circunscriben los roles/parámetros al método sino que son accesibles desde otros método sin que exista un paso de parámetro de por medio. Esto se debe a la distinción entre los roles de conocimiento dinámicos y estáticos: los roles dinámicos, como son las entradas y salidas, sí están circunscritos al método, sin embargo, no existe un criterio para los roles estáticos. Por ejemplo, un rol estático podría utilizarse en distintos métodos y suelen representar elementos globales, como un conjunto de restricciones de fabricación y, por lo tanto, no suelen cambiar a lo largo del tiempo. Por ello cuando intervienen roles estáticos suele existir una disparidad entre el flujo de datos y el flujo de control establecido por el proceso. En estas situaciones caben dos posibles actuaciones: 1. Definir dos HLPNs, una para los datos y otra para el control, y unirlas. Con esta solución el diseño de la red de datos tendría una plaza por cada entrada y parámetro local y global del proceso, y otra plaza por cada salida. El valor del parámetro sería la marca situada en la correspondiente plaza. Esta solución tiene varios inconvenientes: Un parámetro puede tener múltiples valores, ya que una plaza puede almacenar varias marcas. No se puede usar la misma red para la ejecución de múltiples instancias del mismo proceso, ya que no se puede distinguir entre las marcas de una instancia y las de otra.
5.6. Anotación algebraica 235 Parámetro A Parámetro B Proceso 1 Proceso 2 Parameter B Parámetro A Parámetro B Proceso 1 Proceso 2 Parámetro B Ocurrencia del proceso 1 Figura 5.25: Ejemplo de red para el control del flujo de datos El principio de localidad de las redes de Petri. Los dos primeros problemas se producirían únicamente si la red es reutilizada para varias ejecuciones. Estos inconvenientes pueden resolverse incrementando la complejidad de la red de forma que se pueda saber a qué instancia pertenece cada marca. El tercer problema es el más interesante, ya que está directamente ligado a la forma en la que se ejecutan las redes de Petri. Así, el disparo de una transición elimina las marcas de sus plazas de entrada y si éstas representan parámetros, entonces estos parámetros no tendrán valor después del disparo. Sin embargo, se supone que los parámetros mantienen sus valores si el proceso no los modifica explícitamente. Es más, si dos procesos comparten el mismo parámetro (la misma plaza) y uno de ellos se ejecuta, el otro nunca podrá ejecutarse. Por ejemplo, la Figura 5.25 muestra una red donde los procesos 1 y 2 comparten el mismo parámetro de entrada y el estado de la red después del disparo de la transición proceso1. Se puede ver como la ejecución elimina las marcas de entrada de esa transición y genera nuevas marcas en las plazas de salida de la transición. Después del disparo de la transición proceso1, la transición proceso2deja de estar activa y, por lo tanto, ya no puede ejecutarse. Para resolver este problema, los parámetros compartidos deben replicarse. Por ejemplo, la Figura 5.26 representa la adaptación de la red anterior: se utilizan dos transiciones para replicar los parámetros AyB. Con esta solución el disparo de la transición procesos1no afectará a la activación y, por lo tanto, a la ejecución de la transición proceso2, ya que ahora ambas transiciones no comparten ninguna plaza de entrada. Esta solución, no obstante, también tiene un problema cuando el disparo de una transición modifica el parámetro de entrada de otro proceso. En este escenario es posible que una transición lea un valor anticuado del parámetro, es decir, realice una lectura sucia. Por ejemplo, la Figura 5.27 muestra una red donde el disparo de la transición proceso1producirá un nuevo valor en la plaza parámetroA, pero la transición proceso2seguirá activa con el valor antiguo del parámetro A. Una solución a este problema consiste en la sincronización de los datos compartidos a través de semáforos, aunque claro está, el diseño de las redes se complica mucho. El flujo de control de la HLPN de esta primera solución también representa cada proceso por medio de una transición, pero no incluye las plazas que representan los parámetros del proceso. En esta red las plazas representan puntos de control
236 5. Modelo de control Parámetro A Proceso 1 Proceso 2 Parámetro B Replicar Parámetro A Parámetro A’ Parámetro A’’ Parámetro B Replicar Parámetro B Parámetro B’ Parámetro B’’ Figura 5.26: Ejemplo de red para el control del flujo de datos teniendo en cuenta el principio de localidad Parámetro A Replicar Parámetro A Parámetro A’ Parámetro A’’ Proceso 1 Proceso 2 Parámetro B Figura 5.27: Ejemplo del problema de lectura sucia en una red que controla el flujo de datos Proceso 1 Proceso 2 Figura 5.28: Ejemplo de red que representa un flujo de control de forma que se pueda ordenar la ejecución de los procesos. Por ejemplo, la Figura 5.28 representa una secuencia de procesos. La red de control y de datos de esta solución se combinan mediante la fusión de nodos: las transiciones que representan un mismo proceso en ambas redes se fusionan. Por ejemplo, la Figura 5.29 muestra un ejemplo de esta combinación. Sin embargo, la combinación de estas redes no cumple con las propiedades estructurales y de comportamiento que un WF basado en redes de Petri debería tener: no tiene una única plaza de entrada ni una única plaza de salida, no es fuertemente conexa, puede tener ciclos mortales, etc. 2. Independizar los datos del control. Esta solución, que a la postre fue la aplicada en esta tesis doctoral, añade complejidad a la anotación de la HLPN. Concretamente, consiste en definir un contexto de ejecución que actúa como un bus de datos y que contendrá cada uno de los parámetros de entrada, globales, locales y de salida que se utilizan en el proceso. Esta solución implica la definición (i)
5.6. Anotación algebraica 237 Parámetro A Replicar Parámetro A Parámetro A’ Parámetro A’’ Proceso 1 Proceso 2 Parámetro C Parámetro B Proceso 1 Proceso 2 Parámetro A Replicar Parámetro A Parámetro A’ Parámetro A’’ Proceso 1 Proceso 2 Parámetro C Parámetro B Flujo de datos Flujo de control Fusion Process 1 Fusion Process 2 Figura 5.29: Ejemplo de combinación de una red de datos y otra de control de un color que modele al contexto de ejecución y (ii) de un conjunto de operadores que representen las propiedades del contexto. Por una parte, este color anotará todas las plazas de las HLPNs, es decir, cada plaza de la red únicamente podrá almacenar instancias del tipo contexto de ejecución. Por otra parte, la firma contendrá un conjunto de operadores para relacionar este contexto con cada uno de los parámetros de los procesos. Por ejemplo, si el proceso que se quiere modelar tiene al parámetro1como entrada y al parámetro2como salida, la firma deberá contener dos operadores para acceder a los valores de sendos parámetros. Suponiendo que el tipo de dato del parámetro de entrada y de salida es integer yboolean respectivamente, estos dos operadores podrían crearse de la siguiente forma: parameter1:Context ×integer −→ boolean parameter2:Context ×boolean −→ boolean La Figura 5.30 representa una HLPN anotada con esta segunda solución, en la que todas las plazas están tipadas con el mismo contexto de ejecución y donde
238 5. Modelo de control Proceso 1 Proceso 2 Context Context Context [ parameter 1(x,i) and i > 0] x Figura 5.30: Ejemplo de la segunda aproximación para el modelado de WFs la precondición de la transición procesos1está anotada con una expresión que contiene el operador anterior. La evaluación de este operador permitirá acceder, a través del contexto de ejecución almacenado en la variable x, a un valor para la variable ique verifique la condición. Al trabajar siempre sobre el mismo contexto, las transiciones pueden acceder a cualesquiera datos y tomar sus decisiones en función de ellos. Sin embargo, aunque el contexto de ejecución sea el mismo, los valores de los parámetros con los que está relacionado se pueden modificar tras la ejecución de una transición. Por ejemplo, el disparo de una transición puede tomar el contexto de ejecución de su plaza de entrada y modificar un parámetro de salida de dicho contexto. Con esta solución se evitan los problemas de la propuesta anterior: no es necesario replicar nodos, definir semáforos, ni fusionar transiciones en las estructuras de control. Comentar que los niveles de composición del proceso no afectan a esta solución, ya que los identificadores de cada uno de los parámetros dentro del WF son únicos. Esto significa que dentro de un WF no puede haber dos variables distintas con el mismo identificador. Además, permite utilizar la red para la ejecución de varias instancias del proceso, ya que los identificadores de los contextos serán distintos para cada ejecución. Finalmente, es importante resaltar que, al contrario de la aproximación anterior, las redes resultantes cumplen con las propiedades que un WF basado en redes de Petri debería tener. 5.6.2. Firma sintáctica La firma sintáctica contiene las bases para la anotación de las HLPNs: define los colores que anotarán las plazas y los operadores que anotarán los arcos. La firma que anota las HLPNs debe cumplir con algunos requisitos. Uno de esos requisitos, relacionado con el apartado 5.6.1, es incluir el color Context que representa al contexto de ejecución que anotará las plazas de las HLPNs. A nivel sintáctico, el contexto de ejecución es una simple declaración: hasSorts(ControlSignature, Context). Sort(Context). hasName(Context, "Context"). hasName(Context, "Represents an abstract execution context"). Cabe mencionar que este color anotará todas las plazas de las HLPNs indicando de esta forma que todas las marcas que se vayan a localizar en las plazas de estas redes
5.6. Anotación algebraica 239 serán contextos de ejecución: ∀R, H, P ControlModel(C)∧Page(H)∧P lace(P)∧ ∧hasPages(C, H)∧hasNodes(H, P)→hasSort(P, Context) También es necesario comentar que no tiene sentido refinar este color y adecuarlo a un determinado proceso, ya que la firma únicamente describe elementos sintácticos, por lo que un subcolor de Context no añadiría nada. Además, el paso para adecuarlo a un determinado problema se realiza a través del tipo de dato que interpreta al contexto dentro del álgebra. Aunque el contexto de ejecución no es el único color definido dentro de la firma sintáctica sí es el único obligatorio: ∀R, H, S ControlModel(C)∧P age(H)∧Signature(S)∧ ∧hasPages(C, H)∧hasSignature(H, S)→hasSorts(S, Context) Además, cualquier firma incorporará por defecto algunos colores que representan los tipos básicos usados en programación. Por ejemplo, se incluyen los números enteros, números flotantes, símbolos, cadenas de texto, tipo lógico, además de los tipos que permiten tratar las fechas y el tiempo: hasSorts(ControlSignature, integer_sort). hasSorts(ControlSignature, float_sort). hasSorts(ControlSignature, symbol_sort). hasSorts(ControlSignature, string_sort). hasSorts(ControlSignature, boolean_sort). hasSorts(ControlSignature, date_sort). hasSorts(ControlSignature, time_sort). hasSorts(ControlSignature, dateTime_sort). hasSorts(ControlSignature, duration_sort). Los demás colores son añadidos en función de las necesidades del proceso. Estos colores, al igual que los que representan los tipos básicos, se usarán para especificar a los rangos y dominios de los operadores de la firma. En este sentido, también se incluyen a los operadores más significativos de cada uno de los tipos básicos. Por ejemplo la firma contendrá al operador de suma, resta, multiplicación, división y demás operadores de comparación de números enteros y flotantes, operadores de conjunción, disjunción, negación e igualdad, así como algunos operadores para tratar con el tiempo y las fechas: hasOperators(ControlSignature, integer_addition). hasOperators(ControlSignature, integer_subtraction). ... hasOperators(ControlSignature, true). hasOperators(ControlSignature, false). hasOperators(ControlSignature, boolean_and). ...
240 5. Modelo de control Estos operadores son representaciones sintácticas y, por lo tanto, no tienen asociada una implementación. Por ejemplo, el operador que realiza la suma de números enteros se definiría de la siguiente forma: Operator(integer_addition). hasName(integer_addition, "integer_addition"). hasDomain(integer_addition, [integer_sort, integer_sort]). hasRange(integer_addition, integer_sort). Dadas las características de este metamodelo, surge la cuestión de cómo trabajar con las instancias de una ontología dentro de las HLPNs. A lo largo de esta tesis, cada uno de los elementos de una ontología ha sido definido a través de un predicado: las instancias de una clase mediante un predicado unario mientras las instancias de una relación a través de un predicado binario. Esta misma solución es también aplicable a las HLPNs simplemente incluyendo los predicados como operadores con el rango de tipo lógico. Por ejemplo, para comprobar que un elemento es del tipo Context basta con definir el siguiente operador: Operator(Context). hasName(Context, "Context"). hasDomain(Context, [symbol_sort]). hasRange(Context, boolean_sort). Puede apreciarse como el operador Context toma un símbolo como entrada y devuelve un valor de tipo lógico. En este caso, el parámetro del operador representará el símbolo que identifica la instancia. El mismo procedimiento es aplicable a la definición de un operador que represente una relación. Por ejemplo, para comprobar si el contexto de ejecución tiene el parámetro username bastaría con definir el siguiente operador: Operator(username). hasName(username, "username"). hasDomain(username, [Context, symbol_sort]). hasRange(username, boolean_sort). Las HLPNs harán uso de estos operadores a través de los términos que anotan las transiciones y los arcos. Por ejemplo, la expresión representada en la Figura 5.31 podría perfectamente anotar la precondición de una transición. En este caso, el término es la conjunción de varios operadores donde dos de ellos son los previamente definidos. A través de esta condición, la transición puede restringir el disparo de la transición a aquellos usuarios cuyo nombre de usuario tenga el formato de una dirección de correo electrónico. A través de estos mecanismos, se puede operar con las instancias de una ontología. Remarcar la importancia de estos operadores, ya que el contexto de ejecución contendrá una propiedad por cada parámetro definido en el proceso. Por lo tanto, existirá un operador para acceder a cada parámetro que pueda contener el contexto de ejecución.
5.7. Conclusiones 241 Context(x) and username(x,u) and parseEmail(u) Operadores de la firma sintáctica Variable de la HLPN que tomará como valor al contexto de ejecución Variable de la HLPN que identificará a un usuario Operator Application1 and Operator Application2 Operator Application3 hasOperator hasArguments hasOperator hasArguments Context x (Operator) (Operator) (Variable) Figura 5.31: Ejemplo de un término que representa la llamada un operador 5.7. Conclusiones En este capítulo hemos descrito en detalle la parte del metamodelo que permite coordinar la ejecución de las tareas que componen un WF: el modelo de control, que es una de las principales aportaciones de esta tesis doctoral en relación a cómo otros metamodelos enfocan descripción operacional de los métodos. En este sentido, y al contrario de otras aproximaciones, el control se modela de forma que: La estructura de los WFs, y por consiguiente la descripción operacional de los métodos compuestos, se representa a través de redes de Petri jerárquicas, un formalismo aceptado por la comunidad de WFs y muy utilizado para la representación de procesos de negocio en cualquier ámbito de aplicación. El uso de un formalismo de representación de procesos tiene la ventaja de permitir el diseño de modelos que no sean ambiguos, además de dotar de semántica operacional a la mayoría de los comportamientos típicos de cualquier proceso de negocio (por ejemplo, la concurrencia). Las redes de Petri del modelo de control están explicitadas a través de la ontología propuesta en el Capítulo 3. Como ya hemos comentado, esta ontología permite describir tanto las características estructurales como las características dinámicas de las redes de Petri, de tal forma que cuando se crea una red el diseñador puede conocer con exactitud el comportamiento de su modelo. Además, la explicitación mediante una ontología posibilita el razonamiento acerca de las características de los elementos que constituyen la firma y el álgebra de la red, que en nuestro metamodelo serán ontologías de un determinado dominio de aplicación. El modelo de control también aporta los conceptos que permiten describir los patrones de WFs. Por ejemplo, existe un concepto SequencePattern que representa al patrón de WFs secuencia, y que permite especificar la ejecución ordenada de un conjunto de tareas. La semántica operacional de cada uno de estos patrones está basada en un determinado modelo de red de Petri. Para conjugar la semántica de la ontología con la del modelo de redes de Petri, cada concepto extiende al concepto HLPN, es decir, cada concepto es una red de Petri,
248 6. Infraestructura para la ejecución de flujos de trabajo Método 4 Método 2 Método 1 Tarea A Tarea C Tarea D Tarea B Transition 1 ↔Tarea B Transition 2 ↔Tarea C Transition 3 ↔Tarea D Transition 2 ↔Tarea F Transition 3 ↔Tarea G Transition 1 Transition 2 Transition 3 Transition 3 Transition 1 (se cumple condición) Transition 2 (no se cumple condición) Tarea F Tarea G Método 6 Método 7 Método 3 Transition 3 ↔Tarea E Método 5 Transition 1 Si condición 1 entonces x Si condición 2 entonces x Transition 2 Transition 3 Tarea E Figura 6.3: Integración del control dentro del diagrama de descomposición de tareas jerárquica no se vería afectada, ya que estos métodos no tienen descripción operacional al estar su ejecución a cargo de un recurso. En cambio, si mes compuesto será necesario integrar su descripción operacional dentro de la red jerárquica de ejecución. 3. El paso 3.a identifica el modelo de control que coordina la ejecución de las (sub)tareas del método compuesto. Al existir una única descripción operacional asociada al método, este paso consiste en localizar el puente que relaciona el método con un modelo de control. Finalmente, el paso 3.b invoca el procedimiento Añadir encargado de completar la red jerárquica h, para lo cual se agrega (i) cada uno de los componentes del modelo de control c, y (ii) cada uno de los modelos de control cique resuelven algunas de las (sub)tareas del método m. En un primer paso este procedimiento añade las páginas y operaciones de composición (sustituciones y fusiones) de c. Después, incorpora, en caso de ser necesario, a cada uno de los modelos de control asociados a cada una de las (sub)tareas del método. Esta acción se corresponde con el paso 3 del procedimiento Añadir, y
6.2. Composición del modelo de ejecución 249 hasControl Transition 1 HLPN2 (Patrón REPETIR-MIENTRAS) Sustituye a Transición hasControlTransition2 de HLPN1 hasControl Transition 2 hasControl Transition 3 hasControl Transition 1 HLPN1 (Patrón SECUENCIA3) Sustituye a Transición hasRunProcessTransition de HLPN0 Context ContextContext Context Context Context Context x hasIfTransition [ whileCondition ] hasElseTransition [ not whileCondition ] x x x HLPN0 (Patrón PROCESO) CONTROL DEL MÉTODO 1 POSTCONDICIÓN DEL MÉTODO PRECONDICIÓN DEL MÉTODO SUBTAREAS DEL MÉTODO x ifPrecondition [ precondition ] hasInput Place Context x hasRunProcess Transition hasFinished Place hasOutput Place elsePrecondition [ not precondition ] x hasEnabled Place Context Context Context message (PID , ... x x ifPostcondition [ precondition ] elsePostcondition [ not precondition ] message(PID, ... hasSplitTransition Context Context Context x Si condición 1 entonces x hasInput Place Si condición 2 entonces x hasControl Transition1 Context hasOutput Place x x hasControl Transition2 x x HLPN3 (Patrón ELECCIÓN MÚLTIPLE – MEZCLA MÚLTIPLE) Sustituye a Transición hasControlTransition1 de HLPN2 Figura 6.4: HLPNs del modelo de control del método 1 se fundamenta en un bucle que procesa cada una de las correspondencias entre una transición de cy una (sub)tarea del método m, y que se encarga de buscar los métodos mique resuelven las (sub)tareas y de agregar su control a la red jerárquica h. Si el método mies compuesto, su modelo de control cise añade a ha través de una nueva invocación del procedimiento Añadir. Finalmente, los pasos 3.b.3 y 3.b.4 permiten conectar los distintos modelos de control entre sí a través de una sustitución entre la transición que representa la tarea en cy el patrón proceso pidel modelo de control cique la resuelve. Puente método-control. Además de asociar un método a un modelo de control es necesario (i) relacionar la descomposición en tareas del método con determinadas transiciones de la red de control, y (ii) asociar las precondiciones y postcondiciones del método en la estructura de la red. Por ejemplo, para el caso de las precondiciones se trata de crear una función que permita interpretar al operador preconditions que anota la condición de guardia de la transición ifPreconditionTransition del patrón de proceso. Como se puede apreciar en la Figura 6.6, la correspondencia permite establecer que la expresión de esa función se obtiene de las precondiciones del método. Partiendo de la representación gráfica es difícil intuir que las precondiciones del método puedan definir el cuerpo/expresión de una función. Sin embargo, esto es viable porque, como se puede apreciar en la figura, las precondiciones se representan
250 6. Infraestructura para la ejecución de flujos de trabajo Principal 1. Crear HLPN jerárquica h. 2. Identificar el método mque resuelve la tarea principal t. 3. Si el método mes compuesto: a) Identificar el modelo de control cque resuelve m. b)A˜nadir (c, m, h). A˜nadir (c, m, h) Si mes compuesto y no ha sido añadido previamente a h: 1. Añadir las páginas, sustituciones y fusiones de ca la red h. 2. Identificar las correspondencias que relacionen una transición de ccon una (sub)tarea de m: 3. Para cada correspondencia cor(transition, task): a) Identificar el método mique resuelve la tarea task. b) Si el método mies compuesto: 1) Identificar el modelo de control cique resuelve el método mi. 2) A˜nadir (ci, mi, h). 3) Identificar la página pique representa el patrón proceso de ci. 4) Crear nueva sustitución entre la página piy la transición transition. Figura 6.5: Creación de la estructura jerárquica del modelo de ejecución a través de una fórmula/regla aplicable. En lo referente a las postcondiciones se aplicaría el mismo tipo de razonamiento, pero en este caso se interpretaría el operador postcondition. 6.2.1.2. Integración de los recursos En una empresa suele ser usual asociar un modelo de recursos para cada WF de la organización. Aunque cada uno de estos modelos puedan llegar a compartir el mismo modelo de organización (definido a través de una instancia de la ontología TOVE), las reglas de asignación no tienen por qué coincidir. Además, no todos los WFs son creados para las mismas personas y una misma persona puede jugar papeles diferentes y tener responsabilidades distintas en varios WFs. Por ejemplo, un WF para la compra de material suele incorporar únicamente al personal del departamento de compras. En cambio, un WF para el presupuestado de un producto suele involucrar a personal de todas las áreas de la empresa, al tratarse de una tarea transversal que toca a la mayor parte de sus divisiones. La intersección entre la dimensión de recursos y la de procesos asocia los agentes a los procesos, de modo que los métodos primitivos son el punto de unión entre ambas dimensiones. El puente método-recursos, que conecta ambos componentes entre sí, permitirá seleccionar aquellos recursos con derecho a ejecutar el método. Esta
6.2. Composición del modelo de ejecución 251 Context hasIfPrecondition Transition [ preconditions (x) ] hasInput Place hasElse Precondition Transition [ not preconditions (x) ] x x x PRECONDICIÓN DEL MÉTODO Context PUENTE MÉTODO-CONTROL preconditions(x) :- ProblemDecomposer(x), inputRoles(x,a), asignables(a), not miembroDe(x,_). Expresión real preconditions(x) :- ProblemDecomposer(x), inputRoles(x,a), asignatarios(a), notmiembroDe(x,_). ∀i ∃x preconditions(asignacion, x) and containsOperator(preconditions, seq) and function(y) and interpretsOperator(y, preconditions) --> expression(y, x) Correspondencia HLPN0 (Patrón PROCESO) ProblemDecomposer asignacion pragmatics Asignación de recursos a través de la satisfacción de restricciones ontologies selección input roles asignables, asignatarios output roles asignaciones subtasks TareaB, TareaE preconditions ∀i inputRole(asignacion,i) and asignables(i) --> ∃t miembroDe(i, t) ∀i inputRole(asignacion,i) and asignatarios(i) --> ∃t miembroDe(i, t) postconditions ... Figura 6.6: Precondiciones de un método primitivo en el álgebra del modelo de ejecución selección podrá ser directa o estar basada en alguna de las agrupaciones previamente definidas en el modelo de la organización, como por ejemplo los equipos, roles, permisos, divisiones, etc. Estos criterios de asignación han de incorporarse dentro de las condiciones de guardia de la transición asociada a la tarea que debe resolver el método. La Figura 6.7 muestra un ejemplo de intersección entre las dimensiones de procesos y de recursos que asocia el método primitivo método2 con la división1 y el rol3. Esta correspondencia permite inferir que cualquier agente xque cumpla la condición performs(x, actividad2) podrá ejecutar el método, como por ejemplo el agenteA. En definitiva, ya que los métodos primitivos carecen de implementación (estarían fuera del nivel de conocimiento), se considera que los recursos están al cargo de los detalles de su ejecución. De esta forma, se desliga la implementación de los métodos del metamodelo y se delega su ejecución a los recursos. Esta separación también permite analizar el rendimiento de los recursos: por ejemplo, si dos recursos están habilitados para ejecutar el mismo método primitivo, el WMS podría implementar una función que analizase el quehacer de cada recurso e incorporar dicho conocimiento como un criterio más de selección. Puente método-recursos. La asociación entre métodos y recursos también afecta al álgebra del modelo de ejecución. Como se señaló a lo largo de este capítulo, los métodos primitivos no tienen asociada ninguna descripción operacional y, por lo tanto, se representan mediante una transición en el modelo de ejecución. La ejecución de esta transición estará a cargo de un determinado recurso que será asignado a partir de un criterio de selección establecido en el puente entre métodos y recursos. Este puente permite incorporar estos criterios de selección al álgebra del modelo de ejecución y a la
252 6. Infraestructura para la ejecución de flujos de trabajo hasControl Transition 1 hasControl Transition 2 hasControl Transition 3 HLPN2 (Patrón SECUENCIA3) Sustituye a Transición hasRunProcessTransition de HLPN0 Context Context Context Context PRECONDICIÓN RECURSO Método 2 (Primitivo) Modelo de Recursos - entradas - salidas - precondiciones - postcondiciones - asunciones agenteA plays memberOf plays división 1 rol1 rol2 plays rol3 actividad 2 performs Puente método -recursos correspondencia (criterios de asignación) Figura 6.7: Las transiciones que se resuelven mediante un método primitivo añadirán la precondición del recurso propia red. Por una parte, el álgebra incluirá una función cuya expresión contendrá las reglas previamente introducidas en la propiedad knowledge del modelo de recursos. La labor de esta función será interpretar la condición de guardia de la transición que representa al método primitivo dentro del modelo ejecución. Por ejemplo, la Figura 6.8 muestra gráficamente las distintas correspondencias que nos permiten establecer la precondición de la transición que ejecutará el método primitivo. Asignación de recursos. El metamodelo propuesto especifica los criterios de asignación de trabajo en el modelo de recursos. Por lo tanto, cuando un diseñador construye un WF, está aplicando estos criterios a los métodos primitivos a ejecutar. Ya que estos criterios se integran dentro del modelo, la propia dinámica de la HLPN indicará durante la ejecución qué recursos pueden realizar las actividades. Como se ha visto en la Figura 6.8, los criterios de asignación se integran como condiciones de guardia de las transiciones que representan a métodos primitivos. Así, la activación y ejecución de estas transiciones estará restringida a aquellos recursos que cumplan con los criterios de asignación. Por ejemplo, supóngase el siguiente modelo de recursos expresado en TOVE:
6.2. Composición del modelo de ejecución 253 hasControl Transition 1 [ ] Context Context Método 2 (Primitivo) - entradas - salidas - precondiciones - postcondiciones - asunciones agenteA plays performs plays actividad 1 rol1 rol2 plays rol3 división 1 memberOf Puente método-recursos correspondencia (criterios de asignación) Puente método-control correspondencia precondición ∀x Method(metodo2) and ejecuta(x,metodo2) --> performs(x,metodo2) and plays(x,rol1) Figura 6.8: Correspondencias entre los componentes de conocimiento y el álgebra de la red Role(director) Role(profesor) Role(investigador) Agente(alberto) Agente(juan) Agente(manuel) Agente(pedro) Actividad(ac1) Actividad(ac2) Actividad(ac3) performs(alberto, ac1) performs(alberto, ac2) performs(alberto, ac3) performs(manuel, ac2) performs(manuel, ac3) performs(juan, ac2) performs(pedro, ac2) plays(alberto, director) plays(alberto, profesor) plays(alberto, investigador) plays(manuel, director) plays(manuel, profesor) plays(manuel, investigador) plays(juan, director) plays(pedro, director) . . . Partiendo de la red representada en la Figura 6.8, supóngase también que la plaza de entrada de la transición t1contiene una marca contexto1con el contexto de ejecución. En esta situación, el motor evaluaría la condición de guardia Context(x)∧ Agent(a)∧Role(director)∧hasAgent(x, a)∧plays(a, investigador) de la transición para cada uno de los valores que puedan tomar las variables xya. Aquellos valores para los cuales se verifique la expresión constituyen un modo de transición, y además se dirá que la transición está activa. Para la base de conocimiento anterior los modos de transición serían (contexto1, alberto), (contexto1, manuel), (contexto1, juan), (contexto1, pedro), indicando que los usuarios alberto,manuel,juan ypedro están habilitados para ejecutar el método. Por lo tanto, esta entrada se añadirá a la lista de trabajos pendientes para cada uno de los agentes y se actualizará continuamente a partir de los modos de transición de los métodos primitivos que estén activos. Es necesario puntualizar que cuando uno de estos métodos se ejecuta (i) uno de estos modos de transición es seleccionado, (ii) se elimina la marca de la plaza de entrada
254 6. Infraestructura para la ejecución de flujos de trabajo del método y (iii) se genera una nueva marca con el nuevo contexto de ejecución en la plaza de salida. Al no tener marcas en su entrada, la transición asociada al método dejará de estar activa y, por consiguiente, desaparecerá de las listas de trabajos pendientes de los recursos. 6.2.1.3. Integración del conocimiento del dominio Existen distintos criterios a la hora de seleccionar o crear el modelo del dominio de un WF. Algunas empresas prefieren usar un único modelo del dominio para así poder compartirlo y reutilizarlo en todos los WFs. El problema de esta estrategia es que da lugar a dominios muy genéricos, que además suelen contener mucho más conocimiento del que es necesario para ejecutar el WF que se está diseñando. La otra estrategia consiste en crear un dominio que contengan únicamente el conocimiento imprescindible para ejecutar el WF de interés. El problema de esta solución es que trocea el conocimiento de un dominio. No obstante, ambas soluciones son correctas: la primera mantiene el dominio más coherente, aunque tiene un menor rendimiento, ya que tiene que inferir conocimiento innecesario. En cambio, la segunda es menos exigente desde un punto de vista computacional, dado que infiere únicamente el conocimiento imprescindible para solucionar el WF. Una vez seleccionado el modelo del dominio, el siguiente paso consiste en unirlo con las dimensiones de proceso y de recursos. Así, por una parte, la intersección entre las dimensiones de conocimiento y de procesos se realiza a través de dos puentes: tarea-dominio ymétodo-dominio. El primer puente contiene la mayor parte de las correspondencias entre la terminología del dominio y la de los procesos. Como ya se comentó en el Capítulo 4, cuando un dominio establece relaciones con una tarea, también se está relacionando transitivamente con los métodos a través del puente método-tarea. Por ello, el puente método-dominio sólo se encarga de asegurar que el dominio cumple con las asunciones establecidas en el método. Puente dominio-control. El puente entre el modelo del dominio y el modelo de control permite establecer las correspondencias entre la terminología usada para anotar los términos de las HLPNs y el conocimiento de la aplicación. De los capítulos 3 y 5, se sabe que la terminología utilizada para anotar las HLPNs está formada por un conjunto de operadores y tipos de datos agrupados en una misma firma sintáctica y que dicha terminología se adquiere de las ontologías utilizadas por el modelo de control. Por ejemplo, si la ontología utilizada para anotar la red de control trata la fabricación de muebles, entonces la firma sintáctica incorporará al menos tipos de datos como: Mueble,M´aquina,Recurso, etc. Asimismo, incorporará operadores que relacionan dichos tipos, como por ejemplo tienePiezas :Mueble →P ieza, utilizaRecursos :M´aquina →Recurso, etc. Por lo tanto, los tipos de la firma sintáctica serán identificadores de clase de las ontologías mientras que los operadores serán predicados que permiten inferir las clases y relaciones de dichas ontologías. Además, la firma también podría incorporar nuevos tipos y operadores no incluidos en las ontologías, como por ejemplo aquellos relacio-
6.3. Gestor de mensajes 255 Firma sintáctica Álgebra FOL Nivel de representación Nivel semántico Nivel de ejecución Figura 6.9: Los tres niveles de la anotación algebraica nados con el contexto de ejecución (o canal de ejecución) y utilizados para anotar las plazas de las HLPNs del modelo de control. Al existir tan estrecha relación entre los operadores que anotan las HLPNs y las ontologías, las correspondencias entre ambos modelos es prácticamente directa. Por ejemplo, un predicado del dominio de la aplicación denominado mayorQue podría asumir la interpretación del operador mayor previamente definido en la firma. El modelo de control contendrá el comportamiento asociado al predicado mayorQue, cuya semántica estará declarada dentro de las fórmulas asociadas a la propiedad knowledge. En el caso del predicado mayorQue, el cálculo estará a cargo de las siguientes reglas: mayorQue(?_x, ?_y, true) :- ?_x > ?_y. mayorQue(?_x, ?_y, false) :- ?_x <= ?_y. La solución descrita anteriormente muestra la potencia de tener un álgebra asociada a una firma sintáctica. Por un lado el álgebra permite reutilizar redes con dominios de aplicación diferentes. Por otro lado, permite reutilizar redes con motores de inferencia diferentes que tengan lenguajes de representación diferentes simplemente adaptando las reglas del dominio al lenguaje correcto. Finalmente mencionar una última ventaja: con esta aproximación no es necesario crear un intérprete de los términos que anotan las redes de Petri, ya que la evaluación recaerá en el motor de inferencia que se encarga de ejecutar las redes. De esta forma, el propio razonamiento está desligado de las HLPNs haciendo estas redes más reutilizables. La Figura 6.9 representa esta separación donde el álgebra actúa como intermediario entre la sintaxis de anotación de las redes y su semántica de interpretación. 6.3. Gestor de mensajes La tercera capa de la infraestructura facilita las comunicaciones y la interacción entre los recursos que participan en la ejecución del WF. Dependiendo del tipo de recurso, humano o software, la interacción con el manejador de la ejecución puede variar. Lo mismo sucede con quién ha de tomar la iniciativa de la comunicación. Por ejemplo, si el recurso es un servicio web, el manejador debería tomar la iniciativa e invocar la ejecución de ese servicio. En cambio, si el recurso es humano, el usuario estará a
256 6. Infraestructura para la ejecución de flujos de trabajo cargo de la comunicación, es decir, accederá al WMS, recuperará su lista de tareas pendientes y decidirá cuál de ellas ejecuta. En este último caso, la comunicación de los resultados también será responsabilidad del usuario. Con el fin de independizar la infraestructura del tipo de comunicación que pueda establecerse entre el sistema y un determinado recurso, la tercera capa se basa en el paradigma de paso de mensajes, que es la solución ideal para dar soporte a comunicaciones distribuidas y poco acopladas. Es el tipo de comunicación que mejor se adapta a la dinámica de ejecución de los WFs, ya que al contrario que las llamadas a procedimientos remotos (RPC, del inglés Remote Procedure Call), no necesitan que la comunicación entre el cliente y el servidor esté sincronizada. En este sentido, en los RPCs cuando una parte se comunica con la otra, se ha de esperar hasta que el método invocado finalice su ejecución; es decir, se requiere que tanto el cliente como el servidor estén disponibles al mismo tiempo. La comunicación es, por lo tanto, poco adecuada cuando se quiere desacoplar las aplicaciones. En cambio, el pase de mensajes relaja este tipo de comunicación introduciendo un módulo intermedio, llamado cola, que permite que los distintos componentes software se relacionen entre sí de forma asíncrona. El principal beneficio de este tipo de comunicación es que evita que el remitente necesite tener un conocimiento preciso de los receptores, ya que la interacción se realiza a través de la cola. El paso de mensajes utilizado por esta infraestructura se basa en un modelo de publicación/suscripción cuyos tópicos identifican los recursos. Así, los suscriptores se registrarán en el sistema con el fin de recibir los mensajes destinados a un determinado recurso que son enviados por la instancia del WF. Como consecuencia, en este modelo ni el publicador ni el suscriptor se conocen de forma que no existe acoplamiento alguno entre ambas entidades. Además, el modelo también se caracteriza por: Permitir múltiples suscriptores de un mismo recurso. Con esta configuración es posible que varios suscriptores compitan por las tareas de un mismo recurso o que se repartan el trabajo. En cualquier caso, estas estrategias de trabajo colaborativo no están contempladas en la infraestructura. Los mensajes publicados mientras el suscriptor no está conectado son redistribuidos una vez que se conecta. Así, no se pierde ningún mensaje y la lista de trabajos pendientes está siempre actualizada. La Figura 6.10 muestra de forma gráfica la arquitectura del modelo de mensajería, donde se puede ver cómo las instancias de los WFs envían los mensajes referentes a un determinado tópico y los suscriptores reciben dichos mensajes. La principal característica del modelo es que los tópicos se refieren a los identificadores de los recursos y los suscriptores son, por lo tanto, las implementaciones de los propios recursos, que se encargarán de ejecutar los métodos primitivos del WF.
6.4. Participantes del flujo de trabajo 257 Publicador Instancia de WF Publicador Instancia de WF Publicador Instancia de WF Suscriptor Implementación Recurso Suscriptor Implementación Recurso Suscriptor Implementación Recurso Tópico Identificador Recurso Servidor de mensajes Mensaje Mensaje Mensaje Mensaje Mensaje Mensaje Figura 6.10: Modelo de publicación/suscripción del repartidor (broker) de mensajes 6.4. Participantes del flujo de trabajo La cuarta capa integra en la infraestructura de ejecución de WFs a (i) sistemas de legado existentes en la organización, (ii) servicios externos, y (iii) otros agentes software. Esta integración se lleva a cabo mediante adaptadores que actúan como suscriptores del gestor de paso de mensajes. A través de esta solución cada adaptador registrado en esta capa representará a uno de los recursos que participa en la ejecución del WF. De esta forma, los recursos se tratan uniforme e independientemente de su implementación. Cada adaptador debe implementar las funcionalidades básicas que le permitan interpretar los mensajes del gestor. Por ejemplo, cuando el manejador de la ejecución le comunica al recurso que tiene una nueva actividad asignada, el adaptador deberá recuperar la definición del método del WMS; es decir, sus entradas, salidas, y pre/postcondiciones de la misma. De la misma forma, el adaptador debe notificar los resultados al manejador de acuerdo con la firma del método; es decir, deberá asociar un valor a cada uno sus parámetros (entradas y salidas). Aunque desde la perspectiva del WMS los adaptadores son indistinguibles, hacia fuera del sistema cada adaptador deberá manejar el protocolo de comunicaciones, el formato de los mensajes, el lenguaje de descripción, etc. del recurso en cuestión. Por ejemplo, cuando un adaptador integra a un servicio web, debe saber cómo invocarlo. Para ello, primero ha de tener el fichero WSDL (del inglés, Web Service Description Language) que describe dicho servicio o en su defecto saber cómo recuperar la referencia a ese fichero de un registro de servicios UDDI (del inglés, Universal Description, Discovery and Integration). Segundo, ha de saber cómo definir las correspondencias entre la firma del método primitivo y la del servicio web externo. Para entradas y salidas especificadas a través de algún tipo básico, es decir, para los enteros, números reales, valores lógicos, etc., el paso es prácticamente directo. Sin embargo, para tipos complejos requerirá una lógica más compleja. Finalmente, debe saber cómo invocar el servicio web a través de SOAP (del inglés Simple Object Access Protocol) al proveedor de servicios. La Figura 6.11 muestra este escenario, en el que se puede ver
264 6. Infraestructura para la ejecución de flujos de trabajo Por otra parte, el módulo gestor de ontologías se encarga de facilitar la inserción de ontologías del dominio en formato OWL dentro del álgebra de la HLPN. Es una vía alternativa a la inserción de álgebras, ya que éstas pueden insertarse directamente a través de la ontología de HLPN. En este caso, las clases de las ontologías del dominio se cargan como metacarriers del álgebra. Tanto la creación de la taxonomía de la ontología del dominio como la inserción de sus instancias se realiza a través de la interfaz del razonador. Esta fachada también maneja la ejecución de HLPN a través del gestor de ejecución. Este módulo permite dos tipos de ejecución: guiada o automática. La primera se utiliza para simulaciones o depuración y exige la intervención humana para seleccionar qué transición se va a ejecutar. La segunda, proporciona un planificador que permite ejecutar la red de Petri de forma automática. En ambos casos, la activación de una transición implica que existen las evaluaciones de sus arcos de entrada y salida y que se cumplen sus precondiciones. Es importante mencionar que las funciones que anotan los arcos de la red pueden ser de dos tipos: (i) internas (F-Logic) o (ii) externas. Las funciones internas se cargan con la ontología dentro del parámetro expression de la función. Ya que las funciones anotan los arcos y transiciones de las redes, el motor de redes de Petri es capaz de ejecutarlas de forma automática y así obtener su evaluación. Sin embargo, para dotar a OPENET de más flexibilidad, el motor también permite la creación de funciones sin expressión y cuya ejecución se delega a una entidad externa. En este sentido, el ejecutor soporta dos tipos de funciones externas: •Métodos Java. El planificador realiza la invocación de un método Java e inserta su resultado como una evaluación dentro de la ontología. La invocación de servicios Web también se realiza a través de este procedimiento. •Tareas de usuario. El planificador delega la ejecución de la función al usuario. Éste último es el encargado de introducir la evaluación en el sistema. La persistencia de las redes de Petri es otro de los puntos importantes de este motor. Esta interfaz almacena los grafos y la ejecución de estas redes en una base de datos relacional. El gestor de persistencia facilita los métodos y se encarga de acometer dicha tarea de forma automática o bajo demanda. Cuando un cliente carga una red de Petri, esta fachada crea una instancia en el razonador. Este módulo se encarga de relacionar la instancia del cliente en el razonador con la instancia de persistencia que almacena los datos. Interfaz RMI. El cliente puede acceder a OPENET vía su interfaz RMI, a través del cual llama los métodos que exporta esta interfaz. Es necesario resaltar que los métodos exportados pertenecen a la Fachada OPENET y que los clientes referencian los objetos remotos a través del stub local, el cual actúa como proxy de dichos objetos y es el responsable de redirigir las invocaciones remotas al servidor.
6.5. OPENET4WF: Motor de flujos de trabajo 265 Razonador FLORA-2 Sistema de inferencia Base de conocimiento Esquema Ontología HLPN Datos Instancias HLPN Reglas Razonamiento HLPN Motor OPENET4WF Interfaz del razonador Interfaz de OPENET Interfaz del motor de HHLPN Motor OPENET Interfaz deOPENET 4WF Esquema Ontología HHLPN Datos Instancias HHLPN Reglas Razonamiento HHLPN CORRESPONDENCIAS CORRESPONDENCIAS Esquema Ontología OPENET4WF Datos Instancias OPENET4WF Reglas Razonamiento OPENET4WF CORRESPONDENCIAS CORRESPONDENCIAS Figura 6.16: Arquitectura del motor de flujos de trabajo. Este motor está construido sobre el motor de redes Petri y le añade una capa para el manejo de redes de Petri jerárquicas, otra capa para el manejo de patrones y una última capa para el manejo de los componentes del metamodelo. 6.5.2. Capa de redes jerárquicas La Figura 6.16 representa la arquitectura que da soporte a la ejecución de WFs. Como se muestra en la Figura 6.13 este motor extiende a OPENET con dos nuevas pilas encargadas de definir la semántica de (i) las redes de Petri jerárquicas y (ii) la ontología patrones y los demás componentes del metamodelo de WFs. Las redes de Petri jerárquicas definen la capa intermedia que permite componer redes de Petri complejas a partir de HLPNs más sencillas. Son una estructura formada por HLPNs planas y mecanismos de composición, además del morfismo que asocia la red jerárquica con su representación plana. Esto último es de gran utilidad, ya que no existe una semántica operacional para las redes jerárquicas y, por lo tanto, la toman de las HLPN. De forma más detallada, los principales elementos de la pila de redes jerárquicas son los siguientes: Esquema. Almacena el conjunto de clases, relaciones, propiedades y axiomas que describen las HLPNs jerárquicas. Al contrario de la ontología de HLPN, no está basada en ningún estándar matemático sino que simplemente recoge los principales mecanismos de composición de redes de Petri existentes en la bibliografía [120]. Básicamente introduce el concepto de fusión y sustitución en
266 6. Infraestructura para la ejecución de flujos de trabajo %transformHHlpn2Hlpn(?_hhn, ?_fla) :- ?_hhn:HHLPN, ?_hhn[Pages ->-> ?_pal], %createHlpn(?_fla), %setProperty(?_fla, HLPN, name, ?_hhn), %setProperty(?_fla, HLPN, description, ?_hhn), %createMorphism(?_mor), %setPropertyList(?_mor, morphism, sourceNets, ?_pal, HLPN), %setProperty(?_mor, morphism, targetNet, ?_fla), %setProperty(?_hhn, HHLPN, morphism, ?_mor), %associateSignature(?_hhn, ?_fla), %associateVariables(?_hhn, ?_fla), %associateStructure(?_hhn, ?_fla). Figura 6.17: Regla para la transformación de una red jerárquica ?_hhn en una red plana ?_fla. En este caso, el predicado%transformHHlpn2Hlpn crea la red plana y el morfismo que relaciona ambas redes. las HLPN [149] a partir de los cuales se posibilita la construcción de redes más complejas. Datos. Este módulo almacena las instancias de las HLPNs jerárquicas. Por ejemplo, almacena las páginas (redes de Petri planas/HLPN) que componen una red jerárquica y las instancias de fusiones y sustituciones que definen cómo las páginas de la red se relacionan. Reglas. El conjunto de reglas definidas para las redes jerárquicas permite (i) crear, modificar y borrar redes jerárquicas, (ii) crear las copias de las HLPNs de las que una red jerárquica se nutre (páginas) y (iii) crear el morfismo que la relaciona con una red plana (HLPN). Este último punto permite crear automáticamente una red aplanada imagen de la red jerárquica donde cada uno de los elementos de la red jerárquica se relaciona con el correspondiente elemento de la red aplanada. Por ejemplo un nodo de una de las páginas que compone la red jerárquica tiene un mapeado en el morfismo que permite identificar su nodo imagen en la red aplanada. La función de mapeado es sobreyectiva, ya que la red jerárquica permite la fusión de un conjunto de nodos. Otro punto interesante es la definición del álgebra que maneja la red aplanada. Ya que una red jerárquica se compone de iHLPNs y cada una de estas redes puede tener un álgebra Aidiferente, el álgebra de la red aplanada resultante será la unión de las Aiálgebras. Por ejemplo, el código representado en la Figura 6.17 permite crear la imagen aplanada de una red jerárquica.
6.5. OPENET4WF: Motor de flujos de trabajo 267 6.5.3. Capa OPENET4WF La parte más a la derecha de la arquitectura del motor representado en la Figura 6.16 da soporte a la gestión de los conceptos descritos en el metamodelo presentado en esta tesis doctoral [270, 274]. Se trata de la parte encargada de proporcionar los medios para manejar las tareas, métodos, y modelos de control, del dominio y de recursos que describen un WF. La estructura de la base de conocimiento es idéntica a la detallada para las HLPNs o las HLPNs jerárquicas: Esquema. Almacena el conjunto de clases, relaciones, propiedades y axiomas que describen el metamodelo del metamodelo descrito en el capítulo 4. Además, en este esquema también se describen los patrones de WFs utilizados para construir un modelo de control. Datos. Este módulo almacena las instancias de los WFs descritos a través de las tareas, los métodos, etc y unidos a través de puentes y refinadores. Por ejemplo, almacenará las tareas que describen una problemática a resolver, los métodos que resuelven dichos problemas, las estructuras organizativas que participan en la ejecución del WF, los modelos de control, etc. Reglas. El conjunto de reglas de esta capa permite (i) crear, modificar y borrar las instancias del metamodelo de WFs y (ii) crear la red jerárquica que captura el modelo de ejecución del WF. Este último punto es el más complejo, ya que requiere componer los distintos modelos de control que describen los métodos que resuelven las tareas que forman parte del WF. Una vez seleccionados todos los métodos, la regla representada en la Figura 6.18 se utiliza componer en una única red jerárquica al conjunto de modelos de control que describen operacionalmente estos métodos. El predicado createExecutionModel tomará una la lista de modelos de control en la variable ?_lst y una HHLPN en la variable ?_mod que contiene el modelo compuesto. Este módulo también contiene al conjunto de reglas que facilitan la creación de los patrones de WFs utilizados para crear un modelo de control. Por ejemplo, la Figura 6.19 muestra parte del código de la regla utilizada para crear un patrón tipo proceso. Finalmente, la Interfaz del motor OPENET4WF permite la carga y ejecución de WFs desde Java [267]. Respecto a la carga, posibilita la gestión de cada uno de los componentes de conocimiento del metamodelo descrito en esta tesis. Respecto a la ejecución, integra a las fachadas Java de HLPNs y HLPNs jerárquicas a través de las cuales obtiene el modelo ejecutable de un WF. De forma más detallada, permitirá identificar los componentes de conocimiento, seleccionar/crear los adaptadores para unirlos, y a partir de este modelo traducir en un primer paso el modelo a una red jerárquica y posteriormente a una red plana. La ejecución de la red plana estará directamente a cargo del motor de HLPNs previamente descrito.
268 6. Infraestructura para la ejecución de flujos de trabajo %createExecutionModel(?_lst, ?_mod) :- if (?_lst = []) then (?_mod = null) else ( %createHHlpn(?_mod), %addSubstitutions(?_lst, ?_mod), %addFusions(?_lst, ?_mod), %addPages(?_lst, ?_mod)). %addSubstitutions([], ?_mod). %addSubstitutions([?_hhn|?_lst], ?_mod) :- ?_mod[substitutions ->-> ?_su1], ?_hhn[substitutions ->-> ?_su2], append(?_su1, ?_su2, ?_sul)@_prolog(basics), addSubstitutions(?_lst, ?_mod). ... Figura 6.18: Regla para la unión de un conjunto de redes en una única red jerárquica 6.6. Conclusiones Existen muchos factores que determinan el éxito de un WMS y que deben se tenidos en cuenta a la hora de seleccionar una herramienta de WFs. Entre ellos, su metamodelo, sus funcionalidades o su infraestructura de ejecución. Este último factor tiene una gran importancia, ya que incide de manera directa tanto en el diseño de los WFs como en la integración de las aplicaciones que van a participar en su ejecución. Por ello, este capítulo se ha centrado en explicar las principales características de la infraestructura desarrollada para dar soporte al metamodelo. La infraestructura que presentamos está compuesta de cuatro capas, cada una de las cuales da soporte a una parte específica de la ejecución del WF [270, 274]. La primera capa se encarga de la definición de los WFs. Es, por lo tanto, la capa que da soporte al metamodelo descrito en el Capítulo 4 y que permite gestionar cada una de los componentes de un WF. Desde el punto de vista de la ejecución, el principal objetivo de esta capa es proporcionar WFs “completos”, es decir, WFs (pre)definidos a partir de cada una de sus componentes. Aporta por ello las bases para el diseño paramétrico de WFs, ya que un WF se puede ver como el proceso de resolución de un rompecabezas donde cada uno de los componentes muestra una parte de la figura a construir y donde los adaptadores representan el punto de enganche entre dos componentes. La segunda capa trata la ejecución del WF. A su cargo está desde la creación del modelo de ejecución hasta la interpretación de las HLPNs de cada una de las instancias del WF. Se puede considerar esta capa como el núcleo de la infraestructura, el lugar donde se toman las decisiones que afectan a la ejecución. Dado que el modelo de ejecución es una HLPN, un motor de HLPNs [276] está a cargo de dirigir su ejecución. Es justo comentar que al contrario de otros lenguajes ejecutables de WFs (como por
6.6. Conclusiones 269 %createProcessPage(?_pro, ?_rel, ?_pag) :- %createVariable("x", Context, ?_va0), name(?_pro,?_prn)@_prolog(standard), %createSort(?_prn, ?_prn, [value], [?_prn], string, ?_prs), %addProperty(wfSig, signature, sorts, ?_prs), %addProperty(wfSig, signature, operators, ?_prs), %createOperatorApplication(?_prs, [], string, ?_str), %createOperatorApplication(precondition, [?_str, ?_va0], boolean, ?_ot0), %createOperatorApplication(boolean_not, [?_ot0], boolean, ?_ot1), %createOperatorApplication(postcondition, [?_str, ?_va0], boolean, ?_ot2), %createOperatorApplication(boolean_not, [?_ot2], boolean, ?_ot3), append(’input_’, ?_prn, ?_inn)@_prolog(basics), append(’output_’, ?_prn, ?_oun)@_prolog(basics), append(’enabled_’, ?_prn, ?_enn)@_prolog(basics), append(’finished_’, ?_prn, ?_fin)@_prolog(basics), append(’run_process_’, ?_prn, ?_rpn)@_prolog(basics), append(’if_pre_’, ?_prn, ?_ipn)@_prolog(basics), append(’else_pre_’, ?_prn, ?_epn)@_prolog(basics), append(’if_pos_’, ?_prn, ?_ion)@_prolog(basics), append(’else_pos_’, ?_prn, ?_eon)@_prolog(basics), %createPlace(?_inn, Context, ?_inp), %createPlace(?_oun, Context, ?_oup), %createPlace(?_enn, Context, ?_enp), %createPlace(?_fin, Context, ?_fip), %createTransition(?_rpn, ot_true, ?_rpt), %createTransition(?_ipn, ?_ot0, ?_ipt), %createTransition(?_epn, ?_ot1, ?_ept), %createTransition(?_ion, ?_ot2, ?_iot), %createTransition(?_eon, ?_ot3, ?_eot), . . . Figura 6.19: Regla para la creación de un patrón proceso (I). Esta regla traslada la representación de la Figura 5.2 a una red descrita a través de la estructura de clases de la ontología de HLPNs. ejemplo BPEL o BPML), el modelo ejecutable de esta capa incluye todos los aspectos que intervienen en la ejecución, desde las actividades a realizar hasta los recursos que las van a resolver. Descontando las diferencias expresivas de cada lenguaje, los lenguajes de WFs no suelen integrar los recursos dentro del modelo de ejecución, de forma que es necesario buscar mecanismos para interceptar las actividades a realizar y asignar externamente los recursos. En cambio, el modelo de ejecución que describimos en este capítulo integra los recursos directamente a través de restricciones en las condiciones de guardia de las transiciones. Así, sólo se posibilitará la ejecución de una transición a aquellos recursos que cumplan su condición de guardia. Estas dos primeras capas de la infraestructura están soportadas por el motor OPENET4WF, que está a cargo de supervisar la definición de los distintos WFs como del control de su composición y ejecución. El motor OPENET4WF ha sido construido sobre un motor de HLPNs jerárquicas que se utiliza para dar soporte semántico
270 6. Infraestructura para la ejecución de flujos de trabajo y operacional a los modelos de control y al modelo de ejecución derivado del WF. Consecuentemente, es posible ejecutar un WF a través del formalismo de las HLPNs asegurando así la no ambigüedad de la ejecución. En este sentido, no es necesario dar un paso extra para traducir el modelo de HLPNs a un lenguaje de ejecución o a un lenguaje de programación, ya que el propio razonador de OPENET4WF se encargará de coordinar la ejecución de las transiciones. Otra ventaja de esta solución es que trabaja directamente al nivel de la ontología de HLPNs, de forma que en cada paso de la ejecución se evalúan los términos que anotan los arcos y las transiciones, se identifican los modos de transición activos y se selecciona el/los modos(s) de transición a disparar. Los resultados de estas evaluaciones se almacenan a su vez en la base de conocimiento de forma que es posible seguir los pasos y el razonamiento del motor en cada paso de la ejecución, y de a su vez verificar el funcionamiento del WF. Consecuentemente, la ejecución de un WF podría intercambiarse entre distintos motores, ya que toda la información dinámica está almacenada en la base de conocimiento y la ontología de HLPNs permite exportarla. Con estas características, el WMS puede implementar una arquitectura distribuida o tolerante a fallos, ya que en cualquier instante la información de ejecución se puede transmitir a otro motor bien sea para mejorar el rendimiento o por una caída del servidor. La tercera capa implementa un mecanismo de pase de mensajes entre el WMS y los sistemas externos encargados de ejecutar los métodos primitivos del WF. Esta solución permite independizar el WMS de las características de los sistemas externos, y lograr así un bajo acoplamiento entre los clientes y el servidor. El pase de mensajes está basado en el modelo de publicación/suscripción donde el WMS juega el papel de publicador y las aplicaciones externas se suscriben a las noticias dirigidas a un determinado recurso. De esta forma, el WMS simplemente lanza los mensajes dirigidos a un recurso y toda la funcionalidad relacionada con ese mensaje recae en la aplicación externa que implementa dicho recurso. Es fácil deducir que a través de esta estrategia se independiza la implementación del WMS de la de los recursos así como de la solución tecnológica utilizada por dichos recursos. Precisamente, la cuarta capa se encarga de integrar los sistemas externos en el WMS. Esta capa maneja un conjunto de adaptadores que hacen las funciones de recursos del WMS. Un adaptador representa, por lo tanto, uno o más recursos y está suscrito a los mensajes que se refieren a dichos recursos en el sistema de paso de mensajes. Cuando el WMS envía una comunicación a un recurso, por ejemplo la ejecución de una actividad, el adaptador del recurso recuperará el mensaje y ejecutará la correspondiente funcionalidad. Hacia fuera del WMS, los adaptadores facilitan la integración de las distintas tecnologías en las que están implementadas los sistemas externos, y permiten invocar servicios, servicios web, métodos remotos, etc. Los siguientes tres capítulos validarán nuestro metamodelo y OPENET4WF. En particular, en Capítulo 7 nos muestra cómo nuestra solución da soporte a la implementación de WFs con un uso intensivo de conocimiento. En el Capítulo 8 podremos apreciar la versatilidad del modelo en el dominio de la Educación y su manejo de WFs complejos que dan lugar a redes de importantes dimensiones. Finalmente, en el Capítulo 9 veremos la forma de extender la capa de patrones de WFs de nuestro
6.6. Conclusiones 271 metamodelo para dar soporte a la ejecución de servicios web semánticos expresados en OWL-S.
7 Proceso de presupuestado en la industria del mueble En este capítulo presentamos una aplicación del marco conceptual descrito a lo largo de esta tesis doctoral a un proceso del ámbito de las aplicaciones industriales. La aplicación resuelve la tarea de presupuestado dentro del dominio de la fabricación de muebles a medida [275] y ha sido desarrollada en conjunción con la empresa Martínez Otero S.L. El resultado, denominado SEEPIM (acrónimo de Sistema Experto de Elaboración de Presupuestos en la Industria del Mueble) [268], es un sistema que integra varios flujos de trabajo (WFs) que mejoran tanto la estructura del proceso de presupuestado como los resultados obtenidos. Aunque el nombre de SEEPIM pueda llevar a la confusión hemos preferido mantenerlo por razones históricas, ya que la aplicación inicial, desarrollada en el marco de dos proyectos de I+D industrial1se denominaba así. Debe tenerse en cuenta, en cualquier caso, que el sistema no está restringido al presupuestado sino que también abarca otros WFs que le permiten gestionar la planta de fabricación y el control de calidad. En este capítulo se describirá únicamente el WF de presupuestado, ya que es el más representativo de SEEPIM y además de los más interesantes, ya que resuelve muchas de las problemáticas típicas resueltas por los sistemas expertos (planificación, asignación, valoración, etc.). Es por ello un ejemplo representativo del tipo de procesos que pretende resolver nuestro marco conceptual: WFs complejos y que hacen uso intensivo de conocimiento. 7.1. Automatización del presupuestado de muebles Hoy en día, la industria del mueble se enfrenta al reto de la globalización y a inauditos niveles de competitividad. Los mercados cada vez más competitivos están obligando a las organizaciones a mejorar constantemente sus procesos de negocio. Un proceso clave para llevar a cabo esta mejora está relacionado con el problema de presupuestado de muebles, cuyo principal objetivo es determinar el coste de fabricación de un pedido realizado por un cliente. Conseguir una buena estimación del coste real de producción 1El desarrollo de SEEPIM ha tenido el soporte económico de los proyectos “Sistema experto para la elaboración y seguimiento de ofertas en la industria del mueble” (PGIDT01INN35E) y “Sistema de planificación dinámica de la carga de trabajo de la fabricación en la industria del mueble” (PGIDIT04DPI096E) 273
280 7. Proceso de presupuestado en la industria del mueble un espacio de tiempo significativo se ha obtenido un resultado estadístico para cada uno de los parámetros del polinomio. Por ejemplo, el polinomio correspondiente a la seccionadora de madera es: f(P) = 0,1·x(P) + 3 ·y(P) donde las variables tienen el siguiente significado: P: esta variable se refiere al pedido del cliente. x(P): esta función calcula el número de metros lineales cortados . Este valor se obtiene sumando la longitud y anchura del número de tableros de madera a seccionar. Para su cálculo se utiliza la siguiente función donde UD(pi) representa el número de unidades, L(pi) la longitud y A(pi) la anchura de la pieza piy todo ello normalizado para un tablero estándar de 2700x200x76: x(P) = n·2·2,700 · P pi∈Pmadera(pi) UD(pi)·L(pi)·A(pi)·E(pi) 2700 ·200 ·76 y(P): esta función calcula el número de tableros manipulados. Este valor se obtiene sumando los volúmenes de las piezas a seccionar (donde E(pi) representa el espesor de la pieza pi) y se divide por el volumen de un tablero estándar (2700x200x76): y(P) = n· P pi∈Pmadera(pi) UD(pi)·L(pi)·A(pi)·E(pi) 2700 ·200 ·76 Siguiendo una metodología similar, se han identificado los polinomios de las restantes máquinas de la empresa (denominadas centros de coste) y como consecuencia se han obtenido un conjunto de polinomios que dan una medida muy fiable de los tiempos invertidos por cada una de las máquinas y cada proceso de fabricación que realiza. Es importante señalar que este proceso de adquisición ha sido muy arduo y tedioso, ya que un operario ha tenido que tomar nota de los tiempos reales de las máquinas. Asimismo, esta aproximación ha permitido modularizar el proceso de estimación del tiempo de fabricación de un pedido como la suma de los tiempos de fabricación invertidos por los centros de coste por los que pasa. Ello da lugar a que se pueda separar el problema en (sub)problemas más simples y focalizar el esfuerzo de la adquisición de conocimiento en cada polinomio por separado. Ello ha facilitado la validación y refinamiento de los polinomios cuyas estimaciones tienen un mayor error.
7.4. Flujo de trabajo de presupuestado 281 7.4. Flujo de trabajo de presupuestado Como resultado del proceso de diseño, SEEPIM da soporte a un conjunto de WFs para la tarea de presupuestado de muebles [275]. Estos flujos están centrados en el diseño del producto, donde los planos CAD son constantemente evaluados a medida que avanza el proceso. Es necesario mencionar que la solución descrita en esta sección está influenciada por las características estructurales y organizativas de la empresa para la cual se desarrolló SEEPIM. Sin embargo, esta solución es extrapolable a muchos dominios industriales, ya que la mayoría de las empresas se enfrentan a problemas similares cuando abordan esta tarea. Los WFs que modelan la tarea de presupuestado han sido explícitamente definidos dentro de SEEPIM y son una pieza más de conocimiento con la que razonar. Los restantes componentes de conocimiento se han introducido a través de ontologías asociadas al dominio: reglas de fabricación y ensamblaje, guías prácticas, características de los muebles, etc. Finalmente, merece la pena mencionar que la mayoría de los métodos utilizados para modelar esta tarea se han fundamentado en la librería de componentes reutilizables definida por la metodología CommonKADS [43]. Esta metodología ofrece un conjunto de modelos asociados a los distintos tipos de problemas existentes en la ingeniería de conocimiento: clasificación, valoración, diagnosis, predicción, configuración, modelado, planificación y asignación. De esta forma, la construcción del modelo de conocimiento se convierte en un proceso de ingeniería consistente en seleccionar o ajustar componentes predefinidos al problema en cuestión. El primer paso a la hora de abordar el problema de elaboración de presupuestos consiste, por lo tanto, en determinar los tipos de problemas a los que se enfrenta. Del análisis del dominio de la aplicación se identificaron tres tipos diferentes de problemas asociados a la elaboración de presupuestos: Problema de valoración. La evaluación de la viabilidad de llevar a cabo un pedido o de los diseños del producto son ejemplos de este tipo de problema. Problema de asignación. Este tipo de problema se manifiesta a la hora de asociar precios a los materiales o recursos a las actividades a realizar. Problema de planificación. Aunque se trate de un presupuesto, es necesario determinar el plan de producción del pedido de cara a determinar posibles fechas de entrega. 7.4.1. Presupuestado El método que resuelve la tarea de presupuestado está representado en la Figura 7.3. Estas redes seguen con la notación descrita en el Capítulo 3, de forma que cuando una transición está coloreada significa que será sustituida. Para facilitar su lectura, no anotamos todas las transiciones de la red y los métodos complejos se muestran a través
282 7. Proceso de presupuestado en la industria del mueble Presupuestado Diseño de Producto Valorar diseño Finalizar presupuesto Problema de valoración Establecer base de reglas para la estimación de tiempos Proponer diseño Revisar diseño SECUENCIA REPETIR-MIENTRAS SECUENCIA Si el diseño no está finalizado Si el diseño está finalizado Diseño de producto Context Context Context x x x x Establecer base de reglas para la estimación de tiempos Context Context Finalizar presupuesto Valorar diseño x PSM de Presupuestado Proponer diseño Revisar diseño ContextContext Context SECUENCIA PSM proponer y revisar Obtener descripción Context Obtener descripción Figura 7.3: Descomposición en tareas del método que resuelve la tarea de presupuestado de muebles de su árbol de descomposición. Este árbol se lee de arriba hacia abajo y representa las tareas mediante elipses y los métodos mediante rectángulos. Cuando un método resuelve una tarea, existirá un arco entre ambos elementos. Cuando un método se descompone en (sub)tareas, el método tendrá tantos arcos de salida como (sub)tareas. Finalmente, la descripción operacional del método se representa mediante una HLPN. Recordar que en realidad la descripción operacional es una HLPN jerárquica y, por lo tanto, está compuesta por más de una HLPN. Sin embargo, para simplificar dicha representación únicamente se mostrará la estructura de ejecución del proceso y no la red jerárquica completa. La Figura 7.3 muestra la descomposición de primer nivel de la solución propuesta para este problema. Como se puede apreciar en dicha figura, el método que resuelve el presupuestado obtiene en primera instancia la descripción del pedido a realizar. A
7.4. Flujo de trabajo de presupuestado 283 partir de esta descripción inicia un conjunto de iteraciones hasta encontrar el diseño del producto más adecuado para luego finalizar el presupuesto. Cada una de las iteraciones realiza un diseño del producto a partir de la descripción del producto a fabricar. El diseño de un producto es un proceso complicado que difícilmente se realiza en un único paso. Dado que resulta necesario conciliar la componente artística del diseño con los criterios de fabricación y éstos con los criterios de negocio, en cada paso, el director técnico y el departamento comercial se encargan de valorar el resultado del diseño. Esta parte del análisis es compleja, ya que no sólo se supervisan los planos técnicos del producto y los procesos de fabricación necesarios para llevarlos a cabo, sino que también se tienen en cuenta criterios de productividad o estratégicos de la empresa. Por ejemplo, en esta fase se decide si es necesario simplificar partes del mueble o buscar componentes semi-acabados (como son las puestas, cajones, o paneles semi-acabados) que puedan comprarse directamente sin necesidad de fabricarlos y así disminuir la carga de fabricación (aun a expensas del coste). Se puede apreciar también cómo este método combina los distintos patrones de control hasta llegar a las (sub)tareas que lo componen. La coreografía de este método utiliza dos secuencias y una iteración repetir-mientras. La Figura 7.3 también muestra el método que resuelve la tarea de diseño del producto. En este caso, el WF se modela como un método denominado proponer y revisar que es un método genérico utilizado para la satisfacción de restricciones [43, 228]. Este método se emplea para obtener diseños de muebles que sean viables y con un coste adecuado. La obtención de esos diseños se basa en la evaluación y modificación de los requerimientos y restricciones establecidas en el modelo conceptual. 7.4.2. Establecer base de reglas de estimación de tiempos La Figura 7.4 muestra la resolución de la tarea encargada de establecer la base de conocimiento con las reglas para estimar los tiempos de procesado. La selección de la base de reglas no es trivial y depende del diseño conceptual y del tipo de planificación que se quiere realizar. En ocasiones no es posible obtener un diseño detallado del producto a elaborar y consecuentemente no siempre resulta viable inferir con exactitud las operaciones a realizar. Esta situación es más habitual de lo esperado y se suele producir en las primeras tomas de contacto con los clientes o cuando estos últimos no tienen una idea exacta del producto. En cambio, otras veces el diseño conceptual puede trasladarse a planos CAD y a partir de ellos extraer con exactitud las operaciones a realizar. El grado de incertidumbre de las dos situaciones anteriores es completamente diferente. En la primera, ni las operaciones ni la mayoría de los parámetros de fabricación están definidos y en caso de estarlo su incertidumbre es elevada. Para estas situaciones es necesario disponer de un conjunto de fórmulas que permitan absorber esta falta de datos: cada fórmula asimilará parte de la incertidumbre a través de los coeficientes de su polinomio y además hará estimaciones a partir de parámetros más globales desligando dicho tiempo de una máquina en particular. Por ejemplo, si el diseño conceptual no dispone de información acerca de si el acabado será manual o
284 7. Proceso de presupuestado en la industria del mueble REPETIR-HASTA SECUENCIA Establecer base de reglas para la estimación de tiempos PSM para establecer las fórmulas de estimación de tiempos Aprender base de reglas Seleccionar proceso de fabricación y máquina Seleccionar base de reglas Aprender fórmula Seleccionar fórmula de otra base de reglas Context Seleccionar proceso de fabricación y máquina Context Alguna fórmula no establecida Todas las fórmulas establecidas Context Context x xx ELECCIÓN Context ELECCIÓN Seleccionar base de reglas Aprender base de reglas Aprender fórmula Seleccionar fórmula de otra base de reglas Figura 7.4: Flujo de trabajo del método encargado de seleccionar la base de reglas de estimación de tiempos automático, no tiene sentido asignar dicha operación a un conjunto de operarios o a un robot de barnizado. En estos casos, la operación de acabado será genérica, no estará ligada a un recurso en particular y aplicará un coeficiente sobre el largo y el ancho de la pieza que permita asumir dicha incertidumbre. Este tipo de reglas se corresponden directamente con las fórmulas vistas en el Apartado 7.3 y adquiridas de los expertos en fabricación y presupuestado de muebles. En cambio, para el segundo caso, los planos aportan todos los datos para aplicar fórmulas muy complejas o herramientas de simulación que permiten obtener resultados próximos al valor real. Para esta situación, se comprobó que a pesar de disponer de más datos, las reglas obtenidas en la fase de adquisición del conocimiento no mejoraban el error medio de las estimaciones. Por este motivo, se optó por aproximar estas estimaciones de forma automática mediante un sistema de aprendizaje de reglas cuya solución está descrita en el Apéndice A. La tarea seleccionar base de reglas aborda esta problemática y permite seleccionar las fórmulas más adecuadas para la estimación de tiempos. Aunque a partir del diseño
7.4. Flujo de trabajo de presupuestado 285 conceptual es posible discriminar si se usarán reglas con un alto o bajo nivel de detalle, la selección final recae en la dirección técnica. Es necesario mencionar que la tarea no se limita a la selección entre dos bases de reglas sino también a la versión de la base de reglas. Los pedidos de los clientes suelen evolucionar desde la primera entrevista hasta el diseño final y es preferible utilizar siempre la misma base de cálculo para así mantener un punto de referencia común que permita comparar los distintos presupuestos. Sin embargo, ya que el sistema de aprendizaje actualiza la base de reglas de forma periódica o bajo demanda es necesario fijar la versión de la base de reglas a utilizar. Sin embargo, en ocasiones el diseño conceptual combina elementos con un alto nivel de detalle con otros poco desarrollados. En esta situación suele ser necesario crear una base de reglas a medida para el presupuesto, es decir, una base de reglas que pueda combinar reglas genéricas con reglas muy precisas. La tarea aprender base de reglas activa esta opción a petición del usuario. La construcción de la base de reglas está encuadrada dentro del recuadro marcado como bucle repetir-hasta y consiste en asociar la fórmula al proceso de fabricación y máquina que vaya a realizarlo. Como alternativa, el WF también permite elegir la opción de aprender la fórmula con los datos disponibles en la base de datos de productos ya fabricados. El método primitivo que resuelve esta tarea de aprendizaje está detallado en el Apéndice A. Este método se resuelve mediante un modelo de regresión lineal de gran precisión pero que a su vez mantiene la estructura de conocimiento de los polinomios adquiridos de los expertos de la empresa. 7.4.3. Describir detalladamente un pedido Supóngase, a modo de ejemplo, que el departamento de marketing de la empresa recibe una solicitud de presupuesto que incluye la fabricación de un centenar de muebles para las habitaciones de un hotel. La Figura 7.5 muestra la solución a esta primera fase del presupuestado. Este WF resuelve la tarea denominada obtener descripción del método de presupuestado y consiste en fijar los principales requerimientos, restricciones y el diseño conceptual de cada uno de los muebles de los que va a constar el pedido. El primer paso de este método es la introducción del pedido en SEEPIM. Esta descripción incluye el detalle de los muebles a fabricar, es decir, las características superficiales de diseño, del tipo de madera a emplear, de la calidad de la madera, etc. Además de las características de los muebles, también incluye criterios y restricciones de coste y tiempo proporcionados por el propio cliente. Ya que un presupuesto expresa un compromiso firme hacia el cliente, es necesario disponer de una tarea que permita auditar la viabilidad de asumir el pedido a presupuestar. La tarea valorar pedido se encarga de realizar esta labor a partir de la descripción del caso. La tarea tiene dos objetivos, (i) verificar que se dispone de la suficiente información para elaborar el presupuesto, y (ii) verificar que se dispone de tiempo y recursos para asumir su producción. Esta tarea se resuelve adaptando el método clásico de valoración disponible en la librería de componentes de CommonKADS [43]. Siguiendo con el ejemplo y una vez aprobada la creación del presupuesto, el perso-
[Document text truncated for crawler view.]