El lado más interesante de los Gateways Complejos es su comportamien- to unificador. Hay muchos patrones que pueden ser realizados junto con el Gateway Complejo, como el comportamiento típico de un Gateway In- clusivo, procesamiento de múltiples tokens, aceptar tokens de algunos caminos pero ignorar los tokens de otros, etc. El Gateway se ve de igual manera para cada uno de estos patrones, por lo que el modelador debe usar Anotación de Texto para informarle al lector del diagrama cómo se utiliza.
Mejor Práctica: Utilice una Anotación de Texto con el Gateway Complejo—
Dado que el comportamiento real de un Gateway Complejo puede variar para cada uso del Gateway, utilice una Anotación
de Texto para informarle al lector del diagrama qué comporta‐ miento tiene establecido para realizar el Gateway .
El Gateway Complejo usa una asignación entrante cuando un token llega. La condición de la asignación entrante puede referirse a información de un Proceso u Objeto de Dato, y el estado del Flujo de Secuencia entrante. Si la condición es falsa no ocurre nada aparte de que el token es mante- nido allí. Si la condición es verdadera, entonces la acción podría ser con- figurada para pasar el token al lado saliente del Gateway, y por ende acti- vando la asignación saliente, o la acción podría ser configurada para con- sumir el token.
De las diversas formas de utilizar un Gateway Complejo, se utilizara el patrón discriminador como demostración. En este patrón, hay dos o más actividades paralelas. Cuando una de las Actividades se completa, enton- ces las Actividades que la siguen pueden comenzar, excepto que no tiene importancia cual Actividad se completa. Este es otro ejemplo de condición
de carrera. Todas las Actividades restantes se completarán con normali-
dad, pero no tendrán impacto en el Flujo de Procesos.
En la Figura 9-32, la Tarea “Comenzar Análisis” debe empezar después de “Test A” o “Test B”, no importa cuál de las dos finaliza primero. Pero, después de que finalice la segunda, la Tarea “Comenzar Análisis” no debe empezar de nuevo. En cambio, si el modelador elige un Gateway Exclusi- vo para unificar el flujo, la Tarea “Comenzar Análisis” comenzará de nue- vo (es decir, dos instancias).
Figura 9-32—Un Gateway Complejo Unificando el Flujo de Secuencia
Si la Tarea “Ejecutar Test A” finaliza primero, su token es enviado al Ga- teway mientras que el otro token se mantiene en la Tarea “Ejecutar Test B” (véase Figura 9-33).
Ejecutar Test A Ejecutar Test B Comenzar Analisis Preparar Tests T T
Figura 9-33—Un token llega a un Gateway Complejo
Para este patrón, el primer token que llega es enviado inmediatamente mediante el Flujo de Secuencia saliente hacia la siguiente Actividad (véa- se Figura 9-34).
Figura 9-34—El primer token pasa a través del Gateway Complejo
Cuando el otro token finalmente llega, el mismo es consumido por el Ga- teway (véase Figura 9-35).
Ejecutar Test A Ejecutar Test B Comenzar Analisis Preparar Tests T T
Capítulo 10. Swimlanes
BPMN utiliza “swimlanes” para ayudar a dividir y organizar actividades en un diagrama. De estos, hay dos tipos principales:
• Pools—actúan como contenedores para un Proceso, cada uno re- presentando un participante en un Diagrama de Procesos de Ne- gocio colaborativo.
• Carriles—utilizados a menudo para representar roles de negocio internos dentro de un Proceso, los Carriles en realidad proveen un mecanismo genérico para particionar los objetos dentro de un Po- ol, basado en las características del Proceso o elementos.
Pools
El término “Pool” se obtuvo ampliando la analogía de swimlane. Una pis- cina de natación tiene carriles. BPMN tiene dos tipos de particiones swimlane y un tipo está incluido en el otro. Por lo tanto, tiene sentido llamar Carriles a las sub-particiones y, a la partición que contiene los Carriles, Pool.
En BPMN, los Pools representan participantes en un Diagrama de Proce- sos de Negocio interactivo o colaborativo. Un participante se define como un rol de negocios general, por ejemplo un comprador, vendedor, trans- portista o proveedor. Alternativamente, podría definir una entidad de ne- gocio específica, por ejemplo FedEx como el transportista. Cada Pool puede representar solo un participante.
Los Pools son representados como una caja rectangular que actúa como contenedor para los objetos de flujo, del Proceso de un participante. El Diagrama de Procesos de Negocio referido aquí es realmente una colabo-
ración, detallando cómo los participantes coordinan su comportamiento.
Los participantes pueden tener una representación abstracta (por ejemplo, el rol de “Comprador” o “Vendedor”) o pueden representar una entidad de negocio distinta (por ejemplo “IBM” o “Amazon.com”). 30
Ya que un diagrama BPMN puede describir los Procesos de diferentes
participantes, cada participante puede ver el diagrama de diferente mane-
ra. Es decir, cada participante tendrá un punto de vista diferente— algunas Actividades están bajo su control, mientras que otros Pools son externos a ellos.
En la práctica, cada Pool representa un Proceso diferente y cada partici-
pante tiene su propio Pool. No es necesario un Pool para contener un
Proceso. Conocidas como “caja negra”, estos Pools no muestran Activida- des o Flujos de Secuencias dentro de sus límites. La Figura 10-1, la cual fue utilizada en la Parte I de este libro, muestra un Pool “Banco Hipoteca-
<
30 El término “Participante” referencia a colaboraciones business-to-business, las cuales están a
cargo de sus propios Procesos. No se refieren a los roles o posiciones de trabajo de una organi- zación.
rio” conteniendo un Proceso y un Pool “Cliente” cuyo proceso es una caja
negra (en lo que se refiere a Banco Hipotecario, no tienen conocimiento
de los Procesos de sus clientes). Cuando el Pool es una caja negra, la forma del Pool puede ser redimensionada y posicionada en una forma que sea conveniente para el modelador (esto es, no tendría que extender- se todo el largo del diagrama).
Ban c o Hi pot ec ario C lie nt e
Figura 10-1—Una colaboración con dos Pools (una como “caja ne-
gra”).
Los Flujos de Mensajes manejan todas las interacciones entre Pools (y sus Procesos). Cuando el Pool es una caja negra, el Flujo de Mensajes se conecta a su límite. Cuando un Pool tiene elementos de Proceso, el Flujo de Mensajes se conecta a estos elementos (véase Figura 10-1, citada an- teriormente).
Como se discutió en la sección de Flujos de Secuencia, en la página 161, los Flujos de Secuencia no pueden cruzar el límite de un Pool—es decir, un Proceso está totalmente contenido dentro de un Pool. Consulte más acerca de la discusión sobre por qué el Flujo de Mensajes es utilizado pa- ra sincronizar los Procesos entre Participantes, en la página 165.
En algunos casos, cuando el punto de vista del diagrama es claro, el lími- te del Pool “principal” no se visualiza. Por ejemplo, los modeladores del
participante de “Banco Hipotecario” mostrado en la Figura 10-1, citada
anteriormente, han desarrollado el diagrama y pueden no querer mostrar el límite de su Pool para hacer énfasis en la diferencia entre participantes internos y externos (véase Figura 10-2).
Cl
ie
nte
Figura 10-2—Un Diagrama donde el límite de un Pool no es mostrado
Carriles
Los Carriles crean sub-particiones para los objetos dentro de un Pool (véase Figura 10-3). Estas particiones son utilizadas para agrupar ele- mentos del Proceso (mostrando como estos están relacionados), o qué roles tienen la responsabilidad de llevar a cabo las Actividades.
Los Carriles a menudo representan roles de la organización (por ejemplo, Manager, Administración, Asociado, etc.), pero pueden representar cual- quier clasificación deseada (por ejemplo, tecnología subyacente, depar- tamentos organizacionales, productos de la compañía, ubicación, etc.).
Enviar al aprobador Aprobar Solicitud Ge renci a Servidor Web Administración Estas actividades pueden ser iniciadas al mismo tiempo Email de solicitud de aprobación Información de la compra Preparar PO
Figura 10-3—Un ejemplo de Carriles dentro de un Pool
Es posible además anidar Carriles (véase Figura 10-4, donde el Carril “Marketing” está sub-dividido en “Pre-Venta” y “Post-Venta”).
Ventas Ma rketing Pr ov ee d o r Pr e- Ve nta Post -V enta In gen iería Vender al Cliente Acumular Requisitos Verificar Requisitos Desarollar Producto
Figura 10-4—Un ejemplo de Carriles anidados dentro de un Pool
Los puntos clave a recordar acerca de Carriles son:
• En BPMN 1.1 los Carriles pueden representar cualquier agrupa- ción lógica (no solo roles).31 Por ejemplo, pueden representar áreas
funcionales, sistemas de negocios, clasificaciones de negocios (por ejemplo, orientado al cliente, orientado al soporte, etc.), ubicacio- nes de negocios, etc.
• Los Flujos de Secuencia pueden cruzar los límites de un Carril. • Los Carriles pueden estar anidados.
• El Flujo de Mensajes no es utilizado dentro o a través de los Carri- les de un Pool. 32
<
31 Es probable que esto sea reforzado en BPMN 2.0.
32 Para una discusión más amplia de la razón de esto, consulte Flujo de Mensajes en la página
Artefactos
Los Artefactos proporcionan un mecanismo para capturar información
adicional sobre un proceso, más allá de la estructura subyacente de los diagramas de flujo. Esta información no afecta directamente las carac- terísticas del diagrama de flujo de un proceso.
Hay tres Artefactos estándar en BPMN: