Otros
En toda comunicación hay intercambio de datos, por ejemplo: nombre del cliente, dirección de despacho. etc. A nivel tecnológico el intercambio de datos puede ser visto como intercambio de bits o bytes, pero para un Proceso de Negocios el nivel significaivo es el par [atributo, valor]. Por ejemplo: [fecha de nacimiento, 12/enero/1989].
Una parte esencial del modelado de Procesos es el modelado de ítems creados, manipulados y usados durante la ejecución de un Proceso. Estos ítems pueden ser datos, información, elementos físicos, productos y/o servicios. (Poner ejemplos: el catálogo de productos, y los productos en sí.)
(Colocar imagen IDEF que muestra claramente lo que una Actividad requiere y lo que transforma.)
Además de la representación gráfica de los ítems que maneja el Proceso, es importante conocer las estructuras de datos que describen estos ítems, y tener la capacidad de consultarlos y manipularlos. (Esto no es parte de BPMN.)
Se puede hacer una analogía con elementos usados en lengajes de programación como variables, parámetros y conectores a base de datos.
BPMN contiene varios elementos que almacenan y transportan ítems durante la ejecución del Proceso. En la Especificación de BPMN se les denomina "item-aware elements".
| Elemento | Icono | Descripción |
|---|---|---|
| Objeto de Datos |
Icono | Los Objetos de Datos representan ítems que son creados, manipulados y consumidos, por Actividades y Eventos, dentro de los límites de un Proceso. |
| Almacén de Datos |
Icono | Un Almacén de Datos representa un lugar donde se guardan ítems que trascienden al Proceso, es decir, que existen antes y/o después del Proceso. El Proceso recupera estos ítems, los manipula y los actualiza. |
| Entrada / Salida de Datos |
Icono | Las Entradas/Salidas de Datos describen los ítems que recibe/entrega un Proceso cuando es llamado desde otro Proceso, vía una Actividad de Llamada. |
| Mensaje | Icono | La comunicación entre los Procesos de dos Participantes se describe con un Flujo de Mensaje. El Mensaje representa el contenido de dicha comunicación. |
| Error | Icono | Se genera un Error cuando hay un problema crítico en el procesamiento de una Actividad. El Error contiene información sobre sobre su origen. No tiene representación gráfica. |
| Señal | Icono | Una Señal es un mecanismo general de comunicación dentro y entre niveles de Proceso. La Señal representa el contenido de dicha comunicación. No tiene representación gráfica. |
| Escalada | Icono | Una Escalada identifica una situación, no crítica, a la que un Proceso necesita reaccionar. La Escalada contiene información sobre su origen. No tiene representación gráfica. |
Nota: A pesar de que algunos de los elementos tienen en su nombre la palabra "Dato", no están limitados sólo a representar datos, sino que representan ítems en general: datos, información, elementos físicos, productos y/o servicios.
BPMN establece dos tipos predeterminados de ítem: información y elemento físico (Information y Physical). Sin embargo, no hay diferencia en la figura utilizada. La herramienta o el modelador puede usar diferentes colores para resaltar el tipo de ítem.
Cuando una Actividad o Evento están listos para comenzar la ejecución, deben esperar a que los ítems requeridos estén disponibles. La forma en que esto se lleva a cabo, y se representa gráficamente, depende de la Actividad o Evento, y del elemento que contiene los ítems.
Durante la ejecución de Actividad o la activación de un Evento, se pueden producir ítems. La forma en que esto se lleva a cabo, y se representa gráficamente, depende de la Actividad o Evento, y del elemento que contiene los ítems.
Una Actividad espera que sus ítems estén disponibles para comenzar su ejecución. Una vez terminada su ejecución, se llenan los ítems de salida.
En el caso de los Eventos de Lanzamiento y Captura, dada su naturaleza, el manejo de los ítems es diferente.
Cuando se activa un Evento de Lanzamiento, se toman todos los ítems de entrada, y con estos se crea el elemento lanzado por el Evento (Mensaje, Señal, etc.). En el caso más simple, el Evento tiene solo una entrada que tiene la misma estructura del elemento lanzado.
Cuando se activa un Evento de Captura, los ítems de salida del Evento se llenan con el contenido del elemento que activó el Evento (Mensaje, Señal, etc.). En el caso más simple, el Evento tiene solo una salida que tiene la misma estructura del elemento capturado.
No es parte BPMN la definición de un lenguaje para describir las estructuras de datos y realizar consultas sobre ellos. BPMN permite la coexistencia de múltiples lenguajes para describir los datos (por ejemplo, XPath). La compatibilidad y verificación de estos lenguajes es responsabilidad del proveedor de la herramienta. (Esto es relevante cuando se usa BPMN para la ejecución de procesos, pero no para el modelado de procesos.)
Recursos
Además de ítems que el Proceso crea y/o transforma, las Actividades requieren otros recursos para realizar su trabajo. Por ejemplo: personas, normas, herramientas.
BPMN no incorpora ningún elemento gráfico para mostrar estos Recursos en el diagrama. Es posible crear nuevos Artefactos este efecto. Sin embargo, en la descripción de las Actividades debe entregarse el detalle de los Recursos requeridos.
El Ejecutor de la Actividad es en sí un Recurso que ya está representado por la Piscina o Carril donde está la Actividad.
Nota: para Procesos Ejecutables, el modelo subyacente BPMN sí considera la todación de recursos a las Actividades. Ver Resource y ResourceParameter. Los detalles dependerán de cómo un BPMS implemente esta funcionalidad.
Especificación BPMN
Item Definition
BPMN elements, such as DataObjects and Messages, represent items that are manipulated, transferred, transformed, or stored during Process flows. These items can be either physical items, such as the mechanical part of a vehicle, or information items such the catalog of the mechanical parts of a vehicle.
An important characteristics of items in Process is their structure. BPMN does not require a particular format for this data structure, but it does designate XML Schema as its default. The structure attribute references the actual data structure.
In cases where the data structure represents a collection, the multiplicity can be projected into the attribute isCollection.
The itemKind attribute specifies the nature of an item which can be a physical or an information item. The default value is information.
Message, Error, Escalation, ItemAwareElement (Property, DataInput, DataOutput, DataObject, DataStore), ResourceParameter are related to an ItemDefinition.
Resources
The Resource class is used to specify resources that can be referenced by Activities. These Resources can be Human Resources as well as any other resource assigned to Activities during Process execution time.
The definition of a Resource is “abstract,” because it only defines the Resource, without detailing how e.g., actual user IDs are associated at runtime. Multiple Activities can utilize the same Resource.
Every Resource can define a set of ResourceParameters. These parameters can be used at runtime to define query e.g., into an Organizational Directory. Every Activity referencing a parameterized Resource can bind values available in the scope of the Activity to these parameters.
Resources can be assigned to an Activity using Expressions. These Expressions MUST return Resource entity related data types, like Users or Groups. Different Expressions can return multiple Resources. All of them are assigned to the respective subclass of the ResourceRole element, for example as potential owners.
Error, Escalation and Signal are "item-aware" also. But they are not graphically represented.
A traditional requirement of Process modeling is to be able to model the items (physical or information items) that are created, manipulated, and used during the execution of a Process. An important aspect of this is the ability to capture the structure of that data and to query or manipulate that structure.
This requirement is realized in BPMN through various constructs.
Error, Escalation and Signal are "item-aware" also. The ErrorEventDefinition, EscalationEventDefinition, and SignalEventDefinition subclasses comprise of attributes to carry data. But they are not graphically represented.
Data Objects provide information about what Activities require to be performed and/or what they produce (see page 204), Data Objects can represent a singular object or a collection of objects. Data Input and Data Output provide the same information for Processes.
A Message is used to depict the contents of a communication between two Participants (as defined by a business PartnerRole or a business PartnerEntity—see on page 91). AVERIGUAR SI MESSAGE ES UN DATA OBJECT O UN ARTIFACT.
Execution Semantics for Data
When an element that defines an InputOutputSpecification is ready to begin execution by means of Sequence Flow or Event being caught, the inputs of the interface are filled with data coming from elements in the context, such as Data Objects or Properties. The way to represent these assignments is the Data Association elements.
Each defined InputSet element will be evaluated in the order they are included in the InputOutputSpecification.
For each InputSet, the data inputs it references will be evaluated if it is valid.
All data associations that define as target the data input will be evaluated, and if any of the sources of the data association is “unavailable,” then the InputSet is “unavailable” and the next InputSet is evaluated.
The first InputSet where all data inputs are “available” (by means of data associations) is used to start the execution of the Activity. If no InputSet is “available,” then the execution will wait until this condition is met.
The time and frequency of when and how often this condition is evaluated is out of scope for this International Standard. Implementations will wait for the sources of data associations to become available and then re-evaluate the InputSets.
In the case of throw and catch Events, given their nature, the execution semantics for data is different.
When a throw Event is activated, all DataInputAssociations of the event are executed, filling the Data Inputs of the Event. Finally, DataInputs are then copied to the elements thrown by the Event (Messages, Signals, etc.). Since there are no InputSets defined for Events, the execution will never wait.
When a catch Event is activated, Data Outputs of the event are filled with the element that triggered the Event. Then all DataOutputAssociations of the Event are executed. There are no OutputSets defined for Events. Once an InputSet becomes “available,” all Data Associations whose target is any of the Data Inputs of the InputSet are executed. These executions fill the Activity Data Inputs and the execution of the Activity can begin. When an Activity finishes execution, all Data Associations whose sources are any of the Data Outputs of the OutputSet are executed. These executions copy the values from the Data Outputs back to the container’s context (Data Object, Properties, etc.).
Execution Semantics for DataAssociation
The execution of any Data Associations MUST follow these semantics:
- If the Data Association specifies a “transformation” Expression, this expression is evaluated and the result is copied to the targetRef. This operation replaces completely the previous value of the targetRef element.
- For each “assignment” element specified:
- Evaluate the Assignment’s “from” expression and obtain the *source value*.
- Evaluate the Assignment’s “to” expression and obtain the *target element*. The *target element* can be any element in the context or a sub-element of it (e.g., a DataObject or a sub-element of it).
- Copy the *source value* to the *target element*.
- If no “transformation” Expression nor any “assignment” elements are defined in the Data Association:
- Copy the Data Association “sourceRef” value into the “targetRef.” Only one sourceRef element is allowed in this case.
Advanced
BPMN does not itself provide a built-in model for describing structure of data or an Expression language for querying that data. Instead it formalizes hooks that allow for externally defined data structures and Expression languages. In addition, BPMN allows for the co-existence of multiple data structure and Expression languages within the same model. The compatibility and verification of these languages is outside the scope of this International Standard and becomes the responsibility of the tool vendor.
This requirement is realized in BPMN through various constructs: Data Objects, ItemDefinition, Properties, Data Inputs, Data Outputs, Messages, Input Sets, Output Sets, and Data Associations.
Item-Aware Elements. Several elements in BPMN are subject to store or convey items during process execution. These elements are referenced generally as “item-aware elements.” This is similar to the variable construct common to many languages. As with variables, these elements have an ItemDefinition.
The data structure these elements hold is specified using an associated ItemDefinition. An ItemAwareElement MAY be underspecified, meaning that the structure attribute of its ItemDefinition is optional if the modeler does not wish to define the structure of the associated data.
The elements in the specification defined as item-aware elements are: Data Objects, Data Object References, Data Stores, Properties, DataInputs and DataOutputs.
Properties
Properties, like Data Objects, are item-aware elements. But, unlike Data Objects, they are not visually displayed on a Process diagram. Certain flow elements MAY contain properties, in particular only Processes, Activities, and Events MAY contain Properties.
The Property class is a DataElement element that acts as a container for data associated with flow elements. Property elements MUST be contained within a FlowElement. Property elements are not visually displayed on a Process diagram.
The lifecycle of a Property is tied to the lifecycle of its parent Flow Element. When a Flow Element is instantiated, all Properties contained by it are also instantiated. When a Flow Element instance is disposed, all Property instances contained by it are also disposed. At this point the data within these instances are no longer available.
The accessibility of a Property is driven by its lifecycle. The data within a Property can only be accessed when there is guaranteed to be a live Property instance present. As a result, a Property can only be accessed by its parent Process, Sub-Process, or Flow Element. In case the parent is a Process or Sub-Process, then a property can be accessed by the immediate children (including children elements) of that Process or Sub-Process. For example, consider the following structure: (draw a diagram using the example page 209.)
Data-aware elements
The ErrorEventDefinition, EscalationEventDefinition, and SignalEventDefinition subclasses comprise of attributes to carry data. The data is defined as part of the Events package. The MessageEventDefinition subclass comprises of an attribute that refers to a Message which is defined as part of the Collaboration package.
