Permitir sufragar a personas sin credencial para votar o cuyo nombre no aparezca en la lista nominal de

BPMN relies on Business Process Diagram (BPD) to allow business processes to be graphically modelled. A BPD then is meant to contain one or more business processes, which are all described using a graphical notation. This graphical notation is a flowchart-like notation that has its elements divided in four categories:

1. Flow Objects: elements used to defined the behaviour of a business process. There are three Flow Objects: Events, Activities and Gateways. Events are used to model the “happening” of something during the course of a business process. Depending on when such events occur, they are categorised as start, intermediate or end events. An Activity is used to described a piece of work. When an activity is not divided into sub-activities it is considered as atomic, otherwise it is non-atomic. Gateways are used to control the flow of the business process by means of decision points, forking points, and merging points. 2. Connecting Objects: elements used to connect Flow Objects. There are three kinds of

Connecting Objects including: Sequence Flow, Message Flow and Association. A Sequence Flow is used to show the dependency order between Flow Objects. A Message Flow is used to show the flow of messages between two different participants. A participant represents a business entity or role that is modelled as a Pool in a BPD (see below).

3. Swimlanes: elements used to group Activities. There are two grouping elements: Pools and Lanes. A Pool is used to group those activities that the same participant has to perform in a business process. A Lane is a sub-partition within a Pool, used to organise and categorise the activities the same participant performs. A Pool allows a business process to be partitioned in such a way that activities are grouped according to the participant in charge of their execution. However, explicit information about the actual resources that takeover the activities enclosed by a participant is not given as the language does not provide a means to specify this information (i.e. organisation structure, resources and policies of allocation).

4. Artifacts: elements used to provide additional information about the business process being modelled, without affecting the Sequence Flow or Message Flow of such process. The artifacts provided by the notation are: Data Object, Group and Annotation. A Data Object is used to model the information an activity requires to be performed and/or what information is produced once such activity has executed. Both Group and Annotation are artifacts meant to ease the documentation of the business process. While the Group is used to define categories of activities, Annotation allows the business analyst to provide additional information for the reader of the BPD.

These notation elements provide the support required to model concepts that are applicable to the business process, only. This means that other kind of modelling done by organisations like business rules, data models and organisational structures and resources are out of the scope of BPMN.

3.2. Existing business process modelling languages 39

3.2.2.1 Collaboration

BPMN defines a collaboration as any BPD that contains two or more participants which interact with each other. These interactions are defined as communication, in the form of message exchange (shown as Message Flows) between two participants. Therefore, the Pool and Message Flow elements provided by the language are the necessary means to model the collaborative aspects of a particular business process.

It should not be surprising that BPMN considers collaboration as a first-class concern, since support for it was sought since its inception. [WM08].

3.2.2.2 Time

Time is supported in BPMN by the notion of Timer Start Event and Timer Intermediate Event. A Timer Start Event is used to start a business process, whereas a Timer Intermediate Event is used to delay the start of a particular Activity or to interrupt its execution. Both kind of timers posess a time condition that specifies when the event occurs, i.e. is triggered. When a timer is used to start a process (i.e. it is a Timer Start Event), its time condition may be a specific date and time (e.g. Dec 31, 2009 at 8 AM) or a recurring time (e.g. every Monday at 8am). In any case, the condition is compared with a clock12 that measures the passage of physical time. As stated earlier, a Timer Intermediate Event is used either to delay the execution of an Activity or to interrupt its execution. A delay is modelled by inserting a Timer Intermeditate Event between Activities in a process. The Flow Objects that can precede a Timer Intermediate Event are Activities, Gateways, or Intermediate Events.

The time condition held by a Timer Intermediate Event describes the delay in starting the next Activity of the process. This time condition specifies an absolute time (e.g. wait until Dec 31, 2009 at 8 AM) or a relative time (e.g. wait 2 weeks) that might be repetitive (e.g. wait until next Monday at 8am). However, Time conditions written using absolute time inhibit the re-usability of the process as the absolute time condition will be valid only once. It is good practice then to rewrite absolute time conditions as relative conditions, if possible.

A Timer Intermediate Event attached to the boundary of an Activity represents a deadline for the execution of the Activity. This means that the Activity has the time condition described by the Timer as the maximum allowed time for completing its execution. If the time condition becomes true before the Activity is completed, then the Activity is immediately interrupted. The time condition that a Timer Intermediate Events used as a time-out holds is always relative to the start of the Activity to which the Timer is attached.

3.2.2.3 Dependability

BPMN provides elements to support exception handling. An Intermediate Event attached to the boundary of an Activity is used to model an exception that may occur during the execution of the Activity. In the case that an exception is raised (i.e. the trigger the Intermediate Event holds is fired), the Activity is interrupted. As normal flow is the flow followed by the process when the Activity terminates its execution normally, exception flow is that to be followed when an Intermediate Event occurs. Intermediate Events attached to an Activity are used to denote

12

This clock should be seen as a calendar that also provides information about the current physical time: i.e. YYYY-MM-DD:HH.MM.SS

40 3. The DT4BP business process modelling language

the different exceptional flows the Activity can follow. Flow from the Intermediate Events (i.e. exceptional flows) can go anywhere. The execution can follow a completely new path to perform some handling activities for the exception, or it can join the normal path as if the exception would have not occurred. Alternatively it can go go back to attempt a new execution of the activity.

BPMN also provides support for the notion of transaction. In BPMN, a transaction is defined as a formal business relationship and agreement between two or more participants [WM08]. A transaction is considered as successfully executed when all the participants taking part have reached a common agreement point.

Since a transaction involves multiple participants, its definition is spread over the pools that describe each participant. Each participant (i.e. Pool) includes a transactional sub-process defining those activities that form part of the transaction. A double-lined boundary indicates that a sub-process is a transaction.

In the case that any of the participants taking part in the transaction faces with a processing or technical error, then the transaction is interrupted. There are two possibilities for interrupting a transaction. It can be terminated immediately or some compensation can be performed before terminating such that the transaction is considered cancelled. Intermediate Events attached to the transactional sub-process boundary are used to represent each kind of interruption. An Error Intermediate Event is used to model the sudden interruption of the transaction, whereas a Cancel Intermediate represents the cancellation of the transaction.

As just mentioned, cancelling a transaction may require that some compensation be performed. Compensation is the undoing of the work a particular Activity has completed. Since compensa- tion does not happen automatically, another Activity is required to undo the work of the original Activity. BPMN supports compensation by means of Compensation Activity, Compensation In- termediate Event and Compensation Association. Every activity that requires compensation must have a Compensation Intermediate Event attached to its boundary. A Compensation As- sociation is used to bind the original Activity with the one that compensates its effects. The Compensation Association must start at the Compensation Intermediate Event attached to the original Activity and end in the Compensation Activity. A Compensation Activity must not have any incoming or outgoing Sequence Flow. In addition, its use is not limited to activities enclosed within a transactional sub-process (i.e. every Activity can have an associated Compen- sation Activity).