El objetivo principal de BPMN es proporcionar una notación que sea comprensible para todos los involucrados en el negocio: los analistas de negocio que modelan los procesos, los desarrolladores que implementan la tecnología para ejecutar dichos procesos, y los usuarios que los administran y monitorean.(Especificación BPMN)
The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. BPMN Spec.
Modeling Languages-BPMNTM
Texto. texto. texto. texto. texto. texto.
Texto Tool Tip simple aTexto Tool Tip simple bTexto Tool Tip simple c Texto.
Texto Tool Tip default Texto
Texto Tool Tip simple Anchor Texto.
Texto Tool Tip simple Anchor Texto.
Texto Tool Tip simple Anchor Texto.
Texto Tool Tip simple Anchor Texto.
A Start Event MUST NOT be a target for Sequence Flows; it MUST NOT have incoming Sequence Flows.
BPMN-Specification-text. BPMN-Specification-text. BPMN-Specification-text.
BPMN-Specification-text. BPMN-Specification-text. BPMN-Specification-text.
BPMN Introducción
BPMN es un acrónimo de Business Process Model and Notation (www.bpmn.org), en castellano: Modelo y Notación de Procesos de Negocio.
BPMN fue creado y es mantenido por: Object Management Group (www.omg.org).
BPMN define un Modelo y una notación:
- Como Modelo, BPMN define un conjunto de conceptos y sus relaciones. Define qué es un Proceso, un Mensaje, una Actividad, etc. También define relaciones entre ellos: un Proceso tiene Actividades, un Proceso es instanciado, etc.
- Como una notación, BPMN define una forma de representar estos conceptos y relaciones gráficamente.
El propósito de este sitio es mostrar los principales conceptos de BPMN y su representación gráfica.
Es decir, BPMN crea un puente entre el diseño del proceso y su implementación.
Los usuarios de los procesos y los analistas que los modelan acostumbran visualizar los procesos como diagramas de flujo. Se crea una brecha entre esta notación y el formato de los lenguajes, como WSBPEL, en que se ejecutan los procesos. Esta brecha se puede cerrar con un mecanismo formal que mapee la descripción visual de los procesos al lenguaje de ejecución de éstos.
BPMN proporciona múltiples diagramas, que están diseñados para que los utilicen quienes diseñan y administran los procesos. BPMN también proporciona un mapeo al lenguaje de ejecución WSBPEL.
BPMN es una notación estándar que facilita la comprensión de los procesos dentro y entre las organizaciones.
BPMN sigue la tradición de las notaciones de diagramas de flujo. Además, la semántica de ejecución de BPMN está completamente formalizada.
BPMN está diseñado para cubrir muchos tipos de modelado procesos, según las necesidades del modelador. Por ejemplo, BPMN se puede utilizar para modelar:
- Procesos de alto nivel de abstracción, o muy detallados.
- Procesos para ser leídos por personas, o para ser ejecutados por un BPMNS.
- Procesos actuales (as-is) o Procesos nuevos (to-be).
- Procesos realizados por una parte de la organización, o cubrir un Proceso de Negocio de extremo a extremo (end-to-end), involucrando a agentes internos y externos a la organización.
- El detalle interno de un Proceso, o la interacción entre dos o más Procesos.
- Proceso de negocio privado detallado (ya sea ejecutable o no ejecutable) con interacciones con una o más entidades externas (o procesos de "caja negra").
- Relación detallada del proceso comercial ejecutable con una coreografía.
BPMN está orientado sólo al modelado de procesos. Esto siginifica que otros tipos de modelos normalmente utilizados en las organizaciones están fuera del alcance de BPMN, a saber:
- Definición de modelos organizativos y recursos,
- Modelado de datos e información,
- Modelado de reglas de negocio.
Relaciones Externas
Hay herramientas de modelado dedicadas a BPMN, pero hay otras que permiten crear otros tipos de diagramas, e incluso mezclarlos.
Es una buena práctica mantener separados los diagramas de cada lenguaje de modelado, para mostrar distintas vistas de un sistema: procesos, datos, organización, sistemas TI, entre otros.
Sin embargo, los elementos de las distintas vistas tienen relaciones. Por ejemplo, las Tareas Usuario de BPMN y los Casos de Uso UML representan el mismo "fenómeno": la interacción de una persona con una aplicación TI. Esto se puede modelar en EA de la siguiente manera.
Las Piscinas y Carriles en BPMN representan unidades de negocio y roles de negocio. Estos elementos se pueden relacionar con elementos UML que representan la estructura organizacional y los roles/cargos de la organización. Esto se puede modelar en EA de la siguiente manera.
En BPM, los Objetos de Datos representan los ítems que son creados y/o consumidos durante un Proceso. Sin embargo, BPMN no provee mecanismos para modelar las estructuras de estos ítems y sus relaciones. UML, por su parte, permite este modelado con diagramas de Clases. Esto se puede modelar en EA de la siguiente manera.
BPMN Proceso
Un Proceso es una secuencia de Actividades y Eventos que llevan a cabo un trabajo en una organización.
Los Procesos se pueden definir en cualquier nivel, desde Procesos que involucran a toda la organización, hasta Procesos realizados por una sola persona.
En BPMN, un Proceso se representa como un conjunto de Actividades, Compuertas y Eventos unidos por Flujos de Secuencia. Una serie de reglas definen cómo construir Procesos correctos dentro del lenguaje.
Un BPMN un Proceso siempre ocurre dentro de los límites de una Piscina.
En BPMN no existe un elemento "Proceso", es decir, no hay una figura para Proceso, así como existen los elementos Actividad, Compuerta, Evento, etc.
Un proceso puede tener varios niveles, es decir, puede incluir Subprocesos Embebidos o Actividades de Llamada que invocan a otros Procesos. El uso de Eventos Iniciales y Finales es independiente para cada nivel.
- Proceso Principal
- Subproceso
- Embebido
- Actividad de Llamada
Modelo Válido
BPMN entrega al Modelador gran flexibilidad para representar el comportamiento de procesos complejos de una manera compacta. Sin embargo, esta libertad permite crear modelos que no se pueden ejecutar, o que se comportan de una manera no esperada.
Esto pueden ocurrir porque no existe un pareo estricto entre bifurcaciones, uniones, divisiones y sincronizaciones. (Lo que sí existe en un lenguaje basado en bloques.)
Ejemplos: curso sesión 4.
Texto. texto. texto. texto. texto. texto.
BPMN Proceso Principal
El Proceso Principal tiene un responsable, que se puede especificar en la forma de un individuo específico, un grupo, un cargo o rol, o una organización. El responsable del Proceso Principal no es necesariamente el responsable de ejecutar las Actividades que contiene. (Incorporar el tema de Dueño, Responsable etc. del Proceso. Tomar definiciones de CBOK.)
Instancias de un Proceso. Cada vez que se gatilla un Evento Inicial se crea una nueva instancia del Proceso.
Texto. texto. texto. texto. texto. texto.
BPMN Subproceso
Aquí hay que explicar que los subprocesos sirven para detallar un Proceso Principal. Para una jerarquía de Procesos hay que usar Actividades de Llamada (Invocadoras).
Hay que poner un versión simplificada de la entrada Subproceso.
BPMN Proceso Global
Un Proceso Principal puede ser invocado desde otros Procesos a través de una Actividad de Llamada.
Proceso Global: Es un Proceso Principal que es invocado desde otro Proceso a través de un Actividad de Llamada. Para que pueda ser usado como Proceso Global, el Proceso Principal debe tener un Evento Inicial Vacío que se activará cuando sea invicado. Puede tener otro Evento Inicial no Vacío (por ejemplo, Mensaje o Condicional) que se usará para instanciar el Proceso de manera independiente.
Hay que poner un versión simplificada de la entrada Subproceso Reutilizable.
BPMN Proceso Ejecutable y No Ejecutable
Un Proceso Ejecutable ha sido diseñado para ser ejecutado por un BPMS. Durante su desarrollo, habrá etapas en las que el Proceso no tenga suficiente detalle para ser "ejecutable."
Un Proceso no Ejecutable ha sido diseñado para que una persona entienda el comportamiento del Proceso. El nivel de detalle está determinado por el público objetivo: nivel de conocimiento del lenguaje, uso que se hará del diagrama (conocer, seguir, sólo lo público, certificaciones, etc.). Normalmente, está centrado en los aspectos visuales, no incluye información (como las expresiones de condiciones formales) que incluye en un proceso Ejecutable.
Texto. texto. texto. texto. texto. texto.
BPMN Token
Un Token atraviesa Flujos de Secuencia y pasa a través de Actividades, Eventos y Compuertas dentro de los límites de un Piscina.
El comportamiento de Actividades, Eventos y Compuertas se puede definir describiendo cómo interactúan con los Tokens a medida que éstos los "atraviesan". Por ejemplo:
Un Token es un concepto teórico, las herramientas de modelado y ejecución de Procesos que implementan BPMN no están obligadas a implementar ningún tipo de Token.
Un Token nunca atraviesa un Flujo de Mensaje, y tampoco pasa por las Asociaciones.
El caso más simple es cuando un Evento Inicial genera un Token, lo que inicia la ejecución de una instancia del Proceso. El Token, en algún momento, llega al Evento Final donde es consumido. Con esto la instancia del Proceso termina.
Normalmente, el Proceso tiene un Evento Inicial, luego una serie de Compuertas que crean y unen caminos, los que llevan a varios Eventos Finales. En cada instancia del Proceso, el Token incial se dividirá y sicronizará de cierta forma, y los Tokens llegarán a uno o más de los Eventos Finales. En este caso, la instancia del Proceso terminará cuando todas las partes del Token original hayan llegado a un Evento Final.
En un escenario más sofisticado, además del Token creado en el Evento Inicial, se pueden crear otros Tokens en Eventos Intermedios en el Borde, y se pueden consumir Tokens a medio camino, por ejemplo, en Compuertas Complejas. En este caso, la instancia del Proceso terminará cuando todas los Tokens creados hayan sido consumidos.
Una Actividad se instancia cuando llega un Token. Si mientras está ejecutándose llega otro Token, por el mismo u otro Flujo de Secuencia, se crea una nueva instancia de la Actividad. Cuando se completa una instancia, se genera un Token por cada Flujo de Secuencia de salida activable. Este comportamiento puede ser modificado, e indicar que para instanciar la Actividad se requiere un número determinado de Tokens, y que al completarse la Actividad se generará un número determinado de Tokens. Esta posibilidad de modelado debe usarse con precaución.
Texto. texto. texto. texto. texto. texto.
BPMN Colaboración
BPMN usa el término Proceso específicamente para referirse a un conjunto de Elementos de Flujo unidos por Flujos de Secuencia. Para referirse a la interacción entre Procesos utiliza el término Colaboración.
Colaboración: Muestra dos o más Procesos en sus Piscinas, conectados por Flujos de Mensaje. Los Procesos pueden ser Públicos o Privados. Algunas Piscinas pueden ser "cajas negras".
Cada Participante ve la Colaboración de manera diferente. Es decir, los Participantes tienen diferentes puntos de vista del Proceso de Negocio. Algunas de las Actividades son internas del Participante (es decir, realizadas por o bajo su control) y otras Actividades serán externas al Participante.
Sin embargo, todo diagrama es realizado con un propósito específico dentro de una organización. Por lo tanto, en una Colaboración siempre habrá un Proceso central que representa el punto de vista de la organización, y otros secundarios que representan el entorno. Normalmente, el Proceso central está detallado, es decir, es un Proceso Privado, y los demás o son Públicos o están en Piscinas "caja negra".
BPMN no especifica ningún mecanismo gráfico para resaltar el punto de vista. El modelador o la herramienta de modelado pueden proporcionar indicaciones visuales para enfatizar este hecho en el diagrama.
BPMN Participante
Participante = Pool. No hay ningún elemento Pool en el metamodelo BPMN.
Los participantes se visualizan como Piscinas en una Colaboración.
Un Participante puede ser una Entidad Asociada (Partner Entity), por ejemplo, una empresa; o puede ser un Rol Asociado (Partner Rol), por ejemplo, comprador, vendedor o contratista.
Agregar la idea de "Participante sistémico", el que puede ser implementado con BPMS o no. El Participante sistémico puede tener Carriles que representan a Participantes tipo Entidad o Rol. Por ejemplo: Alumno es un Rol Asociado, pero puede ser un Carril en un BPMS. Explicar el ejemplo de Inscripción de Asignaturas. Sin TI no hay Participante sistémico. Con TI tres escenarios: formulario físico con Inscripción, formulario web no relacionado con BPMS, formulario web dentro de BPMS (en este caso hay un Carril sistémico "Alumno").
Un Participante es responsable de la ejecución del Proceso contenido en la Piscina que representa al Participante en el diagrama.
El nombre del Participante se muestra en la Piscina.
Un Participante participa en una o más Colaboraciones. En cada Colaboración está representado por una Piscina. Dentro de la Piscina se muestra lo que hace en Participante en esa Colaboración, es decir, el Proceso del Participante.
BPMN Proceso Público y Privado
Un Proceso Principal contiene Actividades y Eventos destinados a comunicarse con otros Procesos a través de Mensajes. Además, contiene otras Actividades, Eventos y Compuertas para realizar su trabajo interno.
Se dice que Proceso Principal es Privado cuando, en el diagrama, se muestra todo su contenido. Esta es la forma normal de mostrar un Proceso Principal que es interno a la organización dueña del modelo.
Se dice que un Proceso Principal es Público cuando, en el diagrama, se muestran solo aquellos elementos relevantes para la comunicación con otros Procesos. Por lo tanto, el Proceso Público muestra los Mensajes y el orden de estos Mensajes que se necesitan para interactuar con el mundo exterior. Esta es la forma normal de mostrar un Proceso Principal que es externo a la organización dueña del modelo, por ejemplo Proveedor, Cliente.
Un Proceso de Negocio involucra varias organizaciones. En cada organización el Proceso de Negocio tiene un foco distinto.
Si, por ejemplo, hay que negociar con otra organización sobre cómo se interactuará, no es necesario mostrar el Proceso Privado. Se puede crear una versión Privada del Proceso y entregarla a la otra organización.
Explicar Ejemplo de Ministerio y Municipalidades. Cada Municipalidad tiene su Proceso Privado que soporto al Proceso Público definido por el Ministerio.
Un Proceso Público muestra los elementos visibles para otros Participantes en una Colaboración, mientras que un Proceso Privado agrega otros elementos que no son visibles para terceros. Se espera que las instancias del Proceso Privado les parezcan a los otros Participantes como si fueran instancias del Proceso Público. Esto significa que el Proceso Privado "soporta" al Proceso Público. Se espera que todas las instancias del Proceso Privado sean válidas para el respectivo Proceso Público. (Ver p. 309.)
Un Proceso Público debe ser No Ejecutable. Un Proceso Privado puede ser Ejecutable o No Ejecutable.
En un Proceso Público las Actividades pueden considerarse los “puntos de contacto” con otros Participantes.
BPMN Proceso de Negocio
Al describir un Proceso de Negocio hay que responder a las preguntas:
- ¿Qué trabajo hay que hacer?
- ¿Quién hace el trabajo?
- ¿En qué orden se hace el trabajo?
- ¿Qué datos/información/recursos son creados y/o utilizados?, ¿cómo fluyen éstos a través del Proceso de Negocio?
¿Qué trabajo hay que hacer?
En BPMN el trabajo a realizar se describe con Actividades: Tareas y Sub-Procesos en sus diversas variantes.
¿Quién hace el trabajo?
En BPMN los responsables del trabajo se describen de dos maneras complementarias: Piscinas y Carriles.
Una Piscina es la representación gráfica de un Participante, que puede ser:
- una Entidad (Partner Entity), p. ej.: Banco, Ministerio.
- un Rol (Partner Role), p.ej.: Comprador, Vendedor, Proveedor.
Un Carril es una partición dentro de una Piscina, se usa para representar:
- Roles Internos, p.ej.: Gerente, Ejecutivo, Secretaria.
- Sistemas, p.ej.: Sistema de Contabilidad, ERP.
- Unidades Organizacionales, p.ej.: Gerencia de Operaciones, Departamento de Contabilidad.
Texto.
Texto.
¿En qué orden se hace el trabajo?
Texto.
¿Qué datos/información/recursos son creados y/o utilizados?, ¿cómo fluyen éstos a través del Proceso de Negocio?
Texto.
Un Mensaje siempre proviene de (la Piscina de) otro Participante, o es enviado a la (la Piscina de) otro Participante. El otro Participante puede estar o no dibujado en diagrama. Si está dibujado, un Flujo de Mensaje conecta el Evento con el Participante que envía el Mensaje.
Si la Piscina del Participante emisor no contiene el detalle de su Proceso, el origen del Flujo de Mensaje será la Piscina. Por otro lado, si la Piscina del Participante emisor contiene el detalle de su Proceso, el origen del Flujo de Mensaje un Evento o Actividad.
Definición de Proceso de Negocio. CBOK y otros.
Explicar que BPMN no contiene un elemento o diagrama Proceso de Negocio. A veces, por desliz, llama Proceso de Negocio al Proceso Principal.
Justificar que un Proceso de Negocio en BPMN se modela con una Colaboración.
Introducir la idea de "arquitectura del proceso de negocio". No es una tarea de modelado sencilla.
Criterios para determinar qué Particpantes serán cajas negras: Externo a la organización (no hay control y no se sabe qué pasa, tampoco hay responsabilidad). Independencia político administrativa. Entrega un servicio genérico dentro de la organización. No es exclusivo del proceso que se está modelando. Es sólo informado de lo que pasa. La acción que realiza la otra unidad es propia de su naturaleza y no del proceso que se está modelando, debería ser parte de un proceso de la otra unidad.
Destacar que solo hay que colocar los Participantes que realizan Actividades. Tomar la idea de RACI. Solo hay que colocar los "R", los demás solo cuando su actuación sí implica un acción concreta. Por ejemplo, que un "I" debe comprobar que efectivamente fue informado. O un "R" debe dar su aprobación. O un "C" explícitamente entrega su opinión.
Incorporar concepto de Colaboración "implícita".
Agregar la idea de Modelado de Procesos con un enfoque SOA, como se explica en CBOK.
Texto. texto. texto. texto. texto. texto.
BPMN Orquestación y Coreografía
Orquestación: A veces al Proceso Principal se le conoce como Proceso de Flujo de Trabajo (Workflow Process). También se le denomina Orquestación de Servicios.
Explicar la idea de "control centralizado" análogo al control del director de una orquesta. Primero aplicar la idea a un Proceso Ejecutable. Luego extrapolar la idea al un Proceso No Ejecutable. Usar el término "síncrono".
Explicar la idea de "control descentralizado" análogo al control en un ballet. Primero aplicar la idea a un Proceso Ejecutable. Luego extrapolar la idea al un Proceso No Ejecutable. Usar el término "asíncrono".
¿Cómo representar una Coreografía?
- Colaboración.
- Diagrama de Coreografía.
Texto. texto. texto. texto. texto. texto.
Metodologías y BPMN
Niveles de lenguaje.
- Lenguaje del usuario del proceso.
- Lenguaje de la metodología.
- Lenguaje BPMN.
Dos jerarquías de procesos: estructural y metodológica.
- Estructural: la definida en BPMN (top-level, sub-process, call-activity).
- Metodológica: típicamente Macroproceso, proceso, sub-proceso.
Especificación BPMN
The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. BPMN Spec.
Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation. BPMN Spec.
Business people are very comfortable with visualizing Business Processes in a flow-chart format. There are thousands of business analysts studying the way companies work and defining Business Processes with simple flow charts. This creates a technical gap between the format of the initial design of Business Processes and the format of the languages, such as WSBPEL, that will execute these Business Processes. This gap needs to be bridged with a formal mechanism that maps the appropriate visualization of the Business Processes (a notation) to the appropriate execution format (a BPM execution language) for these Business Processes.
Inter-operation of Business Processes at the human level, rather than the software engine level, can be solved with standardization of the Business Process Model and Notation (BPMN). BPMN provides multiple diagrams, which are designed for use by the people who design and manage Business Processes. BPMN also provides a mapping to an execution language of BPM Systems (WSBPEL). Thus, BPMN would provide a standard visualization mechanism for Business Processes defined in an execution optimized business process language.
BPMN provides businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Currently, there are scores of Process modeling tools and methodologies. Given that individuals will move from one company to another and that companies will merge and diverge, it is likely that business analysts need to understand multiple representations of Business Processes—potentially different representations of the same Process as it moves through its lifecycle of development, implementation, execution, monitoring, and analysis. Therefore, a standard graphical notation will facilitate the understanding of the performance Collaborations and business transactions within and between the organizations.
This will ensure that businesses will understand themselves and participants in their business and will enable organizations to adjust to new internal and B2B business circumstances quickly. BPMN follows the tradition of flowcharting notations for readability and flexibility. In addition, the BPMN execution semantics is fully formalized. The OMG is using the experience of the business process notations that have preceded BPMN to create the next generation notation that combines readability, flexibility, and expandability.
BPMN will also advance the capabilities of traditional business process notations by inherently handling B2B Business Process concepts, such as public and private Processes and Choreographies, as well as advanced modeling concepts, such as exception handling, transactions, and compensation.
BPMN is constrained to support only the concepts of modeling that are applicable to Business Processes. This means that other types of modeling done by organizations for business purposes is out of scope for BPMN. Therefore, the following are aspects that are out of the scope of this International Standard:
- Definition of organizational models and resources,
- Modeling of functional breakdowns,
- Data and information models,
- Modeling of strategy,
- Business rules models.
End
Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation. BPMN Spec.
Business people are very comfortable with visualizing Business Processes in a flow-chart format. There are thousands of business analysts studying the way companies work and defining Business Processes with simple flow charts. This creates a technical gap between the format of the initial design of Business Processes and the format of the languages, such as WSBPEL, that will execute these Business Processes. This gap needs to be bridged with a formal mechanism that maps the appropriate visualization of the Business Processes (a notation) to the appropriate execution format (a BPM execution language) for these Business Processes.
Inter-operation of Business Processes at the human level, rather than the software engine level, can be solved with standardization of the Business Process Model and Notation (BPMN). BPMN provides multiple diagrams, which are designed for use by the people who design and manage Business Processes. BPMN also provides a mapping to an execution language of BPM Systems (WSBPEL). Thus, BPMN would provide a standard visualization mechanism for Business Processes defined in an execution optimized business process language.
BPMN provides businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Currently, there are scores of Process modeling tools and methodologies. Given that individuals will move from one company to another and that companies will merge and diverge, it is likely that business analysts need to understand multiple representations of Business Processes—potentially different representations of the same Process as it moves through its lifecycle of development, implementation, execution, monitoring, and analysis. Therefore, a standard graphical notation will facilitate the understanding of the performance Collaborations and business transactions within and between the organizations.
This will ensure that businesses will understand themselves and participants in their business and will enable organizations to adjust to new internal and B2B business circumstances quickly. BPMN follows the tradition of flowcharting notations for readability and flexibility. In addition, the BPMN execution semantics is fully formalized. The OMG is using the experience of the business process notations that have preceded BPMN to create the next generation notation that combines readability, flexibility, and expandability.
BPMN will also advance the capabilities of traditional business process notations by inherently handling B2B Business Process concepts, such as public and private Processes and Choreographies, as well as advanced modeling concepts, such as exception handling, transactions, and compensation.
BPMN is constrained to support only the concepts of modeling that are applicable to Business Processes. This means that other types of modeling done by organizations for business purposes is out of scope for BPMN. Therefore, the following are aspects that are out of the scope of this International Standard:
- Definition of organizational models and resources,
- Modeling of functional breakdowns,
- Data and information models,
- Modeling of strategy,
- Business rules models.
External Relationships
It is the intention of this International Standard to cover the basic elements necessary for the construction of semantically rich and syntactically valid Process models to be used in the description of Processes, Choreographies, and business operations in multiple levels of abstraction. As the International Standard indicates, extension capabilities enable the enrichment of the information described in BPMN and supporting models to be augmented to fulfill particularities of a given usage model. These extensions’ intention is to extend the semantics of a given BPMN Artifact to provide specialization of intent or meaning.
Process models do not exist in isolation and generally participate in larger, more complex business and system development Processes. The intention of the following element is to enable BPMN Artifacts to be integrated in these development Processes via the specification of a non-intrusive identity/relationship model between BPMN Artifacts and elements expressed in any other addressable domain model.
The ‘identity/relationship’ model is reduced to the creation of families of typed relationships that enable BPMN and nonBPMN Artifacts to be related in non intrusive manner. By simply defining ‘relationship types’ that can be associated with elements in the BPMN Artifacts and arbitrary elements in a given addressable domain model, it enables the extension and integration of BPMN models into larger system/development Processes.
It is that these extensions will enable, for example, the linkage of ‘derivation’ or ‘definition’ relationships between UML artifacts and BPMN Artifacts in novel ways. So, a UML use case could be related to a Process element in the BPMN International Standard without affecting the nature of the Artifacts themselves, but enabling different integration models that traverse specialized relationships.
Simply, the model enables the external specification of augmentation relationships between BPMN Artifacts and arbitrary relationship classification models, these external models, via traversing relationships declared in the external definition allow for linkages between BPMN elements and other structured or non-structured metadata definitions.
The UML model for this International Standard follows a simple extensible pattern as shown below; where named relationships can be established by referencing objects that exist in their given namespaces.
T O K E N : Understanding the Behavior of Diagrams
Throughout this International Standard, we discuss how Sequence Flows are used within a Process. To facilitate this discussion, we employ the concept of a token that will traverse the Sequence Flows and pass through the elements in the Process. A token is a theoretical concept that is used as an aid to define the behavior of a Process that is being performed. The behavior of Process elements can be defined by describing how they interact with a token as it “traverses” the structure of the Process. However, modeling and execution tools that implement BPMN are NOT REQUIRED to implement any form of token.
To facilitate the definition of Sequence Flow (and other Process elements) behavior, we employ the concept of a token that will traverse the Sequence Flows and pass through the elements in the Process. A token is a theoretical concept that is used as an aid to define the behavior of a Process that is being performed. The behavior of Process elements can be defined by describing how they interact with a token as it “traverses” the structure of the Process. However, modeling and execution tools that implement BPMN are NOT REQUIRED to implement any form of token.
A Start Event generates a token that MUST eventually be consumed at an End Event (which MAY be implicit if not graphically displayed). The path of tokens should be traceable through the network of Sequence Flows, Gateways, and Activities within a Process.
NOTE: A token does not traverse a Message Flow since it is a Message that is passed down a Message Flow (as the name implies).
Activity attribute startQuantity: The default value is 1. The value MUST NOT be less than 1. This attribute defines the number of tokens that MUST arrive before the Activity can begin. Note that any value for the attribute that is greater than 1 is an advanced type of modeling and should be used with caution.
Activity attribute completionQuantity: The default value is 1. The value MUST NOT be less than 1. This attribute defines the number of tokens that MUST be generated from the Activity. This number of tokens will be sent done any outgoing Sequence Flow (assuming any Sequence Flow conditions are satisfied). Note that any value for the attribute that is greater than 1 is an advanced type of modeling and should be used with caution.
P R O C E S S
A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. In BPMN a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flows that define finite execution semantics (see Figure 10.1). Processes can be defined at any level from enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped together to achieve a common business goal.
A Process MAY have more than one Process level (i.e., it can include Expanded Sub-Processes or Call Activities that call other Processes). The use of Start and End Events is independent for each level of the Diagram. (The usage of expanded Sub-Processes for “parallel boxes” is the motivation for having Start and End Events being optional objects. It is a good practice to use start and end events, even if they are none events.)
Note that BPMN uses the term Process specifically to mean a set of flow elements. It uses the terms Collaboration and Choreography when modeling the interaction between Processes.
A Process is not a specific graphical object. Instead, it is a set of graphical objects.
A Process MAY have more than one Process level (i.e., it can include Expanded Sub-Processes or Call Activities that call other Processes).
Collaboration attribute participantAssociations: This attribute provides a list of mappings from the Participants of a referenced Collaboration to the Participants of another Collaboration. It is used in the following situations
- When a Choreography is referenced by the Collaboration.
- When a definitional Collaboration for a Process is referenced through a Call Activity (and mapped to definitional Collaboration of the calling Process).
A Process is a CallableElement, allowing it to be referenced and reused by other Processes via the Call Activity construct. In this capacity, a Process MAY reference a set of Interfaces that define its external behavior. A Process is a reusable element and can be imported and used within other Definitions.
isClosed: A boolean value specifying whether interactions, such as sending and receiving Messages and Events, not modeled in the Process can occur when the Process is executed or performed. If the value is true, they MAY NOT occur. If the value is false, they MAY occur.
supports: Modelers can declare that they intend all executions or performances of one Process to also be valid for another Process. This means they expect all the executions or performances of the first Processes to also follow the steps laid out in the second Process.
resources: Defines the resource that will perform or will be responsible for the Process. The resource, e.g., a performer, can be specified in the form of a specific individual, a group, an organization role or position, or an organization. Note that the assigned resources of the Process does not determine the assigned resources of the Activities that are contained by the Process.
For Processes that interact with other Participants, a definitional Collaboration can be referenced by the Process. The definitional Collaboration specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flows. The definitional Collaboration need not be displayed. Additionally, the definitional Collaboration can be used to include Conversation information within a Process.
Process Types
ProcessType (none, Private, Public) The processType attribute Provides additional information about the level of abstraction modeled by this Process.
A public Process shows only those flow elements that are relevant to external consumers. Internal details are not modeled. These Processes are publicly visible and can be used within a Collaboration. (Note that the public processType was named abstract in BPMN 1.2.)
A private Process is one that is internal to a specific organization. By default, the processType is “none,” meaning undefined.
An executable Process is a private Process that has been modeled for the purpose of being executed according to the semantics of Clause 14. Of course, during the development cycle of the Process, there will be stages where the Process does not have enough detail to be “executable.”
A non-executable Process is a private Process that has been modeled for the purpose of documenting Process behavior at a modeler-defined level of detail. Thus, information needed for execution, such as formal condition expressions are typically not included in a non-executable Process. The value MAY not be true for public Processes.
Business Process modeling is used to communicate a wide variety of information to a wide variety of audiences. BPMN is designed to cover many types of modeling and allows the creation of end-to-end Business Processes. There are three basic types of BPMN Processes:
Private (Internal) Business Processes
Private Business Processes are those internal to a specific organization. These Processes have been generally called workflow or BPM Processes (see Figure 10.4 ). Another synonym typically used in the Web services area is the Orchestration of services. There are two types of private Processes: executable and non-executable. An executable Process is a Process that has been modeled for the purpose of being executed according to the semantics defined in Clause 14. Of course, during the development cycle of the Process, there will be stages where the Process does not have enough detail to be “executable.” A non-executable Process is a private Process that has been modeled for the purpose of documenting Process behavior at a modeler-defined level of detail. Thus, information needed for execution, such as formal condition Expressions are typically not included in a non-executable Process. If a swimlanes-like notation is used (e.g., a Collaboration, see below), then a private Business Process will be contained within a single Pool. The Process flow is therefore contained within the Pool and cannot cross the boundaries of the Pool. The flow of Messages can cross the Pool boundary to show the interactions that exist between separate private Business Processes.
Public Processes
A public Process represents the interactions between a private Business Process and another Process or Participant (see Figure 10.5). Only those Activities that are used to communicate to the other Participant(s), plus the order of these Activities, are included in the public Process. All other “internal” Activities of the private Business Process are not shown in the public Process. Thus, the public Process shows to the outside world the Messages, and the order of these Messages, that are needed to interact with that Business Process. Public Processes can be modeled separately or within a Collaboration to show the flow of Messages between the public Process Activities and other Participants. Note that the public type of Process was named “abstract” in BPMN 1.2.
Process Instances
A Process can be executed or performed many times, but each time is expected to follow the steps laid out in the Process model. For example, the Process in Figure 10.1 (does not correspond to the described example) will occur every Friday, but each instance is expected to perform Task “Receive Issue List,” then Task “Review Issue List,” and so on, as specified in the model. Each instance of a Process is expected to be valid for the model, but some instances might not, for example if the Process has manual Activities, and the performers have not had proper instruction on how to carry out the Process.
Global process
What a global process is? It is a "called process". A callable Process that can be invoked from Call Activities of other Processes.
Compare this (p.426): Note that a global Process MUST neither have any empty Start Event nor any Gateway or Activity without incoming Sequence Flows. An exception is the Event Gateway. With this (p 238): If the Process is used as a global Process and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered.
Process Instantiation
Advanced
Unmodeled Activities and Public Processes
In some applications it is useful to allow more Activities and Events to occur when a Process is executed or performed than are contained in the Process model. This enables other steps to be taken as needed without changing the Process. For example, instances of the Process in Figure 10.1 might execute or perform an extra Activity between Task “Receive Issue List” and Task “Review Issue List.” These instances are still valid for the Process model in Figure 10.1, because the instances still execute or perform the Activities in the Process, in the order they are modeled and under conditions specified for them.
There are two ways to specify whether unmodeled Activities are allowed to occur in Process instances:
Sequence Flow attribute: isImmediate, a boolean value specifying whether Activities or Choreography Activities not in the model containing the Sequence Flow can occur between the elements connected by the Sequence Flow. If the value is true, they MAY NOT occur. If the value is false, they MAY occur. For non-executable Processes the default value is isImmediate = false. For executable Processes always isImmediate = true. Also see the isClosed attribute on Process, Choreography, and Collaboration. When the attribute has no value, the default semantics depends on the kind of model containing Sequence Flows:
- Private Non-executable (internal) Business Processes
- Private Executable (internal) Business Processes
- Public Processes
- If the isClosed attribute of a Process has a value of false or no value, then interactions, such as sending and receiving Messages and Events, MAY occur in an instance without additional flow elements in the Process. Unmodeled interactions can still be restricted on particular Sequence Flow in the Process (see next bullet). If the isClosed attribute of a Process has a value of true, then interactions, such as sending and receiving Messages and Events, MAY NOT occur without additional flow elements in the Process. This restriction overrides any unmodeled interactions allowed by Sequence Flows in the next bullet.
- If the isImmediate attribute of a Sequence Flow in a Process has a value of false, then other Activities and interactions not modeled in the Process MAY be executed or performed during the Sequence Flow. If the isImmediate attribute has a value of true, then Activities and interactions not modeled in the Process MAY NOT be executed or performed during Sequence Flow. In non-executable Processes (isExecutable attribute has value false, or defaults to false), Sequence Flows with no value for isImmediate are treated as if the value were false. In executable Processes (isExecutable attribute has value true, or defaults to true), Sequence Flows with no value for isImmediate are treated as if the value were true. Executable Processes cannot have a false value for the isImmediate attribute.
Restrictions on unmodeled Activities specified with isClosed and isImmediate apply only under executions or performances (instances) of the Process containing the restriction. These Activities MAY occur in instances of other Processes.
When a Process allows Activities to occur that the Process does not model, those Activities might appear in other Process models. The executions or performances (instances) of these other Processes might be valid for the original Process. For example, a Process might be defined similar to the one in Figure 10.1 that adds an extra Activity between Task “Receive Issue List” and Task “Review Issue List.” The Process in Figure 10.1 might use isClosed or isImmediate to allow other Activities to occur in between Task “Receive Issue List” and Task “Review Issue List.” When the Process is executed or performed, then instances of the other Process (the one with the extra step in between Task “Receive Issue List” and Task “Review Issue List”) will be valid for the Process in Figure 10.1. Modelers can declare that they intend all instances of one Process will be valid for another Process using the supports association between the Processes. During development of these Processes, support might not actually hold, because the association just expresses modeler intent.
A common use for model support is between private and public Processes, see “Overview” (page 21). A public Process contains Activities visible to external parties, such as Participants in a Collaboration, while a private Process includes other Activities that are not visible to external parties. The hidden Activities in a private Process are not modeled in the public Process. However, it is expected that instances of the private Process will appear to external parties as if they could be instances of the public Process. This means the private Process supports the public Process (it is expected that all instances of the private Process will be valid for the public one).
A Process that supports another, as a private Process can to a public Process, does not need to be entirely similar to the other Process. It is only REQUIRED that instances of the Process appear as if they could be instance of the other Process. For example Figure 10.127 shows a public Process at the top with a Send Task and Receive Task. A supporting private Process is shown at the bottom. The private Process sends and receives the same Messages, but using Events instead of Tasks. It also introduces Activities not modeled in the public Process. However all instances of the private Process will appear as if they could be instances of the public one, because the Messages are sent and received in the order REQUIRED by the public Process, and the public Process allows unmodeled Activities to occur.
In practice, a public Process looks like an underspecified private Process. Anything not specified in the public Process is determined by the private one. For example, if none of the outgoing Sequence Flows for an Exclusive Gateway have conditionExpressions, the private Process will determine which one of the Activities targeted by the Sequence Flows will occur. Another example is a Timer Event with no EventDefinition. The private Process will determine when the timer goes off.
P A R T I C I P A N T
Paticipant = Pool. There is no Pool element in the BPMN metamodel.
Participants are visualized as Pools in a Collaboration.
A Participant (see page 113) can be a specific PartnerEntity (e.g., a company) or can be a more general PartnerRole (e.g., a buyer, seller, or manufacturer).
A Participant represents a specific PartnerEntity (e.g., a company) and/or a more general PartnerRole (e.g., a buyer, seller, or manufacturer) that are Participants in a Collaboration. A Participant is often responsible for the execution of the Process enclosed in a Pool; however, a Pool MAY be defined without a Process.
A Participant plays a PartnerRol, a PartnerEntity or both.
The name of the Participant can be displayed directly or it can be substituted by the associated PartnerRole or PartnerEntity. Potentially, both the PartnerEntity name and PartnerRole name can be displayed for the Participant.
The processRef attribute identifies the Process that the Participant uses in the Collaboration. The Process will be displayed within the Participant’s Pool.
A Participant could represent more than one (1) instance for a given interaction. For example, a manufacturer can request a quote from multiple suppliers in a Collaboration.The multi-instance marker will be displayed in bottom center of the
There are situations where the Participants in different diagrams can be defined differently because they were developed independently, but represent the same thing.
- High-level non-executable Process Activities (not functional breakdown).
- Detailed executable Business Process.
- As-is or old Business Process.
- To-be or new Business Process.
- A description of expected behavior between two (2) or more business Participants—a Choreography.
- Detailed private Business Process (either executable or non-executable) with interactions to one or more external Entities (or “Black Box” Processes).
- Two or more detailed executable Processes interacting.
- Detailed executable Business Process relationship to a Choreography.
- Two or more public Processes.
- Public Process relationship to Choreography.
- Two or more detailed executable Business Processes interacting through a Choreography.
Diagram Point of View
Since a BPMN Diagram MAY depict the Processes of different Participants, each Participant could view the Diagram differently. That is, the Participants have different points of view regarding how the Processes will apply to them. Some of the Activities will be internal to the Participant (meaning performed by or under control of the Participant) and other Activities will be external to the Participant. Each Participant will have a different perspective as to which are internal and external. At runtime, the difference between internal and external Activities is important in how a Participant can view the status of the Activities or troubleshoot any problems. However, the Diagram itself remains the same. Figure 7.3 displays a Business Process that has two points of view. One point of view is of a Patient, the other is of the Doctor’s office. The Diagram shows the Activities of both participants in the Process, but when the Process is actually being performed, each Participant will only have control over their own Activities. Although the Diagram point of view is important for a viewer of the Diagram to understand how the behavior of the Process will relate to that viewer, BPMN will not currently specify any graphical mechanisms to highlight the point of view. It is open to the modeler or modeling tool vendor to provide any visual cues to emphasize this characteristic of a Diagram.
