A Generic Framework for Modifying and Extending Enterprise

Modeling Languages

Richard Braun and Werner Esswein

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

Keywords:

Meta Modeling, Extensibility, Enterprise Modeling, Language Dialects, Ad Hoc Modiﬁcation, BPMN.

Abstract:

Conceptual modeling languages are of great importance within information systems management. During

the last decade, a small set of commonly used enterprise modeling languages established and gained broad

acceptance in both academia and practice (e.g., BPMN). Due to their dissemination, these languages often

need to be extended or adapted for domain-speciﬁc or technical requirements. Since most modeling languages

provide rather poor extension mechanisms, it is necessary to modify a language meta model directly. However,

there is lack of integrated methodical support for these modiﬁcations. Within this position paper, we therefore

proclaim a generic framework for modifying enterprise modeling languages on the meta model level. The

framework is divided into the main parts of a modeling language (abstract syntax, concrete syntax, semantics)

and respective operations (add, remove, specify and redeﬁne).

1 INTRODUCTION AND

MOTIVATION

Enterprise Modeling Languages (EML) are of pri-

mary importance for conceptual and technical com-

plexity management within enterprises as they fa-

cilitate an integrated management of views, as-

pects and levels of abstraction (Frank, 1999; Frank,

2002; Braun and Winter, 2005). Examples for such

EMLs are BPMN (OMG, 2011a), ARIS (Scheer and

uttgens, 2000) or MEMO (Frank, 2002). Addi-

tionally, the more engineering-driven general-purpose

modeling language UML is frequently adapted in the

ﬁeld of enterprise modeling (Silingas and Butleris,

2009). The stated languages can largely be seen as

de facto standards due to their prevalence and ac-

ceptance both in academia and professional practice

. This level of dissemination implies several ben-

eﬁts such as a common understanding of syntactical

rules and semantical interpretations. It can be also

assumed, that these languages are subject to quality

management and evolvement over time. However,

there are also some challenges: As it is well known

from other ﬁelds (e.g., ERP management), the emer-

gence of commonly used artifacts leads often to an

increasing demand for individual customization in or-

Indeed, BPMN and UML are speciﬁed as ofﬁcial ISO

standards (OMG, 2011b; OMG, 2011a).

der to satisfy speciﬁc requirements coming from the

peculiarities of a project, business or industry (Braun

and Esswein, 2014; Pardillo, 2010). Therefore, it

seems to be extremely relevant to consider the issue

of extending or modifying EMLs for domain-speciﬁc

adaptations, model transformation support, interoper-

ability and language evolution (Braun, 2015b). Fur-

ther, language extensions and modiﬁcations are con-

tributions to the management of language pluralism.

Instead of springing up “yet another” domain-speciﬁc

modeling language (DSML), having limited practi-

cal relevance, we proclaim the usage of a rather lim-

ited set of common EMLs on the one hand, while fo-

cussing their enhancement, modiﬁcation and extensi-

bility on the other hand (Atkinson et al., 2013; Braun,

2015b)

Extensions or modiﬁcations of EMLs are usually

employed on the meta model level of a language,

which is referred as M2 level (OMG, 2014). Modi-

ﬁcations lead to particular meta model variants of a

considered modeling language (Esswein and Weller,

2007). It is often necessary to address the meta model

level, as the majority of EMLs either does not provide

any extension mechanism or existing mechanisms re-

veal some architectural deﬁcits (Braun, 2015b; Braun,

2015a). Even built extensions of languages with

Nevertheless, we do not want to deny the powerfulness

and accuracy of DSMLs at all. DSMLs are valuable for very

speciﬁc problems or projects.

277

Braun R. and Esswein W..

A Generic Framework for Modifying and Extending Enterprise Modeling Languages.

DOI: 10.5220/0005351702770286

In Proceedings of the 17th International Conference on Enterprise Information Systems (ICEIS-2015), pages 277-286

ISBN: 978-989-758-097-0

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

rather well-deﬁned extension interfaces (e.g., BPMN)

are mainly not designed in accordance to them (Braun

and Esswein, 2014). While this issue might be un-

problematic within single projects, it hampers inter-

operability, change tracking and general comprehen-

sion of the entire modiﬁcation process. Further, it is

necessary to regulate modeling language changes in

order to avoid blowing up or destruction of a language

aggmark and

Agerfalk, 2006).

Generally, this deﬁciency could be tackled by de-

signing consistent and integrated extension mecha-

nisms within EMLs. With regard to the common

four level meta model architecture (OMG, 2014;

Strahringer, 1996), this proposal actually causes a

problem shift to the meta meta model level (M3 level),

as the M3 level should deﬁne appropriate concepts

and constraints for extending a modeling language

that is deﬁned on the meta model level (level M2).

In particular, this aim exemplarily causes a revision

of large parts of the Meta Object Facility (MOF), as

MOF is the most common meta modeling language

(OMG, 2014). However, this is problematic facing

the dissemination of the current MOF version and the

rather crude architecture of some parts of the MOF

itself (Braun, 2015b).

Hence, it seems to be much more feasible and

viable to tackle the issue on level M2 by providing

a reference framework that supports the systematic

and comprehensible design of EML modiﬁcations.

More efﬁcient design of modiﬁcations can also lead to

lower design costs at all. Therefore, this research-in-

progress article aims to outline a generic framework

for modifying meta models of EMLs. Consequently,

the remainder of this article is as follows. Section 2

provides some fundamentals from the ﬁeld of concep-

tual modeling and introduces the E3 model of GREIF-

FENBERG (2004), which is adapted for the structure

of our framework. Section 3 presents the entire frame-

work and describes each part of the framework in de-

tail. The article ends with a short summary and an

outlook to further research.

2 FUNDAMENTALS

2.1 Conceptual Modeling

A conceptual model is deﬁned as the result of a con-

struction process, “done by a modeler, who exam-

ines the elements of a system for a speciﬁc purpose”

(Schuette and Rotthowe, 1998). In contrast to design

models, which typically represent software systems

or parts of it, conceptual models represent and out-

line real world phenomena (Wand and Weber, 2002).

Thereby, graphical or diagrammatic conceptual mod-

els have been established as an appropriate medium

to foster communication between business stakehold-

ers within the information system discipline (Frank,

1999). Thus, EMLs are usually semi-formal modeling

languages. These languages combine aspects of for-

mal languages and natural languages. The syntax of

semi-formal modeling languages is deﬁned formally

within a meta model, but the semantics come from

speciﬁc domain terminology that is typically stated

in a natural language (Pfeiffer and Gehlert, 2005,

p. 111). According to that, a conceptual modeling

language is the result of the application of a speciﬁc

terminology to a meta model based conceptual model-

ing grammar (Wand and Weber, 2002, p. 364). Mod-

eling languages should always be embedded into a

modeling method, which consists of the modeling lan-

guage itself (represented by a meta model) and a pro-

cedure delineating the process of model building and

model usage (Greiffenberg, 2004). Thereby, the meta

model is deﬁned as a model representing a modeling

language (Strahringer, 1996). As stated at the begin-

ning of this article, meta models are typically located

at the M2 level of the common four layer architecture

of MOF (OMG, 2014).

As stated in Section 1, this article considers mod-

iﬁcations of a language meta models due to domain-

speciﬁc alterations or other business-driven purposes.

Alterations of a language meta model can be caused

by the integration of new diagrams or perspectives

(e.g., (Stroppi et al., 2015)), the integration of new

domain-speciﬁc concepts (e.g. (Braun and Esswein,

2014)) or even user-speciﬁc reductions of a language

(based on (zur Muehlen and Recker, 2008)). Gener-

ally, it can be stated that requirements on conceptual

models are frequently changing and it is often neces-

sary to work on different language versions in paral-

lel (Ralyt

e et al., 2004). Therefore, we deﬁne a meta

model modiﬁcation as any kind of meta model alter-

ation, which does not apply possibly existing exten-

sion mechanisms (Esswein and Weller, 2007; Braun,

2015b). The application of an altered modeling lan-

guage, having a notable set of new or changed ele-

ments, that is used by a group of model users leads

to a modeling language dialect

. In addition to the

frequently used term extension, we want to empha-

size, that even meta model reductions and minor meta

model alterations are understood as meta model mod-

iﬁcations, since this article is inspired by the works

from the ﬁeld of meta model conﬁguration manage-

Besides, it is important to emphasize the need for a

more precise deﬁnition of language dialects. For instance,

in terms of both type and quantity of concepts which lead to

an distinction from the original language.

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

278

ment (Esswein and Weller, 2007).

2.2 E3 Model as Frame of Reference

The smallest unit of modiﬁcation can be referred as

conﬁguration item (Esswein and Weller, 2007). Such

a conﬁguration item can stand for all elements that are

speciﬁed within a meta model. In preparation of the

aimed framework, it is required to typecast these ele-

ments in a generic way and under consideration of all

language parts (abstract syntax, concrete syntax and

semantics). Examining the common MOF meta mod-

eling language reveals some shortcomings regarding

to the integrated covering of these aspects, as MOF

solely focusses abstract syntax and suffers from some

architectural problems (e.g., mixing up language and

tool deﬁnitions or self-deﬁnition by the UML infras-

tructure). Hence, an alternative meta modeling lan-

guages was selected: The E3 language of GREIFFEN-

BERG (2004). In contrast to similar approaches such

as MOF (OMG, 2014) or Gmodel (Bettin and Clark,

2010), E3 beneﬁts from its integrated and cohere ar-

chitecture, which is presented in Figure 1.

Model

Level

Object

Level

Property

Level

Type

Level

Instance

Level

Contraint Langauge (ECMA)

Context

Level

View

Level

Presentation

Level

Model

Type (MT)

View Type

(VT)

Presen-

tation

Type (PT)

Object

Type (OT)

Presen-

tation

Object

Type (POT)

Property

Type (PrT)

Presen-

tation

Property

Type (PPT)

Figure 1: Architecture of the E3 meta modeling language

(Greiffenberg, 2004) that is adapted for the structure the

modiﬁcation framework.

The E3 architecture is divided into a type layer

(meta meta model) and an instance level (meta

model), whereby each instantiated element relates to

exactly one type element. Horizontal levels of E3 pro-

vide concepts for the deﬁnition of hierarchical per-

spectives and diagrams to the entire model context for

reasons of user-oriented complexity reduction (Greif-

fenberg, 2004, p. 116). Thus, it is divided into the

Context Level, the View Level and the Presentation

Level, whereby a particular level is bound to the next

level on the left side. It means, that a Model Type

(MT) (e.g., UML) owns several View Types (VT) (e.g.,

static and dynamic views), which in turn refer to par-

ticular Presentation Types (PT). For instance, class

diagrams are presentations of the static view and se-

quence diagrams are presentations of the dynamic

view within UML. Hence, E3 supports separation of

concerns between context and presentation while en-

suring their integration. Vertically, E3 is divided into

the Model Level, the Object Level and the Property

Level (Greiffenberg, 2004, p. 113). The level of ab-

straction descends from the top to the bottom. Within

the model level, the most abstract containers are spec-

iﬁed: Model Types, View Types and Presentations

Types. Below, speciﬁc elements in form of Object

Types (OT) and their corresponding Presentation Ob-

ject Types (POT) can be deﬁned in order to express all

concepts and properties of a language.

Object Types represent intended concepts of a lan-

guage (e.g., UML classes). Presentation Object Types

(POT) represent (perhaps multiple) graphical repre-

sentations of theses elements (e.g., expanded and col-

lapsed UML classes). It is important to note, that

both concepts and relations are understood as Ob-

ject Types in E3 (Greiffenberg, 2004, p. 101). The

lowest horizontal layer describes properties of Object

Types (Property Types) and Presentation Types (Pre-

sentation Property Types). Property Types (PrT) de-

ﬁne particular ranges that can be constituted as sim-

ple ranges (e.g., String, Integer, Boolean) or complex

ranges (references to other Object Types). Each Prop-

erty Type (PT) owns a speciﬁc cardinality (min, max)

and a structure type for managing its instances on a

technical level (Greiffenberg, 2004, p. 102). Presen-

tation Property Types (PPT) are used for the deﬁni-

tion of speciﬁc attributes of graphical elements (e.g.,

connector points between elements).

In addition to the introduced structural elements,

E3 provides an integrated ECMAscript based con-

straint language for the speciﬁcation of complex rules

and constraints both within abstract syntax (e.g., trig-

gers for object renaming or consistency checks) or

concrete syntax (e.g., context-aware graphical adap-

tions).

3 FRAMEWORK

ARCHITECTURE

This section provides the proposed framework for

conducting meta model modiﬁcations based on the

E3 architecture. The framework is vertically divided

into the three components of modeling languages.

Abstract Syntax covers all elements, rules and con-

straints of a language (Wand and Weber, 2002) and

AGenericFrameworkforModifyingandExtendingEnterpriseModelingLanguages

279

Abstract Syntax (Context)

Concrete Syntax (Perspectives, Diagrams)

Semantics

Add

Add new concept

Add new (user-specific) view for complexity reduction

• Horizontal: Additional VT

• Vertical: Refinement of existing VT

• Additional semantics in

the sense of more

textual information

explicated in a natural

language

PrT

Add property to an existing or new OT

• Owned property

• Navigable property:

o Between new OTs; between new and existing OTs

o Between existing OTs ✖

• Range type

• Range values (enumerations)

• Multiplicities (min; max; for unspecified relations)

Add a new diagram of a VT

• Horizontal: Additional VT

• Vertical: Refinement of PT

Inheritances

• Between new OTs

• Between existing OTs ✖

• Between new OT (super) and existing OT (sub)

• Between existing OT (super) and new OT (sub)

POT

Additional representations of OTs

Constraints

Add complex rules

PPT

Additional presentation properties of OTs

• New graphical connection to POT (depends on OT, PT)

• Representation of PrTs within existing OTs

Remove

Remove concept

• Remove super OT

Remove perspective (rarely)

• Reducing textual

statements or

explanations in order to

“dilate” semantics ✖

PrT

Remove property of OT

• Owned property; navigable property

• Range type ✖

• Range values (enumerations) ✖

• Multiplicity limits (min; max)

Remove diagram (rarely)

Inheritances

Remove inheritances

POT

Remove graphical representation(s) of OTs

Constraints

Remove constraints

PPT

Remove presentation properties of OTs

• Remove graphical connection to POT (reducing)

• Remove representations of PT in OTs (reducing)

Alter

Specify

Specifying (mostly generic) existing concepts

• New sub type

Refinement of a view

• Specification of under-

specified semantics of

elements and constructs

• Domain-specific

refinement of elements

or constructs

PrT

Domain-specific concretization of PrTs or their values

• Limitation of multiplicity values (min; max) or ranges

• Overwriting of enumeration value

Refinement of a diagram (restrict number of contained OTs)

Constraints

Specifying constraints (e.g., domain-specific)

POT

Changing the graphical representation of elements

Redefine

All

Renaming the label of a concept or its properties

All

Renaming the label of a view or presentation

• (Redefining the

semantics of a modeling

language by overwriting

parts of the language) ✖

Figure 2: Proposed modiﬁcation framework (thick underlinings and cross symbols emphasize crucial modiﬁcations; cf. Sec-

tion 3.2).

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

280

refers to the previously introduced Context Level of

E3. Concrete Syntax stands for the graphical repre-

sentation of language concepts and their relationships

and refers both to the View Level and the Presenta-

tion Level of E3. TheSemantics column covers the

meaning of modeling language constructs in applica-

tion domains (Pfeiffer and Gehlert, 2005). Semantics

are usually expressed separately by natural language

statements, domain dictionaries or glossaries.

Vertically, the framework is divided into those op-

erations, which can be applied to an element within

the meta model: Add, Remove and Alter. Model el-

ement alterations are further divided into Specifying

and Renaming. Alteration by speciﬁcation refers to

the concretization of generic or under-speciﬁed model

elements (Braun, 2015b). Alteration by redeﬁning

refers either to simple element renaming or to the re-

deﬁnition of their semantics. Figure 2 represents the

modiﬁcation framework by assigning particular E3 el-

ements to segments of the framework matrix.

3.1 Framework Segments

Below, each segment of the framework is presented

in detail by explaining its implications on meta model

elements and possible reasons for adaptation of spe-

ciﬁc alteration techniques. Relevant contributions of

other authors are explicitly stated in order to enable

a seamless integration with existing techniques. We

also consider impacts of meta model changes on al-

ready instantiated models on level M1 in order to

keep them consistent. Therefore, recommendations

for model management are given and points for man-

ual processing are explicated. Additionally, several

examples are given by using the popular business pro-

cess modeling language BPMN (OMG, 2011a).

3.1.1 Add Abstract Syntax

Adding new features to a modeling language con-

stitutes as adding concepts and properties to a meta

model in order to enhance its expressiveness (Atkin-

son et al., 2013). Basically, adding a new OT to a meta

model means contextual enrichment of a language

with a delimitable concept that is not represented so

far. Typically, this is used for dilating the scope of a

language horizontally (while specifying merely refers

to a vertical kind of detailing). In contrast to the im-

plementation of additional OTs, adding new proper-

ties is quite diverse as there are plenty ways for imple-

mentation. First, owned PrTs can be added to OTs in

order to realize a more detailed speciﬁcation of exist-

ing OTs (e.g., by attaching domain-speciﬁc informa-

tion). Also, simple ranges of existing properties can

be extended by new range types or by declaring extra

BPMN

Artifact

«enumeration»

BPMN

Process Types

none

management

private

public

operation

contributes

1..10

1..*

«extension»

BPMN

Business Goal

priority: Integer

BPMN

Activity

completionQuantity: Integer

isForCompensation: Boolean

startQuantity: Integer

maximalDuration: Integer

Navigable PrT

Relation

Owned PrT

New range values

Figure 3: Basal example depicting additional owned and

navigable Property Types (PT), a new Object Type (OT) as

well as extended range values within an enumeration.

range values (e.g., further enumeration values). Sec-

ond, navigable properties (references) can be added

between newly created or original OTs.

However, it has to be emphasized that relations

between original OTs are crucial as they overwrite

the intended core attributes of the language itself.

Third, multiplicities on unspeciﬁed associations can

be added in order to introduce stricter limitations be-

tween instances of these elements.

Further, it is imaginable to introduce new inher-

itances between OTs in order to reduce model com-

plexity and improve the level of hierarchical reuse.

Again, this is unproblematic between newly added

OTs. However, it becomes more complicated when

considering possible inheritances between original

OTs or introducing a new super OT to an existing

(sub) OT. The ﬁrst case refers to the implementation

of hierarchical structures within parts of the original

language, while the latter covers the issue of OT spe-

cialization. Finally, it is also possible to add new

complex rules within the program code of the used

constraint language. This can be done due to the im-

plementation of rigid, perhaps business-speciﬁc rules.

Consequences. Generally, adding meta model ele-

ments is mostly unproblematic, since a previously in-

stantiated model still corresponds to a subset of the

extended meta model. Thus, appending new OTs

does not require any follow-up action. Adding PTs

requires more attention if they are mandatory. In

this case, property values have to be assigned to

model instances in order to ensure validity. Addi-

tional property range types or range values do not re-

quire alterations as they only extend the scope of valid

ranges. In contrast, adding new multiplicities repre-

AGenericFrameworkforModifyingandExtendingEnterpriseModelingLanguages

281

sents stronger constraints of models. Lowering min-

ima values and raising maxima values are unproblem-

atic, since the former multiplicity limits are always in-

cluded. In contrast, increasing minima values and re-

ducing maxima values require modiﬁcations. Increas-

ing minima values causes the identiﬁcation of affected

model elements. If necessary, default elements have

to be added in order to match the rule. In the case of

reducing maxima, surplus relations to other elements

have to be reduced manually in order to match the

new max value (Esswein and Weller, 2007).

Similar to that, introducing new inheritances usu-

ally lead to model alterations. Hierarchical structures

between added OTs or existing super OTs and newly

added sub OTs are unproblematic and do not require

follow-up actions. Inheritances, which create any sit-

uation where an original OT received a new super

OT, require revisions by assigning all properties of

the super OT to the respective sub OT. Afterwards,

each added property has to be dealt like a generally

added property. Accordingly, it is perhaps necessary

to deﬁne and add default property values to model in-

stances.

3.1.2 Remove Abstract Syntax

Removing features of a meta model is a fairly hard

intervention as it erases original meta model con-

structs and reduces the expressiveness of the lan-

guage. While meta model extensions are considered

in numerous publications, meta model reduction has

not gained comparable exposure, although it is con-

ceived as very important (Fondement et al., 2013,

p. 139). Motivated by the complexity of the UML

meta model, BAE ET AL. (2008) introduce the con-

cept of meta model slicing that intends to cut out se-

lected classes, properties and their transitively depen-

dent elements in order to keep only user-relevant meta

model parts (Bae et al., 2008). Similar to that, SEN ET

AL. (2009) proclaim meta model pruning in the sense

of removing all unnecessary classes and properties by

applying a graph-based removal algorithm (Sen et al.,

2009, p. 33).

FONDEMENT ET AL. (2013) introduce the meta

model unmerging approach as contradiction of merg-

ing; the union-like copy technique from MOF (OMG,

BPMN

Human Performer

BPMN

Performer

BPMN

Potential Owner

BPMN

Resource Role

Removal requires new inheritance

Figure 4: Removal of an object type requires the integration

of a new inheritance (OMG, 2011a, p. 154).

2014). Therefore, eleven unmerging use cases (UC)

are proclaimed (Fondement et al., 2013, p. 143).

As the unmerging approach provides an integrated

framework for nearly all relevant reduction cases, we

partly adapt their patterns to our framework: Removal

of OTs refers to UC3 (classes); removal of super OTs

refers to UC7 (hierarchies); removal of owned prop-

erties refers to UC5; removal of navigable properties

refers to UC6; removal of multiplicity limits refers

to UC11 and removing constraints refers to UC10

(Fondement et al., 2013). Additionally, we propose

removing range types and range values. Thus, it

might be possible to release some constraints or re-

move unused range values.

Consequences. If an OT is removed from the meta

model, its instances need to be deleted, too. Besides,

references to the respective OT need to be removed

(both on type and element level). Those references

can be occurred as properties or constraints. If an

OT was a super OT within a hierarchy, it is neces-

sary, to re-organize the meta model hierarchy in order

to ensure hierarchical relations of sub OTs to all their

super OTs in order to bridge the created gap (Fonde-

ment et al., 2013, p. 143). On model level, instances

of sub OTs of the removed OTs need to be updated

recursively in terms of removing inherited properties.

If any kind of a PrT is removed from the meta model,

its corresponding properties on model level are also

removed. Removing a speciﬁc range type is indeed

allowed, but leads to unspeciﬁed properties. We thus

recommend the speciﬁcation of a default range type.

If range values (enumerations) are removed, it is also

suggest to deﬁne a default enumeration value in order

to avoid null values. Removing multiplicity values

(min, max) or constraints requires no follow-up ac-

tions, since the model is than less constrained at all

and still valid.

3.1.3 Specify Abstract Syntax

Specifying the abstract syntax encompasses speciﬁc

conﬁguration of intentionally generic elements or

those elements, which are perceived as overly generic

in the modeling context (Braun and Esswein, 2014,

p. 47). Such specialization is mostly implemented

by introducing new sub OTs owning domain-speciﬁc

PrTs. On the level of PrTs, it might be appropriate

to specify multiplicity values or to limit ranges (e.g.,

Integer instead of Float). Further, speciﬁc range val-

ues can be overwritten if the previous notation is too

broad

. In contrast to modiﬁcation by addition, spec-

Actually, each alteration is a combination of adding or

even removing from a logical point of view. For reasons of

a purposive representation, we refrain from that separation.

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

282

«extension»

BPMN

Evidence-based Expression

BPMN

Complex Gateway

«extension»

BPMN

Evidence Gateway

activation Condition

0..1

«extension»

BPMN

Medical Decision Logic

logicalExpression: String

0..1

activationCondition

0..1

BPMN

Expression

Specification of Complex Gateways

Figure 5: Specifying elements by inheritances (adapted

from the BPMN4CP extension (Braun et al., 2014, p. 15)).

ifying has a much stronger relation to the scope of the

meta model and its limitations.

Consequences. Speciﬁcation of OTs by introducing

new sub OTs does not necessarily require follow-up

actions, since the model is still valid. However, a re-

deﬁnition of those elements that are instantiated from

the speciﬁed generic OT might be rational. Redef-

initions of multiplicity values have to be treated as

described in Section 3.1.1. If enumeration values are

overwritten, a matching list is proposed in order to

comprehend respective updates.

3.1.4 Redeﬁne Abstract Syntax

Redeﬁning abstract syntax covers the case of renam-

ing an element (Esswein and Weller, 2007). Such re-

deﬁnitions are mostly conducted for a better model

understanding in a speciﬁc user environment or avoid-

ing natural language based misunderstandings and

ambiguities. Therefore, renaming is tightly coupled

to semantics as it refers to real-world concepts. There

are no direct implications on model level.

«extension»

BPMN

Department

BPMN

Pool

Figure 6: Rename the Pool concept in order to express or-

ganizational units on type level.

3.1.5 Add Concrete Syntax

Modiﬁcation of the concrete syntax is rarely consid-

ered in literature so far. With regard to the above men-

tioned E3 meta framework, the concrete syntax can

be described by View Types (VTs, ﬁltering perspec-

tives), Presentation Types (PTs, diagrams), Presen-

tation Object Types (POTs, graphical constructs) and

corresponding Presentation Property Types (PPTs).

Adding a new VT is either used for adding bet-

ter complexity reduction mechanisms within a large

set of OTs or for better user-speciﬁc segmentation of

the context (similar to separation of concern (Atkin-

son et al., 2013, p. 47)). Such a ﬁltering can be imple-

mented horizontally or vertically. The horizontal type

covers the deﬁnition of further VTs on the set of all

OTs within a model type. The vertical type refers to

an existing VT and reﬁnes them. Additional PTs (dia-

grams) are implemented in a similar way. Horizontal

PT addition refers to new PTs within a VT; in parallel

to other diagrams. Vertical PT addition addresses the

reﬁnement of existing diagrams, what is tightly cou-

pled to VT additions. For instance, STROPPI ET AL.

(2015) provide additional resource perspectives and

diagrams within the BPMN.

Adding new POTs is a quite simple operation that

is often provided by modeling tools or even stated

in meta model speciﬁcations (e.g., (OMG, 2011a)).

Thus, it is possible to add alternative graphical repre-

sentations for OTs in order to support model under-

standing (e.g., (Stark and Esswein, 2012)). Adding

PPTs to a meta model is caused by two purposes.

First, is might be necessary to represent PrTs of exist-

ing OTs graphically (e.g., property-dependent icons

within the graphic). Second, for the graphical rep-

resentation of relations between original and added

POTs.

Consequences. Adding new VTs, PTs, POTs or PPTs

does not require dedicated follow-up actions as it only

provides more alternatives for model representation.

3.1.6 Remove Concrete Syntax

Removing VTs or PTs is a rather uncommon opera-

tion as it presumes a strong segmentation within the

meta model, which can be found in the context of

enterprise architecture modeling language (Lankhorst

et al., 2009). In contrast, removing POTs or partic-

ular PPTs is more relevant for several reasons (zur

Muehlen and Recker, 2008). First, it is an appro-

priate means for improving model understandability

by reducing the occasionally vast set of graphical ele-

ments. Second, it might be promising to reduce some

relations between model elements in order to enhance

model readability. Removing a POT requires the

deletion of PPTs, which originally has implemented

graphical references to these POTs. Thus, all ref-

erences to these POTs have to be identiﬁed and re-

moved.

Consequences. Similar to abstract syntax, removing

concrete syntax requires various follow-up actions on

model level. Removing a VT is mostly unproblem-

atic as it just works as an abstraction ﬁlter that is than

missing. We propose to assign all PTs of the VT

to the next existing VT in the E3 hierarchy. If the

VT is located on the topmost layer, containing PTs

are directly assigned to the respective MT. The same

AGenericFrameworkforModifyingandExtendingEnterpriseModelingLanguages

283

procedure should be applied to PTs and containing

POTs. Removing POTs is manifested by both erasing

all graphics of that POT and erasing all affected PPTs

(e.g., removing all ingoing and outgoing edges). If

PPTs are removed, all affected graphics have to be

updated and reloaded in the new presentation style.

Finally, it has to be stated, that all these graphical al-

terations cause a revision of model positions due to

particular re-arrangements (Becker et al., 2007; Ess-

wein and Weller, 2007).

3.1.7 Specify Concrete Syntax

Specifying VTs addresses the case of limiting the

number of containing PTs in order to focus on spe-

ciﬁc diagrams without removing particular PTs. For

example, this could be useful in order the empha-

size, that the structural view on UML is limited to

class and package diagrams. Specifying PTs stands

for the limitation of containing POTs in order to fo-

cus particular elements. Next to these more uncom-

mon operations, speciﬁcation of POTs is often used

in order to adapt given graphics to speciﬁc user en-

vironments. A simple example for that is the usage

of emphasizing colors or icons that are typical for a

speciﬁc application, domain or context. In short, typ-

ical monochrome rectangles and circles are adapted

visually in order to bridge the cognitive gap between

a model and its readers.

Document

(Patient File)

Therapy Task

Support Task

Diagnosis Task

Figure 7: Graphical speciﬁcations of Activities, Artifacts

and Gateways within BPMN (Braun et al., 2014).

Consequences. Generally, speciﬁcations of the con-

crete syntax can be automatically adapted to its in-

stances (e.g., by updating graphics and diagrams).

However, it is often necessary to reposition both mod-

els and diagrams due to changing element sizes and

dimensions.

3.1.8 Redeﬁne Concrete Syntax

Redeﬁning the concrete syntax is understood as re-

naming a view or presentation within a meta model in

order to increase user consciousness of their meaning.

There are no direct implications on model level.

3.1.9 Add Semantics

Additional semantics is understood as providing more

contextual information (and thus mostly restrictions)

regarding the meaning of particular concepts and con-

structs by explicating further information in a natural

language. Hence, the relation of particular concepts to

real-world entities or concepts is sharpened and speci-

ﬁed. We therefore divide into explicit and implicit ad-

dition of semantics. The ﬁrst one addresses the stated

extension of textual element descriptions. The second

one refers to additional semantics coming from syn-

tactical changes.

Consequences. As the semantics of a conceptual

modeling language cannot be formalized, it is not

possible to automate any semantical modiﬁcation on

model level. Rather, it has to be proven, whether a

model is still consistent in the light of the changed

semantics. If not, parts of the model have to be re-

arranged (Esswein and Weller, 2007).

3.1.10 Remove Semantics

Removing semantics is understood as increasing the

degree of freedom regarding to a particular meta

model element. This could be seen as simpliﬁcation

of a language in order to provide more interpretations

and applications. On the one side, such reduction

could be helpful for widening the scope of a language

or its concepts. On the other side, it provokes the

risk of language softening and defacement (see Sec-

tion 3.2).

Consequences. There is no need for further follow-

up operations as the models are implicitly valid.

3.1.11 Specify Semantics

Specifying semantics covers situations where inten-

tionally under-speciﬁed semantics of meta model ele-

ments are reﬁned and described in detail by providing

more speciﬁc contextual information. Hence, the way

of model interoperation is usually restricted. This is

a simple way of adapting a modeling language for a

speciﬁc domain without changing the syntax at all.

For instance, the Lane concept of BPMN is intention-

ally under-speciﬁed and needs to be adapted for a par-

ticular model context (OMG, 2011a, p. 308).

Consequences. Each model element, which is instan-

tiated from a meta model element with speciﬁed se-

mantics, needs to be checked whether it is still in the

tighter scope of meaning or not. If not, it is necessary

to update either the title of the element or the model

arrangement.

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

284

3.1.12 Redeﬁne Semantics

The redeﬁnition of parts of a modeling language

should not be acceptable as it would lead to an imme-

diate defacement of the semantical core of a model-

ing language. As a modeling language dialect should

always enable the identiﬁcation of the original mod-

eling language, we do not recommend semantical re-

deﬁnitions. It has to be emphasized, that semantical

redeﬁnitions can also occur by enormous adding and

removing operations (see above). Thus, it is neces-

sary, to provide strong reasons and evidences for each

of these operations in order to avoid excessive alien-

ation from the original language.

3.2 Modeling Language Defacement

As stated at several passages, iterative or even exces-

sive modiﬁcations of a language meta model could

lead to language defacement or language alienation.

It stands for a remarkable estrangement of the origi-

nal intention of a language and is caused by the pos-

sibility of both removing elements and changing its

semantics. We therefore distinguish three categories

of alienation:

Concept Estrangement. Basically, each alteration of

a language element leads to some kind of estrange-

ment. However, we argue that added relations and in-

heritances between existing OTs are especially cruical

as they contradict the original structure and meaning

of a modeling language. We therefore argue, that ad-

ditional inheritances and references between original

OTs should be avoided.

Language Reduction. As stated, meta models can be

pruned or sliced by respective techniques. However,

especially a strong reduction of abstract syntax de-

creases the intended expressiveness and consistency

of the entire language. In order to avoid destruction

of the language core (in the sense of the most impor-

tant and relevant OTs and its relations), it seems to be

promising the assess the indispensability of an OT for

a language and forbid its removal. Alternatively, is

might be appropriate to relax strict constraints within

a meta model (e.g., changing mandatory to optional

relations) and avoid element removing in general.

Semantics Redeﬁnition. As already stated, explicit

semantical changes or redeﬁnitions are crucial if they

affect large parts of a language and lead to a decou-

pling of syntactical elements and their interpretation.

We therefore recommend, that only semantical speci-

ﬁcations and additional semantics should be applied.

Removing or overwriting is not recommended.

4 CONCLUSION

This research-in-progress article propose an inte-

grated framework for meta model modiﬁcations of

enterprise modeling languages in order to support sys-

tematic ad hoc changes. We therefore adapted the E3

meta framework and provide add, remove and change

operations for each segment. As the framework is

generically applicable to any meta model, it can be

used for conducting meta model alterations of model-

ing languages from different meta model languages.

We explicitly focused on the meta model level as most

of the adaptions are conducted on that level due to ar-

chitectural reasons within the most languages. This

article also outlines limitations and risks of excessive

meta model interventions. Of course, there are several

aspects for further research:

In terms of better methodical support, an algo-

rithm for (partly automated) adaption of models af-

ter meta model modiﬁcations should be designed. As

there are several approaches for single purposes (e.g.,

meta model pruning), it seems to be necessary to inte-

grate them to an entire method according to our pro-

posed framework. It is than possible to extend each

meta model based language systematically. Techni-

cally, this method should be designed generically but

needs to be validated with MOF based languages as

MOF is the de-facto standard for meta meta model-

ing. Further, it is necessary to provide suitable mod-

iﬁcation patterns for speciﬁc modiﬁcation purposes.

Finally, research on modeling language dialects needs

to be intensiﬁed in general. For instance, it is conceiv-

able to highlight those elements of a meta model that

should not be changed in order to keep a stable lan-

guage core a avoid language defacement.

ACKNOWLEDGEMENT

The presented research results are partial outcome

of the research project ”SFB Transregio 96” that is

funded by the German Research Foundation (DFG).

The authors is grateful for the funding and its related

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.

Bae, J. H., Lee, K., and Chae, H. S. (2008). Modulariza-

tion of the uml metamodel using model slicing. In In-

formation Technology: New Generations, 2008. ITNG

AGenericFrameworkforModifyingandExtendingEnterpriseModelingLanguages

285

2008. Fifth International Conference on, pages 1253–

1254. IEEE.

Becker, J., Delfmann, P., and Knackstedt, R. (2007). Adap-

tive reference modeling: integrating conﬁgurative and

generic adaptation techniques for information models.

In Reference Modeling, pages 27–58. Springer.

Bettin, J. and Clark, T. (2010). Advanced modelling made

simple with the gmodel metalanguage. In Proceedings

of the First International Workshop on Model-Driven

Interoperability, pages 79–88. ACM.

Braun, C. and Winter, R. (2005). A comprehensive enter-

prise architecture metamodel and its implementation

using a metamodeling platform. Proceedings of the

Workshop Enterprise Modelling and Information Sys-

tems Architectures, pages 24–25.

Braun, R. (2015a). Behind the scenes of the bpmn exten-

sion mechanism - principles, problems and options for

improvement. In Proceedings of the 3rd International

Conference on Model-Driven Engineering and Soft-

ware Development.

Braun, R. (2015b). Towards the state of the art of extending

enterprise modeling languages. In Proceedings of the

3rd International Conference on Model-Driven Engi-

neering and Software Development.

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., Schlieter, H., Burwitz, M., and Esswein,

W. (2014). Bpmn4cp: Design and implementa-

tion of a bpmn extension for clinical pathways. In

IEEE International Conference on Bioinformatics and

Biomedicine (BIBM), pages 9–16. IEEE.

Esswein, W. and Weller, J. (2007). Method modiﬁcations in

a conﬁguration management environment. Proceed-

ings of the Fifteenth European Conference on Infor-

mation Systems, pages 2002–2013.

Fondement, F., Muller, P.-A., Thiry, L., Wittmann, B., and

Forestier, G. (2013). Big metamodels are evil. In

Model-Driven Engineering Languages and Systems,

volume 8107 of Lecture Notes in Computer Science,

pages 138–153. Springer Berlin Heidelberg.

Frank, U. (1999). Conceptual modelling as the core of the

information systems discipline-perspectives and epis-

temological challenges. In Proceedings of the Fifth

Americas Conference on Information Systems (AM-

CIS 1999), pages 695–697.

Frank, U. (2002). Multi-perspective enterprise model-

ing (memo) conceptual framework and modeling lan-

guages. In Proceedings of the 35th Annual Hawaii

International Conference on System Sciences, pages

1258–1267.

Greiffenberg, S. (2004). Methodenentwicklung in

Wirtschaft und Verwaltung. Kova

aggmark, M. and

Agerfalk, P. J. (2006). Why software

engineers do not keep to the principle of separating

business logic from display: A method rationale anal-

ysis. In Advanced Information Systems Engineering,

pages 399–413. Springer.

Lankhorst, M. M., Proper, H. A., and Jonkers, H. (2009).

The architecture of the archimate language. In En-

terprise, Business-Process and Information Systems

Modeling, pages 367–380. Springer.

OMG (2011a). Business Process Model and Notation

(BPMN) - Version 2.0. Object Management Group

(OMG).

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.

Pardillo, J. (2010). A systematic review on the deﬁnition of

uml proﬁles. In Model Driven Engineering Languages

and Systems, pages 407–422. Springer.

Pfeiffer, D. and Gehlert, A. (2005). A framework for

comparing conceptual models. In Proceedings of the

Workshop on Enterprise Modelling and Information

Systems Architectures (EMISA 2005), pages 108–122.

Citeseer.

Ralyt

e, J., Rolland, C., and Deneck

ere, R. (2004). Towards

a meta-tool for change-centric method engineering: A

typology of generic operators. In Advanced Informa-

tion Systems Engineering, pages 202–218. Springer.

Scheer, A.-W. and N

uttgens, M. (2000). ARIS architecture

and reference models for business process manage-

ment. Springer.

Schuette, R. and Rotthowe, T. (1998). The guidelines of

modeling–an approach to enhance the quality in in-

formation models. In Conceptual Modeling–ER’98,

pages 240–254. Springer.

Sen, S., Moha, N., Baudry, B., and J

equel, J.-M. (2009).

Meta-model pruning. In Model Driven Engineering

Languages and Systems, pages 32–46. Springer.

Silingas, D. and Butleris, R. (2009). Towards customizing

uml tools for enterprise architecture modeling. Infor-

mation Systems, pages 25–27.

Stark, J. and Esswein, W. (2012). Rules from cognition for

conceptual modelling. In Conceptual Modeling, pages

78–87. Springer.

Strahringer, S. (1996). Metamodellierung als Instru-

ment des Methodenvergleichs: Eine Evaluierung am

Beispiel objektorientierter Analysenmethoden. PhD

thesis, TU Darmstadt.

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

Deﬁning the resource perspective in the development

of processes-aware information systems. Information

and Software Technology, pages 86–108.

Wand, Y. and Weber, R. (2002). Research commen-

tary: information systems and conceptual modeling—

a research agenda. Information Systems Research,

13(4):363–376.

zur Muehlen, M. and Recker, J. (2008). How much lan-

guage is enough? theoretical and practical use of the

business process modeling notation. In Advanced in-

formation systems engineering, pages 465–479.

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

286