A Framework for Creating Domain-speciﬁc Process Modeling Languages

Henning Heitk

otter

Department of Information Systems, University of M

unster, M

unster, Germany

Keywords:

Business Process Modeling, Domain-speciﬁc Languages, Model Transformation, BPMN 2, EMF.

Abstract:

Using domain-speciﬁc modeling languages to capture business processes can greatly enhance quality and

efﬁciency of process modeling, because language and models are more expressive, concise and easy to under-

stand. The development of domain-speciﬁc languages (DSLs) with accompanying tools and transformations

is, however, a complex, time-consuming, and costly task. An efﬁcient and simple approach to creating process

modeling languages (PMLs) for speciﬁc business domains by reusing common parts is needed, where each

resulting language is still optimally adjusted to its domain. For each of these languages, the abstract and con-

crete syntax have to be deﬁned as well as transformations to more general languages.

This paper presents DSLs4BPM, a generic framework for PMLs, which employs DSL modularization con-

cepts to allow the derivation of domain-speciﬁc PMLs. The framework provides elements common to process

modeling and a basic transformation to the generic Business Process Model and Notation 2.0. DSLs are

created by adding own types to the framework language and own rules to the transformation at predeﬁned

extension points. The approach has been implemented based on the Eclipse Modeling Framework.

1 INTRODUCTION

Business process modeling (BPM) represents enter-

prise processes as models, often using general-purpo-

se process modeling languages (PMLs). PMLs like

Business Process Model and Notation (BPMN, (Ob-

ject Management Group, 2011)) qualify as general-

purpose in the sense of not being constrained to pro-

cesses of a particular business domain. They feature

only domain-neutral concepts like the generic term

“Activity” and are particularly suited for analysis pur-

poses and technical tasks. The latter includes, for ex-

ample, workﬂow management and service orchestra-

tion. Since there are several tools and execution en-

gines supporting popular languages like BPMN, pro-

cess modelers often use these general-purpose lan-

guages directly to describe their business processes.

However, because of their widespread area of ap-

plication, these languages tend to be rather com-

plex (Recker et al., 2009). They offer a low level of

abstraction in order to be applicable to all general sce-

narios and have a highly technical appearance. Con-

sequently, models in these languages tend to be ver-

bose and difﬁcult to understand. The modeling pro-

cess itself may be time-consuming and error-prone.

Domain-speciﬁc languages (DSLs) try to address

these issues by focusing on a particular (business) do-

main. They trade generality for an optimal represen-

tation of concepts from their domain (van Deursen

et al., 2000) and try to reach an adequate level of ab-

straction (Mernik et al., 2005). Instead of complex

combinations of generic elements, domain concepts

can be expressed through exact, concise and seman-

tically rich elements. For example, in the domain of

banking, a single element could represent a domain-

typical, complex series of process steps, like formal

assessment of a case. Business process models using

a DSL are more expressive and easier to create and

understand, also and especially for domain experts.

Model-to-model transformations can still generate

models in lower-level general-purpose languages by

explicitly expressing the semantics of the DSL using

low-level technical artifacts. Thus, existing execu-

tion engines or analysis tools designed for a technical

language like BPMN can be used, even though they

cannot handle the DSL itself. A transformation from

the aforementioned banking DSL to BPMN might, for

example, replace each instance of the formal assess-

ment element by a complex network of BPMN ac-

tivities expressing the same semantics. In this sense,

domain-speciﬁc models are an important component

of model-driven development (MDD). The integra-

tion of DSL and transformation combines some ad-

vantages of general-purpose and domain-speciﬁc lan-

127

Heitkötter H..

A Framework for Creating Domain-speciﬁc Process Modeling Languages.

DOI: 10.5220/0004024201270136

In Proceedings of the 7th International Conference on Software Paradigm Trends (ICSOFT-2012), pages 127-136

ISBN: 978-989-8565-19-8

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

guages.

Developing useful DSLs requires considerable ef-

fort and cost, not least because they consist of sev-

eral parts: They have an abstract syntax describing

the structure of their domain in terms of concepts

and their relationships. One or more concrete syn-

taxes deﬁne the textual or—more common in pro-

cess modeling—graphical notation of the DSL. A ma-

ture tooling infrastructure is needed to make model-

ing with a DSL efﬁcient. As motivated above, DSLs

should provide transformations to lower-level model-

ing or programming languages, taking into account

the semantics of both, DSL and target language. De-

veloping these model transformations from scratch is

not a trivial task, either.

An efﬁcient and simple approach to creating

domain-speciﬁc PMLs with all their components

would decrease the initial investment needed to set

up the DSL. This paper presents our DSL Frame-

work for Business Process Modeling (DSLs4BPM),

from which domain-speciﬁc PMLs can be derived in a

straightforward way. The framework consists of a ba-

sic language and a transformation to BPMN 2. The

framework language provides elements common to

process modeling languages and means for quickly

adapting the framework language to a business do-

main. New, domain-speciﬁc concepts are added to

the framework when designing a domain-speciﬁc lan-

guage. The transformation to BPMN 2 that comple-

ments the language maps the language elements of

the framework to corresponding concepts in BPMN 2.

The transformation provided by the framework is

adapted concurrently with the language. Thus, a DSL

and its mapping to a general-purpose language are op-

timally adjusted to the domain. At the same time,

common parts are reused.

Our main contribution consists of this framework,

which allows the easy and efﬁcient creation of pro-

cess modeling DSLs for different domains in combi-

nation with adapted transformations to BPMN 2. Be-

sides, our approach uses extensibility as proposed in

the research literature about reusing and modulariz-

ing DSLs (Spinellis, 2001; Krahn et al., 2008; Voel-

ter, 2010). Hence, our paper also demonstrates on a

more general level how a language can be designed

with reuse and adaptability in mind by offering ex-

tension points for extending language concepts and

transformation rules in parallel. It also elaborates on

the support for these means in the well-known and

mature Eclipse Modeling Framework (EMF, (Stein-

berg et al., 2009)), proving that modular DSLs can be

built with the pragmatic mechanisms of EMF.

The remainder of this paper is structured as fol-

lows. Section 2 on related work discusses approaches

for creating domain-speciﬁc PMLs as well as general

literature on reusable DSL design. It is followed by

an introduction into process modeling, both from a

general (BPMN 2) and from a domain-speciﬁc view-

point (PICTURE). Both languages are prerequisites

for the following sections. Section 4 describes the

general design of DSLs4BPM. The language part of

the framework is presented in section 5, section 6 out-

lines the transformation. Section 7 gives some details

regarding the implementation and describes how to

create derived DSLs by adapting the framework. We

discuss and evaluate our framework in Section 8. The

paper concludes with a summary and an outlook.

2 RELATED WORK

Research and praxis have proposed and evaluated sev-

eral general-purpose PMLs. Besides BPMN, covered

in the next section, the most prominent of these are

Activity Diagrams from the Uniﬁed Modeling Lan-

guage (UML, (Object Management Group, 2010)),

studied in (Dumas and ter Hofstede, 2001), and

the more technical Business Process Execution Lan-

guage (BPEL, (OASIS Standard, 2007)). These lan-

guages do not consider any particular business do-

main. PICTURE, also described in section 3, is an

example of a domain-speciﬁc PML. The focus of our

work, however, does not lie on a single modeling lan-

guage, but on creating DSLs for process modeling in

an efﬁcient manner and on combining these with cor-

responding transformations.

Creating domain-speciﬁc PMLs efﬁciently is also

the focus of jABC (Steffen et al., 2007) and its pre-

decessors (Steffen and Margaria, 1999; Margaria and

Steffen, 2004). jABC employs a building block-based

approach to the model-driven development of ser-

vices and applications, similar to DSLs4BPM. Exe-

cutable process models are composed from so called

Service Independent Building Blocks (SIB). A SIB

corresponds to a Java class with execution code, so

that models are directly executable or can be trans-

formed to application code. As our approach instead

targets BPMN 2, it provides a higher abstraction level

and supports a stepwise model-driven development,

while retaining executability through the respective

features of BPMN. jABC is a self-contained frame-

work, whereas the process modeling language frame-

work presented in this paper is implemented on top of

standard modeling technologies (EMF), enabling its

integration into larger MDD projects.

Brahe and Østerbye use UML activity diagrams

and the proﬁling mechanism of UML to facilitate the

deﬁnition of domain-speciﬁc PMLs (Brahe and Øster-

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

128

bye, 2006). Their tool generates UML proﬁles for

individual domains. Proﬁles allow the specialization

of generic UML constructs and are an example of an

adaptation mechanism in general-purpose modeling

languages. BPMN 2 offers a similar extensibility con-

cept. DSLs4BPM does not make use of this approach

to adaptation in order to avoid the overhead and sub-

optimal domain representation of a general-purpose

language. Instead, the framework language provides

a minimal set of common concepts and has to be ex-

tended for speciﬁc domains, which ensures ﬂexibil-

ity and expressiveness. In contrast to our framework,

Brahe and Østerbye do not consider model transfor-

mations for their DSLs.

DSLs4BPM uses modularization concepts for

DSLs proposed in the literature. Spinellis identi-

ﬁes recurring patterns in the development of tex-

tual DSLs, of which some describe approaches to

reuse (Spinellis, 2001). Our framework can be seen as

an application of the extension pattern, because new

elements are added to an existing language. In our

framework, however, extensions only take place at

particular points (Section 4). These extension points

provide some guidance to language developers, which

is not considered by the pattern.

olter identiﬁes several modularization concepts

available in the language workbench JetBrains MPS

(Voelter, 2010), one of them being extension, i.e., in-

heritance between languages and language concepts,

in combination with transformation overriding. Other

concepts available in MPS like embedding of lan-

guages are not needed in our framework. Our frame-

work does not use JetBrains MPS but EMF, which

provides less modularization concepts, and offers the

remaining concepts less prominently and less easily

accessible. However, as shown by our implementa-

tion, EMF’s capabilities regarding DSL modulariza-

tion are sufﬁcient for creating a powerful framework

for the efﬁcient creation of process modeling DSLs.

3 PROCESS MODELING

3.1 General-purpose: BPMN 2

The Object Management Group’s (OMG) speciﬁca-

tion Business Process Model and Notation (Object

Management Group, 2011) describes a PML that is

widely used and supports analysis and execution of

business processes. Version 2.0 introduced a com-

plete metamodel not available in previous versions

and enhanced the support for executable models.

Figure 1: Example model of a BPMN process.

Figure 2: BPMN metamodel (simpliﬁed excerpt).

Tools like Activiti

can directly execute processes

modeled in BPMN 2 by managing the workﬂow of

processes and by orchestrating services. Due to its

popularity and good tool support, BPMN is the tar-

get of our framework’s transformation. To introduce

the concepts that are important for the transformation,

this section gives a short overview of BPMN 2.

The example of ﬁgure 1 highlights important ele-

ments of BPMN. It depicts a Process, which forms a

central model element of BPMN. It is a graph of so

called Flow Nodes connected by directed Sequence

Flow edges. BPMN provides several types of ﬂow

nodes, including Task, Gateway and Event. Hierar-

chical nesting is supported by the concept of Subpro-

cesses. Tasks represent units of work and are provided

in different specializations to accommodate different

kinds of activities, for example User Tasks or Service

Tasks. Gateways are used to split the control ﬂow of a

process into parallel or exclusive branches as well as

to merge such branches. Events symbolize that a pro-

cess either triggers some incident (Throw Event) or

waits for its occurrence (Catch Event). Additionally,

events are differentiated with regard to the type of in-

cident, for example message or timer. In BPMN 2’s

metamodel (ﬁgure 2), ﬂow nodes and sequence ﬂow

are subsumed under the term Flow Element. A pro-

cess is a collection of ﬂow elements and is performed

within an organization.

http://www.activiti.org

AFrameworkforCreatingDomain-specificProcessModelingLanguages

129

A business process is made up of several such

BPMN processes, each representing the work carried

out within one organization, called Participant in this

context. A Pool is the graphical representation of a

participant in a BPMN diagram and contains the vi-

sual depiction of the participant’s process. A set of

interacting processes forms a Collaboration. Mes-

sage Flow symbolizes the exchange of information

between two different processes.

As BPMN is domain-independent and has a rather

technical appeal, it is not an appropriate source model

for MDD. Recker et al. analyze the modeling process

with BPMN (Recker et al., 2010; Recker, 2010). They

ﬁnd BPMN to be complex and in some part confusing

for modelers. Deﬁciencies of the language include

ambiguous and redundant elements, as well as lack of

support for business rules and process decomposition.

However, these mainly impact the modeling process.

As described before, BPMN is useful as the techni-

cal speciﬁcation of a process. Our approach renders

direct modeling in BPMN, which was found to be

a non-trivial task, unnecessary, but provides BPMN

models via a transformation.

3.2 Domain-speciﬁc: PICTURE

While there are several general-purpose PMLs, indi-

vidual DSLs have not yet surfaced as prominently in

process modeling as they have in other areas. This

might be due to the effort necessary for developing

such a DSL. However, as the discussion above and

similar approaches from related work highlight, the

usage of DSLs could enhance quality of process mod-

els. PICTURE, a DSL for business processes in pub-

lic administration (Becker et al., 2007), demonstrates

the general viability of DSLs for process modeling. It

was developed to efﬁciently model the process land-

scape of public administrations and was subsequently

transferred to the domain of banking (Becker et al.,

2009b). It restricts the modeler’s freedom in or-

der to reduce complexity. Models in PICTURE fol-

low a clear hierarchical structure and use straightfor-

ward, comprehensible means of expressing control

ﬂow. Typical activities in public administration or

banking, respectively, are available as building blocks

to describe the individual steps of a process in a con-

densed manner. As the DSL furthermore does not

feature redundant or ambiguous elements, a modeler

with experience in public administration or banking

can efﬁciently model processes with PICTURE.

In summary, PICTURE allows for creating con-

cise process models that are nevertheless expressive

and include all information relevant for their respec-

tive purpose. PICTURE has been used and evalu-

Figure 3: Overview of framework (À+Á) and an extension

for a particular domain (Â+Ã).

ated successfully in several projects (Karow et al.,

2008; Matzner et al., 2009) and through experi-

ments (Becker et al., 2009a). Therefore, it of-

fers a good basis for the language of DSLs4BPM.

Our framework language has the same structural ap-

proach to process modeling as PICTURE, but encom-

passes only those core elements of PICTURE that are

domain-independent. As PICTURE has been suc-

cessfully transferred to other domains, it is a viable

basis for the framework language. PICTURE mod-

els for public administrations have been successfully

transformed to BPMN (Heitkoetter, 2011). This sug-

gests that it will also be possible to transform models

based on a framework language that has been derived

and generalized from PICTURE’s structural parts.

4 DESIGN OF FRAMEWORK

Figure 3 gives an overview of our framework for the

integrated creation of process modeling DSLs and

transformations. DSLs4BPM consists of a generic

PML (À in ﬁgure 3) and a transformation (Á) map-

ping the generic concepts to BPMN 2 (Ä). Language

and transformation provide the basic structure and are

explicitly designed to be extended. Domain-speciﬁc

languages can be derived from the framework by ex-

tending the generic language at predeﬁned extension

points with domain-speciﬁc constructs (Â). At the

same time, the transformation should be adapted to

the new language elements and their semantics by

overloading speciﬁed rules (Ã). The new rules should

transform the domain-speciﬁc constructs into corre-

sponding elements from BPMN. They can also adapt

the behavior of the general transformation where nec-

essary. These partial transformations are seamlessly

integrated into the general transformation by the prin-

ciple of Inversion of Control.

The idea behind this approach is to generalize sim-

ilarities of PMLs and to provide a complete transfor-

mation framework for these common concepts. Busi-

ness processes of a particular domain feature recur-

ring patterns that are easily identiﬁable and enumer-

able. These typical activities, each consisting of sev-

eral steps, have a meaning for domain experts and

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

130

are thus possible elements of an expressive DSL. The

already mentioned formal assessment in banking is

an example of such a typical activity. Besides these

individual activities, differing from domain to do-

main, process models mainly feature similar elements

across domains, for example various kinds of control

ﬂow and a hierarchical structure, that can be general-

ized and extracted into a generic language.

Hence, the framework is responsible for common

concepts of structured processes, while the individ-

ual, derived DSLs handle domain-speciﬁc concepts,

for example from banking, insurance or public admin-

istration. This allows for a less complex creation of

business process DSLs that are nevertheless expres-

sive and concise. Additionally, an adapted transfor-

mation to BPMN 2 is available with minor invest-

ment. Thereby, the process modeling framework aims

to overcome the gap between expressive DSL models

and widely usable general-purpose models, combin-

ing the advantages of DSLs and BPMN 2.

DSLs4BPM provides means for structuring a pro-

cess as well as for describing the process ﬂow in terms

of sequences, variations and communication. More-

over, organizational aspects are considered. The main

extension point offered by the general framework is

the metamodel element Process Building Block. It

is intended to be subclassed by derived DSLs. Each

subtype should correspond to a typical, potentially

complex, but clearly delimitable activity of that do-

main. The framework’s core transformation contains

a placeholder rule for building blocks. Derivations

should provide a suitable mapping for their speciﬁc

subtypes that replaces or augments the default behav-

ior to ensure an adequate transformation. Hence, the

additions to our framework made by derived DSLs

and their transformations take place at predeﬁned

points by means of subclassing. This is a less gen-

eral, but more accessible notion of extensibility than

the analogous pattern for DSLs in (Spinellis, 2001),

which covers arbitrary additions. The coupling of

DSL extension with adaptation of a transformation

is also special to our approach. Suchlike extension

points allow a better semantic integration of new types

via the transformation.

5 FRAMEWORK LANGUAGE

The framework language has been adapted from PIC-

TURE by generalizing concepts and focusing on

domain-neutral aspects. Since the general align-

ment and structure of PICTURE have been preserved,

DSLs4BPM inherits the beneﬁts of that well-tested

DSL. Modeling of structured processes is easier and

Figure 4: Metamodel of framework language (excerpt) with

extension points.

more efﬁcient due to a lower complexity of the

language. Models built with a DSL derived from

DSLs4BPM are concise, expressive, and easy to un-

derstand. The easy and understandable syntax is

achieved by focusing on processes that are at least

moderately structured and for the most part linear.

The number of options available to express a concept

and by it the modeler’s freedom is intentionally re-

stricted in order to reduce variability. In the follow-

ing, the domain-independent framework language is

described along with its metamodel (ﬁgure 4) and ex-

tension points for derived DSLs. Figure 5 displays an

example model in a derived DSL that resembles the

original PICTURE for public administration.

A (business) Process is divided into several Sub-

processes along organizational or functional criteria.

Predecessor-successor relationships between subpro-

cesses determine the order of execution. A subpro-

cess can have one or more predecessors and succes-

sors. Its execution begins when all preceding subpro-

cesses have been completed. Additional constraints

enforce the absence of cycles, so that a process is

a connected, directed acyclic graph of subprocesses.

Roughly speaking, a subprocess is a linear sequence

of Process Building Blocks. These blocks will gen-

erally be instances of domain-speciﬁc subtypes. The

domain-speciﬁc building blocks themselves can en-

capsulate complex semantics, but on the subprocess

level they are seen, in principle, as executed sequen-

tially with their inner semantics hidden. The modeler

chooses from the set of building block types available

in the respective DSL and aligns instances in the or-

der they appear in the process ﬂow. Building blocks

have attributes, e.g., name, which must or can be set

on instances. Domain-speciﬁc building blocks will

deﬁne their own attributes as needed. Through these

attributes, instances can match their appearance in the

process at hand and represent the respective step of

the process more precisely. This simple way of ar-

AFrameworkforCreatingDomain-specificProcessModelingLanguages

131

Figure 5: Example model of a process in a derived DSL

(with six subprocesses A-F performed by two organiza-

tional elements P1, P2).

ranging the constitutive elements of a process linearly

considerably simpliﬁes modeling. A large part of

process complexity is handled by the domain-speciﬁc

building blocks, which nevertheless are intuitively ac-

cessible to the domain-experienced modeler, because

they stand for known activities of the domain.

Some subprocesses require, however, the possibil-

ity to model variations in the sequence of building

blocks, like skipped or additional blocks or a differ-

ent order of execution depending on certain condi-

tions. In the example of ﬁgure 5, the second vari-

ant of subprocess D replaces the Create Document

instance of variant 1 with an Inquiry followed by a

Receive Document building block. To accommodate

these needs, the framework language uses the concept

of subprocess variants. Actually, the way of model-

ing described above takes place entirely on the variant

level. Each variant is a complete and separate linear

sequence of building blocks. An instance of a build-

ing block including its attribute values can appear in

one or more variants and is shared among the vari-

ants of a subprocess, enabling the reuse of parts of

the subprocess. In ﬁgure 5, both variants contain the

same Formal Assessment instance (a) and the same

Print Document instance (e).

A typical workﬂow when modeling the course of

a subprocess is to ﬁrst create the main variant repre-

senting the normal case, which is then copied to a new

variant and modiﬁed wherever the respective alterna-

tive differs from the original. The modeler is able to

model every distinct case separately without inﬂuenc-

ing other cases. If the process ﬂow has only a moder-

ate amount of variation, this way of modeling proves

to be very efﬁcient (Becker et al., 2007). Addition-

ally, the resulting models provide a high readability,

as differences are clearly separated. The ﬁrst and last

building block must be identical across all variants of

a subprocess. This constraint makes models easier to

understand, guarantees strictly deﬁned semantics and

simpliﬁes the transformation.

The underlying metamodel of the framework lan-

guage (ﬁgure 4) incorporates the previous explana-

tions with an occurrence concept. Variants as well

as building block instances are stored at subprocess

level, so that blocks can be shared among variants of

their subprocess. Each variant contains a collection

of building block occurrences referencing the build-

ing blocks that are present in the variant. A linear

predecessor-successor-relationship deﬁnes the order

of occurrences separately for each variant. The or-

ganizational view of the process is incorporated by a

generic organizational element. This is another exten-

sion point for a derived DSL, as organizational struc-

tures will be domain-speciﬁc. Process, subprocess

and building block specify the organization in charge

of them by a reference to this organizational super-

type. Resources and data can be attributed similarly

to further describe building block instances.

6 TRANSFORMATION TO

BPMN 2

The transformation to BPMN 2 aims to generate ex-

ecutable models. It thus enables or facilitates the

implementation of supporting systems. The gener-

ated BPMN models explicitly represent both the com-

plex activities embodied in domain-speciﬁc build-

ing blocks and the control ﬂow implicitly existing in

framework models. The transformation is an inherent

part of the framework and a complete mapping of the

framework language. Derived DSLs adapt the trans-

formation by supplying custom transformation rules

for their own elements.

The framework’s generic transformation to

BPMN 2 is based on a previous domain-speciﬁc

transformation from PICTURE to BPMN 2

(Heitkoetter, 2011). That transformation was

tied to the domain of public administration, while

the focus here lies on the domain-neutral concepts

and their generic mapping to BPMN 2. The rules

from the original transformation that are concerned

with domain-neutral structural concepts also apply

to the framework transformation. The following

gives a high-level overview of the transformation and

otherwise focuses on the newly introduced extension

points and their integration into the transforma-

tion. For more details and reasoning regarding the

structural rules please refer to (Heitkoetter, 2011).

A process of the framework language is mapped

to a BPMN collaboration with several participants.

Each participant represents one particular organiza-

tion of the input model. The corresponding pool de-

picts all subprocesses performed by that organization.

Subprocesses are represented by the mapping of their

building block instances. Every building block in-

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

132

stance is transformed only once, irrespective of the

number of occurrences in variants, so that each oc-

currence maps to the same representation. Hence,

this representation can have more than one prede-

cessor and successor in BPMN, respectively. The

transformation connects the representations of build-

ing blocks of a subprocess as determined by their oc-

currences in variants, using sequence ﬂow and, if nec-

essary, exclusive gateways to model the process ﬂow.

Through these transformation rules, a framework sub-

process is represented in BPMN as a connected graph

of representations for its building blocks. The trans-

formation connects these individual graphs according

to the connections between subprocesses, generating

sequence or message ﬂow edges, parallel gateways,

and message events as necessary.

The generic transformation provided by the

framework transforms a building block to a single

task. Building block subtypes of derived DSLs can be

mapped to arbitrary graphs of ﬂow elements. The core

transformation is prepared to handle these more com-

plex representations. It only expects that the BPMN

representation of a building block is a collection of

ﬂow elements (ﬂow nodes and sequence ﬂow) with

one entry and one exit point. These restrictions en-

able the transformation to integrate any representa-

tion conforming to this basic skeleton into the BPMN

process. Besides the default generic task, a building

block can thus be mapped to a speciﬁc type of task

(e.g., User Task or Service Task), to an event, to a

subprocess which in turn contains a connected graph

of ﬂow nodes, or directly to such a ﬂow graph. The

restriction to ﬂow graphs with unique source and sink

is due to the linear nature of variants. The execution

of a building block can nevertheless inﬂuence the pro-

cess ﬂow because it modiﬁes the process state.

7 IMPLEMENTATION

The implementation of DSLs4BPM is based on the

Eclipse Platform

and uses the Eclipse Modeling

Framework (Steinberg et al., 2009), which provides

means to deﬁne modeling languages and handles

models in these languages. The metamodel of the

framework language is described with EMF’s Ecore

language. An implementation of BPMN 2’s meta-

model with EMF is available through an Eclipse

project

. The model-to-model transformation is writ-

ten in the Operational Mapping language of OMG’s

Query/View/Transformation standard (Object Man-

http://www.eclipse.org

http://wiki.eclipse.org/MDT/BPMN2

agement Group, 2008), of which an EMF-based im-

plementation is available in the Eclipse project QVT

Operational

(QVTO).

All elements of the framework language from sec-

tion 5 have been implemented in Ecore, including the

generic type Process Building Block. EMF’s EClass

type, which is used to describe these metamodel el-

ements, supports object-oriented inheritance. There-

fore, implementing derived DSLs is straightforward.

The DSL designer has to provide a new Ecore model

with the domain-speciﬁc building block types as sub-

classes of the generic building block type from the

framework metamodel. These subclasses can have

their own attributes and references. Models built in

the derived DSL resort to the structural elements from

the framework language and to the individual building

blocks from the DSL.

The core transformation included in DSLs4BPM

takes a model written in the framework language as

input and outputs a BPMN model that complies with

BPMN 2’s metamodel and semantics. It implements

the transformation rules of section 6, which deal with

elements from the framework language. Each core

transformation rule creates all BPMN elements that

make up the representation of the framework element

handled by the rule, including helper elements and

connections, and calls the rules for child elements.

The additional rules for a derived DSL have to be de-

ﬁned in a separate transformation.

Listing 1: Excerpt from core transformation.

1 h e l p e r P r o c e s s B u i l d i n g B l o c k : : tra n sfor m PBB ( )

2 : C o l l e c t i o n ( Flow Ele ment ) {

3 var r e s u l t : L i s t ( F low El eme nt ) : = L i s t { } ;

4 r e s u l t += s e l f . map to Fl ow Gr ap h ( ) ;

5 / / c r e a t e c o n n e c t i o n s t o s u c c e s s o r s

6 / / c r e a t e ga te w ay , i f n e c e s s a r y

7 r e t u rn r e s u l t ;

8 }

9 mapping P r o c e s s B u i l d i n g B l o c k : : t oF lo wG ra ph ( )

10 : L i s t ( Fl ow Ele me nt ) {

11 r e s u l t −>add ( s e l f . map t o S i n g l e T a s k ( ) ) ;

12 }

13 query P r o c e s s B u i l d i n g B l o c k : : c o n n e c t o r I n c o m i n g ( )

14 : FlowNode {

15 r e t u rn s e l f . map t o S i n g l e T a s k ( )

16 }

The core transformation contains several op-

erations related to building blocks (listing 1).

transformPBB is responsible for transforming a

building block and integrating it into the process

(lines 1–8). The actual mapping of the building

block to a ﬂow graph as described in section 6

is expected to be performed by toFlowGraph (9–

http://wiki.eclipse.org/M2M/QVTO

AFrameworkforCreatingDomain-specificProcessModelingLanguages

133

12). The core transformation resorts to the query

connectorIncoming to determine the entry point of

the representation when connecting it (13–16). An

analog query exists for the exit point. In case of the

generic building block, both of these methods return

the single task created by toFlowGraph.

In order to represent each domain-speciﬁc ac-

tivity accurately in BPMN, tailored mappings for

domain-speciﬁc builing block types have to be pro-

vided. The new transformation that transforms a de-

rived DSL has to extend the framework transforma-

tion through QVTO’s keyword extends (listing 2,

lines 1–3). As part of the new transformation, the

mapping toFlowGraph and both connector queries

have to be overridden for each building block sub-

type that needs a speciﬁc mapping, in this example

SpecialPBB. The mapping operation creates the ﬂow

nodes and sequence ﬂow edges that make up the spe-

ciﬁc representation and returns them as a collection

of ﬂow elements (4–8). It can resort to the values

of attributes deﬁned for the subtype or to conﬁgura-

tion parameters in order to further tailor the mapping,

which thus does not have to be static. For example,

it could use a project-speciﬁc parameter as the ad-

dress of a Web service in a Service Task or modify

the BPMN representation of a building block instance

according to the instance’s attribute values. The con-

nector queries must return those ﬂow nodes out of the

ﬂow graph that act as entry or exit point, respectively

(9–11). When an instance of a subtype is encountered,

the overridden methods are called instead of the de-

fault ones according to the Inversion of Control prin-

ciple. This way the transformation can incorporate

the elements of the adapted representation into the re-

sult model and create connections to the appropriate

elements. In addition to this general mechanism, the

framework offers shortcuts for certain kinds of exten-

sion, for example a mapping to a single Service Task.

Listing 2: Extended transformation (excerpt).

1 t r a n s f o r m a t i o n dsl2 bpmn 2 ( in s r c : d s l ,

2 o u t t r g t : bpmn2 )

3 e x t e n d s t r a n s f o r m a t i o n framework2bpmn2 ;

4 mapping Sp ec ia lP B B : : t o Fl ow Gr ap h ( )

5 : L i s t ( Fl ow Ele me nt ) {

6 r e s u l t −>add ( s e l f . map t oT as kOn e ( ) ) ;

7 / / c r e a t e o t h e r e l e m e n t s o f t h e f l o w g ra ph

8 }

9 query Sp ec ia lP BB : : c o n n e c t o r I n c o m i n g ( ) : FlowNode {

10 r e t u rn s e l f . map to Ta skO ne ( )

11 }

Besides the extended mappings, nothing has to be

deﬁned for an individual DSL, as the framework al-

ready deﬁnes most of the transformation. If neces-

sary, a modiﬁcation of core transformation rules is

possible via QVTO. The extended transformation is

deﬁned during the development of the derived DSL.

The modeler who eventually uses the DSL is not con-

cerned with these tasks. QVTO’s extension mecha-

nisms in addition to the polymorphism in EMF thus

enable an easy and straightforward way to adapt the

framework’s transformation.

8 DISCUSSION

In the following, we evaluate DSLs4BPM with re-

spect to the development effort needed when design-

ing new DSLs and transformations. Afterwards, we

study the conceptual advantages and contributions.

We also highlight potential areas for improvement.

The savings that can be expected with our results

can be approximated by looking at the source code

of our framework and typical extensions compared to

standalone implementation of DSLs. The framework

language consists of 16 classes with just over 50 dis-

tinct features. The basic transformation to BPMN 2

included in the framework has been implemented in

approximately 650 logical lines of code of QVTO.

As this code transforms the basic process structure

and control ﬂow, nearly all of it would also be re-

quired in a standalone implementation that does not

use the framework. The overhead of the framework

transformation consists of statements due to provi-

sions for adaptation. These lines, which would not be

needed in a single, standalone transformation, amount

to less than ﬁve percent of the transformation’s source

code. Regarding derived languages, only one addi-

tional class due to peculiarities of EMF is needed in a

derived DSL besides the speciﬁc concepts introduced

by that DSL, so that the overhead is minimal. With

respect to an extended transformation, each new con-

cept that has to be transformed to BPMN requires

a corresponding adapted transformation rule. Each

of these adaptations consists of as many statements

as needed to generate the particular BPMN represen-

tation. These mostly perform simple, but laborious

work to build up the corresponding ﬂow graph and

would be needed in either case, so that there are only

0-3 lines of overhead per concept, depending on the

complexity.

In summary, DSLs4BPM introduces only a small

amount of overhead, while relieving DSLs of the most

complex parts of the transformation, namely the rep-

resentation of structure and of control ﬂow. This

greatly reduces the development effort for implement-

ing individual DSLs, which mainly does not extend

beyond a straightforward implementation of concepts

and mappings that have been identiﬁed during the de-

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

134

sign of the DSL. The expected savings have been con-

ﬁrmed in two case studies with DSLs for public ad-

ministration and for banking, respectively.

Our framework suggests a streamlined adaptation

process for deriving a DSL in combination with a

transformation to BPMN 2. The design of the DSL

requires the identiﬁcation of domain concepts that

should be added to the framework language, mainly

as new building block types. For each of these new

elements, relevant attributes have to be identiﬁed, as

well as its mapping to BPMN. In case of building

blocks, the latter should be described in the form of

a BPMN subgraph that represents the typical activ-

ities behind this building block type. Currently, the

implementation has to be done manually with help

provided by the respective Eclipse tools. In princi-

ple, large parts of the adaptation process following

the conceptual design of a DSL can be supported by

a wizard and automated. The wizard would have to

gather the aforementioned information from the lan-

guage designer, i.e., the list of new concepts and their

representation as a BPMN graph. For the latter, the

wizard could resort to a BPMN diagram tool. Based

on the gathered information, the wizard would create

the derived DSL and the source code of an extension

of the transformation in QVTO

. Only a relatively

small amount of additional work would be needed

to adapt the automatically generated transformation

to special requirements, for example if attribute val-

ues inﬂuence the BPMN representation. Hence, our

framework opens up even further improvements for

creating DSLs, besides the already simpliﬁed process

of DSL design and implementation. Future work will

inspect this direction.

As to the trade-off between reuse potential and

domain speciﬁcity, DSLs4BPM provides common

structural elements and commissions derived DSLs to

provide individual building block types representing

typical domain-speciﬁc activities. This separation re-

duces the development effort while enabling expres-

sive models. Transforming the concise and domain-

speciﬁc process models to BPMN 2 yields advan-

tages when analyzing or implementing processes.

Due to the individual transformation rules that ex-

press domain-speciﬁc complex activities, the gener-

ated BPMN 2 models can exhibit a high level of detail

suitable for service orchestration or workﬂow man-

agement. Therefore, using the framework allows for

a valuable combination of expressive DSL models

and executable BPMN models. The fact that adap-

tation takes place at predeﬁned and documented ex-

tension points simpliﬁes the derivation of DSLs from

The generation of QVTO code would require a BPMN-

to-QVTO code generator.

the framework.

The extension mechanisms provided by EMF and

QVTO proved to be suited for creating modular and

reusable modeling languages. Thus, using the mature

EMF environment also enables more complex sce-

narios for DSL creation and reuse than simply deﬁn-

ing each language from scratch. While speciﬁc sce-

narios might need the more advanced modularization

techniques for DSL reuse described in the literature

and available in other language development envi-

ronments, the extensibility approach employed while

designing the framework is sufﬁcient on its own for

reusing common parts. This is especially important

and helpful because most environments for creating

DSLs and model transformations offer some kind of

extension mechanism.

In contrast to approaches that focus on DSL reuse,

DSLs4BPM has an integrated, model-driven perspec-

tive and includes transformations to less abstract but

widely-used languages as an inherent part. A DSL

alone is often not as useful as a combined approach.

As soon as a DSL shall not only to be used for doc-

umentation, but also for other purposes like analysis

or implementation, customized tools are needed. Due

to the speciﬁc nature of a DSL, these are most often

not available and developing them would not be cost-

efﬁcient. Through the readily available transforma-

tion to BPMN, DSLs implemented within our frame-

work can almost immediately proﬁt from the execu-

tion support and other capabilities of BPMN.

9 CONCLUSIONS

The DSL Framework for BPM (DSLs4BPM) pre-

sented in this paper enables the efﬁcient creation of

domain-speciﬁc PMLs by reusing common, generic

parts of a compact language. Thus, the framework

makes it easier to realize the beneﬁts associated with

using an optimally adjusted DSL for process model-

ing. As a particular focus lies on model-driven de-

velopment, the framework is complemented with an

adaptable transformation to BPMN 2. By adapta-

tion, the transformation can express the semantics of

domain-speciﬁc elements. Implementing the frame-

work based on EMF has demonstrated the viability of

that environment for advanced and modular model-

driven approaches.

Future work will deal with improving the tool sup-

port for developing derived DSLs, e.g., by providing

a wizard, and for modeling with the framework. At

the moment, tree-based editors generated by EMF are

used during modeling. A more meaningful and ex-

tendable concrete syntax is needed. Our approach

AFrameworkforCreatingDomain-specificProcessModelingLanguages

135

does not depend on any kind of concrete syntax, so

that the introduction of a notation will be straightfor-

ward, even more so as the framework language lends

itself to a graphical notation. The wizard mentioned

above could also help in this regard by creating a

graphical editor for a DSL based on a generic edi-

tor. Furthermore, it might be worthwhile to explore if

the general approach taken in this paper—creating a

framework from which to derive DSLs—can be trans-

ferred to other aspects of system modeling, for exam-

ple requirements modeling, where DSLs play an im-

portant role as well.

REFERENCES

Becker, J., Algermissen, L., Pfeiffer, D., and R

ackers, M.

(2007). Local, participative process modelling - the

PICTURE-approach. In Proc. of the 1st International

Workshop on Management of Business Processes in

Government (BPMGOV).

Becker, J., Breuker, D., Pfeiffer, D., and R

ackers, M.

(2009a). Constructing comparable business process

models with domain speciﬁc languages - an empirical

evaluation. In 17th European Conference on Informa-

tion Systems (ECIS), pages 1–13.

Becker, J., Weiss, B., and Winkelmann, A. (2009b). Devel-

oping a business process modeling language for the

banking sector - a design science approach. In Proc.

of the 15th Americas Conference on Information Sys-

tems (AMCIS).

Brahe, S. and Østerbye, K. (2006). Business process model-

ing: Deﬁning domain speciﬁc modeling languages by

use of UML proﬁles. In Model Driven Architecture –

Foundations and Applications, pages 241–255.

Dumas, M. and ter Hofstede, A. (2001). UML activity dia-

grams as a workﬂow speciﬁcation language. In UML

2001 — The Uniﬁed Modeling Language. Modeling

Languages, Concepts, and Tools, pages 76–90.

Heitkoetter, H. (2011). Transforming PICTURE to BPMN

2.0 as part of the model-driven development of elec-

tronic government systems. In Proc. of the 44th

Hawaii International Conference on System Sciences

(HICSS 2011).

Karow, M., Pfeiffer, D., and R

ackers, M. (2008). Empirical-

based construction of reference models in public ad-

ministrations. In Multikonferenz Wirtschaftsinfor-

matik 2008. Referenzmodellierung, pages 1613–1624.

Krahn, H., Rumpe, B., and V

olkel, S. (2008). MontiCore:

Modular development of textual domain speciﬁc lan-

guages. In Proc. of TOOLS EUROPE.

Margaria, T. and Steffen, B. (2004). Lightweight coarse-

grained coordination: a scalable system-level ap-

proach. International Journal on Software Tools for

Technology Transfer, 5(2-3):107–123.

Matzner, M., Voigt, M., Alexandrini, F., Araujo, T. S., and

Becker, J. (2009). Process modelling in brazilian pub-

lic administrations: The domain-speciﬁc PICTURE

approach. In 15th Americas Conference on Informa-

tion Systems (AMCIS).

Mernik, M., Heering, J., and Sloane, A. M. (2005). When

and how to develop domain-speciﬁc languages. ACM

Computing Surveys, 37(4):316–344.

OASIS Standard (2007). Web Services Business Process

Execution Language Version 2.0.

Object Management Group (2008). Meta Object Facility

(MOF) 2.0 Query/View/Transformation speciﬁcation.

Object Management Group (2010). UML 2.3 superstructure

speciﬁcation.

Object Management Group (2011). Business Process

Model and Notation 2.0 speciﬁcation.

Recker, J. (2010). Opportunities and constraints: the current

struggle with BPMN. Business Process Management

Journal, 16(1):181–201.

Recker, J., Indulska, M., Rosemann, M., and Green, P.

(2010). The ontological deﬁciencies of process mod-

eling in practice. European Journal of Information

Systems, 19(5):501–525.

Recker, J. C., Rosemann, M., Indulska, M., and Green, P.

(2009). Business process modeling : a comparative

analysis. Journal of the Association for Information

Systems, 10(4):333–363.

Spinellis, D. (2001). Notable design patterns for domain-

speciﬁc languages. The Journal of Systems and Soft-

ware, 56(1):91–99.

Steffen, B. and Margaria, T. (1999). METAFrame in prac-

tice: Design of intelligent network services. In Cor-

rect System Design, LNCS 1710, pages 390–415.

Steffen, B., Margaria, T., Nagel, R., J

orges, S., and

Kubczak, C. (2007). Model-driven development with

the jABC. In Proc. of the 2nd International Haifa Ver-

iﬁcation Conference (HVC).

Steinberg, D., Budinsky, F., Paternostro, M., and Merks,

E. (2009). EMF: Eclipse Modeling Framework, 2nd

Edition. Addison-Wesley Longman.

van Deursen, A., Klint, P., and Visser, J. (2000). Domain-

speciﬁc languages: An annotated bibliography. ACM

SIGPLAN Notices, 35(6):26–36.

Voelter, M. (2010). Implementing feature variability for

models and code with projectional language work-

benches. In Proceedings of the 2nd International

Workshop on Feature-Oriented Software Develop-

ment, pages 41–48.

ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends

136