DPIL Language

The Declarative Process Intermediate Language

The Declarative Process Intermediate Language (DPIL)

The textual Declarative Process Intermediate Language (DPIL) is a multi-perspective rule-based modeling language. It allows representing several business process perspectives, namely, control ow, data and resources. The expressiveness of DPIL and its suitability for business process modelling have been evaluated with respect to the Workflow Resource Patterns.

Fundamentals of DPIL

The following section introduces the declarative process modelling paradigm that is capable of describing complex coherencies in a concise way and allows for decision deferral to run time.

Declarative Process Modelling

Following the terminology of programming languages, there are two paradigms of describing business process models: the impera-tive and the declarative style. The imperative way corresponds to imperative or procedural programming where every possible path must be foreseen at design time and encoded explicitly. If a path is missing then it is considered not allowed. Classic approaches like the BPEL or BPMN follow the imperative style and are therefore limited to the automation type of processes.
In contrast to imperative modelling, declarative models concentrate on describing what has to be done and the exact step-by-step execution order is not directly prescribed. Here, only the undesired paths and constellations are excluded so that all remaining paths are potentially allowed and do not have to be foreseen individually. As knowledge- and decision-intensive business processes often incorporate many unforeseen paths, the declarative approach is best suited for it .

Cross-Perspective Modelling

Declarative modelling is based on constraints that relate events of the process and exclude or discourage from certain correlations. Both constraints and events must be able to involve all the perspectives of a business pro-cess like, e.g., incorporated data, agents performing the work and utilized tools. On this way it becomes possible to express realistic correlations like, e.g., the actual performing agent of a step affecting the type of data used in another step.

Different Modalities and Explanation

A business process usually consists of several “facets” like, e.g., a legal framework (mandatory, “must”) and best practice (recommended but facultative, “should”). Classic approaches like the BPMN only allow for describing one of these facets per model. Combining both of them in one model greatly enhances its documentary character and allows for a BPM system to act more flexibly. An action that, e.g., is contrary to best practice but conforms to the legal framework is offered but marked as discouraged. The BPM system may even explain why the action is not recommended by tracing it back to the process model.

Introduction and Example Process in DPIL

Some of the elements of a DPIL process model undergo a life cycle composed of events that is managed by the execution engine. A human task, e.g., can be started and completed while a data object can be read or written. Besides the static elements like human tasks and data objects, a process model may specify rules constraining that series of events. It may, e.g., claim that some data object may only be written after some task has been started. DPIL provides a textual notation based on the use of macros to define reusable rules. For instance, the sequence macro (sequence(a,b)) states that the existence of a start event of task b implies the previous occurrence of a complete event of task a.
We use the simplyfied business trip process in a university as a running example. For carrying out a business trip the applicant needs to fill out an application thats needs to be approved afterwards. Furthermore, at some point a flight needs to booked. Here, several organisational patterns can be identified: Role-Based Allocation: in any case the application needs to be checked and approved by an employee of the administration department. Retain Familar: the applicant himself knows circumstances and appointments best. Therefore, the flight must be booked by the applicant himself. Cross-Perspective Pattern, Role-Based Sequence: professors can book flights at any time and do not need to wait for the approval. Students, however, have to stick to a certain execution order of activities, i.e., they need to wait for the approval before a flight can be booked. Here, the control-flow is directly in fluenced by organisational circumstances.

use group Administration
use group Student
use relationtype hasRole

sequence(a,b) iff start(of b at :t) implies complete(of a < t)
binding(a,b) iff start(of a by :p) and start(of b) implies start(of b by p)
role(t,r) iff start(of t by :p) implies relation(subject p predicate hasRole object r)
roleSequence(a,b,r) iff start(of b by :i at :t) and relation(subject i predicate hasRole object r) implies complete(of a at < t)

process Business Trip {

	task Apply for trip
	task Approve application
	task Book flight

	ensure sequence(Apply for trip, Approve application)
	ensure role(Approve application, Administration)
	ensure binding(Apply for trip, Book flight)
	ensure roleSequence(Approve application, Book flight, Student)
}

The first three lines refer to roles and relation types of the organisational model. In the following lines four different macros are defined, i.e., the macros sequence, binding, role and roleSequence. The sequence macro relates to the precedence template of Declare. The role macro defines a role-based task allocation. The binding macro defines the structure of a binding of duties pattern. The roleSequence finally depicts a cross-perspective rule template, i.e., the start of activity b by an actor in role r requires the completion of activity a before. The actual process model starts with the definition of the three tasks. The temporal dependency between application and approval is modelled by use of the sequence macro. The rolebased task sequence is modelled by instantiating the role macro. Furthermore, the binding of duties between trip application and flight booking can be defined by the usage of the binding macro. The fact that only students have to stick to a certain execution order is modelled by using the roleSequence macro, i.e., booking a flight by a student implies the approval of the application before.

Expressiveness of DPIL.

The expressiveness of DPIL has been evaluated w.r.t. the well-known Workflow Patterns

Clearly, the key task now is to evaluate to what extent DPIL itself is suited for business process modelling. For this purpose, the Workflow Patterns Initiative has proposed a comprehensive framework of requirements for a business process modelling and execution approach. These so-called Workflow Patterns consist of recurring requirements from the behavioral, organizational and informational perspective. These patterns have been used to evaluate DPIL itself on the one hand and to compare it with BPMN on the other hand.

The evaluation reveals two valuable insights. On the one hand it becomes clear that DPIL and the PN platform meet around 50% more of the requirements than BPMN does. On the other hand it confirms that both approaches occupy their niches. Where the classic control flow patterns are concerned, BPMN is superior to DPIL 67% to 52%. As expected, when exactly specified complex control flow patterns are in focus then BPMN is best-suited. Informational and organizational relationships, however, can be expressed more comprehensively and more precisely in DPIL. The combination of both approaches makes the Process Navigation platform a comprehensive platform for the support of both routine and agile processes.

Modelling Capabilities of DPIL

  • Behavioural Patterns
    %
  • Organisational Patterns
    %
  • Information Patterns
    %

Tool Support

The DPIL Framework provides a tool set for modelling, executing and analysing flexible and resource-aware business processes based on the language DPIL. The framework consists of three modules: the DPIL Modeller, the DPIL Navigator and the DPIL Miner

1

DPIL ModellerTextual Model Editor

2

DPIL NavigatorModel Execution Engine

3

DPIL MinerMining Event Logs