• 分析重點:如何增加Event空間與發生頻率的屬性

Introducing

An Event [1] is something that “happens” during the course of a Process. These Events affect the flow of the Process and usually have a cause or an impact. The term “event” is general enough to cover many things in a Process. The start of an Activity, the end of an Activity, the change of state of a document, a Message that arrives, etc., all could be considered Events. However, BPMN has restricted the use of Events to include only those types of Events that will affect the sequence or timing of Activities of a Process.

Events Class Diagram.JPG
Events Class Diagram


The Event element inherits the attributes and model associations of FlowElement (see Table 8.44), but adds no additional attributes or model associations. The details for the types of Events (Start, Intermediate, and End) are defined in “Event Definitions” on page 260.

Basic of Event

Attributes of BPMN 2.0


Extending for IoT

Frequency Attribute


Spatial Attributes



Event Types


Message Event

Messages are triggers, which are generated outside of the Pool they are published in. They typically describe B2B communication between different Processes in different Pools. When Messages need to reach a specific Process instance, correlation is used to identify the particular instance.

Signal Event

Signals are triggers generated in the Pool they are published. They are typically used for broadcast communication within and across Processes, across Pools, and between Process diagrams.

Timer Event & Conditional Event

Timer and Conditional triggers are implicitly thrown. When they are activated they wait for a time based or status based condition respectively to trigger the catch Event.

Error Event & Escalation Event

Error triggers are critical and suspend execution at the location of throwing.

Escalations are non critical and execution continues at the location of throwing.

If no catching Event is found for an error or escalation trigger, this trigger is unresolved. Termination, compensation, and cancellation are directed towards a Process or a specific Activity instance.

Termination Event

Termination indicates that all Activities in the Process or Activity should be immediately ended. This includes all instances of multi-instances. It is ended without compensation or Event handling.

Compensation Event

Compensation of a successfully completed Activity triggers its compensation handler. The compensation handler is either user defined or implicit. The implicit compensation handler of a Sub Process calls all compensation handlers of its enclosed Activities in the reverse order of Sequence Flow dependencies. If compensation is invoked for an Activity that has not yet completed, or has not completed successfully, nothing happens (in particular, no error is raised).

Cancellation Event

Cancellation will terminate all running Activities and compensate all successfully completed Activities in the Sub-Process it is applied to. If the Sub-Process is a Transaction, the Transaction is rolled back.

(Extended) Spatial Event

In IoT scenarios, Location-aware is a fundamental properties. But, in BPMN 2.0, there is no suitable notion to describe this type of event. We create a new Event type with a “pin” mark to represent location-based event. The expression of the location is based on Keyhole Markup Language (KML).

(Extended) Stream Data Event

Stream data event is a special event processing unit that can monitoring the stream data as audio, video …etc. When it detects target, it can generate an event. Due to the processing of stream data is different to traditional data dependency event. We decide to create a new event type with a “wave” mark to represent it.

Data Modeling and Events

Some Events (like the Message, Escalation, Error, Signal, and Multiple Event) have the capability to carry data. Data Association is used to push data from a Catch Event to a data element. For such Events, the following constraints apply:
  • If the Event is associated with multiple EventDefinitions, there MUST be one Data Input (in the case of throw Events) or one Data Output (in the case of catch Events) for each EventDefinition. The order of the EventDefinitions and the order of the Data Inputs/Outputs determine which Data Input/Output corresponds with which EventDefinition.
  • For each EventDefinition and Data Input/Output pair, if the Data Input/Output is present, it MUST have an ItemDefinition equivalent to the one defined by the Message, Escalation, Error, or Signal on the associated EventDefinition. In the case of a throw Event, if the Data Input is not present, the Message, Escalation, Error, or Signal will not be populated with data. In the case of a catch Event, if the Data Output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of the Event and into the Process.

The execution behavior is then as follows:
  • For throw Events: When the Event is activated, the data in the Data Input is assigned automatically to the Message, Escalation, Error, or Signal referenced by the corresponding EventDefinition.
  • For catch Events: When the trigger of the Event occurs (for example, the Message is received), the data is assigned automatically to the Data Output that corresponds to the EventDefinition that described that trigger.



Extending for IoT



Frequency Attribute


  1. B. P. Model, "Notation (BPMN) Version 2.0," OMG Specification, Object Management Group, 2011