Controles

As claimed in Chapter 1, the main objective of this thesis is to define a modelling language for describing Dependable Collaborative Time-constrained (DCTC) business processes. The objective is to make this language comprehensible, suitable and expressive enough such that the modelling of this kind of business process becomes “easier”. In the end, what is required then, is to define a language for a very specific domain. These kinds of languages are known as Domain- Specific Languages (DSL) [KT08]. The first rule when defining a DSL is to understand the domain of interest. Doing this allows for the identification of the core concepts and components the modelling language should cover. Once the modelling concepts are identified, they are formalised by creating a metamodel, because the metamodelling approach has been chosen to

32 3. The DT4BP business process modelling language

describe the language. In this case, the domain of interest is determined by the intersection of four concepts: business process, collaboration, time and dependability. Thus, identifying the concepts that play a central role in the domain of interest is a necessary condition to engineer a comprehensible, suitable and expressive modelling language.

3.1.1 Business Process

Some of the factors that should be considered when modelling “what a particular business process is intended to do”1 can be deduced from its definition2. An activity represents a piece of work performed within the business process. An activity might require some data in order to perform. It might also produce certain data as result of its execution. It is usually the case that more than one activity is required to reach the goal. In that case, activities have to be ordered, using certain control-flow operators, to create the different paths the business process can go through during its enactment3. In any case, these paths should lead to achieving the business process’ goal. The goal, represents the expected result obtained once the business process was enacted.

A business process is enacted within the context of an enterprise. The activities enclosed in the business process are performed by resources that belong (whether directly or indirectly) to the enterprise. Since a resource is defined as an entity with the capabilities to perform a business process’ activity, it can be either a machine or a human being. A machine is able to perform only activities that are fully automatic, whereas a human being is required to perform activities that are manual or semi-manual.

Resources are involved during the enactment of the business process. But, they also are part of the process definition. Both the available resources that may be assigned to a particular activity, as well as the policy that determines which one will be selected at enactment-time4 to perform the activity are part of the information that must be explicitly contained in the process definition.

It is usually the case that enterprises group their human resources according to a certain organ- isational structure. This organisational structure is generally defines a hierarchical relationship between the enterprise’s staff members. However, an organisational structure can also be used to capture details about the human resources that are relevant to drive the business processes run by the enterprise. In this perspective, it is assumed that each business process has an associated resource model that describes the resources that are available to enact the business process. The notion of participant is used as a grouping mechanism to join (either human or non-human) resources with similar profiles and/or duties (e.g. doctors, nurses, secretaries, etc.).

The notion of participant is also used as grouping mechanism to join the activities that are required to be performed by a same participant within a same business process. Thus, the notion of participant is used as a binding mechanism between the business process definition and the resource model to select (according to certain policy) the resources that will perform the participant’s activities during the enactment of the business process.

1

The outcome of this activity is known as process definition.

2_{Business process: a set of one or more linked procedures or activities, which collectively realise a business}

objective or policy goal, normally within the context of an organisational structure defining functional roles and relationships [Wor99].

3

Enactment: the actual execution of the business process.

4

3.1. Dimensions of interest 33

3.1.2 Collaboration

By definition, a business process takes place within the context of an organisational structure. It is such a structure that determines how the work carried out by the an organisation is divided amongst its staff. In today’s world, companies require several people with different skills to succeed in providing their company’s services. This requirement leads to business processes involving multiple resources that collaborate along the process to succeed in providing the offered service or product (i.e. the process’ goal).

Each resource is assumed to have its own processing capacity for performing activities (one after the other). Thus, while a resource denotes a human or non-human entity capable of executing its activities in parallel with some other part, a collaborative business process denotes a set of resources that interact among them. Two resources interact if they communicate by exchanging messages. Thus, a resource should be able to send and/or receive a message from another peer resource (i.e. a resource that is involved within the same business process). The fact that they interact is what defines them to be collaborative with respect to reaching of the process’s goal. The collaboration between resources, thus, is expected to be captured in the business process definition as it is a major concern in the kind of business process being targeted.

Collaboration is defined as the exchange of messages between the different resources required to perform the business process activities. However, since this information must be captured in the business process definition, the notion of participant must be used instead of the notion of resource. As explained in the previous section, the notion of participant is used within a process definition to group the activities that are required to be performed (at enactment-time) by the same resource (selected according to certain specified policy). Therefore, in the business process description, messages are exchanged between participants that are enclosed within the same business processes. A particular participant then may send a message to one or more participants, and receive messages (one at a time) sent by other peer participants. Notice that a message may convey certain information, so that messages can not only be used as a synchronisation means among participants, but also as a medium to share information among them. It is worth emphasising that a business process is considered collaborative if and only if two or more participants enclosed within the same business process exchange messages, in spite of the existence of other means to exchange information by and among the participants (e.g. data sharing).

In other words, the concept of collaboration in the context of this thesis is semantically equivalent to the one assumed in the business process modelling language BPMN: a collaboration simply describes the participants and their interactions, where the interaction represents the exchanged messages among the participants [WM08].

3.1.3 Time

During the modelling of a particular business process, the modeller (i.e. the business analysts or the software engineer) requires means to describe the time constraints that form part of the business process being modelled. In this thesis, a time constraint is seen as information given in the form of upper and/or lower time bounds associated with a business process or any of its constitutive parts (e.g. participant, activity). Examples of business process time-constraints are: minimum delay (i.e. the minimum amount of time that must elapse before the start of the business process), maximum delay (i.e. the maximum amount of time that can elapse before the start of the business process), and maximum elapse time (i.e. the maximum allowed time

34 3. The DT4BP business process modelling language

for completing the execution of the business process). These time constraints are derived from the business goal, organisational rules, laws, commitment, and so on [EPR99].

The information held by a time constraint can be relative or absolute. Absolute time refers to time as seen in the physical world, whereas relative time refers to the passage of time with respect to certain event5. Within the context of this thesis time constraints set during the modelling phase are assumed to hold relative information, only. Events that can be used as a frame of reference for relative time constraints are: (1) the point in time in which the business process is requested, (2) the point in time in which the business process starts its execution, (3) the point in time at which a business process activity starts being executed, and (4) the point in time at which a business process activity is completed6.

Nevertheless, it is assumed that during the enactment of the business process, absolute deadlines are computed for any relative time constraint. This indicates that the frame of reference used during the execution of a business process is the one determined by absolute time. Therefore, at enactment-time, it is assumed that there exists a device capable of measuring the passage of the physical time such that the time constraints can be monitored to determine whether they are met or not. Such s device is called s clock.

Every participant involved in a collaborative business process needs to have the same point of view regarding the passage of the time. The global time based on physical time is assumed as the time model when modelling the targeted business processes. This time model assumes that there exists a unique clock that accurately measures the passage of physical time7, which is accessible to all participants involved in the business process. Since all participants access the same clock, all of them have the same perspective regarding the passage of the time.

It is worth observing that the global time based on physical time model can be achieved us- ing a clock coordination algorithm [GZ89, CF94, Net09] 8_{. This gives evidence that the time}

model considered during the modelling phase is not an oversimplification of the real time model considered during the business process enactment.

3.1.4 Dependability

A business process definition is expected to capture all the possible paths that can be used to achieve its goal. A process instance that follows one of these paths is termed well-behaved or normal. It might be the case that a particular process instance follows a path which has not been considered in the definition. Because it is assumed that all possible paths that can be used to achieve the business process goal are specified in the process definition, instances following a non-specified path fail in reaching the business process’ goal. It is assumed that once the instance has deviated from the process definition it will eventually fail, if no corrective activities are performed. A process instance missing its goal is termed a business process failure A dependable business process is one whose failures (i.e. process instances missing the goal) are not unacceptably frequent or severe (from some given viewpoint). Therefore, a business process increases its dependability when for those events that cause it to fail more often than expected, corrective activities are explicitly included in its definition such that instances do not miss the

5

In theory, absolute time is also relative, since it counts from a particular event. (e.g. the Christ’s birth is the event on which the Gregorian calendar -unofficial global standard- relies on for numbering the years)

6

The reader is referred to Section 3.4.3 for the full list of events that can be used as frame of reference for defining relative time constraints over a business process and its constitutive parts.

7

Atomic clocks are examples of these kinds of clock.

8