Tutorial Interactivo de BPMN 2

Tutorial interactivo de BPMN

Bienvenido al tutorial interactivo de BPMN v2.0

Objetivos:

Con esta guía tenemos la intención de introducirte en el modelado de procesos de negocio gracias a tres aspectos: contenido teórico, buenas prácticas y ejercicios de apoyo.

Guía de contenidos:

BPMN 2.0: Un paseo por la notación BPMN que debería permitir empezar a modelar procesos de negocio. Patrones y antipatrones: Una presentación de los patrones de uso más frecuente de flujo de trabajo. Ejercicios: Una serie de ejercicios de desarrollo, para poner en práctica tu conocimiento de BPMN. Tests: Exámenes con preguntas cortas y varias posibles respuestas sobre contenido teórico. Descargas: Material adicional para sacar mayor provecho a la web. Enlaces: Páginas web con contenidos de interés.

Usted está en: Tutorial BPMN

Bienvenido al Tutorial de modelado BPMN 2.0

Este tutorial explica los fundamentos teórico-práct icos del estándar de notación BPMN. Está organizado en capít ulos en el cual, cada uno de ellos, profundiza en la comprensi ón de un elemento de modelado específico de esta notación. U na vez completado, podrá modelar utilizando la notación BP MN un proceso de negocio complejo.

ÍNDICE

• Capítulo 0: Introducción y Manejo • Capítulo 1: Eventos • Capítulo 2: Actividades • Capítulo 3: Nodos • Capítulo 4: Swimlanes • Capítulo 5: Conectores de Objetos • Capítulo 6: Datos • Capítulo 7: Artefactos • Capítulo 8: Coreografías • Capítulo 9: Conversaciones

Usted está en: Tutorial BPMN > Capítulo 0

Capítulo 0: Introducción y Manejo

Este capítulo tiene como objetivo mostrar el manejo del tutorial especialmente en el tratamiento de la navegación en tre las páginas de un capítulo. Así mismo, se dan unas pequeñas noc iones sobre las organizaciones que sustentan los diagramas BPMN así como la historia y evolución del mismo.

Índice del capítulo

1. Manejo del tutorial 2. El OMG 3. Los diagramas BPMN 4. Tipos de diagrama BPMN

1. Procesos de Negocio privados 2. Procesos públicos 3. Colaboraciones 4. Coreografías 5. Conversaciones


Los diagramas BPMN

Los diagramas BPMNespañol, Notación para el Modelado de Procesos de N egocio), han sido desarrollados como un estándar por el principal de los diagramas sea entendible por todos los elementos responsables de un negocio, desde los analistas que crean los primeros borradores del proceso, hasta los desarrolladores técnicos respons ables de la implementación de la tecnología que realizará estos procesos, y finalmente, los usuari os finales que serán los encargados de gestionarlos y monitorizarlos. Así, un diagrama BPM N tiende un puente estandarizado para el vacío existente que se suele crear entre los diseños de los procesos de negocio y la i mplementación que se hace de dichos pro

Origen del BPMN

La organización BPMIdesarrolla la herramienta Language , como un lenguaje de ejecución de procesos cuenta de la necesidad de implementar una represent ación gráfica. Posteriormente, BPMLProcess Execution Languageejecución.

• Agosto, 2001: Se forma un grupo de trabajo, el Working Group , compuesto por 35 organizaciones, compañías y personas individuales, que empiezan a elaborar el primer borrador del BPMN.

• Mayo, 2004: Se libera al público la especificación • Junio, 2005: BPMI• Febrero, 2006: Se adopta el

OMG. • Febrero, 2008: Se libera al público la especificaci ón • Enero, 2009: Se libera al público la especificación

Capítulo 0 > Los diagramas BPMN

BPMN, Business Process Modeling Notationespañol, Notación para el Modelado de Procesos de N egocio), han sido desarrollados como un estándar por el OMG. El objetivo principal de los diagramas BPMN es la de proveer una notación que

todos los elementos responsables de un negocio, desde los analistas que crean los primeros borradores del proceso, hasta los desarrolladores técnicos respons ables de la implementación de la tecnología que realizará estos procesos, y

os finales que serán los encargados de gestionarlos y monitorizarlos. Así, un diagrama BPM N tiende un

para el vacío existente que se suele crear entre los diseños de los procesos de negocio y la i mplementación que se hace de dichos pro cesos.

BPMI, Business Process Management Initiativedesarrolla la herramienta BPML, Business Process Modeling

, como un lenguaje de ejecución de procesos XMLcuenta de la necesidad de implementar una represent ación gráfica.

BPML fue reemplazado por BPEL, Business Process Execution Language , como el lenguaje destino para

2001: Se forma un grupo de trabajo, el Notation , compuesto por 35 organizaciones, compañías

y personas individuales, que empiezan a elaborar el primer borrador del BPMN. Mayo, 2004: Se libera al público la especificación BPMN

BPMI forma parte y es mantenido por el Febrero, 2006: Se adopta el BPMN 1.0 como un estandar del

Febrero, 2008: Se libera al público la especificaci ón BPMNEnero, 2009: Se libera al público la especificación BPMN

Business Process Modeling Notation (en español, Notación para el Modelado de Procesos de N egocio), han

. El objetivo es la de proveer una notación que

todos los elementos responsables de un negocio, desde los analistas que crean los primeros borradores del proceso, hasta los desarrolladores técnicos respons ables de la implementación de la tecnología que realizará estos procesos, y

os finales que serán los encargados de gestionarlos y monitorizarlos. Así, un diagrama BPM N tiende un

para el vacío existente que se suele crear entre los diseños de los procesos de negocio y la i mplementación

Business Process Management Initiative , Business Process Modeling

XML y se da cuenta de la necesidad de implementar una represent ación gráfica.

Business , como el lenguaje destino para

Notation , compuesto por 35 organizaciones, compañías

y personas individuales, que empiezan a elaborar el primer

BPMN 1.0. forma parte y es mantenido por el OMG.

como un estandar del

BPMN 1.1. BPMN 1.2.

• Enero, 2011: Se libera al público la especificación BPMN 2.0.

¿Qué es un diagrama BPMN?

Es una notación basada en diagramas de flujos que p ermiten modelar los procesos de negocio de una organización , entendiendo por proceso de negocio toda descripción que permita descubrir como un negocio persigue sus objetivos. Esto es, un proceso de negocio es la captura de una secuencia ordenada de actividades e información suplementaria asociada que permite culm inar con éxito el fin de un hito u objetivo importante del negocio .

El ejemplo que a continuación se expone es un proce so de negocio privado muy simple y básico en el cual se e specifica las acciones que se han de realizar ante una petición d e un solicitante de crédito.

Son varias las ventajas que presenta el BPMN frente a otras técnicas que permiten modelar procesos de negocio, como los diagramas de actividad o los casos de uso de negoci o:

• Surge del acuerdo entre múltiples herramientas de m odelado de diferentes empresas, que tenían su propia (e inc ompatible) notación, para usar una única, común y estandarizad a notación. Esto repercute en un menor tiempo de form ación y un mayor entendimiento del usuario final.

• Soporta un mecanismo para generar procesos de negoc ios ejecutables (a través del lenguaje BPEL) desde una capa superior, la notación del nivel de negocio. Esto ev ita la aparición de problemas debido a malas interpretacio nes por errores humanos o la traducción a otros lenguajes.

• En el contexto de la Ingeniería del Software, permi te mejorar la etapa de elicitación de requisitos al proveer una n otación

entendible tanto para los profesionales del negocio como del equipo responsable del análisis.

Usted está en: Tutorial BPMN > Capítulo 0 > Tipos de diagrama BPMN

Tipos de diagrama BPMN

El modelado de Procesos de Negocio se usa para comu nicar una gran variedad de información a una amplia variedad de audiencias. La notación BPMN está diseñada para cubrir varios t ipos de modelado y permite la creación y especificación de Procesos de Negocio desde que éste se inicia hasta que concluye . Los elementos de modelado de la notación BPMN (que será n vistos más adelante) permiten al lector distinguir fácilmente entre las secciones de un diagrama BPMN. Hay tres tipos básicos de sub- modelos soportados actualmente en la versión 2.0 de BPMN:

1. Procesos (también llamado orquestaciones), inclu yendo: o Procesos de Negocio privados (internos) o Procesos públicos (nótese que los Procesos públicos no

vienen seguidos de de Negocio) 2. Coreografías 3. Colaboraciones, que pueden incluir Procesos y/o Coreografías

o Conversaciones, una descripción particular de una Colaboración.

En siguientes apartados, se irá profundizando y ana lizando en detalle cada uno de estos modelos.

Usted está en: Tutorial BPMN > Capítulo 0 > Tipos de diagrama BPMN > Procesos de Negocio privados

Tipos de diagrama BPMN. Procesos de Negocio privado s.

Los Procesos de Negocio privados son aquellos que s on internos dentro de la propia organización. Por ello, también suelen ser conocidos como workflow o, dentro del área de servicios Web, orquestaciones de servicios.

Si se utiliza el modelado mediante swimlanes (por ejemplo, en los diagramas de tipo Colaboración, que serán vistos má s adelante), entonces el Proceso de Negocio deberá estar conteni do en una única calle. El flujo del proceso estará así mismo contenido dentro de la calle y no podrá cruzar la frontera de la cal le. Únicamente, el

flujo de mensajes podrá cruzar la frontera para mos trar las interacciones existentes entre diferentes Procesos de Negocio privados.

El siguiente diagrama representa un Proceso de Nego cio privado no contenido en ninguna calle.

Usted está en: Tutorial BPMN > Capítulo 0 > Tipos de diagrama BPMN > Procesos públicos

Tipos de diagrama BPMN. Procesos públicos.

Un Proceso público representa la interacción entre un Proceso de Negocio privado y otro Proceso. Sólo aquellas Actividades que se utilizan para comunicarse con el otro participante se incluyen en el Proceso público. El resto de actividades internas d el Proceso de Negocio privado no se muestran en el Proceso públic o. De este modo, el Proceso público modela el sentido y orden del flujo de mensajes necesario para interactuar con el Proceso.

Dado que no se describe la naturaleza interna del P roceso del otro participante, habitualmente suele denominarse a los Procesos públicos como abstractos (denominación utilizada en BPMN 1.2).

Usted está en: Tutorial BPMN > Capítulo 0 > Tipos de diagrama BPMN > Colaboraciones

Tipos de diagrama BPMN. Colaboraciones.

Una Colaboración describe la interacción entre dos o más Procesos independientes. Usualmente suele estar mod elado por dos o más Calles, representando a los diferentes pa rticipantes. El intercambio de mensajes entre ellos se representa m ediante Flujos de Mensaje que conectan dos Calles (o los objetos c ontenidos en ellos) y suelen llevar asociado un texto descriptiv o.

Usted está en: Tutorial BPMN > Capítulo 0 > Tipos de diagrama BPMN > Coreografía

Tipos de diagrama BPMN. Coreografías.

Una Coreografía es la definición gráfica del compor tamiento esperado entre diferentes participantes que interac túan entre sí. Mientras que un Proceso normal está contenido dentr o de una Calle, una Coreografía existe entre dos o más Calles.

La apariencia de una Coreografía es similar a la de un Proceso de Negocio privado , en el sentido de que consiste en una inter-conexión de Actividades , Eventos y Nodos. Sin embargo, una Coreografía es diferente a aquél en varios sentidos . Por ejemplo, la

actividad de la Coreografía son interacciones que r epresentan el intercambio de un conjunto de Mensajes, en el que s e ven involucrados dos o más Participantes.

Usted está en: Tutorial BPMN > Capítulo 0 > Tipos de diagrama BPMN > Conversaciones

Tipos de diagrama BPMN. Conversaciones.

Un diagrama de Conversación es una descripción info rmal de un diagrama de Colaboración. Por ello, las Calles de u na Conversación no suelen mostrar, aunque se puede, la naturaleza i nterna de cada Proceso que describen. El objeto de estudio de un d iagrama de Conversación es la relación lógica que existe entre ellos. Por ejemplo, en un proceso de venta, la relación lógica que modelaría un diagrama de Conversación sería el objeto o bien que se desea adquirir, sin importar demasiado el Proceso interno que pueda seguir tanto el participante Vendedor como la Tiend a.

El siguiente ejemplo muestra un diagrama de Convers ación de Envío y Entrega del que forman parte una gran varie dad de participantes.


Capítulo 1: Eventos

Este capítulo tiene como objetivo explicar el funci onamiento de un elemento de modelado concreto, los Eventos. Se most rará cómo funcionan, cómo se conectan, de qué tipos hay y sus símbolos asociados. Todo proceso de negocio que quiera model arse con un diagrama BPMN debe empezar con un Evento, de ahí el hecho de que este tutorial se inicie explicando este símbolo .


1. Introducción 2. Evento de Inicio

1. Conectando Eventos de Inicio 2. Comportamiento de los Eventos de Inicio 3. Evento de Inicio Simple 4. Evento de Inicio Mensaje 5. Evento de Inicio Temporizador 6. Evento de Inicio Error 7. Evento de Inicio Escalable 8. Evento de Inicio Compensación 9. Evento de Inicio Condicional 10. Evento de Inicio Señal 11. Evento de Inicio Múltiple 12. Evento de Inicio Paralelo Múltiple 13. Procesos con más de un Evento de Inicio 14. Evento de Inicio Opcional

3. Evento Intermedio 1. Conectando Eventos Intermedios 2. Comportamiento de los Eventos Intermedios 3. Evento Intermedio Simple 4. Evento Intermedio Mensaje 5. Evento Intermedio Temporizador 6. Evento Intermedio Error 7. Evento Intermedio Escalable 8. Evento Intermedio Cancelación 9. Evento Intermedio Compensación 10. Evento Intermedio Condicional 11. Evento Intermedio Enlace 12. Evento Intermedio Señal

13. Evento Intermedio Múltiple 14. Evento Intermedio Paralelo Múltiple 15. Uso de los Eventos Intermedios

4. Evento de Fin 1. Conectando Eventos de Fin 2. Comportamiento de los Eventos de Fin 3. Disparadores conocidos para Eventos de Fin 4. Evento de Fin Terminación

5. Resumen de Eventos 6. Fin del Capítulo

Usted está en: Tutorial BPMN > Capítulo 1 > Introducción

Introducción

Un Evento es algo que sucede durante el curso de un Proceso, afectando al flujo de ejecución por defecto del mis mo y usualmente lleva asociado un disparador y un resultado . Esta definición es lo suficientemente general que puede llegar a cubrir m uchos elementos dentro de un Proceso: El inicio o fin de una Actividad, el cambio de estado de un documento, la recepción de u n mensaje… todo esto podría ser considerado un Evento. Sin emb argo, BPMN tiene restringido el comportamiento de los mismos p ara incluir únicamente a aquellos tipos que afectarán la secuen cia o la temporización de una Actividad en un Proceso. Un Ev ento puede, por tanto, iniciar, retrasar, interrumpir o finaliz ar el flujo del Proceso.

El símbolo asociado a un Evento es un círculo abier to. El número y grosor de las líneas indica el tipo de Evento que se trata. Atendiendo a este criterio se distinguen tres tipos de Eventos:

1. Evento de Inicio: Indica el comienzo de un Proce so de Negocio.

2. Evento Intermedio: Ocurre entre un Evento de Ini cio y otro de Fin.

3. Evento de Fin: Indica el fin de un Proceso de Ne gocio.

En la actual versión de BPMN, la 2.0, se soporta un nuevo tipo de Evento denominado No Interruptible. Se tratará con más detalle en posteriores secciones del capítulo. Basta con saber , por ahora, que

es un tipo de Evento que no afecta al flujo del Pro ceso pero sí tiene otros efectos.

Aparte de los tipos listados anteriormente, un Even to puede tener el siguiente comportamiento:

1. Captura (o recibe ) un disparador. Todos los Eventos de Inicio y algunos Intermedios tienen este comportamiento.

2. Lanza (o produce ) un resultado. Todos los Eventos de Fin y algunos Intermedios tienen este comportamiento. El resultado de un Evento productor será eventualmente capturado por un Evento receptor.

Las próximas secciones explican estos tipos de Even tos y van mostrando las diferentes opciones que están disponi bles en cada uno.

Evento de Inicio

Un Evento de Inicio indica el punto donde comienza un Proceso y el flujo de ejecución del mismo. El símbolo asociad o a este tipo de Evento es un círculo abierto cuyo límite viene defi nido con una única línea de trazo fino.

El comienzo de un Proceso puede ser natural, entend iéndose como natural que no necesita de ningún elemento par a iniciarse o bien, puede requerir de alguna circunstancia extern a al propio Evento para que éste se active. Esto es, el Evento necesita un disparador para activarse. Ésta es la razón por la que existe n diferentes tipos de Eventos de Inicio que indiquen los diferentes elementos que pueden llegar a disparar el inicio de un Proceso. Estos elementos, que bien pueden ser un mensaje o u n temporizador, es lo que se conoce en la terminologí a de BPMN, disparador . El hecho de que el símbolo asociado a un Evento s ea un círculo abierto es para que en su interior pueda de clararse el tipo de disparador que activa el Evento.

Con cada nueva versión de BPMN se van habilitando m ás y más posibles disparadores para poder modelar de manera más eficiente

las diferentes situaciones. En la versión 1.1 había 6 posibles disparadores. En la versión actual, la 2.0, el núme ro alcanza ya los 10 elementos.

• Simple: El Evento no lleva asociado ningún disparad or. • Mensaje: El disparador es un mensaje que se recibe desde

otra entidad o participante en el Proceso. • Temporizador: El disparador es una fecha y hora específico o

bien un intervalo que se cumple regularmente (por e jemplo, todos los viernes de julio).

• Error: El disparador es una condición de error que viene definida por la excepción producida en la ejecución de otro Proceso.

• Escalable: El disparador es una condición de apropiación que implica la ejecución del Proceso por una entidad de mayor responsabilidad.

• Compensación: El disparador es una condición de compensación para la cancelación de una Actividad y a realizada.

• Condicional: El disparador es una condición que debe ser cierta para activar el Evento.

• Señal: El disparador es una señal que se difunda desde otro proceso.

• Múltiple: El disparador es un conjunto de los definidos anteriormente.

• Paralelo Múltiple: El disparador es un conjunto de los definidos anteriormente.

En las siguientes secciones se irá definiendo y exp licando con detenimiento cada uno de estos disparadores.

Conectando Eventos de Inicio

La conexión de Eventos de Inicio, aún no habiendo i niciado aún el Capítulo de Conectores de Objetos, es muy simple de entender puesto que la única restricción que existe es que s ólo tienen Flujos de Secuencia de salida . No se permite que los Flujos de Secuencia se conecten a un Evento de Inicio debido a que éste representa el inicio de un Proceso.

A continuación tiene la versión incorrecta y correc ta de conexión de Eventos de Inicio.

En el segundo caso, a pesar de que la Tarea es posi ble que se realice más de una vez no se reinicia todo el Proce so, simplemente se itera sobre la Tarea Diseñar y Ejecutar Prueba.

Si lo que se desea es reiniciar todo el Proceso, es to es, desde el Evento de Inicio, la solución pasa por finalizar el Proceso actual y activar posteriormente el Evento de Inicio. Se esta ría creando una nueva instancia del Proceso.

Comportamiento de los Eventos de Inicio

Antes de explicar el comportamiento asociado a los Eventos de Inicio, hay que definir previamente el concepto de token . Un token refleja el punto exacto dónde se encuentra el flujo de ejecución de un Proceso. Este elemento, que en los siguientes di agramas será descrito mediante una flecha, servirá al lector com o guía para comprender el comportamiento de los Eventos de Inic io y los siguientes elementos de modelado que se definan.

Como se explicó cuándo se introdujo el concepto de Evento de Inicio, éstos son los que generan el flujo inicial de un Proceso. Un Evento de Inicio crea, por tanto, un token .

Una vez activado el Evento y el token generado, éste inicia el flujo del Proceso avanzando por el Flujo de Secuencia de salida.

Evento de Inicio Simple

Se define un Evento de Inicio de tipo Simple cuando no tiene asociado ningún disparador . El uso más común que se realiza de él es cuándo en el Proceso que se desea modelar no vie ne especificada ninguna causa que lo active. Su símbol o asociado es el mismo que el de Evento de Inicio.

Evento de Inicio Mensaje

Este tipo de Evento sirve para iniciar un Proceso t ras la recepción de un disparador de tipo Mensaje. Mensaje debe ser entendido aquí en sentido amplio: recepción de una notificación ad ministrativa, recepción de una carta, una llamada de teléfono… To do aquello que implique un intercambio directo entre dos participantes del Proceso es un Mensaje. Estos participantes que aquí se nombran deben estar en Calles diferentes (se volverá a esto en ot ro capítulo.

Su símbolo asociado es un marcador con forma de sob re dentro del símbolo de Evento.

También existe el tipo No Interruptible para este t ipo de Evento. Se diferencia del Evento de Mensaje en que el borde de l círculo está hecho a trazos. Se volverá a explicar este símbolo en el capítulo que versa sobre las Actividades. Basta por ahora con sa ber cuál es el símbolo asociado.

A continuación, tiene un ejemplo de un Proceso que se activa una vez que se tiene constancia de un pedido de comida.

Evento de Inicio Temporizador

Modelar una condición de tiempo en un diagrama BPMN es sumamente sencillo. Basta con utilizar el disparador Temporizador. Éste indica que el Proceso se inicia cuándo cierta condición de tiempo se cumple, ya sea una fecha y hora específic a como un periodo de tiempo que se repite regularmente.

El marcador asociado a este disparador es un reloj.

También tiene el tipo No Interruptible.

Finalmente, se muestra un ejemplo de uso.

Evento de Inicio Error

Este tipo de Evento viene asociado por la producció n de una excepción en la ejecución de otro Proceso diferente al que se está modelando. Este disparador , por tanto, suele estar asociado al modelado de rutinas de manejo de excepciones que pu eden ocurrir en el contexto de un Proceso principal y cómo deben ser resueltas correctamente.

El marcador asociado a este disparador es el de un rayo. No tiene versión No Interruptible.

Evento de Inicio Escalable

Habitualmente, las tareas de mantenimiento están je rarquizadas. Existe una unidad de desarrollo para cada tarea. Si n embargo, si aparece algún problema en una de ellas se deriva a una unidad de mayor responsabilidad. Este concepto es el que se e ncuentra tras el disparador Escalable.

Un Evento de Inicio de tipo Escalable implica que e l contexto de ejecución del Proceso se sigue ejecutando en un niv el mayor de prioridad y responsabilidad. Su símbolo asociado es el de una flecha.

También tiene versión No Interruptible.

Evento de Inicio Compensación

Existe una alta probabilidad de que en el transcurs o de un Proceso se haya realizado una Actividad que necesit e, a posteriori, ser cancelada. Para modelar esta situación se tiene el disparador Compensación. Se utiliza para deshacer las acciones ya realizadas en una transacción abortada. Se retomará más adelan te este concepto en los siguientes capítulos.

El marcador asociado a este disparador son dos flechas contiguas apuntando a la izquierda.

Evento de Inicio Condicional

Hasta este punto, se ha visto cómo modelar Procesos que se activen una vez ocurridos instantes de tiempo, con el disparador Temporizador, o recibir una información, con el disparador Mensaje. Para el resto de situaciones con otras condiciones se tiene el disparador Condicional. Los Eventos de Inicio de tipo Condici onal representan una situación en la que cierta condició n, que se hace verdadera, activa el Proceso.

Este Evento suele activarse cuando se produce un ca mbio en los datos del Proceso. El disparador Condicional simplemente se utiliza para definir qué detalles de ese cambio en el conte xto del Proceso lo activan.

Esta condición puede estar definida mediante una ex presión, en lenguaje natural o computacional, que prueba una se rie de datos y en la que se obtiene una respuesta de Verdadero o F also. La activación del Evento ocurre cuándo esa condición s e evalúa a Verdadero. Para que pueda dispararse de nuevo el Ev ento, dicha condición debe volver a Falso y Verdadero nuevament e.

El marcador asociado a este disparador es un párrafo de texto con líneas.

También tiene una versión No Interruptible.

Se adjunta un ejemplo de uso de este Evento.

Evento de Inicio Señal

Un Evento de Inicio de tipo Señal activa el Proceso cuando recibe una señal proveniente de otro participante o Proceso. Puede parecer que es equivalente al disparador Mensaje pero tiene sutiles diferencias.

En el disparador Mensaje, remitente y destinatario son conocidos, el mensaje tiene un origen y destino. Una Señal es diferente al Mensaje, tiene un origen (aquél que la produce) per o puede tener más de un destinatario. Será éste, el destinatario, el que decida si responde o no a la Señal. Puede hacerse un símil co n una bengala. Todo el mundo que esté alrededor verá la luz de la bengala pero es decisión de cada uno acudir a la llamada o no. Es p or eso que suele utilizarse más el concepto de difusión que de envío de una Señal.

Otra diferencia con respecto al disparador Mensaje es que una Señal puede ser emitida dentro del propio Proceso y no, obligatoriamente, desde otro participante.

El marcador asociado al disparador Señal es un triángulo.


Se adjunta un ejemplo de uso de este Evento.

Evento de Inicio Múltiple

Un Evento de Inicio de tipo Múltiple encapsula a un conjunto de los disparadores definidos anteriormente. Esto es, cuando se recibe uno de los que están definidos en el disparador Múltiple, se activa el Proceso. Hay que tener en cuenta que cada disparador creará una instancia diferente del Proceso no viéndose afectad o el flujo de activaciones previas que se hayan iniciado.

El marcador asociado a un disparador Múltiple es un pentágono.


Evento de Inicio Paralelo Múltiple

Un Evento de Inicio de tipo Paralelo Múltiple es eq uivalente al anterior en el sentido de que encapsula a un conjun to de los disparadores definidos anteriormente. La diferencia entre el Evento Múltiple y el Paralelo Múltiple es que, como se ha visto, en el primero sólo se requiere que se active uno de los q ue tiene definidos. Sin embargo, para el disparador Paralelo Múltiple se requiere que todos los disparadores que tenga defin idos se activen. Una vez que esta condición se cumple, el Proceso se activa.

El marcador asociado a un disparador Paralelo Múltiple es un signo de suma abierto.


Procesos con más de un Evento de Inicio

El caso más común a la hora de iniciar el modelado de un Proceso es que sólo se necesite un Evento de Inicio, que po drá tener o no un disparador asociado. Sin embargo, no es menos habitual tampoc o que un cierto Proceso tenga que ser modelado con má s de un Evento de Inicio. Esta característica está soportad a en los diagramas BPMN pudiendo realizar cualquier combinac ión de Eventos de Inicio que se necesite, sean con o sin disparador . Modelar con más de un Evento de Inicio se necesita cuándo hay varias formas de que un Proceso se active, pudiendo cada uno empezar por un punto diferente del mismo.

Cada Evento de Inicio es independiente de los que h aya definido en el mismo Proceso. Por ello, cada vez que alguno de ellos se active generará una nueva instancia del Proceso no viéndose afectado, por tanto, las instancias previas del mis mo que se hayan ya iniciado.

Evento de Inicio Opcional

Dependiendo de la complejidad de modelado de un Pro ceso, puede prescindirse del uso de Eventos de Inicio par a modelarlo. Esto es, el uso de un Evento de Inicio es opcional y queda a cargo del modelador incluirlo en el diagrama o no. El pri mer elemento sin Flujos de Secuencia de entrada será el que inicie el flujo del Proceso y el último elemento sin Flujo de Secuencia de salida el que lo finalice.

Eso sí, el uso de Eventos de Inicio y de Fin está i ndisolublemente unido. Si no se utiliza un Evento de Inicio. entonc es no puede usarse un Evento de Fin en el diagrama y viceversa.

Si el Proceso necesita un disparador asociado de los vistos anteriormente que no sea el Simple, entonces el dia grama debe incluir obligatoriamente el Evento de Inicio con el disparador asociado.

Las buenas prácticas de modelado con diagramas BPMN recomiendan incluir siempre los Eventos de Inicio .

Evento Intermedio

Un Evento Intermedio aparece entre un Evento de Ini cio y otro de Fin. Por tanto, indica que algo sucede después de q ue un Proceso se inicia y antes de que éste haya finalizado. Su s ímbolo asociado es un círculo abierto con dos líneas de trazo fino delimitando el borde.

Los Eventos Intermedios se insertan dentro del fluj o del Proceso representando acciones y efectos que aparecen duran te la ejecución del mismo.

Al igual que los Eventos de Inicio se han ido añadi endo cada vez más disparadores de Eventos Intermedios para modelar adecuadamente las diferentes situaciones. En la ver sión 1.1 de BPMN había 9 disparadores diferentes. En la versión 2.0 el número

llega hasta los 12. Algunos son ya conocidos, otros aún no han sido explicados.

• Simple • Mensaje • Temporizador • Error • Escalable • Cancelación • Compensación • Condicional • Enlace • Señal • Múltiple • Paralelo Múltiple

El disparador Cancelación sirve para cancelar un tipo de activid ad concreta, se volverá a este evento en el siguiente capítulo. El disparador Enlace sirve para habilitar un vínculo imaginario entre dos Procesos.

La principal diferencia entre los disparadores de los Eventos de Inicio e Intermedios es que mientras que ambos pued en capturar un disparador , un Evento Intermedio también puede lanzarlos. Se estudiará su comportamiento en la siguiente sección .

Conectando Eventos Intermedios

Como se ha dicho anteriormente, un Evento Intermedi o se coloca en el flujo interior de un Proceso por lo que sólo se permite que tenga un Flujo de Secuencia de entrada y uno de salida .

Comportamiento de los Eventos Intermedios

Una vez que el token llega a un Evento Intermedio desde un Flujo de Secuencia de entrada , éste realizará alguna de estas dos acciones:

1. Esperará a un disparador que lo active. En este primer caso, se denomina un Evento Intermedio capturador . El marcador asociado a este tipo de Eventos tiene un fondo de c olor blanco, el mismo símbolo que para los Eventos de In icio dado que, como ya se ha visto, también producen una espe ra hasta que son activados.

2. Lanzará inmediatamente un resultado . Para este caso, es lo que se conoce como un Evento Intermedio lanzador . El marcador asociado, en contraposición a los Eventos que capturan, tiene un fondo de color negro. Como se ve rá más adelante, es el mismo símbolo que se utilizará para los Eventos de Fin, que también producen un resultado inmediatamente.

Por un lado, los disparadores capturados por un Evento Intermedio son:

• Mensaje. • Temporizador. • Error.

• Escalable. • Cancelación. • Compensación. • Condicional. • Enlace. • Señal. • Múltiple. • Paralelo Múltiple.

Por otro, los resultados lanzados por un Evento Intermedio son:

• Mensaje. • Escalable. • Compensación. • Enlace. • Señal. • Múltiple.

Un token que llega a un Evento Intermedio capturador esperará hasta que el disparador asociado al Evento se active. A continuación, saldrá inmediatamente de éste avanzan do por el Flujo de Secuencia de salida .

Un token que llega a un Evento Intermedio lanzador activará inmediatamente el disparador . A continuación, saldrá inmediatamente de éste avanzando por el Flujo de Se cuencia de salida .

Evento Intermedio Simple

Al igual que el Evento de Inicio Simple, un Evento Intermedio no tiene que estar asociado necesariamente a un disparador . Un Evento Intermedio sin disparador se denomina de tipo Simple.

El uso más común que se hace de él es como document ación tras finalizar una Actividad que no requiere ningún trat amiento especial, como la de alcanzar una versión programada del Proy ecto, por ejemplo. En la mayoría de las ocasiones, establecer un nombre descriptivo al Evento es suficiente.

Dado que no hay disparador asociado, una vez que el token llega a un Evento Intermedio Simple se lanza de inmediato.

Una vez activado el Evento, el token sigue circulando por el Flujo de Secuencia de salida .

Evento Intermedio Mensaje

Un Evento Intermedio de tipo Mensaje tiene, como ya se ha visto en el Evento de Inicio, un marcador con forma de so bre. Se diferencia el símbolo según sea un Evento capturador o lanzador .

Evento lanzador

Este tipo de Evento indica que se lanzará un mensaj e cuándo éste se active. Como ya se ha dicho, cuando el token alcance el Evento activará el disparador y seguirá por el Flujo de Se cuencia de salida .

Evento capturador

Este tipo de Evento indica que se capturará un mens aje. Esto es, cuando el token llegue al Evento se producirá una espera hasta que un disparador de mensaje lo capture y pueda proseguir el flujo d e ejecución del Proceso. Una vez recibido el mensaje, el token seguirá por el Flujo de Secuencia de salida .

Evento No Interruptible

Del mismo modo que con los Eventos de Inicio, los E ventos Intermedios pueden tener su versión No Interruptibl e. Basta con saber, por ahora, el símbolo asociado que es equiva lente a un Evento Intermedio capturador con el borde realizado a trazos. En posteriores capítulos se explicarán con más detalle .

Ejemplo de Uso

Evento Intermedio Temporizador

Un Evento Intermedio de tipo Temporizador tiene, co mo ya se ha visto en el Evento de Inicio, un marcador con forma de reloj.

Evento lanzador

Evidentemente, un Evento que produzca una espera de tiempo no tiene sentido. Por esto, no hay un simbolo asociado a un Evento Intermedio productor de tipo Temporizador.

Evento capturador

Cuando el token llegue al Evento se producirá una espera hasta que se cumpla la condición de tiempo especificada e n el Evento. Una vez cumplido, el token seguirá por el Flujo de Secuencia de salida .


Ejemplo de Uso

Evento Intermedio Error

Este tipo de Evento suele estar unido al concepto d e interrupción de Actividades, que aún no se ha explicado y se ret omará más adelante. Por lo tanto, sólo se mostrará el tipo de símbolo asociado.

Evento lanzador

Aunque podría suponerse que debería existir un Even to Intermedio que produjera un Error debido a una exce pción producida en el flujo del Proceso no se tiene un sí mbolo asociado a este tipo de situaciones. Esto se debe a que en el modelado BPMN una condición de Error está asociado con la termina ción inmediata del Proceso. Es por esto por lo que sólo se tienen Eventos de Fin de Error.

Evento capturador

Este Evento puede ser utilizado únicamente cuándo e s adjuntado a una Actividad y se retomará en el siguiente capít ulo.


No tiene

Evento Intermedio Escalable

Al igual que en los Eventos de Inicio, este tipo de disparador va asociado al cambio de contexto de ejecución del Pro ceso hacia un nivel mayor de responsabilidad.

Evento lanzador

Evento capturador


Evento Intermedio Cancelación

Los Eventos Intermedios de Cancelación sólo pueden capturar una transacción abortada. Dado que se trata de un c oncepto no explicado aún de una Actividad, se retomará su estu dio en el siguiente capítulo. De momento, sólo se va a mostra r su símbolo.

Evento lanzador

Del mismo modo que el Evento Intermedio de Error, s uele estar asociado con la terminación inmediata del Proceso. Ésta es la razón de que no exista símbolo productor a este tipo de Evento Intermedio.

Evento capturador


No tiene.

Evento Intermedio Compensación

Este tipo de Evento está ligado al comportamiento d e las Actividades, por lo que se explicará en el siguient e capítulo. Esta sección muestra simplemente el símbolo asociado a e ste disparador .

Evento lanzador

Evento capturador


No tiene.

Evento Intermedio Condicional

El Evento Intermedio Condicional modela una situaci ón en la cual un Proceso está detenido hasta que cierta condición lógica se vuelve verdadera. El marcador asociado a este Event o es igual que el que ya se vio para el Evento de Inicio, un párra fo con líneas de texto.

Son varios los usos dados a este Evento. De entre e llos, el que se encuentra relacionado con las Actividades se verá e n el siguiente capítulo. Aquí, se mostrará cuándo se utiliza en me dio del flujo de un Proceso.

Evento lanzador

Dado que las condiciones lógicas que se están evalu ando están predefinidas antes de modelar un Proceso en un diag rama BPMN no existe un Evento productor para este disparador .

Evento capturador

Cuando el token llegue al Evento, éste se quedará esperando hasta que la condición que establece el disparador se vuelva verdadera. Hay que tener especial cuidado al modela r esta situación, porque si la condición no se vuelve verd adera en algún momento se produce una espera indefinida en el Even to. Cuando se cumpla la condición, el token seguirá circulando por el Flujo de Secuencia de salida .


Ejemplo de Uso

Evento Intermedio Enlace

Un Evento Intermedio de Enlace sirve para conectar partes separadas de un mismo Proceso que, por cualquier mo tivo, no puede mostrarse en una única sección. Suele estar a sociado con problemas de impresión en papel de Procesos que no caben en las dimensiones y deben ser seccionados en diferentes p artes, o bien, como un mecanismo que habilita para hacer saltos de flujo de ejecución en el Proceso, al estilo de un GoTo compu tacional.

Para evitar resultados ambiguos, se recomienda etiq uetar los Eventos con el mismo descriptor . El Evento de Enlace origen es de tipo lanzador y, por tanto, produce un disparador , mientras que el destino es de tipo capturador y captura el que se ha lanzado previamente.

Evento lanzador

Evento capturador


No tiene.

Ejemplo de Uso

que es equivalente a hacer

Evento Intermedio Señal

Un Evento Intermedio de Señal difunde un disparador que será capturado en los Eventos receptores que tengan que responder a la indicación. Como ya se vio en los Eventos de Inicio con este disparador , una Señal tiene un origen conocido, aquél que origina la difusión de ésta, pero varios receptores y serán éstos los que decidan si responder o no a la petición que se les envía.

Un Evento Intermedio lanzador de este disparador difundirá la Señal y seguirá avanzando por el flujo del Proceso mientras que un Evento Intermedio capturador esperará en éste hasta que se reciba la petición.

Evento lanzador

Evento capturador


Ejemplo de Uso

Los usos que se hacen de este tipo de disparador son muy variados ya que la propia semántica del símbolo así lo permite y pueden abstraerse muchos comportamientos difíciles de modelar mediante el envío de una Señal. Se puede citar, por ejemplo:

• Ordenación de Procesos: Una vez finalizado un Proce so, difunde una Señal para que el resto siga con su flu jo de ejecución.

• Secciones críticas y condiciones de carrera: El uso de recursos compartidos que deben ser utilizados en ex clusión mutua.

• Estados de desarrollo: Puede servir como punto de información de que se ha alcanzado un punto relevan te del Proceso.

• Manejo de excepciones...

Evento Intermedio Múltiple

El Evento de disparador Múltiple es ya conocido, por haber sido estudiado en la sección de Eventos de Inicio. Se tr ata de un tipo de disparador que encapsula un conjunto de los vistos anteriorme nte.

Evento lanzador

Cuando el token llegue a un Evento Intermedio productor enviará todos los disparadores que estén definidos en él y seguirá circulando por el flujo del Proceso.

Evento capturador

Se producirá una espera en el Evento hasta que lleg ue cualquiera de los que estén definidos en él.


Evento Intermedio Paralelo Múltiple

El Evento de disparador Paralelo Múltiple es equivalente al Múltiple dado que también encapsula un conjunto de los vistos anteriormente.

Evento lanzador

No tiene. Debe utilizarse el Evento productor Múltiple.

Evento capturador

Para este disparador , y a diferencia del Múltiple, se producirá una espera en el Evento hasta que lleguen todos los que estén definidos en él.


Uso de los Eventos Intermedios

Dos son los lugares en los que se pueden utilizar l os Eventos Intermedios. Uno de ellos es dentro del flujo del P roceso para, como ya se ha visto, lanzar un disparador o esperar hasta su llegada dependiendo del tipo de Evento Intermedio que se tr ate. Otro lugar en dónde se utilizan es en el borde de las Activida des, que se explicará en el siguiente capítulo.

Esta sección indica qué disparadores pueden utilizarse en cada uno de los lugares dónde está permitido su uso.

Tipos de Eventos Intermedios en el Flujo del Proces o

• Simple • Mensaje • Temporizador • Escalable • Compensación • Condicional • Enlace • Señal • Múltiple • Paralelo Múltiple

Tipos de Eventos Intermedios anclados al borde de u na Actividad

• Mensaje • Temporizador • Escalable • Error • Cancelación • Compensación • Condicional • Señal • Múltiple • Paralelo Múltiple

Evento de Fin

Como el propio nombre indica, un Evento de Fin indi ca el final de un Proceso. El símbolo asociado a un Evento de Fin es un círculo

abierto con el trazo del borde notoriamente más gru eso que el Evento de Inicio.

Manteniendo la consistencia del modelo BPMN que ya se ha visto hasta el momento, los Eventos de Fin también tienen asociado un disparador que permita modelar adecuadamente las diferentes situaciones que puedan ocurrir en el diseño de un P roceso concreto. Un Evento de Fin siempre producirá un resultado , tenga o no un disparador asociado.

Otra característica de los Eventos de Fin es que si empre son lanzadores de resultados , en contraposición a los Eventos Intermedios que también podían capturar. Por tanto, todos los marcadores asociados a los disparadores están rellenados de color negro.

Pocas son las variaciones que se han ido realizando en los Eventos de Fin con las sucesivas versiones que se h an ido haciendo de BPMN. Si en la versión 1.1 había 8 disparadores , en la actual, la 2.0, hay únicamente uno más, 9:

• Simple • Mensaje • Escalable • Error • Cancelación • Compensación • Terminación • Señal • Múltiple

Conexión de Eventos de Fin Los Eventos de Fin tienen la misma restricción de c onexión que los Eventos de Inicio pero opuesta. Esto es, un Evento de Fin sólo puede ser conectado mediante un Flujo de S ecuencia de entrada pero no de salida .

•

Comportamiento de los Eventos de Fin

Los Eventos de Fin reflejan el fin del Proceso que se está modelando. Una vez que el token llega a un Evento de Fin se lanza el disparador que tenga asociado y a continuación se consume.

El flujo de un Proceso se termina en cuánto llega a un Evento de Fin. También hay que tener en cuenta que dentro de un Proceso puede haber definido más de un Evento de Fin por lo que es posible tener más de un hilo de ejecución que continuarán a pesar de que un token sea consumido en uno de ellos. Si el Proceso sigue teniendo algún token activo en otro hilo de ejecución, éste seguirá con vida hasta que todos hayan alcanzado algún Even to de Fin.

Disparadores conocidos para Eventos de Fin

Evento de Fin Simple

Este Evento no tiene un disparador asociado. Simplemente se consume el token cuando llegue al Evento.

Evento de Fin Mensaje

Antes de consumir el token se lanza un disparador de tipo Mensaje.

Evento de Fin Escalable

Antes de consumir el token se lanza un disparador de tipo Escalable.

Evento de Fin Error

Antes de consumir el token se lanza un disparador de tipo Error.

Evento de Fin Cancelación

Antes de consumir el token se lanza un disparador de tipo Cancelación.

Evento de Fin Compensación

Antes de consumir el token se lanza un disparador de tipo Compensación.

Evento de Fin Señal

Antes de consumir el token se lanza un disparador de tipo Señal.

Evento de Fin Múltiple

Antes de consumir el token se lanza un disparador de tipo Múltiple.

Evento de Fin Terminación

Este tipo de Evento de Fin no es conocido por lo qu e se explica a continuación. Este disparador tiene una característica importante que lo diferencia del resto. Si un token llega hasta un Evento de Fin Terminación causa la interrupción y finalización in mediata del Proceso aun existiendo otros tokens activos en el mismo.

Su símbolo asociado es un doble círculo incluido un o dentro de otro.

Resumen de Eventos

Disparador Se capturan Se producen No interruptibles

Mensaje

Temporizador

Error

Escalable

Cancelación

Compensación

Condicional

Enlace

Señal

Terminación

Múltiple

Paralelo Múltiple

Capítulo 2: Actividades

Este capítulo tiene como objetivo explicar el funci onamiento de un elemento de modelado concreto, las Actividades. Una Actividad representa una acción que se realiza en el transcur so de un Proceso. Ya se ha visto el símbolo de un tipo de Ac tividad en los ejemplos que se han ido adjuntando en el primer cap ítulo, por lo que en éste se le dará sentido semántico.


1. Introducción 2. Tarea

1. Especialización de Tareas 2. ¿Tarea o Evento Intermedio?

3. Subproceso 1. Tipos de Subproceso

4. Conectando Actividades 1. Conectando Subprocesos

5. Comportamiento de las Actividades 1. Comportamiento de los Subprocesos

6. Repetición de Actividades 7. Cancelación de Actividades 8. Atributo de Actividades

1. Atributo de Subprocesos 9. Fin del Capítulo

Introducción

Una Actividad representa el concepto principal de u n Proceso puesto que modela la realización de alguna acción que se ha de ejecutar en el mismo. Una Actividad conllevará un c ierto tiempo de ejecución para realizarla, necesitará uno o más recursos de la organización, requerirá de un algún tipo de entrada y producirá algún tipo de salida .

Dependiendo del nivel de detalle de la Actividad, s e distinguirá entre:

1. Tareas: Son Actividades atómicas . Representa el nivel más bajo de detalle presente en el Proceso.

2. Subprocesos: Son Actividades compuestas . Se pueden expandir para ver otro nivel inferior de un Proceso .

Así mismo, una Actividad puede ejecutarse más de un a vez definiendo bucles internos. Pueden establecerse de manera sencilla condiciones de repetición de varias maneras, todas ellas soportadas en BPMN y que se verán más adelante.

Tarea

Una Tarea es una Actividad atómica . Se utiliza cuando el nivel de detalle del Proceso no debe o no puede descomponers e todavía más. Esto no quiere decir que una Tarea no pueda se r compleja. Simplemente que, en el modelado del Proceso que se está creando, no se requiere definir con un nivel mayor de detall e.

Su símbolo asociado es el de un rectángulo con las cuatro esquinas redondeadas y suele describirse la acción que se realiza en ella con una sentencia en su interior.

Del mismo modo que ocurría con los Eventos y sus disparadores asociados, una Tarea puede especializarse para most rar de una

manera gráfica las diferentes situaciones recurrent es que pueden ocurrir en el modelado de un Proceso. Por ejemplo, que cierta Tarea deba ser realizada personalmente y no automatizada. Su uso está asociado para usuarios más avanzados de BPMN y exce de el contenido del tutorial por lo que sólo serán mostra dos en la siguiente sección de forma somera.

Especialización de Tareas

Tarea Simple

Una Tarea genérica representando una acción muy gen eral o frecuente. La propia descripción de la Tarea resuel ve cualquier aspecto ambiguo.

Tarea Servicio

Una Tarea que hace de enlace a alguna aplicación We b o servicio automatizado.

Tarea Envío

Una Tarea que envía un mensaje a un participante fuera del Proceso.

Tarea Recepción

Una Tarea que antes de completarse espera que le ll egue un mensaje de otro participante fuera del Proceso.

Tarea Usuario

Una Tarea cuya ejecución debe recaer en la responsa bilidad de un intérprete humano asistido, generalmente, por una a plicación Software .

Tarea Manual

Una Tarea no automática realizada por un intérprete humano fuera del flujo de control.

Tarea Regla Negocio

Una Tarea que, asistida por un motor de Reglas de N egocio, calcula el resultado dependiente de unos datos de entrada afectados por una Regla de Negocio.

Tarea Script

Una Tarea ejecutada por un Script descrito en el diagrama.

¿Tarea o Evento Intermedio?

BPMN permite modelar diferentes situaciones de muy variadas maneras, por lo cual es el modelador el responsable último de que su diseño sea coherente con el Proceso que está ana lizando.

El lector habrá podido observar que el comportamien to de las Tareas de Envío y de Recepción es equivalente al de los Eventos Intermedios lanzadores y capturadores de Mensaje.

Por lo tanto, es equivalente modelar de una forma u otra.

equivale a

Las buenas prácticas de BPMN recomiendan no mezclar ambos enfoques en

el mismo Proceso, siendo el modelador el que decida utilizar alguna de las

dos opciones.

Subproceso

Un Subproceso representa una Actividad compuesta. E sto quiere decir que una Actividad puede modelar en su interio r otro Proceso. Se tiene, por tanto, soportado de forma nativa en B PMN una estructura jerárquica de Procesos siguiendo una rel ación paterno-filial, llegando en cada Subproceso hijo a un Proce so de menor nivel de detalle y nivel abstracto.

Dos son las representaciones que se tienen de un Su bproceso.

Subproceso Colapsado

Su símbolo no es distinguible de la Tarea, un rectá ngulo con las cuatro esquinas redondeadas salvo por un signo de s uma en su parte inferior que indica que se puede expandir.

En este tipo de Subproceso no puede verse su compor tamiento interno, el Proceso que está modelando.

Subproceso Expandido

Es un Subproceso en el que puede verse los detalles internos del mismo, el Proceso que está modelando. Su símbolo es el mismo que la Tarea pero notoriamente mucho más grande par a permitir modelar cómodamente dentro de él.

Tipos de Subproceso

Del mismo modo que pasaba con la Tarea, los tipos d e Subproceso que existen en BPMN no son importantes p ara la mayoría de sus usuarios y escapa a los objetivos do centes de este tutorial. Por esto, simplemente se va a dar una peq ueña idea de cuáles son y para qué se usan.

Subproceso Embebido

Un Subproceso Embebido sólo es visible dentro del á mbito del Proceso padre . Por tanto, no está disponible para ser utilizado dentro de otros Procesos teniendo que ser, de nuevo , modelado. Por depender de su Proceso padre , éste comparte con aquél todos los datos que estén almacenados en el segundo.

Subproceso Reutilizable

El propio nombre lo indica, se trata de un Subproce so disponible para ser utilizado en el modelado de diferentes Pro cesos padre . Se trata de un Proceso que realiza una Actividad recur rente y de amplio

uso que permite modularizar y paquetizar de forma ó ptima un Proceso de mayor nivel.

Conectando Actividades

Aunque aún no se ha iniciado el capítulo dedicado a los Conectores de Objetos, basta con saber, por ahora, que una Actividad puede estar conectada con uno o más Flujo s de Secuencia de entrada y tener uno o más Flujos de Se cuencia de salida.

Los siguientes ejemplos representan diagramas BPMN correctamente conectados:

Conectando Subprocesos

Dado que un Subproceso es un tipo particular de Act ividad, hereda de éste las restricciones de conexión que he mos visto en la sección anterior. Sin embargo, también posee cierta s restricciones propias que deben ser explicadas para poder modelar lo adecuadamente.

Aplicar las restricciones de conexión vistas anteri ormente a un Subproceso Colapsado es muy sencillo dado que simpl emente hay que conectarlo con un Flujo de Secuencia.

Ahora bien, un Subproceso Expandido, en el que pued e verse el Proceso interno que está modelando, puede dar lugar a confusión a la hora de ser conectado con un Flujo de Secuencia. Existe la restricción de que un Flujo de Secuencia del Proces o padre no puede sobrepasar el límite del borde del Subproceso Expandido.

Sin embargo, existe la posibilidad de situar el Eve nto de Inicio o Fin del Subproceso en la línea que delimita el bord e del mismo, a fin de clarificar la interacción entre el Proceso padre y el hijo .

Esto, que en situaciones en las que el Subproceso t iene únicamente un Evento de Inicio o Fin carece de util idad, permite que Subprocesos con más de un Evento de Inicio o Fin pu edan ser modelados sin obtener diagramas ambiguos.

Evidentemente, la segunda solución, aún siendo los dos diagramas correctos en términos de conexión, es men os ambigua que la primera.

Comportamiento de las Actividades

Cuando el token llegue a una Actividad desde un Flujo de Secuencia de entrada indica que ésta está lista para comenzar su ejecución.

Una vez que esté dentro de la Actividad, ésta se ir á ejecutando hasta finalizar su realización.

Toda vez que la Actividad se haya realizado complet amente, el token avanzará por el Proceso siguiendo por el Flujo de Secuencia de salida .

Este comportamiento general es aplicable únicamente cuando la Actividad está conectada con un Flujo de Secuencia de entrada y otro de salida .

Si la Actividad tiene más de un Flujo de Secuencia de entrada , cada uno de ellos es independiente del resto. Esto quiere decir que

si llega un token desde uno de los flujos de entrada la Actividad está lista para ser ejecutada y se realiza. Si, posterio rmente, llega otro token desde otro flujo de entrada se creará otra instancia diferente de la misma Actividad. En BPMN se permite tener más de una instancia de la misma Actividad ejecutándose al mis mo tiempo y en diferente punto de desarrollo cada una.

Si la Actividad tiene más de un Flujo de Secuencia de salida , entonces cuando ésta termine se generará un token por cada flujo obteniendo, por tanto, más de un hilo de ejecución sobre el mismo Proceso.

Comportamiento de los Subprocesos

Del mismo modo que pasaba con las conexiones de los Subprocesos, el comportamiento de los mismos cumple con las restricciones antes descritas para las Actividades pero tienen una serie de restricciones particulares que conviene de stacar.

Tradicionalmente, cuando el flujo de un Proceso padre llegaba a un Subproceso, éste se detenía hasta que no se comp letaba el Subproceso. Esto tiene sentido con el comportamient o descrito anteriormente ya que un token no sigue circulando por el Flujo de Secuencia de salida hasta que no termina de ejecutarse la Actividad.

Sin embargo, hay ciertos modelados de Procesos en l os cuales puede ser útil en un momento puntual que un Subproc eso no interrumpa el flujo de ejecución del Proceso padre en el que está contenido. Para solucionar esto, había que hacer us o de un Patrón de construcción conocido que conseguía este objetiv o. En la versión actual de BPMN, la 2.0, esto se ha solucion ado con un nuevo concepto: Los Subprocesos de Eventos.

¿Recuerda que algunos Eventos de Inicio tenían una versión No Interruptible? Se identificaban porque su símbolo e staba hecho a trazos y se decía que iban a ser estudiados más ade lante.

Un Subproceso de Evento no es más que un Subproceso que empieza con un Evento de Inicio con un disparador asociado y que puede no interrumpir, si se desea, el flujo de ejec ución de su Proceso padre . Su símbolo asociado es el de un rectángulo con la s cuatro esquinas redondeadas y con el borde punteado .

En los siguientes ejemplos, la segunda versión que se adjunta no interrumpe el flujo del Proceso padre cuando se inicia el Subproceso Analizar Resultados, por lo que seguiría avanzando hacia la Tarea Documentar Conclusiones a pesar de e star ejecutándose aún el Subproceso Analizar Resultados.

Subproceso de Evento Interruptible

Subproceso de Evento No Interruptible

Repetición de Actividades

Dependiendo de la naturaleza del Proceso que se est é modelando, es posible que una cierta Actividad deba ser realiz ada repetidas veces. En BPMN, se tienen varias formas de realizar repeticiones de una cierta Actividad. Dos de ellas serán explicadas a continuación, dejando la última que utiliza un elemento de modela do aún no explicado, los Nodos, para el siguiente capítulo.

Bucles

Una Actividad puede calificarse con un marcador que defina gráficamente que existe una cierta condición lógica que determina la cantidad de veces que tiene que ejecutarse.

Esta condición lógica obliga a ejecutar repetidamen te la Actividad mientras tenga el valor verdadero hasta que dicha condición cambie al valor falso .

Múltiples Instancias

Aunque pueda parecer similar al anterior, tiene sut iles diferencias que deben ser explicadas. Calificar una Actividad c on el marcador Múltiples Instancias conlleva ejecutarla varias vec es pero creando instancias diferentes de la misma para cada una de ellas. Por tanto, cada ejecución tendrá su propio flujo de ejecución y sus propios datos internos.

La siguiente cuestión que debe decidir el modelador es si estas instancias de la Actividad deben ser ejecutadas par alela o secuencialmente. En las antiguas versiones de BPMN sólo estaba soportada la forma paralela. Con ello se consigue q ue todas las instancias de la Actividad se ejecuten en paralelo, a la vez. El marcador asociado son tres líneas verticales en la parte inferior de la Actividad.

La novedad que introduce la versión actual, la 2.0, es que esas instancias que se van a crear de la Actividad sean ejecutadas secuencialmente, sólo cuando se finalice una de ell as se dará paso a la siguiente. El marcador asociado son tres línea s horizontales en la parte inferior de la Actividad.

Cancelación de Actividades

En la realidad, existen muchas situaciones en las c uales se está realizando una acción que, por algún motivo externo o interno, no puede continuar. Un examen que no se termina comple tamente por falta de tiempo, una conversación que se interrumpe porque llaman a uno de los participantes… Todas estas situaciones reflejan ese concepto que se ha descrito inicialmente. Para mode lar un Proceso correctamente, hay que tener en cuenta este aspecto para habilitar un mecanismo que permita cancelar Actividades que, por cualquier motivo, lo requieran.

La forma que utiliza BPMN para manejar las excepcio nes dentro del flujo de ejecución del Proceso es toda una inno vación frente a otras herramientas de modelado. Aúna en la misma se ncillez, claridad y efectividad a la hora de modelar el Proc eso.

Como ya se ha visto, cuando se completa una Activid ad el token sigue el flujo del Proceso avanzando por el Flujo d e Secuencia de salida . Sin embargo, si ocurre la cancelación de dicha Ac tividad, el token avanza por un Flujo de Secuencia de excepción cuyo origen se encuentra en el Evento que la ha generado. Esta cancelación conlleva la finalización del flujo normal del Proce so. En ese sentido, el enfoque de BPMN de anclar un Evento Intermedio a l borde de la Actividad, denota una forma de describir el error q ue muestra el flujo anormal de ejecución de la misma de un modo m uy natural.

Este primer ejemplo muestra un Proceso que finaliza con un Evento de Error, no siendo capturado por ninguna ru tina que la maneje. Este modelado de Procesos debe evitarse en la medida de lo posible, ya que deja la responsabilidad del mane jo de la excepción a un Proceso de mayor responsabilidad que aún no se ha modelado.

Este modelo es mejor que el anterior pues encapsula las operaciones que pueden presentar un error en su eje cución en un Subproceso que puede capturar los Eventos que se la ncen.

Al igual que pasaba con los Subprocesos de Eventos, es posible que la cancelación de una Actividad no deba finaliz ar el flujo normal del Proceso que se está modelando. ¿Recuerda los Ev entos Intermedios No Interruptibles? Anclar un Evento de este tipo a una Actividad indica que la cancelación de la misma no finaliza el flujo normal del Proceso por lo que continúa con su ejecu ción.

Atributos de Actividades

Estos son conceptos que sobrepasan los contenidos d ocentes del tutorial ya que son demasiado avanzados para la gra n mayoría de los modeladores. Por tanto, sólo se definen sin ent rar en profundidad.

Actividad de Llamada

Referencia a una Actividad definida de forma global que se utiliza en el modelado del Proceso actual. Nótese que la di ferencia entre este símbolo y la Tarea es que el trazo del borde e s notoriamente más grueso.

Actividad de Compensación

Sirve para denotar Actividades que revierten lo hec ho anteriormente por otras dentro del mismo Proceso.

Únicamente pueden ir unidas a un Evento Intermedio de Compensación que esté anclado a otra Actividad. Hay que destacar que este tipo de Evento no cancela la Actividad en la que esté anclado, simplemente revierte la acción si posterio rmente se requiere.

Actividad de Llamada y Compensación

Resultado de la unión de ambos atributos.

Atributos de Subprocesos

Transacción

Una Transacción es un Subproceso que está soportado por un protocolo especial que se asegura que todas las par tes involucradas en el mismo tienen conocimiento de que debe terminar completamente.

Debe tener anclado un Evento Intermedio de Cancelac ión para deshacer las acciones ya realizadas en su interior si debe cancelarse.

Subproceso Ad Hoc

Un Subproceso es de tipo Ad Hoc cuando hay un Proce so que no tiene Tareas o se desconoce su orden de ejecución y , por tanto, no pueden ser conectadas con la secuencia del diagrama en la fase de diseño.

Transacción Ad Hoc

Resultado de la unión de ambos atributos.

Capítulo 3: Nodos

Este capítulo tiene como objetivo explicar el funci onamiento de un elemento de modelado concreto, los Nodos. Un Nodo c ontrola el flujo de ejecución de un Proceso, creando y sincron izando hilos diferentes de ejecución en el mismo.


1. Introducción 2. Comportamiento de los Nodos 3. Nodo Exclusivo

1. Repetición con un Nodo Exclusivo 4. Nodo Inclusivo 5. Nodo Paralelo 6. Nodo basado en Eventos 7. Nodo Complejo 8. Nodo Exclusivo de Evento de Inicio 9. Nodo Paralelo de Evento de Inicio 10. Ejemplo de uso combinado de Nodos 11. Fin del Capítulo

Introducción

Un Nodo controla el flujo del Proceso que está mode lando creando hilos de ejecución que convergen y divergen dentro del mismo. Tiene, por tanto, la responsabilidad de aseg urar la correcta ejecución del mismo.

La representación gráfica de un Nodo tiene forma de un diamante.

Son variadas las situaciones que pueden requerir la inclusión de un Nodo en el modelado de un Proceso: El valor de c ierta condición que influye sobre qué alternativa del Proceso ejecu tar, una espera en cierto punto a fin de asegurar que todos los hil os de ejecución del Proceso han llegado para continuar la ejecución del mismo...

Controlar el flujo de un Proceso depende en gran me dida de la naturaleza de la condición que hay que supervisar. Por ejemplo, no se realiza el mismo tratamiento sobre una condición lógica que sobre una condición basada en Eventos. Por ello, BP MN tiene una amplia gama de Nodos diferentes para modelar correc tamente el tipo de condición de que se trate.

Al igual que ocurría con los Eventos, se identifica cada tipo de Nodo por el marcador que se incluye dentro del símb olo.

Comportamiento de los Nodos

Independientemente del tipo de que se trate, un Nod o realiza dos acciones de control sobre el flujo de ejecución de un Proceso. Puede divergirlo si tiene varios Flujos de Secuenci a de salida y puede convergerlo si tiene varios Flujos de Secuenc ia de entrada .

En el caso un Nodo divergente , la naturaleza del mismo podrá generar uno o más tokens que circularán por los que tenga definidos. Si se trata de un Nodo convergente , el token que llegue esperará, si es necesario, a que los restantes que se hubieran generado previamente lo alcancen. Se produce, por t anto, un punto de sincronización en el Nodo.

¿Recuerda en el anterior capítulo cuando se analizó el comportamiento de una Actividad con múltiples Flujo s de Secuencia de entrada ? Se decía que para cada entrada se creaba una inst ancia diferente de la Actividad. Esto, que en algunas sit uaciones no es el comportamiento esperado, se soluciona utilizando un Nodo que sincronice todos los tokens antes de ejecutarla.

Un requisito importante y necesario a la hora de mo delar un Proceso con un Nodo es que el tipo de Nodo divergente que se utilice tiene que ser el mismo, si se usa, para el Nodo convergente .

Nodo Exclusivo

Un Nodo Exclusivo representa un momento del Proceso en el que existen varios caminos alternativos dependiendo del valor de cierta condición lógica. Esta condición puede tener el niv el de complejidad que se necesite, desde un típico Sí o No hasta cons trucciones complejas con operadores binarios relacionales y ló gicos (>, <, AND, OR...).

Su símbolo asociado es el ya visto en la introducci ón

o con un marcador visible en forma de X

Ambas descripciones son equivalentes.

Para un Nodo Exclusivo divergente , se generará un único token que circulará por el primer Flujo de Secuencia de salida que verifique el valor verdadero para la condición, aún existiendo otras alternativas que fueran igualmente válidas.

Nada impide modelar un Nodo Exclusivo que, para cie rta ejecución del Proceso, no verifique ninguna alterna tiva la condición que se esté evaluando. Esto provocaría una espera i ndefinida del token en el Nodo Exclusivo por lo que las buenas práctic as de BPMN recomiendan establecer un Flujo de Secuencia p or defecto. Este Flujo de Secuencia será el elegido por el token en caso de que ninguna de las otras alternativas cumplan la condic ión.

El comportamiento convergente de este Nodo es una mera formalidad porque, como se ha dicho, al generarse u n único token no existe sincronización.

Repetición con un Nodo Exclusivo

¿Recuerda cuándo se explicó el concepto de repetici ón de Actividades? Se indicó que había tres formas posibl es para repetir una Actividad concreta. Dos se de ellas ya se viero n en el capítulo correspondiente a las Actividades. La última es hac iendo uso de un Nodo Exclusivo.

En efecto, se puede establecer la condición que se evalúa en un Nodo Exclusivo y si dicha condición es cierta, se v uelve a ejecutar la Actividad. En caso contrario, se continúa el flu jo de ejecución del Proceso. Se trata de un patrón de desarrollo muy co nocido y tiene la siguiente estructura.

Nodo Inclusivo

Un Nodo Inclusivo presenta las mismas característic as que un Nodo Exclusivo. Se tienen diferentes alternativas p ara una cierta condición lógica. La diferencia con respecto al seg undo es que en éste sí se permite que se generen tantos tokens como alternativas verifiquen la condición.

Su símbolo asociado es el de un círculo.

En este caso, el token sí espera en el Nodo convergente para realizar la sincronización.

Dado que la naturaleza es similar al del Nodo Exclu sivo se recomienda modelar una alternativa por defecto .

Nodo Paralelo

Un Nodo Paralelo no verifica ninguna condición por lo que genera un token por cada Flujo de Secuencia de salida que tenga definido. Se realizará una sincronización en el Nodo converge nte.

Su símbolo asociado es un signo de suma.

Nodo basado en Eventos

Un Nodo basado en Eventos representa un momento del Proceso en el que se tienen dos o más alternativas que depe nden de la ocurrencia de un tipo de Evento para que pueda pros eguir su ejecución.

Su símbolo asociado es el de un pentágono incluido en un Evento Intermedio.

Su comportamiento es similar al Nodo Exclusivo en e l sentido de que únicamente se generará un token que circulará por la primera alternativa que coincida con el tipo de Evento que se ha lanzado. Una posterior activación de otro Evento definido en el mismo Nodo no afectará al token que se haya generado previamen te ni creará uno nuevo.

Evidentemente, es posible modelar un Nodo basado en Eventos en el cual, todas sus posibles alternativas no veri fiquen ninguno de los Eventos que se hayan disparado. El token sufrirá, por tanto, una espera indefinida en el Nodo. Modelar un Flujo de S ecuencia por defecto no tiene sentido porque lo que se están verificand o son Eventos, no condiciones. Por ello, las buenas práct icas de BPMN recomiendan modelar una alternativa mediante un Evento Intermedio Temporizador que se activará cuándo la condición de tiempo que tiene definida se dispare.

Nodo Complejo

Un Nodo Complejo se utiliza cuándo no es posible mo delar el comportamiento que se necesita en el Proceso con ni nguno de los Nodos que provee BPMN por defecto. Es el modelador, en tiempo de diseño del Proceso, el que indicará el comportamien to divergente o convergente del mismo.

Su símbolo asociado es un asterisco.

Nodo Exclusivo de Evento de Inicio

Este Nodo es un nuevo símbolo incluido en la versió n actual de BPMN, la 2.0. Su símbolo asociado es similar al del Nodo basado en Eventos salvo que el tipo de Evento es de Inicio, n o Intermedio.

Permite simplificar el modelado de un Proceso concr eto.

es equivalente a

Nodo Paralelo de Evento de Inicio

Este Nodo es un nuevo símbolo incluido en la versió n actual de BPMN, la 2.0. Su símbolo asociado es el de Evento d e Inicio Paralelo Múltiple.

Permite simplificar el modelado de un Proceso concr eto.

es equivalente a

Ejemplo de uso combinado de Nodos

Capítulo 4: Swimlanes

Este capítulo tiene como objetivo explicar el funci onamiento de un elemento de modelado concreto, los Swimlanes . Un Swimlane se utiliza para modelar Procesos en los que van a form ar parte más de un participante .


1. Introducción

2. Calle 1. Conectando Calles

3. Línea 1. Conectando Líneas

4. Ejemplo de Colaboración 5. Fin del Capítulo

Introducción

Por lo visto hasta ahora, sólo se puede modelar Pro cesos Privados. El concepto Privado debe entenderse en el sentido d e que el Proceso que se modela sólo puede ser realizado por un participante . Sin embargo, es evidente que existen Procesos que s on realizados por dos o más participantes . Piense, por ejemplo, en la contratación de un candidato por una empresa. En el modelado de dicho Proceso habrá que tener en cuenta los dos participante , candidato y

empresa. Un diagrama de este último tipo es lo que se conoce como Colaboración.

BPMN provee de forma estándar unos elementos de mod elado que permiten diseñar Procesos que tengan más de un participante , ayudando a organizar y dividir las actividades en u n diagrama. Dichos elementos serán explicados a continuación.

Calle

Una Calle es la representación gráfica de un participante en un Proceso modelado en BPMN. Cada participante presente en el Proceso deberá estar asociado únicamente a una Call e.

El símbolo asociado a una Calle es una caja rectang ular

que sirve de contenedor para el Proceso que tenga definido en su interior.

Por tanto, participantes diferentes tendrán su propio Proceso modelado en su interior y habrá que estudiar como c omunicarse entre ellos para avanzar por el flujo de ejecución en cada uno.

No es necesario que en el modelado de un diagrama d e Colaboración, todos los participantes tengan su Proceso interno visible, bien sea porque el modelador en la fase de diseño del mismo no lo necesita o porque carece de la informac ión necesaria para ello. Si no lo tiene, se dice que es un participante abstracto y su Calle se modela como una caja negra.

Conectando Calles

Una restricción impuesta a la Calle es que el Flujo de Secuencia del Proceso no puede sobrepasar los límites impuest os por el borde de la misma. Por tanto, para poder interactuar entr e diferentes Calles se utilizará un Conector de Objeto aún no ex plicado, el Flujo de Mensaje.

Los Flujos de Mensaje organizan todas las interacci ones entre las Calles, permitiendo avanzar a cada participante en su Proceso interno. Si uno de los participantes es abstracto, el Flujo de Mensaje se conecta con el borde de la Calle.

Si todos los participantes muestran sus Procesos internos, entonces los Flujos de Mensaje conectan los element os de modelado correspondientes.

Línea

Una Línea es una partición dentro de la Calle de un participante . Representa diferentes roles del participante dentro de su Proceso. Su símbolo asociado es un rectángulo que se conecta dentro de la Calle.

Por tanto, es muy posible que cada elemento de mode lado del Proceso, una Actividad, por ejemplo, sea ejecutado por un rol diferente del participante . Piense, por ejemplo, en el ejemplo anterior de la entrevista de trabajo. Es muy posibl e que la Actividad Realizar Entrevista sea realizado por un rol Entrevistador mientras que la Actividad Evaluar Contratación sea llevada a cabo por el rol Dirección de RR.HH.. Entrevistador y Direccion de R R.HH. son roles diferentes del participante Empresa definidos en su propio Proceso interno.

Conectando Líneas

Son varias las restricciones de conexión de las Lín eas:

• Se permite utilizar un Flujo de Secuencia que conec te diferentes Líneas dentro de la misma Calle.

• Se permite utilizar un Flujo de Mensaje que conecte diferentes Líneas de Calles distintas.

• No hay límites en el anidamiento de Líneas, por lo que pueden definirse diferentes roles subordinados a un rol superior.

Ejemplo de Colaboración

Capítulo 5: Conectores de Objetos

Este capítulo tiene como objetivo explicar el funci onamiento de un elemento de modelado concreto, los Conectores de Ob jetos. Los Conectores de Objetos conectan dos objetos presente s en un diagrama. Existen diferentes tipos y los elementos de modelado que conectan son, igualmente, distintos.


1. Introducción 2. Flujo de Secuencia

1. Flujo de Secuencia Condicional 2. Flujo de Secuencia por Defecto

3. Flujo de Mensaje 4. Asociación

1. Asociación de Datos 5. Fin del Capítulo

Introducción

Un Proceso no es un conjunto aislado de elementos d e modelado como Actividades, Eventos y Nodos. Muy al contrario , estos elementos deben ser conectados a fin de que avance el flujo de ejecución del mismo. Los responsables de que dicha conexión se haga de forma correcta son los Conectores de Objeto s.

Un Conector vincula dos objetos en un diagrama. Dep endiendo de la naturaleza del mismo puede conectar objetos dife rentes o iguales. Cada uno de ellos tiene su propia restricción de co nexión y podrá conectarse con algunos elementos y con otros no.

Se irá explicando en las siguientes secciones del c apítulo cada uno de ellos.

Flujo de Secuencia

Este Conector es ya conocido por haber sido utiliza do en casi la totalidad de los ejemplos gráficos de capítulos ant eriores. Un Flujo de Secuencia conecta Actividades, Eventos y Nodos p udiendo tener cualquier combinación de éstos como origen y destino .

Su símbolo asociado es el de una flecha de línea co ntinua con la punta de la misma sólida o rellena.

Aparte de conectar los elementos antes citados, tam bién sirve como orden de ejecución del Proceso. En el siguient e ejemplo, la Actividad A se ejecuta antes que la B y ésta antes que la C.

Flujo de Secuencia Condicional

Un Flujo de Secuencia Condicional es un tipo de Con ector en el cual un token avanza por él únicamente si cumple una cierta condición definida en el mismo. Este Conector puede tener co mo origen únicamente Actividades o Nodos Inclusivos o Exclus ivos. No puede conectarse desde un Evento ni desde el resto de Nodos disponibles.

Aunque nada impide utilizar este tipo de Conector d esde uno de los Nodos permitidos, las buenas prácticas en BPMN recomiendan no vincular la salida de éstos con este Conector . La razón es sencilla, el propio Nodo ya gestiona la evaluación de la condición y el avance del token por la salida adecuada, por lo que modelarla con un Flujo de Secuencia Condicional redunda la semánt ica del Proceso sin necesidad.

El símbolo asociado a este Conector es una flecha c ontinua cuyo inicio tiene forma de diamante, simulando un Nodo d e pequeñas dimensiones.

Cuando la ejecución de la Actividad haya finalizado , se evaluará la condición del Flujo de Secuencia Condicional, y si la verifica, el token avanzará por dicha salida . Este comportamiento se repetirá por cada Flujo de Secuencia Condicional que tenga l a Actividad y se generarán tantos tokens como verificaciones se hagan de cada condición correspondiente.

Dado que nada impide que ninguna de las condiciones se cumpla, las buenas prácticas de BPMN recomiendan establecer una alternativa de salida, que se modelará con un Flujo de Secuencia normal o por defecto , por la que siempre avance un token a fin de evitar una espera indefinida de éste en la Activida d.

Flujo de Secuencia por Defecto

Este tipo de Flujo de Secuencia ya se vio cuando se estudió el comportamiento de los Nodos Exclusivos e Inclusivos . Un Flujo de Secuencia por Defecto se utiliza cuándo se requiere dotar al elemento al que esté conectado con una alternativa de salida que siempre se cumpla, a fin de evitar esperas indefini das en el mismo.

Su símbolo asociado es el mismo que el Flujo de Sec uencia normal salvo por un signo \ situado en su origen .

Un Flujo de Secuencia por Defecto únicamente puede conectarse desde un Nodo Exclusivo, un Nodo Inclusivo o una Ac tividad.

Aunque no es lo habitual, nada impide conectar un F lujo de Secuencia por Defecto a una Actividad por lo que la s buenas prácticas de BPMN recomiendan modelar una alternativa por defecto en una Actividad con un Flujo de Secuencia normal .

Flujo de Mensaje

El Flujo de Mensaje se ha visto cuándo se estudiaba el capítulo correspondiente a los Swimlanes. Un Flujo de Mensaj e representa la interacción directa entre dos participantes present es en un Proceso.

Su símbolo asociado es una flecha discontinua a tra zos con origen en forma de círculo abierto y destino sin re llenar.

Un Flujo de Mensaje puede conectar Eventos, Activid ades y Nodos de diferentes Calles, no así elementos de la misma Calle.

Asociación

Una Asociación crea una relación entre dos objetos del diagrama. Su uso más común es para incluir comentarios en el mismo, ya lo ha visto en los ejemplos de este mismo capítulo.

Su símbolo asociado es una línea punteada.

Asociación de Datos

Una Asociación de Datos es un tipo particular de As ociación cuyo origen o destino es un elemento de modelado de tipo Dato. Los Datos serán estudiados en el siguiente capítulo por lo que aquí se expondrá únicamente la forma que tiene este Conecto r.

Como se puede observar, la única diferencia con la Asociación es que el destino del Conector es una flecha abierta.

Capítulo 6: Datos

Este capítulo tiene como objetivo explicar el funci onamiento de un elemento de modelado concreto, los Datos. Un Dato r epresenta un recurso que se genera o se necesita a lo largo del Proceso . Se estudiarán los tipos de Datos que hay y dónde se ut ilizan.


1. Introducción 2. Dato Objeto

1. Tipos de Dato Objeto 3. Fin del Capítulo

Introducción

Estudiar este capítulo es una novedad de la última versión de BPMN, la 2.0. Hasta la versión 1.2, los Datos se in cluían en la categoría de Artefactos junto a sus otros elementos . En esta versión se han generado y refinado nuevos símbolos para mod elar de forma más adecuada los Datos.

Un Dato representa un recurso que se genera o se requiere en algún punto del Proceso. Esta necesidad no es algo puntual si no más bien necesaria. En caso de que un Dato no esté generado cuando se necesita en otro punto del Proceso, el token esperará en dicho punto hasta que tal Dato se genere.

Dato Objeto

Un Dato Objeto representa un documento o un dato de l Proceso. Su símbolo asociado es un rectángulo con una esquin a doblada.

Un Dato Objeto está relacionado con las Actividades puesto que es el que define los recursos de entrada que necesita o de salida que genera. Como ya se vio en el capítulo anterior, un Dato se conecta mediante una Asociación de Datos.

Esta Asociación puede colocarse también en el Flujo de Secuencia que une ambas Actividades, siempre que no de cómo resultado un modelo ambiguo.

Un Dato Objeto suele tener asociado un estado que puede ir cambiando a lo largo del Proceso. De esta manera, e l modelador puede ir generando un histórico que documente los c ambios que se van generando en el mismo.

Tipos de Dato Objeto

Estos símbolos son nuevos elementos que se han incl uido dentro de la versión 2.0 de BPMN.

Colección de Datos

Representa una colección de información. Por ejempl o, el conjunto de elementos que componen un pedido hecho a una tienda.

Dato de Entrada

Representa un recurso que necesita una Actividad.

Dato de Salida

Representa un recurso que genera una Actividad.

Almacén de Datos

Representa un lugar en el que una Actividad puede e scribir y leer datos. Por ejemplo, un fichero en disco o una base de datos. Persiste más allá de la finalización del Proceso.

Mensaje

Representa el contenido del mensaje intercambiado e ntre dos participantes de un Proceso.

Como se ve, todos estos elementos simplifican y enr iquecen el modelado de un Proceso pero no presentan ninguna ve ntaja adicional.

es equivalente a

Capítulo 7: Artefactos

Este capítulo tiene como objetivo explicar el funci onamiento de un elemento de modelado concreto, los Artefactos. Un A rtefacto sirve para describir información adicional del Proceso qu e se está modelando a fin de hacer más entendible el diseño d el mismo.


1. Introducción 2. Grupo 3. Anotación de Texto 4. Fin del Capítulo 5. Introducción 6. Como es evidente, a medida que aumenta la comple jidad del

Proceso que se está modelando, se hace cada vez más necesario incluir información adicional sobre el di agrama que permita al lector del mismo entender su comportamie nto.

7. Ocurre lo mismo con el desarrollo de sistemas in formáticos. A fin de garantizar un correcto mantenimiento, se rec omienda documentar el código y las secciones más conflictiv as del mismo para comprender la estructura del mismo.

8. BPMN provee dos herramientas que permiten adjunt ar información adicional al Proceso con la finalidad d e facilitar la comprensión del mismo por parte de sus usuarios.

Grupo

Un Grupo se utiliza para rodear un conjunto de elem entos de un Proceso con el objetivo de destacarlos del resto po r algún motivo, bien sea porque definen una parte importante del mi smo o porque el modelador quiere resaltar algún aspecto particular.

El símbolo de un Grupo es el de un rectángulo con l as cuatro esquinas redondeadas y cuyo borde está descrito con puntos y rayas.

Un Grupo no altera la ejecución del Proceso ni la d el conjunto de elementos que contiene, se trata únicamente de un m ecanismo gráfico de utilidad para categorizar secciones del modelo. Por ello, no se pueden añadir Eventos Intermedios para cancel ar los elementos de un Grupo. Si se necesitara dicho compo rtamiento, habría que modelar los elementos de dicho Grupo en un Subproceso para, posteriormente, anclar un Evento I ntermedio al borde del mismo.

El siguiente ejemplo modela un Proceso simplificado de implementación de un sistema informático. Las Activ idades referentes a la elaboración de la documentación se encuentran clasificadas en un Grupo.

Anotación de Texto

Una Anotación de Texto se utiliza para añadir infor mación descriptiva sobre el Proceso que se está modelando. Pueden conectarse a cualquier elemento del diagrama median te una Asociación o incluirse libremente en el modelo.

Su símbolo es un recuadro abierto.

Ha sido utilizado en muchas de las imágenes de los diferentes capítulos.

Capítulo 8: Coreografías

Este capítulo tiene como objetivo mostrar el compor tamiento de un nuevo tipo de diagrama soportado en la actual ve rsión de BPMN, las Coreografías. Una Coreografía es un tipo de dia grama en el cual se focaliza más en el intercambio de la información entre participantes que en el comportamiento intrínseco del Proceso.


1. Introducción 2. Actividades

1. Ejemplo de Actividades 3. Modelos Equivalentes 4. Fin del Capítulo

Introducción

Hasta este punto, el tutorial se ha focalizado en e xplicar detenidamente el funcionamiento de cada elemento de modelado en un capítulo independiente. Hasta la versión 1.2 de BPMN, el contenido del mismo habría terminado en el capítulo anterior. Sin embargo, en su versión 2.0 se ha dado soporte a un nuevo tipo de diagrama, las Coreografías.

Los capítulos anteriores han explicado cómo afectab a al comportamiento de un Proceso cada uno de los elemen tos de modelado. Los Eventos representan acciones que ocur ren en el mismo, una Actividad la realización de un trabajo, los Nodos crean o sincronizan diferentes hilos de ejecución…

Una Coreografía representa un modo completamente di ferente, aunque equivalente, de modelar un Proceso. En él, n o se modela tanto su comportamiento como el intercambio de info rmación, generalmente por el paso de Mensajes, que ocurre en tre diferentes participantes del mismo.

Actividades

Lo primero que debe tenerse en cuenta es que las Ac tividades de una Coreografía no son diferentes semánticamente, a unque sí gráficamente, a las ya estudiadas en el capítulo an terior correspondiente. Pueden ser una Tarea o un Subproce so, ya sea Colapsado o Expandido. Pueden repetirse mediante Bu cles o Múltiples Instancias Secuenciales o Paralelas.

El símbolo asociado a una Actividad de una Coreogra fía es un rectángulo con las cuatro esquinas redondeadas y en el cual pueden distinguirse, al menos, tres zonas delimitad as en él. La zona central sirve para describir la naturaleza de la Ac tividad del mismo modo que ya se vio anteriormente. La novedad aparec e en las zonas superior e inferior de la Actividad, en ellas se de finen los diferentes participantes que participan en el Proceso. La zona que aparezca sin sombrear son participantes que inician la Actividad y la sombreada aquellos que no la inician.

Tarea

Define un conjunto de participantes que intercambian Mensajes para completar una Tarea.

Subproceso

Abstrae el modelado de una Coreografía con varias i nteracciones no visible si se trata de un Subproceso Colapsado o visible si se trata de un Subproceso Expandido.

Ejemplo de Actividades

El lector no debe encontrar problemas en entender e l modelado de este Proceso puesto que todos los atributos y símbo los han sido explicados previamente.

Note como el Participante C tiene aplicado un atrib uto de Multi Instancia. Con esto se denota que en el Proceso exi sten varios participantes del mismo tipo. De esta forma se evita el tener qu e declararlos uno a uno.

Modelos Equivalentes

Como ya se ha dicho, los modelos de Coreografía son equivalentes a los ya vistos de Colaboración sólo q ue representados de diferente forma. La mejor forma de demostrar esto es mostrar un diagrama de Colaboración, con el que el modelador se encuentra más cómodo por ser el que habitualment e ha utilizado, y su Coreografía equivalente.

A continuación, tiene una serie de ejemplos que van aumentando progresivamente de dificultad. Combinando éstos, po drá modelar Coreografías de Procesos complejos sin dificultad.

Ejemplo 1

Ejemplo 2

Ejemplo 3

Ejemplo 4

Ejemplo 5

Ejemplo 6

Nótese que, generalmente, el diagrama de Coreografí a tiene un diseño más compacto que la Colaboración y que se di seña más cómodamente con él en cuánto se entiende el signifi cado de sus símbolos.

Capítulo 9: Conversaciones

Este capítulo tiene como objetivo mostrar el compor tamiento de un nuevo tipo de diagrama soportado en la actual ve rsión de BPMN, las Conversaciones. Una Conversación es un tipo de diagrama en el cual se focaliza más en el objeto lógico sobre el q ue gira un intercambio de Flujo de Mensajes entre diferentes participantes del Proceso que en el comportamiento intrínseco del mis mo.


1. Introducción 2. Nodo de Conversación 3. Sub Conversación 4. Enlace de Conversación 5. Fin del Capítulo

Introducción

Hasta este punto, el tutorial se ha focalizado en e xplicar detenidamente el funcionamiento de cada elemento de modelado en un capítulo independiente. Hasta la versión 1.2 de BPMN, el contenido del mismo habría terminado hace dos capít ulos. Sin embargo, en su versión 2.0 se ha dado soporte a un nuevo tipo de diagrama, las Conversaciones.

Un diagrama de Conversación es una descripción info rmal de un diagrama de Colaboración. En general, es una versió n simplificada de este tipo de diagrama pero manteniendo todas las características del mismo. Por ejemplo, pueden incluirse los Proces os en las diferentes Calles de los participantes, aunque no e s lo más usual.

Un diagrama de Conversación agrupa los intercambios de mensajes producidos entre diferentes participantes utilizando un Nodo de Conversación (símbolo que se describirá en la siguiente sección), permitiendo de esta manera reducir la com plejidad del modelo y mostrar de una manera simple y visual la e structura del proceso con un nivel menos bajo de detalle.

Los diagramas de Conversación introducen, por tanto , nuevos elementos de modelado adicionales a los ya mostrado s en los capítulos anteriores. Lo mismo ocurría con los diag ramas de Coreografía en el capítulo anterior.

Nodo de Conversación

Un Nodo de Conversación representa la agrupación de uno o más intercambios de mensaje que se realizan sobre un mi smo objeto lógico. Su símbolo asociado es el de un hexágono.

Por ejemplo, en una transacción comercial entre un Comprador y una Tienda, se producirá un intercambio de mensajes iniciándose con un mensaje desde Comprador a Tienda indicando q ue se desea adquirir un producto y, probablemente, finalizará c on otro desde Tienda a Comprador con el producto. Entre éstos dos se generarán otros flujos de mensaje con facturas, pago, cambio… Todo este intercambio, que puede ser tan complejo cómo se nec esite, puede modelarse utilizando un Nodo de Conversación, que a grupe los mensajes anteriores, denotándolo por el objeto lógi co sobre el que gira todo el Proceso que, en este caso, es el produ cto que se adquiere.

es equivalente a

Sub Conversación

Una Sub Conversación representa el mismo papel que los Subprocesos para las Actividades. Encapsula a un co njunto de Nodos de Conversación de menor nivel del mismo modo que un Subproceso encapsula a Procesos, igualmente de meno r nivel.

Manteniendo la homogeneidad de los símbolos que enc apsulan a otros de su misma familia, la diferencia que existe entre un Nodo de Conversación y una Sub Conversación es que la segun da presenta un signo de suma en su parte inferior, siendo el re sto de la misma estructura vista en la sección anterior.

Si se decide expandir la Sub Conversación es tarea del diseñador elegir qué nivel de detalle se mostrará de la Conve rsación, puesto que no existe en BPMN una acción que se realice por defecto. No ocurre así en los Subprocesos Colapsados. Cuando se expande un Subproceso Colapsado, se muestra por defecto el det alle del Proceso interno que tiene encapsulado.

Al expandir una Sub Conversación puede obtenerse un diagrama de Conversación con dos o más Nodos de Conversación ,

obtener directamente un conjunto de Flujos de Mensa je

o una combinación de ambos.

Es el modelador en la etapa del diseño del Proceso, el que decide qué acción realizar al expandir cierta Sub Conversa ción.

Enlace de Conversación

Un Enlace de Conversación es un tipo de Conector de Objetos desarrollado específicamente para los diagramas de Conversación. Uno de los extremos debe conectarse con una Calle y el otro extremo puede conectarse con un Nodo de Conversació n o con una Sub Conversación.

Su símbolo asociado es una o dos líneas de trazo mu y fino.

Patrones y Antipatrones

Un patrón es la abstracción de una forma concreta e l cual mantiene a repetirse en un contexto específico no-a rbitrario. A continuación se detallan cada uno de los patrones a explicar.

• Patrones de Flujo.

En este apartado puedes encontrar errores muy comun es que se producen al realizar construcciones, asi como una p osible solución a ellos.

• Buenas prácticas y Errores comunes.

Patrones de Flujo.

En la siguiente imagen se muestran algunas de las s ituaciones más comunes en un desarrollo BPMN.

En cada uno de las siguientes páginas, se detallan cada unos de los casos expuestos anteriormente.

• Patrones básicos. • Derivación. • Estructural. • Múltiple instancia. • Basado en estados. • Cancelación.

Patrones básicos.

Los patrones básicos son muy comunes en un desarrol lo BPMN, y pueden suponer cerca del 60% de este. Se pueden distinguir 4 tipos:

Desarrollo en paralelo.

Un Nodo Paralelo puede ser utilizado para crear dos flujos paralelos que se ejecutan simultáneamente. El Nodo Paralelo es realmente opcional; dos Flujos de Secuencia de sali da conectados a la tarea A por un lado y la tarea B y C por otro, r espectivamente, habrían tenido el mismo efecto.

Sincronización.

Un Nodo Paralelo también puede ser usado para combi nar dos Flujos de Secuencia paralelas en una.

Elección exclusiva.

Un Nodo Exclusivo se puede utilizar para crear un p unto de decisión en donde varias ramas podrían ser tomadas, pero sólo una se realizará dependiendo del resultado de una expre sión basada en los datos del Proceso.

Unión.

Un Nodo Exclusivo se utiliza para unir dos Flujos d e Secuencia en uno solo. Observe que ambos flujos conllevan la eje cución de la Tarea C.

Patrones derivados.

En esta clase de patrones se presentan los concepto s de ramificación avanzada y patrones de sincronización. Se pueden distinguir 4 tipos:

Elección múltiple.

Un Nodo Inclusivo se puede utilizar para crear un p unto de decisión en varias ramas que podrían tomarse en fun ción del resultado de las condiciones asociadas.

Unión sincronizada.

Un Nodo Inclusivo se puede utilizar para sincroniza r un conjunto de Flujos de Secuencia producidos anteriormente.

Unión múltiple.

Dos o más Flujos de Secuencia están convergiendo en la tarea C. Obsérvese que, a diferencia del caso anterior en qu e la Tarea C se ejecuta dos veces al no haber un Nodo Inclusivo que sincronice los flujos, en este caso sólo se ejecuta una única vez.

Discriminador.

El Nodo discrimina entre los flujos. En el primer caso, al sólo cumplirse una de las con diciones, sólo existe un Flujo de Secuencia y no es necesario sinc ronizar. En el segundo, se crean dos Flujos de Secuencia que posteriormente se unen en el discriminador, lo que permite que tras la llegada del primero el modelo continúe y que al llegar el segundo sea ignorado. Obsérvese que, a diferencia de un Nod o Inclusivo, la Tarea D sólo se ejecutará una vez.

Patrones estructurales.

Esta clase presenta construcciones específicas en l as que las actividades deben ser repetidas. Se pueden distinguir 2 grandes tipos:

Ciclos arbitrarios.

Terminación implícita.

Patrones Multi Instancias.

Esta clase de patrones presenta algunos casos de la ejecución de Subprocesos múltiples. Se pueden distinguir 3 tipos:

Sin sincronización.

Obsérvese que las Tareas A y B tienen una duración diferente y cuando acaban inician el Subproceso, que por tanto se ejecutará dos veces.

2 1

Con prioridad.

En este caso, se ejecutan los Subprocesos una vez c oncluída la Tarea A.

Sin prioridad.

Al contrario que en el caso anterior, aquí no exist e un prioridad clara y el Subproceso se ejecutará tantas veces com o Flujos lleguen a él, sin importar el orden de estos.

Patrones basados en estados.

Estos patrones describen situaciones donde se utili za un estado específico de un proceso para afectar a su ejecució n. Se pueden distinguir 2 tipos:

Elección diferida.

Obsérvese que la Tarea a ejecutar dependerá directa mente del suceso anterior.

Hitos.

En esta ocasión, se puede observar como la tarea E requiere de la finalización de las tareas B y C para ser ejecutada , esto se consigue gracias al Nodo de sincronización situado antes de la Tarea.

Patrones de cancelación.

Esta clase de patrones presenta diferentes formas d e manejo de excepciones.

Cancelar una Actividad.

Obsérvese que, en este caso, la ejecución de la Tar ea C depende de que la Tarea B sea abortada o no.

Buenas prácticas y Errores comunes.

A continuación se detallan posibles errores en el m odelado BPMN asi como formas de solucionarlo.

• Mal Uso de Flujos en/entre Calles. • Uso de Tareas y Eventos. • Uso de Eventos de tiempo. • Uso de Eventos de Mensaje y Flujo de Mensajes. • Flujo dentro de Líneas. • Uso de mecanismo de Secuencia de Flujo. • Uso de Nodos.

Antes de comenzar con los diferentes patrones y ant ipatrones, es conveniente tener en cuenta el significado de algun os símbolos que nos encontraremos a continuación:

Mal Uso de Flujos en/entre Calles.

Es frecuente que cuando se modelen Procesos en dife rentes Calles, los Flujos de Secuencia y Eventos de Inicio y Fin se olviden, porque erróneamente se cree que los Flujos de Mensa je sustituyen los Flujos de Secuencia. Adicionalmente, los Flujos de Secuencia son mal usados al conectar Calles. El modelado de un Proceso en cada Calle es independ iente y se pueden definir Flujo de Mensajes entre Calles.

Uso de Tareas y Eventos.

Los diseñadores de Procesos a menudo modelan erróne amente Eventos y Tareas. Por ejemplo: Algunos Eventos son modelados como Tareas y los estados de las Tareas como nuevas Tareas.

Uso de Eventos de tiempo.

Hay dos errores comunes cuando se usan Eventos que modelen condiciones de tiempo. Por un lado, los Eventos de Inicio son comúnmente u sados en vez de Eventos Intermedios. En segundo lugar, los Eventos Intermedios son usado s como mecanismo de retraso pero modelados como una excepc ión (representando la duración de la tarea) y viceversa .

Uso de Eventos de Mensaje y Flujo de Mensajes.

Eventos de Inicio y Fin no pueden ser causa de Fluj o de Mensajes.

Flujo dentro de Líneas.

Las Líneas son, a menudo, erróneamente utilizadas e n forma similar a una Calle. Estos últimos, erróneamente, c ontienen más Procesos de Negocio o contienen Flujos de Mensaje e ntre diferentes Líneas.

Uso de mecanismo de Secuencia de Flujo.

Cuando se usan Subprocesos Expandidos, los Flujos d e Secuencia deben ser conectados a los límites del Su bproceso y el Subproceso debe tener Eventos de Inicio y Fin.

Uso de Nodos.

Los Nodos sólo pueden ser conectadas con Flujos de Secuencia, también evitan bloqueos potenciales cuando se model a el Proceso utilizando estos elementos.

Tutorial Interactivo de BPMN 2

Documents

Transcript of Tutorial Interactivo de BPMN 2