1

Composición de modelos ejecutables para la Construcción de Motores de Lenguajes Específicos

Pablo Andrés Márquez Fernández

Universidad de los Andes Facultad de Ingeniería

Departamento de Ingeniería de Sistemas y Computación Maestría en Ingeniería de Sistemas y Computación

BOGOTA DC, 2008

2

Composición de modelos ejecutables para la Construcción de Motores de Lenguajes Específicos

Pablo Andrés Márquez Fernández

Tesis de grado:

Director: Profesor Asociado. Jorge Alberto Villalobos Salcedo

Universidad de los andes Facultad de ingeniería

Departamento de Ingeniería de Sistemas y Computación Maestría en Ingeniería de Sistemas y Computación

BOGOTA DC, 2008

3

TABLA DE CONTENIDO

TABLA DE CONTENIDO................................................................................... 3

LISTA DE FIGURAS Y TABLAS....................................................................... 5

1. INTRODUCCIÓN ........................................................................................... 7

2. BPMN Y TABLEROS DE CONTROL............................................................ 8

2.1 BPMN ............................................................................................................................................8

2.1.1 Historia ....................................................................................................................................10

2.1.2 Elementos del Lenguaje .......................................................................................................11

2.1.3 Ejemplo de un Proceso en BPMN.......................................................................................17

2.2 Tableros de Control..................................................................................................................19

2.2.1 KPI ............................................................................................................................................21

3. MARCO CONCEPTUAL.............................................................................. 25

3.1 Fábricas de Software ...............................................................................................................25

3.2 Proyecto Cumbia ......................................................................................................................27

3.2.2 Cumbia XPM ...........................................................................................................................29

3.2.3 Cumbia XAM ...........................................................................................................................32

4. MOTOR DE BPMN SOBRE CUMBIA ......................................................... 34

4.1 Metamodelo Alegre-BPMN ......................................................................................................34

4.2 Arquitectura Alegre ..................................................................................................................41

4.2.1 Kernel.......................................................................................................................................42

4

4.2.2 Traductor.................................................................................................................................45

4.2.3 Protocolos...............................................................................................................................54

5. DOMINIO DE TABLEROS DE CONTROL CUMBIA DASHBOARD........... 56

5.1 Metamodelo Cumbia Dashboard............................................................................................56

5.2 Arquitetura Dashboard-Model ................................................................................................60

5.2.1 Kernel.......................................................................................................................................60

5.2.2 Traductores.............................................................................................................................62

5.2.2 Protocolos...............................................................................................................................62

5.4 Implementación Alegre Dashboard .......................................................................................63

6. CONCLUSIONES ........................................................................................ 66

APENDICE....................................................................................................... 68

BIBLIOGRAFÍA ............................................................................................... 71

5

LISTA DE FIGURAS Y TABLAS Tabla 1. Elementos de Flujo .......................................................................................11 Tabla 2. Tipos de Actividades .....................................................................................12 Tabla 3. Tipos Eventos ...............................................................................................15 Tabla 4. Tipos de Gateways .......................................................................................15 Tabla 5. Conectores....................................................................................................16 Tabla 6. Swimlanes.....................................................................................................16 Tabla 7. Artefactos......................................................................................................17 Figura 1. Proceso Inicio de semestre en el Grupo Cupi2 ............................................19 Figure 2. Cuatro características de los KPI. ................................................................22 Tabla 8. Diagramas, visualización KPI ........................................................................24 Figura 3. Estructura Objeto Abierto .............................................................................29 Figura 4. Ejemplo Cumbia-XPM..................................................................................32 Tabla 9. Elementos Cumbia-XPM ...............................................................................32 Figura 5. Implemetación estructura del Metamodelo de Alegre-BPMN .......................35 Figura 6. Máquinas de Estados del Proceso ...............................................................36 Figura 7. Máquina de estados del Pool .......................................................................36 Figura 8. Máquina de estados del Lane ......................................................................37 Figura 9. Máquina de estados de los Eventos.............................................................38 Figura 10. Máquina de estados de un Subproceso .....................................................38 Figura 11. Máquina de estados de la Actividad...........................................................39 Figure 12. Máquina de estados de las Gateways........................................................40 Figura 13. Máquina de estados de los Conectores .....................................................40 Figura 14. Sincronización de Modelos ........................................................................41 Figura 15. Arquitectura Alegre ....................................................................................42 Figura 16. Vista del Kernel..........................................................................................43 Figura 17. Vista del Process Space BPMN .................................................................43 Figure 18. Vista del Instance Space BPMN ................................................................44 Tabla 10. Patrón Secuencia........................................................................................45 Tabla 11. Patrón División en Paralelo .........................................................................46 Tabla 12. Patrón Sincronización .................................................................................47 Tabla 13. Patrón Decisión Exclusiva...........................................................................47 Tabla 14. Patrón Unión Simple ...................................................................................48 Tabla 15. Patrón Selección Múltiple ............................................................................49 Tabla 16. Patrones Complejos de Sincronización .......................................................49

6

Tabla 17. Patrón Ciclos Arbitrarios..............................................................................50 Tabla 18. Eventos Iniciales .........................................................................................50 Tabla 19. Primer caso de Eventos Intermedios…………………………………………...51 Tabla 20. Segundo caso Eventos Intermedios ............................................................52 Figure 19. Protocolo de Despliegue de un proceso.....................................................54 Figure 20. Protocolo de Creación de una instancia .....................................................55 Figura 21. Metamodelo Cumbia Dashboard................................................................56 Figura 22. Instancia del Modelo de Datos de Alegre Dashboars .................................57 Figura 23. Visualización instancia Alegre Dashboard..................................................58 Figura 24. Máquina de estados de Dashboards ..........................................................59 Figura 25 Máquina de estados de los elementos del modelo......................................59 Figure 26. Arquitectura Alegre Dashboard ..................................................................60 Figura 27. Kernel Dashboard-Model ...........................................................................61 Figura 28. Dashboard Space ......................................................................................61 Figure 29. Protocolo de Despliegue de un proceso.....................................................62 Figure 30. Protocolo de Creación de una instaciacia de un Dashboard ......................63 Figura 31. Visión de Alegre-Dashboard ......................................................................64 Figura 32. Escala Jerárquica Alegre-BPMN................................................................65 Figura 33. Modelo Alegre BPMN.................................................................................68 Figura 34. Archivo Alegre-BPMN ................................................................................69 Figura 35. Archivo Visualización Cumbia-Dashboard..................................................69 Figura 36. Archivo Cumbia-Dashboard .......................................................................70 Figure 37. Alegre Dashboard ......................................................................................70

7

1. Introducción Actualmente dentro de las organizaciones, una de las principales preocupaciones es poder documentar y expresar los diferentes procesos que soportan sus actividades; debido a la gran diversidad de tipos de compañías y por ende la diferencia tan marcada entre los conceptos, se hace necesario crear heurísticas propias para definirlos. Dentro de esta familia de lenguajes existen unos que describen procesos de negocio, otros procesos de desarrollo de software e incluso procesos de aprendizaje. De lo anterior se puede pensar en una industria en la cual se produzcan diferentes tipos de herramientas como motores, editores o clientes que soporten cada uno de los lenguajes; en este tipo de fábricas la reutilización de diferentes componentes se convierte en una obligación debido a la repetición de los conceptos entre los diferentes lenguajes. Tal como se mencionó anteriormente, existe una gran cantidad de lenguajes que describen procesos de negocio, de todos estos se destaca BPMN (Business Process Modelin Notation), que es un lenguaje gráfico en el que se pueden describir diferentes conceptos de organizaciones dedicadas a los negocios como información, recursos entre muchos otros. El principal objetivo de este lenguaje es que sea de fácil lectura para cualquier persona que está involucrada en el mismo. No obstante, al ser un lenguaje gráfico, la construcción de las diferente herramientas se dificulta ya que no tiene un lenguaje estándar que una máquina lo pueda entender, además de la ambigüedad de ciertos conceptos, por ejemplo, un mensaje dentro del contexto BPMN puede ser un correo electrónico, un mensaje de texto o incluso una comunicación escrita. Una vez se tiene en ejecución los diferentes procesos, la creación de métricas sobre el proceso se vuelve una necesidad para el cumplimiento de los objetivos y metas de la organización. Los resultados de estas mediciones se deben dar en el momento oportuno ya que esto le va permitir a la cabeza de la organización tomar medidas correctivas. Por esta razón el apoyo en herramientas tecnológicas es fundamental, estos instrumentos deben dar la flexibilidad necesaria para que los usuarios puedan definir sus propias métricas, además de un conjunto de opciones para poderlas leerlas de una manera muy sencilla y poder definir umbrales para poder tener alarmas automáticas cuando ciertos elementos se salgan de control.

8

2. BPMN y Tableros de Control Dada la diversidad de tipos de organizaciones y por ende la diferencia tan marcada de conceptos, no se puede pensar en un lenguaje estándar en el que se pueda expresar los elementos de cualquier tipo de organización. Es de aquí de donde nace una gran cantidad de lenguajes, por ejemplo, IMS Learning Design (IMS-LD) que es un lenguaje creado para documentar de una forma estándar los procesos de enseñanza. Otro ejemplo de estos lenguajes, es Software Process Engineering Metamodel (SPEM), con el que se describen los procesos de desarrollo de software. Dentro de estos, hay uno cuyo principal objetivo es la orquestación de procesos a nivel de máquinas, es decir, describe y ejecuta la forma en que diferentes máquinas interactúan en un proceso, este es llamado Business Process Execution Lenguage (BPEL). Finalmente, del que se va hablar en este capítulo, BPMN (Business Process Modeling Notation), que es un lenguaje que pretende estandarizar la forma en que se describen los procesos de negocio. Una vez están implementados los procesos, se deben crear objetivos medibles a lo largo de la ejecución del mismo, esta información en el momento adecuado va permitir tomar las medidas necesarias para corregir y así llegar al objetivo final cumpliendo las metas. El tiempo de demora en tener los datos del proceso puede ser un factor determinante en la consecución de las metas, es por esto que el apoyo tecnológico se vuelve una necesidad. Dentro de las herramientas tecnológicas, existe una que se llaman los Tablero de Control, que es la visualización de unas medidas que se definen a partir del proceso para conocer su estado. Este concepto nace de los Tableros de Control de los aviones, los cuales dan una radiografía completa del estado de la aeronave en el momento oportuno. De este tema se hablará en la segunda parte de este capítulo.

2.1 BPMN Como se mencionó anteriormente, existen muchos lenguajes para describir procesos, entre esos hay un gran subconjunto que muestran diferentes formas de expresar losprocesos de negocio, como los Diagramas de Actividad de UML o BPEL4P (Business Process Execution Lenguage for People); entre todos estos BPMN se convirtió en el más utilizado y por ende el estándar. BPMN viene del acrónimo

9

Business Process Modeling Notation y es un lenguaje gráfico que se utiliza para describir procesos de negocio, tal como se mencionó anteriormente. A diferencia de otros lenguajes, este pretende que la lectura sea fácil para cualquier persona que está involucrada en el proceso, además de darle una semántica gráfica a lenguajes que se describen en xml como BPEL4WS (Business Process Execution Lenguange for Web Services), o xpdl (XML Process Definition Language), entre muchos otros. Para evaluar un lenguaje de definición de procesos, W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, A.P hablan de veinte patrones de control de flujo, en los cuales se tratan los esquemas de divergencia, sincronización y cancelación en la secuencia de actividades en un proceso. Estos patrones ayudan a calificar la expresividad de un lenguaje a nivel de control y se dividen en cinco diferentes grupos, Control Básico, Divergencia y Sincronización Avanzada, Estructurales, Múltiples instancias, Basados en estados y Cancelación. La evaluación de BPMN según el artículo “On the suitability of BPMN for Business Process Modelling” arroja los siguientes resultados: Patrones de Control Básico Secuencia Soporte Directo División en Paralelo Soporte Directo Sincronización Soporte Directo Selección Exclusiva Soporte Directo Convergencia Directa Soporte Directo Patrones de Sincronización y Divergencia Avanzada Selección Múltiple Soporte Directo Convergencia Sincronizada Soporte Parcial Convergencia Múltiple Soporte Directo Discriminador Soporte Parcial N-out-of-M Join Soporte Directo Patrones Estructurales Ciclos Arbitrarios Soporte Directo Terminación Implícita Soporte Directo Patrones que Involucran Múltiples Instancias Múltiples Instancias sin Sincronización Soporte Directo Generación de Múltiples Instancias conociendo el número de instancias en tiempo de diseño

Soporte Directo

10

Generación de Múltiples Instancias conociendo el número de instancias en tiempo de ejecución (While)

No da soporte

Generación de Múltiples Instancias conociendo el número de instancias en tiempo de ejecución (For)

Soporte Directo

Patrones Basados en Estados Decisión Diferida Soporte Directo Ruta Paralela Interpolada Soporte Parcial Milestone No da Soporte Cancelación Cancelación de una Actividad Soporte Directo Cancelación del Proceso Soporte Directo Sin embargo, este lenguaje presenta deficiencias en la expresividad de la información y de los recursos. De los cuarenta patrones de Información presentados por Russel, Hofstede, Edmond y Van der Alst, que son descritos en el artículo “Workflow Data Patterns”, tal como lo muestra [10], solo cumple dieciocho. No obstante, el caso más crítico de BPMN, lo presentan en los recursos, de los cuarenta y tres patrones presentados en “Workflow Resource Patterns”, solo logra dar soporte a ocho, tal como lo muestra [10].

2.1.1 Historia En agosto del 2001 se conformó el grupo “Notation Working Group” integrado por 58 miembros de 35 diferentes compañías, cuyo propósito era crear un lenguaje que describiera procesos de negocio. En noviembre de 2002 y en agosto de 2003 se lanzan borradores de la especificación (BPMN 0.9 draft specification), versiones que tenían ciertas deficiencias, las cuales se corrigieron y en el 2004 se lanza la primera versión de “Business Process Modeling Notation Sepecification”, la cual, en febrero del 2006, la organización OMG (Object Managemente Group) acepta y adopta, lo que generó gran controversia y a la vez publicidad para BPMN, ya que OMG es la organización que maneja UML, lenguaje que, como se menciono anteriormente, ya permitía expresión de los procesos de negocio por medio de los Diagramas de Actividad.

11

Actualmente se está realizando la segunda versión de esta especificación, en esta se van a incluir nuevos elementos como el modelo del lenguaje, un xml estándar para la descripción de los procesos, entre muchos otros.

2.1.2 Elementos del Lenguaje BPMN se divide en 4 diferentes tipos de elementos: elementos de flujo, conectores, artefactos y swimlanes. Los elementos de flujo son los encargados de definir el comportamiento del proceso. Estos se dividen en tres diferentes: Actividades Las actividades es una acción que

realiza un participante del proceso. Estas pueden ser atómicas o compuestas [1].

Eventos Es un elemento que dispara una acción

dentro del proceso. Existen tres tipos de eventos, los iniciales que es el punto en que comienza el proceso; los intermedios paran el flujo hasta que la condición se cumpla, o en caso que estén inmersos en una actividad, cuando se cumple la condición indican el camino que se debe tomar; y los eventos finales que indican el final del flujo.

Gateways Los gateways, son los elementos que permiten que el flujo de control se divida y se sincronice.

Tabla 1. Elementos de Flujo

Dentro de cada uno de estos elementos anteriormente descritos hay diferentes tipos:

12

Actividades: Loop (Ciclo) Son las actividades que se repiten y

que se ejecutan secuencialmente, es decir, cuando se termina la ejecución de una comienza la siguiente.

Múltiples Instancias

Son actividades que se repiten, pero que a diferencia del loop, se ejecutan en paralelo.

Compensación Son las actividades que se realizan en

caso de lanzamiento de una excepción dentro de una transacción.

Ad-Hoc Como se puede ver en la figura, a

diferencia de los otros tipos de actividades, este solo se puede como no atómico, ya que lo que indica es que las actividades que hay en su interior se ejecutan sin ninguna clase de orden.

Transacciones Significa que hay una transacción en su interior, en caso que la actividad no se alcance a terminar, el flujo sale por el evento de cancelación mostrado y las actividades de compensación se activan.

Tabla 2. Tipos de Actividades

13

Eventos: Eventos Iniciales Defecto Este evento inicia el proceso.

Mensaje Este evento espera la llegada de un

mensaje para que el proceso arranque. Temporizador Este evento de inicialización indica que

cada que se cumple una condición de tiempo, comienza el proceso.

Regla Este evento espera a que se cumpla una condición para iniciar el proceso.

Link Este evento conecta la finalización de un proceso con el inicio de otro.

Múltiple Se utiliza para expresar mas de una

condición de inicialización del proceso. Solo es necesario que se cumpla una de las condiciones para que se inicie el proceso.

Eventos Intermedios Defecto Solo es válido en medio del flujo del

proceso e indica un cambio de estado del proceso.

Mensaje Cuando está adentro de una actividad, indica que si llega un mensaje sale por el conector que tiene el evento. Cuando está en medio del flujo, indica que se va mandar o recibir un mensaje

Temporizador El cumplimiento de la regla de tiempo cambia el flujo normal de la actividad en la que se encuentra. En caso que esté en medio del flujo, frena el proceso hasta que la condición se cumpla.

Error Este es el evento que atrapa los errores no

14

identificados dentro de los subprocesos y las actividades. Por esta razón solo puede estar inmerso en una actividad o subproceso.

Cancelación Este evento solo puede estar como salida de una transacción y significa que la transacción fue cancelada. Esta dispara las actividades de compensación de la transacción.

Compensación Cuando se genera la cancelación de la transacción, este activa la actividad de compensación.

Regla Es utilizado únicamente para atrapar excepciones identificadas dentro de un subproceso.

Link Se conecta con otro Evento Link para mandar el flujo a ese evento.

Múltiple Es el evento que se utiliza para expresar la

unión de varios eventos. Solo basta con el cumplimiento de uno para que se dispare la acción.

Eventos Finalización Defecto Finalización de un camino.

Mensaje Indica que se finaliza el camino cuando se

termina de mandar un mensaje.

Error Se termina el camino con un error y un evento intermedio de error debe atrapar la excepción.

Cancelación Este debe ir al final de una transacción e implica que la transacción es cancelada y que se debe disparar el evento intermedio de la cancelación y los eventos de compensación.

15

Compensación Indica que una compensación debe ser cumplida y la atrapa un Evento Intermedio de Compensación.

Link Indica que el final de un proceso arranca otro proceso.

Terminación Indica que se debe forzar a terminar el

proceso.

Múltiple Es la unión de varios eventos de finalización.

Tabla 3. Tipos Eventos

Gateways: Gateway Paralelo (AND)

Este elemento divide el flujo en el número de conectores que tiene de salida. Solo permite el paso de flujo cuando todos los conectores de entrada hayan llegado.

Gateway Exclusivo (XOR)

Este elemento no divide el flujo, por el contrario, solo deja que salga por uno de los conectores de salida. Este elemento permite el paso del flujo cuando llega por uno de los conectores de entrada.

Gateway Inclusive (OR)

Este divide el flujo en cualquiera de las combinaciones de los conectores de salida que tiene. En la sincronización, este elemento espera a que el flujo llegue de los caminos que en otro gateway se abrieron.

Gateways Complejo

Los Complex Gateways son los elementos que van a permitir expresar, tanto en sincronización como en divergencia, los casos que no se van a poder expresar en los otros Gateways

Tabla 4. Tipos de Gateways

16

Los conectores son los elementos que unen dos elementos del proceso. Existen cuatro diferentes tipos: Flujos de Secuencia

Es el conector que une dos elementos de flujo que están adentro del mismo pool. Indica que el paso de flujo entre los dos elementos.

Flujo condicional

Une dos elementos de flujo y permite el paso de control si se cumple la condición.

Flujos de Mensaje

Unen dos elementos de flujo que están en diferentes pools. Usualmente se utilizan para sincronizar los procesos que están corriendo en diferentes pools.

Asociaciones Es el conector que une un elemento de flujo con un artefacto.

Tabla 5. Conectores

Los swimlanes son los elementos que describen roles y tipos de tareas de un proceso. Estos se dividen en dos diferentes tipos: Pool El pool es el elemento que describe un

rol o un participante dentro de un proceso.

Lane El lane es una división en el pool que sirve para mostrar los diferentes tipos de tareas.

Tabla 6. Swimlanes

17

Los artefactos son los elementos que nos ayudan a documentar el proceso, estos no generan control de flujo en el proceso. Hay tres diferentes tipos de artefactos: Data Object Este elemento describe que una actividad

tiene como entregable o como entrada un documento.

Grupos Es un elemento que se utiliza para unir

grupos de actividades en diferentes pools, con el fin de documentar el proceso

Anotaciones Es el elemento que se utiliza para dar

información adicional en cualquier parte del proceso.

Tabla 7. Artefactos

2.1.3 Ejemplo de un Proceso en BPMN Se va tomar un ejemplo del grupo de investigación Cupi2, este es un equipo de la Universidad de los Andes que tiene como principal objetivo generar nuevas metodologías pedagógicas para enseñar a programar. Este grupo tiene a cargo algunos cursos de la Facultad de Ingeniería de Sistemas y Computación y el inicio de los semestres se hacen unas tareas para el buen transcurso de los mismos. El proceso es el siguiente, cada principio de semestre, el coordinador debe mandar un mensaje al asistente graduado indicando que es el momento de realizar las tareas de iniciar el semestre, este a su vez tiene que hacer dos tipos de tareas, la primera es la generación de Cronogramas y la actualización del sitio web; una vez el asistente tenga los cronogramas los envía al coordinador quien había quedado en espera de estos. Paralelo a la generación de cronogramas, el coordinador debe crear las listas de correos de las secciones y generar las diapositivas de las presentaciones, la primera

18

es la de inducción a los nuevos profesores y la otra es la bienvenida para todos los profesores. Cuando termine todas estas tareas el coordinador estará listo para hacer las presentaciones, en las que primero debe hacer la inducción de los nuevos profesores y al finalizar debe comenzar el proceso de selección de los monitores. El asistente graduado para generar los cronogramas debe primero ingresar las fechas importantes del semestre y subir la información de los profesores que van a dictar las secciones, estos dos pasos se hacen por medio del sitio web y actualizan el mismo. Una vez tenga lista esta información, puede comenzar la generación automática de los cronogramas, los debe revisar y en caso que no estén correctos, arreglarlos. En el momento que tenga los cronogramas los debe enviar al coordinador y publicarlos en el sitio web. Para la actualización del sitio web cuando se termine de subir la información de los profesores se debe subir los ejercicios y habilitar el sitio de los monitores.

19

Figura 1. Proceso Inicio de semestre en el Grupo Cupi2

2.2 Tableros de Control “Lo que ud mide es lo que ud obtiene” [6], dice el artículo “The Balanced Scorecard – Measures that drive performance” de Robert Kaplan y David Norton publicado en

20

enero/febrero del 1992 en Havard Business Review, haciendo referencia a la importancia de tener metas medibles dentro de una organización. El hecho de tener objetivos que sean cuantificables, da la posibilidad de evaluar para hacer un mejoramiento continuo de la productividad, lo que va generar que la compañía sea cada día mas competitiva y efectiva en sus procesos. Reforzando lo anterior, se han creado varias formas de medir diferentes dimensiones dentro las organizaciones, por ejemplo, los Balance Scorecards, que nacen en el artículo mencionado anteriormente, presentan una metodología que muestra cuando los empleados de las diferentes áreas e incluso la misma compañía, van cumpliendo las metas que están plasmadas en el plan estratégico. Otra técnica donde se plantean diferentes formas de medir es CPM (Corporate Performance Management) que son “las metodologías, métricas, procesos y sistemas usados para la monitorización del funcionamiento del negocio de una empresa”[8]. Como último ejemplo se citará Six Sigma que es una metodología que pretende la mejora en la calidad de los productos entregados, llegando a un máximo de 3.4 defectos por millón de productos, para esto, plantea un proceso donde el primer paso es definir el problema o el defecto, después, hacer las respectivas mediciones, las cuales se analizan y se encuentran los puntos de mejora, manteniendose el control del proceso. Como se puede ver en lo anteriormente mencionado, el monitoreo en el que se mantienen actualizadas las mediciones durante la ejecución de los procesos, es de vital importancia para cualquiera de las metodologías nombradas. Es de aquí de donde nace el concepto de Tablero de Control, que son diferentes mediciones de la organización, de sus procesos en cada una de las áreas, consolidándose de una forma clara, con el fin que sea de fácil comprensión para la persona que las está leyendo y que den una vista del estado de la empresa. En la documentación existente se hace un paralelo con los Tableros de Control de los aviones, ya que es de aquí de donde nace el termino; estos le dan al piloto una visión general del estado del avión y del vuelo, sin necesidad de que esté mirando el tanque de gasolina o midiendo la altura. Además, la información la entrega en tiempo real y en caso de existir un problema lanza una alarma. Haciendo el símil hacía el caso de los Tableros de Control de las empresas, esta herramienta le debe dar a la cabeza de la organización una visión completa del estado de los proceso y de la organización, sin necesidad que esta persona pierda el tiempo midiendo, e igual que en los aviones, la información la debe entregar en tiempo real y en caso de encontrar anomalías lanzar alarmas.

21

Hay varías características deseables de los Tableros de Control, la primera lista viene del acrónimo SMART: Synergetyc (Sinérgico): La suma de todos los elementos juntos deben facilitar el entendimiento del estado de la organización, incluso mas que la lectura individual de cada uno de los elementos. En otras palabras, los colores, la presentación de los elementos para ser visualizados debe facilitar la comprensión del Tablero de Control. Monitor KPIs (Monitor de KPI): Deben estar todos los diagramas que faciliten la lectura del tableros de control. Accurate (Segura): La información que se presenta debe ser exacta y debe prestar la mayor confiabilidad en su veracidad. Responsive (Responsivo): Debe poder responder con alarmas cuando una de las variables se sale de los umbrales establecidos. Timely (Oportuno): El Tablero de Control debe entregar la información en el momento correcto, que en la mayoría de situaciones es en Tiempo Real.

2.2.1 KPI Durante toda la sección se ha mostrado la importancia de medir y de tener la información correcta en el momento oportuno. Esta información en las diferentes organizaciones, e incluso en las diferentes áreas de la misma compañía es diferente. Es por esto que nace un concepto de vital importancia para todo este análisis, los KPI, estos vienen del acrónimo Key Performane Indicators, que son las métricas que se definen en cada una de las organizaciones o áreas de la misma, para medir el rendimiento de la organización. Siguiendo con la analogía presentada en los Tableros de Control de un avión y el de una empresa, los KPI de un avión sería la altitud, el nivel de gasolina, la dirección y en el caso de una empresa puede ser el nivel de satisfacción de un cliente, tiempo de demora de una entrega, entre muchos otros.

22

Tal como se menciona en [7] y se muestra en la figura, los KPI se deben definir a partir de cuatro características:

Figure 2. Cuatro características de los KPI.1

Data Sources (Origen de los Datos): Esta característica se refiere, como su nombre lo dice, al origen de los datos, es decir, una vez se tiene la métrica definida, se debe pensar cuales y de donde se recolectan los datos que se van a utilizar para calcularla. Granularity (Granularidad): Esta característica se refiere a “los diferentes niveles para el cálculo de los KPI”. Los KPI se calculan a partir de la combinación variables que son de tres diferentes tipos, tiempo, geografía y producto. En otras palabras, se debe definir la mayor cantidad de elementos y de variables de estos tres tipos para su futuro cálculo e interpretación. Calculation (Cálculo): Esta característica hace referencia a la frmula matemática para el cálculo del KPI.

1 Imagen tomada de [7]: “Enterprise Dashboards, design and best practice for it”. Página 20.

23

Variance (Varianza): Esta característica hace referencia a la varianza del KPI analizado desde el origen de los cambios, y la forma en que se calcula para la visualización de los mismos. Ya una vez se definieron los KPI, es de vital importancia, dentro del contexto de Tableros de Control, la visualización de los datos. Para esto se utilizará el concepto de Diagramas, que son elementos gráficos que permiten una fácil lectura del estado de los KPI. En principio se van a dividir en cinco: Pies

Es un diagrama que permite la compración porcentual de las variables, cada una de estas ocupa una fracción del área del pastel. Esta porción se calcula a partir de la división del dato entre la suma de las otras que tienen un porcentaje dentro del diagrama.

Barras Las barras es una gráfica en la que se comparan valores entre las diferentes variables. La altura de cada una de las barras indica el valor que tiene.

Velocímetros Es un dato númerico el cual se mueve

en un rango, dentro de este rango se definen zonas en las cuales se van a generar Alarmas.

Líneas Es un gráfico en el que se unen los

puntos de las diferentes variables con una línea. Este gráfico es usado frecuentemente para poder ver el comportamiento númerico de una variable a través del tiempo.

24

Tabla Finalmente tenemos las tablas que son los elementos gráficos que permiten una rápida ubicación de los valores númericos de las varibales.

Tabla 8. Diagramas, visualización KPI

25

3. Marco Conceptual Como se ha mencionado anteriormente en el documento, las organizaciones para ser más eficientes y productivas, tienen la necesidad de apoyar diferentes partes de su negocio en herramientas tecnológicas. Estas carencias a nivel de software se han intentado satisfacer de una forma muy artesanal, donde asegurar la calidad del producto, los tiempos de entrega y el costo se convierte en una labor muy riesgosa. Reforzando esto, solo 16% de los proyectos de software terminan bajo el presupuesto esperado y en el tiempo planeado, según plantea el Informe CHAOS. De aquí surge la necesidad buscar formas de industrializar el desarrollo de software, donde se pueda tener bajo control la calidad, mantener bajos los costos y reducir los riesgos que puedan demorar la entrega del producto. Dentro de este marco, en el grupo de construcción de software de la Universidad de los Andes, nace un grupo de investigación llamado Cumbia, donde uno de sus objetivos es crear una fábrica de software enfocada en el desarrollo de lenguajes y herramientas basadas en procesos. Este grupo creó diferentes modelos para cada una de las diferentes dimensiones que puede conformar una aplicación, por ejemplo, XPM (eXtensible Process Modeling) que es el activo que representa el control dentro de las aplicaciones Cumbia.

3.1 Fábricas de Software Los números para la Ingeniería de Software no son muy alentadores, según dice el estudio CHAOS hecho en 1994, únicamente el 16% de los proyectos terminan en el tiempo y el presupuesto estimado; el costo promedio del 53% de los proyectos que sobrepasan los presupuestos planeados, es de un 189% sobre el valor original, además, un 31% de los proyectos son cancelados por falta de calidad en el desarrollo. Es por esto que se vuelve necesario pensar en el concepto de Fábricas de Software donde el principal objetivo es elevar la calidad y por ende la satisfacción del cliente. El termino Fábricas de Software nace 1968 en el artículo presentado en el congreso IFIP (International Federation of Information Processing) por Bob William Bermer (1920-2004), aduciendo que era imposible que los desarrolladores de software hicieran aplicaciones de calidad simplemente con el monitoreo humano. Después de esto, en 1969, aparece la primera fábrica de software, Hitachi Software Works y con el

26

tiempo se van uniendo a este concepto diferentes empresas como Systems Development Corporation (1975), o NEC (1976), entre muchas otras[16]. Estas compañías que van teniendo una diferencia sustancial en la calidad de sus aplicaciones. A finales de la década de los ochentas y principios de los noventas comienzan a crearse diferentes visiones del termino, por ejemplo, las Fábricas basadas en Entornos de Desarrollos Integrados, cuyo principal objetivo era “producir una arquitectura y un marco de trabajo para los ISDE”, es decir, construir aplicaciones para los desarrolladores donde se automatice parte del desarrollo de software. También, con los objetivos de “mejorar la eficacia del proceso, reducir la cantidad de reprocesos y la reutilización de los ciclos de vida”, el grupo SEL (Software Engineering Laboratory) de la NASA, plantea la visión de la construcción de componentes reutilizables. Otra de estas, es la que se basa en la madurez de los procesos, la cual se crea en el Departamento de Defensa de los Estados Unidos y el objetivo es la mejora continua del proceso de desarrollo y en consecuencia una mejora del producto. Hoy en día las Fábricas de Software tienen un esquema más industrial, donde se parte de la especialización en una línea o familia de productos, creando un producto inicial y a partir de este, se crean las nuevas aplicaciones adaptándolas a las necesidades del cliente. Esto trae como consecuencia, mejorar la calidad del software, reducir los costos y riesgos que contrae el desarrollo artesanal. Tal como se mencionó anteriormente, las fábricas deben tener una especialidad, no se puede pensar en una industria de aplicaciones en la que se pueda crear cualquier tipo de aplicación, además, se debe tener unos activos, es decir unas herramientas, librerías, frameworks, bodegas y generadores de código que puedan interactuar entre ellas para llegar a un producto final. Como en cualquier industria se debe poder pensar en un monitoreo de los diferentes aspectos de la cadena de producción, además de la automatización de muchas partes de la misma. Para este último, se deben generar herramientas, frameworks e incluso lenguajes que faciliten la composición de estos activos con el fin de mejorar la calidad del producto y el tiempo de desarrollo estos. Dentro de esta visión hay dos divisiones diferentes, las fábricas que hacen sus productos a partir de la generación del código y las que componen los productos a partir de la reutilización de componentes.

27

Fábricas de Software Generativas Son las fábricas cuyas aplicaciones se generan partir de transformaciones, es decir, se parte de una entrada como un diagrama de clases, o un archivo en el que describe el producto y una herramienta genera parte del código del producto final. Apoyando este tipo de fábricas existe una línea de investigación, MDA (Model Driven Architecture), definido por la OMG (Object Management Group), donde el principal objetivo es la descripción en diferentes puntos de abstracción de los modelos y de las transformaciones entre ellos. El principal problema de este tipo de fábricas es la incapacidad de traducir uno a uno todos los conceptos entre los diferentes modelos, lo que trae como consecuencia perdida de información que puede llegar a ser relevante. Fábricas de Software por Composición Estas son las fábricas donde los activos son un conjunto de componentes que se combinan entre sí para formar una aplicación. En este tipo de fábricas se debe ofrecer un mecanismo que automatice la composición de los diferentes activos. Tal como se menciona en el libro “Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools”[17], cuando se diseñan cada uno de los activos, se debe pensar en seis diferentes aspectos: Descubrimiento: Hace mención a la generalidad del concepto, lo que significa, la posibilidad de utilizar el activo en diferentes contextos. Composición: Es la forma en que van a trabajar juntos los diferentes activos. Adaptabilidad: Característica que describe la facilidad de reutilización de estos elementos. Instalación: Es la forma en que se van a resolver las dependencias de los diferentes activos. Distribución: Aspecto que hace referencia a la localización de los activos en diferentes servidores de los activos. Organización: Esta característica hace mención a la arquitectura del activo como tal.

3.2 Proyecto Cumbia Cumbia es un proyecto del grupo de Construcción de Software de la Universidad de los Andes, donde su principal objetivo es la creación de herramientas y lenguajes que estén basados en Workflow. En Cumbia se propone “la construcción de familias de aplicaciones basadas en modelos ejecutables para cada perspectiva (control,

28

información, recursos, etc)”[18], es decir, la composición e interacción de los modelos ejecutables forman las diferentes aplicaciones. Los Modelos Ejecutables están compuestos por metamodelos cuyos elementos están desarrollados bajo el paradigma de Objetos Abiertos; bajo este concepto se definen las entidades se como “elementos que están construidos sobre los Objetos, pero tienen características que exponen su estado interno”[18]. En otras palabras, se definen como una entidad de un modelo de objetos, pero que se diferencia en que el estado no está descrito por la combinación de los valores posibles de sus atributos, sino por una estructura externa. Cumbia también se plantea como una fábrica de software por composición donde sus activos son los Modelos Ejecutables. Estos componentes son abstracciones a diferentes niveles de los conceptos que representa cada dominio, por esto dentro de los modelos se deben describir todos y cada uno de los conceptos que lo definen. Además, dar mecanismos de extensión y coordinación con diferentes modelos, esto con el fin de poder evolucionar los diferentes metamodelos y haciendo necesario la construcción de los modelos con elementos que parten del paradigma Objetos Abiertos. Los Objetos Abiertos, tal como se mencionó anteriormente, son entidades dentro de un modelo de objetos, en los cuales su estado esta descrito por una máquina de estados que tiene asociado un conjunto de acciones. Tal como se ve en la figura, las máquina de estados están compuestas por Estados, Transiciones y Eventos. Los estados es la unión de un subconjunto de valores que tienen los atributos del objeto, el cual recibe eventos que pueden generar el cambio del mismo a través de una transición. El cambio de estado genera tres diferentes eventos (1) la salida de estado, (2) el transcurso de la transición y (3) la entrada al nuevo evento, lo que genera un buen punto para la sincronización no solo de los elementos del modelo, si no entre los objetos de los diferentes dominios.

29

Figuro 3. Estructura Objeto Abierto

Estas estructuras ofrecen tres diferentes mecanismos de extensibilidad de sus elementos: Extensión Simple: Se habla de extensión simple cuando se agregan estados a la máquinas de estados. Adaptación: Este mecanismo se refiera a la posibilidad de agregar acciones a las máquinas de estados. Especialización: Los elementos bajo este paradigma pueden heredar el comportamiento de otro elemento y por ende especializar su comportamiento. Bajo este modelo se han desarrollados diferentes modelos, por ejemplo, Cumbia-XPM (eXtensible Process Modeling), que es el componente donde se desarrolla la parte de Control de las aplicaciones; también existe un dominio donde se pueden describir reglas de tiempo, XTM (eXtensible Time Modeling); XRM (eXtensible Resource Modeling), que es el componente donde se define la parte de recursos de una aplicación.

3.2.2 Cumbia XPM Dentro de una fábrica de software donde la línea de producto son las aplicaciones referentes a los procesos, un modelo donde se pueda describir el control de flujo se convierte en una necesidad. Cumbia-XPM viene del acrónimo Extensible Process Modeling y es un modelo ejecutable que cuenta con un conjunto minimal de elementos en el que se puede modelar el componente de control de una aplicación. Al estar dentro de la familia de productos Cumbia, el modelo del lenguaje se hizo partiendo de

30

los objetos abiertos, por esto el comportamiento e interacción entre los elementos del lenguaje se hace por medio de las máquinas de estado, lo que va traer como consecuencia un componente flexible y reutilizable dentro de esta fábrica de aplicaciones. Al ser el Modelo Ejecutable en el que se va a expresar el componente de control de las aplicaciones construidas en Cumbia, se hace necesario la evaluación de la expresividad del lenguaje a este nivel, para esto se utilizan los patrones de flujo descritos en el articulo “Workflow Patterns”, tal como se mencionó anteriormente. En la siguiente tabla se puede notar que el lenguaje le da soporte directo a once de los patrones, uno por medio de una adaptación y a ocho por medio de especializaciones: Patrones de Control Básico Secuencia Soporte Directo División en Paralelo Soporte Directo Sincronización Soporte Directo Selección Exclusiva Especialización Convergencia Directa Soporte Directo Patrones de Sincronización y Divergencia Avanzada Selección Múltiple Especialización Convergencia Sincronizada Especialización Convergencia Múltiple Soporte Directo Discriminador Adaptación Patrones Estructurales Ciclos Arbitrarios Soporte Directo Terminación Implícita Especialización Patrones que Involucran Múltiples Instancias Múltiples Instancias sin Sincronización Especialización Generación de Múltiples Instancias conociendo el número de instancias en tiempo de diseño

Soporte Directo

Generación de Múltiples Instancias conociendo el número de instancias en tiempo de ejecución (While)

Soporte Directo

Generación de Múltiples Instancias conociendo el número de instancias en tiempo de ejecución (For)

Soporte Directo

Patrones Basados en Estados

31

Decisión Diferida Especialización Ruta Paralela Interpolada Especialización Milestone Especialización Cancelación Cancelación de una Actividad Soporte Directo Cancelación del Proceso Soporte Directo El conjunto de elementos que van a permitir el completo cumplimiento de los patrones es: Proceso El proceso es elemento que tiene en su

interior los elementos del lenguaje para que se ejecuten en el orden dado. Al proceso principal se le denomina root y este puede tener en su interior otros procesos.

Multiactividad Es un elemento que representa una actividad que se va ejecutar múltiples veces en paralelo, es decir, se activan al mismo tiempo.

Actividad “Es el elemento que representa un paso en la definición del proceso”. Es decir es una tarea que ejecuta un participante del proceso. Este elemento esta compuesto por un conjunto de puertos, que pueden ser de entrada o salida y un workspace.

Workspace “Es un elemento que permite la comunicación entre la actividad en espera y el mundo exterior del proceso”. Es decir, es el elemento que está dentro de una actividad y es la encargada de hacer una tarea asociada con esta actividad.

Puerto “Es el elemento que identifica el principio o final de un proceso, una

32

actividad o una multiactividad”. Los puertos van a tener un conjunto de variables o tokens que están esperando, la llegada de todos estos, habilitan la actividad, proceso o multiactividad a la que pertenecen.

Dataflow Un dataflow es el elemento que va conectar un puerto de salida de una actividad

Tabla 9. Elementos Cumbia-XPM

Finalmente, se va mostrar un ejemplo de la descripción de un proceso en XPM, donde se describe la elaboración de una tesis en la cual el primer paso es la codificación de la misma, a partir de esta primera codificación, se escribe el documento, en paralelo a esta tarea se revisa el código y se corrigen los defectos. Una vez se haya terminado de corregir los defectos se ejecuta la tesis y finalmente se corrigen los defectos encontrados en la ejecución.

Figura 4. Ejemplo Cumbia-XPM

3.2.3 Cumbia XAM Una aplicación es “la implementación de diferentes requerimientos que dan una funcionalidad completa”, dentro del contexto Cumbia, cada aplicación puede ser dividida en diferentes modelos ejecutables, quienes se sincronizan y articulan para lograr el objetivo final. Por ejemplo, dentro de una aplicación donde se describen el orden de las tareas y su respectivo responsable, deben existir dos dominios, (1) el

33

dominio de control de flujo de las actividades, (2) el dominio de recursos. Además, dentro de esta división existe correspondencia entre los diferentes elementos de los dominios, es decir, para cada actividad que está en el dominio de control debe existir varios responsables y por ende se hace necesario hacer conexiones a este nivel. De esta necesidad de tejido, nace XAM que viene del acrónimo Extensible Application Modeling y es un modelo en el cual se definen los diferentes elementos y propiedades de una aplicación dividida en Modelos Ejecutables y que va permitir generar las relaciones entre los elementos de cada uno de los dominios. El modelo de aplicación de Cumbia-XAM es una definición jerárquica donde en la primera escala se tiene el modelo del dominio, este a su vez debe dar la posibilidad de crear instancias las cuales están compuestas por diferentes elementos. Dentro del tejido los modelos están divididos en dos diferentes, un observador que es donde están los elementos que van a estar monitoreando el cambio de estado del segundo tipo de dominio, los modelos observables. Volviendo al ejemplo de las actividades y responsables, cada uno de los recursos está observando a sus respectivas actividades con el fin de poder saber cuando se activan, lo que define al modelo de recursos como el observador y al de control de flujo como observable. Dentro de este modelo, el observador mantiene una referencia del observable, este elemento comunica por medio de eventos a su Observador el cambio de estado. Para establecer esta relación Cumbia-XAM, en el momento de la creación de la instancia de los modelos, ubica por medio de un identificador único a nivel de instancia el elemento observable y se lo presenta al observador, el cual también es encontrado por un identificador. Con el fin de hacer posible la presentación, los elementos del dominio observador, deben implementar la funcionalidad del elemento básico de composición, el Workitem, este tiene una acción que XAM va utilizar para presentar los diferentes modelos.

34

4. Motor de BPMN sobre Cumbia Dentro del contexto de Cumbia, como fábrica de aplicaciones de procesos, crear herramientas que cumplan con especificaciones altamente usadas, se vueve en una necesidad; en este momento, BPMN se está convirtiendo en un estándar para expresar procesos de negocio y es de aquí de donde nace la idea de Alegre, un motor que ejecuta procesos descritos en BPMN sobre Cumbia. Dado que BPMN no tiene ningún modelo que lo describa y esto juega un papel muy importante en la elaboración del motor, el primer paso que se hizo fue crearlo. Como se mencionará mas adelante, este fue creado a partir del concepto de objeto abierto, por ende, para modelar parte del comportamiento de cada uno de los elementos se crearon máquinas de estados las cuales generan eventos, lo que va permitir la futura construcción de nuevas aplicaciones sobre Alegre. El segundo paso fue definir una arquitectura donde el modelo de Alegre-BPMN cumpliera como dominio dentro de Cumbia; esto, en primera instancia para apoyarse en los otros activos y facilitar el desarrollo, para así también, como modelo de esta fábrica, permitir el enlace con otros dominios para la generación de nuevas aplicaciones.

4.1 Metamodelo Alegre-BPMN Como se mencionó anteriormente el primer paso en la elaboración del Motor fue la creación del modelo del dominio. La principal preocupación, fue contar con la estructura suficiente para expresar cualquier proceso posible dentro de este lenguaje, para ver el modelo mas detallado ir al apéndice. Sin embargo, tal como se muestra en la figura, en el momento de la implementación fue de vital importancia generarlo con los mecanismos necesarios para bajar el acoplamiento entre las clases, además crear un modelo de fácil reutilización. Esto con del fin de poder utilizar la estructura y comportamiento de los elementos propios de Alegre, pero dando la posibilidad de utilizar implementaciones propias de cada una de las aplicaciones que utilicen Alegre como uno de sus activos. Es por esto, que todos los elementos parten de ser IBPMNElement hasta llegar a la especialización del elemento concreto, tal como se muestra en la figura con el caso de BPMNSequenceConnector.

35

Figura 5. Implemetación estructura del Metamodelo de Alegre-BPMN

Todos los elementos implementan la interfaz Visitable con el fin de poder hacer las traducciones a los dominios que sean necesarios, lo que se va explicar con mayor profundidad en la sección 4.2.1, donde se habla del traductor. También es muy importante notar que el elemento BPMNAbstractElement tiene una referencia a una máquina de estados, esta es la que va modelar el comportamiento e interacción entre los elementos del lenguaje. Las máquinas de estados de los elementos son las siguientes:

36

Máquina de estados de los Procesos:

Figura 6. Máquinas de Estados del Proceso

La máquina de estados del proceso, consta de tres estados: Inactive, Active y Finís. El primero es Inactive y como su nombre lo indica, es cuando el proceso está inactivo; cuando el símil en Cumbia-XPM entra al estado activo (Active) se inserta un evento de activar y se queda en espera a tener una señal de terminación (Finish). Máquina de estados de los Pools:

Figura 7. Máquina de estados del Pool

37

La máquina de estados de los pool tiene 4 estados: Inactive, Assign Reposnsible, With responsable y Finish. El estado inicial, Inactive, el cual va cambiar en el momento que el proceso lanza el evento activar; cuando llega esta señal el pool va quedar en espera que se le asigne un responsable, una vez esto sucedo va pasar al último estado que es with responsible. Máquina de estados de los Lanes:

Figura 8. Máquina de estados del Lane

Al igual que la Pool, en principio esta en espera que el proceso se active, una vez pase esto, queda en espera que el pool lance la notificación que ya tiene un responsable para llegar al estado With Responsible. Máquina de estados de los Eventos

38

Figura 9. Máquina de estados de los Eventos

Al igual que todos los elementos, el estado inicial es Inactive y está en espera del evento en el que se activa el proceso; una vez ocurre esto, entra al estado donde la evaluación de la condición es falsa, cuando esta cambia pasa al estado en el cual se indica que es verdadera y queda en espera a que vuelva a cambiar la evaluación. Máquina de estados de los Subprocesos:

Figura 10. Máquina de estados de un Subproceso

La máquina de estados del subproceso, al igual que todos los elementos comienza en Inactive y queda en espera a que se active el proceso. En el subproceso es de vital importancia saber quien es el responsable, es por esto que el subproceso no queda en inicio hasta que el pool no notifique que ya tiene el responsable. En caso que el flujo

39

llegue a este punto y no exista un responsable, pasa a un estado en el que se intenta activar pero no tiene un responsable, una vez se asigna el responsable, pasa a Active. Cuando el Pool ha notificado que ya tiene una persona que la va realizar y no ha llegado el flujo queda iniciada y en espera a que llegue a el flujo para activarse. Una vez está activa, espera a que se termine el proceso o que la evaluación de la condición de uno de los eventos cambie a vedadero, lo que genera un paso a un estado a Condition True, se notifica el fin del flujo y vuelve al estado inicial por si el flujo vuelve a pasar por este punto. Máquina de estados de las Actividades:

Figura 11. Máquina de estados de la Actividad

La máquina de estados de la actividad es muy similar a la del subproceso, comienza en inactivo esperando a que se active el proceso, una vez tenga esto espera a que el pool al que pertenece tenga un responsable, cuando llega la noificación entra en estado inicial, el cual pasa a activo cuando llega el flujo a esta actividad, mas todos los caminos excepcionales que tiene. La gran diferencia radica en el evento para el cambio de estado Active a Init, una vez llegue la notificación de terminación pasa al siguiente estado.

40

Máquina de estados de los Gateways:

Figure 12. Máquina de estados de las Gateways

Los Gateways comienzan, al igual que todos los elementos, en Inactive, estado que va cambiar cuando el proceso lanza la señal que de activación, una vez esto ocurre, queda en el estado inicial, en el cual una vez llega el primer camino cambia al estado de sincronización, que va quedar en espera a que llegue toda la información necesaria para comenzar a hacer la divergencia del flujo. Una vez está en la divergencia del flujo espera los datos necesarios para saber cual camino tomar, a penas termine esto, pasa al estado inicial para esperar otra vez el flujo. Máquinas de estado de los Conectores

Figura 13. Máquina de estados de los Conectores

41

La máquina de estados de los conectores apenas se activa el proceso queda en espera a que control de flujo pase por el elemento, una vez esto ocurre se activa e inmediatamente después se desactiva. Los artefactos y las asociaciones debido a que son elementos netamente documentales y no tienen estados, aunque están en el metamodelo, no tienen máquinas de estados.

4.2 Arquitectura Alegre Alegre a grandes rasgos, tal como se muestra en la figura, son dos procesos que corren en paralelo, uno Cumbia-XPM y el otro Alegre-BPMN. Los eventos generados por las máquinas de estados de los elementos de Cumbia-XPM, sincronizan los estados del proceso BPMN. Por otro lado, los elementos de Alegre mantienen una referencia hacía su símil en XPM, con el fin de inyectar eventos para poder mover la máquina de estados de cada uno de estos elementos.

Figura 14. Sincronización de Modelos

Como se mencionó anteriormente, se va utilizar Cumbia-XPM como el encargado de generar los eventos necesarios para sincronizar el símil en Alegre-BPMN. Debido a

42

que estos dos modelos deben componerse, es decir, se deben generan referencias, fue necesario utilizar el activo de Cumbia que permitiera hacer este proceso, Cumbia-XAM. Se tienen que generar dos elementos, los descriptores de Cumbia-XPM y Cumbia-XAM a partir de una entrada, el proceso en Alegre-BPMN, por lo que se debe tener un elemento que los genere automáticamente, este es el traductor. Todos estos elementos van a ser almacenados en el deposito, esto con el fin de no perder la información de todos los modelos necesarios para el futuro despliegue. Finalmente, es importante tener un elemento donde se estén las definiciones del Modelo de Alegre, además de un componente donde se puedan ejecutar las instancias, es decir el kernel. Por esto la arquitectura propuesta es:

Figura 15. Arquitectura Alegre

4.2.1 Kernel El kernel es el núcleo del motor, este tiene como función subir las definiciones de los procesos, coordinar la creación de las instancias de procesos y finalmente estar evaluando constantemente los eventos. A partir de los requerimientos funcionales presentados anteriormente la arquitectura propuesta es:

43

Figura 16. Vista del Kernel

Donde tenemos los siguiente elementos: Process Space BPMN: El Process Space es el encargado de mantener las referencias a las definiciones de los procesos de BPMN y crear sus instancias. Tal como se muestra en la figura, se van a manejar dos diferentes tipos de definiciones:

Figura 17. Vista del Process Space BPMN

El primero, Alegre-Applications, son los que se parte de la definición del proceso en BPMN y se hace el despliegue desde el motor, de estas se guarda tres elementos

44

diferentes, la definición del proceso, el ApplicationSpace con el que se pueden crear instancias de la aplicación y la referencia a los InstanceSpace generadas a partir de esta definición. El segundo, Process-Definitions, son las definiciones que se despliegan desde otro modelo, de estas, tal como se muestra en la figura, se va a tener la definición del proceso y las instancias del mismo. Instance Space BPMN: Es el sitio donde se ejecuta la instancia de los procesos, en este, al igual que en el Process-Space, se divide en dos:

Figure 18. Vista del Instance Space BPMN

El Alegre Application, que es donde van a estar las aplicaciones tipo Alegre, de aquí se va tener referencia hacía la instancia que se está ejecutando y hacía el Instance Space del proceso símil en XPM. El Instance Process Definition que es la referencia referencia del proceso que se está ejecutando. Event-Holder: El event holder es un espacio del motor donde se instalan eventos con el fin de estar constantemente evaluados. Este a grandes rangos, es un Thread que está mandado la evaluación secuencialmente de los eventos.

45

4.2.2 Traductor El traductor es el elemento encargado de generar un símil del proceso BPMN en el lenguaje Cumbia-XPM, además, generar el archivo XAM para la presentación y generación de las referencias necesarias entre los diferentes modelos, finalmente, generar el archivo cumbiar con todos los elementos necesarios para poder desplegar una aplicación dentro del contexto cumbia. Para la solución de este problema se utilizó el patrón Visitor, en el metamodelo de Alegre-BPMN la interfaz de la que nacen todos los elementos (IBPMNElement) extiende la interfaz Visitable, que es la que nos va permitir que el objeto Visitor, en nuestro caso TranslatorXPM y TranslatorXAM, puedan generar los archivos mencionados anteriormente. Dado que los elementos por si solos no muestran la estructura completa de las traducciones, en primera instancia se utilizarán algunos de los patrones de workflow. Secuencia BPMN Cumbia-XPM

Tabla 10. Patrón Secuencia

Este es un patrón simple donde se muestra que el esquema de traducción de la Actividad de Alegre-BPMN es una actividad en Cumbia-XPM, el id del flujo de secuencia agregándole una ‘a’ en el principio es el token que va fluir y el nombre del puerto, aunque no se vea en la figura, es en el de salida, exit concatenado con el mismo id (exit3) y el de entrada es entry con el id (entry3). Aquí es muy importante notar que las traducciones se hacen por medio de los id, lo que permite que varías elementos tengan las mismas características, pero que sean diferentes y no exista ningún tipo de ambigüedad. División en Paralelo

46

BPMN Cumbia-XPM

Tabla 11. Patrón División en Paralelo

Al igual que en el patrón anterior, por cada actividad en Alegre-BPMN, una actividad en Cumbia-XPM. En el caso del gateway paralelo, se crea una actividad con un solo puerto de salida y con tantos tokens como conectores saliendo de este elemento. En el caso de los subprocesos, se crean dos actividades diferentes, una al principio para hacer divergencia del flujo y la otra que recibe cada flujo en un puerto diferente; esto con el fin de notificar al subproceso que llego al final uno de los caminos, sin embargo, que llegue a este punto no significa que termine, es decir, cuando hay ciclos en el

47

subproceso, el flujo puede llegar varías veces al final del camino, es por esto que cada vez que llega a uno de los caminos se notifica a la actividad y este verifica que se haya terminado, en caso que no se termina se manda abortar en la actividad que sincroniza el subproceso dejándola lista para recibir otra notificación de finalización, en el caso contrario se sigue el flujo nomal actividades que tiene el subproceso. Sincronización

BPMN Cumbia-XPM

Tabla 12. Patrón Sincronización

El símil del gateway paralelo en el momento de la sincronización, es una actividad y un puerto de entrada con el mismo número de tokens como número de conectores que llegan a este elemento. Decisión Exclusiva

BPMN Cumbia-XPM

Tabla 13. Patrón Decisión Exclusiva

Para los gateway exclusivos(XOR), el símil es una actividad con tantos puertos de salida como conectores del mismo tipo del elemento.

48

Unión Simple

BPMN Cumbia-XPM

Tabla 14. Patrón Unión Simple

En este caso, por cada conector de entrada de la actividad o del gateway exclusivo, se crea un puerto diferente. Selección Múltiple

BPMN Cumbia-XPM

49

Tabla 15. Patrón Selección Múltiple

En este caso se hace necesario hacer la combinación de los conectores de salida del gateway o de la actividad, y por cada subconjunto de la combinatoria se crea un puerto diferente. Patrones Complejos de Sincronización Los patrones complejos de sincronización, como Unión Sincronizada, Unión Múltiple y Discriminador, se logran cumplir desde Alegre evaluando las condiciones que se describen en la definición del gateway. Sin embargo, para recibir los eventos necesarios de la capa de xpm se hace la siguiente traducción: BPMN

Cumbia-XPM

Tabla 16. Patrones Complejos de Sincronización

50

Cuando se recibe un evento de llegada de flujo de alguno de los puntos se notifica al gateway en alegre, quién evalúa la condición de continuación, en caso que sea verdadero permite el paso. Patrón Ciclos Arbitrarios BPMN

Cumbia-XPM

Tabla 17. Patrón Ciclos Arbitrarios

Dado que los eventos modifican el flujo, pero dentro de los patrones no se incluyo ninguno de estos elementos se mostrarán los siguientes esquemas: Eventos Iniciales:

BPMN Cumbia-XPM

Tabla 18. Eventos Iniciales

51

Como se mencionó anteriormente estos elementos no modifican el flujo normal de las actividades, simplemente el cumplimiento de la condición del evento crea una instancia de una definición de un proceso, por esta razón se deja como una actividad adicional en XPM de la siguiente forma: Eventos Intermedios: En los eventos intermedios se presentan los siguientes dos casos:

BPMN Cumbia-XPM

Tabla 19. Primer caso de Eventos Intermedios

En la primera figura, cuando la condición del evento se cumple, el flujo debe seguir hacía la actividad 4, en el caso que la evaluación del evento sea falso, el flujo debe seguir hacía a la actividad 2 en ningún caso se toman los dos caminos, lo que lo hace semejante al patrón de Decisión Exclusiva y por ende su traducción es de esa forma. En el segundo gráfico, se puede cumplir una o las dos condiciones de los eventos, en este caso, el flujo, como se explico anteriormente, no debería seguir por el camino normal, debería salir por cualquiera de los eventos donde la evaluación de la condición

52

sea verdadero, lo que se asemeja al patrón de selección múltiple, además debe dar la posibilidad de salir por los caminos normales en caso que no se cumpla ninguna de las condiciones de los eventos, es por esto que se crea un puerto como en el patrón de división en paralelo. Es importante aclarar que solo se continua o modifica el flujo cuando la actividad está activa.

BPMN Cumbia-XPM

Tabla 20. Segundo caso Eventos Intermedios

En este caso el se frena el flujo del proceso hasta que la condición del evento sea verdadero, es por esto que la traducción del evento es una actividad. Al igual que en el caso anterior, solo se continua cuando el evento está activo. En los procesos de BPMN, las transacciones juegan un papel muy importante, el simil en XPM es de la siguiente forma: BPMN

Cumbia-XPM

53

El símil de las transacciones son cuatro actividades diferentes, la primera (1i) la que abre el subproceso, la segunda(1f) la que los sincroniza, la tercera(1m) que va lanzar el evento de terminación de una actividad con el fin de tener este dato en, finalmente la cuarta (1t) que siempre mientras este la transacción activa esta va estar igual, para que en caso que se encienda la cancelación notifique a la tercera y se active las actividades de compensación y la actividad de finalización. En la figura, el flujo normal sería el que está en negro. Los dataflows que están en verde son de notificación de terminación de la tarea. Finalmente, en el momento en el que se cancela la transacción todos los datflows rojos de las actividades que están activas dejan pasar el flujo, lo que genera que la actividad de finalización de la transacción se active, también la actividad que tiene en memoria las tareas que terminaron y por ende sus actividades de compensació Finalmente faltan el último esquema de traducción que no se ha visto es el de las actividades Ad-Hoc:

BPMN Cumbia-XPM

54

4.2.3 Protocolos Para hacer la validación de la arquitectura propuesta se presentan los protocolos: Despliegue de un Proceso

Figure 19. Protocolo de Despliegue de un proceso

Paso 0: Desplegar Proceso: Es el paso en el que se le pide al motor el despliegue del proceso. Como entrada a este paso le entra un archivo donde se describe el proceso en un xml, los ejemplos del xml están en el apéndice. Paso 1: Traducción: El Kernel le pide al traductor, generar el archivo cumbiar a partir de la descripción que viene del paso 0. Paso 2: Almacenar: Una vez se tiene el archivo cumbiar, se envía al deposito. Paso 3: Crear Aplicación XAM: Una vez se tiene el archivo en el deposito, se le entrega a Cumbia-XAM para que cree la aplicación. Paso 4: Poner aplicación en el kernel: Como respuesta a crear una aplicación, Cumbia-XAM devuelve la referencia a ApplicationSpace, una vez se tiene este elemento y la definición del proceso, se inserta en el Kernel. Paso 4.1: Se insertan los dos elementos mencionados en el paso anterior dentro del Process Space de BPMN. Paso 4.2: Se ubican únicamente los eventos que inicializan procesos y se insertan en Event-Holder.

55

Crear una instancia de un Proceso

Figure 20. Protocolo de Creación de una instancia

Paso 0: Instanciar Proceso: Se hace la petición al motor de instanciar un proceso; el id de la definición debe venir como entrada. El motor da la posibilidad de la búsqueda de estos datos. Paso 1: Búsqueda del Application Space: Con el Id del Proceso se ubica el Process Space, el cual tiene la referencia al ApplicationSpace de XAM. Paso 2: Generar Instancia por XAM: Una vez se tiene el ApplicationSpace, se le pide crear la instancia. Paso 2.1: Crear Instancia XPM: Cumbia-XAM pide la creación de una instancia del proceso XPM. Paso 2.2: Crear Instancia Alegre: Cumbia-XAM pide la creación de una instancia del proceso ALegre. Paso 2.3: Crear Referencias entre los elementos: Una vez se crean las dos instancias, XAM hace una presentación de los elementos, según lo descrito en el archivo de XAM. Paso 3: Poner la instancia en el kernel: Como respuesta a crear la instancia, se devuelve la referencia al Instance Space de XPM y la instancia de BPMN, las cuales son puestas en el Kernel. Paso 3.1: Se insertan los dos elementos mencionados anteriormente en el Instance Space de BPMN. Paso 3.2: Se ubican todos los eventos en el Model-Event.

56

5. Dominio de Tableros de Control Cumbia Dashboard Como se mencionó durante el capítulo 2, medir tiempos y movimientos en una organización es una necesidad, la posibilidad de tener esta información en el momento correcto puede ayudar al cumplimiento de las metas, es por esto que el apoyo en herramientas tecnológicas en las que se pueda tener una visión completa de los estados de los procesos se convierte en una necesidad. Sin embargo, la gran cantidad de métricas y medidas que se pueden definir sobre un proceso hace que la elaboración de un tablero de control estándar no sea suficiente. Es de aquí de donde nace Cumbia Dashboard, un Modelo Ejecutable dentro del contexto de Cumbia, el cual va permitir la elaboración rápida de Tableros de Control sobre los diferentes dominios.

5.1 Metamodelo Cumbia Dashboard El primer paso para crear un Modelo Ejecutable compuesto por Objetos Abiertos para los Tablero de Control fue crear el metamodelo:

Figura 21. Metamodelo Cumbia Dashboard

Donde tenemos que los Tableros de Control están compuestos por KPI, los cuales a su vez tienen un conjunto de datos o de información organizada jerárquicamente hasta

57

llagar a lo que se va denominar campos, que son los elementos que van a tener los valores de las variables que se están midiendo; los grupos a su vez van a mantener un conjunto de Monitores, los cuales van cambiar la información de las variables de los campos. Finalmente, los KPI tienen un diagrama asociado, y debido a que muchas veces es necesario poder ver mas dimensiones de las que soporta el tipo de diagrama, se hace necesario crear varios gráficos, los cuales pueden ser de cinco diferentes tipos (pies, barras, líneas, Velocímetros y tablas), estos gráficos a su vez están compuestas por un conjunto de elementos que según el tipo de diagrama se va especializando. Para ilustrar se va mostrar la instancia de un tablero de control donde se quiere comparar las infracciones de transito de dos diferentes grupos de personas, (1) las individuos de 16 a 40 años y (2) de 41 años en adelante, en dos barrios en la Ciudad 1 y en otros dos en la Ciudad 2. El modelo de información se vería de la siguiente forma:

Figura 22. Instancia del Modelo de Datos de Alegre Dashboars

58

Aquí se puede ver la división de los diferentes grupos hasta llegar a los elementos, quienes tienen la variable y están referenciados por los diferentes monitores. Para el ejemplo, la información se va organizar por medio de un diagrama de barras, finalmente la instancia se va ver de la siguiente forma:

Figura 23. Visualización instancia Alegre Dashboard

Donde se puede notar que cada elemento del diagrama tiene una referencia hacía los elementos de la información que se está monitoreando, esto con el fin de poder extraer los datos. Para el momento de la implementación, al igual que en el Motor Alegre, se utilizaron mecanismos de desacoplamiento y reutilización entre las clases, lo que va permitir hacer implementaciones de los diferentes elementos y sobre todo la posibilidad de utilizar Monitores propios para cada uno de los diferentes Modelos que se quieren

59

medir. Los elementos al ser Objetos Abiertos, una parte del comportamiento y de la interacción de los mismos es modelado por medio de las siguientes máquinas de estado: Maquinas de estado de los Dasboards

Figura 24. Máquina de estados de Dashboards

Este elemento tiene tres estados: Inactive, Active y Finish. Este comienza en inactive, cuando se instancia la aplicación pasa active y cada vez que uno de los elementos cambia de valor, el hace una transición notificandolo hasta que se lance una señal de finalización del monitoreo. Maquinas de estado de los elementos

Figura 25 Máquina de estados de los elementos del modelo

60

Al igual que la máquina de los Dashborads, esta tiene tres diferentes: Inactive, Active y Finish. La notificación del Tablero de control hace que cada uno de los elementos se active, estado en el cual van a estar hasta que llegue una señal de finalización.

5.2 Arquitetura Dashboard-Model Dentro de la arquitectura de Dashboard-Model se partió que hay diferentes dominios que se quieren tejer con este modelo, incluso, un mismo dominio podría tener dos diferentes formas de tejido con el mismo, es por esto que se hace necesario tener una bodega de traductores. Además se debe tener un componente que coordine el despliegue de las aplicaciones y la generación de las instancias, por esto, el modelo propuesto es:

Figure 26. Arquitectura Alegre Dashboard

5.2.1 Kernel Tal como se mencionó anteriormente, el kernel es el elemento que va coordinar la creación de instancias del modelo, además de mantener las definiciones de los diferentes Tableros de Control, y sus respectivas instancias.

61

Figura 27. Kernel Dashboard-Model

De esta forma tenemos que el kernel está compuesto por el espacio de las definiciones de los tableros de control y estos a su vez tienen las referencias de sus instancias. No obstante, dentro de las instancias que tiene el Dashboard Space, existen dos tipos diferentes, (1) las que el despliegue se hace desde el modelo y (2) las que el despliegue se hace desde el otro dominio. Tal como se ve en la figura, de las primeras se va mantener la referencia al ApplicationSpace para poder generar las instancias desde este mismo dominio.

Figura 28. Dashboard Space

62

5.2.2 Traductores Tal como se mencionó anteriormente diferentes dominios van a utilizar este modelo, es por esto que se hace necesario tener una bodega donde se tengan los diferentes generadores de los archivos necesarios para la creación de las mismas. Los traductores, es una bodega donde están los diferentes generadores de los Cumbiar y a cada extensión de archivo se declara una clase que implementa la funcionalidad de IGenerator. Esta clase va generar los archivos necesarios para la composición de los mismos.

5.2.2 Protocolos Despliegue de un Dashboard

Figure 29. Protocolo de Despliegue de un proceso

Paso 0: Desplegar Dashboard: Es el paso en el que se le pide al motor el despliegue del dashboard. Como entrada a este paso le entra un archivo donde se describe el proceso en un xml,. Paso 1: Traducción: El Kernel le pide al traductor, generar el archivo cumbiar a partir del archivo que viene en 1. Paso 2: Almacenar: Una vez se tiene el archivo cumbiar, se envía al deposito. Paso 3: Crear Aplicación XAM: Una vez se tiene el archivo en el deposito, se le entrega a Cumbia-XAM para que cree la aplicación. Paso 4: Poner aplicación en el kernel: Como respuesta a crear una aplicación, Cumbia-XAM devuelve la referencia a ApplicationSpace, una vez se tiene este elemento y la definición del proceso, se inserta en el Kernel. Paso 4.1: Se insertan los dos elementos mencionados en el paso anterior dentro del Process Space de BPMN.

63

Crear una instancia de un Dashboard

Figure 30. Protocolo de Creación de una instaciacia de un Dashboard

Paso 0: Instanciar Proceso: Se hace la petición al motor de crear una instancia de un dashboard; el id de la definición debe venir como entrada. El motor da la posibilidad de la búsqueda de estos datos. Paso 1: Búsqueda del Application Space: Con el Id del Proceso se ubica el Process Space, el cual tiene la referencia al ApplicationSpace de XAM. Paso 2: Generar Instancia por XAM: Una vez se tiene el ApplicationSpace, se le pide crear la instancia. Paso 2.1: Crear Referencias entre los elementos: Una vez se crean las instancias, XAM hace una presentación de los elementos, según lo descrito en el archivo de XAM. Paso 3: Poner la instancia en el kernel: Como respuesta a crear la instancia, se devuelve la referencia de la instancia de Dashboard-Model, las cuales son puestas en el Kernel. Paso 3.1: Se inserta la instancia en el la lista de instancias.

5.4 Implementación Alegre Dashboard La implementación como caso de éxito de Alegre Dashboard se basa en la ubicación de elementos que van a estar monitoreeand los eventos lanzados por Alegre, tal como se muestra en la figura.

64

Figura 31. Visión de Alegre-Dashboard

Para lograr este caso de éxito fue necesario desarrollar un lenguaje donde se describieran tableros de control dentro del contexto Alegre. Este lenguaje debe poder describir cualquier subconjunto de elementos, además definir sus propias variables y la visualización de las mismas. La descripción de los subconjuntos de elementos de Alegre parte de la definición de contenencía de los elementos en BPMN. En otras palabras, el lenguaje se basa en la posibilidad de ubicar y filtrar elementos a partir de la escala jerárquica que se muestra en la figura. En esta se hace natural ubicar todas las actividades que contiene un pool en particular.

65

Figura 32. Escala Jerárquica Alegre-BPMN

Una vez se describen el subconjunto de actividades que se quiere monitorear, se hace necesario definir cuales van a ser los Monitores que se van a ubicar. Estos monitores, juegan dos roles diferentes, (1) elementos que oyen los eventos generados por las máquinas de estados de los elementos de BPMN y (2)Monitores dentro del contexto. Finalmente para hacer el recorrido del proceso y ubicar los diferentes elementos, fue necesario hacer utilidad de la implementación del patrón Visitor que tenía el metamodelo de Alegre-BPMN. En este caso se implemento la interfaz Visitor y este navega el modelo y extrae los elementos necesarios.

66

6. Conclusiones Se construyo un motor que ejecuta procesos descritos en BPMN que soporta todos los elementos de este lenguaje, dándole semántica de modelo ejecutable a un lenguaje de propósito específico, lo que genera todos los mecanismos de extensibilidad que este concepto propone. Para esto fue necesario:

• Diseñar un metamodelo en el que se pudiera representar las posibles instancias de los procesos descritos en este lenguaje. Dentro de este metamodelo fue necesario utilizar el paradigma de Objetos Abiertos, lo que obligo a crear máquinas de estado que describieran subconjuntos de valores presentes en sus atributos.

• Crear un formato xml estándar en el cual se pudieran describir las diferentes

instancias que el lenguaje propone.

• Generar transformaciones partiendo de la descripción del proceso en BPMN y llegar a Cumbia-XPM y Cumbia-XAM, lo que va traer como conclusión un motor con un componente de control experto que se va poder adaptar a nuevas y diferentes estructuras de esta área de la aplicación.

Se construyo un dominio dentro de Cumbia para el monitoreo de los diferentes dominios de esta familia de aplicaciones. Para la creación de este dominio fue necesario:

• Diseñar un metamodelo donde se pudieran describir diferentes tipos de información, además de tener la visualización automática de esta información. Este metamodelo fue elaborado a partir del paradigma de Objetos Abiertos, lo que da la posibilidad de tener los diferentes mecanismos de extensibilidad, tal como se mencionó anteriormente.

• Crear un lenguaje donde se pudiera describir las diferentes formas de

agrupación de la información, además de la forma en que se va visualizar.

67

Con la contrucción de este modelo se comprobó la flexibilidad de la arquitectura de Alegre, además de la adaptabilidad de Dashboard-Model.

68

Apendice Modelo Alegre-BPMN

Figura 33. Modelo Alegre BPMN

69

Archivo Alegre-BPMN

Figura 34. Archivo Alegre-BPMN

Archivo de visualización Cumbia-Dashboard

Figura 35. Archivo Visualización Cumbia-Dashboard

70

Archivo de grupos Cumbia-Dashboard

Figura 36. Archivo Cumbia-Dashboard

Archivo Alegre-Dashboard

Figure 37. Alegre Dashboard

71

Bibliografía [1] OMG (Object Management Group) “Business Process Modeling Notation (BPMN) Specification”. 1 de Febrero de 2006. [2] Stephen A. White, “Process Modeling Notations and Workflow Patterns”, IBM Corp., United Status. [3] Stephen A. White, “BPMN Fundamentals”, OMG PM ABSIG Meeting, Burlingame – December 8, 2005 [4] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, A.P. Barro, “Workflow Patterns”, 2002. [5] Enterprise Workflow National Project, “What is workflow?” [En línea]. Disponible: http://www.workflownp.org.uk/content/whatisworkflow.pdf. 2003 [6] Robert Kaplan, David Norton, “The Balanced Scorecard – Measures that drive performance”, Havard Business Review, enero/febrero del 1992. [7] Shadam Malik, “Enterprise Dashboards, design and best practice for it”, John Wiley & sons, Inc. 2005. [8] Gartner Inc, N. Rayner “CPM: A Strategic Deployment of BI Applications”, 2002. [9] Gustavo López, “Metodología Six-Sigma: Calidad Industrial”. [10] Wohed, P.; VanderAlst, W.; Hofstede,A. y Russel, N. En: Proceedings of the International Conferencce on Business Process Management(BPM), Spinger-Verlag, 2006. [11] Russel, N.; Hofstede, A.; Edmond, D. y VanderAlst, W.: «Workflow Data Patterns». Informe técnico, FIT TR- 2004-01,Queensly University of Technology, 2004. [12] Juan Diego Pérez Jiménez, Amador Durán Toro, Antonio Ruiz Cortés, ¿Por qué OMG ha elegido BPMN para modelar de Procesos de Negocio si ya existe UML? [13] VanderAlst, W.; Hofstede, A.; Kiepuszewski, B. y Barros, B.: “Workflow Patterns. Distributed y Parallel Databases”, 2003. [14] Jason Kuo, “Management Dashboards, Enabling Performance Management across the Enterprise”. [15] Standish Group, “The Chaos Report (1994)”, disponible en línea en: http://www.standishgroup.com/sample_research/chaos_1994_1.php [16] Javier Garzás, Mario Plattini, “Conceptos y evolución de las fábricas de Software”, Disponible: http://www.kybeleconsulting.com/pages/articulos/ConceptFabricasSoftware.html

72

[17] Keith Jack Greenfield, “Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools”, John Wiley & Sons © 2004. [18] Jorge Villalobos, Mario Sánchez, Daniel Romero, “Executable Models as Composition Elements in the Construction of Families of Applications”. [19] Pablo Barvo, Mario Sánchez, “Construcción de una línea de producción de motores de workflow basada en modelos ejcutables”. [20] M. Muñoz. (2005). “Modelamiento de Procesos de Desarrollo de Software”. [En línea].Disponible:http://qualdev.uniandes.edu.co/wiki/dok.php?id=development:research:spem [21] Dario Correal, “Definition and Execution of Multiple Viewpoints on Workflow”, Tesis doctoral, Uniandes 2007. [22] Camilo Jiménez “Composición de modelos ejecutables extensibles en una fábrica de aplicaciones basadas en workflows”. Tesis de Maestría, Uniandes 2007. [23] Daniel Romero “Modelos Ejecutables Extensibles como Activos en una Fábrica de de Motores de Workflow: Caso BPEL”. Tesis de Maestría, Uniandes 2007. [24] Jorge Villalobos, Silvia Takahashi, Dario Correal, Carlos Noguera, Rubby Casallas, Jaime Lozano, Gabriel Pedraza, David Murillo, Pablo Barvo, Mario Sánchez, Alex Chacón. “Cumbia-XPM: Cumbia Extensible Process Modeling”. [25] Jorge Villalobos, Mario Sánchez, Pablo Barvo, Daniel Romero, “Cumbia-XAM: Cumbia Extensible Application Modeling”, 2007.