Getting started with DT4BP

In DT4BP, the specification of a business process is split into four different views or models. This division is meant to ease the organisation and interpretation of the process definition. These models are the Process Model, the Data Model, the Resource Model and the Dependability Model. While the Process and Resource models are mandatory, the existence of the Data and Dependability models depends on whether data elements are required and whether undesirable events are being handled, respectively. The Process Model describes the control flow of the business process, whereas the Resource Model describes the flow of the actual business entities on which the organisation relies to achieve the enactment of the business process.

In achieving a business process specification using the DT4BP language, the initial model to be provided is the Process Model. The activities involved in the business process and the flow on which these activities should be performed at enactment-time are part of the information to be described within the Process Model.

The notion of participant is used as a means to group the activities tha the participant is responsible. The activities that each participant must perform are either composite or atomic. A composite activity (for the sake of simplicity) can be seen as one that is made up of sub- activities. Conversely, an atomic activity is one that is not composed of sub-activities. The sub-activities that a composite activity refers to, are defined in another business process. In this manner, a composite activity actually refers to a different business process.

The concept of composite activity determines the hierarchical structure of business processes. A business process containing a composite activity is at a higher level than the business process that encloses the sub-activites the composite activity refers to. It is assumed the existence of a business process which is not referred to by any composite activity. This business process is the root of the hierarchical structure. In DT4BP, it is a good modelling practice to restrict the root business process to only one participant (usually the organisational unit in charge of running the business process). This will provide an overall view of the activities that take place within the business process in a condensed view.

Adhering to this good modelling practice, the root Process Model19 that corresponds to the diagnosis business process is shown in Figure 3.1. The activities “registration” (line 12), “exam- ination” (line 17), “makeDocument” (line 18), “consultation” (line 21), and “giveInformation” (line 23) are enclosed within the participant DiagnosisUnit, which is the hospital unit where these activities take place. These activities are executed in sequence (modelled with the control-flow operator ‘;’ ), except examination and makeDocument which are executed in parallel (modelled with the control-flow operator ‘split’ ).

Notice that all these activities are composite activites, which means that (1) business processes named registration, examination, makeDocument, consultation and giveInformation are also part of the overall definition of the diagnosis business process20, and (2) these business processes are located at a lower hierarchical level with respect to the diagnosis business process, which is the root business process.

19

This is a simplified version of the real Process Model. See the Appendix C for the full description of the model.

20

48 3. The DT4BP business process modelling language

1 ; ;∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗

2 ; ; PROCESS MODEL

3 ; ;∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗

4 business process d i a g n o s i s ( out P a t i e n t S h e e t ps ) {

5 6 7 p a r t i c i p a n t D i a g n o s i s U n i t { 8 F i r e A l a r m f a ; 9 10 do{ 11 P e r s o n p r s ;

12 composite r e g i s t r a t i o n [ , p = a l l o c (new P a t i e n t ) ] ( out p r s ) within [ , 1 5 m i n . ] ;

13

14 Temperature t ;

15 B l o o d P r e s s u r e bp ;

16

17 do{ s p l i t composite examination [ p , , ] ( out t , bp )

18 composite makeDocument ( in p r s ; out ps )

19 }within [ , 3 0 min. ] ;

20

21 composite c o n s u l t a t i o n [ p , ] ( in ps , t , bp ; out ps ) within [ 1 5 min. , 1 h s . ] ;

22

23 composite g i v e I n f o r m a t i o n [ p , ] ( in ps ) within [ , 1 5 m i n . ] 24

25 } deviation [ EX Fire | f a = #ON) ]

26 }

27 28 }

Fig. 3.1: Process Model of the Diagnosis Business Process.

Figure 3.2 shows part of the Process Model of the registration business process. This business process involves two different participants: the Secretary and the Patient. The Secretary inter- acts with the Patient by requesting his medical insurance card. This interaction, which defines the collaborative aspect of the business process, is achieved by an exchange of messages between the two participants using the primitives send (lines 8 and 17) and receive (lines 10 and 15). The resources in charge of executing the activities enclosed by the Secretary and Patient partic- ipants within the registration business process are specified at the level of the composite activity that refers to such business process. In this manner, the resource allocation policy for the regis- tration business process is modelled within the diagnosis Process Model, in the resource region (i.e. area determined by the [ ] brackets - line 12). The allocation policy specified for the regis- tration business process defines that the secretary (modelled with the symbol ‘ ’) will be any of those specified within the Resource Model associated to the registration business process (shown in Figure 3.3). Whereas the resource required to play the activities enclosed by the patient participant, is created at enactment-time (i.e. upon the creation of the process instance). A reference for the created resource (here named p) is kept in order to specify that the same re- source must be involved in the subsequent composite activities of the diagnosis business process. The reference p is considered a resource variable and can be used in any subsequent resource region with respect to its definition. Notice that the activities enclosed by the secretary par- ticipant within the registration business process are to be executed at enactment-time by the resource Ann (line 5, in Figure 3.3) as it is the only available resource that matches for that kind of participant.

Both a business process and its composite activities might require some information in order to be able to execute, or they might produce some information as result of their execution. DT4BP adheres to an object-oriented model to allow modellers to represent information in a

3.3. DT4BP: a tutorial introduction 49

1 ; ;∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗

2 ; ; PROCESS MODEL

3 ; ;∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗

4 business process r e g i s t r a t i o n ( out P e r s o n p ){

5 6

7 p a r t i c i p a n t S e c r e t a r y{

8 send reqSSCard to P a t i e n t block ;

9 . . . 10 r e c e i v e reqSSCard ( s s C a r d ) from P a t i e n t ; 11 . . . 12 } 13 14 p a r t i c i p a n t P a t i e n t{ 15 r e c e i v e reqSSCard from S e c r e t a r y ; 16 . . . 17 send reqSSCard ( s s C a r d ) to S e c r e t a r y ; 18 . . . 19 } 20 }

Fig. 3.2: Extract from Process Model of the Registration Business Process.

1 ; ;∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ 2 ; ; RESOURCE MODEL 3 ; ;∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ 4 resources{ 5 S e c r e t a r y = Ann ; 6 P a t i e n t ; 7 }

Fig. 3.3: Resource Model of the Registration Business Process.

business process. An object represents an entity that contains certain information. The kind of information that may be contained by an object is determined by its data type. The data types used to create objects within a business process must be defined in the Data Model associated with the business process. Figure 3.4 shows the Data Model of the diagnosis business process. A data type is defined in the Data Model using the construct type and followed by a name. The name of the data type is its identifier, which must be unique within the same Data Model. A data type can be defined in a structured manner by using other defined data types. This is the case for the Person data type, which relies on the data type Calendar and the pre-defined types21String and Integer (the other pre-defined types are Float and Boolean). Please note that the Integer type represents mathematical natural numbers, whereas Float the mathematical concept of real numbers. The String type represents a sequence of characters22, and the Boolean type the values true and false. A data type’s attribute may have the range of possible values constrained. This is achieved by setting conditions (aka invariants) over each of the attributes to be constrained. Conditions (introduced by the construct where) are first-order logic formulas written using the OCL language [WK03]. The data types Temperature and BloodPressure are examples of data types with invariants. A data type can also be defined as an enumeration of elements23. This is the case of the data type Alarm.

Objects take place within the Process Model, only. The name of the object is its identifier, and

21

Pre-defined data types are referred to as types.

22

Characters of the ISO/IEC 8859-1:1998 [Int98], known as Latin-1.

23

50 3. The DT4BP business process modelling language ; ;∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ; ; DATA MODEL ; ;∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ type P e r s o n{ String name ; String surname ; C a l e n d a r b i r t h d a y ; String a d d r e s s ; String c i t y ; String c o u n t r y ; Integer s s n ; } type C a l e n d a r ;

type Temperature { Integer t where (30 <= t ) and ( t <= 50)} type B l o o d P r e s s u r e { Integer bp where (50 <= bp ) and ( bp <= 250)} type Treatment , M e d i c i n e , D i a g n o s i s , M e d i c a l H i s t o r y ; type P a t i e n t S h e e t{ Integer s s n ; String name ; String surname ; String a d d r e s s ; String c i t y ; String c o u n t r y ; M e d i c a l H i s t o r y mh ; D i a g n o s i s d ; P r e s c r i p t i o n p ; } type P r e s c r i p t i o n{ Treatment t ; M e d i c i n e m; }

type F i r e A l a r m = enum{ON,OFF}

Fig. 3.4: Data Model of the Diagnosis Business Process.

it must be unique within the context of a same business process. The scope of an object is determined by the place where it is defined. A parameter is an object defined in the header24of the business process. The object ps is an example of a parameter object (line 4, in Figure 3.1). For this kind of object, the scope is the entire Process Model. It is worth noting that a parameter can be defined as input or output. Input parameters represent objects that carry information coming from the environment where the business process is enclosed, whereas output parameters are used to pass information to the environment. Notice that an object that wants to be used both to receive and send information from/to the environment must be defined as input and output. An object may also be defined within a participant. In this case case the scope of the object is the participant where it is defined.

An object (whether defined as a parameter or not) is used both to pass information to an activity to allow its execution and to capture the effects of having executed the activity. Objects used to pass information to the activity are known as input arguments. Those used to capture the effects of the activity execution are known as output arguments. Notice that the same object can be used as both input and output argument. In the example, the (parameter) object ps is

24

3.3. DT4BP: a tutorial introduction 51

used as both input and output in the consultation composite activity (line 21, in Figure 3.1). The DT4BP language offers facilities for modelling time constraints over a business process, as well as its constitutive parts (e.g. participants and activities). The time-related requirements concerning the diagnosis business process are modelled using the primitive within. This primitive is aimed at defining the minimum and maximum allowed time an activity may take. The requirement that the registration of a patient should take less than 15 minutes is modelled using this primitive (see line 12, in Figure 3.1). Notice that the symbol ‘ ’ is used to model the fact that there is no boundary regarding the minimim allowed time for the execution of the activity. In the same manner, the same primitive is used to constrain the other composite activities (lines 19, 21 and 23). Notice that for the composite activities examination and makeDocument, which are to be executed in parallel, the time constraint modelled with the primitive within applies to both activities as it is associated with the block (modelled with the construct do) that contains both activities.

Making the diagnosis business process more dependable means dealing with certain undesirable events such that their occurrence during the process enactment either do not result in a failure of the business process (ideal scenario), or the negative effects they produce can be mitigated. When modelling a dependable business process, the first step consists of identifying the unde- sirable events that may take place during the enactment of the business process. For the sake of simplicity, the only undesirable event to be considered here is a fire taking place at the hospital. Once the undesirable events have been identified, the next step consists of modelling how the occurrence of these events are detected. DT4BP provides the notion of deviation to model the detection of an undesirable event. A fire is detected within the diagnosis unit when the fire alarm (modelled with the object fa -line 8, in Figure 3.1) is activated (i.e. the value held by the object fa is equal to #ON ). The fact that the alarm may turn on at any point during the execution of the activities carried out within the diagnosis unit is modelled attaching the deviation to the entire block of activities (lines 10-25).

1 ; ;∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ 2 ; ; DEPENDABILITY MODEL 3 ; ;∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ 4 r e s o l u t i o n{ 5 EX Fire −> Evacuation ; 6 } 7 8 recovery{ 9 E v a c u a t i o n ( ){ 10 p a r t i c i p a n t D i a g n o s i s U n i t{ 11 e v a c u a t e D i a g n o s i s U n i t ( ) ; 12 } 13 } f a i l e d 14 }

Fig. 3.5: Dependability Model of the Diagnosis Business Process.

The concept of deviation is used to model not only how the undesirable event is detected, but also how its occurrence is noted within the business process where it takes place. The occurrence of an undesirable event is noted by means of signals or exceptions. Thus, EX Fire models the exception that will mark (at enactment-time) that a fire is taking place within the diagnosis unit. It is worth noting that the raising of an exception at enactment-time changes the execution flow of the business process to the handler meant for dealing with the exception. The binding between the exception used to note the occurrence of an undesirable event and the handler in charge of its handling, as well as the proper definition of the handler, is modelled within the

52 3. The DT4BP business process modelling language

Dependability Model. Figure 3.5 shows the Dependability Model associated to the diagnosis business process. The model is composed of two parts: the first part, named resolution modelles the binding exception-handler (line 5), whereas the second part, named recovery, provides the definition of the handler (lines 9-13), which consists of the evacuateDiagnosisUnit activity. This activity is executed once the control flow of the business process is transferred to the activity due to the exception. It must be noted that this handler does not help to reach the process’ goal (i.e. patients are not supposed to be diagnosed nor receive any treatment in the case of a fire), but it does help to mitigate the effects of the fire (patients are evacuated so that they are not injured because of the fire). The keyword failed (line 12) is used to model the fact that the business process fails despite performing activities by the handler.

This section provides an overall view of the different models to be considered when composing a business process in DT4BP. In the following discussion, a more detailed description of the language will be given.