PocketGuide v1 0 BPMN2 Constructos

Familia: Compuertas
Elemento 1: Compuerta Exclusiva

Representacin Grfica Nombre
Compuerta
Exclusiva
divergente
Las Compuertas se utilizan para controlar la interaccin de los Flujos de Secuencia cuando estos convergen o divergen dentro de un Proceso. Si el flujo no necesita ser controlado, no se necesita una Compuerta. El trmino Compuerta implica que hay un mecanismo de admisin
que permite o impide el paso a travs de la Compuerta es decir, los tokens pueden ser combinados en uno slo al entrar, o divididos en varios al salir; segn lo indiquen los mecanismos del tipo de Compuerta utilizado.
Mejores prcticas: aunque una misma compuerta se puede utilizar para divergir y convergir el flujo (es decir una misma compuerta puede tener varios flujos entrantes y varios salientes a la vez) se recomienda que cada compuerta realice slo una de las dos funcione.
Nota: Para compuertas divergentes, SIEMPRE se debe tomar al menos uno de los caminos salientes. El modelador debe asegurarse de que esto se cumpla, utilizando flujos predefinidos si es necesario.
Compuerta
Exclusiva
convergente
Elemento 2: Compuerta Inclusiva
Compuerta
Inclusiva
divergente
Compuerta
Inclusiva
convergente
Elemento 3: Compuerta Paralela
Compuerta Paralela
divergente
Compuerta Paralela
convergente
Elemento 4: Compuerta basada en eventos
Compuerta
Exclusiva Basada en
Eventos
Compuerta
Exclusiva Basada
en Eventos
Iniciadora de
Proceso
Compuerta Paralela
Basada en Eventos
Iniciadora de
Proceso
Elemento 5: Compuerta Compleja
Compuerta
Compleja
divergente
Compuerta
Compleja
convergente
Definicin OMG
La Compuerta Exclusiva divergente (decisin) se utiliza para crear caminos alternativos en el flujo
de un proceso. En una instancia del proceso slo se puede tomar uno de los caminos.
Ejemplo: diagrama
Definicin OMG
La Compuerta Exclusiva convergente se utiliza para unir caminos alternativos. Cada token
entrante es dirigido hacia el flujo de Secuencia Saliente sin sincronizacin.
Ejemplo: diagrama
Definicin OMG
Una Compuerta Inclusiva divergente se puede utilizar para crear caminos alternativos paralelos
dentro de un flujo de Proceso.
Ejemplo: diagrama
Definicin OMG
Una Compuerta Inclusiva convergente se utiliza para combinar varios caminos paralelos. Un token
proveniente de un flujo entrante PUEDE ser sincronizado en una Compuerta Inclusiva con otros
tokens que lleguen ms tarde a esa Compuerta.
Ejemplo: diagrama
Definicin OMG
Una Compuerta Paralela divergente se utiliza para crear flujos paralelos.
Ejemplo: diagrama
Definicin OMG
Una Compuerta Paralela convergente se utiliza para sincronizar (combinar) flujos paralelos.
Ejemplo: diagrama
Definicin OMG
La Compuerta Basada en Eventos representa un punto de bifurcacin en el Proceso en donde los
caminos alternativos que salen de la Compuerta se basan en Eventos que ocurren y no en datos
del Proceso (como en las otras compuertas).
Ejemplo: diagrama
Definicin OMG
caminos alternativos que se siguen al salir de la Compuerta dependen de Eventos que ocurren y
no de datos del Proceso (como en las otras compuertas).
Ejemplo: diagrama
Definicin OMG
caminos alternativos que se siguen al salir de la Compuerta dependen de Eventos que ocurren y
no de datos del Proceso (como en las otras compuertas).
Ejemplo: diagrama
Definicin OMG
La Compuerta Compleja se puede utilizar para modelar comportamiento de sincronizacin
complejo. Una Expresin condicional se utiliza para describir exactamente cmo debe ser el
comportamiento.
Ejemplo: diagrama
Definicin OMG
La Compuerta Compleja se puede utilizar para modelar comportamiento de sincronizacin
complejo. Una Expresin condicional se utiliza para describir exactamente cmo debe ser el
comportamiento.
Ejemplo: diagrama
Explicacin
La compuerta exclusiva se utiliza para crear una bifurcacin. Slo se puede tomar uno
de los caminos que salen. Se tomar el camino cuya condicin se cumpla. Las
condiciones las fija el modelador y debe escribirlas junto a los flujos salientes.
Opcionalmente se puede crear un camino predefinido que se tomar si las otras
condiciones no se cumplen, a este camino se le llama Flujo Predefinido. Un Flujo
Predefinido tiene una lnea transversal al incio (ver ejemplo).
Ejemplo: explicacin
La compuerta se utiliza para representar una decisin entre comer con amigos o comer
solo. La decisin depende de qu quieren los amigos. Si los amigos quieren pizza o
hamburguesas, comer con ellos, si no se cumple ninguna de esas dos condiciones, es
decir, si quieren cualquier otra cosa, comer solo. Note que el tercer flujo no tiene
condicin, en vez de esto tiene una pequea lnea transversal al inicio; sta indica que
es un flujo predefinido.
Explicacin
La Compuerta Exclusiva se utiliza para redirigir tokens de caminos paralelos hacia un
slo camino saliente. Cada token que entra a la compuerta sale por el flujo saliente sin
esperar a ser sincronizado con otros tokens entrantes.
Ejemplo: explicacin
La compuerta se utiliza para indicar que los reportes deben ser enviados conforme se
vayan terminando y no esperar a que todos estn listos para enviarlos. El uso de una
compuerta exclusiva indica que no se debe esperar a que todas las tareas ("Completar
reporte", 1, 2 y 3) estn completas para ejecutar la siguiente tarea, sino que por cada
tarea que se complete se debe iniciar una instancia de la tarea "enviar reporte".
Explicacin
La compuerta inclusiva sirve para dividir un flujo en varios caminos paralelos. A
diferencia de la compuerta exclusiva el que se tome un camino no impide que se tomen
los dems. Se tomarn todas las opciones cuya condicin se cumpla. As que podran
seguirse todos, ninuno o slo algunos caminos.
Ejemplo: explicacin
El ejemplo ilustra el proceso de preparacin para una exposicin. Si el expositor tiene a
la mano carteles, stands y folletos, pone las tres cosas, pero si no tiene alguna colocar
las otras. Se utiliza la Compuerta Inclusiva divergente para indicar que se deben tomar
todas las medidas posibles al momento de que se alcance la compuerta.
Explicacin
Es una de las compuertas ms difciles de comprender, analice con cuidado el ejemplo y
la siguiente explicacin. Esta compuerta "observa" todos los flujos entrantes, y los
caminos por los que venga un token los espera y los sincroniza. No necesariamente
espera a que lleguen tokens por todos los flujos entrantes sino slo por aquellos que
"sabe" que tienen tokens en camino.
Ejemplo: explicacin
La compuerta que nos interesa es la segunda. Para este ejemplo supondremos que en
una instancia dada del proceso, los recursos disponibles sern carteles y stands.
Entonces se enviarn tokens por esos dos caminos. En la segunda compuerta se ver
que slo dos de los tres caminos podran entregar tokens (el camino que viene de
"colocar folletos" no tiene tokens porque no haba folletos a la hora de prepararse para
la exposicin). Cuando se hayan colocado tanto los carteles como los stands se dar
inicio a la exposicin. No se esperar a que se coloquen los folletos, pues a la hora de
llegar a la compuerta ya se sabe que no hay folletos disponibles.
Explicacin
Cuando el flujo llega a esta Compuerta, se envian tokens por todos los flujos salientes
sin revisar condiciones de ningn tipo.
Ejemplo: explicacin
En este ejemplo se utiliza la Compuerta Paralela para dividir el trabajo entre varios
actores e indicar que estos deben ejecutar sus tareas de forma simultnea.
Explicacin
La compuerta esperar a que lleguen tokens por todos los flujos entrantes para luego
enviar un solo token por el flujo saliente. Si por algn camino no llega un token el
proceso simplemente no continuar.
Ejemplo: explicacin
En el ejemplo se utiliza la compuerta para dar a entender que el proyecto no puede
arrancar a menos que se haya recibido la autorizacin, generado el plan de proyecto y
seleccionado al equipo de trabajo. El flujo del proceso estar detenido hasta que se
completen TODAS esas tareas.
Explicacin
La Compuerta Basada en Eventos no puede utilizarse sola; TIENE que ir seguida
inmediatamente de dos o ms eventos intermedios que capturen (seal, mensaje,
temporizador, etc.), o tareas de recepcin. El primer evento que se cumpla es el camino
que seguir el token y los otros caminos quedarn deshabilitados. Casi siempre se
utiliza con eventos de mensaje y se coloca un temporizador para evitar que el proceso
se interrumpa.
Ejemplo: explicacin
En este ejemplo se enva la cotizacin al cliente pero la siguiente accin a realizar
depende de la respuesta del cliente. No sera apropiado utilizar otro tipo de compuerta
con la condicin "qu respondi el cliente?" porque la respuesta del cliente no es
informacin interna al proceso. Note que se utiliza un contador, previendo que el
cliente podra simplemente no contestar. Si no estuviera el evento temporizador y el
cliente no contestara, el proceso se quedara atascado en la compuerta. Se podran
haber utilizado tareas de recepcin en vez de los eventos de mensaje.
Explicacin
Esta compuerta se utiliza para iniciar un proceso. Se comporta exactamente igual que
su contraparte no-iniciadora de procesos, con la excepcin de que no debe tener flujos
entrantes.
Ejemplo: explicacin
En este ejemplo sencillo se responde a un viejo amigo que se ha puesto en contacto. La
forma de responder depende del tipo de mensaje que se reciba, fsico o electrnico. En
este caso quien responde no tiene que tomar una decisin, sino que su forma de actuar
depende de una decisin externa a la que l slo reacciona.
Explicacin
Esta compuerta se utiliza exclusivamente para dar inicio a un proceso. La caracterstica
de esta compuerta es que la activacin del primer evento no deshabilita los otros
caminos. Los tokens parados en los eventos que an no se activan seguirn esperando a
que su evento se cumpla, y si se cumple, pasarn por la compuerta; de forma que se
pueden activar todos, algunos, o ninguno de los flujos de secuencia salientes.
Ejemplo: explicacin
El ejemplo trata sobre el proceso de registro a un concurso con varias modalidades. Si
alguien solicita participar en el concurso de escritura se le inscribir en ste y se le
enviar la informacin relacionada, pero esto no lo excluye de inscribirse en el concurso
de pintura, siempre y cuando enve un mensaje solicitndolo.
Explicacin
El comportamiento de la compuerta compleja es configurable. Para la compuerta
compleja es necesario definir una expresin condicional, esta expresin consta de dos
partes: condiciones y acciones. Dependiendo de cules condiciones se cumplan y cmo
se cumplan, son las acciones que se tomarn. Las condiciones pueden hacer referencia,
por ejemplo, a datos del proceso, el estatus de algn Objeto de Datos, o la llegada de
un token (por ejemplo, "que llegue un token y el reporte A ya se haya generado"). Las
acciones tambin son configurables. Ejemplos de acciones seran enviar tokens por
varios de los caminos, enviar varios tokens por un solo camino, consumir el token
entrante y no enviar nada, etc.
Ejemplo: explicacin
En este ejemplo se evala, y premia o castiga, el desempeo de un empleado en un
diplomado. La anotacin de texto describe el comportamiento de la compuerta
compleja en base al objeto de datos "Calificaciones del empleado". La compuerta est
diseada para que al menos una alternativa se tenga que tomar, pero se pueden tomar
una o varias a la vez. Por ejemplo, si el empleado obtiene una calificacin de A+, se le
otorgar un ascenso, un bono y adems se le rembolsar la colegiatura. Este mismo
diagrama se podra realizar usando las otras compuertas pero se necesitara ms de una
compuerta y mucho ms espacio.
Explicacin
El comportamiento de la compuerta compleja es configurable. Es necesario que el
modelador defina una expresin condicional que determinar cmo se sincronizan los
flujos entrantes. Esta expresin debe tener dos partes: una condicin y una accin. La
condicin puede hacer referencia, por ejemplo, a datos del proceso, el estatus de algn
objeto de datos, o la llegada de tokens. Ejemplo de una condicin es esperar a que
lleguen tokens por 3 de 5 flujos entrantes. La accin es el resultado de que se cumplan
ciertas condiciones. Ejemplos de acciones son sincronizar los tokens, consumirlos o
dejarlos pasar conforme van llegando.
Ejemplo: explicacin
En este ejemplo lo que queremos es que el diagnstico se realice tan pronto se
complete alguno de los anlisis, pero no nos importa cul se complete primero. El
problema es que no queremos que el diagnstico se vuelva a realizar despus de que
termine el segundo anlisis. As que utilizamos una compuerta compleja que tiene la
condicin de dejar pasar un token y consumir el que llegue despus. As, en cada
instancia del proceso el diagnstico se realiza slo una vez. Si hubieramos utilizado una
compuerta exclusiva para unir el flujo, se hubieran creado dos instancias de la tarea
diagnstico, una por cada anlisis realizado.
Usos tpicos
*Cuando el actor debe decidir
entre varias opciones. *Cuando
las acciones a tomar dependen
de la condicin en que se
encuentre algo ms (si un
producto est disponible o no, si
se termin un determinado
reporte o no, etc).
Mejor prctica
Utilice un flujo predefinido para
garantizar que se seguir al
menos uno de los flujos salientes.
Usos tpicos
*Cuando necesitas que el
siguiente paso en el proceso se
realice tan pronto se termine la
tarea anterior.
Usos tpicos
*Cuando necesitas "trabajar con
lo que tienes" si tienes todo usas
todo, si slo tienes algunas
herramientas usas las que tengas.
*Cuando se presenta una
decisin en la que se pueden
tomar varias de las opciones a la
vez.
Mejor prctica
Asegrese que al menos una de
las condiciones se cumplir para
que el flujo no se interrumpa.
Utilice un flujo predefinido si es
necesario.
Usos tpicos
*Cuando previamente usaste una
compuerta inclusiva divergente y
necesitas sincronizar el flujo.
Utilice una compuerta inclusiva
convergente slo si ha utilizado
antes una compuerta inclusiva
divergente o una compuerta
compleja.
Usos tpicos
*Dividir el trabajo entre varios
actores. *Realizar varias cosas al
mismo tiempo en vez de hacerlo
de forma secuencial.
Mejor prctica
Usos tpicos
*Cuando es indispensable esperar
a que varias personas terminen
su trabajo antes de seguir.
*Cuando es indispensable que se
completen varias tareas antes de
continuar.
Usos tpicos
*Cuando las decisiones dependen
de la respuesta de un cliente o
agente externo a la organizacin.
*Esperar la llegada de un mensaje
para decidir. * Cuando la
decisin no depende de
informacin interna al proceso
sino de sucesos externos.
Mejor prctica
Incluya un evento temporizador
para evitar que el proceso se
interrumpa en la compuerta.
Usos tpicos
*Cuando la forma de realizar un
proceso depende de una
indicacin externa. *Cuando un
proceso puede ser iniciado por
cualquiera de un conjunto de
mensajes.
Asegrese de que al menos uno
de los eventos se cumpla, utilice
un evento temporizador si es
necesario.
Usos tpicos
*Cuando el cliente o interesado
puede agregar requerimientos al
proceso aunque ste ya haya
empezado.
Mejor prctica
Asegrese de que al menos uno
de los eventos se cumpla, utilice
un evento temporizador si es
necesario.
Usos tpicos
*Cuando las otras compuertas no
pueden realizar el
comportamiento deseado.
*Cuando se necesitaran muchas
compuertas para obtener el
Mejor prctica
*Utilice una anotacin de texto
para describir el comportamiento
de la compuerta. *Asegrese de
que al menos un flujo saliente
reciba tokens. *No
utilice compuertas complejas a
menos que las otras compuertas
no puedan lograr el
Usos tpicos
*Cuando las otras compuertas no
pueden realizar el
*Cuando se necesitaran muchas
compuertas para obtener el
*Utilice una anotacin de texto
para describir el comportamiento
de la compuerta. *Asegrese de
que al menos un flujo saliente
reciba tokens. *No
utilice compuertas complejas a
menos que las otras compuertas
no puedan lograr el
Familia: Eventos de inicio
Elemento 1: Eventos de inicio para Procesos
Representacin Grfica Nombre Definicin OMG
Evento de Inicio
Nulo
El Evento de Inicio Nulo no
tiene un detonador.
Evento de Inicio
por Mensaje
La llegada de un Mensaje de un
Participante detona el inicio del
Proceso.
Los Eventos de Inicio se utilizan para condicionar el inicio de un Proceso o Sub-Proceso. Existen diferentes tipos de disparadores, es decir de sucesos que provocan
que un Evento de Inicio se active. Al dispararse el Evento de Inicio, se arranca el Proceso. Existen 3 familias de Eventos de Inicio: 1) Aquellos que se utilizan para
iniciar Procesos. 2) Aquellos que se utilizan para iniciar Sub-Procesos y 3) Aquellos que se utilizan para iniciar Sub-Procesos de Evento.
Generalidades: Existen 7 eventos de inicio para Procesos. Los eventos de inicio para Procesos indican qu tiene que ocurrir para que un Proceso comience. Los
Eventos de inicio no pueden tener flujos de secuencia entrantes.
Evento de Inicio
por Temporizador
Una fecha o ciclo temporal
especfico (por ejemplo, cada
Lunes a las 9am) detonar el
inicio del Proceso.
Evento de Inicio
por Seal
La llegada de una seal
publicada desde otro Proceso
detona el inicio del Proceso.
Evento de Inicio
Condicional
Este tipo de Evento se detona
cuando una condicin se vuelve
verdadera.
Evento de Inicio
Mltiple
Este evento indica que hay
varias formas de detonar el
Proceso. Slo una de ellas se
REQUIERE.
Evento de Inicio
Paralelo Mltiple
Este evento indica que se
REQUIEREN varios detonadores
para que el Proceso se
instancie. Todos los tipos de
detonadores listados en el
Evento de Inicio DEBEN
dispararse para que el Proceso
sea instanciado.
Elemento 2: Eventos de inicio para Sub-Procesos
Evento de Inicio de
Sub-Proceso Nulo
El Evento de Inicio Nulo no
tiene un detonador.
Elemento 3: Eventos de inicio para Sub-Procesos de Evento
Slo existe 1 evento de inicio para Sub-Procesos, ya que los Sub-Procesos (igual que una tarea) slo pueden ser detonados por la llegada de un flujo de secuencia
entrante.
Con Interrupcin:
Sin Interrupcin
Con Interrupcin:
Sin Interrupcin
Temporizador
Una fecha o ciclo temporal
especfico (por ejemplo, cada
Lunes a las 9am) detonar el
inicio del Proceso.
Mensaje
La llegada de un Mensaje de un
Participante detona el inicio del
Proceso.
Existen 9 tipos de eventos de inicio para Sub-Procesos de Evento. Los eventos de inicio para Sub-Procesos de Evento pueden interrumpir o no interrumpir al Proceso
que los contiene. Si no interrumpen, el Sub-Proceso de evento se ejecuta de forma simultnea al Proceso padre. Si interrumpen, el Proceso padre se detiene y no
ser completado an despus de que se complete el Sub-Proceso de evento.Una lnea punteada indica que el proceso no interrumpe, y una lnea slida indica que
s.
Ojo: el evento de inicio de error siempre interrumpe, y el de compensacin nunca interrumpe.
Con Interrupcin:
Sin Interrupcin
Error
El Evento de Inicio por Error
slo se puede utilizar para
detonar Sub-Procesos de
Evento. Debido a la naturaleza
de los Errores, un Sub-Proceso
de Evento con un detonador de
Error siempre interrumpe al
Proceso que lo contiene.
Escalable
Llega un Mensaje de un
Participante y detona el inicio
del Proceso.
Compensacin
El Evento de Inicio de
Compensacin slo se puede
utilizar para detonar Sub-
Procesos de Evento. Este tipo
de Evento se detona cuando
ocurre una compensacin. Este
Evento no interrumpe al
Proceso ya que el Proceso tiene
que haberse completado antes
de poder ser compensado.
Con Interrupcin:
Sin Interrupcin
Con Interrupcin:
Seal
detona el inicio del Sub-
Proceso.
Condicional
Este tipo de Evento se detona
cuando una condicin se vuelve
verdadera.
Sin Interrupcin
Con Interrupcin:
Sin Interrupcin
Con Interrupcin:
Sin Interrupcin
Paralelo Mltiple
Este evento indica que se
REQUIEREN varios detonadores
para que el Proceso se
instancie. Todos los tipos de
detonadores listados en el
Evento de Inicio DEBEN
dispararse para que el Proceso
sea instanciado.
Mltiple
Este evento indica que hay
varias formas de detonar el
Proceso. Slo una de ellas se
REQUIERE.
Seal
detona el inicio del Sub-
Proceso.
Las Compuertas se utilizan para controlar la interaccin de los Flujos de Secuencia cuando estos convergen o divergen dentro de un Proceso. Si el flujo no necesita ser controlado, no se necesita una Compuerta. El trmino Compuerta implica que hay un mecanismo de admisin que permite o impide el paso a travs de la Compuerta es decir, cuando los tokens llegan a la Compuerta, pueden ser combinados al entrar o divididos al salir segn se invocan los mecanismos de la Compuerta.
Explicacin Usos tpicos
El evento de inicio nulo no tiene un
detonador y se utiliza ms bien como una
sea visual para explicitar dnde inicia el
Proceso.
*Para indicar dnde inicia un
Proceso. *Cuando el inicio de un
Proceso no depende de que
ocurra algo.
Indica que el Proceso iniciar cuando se
reciba un determinado mensaje.
*Cuando se requiere la
aprobacin de un agente externo
para dar inicio al Proceso.
Los Eventos de Inicio se utilizan para condicionar el inicio de un Proceso o Sub-Proceso. Existen diferentes tipos de disparadores, es decir de sucesos que provocan
que un Evento de Inicio se active. Al dispararse el Evento de Inicio, se arranca el Proceso. Existen 3 familias de Eventos de Inicio: 1) Aquellos que se utilizan para
iniciar Procesos. 2) Aquellos que se utilizan para iniciar Sub-Procesos y 3) Aquellos que se utilizan para iniciar Sub-Procesos de Evento.
Generalidades: Existen 7 eventos de inicio para Procesos. Los eventos de inicio para Procesos indican qu tiene que ocurrir para que un Proceso comience. Los
Eventos de inicio no pueden tener flujos de secuencia entrantes.
El Proceso iniciar en una fecha especfica
o cada vez que se alcance un punto de un
ciclo temporal especfico (por ejemplo,
cada Viernes a las 6:00 p.m.).
*Cuando el Proceso debe llevarse
acabo cada cierto tiempo.
El Proceso iniciar cuando se detecte una
Seal especfica. Una Seal es un
comunicado pblico (por ejemplo, un
anuncio publicado en la intranet de la
Empresa) que no tiene un destinatario
especfico. Todos los Procesos y
Participantes pueden ver la seal y
reaccionar o no a ella. Es como una
bengala, cualquiera puede verla y decidir si
reaccionar o no. Varios Procesos pueden
ser detonados por la misma Seal.
*Cuando el Proceso es la
respuesta del participante a un
anuncio o suceso difundido
El Proceso iniciar cuando se cumpla una
condicin fijada por el modelador. Hay
muchos tipos de condiciones posibles, por
ejemplo "cuando la eficiencia del motor B
baje a menos del 10%", o "cuando la
temperatura suba a 60". La nica
restriccin es que la condicin no puede
hacer referencia a un objeto que se genere
durante el Proceso, ya que el Proceso an
no ha iniciado. Para que el Evento se
vuelva a detonar la condicin tiene que
primero volverse falsa y luego volver a
hacerse verdadera.
*Cuando el inicio del Proceso
depende de condiciones internas
a la organizacin. *Cuando se
necesita monitorear y responder
al estatus de algo.
Este evento permite especificar varias
formas de detonar un Proceso. Por
ejemplo, se puede detonar por la llegada
de un Mensaje o la deteccin de una Seal.
Basta con que se cumpla uno de los
Eventos especificados para que el Proceso
inicie.
*Cuando hay varias razones para
detonar el Proceso. *Cuando hay
que reaccionar a una condicin
interna o obedecer una orden de
un superior
Este evento indica que se requieren varios
eventos para detonar el Proceso. Por
ejemplo se podra requerir la llegada de un
Mensaje y el cumplimiento de una
condicin. El Proceso inicia hasta que
ocurren TODOS los eventos especificados.
*Cuando un Proceso requiere que
se den las condiciones correctas y
adems la aprobacin de un
agente externo o superior.
En realidad la nica forma de detonar un
Sub-Proceso es que le llegue un token por
el flujo de secuencia entrante. No puede
ser detonado por un evento. Es por eso
que, para Sub-Procesos, el evento de inicio
nulo es slo una sea visual que explicita
dnde inicia el Sub-Proceso.
*Para indicar dnde inicia un Sub-
Proceso.
Slo existe 1 evento de inicio para Sub-Procesos, ya que los Sub-Procesos (igual que una tarea) slo pueden ser detonados por la llegada de un flujo de secuencia
entrante.
El Sub-Proceso iniciar en una fecha
especfica o cada vez que se alcance un
punto de un ciclo temporal especfico (por
ejemplo, cada Viernes a las 6:00 p.m.).
Indica que el Sub-Proceso iniciar cuando
se reciba un determinado mensaje.
Existen 9 tipos de eventos de inicio para Sub-Procesos de Evento. Los eventos de inicio para Sub-Procesos de Evento pueden interrumpir o no interrumpir al Proceso
que los contiene. Si no interrumpen, el Sub-Proceso de evento se ejecuta de forma simultnea al Proceso padre. Si interrumpen, el Proceso padre se detiene y no
ser completado an despus de que se complete el Sub-Proceso de evento.Una lnea punteada indica que el proceso no interrumpe, y una lnea slida indica que
s.
Ojo: el evento de inicio de error siempre interrumpe, y el de compensacin nunca interrumpe.
El evento de inicio de Error se activa
cuando ocurre un error durante un
Proceso. El error puede ser un error
inesperado o puede ser un error arrojado
por un evento intermedio de error. El
evento de inicio de error siempre
interrumpe al Proceso que lo contiene. Se
utiliza para lidiar con errores inesperados
que impiden realizar satisfactoriamente el
Proceso.
*Para indicar cmo manejar
errores inesperados.
El evento escalable se utiliza cuando un
participante tiene un impedimento u
obstculo que le impide terminar su tarea
y que requiere la intervencin de alguien
que tenga un nivel ms alto de
responsabilidad. Esto quiere decir que este
evento responde a una peticin de
escalamiento realizada por otro
participante. Por lo general la peticin que
detona este evento se arroja en un evento
intermedio o de fin escalable que aparece
en otra parte del diagrama.
*Cuando un puesto de
responsabilidad alto necesita
atender los problemas de sus
subalternos.
El evento de compensacin se utiliza
cuando un Sub-Proceso que ya se
complet exitosamente tiene que ser
revertido (compensado). El evento, y por
ende el Sub-Proceso que lo contiene, se
detona cuando un evento de fin o un
evento intermedio solicita la
compensacin de la actividad en la que
reside el Sub-Proceso de evento que
contiene al evento de inicio de
compensacin.
*Para definir cmo debe ser
revertido un Sub-Proceso.
*Para comunicar un Proceso
padre con sus Sub-Procesos
Este evento de inicio permite especificar
varios detonadores. El Evento se detonar
cuando todos los detonadores
especificados se presenten. Se pueden
incluir detonadores como mensajes,
seales, condiciones, etc.
*Cuando se necesitan cumplir
varias condiciones para detonar el
Sub-Proceso
El evento de inicio tiene varios
detonadores. Cada vez que ocurra
cualquiera de ellos se iniciar una instancia
del Sub-Proceso.
*Cuando hay varios motivos para
detonar un Sub-Proceso
*Para comunicar un Proceso
padre con sus Sub-Procesos
Ejemplo: diagrama
Ejemplo: diagrama
Ejemplo: diagrama
Ejemplo: explicacin Mejores prcticas
En el diagrama se muestra un Proceso de creacin y envo de un
reporte. El evento de inicio se utiliza para indicar dnde comienza
el Proceso. Note que si el reporte no es aceptado y tiene que ser
redactado de nuevo, el flujo que sale de la compuerta se conecta
a la primera tarea y no al evento de inicio. El evento de inicio
nunca debe tener flujos entrantes.
*Si el diagrama es
extremadamente sencillo no
utilice el evento de inicio
nulo, pues puede resultar
superfluo
En este fragmento de un Proceso de aprobacin de crdito se
utiliza el evento de inicio de mensaje para indicar que el Proceso
iniciar tan pronto se reciba una solicitud de crdito.
En este Proceso de cmo llevar a cabo una junta semanal se utiliza
el evento de inicio por temporizador para indicar que el Proceso
debe realizarse cada Lunes a las 9:00. El Proceso iniciar el da y a
la hora especificada.
En este Proceso la empresa detecta un anuncio publicado por uno
de sus proveedores que advierte de un lote de piezas defectuosas.
No se trata de un mensaje dirigido directamente a la empresa sino
de una seal que el proveedor probablemente ha hecho pblica a
todos sus clientes, quizs a travs de su pgina web o intranet.
Esta seal detona ste Proceso diseado para lidiar con el
problema.
Este evento de venta de acciones da inicio cuando el precio de las
acciones cae en un 10%. La cada del precio de las acciones es la
condicin y tan pronto esta se vuelve verdadera el Proceso se
dispara.
Este Proceso de limpiar un cuarto se puede detonar de dos formas
distintas: al recibir un mensaje de parte de un superior ordenando
que limpie el cuarto o cuando se cumpla la condicin de que haya
un mal olor en el cuarto.
El Proceso del ejemplo que trata sobre asistir a un evento slo
iniciar si se presentan dos detonadores al mismo tiempo: que sea
sbado (temporizador) y que se haya recibido una invitacin
(mensaje).
En este ejemplo se utiliza el evento de inicio nulo para indicar en
dnde inicia el Sub-Proceso "realizar preparativos de viaje", que es
parte de un Proceso para dar una conferencia en el extranjero.
*Si el Sub-Proceso es muy
sencillo no utilice un evento
de inicio. *No utilice
eventos de inicio en cajas
paralelas
El ejemplo describe el Proceso de creacin de un proyecto de
investigacin, quizs acadmico o laboral. El Sub-Proceso de
evento incluido en el Proceso se detona cuando llega la fecha de
entrega. Se utiliza un evento de inicio temporizador con
interrupcin pues al llegar la fecha, se debe interrumpir el
Proceso, es decir se debe dejar de trabajar en el proyecto y se
debe enviar lo que se tenga. Note que cuando se utiliza un evento
que interrumpe, al completarse el Sub-Proceso de evento su
Proceso padre se dar por terminado y no se realizarn las tareas
que faltaban a la hora de dispararse el Sub-Proceso de evento. Es
decir, si an no se aadan las imgenes de apoyo cuando llega la
fecha de entrega, ests no se aadirn an despus de que se
enve el proyecto.
El Proceso es de un restaurante que ofrece servicio a domicilio. El
evento de inicio por mensaje se utiliza para detonar un Sub-
Proceso que se encarga de alterar el pedido si el cliente as lo
solicita.
En este ejemplo el evento de inicio de error se utiliza dentro de un
Sub-Proceso llamado "hacer reservaciones". Si ocurre un error
durante el Proceso de hacer reservaciones, el Proceso se
interrumpe y se dispara un Sub-Proceso de evento en el que se
maneja el error, avisando al cliente del problema y confirmando
su informacin de tarjeta de crdito.
Se muestra el ejemplo de un banco que atiende a un cliente
porque ste desea actualizar su informacin personal. El asesor
atiende al cliente, pero ste podra sbitamente solicitar al aesor
que se aumente su lmite de crdito. Esto detona un sub-proceso
(el del contenedor de arriba) en el cual el asesor pide al cliente
que espere y luego transmite la responsabilidad de atender al
cliente al gerente, pues no est bajo su responsabilidad manejar
aumentos de lmite de crdito. Esto detona el evento de inicio
escalable (que es el que nos interesa) y ejecuta un sub-proceso
que ha de llevar acabo el gerente. El evento escalable se utiliza de
esta forma para solicitar la ayuda de un nivel ms alto de
responsabilidad.
En el ejemplo se utiliza un Sub-Proceso de evento con un evento
de inicio de compensacin para definir cmo se compensar el
Sub-Proceso "Reservaciones". Note que el Sub-Proceso de evento
se utiliza para arrojar la compensacin de las actividades
"Reservar hotel" y "Reservar vuelo" pero adems aade
comportamiento al Proceso pues agrega la tarea "Actualizar
historial del cliente". En el diagrama no se muestra el evento que
detona al evento de inicio. ste podra ser un evento intermedio o
de fin que aparezca ms adelante en el Proceso.
En este Proceso se atiende la orden de un cliente. Si durante la
ejecucin del Proceso se cumple la condicin de que las
existencias se reducen por debajo de un nivel mnimo se dispara el
evento de inicio de Sub-Proceso y se ejecuta la actividad
"Reabastecer inventario".
En este ejemplo se utilizan los eventos de seal para comunicar un
Proceso con uno de sus Sub-Procesos. Durante el flujo normal se
arroja la seal "Conceptos Completados". Esta seal detona el
evento de inicio del Sub-Proceso de Evento, el cual no interrumpe
a su Proceso padre. Al completarse el diseo de la portada otra
seal comunica al Sub-Proceso con el Proceso padre. El Proceso
padre no continuar, es decir, no se publicar el libro, hasta que el
Sub-Proceso arroje la seal "Portada Completada". Note que a
diferencia de los mensajes, las seales no tienen que provenir de
un participante externo, sino que un mismo participante puede
enviar y recibir una seal.
El diagrama describe el Proceso de creacin de un libro. El escritor
desea mantener al tanto a su asesor, lo cual se modela a travs
del Sub-Proceso "mantener al tanto a mi asesor". El Sub-Proceso
se detona cada viernes o cada que su asesor lo solicite. Esto puede
ocurrir en cualquier fase del Proceso.
El diagrama describe el Proceso de creacin de un libro. El escritor
desea mantener al tanto a su asesor, lo cual se modela a travs
del Sub-Proceso "mantener al tanto a mi asesor". El Sub-Proceso
se detona cada viernes, pero slo si el asesor lo solicita. Si es
viernes pero el asesor no solicita un avance, no se le enviar. Y si
el asesor solicita un avance pero no es viernes, tampoco se le
enviar.
En este ejemplo se utilizan los eventos de seal para comunicar un
Proceso con uno de sus Sub-Procesos. Durante el flujo normal se
arroja la seal "Conceptos Completados". Esta seal detona el
evento de inicio del Sub-Proceso de Evento, el cual no interrumpe
a su Proceso padre. Al completarse el diseo de la portada otra
seal comunica al Sub-Proceso con el Proceso padre. El Proceso
padre no continuar, es decir, no se publicar el libro, hasta que el
Sub-Proceso arroje la seal "Portada Completada". Note que a
diferencia de los mensajes, las seales no tienen que provenir de
un participante externo, sino que un mismo participante puede
enviar y recibir una seal.
Familia: Eventos de Fin
Elemento 1: Eventos de Fin
Evento de Fin Nulo No tiene un resultado definido.
Evento de Fin de
Mensaje
Indica el envo de un Mensaje a
un Participante al concluir el
Proceso.
Los Eventos de Fin se utilizan para definir dnde termina un proceso o una rama de un proceso y qu acciones se deben realizar tras su finalizacin. Existen 9 tipos
de eventos de Fin. Se representan con un crculo de lnea gruesa. El marcador que se coloque dentro del crculo define el tipo del evento.
Evento de Fin de
Error
Un Error particular se genera.
Todos los caminos activos en el
Sub-Proceso actual son
finalizados.
Evento de Fin
Escalable
Una Escalada debe detonarse.
Otros caminos activos no son
afectados y continan
ejecutndose.
Evento de Fin
Cancelacin
Es usado en un Sub-Proceso de
Transaccin. La Transaccin
debe ser cancelada y se detona
una Cancelacin de Evento
Intermedio en la frontera del
Sub-Proceso.
Evento de Fin de
Compensacin
Se activa una compensacin.
Evento de Fin
Seal
Se debe transmitir una Seal
cuando se termine el Proceso.
Evento de Fin
Terminador
Las Actividades del Proceso
deben finalizarse
inmediatamente.
Evento de Fin
Mltiple
Finalizar el proceso implica
mltiples consecuencias.
Se utiliza como una sea visual para
indicar dnde termina el proceso o una
rama del proceso. No implica la realizacin
de ms acciones ni un suceso en especfico.
Debajo de su figura se puede escribir
brevemente el estado final del proceso.
*Indicar claramente dnde
termina un proceso.
Se utiliza para mandar un mensaje al final
de un proceso o de la rama de un proceso.
Cuando el flujo llega a este evento, ese
camino se termina y se enva un mensaje a
algn participante o agente externo. Un
participante (es decir, un contenedor) no
puede enviarse un mensaje a s mismo.
*Notificar el resultado del
proceso a un participante
externo.
Los Eventos de Fin se utilizan para definir dnde termina un proceso o una rama de un proceso y qu acciones se deben realizar tras su finalizacin. Existen 9 tipos
de eventos de Fin. Se representan con un crculo de lnea gruesa. El marcador que se coloque dentro del crculo define el tipo del evento.
Se utiliza cuando una rama del proceso
finaliza en un error. A diferencia del evento
de fin de terminacin, el evento de fin por
error arroja una seal a la que se puede
reaccionar. La seal que enva el error no
llega a otros procesos o contenedores de la
misma jerarqua, slo el proceso padre
puede reaccionar a un error en uno de sus
sub-procesos. (Vase Evento Intermedio de
Error).
*Modelar y manejar errores
comunes.
Se utiliza cuando un participante encuentra
un obstculo que le impide completar su
tarea y necesita ayuda de alguien con un
nivel de responsabilidad ms alto. El que
una rama termine en un Evento de Fin
Escalable no interrumpe la ejecucin de las
otras ramas del proceso. El Evento de Fin
escalable transmite una seal a la que
pueden reaccionar el proceso padre u
otros participantes (contenedores). No es
necesario que haya un evento intermedio
o de inicio que reaccione al evento de fin
escalable, ste se puede utilizar para
indicar simplemente que el participante
debe buscar ayuda de sus superiores.
*Modelar y manejar obstculos
comnes que requieren de la
ayuda de un puesto de mayor
responsabilidad.
Se utiliza exclusivamente en transacciones.
ste evento indica que se debe cancelar la
transaccin y se deben compensar, es decir
deshacer, todas las tareas que se hayan
realizado. Difiere del evento de
compensacin en que implica a
cancelacin de una transaccin y por lo
tanto afecta a todos los involucrados en la
transaccin aunque su lado del proceso no
sea visible.
*Modelar y manejar errores
comunes dentro de una
transaccin.
Se utiliza para compensar, es decir,
deshacer el trabajo realizado. Se puede
utilizar de dos formas: 1. especificando el
nombre de la actividad que debe ser
compensada. En este caso slo la actividad
nombrada ser compensada. 2. sin
especificar el nombre de una actividad. En
este caso TODAS las actividades que sean
compensables dentro del proceso sern
compensadas. Ojo: slo se pueden
compensar las actividades que han sido
completadas exitosamente y que tienen un
evento intermedio o de inicio de
compensacin.
*Para deshacer el trabajo
realizado.
*Cuando un cliente cancela un
servicio que haba solicitado.
*Comunicar procesos con sus sub-
procesos. *Publicar el resultado
de un proceso.
Se utiliza para terminar le ejecucin de un
proceso. A diferencia del evento de error,
el evento terminador no interrumpe a su
proceso padre, sino que solamente
interrumpe al proceso en el que se
encuentra y a procesos de nivel inferior.
Adems, el evento de fin no emite seales
a las que se pueda reaccionar. Es muy
utilizado para detener bucles o evitar que
se disparen eventos temporizadores
(Vase el ejemplo).
*Para detener bucles.
*Para finalizar procesos en los
que se ha utilizado un
temporizador que responde a una
fecha de entrega.
El evento de fin mltiple se utiliza para
combinar varios eventos de fin en uno
solo. Por ejemplo para declarar un error y
adems enviar un mensaje. Su
comportamiento depende de qu
combinacin de eventos de fin se elija.
*Su uso ms comn es combinar
eventos de fin de mensaje con
terminadores, compensacin, o
error. *Declarar un error y
avisar a los interesados.
*Enviar un mensaje y terminar un
bucle.
Ejemplo: diagrama
Se modela el proceso de creacin de un libro. El Evento de Fin
Nulo se utiliza para marcar dnde termina el proceso. Note que
debajo del evento de fin se escribe el estatus del proceso: "libro
terminado". Escribir este estatus es opcional y no indica que se
deban realizar ms acciones. Note tambin que en un diagrama
tan sencillo como ste podra fcilmente omitirse el evento de fin
sin perder claridad.
*No utilice el evento de fin
nulo si el proceso es muy
sencillo o si no tiene
bifurcaciones.
Una empresa busca iniciar contrataciones, para lo cual debe
buscar empleados y entrevistarlos. Finalmente, el proceso de
contratacin termina al avisar del resultado a los aspirantes.
*El mensaje enviado tiene
que ir a un participante
distinto del que enva el
mensaje.
Se modela un proceso de cobranza. La empresa hace el cargo a la
tarjeta del cliente, si la tarjeta resulta no ser vlida, se produce un
evento de fin de error con el ttulo "Error de pago". Quizs un
proceso de jerarqua mayor que contenga a este proceso de
cobranza pueda reaccionar al error de pago.
*Si el proceso en el que
utiliz el evento de fin de
error tiene un proceso
padre, incluya en ste ltimo
un evento intermedio de
frontera de error, para
reaccionar y corregir el
error.
Se muestra el ejemplo de un banco que atiende a un cliente que
desea actualizar su informacin personal. El asesor atiende al
cliente, pero ste podra sbitamente solicitar al aesor que se
aumente su lmite de crdito. Esto detona un sub-proceso (el del
contenedor de arriba) en el cual el asesor pide al cliente que
espere y luego transmite la responsabilidad al gerente, pues no
est bajo su responsabilidad manejar aumentos de lmite de
crdito. El evento de fin escalable (que es el que nos interesa) se
utiliza para hacer esta transferencia de responsabilidad. Esto
detona el evento de inicio escalable que se encuentra en el carril
del gerente y ejecuta un sub-proceso. El evento escalable se utiliza
de esta forma para solicitar la ayuda de un nivel ms alto de
responsabilidad.
Se modela la transaccin de hacer reservaciones de una agencia
de viajes. La transaccin tiene dos actividades: reservar vuelo y
reservar hotel. Se utilizan dos eventos de fin de cancelacin. Si se
produce un error en cualquiera de las reservaciones, hotel o
vuelo, se activa el evento de fin de cancelacin y la transaccin se
cancela. Esto implica que se compensan las dos actividades de la
transaccin y se activa el evento intermedio de cancelacin que
est en la frontera de la transaccin. Este evento solicita que se
informe al cliente de la cancelacin.
Se modela el proceso de registro de un cliente en una base de
datos para enviarle informacin peridicamente. En el proceso se
registra al cliente y se le enva un correo para confirmar que desea
inscribirse y recibir correos de la compaa peridicamnte. En el
correo se le da la opcin de confimrar su registro o cancelarlo. Si
lo cancela, el proceso lleva a un evento de fin de compensacin.
Note que slo la tarea "Registrar cliente en base de datos" ser
compensada, ya que es la nica que tiene un evento de
compensacin en la frontera. El modelador ha considerado que las
otras tareas, que consisten en enviar y recibir mensajes, no
requieren compensacin.
Se modela el proceso de escritura y publicacin de un libro. Los
eventos de seal se utilizan para comunicar el proceso de creacin
del libro con su sub-proceso de diseo de la portada. Se utiliza un
evento de fin de seal en el sub-proceso para avisar a su proceso
padre que la portada ha sido completada. Esta seal es capturada
por el evento intermedio "Portada completada" y tras recibir esta
seal, el proceso contina a la publicacin del libro.
Se modela un proceso de creacin y envo de un reporte. Dentro
del modelo hay un bcle infinito que indica que cada semana se
debe solicitar una prrroga. Sin embargo, si el reporte se termina
y se enva se alcanza un evento terminador que detiene toda la
actividad en el proceso. Esto sirve para detener el bcle y
bsicamente indica que tan pronto se termine el reporte se debe
dejar de solicitar prrrogas. Note que no sera prudente utilizar un
evento de error, pues la terminacin del reporte, aunque ocasiona
el fin del proceso no es un error, sino que implica la completud
exitosa del proceso. Esta es una de las formas ms comunes de
utilizar el evento terminador.
Se modela un proceso de cobranza. La empresa hace el cargo a la
tarjeta del cliente, si la tarjeta resulta no ser vlida, se produce un
evento de fin mltiple que indica que se deben realizar dos cosas:
declarar un error, y enviar un mensaje de notificacin al cliente. El
error puede ser manejado por un proceso de nivel superior.
Familia: Eventos Intermedios
Elemento 1: Evento Intermedio
Evento Intermedio
Nulo
Slo es vlido en flujo normal.
No tiene un detonador
especfico, pero es definido
como evento que arroja.
Arrojar
Los eventos intermedios se utilizan para indicar dnde se espera que ocurra algo dentro del proceso. El evento intermedio puede arrojar o capturar. Arrojar quiere
decir enviar una seal, un token, o una informacin. Capturar quiere decir recibir cualquiera de estas cosas. Cuando un token llega a un evento que caputra, ser
retenido ah hasta que el mensaje, informacin o evento esperado suceda y despus continuar por el flujo de salida.
Evento Intermedio
de Mensaje
Puede ser usado para enviar o
recibir un Mensaje.
En esta seccin se cubren los eventos intermedios en lnea. Es decir aquellos que no estn adjuntos a la frontera de un
evento sino que son parte del flujo normal. Algunos eventos intermedios se encuentran en variantes que arrojan y capturan,
otros slo realizan una de estas funciones.
Capturar
Capturar
Evento Intermedio
Temporizador
Acta como un mecanismo de
retraso
Arrojar
Evento Intermedio
Escalable
Provoca una Escalada.
Evento Intermedio
de Mensaje
Puede ser usado para enviar o
recibir un Mensaje.
Arrojar
Evento Intermedio
de Compensacin
Indica que es necesaria una
compensacin.
Capturar
Evento Intermedio
Condicional
This type of event is triggered
when a Condition becomes
true.
Arrojar
Capturar
Evento Intermedio
de Enlace
A Link is a mechanism for
connecting two sections of a
Process. Link Events can be
used to create looping
situations or to avoid long
Sequence Flow lines. Link Event
uses are limited to a single
Process level (i.e., they cannot
link a parent Process with a Sub-
Process).
Arrojar
Capturar
Arrojar
Capturar
Evento Intermedio
Mltiple
This means that there are
multiple Triggers assigned to
the Event. If used within normal
flow, the Event can catch the
Trigger or throw the Triggers.
When used to catch the
Trigger, only one of the
assigned Triggers is required
Evento Intermedio
de Seal
This type of event is used for
sending or receiving Signals. A
Signal is for general
communication within and
across Process Levels, across
Pools, and between Business
Process Diagrams. A BPMN
Signal is similar to a signal flare
that shot into the sky for
anyone who might be
interested to notice and then
react. Thus, there is a source of
the Signal, but no specific
intended target.
Capturar
Evento Mltiple
Paralelo
This means that there are
multiple triggers assigned to the
Event. If used within normal
flow, the Event can only catch
the trigger.
Unlike the normal Multiple
Intermediate Event, all of the
assigned triggers are required
for the Event to be triggered.
Elemento 2:Evento Intermedio de frontera
Interruptor
No interruptor
Los eventos intermedios de frontera se colocan en la orilla de una actividad y pueden reaccionar a algo que sucede tanto dentro como fuera de la actividad. Slo
capturan (reaccionan), no arrojan. Pueden interrumpir o no interrumpir la actividad en la que estn empotrados. Excepciones son los eventos de error y
cancelacin, que siempre interrumpen. Y el evento de compensacin que nunca interrumpe.
Evento Intermedio
en la Frontera por
Mensaje
La llegada de un mensaje
detona este evento y crea un
flujo de excepcin.
Interruptor
No interruptor
Interruptor
No interruptor
Evento Intermedio
en la Frontera de
Escalada
Una seal de escalada detona
este evento y genera un flujo de
excepcin. Una escalada es un
obstculo o error que debe ser
resuelto con la ayuda de alguien
con un puesto mayor de
responsabilidad.
Evento Intermedio
en la Frontera por
Temporizador
La llegada de una fecha
especfica o ciclo temporal
detona este evento y crea un
flujo de excepcin.
Interruptor
Evento Intermedio
en la Frontera de
Error
La ocurrencia de un error
especificado dentro de la
actividad detona este evento y
genera un flujo de excepcin.
Interruptor
Evento Intermedio
en la Frontera de
Cancelacin
Un error o cancelacin dentro
de la transaccin detona este
evento.
Evento Intermedio
en la Frontera de
Compensacin
Indica que una actividad es
compensable. Se detona
cuando un evento de
compensacin ordena la
compensacin de la actividad.
Interruptor
No interruptor
Evento Intermedio
en la Frontera
Condicional
Se detona cuando una
condicin especificada evala a
verdadero. La condicin debe
hacer referencia a informacin
interna a la actividad.
Interruptir
No interrumpir
Interruptor
No interruptor
Interruptor
No interruptor
Evento Intermedio
en la Frontera
Mltiple
Un Evento Mltiple indica que
hay varios detonadores
asignados al evento. El Evento
slo puede "capturar". Slo se
requiere UNO de los
detonadores asignados para
detonar el evento. Despus de
detonado, el evento cambiar el
Flujo Normal a un Flujo de
Excepcin.
La deteccin de una seal
detona el evento y genera un
flujo de excepcin.
Evento Intermedio
en la Frontera por
Seal
Evento Intermedio
en la Frontera
Mltiple Paralelo
Un Evento Mltiple indica que
hay varios detonadores
asignados al evento. El Evento
slo puede "capturar". A
diferencia del Evento Mltiple
normal, se requieren TODOS de
los detonadores asignados para
detonar el evento. Despus de
detonado, el evento cambiar el
Flujo Normal a un Flujo de
Excepcin.
Se utiliza simplemente para indicar que se
ha alcanzado o completado una fase
durante el proceso. No se puede utilizar
para provocar una reaccin en otro
participante o para detonar sub-procesos.
Ms bien sirve para marcar etapas o hitos
en un proceso.
*Marcar la finalizacin de etapas
clave de un proceso. *Marcar un
cambio de estado en un proceso.
Los eventos intermedios se utilizan para indicar dnde se espera que ocurra algo dentro del proceso. El evento intermedio puede arrojar o capturar. Arrojar quiere
decir enviar una seal, un token, o una informacin. Capturar quiere decir recibir cualquiera de estas cosas. Cuando un token llega a un evento que caputra, ser
retenido ah hasta que el mensaje, informacin o evento esperado suceda y despus continuar por el flujo de salida.
Se utiliza para enviar o recibir mensajes a
medio proceso. En su modo de captura, el
proceso se detiene hasta que llegue el
mensaje esperado y luego continua. En su
modo de arrojar simplemente se emite el
mensaje especificado. Los mensajes
TIENEN que ir dirigidos a otro participante
(es decir a otro contenedor o carril).
*Enviar reportes, avisos,
recordatorios, etc.
*Indicar que se debe esperar la
aprobacin o solicitud de un
agente externo.
En esta seccin se cubren los eventos intermedios en lnea. Es decir aquellos que no estn adjuntos a la frontera de un
evento sino que son parte del flujo normal. Algunos eventos intermedios se encuentran en variantes que arrojan y capturan,
otros slo realizan una de estas funciones.
Se utiliza para marcar una pausa en el
proceso. Al llegar al evento, el flujo del
proceso se interrumpe. Se reanudar
cuando pase el tiempo o llegue la fecha
especificados.
*Esperar un trmite que toma
tiempo.
*Marcar tiempos lmite. *Enviar
recordatorios despus de cierto
tiempo. *Crear bucles de
tiempo: es decir repetir una tarea
cada cierto tiempo.
El evento de escalada se utiliza para
modelar obstculos o errores que por lo
general no impiden que el proceso se
complete, pero requieren acciones extras
para lidiar con ellos. Por lo general
requerir la intervencin de una persona
con un puesto de responsabilidad ms alto.
Este evento slo arroja. La seal que arroja
viaja por todo el proceso, al proceso padre
y a los sub-procesos. Tambin llega a otros
contenedores y puede detonar eventos de
escalada de inicio o de frontera.
*Cuando se presenta un
obstculo que puede ser
manejado.
*Cuando el obstculo requiere la
intervencin de un superior.
Se utiliza para enviar o recibir mensajes a
medio proceso. En su modo de captura, el
proceso se detiene hasta que llegue el
mensaje esperado y luego continua. En su
modo de arrojar simplemente se emite el
mensaje especificado. Los mensajes
TIENEN que ir dirigidos a otro participante
(es decir a otro contenedor o carril).
*Enviar reportes, avisos,
recordatorios, etc.
*Indicar que se debe esperar la
aprobacin o solicitud de un
agente externo.
Indica que se necesita realizar una
compensacin. Compensar una actividad
quiere decir deshacerla. La compensacin
slo se puede realizar si la actividad ya fue
completada exitosamente. El modelador
debe especificar qu actividad es la que
hay que compensar.
*Deshacer actividades que el
cliente ya no desea.
*Responder a cancelaciones o
errores.
El flujo se detendr hasta que se cumpla
una condicin. La condicin debe hacer
referencia a datos, estados o informacin
interna al proceso o participante. Debido a
esta restriccin no se puede utilizar el
evento condicional en vez de un evento de
mensaje o seal.
*Monitorear y reaccionar a
condiciones internas al proceso
tales como eficiencia,
productividad, etc.
Se utilizan siempre en pares, un arrojador
con un capturador. Funciona como un flujo
de secuencia virtual, es decir el token entra
por el arrojador y sale por el capturador sin
ms condiciones. El
evento de enlace que arroja es como la
entrada al tnel y el de captura es la salida.
El evento que arrroja y el que captura
deben tener etiquetas idnticas.
El evento intermedio de enlace
cumple dos funciones: 1. Se utiliza
como objeto "go-to" para ahorrar
espacio. Te lleva de un punto del
proceso a otro. 2. Para modelar
procesos que se van a imprimir y
evitar confucin a la hora de
cambiar de pgina. Hay veces que
en el cambio de pgina no queda
muy claro cmo siguen los flujos
de secuencia.
El evento intermedio mltiple se utiliza
para combinar varios tipos de eventos
intermedios en uno solo. Si el evento
mltiple arroja, slo se pueden utilizar
tipos de evento que arrojen. Si captura,
slo se pueden utilizar eventos que
capturen y basta con que ocurra uno de los
detonadores especificados para que se
detone el evento.
*Cuando el proceso debe esperar
a que suceda uno de varios
eventos antes de continuar.
El evento de seal se utiliza para arrojar o
esperar una seal. Una seal es un
mensaje que se difunde sin un destinatario
especfico. Se pblica de forma que
muchos lo puedan ver y decidir si
reaccionar o no. La seal llega a todo lo
largo y ancho del proceso, incluyendo sus
sub-procesos, participantes, y procesos
padre. Se puede hacer una analoga con
una bengala. La bengala se arroja y los que
la vean pueden decidir si reaccionar o no.
La seal, a diferencia del mensaje, puede
ser emitida y recibida por un mismo
participante.
*Para comunicarse con varios
participantes usando un solo
evento. *Para enviar o recibir un
aviso publicado en un medio
masivo como una intranet, una
pgina web, un peridico, etc.
*Para comunicar un proceso con
sus sub-procesos.
ste evento puede tener un conjunto de
detonadores, pero a diferencia de evento
intermedio mltiple, se requiere que se
presenten TODOS los detonadores para
que el evento se dispare.
*Cuando el proceso debe esperar
a que sucedan varios eventos
simultneamente para continuar.
Los eventos intermedios de frontera se colocan en la orilla de una actividad y pueden reaccionar a algo que sucede tanto dentro como fuera de la actividad. Slo
capturan (reaccionan), no arrojan. Pueden interrumpir o no interrumpir la actividad en la que estn empotrados. Excepciones son los eventos de error y
cancelacin, que siempre interrumpen. Y el evento de compensacin que nunca interrumpe.
La recepcin de un mensaje determinado
hace que se active el flujo de excepcin
que sale del evento. Si se utiliza en su
forma interruptora, la actividad a la que
est adjunto se interrumpe.
*Manejar solicitudes de clientes
cuando el trabajo ya ha
comenzado.
*Reaccionar a peticiones de la
administracin de la empresa.
El evento se detona cuando sucede una
escalada dentro de la actividad a la que
est adjunto. Una escalada es un obstculo
o error que no impide la realizacin de la
actividad pero que puede requererir de
trabajo adicional para que sta sea
completada exitosamente. Al detonarse el
evento se activa el flujo de excepcin que
sale de l. Si se utiliza en su forma
interruptora, la actividad a la que est
adjunto se interrumpe.
*Manejar obstculos y errores
comnes sin interrumpir el
proceso.
La llegada de una fecha especfica o un
ciclo temporal (por ejemplo, cada viernes)
hace que se detone el evento. Si es
interruptor, la actividad se detiene y el
flujo se desca hacia el flujo de excepcin
que sale del evento. De otra forma la
activida contina y adems se sigue de
forma simultnea el flujo de excepcin.
*Manejar retrasos y fechas lmite.
Este evento se detona cuando ocurre un
error en la actividad a la que est adjunto.
Al ser detonado interrumpir
inmediatamente a la actividad y desviar el
flujo hacia un flujo de excepcin que sale
del evento. Se utiliza para responder a y
manejar errores. Se puede nombrar el
error especfico al que debe reaccionar o
se puede dejar sin etiquetas, lo cual quiere
decir que ser detonado por cualquier
error.
*Manejar errores comunes.
Se utiliza exclusivamente en Transacciones.
Siempre interrumpe. Se detona cuando se
activa un evento de cancelacin de fin
ubicado dentro de la transaccin o cuando
una de las partes involucradas en la
transaccin cancela. (Vase Transacciones
para ms detalles sobre su
comportamiento). Al ser detonado,
cancelar la transaccin interrumpir los
procesos contenidos en ella y desviar el
flujo hacia un llamado "flujo de excepcin",
es decir un flujo que sale del evento
fronterizo de cancelacin.
*Para manejar la cancelacin de
una transaccin, ya sea por un
error propio o de otro
participante involucrado en la
transaccin.
Se utiliza para modelar cmo se debe
compensar, es decir, deshacer una
actividad. Nunca interrumpe, pues no se
puede compensar una actividad a menos
que haya sido completada exitosamente.
Este evento se detona cuando algn otro
evento, por ejemplo un evento de
compensacin o cancelacin solicita la
compensacin de la actividad. Si una
actividad no tiene un evento de
compensacin fronterizo sta no podr ser
compensada.
*Para manejar la compensacin
de una actividad. *Para indicar
que actividades merece la pena
compensar
El cumplimiento de una condicin detona
el evento. La condicin debe hacer
referencia a informacin, estados de
objetos de datos o estados de elementos
que forman parte del proceso. Si se utiliza
en su froma interruptora, la actividad a la
que est adjunto se detiene y el flujo se
desva hacia el flujo de excepcin que sale
del evento. De otra forma, el flujo de
excepcin se activa simultneamente al
flujo normal.
*Interrumpir actividades cuando
se dan ciertas condicione.
El evento se detona al presentarse uno de
mltiples detonadores seleccionados por el
modelador. Si es interruptor, la actividad
se detiene y el flujo se desca hacia el flujo
de excepcin que sale del evento. De otra
forma la activida contina y adems se
sigue de forma simultnea el flujo de
excepcin.
*Cuando uno de varios eventos
puede requerir la interrupcin de
una tarea.
El evento se detona al recibir una seal que
puede provenir del mismo sub-proceso al
que est adjuntada o de otro proceso o
participante. Al detonarse puede o no
interrumpir la actividad, pero en cualquier
caso dirigir el flujo hacia un flujo de
excepcin, es decir el flujo que sale del
evento de seal.
*Responder a seales externas.
El modelador puede asignar varios
detonadores de captura al Evento. ste se
detona cuando se presentan TODOS los
detonadores. Despus de activarse, el
evento desviar el flujo normal hacia un
flujo de excepcin que sale del evento.
*Cuando una tarea debe ser
interrumpida suceden al mismo
tiempo varios eventos.
Ejemplo: diagrama
Ejemplo: diagrama
Se modela el proceso de creacin de un libro. Los eventos
intermedios nulos marcan hitos en el proyecto. El primero se
utiliza para marcar que se ha completado la fase de planeacin. El
segundo para marcar que se ha desarrollado todo el contenido. El
ltimo evento es un evento de fin que indica que el libro se ha
terminado.
Se modela un proceso de solicitud de una beca. El primer evento
de mensaje arroja (note que el sobre es negro) e indica que se
debe enviar la solicitud de beca antes de que el flujo contine. El
segundo evento de mensaje captura (sobre blanco) e indica que se
debe esperar a recibir el resultado de la solicitud antes de
continuar con el proceso. Una vez recibido el resultado el proceso
contina y la siguiente accin depende del resultado recibido.
En el ejemplo se utiliza el evento temporizador para crear un
bucle o repeticin. Mientras no se complete la tarea recibir pago,
se enviar cada dos das un recordatorio. Esto sucede porque al
llegar al evento temporizador el token se detiene ah por 2 das, y
despus contin por el flujo de salida que lleva a la tarea enviar
recordatorio. El bucle sigue infinitamente hasta que se alcance el
evento de fin terminador que da por terminado todo el proceso
(no slo la rama inferior) (vase Evento de Fin Terminador).
Se muestra un proceso de administracin de un proyecto. Primero
se estima el tiempo requerido para el proyecto, se enva el
estimado al cliente, luego se realiza un plan de proyecto, y
despus se revisa la estimacin inicial. Si la estimacin original es
insuficiente entonces tenemos un problema, que se modela
utilizando el evento intermedio de Escalada. Este evento arroja
una escalada llamada "Riesgo de no cumplir con tiempos". La
escalada arrojada detona el sub-proceso "Manejo de escalda".
Este sub-proceso responde al problema indicando que se debe
solicitar ms personal. Este proceso corre en paralelo al proceso
original, es decir el evento intermedio de escalada simplemente
arroja la escalada y luego el flujo contina hacia la tarea "Arrancar
proyecto", en paralelo se lleva a cabo el sub-proceso de Evento
"Manejo de Escalada".
*Utilice una escalada para
problemas que no impiden
la completud del proceso y
utilice un error para
problemas que requieren
que el proceso se detenga
inmediatamente.
Se modela un proceso de solicitud de una beca. El primer evento
de mensaje arroja (note que el sobre es negro) e indica que se
debe enviar la solicitud de beca antes de que el flujo contine. El
segundo evento de mensaje captura (sobre blanco) e indica que se
debe esperar a recibir el resultado de la solicitud antes de
continuar con el proceso. Una vez recibido el resultado el proceso
contina y la siguiente accin depende del resultado recibido.
El modelo describe el proceso de reservar vuelo y hotel para un
conferencista invitado a un evento. Tras realizar las reservaciones
se confirma la asistencia del conferencista. Si el conferencista dice
que no asistir se utiliza eventos intermedios de compensacin
para ordenar la compensacin de las reservaciones. Note que
cada evento intermedio de compensacin nombra a la actividad
que debe ser compensada. Note tambin que las actividades a
compensar tienen eventos intermedios de compensacin en la
frontera, sin uno de estos eventos la compensacin no es posible.
Se trata de un proceso para hacer caf. Se utiliza el evento
condicional para indicar que no se debe continuar con el proceso
sino hasta que el agua alcance 90C (esta es la condicin). Cuando
esta condicin se cumpla, el proceso continuar.
Los procesos que se muestran en el ejemplo son equivalentes.
Note que los eventos de vnculo se comportan como si hubiera un
flujo de secuencia directo entre las tareas.
El modelo trata sobre preparar la asistencia de un conferencista a
un evento. Despus de reservar su vuelo y cuarto de hotel se
confirma su asistencia una ltima vez. Si el conferencista decide
en ese punto que no podr asistir, entonces se llega al evento
mltiple que arrojar tres eventos: la compensacin de las
reservaciones, y el envo de un mensaje al coordinador del evento.
Se muestra un proceso de crecin y publicacin de una pgina
web y sus aplicaciones. El tcnico especialista en servidores
prepara el servidor y dominio. Al mismo tiempo, el diseador web
y el programador web preparan el contenido que se montar en el
servidor. Cuando estos terminan de preparar el contenido deben
esperar una seal de parte del tcnico. El tcnico enva la seal
tan pronto termina de preparar el servidor. Los otros dos
participantes entonces pueden proseguir a montar sus partes en
el servidor. Note que una sola seal avisa a dos participantes
distintos. (Vase Evento de Fin de Seal para otro uso comn de
las seales).
Se modela el proceso de preparacin de una pizza. Primero se
pide la receta a algn conocido, despus se llega a un evento
intermedio mltiple paralelo. En este evento se tendrn que
cumplir dos detonadores para que el proceso contine: el primero
es de tipo condicional, y la condicin es "tener ganas de pizza", el
segundo es de tipo mensaje y es la recepcin de la receta para
preparar la pizza. Una vez cumplidos AMBOS detonadores, se
continuar a la siguiente actividad: preparar la pizza.
El modelo presenta un proceso en el que se atiende a un cliente,
haciendo reservaciones de vuelo y hotel. Primero se solicita la
informacin de la tarjeta de crdito del clente, despus se realizan
las reservaciones. Pero si llega un mensaje mientras se estn
realizando las reservaciones solicitando actualizar la informacin
de la tarjeta de crdito, el proceso de realizar reservaciones se
interrumpe, se actualiza la informacin de la tarjeta de crdito y
luego se vuelve a realizar el proceso de reservacin. Si no llega el
mensaje mientras se estn realizando las reservaciones, el
llamado flujo de excepcin que conecta el evento de mensaje con
la tarea "Actualizar informacin de tarjeta..." nunca se activar.
Se muestra un proceso en el que se atiende una orden de un
cliente. Si lo que el cliente orden no est en existencia, se activa
el sub-proceso de "obtencin". El sub-proceso de obtencin
implica contactar al proveedor y reabastecer lo que el cliente
orden. Si el proveedor tardar ms de lo esperado en
reabastecer se arroja una escalada, es decir un obstculo o error,
a esta escalada se reacciona informando al cliente que habr un
retraso en su orden. Note que la escalada no interrumpe el
proceso de obtencin. El cliente ser informado y tras completar
la obtencin la orden ser enviada.
Se muestra un proceso de participacin en un concurso. El evento
intermedio temporizador se ha adjuntado a la frontera de la
actividad preparar material para concurso. Si durante la ejecucin
de esta tarea se excede el tiempo especificado por el
temporizador, la tarea se interrumpe (note que las orillas del
evento son slidas y no punteadas), y el flujo pasa a un Evento de
Fin de Error.
El modelo presenta un proceso en el que se atiende a un cliente,
haciendo reservaciones de vuelo y hotel. Primero se solicita la
informacin de la tarjeta de crdito del clente, despus se realizan
las reservaciones. Si durante el proceso de realizar las
reservaciones ocurre un error, ste se interrumpe (note la lnea
slida del evento de error) y el flujo se redirige a un flujo de
excepcin que lleva a la tarea "Notificar al cliente que la
reservacin fall". Note tambin que el evento de error no
nombra un error especfico, esto quiere decir que el evento se
detonar con cualquier error que suceda.
Se muestra una transaccin en la que se realizan reservaciones de
vuelo y hotel. Si ocurre un error en cualquiera de las reservaciones
se activa el evento fronterizo de error, esto interrumpe el proceso
en el que ocurri el error, adems activa un evento de fin de
cancelacin. Esta cancelacin dispara al evento fronterizo de
cancelacin que interrumpe la transaccin entera y adems
genera un flujo de excepcin que lleva a la tarea "Informar al
Cliente".
En este proceso para realizar reservaciones de vuelo y hotel hay 3
actividades que tienen Eventos Fronterizos de Compensacin.
Estos eventos se utilizan para definir cmo se deben compensar
las actividades a las que estn adjuntos. Si ocurre un error en el
sub-proceso "Reservaciones", se detona el evento fronterizo de
error, el cual a su vez activa un evento de compensacin que
ordena compensar al sub-proceso "Reservaciones". Esta orden de
compensacin, detona el evento fronterizo de compensacin, el
cual a su vez lleva a los eventos de compensacin "Reservar
vuelo" y "Reservar hotel" y a una tarea que solicita notificar al
cliente que la reservacin fall. Los eventos intermedios de
compensacin detonan la compensacin de las actividades
"Reservar vuelo" y "Reservar Hotel".
Se muestra el proceso de manufactura de una pieza. En el proceso
se utiliza una mquina. A la hora de procesar la pieza con la
mquina, la mquina podra sobrecalentarse. Si esto sucede, se
detona el evento intermedio condicional, la tarea se interrumpe
(note la lnea slida del evento) y el flujo cambia a un flujo de
excepcin. ste lleva a un evento temporizador que indica que hay
que esperar 20 minutos, pasados los 20 minutos se vuelve a
realizar el procesamiento de la pieza.
Se muestra un proceso sencillo de planificacin y realizacin de un
proyecto. La tarea "Realizar proyecto" tiene un evento mltiple
con dos detonadores. Uno es de tipo condicional, y la condicin
para detonarlo es que los costos excedan al presupuesto, el otro
es de tipo mensaje y es un mensaje que solicita que se detenga el
proceso. Si sucede cualquiera de estos dos detonadores, la tarea
se interrumpe y el flujo se redirige a un flujo de excepcin que
lleva a un evento de fin de error.
Se muestra un proceso sencillo de planificacin y realizacin de un
proyecto. La tarea "Realizar proyecto" tiene un evento mltiple
con dos detonadores. Uno es de tipo condicional, y la condicin
para detonarlo es que los costos excedan al presupuesto, el otro
es de tipo mensaje y es un mensaje que solicita que se detenga el
proceso. Si suceden ambos detonadores, la tarea se interrumpe y
el flujo se redirige a un flujo de excepcin que lleva a un evento de
fin de error. Si slo sucede uno de los dos, el evento no se
activar.
Se muestra un proceso de creacin de un libro. El proceso inicia
con aprender sobre un tema. Despus se pasa a escribir el libro. Si
mientras se est escribiendo un libro se detecta una seal de que
alguien ms ha publicado un libro del mismo tema, la actividad se
interrumpe (note la lnea slida del evento de seal), y el flujo se
redirige a un flujo de excepcin que lleva a la tarea "Buscar otro
tema". Completada esta tarea, se regresa a la primera tarea,
"Aprender sobre el tema" y luego el proceso contina.
Familia: Actividades
Marcadores
Bucle
Actividad es el trmino genrico que se le da al trabajo que realiza una compaa en un proceso. Una Actividad puede ser Atmica o No-Atmica. Si es atmica quiere decir que no se puede dividir, desglosar o modelar con ms detalle. Los tipos de Actividades que se utilizan como
parte de un Proceso son 2: Sub-Proceso y Tarea.
Los marcadores son smbolos que se pueden aadir a cualquier tipo de actividad. Existen 4 tipos de marcadores: bucle, multi-instancia, compensacin y ad-hoc. Una sola tarea puede tener varios marcadores, con la restriccin de que no se pueden utilizar juntos el marcador de
bucle y el de multi-instancia.
Multi-instancia
Compensacin
Instancias paralelas
Instancias secuenciales
Ad-hoc
Elemento 1: Tareas
Tarea Abstracta
Tarea de Servicio
Tarea de Envo
Tarea de Recepcin
Tarea de Recepcin
Instanciadora
Tarea de Usuario
Tarea Manual
Tarea de Regla de
Negocios
Tarea de Script
Elemento 2: Sub-Procesos
Sub-Proceso
Sub-Proceso de
Evento
Transaccin
Elemento 3: Actividad de Llamada
Actividad de
Llamada
Definicin OMG
La Actividad ser repetida mientras una condicin booleana siga siendo verdadera. La condicin
se evala en cada iteracin de la tarea y PUEDE ser evaluada al principio o al final de la iteracin.
Adems, se puede aadir un mximo numrico de iteraciones que NO PUEDE ser excedido.
Ejemplo: diagrama
Definicin OMG
Las instancias se pueden ejecutar en paralelo o secuencialmente. Se utilizar una Expresin para
calcular el nmero deseado de instancias o se utilizar un arreglo basado en datos. En caso de
que se defina una coleccin de datos de entrada el nmero de objetos en la coleccin
determinar el nmero de instancias de la Actividad. Tambin se puede definir exactamente el
nmero de iteraciones deseadas.
Ejemplo: diagrama
Definicin OMG
El marcador indica que la tarea se utiliza exclusivamente para compensacin y fuera del flujo
normal del Proceso. La Actividad que lleva el marcador se denomina Actividad de Compensacin y
se conecta mediante una Asociacin a un Evento Fronterizo de Compensacin.
Ejemplo: diagrama
Definicin OMG
Un grupo de actividades que no tienen relaciones de secuencia REQUERIDAS, y cuyo orden de
ejecucin y nmero de repeticiones lo determinar quien las realice.
Ejemplo: diagrama
Definicin OMG
Una Tarea es una actividad atmica includa en un Proceso. Se utiliza cuando el trabajo en un
Proceso no se va a sub-dividir o detallar ms. Por lo general, un usuario y/o aplicacin realiza la
Tarea a la hora de la ejecucin del proceso.
Una Tarea de Servicio es una tarea que utiliza algn tipo de servicio, el cual puede ser un Servicio
Web o aplicacin automatizada.
Una Tarea de Envo es una tarea sencilla diseada para enviar un Mensaje a un Participante
externo (relativo al proceso). Tras en viar el mensaje, la tarea est completada.
Espera la llegada de un Mensaje de un Participante externo. Tan pronto se recibe el mensaje, la
tarea se da por concluida.
Da inicio al proceso, NO DEBE tener ningn flujo de secuencia entrante.
Una tarea de "flujo de trabajo" tpica, en la cual un realizador humano lleva a cabo la tarea con
ayuda de una aplicacin de software. La tarea est agendada en un administrador de listas de
tareas.
Se espera que sea realizada sin la ayuda de un motor de ejecucin de procesos de negocio o
aplicacin.
Proporciona un mecanismo para que el Proceso proporciona una entrada a un Motor de Reglas
de Negocio y obtenga los datos de salida que el Motor de Reglas de Negocio pueda calcular.
Se ejecuta en un motor de procesos de negocio. El modelador o implementador defina un script
en un lenguaje que el motor pueda interpretar. Cuando la tarea est lista para iniciar, el motor
ejecutar el script. Cuando el script termine su ejecucin, la tarea estar completa.
Definicin OMG
Un Sub-Proceso es una Actividad cuyos detalles internos han sido modelados utilizando otras
Actividades, Compuertas, Eventos, y Flujos de SEcuencia. Un Sub-Proceso es un objeto grfico
dentro de un Proceso, pero tambin puede ser expandido para mostrar el proceso de nivel
inferior
Un Sub-Proceso de Evento es un Sub-Proceso especializado que se utiliza dentro de un Proceso (o
de otro Sub-Proceso). Un Sub-Proceso de Evento no es parte del flujo normal de su Proceso padre
- no tiene Flujos de Secuencia entrantes ni salientes. PUEDE ocurrir mltiples veces y debe tener
un Evento de Inicio como disparador.
Es un tipo especializado de Sub-Proceso que tendr un comportamiento especial controlado a
travs de un protocolo de Transaccin (por ejemplo, WS-Transaction). El comportamiento al final
de una Transaccin exitosa ser ligeramente diferente del de un Sub-Proceso normal.
Definicin OMG
Una Actividad de Llamada identifica un punto en el Proceso en donde se utiliza una Tarea o
Proceso Global. La actividad de llamada acta como un "envoltorio" para la invocacin de un
Proceso o Tarea a la hora de la ejecucin.
Explicacin
Es una pequea flecha enroscada que se coloca abajo y al centro de la figura de la
actividad. Se puede usar con todo tipo de tareas y sub-procesos. Es un mecanismo para
repetir una tarea en base a una condicin. Su funcionamiento es sencillo: se define una
condicin que ser evaluada al inicio o al final de cada iteracin (el modelador define
cundo se evala). Mientras la condicin sea cierta la actividad se repetir. Tambin es
posible especificar un nmero mximo de iteraciones el cul no podr ser superado por
ningn motivo.
Ejemplo: explicacin
Se muestra un proceso sencillo en el que se captura un conjunto de expedientes de
forma digital en una base de datos. La tarea Capturar expediente en base de datos tiene
un marcador de bucle y una anotacin de texto que describe su comportamiento. Note
que la anotacin explica el comportamiento en lenguaje natural. Tambin se podra
describir a travs de una expresin boolean.
Explicacin
Su forma son tres lneas paralelas orientadas vertical u horizontalmente. Al igual que el
bcle consiste en un mecanismo de repeticin, pero el nmero de veces que se repetir
la tarea se determina de forma diferente. Existen varias formas de utilizar este
marcador. Se puede definir una condicin que al llegar a la tarea determinar el
nmero de iteraciones (por ejemplo, que el nmero de iteraciones sea igual al nmero
de clientes de la empresa). Tambin se puede definir el nmero de iteraciones a travs
de una Coleccin de Entradas de Datos. El nmero de objetos en la coleccin
determinar el nmero de iteraciones. Por ltimo, se puede definir que las iteraciones
se ejecuten en paralelo o de forma secuencial. Si el marcador se coloca verticalmente,
las tareas se ejecutan en paralelo. Si se coloca horizontalmente, las tareas se ejecutan
secuencialmente.
Ejemplo: explicacin
Se muestra un proceso sencillo en el que se captura un conjunto de expedientes de
forma digital en una base de datos. La tarea Capturar expediente en base de datos tiene
un marcador de multi instancia horizontal, lo cual indica que las iteraciones se deben
realizar de forma secuencial. Adems, la tarea tiene una Coleccin de Entradas de
Datos. Esto indica que la tarea se debe iterar una vez para cada objeto de la coleccin.
En este caso se capturara cada expediente de la carpeta de expedientes y despus de
esas iteraciones la tarea se dar por concluida.
Explicacin
Su forma es dos tringulos orientados hacia la izquierda, como en un botn de
rebobinar de una grabadora. Indica que la actividad es una actividad de compensacin,
es decir, que no forma parte normal del proceso, sino que se utiliza para deshacer una
actividad cuyos efectos ya no se desean. Es OBLIGATORIO utilizar este marcador cuando
una tarea est asociada a un Evento de Frontera de compensacin (vase Evento de
Forntera de Compensacin, en Eventos Intermedios).
Ejemplo: explicacin
En el ejemplo aparecen dos tareas con marcadores de compensacin llamadas
"Cancelar reservacin". Note que estas tareas estn unidas por una asociacin a los
eventos de frontera de compensacin. Esto indica que son tareas destinadas a
compensar o revertir los efectos de las tareas "Reservar Hotel" y "Reservar Vuelo".
Explicacin
Su forma es una virgulilla (raya ondulada). Se utiliza para indicar que las tareas
contenidas en un sub-proceso pueden realizarse en el orden que el ejecutador
considere conveniente. Es decir no hay un orden ni nmero de iteraciones
OBLIGATORIO para la ejecucin de las actividades del sub-proceso. Sin embargo s se
pueden aadir algunas restricciones utilizando objetos de datos y flujos de secuencia.
Por ejemplo, si una actividad tiene un Objeto de Datos de entrada, sta no puede ser
realizada hasta que ese objeto est disponible. Tambin, si dos actividades estn unidas
por un flujo de secuencia, quiere decir que si la primera se ejecuta, la segunda tambin
debe ejecutarse, no necesariamente inmediatamente despus de la primera, pero s en
algn momento despus. Los elementos que no estn permitidos en un sub-proceso ad-
hoc son: Eventos de Inicio y Eventos de Fin.
Ejemplo: explicacin
El ejemplo muestra un sub-proceso para escribir un captulo de un libro. El sub-proceso
tiene un marcador ad-hoc, lo cul indica que la persona que ejecute el proceso puede
decidir en qu orden realizar las tareas. Pero s tiene algunas restricciones, por ejemplo,
no puede empezar a investigar el tema ni generar los grficos si an no tiene el objeto
de datos "Tema". Tambin, si genera grficos, est obligado a incluir los grficos en el
texto, pues estas dos tareas estn unidas por un flujo de secuencia, pero no est
obligado a realizar una inmediatamente despus de la otra.
Explicacin
Indica que hay cierto trabajo a realizar. No especifica las condiciones bajo las cuales se
debe realizar ese trabajo. Es la tarea ms general. Utilice este tipo de tarea si no
considera necesario especificar las condiciones bajo las cuales se ha de realizar el
trabajo.
Indica que la tarea requiere del apoyo o ser realizada completamente por un servicio
web o aplicacin automatizada.
La tarea consiste en enviar un mensaje especfico. El mensaje puede ser enviado por
cualquier medio y puede contener cualquier tipo de informacin. La tarea se completa
al enviar el mensaje.
Se usa para denotar una tarea que requiere la recepcin de un mensaje. Puede
utilizarse para iniciar un proceso. Si ese es el caso, adems del cono de sobre colocado
en la esquina se debe rodear este cono con un crculo (sta es la figura de un evento de
inicio de mensaje).
Indica que la tarea ser realizada por una persona pero con el apoyo de una aplicacin.
A diferencia de la tarea de servicio, la tarea de usuario implica que hay una persona
involucrada.
Indica que la tarea es una tarea manual, y que no se ejecuta a travs de un sistema.
Esto implica que no puede ser controlada por un motor de workflow o aplicacin de
BPM.
La tarea debe ser ejecutada tomando en cuenta una Regla de Negocio definida por la
organizacin. Las reglas de negocio son lineamientos que indican cmo se debe actuar
en ciertos casos y siempre evalan a verdadero o falso. Estas reglas no son parte de
BPMN sino que son fijadas por la organizacin.
Ejecuta un Script especfico definido por el modelador.
Explicacin
Un Sub-Proceso es una tarea que se describe a ms detalle. Se utiliza cuando se desea
modelar con precisin los pasos para realizar una tarea que forma parte de un proceso
de nivel superior. El Sub-Proceso se activa, al igual que una tarea, cuando un token llega
por un flujo entrante. Su activacin, entonces, no depende de un evento y por lo tanto
los sub-procesos no pueden tener eventos de inicio (a excepcin del tipo Nulo). El Sub-
Proceso se puede mostrar colapsado o expandido. Colapsado quiere decir que se
ocultan sus detalles internos y expandido que s se muestran.
Es un Sub-Proceso especial que no forma parte del flujo de secuencia normal. No tiene
flujos de secuencia entrantes ni salientes. Por lo general est flotando dentro de un
proceso y se activa cuando su Evento de Inicio es detonado. Existen muchos tipos de
Eventos de Inicio para Sub-Procesos de Evento. Este tipo de Sub-Procesos se utilizan
para manejar eventos que pueden ocurrir, pero que no siempre lo hacen durante un
proceso, por ejemplo, errores, escaladas, la llegada de mensajes, etc. Pueden
interrumpir o no interrumpir a su proceso padre, dependiendo del tipo de evento de
inicio que utilicen.
Una transaccin es un tipo especial de Sub-Proceso. Las transacciones se llevan a cabo
en base a un protocolo de transaccin especfico y siempre involucran a dos o ms
participantes. Gracias a esto ltima, a diferencia de un Sub-Proceso normal, una
Transaccin no necesariamente se habr completado cuando se completen todas las
tareas que contiene. Su completud exitosa depende de que el otro actor cumpla su
parte de la transaccin. Si cualquiera de los involucrados cancela su transaccin, la del
otro tambin ser cancelada aunque ya hubiera completado sus tareas exitosamente.
Dentro de las transacciones se utiliza un evento especial llamado evento de cancelacin
que indica que la transaccin debe ser cancelada y que automticamente provoca que
todas las tareas sean compensadas. Las transacciones pueden tener tres resultados: 1)
Completud exitosa, si todas las partes cumplen las tareas de su transaccin y todos los
mensajes de transaccin definidos por el protocolo son enviados correctamente. 2)
Cancelacin, si se llega a un evento de cancelacin o se recibe un mensaje de
cancelacin segn lo defina el protocolo elegido. 3) Error, si ocurre un error que evita
que las tareas sean compensadas. Esto sucede si se alcanza un evento de error.
Explicacin
La actividad de llamada es aquella que invoca un proceso reutilizable conocido como
tarea global. Se utiliza para reciclar procesos comunes. Si un proceso se marca como
tarea global estar disponible para ser llamado por una actividad de llamada. La
actividad de llamada puede llamar Sub-Procesos, Sub-Procesos de Evento o
Transacciones. Dependiendo del tipo de actividad que llame ser su figura: bsicamente
es la misma figura que la del tipo de proceso al que llama, pero con lneas gruesas.
Usos tpicos
*Tareas que, si fallan, deben ser
repetidas hasta lograr su
objetivo.
Usos tpicos
*Tareas que deben realizarse un
nmero de veces que depende de
el nmero de documentos o
participantes a las que
involucran.
Usos tpicos
*Siempre que se necesite
deshacer los efectos de una
actividad.
Usos tpicos
*Para organizar lo que hay que
hacer para completar un proceso
sin definir el orden.
Usos tpicos
*Cuando el trabajo a realizar no
encaja con ningn otro tipo de
tarea. *Si el modelador no
conoce bien los otros tipos de
tareas, sta tarea siempre es
vlida.
*Procesamiento de datos.
*Manufactura automatizada.
*Cualquier actividad que no
requiera de intervencin
humana.
*Enviar correos, facturas,
documentos, hacer llamadas, etc.
*Recibir correos, facturas,
documentos, llamadas, etc.
*Cuando el inicio de un proceso
depende de la recepcin de un
mensaje.
*Alterar bases de datos.
*Utilizar CRMs, ERPs u otros
sistemas de administracin
*Instalaciones, reparaciones,
manufactura de productos,
cualquier proceso que no
requiera un sistema
computacional.
*Tareas para las cuales la
empresa tiene una regla de
negocio definida
*Revisin de ortografa,
validacin de rdenes, diagramas,
cdigo, etc.
Usos tpicos
*Manejar errores, cancelaciones
y escaladas.
*Reaccionar a la llegada de
mensajes que no son parte
normal del proceso.
Usos tpicos
Ejemplo: diagrama
Ejemplo: diagrama
Ejemplo: diagrama
Se modela un proceso sencillo de creacin de un reporte. Las
tareas son las unidades de trabajo que se han de realizar para
completar el proceso. Se ejecutan de forma secuencial y cuando
todas estn completas el proceso lo estar tambin.
Se modela un proceso sencillo para otorgar o denegar un crdito.
Tras registrar el cliente el sistema automticamente y sin
necesidad de intervencin revisar si el cliente se encuentra en el
bur de crdito. Esta es una tarea de servicio porque no requiere
intervencin humana.
Se modela un proceso de cotizacin. Tras hacer la cotizacin se le
enva al cliente. Este envo es una Tarea de Envo pues se est
enviando informacin y/o documentos al cliente.
*Use slo tareas de envo o
recepcin, o eventos de
mensaje, no ambos.
*Tome en cuenta que a las
tareas se les puede asignar
recursos y costos, mientras
que a los eventos no. Pero
los eventos son visualmente
ms distintivos.
enva al cliente. Despus se espera su respuesta para saber si est
interesado en el servicio o no. Esperar esta respuesta es una Tarea
de Recepcin, pues implica esperar a recibir informacin, en este
caso, un mensaje.
Se presenta un proceso de cmo atender una orden. El proceso
arranca cuando se recibe una orden, esta primera tarea es una
tarea de recepcin, pues se espera un mensaje antes de empezar
y es instanciadora porque es la que da inicio al proceso. Note que
la tarea de recepcin no tiene flujos entrantes y que el icono de
mensaje esta circulado.
Se modela un proceso de registro de un cliente en una base de
datos. Tras recibir la informacin del cliente se actualiza su
informacin en la base de datos. sta es una tarea de usuario pues
implica interaccin de un usuario con una aplicacin o software.
Se modela el proceso de instalar un telfono. La tarea Instalar
Telfono es una tarea manual pues no requiere del apoyo de una
aplicacin o software, sino que es realizada por una persona
directamente.
Se modela un proceso de cotizacin. La empresa a la que pertence
el modelo otorga distintos tipos de membresas: platino, oro y
plata. Dependiendo del tipo de membresa que tenga el cliente y
su actividad reciente se determina el precio al que se le vendern
los productos. La empresa ha definido una regla de negocio que
podra ser algo as: "Si el cliente tiene membresa platino y ha
consumido ms de 100 dlares en el ao, el precio es 4 dlares. Si
el cliente tiene membresa de oro y ha consumido ms de 150
dlares en el ao, el precio es de 6 dlares, etc.". La tarea "Cotizar
producto" es una tarea de Regla de Negocio pues se debe realizar
tomando en cuenta la regla antes mencionada.
El ejemplo es de un proceso de creacin de un diagrama de
procesos. Despus de disear y modelar el proceso, se ejecutar
un Script que se encarga de validar el modelo. La tarea "Validar
modelo" es una tarea de Script porque consiste en la ejecucin de
un Script.
Se muestra el mismo proceso dos veces. En el primero, el Sub-
Proceso "Obtencin" se encuentra colapsado, en el segundo se
muestra este mismo sub-proceso pero expandido. Como es lgico
pensar la tarea de obtencin no es una tarea sencilla sino que se
puede modelar a ms detalle.
Se muestra un proceso en el que se realizan reservaciones de
vuelo y hotel. El proceso "Hacer reservaciones" tiene un Sub-
Proceso de Evento llamado "Manejo de errores". Note que el Sub-
Proceso de evento no tiene flujos entrantes ni salientes, sino que
est flotando dentro del proceso padre. Si ocurre un error
duranteel proceso de hacer reservaciones, se dispara el evento de
inicio del Sub-Proceso de Evento y ste se activa. En la parte de
abajo se muestra el mismo proceso pero con el Sub-Proceso de
Evento colapsado.
Se muestra un proceso en el que sea realizan reservaciones para
un cliente. El proceso contiene una transaccin llamada
"Reservaciones" que contiene a su vez dos tareas: Reservar vuelo
y Reservar hotel. Estas tareas tienen eventos de error de frontera
(los crculos con un rayo adentro), los cuales responden a
cualquier error que ocurra dentro de las tareas. Si ocurre un error
se disparan estos eventos y se llega a un evento de fin de
cancelacin (el crculo con la cruz). Esto arroja una cancelacin
que provoca dos cosas: 1) la cancelacin de la transaccin 2) la
compensacin de todas las actividades de la transaccin. Como se
trata de una transaccin, an que se completaran las dos tareas
"Reservar vuelo" y "Reservar hotel" no se puede declarar que la
transaccin est terminada hasta que (1) todas las partes estn de
acuerdo, (2) hayan seguido completamente el protocolo de
transaccin elegido, y (3) todos hayan terminado exitosamente las
tareas contenidas en sus transacciones. Todas estas reglas aplican
an que la transaccin de las otras partes no sea visible dentro del
diagrama.
Se muestra un sencillo proceso de venta y cobranza. Note que el
sub-proceso "Generar Factura" tiene el borde grueso. Esto indica
que es una actividad de llamada que est llamando a un Sub-
Proceso. La razn para utilizar la actividad de llamada en este caso
es que el proceso de generar una factura puede aparecer en
muchos procesos, as que vale la pena modelarlo como un
proceso global (es decir, reutilizable) y en vez de modelarlo de
nuevo en cada diagrama que aparezca simplemente "llamarlo"
usando una actividad de llamada. Note tambin que la figura del
sub-proceso de llamada es la misma que la del sub-proceso pero
con una lnea gruesa.
Familia: Actividades
Marcadores
Elemento 1: Tareas
Tarea Abstracta
Tarea de Servicio
Tarea de Envo
Tarea de
Recepcin
Tarea de
Recepcin
Instanciadora
Tarea de Usuario
Tarea Manual
Tarea de Regla de
Negocios
Tarea de Script
Elemento 2: Sub-Procesos
Sub-Proceso
Sub-Proceso de
Evento
Transaccin
Elemento 3: Actividad de Llamada
Actividad de
Llamada
Definicin OMG
Una Tarea es una actividad atmica includa en un Proceso. Se utiliza cuando el trabajo en un
Proceso no se va a sub-dividir o detallar ms. Por lo general, un usuario y/o aplicacin realiza la
Tarea a la hora de la ejecucin del proceso.
Una Tarea de Servicio es una tarea que utiliza algn tipo de servicio, el cual puede ser un Servicio
Web o aplicacin automatizada.
Una Tarea de Envo es una tarea sencilla diseada para enviar un Mensaje a un Participante
externo (relativo al proceso). Tras en viar el mensaje, la tarea est completada.
Espera la llegada de un Mensaje de un Participante externo. Tan pronto se recibe el mensaje, la
tarea se da por concluida.
Da inicio al proceso, NO DEBE tener ningn flujo de secuencia entrante.
Una tarea de "flujo de trabajo" tpica, en la cual un realizador humano lleva a cabo la tarea con
ayuda de una aplicacin de software. La tarea est agendada en un administrador de listas de
tareas.
Se espera que sea realizada sin la ayuda de un motor de ejecucin de procesos de negocio o
aplicacin.
Proporciona un mecanismo para que el Proceso proporciona una entrada a un Motor de Reglas de
Negocio y obtenga los datos de salida que el Motor de Reglas de Negocio pueda calcular.
Se ejecuta en un motor de procesos de negocio. El modelador o implementador defina un script
en un lenguaje que el motor pueda interpretar. Cuando la tarea est lista para iniciar, el motor
ejecutar el script. Cuando el script termine su ejecucin, la tarea estar completa.
Definicin OMG
Un Sub-Proceso es una Actividad cuyos detalles internos han sido modelados utilizando otras
Actividades, Compuertas, Eventos, y Flujos de SEcuencia. Un Sub-Proceso es un objeto grfico
dentro de un Proceso, pero tambin puede ser expandido para mostrar el proceso de nivel
inferior
Un Sub-Proceso de Evento es un Sub-Proceso especializado que se utiliza dentro de un Proceso (o
de otro Sub-Proceso). Un Sub-Proceso de Evento no es parte del flujo normal de su Proceso padre -
no tiene Flujos de Secuencia entrantes ni salientes. PUEDE ocurrir mltiples veces y debe tener un
Evento de Inicio como disparador.
Es un tipo especializado de Sub-Proceso que tendr un comportamiento especial controlado a
travs de un protocolo de Transaccin (por ejemplo, WS-Transaction). El comportamiento al final
de una Transaccin exitosa ser ligeramente diferente del de un Sub-Proceso normal.
Definicin OMG
Una Actividad de Llamada identifica un punto en el Proceso en donde se utiliza una Tarea o
Proceso Global. La actividad de llamada acta como un "envoltorio" para la invocacin de un
Proceso o Tarea a la hora de la ejecucin.
Explicacin
Indica que hay cierto trabajo a realizar. No especifica las condiciones bajo las cuales se
debe realizar ese trabajo. Es la tarea ms general. Utilice este tipo de tarea si no
considera necesario especificar las condiciones bajo las cuales se ha de realizar el
trabajo.
Indica que la tarea requiere del apoyo o ser realizada completamente por un servicio
web o aplicacin automatizada.
La tarea consiste en enviar un mensaje especfico. El mensaje puede ser enviado por
cualquier medio y puede contener cualquier tipo de informacin. La tarea se completa
al enviar el mensaje.
Se usa para denotar una tarea que requiere la recepcin de un mensaje. Puede
utilizarse para iniciar un proceso. Si ese es el caso, adems del cono de sobre colocado
en la esquina se debe rodear este cono con un crculo (sta es la figura de un evento
de inicio de mensaje).
Indica que la tarea ser realizada por una persona pero con el apoyo de una aplicacin.
A diferencia de la tarea de servicio, la tarea de usuario implica que hay una persona
involucrada.
Indica que la tarea es una tarea manual, y que no se ejecuta a travs de un sistema.
Esto implica que no puede ser controlada por un motor de workflow o aplicacin de
BPM.
La tarea debe ser ejecutada tomando en cuenta una Regla de Negocio definida por la
organizacin. Las reglas de negocio son lineamientos que indican cmo se debe actuar
en ciertos casos y siempre evalan a verdadero o falso. Estas reglas no son parte de
BPMN sino que son fijadas por la organizacin.
Ejecuta un Script especfico definido por el modelador.
Explicacin
Un Sub-Proceso es una tarea que se describe a ms detalle. Se utiliza cuando se desea
modelar con precisin los pasos para realizar una tarea que forma parte de un proceso
de nivel superior. El Sub-Proceso se activa, al igual que una tarea, cuando un token
llega por un flujo entrante. Su activacin, entonces, no depende de un evento y por lo
tanto los sub-procesos no pueden tener eventos de inicio (a excepcin del tipo Nulo).
El Sub-Proceso se puede mostrar colapsado o expandido. Colapsado quiere decir que
se ocultan sus detalles internos y expandido que s se muestran.
Es un Sub-Proceso especial que no forma parte del flujo de secuencia normal. No tiene
flujos de secuencia entrantes ni salientes. Por lo general est flotando dentro de un
proceso y se activa cuando su Evento de Inicio es detonado. Existen muchos tipos de
Eventos de Inicio para Sub-Procesos de Evento. Este tipo de Sub-Procesos se utilizan
para manejar eventos que pueden ocurrir, pero que no siempre lo hacen durante un
proceso, por ejemplo, errores, escaladas, la llegada de mensajes, etc. Pueden
interrumpir o no interrumpir a su proceso padre, dependiendo del tipo de evento de
inicio que utilicen.
Una transaccin es un tipo especial de Sub-Proceso. Las transacciones se llevan a cabo
en base a un protocolo de transaccin especfico y siempre involucran a dos o ms
participantes. Gracias a esto ltima, a diferencia de un Sub-Proceso normal, una
Transaccin no necesariamente se habr completado cuando se completen todas las
tareas que contiene. Su completud exitosa depende de que el otro actor cumpla su
parte de la transaccin. Si cualquiera de los involucrados cancela su transaccin, la del
otro tambin ser cancelada aunque ya hubiera completado sus tareas exitosamente.
Dentro de las transacciones se utiliza un evento especial llamado evento de
cancelacin que indica que la transaccin debe ser cancelada y que automticamente
provoca que todas las tareas sean compensadas. Las transacciones pueden tener tres
resultados: 1) Completud exitosa, si todas las partes cumplen las tareas de su
transaccin y todos los mensajes de transaccin definidos por el protocolo son
enviados correctamente. 2) Cancelacin, si se llega a un evento de cancelacin o se
recibe un mensaje de cancelacin segn lo defina el protocolo elegido. 3) Error, si
ocurre un error que evita que las tareas sean compensadas. Esto sucede si se alcanza
un evento de error.
Explicacin
La actividad de llamada es aquella que invoca un proceso reutilizable conocido como
tarea global. Se utiliza para reciclar procesos comunes. Si un proceso se marca como
tarea global estar disponible para ser llamado por una actividad de llamada. La
actividad de llamada puede llamar Sub-Procesos, Sub-Procesos de Evento o
Transacciones. Dependiendo del tipo de actividad que llame ser su figura:
bsicamente es la misma figura que la del tipo de proceso al que llama, pero con lneas
gruesas.
Usos tpicos
*Cuando el trabajo a realizar no
encaja con ningn otro tipo de
tarea. *Si el modelador no
conoce bien los otros tipos de
tareas, sta tarea siempre es
vlida.
*Procesamiento de datos.
*Manufactura automatizada.
*Cualquier actividad que no
requiera de intervencin humana.
*Enviar correos, facturas,
documentos, hacer llamadas, etc.
*Recibir correos, facturas,
documentos, llamadas, etc.
*Cuando el inicio de un proceso
depende de la recepcin de un
mensaje.
*Alterar bases de datos.
*Utilizar CRMs, ERPs u otros
sistemas de administracin
*Instalaciones, reparaciones,
manufactura de productos,
cualquier proceso que no requiera
un sistema computacional.
*Tareas para las cuales la
empresa tiene una regla de
negocio definida
*Revisin de ortografa,
validacin de rdenes, diagramas,
cdigo, etc.
Usos tpicos
*Manejar errores, cancelaciones y
escaladas.
*Reaccionar a la llegada de
mensajes que no son parte
normal del proceso.
Usos tpicos
Ejemplo: diagrama
Ejemplo: diagrama
Ejemplo: diagrama
Se modela un proceso sencillo de creacin de un reporte. Las
tareas son las unidades de trabajo que se han de realizar para
completar el proceso. Se ejecutan de forma secuencial y cuando
todas estn completas el proceso lo estar tambin.
Se modela un proceso sencillo para otorgar o denegar un crdito.
Tras registrar el cliente el sistema automticamente y sin
necesidad de intervencin revisar si el cliente se encuentra en el
bur de crdito. Esta es una tarea de servicio porque no requiere
intervencin humana.
enva al cliente. Este envo es una Tarea de Envo pues se est
enviando informacin y/o documentos al cliente.
*Use slo tareas de envo o
recepcin, o eventos de
mensaje, no ambos.
*Tome en cuenta que a las
tareas se les puede asignar
recursos y costos, mientras
que a los eventos no. Pero
los eventos son visualmente
ms distintivos.
enva al cliente. Despus se espera su respuesta para saber si est
interesado en el servicio o no. Esperar esta respuesta es una Tarea
de Recepcin, pues implica esperar a recibir informacin, en este
caso, un mensaje.
Se presenta un proceso de cmo atender una orden. El proceso
arranca cuando se recibe una orden, esta primera tarea es una
tarea de recepcin, pues se espera un mensaje antes de empezar
y es instanciadora porque es la que da inicio al proceso. Note que
la tarea de recepcin no tiene flujos entrantes y que el icono de
mensaje esta circulado.
Se modela un proceso de registro de un cliente en una base de
datos. Tras recibir la informacin del cliente se actualiza su
informacin en la base de datos. sta es una tarea de usuario pues
implica interaccin de un usuario con una aplicacin o software.
Se modela el proceso de instalar un telfono. La tarea Instalar
Telfono es una tarea manual pues no requiere del apoyo de una
aplicacin o software, sino que es realizada por una persona
directamente.
Se modela un proceso de cotizacin. La empresa a la que pertence
el modelo otorga distintos tipos de membresas: platino, oro y
plata. Dependiendo del tipo de membresa que tenga el cliente y
su actividad reciente se determina el precio al que se le vendern
los productos. La empresa ha definido una regla de negocio que
podra ser algo as: "Si el cliente tiene membresa platino y ha
consumido ms de 100 dlares en el ao, el precio es 4 dlares. Si
el cliente tiene membresa de oro y ha consumido ms de 150
dlares en el ao, el precio es de 6 dlares, etc.". La tarea "Cotizar
producto" es una tarea de Regla de Negocio pues se debe realizar
tomando en cuenta la regla antes mencionada.
El ejemplo es de un proceso de creacin de un diagrama de
procesos. Despus de disear y modelar el proceso, se ejecutar
un Script que se encarga de validar el modelo. La tarea "Validar
modelo" es una tarea de Script porque consiste en la ejecucin de
un Script.
Se muestra el mismo proceso dos veces. En el primero, el Sub-
Proceso "Obtencin" se encuentra colapsado, en el segundo se
muestra este mismo sub-proceso pero expandido. Como es lgico
pensar la tarea de obtencin no es una tarea sencilla sino que se
puede modelar a ms detalle.
Se muestra un proceso en el que se realizan reservaciones de
vuelo y hotel. El proceso "Hacer reservaciones" tiene un Sub-
Proceso de Evento llamado "Manejo de errores". Note que el Sub-
Proceso de evento no tiene flujos entrantes ni salientes, sino que
est flotando dentro del proceso padre. Si ocurre un error
duranteel proceso de hacer reservaciones, se dispara el evento de
inicio del Sub-Proceso de Evento y ste se activa. En la parte de
abajo se muestra el mismo proceso pero con el Sub-Proceso de
Evento colapsado.
Se muestra un proceso en el que sea realizan reservaciones para
un cliente. El proceso contiene una transaccin llamada
"Reservaciones" que contiene a su vez dos tareas: Reservar vuelo
y Reservar hotel. Estas tareas tienen eventos de error de frontera
(los crculos con un rayo adentro), los cuales responden a
cualquier error que ocurra dentro de las tareas. Si ocurre un error
se disparan estos eventos y se llega a un evento de fin de
cancelacin (el crculo con la cruz). Esto arroja una cancelacin
que provoca dos cosas: 1) la cancelacin de la transaccin 2) la
compensacin de todas las actividades de la transaccin. Como se
trata de una transaccin, an que se completaran las dos tareas
"Reservar vuelo" y "Reservar hotel" no se puede declarar que la
transaccin est terminada hasta que (1) todas las partes estn de
acuerdo, (2) hayan seguido completamente el protocolo de
transaccin elegido, y (3) todos hayan terminado exitosamente las
tareas contenidas en sus transacciones. Todas estas reglas aplican
an que la transaccin de las otras partes no sea visible dentro del
diagrama.
Se muestra un sencillo proceso de venta y cobranza. Note que el
sub-proceso "Generar Factura" tiene el borde grueso. Esto indica
que es una actividad de llamada que est llamando a un Sub-
Proceso. La razn para utilizar la actividad de llamada en este caso
es que el proceso de generar una factura puede aparecer en
muchos procesos, as que vale la pena modelarlo como un
proceso global (es decir, reutilizable) y en vez de modelarlo de
nuevo en cada diagrama que aparezca simplemente "llamarlo"
usando una actividad de llamada. Note tambin que la figura del
sub-proceso de llamada es la misma que la del sub-proceso pero
con una lnea gruesa.
Familia: Contenedores
Contenedor
Un Contenedor es una sub-
particin dentro de un Proceso
y se extiende la longitud entera
del Proceso, ya sea vertical u
horizontalmente.
BPMN no especifica ms el uso
de Contenedores. Por lo general
se utilizan para cosas tales
como roles internos, sistemas,
departamentos internos, etc.
Adems, los contenedores
pueden tener Carriles anidados
para realizar ms sub-divisiones.
Carril
Un Carril es una sub-particin
dentro de un Contenedor y se
extiende la longitud entera del
Contenedor.
BPMN no especifica ms el uso
de Carriles. Por lo general se
utilizan para cosas tales como
roles internos, sistemas,
departamentos internos, etc.
Adems, los Carriles pueden
tener otros Carriles anidados
para realizar ms sub-divisiones.
Los contenedores se utilizan para sub-dividir un proceso y agrupar sus elementos en base a quin los va a ejecutar o utilizar. Cada contenedor debe representar un
actor distinto y puede ser sub-dividido. Se utilizan para modelar personas, roles, departamentos, organizaciones, sistemas y otros actores.
El contenedor es la representacin grfica
de un participante. Puede ser una
organizacin, una persona, un rol, etc. Si
hay un proceso dentro del contenedor,
ste lo llevar acabo el participante
correspondiente. No es necesario que haya
un proceso dentro de un contenedor, se
puede dejar como una caja negra para
modelar el envo y recepcin de mensajes
(vase el ejemplo).
*Indispensable cuando hay varias
personas, departamentos o roles
involucrados en el proceso.
*Como caja negra para indicar de
dnde provienen y a dnde se
envan los mensajes.
Un carril es una subdivisin de un
contenedor. Sirve para descomponer el
grupo de personas representado por el
contenedor. Por ejemplo, el contenedor
puede ser una organizacin y los carriles
sus distintos departamentos.
*Cuando varios departamentos
de una misma empresa, o varios
roles de un mismo departamento
estn involucrados en el proceso.
Los contenedores se utilizan para sub-dividir un proceso y agrupar sus elementos en base a quin los va a ejecutar o utilizar. Cada contenedor debe representar un
actor distinto y puede ser sub-dividido. Se utilizan para modelar personas, roles, departamentos, organizaciones, sistemas y otros actores.
Ejemplo: diagrama
Se muestra un proceso en el que un diseador interacta con su
cliente. Como el proceso involucra a dos participantes se utilizan
dos contenedores. Uno de estos representa al cliente y el otro al
diseador. En el contenedor del diseador se ha modelado un
proceso que ste habra de llevar a cabo. El proceso incluye un
intercambio de mensajes con el cliente. Los flujos punteados que
unen los dos contenedores indican estos intercambios. Note que
no se modela el proceso que realiza el cliente: su contenedor es
una "caja negra", pero an as es til modelarlo porque permite
indicar a quin enva los mensajes el diseador.
En el ejemplo se muestra una empresa dividida en tres
departamentos: Marketing, Ingeniera y Ventas. El contenedor
representa a la empresa y sus tres carriles representan los
departamentos. Se modela un solo proceso y la posicin de las
tareas dentro de los diferentes carriles indica quin realizar cada
tarea. Por ejemplo, el departamento de Ingeniera se encargar de
la tarea "Desarrollar producto" y el de ventas de la tarea "Vender
producto".
Familia: Artefactos
Anotacin de Texto
Los artefactos son elementos visuales que no alteran la ejecucin o flujo de un proceso. Se utilizan para hacer ms legible un diagrama o enfatizar algunas de sus partes. Existen dos artefactos en BPMN: la Asociacin de Texto y el Grupo.
Grupo
Definicin OMG
Es un mecanismo para que el modelador proporcione informacin adicional al lector del
Diagrama BPMN. Puede ser conectada a objetos en especfico. No afecta el flujo del Proceso.
Ejemplo: diagrama
Definicin OMG
Proporciona un mecanismo visual para agrupar elementos de un diagrama informalmente. Los
Grupos se suelen utilizar para resaltar ciertas secciones de un Diagrama sin aadir restricciones en
la ejecucin. La seccin agrupada puede ser separada para propsitos de reporte y anlisis.
Ejemplo: diagrama
Explicacin
La anotacin de texto es una pequea nota que se adjunta a algn elemento de un
diagrama. Permite aadir informacin o detalles extras de cmo leer el diagrama.
Ejemplo: explicacin
Se muestra un fragmento de un proceso largo que al ser imprimido abarca varias
pginas. El modelador ha agregado una anotacin de texto para facilitar la lectura del
diagrama, indicando en qu pgina contina el proceso.
Explicacin
El Grupo sirve para agrupar elementos que tienen alguna relacin. No altera el
comportamiento del proceso y es ms bien un elemento visual. Se utiliza para destacar
secciones particularmente importantes de un proceso o secciones que se desean
analizar o reportar por separado.
Ejemplo: explicacin
Se muestra un fragmento de un proceso en el que interactan un diseador grfico y su
cliente. El diseador genera una propuesta y la enva al cliente para evaluacin. ste la
evala y aprueba y devuelve su aprobacin al diseador. El modelador ha decidido
utilizar un Grupo para indicar que ciertos elementos del proceso conforman una unidad
lgica a la que llama "Negociacin de propuesta". El Grupo no altera el comportamiento
del proceso, es slo una ayuda para hace rms legible el proceso y dividirlo en partes
lgicas o etapas.
Usos tpicos
*Para describir el
comportamiento de una
compuerta compleja.
*Para indicar de dnde proviene
un proceso o dnde contina, en
especial si sern impresos.
Mejores prcticas
*Siempre que utilice una
compuerta compleja deber
utilizar una anotacin de texto
para describir su
comportamiento.
Usos tpicos
*Dividir un proceso en etapas o
unidades.
*Dividir un proceso con un
enfoque de servicios, indicando
dnde se generan qu
entregables.
Mejores prcticas
Familia: Objetos de Datos
Objeto de Datos
Los Objetos de Datos proporcionan informacin sobre lo que una Actividad producir o requerir para su realizacin. Los Objetos de Datos pueden representar un solo objeto o una coleccin de objetos. Las Entradas y Salidas de datos proporcionan la misma funcin para procesos.
Entrada de Datos
Salida de Datos
Coleccin de
Objetos de Datos
Almacn de Datos
Definicin OMG
Es el elemento principal utilizado para modelar datos dentro de un proceso. Tiene un ciclo de vida
bien definido que resulta en ciertas restricciones de acceso. El objeto de datos puede ser utilizado
varias veces dentro de un mismo diagrama y se pueden indicar estados distintos cada vez que
aparece.
Ejemplo: diagrama
Definicin OMG
Las Actividades y Procesos frecuentemente necesitan datos para ser ejecutados. Adems, pueden
producir datos durante o como resultado de su ejecucin. Los requerimientos de Datos se
modelan como Entradas de Datos. Y los datos producidos se modelan como Salidas de Datos.
Ejemplo: diagrama
Definicin OMG
Las Actividades y Procesos frecuentemente necesitan datos para ser ejecutados. Adems, pueden
producir datos durante o como resultado de su ejecucin. Los requerimientos de Datos se
modelan como Entradas de Datos. Y los datos producidos se modelan como Salidas de Datos.
Ejemplo: diagrama
Definicin OMG
Un Objeto de Datos que hace referencia a una coleccin de datos. Tiene una figura distinta a la
del Objeto de Datos.
Ejemplo: diagrama
Definicin OMG
El almacn de datos proporciona un mecanismo para que las Actividades extraigan o actualicen
informacin que persisitir ms all del alcance del proceso. Un mismo Almacn de Datos puede
ser visualizado ms de una vez en un Proceso.
Ejemplo: diagrama
Explicacin
Un objeto de datos puede representar a un documento fsico o digital o cualquier
objeto que contenga informacin. Se une a las tareas mediante una flecha punteada
llamada asociacin de datos, la direccin de la flecha idnica si el objeto de datos es
generado por la tarea (salida) o utilizado por la tarea (entrada). Se utiliza para modelar
los documentos creados o utilizados durante un proceso. Slo el proceso que contiene
al objeto y los procesos que estn dentro de ste mismo pueden acceder al objeto de
datos. Procesos de niveles superiores no pueden hacerlo, pero de niveles inferiores s.
Se puede modelar el mismo objeto de Datos varias veces en un proceso. Esto no indica
que el objeto se genere varias veces, es ms bien una prctica que se utiliza para evitar
asociaciones de datos muy largas y mejorar la legibilidad del diagrama. Adems, debajo
del nombre del objeto de datos, se puede indicar su estado entre parntesis o
corchetes.
Ejemplo: explicacin
Se muestra un fragmento de un proceso de evaluacin de una solicitud de crdito. Al
inicio del proceso se recibe la solicitud. Note varias cosas: 1) la flecha va de la solicitud a
la tarea, esto quiere decir que la solicitud es una entrada para la tarea, es decir que la
tarea utiliza la solicitud. 2) Debajo del nombre del objeto de datos, se especifica su
estado entre corchetes ("Sin Evaluar"). Tras analizar el historial del cliente se decide si
aprobar o rechazar la solicitud. Para cada una de estas tareas se muestra un objeto de
datos que tiene el mismo nombre que el objeto ya mostrado. Esto indica que en
realidad es el mismo objeto, es decir, es la misma solicitud. Note que el estado cambia
tras realizar la tarea de aprobar o rechazar solicitud. Tambin revise la direccin de la
asociacin de datos (la flecha punteada), ahora va de la tarea al objeto, indicando que
la tarea altera el objeto.
Explicacin
Se comporta igual que el objeto de datos normal, pero indica de forma explcita que es
entrada para una tarea, es decir, que la tarea necesita del objeto de datos para ser
realizada. Se usan cuando la Tarea tiene una restriccin predefinida que indica que slo
puede ser ejecutada si tiene la Entrada de Datos disponible.
Ejemplo: explicacin
Se muestra un proceso sencillo de realizacin de un estudio de mercados. Primero se
realiza una encuesta, despus se capturan sus resultados, lo cual produce (es decir,
tiene por salida) una Salida de Datos llamado "Resultados de encuesta". Despus esta
informacin es analizada, y esta tarea tiene asociada una Entrada de Datos que
representa esos mismos resultados de la encuesta. Finalmente la tarea Generar
reporte... tiene asociada una salida de datos llamada "Reporte de resultados de
encuesta". Note cmo las entradas son informacin que se necesita para realizar una
tarea y las salidas son informacin producida. Note tambin las direcciones de las
asociaciones de datos (las flechas punteadas).
Explicacin
Se comporta igual que el objeto de datos normal, pero indica de forma explcita que es
una salida para una tarea, es decir, que la tarea genera al objeto de datos. Se usan
cuando la Tarea tiene una restriccin predefinida que indica que slo puede ser
completada si genera una Salida de Datos especfica.
Ejemplo: explicacin
Se muestra un proceso sencillo de realizacin de un estudio de mercados. Primero se
realiza una encuesta, despus se capturan sus resultados, lo cual produce (es decir,
tiene por salida) una Salida de Datos llamado "Resultados de encuesta". Despus esta
informacin es analizada, y esta tarea tiene asociada una Entrada de Datos que
representa esos mismos resultados de la encuesta. Finalmente la tarea Generar
reporte... tiene asociada una salida de datos llamada "Reporte de resultados de
encuesta". Note cmo las entradas son informacin que se necesita para realizar una
tarea y las salidas son informacin producida. Note tambin las direcciones de las
asociaciones de datos (las flechas punteadas).
Explicacin
Como su nombre lo indica es un conjunto de objetos de datos. Se comporta igual que el
Objeto de Datos sencillo, pero indica que en realidad es una coleccin de documentos,
archivos, etc.
Ejemplo: explicacin
Se muestra un proceso de construccin de una historia familiar o rbol genealgico. La
primera tarea, llamada "Buscar Acta" tiene asociado una Coleccin de Objetos de Datos
llamada "Archivo de actas de nacimiento de la ciudad". Se considera una coleccin
porque es un conjunto de documentos. La primera tarea utiliza esta coleccin (note la
direccin de la flecha punteada).
Explicacin
A difernecia del objeto de datos, el almacn representa un contenedor de informacin
que es accesible ms all del alcance del proceso en el que est contenido. Por ejemplo,
un almacn de datos puede representar una base de datos accesada durante el proceso
pero que tambin se utiliza en otros procesos y contextos.
Ejemplo: explicacin
Se muestra un proceso simplificado de una consulta mdica. Hay un almacn de datos
llamado "Base de datos de pacientes". Dos tareas del proceso utilizan este almacn. La
primera es para revisar el expediente del cliente y el almacn funje como entrada de
datos, es decir, la tarea lee infomracin del almacn (note la direccin de la flecha
punteada). La segunda tarea que utiliza el almacn es "Actualizar expediente del
paciente". Esta tarea escribe en el almacn de datos (note la direccin de la flecha
punteada).
Usos tpicos
*Generar o acceder a reportes,
facturas, listas, rdenes y otros
documentos.
Usos tpicos
*Cuando una tarea requiere de la
llegada de un documento, por
ejemplo realizar evaluaciones,
tomar decisiones basadas en
informacin, o procesar datos.
Usos tpicos
*Cuando una tarea genera un
documento, por ejemplo, realizar
un reporte, capturar informacin
de encuestas, generar una
factura, etc.
Usos tpicos
*Generar o acceder a archivos,
expedientes, contratos u otros
conjuntos de documentos.
Usos tpicos
*Para alterar o accesar a bases de
datos.
Familia: Flujos
Flujo de Secuencia
A Sequence Flow is used to
show the order that
Activities will be performed in a
Process (see page
97) and in a Choreography (see
page 320).
Flujo de Mensaje
A Message Flow is used to show
the flow of
Messages between two
Participants that are
prepared to send and receive
them (see page
120). In BPMN, two separate
Pools in a
Collaboration Diagram will
represent the two
Participants (e.g.,
PartnerEntities and/or
PartnerRoles).
Los Flujos se utilizan para indicar cmo se relacin e interaccin entre s los elementos de un diagrama. Indican el orden en el que se realizan las tareas, el
destinatario y emisor de un mensaje, los objetos que una tarea produce o que necesita para su realizacin, o indican que un artefacto est asociado de alguna forma
a un elemento.
Normal
Predefinido
Asociacin de
Datos
Una Asociacin se utiliza para
ligar informacin y Artefactos
con elementos grficos de
BPMN. Una flecha en la
asociacin indica la direccin de
flujo (por ejemplo de datos)
cuando esto es apropiado.
Asociacin
Una Associacin se utiliza para
vincular informacin y
Artefactos con elementos
grficos de BPMN. Se puede
Asociar Anotaciones de Texto y
otros artefactos con elementos
grficos. Una flecha en la
asociacin indica la direccin de
flujo (por ejemplo, de datos)
cuando es apropiado indicarla.
Sin Direccin
Unidireccional
Bidireccional
Se utiliza para indicar el orden en el que se
realizan las actividades. La flecha indica
cul es la actividad que sigue. Puede unir
tareas, Sub-Procesos, eventos y
compuertas. Existen dos variantes: flujo
predefinido, flujo condicional y flujo de
excepcin. El flujo de excepcin es aquel
que sale de un evento intermedio en la
frontera y que no es parte del flujo normal
sino que puede o no activarse
dependiendo de un suceso. El flujo
predefinido es el que sale de una
compuerta e indica que si ninguno de los
caminos de la compuerta se activan ese es
el que ser utilizado.
*Conectar eventos, actividades y
compuertas. *Se utiliza en
todos los procesos.
Se utiliza para indicar el envo de mensajes
y la direccin en la que se envan. La flecha
indica quin recibe el mensaje. Slo puede
unir dos contenedores diferentes o dos
elementos que se encuentran en
contenedores diferentes.
*Cuando hay interaccin entre
varios participantes, como envo y
recepcin de mensajes, correos,
documentos, etc.
Los Flujos se utilizan para indicar cmo se relacin e interaccin entre s los elementos de un diagrama. Indican el orden en el que se realizan las tareas, el
destinatario y emisor de un mensaje, los objetos que una tarea produce o que necesita para su realizacin, o indican que un artefacto est asociado de alguna forma
a un elemento.
Se utiliza para indicar que una actividad u
objeto hace uso de un objeto de datos. La
direccin de la flecha indica que la
actividad utiliza el objeto o lo genera (es
decir si es una entrada de datos o una
salida). Slo puede ser unidireccional.
*Siempre que se utilice un objeto
de datos.
Se utiliza para conectar una anotacin de
texto o almacn de datos a un objeto.
Puede ser unidireccional, bidireccional o no
tener direccin. Indica que hay una
relacin entre el artefacto y el elemento al
que ha sido conectado. El tipo de relacin
depende del artefacto utilizado (Vase
Anotacin de Texto y Almacn de Datos.
*Cuando se utiliza un artefacto
como una anotacin de texto o un
objeto de datos como un almacn
de datos.
Ejemplo: diagrama
Se muestra un diagrama sencillo con un proceso de decisin. Las
flechas indican el orden en el que se realiza el proceso. Note que
el flujo de secuenica un un evento de inicio, a una compuerta y a
tareas. Tambin se utiliza un flujo de secuencia predefinido en la
compuerta. Si los amigos no quieren ni pizza ni hamburguesas (es
decir, si no se activa ningn camino de la compuerta), entonces se
seguir el flujo de secuencia predefinido y se comer solo.
Se muestra un proceso sencillo en el que un diseador interacta
con su cliente. Note que los flujos de mensaje se utilizan para
modelar el envo de mensajes y que unen dos contenedores
distintos (o elementos dentro de dos contenedores distintos).
Note la direccin de los flujos de mensaje, esta indica quin enva
y quin recibe el mensaje.
Se muestra un proceso sencillo de anlisis de mercados. Las
Asociaciones de Datos son las flechas que unen los objetos de
datos (que tienen forma de documentos) con las tareas. Note que
la direccin de la asociacin de datos indica si la tarea utiliza o
genera el documento. A un documento utilizado por una tarea se
le llama una entrada de datos y a un documento generado por
una tarea se le llama salida de datos. En este caso el documento
"Resultados de encuesta" funje primero como salida y luego como
entrada de datos.
Se muestra un fragmento de un proceso largo que al ser
imprimido abarca varias pginas. El modelador ha agregado una
anotacin de texto para facilitar la lectura del diagrama, indicando
en qu pgina contina el proceso. La anotacin de texto se une a
un evento de vnculo utilizando una Asociacin sin direccin.
Familia: Coreografa
El diagrama de coreografa tiene un enfoque distinto a los diagramas de orquestacin o proceso comunes. Su objetivo no es mostrar el trabajo que se realiza dentro
de los participantes sino el intercambio de informacin ENTRE participantes. Se utiliza para organizar negociaciones, contratos y otras situaciones cuyas actividades
consisten exclusiva o principalmente en intercambiar mensajes. Se puede insertar un diagrama de Coreografa dentro de un diagrama de orquestacin para mostrar
cmo se relaciona la interaccin con la realizacin del trabajo. A este tipo de diagramas combinados se les llama diagramas de Colaboracin. Los diagramas de
Coreografa permiten el uso de todos los elementos propios de un diagrama de orquestacin y adems aaden tres elementos: la tarea de Coreografa, el artefacto
de mensaje y la Coreografa de llamada.
Nota: En las coreografas no hay un centro de manejo de datos. Esto implica que los participantes slo tienen acceso a la informacin que les ha sido enviada en
forma de mensajes. Ms an, es esta informacin la nica que les puede decir cundo actuar. Por este motivo un participante que inicia una tarea de coreografa
TIENE que haber participado en la tarea inmediatamente anterior. De otra forma, no hay manera de que sepa en qu momento especfico debe iniciar la tarea que le
corresponde. Por este mismo motivo no se utilizan Objetos de Datos en los diagramas de coreografa, ni ningn elemento que haga referencia al estado de algn
objeto o proceso. La nica informacin disponible es la que se transmite en los mensajes.
Tarea de
Coreografa
Una Tarea de coreografa es una
Actividad atmica en un
Proceso de Coreografa.
Representa una interaccin,
que incluye el intercambio de
uno o dos mensajes entre dos
participantes.
Mensaje
El Mensaje se utiliza para
modelar los contenidos de una
comunicacin entre dos
Participantes.
Iniciador
Respuesta
Sub-Coreografa
Una Sub-Coreografa es una
Actividad compuesta, ya que
tiene detalles definidos como
flujo de otras actividades, en
este caso, una Coreografa.
Cada Sub-Coreografa involucra
por lo menos dos Participantes.
Puede estar en estado
colapsado, escondiendo sus
detalles, o expandido,
mostrndolos.
Colapsada
Expandida
Con ms de 2 participantes
Marcador de Multi-
Instancia
Un Participante multiinstancia
representa una situacin en la
cual hay varios Participantes
posibles involucrados en la
Coreografa. Por ejemplo, en
una coreografa que involucra el
envo de un producto, puede
utilizarse ms de un tipo de
servicio de mensajera,
dependiendo del destino.
Cuando un Participante en una
Coreografa contiene multiples
instancias, el marcador multi-
instancia se aadira a la banda
del Participante.
Actividad de
Coreografa de
Llamada
Una Coreografa de Llamada
identifica un punto en el
proceso en el cual se utiliza una
Coreografa global o Tarea de
Coreografa global. La
Coreografa de Llamada acta
como un contenedor para la
inclusin del elemento de
Coreografa al que llama. Este
elemento de Coregrafa
previamente definido se
convierte en parte de la
definicin de la Coreografa
padre.
Ejemplo: Combinacin de diagramas de coreografa y orquestacin
Ejemplo: Manejo de la informacin en coreografas
A continuacin se presenta un ejemplo que ilustra cmo se pueden combinar los diagramas de coreografa y orquestacin para
formar un diagrama de colaboracin (el trmino colaboracin no es exclusivo de esta combinacin, sino que se refiere a
cualquier diagrama que tenga dos o ms Contenedores).
Este ejemplo ilustra por qu es OBLIGATORIO que el participante que inicia una tarea haya participado en la tarea anterior.
Ejemplo
Ejemplo
Elementos utilizables en una coreografa
Eventos
Tipo Inicio Intermedio
Nulo S S
Mensaje No No
Temporizador S S
Condicional S S
Seal S S
Mltiple S S
Mltiple Paralelo S S
Escalada No No
Error No N/A
Compensacin No No
A continuacin se presenta una lista detallada de los elementos que se pueden utilizar en un diagrama de Coreografa. Esto aplica
slo si el diagrama es exclusivamente de Coreografa. Si el diagrama es una Colaboracin (es decir si es una combinacin entre un
diagrama de Coreografa y uno de Orquestaci), entonces se pueden utilizar todos los elementos que se utilizan en
Colaboraciones o procesos "normales".
Vnculo N/A S
Cancelacin N/A N/A
Terminacin N/A N/A
Compuertas
Artefactos
Todos.
Actividades
Ninguna.
Objetos de Datos
Ninguno.
Contenedores
Ninguno.
Todas las compuertas son utilizables, siempre y cuando se recuerde que no existe un mecanismo de control de datos que
permita su visibilidad. La nica informacin a la que tienen acceso los Participantes es la contenida en los Mensajes.
El diagrama de coreografa tiene un enfoque distinto a los diagramas de orquestacin o proceso comunes. Su objetivo no es mostrar el trabajo que se realiza dentro
de los participantes sino el intercambio de informacin ENTRE participantes. Se utiliza para organizar negociaciones, contratos y otras situaciones cuyas actividades
consisten exclusiva o principalmente en intercambiar mensajes. Se puede insertar un diagrama de Coreografa dentro de un diagrama de orquestacin para mostrar
cmo se relaciona la interaccin con la realizacin del trabajo. A este tipo de diagramas combinados se les llama diagramas de Colaboracin. Los diagramas de
Coreografa permiten el uso de todos los elementos propios de un diagrama de orquestacin y adems aaden tres elementos: la tarea de Coreografa, el artefacto
de mensaje y la Coreografa de llamada.
Nota: En las coreografas no hay un centro de manejo de datos. Esto implica que los participantes slo tienen acceso a la informacin que les ha sido enviada en
forma de mensajes. Ms an, es esta informacin la nica que les puede decir cundo actuar. Por este motivo un participante que inicia una tarea de coreografa
TIENE que haber participado en la tarea inmediatamente anterior. De otra forma, no hay manera de que sepa en qu momento especfico debe iniciar la tarea que le
corresponde. Por este mismo motivo no se utilizan Objetos de Datos en los diagramas de coreografa, ni ningn elemento que haga referencia al estado de algn
objeto o proceso. La nica informacin disponible es la que se transmite en los mensajes.
La Tarea de coreografa representa el
envo, recepcin y respuesta de un
mensaje. Tiene tres partes: una pestaa
superior, una pestaa inferior y un
rectngulo central. Las pestaas se utilizan
para escribir el nombre de los participantes
involucrados en el intercambio de
mensajes. En el rectngulo central se
escribe el asunto de la conversacin y
junto a las pestaas se coloca una figura
con forma de mensaje debajo de la cual se
escribe el contenido del mensaje o
respuesta segn sea el caso. Una pestaa
debe ser blanca para identificar al que
inicia el intercambio y la otra gris para
identificar al que recibe el mensaje y
contesta. No es obligatorio que el receptor
conteste.
*Se utiliza en todas las
coreografas sin excepcin.
Es una figura en forma de carta que
representa un mensaje que enva el
participante. Debajo de sta se debe
colocar el contenido del mensaje. Si es
blanco, quiere decir que es el mensaje
inicial, si es gris, quiere decir que es la
respuesta al mensaje inicial. No es
obligatorio utilizar este objeto, pero es
recomendable hacerlo si el contenido de
los mensajes no es obvio. Se une a la tarea
de coreografa mediante una asociacin
(un tipo de flujo).
*Se utiliza en todas las
coreografas para escribir el
contenido de los mensajes.
Una sub-coreografa es una tarea de
coreografa que ha sido desglosada o
modelada a ms detalle. Puede estar
colapsada o expandida, ocultando o
mostrando su contenido. Es similar al sub-
proceso utilizado en los diagramas de
orquestacin. Las Sub-Coreografas pueden
tener ms de dos participantes. En este
caso, se puede aadir ms bandas a la
figura para indicar estos participantes
extra, pero no es obligatorio. Las bandas
extra pueden ser colocadas arriba o abajo,
segn prefiera el modelador o herramienta
de modelado.
*Cuando una parte de la
coreografa representa una
unidad lgica de comunicacin
pero puede ser desglosada.
Un marcador de multi-instancia en una de
las bandas de participante indica que ste
no es un ente especfico sino un rol. Por
ejemplo, si una empresa hace envos,
puede que los haga a travs de compaas
de mensajera distintas dependiendo del
producto. En un diagrama de coreografa
se podra colocar el nombre "empresa de
mensajera" en una banda de participante
y un marcador multi-instancia. Esto quiere
decir que el mensaje debe ir dirigido a la
empresa que en esa ocasin este
cumpliendo el rol de "empresa de
mensajera", sin importar qu empresa en
especfico sea.
*Cuando el participante no es una
persona o entidad especfica sino
un rol
Una coreografa de llamada es un objeto
que llama o invoca a una tarea de
coreografa global o coreografa global. Se
identifica por tener la misma forma del
objeto al que llama, pero con una lnea
gruesa. Una tarea de coreografa o
coreografa global es simplemente una
actividad que el modelador ha identificado
como reutilizable y que est diseada para
ser invocada desde otras coreografas. Se
utiliza cuando hay una coreografa o
procedimiento muy comn que aparece en
otras coreografas. El modelador la modela
como una coreografa global y la llama
cuando la necesita utilizando la actividad
de llamada; as se ahorra modelar lo
mismo muchas veces.
*Cuando una coreografa o tarea
de coreografa se utiliza de forma
idntica en varios diagramas.
Ejemplo: Combinacin de diagramas de coreografa y orquestacin
A continuacin se presenta un ejemplo que ilustra cmo se pueden combinar los diagramas de coreografa y orquestacin para
formar un diagrama de colaboracin (el trmino colaboracin no es exclusivo de esta combinacin, sino que se refiere a
cualquier diagrama que tenga dos o ms Contenedores).
Este ejemplo ilustra por qu es OBLIGATORIO que el participante que inicia una tarea haya participado en la tarea anterior.
Explicacin
Explicacin
El ejemplo es idntico al utilizado en esta gua para el elemento "Mensaje".
Observe que la coreografa existe en el espacio entre contenedores y se
conecta a estos de forma similar a como se indica el envo y recepcion de
mensajes en un proceso de colaboracin normal.
Fronterizo Fin
N/A S
S No
S N/A
S N/A
S No
S No
S No
No No
No No
No No
A continuacin se presenta una lista detallada de los elementos que se pueden utilizar en un diagrama de Coreografa. Esto aplica
slo si el diagrama es exclusivamente de Coreografa. Si el diagrama es una Colaboracin (es decir si es una combinacin entre un
diagrama de Coreografa y uno de Orquestaci), entonces se pueden utilizar todos los elementos que se utilizan en
Colaboraciones o procesos "normales".
El diagrama superior est mal modelado. La situacin es la siguiente: El
supervisor y el demoledor trabajan en una compaa de demolicin. Sus
bombas se detonan a control remoto al recibir un archivo detonador. El
modelador ha cometido un grave error: veamos lo que podra suceder. En la
primera tarea, el supervisor enva al demoledor el archivo llave para detonar
la bomba. En la segunda tarea el supervisor avisa a los inquilinos que el
edificio ser demolido, y estos confirman que ya han desalojado. En la tercera
tarea el demoledor enva el archivo de detonacin a la bomba, y la bomba
explota. La secuencia parece correcta y segura, pero no lo es. En la tercera
tarea, el demoledor inicia la interaccin, pero l no particip en la tarea
anterior. Esto quiere decir que no tiene idea de si los inquilinos ya enviaron su
mensaje de desalojo, lo nico que l sabe es que el supervisor ya le envi el
detonador. No hay forma de garantizar que el demoledor detonar la bomba
despus de que ocurra la segunda tarea (es decir, despus de que los
inquilinos hayan confirmado su desalojo), pues l no est consciente de ella;
ya que en una coreografa no hay un sistema central de manejo de
informacin que el demoledor pueda revisar para conocer qu tareas ya se
llevaron a cabo. Este ejemplo ilustra una leccin importante: el que inicia la
interaccin en una tarea TIENE que haber participado en la tarea anterior. El
diagrama inferior muestra cmo modelar esta coreografa correctamente.
N/A N/A
S No
N/A S
Todas las compuertas son utilizables, siempre y cuando se recuerde que no existe un mecanismo de control de datos que
permita su visibilidad. La nica informacin a la que tienen acceso los Participantes es la contenida en los Mensajes.
Ejemplo: diagrama
El diagrama de coreografa y de colaboracin que se muestran son
idnticos. Analcelos para comprender el funcionamiento de una
tarea de coreografa. La primera tarea de coreografa inicia
cuando el cliente enva una orden a la empresa (note que la banda
de cliente aparece en blanco, esto se debe a que l inicia la
interaccin), sta contesta con un mensaje de "Orden recibida"
(note que la banda de empresa es color gris, esto indica que la
empresa no inicia, sino responde a la interaccin). En la siguiente
tarea los roles se invierten, es la empresa quien comienza la
interaccin.
Se muestra una coreografa sencilla entre un paciente y la oficina
de su doctor. La interaccin la inicia el paciente (note que su
banda es color blanco), el mensaje que enva a la oficina es
"Quiero ver al doctor". La oficina del doctor contesta a ese
mensaje inicial (note que su banda aparece de color gris, porque
l no inicia la interaccin sino que contesta), enva la respuesta
"Venga a ver al doctor". La siguiente tarea se llama manejo de
sntomas. El paciente inicia la interaccin en esta tarea y no
requiere una respuesta para ser completada, el paciente
simplemente anuncia sus sntomas. Preste atencin a la siguiente
tarea. Ahora es la oficina del doctor quien la inicia (note el color
de las bandas). El resto de la coregrafa transcurre de forma
similar.
Se muestra la misma coreografa dos veces. Trata sobre una
empresa que tiene un problema y solicita a su departamento de
solucin de problemas que encuentre un producto para
resolverlo. El departamento de solucin de problemas se pone en
contacto con un proveedor y enva la informacin obtenida de
vuelta a la administracin. La actividad de coreografa que aparece
en medio, titulada "Investigacin de solucin", es una sub-
coreografa. En el primer diagrama aparece expandida y en el
segundo, colapsada.
Se muestra una coreografa sencilla en la que se atiende la orden
de un cliente. La segunda sub-coreografa, titulada "Manejo de
envo" indica cmo ser la interaccin entre la empresa y la
paquetera mediante la cul se enviarn los productos al cliente.
Note que en esta coreografa el participante "Paquetera" es un
participante multi-instancia (tiene el marcador de tres lneas
verticales en su banda). Esto indica que la coreografa "Manejo de
envo" debe darse entre la Empresa y la organizacin que en esta
instancia este cumpliendo el rol de "Paquetera". No se especifca
qu organizacin o empresa en especfico ser la que cumpla el
rol de paquetera en una instancia dada.
Se muestra una coreografa para el manejo de una orden realizada
por un cliente. La actividad de coreografa de llamada "Manejo de
envo" llama a una sub-coreografa del mismo nombre. Esta sub-
coreografa es utilizada por la empresa en varios de sus
diagramas, as que el modelador ha decidido modelarla por
separado, definirla como una coreografa global y llamarla cada
vez que se necesite utilizando una actividad de coreografa de
llamada. De esta forma, se ahorra el esfuerzo de modelar una
misma coreografa muchas veces.
Familia: Conversacin
Vnculo de
Conversacin
Los Vnculos de Conversacin se
utilzan para conectar
Conversaciones, Sub-
Conversaciones y
Conversaciones con los
participantes.
Conversacin
Es un elemento atmico del
diagrama de Conversacin.
Representa un conjunto de
Flujos de Mensaje agrupados en
base a un concepto o Clave de
Correlacin. Una Conversacin
siempre involucra dos o ms
Participantes.
El diagrama de Conversacin es un tipo informal de diagrama de Colaboracin. Se utiliza para mostrar de forma sinttica los intercambios de mensajes,
negociaciones e interacciones que se dan entre un conjunto de participantes. Un diagrama de conversacin hace uso solamente de artefactos, flujos de mensaje, y
tres elementos que no aparecen en otros tipos de diagrama: la Conversacin, Sub-Conversacin, el Vnnculo de Conversacin y la Conversacin de Llamada.
Sub-Conversacin
Una Sub-Conversacin es una
divisin jerrquica dentro de la
Colaboracin padre. Es un
objeto grfico dentro de una
Colaboracin, pero tambin
puede ser "abierto" para
mostrar detalles de ms bajo
nivel de la Conversacin, que
pueden incluir Flujos de
Mensaje, Conversacin y/o
otras Sub-Conversaciones. La
Sub-Conversacin tiene los
mismo participatnes que su
Conversacin padre.
Conversacin de
Llamada
Una Conversacin de Llamada
identifica un lugar en la
Conversacin (Colaboracin) en
donde se utiliza una
Conversacin global.
Llamando una
Conversacin
Llamando una
Colaboracin
Ejemplo: Combinacin de diagramas de conversacin y orquestacin
Elementos utilizables en un diagrama de Conversacin
Adems de los elementos propios del diagrama, se pueden utilizar solamente Contenedores, Artefactos, y Flujos de Mensaje.
Ejemplo
El siguiente ejemplo muestra cmo se pueden combinar diagramas de conversacin con diagramas de orquestacin. Este es un
tipo de diagrama de Colaboracin (cualquier diagrama con dos o ms contenedores es un diagrama de Colaboracin) y se utiliza
para, adems de modelar el proceso, mostrar de forma resumida las interacciones que se tendrn que realizar para que ste se
complete exitosamente.
El vnculo de conversacin se utiliza para
unir una conversacin a un contenedor
(participante) indicando que est
involucrado en esa conversacin. No se
puede unir dos contenedores directamente
usando Vnculos de Conversacin.
*Se usa en todos los diagramas de
conversacin.
La conversacin representa un conjunto de
intercambios de mensajes entre dos o ms
participantes. Los mensajes deben tener
alguna relacin lgica, por ejemplo ser
parte de una negociacin o tener un
objetivo comn.
*Se usa en todas las
conversaciones.
El diagrama de Conversacin es un tipo informal de diagrama de Colaboracin. Se utiliza para mostrar de forma sinttica los intercambios de mensajes,
negociaciones e interacciones que se dan entre un conjunto de participantes. Un diagrama de conversacin hace uso solamente de artefactos, flujos de mensaje, y
tres elementos que no aparecen en otros tipos de diagrama: la Conversacin, Sub-Conversacin, el Vnnculo de Conversacin y la Conversacin de Llamada.
Una Sub-Conversacin es un conjunto de
Conversaciones, Mensajes y otras Sub-
Conversaciones agrupadas por tener una
relacin lgica.
*Agrupar conversaciones en
unidades lgicas.
Una conversacin de llamada es un
elemento que indica dnde se debe utilizar
una Conversacin global o Colaboracin
global. Una conversacin o colaboracin
global es bsicamente un diagrama o
conjunto de intercambios de mensajes
reutilizable. Si una conversacin o
colaboracin determinada aparece muy
seguido, el modelador puede elegir
modelarla por separado, definirla como
global, y llamarla cuando la necesita. As se
ahorra el trabajo de modelar lo mismo
varias veces. Cuando la Conversacin de
Llamada llama a una colaboracin, puede
ser que los participantes no coincidan, es
decir que en la colaboracin estn
definidos como roles y que en la
conversacin sean entes especficos. Si es
el caso, ser necesario agregar etiquetas
para identificar quin est cumpliendo qu
rol de la colaboracin (Ver ejemplo).
*Reutilizar conversaciones que
aparecen comunmente.
Ejemplo: Combinacin de diagramas de conversacin y orquestacin
Adems de los elementos propios del diagrama, se pueden utilizar solamente Contenedores, Artefactos, y Flujos de Mensaje.
Explicacin
En el diagrama se muestra un proceso de manejo de una orden. Hay tres
participantes: "Tienda", "Cliente" y "Mensajera". El diagrama muestra el
proceso completo que ha de realizar la tienda e ilustra las interacciones que se
deben llevar a cabo entre sta y el Cliente y Mensajera. Note que los vnculos
de conversacin pueden ir unidos directamente a tareas especficas (como en
la conversacin "Compra") o simplemente a los contenedores (como en la
conversacin "Manejo y Envo"). Recuerde que una Conversacin es cualquier
intercambio de mensajes entre participantes. En la conversacin de compra
estos intercambios incluyen: el envo de la orden por parte del cliente, el cual
detona el evento de inicio de mensaje del proceso de la Tienda; el envo de la
cotizacin de la tienda al cliente; el envo del comprobante de pago del cliente
a la tienda; y el envo de la factura de la tienda al cliente. La conversacin
entre la Tienda y la Mensajera no es tan explcita y se utiliza simplemente
para indicar que en algn punto del proceso la Tienda y la Mensajera deben
ponerse de acuerdo sobre el Manejo y Envo de productos.
El siguiente ejemplo muestra cmo se pueden combinar diagramas de conversacin con diagramas de orquestacin. Este es un
tipo de diagrama de Colaboracin (cualquier diagrama con dos o ms contenedores es un diagrama de Colaboracin) y se utiliza
para, adems de modelar el proceso, mostrar de forma resumida las interacciones que se tendrn que realizar para que ste se
complete exitosamente.
Ejemplo: diagrama
Se muestra un diagrama de Conversacin que resume las
interacciones que tiene una Tienda con otros tres participantes:
"Servicio de mensajera", "Proveedor" y "Cliente". Estas
interacciones estn modeladas como conversaciones. As, la
Tienda interacta con el Cliente en la conversacin "Compra de
Productos", con el proveedor en "Solicitud de productos
ordenados" y con el Servicio de Mensajera en "Negociaciones de
Envo. Las conversaciones estn unidas a los participantes
involucrados utilizando vnculos de conversacin.
El ejemplo muestra un diagrama de Conversacin con una
Conversacin entre dos participantes: "Cliente" y "Tienda". El
diagrama de la derecha muestra un diagrama de Colaboracin
equivalente. Note que una conversacin no es ms que un
conjunto de flujos de mensaje que tienen alguna relacin lgica o
un objetivo comn.
El ejemplo muestra dos veces la misma conversacin. El diagrama
superior muestra una sub-conversacin colapsada, titulada
"Negociaciones de poltica exterior". El diagrama inferior muestra
esta misma sub-conversacin expandida. Note que la sub-
conversacin contiene la conversacin "Negociaciones de poltica
militar", el mensaje "Prstame dinero" y otra sub-conversacin
titulada "Negociaciones de poltica econmica. La relacin lgica
entre estos tres elementos es que todos forman parte de las
negociaciones de poltica exterior de estos dos pases.
El diagrama de la izquierda muestra una conversacin que llama a
una colaboracin con el ttulo "Adquisicin de Crdito". El
diagrama de la derecha es la colaboracin llamada. Note que los
nombres de los participantes no son idnticos, pero que los
participantes de la conversacin, estn cumpliendo el rol definido
en la colaboracin. Se aaden etiquetas de cada lado de la
conversacin para definir quin corresponde a qu rol. En este
caso, la Compaa Financiera est cumpliendo el rol de "Agencia
de Crdito". Y el minorista est cumpliendo el rol de "Comprador".

PocketGuide v1 0 BPMN2 Constructos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PocketGuide v1 0 BPMN2 Constructos

Cargado por

Copyright:

Formatos disponibles

Familia: Compuertas

Elemento 1: Compuerta Exclusiva

También podría gustarte