Considering both the requirements and the global time model defined in Section 3.1.3, it is necessary to determine all possible time constraints that should be specified when modelling a business process. The strategy for determining these time constraints consists of considering every concept introduced thus far and deciding the kind of time-related information that can be associated with it. Identifying the possible time constraints allows for establishing which modelling concepts are required to capture this information. In addition, this process highlights which concrete modelling elements should be provided to the language’s user such that they may describe time constraints in an easy and direct manner.
3.4.3.1 Timing constraints over a business process
As explained in Section 3.4.1.5, a business process is initiated by a request. The request is either an external event coming from the environment where it operates41or a simple call (like the one made by composite or nested activities).
The point in time when the request to a business process is performed (tr in Figure 3.29) can be
used as the temporal frame of reference when setting time constraints over the business process. Another point in time that can be used as a frame of reference is the actual time at which the business process begins its execution (ts in Figure 3.29). Both frames of references then are used
to analyse the time constraints that may be set over a business process.
• Starting: taking tr as the frame of reference, the actual initiation of a business process
could be constrained in the following way:
– the process starts ts time units after tr (ts is the delay),
– the process starts at least tsmin time units after tr (tsmin is the minimum delay),
– the process starts no later than tsmax time units after tr (tsmax is the maximum delay),
The concept start then is used to capture such potential time constraints. The keyword
start is proposed as the primitive to concretely specify constraints related to the start of
the business process. This primitive may be followed by either a single time value ts or
a pair of time values [tsmin, tsmax]. Start followed by a single time value (i.e. start ts) is
used to specify the exact delay in starting the business process. Whereas if it is followed by a pair of constraints (i.e. start [tsmin, tsmax]), it is used to specify the minimum delay
([tsmin, ]), the maximum delay ([ , tsmax]), or both ([tsmin, tsmax]).
• Periodicity: in general, there is no information about how often the requests that initiate a business process arrive (i.e. request patterns are not known in advance). An exception to this rule is the periodic business processes. A periodic business process is performed
41
Time-related events are included in this consideration. These events are launched automatically by the built-in clock that measures the passage of the time as observed in the physical world.
3.4. DT4BP: a detailed explanation 73 s t a r t BP Business Process (start t i m e ) (request t i m e ) tr ts m a x ts m i n ts t i m e last BP (last t i m e ) tl m i n tl m a x tl period period Business Process m a x ts m i n ts (last t i m e ) m i n tl m a x tl (start t i m e ) ts tP tP tl
duration of the periodic execution of the business process tpu n t i l
Fig. 3.29: Timing constraints over a business process.
according to a recurring pattern, which specifies how often the business process is requested and for how long the recurring patterns has to be applied (if any). However, it must be noted that a periodic business process must be initially requested by a certain (either internal or external) event. The point in time when the initial request takes place (i.e. tr)
is the frame of reference both for the periodicity (i.e. tP in Figure 3.29) and marks when
subsequent requests are made (i.e. tPuntil in Figure 3.29).
The primitives every and until are used to specify information related the period of the process and the end of the periodic sequence, respectively. Thus, while every tP is used to
specify how often the business process is requested, until tPuntil specifies the termination
of the requests.
It is worth noting that (1) the timing constraints relative to the start of the business process are considered in the first and every subsequent periodic request of the business process; (2) periodic business process might last longer than the value specified using the
until primitive as it constrains the duration the periodic business process is requested,
and not its duration; and (3) the period of a business process (i.e. tP) defines not only
the point in time at which the next business process is going to be requested, but also the maximum elapsed time for the current business process under execution as a periodic business process must complete its execution within the period.
• Duration: taking as the frame of reference the actual point in time at which the business process starts its execution (i.e. ts in Figure 3.29), then the duration of the business
process can be constrained in the following way:
– the process lasts exactly tl time units (tl is the elapse time)
– the process lasts at least tlmin time units (tlmin is the minimum elapse time)
– the process lasts no more than tlmax time units (tlmax is the maximum elapse time)
In this case, the concept last is used to capture the constraints related to the duration of the business process. The modeller has to use the primitive last to specify this information.
74 3. The DT4BP business process modelling language
In the same way as was done previously, this primitive followed by a single time value (tl)
specifies the exact duration of the process, whereas if it is followed by a pair ([tlmin, tlmax])
it specifies the minimum and maximum elapse times for such process.
1 business process d i a g n o s i s ( out P a t i e n t S h e e t p s )
2 when( p a t i e n t A r r i v e s ) l a s t [ , 2 h s . ] { . . . }
Fig. 3.30: Constraining the duration of the Diagnosis process.
In the running example, the duration of the “diagnosis” process has to be constrained, as it is required that “the patient should get its diagnostic in less than two hours”. Figure 3.30 shows how this requirement is modelled using the concept last.
name : String BusinessProcess max : TimeExp min : TimeExp TimeRange until : TimeExp Period value : Integer Every Wednesday Start Last Thursday Tuesday Monday Second Month Friday Week
Hour Day Year
period 0..1 last 0..1 start 0..1 every 1 1
Fig. 3.31: Time concepts related to a business process.
Figure 3.31 shows the formalisation of these time-related concepts according to the metamod- elling principle. This formalisation, thus, specifies that a business process (of type BusinessPro- cess) may or may not have its starting time constrained. When this constraint exists, it is held by the composite relationship start. Notice that only one start constraint may be associated with a business process. In addition, the constraint (since Start extends from the abstract class TimeRange) and may restrict the minimum delay (specified with themin attribute), the maximum delay (specified with themax attribute), or both. The particular case in which the attributes min and max have the same time values represents the modelling of an exact delay.
3.4. DT4BP: a detailed explanation 75
It is worth noting that the time values these attributes may have are of type TimeExp. This datatype defines a time value as a positive integer.
Regarding the duration of the business process, it is specified by means of the class Last, which also extends from the TimeRange and the composite relationship last. When a business process has its duration constrained, then the composite relationship must contain one (and only one) instance of the class Last that has, at least one of the attributes min and max different from zero. The min attribute contains the time expression that determines the minimum allowed duration of the business process, whereas max represents the maximum allowed duration. The remaining part of the meta-model is concerned with the formalisation of the business process periodicity (if any). In case a business process is periodic, then it must have a period, which is modelled by the composite relationship period. A period (of type Period ) has two time values. One time value, modelled by the composite relationship every, describes how often the business process has to be requested (once it is started). The other time value, modelled by the attribute until, describes the time up to which these requests have to be performed. Notice that the instance held by the composite relationship every is an instance of one the classes that extends from the abstract class Every.
context TimeRange inv C o n s i s t e n t R a n g e :
( s e l f . min > 0 or s e l f . max > 0 )
and
( i f ( s e l f . min > 0 and s e l f . max > 0 )
then s e l f . min <= s e l f . max e l s e t r u e e n d i f )
context B u s i n e s s P r o c e s s inv C o n s i s t e n t P e r i o d : i f ( s e l f . p e r i o d . e v e r y . v a l u e > 0 ) then i f ( s e l f . s t a r t . min > 0 ) then i f ( s e l f . l a s t . min > 0 ) then s e l f . s t a r t . min + s e l f . l a s t . min <= s e l f . p e r i o d . e v e r y . v a l u e e l s e s e l f . s t a r t . min <= s e l f . p e r i o d . e v e r y . v a l u e e n d i f e l s e i f ( s e l f . l a s t . min > 0 ) then s e l f . l a s t . min <= s e l f . p e r i o d . e v e r y . v a l u e e l s e t r u e e n d i f e n d i f e l s e t r u e e n d i f
Fig. 3.32: Consistency between time-related values at the level of the business process.
Figure 3.32 shows the OCL conditions that ensure the values held by the previously mentioned time-related concepts are such that there exist at least one process instance that meets these conditions. Such OCL conditions are specified over the assumption that all time-related values are in the same time unit. This assumption can be achieved by performing a normalisation of the time-related information, that takes place during the parsing of the model.
The invariant ConsistentRange then not only ensures that every instance of the sub-type TimeRange has at least one of its attributes with a value greater than zero (otherwise it does not make sense to create an instance), but also that when both attributes are different from zero that max is greater or equal to min (the case max=min represents an exact delay or duration of the business process).
76 3. The DT4BP business process modelling language
On the other hand, the invariant ConsistentPeriod checks that period is greater than or equal to the minimum delay (if any), the minimum elapse time (if any), and the sum of both in the case that both minimums are greater than zero. Notice that this invariant will not hold in the case that the business process has to (1) wait for a time that goes beyond the period, (2) last longer than the period, or (3) wait and last for a time that exceeds the period. Since such cases only describe invalid process instances they should not be model.
3.4.3.2 Timing constraints over a participant
The time a participant takes for completing its enclosed activities (including waiting times between activities) may also be constrained42 . The frame of reference for this time constraint is determined by the point in time at which the business process starts its execution, ts in Figure
3.33. Notice that a business process starts executing only once all its required resources have been allocated. It is assumed that the time taken to allocate the resources is negligible.
t i m e s t a r t BP last BP Business Process (start t i m e ) (last t i m e ) Participant i tl (request t i m e ) tr ts m i n tl m a x tl m a x ts m i n ts period t P Participant 1 Participant 2 Participant 3 work for Participant i (work for t i m e ) m i n t w f t w f m a x t w f
Fig. 3.33: Timing constraints over a participant.
The notion of workFor is used to capture the minimum time (i.e. twfmin in Figure 3.33) and
maximum time (i.e. twfmax in Figure 3.33) a participant may be engaged in executing its en-
closed activities. The primitive that allows its modelling carries the same name. This primitive followed by a pair of values [twfmin, twfmax] specifies the minimum and maximum working times
the participant has to execute its enclosed activities. As usual, the symbol ‘ ’ is used to leave without specifying one of the values.
Figure 3.34 shows how this primitive is used to specify the requirement that a doctor should work in the examination of the patient for at least 15 minutes in order to ensure a certain level of quality in the examination. Notice that the time information held by the workFor primitive is concerned with the time the resource will be engaged for completing the activities enclosed
42
3.4. DT4BP: a detailed explanation 77
by the participant, whereas the primitive last is with the duration of “consultation” business process. 1 business process c o n s u l t a t i o n ( 2 in P a t i e n t S h e e t ps , Temperature t , B l o o d P r e a s u r e bp ; 3 out P a t i e n t S h e e t ps ) l a s t [ 1 5 min. , 1 h s . ]{ 4 5 p a r t i c i p a n t P a t i e n t{ 6 . . . 7 } 8 p a r t i c i p a n t D o c t o r { 9 . . . 10 }workFor[ 1 5 min. , ] 11 }
Fig. 3.34: Constraining the working time of Doctor participant.
Figure 3.35 shows the part of the meta-model that formalises the time-related concept workFor. This formalisation indicates that a participant may or may not have its working time constrained. This is modelled by the composite relationship workFor, which allows a particular participant (of type Participant ) to be bound with an instance of class WorkFor. Every instance of class WorkFor has attributes min and max. These attributes own the time-related values that specify the minimum and maximum times the participant is allowed to work, respectively.
max : TimeExp min : TimeExp TimeRange name : String Participant WorkFor workFor 0..1 1
Fig. 3.35: Time concepts related to a participant.
Notice that the minimum time duration that participants may work should not exceed the maximum elapse time of the business process where they are embedded, otherwise it is impossible to create any valid process instance that meets both time constraints. In the case that the participants are part of a periodic business process, their minimum workFor time should not exceed the period of the business process (i.e. tP in Figure 3.33). The OCL invariants that
ensure the consistency between these time-related values are shown in Figure 3.36. The invariant PartWorkForMinElapseMax checks the minimum workFor time is always lower than or equal to the maximum elapsed time. Whereas PartWorkForMinPeriod does the same but for the period.
3.4.3.3 Timing constraints over an activity
Taking as the frame of reference the point in time at which an (whether composite, nested or Atomic) activity ends (finish of act1 in Figure 3.37) or, by default, the initiation of its enclosing
78 3. The DT4BP business process modelling language
context P a r t i c i p a n t inv PartWorkForMinElapseMax :
i f ( s e l f . workFor . min > 0 and s e l f . bp . l a s t . max > 0 ) then
s e l f . workFor . min < s e l f . bp . l a s t . max
e l s e t r u e e n d i f
context P a r t i c i p a n t inv PartWorkForMinPeriod :
i f ( s e l f . workFor . min > 0 and s e l f . bp . p e r i o d . e v e r y . v a l u e > 0 ) then
s e l f . workFor . min < s e l f . bp . p e r i o d . e v e r y . v a l u e
e l s e t r u e e n d i f
Fig. 3.36: Consistency between Participant and Business Process time-related values.
business process, an activity may be constrained such that it has to wait for at least tactdelay time
units (aka delay) before starting its execution. It is worth explaining that both composite and nested activities are considered as starting immediately in spite of the business processes these kinds of activities refer to may not start their execution immediately (e.g. the business process holds a delay). t i m e s t a r t BP last BP Business Process (start t i m e ) (last t i m e ) Participant i (request t i m e ) tr ts m i n tl m a x tl m a x t s m i n ts period tP Participant 1 Participant 2 Participant 3 work for Participant i (work for t i m e ) m i n t w f t w f m a x t w f
act 1 act 2 act n
s t a r t a c t i v i t y 2 tl finish a c t i v i t y 2 m i n t a c t l m a x t a c t l t a c t delay
Fig. 3.37: Timing constraints over an activity.
As it is assumed that the execution of certain activity takes time, the actual time it takes to execute is called the activity duration. This duration can be explicitly constrained by specifying the minimum amount of time (i.e. tactlmin in Figure 3.37) the activity must be under execution
(aka earliest deadline) and/or the maximum allowed time (i.e. tactlmax in Figure 3.37) to be
spent performing this activity (aka latest deadline).
According to the previous analysis, it may be required to specify (1) in which point in time the activity has to start and (2) the point in time within which the activity should finish. While the former is used to capture the information related to the delay in requesting the activity, the
3.4. DT4BP: a detailed explanation 79
latter captures the activity’s deadlines.
The formalisation in terms of the metamodelling of the in and within concepts is shown in Figure 3.38. The composite relationships in and within owned by the class Activity (by inheriting from class Execution) allow an activity to capture the information regarded as its delay and duration, respectively. Notice that the duration of an activity is defined by a range of time values, whereas the delay is defined by only one. Hence, the duration of an activity (modelled as an instance of class Within) has two time values (i.e. attributes min and max ), whereas the delay (modelled as an instance of class In) has only one time value (i.e. attribute delay).
Activity max : TimeExp min : TimeExp TimeRange delay : TimeEx In Execution Within within 0..1 1 in 0..1 1
Fig. 3.38: Time concepts related with the notion of Activity.
Primitives with the same name are provided to allow the language’s user to describe such information. In this manner, in allows the modeller to describe information related to the start of an activity. This primitive must be followed by a single time value tactDelay which specifies
the delay in starting the activity. On the other hand, the primitive within is used to allow the modeller to specify the time information that constrains the duration of the activity: i.e. its earliest and latest deadlines. Following the same strategy when minimums and maximums need to be specified, a pair of time values following the primitive within is used to constrain the duration of the activity. Thus, the pair [tactlmin, tactlmax] indicates that the activity executes
for at least tactlmin time units and it does not take more than tactlmax time units. As used so far,
the ‘ ’ symbol means that no constraint is set over the time value where this symbol is used. Figure 3.39 shows how this primitive is used to model the duration of the activity “consultation” according to the given requirement: “consultation’ has to take less than 1 hour, but more than 15 minutes.
It is worth noting that time constraints set over composite or nested activities, i.e. values specified with within, must be consistent with those time constraints that might have been set in the definition of the business processes they refer to, e.g. last values. Thus, in the case that a composite or nested activity has its maximum allowed duration constrained (i.e.
within[ , tactlmax] ) and the business process being referred to is either (1) periodic (i.e. business
process bp every tP until) tPuntil or (2) its minimum elapse time is constrained (i.e. business process bp last [ , tlmax]), then:
80 3. The DT4BP business process modelling language
1 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 ) when( p a t i e n t A r r i v e s ) l a s t [ , 2 h s . ] {
2
3 p a r t i c i p a n t D i a g n o s i s U n i t {
4 . . .
5 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 . ] ;
6 . . .
7 }
8 }
Fig. 3.39: Constraining the duration of the activity consultation.
• for case (1): the maximum allowed duration of the composite or nested activity has to be greater than or equal to the sum of the duration of the periodic execution of the business process and its period (i.e.tP+ tPuntil ≤ tactlmax)
• for case (2): the maximum allowed duration of the composite or nested activity has to be greater than or equal to the sum of minimum delay (i.e. start[tsmin, ]) set at the start
of the referred business process (if any) and its minimum elapse time (i.e. tsmin + tlmax ≤ tactlmax)
The OCL invariants that ensure these conditions are shown in Figure 3.40. The reader should notice that no consistency is required between the time constraints defined by the concepts in (at the level of composite or nested activities) and start (at the level of the referred business process). The concept in is used to constrain the request to start executing the activity, whereas start is used to constrain the actual starting of the business process.
context Composite inv C o n s i s t e n c y W i t h i n L a s t P e r i o d :
i f ( s e l f . w i t h i n . max > 0 and s e l f . c a l l . p e r i o d . e v e r y . v a l u e > 0 ) then i f ( s e l f . c a l l . p e r i o d . u n t i l > 0 ) then s e l f . c a l l . p e r i o d . u n t i l + s e l f . c a l l . p e r i o d . e v e r y . v a l u e <= s e l f . w i t h i n . max e l s e s e l f . c a l l . p e r i o d . e v e r y . v a l u e <= s e l f . w i t h i n . max e n d i f e l s e t r u e e n d i f and
i f ( s e l f . w i t h i n . max > 0 and s e l f . c a l l . l a s t . min > 0 ) then i f ( s e l f . c a l l . s t a r t . min > 0 ) then
s e l f . c a l l . s t a r t . min + s e l f . c a l l . l a s t . min <= s e l f . w i t h i n . max
e l s e
s e l f . c a l l . l a s t . min <= s e l f . w i t h i n . max
e n d i f e l s e t r u e e n d i f
Fig. 3.40: Consistency between within, last and period time-related values for a composite
activity.
Another condition that may be checked at modelling time is that the sum of the activities’ minimum delays and/or durations (if any have been specified) has to be lower than or equal to (1) the maximum allowed working time of the participant that encloses the activities (if any), (2) the maximum allowed elapse time of the business process (if any), and (3) the period of the business process (if any). Figure 3.41 shows the OCL conditions that perform these checks.
3.4. DT4BP: a detailed explanation 81
context P a r t i c i p a n t inv MinGuaranteedET :
l e t
e x e c s : Sequence ( E x e c u t i o n ) = s e l f . s t m t s−>c o l l e c t ( s | s . oclIsKindOf ( Execution ) ) , minWithinET : Integer= e x e c s−>c o l l e c t ( e | e . within . min > 0)−> sum ( ) ,
minInET : Integer= e x e c s−>c o l l e c t ( e | e . max . min > 0)−>sum ( ) i n
i f ( s e l f . workFor . max > 0 ) then
minWithinET + minInET <= s e l f . workFor . max
e l s e t r u e e n d i f
and
i f ( s e l f . bp . l a s t . max > 0 ) then
minwithinET + minInGET <= s e l f . bp . l a s t . max
e l s e t r u e e n d i f
and
i f ( s e l f . bp . p e r i o d . e v e r y . v a l u e > 0 ) then
minwithinET + minInGET <= s e l f . bp . p e r i o d . e v e r y . v a l u e
e l s e t r u e e n d i f
Fig. 3.41: Consistency of the sum of activities’ max/min delays with respect to their enclosing
context.
3.4.3.4 Timing constraints when exchanging messages
The exchange of messages between participants is captured by the send and receive concepts (see Section 3.4.2 for details about these concepts). Time constraints over these concepts may be set to specify:
1. how long a (blocking) sending participant is willing to wait for the recipient to get the message,
2. how long the recipient is willing to wait for a message to arrive,
3. how long the recipient executes their activities to produce a reply after a message has been received, and
4. how soon a reply should arrive to a sending participant after a message has been sent.
The timing constraints (1) and (2) can be modelled using the concept within introduced in the previous section. More precisely, a participant psender holding the statement send msg to