A Framework for Creating Domain-specific Process Modeling Languages Henning Heitk ¨ otter Department of Information Systems, University of M¨ unster, M¨ unster, Germany [email protected]Keywords: Business Process Modeling, Domain-specific Languages, Model Transformation, BPMN 2, EMF. Abstract: Using domain-specific modeling languages to capture business processes can greatly enhance quality and efficiency of process modeling, because language and models are more expressive, concise and easy to under- stand. The development of domain-specific languages (DSLs) with accompanying tools and transformations is, however, a complex, time-consuming, and costly task. An efficient and simple approach to creating process modeling languages (PMLs) for specific 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 defined 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-specific 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 predefined 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, workflow 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 difficult to understand. The modeling pro- cess itself may be time-consuming and error-prone. Domain-specific 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-specific 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-specific lan- 127 Presented at ICSOFT 2012
Transcript
A Framework for Creating Domain-specific Process Modeling Languages
Henning HeitkotterDepartment of Information Systems, University of Munster, Munster, Germany
Keywords: Business Process Modeling, Domain-specific Languages, Model Transformation, BPMN 2, EMF.
Abstract: Using domain-specific modeling languages to capture business processes can greatly enhance quality andefficiency of process modeling, because language and models are more expressive, concise and easy to under-stand. The development of domain-specific languages (DSLs) with accompanying tools and transformationsis, however, a complex, time-consuming, and costly task. An efficient and simple approach to creating processmodeling languages (PMLs) for specific business domains by reusing common parts is needed, where eachresulting language is still optimally adjusted to its domain. For each of these languages, the abstract and con-crete syntax have to be defined 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-specific PMLs. The framework provides elements common to processmodeling and a basic transformation to the generic Business Process Model and Notation 2.0. DSLs arecreated by adding own types to the framework language and own rules to the transformation at predefinedextension 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 likeBusiness 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 featureonly 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, workflow 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 ofabstraction 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 difficult to understand. The modeling pro-cess itself may be time-consuming and error-prone.
Domain-specific languages (DSLs) try to addressthese issues by focusing on a particular (business) do-
main. They trade generality for an optimal represen-tation of concepts from their domain (van Deursenet al., 2000) and try to reach an adequate level of ab-straction (Mernik et al., 2005). Instead of complexcombinations of generic elements, domain conceptscan be expressed through exact, concise and seman-tically rich elements. For example, in the domain ofbanking, a single element could represent a domain-typical, complex series of process steps, like formalassessment of a case. Business process models usinga DSL are more expressive and easier to create andunderstand, also and especially for domain experts.
Model-to-model transformations can still generatemodels in lower-level general-purpose languages byexplicitly expressing the semantics of the DSL usinglow-level technical artifacts. Thus, existing execu-tion engines or analysis tools designed for a technicallanguage like BPMN can be used, even though theycannot handle the DSL itself. A transformation fromthe aforementioned banking DSL to BPMN might, forexample, 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-specific models are an important componentof model-driven development (MDD). The integra-tion of DSL and transformation combines some ad-vantages of general-purpose and domain-specific lan-
fort and cost, not least because they consist of sev-eral parts: They have an abstract syntax describingthe structure of their domain in terms of conceptsand their relationships. One or more concrete syn-taxes define 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 efficient. As motivated above, DSLsshould provide transformations to lower-level model-ing or programming languages, taking into accountthe semantics of both, DSL and target language. De-veloping these model transformations from scratch isnot a trivial task, either.
An efficient and simple approach to creatingdomain-specific PMLs with all their componentswould decrease the initial investment needed to setup the DSL. This paper presents our DSL Frame-work for Business Process Modeling (DSLs4BPM),from which domain-specific PMLs can be derived in astraightforward way. The framework consists of a ba-sic language and a transformation to BPMN 2. Theframework language provides elements common toprocess modeling languages and means for quicklyadapting the framework language to a business do-main. New, domain-specific concepts are added tothe framework when designing a domain-specific lan-guage. The transformation to BPMN 2 that comple-ments the language maps the language elements ofthe framework to corresponding concepts in BPMN 2.The transformation provided by the framework isadapted concurrently with the language. Thus, a DSLand 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 efficient 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 inthe research literature about reusing and modulariz-ing DSLs (Spinellis, 2001; Krahn et al., 2008; Voel-ter, 2010). Hence, our paper also demonstrates on amore general level how a language can be designedwith reuse and adaptability in mind by offering ex-tension points for extending language concepts andtransformation rules in parallel. It also elaborates onthe support for these means in the well-known andmature Eclipse Modeling Framework (EMF, (Stein-berg et al., 2009)), proving that modular DSLs can bebuilt 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-specific PMLs as well as generalliterature on reusable DSL design. It is followed byan introduction into process modeling, both from ageneral (BPMN 2) and from a domain-specific view-point (PICTURE). Both languages are prerequisitesfor the following sections. Section 4 describes thegeneral design of DSLs4BPM. The language part ofthe framework is presented in section 5, section 6 out-lines the transformation. Section 7 gives some detailsregarding the implementation and describes how tocreate derived DSLs by adapting the framework. Wediscuss and evaluate our framework in Section 8. Thepaper concludes with a summary and an outlook.
2 RELATED WORK
Research and praxis have proposed and evaluated sev-eral general-purpose PMLs. Besides BPMN, coveredin the next section, the most prominent of these areActivity Diagrams from the Unified Modeling Lan-guage (UML, (Object Management Group, 2010)),studied in (Dumas and ter Hofstede, 2001), andthe 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 anexample of a domain-specific PML. The focus of ourwork, however, does not lie on a single modeling lan-guage, but on creating DSLs for process modeling inan efficient manner and on combining these with cor-responding transformations.
Creating domain-specific PMLs efficiently is alsothe focus of jABC (Steffen et al., 2007) and its pre-decessors (Steffen and Margaria, 1999; Margaria andSteffen, 2004). jABC employs a building block-basedapproach to the model-driven development of ser-vices and applications, similar to DSLs4BPM. Exe-cutable process models are composed from so calledService Independent Building Blocks (SIB). A SIBcorresponds to a Java class with execution code, sothat models are directly executable or can be trans-formed to application code. As our approach insteadtargets BPMN 2, it provides a higher abstraction leveland supports a stepwise model-driven development,while retaining executability through the respectivefeatures of BPMN. jABC is a self-contained frame-work, whereas the process modeling language frame-work presented in this paper is implemented on top ofstandard modeling technologies (EMF), enabling itsintegration into larger MDD projects.
Brahe and Østerbye use UML activity diagramsand the profiling mechanism of UML to facilitate thedefinition of domain-specific PMLs (Brahe and Øster-
bye, 2006). Their tool generates UML profiles forindividual domains. Profiles allow the specializationof generic UML constructs and are an example of anadaptation mechanism in general-purpose modelinglanguages. BPMN 2 offers a similar extensibility con-cept. DSLs4BPM does not make use of this approachto adaptation in order to avoid the overhead and sub-optimal domain representation of a general-purposelanguage. Instead, the framework language providesa minimal set of common concepts and has to be ex-tended for specific domains, which ensures flexibil-ity and expressiveness. In contrast to our framework,Brahe and Østerbye do not consider model transfor-mations for their DSLs.
DSLs4BPM uses modularization concepts forDSLs proposed in the literature. Spinellis identi-fies recurring patterns in the development of tex-tual DSLs, of which some describe approaches toreuse (Spinellis, 2001). Our framework can be seen asan application of the extension pattern, because newelements are added to an existing language. In ourframework, however, extensions only take place atparticular points (Section 4). These extension pointsprovide some guidance to language developers, whichis not considered by the pattern.
Volter identifies several modularization conceptsavailable 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. Otherconcepts available in MPS like embedding of lan-guages are not needed in our framework. Our frame-work does not use JetBrains MPS but EMF, whichprovides less modularization concepts, and offers theremaining concepts less prominently and less easilyaccessible. However, as shown by our implementa-tion, EMF’s capabilities regarding DSL modulariza-tion are sufficient for creating a powerful frameworkfor the efficient creation of process modeling DSLs.
3 PROCESS MODELING
3.1 General-purpose: BPMN 2
The Object Management Group’s (OMG) specifica-tion Business Process Model and Notation (ObjectManagement Group, 2011) describes a PML that iswidely used and supports analysis and execution ofbusiness processes. Version 2.0 introduced a com-plete metamodel not available in previous versionsand enhanced the support for executable models.
Figure 1: Example model of a BPMN process.
Figure 2: BPMN metamodel (simplified excerpt).
Tools like Activiti1 can directly execute processesmodeled in BPMN 2 by managing the workflow ofprocesses and by orchestrating services. Due to itspopularity and good tool support, BPMN is the tar-get of our framework’s transformation. To introducethe concepts that are important for the transformation,this section gives a short overview of BPMN 2.
The example of figure 1 highlights important ele-ments of BPMN. It depicts a Process, which forms acentral model element of BPMN. It is a graph of socalled Flow Nodes connected by directed SequenceFlow edges. BPMN provides several types of flownodes, including Task, Gateway and Event. Hierar-chical nesting is supported by the concept of Subpro-cesses. Tasks represent units of work and are providedin different specializations to accommodate differentkinds of activities, for example User Tasks or ServiceTasks. Gateways are used to split the control flow of aprocess into parallel or exclusive branches as well asto merge such branches. Events symbolize that a pro-cess either triggers some incident (Throw Event) orwaits 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’smetamodel (figure 2), flow nodes and sequence floware subsumed under the term Flow Element. A pro-cess is a collection of flow elements and is performedwithin an organization.
A business process is made up of several suchBPMN processes, each representing the work carriedout within one organization, called Participant in thiscontext. A Pool is the graphical representation of aparticipant in a BPMN diagram and contains the vi-sual depiction of the participant’s process. A set ofinteracting processes forms a Collaboration. Mes-sage Flow symbolizes the exchange of informationbetween two different processes.
As BPMN is domain-independent and has a rathertechnical appeal, it is not an appropriate source modelfor MDD. Recker et al. analyze the modeling processwith BPMN (Recker et al., 2010; Recker, 2010). Theyfind BPMN to be complex and in some part confusingfor modelers. Deficiencies of the language includeambiguous and redundant elements, as well as lack ofsupport for business rules and process decomposition.However, these mainly impact the modeling process.As described before, BPMN is useful as the techni-cal specification of a process. Our approach rendersdirect modeling in BPMN, which was found to bea non-trivial task, unnecessary, but provides BPMNmodels via a transformation.
3.2 Domain-specific: PICTURE
While there are several general-purpose PMLs, indi-vidual DSLs have not yet surfaced as prominently inprocess modeling as they have in other areas. Thismight be due to the effort necessary for developingsuch a DSL. However, as the discussion above andsimilar approaches from related work highlight, theusage of DSLs could enhance quality of process mod-els. PICTURE, a DSL for business processes in pub-lic administration (Becker et al., 2007), demonstratesthe general viability of DSLs for process modeling. Itwas developed to efficiently model the process land-scape of public administrations and was subsequentlytransferred 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 controlflow. Typical activities in public administration orbanking, respectively, are available as building blocksto describe the individual steps of a process in a con-densed manner. As the DSL furthermore does notfeature redundant or ambiguous elements, a modelerwith experience in public administration or bankingcan efficiently model processes with PICTURE.
In summary, PICTURE allows for creating con-cise process models that are nevertheless expressiveand include all information relevant for their respec-tive purpose. PICTURE has been used and evalu-
Figure 3: Overview of framework (À+Á) and an extensionfor 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 aredomain-independent. As PICTURE has been suc-cessfully transferred to other domains, it is a viablebasis for the framework language. PICTURE mod-els for public administrations have been successfullytransformed to BPMN (Heitkoetter, 2011). This sug-gests that it will also be possible to transform modelsbased on a framework language that has been derivedand generalized from PICTURE’s structural parts.
4 DESIGN OF FRAMEWORK
Figure 3 gives an overview of our framework for theintegrated creation of process modeling DSLs andtransformations. DSLs4BPM consists of a genericPML (À in figure 3) and a transformation (Á) map-ping the generic concepts to BPMN 2 (Ä). Languageand transformation provide the basic structure and areexplicitly designed to be extended. Domain-specificlanguages can be derived from the framework by ex-tending the generic language at predefined extensionpoints with domain-specific constructs (Â). At thesame time, the transformation should be adapted tothe new language elements and their semantics byoverloading specified rules (Ã). The new rules shouldtransform the domain-specific constructs into corre-sponding elements from BPMN. They can also adaptthe behavior of the general transformation where nec-essary. These partial transformations are seamlesslyintegrated 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 identifiable and enumer-able. These typical activities, each consisting of sev-eral steps, have a meaning for domain experts and
are thus possible elements of an expressive DSL. Thealready mentioned formal assessment in banking isan example of such a typical activity. Besides theseindividual activities, differing from domain to do-main, process models mainly feature similar elementsacross domains, for example various kinds of controlflow and a hierarchical structure, that can be general-ized and extracted into a generic language.
Hence, the framework is responsible for commonconcepts of structured processes, while the individ-ual, derived DSLs handle domain-specific concepts,for example from banking, insurance or public admin-istration. This allows for a less complex creation ofbusiness 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 aimsto overcome the gap between expressive DSL modelsand 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 flow in termsof sequences, variations and communication. More-over, organizational aspects are considered. The mainextension point offered by the general framework isthe metamodel element Process Building Block. Itis intended to be subclassed by derived DSLs. Eachsubtype should correspond to a typical, potentiallycomplex, but clearly delimitable activity of that do-main. The framework’s core transformation containsa placeholder rule for building blocks. Derivationsshould provide a suitable mapping for their specificsubtypes that replaces or augments the default behav-ior to ensure an adequate transformation. Hence, theadditions to our framework made by derived DSLsand their transformations take place at predefinedpoints by means of subclassing. This is a less gen-eral, but more accessible notion of extensibility thanthe analogous pattern for DSLs in (Spinellis, 2001),which covers arbitrary additions. The coupling ofDSL extension with adaptation of a transformationis also special to our approach. Suchlike extensionpoints allow a better semantic integration of new typesvia the transformation.
5 FRAMEWORK LANGUAGE
The framework language has been adapted from PIC-TURE by generalizing concepts and focusing ondomain-neutral aspects. Since the general align-ment and structure of PICTURE have been preserved,DSLs4BPM inherits the benefits of that well-testedDSL. Modeling of structured processes is easier and
Figure 4: Metamodel of framework language (excerpt) withextension points.
more efficient due to a lower complexity of thelanguage. Models built with a DSL derived fromDSLs4BPM are concise, expressive, and easy to un-derstand. The easy and understandable syntax isachieved by focusing on processes that are at leastmoderately structured and for the most part linear.The number of options available to express a conceptand by it the modeler’s freedom is intentionally re-stricted in order to reduce variability. In the follow-ing, the domain-independent framework language isdescribed along with its metamodel (figure 4) and ex-tension points for derived DSLs. Figure 5 displays anexample model in a derived DSL that resembles theoriginal 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 constraintsenforce the absence of cycles, so that a process isa connected, directed acyclic graph of subprocesses.Roughly speaking, a subprocess is a linear sequenceof Process Building Blocks. These blocks will gen-erally be instances of domain-specific subtypes. Thedomain-specific building blocks themselves can en-capsulate complex semantics, but on the subprocesslevel they are seen, in principle, as executed sequen-tially with their inner semantics hidden. The modelerchooses from the set of building block types availablein the respective DSL and aligns instances in the or-der they appear in the process flow. Building blockshave attributes, e.g., name, which must or can be seton instances. Domain-specific building blocks willdefine their own attributes as needed. Through theseattributes, instances can match their appearance in theprocess at hand and represent the respective step ofthe process more precisely. This simple way of ar-
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 linearlyconsiderably simplifies modeling. A large part ofprocess complexity is handled by the domain-specificbuilding blocks, which nevertheless are intuitively ac-cessible to the domain-experienced modeler, becausethey stand for known activities of the domain.
Some subprocesses require, however, the possibil-ity to model variations in the sequence of buildingblocks, like skipped or additional blocks or a differ-ent order of execution depending on certain condi-tions. In the example of figure 5, the second vari-ant of subprocess D replaces the Create Documentinstance of variant 1 with an Inquiry followed by aReceive Document building block. To accommodatethese needs, the framework language uses the conceptof subprocess variants. Actually, the way of model-ing described above takes place entirely on the variantlevel. Each variant is a complete and separate linearsequence of building blocks. An instance of a build-ing block including its attribute values can appear inone or more variants and is shared among the vari-ants of a subprocess, enabling the reuse of parts ofthe subprocess. In figure 5, both variants contain thesame Formal Assessment instance (a) and the samePrint Document instance (e).
A typical workflow when modeling the course ofa subprocess is to first create the main variant repre-senting the normal case, which is then copied to a newvariant and modified wherever the respective alterna-tive differs from the original. The modeler is able tomodel every distinct case separately without influenc-ing other cases. If the process flow has only a moder-ate amount of variation, this way of modeling provesto be very efficient (Becker et al., 2007). Addition-ally, the resulting models provide a high readability,as differences are clearly separated. The first and lastbuilding block must be identical across all variants ofa subprocess. This constraint makes models easier tounderstand, guarantees strictly defined semantics andsimplifies the transformation.
The underlying metamodel of the framework lan-guage (figure 4) incorporates the previous explana-
tions with an occurrence concept. Variants as wellas building block instances are stored at subprocesslevel, so that blocks can be shared among variants oftheir subprocess. Each variant contains a collectionof building block occurrences referencing the build-ing blocks that are present in the variant. A linearpredecessor-successor-relationship defines the orderof occurrences separately for each variant. The or-ganizational view of the process is incorporated by ageneric organizational element. This is another exten-sion point for a derived DSL, as organizational struc-tures will be domain-specific. Process, subprocessand building block specify the organization in chargeof them by a reference to this organizational super-type. Resources and data can be attributed similarlyto further describe building block instances.
6 TRANSFORMATION TOBPMN 2
The transformation to BPMN 2 aims to generate ex-ecutable models. It thus enables or facilitates theimplementation of supporting systems. The gener-ated BPMN models explicitly represent both the com-plex activities embodied in domain-specific build-ing blocks and the control flow implicitly existing inframework models. The transformation is an inherentpart of the framework and a complete mapping of theframework language. Derived DSLs adapt the trans-formation by supplying custom transformation rulesfor their own elements.
The framework’s generic transformation toBPMN 2 is based on a previous domain-specifictransformation from PICTURE to BPMN 2(Heitkoetter, 2011). That transformation wastied to the domain of public administration, whilethe focus here lies on the domain-neutral conceptsand their generic mapping to BPMN 2. The rulesfrom the original transformation that are concernedwith domain-neutral structural concepts also applyto the framework transformation. The followinggives a high-level overview of the transformation andotherwise focuses on the newly introduced extensionpoints and their integration into the transforma-tion. For more details and reasoning regarding thestructural rules please refer to (Heitkoetter, 2011).
A process of the framework language is mappedto 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 theirbuilding block instances. Every building block in-
stance is transformed only once, irrespective of thenumber 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. Thetransformation connects the representations of build-ing blocks of a subprocess as determined by their oc-currences in variants, using sequence flow and, if nec-essary, exclusive gateways to model the process flow.Through these transformation rules, a framework sub-process is represented in BPMN as a connected graphof representations for its building blocks. The trans-formation connects these individual graphs accordingto the connections between subprocesses, generatingsequence or message flow edges, parallel gateways,and message events as necessary.
The generic transformation provided by theframework transforms a building block to a singletask. Building block subtypes of derived DSLs can bemapped to arbitrary graphs of flow elements. The coretransformation is prepared to handle these more com-plex representations. It only expects that the BPMNrepresentation of a building block is a collection offlow elements (flow nodes and sequence flow) withone entry and one exit point. These restrictions en-able the transformation to integrate any representa-tion conforming to this basic skeleton into the BPMNprocess. Besides the default generic task, a buildingblock can thus be mapped to a specific type of task(e.g., User Task or Service Task), to an event, to asubprocess which in turn contains a connected graphof flow nodes, or directly to such a flow graph. Therestriction to flow graphs with unique source and sinkis due to the linear nature of variants. The executionof a building block can nevertheless influence the pro-cess flow because it modifies the process state.
7 IMPLEMENTATION
The implementation of DSLs4BPM is based on theEclipse Platform2 and uses the Eclipse ModelingFramework (Steinberg et al., 2009), which providesmeans to define modeling languages and handlesmodels in these languages. The metamodel of theframework language is described with EMF’s Ecorelanguage. An implementation of BPMN 2’s meta-model with EMF is available through an Eclipseproject3. The model-to-model transformation is writ-ten in the Operational Mapping language of OMG’sQuery/View/Transformation standard (Object Man-
agement Group, 2008), of which an EMF-based im-plementation is available in the Eclipse project QVTOperational4 (QVTO).
All elements of the framework language from sec-tion 5 have been implemented in Ecore, including thegeneric type Process Building Block. EMF’s EClasstype, 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 modelwith the domain-specific building block types as sub-classes of the generic building block type from theframework metamodel. These subclasses can havetheir own attributes and references. Models built inthe derived DSL resort to the structural elements fromthe framework language and to the individual buildingblocks from the DSL.
The core transformation included in DSLs4BPMtakes a model written in the framework language asinput and outputs a BPMN model that complies withBPMN 2’s metamodel and semantics. It implementsthe transformation rules of section 6, which deal withelements from the framework language. Each coretransformation rule creates all BPMN elements thatmake up the representation of the framework elementhandled by the rule, including helper elements andconnections, and calls the rules for child elements.The additional rules for a derived DSL have to be de-fined 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 : : t ransformPBB ( )2 : C o l l e c t i o n ( FlowElement ) {3 var r e s u l t : L i s t ( FlowElement ) := L i s t {} ;4 r e s u l t += s e l f . map toFlowGraph ( ) ;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 s6 / / c r e a t e gateway , i f n e c e s s a r y7 re turn 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 : : toFlowGraph ( )
10 : L i s t ( FlowElement ) {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 re turn 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 abuilding block and integrating it into the process(lines 1–8). The actual mapping of the buildingblock to a flow graph as described in section 6is expected to be performed by toFlowGraph (9–
12). The core transformation resorts to the queryconnectorIncoming to determine the entry point ofthe representation when connecting it (13–16). Ananalog query exists for the exit point. In case of thegeneric building block, both of these methods returnthe single task created by toFlowGraph.
In order to represent each domain-specific ac-tivity accurately in BPMN, tailored mappings fordomain-specific 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, themapping toFlowGraph and both connector querieshave to be overridden for each building block sub-type that needs a specific mapping, in this exampleSpecialPBB. The mapping operation creates the flownodes and sequence flow edges that make up the spe-cific representation and returns them as a collectionof flow elements (4–8). It can resort to the valuesof attributes defined for the subtype or to configura-tion parameters in order to further tailor the mapping,which thus does not have to be static. For example,it could use a project-specific parameter as the ad-dress of a Web service in a Service Task or modifythe BPMN representation of a building block instanceaccording to the instance’s attribute values. The con-nector queries must return those flow nodes out of theflow 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 incorporatethe elements of the adapted representation into the re-sult model and create connections to the appropriateelements. In addition to this general mechanism, theframework 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 dsl2bpmn2 ( in s r c : d s l ,2 out t r g t : bpmn2 )3 ex tends t r a n s f o r m a t i o n framework2bpmn2 ;4 mapping Specia lPBB : : toFlowGraph ( )5 : L i s t ( FlowElement ) {6 r e s u l t−>add ( s e l f . map toTaskOne ( ) ) ;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 graph8 }9 query Specia lPBB : : c o n n e c t o r I n c o m i n g ( ) : FlowNode{
10 re turn s e l f . map toTaskOne ( )11 }
Besides the extended mappings, nothing has to bedefined for an individual DSL, as the framework al-ready defines most of the transformation. If neces-sary, a modification of core transformation rules is
possible via QVTO. The extended transformation isdefined 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 thusenable an easy and straightforward way to adapt theframework’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, westudy the conceptual advantages and contributions.We also highlight potential areas for improvement.
The savings that can be expected with our resultscan be approximated by looking at the source codeof our framework and typical extensions compared tostandalone implementation of DSLs. The frameworklanguage consists of 16 classes with just over 50 dis-tinct features. The basic transformation to BPMN 2included in the framework has been implemented inapproximately 650 logical lines of code of QVTO.As this code transforms the basic process structureand control flow, nearly all of it would also be re-quired in a standalone implementation that does notuse the framework. The overhead of the frameworktransformation consists of statements due to provi-sions for adaptation. These lines, which would not beneeded in a single, standalone transformation, amountto less than five percent of the transformation’s sourcecode. Regarding derived languages, only one addi-tional class due to peculiarities of EMF is needed in aderived DSL besides the specific concepts introducedby that DSL, so that the overhead is minimal. Withrespect to an extended transformation, each new con-cept that has to be transformed to BPMN requiresa corresponding adapted transformation rule. Eachof these adaptations consists of as many statementsas needed to generate the particular BPMN represen-tation. These mostly perform simple, but laboriouswork to build up the corresponding flow graph andwould be needed in either case, so that there are only0-3 lines of overhead per concept, depending on thecomplexity.
In summary, DSLs4BPM introduces only a smallamount of overhead, while relieving DSLs of the mostcomplex parts of the transformation, namely the rep-resentation of structure and of control flow. Thisgreatly reduces the development effort for implement-ing individual DSLs, which mainly does not extendbeyond a straightforward implementation of conceptsand mappings that have been identified during the de-
sign of the DSL. The expected savings have been con-firmed in two case studies with DSLs for public ad-ministration and for banking, respectively.
Our framework suggests a streamlined adaptationprocess for deriving a DSL in combination with atransformation to BPMN 2. The design of the DSLrequires the identification of domain concepts thatshould be added to the framework language, mainlyas new building block types. For each of these newelements, relevant attributes have to be identified, aswell as its mapping to BPMN. In case of buildingblocks, the latter should be described in the form ofa BPMN subgraph that represents the typical activ-ities behind this building block type. Currently, theimplementation has to be done manually with helpprovided by the respective Eclipse tools. In princi-ple, large parts of the adaptation process followingthe conceptual design of a DSL can be supported bya wizard and automated. The wizard would have togather the aforementioned information from the lan-guage designer, i.e., the list of new concepts and theirrepresentation as a BPMN graph. For the latter, thewizard could resort to a BPMN diagram tool. Basedon the gathered information, the wizard would createthe derived DSL and the source code of an extensionof the transformation in QVTO5. Only a relativelysmall amount of additional work would be neededto adapt the automatically generated transformationto special requirements, for example if attribute val-ues influence the BPMN representation. Hence, ourframework opens up even further improvements forcreating DSLs, besides the already simplified processof DSL design and implementation. Future work willinspect this direction.
As to the trade-off between reuse potential anddomain specificity, DSLs4BPM provides commonstructural elements and commissions derived DSLs toprovide individual building block types representingtypical domain-specific activities. This separation re-duces the development effort while enabling expres-sive models. Transforming the concise and domain-specific process models to BPMN 2 yields advan-tages when analyzing or implementing processes.Due to the individual transformation rules that ex-press domain-specific complex activities, the gener-ated BPMN 2 models can exhibit a high level of detailsuitable for service orchestration or workflow man-agement. Therefore, using the framework allows fora valuable combination of expressive DSL modelsand executable BPMN models. The fact that adap-tation takes place at predefined and documented ex-tension points simplifies the derivation of DSLs from
5The 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 andreusable modeling languages. Thus, using the matureEMF environment also enables more complex sce-narios for DSL creation and reuse than simply defin-ing each language from scratch. While specific sce-narios might need the more advanced modularizationtechniques for DSL reuse described in the literatureand available in other language development envi-ronments, the extensibility approach employed whiledesigning the framework is sufficient on its own forreusing common parts. This is especially importantand helpful because most environments for creatingDSLs and model transformations offer some kind ofextension mechanism.
In contrast to approaches that focus on DSL reuse,DSLs4BPM has an integrated, model-driven perspec-tive and includes transformations to less abstract butwidely-used languages as an inherent part. A DSLalone 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 analysisor implementation, customized tools are needed. Dueto the specific nature of a DSL, these are most oftennot available and developing them would not be cost-efficient. Through the readily available transforma-tion to BPMN, DSLs implemented within our frame-work can almost immediately profit 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 efficient creation ofdomain-specific PMLs by reusing common, genericparts of a compact language. Thus, the frameworkmakes it easier to realize the benefits associated withusing an optimally adjusted DSL for process model-ing. As a particular focus lies on model-driven de-velopment, the framework is complemented with anadaptable transformation to BPMN 2. By adapta-tion, the transformation can express the semantics ofdomain-specific elements. Implementing the frame-work based on EMF has demonstrated the viability ofthat 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 providinga wizard, and for modeling with the framework. Atthe moment, tree-based editors generated by EMF areused during modeling. A more meaningful and ex-tendable concrete syntax is needed. Our approach
does not depend on any kind of concrete syntax, sothat the introduction of a notation will be straightfor-ward, even more so as the framework language lendsitself to a graphical notation. The wizard mentionedabove could also help in this regard by creating agraphical editor for a DSL based on a generic edi-tor. Furthermore, it might be worthwhile to explore ifthe general approach taken in this paper—creating aframework 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 Rackers, M.(2007). Local, participative process modelling - thePICTURE-approach. In Proc. of the 1st InternationalWorkshop on Management of Business Processes inGovernment (BPMGOV).
Becker, J., Breuker, D., Pfeiffer, D., and Rackers, M.(2009a). Constructing comparable business processmodels with domain specific languages - an empiricalevaluation. 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 thebanking 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: Defining domain specific modeling languages byuse of UML profiles. In Model Driven Architecture –Foundations and Applications, pages 241–255.
Dumas, M. and ter Hofstede, A. (2001). UML activity dia-grams as a workflow specification language. In UML2001 — The Unified Modeling Language. ModelingLanguages, Concepts, and Tools, pages 76–90.
Heitkoetter, H. (2011). Transforming PICTURE to BPMN2.0 as part of the model-driven development of elec-tronic government systems. In Proc. of the 44thHawaii International Conference on System Sciences(HICSS 2011).
Karow, M., Pfeiffer, D., and Rackers, 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 Volkel, S. (2008). MontiCore:Modular development of textual domain specific 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 forTechnology Transfer, 5(2-3):107–123.
Matzner, M., Voigt, M., Alexandrini, F., Araujo, T. S., andBecker, J. (2009). Process modelling in brazilian pub-lic administrations: The domain-specific PICTURE
approach. In 15th Americas Conference on Informa-tion Systems (AMCIS).
Mernik, M., Heering, J., and Sloane, A. M. (2005). Whenand how to develop domain-specific languages. ACMComputing Surveys, 37(4):316–344.
OASIS Standard (2007). Web Services Business ProcessExecution Language Version 2.0.
Object Management Group (2008). Meta Object Facility(MOF) 2.0 Query/View/Transformation specification.
Object Management Group (2010). UML 2.3 superstructurespecification.
Object Management Group (2011). Business ProcessModel and Notation 2.0 specification.
Recker, J. (2010). Opportunities and constraints: the currentstruggle with BPMN. Business Process ManagementJournal, 16(1):181–201.
Recker, J., Indulska, M., Rosemann, M., and Green, P.(2010). The ontological deficiencies of process mod-eling in practice. European Journal of InformationSystems, 19(5):501–525.
Recker, J. C., Rosemann, M., Indulska, M., and Green, P.(2009). Business process modeling : a comparativeanalysis. Journal of the Association for InformationSystems, 10(4):333–363.
Spinellis, D. (2001). Notable design patterns for domain-specific 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., Jorges, S., andKubczak, C. (2007). Model-driven development withthe jABC. In Proc. of the 2nd International Haifa Ver-ification Conference (HVC).
Steinberg, D., Budinsky, F., Paternostro, M., and Merks,E. (2009). EMF: Eclipse Modeling Framework, 2ndEdition. Addison-Wesley Longman.
van Deursen, A., Klint, P., and Visser, J. (2000). Domain-specific languages: An annotated bibliography. ACMSIGPLAN Notices, 35(6):26–36.
Voelter, M. (2010). Implementing feature variability formodels and code with projectional language work-benches. In Proceedings of the 2nd InternationalWorkshop on Feature-Oriented Software Develop-ment, pages 41–48.
