Behind the Scenes of the BPMN Extension Mechanism

Principles, Problems and Options for Improvement

Richard Braun

TU Dresden, Chair for Wirtschaftsinformatik, esp. System Development, 01062 Dresden, Germany

Keywords:

Business Process Modeling, Language Extension, Enterprise Modeling, Meta Modeling, Meta Model

Extension, MOF, BPMN.

Abstract:

The Business Process Model and Notation (BPMN) is a standard for modeling business processes that is

widely used and accepted both in academia and industry due to its well-deﬁned meta model, its large set

of concepts and its extensibility. BPMN is one of very few modeling languages that provides an integrated

extension mechanism. However, the mechanism is not often implemented in research articles or in professional

practice. We suppose, that both syntactical and methodical aspects within the BPMN extension mechanism

may cause misunderstandings and uncertainty regarding its implementation. Therefore, we conducted an in-

depth analysis of the extension mechanism in order to rationally ﬁgure out problematic aspects. These aspects

are consolidated and compared to two existing BPMN extension methods. Based on that, a range of further

research topics is ﬁnally derived.

1 INTRODUCTION AND

MOTIVATION

The Business Process Model and Notation (BPMN) is

a very common modeling language for business pro-

cesses and widely used in professional practice (Chi-

nosi and Trombetta, 2012). BPMN is deﬁned by the

Object Management Group (OMG) and additionally

speciﬁed as ISO standard (OMG, 2011b). The mod-

eling language provides a set of generic business pro-

cess elements, independent from a speciﬁc domain.

However, both in academia and industry, it is often

necessary to extend BPMN with custom concepts in

order to represent characteristics of a particular verti-

cal domain (e.g., health care or quality management).

Thus, it remains possible to both use the beneﬁts of

BPMN as a general purpose process modeling lan-

guage (e.g., standardization, tool support and aware-

ness) and adapt the language to speciﬁc requirements

of a problem or a domain. BPMN is one of very

few modeling languages that provides a set of generic

extension elements within its meta model (see Fig-

ure 1). That extension mechanism is intended to en-

able the deﬁnition of extensions and ensure validity of

the BPMN core (OMG, 2011b).

However, only very few BPMN extensions base

on the mechanism, what hampers model interoper-

ability, comparability and replicability (Braun and Es-

swein, 2014). We assume, that both missing me-

thodical support and some syntactical obscurities lead

to these deﬁciencies. We therefore conducted an in-

depth analysis of the BPMN speciﬁcation in order to

carve out problematic issues. Thus, we aim to foster

a discussion within academia regarding to a potential

improvement of the BPMN extension mechanism that

could ﬁnally lead to improvements in practice (e.g.,

better BPMN tool support for extensibility). This re-

search paper is understood as a research-in-progress

article, since we focus the current state of the art and

indicate some ﬁrst points for improvement.

The structure of the article is as follows. Sec-

tion 2 provides an investigation of implicit extension

capabilities with BPMN. In detail, we looked for el-

ements that can be exploited for customization. Sec-

tion 3 presents the BPMN extension elements in de-

tail. While considering its elements, problematic as-

pects regarding to syntax and semantics are expli-

cated. The same procedure is applied to the extension

mechanism at all in Section 4. Afterwards, a table

of “problem notices” is presented and compared to

approaches from literature. Thus, a range of further

research topics is ﬁnally derived.

403

Braun R..

Behind the Scenes of the BPMN Extension Mechanism - Principles, Problems and Options for Improvement.

DOI: 10.5220/0005329904030410

In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 403-410

ISBN: 978-989-758-083-3

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

documentation

defini tion

Foundation

Base Element

id: String

extensionDefinitions

value

0..1

extensions

extensionAttribute

Definition

Foundation

ExtensionAttributeValue

extensionValues

Foundation

ExtensionDefinition

Infrastructures

Definitions

typeLanguage: String

exporterVersion: String

expressionLanguage:

String

targetNamespace: String

exporter: String

extensionAttributeDefinitions

Foundation

Documentation

text: String

textFormat: String

valueRef

0..1

Foundation

ExtensionAttributeDefinition

type: String

isReference: Boolean

Foundation

Extension

mustUnderstand: Boolean

CMOF

Element

Figure 1: Excerpt of the BPMN meta model containing all

relevant classes and relationships of the extension mecha-

nism.

2 IMPLICIT EXTENSIBILITY

Leveraging a modeling language for speciﬁc purposes

not always requires the deﬁnition of lightweight or

heavyweight extensions, since modeling languages

sometimes provide concepts that are intended for cus-

tom speciﬁcation. Thus, we ﬁrst consider such con-

cepts within BPMN in order to pose existing capabil-

ities beyond the extension mechanism. Sometimes,

it might be more favourable to use the following op-

tions instead of taking a sledgehammer to crack a nut

(extension mechanism).

2.1 Artifacts and External

Relationships

Artifacts are used to provide additional information

about a process. BPMN provides three Artifacts by

default: Groups, Text Annotations and Associations

(OMG, 2011a, p. 67). BPMN explicitly allows mod-

elers and modeling tools to add additional Artifacts

for speciﬁc purposes (OMG, 2011a, p. 28). This op-

portunity allows augmentation of the BPMN (Atkin-

son et al., 2013) in the sense of speciﬁc domain con-

cepts or constructs for operations on BPMN models

such as model transformations. As stated, new types

can be added to a BPMN diagram, if sequence ﬂow

rules and message ﬂow connection rules are respected

(OMG, 2011a, p. 66). From a language point of view,

rules and constraints of BPMN are not affected by this

simple extension option. Moreover, the deﬁnition of a

new information view of the languages is facilitated.

Additionally, BPMN allows the integration of “a new

shape representing a kind of Artifact” (OMG, 2011a,

p. 8).

Problem Notice 1. Despite the ﬂexibility of the Ar-

tifact approach, there are some unconsidered issues.

First, it remains unclear what level of complexity a

custom Artifact can have. This especially addresses

the issue of attributed Artifact types and relations be-

tween them. Actually, Artifacts are supposed to be

very simple objects getting their semantics primarily

from their assigned name. Second, it also remains

open, whether custom Artifacts should be integrated

on meta level (M2) or model level (M1). While the

ﬁrst one increases model exchangeability, the latter is

easier for integration within modeling tools.

BPMN also allows the integration of Artifacts and

“elements expressed in any other addressable domain

model” (OMG, 2011a, p. 62). This is enabled by

the External Relationship element which represents

associations between Artifacts an external model ele-

ments. This simple mapping mechanism is intended

to facilitate traceability, model derivation and model

integration (OMG, 2011a, p. 63).

In consequence, BPMN provides two basal proce-

dures for domain-speciﬁc adaptions: First, new Arti-

facts can be designed individually. Strictly speaking,

each custom Artifact also leads to a new variation of

the BPMN meta model since new Artifact types need

to be integrated. Thus, such an extension would lead

to a minor, element-wise specialization of the BPMN

meta model. However, this is not clearly explicated

by BPMN as we stated above. Second, the External

Relationship mechanisms provides the opportunity to

integrate BPMN models and models of other mod-

eling languages. Hence, the BPMN meta model re-

mains unmodiﬁed, but techniques like model weaving

need to be applied in order to realize model integra-

tion (Del Fabro and Valduriez, 2009).

2.2 Adapting the Concrete Syntax

Generally, BPMN is quite open for the customization

of the concrete syntax: “An extension SHALL NOT

change the speciﬁed shape of a deﬁned graphical el-

ement or marker (e.g., changing a square into a tri-

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

404

angle, or changing rounded corners into squared cor-

ners, etc.)” (OMG, 2011a, p. 8). Further, adaptions

of the concrete syntax can also be used for the ex-

plication of speciﬁc semantics: For instance, coloring

elements can emphasize some categories. It is also

allowed to add markers to elements in order to em-

phasize speciﬁc sub types. As stated above, Artifacts

can be layouted individually.

3 EXPLICIT EXTENSIBILITY

BPMN provides an extension by addition mechanism

that ensures the validity of the BPMN core elements

while specifying additional constructs (OMG, 2011a,

p. 44). Figure 1 depicts the relevant meta model ex-

cerpt. Due to the fact, that the majority of BPMN ex-

tensions is not designed in conformity to the BPMN

meta model (Braun and Esswein, 2014), we provide

an analysis of BPMN extension capabilities by ana-

lyzing both syntactical and semantical aspects of the

four BPMN extension classes in detail. We also con-

sider relevant consequences for XML based model in-

terchange. Based on a rational discourse, some prob-

lematic (or even not clearly deﬁned) aspects are stated

within problem notices. Finally, these statements are

summarized in a table and possible points for im-

provement will be suggested.

3.1 Extension

The element Extension binds and imports the entire

extension deﬁnition and its attributes to a BPMN

model deﬁnition. By doing so, all extension ele-

ments become accessible for BPMN elements (OMG,

2011b, p. 58). If the semantics of an Extension need

to be understood by a BPMN adopter in order to pro-

cess a BPMN model correctly, the mustUnderstood

attribute is set to true. Otherwise, the Extension re-

mains optional to BPMN deﬁnitions. AnyBPMN def-

inition can be associated to multiple Extensions. Fur-

ther, an Extension consists of exactly one Extension

Deﬁnition, that deﬁnes its actual content.

Semantics. The Extension class is only the outermost

deﬁnition layer, without any concrete domain-speciﬁc

information.

XML. On XML level, the reference to the Extension

Deﬁnition is simply represented by the QName type.

At this point, the XML speciﬁcation disappears from

the scope of BPMN and refers to an external XML

speciﬁcation.

3.2 Extension Deﬁnition

An Extension Deﬁnition is a named group of new at-

tributes that can be used by BPMN elements. An

Extension Deﬁnition is not inevitably a new element,

since it can also be intended as a single additional at-

tribute of a BPMN element. The only attribute of the

class is the name attribute that denotes the group. The

particular characteristics of the new element or at-

tribute are deﬁned by Extension Attribute Deﬁnitions.

A Base Element can reference an Extension Deﬁnition

multiple times. On the contrary, it is not intended to

specify, what speciﬁc BPMN element can access the

Extension Deﬁnition. Thus, actually all extensions are

accessible for all BPMN elements since each element

is a sub class of Base Element. Also, a navigation

from the Extension Deﬁnition to the Base Element is

not possible.

Semantics. Name and container of the designed ex-

tension. Due to the fact, that the Extension is asso-

ciated with exactly one Extension Deﬁnition, an ex-

tension actually can be seen as exactly one new ele-

ment in the sense of a concept having attributes or a

concept that only stands for an additional attribute of

some BPMN element (a differentiation is only possi-

ble in context of the application). This new element

then can be referencedby severalBPMN standard ele-

ments what emphasizes the additional character of the

extension mechanism. However, this provokes some

problems:

Problem Notice 2. Due to this constellation, it is

quite inconvenient to add complex extensions, since

it is necessary to ﬁrst design all Extension Deﬁni-

tions singularly and than add the relationships be-

tween them subsequently. Therefore, it remains un-

clear, whether an Extension Deﬁnition can also have

an Extension Attribute Deﬁnition that is typed by an-

other new Extension Deﬁnition. Actually, that should

be possible, since the type is speciﬁed as String. How-

ever, the speciﬁcation should make this more clearer,

because a domain extension with - for instance - a set

of ﬁve elements requires a preloading of all ﬁve Ex-

tension Deﬁnitions in order to make the correspond-

ing Extension Attribute Deﬁnitions available. More-

over, it would be better, to explicate the concep-

tual interrelations between the new elements in one

model. Currently, each of the exemplarily ﬁve ele-

ments would cause a particular extension model and

their conceptual interrelations would be barely ob-

vious. Further, it is currently not possible to depict

more complex relations between single extension ele-

ments such as aggregations or inheritances what ham-

pers expressiveness and the representation of domain

rules.

BehindtheScenesoftheBPMNExtensionMechanism-Principles,ProblemsandOptionsforImprovement

405

Problem Notice 3. In the current extension mecha-

nism, each BPMN element can access all Extension

Deﬁnitions, since all BPMN types are sub classes

of Base Element. This leads both to missing sep-

aration of concern and to semantic irregularities, as

also elements that are not intended to be related to an

Extension Deﬁnition, can be related to them techni-

cally. In order to avoid such situations, it needs to

be speciﬁed, to which element an Extension Deﬁni-

tion can be associated. This should also be consid-

ered on XML interchange level. Otherwise, the stated

under-speciﬁcation could lead to semantically incor-

rect models.

Problem Notice 4. In the current version, BPMN

does not make a conceptual difference between

element-wise extensions (in the sense of deﬁnable

classes with own attributes that can be referenced by

other classes) and attribute-wise extensions (in the

sense of adding some attributes to standard BPMN

classes). While this should be syntactically correct,

it might provoke some conceptual confusion whether

the deﬁnition of new elements is allowed at all.

XML. BPMN speciﬁcation states that this “type is

not applicable when the XML schema interchange is

used, since XSD Complex Types already satisfy this

requirement” (OMG, 2011b, p. 58). Hence, BPMN

excludes XML speciﬁcation of Extension Deﬁnitions

from its meta model and just refers to under-speciﬁed

XSD Complex Types. There is actually no deeper con-

trol of the extension structure (syntax) on XML level.

3.3 Extension Attribute Deﬁnitions

As stated above, the Extension Attribute Deﬁnition

class deﬁnes the actual characteristics of an extension.

An Extension Attribute Deﬁnition is speciﬁed by the

name and the type of the attribute. The corresponding

type must be given as string reference to the identiﬁer

of the corresponding class. The isReference attribute

indicates whether the attribute value is set directly or

by reference to the referred element.

Semantics. A list of attributes of a new element or

attribute.

XML. BPMN speciﬁcation states that “this type is

not applicable when the XML schema interchange is

used; since the XSD mechanisms for supporting Any-

Attribute and Any type already satisfy this require-

ment” (OMG, 2011b, p. 59). This statement also in-

dicates that the XML based deﬁnition of an exten-

sion is out of the syntactical scope of BPMN. More-

over, implementing the speciﬁcation depends totally

on the language engineer. In this case, it might be bet-

ter to keep it within some syntactical rules of BPMN

in order to avoid semantically incorrect models (see

above).

3.4 Extension Attribute Value

The Extension Attribute Values class can be used for

the speciﬁcation of concrete attribute values. If the

corresponding isReference attribute of the Extension

AttributeDeﬁnition is set of false, the attributevalueis

given directly. Otherwise, a reference to the targeted

class needs to be given (OMG, 2011b, p. 59). A spe-

ciﬁc meta model Element is addressed in both cases.

The stated Element class is one of the most generic

classes within the Complete Meta Object Facility

(CMOF) on level M3. On that meta meta model level,

Packages, Features and Classiﬁers (OMG, 2014) in-

herit from the Element class. Classiﬁers are speci-

ﬁed into Classes and Data Types. Thus, both com-

plex types (e.g., BPMN elements) and primitive data

types (e.g., Strings) can be referenced by Extension

Attribute Values.

Semantics. A list of typed attributes of a new ele-

ment.

Problem Statement 5. While understanding the se-

mantics of the Element reference, the syntax is not

accurate at this point, since the BPMN speciﬁcation

integrates an element that is speciﬁed on level M3

(within CMOF) and not on level M2 as BPMN is

(see Figure 2). In the current version, the extension

meta model violates the separation of abstraction lay-

ers (type instance relation). Also, BPMN does not

provide clear evidences on the relation between basic

concepts and the correspondingmeta meta level (M3).

Actually, each abstraction level is realized by type in-

stance relations. Nonetheless, this is quite clear for

the most classes (e.g., namespaces or associations), it

is confusing regarding to the extension classes, since

MOF already provides a basal extension mechanism

and we cannot detect any correspondence to that in

BPMN (OMG, 2014, p. 23).

3.5 Mechanism in General

As stated above, BPMN deﬁnes elements that should

facilitate the design of vertical or domain-speciﬁc ex-

tensions. By providing elements on meta level M2 the

instantiated extensions are actually located on model

level M1 due to the “instance of” relation. However,

an application of the extension requires another in-

stantiation step regarding to the creation of the actual

extension instances on level M1. This instantiation

sequence collides with the strict four layer architec-

ture of the OMG. Respectively, a new “intermediate

layer” is created, which contains the standard meta

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

406

extensionAttributeDefinitions

extensionValues

CMOF

Element

Foundation

Base Element

id: String

Abstraction Problem: CMOF::Element from Level M3

Foundation

Documentation

text: String

textFormat: String

valueRef

0..1

Foundation

ExtensionAttributeValue

value

0..1

extensions

extensionDefinitions

Foundation

ExtensionDefinition

Infrastructures

Definitions

exporter: String

exporterVersion: String

targetNamespace: String

expressionLanguage:

String

typeLanguage: String

Foundation

ExtensionAttributeDefinition

type: String

isReference: Boolean

Foundation

Extension

mustUnderstand: Boolean

documen t a t ion

definit ion

extension A t t ribute

Definition

Figure 2: Abstraction problem: The class CMOF::Element

originally comes from level M3, while all other classes are

from the BPMN deﬁnition on level M2.

model and its new extension meta model elements

(could be referred as “M1.5’, see Figure 3). Never-

theless, the BPMN mechanism is principally feasible,

its application should be clearly explained, since the

CMOF::Element relation speaks against this assump-

tion (see above).

If BPMN aims to provide an extension on level

M2, the problems are getting more severe, since

BPMN is deﬁned on level M2 and cannot provide any

mechanism of the level it is deﬁned on. Rather, there

either needs to be an application of MOF extension

capabilities in the form of clear instances or any kind

of overwriting of the M3 deﬁnitions regarding exten-

sibility.

Problem Notice 6. Currently, it is not clear whether

BPMN aims to provide an extension mechanism sim-

ilar to the lightweight UML proﬁle mechanism (M1)

or a heavyweight meta model extension (M2). Evi-

dences for both approaches can be found.

3.6 XML Serialization

As mentioned above, BPMN speciﬁcation reveals

deviations in regard of the XML interchange for-

mat. Generally, MOF speciﬁes the XMI metadata

interchange format in order to ensure serialized in-

teroperability (OMG, 2014). Also the instances of

MOF (meta models on level M2) should make use of

XMI. However, BPMN propagates a dedicated XML

schema what leads to various conceptual problems

(Stroppi et al., 2011, p. 2).

Problem Notice 7. The extension mechanism is not

very well included into the BPMN XML schema since

the deﬁnition of the extension is outsourced to a sepa-

rate XML schema without any further speciﬁcation of

its structure. Consequently, BPMN also states that if

XML schema interchange is used, both Extension At-

tribute Deﬁnition and Extension Attribute Deﬁnition

Value cannot be applied (see above). Rather, it is in-

tended to extend the concerning BPMN classes with

the XSD AnyAttribute and Any type. Thus, we ob-

serve also a break between the MOF based BPMN

meta model and its XSD based serialization! These

aspects could lead to uncertainty regarding to the ex-

change of extension data between two modeling tools,

for example.

4 METHODOLOGICAL ASPECTS

AND RELATED WORK

4.1 Methodological Aspects

Despite the fact that BPMN provides a well-deﬁned

extension interface, a procedure model for the

straightforwarddevelopmentof extensions is missing.

Problem Notice 8. BPMN does not provide any

methodological guidance. Especially, there is no sup-

port for the issue of comparing new domain-speciﬁc

elements with standard BPMN elements in order to

identify reasonable need for extension and ensure the

required check whether the elements do not contradict

the semantics of other BPMN elements.

Problem Notice 9. Besides to the customization of

the concrete syntax of single items, it remains open,

how the concrete syntax of extension elements should

be exchanged through BPMN Diagram Interchange

(OMG, 2014, p. 367). Also, there is no consideration

of new diagrams in the sense of views or presentations

based on extended elements.

4.2 Related Work

Only very few research articles address extensibility

of BPMN. In the following, the approaches of Stroppi

et al. (2011) as well as Braun and Schlieter (2014) are

discussed against the background of the stated issues.

BehindtheScenesoftheBPMNExtensionMechanism-Principles,ProblemsandOptionsforImprovement

407

Foundation

Extension

instance of

name = "Expacted Lifetime"

type = "Integer"

isReference = false

«Base Element»

Activity

Foundation

ExtensionDefinition

«Resource Type Value, Extension Attribute Value»

Production Machine

«Extension Definition»

Resource

M1.5

name = "Resource Type"

type = Resource Type Value

isReference = true

instance of

M1.5

«Extension Attribute Value, Resource Type Value»

Hardware

M 1

Foundation

ExtensionAttributeValue

M1.5

instance of

«Extension Attribute Definition»

Expacted Lifetime

M1.5

«Extension Attribute Definition»

Resource Type

Foundation

ExtensionAttributeDefinition

«Extension»

Resource Extension

«Activity»

Milling Work Piece

M 2

Abstraction Conflict: Sub Layer M1.5

M1.5

instance of

(M 1 .5)

«Resource Extension»

Resource Extension

instance of

«Resource»

Milling Machine

Expacted Lifetime = 10

Production Machine Type = "Production Machine"

Foundation

Base Element

Figure 3: A simple extension example yields that the instantiation of BPMN extension meta model elements leads to a de

facto sub layer (denoted “M1.5”) that causes irregularities from the perspective of meta model layers. The example depicts

the creation of a simple resource extension containing an element with two attributes.

4.2.1 Stroppi et al. (2011)

Stroppi et al. (2011) deﬁne a model-transformation

based procedure model for the methodical develop-

ment of valid BPMN extensions models. Their proce-

dure model consists of mainly three steps: First, the

domain is conceptualized by deﬁning a Conceptual

Domain Model of the Extension (CDME) as UML

class diagram. Second, the CDME is transformed into

a valid BPMN extension model (BPMN+X) by using

UML stereotypes and a set of transformation rules

for several model element constellations. Third, the

BPMN+X model its transformed into a XML Schema

Extension Deﬁnition Model, whereby the following

matchings are applied: Extension to xsd:schema, Ex-

tension Deﬁnition to xsd:group, Extension Attribute

Deﬁnition to xsd:complexTypeDeﬁnition and Exten-

sion Attribute Value to xsd:simpleTypeDeﬁnition. Ob-

viously, the approach of Stroppi et al. (2011) provides

a well-deﬁned and consistent approach that tackles

the problem of missing methodical support and XSD

generation. Nevertheless, we see some minor short-

comings (or better points for improvement) regarding

to this approach:

First, the authors state that a BPMN extension is

a direct instance of the BPMN meta model. As we

have already argued in Section 3.5, this is not the case

since the extension model is actually an instance of

the new meta model variant on level “M1.5”. Thus,

MOF

CMOF

Core

«merge»

Profiles

«merge»

Profile

AuxiliaryConstructs

Superstructure

«merge»

Basic

Constructs

Infrastructure Library

Abstractions

«merge»

«import»

EMOF

«merge»

Figure 4: Excerpt of the MOF that indicates that MOF does

not merge the Proﬁle package. Strictly speaking, it is con-

sequently not possible to apply the proﬁle mechanism.

an extension model is only an indirect instance of the

BPMN meta model. Stroppi et al. (2011) implic-

itly tackle this issue by adapting the proﬁle mecha-

nism from UML to the BPMN extension meta model,

what leads to the creation of a M2

proﬁle

model (in the

sense of the their BPMN+X model). Although, this

is a suitable technique, the application of the proﬁle

mechanism to either MOF or BPMN is actually not

permitted by the MOF speciﬁcation. The (not re-

ally obvious) reason is, that MOF does not import

or merge the Proﬁle package from Infrastructure Li-

brary (see Figure 4). Only the UML Superstructure

imports the Proﬁle package and is able to apply the

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

408

Problem Notice

Stroppi

et al. (2011)

Braun and

Schlieter

(2014)

Possible Improvements and

Further Research

Artifacts on M1 or M2?

−

• Clear statement in specification needed

Complex extension models

(! )

• Extending the method of Stroppi et al.

(2011) for specific relation types

• Perhaps, integration of OCL is helpful for

specific dependencies

No specification of the extended

Base Element sub class

(" )

• Update of the extension meta model or

explication of conditional statements (OCL)

for element specification

Clear distinction between element

extension and attribute extension

(" )

• Update of the extension meta model

Conflict of level abstraction

CMOF::Element

(! )

• Update of the extension meta model

Extension instantiation enforces

intermediate level (M1.5)

(! )

• Clear statement in specification needed

• Option 1: Profile mechanism according to

Stroppi et al. (2011) with MOF update

• Option 2: Changing level M3 / meta meta

model extension capabilities

Missing specification of extension

XML interchange

(! )

• Generic as well as sufficient specification of

a serialization format

Lack of methodological guidance

• Consideration of domain analysis

(preparation of extension design)

• Integrated meta model, adaption of

techniques from model comparison and

model transformation

• Formulation of extension guidelines/ patterns

Unclear interchange of concrete

extension syntax

−

• Generic techniques for concrete extension

syntax specification and exchange (re-use of

BPMN DI basics!)

" (solution proposed) ! (solution partially proposed) − (neither considered or solved)

Figure 5: Summary of the noticed problems and possible topics fur further investigation.

mechanism. In contrary, MOF provides only a basal,

element-wise “name value pair” extension opportu-

nity (OMG, 2014, p. 23).

Second, the method lacks in terms of a de-

tailed analysis and consideration of the domain since

it is an engineering driven approach that empha-

sizes stereotype deﬁnitions and transformation rules

(Stroppi et al., 2011). Besides, an extension of the

CDME model in terms of using further relation types

(e.g., navigable associations, aggregations or com-

pensations) should be considered in order to design

more complex domain models on a conceptual level.

Stroppi et al. (2011) present rules for the transforma-

tion of inheritances to basic associations by adding in-

herited attributes to the sub class. Similar rules need

to be deﬁned for further relation types that are needed

for expressive domain models.

4.2.2 Braun and Schlieter (2014)

Braun and Schlieter (2014) outline an integrated pro-

cedure model for the design of BPMN extensions

and extend the approach of Stroppi et al. (2011)

by the analysis of the domain and its conceptual-

ization. Therefore, the authors proclaim an initial

domain requirements analysis step in order to iden-

tify requirements of the general modeling approach.

Based on these requirements, a decision on the suit-

ability of BPMN is made. Afterwards a domain on-

tology should be designed in order to prepare the con-

ceptual domain model and set a base for the so-called

equivalence check. This check covers an examina-

tion of each required domain concept against standard

BPMN concepts and their semantics in order to de-

rive a rational decision whether a concept needs to

be added or not (Braun and Schlieter, 2014). How-

ever, the proposed method is still under research and

more detailed information on the semantical equiva-

lence check is necessary.

5 PROBLEM CONSOLIDATION

AND FURTHER RESEARCH

Figure 5 summarizes the analyzed problem state-

BehindtheScenesoftheBPMNExtensionMechanism-Principles,ProblemsandOptionsforImprovement

409

ments and compares each of them against the back-

ground stated in Section 4.2. Some assessments re-

garding the approach of Braun and Schlieter (2014)

were greyed out since the authors mostly re-use the

approach of Stroppi et al. (2011). Also, possible

points for improvement or aspects for further research

are given. These aspects should be understood as ﬁrst

inspirations for further investigation.

All in all, we see two main directions for improv-

ing the current struggle with BPMN extensions. The

ﬁrst one addresses revising and updating parts of the

BPMN meta model in order to remedy the examined

problems, obscurities and ambiguities. Consequently,

this would also require an review of the capabilities

of MOF regarding the proﬁle mechanism. However,

changing such standards is indeed very hard to im-

plement. Thus, the second option constitutes further

development as well as enhancement of the approach

of Stroppi et al. (2011) regarding to the mentioned

aspects. Beyond, also questions of meta model ver-

sion management and its respective instances need to

be considered in order to ensure reasonable BPMN

model comparison. Also, it seems to be promising to

examine possible consequences of BPMN extensions

relating to executable BPEL extensions (Kopp et al.,

2011).

ACKNOWLEDGEMENT

This research was funded by the German Research

Foundation (DFG) within the research project “SFB

Transregio 96”. The author is grateful for the funding

and the research opportunities.

REFERENCES

Atkinson, C., Gerbig, R., and Fritzsche, M. (2013). Model-

ing language extension in the enterprise systems do-

main. In 17th IEEE International Enterprise Dis-

tributed Object Computing Conference, pages 49–58.

Braun, R. and Esswein, W. (2014). Classiﬁcation of

domain-speciﬁc bpmn extensions. Lecture Notes of

Business Information Processing, 147:42–57.

Braun, R. and Schlieter, H. (2014). Requirements-based

development of bpmn extensions: The case of clinical

pathways. In IEEE 1st International Workshop on the

Interrelations between Requirements Engineering and

Business Process Management, pages 39–44.

Chinosi, M. and Trombetta, A. (2012). Bpmn: An intro-

duction to the standard. Computer Standards & Inter-

faces, 34(1):124–134.

Del Fabro, M. D. and Valduriez, P. (2009). Towards the

efﬁcient development of model transformations using

model weaving and matching transformations. Soft-

ware & Systems Modeling, 8(3):305–324.

Kopp, O., G¨orlach, K., Karastoyanova, D., Leymann, F.,

Reiter, M., Schumm, D., Sonntag, M., Strauch, S.,

Unger, T., Wieland, M., et al. (2011). A classiﬁcation

of bpel extensions. Journal of Systems Integration,

2(4):3–28.

OMG (2011a). Business Process Model and Notation, Ver-

sion 2.0.

OMG (2011b). Uniﬁed Modeling Language, Infrastructure,

Version 2.4.1. OMG.

OMG (2014). Meta Object Facility (MOF) Core Speciﬁca-

tion, Version 2.4.2.

Stroppi, L. J. R., Chiotti, O., and Villarreal, P. D. (2011).

Extending bpmn 2.0: Method and tool support. In

Business Process Model and Notation, pages 59–73.

Springer.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

410